Using GDB without debugging symbols on x86?

19,901

Solution 1

To start out, you can do;

gdb "whatever"
break __libc_start_main
r

that will setup a breakpoint in libc's crt0 code and allow you to break before main, even if the target binary is totally stripped.

That will get you to a running state at a breakpoint before most user code. You can then single step, dissasemble, dump memory etc... to your heart's content.

This works on all platforms, the fact your asking about IA-32 / x86 does not matter.

Solution 2

Without debugging symbols, you can only debug at the ASM level. Ok you get a bit more information, but you're not going to get very far unless you understand a bit of ASM and the code the compiler generates. This will let you do a simple inspection of local variables etc if you know what you're doing.

If you have the source, it's going to be far easier just to recompile it.

Solution 3

All you can do is look at registers and the contents of the stack - you'll have to do everything by inferring what things are used for, as Draemon mentions.

Solution 4

Well, the absolutely most important thing is that you be able to unwind the stack. There are three ways this can be ensured:

  • Build debugging symbols with -g

  • On systems that do C++ exception unwinding via tables (probably anything ELF these days?), the -funwind-tables flag will tell it to generate such tables regardless of language, and GDB can use these tables (at least, with x86 linux it can).

  • Or, failing those, at least make sure that -fomit-frame-pointer isn't enabled

Share:
19,901
Johan Dahlin
Author by

Johan Dahlin

Python, C developer.

Updated on June 03, 2022

Comments

  • Johan Dahlin
    Johan Dahlin about 2 years

    How do I use GDB to debug a program which do not have debugging symbols on a 32-bit x86 processor? Inspecting the function arguments, local variables, resolving pointers would be useful to know how to do. The intention is not really to use this for reverse engineering, as I'm sometimes just too lazy to install the debugging symbols and would be great to know how to get some basic information out of gdb.