Bonjour à vous,
Les examens terminés, presque en poche, je peux dorénavant me re-consacrer à ce blog.
J'ai été tout d'abord pas mal occupé par les revisions par exemple, afin de me permettre de rentrer à l'IUT l'année prochaine .
J'en profite pour constater que malgré tout ce qu'on peut dire, la scène française est tout de même en ébulition : SSTIC, Nuit du hack, Hacker Space Festival, etc.
Tant qu'on y est je voulais faire une petite publicité pour le microblog de nibbles, une idée que je trouve excellente : Il s'agit de créer un blog, dans lequel les posteurs écriraient des 'brêves', ou jetteraient quelques bouts de codes, let's share your knowledge
Sinan, j'ai préparé un petit article que je compte release en même temps qu'un projet qui est en train de se monter, donc ne vous inquiétez pas des nouveautés arrivent à flots !
Maintenant que j'ai finis mon blabla (et oui, ça fait longtemps !), je vous propose un petit code à vous mettre sous la dent.
Il s'agit en effet d'un """packer""" de binaire PE, il est très simple.
Le binaire est mappé en mémoire afin de toucher au section, c0rt3x va vérifier si il reste assez de place à la fin de la première section afin d'y placer son "loader", qui déchiffrera la section encodée par un simple XOR.
Le binaire est donc directement exécutable en fin du package.
Quelques parties de codes furent assez galère à mettre en place, comme l'adaptation du loader au binaire etc.
De plus je n'avais jamais rencontré de source du style, en C c'est pour cela que je vous propose ce petit code.
Au niveau compréhension je ne pense pas qu'il nécessite d'autres informations que celles relatives au format PE tout simplement.
Voici le code :
c0rt3x.c
Loader.asm
Et voilà de quoi vous occupez un petit peu, à plus.
C0RT3x WAS HERE !
Inscription à :
Publier les commentaires (Atom)
4 commentaires:
Tient! Le retour du Jedi :P
Alors?! Le bac? Tu l'as Owned?!
"decryptera" : on dit "déchiffrer" en français :)
Merci pour le code.
J'ai mis pas mal de temps à l'étudier pour comprendre comment ça marche mais j'y suis lol
Quelques remarques sur le code toutefois :
* Dans la version en ligne il y a un "exit(0);" qui a sans doute été retiré par la suite sans quoi le code quitte trop tôt.
* Tu fais des mallocs pour tes différents pointeurs (imgDosHeader, imgNtHeader et imgSectionHeader) mais comme ensuite tu fais des affectations cet espace mémoire est perdu... et les free() à la fin risques de gueuler.
* Dans la boucle pour vérifier l'espace dispo dans la section, tu tourne sizeof(loader)/4 fois car tu fais une vérification par int mais adresseFinSection ne devrait pas être décrémenté de 4 à chaque boucle dans ce cas là ?
Sinon très instructif, je vais le garder de côté :)
Salut à toi,
Alors je vais répondre à tes questions :).
*Le exit(0), bien évidement c'était un petit oublis, j'avais exporté la source "trop tôt".
*En effet, les mallocs sont complètement inutile, enfin il l'était pas au départ :).
*Durant la boucle addrFinSection est de type DWORD* autrement dit sa taille s'élève à 4octets.
Lors de la boucle je procède donc à un addrFinSection-- qui va le décrémenter de 4 en effet.
Regarde ce petit exemple, considère un pointeur sur un DWORD ou un long :
PDWORD tapz;
tapz = (PDWORD)0x1337;
printf("Pointeur : %x , Pointeur + 1 : %x.\n" , tapz , tapz+1);
Ce qui s'affichera dans la console sera :
Pointeur : 1337 , Pointeur + 1 : 133b.
Soit 133b - 1337 = 4 :).
En C lorsque tu incrémentes un pointeur sur un type X, le pointeur est en fait incrémenté de la taille du type X.
Merci pour l'histoire des mallocs, le poc est un peu écrit avec les pieds, c'est une """ébauche""" :)).
Bonne soirée, 0vercl0k.
Enregistrer un commentaire