Or, deux collègues de Sysdream, Stéfan Leberre (Heurs) et Damien Cauquil (Virtualabs), viennent de trouver une méthode permettant de la contourner sous certaines conditions. Leur article ainsi que leur Proof Of Concept est disponible sur le site de Sysdream :

• L’article Bypassing SEHOP
• Proof Of Concept fonctionnant sous Windows 7

Le décor

Il y a environ 2 ans, j’achète un laptop. Vista est préinstallé dessus, et la machine n’a qu’1 Go de RAM et un AMD Turion x2 pas très véloce. Bref, je ne vous fais pas de dessin : Vista est sans surprise extrèmement lent. Je décide donc d’installer un XP. Pour éviter les problèmes avec un éventuel retour SAV de la machine, je préfère garder Vista ; je réduis donc sa partition à 20 Go et installe XP sur le reste. Et je me dis que je l’utiliserai sans doute occasionnelement…

Lors de l’installation, XP détecte Vista, et s’installe dans une partition étendue qu’il crée automatiquement. Pourquoi une étendue et pas une principale ? Seul Microsoft le sait… Une fois XP installé, celui-ci a viré le boot loader de Vista. Il faut donc que j’utilise Vista Boot Pro afin de mettre en place un dual boot Vista – XP. Je vous passe les détails, ce n’est pas le but de cet article.

Enfin, je me décide à installer une Ubuntu. Je rétrécis donc XP et installe Ubuntu dans des partitions à la suite de celle contenant XP. Grub s’installe sur le MBR et me permet alors de mettre en place mon triple boot. En fait, Grub détecte les deux Windows comme une seul entrée. Au boot, il me propose le choix entre Linux et les Windows. Si je choisis Windows, le boot loader de Vista prend la relève et me donne le choix entre booter Vista ou XP. Ouf !

Pour résumer, mon disque dur est donc partitionné comme suit :

• Une partition primaire contenant Vista
• Une partition étendue avec :
  • XP
  • Linux

La revanche de Vista

Cette config a très bien marché pendant près de 2 ans. Jusqu’au jour ou je me rend compte qu’en fait, je n’ai jamais utilisé Vista, alors qu’il m’utilise tout de même 20 Go sur mon disque. Comme la garantie du laptop est de toutes façon arrivée à terme, je me dis que je ne risque rien à le supprimer. Ni une ni deux ; je supprime la partition avec GParted, sous Linux. Je reboote. Et là, c’est le drame. XP ne boote plus, j’obtiens le message « Invalid device requested« . Il faut croire que Vista a emporté XP dans sa tombe…

Le combat

En cherchant un peu sur le Web, je m’aperçois que cette erreur viendrait de Grub. Je vérifie l’entrée correspondant à XP (en tapant « e » au menu de Grub lors du boot), qui est toujours valide. En effet, XP étant au début de la partition étendue, Grub la nomme (hd0,4) (équivalent de /dev/sda5). D’où vient l’erreur ?

Je continue à chercher, et je m’aperçois que Windows XP n’a apparemment pas été prévu pour pouvoir booter sur une partition étendue. La question que je me pose alors est : dans ce cas, pourquoi bootait-il lorsque Vista était encore là ? En me documentent sur le multiboot Vista – XP, j’apprends que lorsqu’un tel multiboot est mis en place, c’est Vista qui se charge de booter XP. Ce qui expliquerait donc pourquoi XP ne boote plus désormais…

La solution se dessine : il faudrait que je « sorte » ma partition XP de ma partition étendue, pour en faire une primaire. Peut-être que de cette façon, XP sera capable de booter tout seul comme un grand. Sous Linux, j’utilise donc GParted pour copier ma partition XP en dehors de la partition étendue (à la place de l’ancien Vista). Après pas mal de temps, l’opération se termine avec succès. Tant qu’à faire, je marque la partition comme bootable. Je reboote, et demande à Grub de booter désormais sur (hd0,0), c’est à dire la nouvelle partition. Cette fois-ci, nouvelle erreur : « NTLDR is missing« .

NTLDR est le boot loader de XP, et il semble introuvable. Je glane encore quelques infos sur le Web. Il semblerait qu’il soit possible de remédier à ce problème avec la console de récupération du CD de XP, en utilisant l’utilitaire fixboot. Je le fais, mais cela n’améliore rien. Je recommence, en rajoutant cette fois-ci un coup de fixmbr. Là, c’est encore pire : Grub ne démarre même plus, car Windows a écrasé le MBR (logique), mais le processus de boot va encore moins loin car j’obtiens une erreur « Invalid partition table« . De mieux en mieux…

Je commence par réinstaller Grub, en utilisant un live CD d’Ubuntu et l’utilitaire grub-install, qui répare le MBR. Je peux alors booter à nouveau sous Linux. Je monte ma partition Windows défectueuse et liste les fichiers situés à la racine. Dans /dev/sda1 (C:), je ne vois aucun fichier ntldr. Ni de boot.ini, ni de ntdetect.com… Pourtant, ces fichiers sont vitaux au démarage de Windows ! J’en conclus donc que Vista avait du déplacer ces fichiers dans sa partition (vu qu’il boote XP lui-même), et qu’ils ont été effacés avec le reste de la partition. Heureusement, j’ai un autre XP qui fonctionne sur une autre machine. J’utilise donc une clé USB pour copier les fichiers ntldr, boot.ini et ntdetect.com sur ma partiton XP defectueuse. Au passage, je vérifie que le boot.ini est correct. Je repasse ensuite un coup de fixboot avec la console de récupération XP. Je reboote, et…

Le bout du tunnel

Yeah, XP démarre ! Après un check des disques, tout semble fonctionner… Du moins pendant quelques secondes. Rapidement, plusieurs services se mettent à planter. En regardant de plus près, je commence à comprendre pourquoi : les lettres des lecteurs ont changé. En effet, lorsque j’avais installé XP pour la 1ère fois, il s’était attribué la lettre F, car il était sur la partition étendue. Comme cette fois-ci je boote sur une partition primaire (copie de l’ancienne), et que Windows attribue « bêtement » les lettres dans l’ordre des partitions sur le disque, cette partition se retrouve nommée C. Seul problème : tous les programmes, raccourcis et la base de registre pointent encore vers F…

