ELF,Build-ID,是否有一个实用程序来重新计算它？

我在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的精确长度.有多种方法可以使用不同的散列算法来计算build-id以获得通用唯一值.并非所有数据都可能(仍然)在ELF文件中重新计算,即使您知道它是如何创建的.

显然,自Fedora功能页面编写以来,Build-ID的意图发生了变化.人们的意见在现在的情况上有所不同.也许在你的回答中你可以包括Build-ID的状态以及它现在的状态如何？

我觉得事情并没有很精确地制定出来.如果工具更改了创建ELF文件的构建,使其不再是"语义相同"的二进制文件,那么它应该获得一个新的(重新计算的)构建ID.但是,如果某个工具更改了仍然导致"语义相同"二进制文件的文件,那么build-id保持不变.

没有精确定义的是"语义相同的二进制"意味着什么.目的是它捕获构建的所有内容.因此,如果用于生成二进制文件的源文件不同,那么您需要使用不同的build-id,即使生成的二进制代码可能恰好相同.

这就是为什么在通过哈希算法计算文件的build-id时,不仅使用(已分配的)代码段,还使用debuginfo段(包含对源文件名的引用).

但是,如果您然后将debuginfo剥离(并将其放入单独的文件中),那么这不会更改build-id(该文件仍然是从同一版本创建的).

这也是为什么即使您知道用于计算build-id的精确散列算法,也可能无法重新计算build-id.因为您可能缺少散列算法中使用的一些原始数据来计算build-id.

随意与他人分享这个答案.

干杯,

标记

另外,对于那些对debuginfo(linux性能和跟踪,任何人？)感兴趣的人,他提到了几个在Fedora上管理它们的项目:

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

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