Breakpoint in GDB hit 144 times before first call to function

Question

I am working on a reverse engineering challenge and have a binary file. I know how to get the flag by changing the instruction flow after doing a strcmp so I jump to the function that prints the flag. However, when I set a breakpoint on strcmp, it is hit 144 times before the first call to strcmp in the program.

For example, the program asks for user input twice and after each scanf(), strcmp is called. The program wants you to enter two passwords to get the flag. Before the initial strcmp, I have to pass 144 breaks at strcmp and I cannot figure out why when the results of objdump only call strcmp the two times that I mentioned above. I can share the objdump if necessary, but does anybody have any idea why this could be? Am I missing something about debugging in GDB? Are there ways to hide the code doing this in the binary that I am not seeing?

I know that it's 144 times before the "initial call" since I continue 144 breaks and then the program finally asks me for the first input (password).

Answer 1

It is to be taken in consideration that many internal functions use strcmp too. For example in this binary for the first hit on strcmp on my machine looks like this

─────────────────────────────────────────────────────────────────────────────────────────[ BACKTRACE ]─────────────────────────────────────────────────────────────────────────────────────────
 ► f 0     7ffff7df2990 strcmp
   f 1     7ffff7ddb5a6 dl_main+1670
   f 2     7ffff7df079e _dl_sysdep_start+1006
   f 3     7ffff7ddaae8 _dl_start+648
   f 4     7ffff7ddaae8 _dl_start+648
   f 5     7ffff7dd9c28 _dl_start_user
   f 6                1
   f 7     7fffffffe340
   f 8                0
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Breakpoint strcmp
pwndbg> dumpargs
 rdi = 0x400238 ◂— '/lib64/ld-linux-x86-64.so.2'
 rsi = 0x7ffff7dd9794 ◂— insb   byte ptr [rdi], dx /* 'ld-linux-x86-64.so.2' */
...

Judging by the backtrace dl_main calls strcmp to match loader path. Similarly other calls are from loader when libraries are resolved.

─────────────────────────────────────────────────────────────────────────────────────────[ BACKTRACE ]─────────────────────────────────────────────────────────────────────────────────────────
 ► f 0     7ffff7df2990 strcmp
   f 1     7ffff7de9845 _dl_name_match_p+21
   f 2     7ffff7de15c9 _dl_map_object+137
   f 3     7ffff7de5fc0 openaux+48
   f 4     7ffff7de8644 _dl_catch_error+116
   f 5     7ffff7de622f _dl_map_object_deps+607
   f 6     7ffff7ddc6c2 dl_main+6050
   f 7     7ffff7df079e _dl_sysdep_start+1006
   f 8     7ffff7ddaae8 _dl_start+648
   f 9     7ffff7ddaae8 _dl_start+648
   f 10     7ffff7dd9c28 _dl_start_user
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Breakpoint strcmp
pwndbg> dumpargs
 rdi = 0x4003d9 ◂— insb   byte ptr [rdi], dx /* 'libc.so.6' */
 rsi = 0x7ffff7ffe700 ◂— 0x0

This number of calls to could be variable based on the config on your system - such as loaders and libraries.

Another thing to note is that in my case the binary's GOT resolves with

[0x601038] strcmp@GLIBC_2.2.5 -> 0x7ffff7ac9520 (__strcmp_sse2_unaligned) ◂— mov    eax, edi

This is a different function than the one we hit in breakpoints above.

If you want to just stop on the ones which get called from the binary, set up a breakpoint on the call sites.

0x40090d    call   strcmp@plt <0x400630>
0x400961    call   strcmp@plt <0x400630>