Pourquoi les gestionnaires de partitions ont-ils besoin de leurs propres pilotes?

@David Schwartz a suggéré que c'est parce qu'ils interceptent tout l'accès au disque. Cela me semble certainement crédible. Mais je me demande si c'est toute l'histoire. J'ai enquêté sur le pilote EaseUS, empmntdrv.sys. Voici quelques points à noter :

1. Il se charge dès que je lance l'interface utilisateur, sans effectivement partitionner quoi que ce soit.

2. Les forums de EaseUS regorgent de messages de personnes se plaignant que aucune partition n'apparaisse lorsqu'elles lancent l'interface utilisateur, et la réponse standard du support technique de EaseUS est : réinstaller le pilote. Cela me fait penser qu'il est utilisé pour en fait lire la table.

3. J'ai sorti l'artillerie lourde : PE Explorer pour désassembler le fichier du pilote. Principalement du chinois pour moi, bien sûr, mais quelques choses me sautent aux yeux. Tout d'abord, la table des symboles montre la liste des appels système effectués vers ntoskrnel.exe, et cela inclut des manipulations de liens symboliques :

   ; Importations de ntoskrnl.exe
       extrn DbgPrint
       extrn ExAllocatePoolWithTag
       extrn ExFreePoolWithTag
       extrn IoBuildAsynchronousFsdRequest
       extrn IoBuildDeviceIoControlRequest
       extrn IoCreateDevice
       extrn IoCreateSymbolicLink
       extrn IoDeleteDevice
       extrn IoDeleteSymbolicLink
       extrn IoFreeIrp
       extrn IoFreeMdl
       extrn IoGetAttachedDeviceReference
       extrn IoGetDeviceObjectPointer
       extrn IofCallDriver
       extrn IofCompleteRequest
       extrn KeBugCheckEx
       extrn KeInitializeEvent
       extrn KeSetEvent
       extrn KeTickCount
       extrn KeWaitForSingleObject
       extrn MmMapLockedPagesSpecifyCache
       extrn MmUnlockPages
       extrn ObfDereferenceObject
       extrn ObfReferenceObject
       extrn RtlAnsiCharToUnicodeChar
       extrn RtlInitUnicodeString
       extrn RtlUnicodeStringToInteger
       extrn memcpy
       extrn memset

   Remarquez aussi que ce ne sont pas les routines du pilote de filtre, ce sont des fonctions IO de bas niveau. (Pas FltGetDiskDeviceObject, mais plutôt IoGetDeviceObjectPointer).

4. En continuant à fouiner, j'ai trouvé quelques constantes qui pourraient donner plus d'indices. Comme la plupart du code compilé Windows, il y a une référence directe au fichier PDB, généralement avec le chemin sur l'ordinateur qui l'a créé :

   h:\epm2.0\01_projectarea\00_source\epm2\mod.windiskaccessdriver\windiskaccessdriver\objfre_wxp_x86\i386\epmntdrv.pdb

   C'est probablement le nom du projet du développeur : "win disk access driver" Je pense qu'ils ont besoin du pilote pour lire réellement la table d'une manière qui leur est utile.

5. Ensuite, il y a cette constante, qui semble vraiment intéressante :

   \Device\Harddisk%u\Partition0

   Cela semblait assez intéressant pour que je suive sa référence dans le code désassemblé, ce qui m'a amené ici :

    0001051E  68C6190100                       push    L000119C6
    00010523  6A78                             push    00000078h
    00010525  50                               push    eax
    00010526  E85BFFFFFF                       call    SUB_L00010486
    0001052B  83C420                           add esp,00000020h
    0001052E  85C0                             test    eax,eax
    00010530  7404                             jz  L00010536
    00010532                           L00010532:
    00010532  33C0                             xor eax,eax
    00010534  EB43                             jmp L00010579
    00010536                           L00010536:
    00010536  8D4584                           lea eax,[ebp-7Ch]
    00010539  50                               push    eax
    0001053A  8D8574FFFFFF                     lea eax,[ebp-0000008Ch]
    00010540  50                               push    eax
    00010541  FF15941A0100                     call    [ntoskrnl.exe!RtlInitUnicodeString]
    00010547  8D4580                           lea eax,[ebp-80h]
    0001054A  50                               push    eax
    0001054B  8D857CFFFFFF                     lea eax,[ebp-00000084h]
    00010551  50                               push    eax
    00010552  56                               push    esi
    00010553  8D8574FFFFFF                     lea eax,[ebp-0000008Ch]
    00010559  50                               push    eax
    0001055A  FF15901A0100                     call    [ntoskrnl.exe!IoGetDeviceObjectPointer]

6. Alors, quelle chose magique fait IoGetDeviceObjectPointer, qui n'est disponible qu'en mode noyau, vous dire lorsque vous l'appelez sur \Device\Harddisk0\Partition0 ?

   Dans un ancien post sur comp.os.ms-windows.programmer.nt.kernel-mode:

   Si vous obtenez le pointeur vers \device\harddisk(n)\partition(n) en utilisant IoGetDeviceObjectPointer(), vous obtiendrez un pointeur vers l'objet de périphérique des partitions. Si vous voulez l'objet de périphérique du disque physique, vous devez obtenir le pointeur vers \device\harddisk(n)\partition0.

   Ainsi, la partition0 nous permet d'accéder au disque physique

   Et cela nous donne beaucoup de métriques et de compteurs de performances qui sont en dessous du niveau logique du disque.

7. Enfin, essayant de trouver un moment où je pensais qu'il pourrait effectivement utiliser le pilote. J'ai lancé un "test de surface" depuis EaseUS, et j'ai vu des statistiques sur les performances. Ils pourraient le faire au niveau utilisateur, mais dans Process Explorer, lorsque j'ai pris une capture d'écran, j'ai soudain vu le fichier Device.mo actif : vraisemblablement la partie du système qui communique avec le pilote.

Je ne suis toujours pas sûr que ce soit une bonne réponse à la question. Mais c'était amusant d'explorer, de toute façon ! Merci de lire.

Ils doivent intercepter tous les accès au disque. Par exemple, supposons que vous êtes en train de cloner une partition. Si des écritures sont faites sur le disque pendant le processus de clonage, le secteur écrit doit être cloné avant de permettre à l'écriture de passer, sinon le clone résultant sera incohérent.