сокрытие файлов и папок

Ms Rem, CARDINAL

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

 

NeuronViking

+ NtOpenFile



Я когда делал, то перехватывал эти 3 ф-ции: NtQueryDirectoryFile, NtCreateFile, NtOpenFile, и все четко пашет.

 

так нельзя делать уже хотябы потому что есть случаи когда ObjectAttributes.FileName показывает на вот такую UNICODE_STRING -> {DW 0, DW 0, DD 0}

и на команде "cmp word ptr[eax+6],03Ah" ты получишь AV



SEH обязателен, иначе будешь падать, проверено

 

MegaZu

того что ты перечислил тоже недостаточно )

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

 

NeuronViking



Ну если так ... то какие еще ф-ции надо перехватить в ядре ?

 

NeuronViking

А если с ним перехватывать еще ZwOpenFile то достаточно. И вобще, где тут шла речь о контроле доступа к файлам юзермодных приложений? К чему это ты?

 

Ms Rem, нет не достаточно...

речь шла там, где я задал тебе вопрос.

 

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

 

ага, перехватить еще и ReadProcessMemory, тогда и хэндла не получишь из другова процесса=))))

 

Ms Rem, CARDINAL

еще раз повторяю - перехвата системных сервисов недостаточно для контроля обычных программ

 

А ты не повторяй, а обьясни свою точку зрения.

Я могу свою точку зрения аргументировать так:

Обычные программы перед работой с файлами открывают их с помощью CreateFile и OpenFile (копирование хендлов, прямой доступ к тому и.т.п. трюки они не используют), а эти функции сводятся к системным вызовам ZwCreateFile и ZwOpenFile. Ты же говоришь что их перехвата недостаточно. Пожалуйста обьясни почему.

 

приведу один пример - если папку с файлами расшарить и залезть на нее как на сетевой ресурс, то перехват сервисов SSDT желаемого результата не даст.

что проконтролировать эту, конкретно взятую, ситуацию необходимо перехватывать IoCreateFile... по этой теме можешь почитать об архитектуре CIFS.

 

...речь идет естественно об обычных программах использующих CreateFile и OpenFile без всяких ухищрений...

 

Ну дык если ведеться контроль за приложениями запущеными на этой машине, то доступ к файлам на шарак всеравно будет идти через CreateFile и OpenFile. А про контроль досупа к файлам из сети через шары мы не говорили. В таком случае вобще лучше ставить фильтр ФС.

 

Люди, это всё интересно, но мне не нужно работать с файлами, и также не нужно запрещать работу с файлами кому бы то ни было.

Мне нужно запретить отображение файлов программами типа explorer.exe, wincmd.exe и т.п.



Ms Rem



Не понял аргументации

Берем обычную программу - explorer.exe.

Идем в C:\Windows\system32\

В этой папке 3000 файлов. Значит ли это, что при отображении в листвью проводника списка файлов будет 3000 раз вызвана CreateFile и 3000 раз вызвана OpenFile и 3000 раз вызвана CloseHandle ?



И ещё, о перехвате ZwQueryDirectoryFile: мне не нужен код перехвата. Мне интересно понять, почему последний приведенный мной код выводит все поля структуры FILE_BOTH_DIRECTORY, кроме поля FileName?

 

Покажи свое описание структуры FILE_BOTH_DIRECTORY_INFORMATION

 

Код (Text):

1. FILE_BOTH_DIRECTORY_INFORMATION struct
2.     NextEntryOffset     dd ?
3.     Unknown             dd ?
4.     CreationTime        LARGE_INTEGER <>
5.     LastAccessTime      LARGE_INTEGER <>
6.     LastWriteTime       LARGE_INTEGER <>
7.     ChangeTime          LARGE_INTEGER <>
8.     EndOfFile           LARGE_INTEGER <>
9.     AllocationSize      LARGE_INTEGER <>
10.     FileAttributes      dd ?
11.     FileNameLength      dd ?
12.     EaInformationLength dd ?
13.     AlternateNameLength db ?
14.     AlternateName       dw 12 dup (?)
15.     FileName            dw ?
16.  
17. FILE_BOTH_DIRECTORY_INFORMATION ends

Переделано со справочника Неббета. Оригинал:

Код (Text):