La solution est donc de renommer les lecteurs, en inversant C et F. Cependant, l’utilitaire de gestion des disques Windows refuse, car la partition C est une partition système. Quasiment désespéré, je reparcours le Web en recherche d’une méthode miracle pour renommer de force cette partition… Et je finis par en trouver une, que voici !

Pour résumer, il s’agit d’inverser deux clés dans la base de registre. Elles se trouvent dans HKEY_LOCAL_MACHINESYSTEMMountedDevices. Dans mon cas, je dois inverser DosDevicesC: et DosDevicesF:.  Je le fais, et je reboote…

Ca marche ! Au reboote, F: est bien ma partition système primaire, et C: est devenu l’ancienne partition. Mon XP est désormais stable, il pète de nouveau la forme… Je supprime C et à reboote une dernière fois pour m’assurer que tout roule, et c’est le cas. Encore une victoire de canard

Morales

Les leçons à tirer de cette histoire sont :

• Méfiez vous comme la peste du multiboot Vista – XP, surtout quand vous supprimez Vista.
• N’installez pas Windows dans une partition étendue.
• Ayez toujours un CD de Windows XP sous la main, car la console de restauration est bien pratique.
• Même chose concernant les live CD de Linux : GParted est un outil gratuit incontournable qui pourra vous sauver la mise même si tous vos OS sont inutilisables. En plus, vous pourrez aller sur Internet avec et chercher de la doc…
• Sauvegardez votre ntldr, boot.ini et ntdetect.com pour les avoir à disposition au cas où (ils ne font que quelques ko).
• Changer la lettre d’une partition système est possible… mais ne changera pas les références gardées en dur par tous vos programmes. Ne le faites que si la lettre de votre partition a changée toute seule !

Sur ce, j’espère avoir aidé du monde !

GoRing0

GoRing0 est donc un rootkit qui a pour objectif de faire passer un thread en ring 0, et de le rebasculer accessoirement en ring 3 lorsqu’il le souhaite. Pour cela, celui-ci devra bien évidemment charger un driver, afin de s’élever les droits et de permettre une telle commutation. La partie utilisateur du rootkit pourrait se présenter sous la forme d’une librairie exportant deux fonctions principales : GoRing0() et GoRing3(), permettant le basculement en ring 0 et ring 3 respectivement. N’importe quel programme pourrait alors faire appel à ces fonctions et s’élever les droits à volonté. Je développe pour le moment sous Windows, mais idéalement, GoRing0 devrait être capable de fonctionner aussi bien sous sous Linux, la manipulation qu’il effectue étant surtout liée à l’architecture x86.

Le principe de fonctionnement de GoRing0 repose sur les interruptions. Les fonctions GoRing0() et GoRing3() déclenchent une interruption spécifique qui est hookée par le driver et qui se charge de modifier la valeur de CS empilée automatiquement par le processeur. En effet il se trouve que le ring courant du processeur (le CPL) est encodé dans les 2 premiers bits de CS ainsi que dans le descripteur de segment (dans la GDT) auquel il correspond. Plus intéressant encore, Windows définit deux valeurs spéciales de CS : une en userland (0x1b), et une en kernelland (0×8). Il suffit alors au handler d’interruption de substituer la valeur empilée de CS par la valeur kernelland pour passer le thread en ring 0 au retour d’interruption.

Pour le moment, j’ai un prototype fonctionnel stable : j’arrive à passer un thread en ring 0 et à le rebasculer en ring 3. Pour m’en assurer, je peux afficher la mémoire kernel depuis ce thread (adresses supérieures à 0×80000000 sous Windows). Cependant, lorsqu’un thread est en ring 0, il est impossible d’appeler des API Windows car celles-ci vérifient apparamment si le thread qui les appelle vient bien du ring 3. De même, il n’est pas possible d’appeler des fonctions du kernel depuis le thread même en ring 0, à moins d’en connaître l’adresse ou de la résoudre à l’exécution.

Nouvelle conférence à la Nuit Du Hack

Enfin, j’en viens à la véritable news de ce post… Au départ, je devais présenter une conférence sur XeeK et une autre sur InjecSO. Etant donné qu’InjecSO est sorti depuis un moment maintenant (avec la doc sur ce blog), que je me suis lancé dans ce nouveau projet, et que cette année il n’y a pour l’instant aucune conférence orientée kernel, j’ai pensé intéressant de remplacer la conférence sur InjecSO par une sur GoRing0. Je compte y présenter le projet et par la même occasion de présenter rapidement l’architecture x86 et le développement en mode kernel aux débutants en la matière. Ceux pour qui les concepts d’interruption, segments et autre GDT sont du chinois (autrement dit ceux qui n’ont pas compris le paragraphe technique ci-dessus…) sont les bienvenus, je compte justement expliquer tout cela ! Ca sera de plus l’occasion de releaser officiellement GoRing0 et de faire une petite démo. Sur ce, à la NDH !

Le pourquoi du BSOD

Avant de mettre les mains dans le cambouis, il est intéressant de comprendre pourquoi Windows affiche un écran bleu. Cet écran maléfique est affiché lorsque quelque chose d’assez sérieux s’est produit au niveau du noyau. Cela peut être aussi bien matériel que logiciel (parfois les deux). Par exemple : un driver tente d’accéder à une zone mémoire non existante ou protégée. Si vous essayez de faire cela avec un programme en en mode utilisateur, celui-ci crashera en affichant un message d’erreur Windows (ou une segmentation fault sous Linux). En mode noyau, l’équivalent est le BSOD sous Windows (Kernel Panic sous Linux) et vous n’avez pas d’autre choix que de rebooter votre bécane. Eh oui, on ne plaisante pas avec le kernel. Voici un exemple de driver qui provoquera un écran bleu à coup sûr :

