Retour menu KMD / Retour menu assembleur

Services

 Code Source : KmdKit\examples\simple\Beeper

Vous vous demandez peut être comment les services du mode utilisateur se relient aux drivers en mode Kernel. En fait ce sont des bestioles tout à fait différentes. Mais avant que nous puissions communiquer avec le module de gestion de périphérique [ device driver ] nous devons l'installer et le démarrer. Nous devrons ici nous conformer aux règles d'interface destinées aux services.

2.1 Services

Windows NT a un mécanisme pour démarrer les processus qui fournissent des services non attachés à un utilisateur interactif. De tels processus s'appellent les services. Un bon exemple d'un service pourrait être un serveur Web. La plupart des services temporels [ time services ] n'ont absolument aucune interface utilisateur. C'est la seule catégorie d'applications fonctionnant d'une telle manière. Les services peuvent être démarrés au moment même du démarrage de système ou bien ils peuvent également être démarrés manuellement. Dans ce sens les modules de gestion de périphérique sont très semblables aux services.

Windows NT supporte également un service de drivers [ drivers services ] qui se conforme aux protocoles de module de gestion de périphérique pour Windows NT. Il est semblable au service du mode utilisateur. Ainsi, les services peuvent se référer à un processus de serveur ou encore à un module de gestion de périphérique. Microsoft a mélangé les drivers en mode Kernel et ceux en mode utilisateur. Par conséquent la suite de ce tutorial peut sembler être un imbroglio, puisque je parlerai parfois de "service" et parfois de "driver". Cet article traite uniquement des modules de gestion de périphérique (sous entendu "drivers"). Ainsi vous devriez toujours lire "driver". Je le notifierai évidemment s'il est nécessaire de séparer l'appellation "service" de celle de "driver". Considérez en outre que la documentation décrivant les fonctions en relation avec les services, est parfois plutôt ambiguë. Beaucoup de fonctions discutées dans cette section s'appliquent aussi bien aux services qu'aux modules de gestion de périphérique, mais je me concentrerai sur des modules de gestion de périphérique et éviterai de discuter des services.

Il y a trois types de composants impliqués dans le fonctionnement des services de Windows NT:

• Administrateur de contrôle de service [Service Control Manager (SCM)]. Le SCM est responsable du démarrage du service, de la communication avec lui et ainsi de suite.

• Programme de controle de service [Service Control Program (SCP)]. Le SCP communique avec le SCM lui indiquant quand démarrer ou arrêter le service et ainsi de suite.

• A programme de service qui contient le code exécutable. A ce propos vous pouvez vous remémorer ce qui a été mentionné plus tôt dans cet article, à savoir qu'un service est un module de gestion de périphérique.

Comme il a déjà été dit, nous étudierons le driver lui-même dans la prochaine partie, mais maintenant concentrerons nous sur les deux premiers composants.

2.2 L'administrateur de controle de services [SCM]

Le SCM réside dans \%SystemRoot%\System32\Services.exe. Le processus de Winlogon démarre le SCM tôt pendant le boot du système. Il balaye alors le contenu de HKLM\SYSTEM\CurrentControlSet\Services, créant une entrée dans la base de donnée de service pour chaque clef qu'il rencontre. Une entrée de base de donnée inclut tous les paramètres connexes définis pour un service. Si le service ou le driver est marqué comme ayant un démarrage automatique le SCM le démarre et détecte les échecs au démarrage.

Pour vous faire une certaine représentation à ce sujet, démarrez l'éditeur de registre (\%SystemRoot%\regedit.exe), ouvrez HKLM\SYSTEM\CurrentControlSet\Services\ et explorez son contenu.

Pour énumérer les services installés (et non les drivers), choisissez les outils d'administration du panneau de configuration, et choisissez « services ».

