DDK et Delphi ?

**- Robby -** · 19/12/2003, 17h22

Merci pour ta réponse fd.

Oui, si tu arrives a trouver la réponse précise a cette question,
elle m'intéresse énormément.

Oui ! GetProcessAdress via LoadLibrary !
Peut etre qu'avec " NtVdm.exe ", ca fonctionne, possible !
Mais si tu essayes d'extraire dynamiquement par cette méthode le code d'une fonction de " NtOsKrnl.exe " , ca ne fonctionne pas.
Oui, le LoadLibrary et le GetProcessAdress vont fonctionner.
Tu chargeras effectivement NtOsKrnl.exe dans la mémoire de ton process, et tu obtiendras bien l'adresse de départ de ta fonction avec GetProcessAdress. Apparemment tout fonctionnera. Mais le code de ta fonction sera un code inexploitable ... dynamiquement mort ... s'il y a la moindre référence d'adresse a un élément réel du kernel, c'est foutu.
Le "vrai" NtOsKrnl.exe ... qui tourne dans le kernel, et une copie de son code dans la mémoire de ton process, c'est pas du tout la meme chose !
Mais NtVdm.exe n'est pas une partie du kernel, il est donc possible que cette technique fonctionne dans ce cas.

Pour le ddk xp ... je m'étais un peu perdu dans l'arbre des répertoires.
C'est un peu un labyrinthe ce truc. Mais tu me dis qu'il y a effectivement des exemples de drivers. Je vais donc reprendre répertoire par répertoire.
Si jamais tu as en tete le path des exemples que tu as trouvé ...

respect a toi fd,

fd · 19/12/2003, 17h26

pour avoir les exemples faut l'installer

**- Robby -** · 19/12/2003, 17h37

bein heu ..., je l'ai installé fd ...
et tu fais comment pour acceder aux exemples ?
Un sous répertoire de c:\winddk\2600.1106\ .... je suppose ?
Chez moi, l'arbre du dkk débute comme ca.

[edit] je pense avoir trouvé.
Tous les exemples sont dans le répertoire " src\ ".
J'ai encore du mal a reconnaitre simplement " a l'oeil ",
les lignes C constituant un driver.
Fd, n'y a t il QUE des exemples de Drivers dans ce répertoire " src\ " ?
Ou y a t il aussi autres choses ?
merci a toi.

fd · 22/12/2003, 09h49

En gros tu as :
dans sys le driver
dans exe un applicatif utilisant le driver

**- Robby -** · 22/12/2003, 12h53

Merci pour ta réponse fd.
Le sujet est terminé, je pense bien.
reste a expérimenter tout ca !
Si je devais plus tard te poser une question spécifique,
j'ouvrirai alors un nouveau sujet ... probablement sur le forum Visual C++ .
Merci pour votre présence a tous tout au long de ce débat.
Bonnes fetes de fin d'année a tous.

**LeRoi** · 17/02/2007, 16h44

Franchment, j'ai pas trop compris ce qu'a ete ecrit dans les pages précedantes ...
Mais, j'ai tomber récemment sur une page, qui semble toucher a ce sujet, donc voici le lien:

http://hxdef.org/download.php

Il s'agit d'un "Delphi Driver Development Kit v0.0.4"
A vous de voir....

**- Robby -** · 22/02/2007, 00h35

Février 2007 ... déjà !
Non, maintenant, c'est certain, les Driver Mode Kernel, n'ont plus de secrets pour moi (presque plus). DriverEntry, les MajorFunctions, et tous le reste. Mais j'ai du me mettre au C. Pas par impossibilité, mais par facilité. Avec le DDK intégré dans l'environnement de Visual Studio .Net 2003 ... plus éventuellement Driver Srudio intégré aussi .... et pourquoi pas IDA aussi ... il y a moyen de s'amuser.

**sepullayer** · 22/03/2007, 14h16

Heu .. juste pour que je vois les choses plus clairement :

Ce que vous appeliez précédement le mode ring 0, c'est le mode protégé du micro. * ? Parce que à ma connaissance il l'est déjà pour faire tourner l'OS, donc où est l'utilité ?

* je dis ça car le seul moment où jutilise la création de gdt idt ... c'est lors du passage en mode portégé. Pour repasser en mode réel il n'y a qu'à les lire normalement ?!

Tous ça c'est juste par curiosité personnelle.

**Mat.M** · 22/03/2007, 14h38

Envoyé par sepullayer

Heu .. juste pour que je vois les choses plus clairement :

Ce que vous appeliez précédement le mode ring 0, c'est le mode protégé du micro. * ? Parce que à ma connaissance il l'est déjà pour faire tourner l'OS, donc où est l'utilité ?
* je dis ça car le seul moment où jutilise la création de gdt idt ... c'est lors du passage en mode portégé. Pour repasser en mode réel il n'y a qu'à les lire normalement ?!

