Geben Sie PT_NOTE, p_offset=p_addr=0x254, p_filesz=p_memsz ein =0x44
Der Versatz zeigt in der Mitte des ELF-Headers (irgendwo in der Segmenttabelle). Die Bytes, auf die es zeigt, sehen nicht wie gültige Notizen aus – es handelt sich um echte Programm-Header-Daten. Die Zahlen 0x254/0x44 tauchen zu konsistent auf, als dass es Zufall wäre.
Soweit ich sehen kann, werden Segmente vom Typ PT_NOTE vom Linux-Loader ohnehin ignoriert. Es sieht so aus, als ob ein Toolchain-Anbieter beschlossen hat, Felder in einem Notiztypsegment als Arbeitsspeicher zu verwenden – nicht zum Laden und/oder Zuordnen, sondern zur anderweitigen Interpretation. Das ABI-Dokument lässt nichts dergleichen vermuten. Die Binärdateien haben auch Notiztyp-Abschnitte, an anderer Stelle und mit vollkommen gültigem Format.
Was ist hier die Geschichte?EDIT: vielleicht ist es doch kein Kratzer; Zumindest in den Binärdateien, die ich habe, entspricht die Zahl 0x44 zufällig der Gesamtgröße der darin enthaltenen Abschnitte (ABI-Tag von 0x20 und Build-ID von 0x24). Aber was ist mit dem Offset und der Adresse?
In meinen kürzlich (mit GCC) erstellten Binärdateien gibt es ein PT_NOTE-Segment der Größe 0x44, aber der Offset/die Adresse entspricht zwei zusammenhängenden Notizen Abschnitte in der Binärdatei. Es könnte sich also entweder um einen alten Linker-Fehler handeln, den der Loader verzeiht und seitdem behoben hat, oder um eine Art magische Vorkehrung speziell für PT_NOTEs...
Beweis anderswo:
- ELF-Programmsegmente in Datei versetzt
- https://velog.io/@silvergun8291/GEF-%EC ... 9%EB%B2%95
- https:/ /gist.github.com/rallias/4abdb811ed8cced0623c
- https://www.filescan.io/uploads/670caa9 ... ff/details
- https://lists.volatilityfoundation.org/ ... GUKCEQBUH/