Re: Magic iso heap over flow <Help>

[v9 () fakehalo us]

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