Search code examples
assemblygdbreverse-engineeringexploit

I don't know why codes flow this way in gdb


I'm debugging the binary(vortex8). This program runs two threads using pthread_create() function. Assembly codes are below.

(gdb) 0xbffffa01 in ?? ()
(gdb) x/i 0xbffff9fd
0xbffff9fd: nop
0xbffff9fe: jmp    0xbffffa0d
0xbffffa00: pop    ebx
0xbffffa01: add    ebx,0xb
0xbffffa04: mov    eax,0x804a010      // address of fflush@got 
0xbffffa09: mov    DWORD PTR [eax],ebx // fflush@got change
0xbffffa0b: jmp    0xbffffa12
0xbffffa0d: call   0xbffffa00
...
0xbffffa1b: xor    eax,eax
0xbffffa1d: push   eax
0xbffffa1e: push   0x68732f2f
0xbffffa23: push   0x6e69622f
0xbffffa28: mov    ebx,esp
0xbffffa2a: push   eax
0xbffffa2b: push   ebx
0xbffffa2c: mov    ecx,esp
0xbffffa2e: mov    al,0xb
0xbffffa30: xor    edx,edx
0xbffffa32: int    0x80
(gdb) b * safecode + 40
(gdb) ni
[Switching to Thread 0xb7df8b40 (LWP 17523)]
Breakpoint 5, 0x08048685 in safecode ()
=> 0x8048685 <safecode+40>: call   0x80484d0 <fflush@plt>
0x804868a <safecode+45>:    mov    DWORD PTR [esp],0x1
0x8048691 <safecode+52>:    call   0x80484e0 <sleep@plt>
0x8048696 <safecode+57>:    jmp    0x804866a <safecode+13>
0x8048698 <unsafecode> :    push   ebp
(gdb) si
0x80484d0 <fflush@plt>: jmp    DWORD PTR ds:0x804a010
(gdb) ni
0xbffffa1b : xor eax, eax
0xbffffa1d: push   eax
0xbffffa1e: push   0x68732f2f
0xbffffa23: push   0x6e69622f
0xbffffa28: loopne 0xbffff9ae

I don't know why thread change in first 'ni'. In first 'ni', fflush@got is not changed because thread changing is occured before execute '0xbffffa09'. However, After thread changing, fflush@got is changed, so the value of fflush@got is 0xbffffa1b what I want to change. Also, codes after 0xbffffa1b is changed. Why?


Solution

  • You're missing some information such as the registry values. The exception occurs at 0xbffffa01 which is not included in your output either. Presumably it could be the result of this jump: 0xbffff9fd: nop 0xbffff9fe: jmp 0xbffffa0d I would recommend placing a breakpoint at 0xbffff9fd either by changing the nop (0x90) to an int 3 (0xCC) or by setting it in gdb and then stepping through your code instruction by instruction to see what happens just before the crash.