Не пойму причину "падения системы"..

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

Всем спасибо, сейчас начну проверять с фастмьютексом...

 

ExTryToAcquireFastMutex пробует захватить, если удачно - возвращает TRUE, если неудачно - FALSE.
тогда первый поток захватит мьютекс, а рекурсивные вызовы пройдут прозрачно в nt!NtClose по идее

 

Вообщем то опять какие-то сбои...

Код (Text):

1. NTSTATUS NewNtClose( IN HANDLE  Handle)
2. {NTSTATUS D;
3. NTSTATUS  status;
4. PFILE_OBJECT pFileObject;
5. UNICODE_STRING devpath, dev2;
6. ANSI_STRING ansiStr;
7.  
8. //DPRINT("CLOSE HANDLE %x, NORMAL ", Handle);
9.   if (ExTryToAcquireFastMutex(&g_fMutex))
10.               {
11.             //  DPRINT("@@@ CLOSE HANDLE %x, IN MUTEX ", Handle);
12.                  // do some actions
13.                  status = ObReferenceObjectByHandle(Handle,
14.                                                0,
15.                                                *IoFileObjectType,
16.                                                KernelMode,
17.                                                &pFileObject,
18.                                                NULL
19.                                                );
20.                 if (status ==0 ) {
21.                            
22. //      RtlVolumeDeviceToDosName(pFileObject->DeviceObject , &devpath);
23. //  DPRINT("CLOSE HANDLE %x, status = %x, PATH = %S", Handle, status,devpath.Buffer ); 
24.  
25.                            
26.                         if (( pFileObject->WriteAccess)&&(1==1) ){
27.                                
28.                             DPRINT("WRITE CLOSE HANDLE %x, status = %x, FILE = %S", Handle, status,  pFileObject->FileName.Buffer);    
29.  
30.  
31.                                                                     }
32.                     ///ExFreePool(devpath.Buffer);                             
33.                                     }
34.                 if (pFileObject!=NULL) ObDereferenceObject(&pFileObject);  
35.          
36.      ExReleaseFastMutex (&g_fMutex);
37.   }
38. D = TrueNtClose(Handle);
39. return D;

RtlVolumeDeviceToDosName
все равно сбоит ((
Попробую убрать эту конструкцию и использовать
ZwQueryObject(handle, ObjectNameInformation ...)

 

Никто не знает, почему для файлов не работает
ZwQueryObject

То есть я таким образом опрашиваю все хакрываемые хендлы
ObjectTypeInfo
ObjectBasicInfo
ObjectNameInfo

Ну так вот, для ключей реестра дается полный пусть в закрываемому разделу, и

Код (Text):

1. ZwQueryObject (
2.     IN HANDLE               ObjectHandle,
3.     IN OBJECT_INFO_CLASS    ObjectInformationClass,
4.     OUT PVOID               ObjectInformation,
5.     IN ULONG                Length,
6.     OUT PULONG              ResultLength
7. );

если это реестр, возвращяет ненулевое, а соотв. длине ключа реестра, а если это файл, то там всегда ноль..

Код (Text):

1. ZwQueryObject(Handle, ObjectNameInfo,NULL, 0, &RES1);
2.              if (RES1>0)
3.              {
4.             pFileObj = (POBJECT_NAME_INFORMATION) ExAllocatePool(PagedPool, RES1);
5.             ZwQueryObject(Handle, ObjectNameInfo, pFileObj, RES1, &RES1);
6.             DPRINT("Additional info: %wZ", &pFileObj->Name);
7.             ExFreePool(pFileObj);

А на запрос ObjectTypeInfo внятно получаю File...

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


Можно ли в ZwQueryObject все же получить имя файла..??

Изучаю ZwQueryInformationFile

 

ZwQueryInformationFile дает обрезанные пути ((

Как заколустался уже с этими БСОДами...

 

test555
И я тоже )))

 

нащет FILE_NAME_INFORMATION не знаю - не юзал
а ZwQueryInformationFile c FILE_ALL_INFORMATION возвращает path от корня
вполне достаточно ИМХО
только я в ядре стараюсь не юзать АПИ, а сам заполняю IRP и говорю IoCallDriver - так надежнее ИМХО

 

z0mailbox, возможно что я где-то ошибся, но:

Код (Text):

1. typedef struct _FILE_ALL_INFORMATION {
2.     FILE_BASIC_INFORMATION      BasicInformation;
3.     FILE_STANDARD_INFORMATION   StandardInformation;
4.     FILE_INTERNAL_INFORMATION   InternalInformation;
5.     FILE_EA_INFORMATION         EaInformation;
6.     FILE_ACCESS_INFORMATION     AccessInformation;
7.     FILE_POSITION_INFORMATION   PositionInformation;
8.     FILE_MODE_INFORMATION       ModeInformation;
9.     FILE_ALIGNMENT_INFORMATION  AlignmentInformation;
10.     FILE_NAME_INFORMATION       NameInformation;
11. } FILE_ALL_INFORMATION, *PFILE_ALL_INFORMATION;

Та стркутура мне дается если делать запрос

Код (Text):

1. status=ZwQueryInformationFile(Handle,&IoStatusBlock, pFile_allinfo,  4000,   FileAllInformation );

Но поле FILE_NAME_INFORMATION NameInformation -- все равно приводит к

Код (Text):

1. typedef struct _FILE_NAME_INFORMATION {
2.     ULONG FileNameLength;
3.     WCHAR FileName[1];
4. } FILE_NAME_INFORMATION, *PFILE_NAME_INFORMATION;

Что в свою очередь мне дает неполный путь, то же самое что и опросил я с FileNameInformation
...

И еще, откуда мне узнать, сколько этому шайтану надо памяти выделить чтобы он туда данные вбил?

 

Код (Text):

1. NTSTATUS NewNtClose( IN HANDLE  Handle)
2. {NTSTATUS D;
3. NTSTATUS  status;
4. PFILE_OBJECT pFileObject;
5. UNICODE_STRING devpath, dev2;
6.   if (ExTryToAcquireFastMutex(&g_fMutex))
7.               {
8.                  status = ObReferenceObjectByHandle(Handle,
9.                                                0,
10.                                                *IoFileObjectType,
11.                                                KernelMode,
12.                                                &pFileObject,
13.                                                NULL
14.                                                );
15.                 if (status ==0 ) {
16.  
17.                         if ( pFileObject->WriteAccess   ){
18.                         DPRINT(" FILE  BEFORE");
19. status = IoVolumeDeviceToDosName(pFileObject->DeviceObject , &devpath);
20.                         DPRINT(" FILE  after %x",status ); 
21.                            
22.                                     }
23.                 if (pFileObject!=NULL) ObDereferenceObject(&pFileObject);  
24.  
25.      ExReleaseFastMutex (&g_fMutex);
26.   }
27.  
28. D = TrueNtClose(Handle);
29. return D;
30. }

очень интересно, почему IoVolumeDeviceToDosName мне возвращяет 0xC000000D

0xC000000D
STATUS_INVALID_PARAMETER
An invalid parameter was passed to a service or function.

 

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

 

что ты имеешь в виду под "неполным путем" ?

можно
1) фильтр-драйвер
2) ReadDirectoryChangesW (только для изменений)

 

Ура. Избавился от проблем. Объяснить в чем дело - не могу...

Сработала связка функций

Код (Text):

1. status = ObReferenceObjectByHandle(Handle,
2.                                                FILE_READ_ATTRIBUTES,
3.                                                *IoFileObjectType,
4.                                                KernelMode,
5.                                                &pFileObject,
6.                                                NULL
7.                                                );
8.                 if (status ==0 ) {
9.  
10. status = ObQueryNameString(pFileObject->DeviceObject, NULL , 0 ,  &RES1);

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

Зато приобел некие навыки и знания.
Всем спасибо. Вопрос больше не актуален, но кто все же хочет - может высказать мнения..

 

test555

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