ELF, Build-ID, y a-t-il un utilitaire pour le recalculer?

Question

Je suis tombé sur cette fonctionnalité utile dans les binaires ELF - Build ID. "It ... is (normally) the SHA1 hash over all code sections in the ELF image." On peut le lire avec l'utilitaire 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 

Et je me demande s'il y a un moyen facile de recalculer ID Build-vous? Pour vérifier si elle n'est pas corrompue etc.

Answer 1

J'ai donc une réponse de Mark. Comme c'est une information à jour, je l'affiche ici. Mais en gros, vous avez raison. En effet, il n'y a pas d'outil pour calculer Build-ID, et les intentions de Build-ID ne sont pas (1) l'identification du contenu du fichier, et pas même (2) l'identification de l'exécutable (code), mais (3) capturer "la signification sémantique" d'une construction, qui est le bit dur pour la formalisation. (Les chiffres sont pour l'auto-référence.)

Citation de l'e-mail:

- « Y at-il un outil utilisateur recalculant l'accumulation id du fichier lui-même, à vérifier si ce n'est pas corrompu/compromis en quelque sorte etc? " Si vous avez le temps, vous pourriez peut-être poster une réponse là-bas?

Désolé, je n'ai pas de compte stackoverflow. Mais la réponse est: Non, il n'y a pas un tel outil, car la façon précise dont un build-id est calculé n'est pas spécifiée. Il doit juste être universellement . Même la longueur précise du build-id n'est pas spécifiée. Il y a différentes manières d'utiliser différents algorithmes de hachage. Un identifiant de construction peut être calculé pour obtenir une valeur universellement unique. Et toutes les données ne peuvent pas (être toujours) dans le fichier ELF pour le recalculer même si vous saviez comment il a été créé à l'origine.

Apparemment, les intentions de construction ont changé ID depuis the Fedora Feature page a été écrit sur il. Et les opinions des gens divergent sur ce que c'est maintenant. Peut-être que dans votre réponse, vous pourriez inclure le statut de Build-ID et ce qu'il est maintenant aussi?

Je pense que les choses n'ont pas été formulées très précisément. Si un outil modifie la construction qui crée le fichier ELF de sorte qu'il ne soit plus un binaire "sémantiquement ", il doit obtenir un nouveau (recalculé) build-id. Mais si un outil change quelque chose à propos du fichier qui reste donne un binaire "sémantiquement identique" alors l'identifiant de construction reste identique à .

Ce qui n'est pas précisément défini est ce que signifie "binaire sémantiquement identique" . L'intention est de capturer tout ce qui a été fabriqué à partir de . Donc, si les fichiers source utilisés pour générer un binaire sont différents, alors vous attendez des ID de construction différents, même si le code binaire produit peut être le même.

C'est pourquoi lors du calcul de l'accumulation id d'un fichier par un algorithme de hachage vous utilisez pas seulement les (affectés) sections de code, mais aussi les sections debuginfo (qui contiendra des références au fichier source noms) .

Mais si vous alors par exemple dépouillez la debuginfo out (et le mettre dans un fichier séparé ) puis qui ne change pas l'accumulation id (le fichier était encore créé à partir de la même construction). C'est aussi pourquoi, même si vous connaissiez l'algorithme de hachage précis utilisé pour calculer l'ID de construction, vous ne pourrez peut-être pas recalculer l'ID de construction . Parce que vous pourriez manquer certaines des données d'origine utilisées dans l'algorithme de hachage pour calculer l'ID de construction.

N'hésitez pas à partager cette réponse avec les autres.

Cheers,

Mark

En outre, pour les personnes intéressées à debuginfo (? Performances linux & suivi, tout le monde), il a mentionné un projet de couple pour les gérer sur Fedora:

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

Answer 2

L'ID de construction n'est pas un hachage du programme, mais plutôt un identifiant unique pour la construction, et doit être considéré comme un "blob unique" - au moins à certains point qu'il a l'habitude d'être défini comme un hachage de l'horodatage et le chemin absolu du fichier, mais ce n'est pas non plus une garantie de stabilité.

Answer 3

Je me demande s'il existe un moyen facile de recalculer Build ID vous-même?

Non, il n'y a pas, par conception.

La page que vous avez liée à elle-même contient des liens vers l'original description de ce qu'est l'ID de construction et pour quoi il est utilisable. Cette pages dit:

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.) 

complications supplémentaires sont: l'éditeur de liens can take any of:

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

Ainsi l'ID build est pas nécessairement une somme SHA1 pour commencer.