9

Is it possible to debug core file generated by a executable compiled without gdb flag ?

If yes, any pointers or tutorials on it ?

Hemanth
  • 5,035
  • 9
  • 41
  • 59
  • What are you referring as gdb flag??Do you mean -g flag(debug flag) – Pradeep Aug 02 '11 at 11:37
  • 1
    As your one good answer suggests, assembly level debugging is all you'll get that way. It can be done, but it's not easy, and there won't be a 'tutorial'. You're going to have to learn the assembly language of the processor the program is running on. – Omnifarious Aug 05 '11 at 18:53
  • It might be helpful to know the operating system, CPU architecture and object file format to make this a smarter question. Could you provide this information? – Jens Aug 09 '11 at 09:38
  • If you don't pick an answer, one will be picked for you. :-) – Omnifarious Aug 12 '11 at 17:22

3 Answers3

15

Yes you can. It will not be easy though. I will give you an example.

Lets say that I have the following program called foo.c:

main()
{
    *((char *) 0) = '\0';
}

I'll compile it and make sure that there is no symbols:

$ cc foo.c
$ strip a.out
$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

Ok, time to run it:

$ ./a.out
Segmentation fault (core dumped)

Oops. There seems to be a bug. Let's start a debugger:

$ gdb ./a.out core
[..]
Reading symbols from /tmp/a.out...(no debugging symbols found)...done.
[..]
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0  0x0804839c in ?? ()
(gdb) bt
#0  0x0804839c in ?? ()
#1  0xb7724e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#2  0x08048301 in ?? ()

Hmm, looks bad. No symbols. Can we figure out what happened?

(gdb) x/i $eip
=> 0x804839c:   movb   $0x0,(%eax)

Looks like it tried to store a byte with a value of zero to the memory location pointed by the EAX register. Why did it fail?

(gdb) p $eax
$1 = 0
(gdb)

It failed because the EAX register is pointing to a memory address zero and it tried to store a byte at that address. Oops!

Unfortunately I do not have pointers to any good tutorials. Searching for "gdb reverse engineering" gives some links which have potentially helpful bits and pieces.

Update:

I noticed the comment that this is about debugging a core dump at a customer. When you ship stripped binaries to a customer, you should always keep a debug version of that binary.

I would recommend not stripping and even giving the source code though. All code that I write goes to a customer with the source code. I have been on the customer side too many times facing an incompetent vendor which has shipped a broken piece of software but does not know how to fix it. It sucks.

This seems to be actually a duplicate of this question:

Debug core file with no symbols

There is some additional info there.

Community
  • 1
  • 1
snap
  • 2,751
  • 22
  • 33
2

Yes, you can, this is what people who i.e. write cracks are doing, unfortunately i don't have the slides and documents of a course i followed at university anymore, but googling for reverse engineering or disassembly tutorials will give you some starting points. Also knowing your way around in assembly code is essential.

Our class was based on a book mainly chapter 1 & 3 but there is a new edition out now

Computer Systems: A programmer's perspective by R.E. Bryant and D.R. O'Hallaron

which explains the basics behind computer systems and also gives you good knowledge of the working of programs in systems.

Also when learning this be aware that 64bit cpus have different assembly code than 32bit cpu's, just in case.

Xtroce
  • 1,749
  • 3
  • 19
  • 43
-2

If the program is compiled without -g flag,you cannot debug core file.

Otherwise you can do so as: gdb executable corefile

More you can find at: http://wwwpub.zih.tu-dresden.de/~mlieber/practical_debugging/04_gdb.pdf

Pradeep
  • 3,420
  • 11
  • 35
  • 38
  • 1
    So in most of customer scenarios their executable would have been compiled without gdbflag -g right ? so how can we debugg the core dumps generated in case of customer scenarios ? – Hemanth Aug 05 '11 at 07:06
  • By customer scenarios ,I think you are talking about released build or exe.So in that case debug is not possible for core dump as per my experience.You may wait for some better answer,so that I can also get benefited :) – Pradeep Aug 05 '11 at 09:21
  • In my experience, release builds are still built with -g (even with optimizations, such as -O3). This ensures *some* debuggability. The executables are copied to an archive. Then, the symbols are stripped from the executables (including libraries), which then also gets archived. Finally, the symbol-less version is released to the wild. You can then tell gdb to set the executable to the debuggable executable while using the core file from the executable with stripped symbols. Then GDB's happy and everything "works" (well, as much as debugging an optimized executable "works"). – inetknght Jun 23 '14 at 16:07