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の正確な長さも指定されていません。そこに はさまざまな方法で異なるハッシングアルゴリズムを使用しています.build-idは普遍的な一意の値を得るために計算された です。 が元々作成されたことが分かっていたとしても、すべてのデータがELFファイル内の （まだ）であるとは限りません。

the Fedora Feature pageがそれ について書かれていたので、どうやら、ビルド-IDの意図は を変更しました。 そして、人々の意見は今のものとは異なります。 あなたの回答にBuild-IDのステータスを含めることができ、それは今でも なのでしょうか？

非常に正確には定式化されていないと思います。ツールが "semantically 同一"バイナリではなくなるようにELFファイルを作成する ビルドを変更すると、新しい（再計算された） build-idが得られるはずです。しかし、ツールがファイルについて何か変わっても、まだ という結果が "semantically identical"バイナリになると、build-idは のままです。

正確に定義されていないのは、「意味的に同一のバイナリ」とは何ですか？ を意味します。その意図は、ビルドが から作られたすべてをキャプチャすることです。したがって、バイナリを生成するために使用されるソースファイルが 異なる場合、バイナリコード が同じように生成されたとしても、異なるbuild-idsが必要です。

これは、ハッシュ アルゴリズムによってファイルのビルドIDを計算する際にあなただけの（割り当てられた）コードセクションがありません使用する理由ですが、また のdebuginfoセクション（ソースファイルへの参照 名が含まれます） 。

しかし、例えばdebuginfoを取り除いて別ファイル に入れると、ビルドIDは変わりません（ファイルは同じビルドから作成された です）。

ビルドIDの計算に使用されている正確なハッシングアルゴリズムが分かっていても、 ビルドIDを再計算できないことがあります。 で使用されている元のデータの一部が失われている可能性があるため、ハッシュアルゴリズムはビルドIDを計算します。

この回答を他の人と自由に共有してください。

乾杯、

マーク

はまた、debuginfoに興味がある人（？Linuxのパフォーマンス&トレース、だれでも）のために、彼は、Fedora上でそれらを管理するためのカップルのプロジェクトを述べた：

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

Answer 2

ビルドIDはプログラムのハッシュではなく、ビルドの一意の識別子であり、少なくとも「一意のBLOB」とみなされますポイントはタイムスタンプと絶対ファイルパスのハッシュとして定義されていましたが、それはどちらも安定性の保証ではありません。

Answer 3

自分で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の合計です。