hacking-the-art-of-exploitation

Back in the debugging terminal, the first breakpoint is encountered.
Some important stack registers are displayed, which show the stack setup
before (and after) the handle_connection() call. Then, execution continues
to the int3 instruction in the shellcode, which acts like a breakpoint. Then
these stack registers are checked again to view their state at the moment the
shellcode begins to execute.
Breakpoint 1, 0x08048fb2 in main () at tinywebd.c:72
72 handle_connection(new_sockfd, &client_addr, logfd);
(gdb) i r esp ebx ebp
esp 0xbffff7e0 0xbffff7e0
ebx 0xb7fd5ff4 -1208131596
ebp 0xbffff848 0xbffff848
(gdb) cont
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0xbffff753 in ?? ()
(gdb) i r esp ebx ebp
esp 0xbffff7e0 0xbffff7e0
ebx 0x6 6
ebp 0xbffff624 0xbffff624
(gdb)
This output shows that EBX and EBP are changed at the point the shellcode
begins execution. However, an inspection of the instructions in main()’s
disassembly shows that EBX isn’t actually used. The compiler probably saved
this register to the stack due to some rule about calling convention, even
though it isn’t really used. EBP, however, is used heavily, since it’s the point
of reference for all local stack variables. Because the original saved value of
EBP was overwritten by our exploit, the original value must be recreated.
When EBP is restored to its original value, the shellcode should be able
to do its dirty work and then return back into main() as usual. Since computers
are deterministic, the assembly instructions will clearly explain how
to do all this.
(gdb) set dis intel
(gdb) x/5i main
0x8048d93 : push ebp
0x8048d94 : mov ebp,esp
0x8048d96 : sub esp,0x68
0x8048d99 : and esp,0xfffffff0
0x8048d9c : mov eax,0x0
(gdb) x/5i main+533
0x8048fa8 : mov DWORD PTR [esp+4],eax
0x8048fac : mov eax,DWORD PTR [ebp-12]
0x8048faf : mov DWORD PTR [esp],eax
0x8048fb2 : call 0x8048fb9
0x8048fb7 : jmp 0x8048f65
(gdb)
344 0x600