Discussion :

[barthelv]

Bonjour,

Voila, le but est de developper un driver, mais celui-ci a besoin d'utiliser une DLL. Comme je crois que ce n'est pas possible avec un .sys normal, l'idee serait de faire communiquer le driver avec un service, ce qui je crois est possible et que cela soit le service qui communique avec la DLL. Le probleme, c'est que ensuite le service puisse renvoyer les resultats au driver.

Est-ce envisageable, et surtout, si cela est possible, quelle techno utiliser ? Des tubes nommes par exemple ?

EDIT: Je renomme le sujet en quelque chose de plus clair

[Aurelien.Regat-Barrel]

Typiquement, on communique avec un driver via DeviceIOControl. Tu peux le faire depuis une dll sans souci, c'est même fait pour.
Pour "renvoyer les resultats au driver", tu peux préciser le besoin + le contexte ?

[barthelv]

Disons que l'on a notre produit avec lequel on sait communiquer via une DLL. Or il s'avere qu'il existe un logiciel utilise dans le milieu qui sert de test performance pour comparer tous les produits de cette gamme, quel que soit le fabriquant.

Sachant que ce logiciel communique avec un driver generique, si l'on veut que ce logiciel fonctionne avec notre produit, il faut developper ce driver (.sys).

Or on ne veut pas avoir a tout redevelopper, ce qui prendrait au moins six mois de developpement vu la complexite du produit. L'ideal serait de pouvoir developper un driver qui se contenterait de faire de "reroutage". On ne veut surtout pas modifier notre DLL. C'est a dire:

* Le logiciel communique avec le driver
* Le driver appelle la DLL
* La DLL communique avec notre produit
* La DLL renvoie le resultat au driver
* Le Driver renvoie le resultat au logiciel

Or il est impossible de linker une DLL depuis un .sys. D'ou le probleme qui se pose.

[Aurelien.Regat-Barrel]

Oula oula, c'est confus. Un .sys, c'est une dll renommée. Les drivers sont des dll. Mais elles sont utilisées par le kernel, c'est ce qui en fait un driver (le code s'execute en kernel land). Tu peux considérer un driver comme une dll exécutée par un autre processus (le kernel). Typiquement on communique avec ce "processus" via DeviceIOControl, mais aussi ReadFile / WriteFile.
Alors, ton logiciel X il communique avec un "driver générique", mais encore ? Comment il communique ? C'est quoi ce driver générique ?
Ensuite dans le modèle WDM les drivers peuvent être empilés, ainsi tu peux créer un driver filtre qui s'interpose entre un driver existant et les applis qui l'utilise. En moins complexe, tu peux intercepter via l'API hooking les appels d'une appli vers un driver, sans passer par un driver.

Par exemple, si tu créées une dll à toi que tu injectes dans le processus du logiciel X, que celle-ci hook les bonnes API, cette dll va intercepter les appels du logiciel X, lui répondre, etc... sans qu'il ne se rende compte de rien.
Sans l'injecter, tu peux aussi créer une dll proxy, et lui faire utiliser celle là au lieu de la normale.

[barthelv]

Ensuite dans le modèle WDM les drivers peuvent être empilés, ainsi tu peux créer un driver filtre qui s'interpose entre un driver existant et les applis qui l'utilise. En moins complexe, tu peux intercepter via l'API hooking les appels d'une appli vers un driver, sans passer par un driver.

Si je comprends bien il est possible de developper un module qui intercepte les appels entre un logiciel et un driver... Qui donc simule la presence d'un driver.

Avez vous un lien qui explique ce procede SVP ?

EDIT:

1. Je ne peux pas toucher au code du logiciel de test, il est developpe par une autre compagnie (par analogie il faut imaginer par exemple un logiciel de scan qui communique avec un driver TWAIN)
2. Je ne peux pas toucher non plus au code de notre DLL qui pilote notre produit
3. Je ne peux donc que me placer entre les deux.

[Aurelien.Regat-Barrel]

En fait c'est plus général que ça : il est possible d'intercepter l'appel d'une fonction en général. Si cette fonction permet de communiquer avec un driver, alors tu interceptes la communication avec le driver.
Il y a beaucoup de techniques, au cas par cas. Tu peux intercepter un process en particulier, ou tous les process en même temps, etc...
On résume le principe par "API hooking". Une présentation des différentes techniques:
http://www.internals.com/articles/apispy/apispy.htm
et puis bon google.
Voir aussi ce qu'a développé Microsoft : detours
http://research.microsoft.com/sn/detours/
http://research.microsoft.com/~galenh/Publications/HuntUsenixNt99.pdf

reste à identifier les bonnes fonctions à hooker.

NOTE: ça n'a rien à voir avec les drivers.

[barthelv]

