Etude d un Loader Tout en Memoire pour Packer.pdf

(474 KB) Pobierz
Étude d’un Loader Tout en Mémoire pour
Packer
par
Homeostasie (Nicolas.D)
15/06/2012
(trashomeo (at) gmail (dot) com)
Étude d'un Loader Tout en Mémoire pour Packer
Tables des matières
1.Introduction..............................................................................................................................3
2.Un loader tout en mémoire.......................................................................................................4
2.1.Principe de fonctionnement.............................................................................................. 4
2.2.Description comportementale........................................................................................... 5
2.2.1.Recopie du loader en mémoire...................................................................................5
2.2.2.Copie en mémoire de l’exécutable.............................................................................8
3.Analyse du loader tout en mémoire ...................................................................................... 13
3.1.L’évolution des entêtes PE..............................................................................................13
3.2.L’évolution des modules chargés....................................................................................14
3.3.L’évolution des ressources..............................................................................................15
4.Quelques mots avant de conclure...........................................................................................16
5.Conclusion............................................................................................................................. 16
6.Références..............................................................................................................................17
Tables des illustrations
Figure 1: Diagramme de séquences – Comportement du loader................................................5
Figure 2: Diagramme de séquences - Recopie du loader en mémoire........................................8
Figure 3: Table des sections d'un exécutable..............................................................................9
Figure 4: Diagramme de séquences - Chargement de l'exécutable en mémoire.......................11
Figure 5: Entête PE de MyPELoader (droite) et Netcat (gauche).............................................13
Figure 6: Entête PE de MyPELoader après chargement de Netcat en mémoire.......................13
Figure 7: Liste des DLLs avant chargement de Netcat.............................................................14
Figure 8: Liste des DLLs après chargement de Netcat.............................................................14
Figure 9: Liste des Handles avant exécution de Netcat............................................................15
Figure 10: Liste des Handles après exécution de Netcat...........................................................15
-2/17-
Étude d'un Loader Tout en Mémoire pour Packer
1. Introduction
Pouvoir exécuter un programme sans être détecté par un antivirus est un des enjeux
primordiaux des développeurs de logiciels malveillants. D'un autre côté, les
pentesteurs apprécieront, après avoir obtenu un accès sur une machine, pouvoir
utiliser des outils normalement détectés par les antivirus et ainsi faciliter la prise de
contrôle et la recherche d’informations. Cet article étudie une conception d'un loader
tout en mémoire pour packer du point de vue d’un développeur afin de rendre un
exécutable Windows indétectable une fois chargé dans la mémoire du loader.
Je précise que cet article est écrit dans un but essentiellement éducatif et informatif
et n'engage en aucun cas ma responsabilité quant à l'usage que vous en feriez.
-3/17-
Étude d'un Loader Tout en Mémoire pour Packer
2. Un loader tout en mémoire
2.1.
Principe de fonctionnement
Ce loader « fait-maison » a pour but de charger dans son espace mémoire un
exécutable et de lui donner la main. De ce fait, le loader Windows ne sera pas
sollicité.
Pour arriver à ces fins, le loader devra se recopier lui-même dans un emplacement
libre de sa mémoire virtuelle pour éviter tout éventuel écrasement avec le
programme à charger. En effet, il est très envisageable que l’image de base soit
identique au deux ou que les tailles de sections fassent que finalement l’une empiète
sur l’autre.
Une fois la recopie du loader effectué, celui-ci réalise un saut sur le point d'entrée de
son propre code mais au nouvel emplacement mémoire. Nous verrons plus tard que
le loader devra au préalable s’auto-patcher pour corriger les instructions
assembleurs faisant appel à un adressage absolu.
Ensuite, le loader nouvellement recopié effectuera le chargement de l'exécutable
souhaité. Pour réaliser ceci, il devra:
Parcourir les différents champs du fichier PE à charger pour allouer les
différentes sections
Mapper les DLLs requises
Construire l’IAT (« Import Address Table »)
Fournir finalement l’exécution au programme injecté dans sa propre mémoire
Afin de résumer le comportement général de ce loader, ci-dessous un diagramme de
séquences :
-4/17-
Étude d'un Loader Tout en Mémoire pour Packer
Figure 1: Diagramme de séquences – Comportement du loader
2.2.
Description comportementale
2.2.1. Recopie du loader en mémoire
Avant de charger le programme souhaité dans son espace mémoire, le loader devra
être capable de se recopier lui-même dans un autre espace de sa propre mémoire
virtuelle et de déterminer si cette action a déjà été effectuée. Pour effectuer son
chargement, le loader viendra lire son propre fichier exécutable pour récupérer les
valeurs contenues dans les différents champs PE [1] comme la base de l’image, la
base et la taille des sections « code » et « data », le point d’entrée etc...
Afin de vérifier si sa propre recopie est effective, le loader s’appuie sur l’utilisation
d’un objet nommé, ici l’utilisation d’une mutuelle exclusion (mutex) [2]. D'autres
moyens plus ou moins discrets auraient pu être utilisé.
Dans un premier temps, le loader tente d’ouvrir la mutex nommée. Si l’appel échoue,
cela signifie que la mutex n’a pas encore été crée et que le loader ne s'est donc pas
recopié.
Un exemple de code d’utilisation est présenté ci-dessous:
-5/17-
Zgłoś jeśli naruszono regulamin