用于区分 Windows 二进制文件的工具？答案

【问题标题】：tools for diffing windows binaries?用于区分 Windows 二进制文件的工具？
【发布时间】：2008-12-06 02:57:42
【问题描述】：

我们的 QA 团队希望根据 EXE 和 DLL 在构建之间的实际更改来集中测试。我们有一个不错的 svn 更改报告，但是源代码和更改后的二进制文件之间的关系并不总是很明显。我们比较的构建总是完全干净的构建，所以我们不能使用文件系统时间戳。我正在寻找用于比较 Windows（和 Windows CE）PE 二进制文件的工具，这些二进制文件将忽略嵌入的时间戳和其他杂乱无章的东西。对于生成可靠的“哪些二进制文件真正改变了”报告的工具或其他方法有什么建议吗？谢谢。

澄清：感谢到目前为止的回答，但我们无法通过直接逐字节比较或比较校验和来生成报告，因为每次构建时所有文件看起来都不同，即使源没有' t 改变了，因为编译器插入了时间戳。问题是如何忽略误报。我认为拆解和比较的想法最接近我们的需要......

回答！ Bindiff 正是我想要的。非常感谢。

【问题讨论】：

有趣的技术问题，但是是什么让“EXEs/DLLs changed”列表比“source files changed”列表更相关？
这里是场景：svn 说 ObscureLib.c 自上次构建以来发生了变化。我应该重新运行 foo.exe 的测试套件吗？

标签： windows diff compare build binaries

【解决方案1】：

你看过Bindiff吗？

【讨论】：

不幸的是，这似乎不适用于在 Visual Studio 中构建的托管文件。即使我在 VS2010 中编译了一个 dll，将该文件重命名为 .old.dll，然后再次编译（不更改版本信息！），然后执行“bindiff.exe /v file.dll file.old.dll”然后它说文件不同。进行十六进制比较证实了这一点。想知道这是什么原因？

【解决方案2】：

我之前遇到过这个问题。我的解决方案是编写一个工具，将 .EXE/.DLL 中的所有时间戳设置为已知值。我会将它作为构建后的步骤运行。然后二进制差异就可以正常工作了。

【讨论】：

【解决方案3】：

您也许可以反汇编二进制文件，然后对程序集进行比较...

这听起来像是您的 QA 团队采用了错误的方法……但对他们而言，代码是什么样子并不重要；只是它做了它应该做的事情。

编辑：哦！再次阅读后，我意识到我误解了你的问题。我以为他们想测试已经改变的方法......

在这种情况下，为什么不获取 MD5 哈希值并进行比较呢？最细微的变化都会导致生成完全不同的哈希。

【讨论】：

是的，但我认为 QA 团队只想花时间测试已更改的二进制文件，因此需要 diff 工具

【解决方案4】：

不确定哪种二进制文件（DLL？仅限 PE/WinCE 可执行文件？其他？）是否可以在二进制文件中嵌入版本信息，例如使用源代码控制标签在提交时更新源代码中的版本。然后，当创建新版本时，二进制文件也会更新它的版本字符串。不必比较二进制文件，您可以使用版本字符串并检查更改。

【讨论】：

我们考虑了版本号。自动更新版本号仍然需要将源更改映射到二进制文件（这很难）。手动更新版本号太容易出错。（即我不相信开发人员能可靠地做到这一点。:-)）

【解决方案5】：

看NDepend。

【讨论】：

【解决方案6】：

当我在公司开发用于安装验证的“自制”工具时，我们使用 Beyond Compare 作为后端进行比较。

它具有出色的文件/文件夹比较（以及二进制）和脚本功能，并且可以输出 XML 报告。

【讨论】：

【解决方案7】：

Project dependency graph generator 和 Dependency-Grapher for C++-Projects 都使用 GraphViz 来可视化依赖关系。我想你可以使用它们中的任何一个作为你需要的基础，特别突出依赖图中源文件或其他叶子发生变化的分支。

MD5 哈希或校验和（如上所述）、忽略空格并过滤掉注释更改的简单差异，或来自版本控制系统的 changlist 信息可以指示哪些文件已更改。

【讨论】：

【解决方案8】：

gnu binutils 特别是strings

【讨论】：