Re: How to make a core dump?
From: Glynn Clements (glynn.clements_at_virgin.net)
Date: Sun, 5 Sep 2004 06:54:18 +0100 To: Alexander Morozov <firstname.lastname@example.org>
Alexander Morozov wrote:
> recently my friend have found a malcious program running on his
> web-server. After some actions i thought it would be helpful to make
> its core dump, but i couldn't figure out how to do this. The only
> thing that came to mind was attaching to it with gdb, stopping
> it and dumping regions of memory manually (using memory map in
> /proc/pid/mem). It went fine, i copied all segments but it would be much
> better to have standart core dump, to be able to use usual programms on
> it later. I remember, that several years ago default behaviour of a
> program running under linux was dumping itself on SIGSEGV.
> And I wonder, how was this fullfilled, was it feature of glibc to catch
> SIGV and write a dump? Or was it made by the kernel?
This is handled by the kernel; e.g. arch/i386/kernel/signal.c:
case SIGQUIT: case SIGILL: case SIGTRAP:
case SIGABRT: case SIGFPE: case SIGSEGV:
case SIGBUS: case SIGSYS: case SIGXCPU: case SIGXFSZ:
if (do_coredump(signr, regs))
exit_code |= 0x80;
However, all of the above signals can be caught (SIGKILL and SIGCONT
can't be caught, but they don't cause a core dump). Also, the process'
resource limits (specifically, RLIMIT_CORE) may prevent a core dump,
or it may not have write permission to its current directory.
It may suffice to simply send the program one of the above signals.
However, if it's specifically trying to avoid this, you could try
attaching gdb to the process then restoring the signal handler and
resource limit before sending it the signal from within gdb.
I dare say that there are other things which it could do if it was
trying to thwart debugging attempts, e.g. having itself ptrace()d,
continually changing its PID/PGID.
-- Glynn Clements <email@example.com>