Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: exploit write, small jump

  1. #11
    Super Moderator lupin's Avatar
    Join Date
    Jan 2010
    Posts
    2,943

    Default

    Quote Originally Posted by compaq View Post
    My sound a bit.. Do i add the address of the start of a pop pop ret into ecx, as. like 77c40000? , I have try things like that push ecx,call , as well has a short jump, all just display the string of the commands at address 77c40000 in ecx.
    You need to load the start address of the POP, POP, RET into the SEH address, which will then get copied to EIP once the SEH address is used as an exception handler. On XP SP2 and up the address you use for SEH must be from within a module with SafeSEH Off, or from another predictable location in memory thats outside of any loaded module and is marked executable. The address should not have any restricted characters in it.

    Here are some good references:

    Exploit: Stack Overflows - Exploiting default seh to increase stability - SecurityForest
    Exploit: Stack Overflows - Exploiting SEH on win32 - SecurityForest
    http://www.corelan.be:8800/index.php...-dep-and-aslr/
    http://www.corelan.be:8800/index.php...al-part-3-seh/
    http://www.corelan.be:8800/index.php...ample-part-3b/
    I-Hacked.com Taking Advantage Of Technology - Understanding SEH (Structured Exception Handler) Exploitation
    Nabble - Vulnerability Development - overwriting SEH and debugging

    You might want to try one of the guided examples in the posts above so you can get a good grip on how this works.

    Quote Originally Posted by compaq View Post
    It goes into the exception handler, but ecx just gets zeroed out
    This happens with programs using SEH to handle exceptions in XP SP1 and up, registers get zeroed during the process of calling the SEH exception handler.

    Quote Originally Posted by Gitsnik View Post
    Anti-debugging code will do that - Immunity Debugger has a !hidedbg command (misspellings may apply).
    When I have run code with anti debugging features included in Olly, it has terminated the process inside the debugger, but has never terminated the debugger itself. Plus its even more unusual for this to happen after a buffer overflow exception has been thrown, because the programs code usually doesn't have control at this point. Also, the killing of the process due to anti-debugging code usually happens pretty early on in the programs execution, normally before you have a chance to get the program running to the point where you could send bad data to it via the network...

    Perhaps if the program has some crafty debugger-killing custom exception handler...
    Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".

    The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.

  2. #12
    Very good friend of the forum Gitsnik's Avatar
    Join Date
    Jan 2010
    Location
    The Crystal Wind
    Posts
    851

    Default

    Quote Originally Posted by lupin View Post
    When I have run code with anti debugging features included in Olly, it has terminated the process inside the debugger, but has never terminated the debugger itself. Plus its even more unusual for this to happen after a buffer overflow exception has been thrown, because the programs code usually doesn't have control at this point. Also, the killing of the process due to anti-debugging code usually happens pretty early on in the programs execution, normally before you have a chance to get the program running to the point where you could send bad data to it via the network...

    Perhaps if the program has some crafty debugger-killing custom exception handler...
    compaq pointed out that he hits run and then it bails out.

    That said I don't think that is what is going on here - sounds more like an issue with the host OS than the debugger itself.
    Still not underestimating the power...

    There is no such thing as bad information - There is truth in the data, so you sift it all, even the crap stuff.

  3. #13
    Super Moderator lupin's Avatar
    Join Date
    Jan 2010
    Posts
    2,943

    Default

    Quote Originally Posted by Gitsnik View Post
    compaq pointed out that he hits run and then it bails out.

    That said I don't think that is what is going on here - sounds more like an issue with the host OS than the debugger itself.
    I interpreted what he said differently - the the crash of the debugger only happened after the bad buffer was sent to it (because he did manage to get the value 41414141 into a register indicating a big string of "A" characters being put into memory). Id agree that the cause could be in the host OS.
    Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".

    The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •