有没有办法来检测两个EXE（从VS.Net 2008编译为C ++ / MFC）是否没有任何代码级别的变化，即为了知道没有语句的变化。
这是为了遵守的目的，当我的供应商运送我一个EXE，表面上没有任何改变，因为我们上次testing它的代码。
有没有一个工具来检查这是如此？
干杯
您可以使用拆装工具将可执行文件反汇编为汇编，并与普通的文本差异工具进行比较。
但即使这样也不会100％准确。 编译过程不是无损的，编译C ++代码时会丢失或不可逆转的信息。
特别是，不同的编译器设置可以从完全相同的源生成大不相同的机器代码。 相同编译器的不同编译器甚至不同版本或服务包/修补程序级别可能会从相同的源文件产生截然不同的机器代码。
另一个问题是，为什么他们甚至把你的exe文件“表面上没有改变”发回给你？ 如果是这样的话，你为什么不使用原来的那个？
自动化测试，以便测试可以快速重新运行。
尽管这是一个小小的陈述，但这是一个很大的事业
对于二进制审计，您必须具备的最佳工具之一是交互式反汇编程序 ，也称为IDA Pro 。 当您需要审核而无需访问源代码时，这是必须的。 精通使用IDA Pro的人将能够合理地告诉你，如果对源代码有任何超过表面的修改的话。 在这种情况下，表面变化将包含源文件内的变量重命名或变更变量，函数或类声明和定义的顺序。 他们将能够告诉你，构成可执行文件的基本代码块之间是否有足够的差异，可以被标记为可疑，因为这些差异很可能表明源级差异。
我或多或少地说，因为有几种方法可以使用完全相同的源代码树生成的两个可执行文件之间的细微差别，有时也不会太微妙。 可能影响可执行文件生成的因素包括：
而这份名单可能会持续一段时间。
你认为这种二元审计是可能的吗？ 是的，一个有足够的知识和技能的人可以做到这一点。 黑客一直这样做。 如果做这个分析的人员足够好，他们将能够告诉你他们在评估中的确信程度。
最终它成为一个可行性的问题。 你愿意花多少钱在这个审计上？ 聘用或者聘用可以做这件事的人可能会超出这个审计的预算，是否有足够的资金来做到这一点？ 你正在测试的软件有多复杂？ 你与供应商的关系的性质是什么？
最后一个问题是重要的，因为如果通过这个审计符合他们的最大利益，并且他们意识到这一点，他们可能愿意在一定程度上给予协助。 这可能以调试符号，使用的编译器选项列表或者他们愿意公开的构建过程的其他工件的形式出现。 前面的内容在任何源代码由于任何原因而不能用于分析目的的分析中都是非常有用的。 而且，如果对源代码的访问可用于这样的目的，事情就变得更容易分析。
如果这是你想要自己去追求的话，我推荐的两本书是“IDA专业书籍”： Chris Eagle 编着的 “世界最受欢迎反 编译器 非官方指南”和Shellcoder's Handbook： Chris Anley发现和利用安全漏洞， John Heasman，Felix Linder和Gerardo Richarte。
最后，开发用于分析的技术和工具将有助于您仍然是非常活跃的研究领域。 你的问题要么比你想象的更深，要么可能被我误解了。 彻底处理你的问题，即使只是从实际的角度来看，而忽略了与之相关的理论，也可以并且确实填补了许多书籍。
我希望你至少能找到一些有用的部分。 祝你好运！
您可以随时在可执行文件上执行MD5sum。 这不会告诉你他们是否在逻辑上相同或不同，只是存在差异。
我不确定这是否能解决您的问题，因为您可能正在寻找一个合乎逻辑的比较工具。
如果你是在控制源，只是不发运exes，没有适当的版本信息与他们相关联。
如果由于某种原因，他们建立了自己的exes，那么我会建议他们有一个构建步骤，他们必须使用它将版本控制版本号嵌入到版本信息中。
如果他们不使用你的构建步骤（你可以检测到），那么你认为他们是不同的。
大多数版本控制系统（比如SVN）都可以让你有一个构建步骤来说明代码是否处于修改状态。 您可以将这些信息嵌入到EXE嵌入式资源中的字符串中。 然后你会提取该资源。
所以下来确保所有的构建发生在您的自定义构建脚本中。
从现在开始，添加一个后期构建步骤，将生成源文件的MD5并将其添加到VERSION资源（以便您可以在exe属性中看到它）。
这将花费你2或3个人日子。
在十六进制比较程序（BeyondCompare rocks！）中加载exes。
如果有任何不小的改变（假设编译器设置没有改变），它们应该很容易拾取。 如果只是时间戳的问题等等，这可能是非常明显的。
这绝对不是万无一失的，但这将是我的第一步。