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 <glynn.clements@virgin.net>
