étant donné les rapides soutiens dans les commentaires des articles précédents (et j'en remercie les auteurs) ainsi que d'une motivation inouïe, je me mets à continuer ma route sur le format PE. Cet article conclura le mois de mars avec brio, je l'espère.
Je me triture la cervelle en cours. Mais j'avais déjà réfléchi à injecter du code à la place des octets nuls présents à partir de 0x240, j'en avais parlé avec UnKnOwN*DrAgOoN - il est chiant à écrire, son pseudo - ; j'y suis arrivé, et j'y consacrerai un article plus tard.
Cet article servira de support à la pratique pour trifouiller le format PE. Il vous faudra unn outil intéressant que vous possédez certainement : Olly dbg. Pour ceux qui ne connaissent pas, Olly Dbg est un outil gratuit qui permet de désassembler des programmes afin de :
- Cracker (ouuuh c'est mal !) ;
- "Reverser" le programme - c'est-à-dire comprendre son fonctionnement en lisant le code assembleur ;
- Trouver le problème en cas d'algorithme mal implémenté ;
- ...
Ici, on va s'en servir pour analyser la mémoire d'un exécutable. Voici ce dont vous aurez besoin pour la pratique : http://venom630.free.fr/geo/?path=blog/pratique_pe.
Quatre fichiers :
- sh_over_asm.txt : shellcode conçu par 0vercl0k que j'ai piqué sur son blog (il ne m'en voudra pas, puisque je l'embrasse sur la fesse droite et lui adresse mes remerciements les plus profonds du cœur et tout) ;
- sh_over.exe : version compilée du shellcode d'0vercl0k (avec MASM32) ;
- ...
Vous verrez les deux fichiers plus tard. Je sais, j'ai un peu gâté, mais tant pis.
(Cliquez sur les images pour les voir en grand)
On ouvre sh_over.exe avec ollydbg, et on va voir dans la mémoire.
On tombe sur ça :
J'ai grisé la zone intéressante, qui va nous permettre de voir les en-têtes du format PE. Double-cliquez sur cette zone. Déplacez-vous jusqu'à, ensuite, trouver ça :
Je peux maintenant expliquer où je veux en venir. Je souhaite faire un programme qui ouvre un exécutable, en extrait le contenu de la section qui contient le code, et qui affiche les opcodes - équivalents binaires des instructions en assembleur - en dur dans la console (on peut enregistrer le flux de sortie via l'opérateur > dans la ligne de commandes).
Pour ce faire, j'ai besoin d'élaborer un algorithme précis. Tout d'abord, connaître l'offset de notre en-tête PE (logique), trouver le nombre de sections présentes ainsi que la taille de l'en-tête optionnelle. Une fois que j'ai trouvé ces informations, je peux me déplacer dans le fichier à la fin de l'en-tête optionnelle pour trouver l'en-tête des options qui suivent (cf. capture d'écran).
Je peux aussi élaborer une structure C de l'en-tête d'une section (Pour info, ne maîtrisant pas l'API Win32, je ne me servirai pas de windows.h pour prendre la structure toute faite) :
typedef struct {
char name[8];
long VirtualSize,
VirtualAddress,
SizeOfRawData,
PointerToRawData,
PointerToRelocations,
PointerToLineNumbers;
short NumberOfRelocations,
NumberOfLineNumbers;
long Characteristics;
} Section_Pe;La section fait 40 octets ; multiple de 4, donc pas de problème de Data Structure Alignment. Le lien pointe sur un article de 5m0k3 qui évoque ce concept, et je vous le recommande car je n'irai pas plus loin. Il ne faut pas dériver du sujet.
Dans notre structure :
- il faudra vérifier que le membre Characteristics ait le flag "Je contiens du code" actif ; si ce n'est pas le cas, on saute à la section suivante (si y'en a plusieurs) ;
- dès qu'on aura la section qui nous intéresse, on se déplacera en dur dans le fichier à l'aide du membre PointerToRawData ;
- On lira les opcodes via une boucle for() qui s'arrêtera jusqu'à SizeOfRawData.
PointerToRawData contient 200. Voyons voir...
J'en mets mon zizi à couper qu'il s'agit de notre section qui contient le code exécutable !
Vraiment bien foutue et utile, cette en-tête de section. Au fait, j'aurais pu faire un algorithme qui trouve la section ".text", mais la section de code ne s'appelle pas tout le temps comme ça ; c'est, certes, une convention, mais les compilateur Borland nomment cette section "CODE". Et puis, elles ont le nom qu'elles veulent.
Au final, j'élabore un code (que je commente au max) qui va dumper la section code de notre exécutable pour ensuite se servir des opcodes en tant que shellcode, et j'en passe. Ce fut une bonne expérience pour moi afin de comprendre davantage le PE.
Voici le code :
#include <stdio.h>
#include <stdlib.h>
#define OFFSET_E_LFANEW 0x3C // Offset absolu contenant l'offset d'en-tête PE
#define MOTMAGIQUE 0x00004550 // Mot magique de l'en-tête PE ('PE#0#0')
#define CONTAINS_CODE 0x020 // Flag qui vérifie si la section PE contient du code
// Structure représentant l'en-tête d'une section PE
typedef struct {
char name[8];
long VirtualSize,
VirtualAddress,
SizeOfRawData,
PointerToRawData,
PointerToRelocations,
PointerToLineNumbers;
short NumberOfRelocations,
NumberOfLineNumbers;
long Characteristics;
} Section_Pe;
int main(int argc, char **argv) {
// Il faut inciter à fournir les arguments en ligne de commande
if(argc < 2) {
printf("Utilisation : %s\n", argv[0]);
exit(EXIT_FAILURE);
}
long MagicWord, // Mot magique pour vérifier qu'il s'agit bien d'un PE
OffsetPeHeader; // L'offset du header PE
short NumberOfSections, // Nombre de sections
SizeOptionalHeader; // taille header optionnel
FILE *fe; // Pointeur de fichier
// On essaie d'ouvrir le fichier exécutable
if((fe = fopen(argv[1],"rb")) == NULL) {
printf("Erreur lors de l'ouverture de %s !\n",argv[1]);
exit(EXIT_FAILURE);
}
// On se déplace a l'offset (à partir du début) qui contient lui-même
// l'offset de la signature PE, puis on a lit
fseek(fe, OFFSET_E_LFANEW, SEEK_SET);
fread(&OffsetPeHeader, 1, sizeof(long), fe);
// On s'y déplace
fseek(fe, OffsetPeHeader, SEEK_SET);
// On lit le mot magique et on vérifie sa conformité
fread(&MagicWord, 1, sizeof(long), fe);
if(MagicWord != MOTMAGIQUE) {
printf("Ce fichier n'est pas un PE.\n");
exit(EXIT_FAILURE);
}
// On se déplace pour trouver le nombre de sections (toujours à partir du début)
// Le + 2 sert à sauter par dessus le mot magique & le nombre représentant l'architecture système
// qui ne nous intéresse pas.
fseek(fe, 2, SEEK_CUR);
// On lit le nombre de sections
fread(&NumberOfSections, 1, sizeof(short), fe);
// On s'occupe ensuite de savoir s'il y a une en-tête optionnelle
// en récupérant sa taille. Si != 0, alors elle existe.
// On saute le timestamp (+4), L'adresse pointant
// vers la table des symboles (+4) et le nombre des symboles (+4)
// = 12 octets
fseek(fe, 12, SEEK_CUR);
// On lit la taille de l'header optionnel
fread(&SizeOptionalHeader, 1, sizeof(short), fe);
// Et on se déplace jusqu'aux en-têtes de sections
// (ou jusqu'à l'en-tête section, s'il n'y en a qu'une)
// après avoir sauté les caractéristiques (+2)
fseek(fe, 2 + SizeOptionalHeader, SEEK_CUR);
// On lit la première section
Section_Pe SectionActuelle;
fread(&SectionActuelle, 1, sizeof(Section_Pe), fe);
// Tant que la section lue ne contient pas du code, on cherche la bonne
while(!(SectionActuelle.Characteristics & CONTAINS_CODE)) {
fread(&SectionActuelle, 1, sizeof(Section_Pe), fe);
}
// On a notre section exécutable. On affiche ses informations
printf("Name = %s\n"
"VirtualSize = 0x%x (%d.)\n"
"VirtualAddress = %d\n"
"SizeOfRawData = 0x%x (%d.)\n"
"PointerToRawData = 0x%x\n\n",
SectionActuelle.name, SectionActuelle.VirtualSize, SectionActuelle.VirtualSize,
SectionActuelle.VirtualAddress,SectionActuelle.SizeOfRawData, SectionActuelle.SizeOfRawData,
SectionActuelle.PointerToRawData);
// On s'y positionne
fseek(fe, SectionActuelle.PointerToRawData, SEEK_SET);
// On lit les octets (opcodes) et on les affiche sous la forme \xXX
int i; // compteur de boucle
unsigned char opcode; // opcode lu
for(i = 0; i < SectionActuelle.VirtualSize; i++) {
fread(&opcode, 1, sizeof(char), fe);
printf("\\x%02X", opcode);
}
printf("\n");
fclose(fe);
return EXIT_SUCCESS;
}
Source disponible ici : http://venom630.free.fr/geo/blog/pratique_pe/shellcodeme_c.txt - Exécutable disponible ici : http://venom630.free.fr/geo/blog/pratique_pe/shellcodeme.exe
C:\Pratique_format_PE>shellcodeme sh_over.exe
Name = .text
VirtualSize = 0x3b (59.)
VirtualAddress = 4096
SizeOfRawData = 0x200 (512.)
PointerToRawData = 0x200
\x33\xDB\x33\xC0\x66\xB8\x6C\x6C\x50\x68\x33\x32\x2E\x64\x68\x75\x73\x65\x72\xBF
\x77\x1D\x80\x7C\x54\xFF\xD7\x53\x68\x63\x6C\x30\x6B\x68\x30\x76\x65\x72\x8B\xCC
\x53\x51\x51\x53\xBF\x0B\x05\xD5\x77\xFF\xD7\x53\xBF\xA2\xCA\x81\x7C\xFF\xD7
Name = .text
VirtualSize = 0x3b (59.)
VirtualAddress = 4096
SizeOfRawData = 0x200 (512.)
PointerToRawData = 0x200
\x33\xDB\x33\xC0\x66\xB8\x6C\x6C\x50\x68\x33\x32\x2E\x64\x68\x75\x73\x65\x72\xBF
\x77\x1D\x80\x7C\x54\xFF\xD7\x53\x68\x63\x6C\x30\x6B\x68\x30\x76\x65\x72\x8B\xCC
\x53\x51\x51\x53\xBF\x0B\x05\xD5\x77\xFF\xD7\x53\xBF\xA2\xCA\x81\x7C\xFF\xD7
Conclusion
Pff... Que dire ? Que ça m'a occupé deux bonnes heures pour éviter les pensées négatives ? Je sais pas. On a qu'à dire que je trace mon évolution.
Par ailleurs, j'aspire à penser qu'il existe sûrement des outils qui se chargent de faire ça ; Heurs et Squallsurf en ont peut-être codé un semblable que j'ai pas réussi à faire marcher, mais je viens de comprendre pourquoi ils disaient que le code C ne devaient pas comporter d'appels à des fonctions extérieures. Effectivement, en assembleur, cela se traduit par des CALL. Et les fonctions se trouvent peut-être ailleurs... M'enfin, je préfère m'abstenir de dire des conneries, d'où le "peut-être".
C'est tout. J'espère continuer sur cette lancée, et merci aux soutiens, ça fait véritablement plaisir.
Je vous laisse, j'ai des devoirs à faire. Merde.
