Vulnerability Development mailing list archives

Re: Getting Base Address using the Structured Exception Handler


From: Gerardo Richarte <gera () corest com>
Date: Thu, 26 Jun 2003 11:24:17 -0300

Nobody Mind wrote:

I basically am wondering if anyone has links or can
post a short explanation of why (not how) using the
SEH method works for getting the base
address of kernel32.dll and others?

[as you don't ask how, I'm assuming you know how SEH
works... anybody else can ask again]

    Ok, you are asking why using SEH may help in finding
the base address of kernel32, not the shellcode itself, right?
short answer... I'm not sure why (nor how) :-)

    I think SEH is used to search for things in memory sometimes,
but usually it's used to search for the shellcode, and not kernel32.

    However, now that you ask about it, I can think of two ways to
use SEH to find kernel32 in memory, however, I'm writing realtime,
so I'm not sure if it'll work or not (let me know if you try it :-). Oh,
and erm... let me get into how, as I said, I don't know the why, and
I won't know it unless this hows work :-)

    1st trick:
        Know an address for each version of kernel32. This address must:
            1st not crash, and/or return with a known value for the correct kernel32 versions(*)
            2nd crash, and/or return with a different value for all the other kernel32 versions

        with this, and using SEH, you could call the known address for each version and
    know if it really was the right version, else, try with the next candidate.

    (*) versions: only as far as differin versions is needed, if you only need to know the
    base address of kernel32, it may be enough with just a few entries in your address list,
    if you need to differentiate between more versions, well, you'd need more entries.

    2nd trick:
        I think I like it, if it works...
        to know the address of ntdll.dll may be easy using SEH:
            ntdll.dll calls the exception handler, and as call "is synonim" for push eip/jmp,
        ntdll.dll is pushing its own address in the stack before execution the exception
        handler. Now, if the exception handler you install, gets the return address from
        the stack (pop eax), and uses compares to a list of known ntdll.dll addresses,
        it will be easy to find out the version of ntdll.dll. Then, if you can, somehow,
        infer the version of kernel32.dll from the version of ntdll.dll, well... Bingo!

            the code would be something like

        install SEH pointing to "here"
        generate exception
"here":
        pop    eax
        setup edi,ecx,etc
        rep    scasdw
        mov    ds:[edi+4], eax

        now, if you did everything correct and everthing I said makes sence, you have
        the address of kernel32.dll in eax

    Now, for the why: if any of the methods here described [specially the second that
    I like most] works, it's easy to know the why: because it's a nice why to learn

        gera

PS: Now, if you were talking about fs:30 (or any other number) but not fs:0 [SEH],
the story is absolutely different


Current thread: