GDB breakpoint does not stop at specified address

Question

I have set a breakpoint at a specific address with this command: break *0x080488CA but it is not stopping. I have a breakpoint set previously to this one and it works fine, but when running in gdb with run group3, and continuing after the 1st breakpoint, it skips over this second one. Any idea as to why this would happen? Below is the picture, with the line highlighted which I am attempting to break at:

The entire source file can be downloaded here: https://drive.google.com/open?id=1iLS8vhbPIHCmOqTjidFFUIkYq4_7WuEZ

Here is the code where ptrace is called:

.text:0804889D
.text:0804889D loc_804889D:                            ; CODE XREF: check+158↑j
.text:0804889D                 call    _getppid
.text:080488A2                 mov     [ebp+var_C], eax
.text:080488A5                 mov     dword ptr [esp+0Ch], 0
.text:080488AD                 mov     dword ptr [esp+8], 0
.text:080488B5                 mov     eax, [ebp+var_C]
.text:080488B8                 mov     [esp+4], eax
.text:080488BC                 mov     dword ptr [esp], 10h ; request
.text:080488C3                 call    _ptrace
.text:080488C8                 test    eax, eax
.text:080488CA                 jns     short loc_80488E4
.text:080488CC                 mov     dword ptr [esp], offset aYouFoolNobodyD ; "[-] You fool, nobody debug me!!!"
.text:080488D3                 call    _puts
.text:080488D8                 mov     dword ptr [esp], 0FFFFFFFFh ; status
.text:080488DF                 call    _exit
.text:080488E4
.text:080488E4 loc_80488E4:                            ; CODE XREF: check+195↑j
.text:080488E4                 mov     dword ptr [esp], 1 ; seconds
.text:080488EB                 call    _sleep
.text:080488F0                 mov     dword ptr [esp+0Ch], 0
.text:080488F8                 mov     dword ptr [esp+8], 0
.text:08048900                 mov     eax, [ebp+var_C]
.text:08048903                 mov     [esp+4], eax
.text:08048907                 mov     dword ptr [esp], 11h ; request
.text:0804890E                 call    _ptrace
.text:08048913                 mov     dword ptr [esp], 0 ; status
.text:0804891A                 call    _exit
.text:0804891A check           endp ; sp-analysis failed
.text:0804891A
.text:0804891F
.text:0804891F ; =============== S U B R O U T I N E =======================================

Successful breakpoint at 08048859:

.text:0804882A loc_804882A:                            ; CODE XREF: check+DD↑j
.text:0804882A                 mov     eax, [ebp+var_14]
.text:0804882D                 cmp     eax, 32h
.text:08048830                 jbe     short loc_8048814
.text:08048832                 mov     dword ptr [esp+4], offset modes ; "r"
.text:0804883A                 lea     eax, [ebp+command]
.text:0804883D                 mov     [esp], eax      ; command
.text:08048840                 call    _popen
.text:08048845                 mov     [ebp+stream], eax
.text:08048848                 cmp     [ebp+stream], 0
.text:0804884C                 jz      short loc_8048876
.text:0804884E                 mov     eax, [ebp+stream]
.text:08048851                 mov     [esp], eax      ; stream
.text:08048854                 call    _fgetc
.text:08048859                 cmp     eax, 0FFFFFFFFh
.text:0804885C                 jz      short loc_8048876
.text:0804885E                 mov     dword ptr [esp], offset aNoVmPlease ; "[-] No vm please ;)"
.text:08048865                 call    _puts
.text:0804886A                 mov     dword ptr [esp], 0FFFFFFFFh ; status
.text:08048871                 call    _exit

You realize `gdb` is using `ptrace`, right? So whatever `ptrace` call the program makes is intended to disable `gdb`. Skip the `call` then it should work. — Jester, Nov 25 '17 at 00:34
Oh kk thanks @Jester! Would I do that by replacing`call _ptrace` with a NOP, such as in this article? https://reverseengineering.stackexchange.com/questions/10862/is-it-possible-to-make-an-application-skip-a-call — Tom, Nov 25 '17 at 00:46
@Jester I set a breakpoint at the address where ptrace is called, but it still skips it. So i'm not sure how I could skip `call _ptrace` — Tom, Nov 25 '17 at 01:18
You didn't show the code for that. What's between that and the posted code? Anyway, move it down and see which is the first location where it does not work. — Jester, Nov 25 '17 at 01:54
I added more code, the ptrace call i want to skip is at 080488C3. I tried moving the breakpoint to lower registers (higher in the code) but i had to go pretty far and it STILL would skip the breakpoint — Tom, Nov 25 '17 at 01:58
Lower *address* I think you mean. I'm not sure you've grokked what Jester is suggesting. Use a GDB `jump` command (or `set $pc = 080488C8`) when stopped right *before* the `call _ptrace` to skip over it. (Not `next` or `nexti` to run it without tracing, but actually not run it at all.) See https://stackoverflow.com/questions/4116632/is-it-possible-to-jump-skip-in-gdb-debugger/46043760#46043760. Or NOP it out, that would work, too. — Peter Cordes, Nov 25 '17 at 02:12
You said the working breakpoint is at `0x08048859`. But you still did not show that part! — Jester, Nov 25 '17 at 02:37
@PeterCordes Yeah, lower *address. I did try to put a break point right before `call _ptrace` but gdb seems to ignore it. I also tried to NOP it out, but when i tried to save the new file in IDA i got a "bad character" error and it didn't let me save so i couldn't run the code that NOP'd out the ptrace call. Sorry @Jester, i added that code — Tom, Nov 25 '17 at 20:16
Have you checked that the code doesn't go to `08048871` where it simply exits the program? If it doesn't then it goes to `8048876` which you again forgot to show... — Jester, Nov 25 '17 at 21:34
I am pretty certain the code doesn't go to 08048871, where it exits. I have just added a link to a download link for the entire file, in case you would like to see. Thanks for your help so far @Jester and PeterCordes — Tom, Nov 26 '17 at 18:48
I NOP'd out the call to ptrace (which is `90 90 90 90 90` at line `000008c3` in WinHex or `080488c3` in IDA) and it does seem to skip over that which is good. However, it makes a call to libc (Standard C library I think) and I expect when I run the command `finish` in GDB for it to return to the program, but it never does. It just exits the program with `Inferior 1 (process ...)`, and I don't understand why — Tom, Nov 26 '17 at 18:56
The code you didn't post of course turned out to be somewhat important ... you realize it has a [`fork`](https://linux.die.net/man/2/fork) call in it, right? — Jester, Nov 26 '17 at 19:36
I saw that there are jump statements depending on status flags, is that the same as `fork`? So far i've tried to use breakpoints before compares or jumps and manipulating variables so it takes the path of execution that I want. That worked for getting past the check for a VM, but i'm now stuck on the the check that looks at if i'm running in a debugger (the `jns` at `080488CA`). I want the program to think i'm not running in a debugger, even though i'm running in GDB — Tom, Nov 26 '17 at 19:55
@Jester OHHHH I never saw that! would NOP'ing out those work as well? — Tom, Nov 26 '17 at 22:33
I haven't checked what the code is actually doing. You might just want to attach to the forked process. — Jester, Nov 26 '17 at 22:45

GDB breakpoint does not stop at specified address

0 Answers0