* (unsigned int *) 0 = 0;

Ce code essaye d’écrire 0 à l’adresse mémoire virtuelle 0, qui est invalide. Par conséquent, le processeur déclenchera un défaut de page, ce qui provoque un écran bleu puisque son descripteur est invalide. Il y a plein d’autres manières de provoquer un écran bleu, mais cela dépasse le cadre de cet article.

Reversing de la routine du BSOD

Le code de la routine affichant le BSOD se situe dans le kernel Windows, dans ntoskrnl.exe (ou ntkrnlpa.exe si vous avez la PAE). Après avoir débuggé une machine virtuelle et provoqué un écran bleu volontairement grâce au code donné ci-dessus, je m’aperçois que la VM s’est arrêtée dans la routine KeBugCheckEx. J’ouvre ntoskrnl.exe avec IDA PRO et désassemble cette routine.

public _KeBugCheckEx@20
_KeBugCheckEx@20 proc near

BugCheckCode= dword ptr  8
BugCheckParameter1= dword ptr  0Ch
BugCheckParameter2= dword ptr  10h
BugCheckParameter3= dword ptr  14h
BugCheckParameter4= dword ptr  18h

mov     edi, edi
push    ebp
mov     ebp, esp
push    0
push    [ebp+BugCheckParameter4]
push    [ebp+BugCheckParameter3]
push    [ebp+BugCheckParameter2]
push    [ebp+BugCheckParameter1]
push    [ebp+BugCheckCode]
call    _KeBugCheck2@24 ; KeBugCheck2(x,x,x,x,x,x)
pop     ebp
retn    14h
_KeBugCheckEx@20 endp

Cette fonction est très courte, elle ne fait qu’empiler des paramètres et appeler la routine KeBugCheck2. Cette dernière est par contre très longue. Comme mon but n’est pas de la reverser intégralement mais juste isoler la partie qui m’intéresse, je parcours rapidement son graphe avec IDA. Vu le nom des fonctions appelées, cette routine récupère des informations auprès des drivers sur le crash qui vient d’avoir lieu.

Couleur de fond

A peu près au milieu de la fonction, on tombe sur ce code :

call    _InbvAcquireDisplayOwnership@0 ; InbvAcquireDisplayOwnership()
call    _InbvResetDisplay@0 ; InbvResetDisplay()
push    4
push    1DFh
mov     ebx, 27Fh
push    ebx
push    esi
push    esi
call    _InbvSolidColorFill@20 ; InbvSolidColorFill(x,x,x,x,x)

Apparemment, on a affaire à des appels de fonction gérant l’affichage. On commence par faire un reset de l’affichage, puis on appelle la routine InvbSolidColorFill. Les paramètres qui lui sont passés sont les suivants (je rappelle que l’ordre est inversé, selon la convention d’appel utilisé) :

• deux arguments égaux à 0 (si on cherche un peu plus haut on trouve un xor esi,esi donc esi = 0)
• 0x27F = 639
• 0x1DF = 479
• 4

Etant astucieux, on se rend compte que 639 = 640 – 1 et 479 = 480 – 1. Hors, 640 x 480 correspond exactement à la résolution de l’écran bleu. Avec les deux paramètres 0 qui précèdent, ces valeurs correspondent aux bornes (gauche, haute, droite, et basse) de la zone de l’écran à remplir. La couleur de remplissage est précisée par le dernier paramètre, qui vaut 4. En cherchant un peu sur Google, on se rend compte que le code couleur utilisé par cette fonction est sur 4 bits : IBGR soit Intensity, Blue, Green and Red. 4 en décimal équivaut à 0100 en binaire, soit 1 pour le bleu et 0 pour le reste. Voilà donc pourquoi l’écran bleu est bleu !

Si on désassemble la fonction InvbSolidColorFill, on se rend compte qu’assez rapidement, celle-ci appelle la fonction VidSolidColorFill. Il s’agit d’une fonction importée par ntoskrnl.exe depuis bootvid.dll, le module chargé de la vidéo lors du boot. Son code est relativement peu clair, aussi j’ai préféré jeter un coup d’oeil aux sources de ReactOS, qui est nettement plus lisible. Pour ceux qui ne connaissent pas, il s’agit d’un projet visant à recoder Windows en Open Source. Voici le code de la fonction dans ReactOS (qui doit être très similaire dans Windows) :

VOID NTAPI
VidSolidColorFill(IN ULONG Left, IN ULONG Top,
                  IN ULONG Right, IN ULONG Bottom,
                  IN UCHAR Color)
{
    int y, x;

	for (y = Top; y <= Bottom; y++)
	{

            for (x = Left; x <= Right; x++)
            {
                //
                // Draw the pixel
                //
                VidpSetPixel(x, y, Color);
            }
	}
}

Comme vous pouvez le voir, on peut difficilement faire plus simple. Une fonction chargée de fixer la couleur d’un pixel est appelée dans une double boucle, ce qui a pour effet de remplir l’écran.

Couleur du texte

Revenons au code de KeBugCheck2. Juste après le code qui remplit l’écran, on a ceci :

push    0Fh
call    _InbvSetTextColor@4 ; InbvSetTextColor(x)

Vu le nom de la fonction, on peut se douter que celle-ci fixe la couleur du texte du BSOD. 0xF = 0b1111 = blanc. Que demander de plus ?

Patching à chaud pour changer les couleurs

Que diriez vous de personnaliser la couleur du BSOD sur votre système ? Je n’ai personnellement jamais aimé le bleu, je préfère le rouge (plus sexy pour un message d’erreur !). Quand au texte, du jaune devrait faire l’affaire…

