Walking the Stack Without Symbols and With FPO (Frame Pointer Omission)

In the previous post on stack corruptions, we have discussed the case where the stack becomes corrupted but still contains a chain of EBP references which allows for manual reconstruction. (For background reading, see this article on EBP stack reconstruction and calling convention nightmares on x86.)

Below is a call stack from an application crash dump. The reported crash was an access violation inside a module called “HelperLibrary” for which we don’t have symbols or source code. The call stack doesn’t look promising:

0:000> kv
ChildEBP RetAddr  Args to Child            
WARNING: Stack unwind information not available. Following frames may be wrong.
0028fcec 74ba339a 7efde000 0028fd38 77479ed2
  HelperLibrary+0x1014
0028fcf8 77479ed2 7efde000 776a5346 00000000
  kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
0028fd38 77479ea5 011212b2 7efde000 00000000
  ntdll!__RtlUserThreadStart+0x70 (FPO: [SEH])
0028fd50 00000000 011212b2 7efde000 00000000
  ntdll!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

There are no real frames here other than HelperLibrary+0x1014, but we’re pretty sure that there should be other code on the stack, such as the application’s main function :-)

To reconstruct something from this stack, you need to understand who called HelperLibrary+0x1014, even though you don’t have accurate symbols. Usually, it would be a matter of traversing EBP references, but if it were that easy, the debugger would already have done it!

Read more: All Your Base Are Belong To Us
QR:

Posted via email from Jasper-Net