vitoplantamura/bugcheckerDébogueur noyau de type SoftICE pour Windows 11
BugChecker est un débogueur noyau et utilisateur de type SoftICE pour Windows 11 (et Windows XP également : il prend en charge les versions de Windows de XP à 11, en x86 et x64). BugChecker ne nécessite pas qu'une deuxième machine soit connectée au système en cours de débogage, contrairement à WinDbg et KD. Cette version de BugChecker (contrairement à la version originale développée il y a 20 ans) exploite l'API KD interne et non documentée de NTOSKRNL. L'API KD permet à WinDbg/KD d'effectuer des appels comme la lecture/écriture de la mémoire virtuelle, la lecture/écriture des registres, le placement d'un point d'arrêt à une adresse, etc.
En revanche, l'original BugChecker, tout comme SoftICE, avait l'habitude de « prendre le contrôle » du système, en hookant plusieurs API du noyau (à la fois exportées et privées), en prenant le contrôle de l'APIC, en envoyant des IPI, etc. Cette approche augmente la complexité de manière exponentielle (et réduit la stabilité du système), car l'implémentation doit être compatible avec toutes les versions et sous-versions de Windows prises en charge (au niveau de la signature des fonctions) ainsi qu'avec toutes les configurations matérielles prises en charge. De plus, 20 ans plus tard, PatchGuard rend cette solution impossible.
En revanche, cette version de BugChecker, en interceptant les appels à KdSendPacket et KdReceivePacket dans le noyau, se présente à la machine en cours de débogage comme un deuxième système exécutant un débogueur noyau externe, mais, en réalité, tout se passe sur la même machine. Typiquement, cela est réalisé en remplaçant KDCOM.DLL (qui est le module qui implémente la communication série pour l'API KD dans Windows) et en démarrant le système en mode débogage noyau. Cette approche (inspirée de VirtualKD) réduit la complexité et augmente la stabilité, la compatibilité (et la portabilité, par exemple vers ARM - et la modularité, car les capacités de débogage de bas niveau sont implémentées derrière KdXxxPacket et pourraient être remplacées par une implémentation personnalisée). De plus, la présence d'un débogueur noyau au démarrage (bien que « factice ») désactive PatchGuard.
Pour le moment, BugChecker nécessite un clavier PS/2 pour la saisie et un framebuffer linéaire pour écrire sa sortie. Veuillez noter que le clavier intégré de nombreux ordinateurs portables modernes est encore PS/2.
Démonstration de BugChecker sur Windows 11 22H2, dans VirtualBox 7.0.4. Une condition de point d'arrêt JavaScript est écrite, modifiant le flux d'exécution dans un thread en mode utilisateur.
BugChecker fonctionnant dans un environnement très contraint : un Raspberry Pi 4 (4 Go de RAM), via QEMU sur Windows XP (512 Mo de RAM). Un point d'arrêt est utilisé pour journaliser tous les appels SYSENTER du mode utilisateur vers le noyau. L'index de service est stocké dans un tableau JavaScript.
Exécution de BugChecker directement sur du matériel nu, sur un HP Pavilion Dv2000, un ancien PC avec un clavier PS/2. Le système d'exploitation est Windows 7 Home 32 bits.
Assurez-vous que Secure Boot est désactivé lors de l'installation et de l'utilisation de BugChecker. Vous pouvez généralement le réactiver ultérieurement. Si vous utilisez VMware ou VirtualBox, Secure Boot peut être désactivé dans les paramètres de la machine virtuelle.
Envisagez également d'activer le menu de démarrage hérité, si vous utilisez Windows 8, 10 ou 11, en utilisant la commande : bcdedit /set "{current}" bootmenupolicy legacy. Cela permet une expérience plus fluide lors du démarrage, en permettant de sélectionner l'option de démarrage BugChecker et de désactiver l'application de la signature des pilotes en même temps.
La première étape consiste à démarrer le chargeur de symboles :
Si nécessaire, désactivez les pilotes d'affichage en cliquant sur le bouton « Disable Display Drvs ». La même opération peut être effectuée dans le Gestionnaire de périphériques Windows. Une fois les pilotes d'affichage désactivés, ils restent désactivés même après un redémarrage du système. Ils peuvent être réactivés à tout moment ultérieurement lorsque vous n'utilisez pas BugChecker.
Le point ici est que BugChecker a besoin d'un framebuffer linéaire avec un format de 32 bits par pixel pour dessiner son interface. Lors de la désactivation des pilotes d'affichage, Windows abandonne l'accélération matérielle pour dessiner son interface utilisateur et revient au mode de compatibilité VGA. Si vous exécutez sur du matériel nu ou VMware, vous devez désactiver les pilotes d'affichage. Si vous exécutez sur VirtualBox, vous devez désactiver les pilotes d'affichage ou définir le paramètre vm_screen dans BugChecker.dat, comme décrit ci-dessous. Si vous exécutez sur QEMU, vous n'avez pas besoin de désactiver les pilotes d'affichage mais assurez-vous de spécifier le périphérique d'affichage « -vga std ».
Notez que le mode de compatibilité VGA pourrait limiter la résolution maximale de l'écran. VMware est limité à une résolution maximale de 1152x864. QEMU avec le périphérique d'affichage « -vga std » ne souffre pas de cette limitation.
Fait intéressant, si BugChecker est installé sur un système avec plus d'une carte graphique, il est possible de désactiver les pilotes d'affichage d'une seule carte graphique, qui sera la carte connectée à l'écran affichant l'interface utilisateur de BugChecker. La deuxième carte (définie comme affichage principal) conservera toutes ses fonctionnalités d'accélération 2D et 3D, y compris la prise en charge d'OpenGL et DirectX (REMARQUE : testé sur VMware, avec Windows 11 et un écran DisplayLink).
Cliquez ensuite sur « Start Driver », puis sur « Auto Detect » et enfin sur « Save ». « Auto Detect » devrait être en mesure de déterminer automatiquement la largeur, la hauteur, l'adresse physique et le pas du framebuffer. Cependant, vous pouvez spécifier ces paramètres manuellement (n'oubliez pas de cliquer sur « Save » une fois terminé). Si « Stride » est 0, il est calculé comme « Width » * 4 automatiquement lors du démarrage du pilote. « Address » (c'est-à-dire l'adresse physique du framebuffer) peut être obtenue dans le Gestionnaire de périphériques Windows, en cliquant sur « Propriétés » du périphérique d'affichage, sous l'onglet « Ressources ».
Ensuite, cliquez sur « Callback » dans la section « KDCOM Hook Method », puis sur « Copy/Replace Kdcom » et enfin vous pouvez redémarrer le système.
Cette procédure de configuration ne doit être effectuée qu'une seule fois et les pilotes d'affichage peuvent être réactivés si nécessaire. Cependant, lors de l'utilisation de BugChecker, les pilotes d'affichage doivent être à nouveau désactivés si votre configuration l'exige.
Le paramètre vm_screen dans BugChecker.dat permet d'ouvrir l'interface utilisateur du débogueur BugChecker dans VirtualBox sans spécifier à l'avance une résolution d'écran dans le chargeur de symboles et sans désactiver les pilotes d'affichage.
L'idée est d'écrire directement sur les ports d'E/S et le tampon de commande du périphérique d'affichage virtuel pour obtenir la résolution d'écran actuelle et notifier l'hyperviseur de toute mise à jour du framebuffer.
Cette solution a été inspirée par le pilote X.org xf86-video-vmware.
Cette solution fonctionne uniquement pour les machines virtuelles VirtualBox et en éditant manuellement le fichier BugChecker.dat :
Il s'agit d'une fonctionnalité expérimentale. À l'avenir, ce paramètre sera automatiquement ajouté par le chargeur de symboles.
Le nom de la commande et la syntaxe sont choisis pour être aussi proches que possible de ceux du SoftICE original pour NT :
Remarque : Le WDK doit être installé dans son emplacement par défaut, c'est-à-dire X:\WinDDK, où X est le lecteur où les sources de BugChecker sont sauvegardées.
Un guide étape par étape pour la construction du pilote noyau est disponible ici.