Pour des raisons de sécurité, je vous déconseille fortement d’éditer l’exécutable de votre noyau (ntoskrnl.exe) car une erreur peut être vraiment fatale. Je préfère nettement opérer en mémoire, afin qu’un simple reboot efface les modifications. D’autre part, comme on s’apprête à débugger Windows et à le faire planter, il faut opérer sur une deuxième machine. Munissez vous d’une VM (VirtualBox pour ma part) que vous bootez en mode debug (flag /debug du boot.ini) avec Windbg lancée en parallèle sur votre machine. Pour ceux qui débutent, je vous conseille de lire cet article d’0vercl0ck qui vous expliquera comment tout configurer comme il faut. Prêt ? C’est parti !

Une fois Windows démarré, freezez le avec Ctrl+Pause sous Windbg. Commençons par localiser ou se trouve l’appel à InvbSolidColorFill dans KeBugCheck2. Sous IDA, on effectue un petit calcul d’offset pour savoir ou se trouve le push 4 par rapport au début de KeBugCheck2. Chez moi, j’ai un offset de 0x60D. Dans Windbg, je tape donc u KeBugCheck2+0x60d. Cependant, ça ne tombe pas juste ; j’atterris après ce bout de code (facile de le constater avec IDA). C’est sans doute à cause du fait que j’ai des mises à jours différentes sur ma machine et dans ma VM. Je remonte donc petit à petit et je finir par arriver sur l’instruction qui m’intéresse :

kd> u KeBugCheck2+0x5e4
nt!KeBugCheck2+0x5e4:
8053342e e8da9fffff      call    nt!InbvResetDisplay (8052d40d)
80533433 6a04            push    4
80533435 68df010000      push    1DFh
8053343a bb7f020000      mov     ebx,27Fh
8053343f 53              push    ebx
80533440 56              push    esi
80533441 56              push    esi
80533442 e84aa0ffff      call    nt!InbvSolidColorFill (8052d491)

Il suffit de patcher la valeur située à l’adresse 80533434 pour changer la couleur du BSOD ! Pour ma part, je choisis le rouge, soit 0b0001 = 1. Je tape donc ceci dans Windbg (eb = edit byte) :

kd> eb 80533434 01

Vérifions cela en désassemblant à nouveau :

kd> u KeBugCheck2+0x5e4
nt!KeBugCheck2+0x5e4:
8053342e e8da9fffff      call    nt!InbvResetDisplay (8052d40d)
80533433 6a01            push    1
80533435 68df010000      push    1DFh
8053343a bb7f020000      mov     ebx,27Fh
8053343f 53              push    ebx
80533440 56              push    esi
80533441 56              push    esi
80533442 e84aa0ffff      call    nt!InbvSolidColorFill (8052d491)

Super, ça semble avoir marché. Faisons de même avec la couleur du texte !

kd> u KeBugCheck2+0x5fd
nt!KeBugCheck2+0x5fd:
80533447 6a0f            push    0Fh
80533449 e8d1a0ffff      call    nt!InbvSetTextColor (8052d51f)

Je veux du jaune, je remplace donc le 0x0F par un 0x0B soit 0b1011 (mélange clair de vert et rouge).

kd> eb 80533448 0B
kd> u KeBugCheck2+0x5fd
nt!KeBugCheck2+0x5fd:
80533447 6a0b            push    0Bh
80533449 e8d1a0ffff      call    nt!InbvSetTextColor (8052d51f)

Nikel. Il ne reste plus qu’à provoquer un écran bleu ! Pour ce faire à partir de Windbg, c’est très simple : il suffit de mettre eip à 0. On tape juste r eip = 0 et on débloque la machine avec la commande g. Windows crashe instantanément et Windbg reprend la main. Attendez quelques secondes que les symboles se rechargent, appuyez sur Ctrl+Pause pour arrêter l’opération de diagnostique de crash, et retapez g pour voir apparaître votre beau BSOD personnalisé. En ce qui me concerne, c’est plutôt un RSOD (Red Screen Of Death) !

Red Screen Of Death

C’est ti pas mignon tout ça ? Pour ceux qui par malheur verraient leur écran s’afficher puis disparaître à cause d’un reboot instantané, refaites la manip en n’oubliant pas au préalable de désactiver les reboots sur crash système en faisant un clic droit sur le poste de travail, propriétés, avancé, paramètres de démarrage et récupération, puis décochez la case « redémarrer automatiquement ».

Conclusion

J’espère que cet article vous aura plu et que vous allez dès à présent tuner votre BSOD pour rendre jaloux vos amis. Pour ceux qui voudraient aller plus loin, sachez qu’il est également possible de modifier le texte affiché sur l’écran… Après, vous pouvez intégrer tout ça dans un driver qui se chargera d’effectuer le patching lui-même. C’est ce que fait le programme BSOD Hack (cf en bas). Et si vous en avez le courage, vous pouvez même faire un petit hook inline (detour patching) afin de rediriger un crash vers votre propre routine. J’ai entendu dire que certains avaient réussi à charger et afficher une image de bière lors d’un crash, si ça peut vous donner des idées…

Références

• BSOD Hack

Généralités sur les interruptions

Une interruption est un événement particulier qui peuvent se produire lors de l’exécution d’un programme. A chaque type d’interruption est associé un numéro appelé vecteur d’interruption, connu du ou des processeur(s). Pour simplifier, les interruptions peuvent provenir de deux sources : le logiciel et le matériel. Les interruptions matérielles sont générées par les périphériques (clavier, souris, cartes, timers, disques durs…) et sont transmises au processeur par l’APIC (Advanced Programmable Interrupt Controller).  Les interruptions logicielles peuvent être quant à elles déclenchées volontairement par une instruction (int) ou de façon accidentelle par une erreur arithmétique, logique, de protection, etc. Dans ce cas, on parle souvent d’exception et de fautes.

Généralement, les interruptions (aussi bien matérielles que logicielles) sont susceptibles de se déclencher à n’importe quel moment dans l’exécution d’un programme, et chaque processeur doit savoir comment traiter chacune d’entre elles. A chaque vecteur d’interruption on associe alors un handler d’interruption, qui est une fonction qui sera appelée automatiquement quand l’interruption sera générée.  On place ces fonctions dans une table, l’IDT, pour Interrupt Descriptor Table. Il est important de noter qu’il y a une IDT par processeur, afin que chacun puisse avoir si besoin un comportement différent pour chaque interruption.