Depuis la « Gestion de l'ordinateur » vous pouvez énumérer les drivers installés. (Menu Démarrer, choisissez Programmes, outils d'administrations, gestion de l'ordinateur ; ou du panneau de configuration, outils d'administrations, gestion de l'ordinateur.) Depuis « gestion de l'ordinateur », ouvrez « Information système » puis « Environnement logiciel », et ouvrez « Pilotes ». (Malheureusement, cette option n'est plus présente depuis Windows XP).

Après avoir analysé le contenu de ces trois fenêtres, vous remarquerez qu'ils coïncident à bien des égards.

L'entrée HKLM\SYSTEM\CurrentControlSet\Services\ contient des sous-clés, désignées en interne par le nom du driver ou du service. Chaque sous-clé inclut tous les paramètres en relation avec le service.

Considérons un ensemble minimum possible de paramètres nécessaires pour installer un module de gestion de périphérique. Comme exemple, nous prendrons le driver beeper.sys (nous parlerons du driver en lui-même la fois prochaine).

Figure 2-1. Clés de registre pour le driver beeper.sys

Après avoir regardé le schéma 2-1, que pouvons nous dire au sujet du driver beeper.sys ? Et bien, le driver en mode Kernel du beeper réside dans le dossier C:\masm32\Ring0\Kmd\Article2\beeper. Son nom d'affichage est "Nice Beeper Melody", son démarrage est sur demande, et les erreurs possibles sont ignorées et non notifiées.

Nous verrons plus tard ce que le préfixe «  \?? » situé dans le chemin du dossier de l'image du driver signifie.

Si nous voulons démarrer le driver, qui n'est pas présent dans la base de données du SCM, cela peut être fait dynamiquement, à tout moment, avec l'aide du programme de gestion de service ( Device Control Program pour être plus précis, mais il n'existe aucun concept de ce type dans la terminologie Microsoft).

2.3 Le Programme de controle de service [SCP]

Comme l'indique son nom, le programme de gestion de service est prévu pour commander les services ou les modules de gestion de périphérique. Il fait ceci sous la surveillance du SCM, appellant les fonctions appropriées. Tous sont exportés par le module \%SystemRoot%\System32\advapi.dll ( Advanced AP I).

Voici le code du programme de gestion de service qui commandera le driver beeper.sys.

;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;                                                                                                   
;  Programme de contrôle de services pour le driver "beeper"         				  
;                                                                                                   
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

.386
.model flat, stdcall
option casemap:none

;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;                             I N C L U D E   F I L E S                                             
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

include \masm32\include\windows.inc

include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
include \masm32\include\advapi32.inc

includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib
includelib \masm32\lib\advapi32.lib

include \masm32\Macros\Strings.mac

;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;                                       C O D E                                                     
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

.code

start proc

local hSCManager:HANDLE
local hService:HANDLE
local acDriverPath[MAX_PATH]:CHAR

    invoke OpenSCManager, NULL, NULL, SC_MANAGER_CREATE_SERVICE
    .if eax != NULL
        mov hSCManager, eax

        push eax
        invoke GetFullPathName, $CTA0("beeper.sys"), sizeof acDriverPath, addr acDriverPath, esp
        pop eax

        invoke CreateService, hSCManager, $CTA0("beeper"), $CTA0("Nice Melody Beeper"), \
                SERVICE_START + DELETE, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, \
                SERVICE_ERROR_IGNORE, addr acDriverPath, NULL, NULL, NULL, NULL, NULL
        .if eax != NULL
            mov hService, eax
            invoke StartService, hService, 0, NULL
            invoke DeleteService, hService
            invoke CloseServiceHandle, hService
        .else
            invoke MessageBox, NULL, $CTA0("Can't register driver."), NULL, MB_ICONSTOP
        .endif
        invoke CloseServiceHandle, hSCManager
    .else
        invoke MessageBox, NULL, $CTA0("Can't connect to Service Control Manager."), \
                            NULL, MB_ICONSTOP
    .endif

    invoke ExitProcess, 0

start endp

;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;                                                                                                   
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

end start

2.3.1 Etablir une connexion au SCM

La première étape est d'appeler la fonction OpenSCManager pour établir un raccordement au SCM sur l'ordinateur indiqué et pour ouvrir la base de données adéquate.

OpenSCManager proto lpMachineName:LPSTR, lpDatabaseName:LPSTR, dwDesiredAccess:DWORD

.const
szActiveDatabase db "ServicesActive", 0
SERVICES_ACTIVE_DATABASE equ offset szActiveDatabase

Nous établissons une connexion au SCM comme ceci :

    invoke OpenSCManager, NULL, NULL, SC_MANAGER_CREATE_SERVICE
    .if eax != NULL
        mov hSCManager, eax

Si la fonction OpenSCManager réussit, la valeur de retour est un handle à la base de donnée du SCM indiquée. Nous passerons ce handle à d'autres fonctions pour manipuler la base de données du SCM.

Notez que l'installation de module de gestion de périphérique en mode Kernel exige un compte avec les droits d'administrateur. Ceci assure une sécurité nécessaire, ainsi les utilisateurs normaux ne peuvent pas ajouter et exécuter de code privilégié sans l'autorité compétente. Par conséquent, il est considéré ici que vous êtes administrateur.

2.3.2 Installation d'un nouveau driver

Une fois que le SCM a été ouvert, nous ajoutons notre driver à la base de données du SCM par un appel à CreateService. Voici son prototype. CreateService a treize paramètres. Mais ne paniquez pas. En fait tout ceci est plutôt simple.

CreateService proto hSCManager:HANDLE, lpServiceName:LPSTR, lpDisplayName:LPSTR, \
                    dwDesiredAccess:DWORD, dwServiceType:DWORD, dwStartType:DWORD, \
                    dwErrorControl:DWORD, lpBinaryPathName:LPSTR, lpLoadOrderGroup:LPSTR, \
                    lpdwTagId:LPDWORD, lpDependencies:LPSTR, lpServiceStartName:LPSTR, \
                    lpPassword:LPSTR

Résumons. Dans les cinq derniers paramètres nous spécifions toujours NULL, et vous pouvez complètement oublier ceux-ci. Le premier paramètre est le Handle à la base de données du SCM. Le paramètre dwDesiredAccess est très clair aussi. Je pense que vous avez déjà deviné pour ce qui est des autres paramètres. Ils correspondent aux clefs de la base de registre que nous avons analysées ci-dessus. La table ci-dessous est une aide visuelle pour votre convenance.

Comme vous pouvez le voir, tout n'est pas aussi complexe. Retournons au code source.

        push eax
        invoke GetFullPathName, $CTA0("beeper.sys"), sizeof acDriverPath, addr acDriverPath, esp
        pop eax

        invoke CreateService, hSCManager, $CTA0("beeper"), $CTA0("Nice Melody Beeper"), \
                SERVICE_START + DELETE, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, \
                SERVICE_ERROR_IGNORE, addr acDriverPath, NULL, NULL, NULL, NULL, NULL
        .if eax != NULL
            mov hService, eax

En appelant GetFullPathName nous obtenons le chemin complet au fichier du module de gestion de périphérique pour le passer ensuite à CreateService.

CreateService ajoute notre driver à la base de données du SCM, et crée une sous-clé d'enregistrement appropriée. Regardez le schéma 2-1 de nouveau. Toutes ces informations ont été ajoutées dans la base de registre par CreateService. Si vous commentez l'appel à DeleteService dans le fichier csp.asm, recompilez ce dernier et le faite fonctionner vous pouvez voir exactement la même chose sur votre ordinateur.

Ne pensez pas qu'en ayant utilisé des fonctions pour la base de registre (fonction Reg*) pour manipuler cette dernière, il soit possible d'obtenir le même résultat. Vous pouvez ajouter des données dans la base de registre, mais celles-ci n'apparaîtront pas dans la base de données du SCM.

Si le module de gestion de périphérique indiqué existe déjà dans la base de données du SCM l'appel à CreateService échouera. Un Appel à GetLastError renvoie ERROR_SERVICE_EXISTS. Si CreateService est réussi après avoir ajouté le driver à la base de données du SCM, le Handle du driver est retourné. Ce Handle est exigée par d'autres fonctions afin de manipuler le driver.

2.3.3 Démarrer le driver

T La prochaine fonction que nous devrons appeler est StartService. En voici son prototype :

StartService proto hService:HANDLE, dwNumServiceArgs:DWORD, lpServiceArgVectors:LPSTR

Maintenant nous démarrons le driver comme ceci :

            invoke StartService, hService, 0, NULL

La fonction StartService force le système à faire quelques actions qui rappelle le chargement de DLL en mode utilisateur. Une image du fichier du driver est mappée dans l'espace d'adresse du système. Le driver est toujours mappé à une adresse arbitraire. Ainsi le système exécute quelques relocalisations [relocations] dans l'image du driver en utilisant la section .reloc du fichier PE. Toutes les références aux symboles importés sont réarrangées. Quand l'image du driver est prête, le système appelle le point d'entrée du driver, qui réside dans la routine de DriverEntry. La différence principale ici est que le code de la routine de DriverEntry fonctionne toujours dans le contexte du processus système.

L'appel à la fonction StartService est synchrone. Cela signifie qu'il n'y aura pas de retour de la fonction tant que la routine DriverEntry du driver ne sera pas fini. Si l'initialisation du driver réussit, DriverEntry devrait renvoyer STATUS_SUCCESS, et StartService renverra une valeur non nulle.

La valeur retournée par StartService est sans intérêt pour nous, puisque le driver de beeper a déjà joué sa gentille mélodie et a renvoyé un code d'erreur. Ainsi, nous savons à l'avance que la fonction StartService renverra une erreur.

2.3.4 Désinstallation du driver

            invoke DeleteService, hService
            invoke CloseServiceHandle, hService
        .else
            invoke MessageBox, NULL, $CTA0("Can't register driver."), NULL, MB_ICONSTOP
        .endif
        invoke CloseServiceHandle, hSCManager

Maintenant tout ce qu'il nous reste à faire c'est de restaurer le système dans son état initial. Nous appellerons DeleteService pour enlever le driver de la base de données du SCM. Étrangement, il n'est pas nécessaire de passer le Handle de la base de données du SCM à DeleteService. Le prototype de DeleteService est très simple :

DeleteService proto hService:HANDLE

Cette fonction ne supprime pas réellement le service tout de suite ; elle marque simplement le service pour la suppression. Le SCM supprimera le service seulement quand le service cessera de fonctionner et après que tous les Handles au service aient été fermés. Car nous possédons toujours le Handle sur le driver, il n'est pas enlevé de la base de données du SCM. Si vous essayez d'appeler DeleteService à plusieurs reprises la fonction échouera ; Un appel à GetLastError retournera ERROR_SERVICE_MARKED_FOR_DELETE.

Puisque nous n'avons plus besoin de communiquer avec le driver, nous devons fermer le Handle en appelant CloseServiceHandle :

CloseServiceHandle proto hSCObject:HANDLE

Comme il n'y a plus d'handles ouverts pour le driver à cet instant , l'entrée de ce dernier est enlevée de la base de données du SCM. Le deuxième appel à CloseServiceHandle ferme le Handle au SCM lui-même.

2.4 Macros de chaînes

Enfin vous devez savoir ce qu'est $CTA0. C'est une fonction de Macro. Elle vous laisse définir une chaîne ASCII se terminant par NULL dans la section de donnée en lecture seule. Vous pouvez l'employer directement avec la macro Invoke . Cette macro n'est pas la seule. Le dossier \Macros\Strings.mac contient beaucoup d'autres macros utiles pour définir des chaînes de caractères avec une explication détaillée quant à leur emploi. Comme ces macros ne sont pas spécialement liées au développement de drivers je ne prêterai plus attention à ce sujet, mais j'emploierai de telles macros un peu partout.