RE: win32 bof question

From: Brett Moore (brett_at_softwarecreations.co.nz)
Date: 11/24/03

  • Next message: mark: "Re: Can you exploit this XSS?"
    To: "ma1ler_deamon" <ma1ler_deamon@yahoo.com>, <Vuln-Dev@securityfocus.com>
    Date: Tue, 25 Nov 2003 11:11:40 +1300
    
    

    Hi,

    The JMP you are trying to use is executed relative to the start position, as
    can
    be seen in the following. The second operand of the jmp instruction
    instructs
    the cpu the distance to jump.

    0012EA4D EB 01 jmp 0012EA50 // jmp 1 byte to tester
    0012EA4F 90 nop // spacer
    0012EA50 B9 0F 04 17 01 mov ecx,117040Fh // tester:

    0012EA4D EB 07 jmp 0012EA56 // jmp 7 bytes to
    tester
    0012EA4F 90 nop
    0012EA50 90 nop
    0012EA51 90 nop
    0012EA52 90 nop
    0012EA53 90 nop
    0012EA54 90 nop
    0012EA55 90 nop
    0012EA56 B9 0F 04 17 01 mov ecx,117040Fh // tester

    > I have tried several things to get the right opcodes for this jmp, first I
    tried
    > __asm{
    > jmp never_really_called //E9 FE 59 FF FF
    > };

    Would give you the correct opcodes to jmp to the function FROM the position
    where
    this was executed. So will not give you the correct opcodes required.

    > what I am trying to do is to jump to a function called
    "never_really_called"
    > located at memory offset 0000401140
    If you know that this is located at this 'static' location you can reach it
    thru
    ways similiar to;
            push 0x0000401140 (It has nulls tho)
            ret
    or
            mov ecx,0x0000401140 (It has nulls tho)
            jmp/call ecx

    or you could work out the distance between 'never_really_called' and the
    position
    of the jmp instruction to use a JMP <distance>. But that is not really
    effective
    as under a real overflow situation the shellcode is 'usually' in an unknown
    location
    and therefore relative offsets can't be used to jump into code that is not
    part of
    your code, even if you do find yourself.
    0012EA4D 68 5F 57 C3 AC push 0ACC3575Fh
    0012EA52 FF D4 call esp

    Regards
    Brett

    -----Original Message-----
    From: ma1ler_deamon [mailto:ma1ler_deamon@yahoo.com]
    Sent: Tuesday, November 25, 2003 7:26 AM
    To: Vuln-Dev@securityfocus.com
    Subject: win32 bof question

    I am trying to wrap my brain around some shell code
    stuff and ran into
    something that isnt making much sense yet.

    I have a function

    void test3(void){
            char buf[3];

            buf[0]=0x90;
            buf[1]=0x90;
            buf[2]=0xe9;
            buf[3]=0x40;
            buf[4]=0x11;
            buf[5]=0x40;
            buf[6]=0x00;
            buf[7]=0x00;

            //set eip on stack to be loc of buf[0]
            buf[8]= 0x24;
            buf[9]= 0xff;
            buf[10]= 0x12;
            buf[11]= 0x00;

    }

    buf 8-11 is overwriting saved eip with the location of
    buf[0]
    buf 0-7 is my super simple (yet still failing) shell
    code

    what I am trying to do is to jump to a function called
    "never_really_called"
    located at memory offset 0000401140

    I have tried several things to get the right opcodes
    for this jmp, first I tried

    __asm{
            jmp never_really_called //E9 FE 59 FF FF
    };

    inline in the function and then extracted the opcodes
    in the debugger...
    which I thought would give me the right result, but
    didnt..

    then I opened a random exe in hiew and changed the
    first instruction to jmp 401140
    in asm mode and grabbed the opcodes..but that wasnt
    quite right either..

    as is in the example the E9 40 11 40 00 00 shows up
    right in the dsm view
    of the debugger, as a "jmp never_really_called
    (401140)" but then when the jump
    actually happens...I find myself at 53106b

    I have to be missing something simple...any words of
    wisdom?

    I am using vc6 w/ debug config

    __________________________________
    Do you Yahoo!?
    Free Pop-Up Blocker - Get it now
    http://companion.yahoo.com/


  • Next message: mark: "Re: Can you exploit this XSS?"

    Relevant Pages

    • Re: Which assembler can handle the BIG stuff ?
      ... although I agree that a 16M jump table might be a table looking ... The worst OS DLL that I know of it the kernal and it has 864 entries ... four bytes (offset only) while others are six bytes. ... there is no jmp table in the kernal. ...
      (alt.lang.asm)
    • Re: Which assembler can handle the BIG stuff ?
      ... Here is a sample extract from the Windows kernal... ... >>One entry contains an offset and the other contains an offset and a segment. ... It is a list of pointers, not a jmp table. ... >A jump table is a list of addresses or offsets to jump to. ...
      (alt.lang.asm)
    • Re: Which assembler can handle the BIG stuff ?
      ... >> shl eax, 2; Byte offset from start of TABLE ... Jump tables as defined in "ancient code" were very efficient for the ... most code using "jump tables" call the pointers instead of jmp ax or jmp eax. ... ASM programs, and in fact would be a sign of incpometent programming skills if a ...
      (alt.lang.asm)
    • Re: Which assembler can handle the BIG stuff ?
      ... Here is a sample extract from the Windows kernal... ... It is a list of pointers, not a jmp table. ... A jump table is a list of addresses or offsets to jump to. ... > will do all the calculations for you with GETPROCADDRESS(). ...
      (alt.lang.asm)
    • Re: Which assembler can handle the BIG stuff ?
      ... to create an application with a 16k jmp table, much less a 16M jmp table. ... you don't have to look too far for examples of jump tables bigger than 16K. ... There are 6937 entries in mfc42.dll, a Visual C DLL used by applications developed using MFC at run time. ... would expect a hardware simulator to have more entries in the jmp table. ...
      (alt.lang.asm)