Patrzyłem na WindowsSterowniki filtru systemu plików. Zacząłem od tego przykładu „FsFilter”:

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

Z wysiłkiem udało mi się go zbudować i podpisać w wersjach, które działają na wszystkim, od 64-bitowego Win8 do 32-bitowego WinXP.(Cóż, dopóki biegnęBcdedit.exe -set TESTSIGNING ON aby zezwolić na zaakceptowanie mojego certyfikatu testowego, ponieważ nie zapłaciłem Microsoftowi 250 USD za podpisanie pliku .SYS. : - /)

Teraz chcę zmodyfikować FsFilter. Chciałbym, aby dostęp do zapisu do pewnych typów plików był zatrzymywany przez filtr. Następnie chcę, aby użytkownik otrzymał okno dialogowe, w którym może zezwolić na dostęp lub odmówić.

Być może oczywiście ... kod trybu jądra nie może wyświetlić interfejsu użytkownika. Będzie musiał zasygnalizować proces w trybie użytkownika, który (po dowolnie ukrytym okresie czasu) zasygnalizuje kierowcy, że chce. Trochę się obejrzałemInterakcje w trybie użytkownika: wytyczne dla sterowników trybu jądra (tu jestPamięć podręczna Google jako HTML, zamiast .DOC)

Nie wiem, jaki jest najlepszy sposób na atak. Jedynym przykładem, który do tej pory odkryłem, jest SysInternals FileMon. Sterownik, który instaluje, gromadzi dane w buforze, który jest okresowo żądany przez .EXE zgodnie z pętlą WM_TIMER:

// 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;
}

Czy powinienem użyć podobnej techniki? Być może sterownik filtru po otrzymaniu żądania, które chce sprawdzić, może umieścić rekord w celu śledzenia żądania w buforze, który zawierałby dwa HEVENTy. Następnie oczekiwałbyForMultipleObjects na tych dwóch HEVENTach, które reprezentują sygnalizowane „TAK” lub „NIE” w trybie użytkownika, czy zezwolić na dostęp.

Okresowo proces monitorowania (działający w trybie użytkownika) będzie odpytywał sterownik z innego wątku za pomocą niestandardowego IOCTL. Sterownik filtru zwróci informacje o żądaniu ... jak również dwa HEVENTy, na które oczekuje żądanie. Monitor będzie oczekiwał na informację zwrotną od użytkownika, a kiedy będzie dostępny, zasygnalizuje odpowiednie zdarzenie.

Mogłem także odwrócić ten model. Kod trybu użytkownika może używać niestandardowego IOCTL do przekazywania danych ... takich jak HEVENTs, które mogą być sygnalizowane przez sterownik, i po prostu zaimplementować jakiś bezpieczny protokół. Wyeliminowałoby to potrzebę odpytywania.

Po prostu szukam wskazówek dotyczących metody lub działającego przykładu w sieci! Chciałbym również wiedzieć, jaka byłaby mechanika asynchronicznego dostępu do plików. Zakładam, że istnieje sposób, aby klient wykonujący sprawdzane połączenie asynchroniczne mógł nadal działać i być zatrzymywany tylko wtedy, gdy czekał na żądanie zakończenia ...?

(Uwaga: Wraz ze sposobem budowania i debugowania filtrów dowiedziałem się, że za pomocą „miniFilterów” są pewne bardziej nowoczesne techniki - które są częścią czegoś, co nazywa sięModel menedżera filtrów. Ale na razie nie jestem tym zainteresowany, dopóki obsługiwany jest stary model. I tak wygląda podobnie.)