*mode protégé soi dit en passant c'est un méchanisme que l'on trouve seulement sur les CPU Intel et compatibles ( AMD)
*eh non en ring 0 on y loge d'abord les gestionnaires de périphériques ( Device Drivers),l'OS il me semble étant logé un cran au-dessus

**sepullayer** · 22/03/2007, 15h13

Ah, je croyais que ce mode avait été reprit par tous les x86.

Le mode ring 0 est donc complètement étrangé au mode protégé et ses gdt idt ... ?

**Neitsa** · 22/03/2007, 17h31

Bonjour,

eh non en ring 0 on y loge d'abord les gestionnaires de périphériques ( Device Drivers),l'OS il me semble étant logé un cran au-dessus

Le mode protégé implémente 4 niveau de protections sous x86. Seuls deux sont utilisés sous les systèmes actuels, le niveau 3 et le niveau 0.

Le mode le plus privilégié (mode ayant le plus de "pouvoir"), est dit mode noyau ("kernel mode" en anglais) ou plus simplement ring0 (anneau de protection 0).

C'est là où se loge le noyau du système d'exploitation, mais certaines partie de ce dernier fonctionne dans le mode le moins privilégié (mode utilisateur, "user mode" ou encore "ring 3").

sous Windows, le kernel et les drivers sont logés à la même enseigne (même anneau de protection).

Le mode ring 0 est donc complètement étrangé au mode protégé et ses gdt idt ... ?

En mode protégé, seul le mode ayant le plus de pouvoir est apte à changer les informations de la GDT ou de l'IDT (et d'autres registres, structures ou tableaux internes).

La protection du changement de la GDT ou l'IDT est implémentée au niveau hardware : les instructions d'écriture ne sont pas pas disponibles en ring3 étant donné que le CPL [code privilege level] - rattaché au descripteur de segment CS - est interrogé avant l'exécution d'une instruction visant à écrire dans la GDT ou l'IDT. Si nous sommes en mode utilisateur (ring3), le niveau de privilège du code s'exécutant est alors de 3 [CPL = 3] et comme seul un CPL = 0 permet la modification, l'instruction voulant modifier l'IDT ou la GDT lèvera alors une exception en mode utilisateur.

**rt15** · 06/03/2009, 18h13

J'ai lu ce thread qui m'intéressais pas mal il y a un moment et je l'ai relu récemment avant de m'attaquer sérieusement au problème (Coder un driver en Delphi). Je remercie donc Robby (Pour ce thread et aussi son autre thread Ring0 sous XP. C'est un fou Robby.

) et les participants

et m'excuse si ce petit up dérange quelqu'un.

Je n'ai pas souhaité utiliser le "delphi driver development kit" (Google it pour plus d'infos

), notamment car il se basait sur le lieur de VC à ce que j'ai compris (Je l'ai même pas téléchargé pour cause de restrictions).

J'ai préférer compiler une dll Delphi, et la transformer en un driver .sys. Ce qui m'a bien aidé, c'est un .sys d'exemple relativement simple, et la référence du format PE qui détaille la structure des .exe, .dll, .sys et autres.

Il faut tout d'abord l'écrire cette dll. On va commencer par le point d'entrée du driver. On va d'ailleurs l'exporter de manière à retrouver son adresse facilement par la suite. On va importer les symboles de ntoskrnl dont on a besoin avec le mot clé external, classiquement. Le travail de traduction des headers C est fastidieux mais bon... Il faut aussi globalement s'arranger pour que l'assembleur produit soit très propre. On va pas coder en objet, pas utiliser de type compliqués de Delphi, pas mettre d'unité dans les uses... Faut avoir une bonne idée de ce que notre petit compilo préféré va générer, et pas hésiter à désassembler. Mais ça se passe très bien sous une Delphi 7.

[troll]C'est pas pour rien que le Delphi est un des rares langages à suivre le C sur 100 mètres.[/troll]

Une fois que l'on a la dll, il faut la convertir en .sys. Voici un résumé des opérations nécessaires, que j'ai déduit de comparaisons entre ma dll et mon .sys d'exemple (Y compris des comparaisons de ces modules une fois chargés via un dump de la mémoire noyau après écran bleu...

) :
1) Modification de flags divers... Le plus important étant sans doute le sous système : IMAGE_SUBSYSTEM_NATIVE.
2) Suppression des imports sur les dll win32 dans la table d'import. On ne conserve que nos imports vers ntoskrnl.
3) Remplacement du point d'entrée mis en place par Delphi (Qui fait probablement tout un tas de truc obscure digne de la CRT) par l'adresse de notre point d'entrée que l'on a exporté pour pouvoir le retrouver facilement.
4) Détail super important : dans la Import Directory Table, faire pointer la Lookup sur la Import Address Table. Sinon le loader du driver ne va pas résoudre la Import Address Table et on va faire des calls dans la nature. Je sais pas pourquoi Delphi le fait pas.

5) Calcul du checksum (En dernier !), sinon Windows va refuser le driver.

C'est tout !

[edit]
Et au cas où j'aurais pas été assez clair :

Et ça marche !