Il existe deux types d’interruptions matérielles, les masquables (les IRQ) et les non masquables (la NMI et la SMI) qu’on ne traitera pas ici en raison de leur grande particularité. Chaque interruption matérielle possède une priorité, qui est gérée par l’APIC. Pour faire simple, ce composant est relié aux périphériques par des lignes d’IRQ (Interrupt Requests) et se charge de faire le médiateur entre tous ces périphériques et le ou les processeur(s). Son rôle est en gros de transformer ces IRQ en demandes d’interruptions avec le vecteur associé.  Comme plusieurs IRQ peuvent intervenir en même temps, l’APIC définit des priorités afin de transmettre les plus urgentes d’abord.

Dans certains cas, le processeur peut ne pas vouloir être dérangé par une interruption. C’est le cas par exemple lorsqu’il est en train de modifier des structures globales en mémoire. Il a alors la possibilité d’ignorer les interruptions qu’il va recevoir de deux manières. La première, que je ne détaillerai pas, est de ne masquer que celles dont la priorité est inférieure à un certain seuil (appelé IRQL sous Windows) en communiquant avec l’APIC. La deuxième est de masquer la totalité des interruptions et c’est celle que nous allons détailler.

Subtilité sur le masquage

C’est le registre EFLAGS et plus précisément son bit IF (bit 9) qui contrôle si les interruptions masquables sont activées ou non. Ce bit est modifiable par l’intermédiaire des instructions cli pour masquage et sti pour démasquage, ou bien en utilisant pushf / popf associés à des masques.

Attention, le masquage des interruptions n’affecte que les interruptions matérielles ! Les interruptions logicielles (ainsi que les interruptions NMI et SMI, très particulières) ne sont pas affectées par ces opérations. Autrement dit, vous aurez beau baisser l’IRQL ou faire un cli, une exception due à une division par zéro ou à un défaut de page pourra toujours survenir.

Problème n°1 : DbgPrint(), c’est le mal

J’ai fait tous mes tests en machine virtuelle. Comme le développement de driver n’est jamais sûr à 100% et que je voulais tout de même avoir quelque chose de fonctionnel, j’ai réalisé un petit script qui charge le driver et le décharge 100 fois de suite, en lançant en plus des programmes divers pour solliciter l’OS un maximum. Le tout étant de prouver que le driver n’explose pas à la première interruption, bien entendu.

Dans mon cas, je devais hooker l’interruption n°14 correspondant au défaut de page (page fault), en insérant du code avant de rappeler le handler par défaut de Windows. Je rappelle que cette exception (logicielle) se produit quand une page virtuelle n’est mappée à aucune adresse physique (soit parce qu’elle a été swappée sur disque, soit parce qu’elle n’existe tout simplement pas). Cela se produit quand on tente d’accéder à une page dont le descripteur PTE a son premier bit (bit P) à 0.

J’ai donc commencé par concevoir un handler minimal qui ne faisait rien à part empiler tous les registres, les dépiler puis appeler le handler de Windows, KiTrap0E. Jusqu’ici, tout fonctionne, sauf que je n’ai pas vraiment de preuve que ma routine est appelée (vu que je n’ai aucune trace).

Je me décide donc à insérer des DbgPrint() dans le code de la routine. Et là, c’est le drame : j’obtiens des traces certes, mais j’en obtiens tellement que la VM freeze ou affiche un écran bleu au bout de quelques secondes. Il faut croire que les défauts de page sont très nombreux sous Windows… Mais pourquoi ça plante maintenant et pas avant ? L’explication est liée au visualisateur de traces (j’utilise DebugView). Lorsque DbgPrint() est appelé, le message est récupéré par le noyau puis par DebugView. Je ne sais pas exactement pourquoi, mais apparemment quand il y a beaucoup de messages de récupérés, DebugView commence à provoquer des défauts de page (probablement à cause du fait qu’il se fait swapper par l’OS). Comme ces défauts de pages sont à leur tour catchés par mon handler, ils entraînent d’autres appels à DbgPrint()… Bref, une belle boucle qui finit par exploser tôt ou tard.

Au final, je renonce donc  à afficher des traces, vu que cela perturbe plus le système qu’autre chose. En plus j’ai ma preuve que mon handler est appelé, vu que ça plante

Problème n°2 : sti, c’est aussi le mal

Le réel but de mon handler est de modifier une structure assez cruciale du noyau sous certaines conditions. Afin d’éviter que cette modification entraîne des problèmes de concurrence, je décide de masquer les interruptions avant le traitement (cli), et de les démasquer ensuite à l’aide de  et sti. Je lance le driver. Pas de crash. Je commence à crier victoire, et au moment ou je lance mon script de déchargement, j’ai le droit à un écran bleu. Je regarde le code de déchargement, il ne fait absolument rien de méchant. Je relance, idem. Je finis par comprendre que ce n’est pas le déchargement du driver qui foire, mais juste le fait de lancer un programme, car cela provoque un défaut de page… C’est donc bien mon handler qui pose problème, mais où ?

Je supprime ma modification de variable globale, ça plante toujours. Pourtant je n’ai plus que cli et sti dans mon handler (en plus de l’appel au handler par défaut). Je retire sti et je constate que ça marche ! C’est donc cette instruction qui est responsable du plantage du driver… mais pourquoi ? En fait, il se trouve que lors des appels au handler de défaut de page, les interruptions sont déjà masquées. C’est dû au fait que l’interruption correspondant au défaut de page possède un descripteur dans l’IDT qui précise que l’IF doit être mis à 0 lors de l’appel du handler (c’est une interrupt gate, selon Intel). Ainsi, lors de l’appel au handler, l’instruction cli ne fait absolument rien (le bit IF d’EFLAGS est déjà à 0)… Le problème, c’est que sti le passe à 1, ce qui autorise les interuptions ! Si jamais le défaut de page s’est produit dans une zone critique de l’OS et qu’une interruption survient précisément à ce moment, le kernel se vautre. Cela ne se produit peut-être pas à tous les coups, mais croyez moi, ça arrive (faites le test pour vous en convaincre).

