3

Whilst messing around with some x86 asm, I got to wondering about cases where a bug has caused EIP to be set to 00000000, or another memory location that does not exist. Is it possible to catch these cases with SEH or similar error handling mechanisms and recover execution? (assuming the stack, heap and registers weren't trashed)

Polynomial
  • 27,674
  • 12
  • 80
  • 107
  • Do you know how do you want to "recover execution" in such situation? I can't imagine any reliable action that could recover from every stack corruption scenarios that could happen. – Zuljin Jan 20 '12 at 15:05
  • 1
    You cannot assume that stack weren't corrupted when EIP is 0, because corruption of stack return address is most common issue that cause wrong EIP value. – Zuljin Jan 20 '12 at 15:14
  • Actually, the case I was considering was a conditional jump to a pointer, e.g. `je [eax]`. – Polynomial Jan 20 '12 at 15:18
  • This is rare compared to the case where some zeros fill the stack and then a return is executed – Gunther Piez Jan 21 '12 at 14:06

2 Answers2

2

There's no really good way to catch this before it happens, but one thing you can try is to inspect the stack (memory at ESP and/or EBP) and check for pointers to code.

If the instruction that caused this was a call, you're in luck - the dword at ESP will be the return address, pointing right after the offender.

If it was a jmp, the chances are slimmer, but you can still look for possible traces of execution.

The worst case is when this is caused by a ret with trashed ESP - usually at this point the stack is completely bogus. You can still check values of other registers, maybe one of them will contain a pointer which might give you some clues, and you scan the whole stack area for the stack frame patters, as described in this post.

Igor Skochinsky
  • 24,629
  • 2
  • 72
  • 109
  • if you return to the last caller address in the stack this way, you are most likely gonna corrupt everything anyways (because the register may be borked, or you have address before the actual return address, due to stack allocation) or make yourself a potential code inject nightmare... – Necrolis Jan 20 '12 at 15:37
0

Your most likely, and probably safest, "solution" is a snapshot of a process state that is safe to return to, using setjmp/longjmp (or a CONTEXT) that is stored somewhere unique to the process, but untouchable, such as FS/GS/ES segments, simliar to how the PEB is stored. This allows all registers to be restored correctly, without leaving too many possible holes.

Of course this would buggy for something like a game (depends where exactly the explosion occurs), but for something like a word processor, or an app where minor state loss is not a major issue, it should work ok (this reminds me of the old Dev-C++ IDE, which used to crash every other file, but somehow still continued running, even though it assured me of a 'fatal' exception it couldn't recover from...).

Necrolis
  • 25,836
  • 3
  • 63
  • 101