Is there a way to detect whether two EXE's (compiled from VS.Net 2008 for C++/MFC) do not have any code-level changes between them i.e. for purposes of knowing that there have been no statement changes.
This is for compliance purposes when my vendor ships me an exe, ostensibly with no changes made to the code since the last time we tested it.
Is there a tool to check that this is so?
Cheers
You could use a dissembler to disassemble the executable back into assembly and compare with a normal text diff tool.
But even that will not be 100% accurate. The compilation process is not lossless and much information is lost or irreversibly transformed when C++ code is compiled.
In particular, different compiler settings can generate vastly different machine code from exactly the same source. Different compilers and even different versions or service-pack/hotfix levels of the same compiler can produce vastly different machine code from the same source files.
The other question is, why are they even sending you the exe back "ostensibly with no changes made"? If that's the case, why don't you just use the one you had originally?
You can always perform an MD5sum on the executables. This won't tell you whether they are logically equivalent or different, simply that a difference exists.
I'm not sure if this solves your issue, as you may be looking for a logical comparison tool.
If you are in control of the source simply don't ship out exes that don't have proper versioning info associated with them.
If for some reason they build their own exes, I would suggest having a build step that they have to use that will embed the version control revision number into the versioning info.
If they don't use your build step (which you can detect) then you assume they are different.
Most revision control systems (such as SVN for example) will allow you to have a build step that will say whether the code is in a modified state or not. You could have this info embedded into a string in an embedded resource for the exe. You would then just extract that resource.
So it comes down to make sure all builds happen from your custom build script.
Automate your testing so that the tests can be rerun quickly.
Even though this is a small statement to make, it is a big undertaking
For binary auditing, one of the hands-down best tools that you must have is the Interactive Disassembler, also better known as IDA Pro. It is a must have when you need to audit without access to the source code. Someone proficient in using IDA Pro will be able to tell you, with a reasonable amount of confidence, if there have been anything more than superficial changes to the source code. In this context, superficial changes would encompass things like variable renaming within the source files or changing the order of variable, function or class declarations and definitions. They will be able to tell you if the basic code blocks making up the executables have differences between them substantial enough to be flagged as suspicious, in the sense that there is a high probability that the differences are indicative of a source-level difference.
I say more or less, because there are several ways in which two executables generated from the exact same source tree could still have subtle, and on occasion not so subtle, differences between each other. Factors that can influence the generation of the executables include:
And this list could go on for a while.
Is the sort of binary audit you are suggesting possible? Yes, a person with enough knowledge and skill could do this. Hackers do this all the time. And if the person doing the analysis is good enough, they will be able to tell you exactly how confident they are in their assessment as well.
Ultimately it becomes a question of feasibility. How much are you willing to spend on this audit? Hiring or contracting someone who can do this may push beyond what is budgeted for such auditing, is there enough money to do this? How complex is the software you are testing? What is the nature of your relationship with your vendor?
That last question is important because if it is in their best interest to pass this audit, and they realize this, they may be willing to assist you up to a certain degree. This could come in the form of debugging symbols, a list of compiler options which were used or some other artifacts of the build process they are willing to disclose. The preceding can all be very helpful in any analysis where source code is not being made available for the purposes of analysis due to whatever reason. And if access to the source code is available for such a purpose, things become an order of magnitude easier to analyze.
If this is something you would like to pursue on your own, two books I would recommend are The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler by Chris Eagle and The Shellcoder's Handbook: Discovering and Exploiting Security Holes by Chris Anley, John Heasman, Felix Linder and Gerardo Richarte.
Lastly, the techniques and tools developed for analysis of the kind that would help you are still very much active areas of research. Your question either runs deeper than you may realize, or it may have been misunderstood by me. A thorough treatment of your question, even from just a practical standpoint and ignoring the theory that goes along with it, could, and does, fill many books.
I hope you find at least some part of this helpful. Good luck!
From now on, add a post build step that will generate a MD5 of the sources files and add it to the VERSION resource (so that you can see it in the exe properties).
It will cost you 2 or 3 man days.
Load up the exes in a hex compare program (BeyondCompare rocks!).
If there are any non-trivial changes (assuming compiler settings have not changed), they should be pretty easy to pick up. If it's just a matter of timestamps, etc. it may be pretty obvious.
This definitely isn't foolproof, but it would be my first step.