1. typedef struct _FILE_BOTH_DIRECTORY_INFORMATION { // Information Class 3
2. ULONG          NextEntryOffset;
3. ULONG          Unknown;
4. LARGE_INTEGER  CreationTime;
5. LARGE_INTEGER  LastAccessTime;
6. LARGE_INTEGER  LastWriteTime;
7. LARGE_INTEGER  ChangeTime;
8. LARGE_INTEGER  EndOfFile;
9. LARGE_INTEGER  AllocationSize;
10. ULONG          FileAttributes;
11. ULONG          FileNameLength;
12. ULONG          EaInformationLength;
13. UCHAR          AlternateNameLength;
14. WCHAR          AlternateName[12];
15. WCHAR          FileName[1];
16. } FILE_BOTH_DIRECTORY_INFORMATION, *PFILE_BOTH_DIRECTORY_INFORMATION;

При открытии папок структура содержит количество итемов, совпадающее с количеством объектов в папке (с учетом "." и ".."). По FileNameLength проверяю длины имён - все совпадают, вместо самих имен - ерунда типа "???????". Грешил на DbgPrint - сделал с RtlUnicodeStringToAnsiString и затем вывод анси строки - та же картина.

 

У тебя структура ошибочна. Вот правильная структура.

Код (Text):

1. typedef struct _FILE_BOTH_DIRECTORY_INFORMATION
2. {
3.     ULONG NextEntryOffset;
4.     ULONG Unknown;
5.     LARGE_INTEGER CreationTime;
6.     LARGE_INTEGER LastAccessTime;
7.     LARGE_INTEGER LastWriteTime;
8.     LARGE_INTEGER ChangeTime;
9.     LARGE_INTEGER EndOfFile;
10.     LARGE_INTEGER AllocationSize;
11.     ULONG  FileAttributes;
12.     ULONG  FileNameLength;
13.     ULONG  EaInformationLength;
14.     USHORT AlternateNameLength;
15.     WCHAR  AlternateName [12];
16.     WCHAR  FileName [1];
17. } FILE_BOTH_DIRECTORY_INFORMATION,*PFILE_BOTH_DIRECTORY_INFORMATION;

 

Ага, уже заметил. Ёперный неббет

Решил посмотреть FileName в HEX-виде - видно, что там есть юникод-символы (коды символов чередуются с нулями), и случайно обратил внимание, что нули стоят на четных позициях(0,2,4,6), а должны на нечетных...

Хотя до сих пор никаких ошибок у него не встречал.

Спасибо. В т.ч. и за глобальные. Окончательно выглядит так:

Код (Text):

1. NewZwQueryDirectory proc hDir:DWORD,Event:DWORD,pApcR:DWORD,pApcC:DWORD,pIO:DWORD,pOut:DWORD,cb Out:DWORD,iClass:DWORD,bSingle:DWORD,pwName:DWORD,bRestart:DWORD
2.     LOCAL uStr          :UNICODE_STRING
3.     LOCAL aStr          :ANSI_STRING
4.     LOCAL retValue      :DWORD
5.        
6.     push    bRestart
7.     push    pwName
8.     push    bSingle
9.     push    iClass
10.     push    cbOut
11.     push    pOut
12.     push    pIO
13.     push    pApcC
14.     push    pApcR
15.     push    Event
16.     push    hDir
17.     call    dword ptr trueZwQueryDirectory
18.     mov     retValue,eax
19.     .if     (!eax)
20.         .if     (iClass==3)
21.             .if     (pOut)
22.                 push    ebx
23.                 mov     ebx,pOut
24.                 assume  ebx : ptr FILE_BOTH_DIRECTORY_INFORMATION
25.                 _loop:
26.                     mov     eax,[ebx].FileNameLength
27.                     mov     uStr._Length,ax
28.                     inc     eax
29.                     mov     uStr.MaximumLength,ax
30.                     lea     eax,[ebx].FileName
31.                     mov     uStr.Buffer,eax
32.                     invoke  RtlUnicodeStringToAnsiString, addr aStr, addr uStr, TRUE
33.                     .if     (!eax)
34.                         invoke  DbgPrint, $CTA0("%s"), aStr.Buffer
35.                         invoke  RtlFreeAnsiString, addr aStr
36.                     .endif
37.                     cmp     [ebx].NextEntryOffset,0
38.                     je      @F
39.                     add     ebx,[ebx].NextEntryOffset
40.                     jmp     _loop
41.                 @@:
42.                 assume  ebx : nothing
43.                 pop     ebx
44.             .endif
45.         .endif
46.     .endif
47.     mov     eax,retValue
48.     ret
49.    
50. NewZwQueryDirectory endp

 

Тоже сталкивался с этим глюком в неббете.

Видимо ты не делал поиск перед тем как пост создавал