ELF，Build-ID，是否有重新计算它的实用程序？

Question

我在 ELF 二进制文件中发现了这个有用的功能 -- Build ID。 "It ... is (normally) the SHA1 hash over all code sections in the ELF image." 可以使用 GNU 实用程序阅读：

$ readelf -n /bin/bash
...
Displaying notes found at file offset 0x00000274 with length 0x00000024:
  Owner                 Data size   Description
  GNU                  0x00000014   NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 54967822da027467f21e65a1eac7576dec7dd821

我想知道是否有一种简单的方法可以自己重新计算构建 ID？检查它是否没有损坏等。

Answer 1

所以，我得到了马克的答复。由于它是最新信息，因此我将其发布在这里。但基本上你们是对的。确实没有计算Build-ID的工具，Build-ID的目的不是（1）识别文件内容，甚至不是（2）识别它的可执行（代码）部分，而是为了(3) 捕获构建的“语义”，这是形式化的难点。 （数字仅供参考。）

来自电子邮件的报价：

--“是否有用户工具从文件本身重新计算构建ID，以 检查它是否没有以某种方式损坏/受损等？” 如果你有时间，也许你可以在那里发布一个答案？

抱歉，我没有 stackoverflow 帐户。 但答案是：不，没有这样的工具，因为精确的方法 build-id 计算未指定。它必须是普遍的 独特。甚至没有指定构建 ID 的精确长度。那里 是使用不同哈希算法的各种方法，构建 ID 可能是 计算得到一个普遍唯一的值。并非所有数据都可能 （仍然是）在 ELF 文件中重新计算它，即使你知道它是如何的 最初创建的。

显然，Build-ID 的意图发生了变化 因为the Fedora Feature page 是关于 它。 人们对它现在的看法存在分歧。 也许在您的回答中，您可以包括 Build-ID 的状态以及它是什么 现在也是？

我认为事情的表述并不十分精确。如果一个工具改变了 创建 ELF 文件的构建，因此它不是“语义上 相同的”二进制文件，那么它应该得到一个新的（重新计算的） 构建 ID。但是，如果一个工具改变了文件的某些内容，仍然 产生一个“语义相同”的二进制文件，然后 build-id 保持 一样。

没有精确定义的是“语义相同的二进制” 方法。目的是它捕获构建的所有内容 制成。因此，如果用于生成二进制文件的源文件是 不同，那么您期望不同的构建ID，即使二进制代码 产生的可能恰好是相同的。

这就是为什么在通过哈希计算文件的 build-id 时 您不仅使用（分配的）代码段，还使用 debuginfo 部分（将包含对源文件的引用 名字）。

但是，如果您随后将 debuginfo 剥离（并将其放入 单独的文件）然后不会改变构建ID（文件仍然是 从同一个版本创建）。

这也是为什么，即使您知道用于 计算 build-id，您可能无法重新计算 构建 ID。因为你可能会遗漏一些在 用于计算 build-id 的哈希算法。

请随时与他人分享此答案。

干杯，

标记

此外，对于对debuginfo（Linux 性能和跟踪，有人知道吗？）感兴趣的人，他提到了几个在 Fedora 上管理它们的项目：

• https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
• https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo

Answer 2

我想知道是否有一种简单的方法可以自己重新计算 Build ID？

不，没有，设计。

您链接到其自身的页面链接到原始description 的构建ID 是什么以及它的用途。那页说：

But I'd like to specify it explicitly as being a unique identifier good
only for matching, not any kind of checksum that can be verified against 
the contents.

(There are external general means for content verification, and I don't 
think debuginfo association needs to do that.)

其他复杂情况是：链接器can take any of：

--build-id
--build-id=sha1
--build-id=md5
--build-id=0xhexstring

所以构建 id 不一定是一个 sha1 总和。

Answer 3

构建 ID 不是程序的哈希，而是构建的唯一标识符，被认为只是一个“唯一的 blob”——至少在某些时候它被定义为时间戳的哈希和绝对文件路径，但这也不能保证稳定性。