Comment patcher cela ? Ne pas masquer les interruptions dans un handler de défaut de page, puisqu’elles le sont déjà. La solution, c’est tout simplement de ne rien faire

Conclusion

Morale de l’histoire : utiliser DbgPrint() ou sti dans un handler de défaut de page est une mauvaise idée. Pour déboguer, préférez utiliser des variables globales plutôt que des fonctions à effet de bords incontrôlables. Et ne cherchez pas à masquer (et surtout à démasquer) les interruptions qui le sont déjà . J’espère que ce post vous aura épargné un long moment de galère. En tout cas, j’aurais aimé en lire un du même type plus tôt !

Privilèges des processeurs x86

Avant d’aborder le sujet, il est nécessaire de bien comprendre une subtilité des processeurs x86 : les niveaux de privilèges. Un processeur est censé exécuter du code machine produit par un compilateur / assembleur. Le code qui s’exécute à un instant t a accès à certains privilèges qui dépendent du niveau de privilège dans lequel se trouve le processeur. Ce niveau, aussi appelé ring, ou anneau, est un entier codé sur deux bits. Il peut donc prendre 4 valeurs : 0, 1, 2, et 3. Plus ce nombre est petit, plus les privilèges sont élevés ; plus il est grand, plus ils sont restreints. Le ring 0 est appelé mode superviseur, ou kernelland,et c’est sous ce mode que tournent 99% des noyaux d’OS (Windows et Linux en font partie). Les programmes utilisateurs s’exécutent quant à eux en ring 3, appelé mode utilisateur ou userland.

Le niveau de privilège courant du processeur est appelé CPL (Current Privilege Level). En interne, le CPL est stocké dans les deux premiers bits des registres CS et SS. La règle générale est la suivante : il n’est pas possible d’exécuter des instructions nécessitant un niveau de privilège inférieur au CPL. De même, il n’est pas directement possible de demander au processeur de changer le CPL vers un niveau inférieur. On peut donc se demander : comment est-ce possible d’appeler une routine du noyau depuis un code utilisateur ? C’est là tout l’objet de cet article…

Un programme d’exemple

Afin d’analyser comment se déroule un appel système, nous allons commencer par coder un programme d’exemple en C.

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

int main(int argc, char *argv[])
{
    HANDLE handle;
    WIN32_FIND_DATA findData;

    handle = FindFirstFile(".", &findData);

    printf("Handle = %dn", handle);

    getchar();

    return 0;
}

Ce programme appelle l’API Windows FindFirstFile. Cette fonction prend en paramètre un nom de dossier et retourne un handle vers le premier fichier de ce dossier. Je suis d’accord : ce programme ne sert pas à grand chose, à part appeler une API Windows, mais c’est justement le but.

Tracing en userland

Pour information, j’ai réalisé tous ces tests sur un Windows XP SP3 français, avec Dev-C++ et GCC 3.4.2. Une fois le programme compilé, on peut utiliser un débogeur pour suivre l’exécution du programme. Lançons OllyDbg et observons le main() du programme :

