32

最终目标是比较在完全相同的环境中从完全相同的源构建的 2 个二进制文件，并能够判断它们在功能上确实是等效的。

一个应用程序是将 QA 时间集中在版本之间实际更改的内容上，以及一般的更改监控。

MSVC 与 PE 格式相结合自然很难做到这一点。

到目前为止，我发现并消除了这些东西：

  • PE 时间戳和校验和
  • 数字签名目录条目
  • 调试器部分时间戳
  • PDB 签名、年龄和文件路径
  • 资源时间戳
  • VS_VERSION_INFO 资源中的所有文件/产品版本
  • 数字签名部分

我解析 PE，找到所有这些东西的偏移量和大小，并在比较二进制文件时忽略字节范围。像魅力一样工作（好吧，对于我运行过的几个测试）。我可以说，在 Win Server 2008 上构建的 1.0.2.0 版本的签名可执行文件等于在我的 Win XP 开发盒上构建的 10.6.6.6 版本的未签名可执行文件，只要编译器版本和所有源代码和标头都相同。这似乎适用于 VC 7.1 -- 9.0。（对于发布版本）

有一个警告。

两个构建的绝对路径 必须 相同，长度必须相同。

cl.exe 将相对路径转换为绝对路径，并将它们与编译器标志等一起放入对象中。这对整个二进制文件有不成比例的影响。路径中的一个字符更改将导致一个字节在整个 .text 部分中在这里和那里多次更改（但是我怀疑有很多对象被链接）。改变路径的长度会导致明显更多的差异。在 obj 文件和链接的二进制文件中。

感觉像带有编译标志的文件路径被用作某种哈希，这使它成为链接的二进制文件，甚至影响不相关的已编译代码的放置顺序。

所以这是一个由 3 部分组成的问题（总结为“现在怎么办？”）：

  • 我是否应该放弃整个项目并回家，因为我正在尝试做的事情违反了物理定律和 MS 的公司政策？

  • 假设我处理绝对路径问题（在策略级别或通过找到一个神奇的编译器标志），还有其他我应该注意的事情吗？（像 __TIME__这样的东西确实意味着改变了代码，所以我不介意那些没有被忽略的东西）

  • 有没有办法强制编译器使用相对路径，或者让它认为路径不是它的样子？

最后一个原因是令人讨厌的 Windows 文件系统。你永远不知道什么时候删除几个 gigs 的源和对象以及 svn 元数据会因为恶意文件锁定而失败。至少在有空间的情况下创建新的根总是成功的。一次运行多个构建也是一个问题。运行一堆虚拟机虽然是一种解决方案，但却是一个相当繁重的解决方案。

我想知道是否有一种方法可以为一个进程及其子进程设置一个虚拟文件系统，以便多个进程树将同时看到不同的“C:\build”目录，它们只对它们私有...... -各种重量虚拟化......

更新：我们最近在GitHub 上开源了该工具。请参阅文档中的比较部分。

4

5 回答 5

13

我在一定程度上解决了这个问题。

目前，我们有构建系统，可确保所有新构建都在恒定长度的路径上（builds/001、builds/002 等），从而避免 PE 布局的变化。构建后，工具会比较新旧二进制文件，忽略相关 PE 字段和其他已知表面变化的位置。它还运行一些简单的启发式方法来检测动态可忽略的变化。以下是要忽略的完整列表：

  • PE 时间戳和校验和
  • 数字签名目录条目
  • 导出表时间戳
  • 调试器部分时间戳
  • PDB 签名、年龄和文件路径
  • 资源时间戳
  • VS_VERSION_INFO 资源中的所有文件/产品版本
  • 数字签名部分
  • 嵌入式类型库的 MIDL 虚存根（包含时间戳字符串）
  • __FILE__、__DATE__ 和 __TIME__ 宏，当它们用作文字字符串时（可以是宽字符或窄字符）

有时，链接器会使一些 PE 部分变大，而不会使其他任何东西失去对齐。看起来它在填充内移动了部分边界——无论如何它都是零，但正因为如此，我会得到具有 1 个字节差异的二进制文件。

更新：我们最近在GitHub 上开源了该工具。请参阅文档中的比较部分。

于 2012-05-15T17:29:18.250 回答
8

标准化构建路径

一个简单的解决方案是标准化您的构建路径，因此它们始终采用以下形式，例如：

c:\buildXXXX

然后，当您将build0434与build0398进行比较时，只需预处理二进制文件以将所有出现的build0434更改为build0398。选择一个您知道不太可能出现在您的实际源/数据中的模式，除了编译器/链接器嵌入到 PE 中的那些字符串。

然后你可以做你的正常差异分析。通过使用相同长度的路径名，您不会移动任何数据并导致误报。

垃圾箱实用程序

另一个技巧是使用dumpbin.exe（随 MSVC 提供）。使用dumpbin /all将二进制文件的所有详细信息转储到文本/十六进制转储。这可以更清楚地看到发生了什么/在哪里发生了变化。

例如：

dumpbin /all program1.exe > program1.txt
dumpbin /all program2.exe > program2.txt
windiff program1.txt program2.txt

或者使用你最喜欢的文本差异工具，而不是 Windiff。

Bindiff 实用程序

您可能会发现 Microsoft 的bindiff.exe工具很有用，可在此处获得：

Windows XP Service Pack 2 支持工具

它有一个 /v 选项，指示它忽略某些二进制字段，例如时间戳、校验和等：

“BinDiff 对 Win32 可执行文件使用特殊的比较例程，在执行比较时屏蔽两个文件中的各种构建时间戳字段。这允许两个可执行文件在文件真正相同时标记为“几乎相同”，除了他们建造的时间。”

但是，听起来您可能已经在做bindiff.exe 的超集了。

于 2009-07-25T01:24:59.150 回答
3

您是否尝试过反汇编可执行文件并比较反汇编？这应该会删除您提到的许多令人分心的细节，并使删除其他人更容易。

于 2009-07-25T01:07:48.180 回答
3

有没有办法强制编译器使用相对路径，或者让它认为路径不是它的样子？

你有两种方法可以做到这一点：

  1. 使用 subst.exe 命令并将驱动器号映射到构建文件夹（这可能不可靠）。
  2. 如果 subst.exe 不起作用，则为每个构建文件夹创建共享并使用“net use”命令。这个几乎可以肯定应该工作。

在任何一种情况下，您都将在开始特定构建之前为文件夹映射并重用相同的驱动器号，以便路径看起来与编译器相同。

于 2009-07-25T01:28:50.347 回答
1

我遇到了一个额外的工具来帮助解决这个问题： GitHub 上的 Ducible

“这是一个使可移植可执行文件 (PE) 和 PDB 的构建可重现的工具。”

它会修改提供的 *.exe、*.dll 和 *.pdb 文件，用确定性数据替换非确定性数据。

于 2021-04-20T20:20:13.390 回答