Re: locating default signal handler for SIGSEGV

From: Roland Postle (mail_at_blazde.co.uk)
Date: 12/08/03

  • Next message: npguy: "Re: Internet Explorer JavaScript insecure function" 
    To: "vuln-dev@securityfocus.com" <vuln-dev@securityfocus.com>, "Devrat Mittal" <u02113@cs.unipune.ernet.in>
Date: Mon, 08 Dec 2003 21:11:47 +0000

    On Mon, 8 Dec 2003 17:51:32 +0530 (IST), Devrat Mittal wrote:

    >So the daemon does do a
    >segfault & it has a handler installed for it. So it displays
    >
    >Proftpd terminating (signal 11)...
    >
    >Problem is I cant run the code under gdb as the segfault fails to occur if
    >i debug the binary, further i cant recompile the binary at all as that
    >also changes addresses & the segfault fails to occur. My goal is to
    >somehow call the default signal handler (to get a core dump) & then
    >analyze the program to see where the shellcode was placed.

    Load the binary into IDA Pro or something and find the code that
    installs the signal handler (a call to signal() probably via libc),
    then nop it out. If it's tricky to nop out you could also change the
    handler address argument to the call to SIG_DFL (which is 0 on linux at
    least) so it uses the default handler. If you don't have IDA you could
    also do something like strace -i to find the address of the signal call
    (if it's in libc then set a breakpoint on it in gdb and stack backtrace
    to find where in your binary the call originates from). Then a
    hexeditor's enough to nop it out.

    - Blazde

  • Next message: npguy: "Re: Internet Explorer JavaScript insecure function"

    Relevant Pages