Build-ID-Daten-Offset in der ELF-Datei

Question

build-idIch muss den Abschnitt der ELF-Notizen ändern . Ich habe herausgefunden, dass es hier möglich ist . Habe auch herausgefunden, dass ich es tun kann, indem ich diesen Code ändere . Was ich nicht herausfinden kann, ist der Datenspeicherort. Hier ist, wovon ich spreche.

$ eu-readelf -S myelffile

Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
...
[ 2] .note.ABI-tag        NOTE         000000000000028c 0000028c 00000020  0 A      0   0  4
[ 3] .note.gnu.build-id   NOTE         00000000000002ac 000002ac 00000024  0 A      0   0  4
...


$ eu-readelf -n myelffile

Note section [ 2] '.note.ABI-tag' of 32 bytes at offset 0x28c:
  Owner          Data size  Type
  GNU                   16  GNU_ABI_TAG
    OS: Linux, ABI: 3.14.0

Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x2ac:
  Owner          Data size  Type
  GNU                   20  GNU_BUILD_ID
    Build ID: d75a086c288c582036b0562908304bc3a8033235
             

.note.gnu.build-idAbschnitt ist 36 Byte groß. Die Build-ID ist 20 Byte groß. Was sind die anderen 16 Bytes?

Ich habe ein bisschen mit dem Code gespielt und 36 Bytes von myelffileat offset gelesen 0x2ac. Habe folgendes bekommen 040000001400000003000000474e5500d75a086c288c582036b0562908304bc3a8033235.

Dann entschied ich mich für die Verwendung von Elf64_Shdrdefinition , also las ich Daten unter Adresse 0x2ac + sizeof(Elf64_Shdr.sh_name) + sizeof(Elf64_Shdr.sh_type) + sizeof(Elf64_Shdr.sh_flags)und erhielt meine Build-ID d75a086c288c582036b0562908304bc3a8033235. Es macht Sinn, warum ich es bekommen habe sizeof(Elf64_Shdr.sh_name) + sizeof(Elf64_Shdr.sh_type) + sizeof(Elf64_Shdr.sh_flags) = 16 bytes, aber laut Elf64_ShdrDefinition sollte ich auf verweisen Elf64_Addr sh_addr, dh auf die virtuelle Adresse des Abschnitts.

Was mir also nicht klar ist, was sind die anderen 16 Bytes des Abschnitts? Was repräsentieren sie? Ich kann die Elf64_ShdrDefinition und die Ergebnisse meiner Experimente nicht in Einklang bringen.

Answer 1

Der Abschnitt .note.gnu.build-id ist 36 Byte groß. Die Build-ID ist 20 Byte groß. Was sind die anderen 16 Bytes?

Jeder .note.*Abschnitt beginnt mit Elf64_Nhdr(12 Bytes), gefolgt von (4-Byte-ausgerichteten) Notennamen variabler Größe ( GNU\0hier), gefolgt von (4-Byte-ausgerichteten) tatsächlichen Notendaten. Dokumentation .

Blick /bin/dateauf mein System:

 eu-readelf -Wn /bin/date

Note section [ 2] '.note.ABI-tag' of 32 bytes at offset 0x2c4:
  Owner          Data size  Type
  GNU                   16  GNU_ABI_TAG
    OS: Linux, ABI: 3.2.0

Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x2e4:
  Owner          Data size  Type
  GNU                   20  GNU_BUILD_ID
    Build ID: 979ae4616ae71af565b123da2f994f4261748cc9

Was sind die Bytes am Offset 0x2e4?

 dd bs=1 skip=$((0x2e4)) count=36 < /bin/date | xxd

00000000: 0400 0000 1400 0000 0300 0000 474e 5500  ............GNU.
00000010: 979a e461 6ae7 1af5 65b1 23da 2f99 4f42  ...aj...e.#./.OB
00000020: 6174 8cc9                                at..

Wir haben also: .n_namesz == 4, .n_descsz == 20, .n_type == 3 == NT_GNU_BUILD_ID, gefolgt von einem 4-Byte- GNU\0Notennamen, gefolgt von 20 Bytes tatsächlicher Build-ID-Bytes 0x97, 0x9a, usw.