Ich habe mir Windows angesehenDateisystem-Filtertreiber. Ich habe mit diesem "FsFilter" -Beispiel begonnen:

http://www.codeproject.com/Articles/43586/File-System-Filter-Driver-Tutorial

Mit Mühe gelang es mir, es in Versionen zu erstellen und zu signieren, die auf allen 64-Bit-Win8- bis 32-Bit-WinXP-Versionen funktionieren.(Nun, solange ich renneBcdedit.exe -set TESTSIGNING ON Damit mein Testzertifikat akzeptiert werden kann, habe ich für das Signieren meiner .SYS-Datei nicht Microsoft 250 US-Dollar bezahlt. : - /)

Jetzt möchte ich FsFilter ändern. Ich möchte, dass Schreibzugriffe auf bestimmte Dateitypen vom Filter abgefangen werden. Ich möchte dann, dass der Benutzer ein Dialogfeld erhält, in dem er den Zugriff entweder zulassen oder verweigern kann.

Vielleicht offensichtlich ... der Kernel-Mode-Code kann die Benutzeroberfläche nicht anzeigen. Es muss ein Benutzermodus-Prozess signalisiert werden, der (nach einer willkürlich latenten Zeitspanne) den Wunsch des Benutzers an den Fahrer zurückmeldet. Ich habe ein bisschen nachgesehenBenutzermodus-Interaktionen: Richtlinien für Kernelmodustreiber (hier istGoogles Cache als HTML, anstelle von .DOC)

Ich weiß nicht, wie ich das am besten angreifen kann. Das einzige Beispiel, das ich bisher gefunden habe, ist SysInternals FileMon. Der Treiber, den er installiert, sammelt Daten in einem Puffer, der gemäß einer WM_TIMER-Schleife regelmäßig von der EXE-Datei angefordert wird:

// Have driver fill Stats buffer with information
if ( ! DeviceIoControl( SysHandle, IOCTL_FILEMON_GETSTATS,
            NULL, 0, &Stats, sizeof Stats,
            &StatsLen, NULL ) )
{
    Abort( hWnd, _T("Couldn't access device driver"), GetLastError() );
    return TRUE;
}

Sollte ich eine ähnliche Technik anwenden? Möglicherweise könnte der Filtertreiber nach dem Empfang einer Anforderung, die geprüft werden soll, einen Datensatz zum Verfolgen der Anforderung in einem Puffer ablegen, der zwei HEVENTs enthalten würde. Es würde dann WaitForMultipleObjects auf diesen beiden HEVENTs anzeigen, die vom Benutzermodus ein "JA" oder "NEIN" signalisieren, ob der Zugriff zugelassen werden soll.

Der Monitorprozess (der im Benutzermodus ausgeführt wird) ruft den Treiber regelmäßig von einem anderen Thread mithilfe einer benutzerdefinierten IOCTL ab. Der Filtertreiber würde die Anforderungsinformationen sowie die beiden HEVENTs zurückgeben, auf die die Anforderung wartet. Der Monitor wartet auf die Rückmeldung des Benutzers und signalisiert, wenn verfügbar, das entsprechende Ereignis.

Ich könnte dieses Modell auch umkehren. Der Benutzermoduscode könnte eine benutzerdefinierte IOCTL verwenden, um Daten weiterzuleiten, wie z. B. HEVENTs, die vom Treiber signalisiert werden könnten, und einfach eine Art sicheres Protokoll implementieren. Dies würde die Notwendigkeit einer Abfrage beseitigen.

Grundsätzlich nur nach Anleitungen zur Methode oder einem Arbeitsbeispiel im Web Ausschau halten! Mich würde auch interessieren, was die Mechanik bei einem asynchronen Dateizugriff wäre. Ich nehme an, es gibt eine Möglichkeit, dass ein Client, der einen zu überprüfenden asynchronen Anruf tätigt, weiterläuft und nur dann angehalten wird, wenn er auf die Fertigstellung der Anforderung gewartet hat ...?

(Hinweis: Auf dem Weg, die Filter zu bauen und zu debuggen, habe ich gelernt, dass es über "miniFilters" einige modernere Techniken gibt, die Teil von etwas sind, das als "." Bezeichnet wirdFilter-Manager-Modell. Aber im Moment bin ich nicht so besorgt, solange das Vorgängermodell unterstützt wird. Es sieht sowieso ziemlich ähnlich aus.)