Bonjour a tous, je travaille actuellement sur un projet de reverse engineering qui permettrai de chargé un binaire ELF en mémoire, le réécrire en ajoutant une section (et donc du code).

Actuellement j'arrive a chargé le binaire, et le réécrire tel quelle. Mais je bloque sur la parti injection.

Tout d'abord je modifie mon headerELF:

   - J'actualise l'entry point pour pointer sur la nouvelle section

   - J'ajoute + 1 au program header et + 1 au section header.

Ensuite je réécris les "Programmes header" du fichier original; pour ensuite écrire le programme header de ma nouvelle section. Mon problème est actuellement sur p_offset que je n'arrive pas a calculer, d'après tout mes test je ne comprend pas la corrélation qu'il y a entre l'offset et ce que je peu troué dans le fichier. De plus je ne trouve pas la doc très claire:

tu dis faire un +1 sur program header et section header, ça correspond aux valeurs de nombre de programmes et nombre de sections de l'entête ?

De ce que je crois comprendre, pour p_offset (présent dans la partie Program Header), c'est le décalage à faire depuis le début du fichier pour tomber sur le programme correspondant à cette entrée du Program Header https://en.wikipedia.org/wiki/Executable_and_Linkable_Format 

Peut-être que l'image présent sur le wiki pourra t'aider à mieux comprendre.

Enfaite étant donné que j'injecte une nouvelle section dans le binaire, je doit également ajouter le program Header de la section, ainsi que la section header. Donc oui c'est bien ça.

Je crois avoir compris la même chose que toi sur le p_offset, mais en mettant le p_offset sur la ou commence le program Header que j'ajoute; et en calculant l'address par rapport au p_offset, je tombe sur la même address que mon deuxième program header (celui avec l'index 1). Dans le screen j'ai ajouté. (Le program header que j'ai insérer et le dernier avec l'index 13)

EDIT:

Sur stackoverflow j'ai vue un post qui si j'ai bien compris explique que le p_offset doit être par rapport au début de la section. Mais nouveau problème comment le connaitre a l'avance ? Étant donné que les section sont placé après le programme header, je ne peu pas connaitre a l'avance l'address ou les bytes de la section sont écris ?

-
Edité par SebastienPhelip 5 octobre 2023 à 12:27:27

non le Program Header (table) au début vaut pour l'ensemble du fichier tout comme le section Header (table) à la fin.
Si je reprends l'image du Wiki, le fichier est composé de:

• un header composé du Elf Header et d'une table de Program Header
• de sections contenant le code, des datas, ...
• un header de section

Plus bas, dans le Wiki, on y voit qu'un Program Header est composé de 32 octets (et donc la table contient n blocs de 32 octets) et le p_offset contient l'offset (nombre d'octets) entre le début du fichier et la section du programme du bloc Program Header en question.

Si tu insères une section, il faut recalculer les adresses et offsets des autres blocs dans les headers, puisque les sections vont être déplacées du fait de l'insertion.
Et comme c'est toi qui fait l'insertion, tu peux écrire a posteriori ces offsets (je pense d'ailleurs que c'est ce qui est fait).

Donc si je comprend bien, j'ai fait ce schema assez simplifier, je passe de ca, a ca:

ph_N -> program header N = index

s_N -> section N = index

On imagine que chaque section a une address a 0x10 de plus que la suivante pour simplifier les choses.

-
Edité par SebastienPhelip 5 octobre 2023 à 14:42:33

gwnarf  j'ai un doute maintenant en regardant mieux le wiki, si p_offset c'est un offset logique (numéro de section de 0 à N-1) ou un offset de nombre d'octets.

Si on considère que c'est un offset logique (ce qui semble être le cas finalement), ça simplifie bien les choses en fait, p_offset contient alors le numéro du secteur en partant de 0.
Ce qui est utilisé pour déterminer l'emplacement des secteurs, ce sont les infos e_phoff qui donne le début des program header, e_phnum le nombre de program header et e_phentsize la taille d'un program header pour le début de la zone des sections, et les p_filesz qui correspondent à la taille des segments des programmes. Tout ça permet de calculer les adresses de début de chaque section.

Désolé si je te mets sur une fausse piste à un moment, mais selon comment je relis, je comprends différemment de ce que je pensais avoir compris, rageant!!!

Sur ta capture précédente, les p_offset sont de vrais p_offset d'un fichier elf fonctionnel ? si oui, ça ne semble pas suivre la logique que j'ai décrit ici grrrr

J'ai l'impression d'avoir le même problème je ne comprend jamais vraiment la même chose a chaque fois que je relis :/

Oui en effet sur ma capture d'écran les data sont réels. Ca vient d'un bubble sort compilé en elf64

Si on part de ta capture, p_offset semble alors être un décalage en octet.

Si j'essaie d'interpréter, on a:

- 4 segments chargeables commençant à 0x0, 0x1000, 0x2000 et 0x2DF8

- à partir de 0x38 on a une table d'entête de programme (type phdr) (donc présent dans le 1er segment)

- à partir de 0x318, on a des info sur l'interpréteur (type INTERP) (donc aussi présent dans le 1er segment)

- à partir de 0x2E08, on a des infos de liaisons dynamique (type DYNAMIC) (donc présent dans le 4ème segment)

etc

Donc si tu rajoutes quelque chose, il faut savoir si c'est un segment entier, auquel cas, il faut ajouter un program header, et lui indiquer le début des nouvelles données; si c'est du code, il pourrait directement être ajouté à un secteur existant, il faudra s'assurer que ça n'empiète pas sur d'autres parties décrites, et juste changer les tailles p_filesz et p_memsz.
Il faudrait comparer avec ce que peut donner les sorties de compilation (si c'est du C, il me semble que l'on peut demander au compilateur de sortir les fichiers intermédiaires (assembleur, édition de liste, ..) en les étudiant, on doit pouvoir retrouver nos petits.
Rajoute du code dans le fichier d'origine, refait une compilation, et regarde ce qui a été modifié; c'est peut-être le plus simple pour essayer de comprendre.

-
Edité par umfred 6 octobre 2023 à 11:25:19