I want to exploit a vulnerability of a C piece of code for educational purposes by controlling the stack. A simple stack based buffer overflow, overwriting the return address with the address where a shellcode should be executed. The code is a simple function which takes as arguments a buffer and tries to strcpy() the buffer into a fixed size. The parameter given from main is the argv[1]. So I think that if I found the exact amount of memory that I have to overwrite then I could simply give as input a string composed by \x90 (NOP instructions) followed by the shellcode and in the end the address of this buffer. Since this is the first argument its address is $ebp+8 and you can find this by running gdb, set a breakpoint in the begining of the function and just type i args gives you the address of the string which is passed as an argument. So I found that if I overwrite n bytes and then give the values of the address then this will exactly overwrite the return address. So I have an input like this:
perl -e print(\x90 x n-sizeof(shellcode) . shellcode . address)'
It didn't work and I tried to understand why. With gdb I run the program. I put a breakpoint before the strcpy() function. At that point I have an argument which is a string pointer that points to my input and its address is the same with that given at the end of my string input, I stepped forward 1 instruction. I examined the stack. I have now the saved eip ($ebp + 4) with the value of the address given at the end of argv[1], which is the expected behavior (That implies that it doesn't overwrite other addresses above the ret address that is the value of the first argument). The weird thing is that now the content of $ebp+8 is not the "address" but something else? But the content of the saved eip is the address that points to my string that exploits the vuln. But it doesn't seem that the ret addr executes the content of that address.
buf?