00401290  /$ 55             PUSH EBP
00401291  |. 89E5           MOV EBP,ESP
00401293  |. 81EC 78010000  SUB ESP,178
00401299  |. 83E4 F0        AND ESP,FFFFFFF0
0040129C  |. B8 00000000    MOV EAX,0
004012A1  |. 83C0 0F        ADD EAX,0F
004012A4  |. 83C0 0F        ADD EAX,0F
004012A7  |. C1E8 04        SHR EAX,4
004012AA  |. C1E0 04        SHL EAX,4
004012AD  |. 8985 A4FEFFFF  MOV DWORD PTR SS:[EBP-15C],EAX
004012B3  |. 8B85 A4FEFFFF  MOV EAX,DWORD PTR SS:[EBP-15C]
004012B9  |. E8 82040000    CALL syscalls.00401740
004012BE  |. E8 1D010000    CALL syscalls.004013E0
004012C3  |. 8D85 A8FEFFFF  LEA EAX,DWORD PTR SS:[EBP-158]           ; |
004012C9  |. 894424 04      MOV DWORD PTR SS:[ESP+4],EAX             ; |
004012CD  |. C70424 0030400>MOV DWORD PTR SS:[ESP],syscalls.00403000 ; |ASCII "fg"
004012D4  |. E8 E7050000    CALL <JMP.&KERNEL32.FindFirstFileA>      ; FindFirstFileA
004012D9  |. 83EC 08        SUB ESP,8
004012DC  |. 8945 F4        MOV DWORD PTR SS:[EBP-C],EAX             ; |
004012DF  |. 8B45 F4        MOV EAX,DWORD PTR SS:[EBP-C]             ; |
004012E2  |. 894424 04      MOV DWORD PTR SS:[ESP+4],EAX             ; |
004012E6  |. C70424 0330400>MOV DWORD PTR SS:[ESP],syscalls.00403003 ; |ASCII "Handle = %d"
004012ED  |. E8 4E050000    CALL <JMP.&msvcrt.printf>                ; printf
004012F2  |. E8 39050000    CALL <JMP.&msvcrt.getchar>               ; [getchar
004012F7  |. B8 00000000    MOV EAX,0
004012FC  |. C9             LEAVE
004012FD  . C3             RETN

Je rappelle que nous sommes à présent dans un programme utilisateur, donc en userland. Il est facile de le vérifier en regardant la valeur de CS. Chez moi, c'est 0x2B, soit 0b101011. Les deux premiers bits (poids faible) sont bien 0b11, correspondant au ring 3.

L'appel à FindFirstFile se trouve en 004012D4, après que les paramètres aient été mis sur la pile. Après avoir placé un breakpoint sur le call (F2), et lancé l'exécution (F9), le programme s'arrête dessus. On fait un step in (F7) pour suivre le call.

004018C0   $-FF25 B8504000  JMP DWORD PTR DS:[<&KERNEL32.FindFirstFileA>]

Nous nous situons à présent dans une zone appelée trampoline. Cette zone fait référence à l’IAT (Import Address Table) de l’exécutable, qui contient les adresses des fonctions importées. Pour faire le parallèle avec Linux, le trampoline est l’équivalent de la section .plt, et l’IAT joue le même rôle que la section .got. Pour plus d’informations sur ces sections je vous conseille de lire cet article.

Le jump fait référence à un pointeur situé en 004050B8, qui contient l’adresse de la fonction FindFirstFileA. On rappuie sur F7 pour suivre l’appel. On arrive alors dans la section .text de kernel32.dll, qui a été chargée à l’exécution.

7C813869 > 8BFF             MOV EDI,EDI
7C81386B   55               PUSH EBP
7C81386C   8BEC             MOV EBP,ESP
7C81386E   81EC 6C020000    SUB ESP,26C
...
7C813894   56               PUSH ESI
7C813895   56               PUSH ESI
7C813896   56               PUSH ESI
7C813897   8D8D ACFDFFFF    LEA ECX,DWORD PTR SS:[EBP-254]
7C81389D   51               PUSH ECX
7C81389E   56               PUSH ESI
7C81389F   FF70 04          PUSH DWORD PTR DS:[EAX+4]
7C8138A2   E8 66B2FFFF      CALL kernel32.FindFirstFileExW

On s’aperçoit que cette fonction en appelle une autre, FindFirstFileExW, toujours dans kernel32. Pourquoi ? Simplement parce que la plupart des fonctions internes de Windows utilisent un encodage Unicode, et non pas ASCII. Dans la convention Windows, les fonctions se terminant par un A gèrent l’ASCII, et celles en W gèrent l’Unicode. En interne, les fonctions ASCII convertissent les paramètres passés en Unicode, et appèlent les fonctions Unicode correspondantes. C’est le call que nous venons de voir. Suivons le.

7C80EB0D > 8BFF             MOV EDI,EDI
7C80EB0F   55               PUSH EBP
7C80EB10   8BEC             MOV EBP,ESP
7C80EB12   81EC CC020000    SUB ESP,2CC
...
7C80EC66   57               PUSH EDI
7C80EC67   8D85 90FDFFFF    LEA EAX,DWORD PTR SS:[EBP-270]
7C80EC6D   89B5 40FDFFFF    MOV DWORD PTR SS:[EBP-2C0],ESI
7C80EC73   8B35 1410807C    MOV ESI,DWORD PTR DS:[<&ntdll.NtOpenFile>] ; ZwOpenFile
7C80EC79   50               PUSH EAX
7C80EC7A   C785 34FDFFFF 18>MOV DWORD PTR SS:[EBP-2CC],18
7C80EC84   FFD6             CALL ESI
...
7C80ED46   FFB5 90FDFFFF    PUSH DWORD PTR SS:[EBP-270]
7C80ED4C   FF15 2812807C    CALL DWORD PTR DS:[<&ntdll.NtQueryDirectoryFile>]

On voit que cette fonction réalise plusieurs appels (ici je n’en n’ai affiché que 2 mais il y en a d’autres) dans ntdll.dll, une autre DLL chargée. Continuons notre traçing en explorant l’appel à ZwOpenFile.

7C91D580 > B8 74000000      MOV EAX,74
7C91D585   BA 0003FE7F      MOV EDX,7FFE0300
7C91D58A   FF12             CALL DWORD PTR DS:[EDX]  ; ntdll.KiFastSystemCall
7C91D58C   C2 1800          RETN 18

Transition vers le mode noyau

Nous sommes à présent dans ntdll.dll, dans la fonction ZwOpenFile exportée par la dll. Comme vous le voyez, la fonction est très courte. La première instruction place 0×74 dans EAX, qui correspond au numéro de la fonction du noyau qui va être appelée. On a ensuite un appel à une fonction nommée KiFastSystemCall. C’est elle qui va réaliser le passage en mode noyau, à l’aide des instructions suivantes :

7C91E4F0 > 8BD4             MOV EDX,ESP
7C91E4F2   0F34             SYSENTER
7C91E4F4 > C3               RETN

C’est précisément SYSENTER qui réalise la transition. Mais que fait donc cette instruction ? On ouvre le manuel Intel 2B au chapitre 4.1, instruction SYSENTER. On y apprend que cette instructionpermet d’exécuter des appels systèmes. Historiquement, les appels systèmes étaient exécutés en utilisant les interruptions logicielles, avec l’instruction INT 2E sous Windows (et INT 80 sous Linux). SYENTER étant plus rapide, elle a succédé à l’ancienne méthode, qui reste toutefois disponible pour des raisons de compatibilité.

Contrairement aux interruptions, SYSENTER n’utilise pas de table de pointeurs, mais des registres spéciaux du processeur, appelés MSR (pour Model Specific Register). Ces registres sont assez particuliers ; ils possèdent un numéro et sont accessibles en lecture et écriture via les instructions rdmsr et wrmsr. SYSENTER en utilise 3 :

• IA32_SYSENTER_CS (0×174) correspond à la valeur à charger dans CS quand SYSENTER sera appelé
• IA32_SYSENTER_ESP (0×175) sera quant à lui chargé dans ESP
• IA32_SYSENTER_EIP (0×176) sera chargé dans EIP

Ainsi, ces trois registres définissent tout ce qu’il faut pour exécuter un bout de code en mode en mode noyau, puisque CS (et donc ses deux premiers bits, encodant le CPL) sera changé.

Ces registres ne sont pas lisibles en mode utilisateur ; il faut impérativement être en ring 0 pour les lire. Pour cela, utilisons Windbg, le débogueur noyau de Microsoft. Il se télécharge ici, vous trouverez également des informations pour la configuration des symboles sur cette page.

Lançons Windbg en local kernel debugging (Cltrl K puis local). Dans l’invite de commande, tapons :

lkd> rdmsr 174
msr[174] = 00000000`00000008
lkd> rdmsr 176
msr[176] = 00000000`80541520

Nous voyons donc que IA32_SYSENTER_CS = 0×8 (donc avec un niveau de privilège à 0) et IA32_SYSENTER_EIP = 80541520. Au passage, on notera que cette adresse est supérieur à 80000000, c’est à dire en mode noyau, puisque Windows divise l’espace d’adressage de tout processus en 2 : 2 Go pour l’utilisateur (de 00000000 à 7FFFFFFF) et 2 Go pour le noyau (de 80000000 à FFFFFFFF). Regardons ce qui se trouve en 80541520 :

lkd> u 80541520 80541520+100     //desassemble les 100 premiers octets
nt!KiFastCallEntry:
80541520 b923000000      mov     ecx,23h
80541525 6a30            push    30h
80541527 0fa1            pop     fs
80541529 8ed9            mov     ds,cx
8054152b 8ec1            mov     es,cx
...
80541600 8b3f            mov     edi,dword ptr [edi]
80541602 8b1c87          mov     ebx,dword ptr [edi+eax*4]
80541605 2be1            sub     esp,ecx
80541607 c1e902          shr     ecx,2
8054160a 8bfc            mov     edi,esp
8054160c 3b3534215680    cmp     esi,dword ptr [nt!MmUserProbeAddress (80562134)]
80541612 0f83a8010000    jae     nt!KiSystemCallExit2+0x9f (805417c0)
80541618 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
8054161a ffd3            call    ebx

On voit que la fonction s’appelle KiFastCallEntry et se trouve dans le module nt qui correspond à ntoskrnl.exe, un des exécutables du noyau.

Après plusieurs vérifications de paramètres, la fonction KiFastCallEntry charge une table dans EDI (après les « … »). Il s’agit de la SSDT (Service System Dispatch Table), une table très importante du noyau qui a un rôle similaire à la table d’interruptions (IDT). Elle sert à dispatcher les appels systèmes vers la bonne fonction. Le symbole correspondant à la SSDT se nomme KiServiceTable, et est exporté par le noyau. Voici le début de son contenu :

lkd> dds KiServiceTable
80504450  805a4614 nt!NtAcceptConnectPort
80504454  805f0adc nt!NtAccessCheck
80504458  805f4312 nt!NtAccessCheckAndAuditAlarm
8050445c  805f0b0e nt!NtAccessCheckByType
80504460  805f434c nt!NtAccessCheckByTypeAndAuditAlarm

Souvenez-vous : juste avant le SYSENTER, on a placé le numéro d’appel système dans EAX. Ce registre va être utilisé ici afin de servir d’index dans cette table et de trouver le pointeur de la fonction à appeler. L’instruction suivante multiplie justement EAX par 4 (la taille d’une entrée dans la table) et l’ajoute à l’adresse de début de la table contenu dans EDI. Le résultat est place dans EBX. Et quelques instructions plus loin, on trouve… un call EBX

Faisons le calcul nous même : nous connaissons le numéro d’appel système (0×74) :

lkd> dds KiServiceTable+0x74*4
80504620  8057a182 nt!NtOpenFile

Bingo, voila la fonction NtOpenFile : c’est elle qui sera exécutée lors du call EBX.

Retour en userland

Notre reversing peut s’arrêter ici. Nous n’allons pas désassembler cette fonction car ce n’est pas le but de l’article. Concernant le retour de l’appel système, on peut, en désassemblant la suite de KiFastCallEntry , voir que la fonction KiServiceExit va être appelée. A son tour, elle appelle une des deux fonctions KiSystemCallExit ou KiSystemCallExit2. La première revient en mode utilisateur en utilisant l’instruction IRET, et l’autre le fait en utilisant SYSEXIT (c’est celle là qui sera appelée dans notre cas). Cette instruction rebascule en userland et restaure EIP. On se retrouve alors dans ZwOpenFile, de ntdll.

Conclusion

Au travers de cet article, nous avons tracé l’exécution d’un programme utilisateur afin de comprendre comment il passe en mode noyau afin d’exécuter des instructions privilégiées.  Nous avons vu comment fonctionne l’instruction SYSENTER et le rôle de la SSDT.

On peut alors imaginer plusieurs hooks possibles exploitant ce schéma de fonctionnement. Au niveau utilisateur, on peut hooker l’entrée de l’IAT correspondant à la fonction à appeler. En mode noyau, il y a plusieurs possibilités. La première serait de remplacer l’adresse de la fonction à appeler dans la SSDT par une autre fonction qui appelle l’originale et effectue un filtrage en entrée et en sortie. Une autre serait de modifier carrément le registre IA32_SYSENTER_EIP en le faisant pointer sur une autre routine de traitement. L’équivalent pour les vieilles versions de Windows utilisant les interruptions serait de modifier le registre IDTR contenant l’adresse de la table des interruptions, ou bien de hooker l’entrée 2E dans cette table. Enfin, une dernière solution, radicale mais fonctionnelle, serait de faire un hook inline de la fonction pointée, en remplaçant ses premiers octets par un call d’une autre fonction. Comme vous le voyez, les possibilités de hook sont innombrables, les plus « profondes » étant bien souvent les plus indétectables…

Références

• Ivanlef0u’s Blog – SSDT Hooking Reinvented
• Ivanlef0u’s Blog – SYSENTER, stepping into da ring0
• Rootkits – Subverting the Windows Kernel, Greg Hoglund et Jamie Butler
  
• Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B, Chapitre 4.1, Instruction SYSENTER
• Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, Chapitre 4.5
• Debugging Tools for Windows
• Debugging Tools and Symbols: Getting Started