Здравствуйте!
Пытаюсь заблокировать доступ к файлу, т.е. чтобы при поптке его открыть возвращался код ошибки типа ACCESS_DENIED.
Через драйвер делаю перехват сервиса NtOpenFile, обрабатываю так:


// . . .
NTSTATUS ReNtOpenFile
(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN ULONG ShareAccess,
IN ULONG OpenOptions
)
{
DbgPrint("NtOpenFile: %ws", ObjectAttributes->ObjectName->Buffer);

// сравнение имени открываемого файла с тем что надо блокировать
if (_wcsnicmp(ObjectAttributes->ObjectName->Buffer, L"\\??\\C:\\LockMe.xxx",
ObjectAttributes->ObjectName->Length) == 0)
{ // если это тот самый файл
DbgPrint("!!! EQU !!!");

// СОМНИТЕЛЬНОЕ МЕСТО - НИЧЕГО ДРУГОГО ПРИДУМАТЬ НЕ СМОГ
*FileHandle = NULL; //
IoStatusBlock->Status = STATUS_ACCESS_DENIED;

return STATUS_ACCESS_DENIED;
}
else
{ // если это какой либо другой файл - отдаем системному сервису...
DbgPrint("!!! __NOT__ EQU !!!");

// вызов настоящего NtOpenFile
return SysOpenFile(FileHandle, DesiredAccess, ObjectAttributes, IoStatusBlock, ShareAccess, OpenOptions);
}
}

// . . .

Проблема в том, что файл C:\LockMe.xxx при всем этом _открывается_, хотя судя по отладочным сообщениям, эта ветка моего кода получает управление.
Странным мне это кажется, т.к. если в обработчике _сразу_ делать return STATUS_ACCESS_DENIED блокируется доступ ко всем файлам.

Что я делаю не так? Возможно вообще не то перехватываю (может попробывать IoCreateFile?).
Кто знает, подскажите пожалуйста.

| Сообщение посчитали полезным:

а что если FileHandle = 0xFFFFFFFF ?

| Сообщение посчитали полезным:

ну лично я делал так:
if(memcmp(BadFile,ObjectAttributes->ObjectName->Buffer,20)==0)
{
DebugPrint(("BAD CreateFile called!\n"));
(*IoStatusBlock).Status=FILE_DOES_NOT_EXIST;
return -1;
}

| Сообщение посчитали полезным:

Мда, в таком простом коде оказывается можно наделать много ошибок. Вот краткий список всего, что следует учесть:

1) ObjectAttributes->ObjectName->Buffer подобные вещи страшно небезопасны. Если из юзермода будет передан нулевой указатель - то это сразу бсод. К сожалению, это ошибка очень распостраненная. Никогда не принимай указатели из юзермода без должной проверки!
2) Сравнение с "\\??\\C:\\LockMe.xxx" просто блещет своей наивностью. Во-первых, стоит запомнить, что один и тотже файл может быть представлен несколькими разными native именами. Это может быть как \??\C:\LockMe.xxx, так и \device\harddiskvolume1\LockMe.xxx, или даже \??\fignia\hren.txt. Все зависит от того, через какие символические ссылки будет открыт файл. (к слову, некоторые проактивные защиты на этих тонкостях горят).
3) В дополнеии к 2 могу сказать, что файл может быть открыт путем нескольких последовательных вызовов NtOpenFile, с передачей путей к файлу по частям. Смотри назначение поля RootDirectory в OBJECT_ATTRIBUTES.
4) Помимо NtOpenFile файл может быть открыт через NtCreatFile либо скомунизжен у другого процесса путем копирования хэндлов.
5) может быть не FileHandle = NULL, а *FileHandle = NULL ?
6) IoStatusBlock->Status = STATUS_ACCESS_DENIED; А где же опять проверка указателей? Это уже посерьезнее AV при чтении, это уже баг на запись в память ядра, и возможно поднятие привилегий.

Вот такие вот дела...

-----
Скажем дружно - нафиг нужно.

| Сообщение посчитали полезным:

Archer
И еще один пишет драйвера непрямыми руками

-----
Скажем дружно - нафиг нужно.

| Сообщение посчитали полезным:

Просто открой его из драйвера в эксклюзивном режиме (ShareAccess == 0) и никто его по человечески больше открыть не сможет

| Сообщение посчитали полезным:

To MS-Rem:
1) Согласен полностью - сей код чисто "на посмотреть на форуме" дабы кто-то ответил на основной вопрос. В реале ф-ия покрупнее будет (с проверками все ок) и всю ее выкладывать - отмимать чье то время.
2-3-4) Тоже понятно, но мне бы _сейчас_ хоть _так_ заставить это работать
5) Это да )) не заметил что то...
6) то что и к 1)
За критику спасибо, но я помощь попросил, а не...
Ваше обращение к Archer это еще и в мою сторону камень. При всем увежении в Вам MS-Rem, но вы от рождения дрова пишете, или тоже когда то начинали?
Меня интересует почему даже _так_ не работает.

Что же все также должен возвращать NtOpenFile в таких ситуациях?

| Сообщение посчитали полезным:

shadow_warrior пишет:
Что же все также должен возвращать NtOpenFile в таких ситуациях?
ну открой несуществующий файл и посмотри что она возвращает...

| Сообщение посчитали полезным:

shadow_warrior пишет:
Меня интересует почему даже _так_ не работает.

Тебе уже обьяснили почему не работает. Из за кривого сравнения имени файла. И из за того, что файл открывается еще через ZwCreateFile. Неужели трудно взять отладчик и проверить, вместо того, чтобы задавать глупые аопросы?

-----
Скажем дружно - нафиг нужно.

| Сообщение посчитали полезным:

DrGolova
Просто открой его из драйвера в эксклюзивном режиме (ShareAccess == 0) и никто его по человечески больше открыть не сможет

сможет через CreateFile =) ....но не совсем по человечески

-----
power and the money money and the power

| Сообщение посчитали полезным: