Forum Linux.général magic number et structure de mon executable a.out

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
21
mai
2019

Bonjour à tous,

voila j'ai compilé mon programme : gcc main.c et ensuite j'utilise la commande :
hexdump ./a.out | head

ce qui me renvoie :

0000000 457f 464c 0102 0001 0000 0000 0000 0000
0000010 0003 003e 0001 0000 0540 0000 0000 0000
0000020 0040 0000 0000 0000 1930 0000 0000 0000
0000030 0000 0000 0040 0038 0009 0040 001d 001c
0000040 0006 0000 0004 0000 0040 0000 0000 0000
0000050 0040 0000 0000 0000 0040 0000 0000 0000
0000060 01f8 0000 0000 0000 01f8 0000 0000 0000
0000070 0008 0000 0000 0000 0003 0000 0004 0000
0000080 0238 0000 0000 0000 0238 0000 0000 0000
0000090 0238 0000 0000 0000 001c 0000 0000 0000

hexdump me renvoie 16 octets par ligne alors que je m'attendais sur du 64 bits à avoir des lignes de 8 octets,
de plus il regroupe les lignes par paquets de 2 octets (pourquoi?) qui semble inversé car je tombe sur E DEL F L au lieux de DEL E L F (qui est le magic number attendu). Avez vous une idée sur la structure des données de mon exécutable ?

Merci d'avance pour votre aide

  • # canonique

    Posté par  (site web personnel) . Évalué à 6.

    Bonjour,
    j'utilise en général l'option -C qui permet d'afficher la forme dite canonique :

    $ hexdump -C a.out
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  03 00 3e 00 01 00 00 00  90 23 00 00 00 00 00 00  |..>......#......|
00000020  40 00 00 00 00 00 00 00  10 21 02 00 00 00 00 00  |@........!......|
00000030  00 00 00 00 40 00 38 00  0b 00 40 00 25 00 24 00  |....@.8...@.%.$.|
00000040  06 00 00 00 04 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000050  40 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |@.......@.......|
00000060  68 02 00 00 00 00 00 00  68 02 00 00 00 00 00 00  |h.......h.......|

    Un man hexdump montre que l'affichage peut être paramétré finement.

  • # Nombre d'octets par ligne

    Posté par  (site web personnel) . Évalué à 5.

    hexdump me renvoie 16 octets par ligne alors que je m'attendais sur du 64 bits à avoir des lignes de 8 octets

    Le nombre d'octet par ligne n'a rien à voir avec la structure du fichier. Le fichier, c'est une séquence d'octets, point. Ils ne sont pas groupés par paquet de x octets dans le fichier, c'est la manière d'utiliser le fichier qui décide ce qu'on en fait. hexdump te donne une disposition qui a le mérite de tenir dans un terminal (<50 caractères de large) et de numéroter les adresses avec des nombres ronds en hexa.

    il regroupe les lignes par paquets de 2 octets (pourquoi?)

    Là encore, question de présentation, c'est sans doute le plus lisible.

    qui semble inversé car je tombe sur E DEL F L au lieux de DEL E L F (

    hexdump affiche les deux octets comme un nombre, et il a le choix entre considérer que le premier octet continent les bits de poids faibles ou de poids fort. Il fait le même choix que l'endianness de la machine sur laquelle il tourne, donc little-endian sur architecture Intel (poids faible d'abord), ce qui te donne l'impression que c'est « inversé ».

    Tu peux utiliser hexdump -C à la place, ça sera beaucoup plus proche de ce que tu souhaites.

    Ou mieux, un utilitaire comme https://pypi.org/project/hachoir-wx/ (mince, ça n'a plus l'air vraiment maintenu) pour visualiser plus précisément la structure de la plupart des formats de fichiers binaires.

  • # readelf

    Posté par  (site web personnel) . Évalué à 4.

    readelf ou objdump pour analyser le contenu d'un programme compilé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.