Stats

  • Total des pages vues: 15609
  • Pages vues aujourd'hui: 105
  • Visiteurs connectés: 1
  • Nombre de visiteurs: 9833

First steps in ring0

Written by aaSSfxxx - 15 july 2012

Ceux qui me croisent sur IRC savent que je commence à me mettre (timidement) à la programmation ring0 sous Windows (the real life, je jouerai avec le kernel linux un peu plus tard peut-être, quand je serai réapprovisionné en chocapicz).
Cet article se veut être une initiation au monde merveilleux qu'est le noyau Windows et ses drivers, monde merveilleux où un BSOD arrive très vite cependant.

Devant l'enthousiasme général, je vous propose donc de me suivre dans cette longue quête du Graal.

Préparation de l'environnement: the h4x0r way

Pour explorer le monde du noyau, une petite préparation s'impose. En effet, la programmation de driver diffère de la programmation d'un programme Windows classique, puisque le driver est chargé par le noyau, et donc il est plus difficile d'y accéder pour le déboguer. De plus, nos chères APIs Windows ne sont d'aucune utilité ici, et il nous faudra passer par les fonctions du noyau pour arriver à nos fins (plus ou moins documentées). Pour le développement de drivers, je vous recommande fortement de le faire depuis une machine virtuelle (ou depuis un PC "sacrifié"), un BSOD étant très vite arrivé.

Il nous faudra dans un premier temps installer un compilateur C (si ceci n'a pas déjà été fait). Que les libristes ou les réfractaires de Visual Studio se rassurent, il est tout à fait possible de compiler un driver avec MinGW, qui installe nativement les en-têtes nécessaires (et Code::Blocks, ce que je montrerai dans l'article). Si vous voulez malgré tout utiliser le compilateur MSVC, je vous laisse stfw pour la procédure d'installation du DDK.
Code::Blocks propose par ailleurs un modèle "Windows Driver" dont il serait bête de se priver. Il faudra juste veiller à rajouter le dossier "include\ddk" du répertoire d'installation de MinGW aux répertoires d'include pour que la compilation réussisse sans problème.

Avant de continuer, il nous faut aussi deux éléments indispensable: DebugView, qui permet d'afficher les messages de débogage du noyau (via la fonction DbgPrint), qui sera notre seul moyen de vérifier que tout fonctionne bien pour le moment ; ainsi que InstDrv, qui va permettre de charger notre driver. InstDrv est téléchargeable ici, et DebugView est disponible ici. Il faudra évidemment veiller à lancer DebugView avant de charger le driver avec InstDrv pour voir les messages (et afficher les messages du noyau, en cochant le menu "Capture -> Capture kernel", ainsi que "Catpure -> Enable Verbose Kernel Output").
Une fois ceci fait, nous voilà prêt pour créer notre premier driver !

Your first driver !

Il ne vous reste plus qu'à créer un nouveau projet du type "Kernel mode driver" sous Code::Blocks (et stfw si vous utilisez autre chose :þ). Cela nous crée un fichier driver.c qui contient:

Code C :
  1. #include <ntddk.h>
  2. NTSTATUS
  3. STDCALL
  4. DriverDispatch(IN PDEVICE_OBJECT DeviceObject,
  5.                IN PIRP Irp)
  6. {
  7.     return STATUS_SUCCESS;
  8. }
  9.  
  10. VOID
  11. STDCALL
  12. DriverUnload(IN PDRIVER_OBJECT DriverObject)
  13. {
  14.     DbgPrint("DriverUnload() !\n");
  15.     return;
  16. }
  17.  
  18. NTSTATUS
  19. STDCALL
  20. DriverEntry(IN PDRIVER_OBJECT DriverObject,
  21.             IN PUNICODE_STRING RegistryPath)
  22. {
  23.     DbgPrint("DriverEntry() !\n");
  24.  
  25.     DriverObject->DriverUnload = DriverUnload;
  26.  
  27.     return STATUS_SUCCESS;
  28. }    
  29.  
La fonction principale est DriverEntry, comme on peut s'y attendre ; et je vous laisse demander à votre petite soeur ce que fait DriverUnload. La fonction DriverDispatch semble, elle plus bizarre. Cette fonction servira à gérer les IRP (je reviendrai sur ce point), mais n'est pas d'une grande utilité pour le moment.

