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