Bonjour à tous! Dans le cadre du lancement du cours «Reverse Engineering», nous avons organisé une leçon ouverte prévue. Il a démonté l'algorithme d'opération de démarrage à différentes étapes de son chargement.
Conférencier -
Arthur Pakulov , analyste de virus chez Kaspersky Lab.
L'article suivant est une introduction et est une version texte d'une partie seulement de la leçon, qui est consacrée au programme d'installation de bootkit. Une analyse détaillée du bootkit lui-même, voir la vidéo. Un bootkit est un programme malveillant qui modifie le Master Boot Record, le premier secteur du premier disque physique ou secteur de démarrage, VBR. Les programmes de ce type ont fondamentalement une fonctionnalité de cheval de Troie et sont utilisés pour effectuer toutes les actions cachées dans le système. Dans notre exemple, le bootkit effectue une élévation de privilèges au niveau du processus, dont le nom commence par une séquence de lettres: «inte». En fait, un bootkit est un rootkit qui commence à fonctionner dans l'anneau de protection 0, qui démarre même avant le chargement du système d'exploitation. C'est pour cette raison qu'il présente un grand intérêt pour la recherche.
Pour développer un tel programme, les compétences habituelles en reverse engineering ne suffisent pas. Il ne suffit pas simplement de pouvoir lire la liste, vous devez également comprendre des éléments tels que l'architecture du processeur, l'adressage de la mémoire, etc. Nous avons examiné les endroits clés du kit de démarrage dans une leçon ouverte.
Pour le travail, un exemple spécial bootkit-xp.exe a été préparé, fonctionnant sous Windows XP. Par conséquent, en plus d'étudier le bootkit, nous étions un peu nostalgiques de ce système d'exploitation. Mais en général, l'OS XP a été choisi afin de faciliter la marche arrière, car XP est une bonne visualisation et l'absence de complications inutiles. Eh bien, l'exemple a été écrit spécifiquement pour cet OS, à en juger par son code.
Voici à
quoi ressemble le programme d'installation du bootkit :
En le regardant, vous pouvez tirer certaines conclusions. Par exemple, il est immédiatement évident que ce fichier a un petit poids. Si vous regardez le point d'entrée, vous pouvez voir que le code reçoit un descripteur de fichier avec le nom d'un lien symbolique vers le premier disque physique - "PhysicalDrive0":
De plus, pour faciliter la perception du code, nous sommes
passés à l'IDA . Il devient clair que pour un cheval de Troie typique, la fonctionnalité disponible est assez petite. Même la table d'importation est étrangement petite:
Une telle image émerge généralement lors de l'analyse d'échantillons emballés. Mais, dans notre cas, le fichier ne semble pas emballé. Il s'avère que l'échantillon est soit couvert par un protecteur / crypteur et, au cours de son travail, reçoit les adresses des fonctions de manière dynamique, après quoi il appelle la fonction souhaitée, ou tout va bien, et l'échantillon est tel qu'il est.
Nous continuons à explorer le code.
Comme nous l'avons vu dans HIEW, la fonction
CreateFileA est appelée avec un argument intéressant comme premier paramètre. Que fait-on exactement ici? Ici, il convient de rappeler une chose telle que
les objets du noyau . Ils ne peuvent pas être manipulés directement depuis le mode utilisateur, ils sont contrôlés par le noyau du système d'exploitation. Depuis le mode utilisateur, un programme ne peut faire qu'une demande pour recevoir / changer l'état de n'importe quel objet noyau. Pour indiquer au système avec quel objet noyau particulier le programme fonctionnera, il est nécessaire d'obtenir le descripteur de l'objet noyau requis. Sur demande de réception, si tous les contrôles sont réussis, le système d'exploitation nous renverra la
poignée de l' OA demandé. Et déjà en utilisant handle, nous pouvons travailler avec l'OA associé.
Ainsi, dans l'image ci-dessus, à l'aide de CreateFile, un lien symbolique est accédé au premier disque dur physique connecté. Si l'accès est accordé, vous pouvez travailler avec un tel «fichier» comme avec tout autre fichier simple. Autrement dit, l'intégralité du disque dur sera présenté comme un seul gros fichier.
Alors continuons. La poignée est de retour, et on se retrouve ici:
Que se passe-t-il ensuite? Et puis la fonction
ReadFile lit les premiers octets 0x200. Et nous avons là le tout premier secteur du premier disque physique.
Comme vous l'avez peut-être deviné, il s'agit du
Master Boot Record (MBR). MBR se compose de 3 parties: partie de code, table de partition et signature. Dans une situation normale, le BIOS lit le MBR en mémoire à l'adresse 0: 0x7c00h, en lui passant le contrôle. Ainsi, la partie code du MBR commence à s'exécuter. Pendant l'exécution, il analyse la table de partition, trouve le secteur de démarrage et le charge. Dans le cas d'un bootkit, si le MBR est écrasé, son code recevra désormais le contrôle.
Ok, MBR est lu, et
quelle est la prochaine étape ? Et puis le bootkit ouvre à nouveau PhysicalDrive0, mais avec le mode d'accès en écriture.
Ensuite, un pointeur est placé au 600ème décalage. Autrement dit, le
secteur d'origine est lu et copié dans le troisième secteur .
Pourquoi sauvegarder un secteur? De toute évidence, cela est nécessaire car il sera nécessaire à l'avenir.
Ensuite, le cycle commence. Naturellement, en regardant le code, on ne peut que faire attention aux constantes comme var_1C,
1BEh et autres. Et, en même temps, la structure MBR située ci-dessus doit être actualisée en mémoire. En particulier, nous nous intéressons à la colonne «Offset».
Voir, le tampon de lecture du premier secteur est dans
lpBuffer . Ensuite,
1BEh lui est ajouté. En fait, le pointeur va au début de la table de partition. Toutes les données de la table jusqu'à la fin du secteur sont insérées dans
_marked_bytes , à partir du même décalage - 1BE.
Autrement dit, les deuxième et troisième parties du MBR d'origine sont insérées dans
_marked_bytes .
Que se passe-t-il ensuite? Et
puis SetFilePointer place le pointeur sur le tout début de notre «fichier», c'est-à-dire sur le MBR.
Ensuite, il y a une écriture (WriteFile) formée de
_marked_bytes et libérant de la mémoire. Sur ce, la fonctionnalité du programme d'installation de bootkit se termine.
Mais ce serait bien de
voir ce qui se trouve
exactement dans la première partie de
_marked_bytes . Pour ce faire, videz-le sur le disque et analysez-le. La première chose qui attire votre attention est une diminution de 2 du contenu de la variable à l'adresse 0x413.
Si vous consultez la documentation technique, vous pouvez constater que la variable à 0X413 contient la quantité de mémoire physique installée en kilo-octets. En conséquence, le code de bootkit "coupe" deux kilo-octets de mémoire:
Maintenant, pour ne pas aller plus loin, on considérera qu'il y a 2 kilo-octets de mémoire en moins. Pourquoi - n'est pas encore clair.
Ensuite, l' adresse physique
est calculée sur la pièce de mémoire «bit off» en utilisant un décalage à gauche de 6 bits:
Un décalage de 6 effectue deux actions à la fois - convertit les kilo-octets en octets (multipliant la valeur de la variable par 2 ^ 10), obtenant ainsi l'adresse physique de la mémoire mordue et en extrayant le numéro de segment, en divisant le résultat par 0x10 (2 ^ 4).
Après cela, votre corps sera copié sur ce morceau de mémoire, et, puisque le code du bootkit est dans le morceau "bit off",
personne ne le dérangera plus . De plus, aucune interruption ne changera ce qui est écrit dans cette zone mémoire. On peut dire que le
code devient pratiquement invisible pour le système , comme s'il n'y avait pas de mémoire là-bas.
Ce n'est que le début du bootkit. Ensuite, il y aura l'interception d'interruption, le suivi des signatures ntldr, la modification du module du noyau du système d'exploitation, etc.
Par conséquent, nous ne le gâcherons pas, il vaut mieux
regarder le webinaire jusqu'au bout pour ne rien manquer.