Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
DDK et Delphi ?
Bonjour a tous !
est il possible d'utiliser le DDK avec Delphi ?
Exemple, l'api IoCreateDevice ! A l'origine cette api se trouve dans NtOsKrnl.exe. Pour l'utiliser on me parle de DDK ... mais moi, je programme en delphi ! es ce possible de faire "parler" DDK et Delphi ensemble ?
Merci a tous.
Le DDK c'est pour les drivers, c'est gavé orienté C/C++, VC++ même (même pas un autre compilo C++!)
Donc oublie le DDK, surtout qu'il est pas dispo en download, et que, heu, toi t'es pas en C++.
Tu veux faire quoi? As tu conscience que tu veux faire un driver, et que c'est pas de la tarte?
Merci de ta réponse.
Oui, évidemment que je sais que c'est pas de la tarte.
Mais je suis déjà bien avancé sur ce chemin la !
J'utilise déjà "OpenSCManager", "CreateService", "OpenService" ...
Mais la, je ne crée pas un driver complet ! Il me faut "IoCreateDevice" !
Le DDK pas en free download ... oui, ca je sais auusi ! Mais c'est pas trop trop cher (25$) ... tu commandes ca par le Net, et c'est tip top ! J'ai le DDK ! Mais ce truc est complètement orienté C, grave ! Windows (Xp) c'est Microsoft, et le DDK, c'est Microsoft aussi bien sur ! Comme quoi Microsoft a des interets du coté de C, clair ! Franchement, ca fait plusieurs années que j'utilise Delphi ... et la, je regrette ! Le monde des PC est totalement sous la coupe de Microsoft (Windows) ... et dans ce cas précis, je me trouve dans une impasse... a cause de Delphi !
Sur mon ordi, j'ai aussi Visual C++ ... Je vais donc devoir me mettre au C uniquement pour cette histoire de DDK ? c'est un peu désolant !
Haurissant que Borland ne propose pas un équivalent pour son produit Delphi ! Impossible de croire que Borland en soit incapable... alors pourquoi Borland laisse t il se crénaux libre aux mains de Microsoft sans broncher ? ... bein voyons ... pour fonctionner impec sous windows, Borland doit bien sacrifier qq interets ! ... c'est fou ! ...
Merci a toi pour ton avis ...
Je crois que tu n'as pas pigé ce qu'est le DDK...
MS dévelope Windows, en C (LE langage des OS). Des programmes sont destinés à fonctionner dessus. MS fournit, gratos, le SDK qui contient de l'info sur les fonctions de WIndows et les .h qui vont avec. Borland les a récupéré, converti en Delphi-Pascal, et a sorti Delphi. Cool.
Mais Windows fonctionne sur du hardware, et a besoin de drivers.
Donc, jusqu'à il y a pas très longtemps, MS fournissait, gratos, le DDK, qui est le SDK spécial pour les drivers. Un driver n'est pas un prog classique. A ma connaissance, seul VC++ sait compiler un driver. Y'a pas grand monde qui développe des drivers. Pourquoi Borland aurait-il investi dans un tel outil ? Sutout que le RAD ne s'applique pas aux drivers : pas de fenêtres, trsè peu de code réutilisable, jsute du code bas niveau C, hyper spécifique à un périphérique donné. Y'a pas de marché pour les drivers. C'est pourquoi MS est seule. Et ils sont font pas leur tune avec le DDK. Il est là parce qu'il est obligatoire pour un OS. Il est pas dans le SDK parce qu'en prog normale, on n'en n'a pas besoin.
Pourquoi en as tu besoin ?
Si, je vois bien ce qu'est le DDK.
Tous les OS fonctionnent sur du Hardware, par définition ! Prends n'importe quelle machine, avec n'importe quel OS ... y'a quoi plus bas que l'OS ... le hardware ... et entre les deux ? des drivers !
D'accord avec toi, la conception de driver interesse peu de monde.
Les api ... elles sont toutes a l'origine contenues dans le kernel de Windows. Mais a cet endroit, elles sont inexploitables depuis le mode utilisateur. Il existe donc des librairies permettant d'accéder a ces api.
Fichiers "lib" pour le C, fichier "dll" pour Delphi. En ce qui concerne "IoCreateDevice", une api cléf pour la conception d'un driver, Microsotf propose via son kit DDK la librairie NtOsKrnl.Lib. Elle permet via le language C d'utiliser sans pb l'api en question. Borland ne propose aucune "dll" équivalente. Pour Delphi, cette api reste interdite.
Normalement, me dis tu, un programme n'a pas besoin d'utiliser cela !
D'accord avec toi ! Mais Microsoft propose malgré tout un outil pour le faire, Borland non ! Personnellement, j'ai besoin de cette api (et de certaines autres) justement pour développer un Kernel Mode driver.
Je suis a deux doigts de pouvoir la faire. Mais Delphi me bloque complètement.
Voila ... qu'en penses tu ?
Si tu veux faire un driver, c'est C/C++, et VC++ pour se faciliter la vie.Normalement, me dis tu, un programme n'a pas besoin d'utiliser cela !
D'accord avec toi ! Mais Microsoft propose malgré tout un outil pour le faire, Borland non ! Personnellement, j'ai besoin de cette api (et de certaines autres) justement pour développer un Kernel Mode driver.
Un .lib associé à une dll n'est qu'un pseudo .DEF qui indique au compilo C/C++ comment s'y prendre pour linker avec la dll, et éviter de se farcir des GetProcAddress. L'exe qui en sort est lié à la dll, la meme que Delphi utilise.Fichiers "lib" pour le C, fichier "dll" pour Delphi.
IoCreateDevice n'est pas une API.En ce qui concerne "IoCreateDevice", une api cléf pour la conception d'un driver, Microsotf propose via son kit DDK la librairie NtOsKrnl.Lib. Elle permet via le language C d'utiliser sans pb l'api en question. Borland ne propose aucune "dll" équivalente. Pour Delphi, cette api reste interdite.
Tu te mélange pas mal le spinceaux. Borland n'a jamais fourni de dll équivalente à celles de MS, vu que t'es obligé de les utiliser. Tu as l'outil implib il me semble pour convertir les .lib MS en .lib Borland.
Si tu persistes avec Delphi, faut te traduire en Pascal tout le ntddk.h.
Delphi n'est absolument pas fait pour ça.Voila ... qu'en penses tu ?
Merci pour ta réponse.
1) Bien entendu que IoCreateDevice est une api !
Documentations du site Sysinternals:
IoCreateDevice
Why does Everyone:R/W show up on most device objects? Because IoCreateDevice, the kernel-mode API used to create device objects, assigns the permissions I list above as default permissions - its up to a device driver to adjust .....
2) Ne pas dire:
Borland n'a pas de dll équivalente, vu qu'on est obligé d'utiliser le MS DDK.
Mais, c'est l'inverse, ne confond pas la cause et l'effet.
On est obligé de se faire le MS DDK, parceque Borland n'a rien d'équivalent et ne propose rien a ce sujet.
3) y'a pas de ".lib" chez Delphi.
4) Delphi n'est pas un language orienté applications spécifiques.
C'est un language de haut niveau absolument polyvalent.
Il n'a pas a etre "fait" ou "pas fait" pour "ca" ... mais il est clair que la ...
il lui manque un outil que Microsoft ... lui .. a fournit.
5)Non, "implib" ne permet pas de convertir les librairies".Lib" du DDk de
MS en librairies ".Dll" utilisées par Delphi.
Du coté des NewsGroup US de Borland ... le scoop se saurait !
6)Convertir le Ntddk.h, oui ... c'est pas un soucis ca. La difficulté de fond ne se trouve pas la.
7)le C, C++ est un plus pour programmer un driver.
Oui ... c'est plutot une obligation sans plus. Vu que MS s'est gardé le monopole de l'outil nécessaire.
8)je penses que je ne les mélange pas tant que ca
Un grand merci pour ta présence sur ce sujet.
Salut.
Désolé de m'incruster dans la conversation, mais je soutiens le fait que, comme le dit HW, Delphi n'est pas fait pour çà !
Par exemple, on peut bien créer un OS en C, pas en Delphi, pardi ;-)
Le but de ce message: te faire sortir de la tête cet acharnement à essayer de le faire avec Delphi !!
Un historique local pour Visual Studio 2005 et 2008 :
http://www.codeplex.com/VLH2005
Tu es le bien venu rolkA,
Non ... je vais passer au C ... c'est clair.
J'ai pas le choix ... Borland n'a pas fournit ce qu'il faut pour le faire en Delphi. C'est pas une question de language. Delphi dans l'absolu sait tout faire comme C. C'est une question d'outil manquant, les librairies du DDK. De la a se dire que C est plus adapté au developpement d'un driver, non pas du tout. Mais on est contraint de passer par C, par le monopole de Microsoft concernant les outils annexe pour y parvenir.
Le centre de ca, c'est la librairie "NtOsKrnl.LIB" du MS DDK. Borland ne fournit aucune NtOsKrnl.DLL équivalente. Ce n'est que ca. Si Borland avait fournit ce truc, Delphi serait tout aussi bon que C pour implémenter un driver.
Donc, je dois passer au C, pas par avantage du C, mais par simple monopole de MS sur certains de ses outils.
Je trouverai peut etre ca super génial au passage le C, mais faut tout reprendre a zéro, c'est pas évident.
Ok ok. Reprenons.
Une API, c'est un regroupement de foncctions et types de données, dont IoCreateDevice fait partie, IoCreateDevice est une fonction de l4API kernel.1) Bien entendu que IoCreateDevice est une api !
http://www.tout-savoir.net/lexique.php?rub=definition&code=552
Si Borland fournissait une autre version de ntoskrnl.exe, et non ntokkrn.DLL, Borland fournirait un autre système d'exploitation. ntoskrnl.exe est chargé par ntldr lors du boot.Borland n'a pas de dll équivalente, vu qu'on est obligé d'utiliser le MS DDK.
Mais, c'est l'inverse, ne confond pas la cause et l'effet.
On est obligé de se faire le MS DDK, parceque Borland n'a rien d'équivalent et ne propose rien a ce sujet.
Le centre de ca, c'est la librairie "NtOsKrnl.LIB" du MS DDK. Borland ne fournit aucune NtOsKrnl.DLL équivalente
Borland ne propose pas d'equivalent des librairie de MS. WIn32 est basé sur kernel32.dll, gdi32.dll, user32.dll et advapi32.dll. On passe par ces dll pour faire un prog windows, quelque soit le langage. On ne peut pas les remplacer.Delphi utilise la même kernel32.dl qu'un prog C. C'est le but des dll : être utilisée depuis différents langages.
Le .lib maintenant...
Une dll est unr bibliothèque de fonctions liée à l'exécution. Le compilo ne l'utilise pas et ne vérifie pas son existance au moment de la compilation. Windows se charge de charger la dll avec l'exe et d'effectuer le lien entre les appels au sein de l'exe et le code au sein de la dll. Mais l'exe doit être organisé de façon à dire à Windows qu'il utilise telles fonctions de telles dll. C'est fait via la section import du format PE.
http://coding.bug.free.fr/win/import.htm
Comment le compilo, ou plutôt le linker, peut-il savoir les fonctions exportées par une dll sans avoir cette dll et sans y fakire référence ? C'est là qu'intervient le .lib. Le .lib indique au linker les fonctions et autre contenues dans une dll. Le linker pourrait aller voir dans la dll, mais ça serait trop long à faire. GCC sait le faire. Les autres compilos non. VC++ a besion d'un .lib. Les softs borland aussi ont besoin d'un fichier. Je suis pas spécialiste, mais apparement BC++ utilise les .lib (format différent de VC++, d'ou des pblm, d'ou implib), et Delphi/BCB utilisent le format DCU, dont je ne sais rien. Mais en ouvrant dans un editeur windows.dcu, j'ai bien quelque chose qui ressemble à la description des imports, avec apparement une différence par rapport au .lib : ca concerne plusieurs DLL. Windows.dcu par exemple semble regrouper plusieurs VC++ .lib équivalent (pas mal de noms de DLL dedans).
Ainsi, quand tu utilise windows.pas, comme tu as le dcu, hop, ca marche.
AInsi, quand tu inclus windows.h, comme tu as les kernel32.lib, user32.lib, ... hop ca marche.
Si tu n'as pas de .lib / .dcu, il faut te cogner le link dynamique entre les fonctions de la dll (dans la dll) et les pointeurs de fonctions utilisés dans ton prog (de manière explicite cette fois vu que le compilo peut pas le faire pour toi) avec des GetProcAddress.
Donc, Borland ne fournit aucune réécriture à la Borland des dll de Windows, qui sont les composant de l'OS. Il fournit les header (réécrits en PAscal pour Delphi) et les .lib (dcu) pour les appeler, c'est tout.
Un bout de header de Windows.pas :
Avec kernel32 = 'kernel32.dll';
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Ca ressemble à l'import sous VB.
Le DCU est donc un truc généré partir d'un .pas qui décrit où se trouvent les fonctions et quell sont leurs noms. Ca fait confiance au programmeur qui a écrit ça quoi.
Un .lib est généré par le compilateur lors de la compilation d'une dll, en même temps que celle-ci.
Le cas du DDK...
Alors, apparement, il te suffit de créer ton ntddk.pas du genre :
Théoriquement tu peux alors utiliser ntoskrnl.IoCreateDevice depuis ton prog Delphi. Cool. Mais pkoi Borland l'a pas fait ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Parce que, non, ca marche pas. Ton appli ne peut pas l'appeler. Il faut créer un driver (compilation spéciale). Je sais pas si Borland sait compiler un driver. BC++ peut être, Delphi je suis sceptique.
Chaque langage a son domaine de prédilection. Delphi = haut niveau = l'inverse d'un driver.Pascal n'est clairement pas fait pour faire des drivers. Pourquoi pas en faire en Vb aussi. C, c'est LE langage des drivers. Pascal et C n'iont pas les mêmes conventions d'appel, pas les même chaines de caractère, pas les types... Vouloir utiliser Delphi c'est du gaspillage de temps. Ce que tu ^peux faire, et que normalement on fait, c'est ton driver en C/C++ et son utilisation depuis un prog Delphi. Là, Ok.4) Delphi n'est pas un language orienté applications spécifiques.
C'est un language de haut niveau absolument polyvalent.
Il n'a pas a etre "fait" ou "pas fait" pour "ca" ... mais il est clair que la ...
20000 lignes tout de même, sans les autres includes. Mais tu as raison, le probleme de fond c'est pas ça, c'est : dans quel but ?6)Convertir le Ntddk.h, oui ... c'est pas un soucis ca. La difficulté de fond ne se trouve pas la.
Et que fait-on de Win9x? Bien qu'il y ait le WDM, il faut offrir au développeur la possibilité de faire un VxD. Hu hu, un VxD en Delphi^^
Y'a pas mal d'outils à adapter aussi. Tout ça pour quoi ? Produire + difficilement en Delphi un driver moins performant.
C'est très exactement pourquoi Borland ne s'est pas penché sur la création de drivers en Delphi. Ca représente bcp d'investissement, en pure perte.Donc, je dois passer au C, pas par avantage du C, mais par simple monopole de MS sur certains de ses outils.
Je trouverai peut etre ca super génial au passage le C, mais faut tout reprendre a zéro, c'est pas évident.
AMA, tu n'as pas bien compris le principe des dll et surtout de leut utilisation. C'est ça d'utiliser des outils haut niveau. Fait un peit tour par le C et GetProcAddres. Compile et utilise une dll, explicitement et implicitement. Tu ne me semble pas prêt à écrire un driver (il te sert à quo se driver ?)8)je penses que je ne les mélange pas tant que ca
Bien ... j'ai appris certaines petites choses, et je t'en remercie.
Sur le fond, je te répondrai plus tard, j'ai besoin de creuser certaines choses pour te faire une réponse "intelligente" ... la de suite, j'ai pas le temps.
Oui, cool ... je vais passer au C, Visual C++ pro est déjà installé sur la becanne et j'ai des bouquins plein la table ..
Mais, juste une réflexion ... totalement théorique, du style "on refait l'monde", tu vois
Le language C est plus adapté pour écrire un Driver.
Le C n'a pas les memes conventions d'appel, pas les memes chaines, les types ... etc .. mais peu importe ! Le résultat c'est du code exécutable. Et Pascal/Delphi est tout aussi capable de générer n'importe quel code que toi via C. En terme de truc de bas niveau, j'ai fais pas mal de truc avec Delphi. Un CallGate, construire la table de service n°2 au sein meme du kernel, j'ai dévié des vecteurs de l'IDT, installé un service Windows,hooké la table de service principal, avec un "code" de passage, me permettant de passer moi meme en ring0 et accessoirement de comptabiliser les réels appels du Kernel. Y'a pas de limites. Il faut bien connaitre son language, c'est tout. Il n'existe pas une séquence de code exécutable que tu puisses générer avec C et pas avec delphi. Aucune !
Oui, implémenter un Driver avec delphi, c'est une perte de temps !
J'en suis un exemple ! Mais pas a cause du language, allons ! A cause de l'environnement "outil" incomplet de Borland ...
Non, il ne suffit pas de déclarer la dite fonction pour pouvoir l'utiliser.
Dans ce cas, le compilateur m'indique qu'il ne trouve pas NtOsKrnl.dll,
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3function IoCreateDevice(A,B,C,D,E,F,G : cardinal): cardinal; stdcall; external 'NtOsKrnl' name 'IoCreateDevice';
et si je pousse la plaisenterie a indiquer "external NtOsKrnl.exe" il me jette avec une "violation d'acces".
Oui, je ne connais pas le fin du fin en matière de fichier .dll, exact !
Si Borland avait fourni un NtOsKrnl.dll ... il n'aurait pas ré-écrit un os pour autant. Truc.exe et Truc.dll, c'est pas la meme chose. Dans une dll les fonctions peuvent etre utilisées de l'extérieur. La seule facon d'accéder au code de NtOsKrnl.exe ce serait de le mapper dans la mémoire de ton process (je l'ai fait...en delphi). Mais le code obtenu est un code "mort" et inexploitable. J'ai eu la blague avec l'api .. heu pardon
Oui, aussi, je ne connais pas le contenu exact d'un .Lib ... idem que ma connaissance des dll. Mais il est clair que dans ce .LIB du ddk il y a les infos nécessaire pour que C puisse utiliser le contenu de NtOsKrnl.exe !
Si C n'avait pas ce fichier, il ne serait pas plus capable de créer un Driver que Delphi. Si Borland avait fourni un NtOsKrnl.dll ... pas une espèce de copie inutile du .exe, mais une "version" ou le code et les fonctions de NtOsKrnl.exe sont exploitables de l'extérieur ... bingo, c'est tout !
Le C n'est pas plus capable que delphi d'utiliser "tel quel" le code de NtOsKrnl.exe, mais entre les deux, y'a le fameux .Lib du ddk. Borland n'as pas fournit l'équivalent.
Voila, et dans le fond, je pense que j'ai tout dit .
J'espère que je ne t'agresse pas trop avec tout mes trucs,
Ton avis sincère sur tout ca m'intéresse bien évidemment.
merci a toi,
Le problème n'est pas là. Windows était codé en C bien avant que naisse Delphi1.Le C n'a pas les memes conventions d'appel, pas les memes chaines, les types ... etc .. mais peu importe ! Le résultat c'est du code exécutable. Et Pascal/Delphi est tout aussi capable de générer n'importe quel code que toi via C.
Je n'entrerais pas dan sun troll C vs Pascal. L'auteur du C s'est expliqué à ce sujet.
http://www.lysator.liu.se/c/bwk-on-pascal.html
Question perso : comment traduis-tu en Delphi une union C ?
Comment t'y prends-tu ?avec un "code" de passage, me permettant de passer moi meme en ring0
Tu es visiblement très attaché à ce langage. Mais méfie toi, chaque langage / technique a ses forces / ses faiblesses, et il ne faut pas l'utiliser à toutes les sauces sous prétexe qu'il est très bon dans beaucoup de domaines. bcp de programmeurs ont leur petit bébé : les callback, les templates, l'héritage multiple, ... Tout cela fournit des réponses élégantes et puissantes à certains problèmes. mais pas à tous. Faut savoir utiliser la meilleur technologie pour un cas donné, et non essayé d'adapter la technologie que l"on maîtrise le mieux à tous les cas. Delphi c'est pareil. Ton challenge n'a pour mio qu'une seule utilité : démontrer les possibilités du langages, faire des "tricks", dans un but de démonstration. C'est pas sérieux pour autrement.Il n'existe pas une séquence de code exécutable que tu puisses générer avec C et pas avec delphi. Aucune !
Normal, par défaut, l'extension utilisée, si tu ne la précise pas, c'est .dll. ntoskrnl.dll n'existe effectivement pas.Dans ce cas, le compilateur m'indique qu'il ne trouve pas NtOsKrnl.dll,
Pas vraiment surprenant, pour peu qu'il l'ouvre en écriture. Copie le dans ton rep et retente.et si je pousse la plaisenterie a indiquer "external NtOsKrnl.exe" il me jette avec une "violation d'acces".
En Win32, on utilise GetProcAddress pour se lier dynamiquement à une dll dont on a pas le .lib. Le .lib est juste une commodité, il n'est pas indispensable. En Delphi aussi je pense que c'est faisable.Si C n'avait pas ce fichier, il ne serait pas plus capable de créer un Driver que Delphi
Depuis un driver y'a pas GetProcAddress. Peut être qu'il y a un equivalent. Mais étant donné que le kernel est toujours chargé à la même adresse, on pourrait se coder un GetProcAddress maison.
En Delphi aussi ça doit être envisageable.
Maintenant c'est à moi de poser les questions.
J'ai compilé la dll suivante :
Cette Dll, vide, est linkée avec tout un tas d'autres dll : kernel32, user32.dll, etc... Peux-tu empêcher cela ? Car si non, je vois pas comment tu peux pondre un driver.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Corriges-moi si je me trompe : tu ne peux pas utiliser les objets genre AnsiString depuis ton code, vu que tu ne te lie plus à rien. Tu dois dont toi même te coder une gestion des chaines, compatible avec C tant qu'à faire. Bref, faire du C en Pascal.
Il te sert à quoi ce driver ?
Salut Robby,
Je voulais juste te dire, avant que tu abandonnes ton delphi chéri et que tu passes au C, qu'il existe une astuce pour utiliser les api de ntoskrnl.exe
En fait tu load ntoskrnl avec LoadLibrary, normal, ensuite tu recupères l'adresse de la fonction désirée avec GetProcAddress, toujours normal, et la tu obtiens un pointeur vers ta fonction. L'astuce c'est d'ajouter 0x7FFE0000 à ce pointeur, et normalement tu as la bonne adresse, tu peux passer en ring0 et appeler la fonction via ce pointeur. J'ai pas encore essayer, je viens de trouver ça. Tiens moi au courant si ça t'aide.
On peut compiler des drivers en assembleur, ya des sites qui donne des modèles pour faire ça.Envoyé par HW
Bon visiblement tu ne comprends pas ce qu'est un driver !
Tu n'est pas "à deux doigts" comme tu le crois...
Un driver c'est un soft TRES particulier, qui contrairement aux application tourne en ring 0.
Penche toi sur la doc des drivers kernel et tu verra.
(et pourquoi tu a besoin de cette fonction ? Tu veux faire quoi exactement ?)
sans vouloir t'offenser fd, Robby en sait certainement plus que toi sur le ring0, et il est assez avancé dans ses recherches, tu devrais pas lui parler comme à un bébé.
Plus avancé que moi sur le ring 0 ?
Pour ta gouverne j'ai développé des drivers nt en ring 0.
Et il est trés loin de la solution...
Et je ne lui parle pas "comme un bébé" mais j'essaie de lui éviter de se faire c... pour rien
Je pouvais pas deviner, mais il est tout sauf très loin de la solution, je sais pas pourquoi tu dis ça, ça m'étonne d'ailleurs venant d'une personne sensée travailler là-dedans
trés loin, et toi aussi.
un simple exemple :
NTSTATUS
IoCreateDevice(
IN PDRIVER_OBJECT DriverObject,
IN ULONG DeviceExtensionSize,
IN PUNICODE_STRING DeviceName OPTIONAL,
IN DEVICE_TYPE DeviceType,
IN ULONG DeviceCharacteristics,
IN BOOLEAN Exclusive,
OUT PDEVICE_OBJECT *DeviceObject
);
tu le trouve ou le DriverObject ?
(c'est un des paramétres passé à la fonction DriverEntry qui est appelé par windows au chargement du driver)
pour utiliser les api du ddk tu DOIS déja étre en mode kernel donc développer un driver, et ça n'est pas trivial!
?
Moi je suis loin ? je suis loin de quoi ? je développe pas de driver, j'y connais rien en développement de driver et j'ai jamais prétendu le contraire. J'aide simplement Robby à trouver un moyen d'appeler des fonctions de ntoskrnl en bidouillant.
Sympa le copier-coller de prototype. A moi.
NTSTATUS
NtMapViewOfSection(
IN HANDLE SectionHandle,
IN HANDLE ProcessHandle,
IN OUT PVOID *BaseAddress,
IN ULONG ZeroBits,
IN ULONG CommitSize,
IN OUT PLARGE_INTEGER SectionOffset,
IN OUT PULONG ViewSize,
IN SECTION_INHERIT InheritDisposition,
IN ULONG AllocationType,
IN ULONG Protect );
ça correspond à quoi le SectionOffset ?
Et me voilà devenu un fort.
Hello Chris, tu es de passage sur le sujet ? ..
Oui, Chris ... mais j'ai pas besoin d'utiliser une astuce (7FFE0000)
pour connaitre tip top l'adresse réelle d'une fonction de NtOsKrnl.exe.
Voici un truc général : librairie=NtOsKrnl.exe, target=IoCreateDevice.
dans result, j'ai la réelle adresse de la foncion.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37FUNCTION References (librairie, target : string): cardinal; stdcall; var SDT, Buffer, BI_Target, Resultat, BI_Librairie : cardinal; P_SDT : ^dword absolute SDT; P_Buffer : ^dword absolute Buffer; P_BI_Target : ^dword absolute BI_Target; begin // resultat := 1er NtQuery "a vide", la taille du buffer nécessaire NtQuerySystemInformation(SystemModuleInfo, nil, 0, @Resultat); // On arrondit cette "taille" a la page supérieure Resultat := (resultat + $1000) and (not masque); P_Buffer := VirtualAlloc(nil, resultat, MEM_COMMIT, PAGE_READWRITE); NtQuerySystemInformation(SystemModuleInfo, P_Buffer, Resultat, @Resultat); // Le 1er module est toujours NtOSKrnl.exe // + $0C : passe le compteur de Modules + les 2 dword réservés // Récupère l'Adresse-Base du 1er module - NtOSKrnl.exe Buffer := Buffer + $0C; BV_Librairie := P_Buffer^; * <----- 1ere Référence // Récupère la taille du 1er module - NtOSKrnl.exe // Buffer := Buffer + $04; // Size_NtOSKrnl := P_Buffer^; VirtualFree(P_Buffer, 0, MEM_RELEASE); * si ok, retour <> 0 BI_Librairie := LoadLibrary(PChar(librairie)); P_BI_Target := GetProcAddress (BI_Librairie, PChar(target)); FreeLibrary(BI_Librairie); if BI_Target = 0 then begin res:= 1 ; Error(888); end; // P_BI_Target et BI_Target sont "absolute" result := (BI_Target - BI_Librairie) + BV_Librairie; // result = Base Vraie Target <----- 2eme Référence end;
J'ai juste copier/coller ca en vitesse ... il manque peut etre un pti truc.
Bien entendu que si je passe en ring0 je peux appeller les fonction contenue dans NtOsKrnl.exe ... c'est clair ca !
Passer en Mode Kernel n'a plus rien d'un soucis pour moi.
Je me construit ma table de service perso depuis longtemps. Ou par un petit CallGate.
Le noyeau d'un CallGate ... allez .... c'est bientot Noel ...
Mais CallGate, ce sont mes débuts, y'a bien mieux que ca !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103global ------- TYPE MON_STRUCT = packed record W_1 : word; W_2 : word; W_3 : word; W_4 : word; end; pMA_STRUCTURE = ^MON_STRUCT; VAR Depart, base : Cardinal; Descript : pMA_STRUCTURE absolute Depart; Gdt : packed record size : word; Base : Cardinal; end; CgCall : packed record {48 bits} A : dword; B : word; end; -------------------------------------------------------------------------- FUNCTION Call_Gate (Ma_Demande : pointer): cardinal ; stdcall ; label fin; var pas_trouver : boolean; Size_Code : cardinal; Procedure tremplin; asm mov fs, bx // bx = 30h. <--- ici je suis en Ring0. mov eax, cr0 call [esp+8] // ici, je Call a " Ma_Demande ". call [esp + 8] retf 4 // et retour juste après le Call Far. end; begin asm sgdt Gdt end; Acces_Memoire(oui); base := Open_Map(Gdt.Base); Depart := (Gdt.size and $FFF8) + base; pas_trouver := oui; While (Depart > base) and pas_trouver do begin // Descriptor:Pointer ABSOLUTE Depart:Cardinal. if (Descript.W_3 and $8000) = $0 then // Descriptor libre ? begin Struct_Save := Descript^; //Save "Gate Descriptor" d'origine. Adr_Ptr := @tremplin; // Adr_Ptr:Pointer ABSOLUTE Addr_Ring0_Code:record 2xword. Descript.W_1 := Addr_Ring0_Code.low; Descript.W_2 := $0008; // --> sélecteur de Code + Ring0. // $EC01 = 1 11 0 1100 0000 0001 Descript.W_3 := $EC01; // P|DPL|S|Type X ----|nb param. Descript.W_4 := Addr_Ring0_Code.high; pas_trouver := non; end else Depart := Depart - $8; end; if pas_trouver then // = oui. begin res := 1; Error(999); end ; CgCall.A := $0; CgCall.B := ((Depart - base) or b00000011 ) and b11111011 ; asm push eax mov eax, offset fin sub eax, offset Call_Gate mov Size_Code, eax pop eax end; VirtualLock(@Call_Gate, Size_Code); Temps_Reel(true); Sleep(0); //--------------------------------- asm pushad push fs push Ma_Demande mov ebx, 00000030h // FS d'arrivée. mov eax, offset CgCall dw Call_Far_eax // Call far ptr [eax] ... --> Ring0 --> @tremplin pop fs popad end; //--------------------------------- Temps_Reel(false); VirtualUnLock(@Call_Gate, Size_Code); Descript^ := Struct_Save; //restore "Gate Descriptor" d'origine. Close_Map(base); Acces_Memoire(non); result := 0; fin: end;
Ici aussi, c'est copier/coller rapidos ...
Ou alors une méthode en détournant un vecteur de l'IDT ... le tout totalement depuis ring3 et tout en delphi. En n'oubliant pas d'utiliser les registre MMX pour le travail, car l'offset dans un descripteur d'exeption est en deux morceaux, il faut donc un registre 64 bits pour détourner en une seule opération. ..
Ou en installant un service windows qui créera lui meme la table de service n°2 ... via un fichier systeme .sys.
Ca donne ca:
S'il faut obligatoirement se trouver déjà en ring0 pour pouvoir écrire un Driver comme tu le dis, alors y'a plus d'soucis. Je passe en ring0 et j'écris tout en assembleur, nickel.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32PROCEDURE Robby_Ring0_Sys; var H_Create, hSCM : cardinal; nom_driver : string; T_F : LongBool; Abs : cardinal absolute T_F; const pc : ^PChar = nil; Function err (code : cardinal):cardinal;stdcall; begin if code = 0 then RaiseLastOSError; result := 0; end; begin nom_driver := 'Robby'; hSCM := OpenSCManager(nil, nil, SC_MANAGER_ALL_ACCESS); err(hSCM); H_Create := CreateService(hSCM, PChar(nom_driver), PChar(nom_driver), SERVICE_ALL_ACCESS, SERVICE_KERNEL_DRIVER, SERVICE_SYSTEM_START, SERVICE_ERROR_NORMAL, PChar('C:\WINDOWS\Robby.sys'), nil, nil, nil, nil, nil); err(H_Create); T_F := StartService(H_Create, 0, pc^); err(Abs); T_F := DeleteService(H_Create); err(Abs); T_F := CloseServiceHandle(H_Create); err(Abs); T_F := CloseServiceHandle(hSCM); err(Abs); // et ensuite hop en ring0 via Sysenter. end;
Merci pour ta présence HW , qu'en penses tu ?
Merci a toi pour ton intervention Chris, sympa !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager