I was testing out a buffer overflow and the following strange thing happened:
The return address is at
0xbffff7bc which I discovered from testing. I replaced it with the value I wanted
When return is called it seems to direct to a different address than the one I added. From the back trace it can be seen that it tested all the addresses next to that one.
However, it replaced
0xbffff71b. Clearly it didn't change the other addresses it tried to return to in the backtrace 1 through 6, but 0 is incorrect. It seems that #0 should have been
0xbffff636 but it got edited, as all the other addresses after it were tested.
What is a possible reason for why the address changed?
This shows what's at address
0xbffff636 it's the middle of a NOP sled. The buffer is 500 bytes the return address is at 540 offset.
I am currently at a break point at the return statement, and what's strange is that doing a backtrace at the point shows that
0xbffff636 was tried as a return point, but I haven't returned yet. When I continue and return the backtrace turns into the backtrace I posted originally with '0xbff636` becoming '0xbffff71b'. Thought I might add that.
Instead of just continuing I continue to 'next' through the program till I left the function
recv_line that copied data to a buffer(called request) it was passed. That function returned fine since I didn't touch it's address. Now I continued through the handler function above until I got to the end and this is what I saw:
It seems to not find
0xbfff636 to valid when it first sees it. I have done overflows in this environment before, so I am pretty sure no protections are on.
Note: I'm compiling with -g debug flag. I run the process as sudo. Then attach to the running process with gdb