我在 ELF 二进制文件中发现了这个有用的功能——Build ID。 “它……（通常）是 ELF 映像中所有代码部分的 SHA1 哈希值。” 人们可以使用 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
我想知道是否有一种简单的方法可以自己重新计算 Build ID？检查它是否没有损坏等。
所以，我从马克那里得到了答案。由于这是最新信息，我将其发布在这里。但基本上你们是对的。事实上，没有计算Build-ID的工具，并且Build-ID的意图不是（1）识别文件内容，甚至不是（2）识别文件的可执行（代码）部分，而是为了(3) 捕获构建的“语义”，这是形式化的难点。 （数字仅供自我参考。）
引自电子邮件：
--“是否有一个用户工具可以从文件本身重新计算 build-id，以 检查它是否没有以某种方式损坏/受损等？” 如果您有时间，也许您可以在那里发布答案？
抱歉，我没有 stackoverflow 帐户。 但答案是：不，没有这样的工具，因为精确的方法 build-id 是计算出来的，没有指定。它必须是普遍的 独特的。甚至连 build-id 的精确长度也没有指定。那里 使用不同的哈希算法构建 id 的方法有多种 计算以获得普遍唯一的值。并非所有数据都可能 （仍然是）在 ELF 文件中重新计算它，即使你知道它是怎么回事 原创创建。
显然，Build-ID 的意图发生了变化 自从 Fedora 功能页面 被写入以来 它。 人们对现在的情况看法不一。 也许在您的回答中您可以包括 Build-ID 的状态及其含义 现在也这样吗？
我认为事情的表述并不十分精确。如果一个工具改变了 构建创建 ELF 文件，这样它就不是“语义上的” 相同的”二进制文件，那么它应该得到一个新的（重新计算的） 构建 ID。但是，如果工具更改了文件的某些内容，仍然 产生“语义相同”的二进制文件，然后 build-id 保持不变 一样。
没有精确定义的是“语义相同的二进制文件” 方法。目的是它捕获构建的所有内容 制成。因此，如果用于生成二进制文件的源文件是 不同的话你期望不同的构建ID，即使二进制代码 生产出来的可能会是一样的。
这就是为什么在通过哈希计算文件的build-id时 您不仅使用（分配的）代码部分，还使用算法 debuginfo 部分（其中将包含对源文件的引用 名称）。
但是，如果您随后将调试信息剥离出来（并将其放入 单独的文件）那么这不会改变构建ID（该文件仍然是 从同一版本创建）。
这也是为什么，即使您知道用于计算的精确哈希算法 计算 build-id，您可能无法重新计算 构建 ID。因为您可能会丢失一些原始数据 计算 build-id 的哈希算法。
请随意与其他人分享这个答案。
干杯，
马克
此外，对于对
debuginfo构建 ID 不是程序的哈希值，而是构建的唯一标识符，并且被视为只是一个“唯一的 blob”——至少在某些时候它曾经被定义为时间戳和绝对值的哈希值文件路径，但这也不能保证稳定性。
我想知道是否有一种简单的方法可以自己重新计算Build ID？
不，不存在，按设计。
您链接到自身的页面链接到原始 description，说明 build-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.)
额外的复杂性是：链接器可以采用以下任意一个：
--build-id
--build-id=sha1
--build-id=md5
--build-id=0xhexstring
因此，构建 ID 不一定是 sha1 总和。