THJ13/PE Header, l'incontournable en cracking Windows
Un article de HackaWiki.
Fatigué d'inverser des sauts conditionnels ? En route pour des techniques de cracking plus avancées, faisant intervenir le coeur des fichiers exécutables Windows : le PE Header. Quelques pistes, et surtout un guide pratique sur l'utilisation des éditeurs PE, et autres unpackers.
Wild
By silkscalp
Un bonne connaissance du format PE peut permettre aux reversers d’aller très loin dans la modification d’un programme. Que ce soit pour faire des patch en mémoire, analyser les sections comme celle contenant la table d’import (les fonctions importées depuis des DLL) ou encore modifier des sections d'un programme. Nous allons dans cet article essayer de comprendre ce qu’est le PE, quelles sont les informations qu'il fournit et en quoi ces informations peuvent être utiles à un cracker.
Le sigle PE signifie Portable Exécutable. C’est une en-tête reconnue par toute les plateformes Windows. Le PE est obligatoire pour le bon fonctionnement de tout exe sur Windows : il permet de savoir de quel type de programme il s'agit et comment le faire fonctionner. C'est lui, par exemple, qui nous sort la célèbre phrase : « This program cannot be run in DOS mode ».
Mais quel est le fonctionnement d’un exécutable sous Windows ? Le PE header est crée par le compilateur du langage utilisé. Le PE loader va lire le PE, puis il va mapper le programme en mémoire vive en fonction des informations données, avant que le début du code soit exécuté.
Chaque PE header contient un grand nombre d’informations sur le programme qu'il décrit, dont je vais, dans cette introduction, parler du principal. Pour vous montrer la mesure des informations contenues par le PE header, sachez que toutes les informations données par LordPE ou StudPE (voir prise d’écran 1 et 2) proviennent du PE.
En fait ces logiciels décortiquent le PE pour nous donner les information qu’il contient, et d’ailleurs permettent souvent de savoir par quel programme le logiciel étudié a été packé. En effet, beaucoup de logiciels utilisent comme protection le packing/cryptage de leur code. Or les informations d’un éditeur de PE peuvent servir à passer ces mesures préliminaires de protéction, soit à la main, soit par des moyens automatiques. Les éditeur de PE élaboré vont trouver pour nous l'algorithme de packing utilisé (s'il est connu) et proposer de décompresser le programme.
Je vais vous montrer avec quelques prises d’écrans les informations que peut donner un éditeur de PE.
Les séctions
Illustration (ICI)
Image: pecracking-section.png
Dans cette prise d’écran les choses sont simples. Les informations données sont :
- Le nom des sections
- Leur offset Virtuel (Voffset) et leur Offset Réel (Roffset)
- Leur taille virtuelle (VSize) et leur taille réelle (Rsize)
- Et aussi, ce qui est très important, leur caractéristiques : ‘readable’, ‘writtable’, et ‘contain initialized data’.
D'abord,il faut savoir qu’un exécutable est séparé en différentes sections. Les principales sections sont : CODE (ou .TEXT) qui contient le code même du programme, la section .DATA qui contient les donnée ou variable utilisées par le programme, la section .IDATA qui contient les informations sur les fonctions et les DLL utilisées par le programme. C’est la section d'Import. Il y a encore la section .EDATA qui contient les fonction Exportées par le programme ; la section .rsrc qui contient les ressources utilisées par le programme (icones, chaines traduisibles, etc.). Toutes les informations sur la séparation des section et leurs taille est contenu dans le PE header.
Sachant que dans la plupart des cas, la taille réservée est plus grande que la taille réelle (la taille réservée est arrondie à 256 près), il reste presque toujours de la place a la fin des section pour qu'un crackeur puisse faire des chose pas très catholique. Nous verrons ces possibilités, en détail, dans un prochain Manuel, mais sachez déjà que cela peut permettre de passer la protection par checksum de l'article précédant. Vous vous rappelez sans doute que nous cherchions un endroit à modifier pour compenser les différences de la somme de contrôle. Les fins de section sont toutes trouvées. C'est également un endroit commode pour rajouter une petite portion du code (pour modifier le programme lors de son exécution, par exemple), sur lequel on peut se brancher depuis l'intérieur du programme.
Informations générales
Illustration
Image : pecracking-infogen.png
La deuxième prise d’écran présente ce qu’un éditeur de PE classique montre en premier, c'est-à-dire des infos comme l’image base, l’EntryPoint, la size of image, le header size (qui en général est toujours de 400h). Ici on peut relever des information comme le RVA (valeur 1000, en rouge) qui signifie Relative Virtual Adresse , l’ImageBase ,l’entryPoint, le nombre de section (5) et d’autre informations. Pour vous donner un exemple : pourquoi la majorité des programme non packé commence en 401000 (ou du moins leur code, data comprises) quand on les désassemble ?
En fait, cela vient du PE header. Le PE loader charge l’exe en mémoire grâce au infos données par le PE et ici le PE indique que la plage mémoire réservée au programme commence en 400000 (l’Image base comme par hasard) , additionné a l’EntryPoint (1000) : 400000 + 1000 = 401000 soit l’adresse du début du programme quand on le désassemble. Ce n’ai pas un hasard et ces valeurs sont très importantes pour arriver a une bonne décompression d’un programme compressé.
Unpackers
Illustration
Image : pecracking-unpack.png
Ici on voit que l’éditeur de PE peut détecter le type de compression utilisé pour protéger le programme (parmi un grand nombre d'algorithmes), présentement FSG1.2 par dulek/xt. Pe-scan ou StudPE en sont capable (même si pe-scan donne juste la compression sans faire éditeur de PE). C'est aussi le cas de ProcDump, qui permet également d'ajouter de nouveaux format de compression, grâce à un langage de script. En effet, lors qu'un nouvelle technique est rencontrée, le cracker doit décompresser le programme à la main (avec un débugger pour les plus simples). Le langage de script permet d'automatiser le processus, au cas où cette technique est à nouveau rencontrée.
Nous n'avons fait que survoler les possibilités offertes par la manipulation du PE header. À vous de les expérimenter, en attendant mes prochains articles sur le sujet.
Un bon site pour trouver les outils dont nous parlons (attention, c'est l'occasion de sortir votre antivirus, nous ne pouvons garantir la fiabilité de ces sources) :
http://protools.cjb.net
