Exécution du mode de débogage du noyau Windows 7. Débogage hardcore avec Linice : apprendre à travailler dans le débogueur du noyau de la console. Symboles pour le débogage du noyau
Introduction
1. Types de débogueurs Windows
2. Débogueurs en mode utilisateur
3. Débogueurs en mode noyau
3.1 Débogueur WDEB386
3.2 Débogueur I386KD
3.3 Gagner le débogueur DBG
3.4 Débogueur SoftICE
4. Problème général de débogage
5. Lancez automatiquement les applications dans le débogueur
5.1 Raccourcis d'interruption
Conclusion
Littérature
Introduction
Apprendre le fonctionnement des outils logiciels est la partie la plus difficile du processus de débogage. Ce n'est qu'en comprenant les capacités et les limites des outils que vous pourrez en tirer le meilleur parti et passer moins de temps au débogage. En général, les débogueurs sont extrêmement utiles, mais peuvent conduire à des problèmes assez subtils qui conduisent le programmeur dans une impasse. Ce chapitre montre ce qu'est un débogueur et comment les différents débogueurs fonctionnent sur les systèmes d'exploitation Win32 (les systèmes d'exploitation Windows 32 bits de Microsoft).
Dans le même temps, nous nous concentrerons sur les propriétés spéciales des débogueurs en général qui sont activées lorsqu'un processus logiciel s'exécute sous le contrôle de ce dernier. Il explique également comment améliorer certaines fonctionnalités des systèmes d'exploitation Windows 32 bits pour faciliter le débogage. Deux débogueurs propriétaires seront présentés, dont le code source se trouve sur le CD qui l'accompagne. Le premier (MinDBG) possède des capacités suffisantes pour être appelé débogueur. Le second (WDBG) est un exemple de débogueur Microsoft Windows qui fait presque tout ce qu'un véritable débogueur système fait, y compris la manipulation des tables de symboles, la gestion des points d'arrêt, la génération de code de désassembleur et la coordination avec une interface utilisateur graphique (GUI). Dans notre discussion sur WDBG, nous montrerons comment fonctionnent les points d'arrêt et discuterons de ce que sont les différents fichiers de symboles.
Avant de passer au sujet principal de ce chapitre, définissons deux termes standards qui seront fréquemment utilisés dans ce livre : débogueur principal (ou de base) (débogueur) et débogueur subordonné (débuggé). En termes simples, un débogueur maître est un processus qui peut déboguer et contrôler un autre processus, et un débogueur esclave est un processus qui s'exécute sous le débogueur maître. Sur certains systèmes d'exploitation, le débogueur principal est appelé processus parent et le débogueur esclave est appelé processus enfant.
Un débogueur (debugger, débogueur anglais de bug) est un programme informatique conçu pour rechercher des erreurs dans d'autres programmes, noyaux de système d'exploitation, requêtes SQL et autres types de code. Le débogueur vous permet de tracer, surveiller, définir ou modifier les valeurs des variables pendant l'exécution du code, définir et supprimer des points d'arrêt ou des conditions d'arrêt, et bien plus encore.
La plupart des développeurs sont plus familiers avec les débogueurs en mode utilisateur. Sans surprise, les débogueurs de ce mode sont conçus pour déboguer les applications en mode utilisateur. Un excellent exemple de débogueur en mode utilisateur est le débogueur Microsoft Visual C++. Les débogueurs en mode noyau, comme leur nom l'indique, sont des débogueurs qui permettent de déboguer le noyau du système d'exploitation. Ils sont principalement utilisés par ceux qui écrivent (et déboguent, bien sûr) les pilotes de périphériques.
2. Débogueurs en mode utilisateur
Les débogueurs en mode utilisateur sont conçus pour déboguer toute application exécutée en mode utilisateur, y compris les programmes GUI, ainsi que les applications inhabituelles telles que les services Windows 2000. En général, ce type de débogueur prend en charge une interface utilisateur graphique (GUI1). La principale caractéristique de ces débogueurs est qu'ils utilisent l'interface de programmation d'applications de débogage Win32 (API de débogage). Étant donné que le système d'exploitation marque un débogueur esclave comme « s'exécutant en mode spécial », vous pouvez utiliser la fonction API IsDebuggerPresent pour savoir si votre processus s'exécute sous un débogueur.
Lors de la fourniture de l'API de débogage Win32, la convention suivante est implicite : une fois qu'un processus s'exécute sous l'API de débogage (et en fait ainsi un processus esclave), le débogueur principal ne peut pas se détacher de ce processus. Cette relation symbiotique signifie que si le débogueur maître se ferme, le débogueur esclave se ferme également. Le débogueur maître se limite au débogage uniquement du débogueur esclave et de tous les processus qu'il génère (si le débogueur maître prend en charge les processus enfants).
GUI - Interface utilisateur graphique. - Par.
Pour les langages interprétés et les systèmes d'exécution qui utilisent l'approche des machines virtuelles, les machines virtuelles elles-mêmes fournissent l'environnement de débogage complet et n'utilisent pas l'API de débogage Win32. Quelques exemples de ces types d'environnements sont les machines virtuelles (JVM) Microsoft ou Sun Java, l'environnement de script d'application Web Microsoft et l'interpréteur de code p Microsoft Visual Basic.
système d'exploitation du noyau du débogueur
Nous aborderons le débogage dans Visual Basic au chapitre 7, mais sachez que l'interface p-code de Visual Basic n'est pas documentée. Nous n'entrerons pas dans les détails de Java et des interfaces de débogage de scripts ; ces sujets dépassent le cadre de ce livre. Pour plus d'informations sur le débogage et le profilage de la JVM Microsoft, consultez Débogage et profilage des applications Java sur MSDN. L'ensemble de ces interfaces est très riche et varié et permet de contrôler totalement le fonctionnement de la JVM. Pour plus d'informations sur l'écriture d'un débogueur de script, consultez la rubrique MSDN « Objets API de débogage de script actif ». Comme la JVM, les objets du débogueur de script fournissent une interface riche pour l'accès aux scripts et la documentation.
Un nombre surprenant de programmes utilisent l'API de débogage Win32. Ceux-ci incluent : le débogueur Visual C++, qui est traité en détail dans les chapitres 5 et 6 ; le débogueur Windows (WinDBG), abordé dans la section suivante (sur le débogueur en mode noyau) ; Programme BoundsChecker de Compuware NuMega ; Programme HeapWalker du SDK de plate-forme ; SDK de plate-forme Dépend du programme ; Débogueurs Borland Delphi et C++ Builder, ainsi que NT Symbolic Debugger (NTSD). Je suis sûr qu'il y en a beaucoup d'autres.
3. Débogueurs en mode noyau
Les débogueurs en mode noyau se situent entre le processeur et le système d'exploitation. Cela signifie que lorsque vous arrêtez le débogueur en mode noyau, le système d'exploitation s'arrête également complètement. Il est facile de voir qu'arrêter brutalement le système d'exploitation est utile lorsque vous travaillez sur des minuteries et des problèmes de timing. Cependant, à l'exception d'un débogueur, qui sera abordé ci-dessous (dans la section « Débogueur SoftlCE » de ce chapitre), vous ne pouvez pas déboguer du code en mode utilisateur à l'aide de débogueurs en mode noyau.
Il n'existe pas beaucoup de débogueurs en mode noyau. En voici quelques-uns : Débogueur Windows 80386 (WDEB386), Débogueur du noyau (1386KD), WinDBG et SoftlCE. Chacun de ces débogueurs est brièvement décrit dans les sections suivantes.
3.1 Débogueur WDEB386
WDEB386 est un débogueur en mode noyau Windows 98 distribué dans le cadre du SDK Platform. Ce débogueur n'est utile que pour les développeurs qui écrivent des pilotes de périphériques virtuels Windows 98 (VxD). Comme la plupart des débogueurs en mode noyau pour les systèmes d'exploitation Windows, le débogueur WDEB386 nécessite deux machines et un câble null modem pour fonctionner. Deux machines sont nécessaires car la partie du débogueur qui s'exécute sur la machine cible a un accès limité à son matériel, elle envoie donc sa sortie et reçoit des commandes de l'autre machine.
Le débogueur WDEB386 a une histoire intéressante. Il a commencé comme un outil d'arrière-plan interne pour Microsoft à l'époque de Windows 3.0. Il était difficile à utiliser et manquait de prise en charge suffisante pour le débogage du code source et d'autres fonctionnalités intéressantes avec lesquelles les débogueurs Visual C++ et Visual Basic nous avaient gâtés.
Les commandes Dot (DOT) sont la fonctionnalité la plus importante du WDEB386. Grâce à l'interruption INT 41, le WDEB386 peut être étendu pour ajouter des commandes. Cette extensibilité permet aux auteurs de pilotes VxD de créer des commandes de débogage personnalisées qui leur permettent d'accéder facilement aux informations de leurs périphériques virtuels. La version de débogage de Windows 98 prend en charge de nombreuses commandes DOT qui vous permettent d'observer l'état exact du système d'exploitation à tout moment du processus de débogage.
3.2 Débogueur I386KD
Windows 2000 diffère de Windows 98 dans le sens où la partie active du débogueur en mode noyau est la partie NTOSKRNL. EXE - le fichier du noyau principal du système d'exploitation Windows 2000. Ce débogueur est disponible dans les configurations de système d'exploitation gratuites (version) et testées (débogage). Pour activer le débogage en mode noyau, définissez l'option du chargeur de démarrage /DEBUG sur BOOT. INI et, en outre, l'option du chargeur de démarrage /DEBUGPORT, si vous devez définir le port de communication du débogueur en mode noyau sur une valeur autre que la valeur par défaut (COM1). I386KD fonctionne sur sa propre machine et communique avec la machine Windows 2000 via un câble null modem.
Débogueur en mode noyau NTOSKRNL. L'EXE fait juste assez pour contrôler le CPU afin que le système d'exploitation puisse être débogué. La plupart du travail de débogage - traitement des symboles, points d'arrêt étendus et désassemblage - est effectué du côté 1386KD. À une certaine époque, le kit de pilotes de périphérique (DDK) Windows NT 4 documentait le protocole utilisé dans le câble null modem. Cependant, Microsoft ne le documente plus.
La puissance du 1386KD est évidente lorsque vous examinez toutes les commandes qu'il propose pour accéder à l'état interne de Windows 2000. Connaître le fonctionnement des pilotes de périphériques dans Windows 2000 aidera un programmeur à surveiller la sortie de nombreuses commandes. Malgré toute sa puissance, i386KD n'est quasiment jamais utilisé car il s'agit d'une application console, très fastidieuse à utiliser pour le débogage de base.
3.3 Gagner le débogueur DBG
WinDBG est un débogueur fourni avec le SDK Platform. Vous pouvez également le télécharger depuis #"897008.files/image001.gif">
Figure 1. Résultat du programme GFLAGS. EXE
Inscription 4-1. Exemple de destruction du tas Windows 2000
vide principal (vide)
POIGNÉE hHeap = HeapCreate (0, 128, 0);
// Alloue de la mémoire pour un bloc de 10 octets.
LPVOID pMem = HeapAlloc (hHeap, 0,10);
// Écrit 12 octets dans un bloc de 10 octets (débordement de tas).
memset (pMem, OxAC,
// Alloue un nouveau bloc de 20 octets.
LPVOID pMem2 = HeapAlloc(hHeap, 0, 20);
// Écrivez 1 octet dans le deuxième bloc.
char * pUnder = (char *) ((DWORD) pMem2 - 1);
// Libère le premier bloc. Cet appel à HeapFree sera
// déclenche un point d'arrêt dans le code du tas de débogage
// système opérateur.
HeapFree(hHeap, 0, pMem);
// Libère le deuxième bloc. Notez que cet appel ne sera pas
// émet des messages d'erreur
HeapFree(hHeap, 0, pMem2);
// Libère le bloc factice. Notez que cet appel ne sera pas
// émet des messages d'erreur
Si vous cochez les mêmes cases que sur la Fig. 4.1 et répétez l'exécution de HEAPER. EXE, vous obtiendrez le résultat suivant, plus détaillé :
PAGEHEAP : le processus 0x490 a créé le tas de débogage 00430000
(drapeaux 0xl, 50, 25, 0, 0) : le processus 0x490 a créé le tas de débogage 00CF0000
(drapeaux Oxl, 50, 25, 0, - 0) : le processus 0x490 a créé le tas de débogage 01600000
(drapeaux Oxl, 50, 25, 0, 0) : corruption de remplissage de queue détectée : à 0x01606FF0size 0x0000000Asize 0x00000010at Ox01606FFA : tentative de référencement d'un bloc qui n'est pas alloué
Le contenu de la liste est expliqué par les noms des drapeaux définis par le panneau Global Flags.
Discussion sur le programme GFLAGS. EXE, je tiens à souligner une option très utile : Afficher les instantanés du chargeur. Si vous cochez cette case et exécutez l'application, vous verrez ce qu'on appelle un instantané de l'application, qui montre où Windows 2000 charge les fichiers DLL et comment il commence à organiser l'importation. Si vous avez besoin de voir exactement ce que fait le chargeur de démarrage de Windows 2000 lors du chargement d'une application (surtout s'il y a un problème), activer cette option peut être une étape très utile. Pour plus d'informations sur les instantanés du chargeur de démarrage, consultez la rubrique « Under the Hood » de Matt Pietrek dans le numéro de septembre 1999 du Microsoft Systems Journal.
5. Lancez automatiquement les applications dans le débogueur
Les types d'applications les plus difficiles à déboguer sont celles qui sont lancées par un autre processus. Les services Windows 2000 et les serveurs COM hors processus entrent dans cette catégorie. Pour forcer un débogueur à s'attacher à un processus, vous pouvez utiliser la fonction API DebugBreak dans de nombreux cas. Toutefois, dans deux cas, cette fonction ne fonctionnera pas. Premièrement, cela ne fonctionne parfois pas avec les services Windows 2000. Si vous devez déboguer le démarrage d'un service, l'appel de DebugBreak attachera le débogueur, mais au moment où le débogueur démarre, le délai d'attente du service peut être dépassé et Windows 2000 s'arrêtera. il. Deuxièmement, DebugBreak ne fonctionnera pas lorsque vous devrez déboguer un serveur COM hors processus. Si vous appelez DebugBreak, le gestionnaire d'erreurs COM interceptera l'exception de point d'arrêt et mettra fin au serveur COM. Heureusement, Windows 2000 vous permet de spécifier que l'application doit démarrer dans le débogueur. Cette propriété vous permet de démarrer le débogage dès la première instruction. Toutefois, avant d'activer cette propriété pour un service Windows 2000, assurez-vous que le service est configuré pour communiquer avec le bureau Windows 2000.
La propriété Exécuter avec le débogueur peut être activée de deux manières. Le plus simple consiste à exécuter l'utilitaire GFLAGS. EXE et sélectionnez le bouton radio ImageDéposer Possibilités(voir Fig. 4.1). Après avoir entré dans le champ modifiable, je magicienDéposerNom case à cocher du nom du fichier binaire du programme Débogueur dans le groupe Image DébogueurPossibilités) et entrez le chemin complet du débogueur dans le champ modifiable à côté de cette case à cocher.
Une manière plus difficile : vous devez définir manuellement les paramètres nécessaires dans les sections de registre appropriées (à l'aide de l'éditeur RegEdit). Sous_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NTXCurrent Version\Image Tile Execution Options
créez une sous-clé dont le nom est le même que le nom de fichier de votre application. Par exemple, si le nom de l'application est FOO. EXE, le nom de la sous-clé de registre est également FOO. EXE. Dans cette sous-clé, créez un nouveau paramètre de chaîne nommé Debugger. Dans la boîte de dialogue Modifier le paramètre de chaîne, tapez le nom de fichier complet (y compris le chemin du répertoire) du débogueur que vous avez sélectionné. Si vous avez spécifié GFLAGS. EXE et définissez certaines options globales, vous remarquerez la valeur de chaîne GiobaiFiag dans votre clé d'application.
Désormais, lorsque vous démarrez votre application, le débogueur est automatiquement chargé et lancé. Les options de ligne de commande pour le débogueur peuvent également être spécifiées dans le paramètre de chaîne du débogueur (après le nom du programme du débogueur). Par exemple, pour utiliser le débogueur WinDBG et lancer automatiquement le débogage dès le démarrage de WinDBG, vous devez saisir la valeur d:\platform sdk\bin\windbg dans la boîte de dialogue de modification du paramètre de chaîne du débogueur. exe-g.
5.1 Raccourcis d'interruption
Parfois, vous devez accéder rapidement au débogueur. Si vous déboguez des applications console, les frappes au clavier
Une fonctionnalité utile de Windows 2000 et de Windows NT 4 est la possibilité de passer au débogueur à tout moment, également dans les applications GUI. Lors de l'exécution sous le débogueur, en appuyant sur la touche
Sous Windows NT 4, le raccourci de la touche Arrêt
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AeDebug
Définissez le paramètre userDebuggerHotKey sur le code clé (VK_*). Par exemple, pour utiliser la clé
Conclusion
Nous avons examiné les fonctionnalités de base du débogage, ses types et types, la problématique générale du débogage, ainsi que les erreurs et comment les détecter.
Les débogueurs existants jouent un rôle important dans le développement de logiciels lors de la recherche d'erreurs logiques, en fournissant une large gamme d'outils, notamment la prise en charge du code source, le suivi de l'exécution des applications, la modification dynamique de la mémoire, etc. etc.
Littérature
1..aspx?.aspx?id=553022>
2. https://ru. wikipedia.org/wiki/%D0%9E%D1%82%D0%BB%D0%B0%D0%B4%D1%87%D0%B8%D0%BA
http://bourabaï. kz/alg/debug4. htm
4. Kostyukhin K. - DÉBOGAGE DES SYSTÈMES EN TEMPS RÉEL. Revoir
Il existe peu de débogueurs décents au niveau du noyau pour Windows, mais sous Linux, ils se comptent sur les doigts d'une main, et même ceux-ci sont pour la plupart rudimentaires, inachevés ou abandonnés et envahis par la mousse... Aujourd'hui, nous parlerons des plus populaires et le plus intéressant d'entre eux -
Linice.
Introduction
Comme son nom l'indique déjà, Linice est un « port » non officiel du légendaire
SoftICE pour Linux, qui a conservé l'interface, le système de commande et la plupart des capacités de ce dernier : pop-up utilisant un raccourci clavier (dans Linice Ce
Contrairement à la plupart des autres débogueurs, qui fonctionnent via le mécanisme de protection ptrace non réentrant et facilement détecté (dont l'analogue Windows est DEBUG_PROCESS, utilisé par les débogueurs d'applications), Linice utilise le traçage natif, le même que dans SoftICE, qui permet aux deux débogueurs de déboguer des programmes hautement sécurisés que d'autres ne peuvent pas gérer.
En fait, il ne s'agit pas du tout d'un portage (d'où les guillemets), mais d'un projet indépendant, écrit à partir de zéro et distribué gratuitement en code source (de SoftICE il n'y a que de l'inspiration). La partie principale du code destiné au noyau 2.4 a été écrite par le hacker allemand Goran Devic, mais des personnes complètement différentes ont été impliquées dans la maintenance du noyau 2.6 : Daniel Reznick, Peter K. et Carlos Manuel Duclos Vergara. Et notre compatriote - Oleg Khudakov - a réécrit les fichiers assembleur de nasm en
gcc.
Les textes sources sont sur le site officiel du projet -
Ligne%0A.com">www.Linice.com, il y a aussi de la documentation, une courte FAQ et un lien vers le forum
Ligne%0A">groups.google.com/group/Linice. Il n'existe pas d'assemblys binaires prêts à l'emploi.
Les créateurs du projet ont ouvert leur propre compte sur SourceForge, mais ont été trop paresseux pour y télécharger des fichiers, ne présentant que 3 captures d'écran de très mauvaise qualité :
.
Configuration système requise
Dernière version Linice est numéroté 2.6 et date du 28 juillet 2005, prenant entièrement en charge le noyau 2.4.x et le mode console VGA. Les noyaux les plus récents ont de sérieux problèmes et le noyau 2.6.x n'a qu'un support limité.
Le débogueur a été développé et testé sous Debian 2.6. Sa compatibilité avec d'autres distributions n'est pas garantie, ce qui nous oblige à recourir au tambourin, mais dans certains cas même le tambourin n'aide pas. En fait, gardez Debian sur votre machine juste pour travailler avec Linice, - c'est tout à fait normal. Il y a longtemps, alors qu'il n'existait pas encore d'implémentation de SoftICE pour NT, de nombreux pirates informatiques installaient Win 9x uniquement pour casser des programmes, alors qu'ils étaient eux-mêmes sous Windows.
N.T. Parce que pour couvrir toutes les subtilités de l'installation Linice dans le cadre d'un article c'est pratiquement impossible, je me limiterai à décrire le processus de compilation et de lancement Linice sous une distribution spécifique - Knoppix 3.7 avec noyau 2.4.1 en mode console VGA.
Linice prend en charge l'ACPI et les machines multiprocesseurs, mais ne fonctionne pas bien avec X, en particulier sur les cartes vidéo autres que nVidia. Il ne perçoit pas du tout la profondeur de couleur de 24 bits, « digérant » uniquement 8, 16 et 32 bits, c'est donc plus pratique. pour déboguer des applications X via un terminal distant connecté via un port COM utilisant le protocole VT100. Dans ce cas, le clavier local fonctionnera également avec.
Linice!
Compilation et configuration de Linice
Téléchargez l'archive gzip des textes sources www. Linice.devic.us/ Linice-2.6.tar.gz, qui prend un peu moins d'un mégaoctet, décompressez-le sur le disque, allez dans le répertoire ./docs et à partir du fichier readme, nous découvrons que le débogueur est construit pour le noyau 2.4 comme suit :
# construction de CD
# ./make_bin-2.4
# cd ../bin
# rendre propre ; faire e
Cependant, avant de lancer make, vous devez ouvrir le fichier ./bin-2.4/Makefile et éditer la ligne "TARGET" en fonction de la configuration et de l'architecture de la plateforme cible. En particulier, sur les machines ACPI équipées de processeurs multicœurs ou HyperThreading, cela ressemblera à ceci :
CIBLE = -DSMP -DIO_APIC
Une fois la compilation terminée, il y aura de nombreux fichiers et répertoires dans le répertoire ./bin, mais les seuls importants sont :
linsym – module de chargement du débogueur ;
linince.dat – fichier de configuration ;
xice – prise en charge des X, lorsque vous travaillez en mode texte, ils peuvent être supprimés ;
./Linice_2.4.27/Linice.o – un module de noyau chargeable contenant le débogueur lui-même.
|
Processus de construction Linice |
Après avoir assemblé un kit fonctionnant de manière minimale, ce serait bien d'avoir tout le reste - des exemples de débogage de démonstration situés dans le répertoire ./test et compilés avec le script de compilation, ainsi qu'un module d'extension (à notre avis, un plugin) situé dans le Répertoire ./ext, compilé par la commande make et chargé par la commande insmod. Cela n'apporte aucun avantage, mais après avoir étudié le code source, nous pouvons écrire nos propres modules qui étendent les fonctionnalités
Linice.
Lors du chargement de Knoppix, une invite "boot:" apparaît en bas de l'écran où vous devez saisir "knoppix 2 vga=normal". Le code de triche "knoppix" sélectionne le noyau 2.4 (automatiquement chargé par défaut, donc "knoppix"). peut être omis), " 2 " bloque le chargement des X " et " vga=normal " définit le mode vga standard avec une résolution de 80x25.
Après avoir attendu la fin du téléchargement, nous disons « su », puis « passwd » et entrons un nouveau mot de passe pour root "a, sous lequel nous nous connectons immédiatement au système à l'aide de la commande login. Si cela n'est pas fait, une tentative de commencer Linice se terminera par un échec cuisant au cri de « défaut de segmentation ».
Lorsque vous démarrez Knoppix depuis votre disque dur (sur lequel vous pouvez l'installer avec la commande « sudo knoppix-installer » tapée dans la fenêtre du terminal sous la session LiveCD), un menu démarrer apparaîtra avec une liste des noyaux disponibles. (2.4)-1 et cliquez sur
Le débogueur est lancé avec la commande ./linsym –i, après quoi il apparaît immédiatement à l'écran. Si cela ne se produit pas, essayez de spécifier le commutateur "--verbose 3" pour afficher les messages de diagnostic.
L'une des raisons de l'échec du démarrage peut être l'absence du fichier /boot/System.map contenant les adresses des fonctions du noyau. Le téléchargement échouera également si le contenu de System.map ne correspond pas au noyau actuel, ce qui peut arriver, par exemple, lors de sa recompilation. Certains compilateurs de distribution soit n'incluent pas du tout System.map (pensant que cela renforcera la sécurité du système, car il sera plus difficile pour les rootkits d'intercepter les appels système), soit ils placent ici quelque chose de complètement faux et on ne sait généralement pas où ça vient de. Dans de tels cas, il suffit simplement de recompiler le noyau, en pointant le débogueur vers le chemin d'accès au fichier System.map à l'aide du commutateur "-m", s'il se trouve ailleurs que /boot. De cette façon, la sécurité ne sera pas compromise et Linice peut fonctionner !
Le débogueur revient au système en
Le commutateur «-x», passé au même linsym, est responsable du déchargement du débogueur (si vous voulez vraiment le décharger).
Les bases du travail avec Linice
Pour ceux qui ont déjà travaillé avec SoftICE, maîtriser Linice ne posera aucun problème. Les mêmes commandes sont utilisées ici : D – vidage de la mémoire, E – édition de la mémoire, T – traçage pas à pas, P – traçage sans entrer de fonctions, R – visualisation/modification des registres, BPM/BPX – définition d'un point d'arrêt pour l'accès à la mémoire /exécution et etc. Une liste complète des commandes est contenue à la fois dans l'aide intégrée, appelée via HELP (d'ailleurs, « HELP command_name » fournit des informations supplémentaires sur la commande) et dans la documentation standard.
Cliquons
:PROC
1 0000 C1C3E000 SOMMEIL 0 0 initialisation
2 0000 F7EE8000 SOMMEIL 0 0 keventd
3 0000 F7EE2000 SOMMEIL 0 0 ksoftirqd_CPU0
4 0000 F7EE0000 SOMMEIL 0 0 ksoftirqd_CPU1
5 0000 F7ED0000 SOMMEIL 0 0 kswapd
6 0000 F7EAA000 SOMMEIL 0 0 bdflush
7 0000 F7EA8000 SOMMEIL 0 0 mis à jour
56 0000 F6A36000 DORMIR 0 0 kjournald
1006 0000 F7A34000 RUNNING 0 0 montage automatique
1013 0000 F68E6000 SOMMEIL 0 0 tassesd
...
1105 0000 F6DDE000 DORMIR 0 0 mc
1106 0000 F6DD4000 SOMMEIL 0 0 économiseur de cons.
Les processus sont bien sûr bons, mais comment pouvons-nous encore déboguer les programmes ? Le plus simple est d'insérer la commande machine CCh correspondant à l'instruction INT 03h dans le point d'entrée, après avoir préalablement noté le contenu de l'octet d'origine. Cela peut être fait avec n'importe quel éditeur hexadécimal, par exemple celui que j'ai mentionné plusieurs fois.
HTE.
Après avoir chargé le fichier dans l'éditeur, cliquez sur
CCh.
État du programme avec un point d'entrée corrigé au moment où le débogueur apparaît
0023:080482C0 CC int 3
0023:080482C1 ED dans eax, dx
0023:080482C2 5E pop esi
0023:080482C3 89E1 mouvement ecx, esp
Le curseur pointe sur l'instruction in eax,dx (EDh), qui est un fragment de l'instruction xor ebp,ebp (31h EDh) corrigée. Maintenant (en théorie), nous devrions restaurer l'octet d'origine en changeant CCh à 31h, réduire le registre EIP de un et continuer le traçage comme d'habitude.
Mais ce n’était pas le cas ! Linice- il s'agit bien sûr d'un portage, mais très rudimentaire, et il ne peut pas modifier la mémoire d'une image de page, même si vous ouvrez d'abord le segment de code en écriture. Ni E (modifier), ni F (remplir), ni M (copie en mémoire) ne fonctionnent ! Mais écrire dans la pile fonctionne, et c'est largement suffisant pour nous, les hackers.
On se souvient de la valeur actuelle du registre EIP ; copiez la commande de machine corrigée en haut de la pile ; restaurez-y l'octet CCh ; nous lui transférons le contrôle, en modifiant la valeur EIP ; nous le réalisons en effectuant un seul acte de traçage ; et remettez EIP à sa place, c'est-à-dire à la commande machine suivante :
Récupération de l'octet d'origine remplacé par l'instruction INT 03h
; Regardons ce qui se trouve au sommet de la pile (par pure curiosité).
:d esp-10
0018:BFFFEFC0 C0 82 04 08 00 00 00 00 5D 0C 00 40 DC EF FF BF
; Nous copions la commande machine corrigée en haut de la pile.
; Le nombre 10h est la taille maximale possible d’une instruction machine sur x86.
:m eip-1 L 10 esp-10
; Voyons comment la pile a changé.
:d esp-10
0018:BFFFEFC0 CC ED 5E 89 E1 83 E4 F0 50 54 52 68 F0 85 04 08
; Ouais! Le stack a vraiment changé, il est temps de fixer CCh à 31h.
:e esp-10 31
Modifier les données immédiates non encore implémentées.
; Oups ! L'affectation directe des données n'est pas implémentée dans Linice,
; mais nous pouvons éditer le dump de manière interactive (également
; comme dans SoftICE) ou donnez la commande F esp-10 L 1 31, gardez simplement à l'esprit que
; que contrairement à SoftICE, le débogueur Linice ne met pas à jour la fenêtre de dump,
; donc après avoir exécuté la commande F, il peut apparaître que
; aucun résultat ; en fait, ce n'est pas le cas, il suffit de mettre à jour
; dump avec la commande D esp-10, et tout se mettra en place.
; On transfère le contrôle à la commande copiée dans la pile,
; rappelez-vous la valeur du registre EIP.
:r eip (esp-10)
reg:eip=BFFFEFC0
; Nous effectuons un seul acte de traçage.
:t
0023:BFFFEFC2 5E pop esi
; Comme on peut le voir, le registre EIP a augmenté de 2 (BFFFEFC2h - BFFFEFC0h) = 02h,
; donc l'adresse de la commande suivante est : 080482C1h - 01h + 02h = 080482C2h,
; où 080482C1h est la valeur initiale d'EIP lors de l'entrée dans le programme, et 01h est la taille de INT 03h.
; Nous définissons EIP sur la commande suivant l'instruction corrigée.
:r eip 80482C2
reg:eip=80482C2
C’est le genre de danses avec un tambourin qu’il faut faire. Que pouvons-nous faire ? Nous avons donc réglé le chargement des programmes dans le débogueur, divisons maintenant les points d'arrêt en appels système et fonctions du noyau.
La commande exp imprime les noms exportés par le noyau, chacun pouvant apparaître dans des expressions, par exemple "bpx do_bkr" est équivalent à "bpx C012C9E8".
Liste des noms exportés par le noyau
:exp
noyau
C0320364 mmu_cr4_features
C02AC3A4 acpi_disabled
C02AC8A0 i8253_verrouillage
...
C012BDA8 do_mmap_pgoff
C012C764 do_munmap
C012C9E8 do_brk
C011E990 sortie_mm
C011E69C fichiers_exit
Les appels système sont plus difficiles. Soutien direct de Linice ce n'est pas ici (mais c'est censé l'être, étant donné les spécificités de Linux), donc cette chose doit être faite à la main.
La table syscall, comme vous le savez, est un tableau de mots doubles commençant à l'adresse sys_call_table (cette variable est exportée par le noyau).
Tableau des appels système
; Nous passons le débogueur en mode d'affichage double mot.
:jj
; Nous affichons le tableau à l'écran.
:d sys_call_table
0018 : C02AB6A8 C0126ACC F8932650 F89326A0 C013DC10
0018:C02AB6B8 C013DD18 C013D5C8 C013D724 C011F3BC
0018:C02AB6C8 C013D664 C014A8E0 C014A3B4 F893020C
Chaque élément du tableau correspond à son propre appel système, et chaque appel a son propre numéro, que l'on peut trouver en regardant dans le fichier /usr/include/sys/syscall.h, mais il vaut mieux ne pas le faire sous Linux , où il n'y a pas de numéros directs, mais pour emprunter le même fichier à BSD - tout de même, les numéros des principaux appels système sur tous les systèmes sont les mêmes. En particulier, l’appel système ouvert est le numéro 5.
Pour définir un point d'arrêt en ouverture, vous devez connaître son adresse, située dans le cinquième double mot de la table des appels système, en comptant à partir de zéro, et égale (dans ce cas) C013D5C8h.
Définition d'un point d'arrêt sur l'appel système ouvert
; Définir un point d'arrêt sur l'appel système ouvert,
:bpxC013D5C8
; quittez le débogueur,
:x
...
# ouvre un fichier,
...
; le débogueur apparaît immédiatement et nous en parle,
:Point d'arrêt dû à BPX 01
; Nous émettons la commande proc pour nous assurer que nous sommes coincés dans notre processus.
:proс
PID TSS État de la tâche UID Nom du gid
1049 0000 F6364000 DORMIR 0 0 getty
1145 0000 F61CC000 DORMIR 0 0 mc
1146 0000 F614A000 SOMMEIL 0 0 économiseur de cons.
De cette façon, il est facile de pirater des processus déjà en cours d'exécution, de définir des points d'arrêt sur les appels système qu'ils utilisent et de réaliser bien d'autres choses essentielles au piratage.
Conclusion
Malgré son humidité évidente, Linice est tout à fait approprié pour déboguer des applications protégées, même si vous devez souvent recourir à des solutions de contournement exécutées automatiquement dans les débogueurs normaux. C'est pourquoi Linice ne remplace pas du tout gdb, mais le complète seulement.
chPF OELPFPTSCHE KHLBBOYS RP TBVPFE U PFMBDLPK SDTB U BCHBTYKOSCHNY DBNRBNY RBNSFY. lBL RTBCHYMP, CHBN OHTSOP VKDEF ЪBDBFSH PDOP YЪ KHUFTPKUFCH RPDLBYULY, RETEYUYUMEOOSCHI CH ZHBKME /etc/fstab . uvtpu pvtbpch RBNSFY À PROPOS DE KHUFTPKUFCHB, OE SCHMSAEYEUS KHUFTPKUFCHBNY RPDLBYULY, OBRTYNET, MEOFSHCH, CH DBOOSCHK NPNEOF OE RPDDETSYCHBAFUS.
Note: yURPMSHKFE LPNBODH dépotoir (8) DMS KHLBBOYS SDTH NEUFB, ZDE OHTsOP UPITBOSFSH BCHBTYKOSH DBNRSHCH. rPUME OBUFTPKLY RP LPNBODE échange (8) TBDEMB RPDLBYULY DPMTSOB VSHFSH CHSHCHBOB RTPZTBNNNB dumpon . pVSHYUOP LFP CHSHRPMOSEPHUS ЪBDBOYEN RETENOOOPK dumpdev CH ZHBKME rc.conf (5). еUMY ЪБДБOB ьФБ RЭТЭНООБС, Ф РПУМЭ УВПС RTY RETCHPK NOPZPRPMSHЪPCHBFEMSHULPK RETEЪBZTHЪLE VHDEF BCHFPNBFYUEULY ЪBRHEEOOB RTPZTBNNNB sauvegarde (8). pOB UPITBOIF BCHBTYKOSHCHK DBNR SDTB CH LBFBMPZ, ЪBDBOOSCHK CH RETENEOOOPK dumpdir ZHBKMB rc.conf . rP KHNPMYUBOYA LBFBMPZPN DMS BCHBTYKOSCHI DBNRPCH SCHMSEFUS /var/crash .
myVP CHSC NPTSEFE ЪBDBFSH KHUFTPKUFCHP DMS UVTPUB PVTBB RBNSFY SCHOP YUETE RBTBNEFT dump CH UFTPLE config LPOZHYZHTBGYPOOPZP ZHBKMB CHBYEZP SDTB. fBLPK URPUPV YURPMSHЪPCHBFSH OE TELPNEODHEFUS Y PO DPMTSEO YURPMSHЪPCHBFSHUS, FPMSHLP EUMY CHSCH IPFYFE RPMKHYUBFSH BCHBTYKOSHCHE PVTBSCH RBNSFY SDTB, LPFPTPE BCHBTYKOP ЪBCHETYBEF UCHPA TBVPFH RTY ЪBZTHЪLE.
Note: dBMEE FETNYO gdb PYOBYUBEF PFMBDYUYL gdb , ЪBRHEEOOSCHK CH ``TETSINE PFMBDLY SDTB". RETEIPD CH LFPF TETSYN DPUFYZBEFUS ЪBRHULPN gdb U RBTBNEFTPN -k . h TETSYNE PFMBDLY SDTB gdb YЪNEOSEF UCHPЈ RTYZMBYEOYE À PROPOS (kgdb) .
Conseil: eUMY CHSH YURPMSH'HEFE FreeBSD CHETUYY 3 YMY VPMEE TBOOAA, CHCH DPMTSOSCH CHSHRPMOYFSH HUEYEOYE PFMBDPUOPZP SDTB LPNBODPK bande, B OE KHUFBOBCHMYCHBFSH VPMSHYPE PFMBDPUOPE SDTP :
# noyau cp noyau.debug # strip -g noyau
bFPF YBZ OE FBL KhTS Y OEPVIPDYN, OP TELPNEODKHEN. (PH FreeBSD 4th VPMEE TEMYYBI LFPF YBZ CHSHRPMOSEFUS BCHFPNBFYUEULY CH LPOGE RTPGEUUB RPUFTPEOOYS SDTB make .) lPZDB SDTP HUEYEOP, BCHFPNBFYUEULY YMY RT Y RPNPEY LPNBOD CHCHYE, CHCH NPTSEFE KHUFBOPCHYFSH EZP PVSHCHYUOSCHN PVTBBPN, OVTTBCH make install .
ъBNEFSHFE, YuFP CH UFBTSHCHETUISI FreeBSD (DP 3.1, OE CHLMAYUBS LFPF TEMY), YURPMSHHEFUS SDTB CH ZHTNBFE a.out, RPFPNH YI FBVMYGSCH UINCHPMPCH DPMTSOSCH TBURPMBZBFShu S RPUFPSOOP CH RBNSFY. u VPMSHYPK FBVMYGEK UYNCHPMPCH CH OE HUEOOOOPN PFMBDPUOPN SDTE LFP YЪMYYOSS FTBFB. rPUMEDOYE TEMYYSH FreeBSD YURPMSHHAF SDTB CH ZHTNBFE ELF, ZHE LFP OE SCHMSEFUS RTPVMENPK.
eUMY CHSH FEUFYTHEFE OPCHPE SDTP, ULBTSEN, OBVYTBS YNS OPCHPZP SDTB CH RTYZMBYYE OYBZTHYUYLB, OP CHBN OHTSOP ЪBZTHTSBFSH Y TBVPFBFSH U DTHZYN SDTPN, SC UOPCHB CHETOHFSHUS L OPTNBMSHOPNH ZHOLGYPOYTPCHBOYA, ЪBZTHTSBKFE EZP F PMSHLP CH PDOPRPMSHЪPCHBFEMSHULPN TETSYNE RTY RPNPEY ZHMBZB -s , KHLBSCCHBENPZP RTY ЪBZTH ЪLE, B ЪBFEN CHSHRPMOYFE FBLYE YBZY :
# fsck -p # mount -a -t ufs # pour que votre système de fichiers pour /var/crash soit accessible en écriture # savecore -N /kernel.panicked /var/crash # exit # ...vers multi-utilisateurs
bFB RPUMEDPCHBFEMSHOPUFSH KHLBSCCHBEF RTPZTBNNE sauvegarde (8)À PROPOS DE YURPMSHЪPCHBOYE DTHZPZP SDTB DMS YЪCHMEYUEOYS UYNCHPMYUEULYI YNEO. YOBYUE POB VKhDEF YURPMSHЪPCHBFSH SDTP, TBVPFBAEE CH DBOOSHK NPNEOF Y, ULPTEE CHUEZP, OYUEZP OE UDEMBEF, RPFPNH YuFP BCHBTYKOSHCHK PVTB RBNSFY YYNCHPMSCH SDTB F PFMYUBFSHUS.
b FERETSH, RPUME UVTPUB BCHBTYKOPZP DBNRB, RETEKDYFE CH LBFBMPZ /sys/compile/WHATEVER Y ЪBRKHUFYFE LPNBODH gdb -k . yЪ RTPZTBNNSH gdb UDEMBKFE CHPF SFP :
Fichier-symbole kernel.debug fichier-exécutable /var/crash/kernel.0 fichier-core /var/crash/vmcore.0 Y CHBMS - CHCH NPTSEFE PFMBTSYCHBFSH BCHBTYKOSHK DBNR, YURPMSHЪHS YUIPDOSCH FELUFSCH SDTB FPYuOP FBLCE, LBL CHSHCH LFP D EMBEFE AT MAVPC DTHZPK RTPZTBNNPK.
ChPF TsKHTOBM LPNBOD UEBOUB TBVPFSH gdb, YMMAUFTYTHAEIK bfh RTPGEDHTH. dMYOOSCH UFTPLY VSHMY TBPTCHBOSH DMS KHMHYUYEOYS YUYFBVEMSHOPUFY Y DMS KHDPVUFCHB UFTPLY VSHCHMY RTPOKHNETPCHBOSHCH. CHUE PUFBMSHOPE SCHMSEFUS FTBUUYTPCHLPK PYYVLY, TEBMSHOP CHPOYLOKHCHYEK PE CHTENS TBVPFSCH OBD DTBKCHETPN LPOUPMY pcvt.
1 : Script démarré le vendredi 30 décembre 23:15:22 1994 2 : # cd /sys/compile/URIAH 3 : # gdb -k kernel /var/crash/vmcore.1 4 : Lecture des données de symbole depuis /usr/src/ sys/compile/URIAH/kernel ... terminé. ./../i386/i386/trap.c ligne 673) 73:673 erreur = (*callp->sy_call)(p, args, rval); 74 : (kgdb) jusqu'à 75 : Image initiale sélectionnée ; tu ne peux pas monter. 76 : (kgdb) quit 77 : # exit 78 : exit 79 : 80 : Script terminé le vendredi 30 décembre 23:18:04 1994
lPNNEOFBTYY L CHSHCHYYERTYCHEDEOOPNH TSHTOBMKH :
UFTPLB 6 :
ьФП DBNR, CHSFSHCHK RTY RPNPEY DDB (UNPFTY OITSE), RPPFPNH LPNNEOFBTYK L BCHBTYKOPNH PUFBOPCHH YNEEF YNEOOP CHYD « parce que tu as dit de ! » Y FTBUUYTPCHLB UFELB ZMHVPLB ; PDOBLP YOBYUBMSHOPK RTYYUYOPK RETEIPDB CH DDB VSHMB BCHBTYKOBS PUFBOPCHLB RTY CHPOYLOPCHEOYA PYYVLY UFTBOIGSC RBNSFY.
UFTPLB 20 :
lFP NEUFPOBIPTSDEOOYE ZHKHOLGYY trap() CH FTBUUYTPCHLE UFELB.
UFTPLB 36 :
rTYOKHDIFEMSHOPE YURPMSHЪPCHBOIE OPChPK ZTBOYGSCH UFELB; FERTSH LFP OE OHTSOP. rTEDRPMBZBEFUS, YuFP ZTBOYGSCH UFELB KHLBSCCHBAF À PROPOS DE RTBCHYMSHOP TBURPMPTSEOYE, DBCE CH UMHUBE BCHBTYKOPZP PUFBOPCHB. ZMSDS À PROPOS DE UFTPLH YUIDOPZP LPDB 403, NPTsOP ULBBFSH, YuFP CHEUSHNB CHETPSFOP, YuFP MYVP CHYOPCHBF DPUFHR RP KHLBBFEMA ``tp"", MYVP VSHM CHSHCHIPD ЪB ZТBOYGSC NBUUYCHB.
UFTPLB 52 :
rPIPTSE, YuFP CHYOPCHBF KHLBBFEMSH, OP SUR SCHMSEFUS DPRKHUFYNSCHN BDTEUPN.
UFTPLB 56 :
pDOBLP, PYUECHYDOP, UFP SUR KHLBSCCHBEF À PROPOS DE NHUPT, FBL UFP NSCH OBYMY OBYKH PYYVLH ! (DMS FEI, LFP OE OBLPN U LFPC YUBUFSHHA LPDB : tp->t_line UMHTSYF DMS ITBOEOYS TETSYNB LBOBMSB LPOUPMSHOPZP HUFTPKUFCHB, Y LFP DPMTSOP VShchFSH DPUFBFPYuOP NBMEOSHLPE GEMPE YUYUMP .)
Cette série d'articles est parue pour deux raisons. Tout d'abord, j'aime travailler avec le projet HackSysExtremeVulnerableDriver. Deuxièmement, j'ai reçu beaucoup de voeux pour aborder ce sujet.
Tout le code utilisé pour écrire cette série se trouve dans mon référentiel.
Dans cette série d'articles, nous examinerons l'écriture d'exploits au niveau du noyau sous Windows. Il est important de noter que nous traiterons de vulnérabilités connues et qu'il n'y a pas besoin de rétro-ingénierie (du moins pour le pilote).
Il est prévu qu'après avoir lu tous les articles, vous connaîtrez toutes les classes de vulnérabilités et méthodes d'exploitation les plus courantes, et serez également en mesure de porter les exploits de l'architecture x86 vers l'architecture x64 (si possible) et de vous familiariser avec les nouvelles méthodes de protection. sous Windows 10.
Circuit de débogage du noyau
Contrairement au débogage au niveau de l'utilisateur, qui suspend l'exécution d'un seul processus, le débogage au niveau du noyau implique l'ensemble du système et nous ne pourrons pas utiliser cette méthode. En conséquence, nous avons besoin d'une machine de débogage distincte capable de communiquer avec le système sur lequel le noyau est débogué, d'afficher la mémoire et les structures du noyau, et également de détecter les pannes du système.
Matériel supplémentaire à étudier :
Exploiter les vulnérabilités du noyau
Ce processus est bien plus amusant que d’opérer au niveau de l’utilisateur J.
L'objectif principal est d'obtenir une exécution privilégiée dans le contexte du noyau. Et puis tout dépend de notre imagination, d’un festin avec de la bière maison à l’introduction de logiciels malveillants parrainés par l’État.
En général, notre tâche est d'obtenir un shell avec les privilèges système.
Sujets des articles de cette série
- Partie 1 : Configurer votre environnement de travail
- Configuration de trois machines virtuelles et d'un système qui fera office de débogueur.
- Configuration du débogueur WinDBG.
- Partie 2 : Charges utiles
- Explorez les charges utiles les plus courantes. Les parties suivantes aborderont des vulnérabilités spécifiques et, le cas échéant, fourniront des liens vers cet article.
- Les parties restantes.
- Prise en compte des vulnérabilités.
Cycle de vie du développement des exploits du noyau
- Trouver une vulnérabilité. Ce sujet ne sera pas abordé dans cette série, car nous savons déjà exactement où se situent les lacunes.
- Intercepter le fil d'exécution. Certaines vulnérabilités impliquent l'exécution de code et d'autres nécessitent des exigences supplémentaires.
- Élévation de privilèges. L'objectif principal est d'obtenir un shell avec les privilèges système.
- Restauration du fil d'exécution. Les exceptions non vérifiées au niveau du noyau provoquent le crash du système. Si vous n'écrivez pas d'exploit pour une attaque DoS, vous devez en tenir compte.
Types de systèmes cibles
Nous travaillerons avec les vulnérabilités des systèmes suivants (la version spécifique n'est pas importante) :
- Machine virtuelle Win7 x86
- Machine virtuelle Win7 x64
- Machine virtuelle Win10 x64
Commençons par l'architecture x86, puis nous porterons l'exploit sur le système Win7 x64. Certains exploits ne fonctionneront pas sur les machines Win10 en raison de la présence de nouvelles protections. Dans ce cas, nous modifierons la logique de l’exploit ou utiliserons une approche complètement différente.
Logiciel utilisé :
- Hyperviseur (beaucoup d'options).
- Machine virtuelle Windows 7 x86
- Machine virtuelle Windows 7 x64
- Machine virtuelle Windows 10 x64
Configuration des systèmes pour le débogage
Les systèmes de débogage avec lesquels nous interagirons sont conçus pour charger le pilote vulnérable. Ces machines planteront fréquemment, puisque la plupart des exceptions du noyau contribuent à ce type de phénomène. Vous devez allouer suffisamment de RAM à ces systèmes.
Sur chaque machine qui sera déboguée, vous devez procéder comme suit :
- Dans le répertoire VirtualKD, exécutez le fichier target\vminstall.exe. Une nouvelle entrée de démarrage sera ajoutée et des fonctions de débogage seront disponibles ainsi qu'une connexion automatique au serveur VirtualKD installé sur le système, qui fait office de débogueur.
Dans le cas d'une machine virtuelle Windows 10, vous devez activer le mode de signature de test, qui vous permet de charger des pilotes non signés dans le noyau.
Après avoir exécuté la commande bcdedit /set tests et redémarré, « Mode test » apparaîtra sur le bureau.
Brève description du module HEVD
La procédure DriverEntry est la procédure de démarrage de chaque pilote :
NTSTATUS DriverEntry (IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) (
UINT32 je = 0 ;
PDEVICE_OBJECT DeviceObject = NULL ;
Statut NTSTATUS = STATUS_UNSUCCESSFUL ;
UNICODE_STRING NomDePériphérique, DosDeviceName = (0);
UNREFERENCED_PARAMETER(RegistryPath);
PAGED_CODE();
RtlInitUnicodeString(&DeviceName, L"\\Device\\HackSysExtremeVulnerableDriver");
RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\HackSysExtremeVulnerableDriver");
//Créer l'appareil
Statut = IoCreateDevice (DriverObject,
0,
&Nom du périphérique,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
FAUX,
&DeviceObject);
- Cette procédure contient un appel à la fonction IoCreateDevice, qui contient le nom du pilote que nous utiliserons lors de la communication.
- Les structures et pointeurs de fonction nécessaires seront ajoutés à l'objet DriverObject.
- Ce qui est important pour nous, c'est le pointeur de fonction associé à la procédure DriverObject->MajorFunction, qui est responsable du traitement des IOCTL (I/O Control) ;
- Dans HEVD, cette fonction s'appelle IrpDeviceIoCtlHandler, qui est une grande expression conditionnelle avec de nombreuses branches pour chaque IOCTL. Chaque vulnérabilité possède un IOCTL unique.
Exemple : HACKSYS_EVD_IOCTL_STACK_OVERFLOW est un IOCTL utilisé pour déclencher un exploit de dépassement de pile.
Ceci conclut la première partie. Dans le prochain article, nous parlerons des charges utiles. Pour le moment, la seule charge utile disponible est celle conçue pour voler des jetons, qui seront utilisés dans la troisième partie.
P.S. Je comprends que vous pourriez rencontrer de nombreuses subtilités et problèmes. Puisque cette série se concentre sur le développement d’exploits, vous devrez résoudre vous-même tous les problèmes associés. Cependant, vous pouvez poser toutes vos questions dans les commentaires.
Comment démarrer le débogueur du noyau ?
Réponse du Maître :
Il existe un élément très important dans le processus de développement logiciel : le débogage. En ce qui concerne les programmes d'application, elle est réalisée à l'aide de moyens fonctionnant en mode utilisateur et souvent intégrés à l'EDI. Afin de pouvoir déboguer, par exemple, les pilotes, vous devez exécuter le débogueur du noyau.
Vous devez démarrer le processeur de commandes cmd. Ouvrez le menu Démarrer dans la barre des tâches. Dans la fenêtre qui apparaît, cliquez sur l'élément « Exécuter… ». La fenêtre « Exécuter le programme » apparaîtra. Dans le champ de texte, saisissez cmd, puis cliquez sur OK.
Sauvegardez maintenant votre fichier boot.ini. Tout d'abord, recherchez le chemin d'installation de votre copie actuelle de Windows à l'aide de la commande : echo %SystemRoot%
Ensuite, accédez au disque sur lequel le système d'exploitation est installé en entrant les lettres du périphérique, suivies de deux points. À l’aide de la commande cd, accédez au répertoire racine. Maintenant, à l'aide de la commande attrib, supprimez les attributs "caché", "lecture seule" et "système" du fichier boot.ini. Utilisez la commande copy pour créer une copie de sauvegarde, puis définissez les attributs en place.
Pour afficher la liste actuelle des options de démarrage, utilisez la commande bootcfg /query. Parcourez la liste et déterminez l'élément sur la base duquel de nouveaux paramètres seront créés avec la possibilité de déboguer en mode noyau. L'ID d'entrée de démarrage doit être mémorisé.
Utilisez la commande bootcfg/copy pour créer une entrée de démarrage. Pour préciser l'identifiant de l'enregistrement que vous allez copier, utilisez le paramètre /id. À l'aide de l'option /d, spécifiez le nom de l'entrée qui sera affichée. Vous devez maintenant revenir à la liste des options de démarrage à l'aide de la commande bootcfg /query et consulter l'ID de l'entrée ajoutée.
Vous devez maintenant inclure des options pour lancer le débogueur du noyau dans l'entrée de démarrage créée précédemment. Si vous déboguez sur la machine cible, il vous suffit d'ajouter l'option /debug.
Si vous souhaitez effectuer un débogage à distance en connectant l'ordinateur cible via un port COM à la machine hôte, utilisez les options /port et /baud pour spécifier le numéro de port et la vitesse de transmission.
Si vous effectuez un débogage à distance via un câble FireWire (interface IEEE 1394), utilisez l'option /dbg1394 pour activer le mode correspondant et l'option /ch pour spécifier le numéro de canal.
Pour vous assurer que les modifications ont été apportées, vérifiez vos fichiers de démarrage à l'aide de la commande bootcfg avec le paramètre /query. Après avoir exécuté la commande exit, fermez la fenêtre shell.
Si nécessaire, modifiez les paramètres de démarrage du système d'exploitation. Ouvrez le Panneau de configuration via le menu Démarrer et ouvrez-y l'élément Système. Dans la fenêtre « Propriétés système » qui s'ouvre, sélectionnez l'onglet « Avancé ». Dans cet onglet, sélectionnez la section intitulée « Démarrage et récupération » et cliquez sur le bouton « Options ». Dans la fenêtre « Boot and Recovery » qui apparaît, vous devez activer l'option « Afficher la liste des systèmes d'exploitation ». Fermez les deux boîtes de dialogue avec le bouton OK.
Redémarrez votre ordinateur. Sélectionnez démarrer avec le débogueur. Connectez-vous et commencez à travailler sur la machine cible ou démarrez le débogage à distance. Utilisez des outils tels que WinDbg et KD.