Я тут пишу драйверок, он просто подменяет системные сервисы ядра.
Так вот, мне нужно подменить всего 2 функции:

ZwCreateFile()
ZwOpenFile()

С функцией ZwCreateFile() прошло все легко. А вот с ZwOpenFile у меня небольшая проблема. По ней у меня собственно и вопрос:
я делаю так, — в своем обработчике принимаю все параметры, которые предназначены для функции ZwOpenFile(), проверяю имя файла, оно содержится в одном из параметров функции — структуре ObjectAttributes->ObjectName,
если оно \??\c:\myfile.dat, то что-то делаю, иначе передаю через стек параметры и вызываю оригинальный обработчик.

Так вот, для ZwCreateFile() такая проверка работала, а для ZwOpenFile() почему-то нет.

Хотелось бы услышать возможные идеи по решению этой проблемы. Наверняка это уже кто-нибудь делал.
Заранее спасибо.

Здравствуйте, nike_zp, Вы писали:

---Описание проблемы покусано----

1) У структуры OBJECT_ATTRIBUTES есть поле RootDirectory. Это handle родительского каталога, если он равен NULL, то в поле ObjectName находится абсолютное имя файла. (Начиная с корня дерева объектов.) Если же это не так, то ObjectName содержится относительное имя файла, а для получения абсолютного имени надо узнать имя объекта, представленного в поле RootDirectory и к нему приписать содержимое поля ObjectName.
2) Гм., всегда считал, что перехват указанных вами функций NativeAPI это не самый лучший способ решения вашей задачи. Ведь я всегда могу из драйвера послать открыть файл без этих функций. (формирую запросы к драйверу файловой системы) Или это в вашем случе проблемы не представляет?

Здравствуйте, nike_zp, Вы писали:

_>Я тут пишу драйверок, он просто подменяет системные сервисы ядра.
_>Так вот, мне нужно подменить всего 2 функции:

_> ZwCreateFile()
_> ZwOpenFile()
как минимум не 2, посмотрите в сторону IoCreateFile — в итоге все сводится к ней, а за ней уже ... ну если не Москва, то конструирование IRP точно

_>С функцией ZwCreateFile() прошло все легко. А вот с ZwOpenFile у меня небольшая проблема. По ней у меня собственно и вопрос:
_>я делаю так, — в своем обработчике принимаю все параметры, которые предназначены для функции ZwOpenFile(), проверяю имя файла, оно содержится в одном из параметров функции — структуре ObjectAttributes->ObjectName,
_>если оно \??\c:\myfile.dat, то что-то делаю, иначе передаю через стек параметры и вызываю оригинальный обработчик.

_>Так вот, для ZwCreateFile() такая проверка работала, а для ZwOpenFile() почему-то нет.
имя файла не всегда абсолютное

_>Хотелось бы услышать возможные идеи по решению этой проблемы. Наверняка это уже кто-нибудь делал.
_>Заранее спасибо.
проблему возможно Вам и удастся решить на конкретной версии ntoskrnl, сервис пака или даже ОС, но Вы попробуйте затем свое изделие поставить под driver verifier, под серьезную нагрузку и прогоните хотя бы тесты из MS HCT (то что делается в рамках процедуры WHQL).

в любом случае такой грязный хак не есть правильно. Это непереносимо, часто даже между промежуточными версиями ОС, не говоря уже об IA64/AMD64 и просто потенциально опасно. Т.е. никто никогда не сертифицирует официально такой драйвер, не говоря уже о продажах — если это минимально коммерческий продукт, можно огрести тонну проблем на саппорте и багофиксинге ибо версий ОС (включая локализованные!) с разными ntoskrnl просто огромно. И это при довольно тяжелой и недешовой разработке и QA. Серьезный заказчик пойдет по этому скользкому пути только при отсутствии других вариантов решения проблемы, либо по незнанию

Если Вам всего лишь нужно контролировать доступ к файлу, есть более легкий способ:
— SetFileSecurity, SetNamedSecurityInfo или SetKernelObjectSecurity на файл на файловой системе поддерживающей ACL.

Но если этого Вам недостаточно и все же хочется в динамике работать с запросами к файлу, то правильно в данном случае написать фильтр файловой системы и получить в нем аккуратно что нужно в правильном месте и в правильное время.

Начиная с ХР есть сервис позволяющий в Вашем фильтре легко получить имя файла (я про IoCreateFileSpecifyDeviceObjectHint). На более ранних системах немного сложнее, но в любом случае это будет правильнее чем Ваш способ.