Question

Say I’m trying to develop an exploit for a certain software and it can respond with two seperate behaviors: one, the process crashes due to incorrect variable assignment or two, I gain control of EIP and return to an invalid address. The reason for these two different behaviors is due to ASLR and because I only have a partial information leak I am forced to do some brute forcing. I would like the program only to break when EIP is modified. However, because the processes are constantly crashing and respawning, I have no way of telling the program to stop only when EIP is modified; the process will always crash in GDB regardless. How can I overcome this difficulty? (Thought about posting this in IT Security but decided it would be better here since this has more to do with GDB)

Answer 1

You should set a breakpoint before memory corruption takes place. At the moment of the crash gdb will break and you can use the command show stack which will tell you want it thinks the call stack is, however if you have already corrupted the EIP, then you have partially corrupted the function’s stack frame and show stack will be partially corrupted (depending on how much of the stack you have smashed!). However this process can help narrow down where the memory corruption takes place, and you can always set a break point higher up in the call stack and step through the program.

GDB also has reverse debugging, which is probably an easier approach because you can just step backwards after the crash. However this feature is fairly new. Usually hackers had to use the technique described above.