Pour le moment contentons-nous de charger le driver avec InstDrv (normalement votre grand-mère devrait pouvoir le faire), et admirer le "DriverEntry() !" qui s'affiche dans DebugView (qu'il faut lancer avant de démarrer le driver). En cliquant sur le bouton "Stop" de InstDrv, on doit voir apparaître "DriverUnload() !" apparaître (si c'est pas le cas, vous pouvez toujours vous reconvertir dans l'élevage de chèvres).

On ne va pas s'arrêter en si bon chemin, et on va découvrir comment sortir notre driver de son autisme, et comment lui permettre de communiquer avec le monde utilisateur que nous connaissons bien, nous, humains.

Une histoire de devices et d'IRP

Notre driver est pour le moment un pauvre autiste, incapable de communiquer avec le monde extérieur. Un moyen assez simple de lui permettre de communiquer vers l'extérieur est de créer un "device" (du point de vue du kernel, ne rêvez pas, une imprimante 3D ne va pas se matérialiser subitement) qui sera accessible depuis l'userland (chez Mme Michu) via la fonction CreateFile. Une fois le "fichier" créé (point commun avec les systèmes UNIX-like, un device est un fichier), on peut soit lui envoyer des IOCTL, soit utiliser les fonctions ReadFile et WriteFile ; ces deux méthodes envoyant des IRP à notre driver, qu'il devra rattraper et traiter.
Une IRP est en réalité une structure qui "représente" une opération d'entrée/sortie sur le driver. Ainsi toutes les opérations de lecture ou d'écriture sont des IRP du point de vue du driver. Heureusement pour nous, Windows propose un moyen de filtrer les IRP, et de définir des fonctions "handler" permettant de traiter ces IRP (du même prototype que DriverDispatch).

Du point de vue programmation, on crée un device via la fonction IoCreateDevice, avec le code suivant qu'on placera dans DriverEntry, puis on crée un lien symbolique vers DosDevices pour rendre notre device accessible depuis l'userland (via \\.\NomDuDevice):

Code C :
  1.     NTSTATUS ntStatus;
  2.     const WCHAR *driverName = L"\\Device\\T4pZ";
  3.     const WCHAR *symlinkName = L"\\DosDevices\\T4pZ";
  4.  
  5.     UNICODE_STRING unicodeDriverName;
  6.     UNICODE_STRING unicodeSymlink;
  7.  
  8.     RtlInitUnicodeString(&unicodeDriverName, driverName);
  9.     RtlInitUnicodeString(&unicodeSymlink, symlinkName);
  10.  
  11.     ntStatus = IoCreateDevice (
  12.         DriverObject,
  13.         0,
  14.         &unicodeDriverName,
  15.         FILE_DEVICE_UNKNOWN,
  16.         0,
  17.         TRUE,
  18.         &mydevice);
  19.     mydevice->Flags |= DO_BUFFERED_IO;
  20.  
  21.     if(NT_SUCCESS(ntStatus))
  22.     {
  23.         DbgPrint("THE GAME BITCHZ\n");
  24.         IoCreateSymbolicLink(&unicodeSymlink, &unicodeDriverName);
  25.     }
  26.  
. Il ne faudra pas oublier de rajouter
Code C :
  1. PDEVICE_OBJECT mydevice;
