Using GDB without debugging symbols on x86?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Set aside the option that you are working on a program without it's source, (that was well covered on the other answers)

You don't have to install special debugging symbols for your own programs. gcc usually adds some debugging information about your own functions, and if it doesn't, There is very little work to write 'gcc -ggdb3' for getting the most debugging information for your own program, or some other debugging information you require.

When during the debugging, you reach a function that is not yours and you don't have it's debugging symbols (this is where the installation is usually needed), you can assume it is not buggy, which if it is from a descent library, such as LIBC, it is a descent assumption (unless you tested your own program first).