Question

The software that I write (and sell) is compressed and encrypted before I distribute it. Everytime I release a new build, I keep all the .map files and the generated binaries including the exe before it is compressed and encrypted.

When it crashes on a client s machine I get a minidump back. I open these minidumps in Visual Studio and explore them there.

I have made good use of these minidumps by searching for addresses in the .map files. This will typically get me in the correct area of the code and I can generally reason about why the crash occured and fix it but this is VERY time consuming.

It would be helpful if I could use the symbols that I saved from the original build in the debugging of the minidump.

My problem is that I get warnings about being unable to find the right symbols. My research leads me to believe that this is because the checksum of the exe on the client s machine does not match the checksum of the exe that Visual Studio built. And I understand why, it has been compressed and encypted. Of course the checksums don t match.

I figure I can manually edit the minidump or change the checksum of the saved binaries to match the checksum of the distributable. I would prefer to manipulate the stored copies so I don t have to modify every dump that comes in, but I d be estatic with either.

So, my question is: How can I locate these checksums and figure out what I should replace them with? As an auxiliary question: Is there a better way?

Answer 1

Without knowing how exactly you are compressing and encrypting your binaries, it s hard for me to be very specific.

This blog post by John Robbins points out that executable images are associated with their PDBs via a GUID that s embedded in the executable s PE header. You should be able to view it by running DUMPBIN /HEADERS on the executable, and looking for the output of Debug Directories. If your compression and encryption has modified the PE headers such that this information isn t available (or correct), then it would explain why your debugger can t find anything.

There are a few approaches that I think that you could take to resolve this issue. To really try to get this to work, you might want to consider using WinDbg instead of the Visual Studio debugger. You ll understand why I am recommending this in a moment...

WinDbg provides some options that allow the relaxed loading of symbol files. The idea with this option is that, if the source code hasn t changed but the binaries are from a different build than the PDB, the GUID check can be waived and the mismatched symbol file can be loaded. I don t know how well this will work with your compression and encryption, so YMMV.

WinDbg and its accompanying tools can be used to dump the GUID from both the executable and the PDB, but I m omitting that for now because I am hoping that those steps won t be necessary.

After you have opened your minidump in WinDbg, you will need to enter several commands into the command line to get this all to work:

.symopt +0x40
!sym noisy
ld <exe name>

The first command enables the SYMOPT_LOAD_ANYTHING option that skips the GUID check. The !sym command enables verbose output for symbol loading so that you may see more detailed error messages. The ld command directs WinDbg to try to load the symbols for the executable name that you will type in the place of <exe name>. If you repeat the ld command, WinDbg will indicate if it successfully loaded the symbols the first time.

Hopefully this helps -- again, I don t know how well this will work with your compression and encryption, but it s worth trying.

Answer 2

Is this compression / encryption something like UPX? If the actual executable content of the binaries is changing (as is done with tools like UPX), you re going to be out of luck (unless you enjoy debugging complex applications in assembly language). Is your software really so important / special that its binaries need to be encrypted before being delivered? In my experience, the ability to debug crash dumps is far more important than stopping people from reverse engineering your code.

友情链接