CareerCup

Well, to understand what is happening in this case, one needs to understand the way sub routine calls are handled by the compiler which in turn is executed by the OS using a stack to store state and pass parameters.

So when you make a call to a func with the following declaration:

int myFunc(int val1, char val2)

what is really happening is that (assuming this is a regular function call and not a fastcall. In the later everything happens over registers)
a. The input parameters - val1 (4 bytes) and val2 (1 byte) are pushed on to the stack. The order and size will depend on the language and compiler.
b. The return address (of the current processor pointer) is pushed onto the stack
c. The local variables get allocated on top.

So visually, the process stack looks like this:

| local variable n |
| local variable n-1 |
| ... |
| local variable 1 |

| RETURN ADDRESS |

| parameter n |
| parameter n-1 |
| ... |
| parameter 1 |


After executing the function there is an instruction to return back by poping out the RETURN ADDRESS on the stack and returning to that location for the next instruction to execute.

Now, coming back to this program, the Buffer Overflow (BO) will first exceed the 50 units of storage on the stack for the local variable (array in this case), then overwrite the 'return address' and go ahead. Finally, when the program finishes it tries to return but to address '51', which is meaningless and most likely contains no valid instructions or in some cases an instruction that tries to reference an invalid memory location i.e. a virtual address that is not backed by content on physical memory. The latter can result in a segmentation fault (which in the windows world is error - 'Access violation')

When I tried the program, I did not see the program crash. What I have seen is that the program just runs into an endless loop.

The reason why there is an endless loop is that, as I guess, the buffer overflow after 50 elements just erased(or say overwrites the value of local variable i), then i becomes 0, so it is able to start the for loop from 0... and this goes on again and again...

You can even put a 'printf' before 'buff[i]' to trace exactly how the value of 'i' is changed. You should be able to see, 0-51 1-51 1-51... loops like this.

I tried with a printf inside for...
it prints upto 100 and throws segmenation fault after that...

instead of 100 I changed it to 250 and it behaves same..
prints upto 250 and throws segmentation fault...

In java there would through an ArrayIndexOutOfBoundsException when i=50. In C I believe it will keep running as long as there is a valid memory address there, so it's kind of unpredictable.

Hey guys, you're learning how to hack!

What you are doing is overwriting the value at the address of buff[i]. Thus, at the point i=51 & >, you are doing nothing wrong and so your program doesn't crash.

Ex:

&buff = 0x00 (** FOR EXAMPLE **)
so &buff[51] = 0x33

and so, buff[51] = 0 simply does that.

OK, so easy right? But why not crash, well that's simply. You're program is allowed to modify that address. If the OS were to restrict access to the address for your process, then BOOM, crash. If another thread in your program were using that address and you're putting a 0 in that address causes problems...then BOOM, crash. (I use "BOOM" and "crash" loosely).

Why is this hacking, because this is how your program gains access to other parts of the PC (if you will). How or why is this significant for hacking...well, if you're truly interested, you'll figure it out....

Well,
char * s = "hello";
s[1] = 'a'; <-----------CRASH!!

Usually, strings like s="hello" are placed in the read-only section. So when you try to assign a value to s[1], it "booms".

for me running this prog on ubuntu 10.04...says
*** stack smashing detected ***: ./a.out terminated