我在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
我想知道是否有一种简单的方法可以自行重新计算Build ID?检查它是否没有损坏等。
答案 0 :(得分:6)
所以,我得到了马克的回答。由于这是一个最新的信息,我在这里发布。但基本上你们是对的。实际上没有用于计算Build-ID的工具,并且Build-ID的意图不是(1)文件内容的标识,甚至不是(2)标识它的可执行(代码)部分,但它是(3)捕捉"语义含义"构建,这是形式化的难点。 (数字用于自我参考。)
从电子邮件中引用:
- "是否有用户工具从文件本身重新计算build-id 检查它是否以某种方式损坏/妥协等?" 如果你有时间,也许你可以在那里发表答案?
抱歉,我没有stackoverflow帐户。 但答案是:不,没有这样的工具因为精确的方式了 计算的build-id未指定。它必须是普遍的 独特。甚至没有指定build-id的精确长度。那里 是使用不同的散列算法的各种方式,build-id可以是 计算得到一个普遍唯一的价值。并非所有数据都可能 (仍然是)在ELF文件中重新计算它,即使你知道它是怎么回事 最初创建。
显然,Build-ID的意图发生了变化 自the Fedora Feature page撰写以来 它。 人们的观点与现在的情况不同。 也许在你的回答中你可以包括Build-ID的状态及其含义 现在呢?
我认为事情并非精确制定。如果工具改变了 构建它创建ELF文件,以便它不是语义上的 相同"二进制,然后它应该得到一个新的(重新计算) 建立-ID。但是,如果一个工具改变了仍然存在的文件 结果是"语义相同"二进制然后build-id保持不变 相同。
没有精确定义的是什么"语义上相同的二进制" 手段。目的是它捕获构建的所有内容 由...制成。因此,如果用于生成二进制文件的源文件是 不同的是你期望不同的build-id,即使是二进制代码 生产可能恰好相同。
这就是通过哈希计算文件的build-id的原因 您不仅使用(已分配)代码段而且使用的算法 debuginfo部分(包含对源文件的引用) 名)。
但是,如果你那么例如剥离debuginfo(并将其放入 单独的文件)然后,这不会改变构建ID(文件仍然是 从同一个版本创建。)
这也是为什么,即使你知道精确的哈希算法 计算build-id,你可能无法重新计算 建立-ID。因为您可能遗漏了一些原始数据 用于计算build-id的散列算法。
随意与他人分享这个答案。
干杯,
标记
另外,对于对debuginfo
感兴趣的人(linux性能和跟踪,有人吗?),他提到了几个在Fedora上管理它们的项目:
答案 1 :(得分:2)
构建ID不是程序的哈希,而是构建的唯一标识符,并且只被视为“唯一的blob” - 至少在某些时候它曾被定义为时间戳的哈希值和绝对文件路径,但这也不是稳定性的保证。
答案 2 :(得分:2)
我想知道是否有一种简单的方法可以自行重新计算构建ID?
不,没有,按设计。
您链接到自己的网页会链接到构建ID的原始description以及它可用的内容。那些页面说:
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开头。