<<< Date Index >>>     <<< Thread Index >>>

Re: Magic iso heap over flow <Help>



I actually looked into this when you posted this on milw0rm.  I was able to get 
it to run arbitrary code, however it was so unreliable it wasn't worth me 
posting... however, it was informative.

you have control of several registers, however it's eax and edx(not ecx) that 
are most interesting... the next instructions that get called(and fault 
magiciso) are:

MOV DWORD PTR DS:[EDX],EAX
MOV DWORD PTR DS:[EAX+4],EDX

...now, with that you can overwrite any 4byte area in memory with anything you 
want.  the problem is you can't use null bytes(which is where the shellcode and 
the current SEH handler is(non-PEB)) in this situation. (and the 2nd MOV can 
trigger an exception, which you will want to overwrite the handler of)

you can possibly use other methods, like you mentioned(although i didnt try for 
this situation), but i chose to write SEH handler for that block (if you 
trigger it with a bunch of x's it will show up right under it in ollydbg)

step 1 for making the 0x00?????? (EDX) nullbyte:
you can just so happen to happen to overwrite this buffer with full control 
until the end of the buffer.  so, when most (C) functions write to a buffer 
they will cap it with an 0x00 on the end, i just used that.  so the overflow 
has to be an EXACT size for that to work.

step 2 for making the 0x00?????? (EAX) nullbyte:
once i had control of where i was writing EAX to (EDX), i had to figure out a 
way to make another nullbyte as that is where the shellcode was located.  to do 
this i came up with overwriting the SEH handler off-by-one, overwriting a 
single throw-away byte into another memory address(that would never be used), 
and leaving the original null-byte that was already there.

the downside to this is there is there was nothing left to keep track of where 
the shellcode was, ie a simple CALL reg wasn't possible as by the time i gained 
control of EIP there was no trace of where i was...so it became a blind guess, 
and memory gets pretty scattered...never the less, it is exploitable, and i 
popped up several calc.exe's when testing :)

even if not reliable, i found it an interesting workaround for null-bytes.  
carry on if you like, here's the code i was using to test(which is functional, 
just not reliable):

http://fakehalo.us/xmagiciso_24bit.c