en variable globale, afin de pouvoir utiliser IoDeleteDevice dans la fonction DriverUnload (sous peine de devoir rebooter la machine ou de changer le nom du device ensuite). On a donc pour le moment ce code de driver, qui crée un device, mais qui ne fait rien pour le moment:
Code C :
  1. #include <ntddk.h>
  2.  
  3. PDEVICE_OBJECT mydevice;
  4.  
  5. NTSTATUS
  6. STDCALL
  7. DriverDispatch(IN PDEVICE_OBJECT DeviceObject,
  8.                IN PIRP Irp)
  9. {
  10.     return STATUS_SUCCESS;
  11. }
  12.  
  13. VOID
  14. STDCALL
  15. DriverUnload(IN PDRIVER_OBJECT DriverObject)
  16. {
  17.     DbgPrint("DriverUnload() !\n");
  18.     IoDeleteDevice(mydevice); // destruction du device sinon on est bon pour rebooter
  19.     return;
  20. }
  21.  
  22. NTSTATUS
  23. STDCALL
  24. DriverEntry(IN PDRIVER_OBJECT DriverObject,
  25.             IN PUNICODE_STRING RegistryPath)
  26. {
  27.     NTSTATUS ntStatus;
  28.     const WCHAR *driverName = L"\\Device\\T4pZ";
  29.     const WCHAR *symlinkName = L"\\DosDevices\\T4pZ";
  30.  
  31.     UNICODE_STRING unicodeDriverName;
  32.     UNICODE_STRING unicodeSymlink;
  33.  
  34.     DbgPrint("DriverEntry() !\n");
  35.  
  36.     DriverObject->DriverUnload = DriverUnload;
  37.     
  38.     RtlInitUnicodeString(&unicodeDriverName, driverName);
  39.     RtlInitUnicodeString(&unicodeSymlink, symlinkName);
  40.  
  41.     ntStatus = IoCreateDevice (
  42.         DriverObject,
  43.         0,
  44.         &unicodeDriverName,
  45.         FILE_DEVICE_UNKNOWN,
  46.         0,
  47.         TRUE,
  48.         &mydevice);
  49.     mydevice->Flags |= DO_BUFFERED_IO;
  50.  
  51.     if(NT_SUCCESS(ntStatus))
  52.     {
  53.         IoCreateSymbolicLink(&unicodeSymlink, &unicodeDriverName);
  54.     }
  55.     return STATUS_SUCCESS;
  56. }
  57.  

Gestion des IRP

