tools for diffing windows binaries?

3
votes

Our QA team wants to focus their testing based on what EXEs and DLLs have actually changed between builds. We have a nice svn change report, but the relationship between source and changed binaries isn't always obvious. The builds we're comparing are always full clean builds, so we can't use file system timestamps. I'm looking for tools to compare windows (and windows CE) PE binaries that will ignore the embedded timestamps and other cruft. Any recommendations for tools or other ways to generate a reliable 'what binaries have really changed' report? Thanks.

clarification: Thanks for the answers so far, but we can't generate the report by doing straightforward byte-for-byte compares or comparing checksums, because all the files appear different every time we build, even if the sources haven't changed, because of timestamps that the compiler inserts. The problem is how to ignore the false positives. The disassemble & compare idea is closest to what we need, I think...

answered! Bindiff is just what I was looking for. Many thanks.

8
windowsdiffcomparebuildbinaries
Interesting technical problem, but what makes the 'EXEs/DLLs changed' list more relevant than 'source files changed' list? - orip
Here's the scenario: svn says ObscureLib.c changed since the last build. Should I rerun my test suite for foo.exe? - Pete Richardson

8 Answers

4
votes

Have you had a look at Bindiff?

2
votes

I ran into this problem before. My solution was to write a tool which set all the timestamps in an .EXE/.DLL to a known value. I would run it as a post-build step. Then binary diffs would work just fine.

1
votes

You could perhaps disassemble the binary, and then do a diff on the assembly...

This sounds like your QA team is taking the wrong approach though... It shouldn't matter to them what the code looks like; just that it does what it's supposed to do.

Edit: Oh! After reading it again, I realized that I misinterpreted your question. I thought they wanted to test the methods that had changed...

In that case, why not get the MD5 hash and compare those? The tiniest change will cause a totally different hash to be generated.

1
votes

Not sure what kind of binaries (DLLs? PE/WinCE executables only? Other?)Is it possible to embed version information in the binaries, e.g. using a source control tag that updates the version in the source code on commits. Then when the new build is created, the binary would have it's version string updated as well. Instead of having to diff a binary file, you could use the version string and check that for changes.

1
votes

Look at NDepend.

0
votes

When I was working on the "home grown" tool for installation verification at my company, we used Beyond Compare as a backend for comparison.

It has great file/folder comparison (binary as well) and scripting capabilities and can output XML reports.

0
votes

Project dependency graph generator and Dependency-Grapher for C++-Projects both use GraphViz to visualize dependencies. I imagine that you could use either of them as a basis for your needs with special highlighting of the branches in the dependency graph where source files or other leaves have changed.

MD5 hashes or checksums (as suggested above), a simple diff ignoring whitespace and filtering out comment changes, or changlist information from your version control system can signal which files have changed.