мы смотрели на WindowsДрайверы фильтров файловой системы, Я начал с этогоFsFilter» пример:

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

С усилием мне удалось собрать его и подписать в версиях, которые работают на всем: от 64-битной Win8 до 32-битной WinXP.(Ну пока бегаюBcdedit.exe -set TESTSIGNING ON чтобы он мог принять мой сертификат испытаний, так как я неt заплатить Microsoft $ 250, чтобы подписать мой файл .SYS. : - /)

Теперь я хочу изменить FsFilter. Я'Я хотел бы получить доступ для записи к определенным типам файлов, которые будут перехвачены фильтром. Затем я хочу, чтобы пользователь получил диалоговое окно, в котором он может разрешить доступ или запретить его.

Возможно, очевидно ... код режима ядра не может отображать пользовательский интерфейс. Он должен будет сигнализировать о некотором процессе пользовательского режима, который (после произвольно скрытого периода времени) сообщит пользователю 'Желание водителя. Я'я посмотрел немногоВзаимодействие в пользовательском режиме: рекомендации для драйверов режима ядра (ЗдесьGoogle»Кэш как HTMLвместо .DOC)

Я неНе знаю, как лучше атаковать это. Единственный пример, который яЯ нашел для изучения SysInternals FileMon. Установленный драйвер собирает данные в буфер, который периодически запрашивается .EXE в соответствии с циклом 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;
}

Должен ли я использовать подобную технику? Возможно, драйвер фильтра после получения запроса, который он хочет проверить, может поместить запись для отслеживания запроса в буфер, который будет содержать два объекта HEVENT. Затем было бы WaitForMultipleObjects на этих двух HEVENT, которые представляют сигнализированный "ДА" или же "НЕТ» из режима пользователя о том, разрешить ли доступ.

Периодически процесс мониторинга (запущенный в пользовательском режиме) будет опрашивать драйвер из другого потока, используя собственный IOCTL. Драйвер фильтра будет возвращать информацию о запросе ... а также два события, которые ожидает запрос. Монитор будет ждать пользователяс обратной связью, и когда доступно, сигнализируют соответствующее событие.

Я мог бы также инвертировать эту модель. Код пользовательского режима может использовать пользовательский IOCTL для передачи данных ... таких как HEVENT, которые могут сигнализироваться драйвером, и просто реализовывать какой-то безопасный протокол. Это исключило бы необходимость опроса.

В основном просто ищу руководство по методу или рабочий пример в Интернете! Я'Мне также было бы интересно узнать, какова будет механика асинхронного доступа к файлам. Я предполагаю, что тамЕсть ли способ, чтобы клиент, выполняющий проверяемый асинхронный вызов, мог продолжать работу и задерживаться только тогда, когда он ждал завершения запроса ...?

(Примечание: на пути к созданию и отладке фильтров я узнал, что есть несколько более современных методов через "минифильтры»- которые являются частью чего-то под названиемМодель диспетчера фильтров, Но на данный момент яМеня это не касается, если поддерживается устаревшая модель. Это выглядит довольно похоже в любом случае.)