Une fois notre device créé et un handle ouvert par un programme userland quelconque, notre driver se fait bombarder d'IRPs qu'il ne sait pas traiter. Pour simplifier les choses, on ne traitera ici que les requêtes envoyées par ReadFile et WriteFile, et faire en sorte qu'un appel de WriteFile sur le handle de notre device affiche ce qui a été écrit avec DbgPrint, et qu'un appel à ReadFile renvoie "Salut les tapz !" (l'exemple est inutile, mais assez instructif).

Avant de passer du côté codingz de la Force, il faut savoir qu'il existe 3 modes différents de lecture/écriture des données passées dans un IRP,définis par le champs Flags de la structure PEDVICE_OBJECT (expliqués en mieux ici):

  • Le Direct Mode: dans ce mode, le kernel remplit la structure MdlAddress, qui est un pointeur vers une structure qui décrit le tampon de donnée (et il faudra utiliser les fonctions commençant Mm pour y accéder)
  • Le "Buffered I/O": ici le buffer est stocké dans le champ AssociatedIrp.SystemBuffer de la structure IRP, ce buffer étant une "copie" faite par le kernel du tampon fourni par l'utilisateur.
  • Le Neither Mode: ce mode donne un accès direct au tampon utilisateur, via le champ UserBuffer de la structure IRP.

Comme vous l'avez remarqué, j'ai utilisé le mode Buffered I/O dans le code, le direct mode étant assez "fastidieux" à utiliser. Grâce à ces précieuses informations, on va enfin pouvoir implémenter l'IRP associé à WriteFile (le plus facile), dont le doux nom est IRP_MJ_WRITE. Voici donc le code de notre handler de IRP_MJ_WRITE:

Code C :
  1. NTSTATUS
  2. STDCALL
  3. WriteFunction(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
  4. {
  5.   DbgPrint("Write Function called");
  6.   if(Irp->AssociatedIrp.SystemBuffer != 0) {
  7.     DbgPrint("Got data from SystemBuffer: %s ", Irp->AssociatedIrp.SystemBuffer);
  8.   }
  9.   else {
  10.     //on rattrape l'erreur pour pas se prendre un BSOD dans la face
  11.     DbgPrint("OMGWTFBBQ is that shit ?");
  12.   }
  13.   return STATUS_SUCCESS;
  14. }
  15.  
Cependant, le kernel n'est pas au courant de l'existence de cette fonction, et il faut donc lui déclarer son existence grâce à la ligne
Code C :
  1. DriverObject->MajorFunction[IRP_MJ_WRITE] = WriteFunction;
dans notre fonction DriverEntry. Ainsi, un appel à WriteFile provoquera l'affichage de ce qui a été écrit dans DebugView.

Pour l'IRP Read, c'est un peu plus compliqué, puisque le buffer fourni par le programme userland a une taille fixée, et il se peut que les données à envoyer soient trop grosses pour le pauvre buffer. Pour la fonction de lecture, il faut donc récupérer la taille du buffer, s'assurer que les données à envoyer ne dépassent pas et indiquer le nombre d'octets écrits une fois la transmission terminée. Pour obtenir ces informations, il nous faut obtenir la structure IO_STACK_LOCATION, ce qui est possible grâce à la fonction IoGetCurrentIrpStackLocation. Je vous laisse lire la documentation de IRP_MJ_READ, pour comprendre le fonctionnement du code (qui devrait être assez simple à comprendre).

Code C :
  1. NTSTATUS
  2. STDCALL
  3. ReadFunction(IN PDEVICE_OBJECT DeviceObject,
  4.                       IN PIRP Irp)
  5. {
  6.   PIO_STACK_LOCATION IrpSp = IoGetCurrentIrpStackLocation(Irp);
  7.   DbgPrint("Read Function called");
  8.   DbgPrint("Asking reading %d bytes", IrpSp->Parameters.Read.Length);
  9.   if(Irp->AssociatedIrp.SystemBuffer != 0)
  10.   {
  11.       DbgPrint("Sending \"Salut les t4pz !\" to reader");
  12.       char *data = "Salut les t4pz !";
  13.       int mini = min(IrpSp->Parameters.Read.Length, 17); // 17 = strlen(data)
  14.       memcpy(Irp->AssociatedIrp.SystemBuffer, data, mini);
  15.       Irp->IoStatus.Status = STATUS_SUCCESS;
  16.       Irp->IoStatus.Information = mini;
  17.   }
  18.   else {
  19.     //on rattrape l'erreur pour pas se prendre un BSOD dans la face
  20.     DbgPrint("OMGWTFBBQ is that shit ?");
  21.   }
  22.   return STATUS_SUCCESS;
  23. }
, et on enregistre notre ReadFunction comme ci-dessus.

Le code au complet nous donne finalement ceci:

Code C :
  1. #include <ntddk.h>
  2.  
  3. PDEVICE_OBJECT mydevice;
  4.  
  5. NTSTATUS
  6. STDCALL
  7. DriverDispatch(IN PDEVICE_OBJECT DeviceObject,
  8.                IN PIRP Irp)
  9. {
  10.     return STATUS_SUCCESS;
  11. }
  12.  
  13. NTSTATUS
  14. STDCALL
  15. ReadFunction(IN PDEVICE_OBJECT DeviceObject,
  16.                       IN PIRP Irp)
  17. {
  18.   PIO_STACK_LOCATION IrpSp = IoGetCurrentIrpStackLocation(Irp);
  19.   DbgPrint("Read Function called");
  20.   DbgPrint("Asking reading %d bytes", IrpSp->Parameters.Read.Length);
  21.   if(Irp->AssociatedIrp.SystemBuffer != 0)
  22.   {
  23.       DbgPrint("Sending \"Salut les t4pz !\" to reader");
  24.       char *data = "Salut les t4pz !";
  25.       int mini = min(IrpSp->Parameters.Read.Length, 17); // 17 = strlen(data)
  26.       memcpy(Irp->AssociatedIrp.SystemBuffer, data, mini);
  27.       Irp->IoStatus.Status = STATUS_SUCCESS;
  28.       Irp->IoStatus.Information = mini;
  29.   }
  30.   else {
  31.     //on rattrape l'erreur pour pas se prendre un BSOD dans la face
  32.     DbgPrint("OMGWTFBBQ is that shit ?");
  33.   }
  34.   return STATUS_SUCCESS;
  35. }
  36.  
  37. NTSTATUS
  38. STDCALL
  39. WriteFunction(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
  40. {
  41.   DbgPrint("Write Function called");
  42.   if(Irp->AssociatedIrp.SystemBuffer != 0) {
  43.     DbgPrint("Got data from SystemBuffer: %s ", Irp->AssociatedIrp.SystemBuffer);
  44.   }
  45.   else {
  46.     //on rattrape l'erreur pour pas se prendre un BSOD dans la face
  47.     DbgPrint("OMGWTFBBQ is that shit ?");
  48.   }
  49.   return STATUS_SUCCESS;
  50. }
  51.  
  52. VOID
  53. STDCALL
  54. DriverUnload(IN PDRIVER_OBJECT DriverObject)
  55. {
  56.     DbgPrint("DriverUnload() !\n");
  57.     IoDeleteDevice(mydevice); // destruction du device sinon on est bon pour rebooter
  58.     return;
  59. }
  60.  
  61. NTSTATUS
  62. STDCALL
  63. DriverEntry(IN PDRIVER_OBJECT DriverObject,
  64.             IN PUNICODE_STRING RegistryPath)
  65. {
  66.     NTSTATUS ntStatus;
  67.     const WCHAR *driverName = L"\\Device\\T4pZ";
  68.     const WCHAR *symlinkName = L"\\DosDevices\\T4pZ";
  69.  
  70.     UNICODE_STRING unicodeDriverName;
  71.     UNICODE_STRING unicodeSymlink;
  72.  
  73.     DbgPrint("DriverEntry() !\n");
  74.  
  75.     DriverObject->MajorFunction[IRP_MJ_CREATE] = DriverDispatch; //on fait rien à l'ouverture et à la fermeture du "fichier"
  76.     DriverObject->MajorFunction[IRP_MJ_CLOSE] = DriverDispatch;
  77.     DriverObject->MajorFunction[IRP_MJ_READ] = ReadFunction;
  78.     DriverObject->MajorFunction[IRP_MJ_WRITE] = WriteFunction;
  79.     DriverObject->DriverUnload = DriverUnload;
  80.     
  81.     RtlInitUnicodeString(&unicodeDriverName, driverName);
  82.     RtlInitUnicodeString(&unicodeSymlink, symlinkName);
  83.  
  84.     ntStatus = IoCreateDevice (
  85.         DriverObject,
  86.         0,
  87.         &unicodeDriverName,
  88.         FILE_DEVICE_UNKNOWN,
  89.         0,
  90.         TRUE,
  91.         &mydevice);
  92.     mydevice->Flags |= DO_BUFFERED_IO;
  93.  
  94.     if(NT_SUCCESS(ntStatus))
  95.     {
  96.         IoCreateSymbolicLink(&unicodeSymlink, &unicodeDriverName);
  97.     }
  98.     return STATUS_SUCCESS;
  99. }

The userland code

Maintenant, compilez et lancez le driver, puis créez un exécutable classique contenant ce code:

Code C :
  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <windows.h>
  4. int main()
  5. {
  6.     HANDLE hDevice = CreateFile("\\\\.\\T4pZ",GENERIC_WRITE|
  7.         GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
  8.     DWORD written, read;
  9.     char buffer[255];
  10.     WriteFile (hDevice, "THE GAME", 9, &written, NULL);
  11.     ReadFile (hDevice, buffer, 255, &read, NULL);
  12.     printf ("Got \"%s\" from the kernel - %d bytes read\n", buffer, read);
  13.     printf("hDevice handle: %x", hDevice);
  14.     return 0;
  15. }
, puis lancez l'exécutable.

Vous devriez voir apparaître "Got data from SystemBuffer: THE GAME" dans DebugView, puis "Salut les tapz !" dans la console du programme lancé.

Voilà pour cette introduction à la programmation système sous Windows :þ

Classified in : Hacking & Programming - Tags : ring0, windows, kernel, IRP

tuesday 09 april 2013 @ 13:28 Ching said : #1

Avatar GravatarSuper article merci beaucoup (:

saturday 13 april 2013 @ 11:18 Xash said : #2

Avatar GravatarUn article digne d'un poney tel que toi ! Merci :]

wednesday 01 may 2013 @ 16:57 erik said : #3

Avatar GravatarMerci Merci !!!! Tu ma permis de comprendre le rôle de ioCreateDevice ET de s'en servir depuis l'userland
avec l api de CreateFile .
ENCORE MERCI

thursday 09 may 2013 @ 12:50 aaSSfxxx said : #4

Avatar Gravatar@erik : De rien :p (désolé pour le temps de réponse, je mettais à jour mon thème :þ). Enfin dans l'article j'ai choisi d'implémenter les IRP IRP_MJ_READ et IRP_MJ_WRITE pour permettre la lecture/écriture avec ReadFile & WriteFile, cependant il est tout à fait possible de créer ses propres IRP, mais qu'on ne peut appeler qu'avec DeviceIoControl.

Comments are closed.