Re: core dump

[tymm () COE MISSOURI EDU (Tymm Twillman)]

A coredump is a snapshot of a program that dies a tragic death.  It can be
caused by a program accessing memory that it shouldn't, accessing memory
in ways it's not supposed to, certain signals that one can send to the
process, or miscellaneous severe errors (generally OS related).

The purpose is to allow one to use a post-mortem debugger so that after
the process dies one can use gdb (gnu debugger), dbx (the name of the
debugger on many commercial OS's, etc), or other programs to investigate
exactly why the process dies.

You can use file(1) to determine what program dumped a specific core file
if it's unknown, and then run gdb/dbx/whatever with the name of the
program and the core file to try to figure out what went wrong.  The
debugger needs the original program to determine how the program was set
up, where it was at, the variables that were in use, etc. (a core file
without the original program is generally pretty worthless)

Also note that if the stack gets completely messed up before the program
crashes, it can scramble the data the debugger needs to reconstruct what
was going on at the time.

Also note that if a file is stripped (see strip(1)) debugging information
is removed and it can become hard to reconstruct what is going on in
the program.  Debugging information contains such info as variable and
function names, making the output much more readable.

Example of gdb in use:

(with stack intact -- heap overflows (allocating a malloc()d segment)
will usually do this, as an example)

[tymm@uvula tymm]$ cat testnn.c
#include <stdlib.h>
#include <stdio.h>

int main()

/*
 * allocates a buffer of 1000 characters and copies stdin to it,
 *  printing the result
 *
 *  Example of how NOT to program --
 *   copying user data without bounds to buffer of fixed size
 *   (gets is ***HORRIBLE***),
 *   also should be checking return value of malloc to make
 *   sure it's not NULL.  Should probably also check return
 *   value from any input routines.
 */

  char *string;

  string = malloc(1000);
  gets(string);

  printf("I read %s\n", string);

[tymm@uvula tymm]$ cc -g -o testnn testnn.c
/tmp/ccfXuOwN.o: In function `main':
/home/tymm/testnn.c:21: the `gets' function is dangerous and should not be
used.

*** note the complaint from gcc; it's not kidding :) ***

[tymm@uvula tymm]$ ./testnn < /usr/bin/perl -e 'print "A"x4096'
Segmentation fault (core dumped)

*** here we overwrote the malloc()d segment)

[tymm@uvula tymm]$ file core
core: ELF 32-bit LSB core file of 'testnn' (signal 11), Intel 80386,
version 1

*** and checked what process was responsible for the core file ***

[tymm@uvula tymm]$ gdb testnn core
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./testnn -e print "A"x4096'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x400778a7 in memcpy (dstpp=0x80495c9, srcpp=0x40014001, len=2731)
    at ../sysdeps/generic/memcpy.c:55
../sysdeps/generic/memcpy.c:55: No such file or directory.
(gdb) where
#0  0x400778a7 in memcpy (dstpp=0x80495c9, srcpp=0x40014001, len=2731)
    at ../sysdeps/generic/memcpy.c:55
#1  0x4006a6d9 in _IO_getline_info (fp=0x401010e0,
    buf=0x80495c9 "ELF\001\001\001", n=2147483647, delim=10,
extract_delim=0,
    eof=0x0) at iogetline.c:102
#2  0x4006a5e6 in _IO_getline (fp=0x401010e0, buf=0x80495c9
"ELF\001\001\001",
    n=2147483647, delim=10, extract_delim=0) at iogetline.c:39
#3  0x4006a7f7 in _IO_gets (buf=0x80495c8 "\177ELF\001\001\001") at
iogets.c:56
#4  0x8048449 in main () at testnn.c:21
#5  0x40030cb3 in __libc_start_main (main=0x8048428 <main>, argc=3,
    argv=0xbffffd14, init=0x80482e0 <_init>, fini=0x804848c <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffd0c)
    at ../sysdeps/generic/libc-start.c:78
(gdb)

*** note the lower #'d entries in the trace are the inner functions;
the program starts in __libc_start_main, which calls main(), which here
has called _IO_gets (gets is a macro that the compiler turns into IO_gets)

you can see that it died in a call to memcpy() here.

(example w/screwed up stack)

[tymm@uvula tymm]$ statserial `perl -e 'print "A"x4096'`
Segmentation fault (core dumped)
[tymm@uvula tymm]$ gdb statserial core
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Core was generated by
`AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
#0  0x806db13 in ?? ()
(gdb) where
#0  0x806db13 in ?? ()
#1  0x8063a7d in ?? ()
#2  0x805e71e in ?? ()
#3  0x8048416 in ?? ()
#4  0x41414141 in ?? ()
(gdb)

Here I caused statserial to overwrite a large portion of the stack with
'A's, which destroyed information that would have been needed to see where
exactly the program was when it died.  Note the 0x41414141 address on the
last line (0x41 is 'A'); this is one of the telltale signs of a classic
buffer overflow (we could have used any group of characters instead of a
bunch of A's but it's really easy to spot like this :) ) -- if you can
pass a program a whole bunch of characters and have that character
sequence appear in the stack trace.

There's pretty good docs on gdb out there, GNU press has a book on it, and
you can learn a lot just by playing with it.

also note that gdb/dbx/etc can be used to debug a program while it's
running, which is often more helpful (but just as often tedious,
as you often have to walk the program through line by line to see what's
going on).

Hope this helps somewhat :),

-Tymm

On Thu, 13 Jul 2000, mount ararat blossom wrote:

> hi folks,
> i do not know this has been asked before but if so, sorry.
> my question is that i am new into the topic of vulnerability development
> world and i really wonder why unix like OS dumps core files and what is the
> importance
> of it.
> thanks
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com