автор1) Внедриться в оболочку (explorer.exe), "легально", через какой-нибудь shell extension, или
"грязно", через инжект или оконный хук, и поставить перехватчик на CreateFile.
Плюсы: максимально простой способ, можно обойтись только функциями Win32 API, без
недокументированных возможностей, native api или использования драйверов.
Минусы: будут перехватываться только открытия файлов из Проводника.
2) Внедриться в оболочку и перехватить не только CreateFile, но и CreateProcess, после чего
появится определенный контроль над приложениями, запускаемыми пользователем (так как все они
так или иначе "наследуются" от explorer.exe). В каждом запускаемом приложении снова патчится
CreateFile и CreateProcess и так далее, на произвольную глубину запусков. То есть, перехватчик
CreateFile отслеживает открытие файла пользователем, а перехватчик CreateProcess распостраняет
эту "заразу" на дочерние процессы. По такому принципу, кстати, работают некоторые программы
скрытия файлов и папок.
Плюсы: большее, по сравнению с предыдущим способом, покрытие.
Минусы: написать качественный API-перехватчик довольно сложно (патч таблицы импорта не
универсален, а сплайсинг требует дизассемблера длин инструкций, хотя в данном случае
это решаемо, так как перехватываются лишь две функции), способ не будет работать для
служб и других процессов, запускаемых не проводником. Например, для COM-серверов в exe.
Также возможны различные конфликты с системой безопасности Windows и со сторонним софтом.
А еще существуют процессы, защищенные протекторами, где поставить перехват API-функций
довольно затруднительно, а также всякие виртуальные машины...
3) Установить глобальный перехват на CreateFile, для всех запускаемых процессов.
Еще более универсальный, но вместе с тем и более сложный способ. Основная трудность здесь именно в
отслеживании запуска новых процессов и установке в них перехватчика. Напомню, что AppInit_DLLs на
Windows 7 и выше по умолчанию отключен, к тому же dll аттачится только к GUI-процессам, запущенным
на сопостовимом с explorer.exe уровнем целостности, так что оконные хуки — очень ограниченный в
данном случае вариант. Вырисовывается схема с привелегированным процессом (LocalSystem ?), который
бы отслеживал запуск новых процессов (как ?) и патчил бы в них точку входа в CreateFile.
Плюсы: покрытие, близкое к максимальному.
Минусы: к минусам, описанным в предыдущем пункте, добавляется сложность отслеживания запуска
новых процессов из user mode.
4) Пропатчить NtCreateFile в таблице системных сервисов (SSDT hook).
Вариация предыдущего способа. Технически сопоставим по сложности.
Плюсы: не требует возни со сплайсингом/патчингом таблиц импорта, очень высокое покрытие.
Минусы: требует написания драйвера, не работает на 64-битных версиях Windows, требует знания индекса
NtCreateFile в таблице системных сервисов, который от версии к версии меняется, возможны конфликты со
сторонним софтом, которые приводят уже не просто к падению приложения, а к "синему экрану".
5) Фильтр файловой системы.
Наиболее универсальный и мощный способ. За основу берется сэмпл sfilter из WDK.
Плюсы: стопроцентное покрытие. Перехватываются открытия файлов на любых дисках, включая
съемные и виртуальные диски, сетевые шары и т.п.
Минусы: относительно высокая сложность реализации, необходимость цифровой подписи для
запуска драйвера на 64-битных версиях Windows от Vista и выше.
отсюда
