GDB is not stopping at the first machine code instruction with break _start or info files Entry point address

1
votes

I want to debug an application I don't have symbol files for. I understood that it is necessary to debug on assembly level if I lack the necessary debug information. Since I don't have debug symbols I can't set breakpoints directly on method names, however I still should be able to set a breakpoint on an address.

So I simply tried to set a breakpoint on the entry address, this is what I did:

user@MacBookAir$ gdb
(gdb) file someexecutable
(gdb) info file

The last command returned the following entry point: enter image description here

After having the address, I simply said:

(gdb) break *0x0000000100119ec8
(gdb) run

Unfortunately the target application launched without breaking at the entry point, so I tried it again but this time I did set breakpoints on a few addresses following the entry point address - without success.

The next attempt was to try the solution by Igor Skochinsky which he posted in this question (Stopping at the first machine code instruction in GDB) to set breakpoints with:

(gdb) b _start
(gdb) b start

But both of these commands resulted in the same error:

No symbol table is loaded. Use the "file" command.

Well yeah, apparently I need debug symbols for this to work as well. Then I thought perhaps it just showed an incorrect entry point address, so I verified it with the command:

user@MacBookAir$ otool -l someexecutable

And received the following output: enter image description here

So it appears to be the same entry point as GDB returned. And now I don't know what else I could try. :) Perhaps you guys have an idea on what else I could try. Any help would be very much appreciated. If something is unclear or if I missed some important information just leave a short comment.

1
debugginggdbreverse-engineering
I do not reproduce in GDB 7.7.1, GCC 4.8 and a hello world: both address and symbol methods work. How exactly was the executable generated? What is the GDB version? – Ciro Santilli 新疆再教育营六四事件法轮功郝海东

1 Answers

2
votes

This looks like a bug in GDB to me. I'm guessing the ASLR relocates the binary to another address but GDB does not move the breakpoint. I'd suggest one of the following:

  1. disable ASLR: set disable-aslr on
  2. set env var DYLD_NO_PIE=1
  3. remove the MH_PIE flag from the executable's header
  4. patch the entrypoint to 0xCC. Once it breaks, you can patch it back to the original byte.