Merci beaucoup, je vais jetter un coup d'oeil a tout cela.

Juste pour en finir, pour etre sur que j'ai bien compris. Avec l'exemple d'un scanner, en utilisant cette technique, il me serait possible d'utiliser un logiciel de scan quelconque que l'on trouve dans le commerce et qui sait communiquer avec un driver TWAIN, de developper une DLL/EXE (quel format d'ailleurs ?) et que ce soit celle-ci qui communique avec le scanner et non pas le driver TWAIN ?

[Aurelien.Regat-Barrel]

Y'a plusieurs approches. Mais par exemple, concrètement, utiliser un driver TWAIN, ça veut dire passer par la dll twain_32.dll. Si tu crées une dll qui porte exactement ce nom et la place dans le répertoire de l'exe en question, hop il utilise ta dll au lieu de la véritable (à condition d'exporter les fonction dont il a besoin).
Une dll proxy va exporter les mêmes fonctions en faisant tout simplement un appel direct vers la vraie dll TWAIN (qu'elle aura chargé au prélable), sauf sur les fonctions qui l'intéresse où elle va faire un prétraitement, ou autre chose...
Le driver n'intervient pas là dedans, juste la dll cliente qui s'interface au driver TWAIN (twain_32.dll).

[barthelv]

Ok, mais le probleme dans ce cas la, c'est qu'il n'est pas possible d'installer le logiciel de test (encore une fois non developpe par nous, imaginons qu'il a ete developper par ceux qui font les normes ISO par exemple), puis:

* Brancher un premier produit, le tester, le debrancher
* Brancher un second produit, le tester, le debrancher
* Brancher notre produit, le tester, le debrancher
* Brancher un quatrieme produit, le tester, le debrancher
* etc...

Sans effectuer d'operation sur le PC.

Hors nous ce que l'on veut c'est que lorsque l'on branche notre produit, Windows le reconnaisse et sache tout de suite comment communiquer avec.

[Aurelien.Regat-Barrel]

La dll que tu développes peut détecter si c'est ton produit qui est branché auquel cas elle courcircuite les appels, et sinon elle laisse filer normalement. Mais...
Je me demande si j'ai bien compris : c'est pour du test sur une machine à vous, ou c'est pour réaliser un produit fini (vous fournissez un driver) qui devra fonctionner avec le logiciel X déjà installé chez le client ?

[barthelv]

C'est un produit fini et on fournit un driver avec. Celui-ci devra fonctionner avec le logiciel X déjà installé chez l'organisme qui teste tous les produits finis et emet un comparatif de performances.

Or nous avons deja developpe depuis X annees une DLL qui sait communiquer avec notre produit. C'est pourquoi on voudrait que notre driver puisse communiquer avec cette DLL.

Imagine que tu sois un developpeur de scanners et que tu developpes un driver pour celui-ci afin qu'il foncitonne sous photoshop et autres logiciels bien connus. Seulement tu ne sais communiquer avec ton scanner que via une DLL que tu as deja developpe, il va bien falloir que le driver sache communiquer avec ta DLL. Et ca ben c'est pas possible. C'est pourquoi j'avais pense a passer par un service Windows.

[Aurelien.Regat-Barrel]

Ah ok, oublie ce que j'ai dit alors, même si ça marche, c'est pas propre du tout.
Désolé de faire le boulet, mais la dll que vous avez développé, comment elle communique avec votre appareil sans passer par un driver ? Vous pouvez pas isoler le code nécessaire au pilotage et le réutiliser dans votre driver ?

[barthelv]

Disons que c'est un ensemble de DLL qui representent une API complete qui permet a nos clients de developper leurs applications et de communiquer avec notre produit sans trop se prendre la tete. la communication se fait via ethernet. Et honnetement il ne serait pas envisageable en moins de 6 mois de creer un driver qui ferait ce que fait cet ensemble de DLL.

EDIT: En admettant que l'on isole la partie communication, ce qui serait le plus propre a mon avis, la couche qui s'en occupe est si complexe que l'on est pas sortis de l'auberge. En fait ce que l'on veut c'est justement que le driver communique avec la DLL qui s'occupe de la communication

[barthelv]

Je donne un exemple car j'ai du mal a expliquer.

Imaginons que le logiciel sache faire n choses. On veut que lorsqu'il appelera le driver, nous dans notre driver on code que si c'est l'operation 1 qui est appelee alors il faut appeler notre API et faire une liste de choses. Si c'est l'operation 2, alors on fait autrement en utilisant notre API etc...

[Aurelien.Regat-Barrel]

Ok je pense avoir compris. C'est que au niveau perf justement c'est pas optimal. Regarde le chemin que ça va suivre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
User                   Kernel

Application X   -> votre driver
votre dll       <-
                -> driver reseau
votre dll       <-
                -> votre driver
Application X   <-

y'a un aller-retour user <-> kernel en plus, et donc copie supplémentaire. J'espère que vous échangez pas beaucoup de données.

Pour déléguer l'exécution du driver à du code qui se trouve en mode user dans une dll, je ne suis pas spécialiste, mais à priori si quand le logiciel X interroge ton driver, celui-ci rend la main à ta dll (débloquer un ReadFile, signaler un event...) en lui disant ce qu'il faut faire, attend que la dll rende le résultat (WriteFile, IOCTL perso...) et transmet ce résultat comme réponse à l'appel initial de l'application X, ben ça devrait être jouable.
C'est un design moyen car ta dll en user mode peut bloquer un driver en kernel mode, mais bon, en théorie... reste à passer à la pratique

[barthelv]

Pour déléguer l'exécution du driver à du code qui se trouve en mode user dans une dll, je ne suis pas spécialiste, mais à priori si quand le logiciel X interroge ton driver, celui-ci rend la main à ta dll (débloquer un ReadFile, signaler un event...) en lui disant ce qu'il faut faire, attend que la dll rende le résultat (WriteFile, IOCTL perso...) et transmet ce résultat comme réponse à l'appel initial de l'application X, ben ça devrait être jouable.
C'est un design moyen car ta dll en user mode peut bloquer un driver en kernel mode, mais bon, en théorie... reste à passer à la pratique

Justement le probleme c'est qu'il existe plusieurs types de drivers. Je me base sur cet article de la MSDN qui est tres court : http://www.microsoft.com/whdc/driver/tips/KmDLL.mspx. Il y est bien explique que depuis un driver en mode Kernel, on ne peut pas communiquer avec une DLL. Par contre ils parlent d'un autre type de driver qui est en mode "export driver".

Si j'ai bien compris il faudrait developper, pour repondre a nos besoins:
* un driver en mode kernel qui serait appele par l'application
* un driver en mode export qui serait appele par le precedent driver, communiquerait avec la DLL et renverrait les resultats au premier.

Ou alors on explore la piste qui consiste a faire communiquer un driver en mode kernel avec un service Windows qui lui communiquerait avec notre DLL.

[Aurelien.Regat-Barrel]

Je me base sur cet article de la MSDN qui est tres court : http://www.microsoft.com/whdc/driver/tips/KmDLL.mspx. Il y est bien explique que depuis un driver en mode Kernel, on ne peut pas communiquer avec une DLL.

communiquer avec une dll, ça ne veut pas dire grand chose. Une dll, c'est du code compilé. On ne fait que l'appeler. L'article dit d'ailleurs qu'on ne peut pas appeler le code d'une dll depuis un driver.
Mais si tu as un process user qui utilises ta dll, ton driver peut tout à fait communiquer avec ce process (enfin l'inverse plutôt : le process communique avec le driver).
Un export driver, si j'en crois cet article, c'est une dll driver = un code compilé pour être exécuté en tant que driver (par des drivers). Dans ton cas ça veut dire réécrire ta dll comme driver, ce qui revient à écrire un driver.
Comme je te l'ait dit, les drivers sont des dlls. D'ailleur la HAL porte l'extension dll.

[barthelv]

communiquer avec une dll, ça ne veut pas dire grand chose. Une dll, c'est du code compilé. On ne fait que l'appeler. L'article dit d'ailleurs qu'on ne peut pas appeler le code d'une dll depuis un driver.

En effet, or c'est ce que je veux faire, je veux "rerouter" les appels vers le driver vers ma DLL... Et ca c'est pas possible.

Mais si tu as un process user qui utilises ta dll, ton driver peut tout à fait communiquer avec ce process (enfin l'inverse plutôt : le process communique avec le driver).

Je suis d'accord que le process peut communiquer avec le driver, mais je ne vois pas comment cela peut s'appliquer a mon cas.

Un export driver, si j'en crois cet article, c'est une dll driver = un code compilé pour être exécuté en tant que driver (par des drivers). Dans ton cas ça veut dire réécrire ta dll comme driver, ce qui revient à écrire un driver.

Dans ce cas ce genre de driver ne convient pas non plus pour ce que je veux faire car il faut eviter de toucher a notre DLL.

En consequence de quoi, voici les deux questions que je me pose:

1. Est il possible de faire communiquer un driver en mode kernel avec un service windows ?
2. Est il possible qu'un service Windows fasse des appels a une DLL ?

EDIT : J'ai la reponse a la question que je me pose, un collegue a trouve un template de driver qui communique avec un service Windows. De plus il connait un produit qui utilise ce genre de technique. Je vais etudier tout cela et je reviens vers vous si il y a un probleme.

Merci beaucoup pour l'aide .