Pointer Crash Course C++

Pointers In C++ (Crash Course)


Before We Get Started:
First lets talk briefly about computer memory and how it's addressing works.
Just like your house, the computer has an address for every memory block.
However instead of 124 LeeT Haxz0r Street, it is in a hexadecimal format.
So it looks something like ~ 0x00000000. Lets look at an example..

Code:

#include

int main()
{
int myInt;

std::cout << "The address of \'myInt\' is: " << (&myInt) << std::endl;

return 0;
}

Ok, lets analyze this code.
First we declare an variable of type int called 'myInt'.
Then we use 'std::cout <<' to print the address of the variable to the screen.
This is possible because of the little '&' symbol. This is called the address operator.
Okay let's compile this thing..


$ g++ example.cpp -o example
$
$./example
$The address of 'myInt' is: 0xbfcbfab0

_________


Dev C++..
[F9 Key]
note: If you are compiling and running on widows, and your window vanishes before you can see the output.. add one of these:
'cin.get();'
__________

Alright if you compiled and ran it successfully congrats, please note that the memory address will vary. Alright since you understand a little bit how addressing works lets move on to actual pointers.

__________

Okay, so now with that all out of the way what do 'pointers' actually do.
Well their name is actually the thing they do, they point.
What they do is point to another address, this could be the address of a variable or something a little more complex like a function (we won't cover that yet).
In the example above we found out the address of our int by using that handy little operator called the.... yep, you guessed it: The Address Operator!

Lets open up that program and actually use a pointer and not just print the address to the screen..
Get your IDE's ready!!

Code:

#include

int main()
{
int myInt;
int* p_myInt = &myInt; // in this case p stands for pointer :p

std::cout << "The address of \'myInt\' is: " << (&myInt) << std::endl;
std::cout << "The address of my pointer \'p_myINt\' is: "<< p_myInt << std::endl;
return 0;
}

Alright compile and run that!
Again the address will vary!

So for my output I got:
The address of 'myInt' is: 0xbfe52570
The address of my pointer 'p_myINt' is: 0xbfe52570

Hah!! The addresses match, so we successfully used a pointer.
Alright, pretty cool eh?
Wouldn't it be cooler if you could actually see the value that is at that address?
Well it turns out you can :]

To do that we are going to use the '*' dereferencing operator!
We are going to edit that program again a minuscule amount, let's assign a value to myInt~
Code:

#include

int main()
{
int myInt = 6;
int* p_myInt = &myInt; // in this case p stands for pointer :p

std::cout << "The address of \'myInt\' is: " << (&myInt) << std::endl;
std::cout << "The address of my pointer \'p_myInt\' is: "<< (p_myInt) << std::endl;
std::cout << "The VALUE of myInt is : " << (myInt) << std::endl;
std::cout << "The VALUE of *p_myInt is : " << (*p_myInt) << std::endl;
return 0;
}

Compile and run it

Here is my output~
The address of 'myInt' is: 0xbfb2810c
The address of my pointer 'p_myInt' is: 0xbfb2810c
The VALUE of myInt is : 6
The VALUE of *p_myInt is : 6

poting by Id4_dani

Trojan Horses

Trojan Horses


Back to the "modern" Trojan Horses. They're pretty much the same: invisible to the naked eye; appear within harmless programs; require some form of user/operating system intervention to activate; and they do something unexpected by surprise. This article is just to convey a basic principle about the design of Trojan horse programs.

Trojans are designed to access permissions and exploit resources. The goal of password snatchers is to securely leak the login/password pairs to the Trojan author, and the goal in kleptographic attacks is to securely leak private keys to the attacker.

Nature of Trojan Horses


There is no "real" definition of a Trojan horse. It all depends on the perspective of the user that runs into it. From the perspective of a hacker (generally black-hat hackers), a reboot monitoring Trojan (useful in making sure no one used your machine) is not a Trojan to him/her since the hacker knows what it's about. From a law enforcement agent or people like that, it is a Trojan since the agent doesn't know it's there.

