Question

I get crash reports from end users with Dr. Watson info and I want to use them to find out where the crash occured (i.e. on which line of the code).

I can’t just use the EIP from the crash report because the exe we ship is digitally signed, and that changes all the offsets. However the crash info also has “bytes at CS:EIP”, which is the first 16 bytes starting from EIP where the crash occured. It looks like this:

Bytes at CS:EIP:
85 c4 14 c3 8b ff 55 8b ec 6a 0a 6a 00 ff 75 08

Those 16 bytes occur exactly once in the exe. I can find their offset in the EXE using just a HEX viewer, but in order to jump there during debugging and see which line that is in the source, I need to know their offset in memory after the EXE is loaded.

What’s the best way to scan the code segment of the program after it’s loaded? Can I add code that finds where the base offset of the EXE is, and then cycle through that and use memcmp to find where the byte pattern occurs.

Also, how can I find where the base offset of the EXE is?

Answer 1

I’m using a very simple approach for the same problem.

First, I dumpbin my executable to find the physical (in file) offset of the code segment.

Then I subtract it from the memory address where these “magic” bytes are located in the binary.

Then I run the program under a debugger, and just add this offset to the virtual address of the code segment.

       .text name
  10EE8E virtual size
    1000 virtual address (00401000 to 0050FE8D)
  10F000 size of raw data

 --> 400 file pointer to raw data (00000400 to 0010F3FF) <--

       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
60000020 flags
         Code
         Execute Read