There are two examples of Trojans. One is a Trojan that is nothing more than a bug. Don't think that's a good thing. This bug could be bad enough that when planted properly, a Trojan author can break into the computer system. The second Trojan is a mathematical one. The statistical distribution of the output of a random number generator is affected so that it makes the generator very sensitive to the input entropy (I will not go into detail in this, please Google if you do not understand this :D).

TH in a text editor


An example of a text editor being used as a target for a Trojan horse:

If there was an installed text editor on a multiuser operating system which cannot be deleted or modified by the users themselves, then this program has certain unique privileges. For instance, It can access all the text files that users create or open. This would be the perfect target for a Trojan horse. When the Trojan is installed on this program, it will store data from users and makes the data accessible for the Trojan horse author.

Salami Slicing


There was once an article describing a Trojan horse attack that was intended to achieve money. This was carried out by an employee of a bank. He managed to get 70 000$ by taking a few cents from every account, and transferred it into his own account. It got the name of salami slicing because small amounts of money were taken from a lot of accounts. It's pretty useful to prevent anyone from noticing any drastic changes. The bank Trojan had access to money therefore the Trojan steals the money. Therefore, a text editor has access to documents so the Trojan steals the documents (pretty simple isn't it?).

Password Snatching


Every hacker would love to steal login/password pairs (referring to black-hat hackers). Password-snatching programs are installed when a system is infiltrated. These programs are also called rootkits. They were probably written in DOS terminate and stay resident programs (TSR). They record all keystrokes entered via the keyboard and patch the operating system hardware interrupt for key presses and log them to a file.

It is best if a password-snatching Trojan is hosted in a program that could access the passwords of users, like the UNIX "passwd" program. It verifies the identity of UNIX users by checking the login/password pairs. One could copy the Trojan to the end of the passwd program, or one could modify the source code for the password program, recompile it, and then install the compromised version (only if the root access is possible).

However, if the source code for the passwd program is updated and the administrator compiles a new version of it, then the attack would fail. So it would make sense to install a Trojan horse into the compiler which will increase the percentage of success of the attack. But if the compiler is recompiled, then the code that secretly inserts the Trojan into the passwd program would be gone.
______________________________________________________________________

There's not much left for me to explain. But one more thing for you to see :

Ken Thompson described an involved Trojan horse attack.

CODE :
compiler(char*s)
{
...
}


This is a figure of a normal compiler (ANSI C notation) (I did not create this)

The parameter s is a pointer to a string that contains the source code. The idea is to insert a source level Trojan horse into the source code of the compiler that checks for two patterns in the string s.

The first pattern is source code corresponding to the password verification program. When it is found, the password-snatching source code is added to the program before it is compiled. But the Trojan is not saved to the source file of the password program.

The second pattern is source code corresponding to the compiler. When it is found, the entire compiler Trojan is included in the compiler source code. It will contain all of the source code for the Trojan which is marked by the "if" statements in this following figure.

CODE :
compile(char*s)
{
if (match)s,pattern1) ==true)
{
compile(trojan1);
return;
}
if (match)s,pattern2) ==true)
{
compile(trojan2);
return;
}
...
}


Figure of a compiler with Trojan (ANSI C notation)(I did not create this either)

Whenever the compiler is compiled, the Trojan copies itself into the source file for the compiler. It can be added to the source for the compiler then the compiler could be recompiled, and the old compiler could be replaced. This would remove all traces of the source code for the Trojan attack. It would remain in binary form, integrated with the compiled instructions.

So Thompson's Trojan horse attack exploits the capabilities of its host. For example, it exploits the fact that compilers are used to create programs such as the passwd program and the compiler itself.
Also, it exploits the fact that the passwd program has access to login/password pairs and that the compiler has access to them as well by transitivity.

Yeah... I believe that this is okay to be an overview of Trojan horses. Please note that this is my first article, so my writing skills are not that great D:
Poring by Id4_dani