получение HANDLE'ов файлов

разбирал статью Ms-rem'a [ http://www.wasm.ru/article.php?article=lockfileswork ].

для kernelmode:

Код (Text):

1. PVOID GetInfoTable( ULONG ATableType )
2. {
3.     ULONG mSize = 0x4000;
4.     PVOID mPtr = NULL;
5.     NTSTATUS St;
6.     do
7.     {
8.         mPtr = ExAllocatePoolWithTag( PagedPool, mSize, 'lbat' );
9.         memset( mPtr, 0, mSize );
10.         if ( mPtr )
11.         {
12.             St = ZwQuerySystemInformation( ATableType, mPtr, mSize, NULL );
13.         } else return NULL;
14.         if ( St == STATUS_INFO_LENGTH_MISMATCH )
15.         {
16.             ExFreePool( mPtr );
17.             mSize = mSize * 2;
18.         }
19.     }
20.     while ( St == STATUS_INFO_LENGTH_MISMATCH );
21.     if ( St == STATUS_SUCCESS )
22.         return mPtr;
23.     ExFreePool( mPtr );
24.     return NULL;
25. }

но когда начинаю перечислять хэндлы:

Код (Text):

1. PSYSTEM_HANDLE_INFORMATION Info;
2. PFILE_OBJECT p_fo;
3.  
4. Info = GetInfoTable( SystemHandleInformation );
5.  
6.         if ( Info )
7.         {
8.             DbgPrint( " type = %d, Name = %ws\n ", p_fo->Type, p_fo->FileName.Buffer );
9.             for ( r = 0; r < Info->uCount; r++ )
10.             {
11.                 if ( Info->aSH[r].Handle )
12.                 {
13.                     Result = Info->aSH[r].ObjectType;
14.                     p_fo = Info->aSH[r].pObject;
15.                                                         DbgPrint( " type = %d, Name = %ws\n ", p_fo->Type, p_fo->FileName.Buffer );
16.                 }
17.             }
18.         }

вижу далеко не все. В частности, есть SAM-файл, но нет $MFT и ему подобных.

Суть вопроса: где найти хэндлы на $MFT?
Спасибо.

 

А откуда уверенность, что они вообще должны быть?

 

Во-первых, ZwQuerySystemInformation не даёт информацию обо всех открытых хэндлах в системе. По моим наблюдениям, с помощью ZwQuerySystemInformation можно получить только 30-40% хэндлов ( на чистой системе ).
Но перечислить все хэндлы можно, однако для этого придётся вручную пройтись по HANDLE_TABLE всех процессов. Код в принципе, не сложный. Можешь посмотреть в WRK ( будет работать на XP - 7, на 2000й немного по-другому ).
Во-вторых, как заметил x64, хэндлов на $MFT не будет. Системе они попросту не нужны. Хэндлы - это юзермодные рудименты. Система использует FILE_OBJECT'ы и не создаёт для них дескрипторов.

 

x64
Понял насчет хендлов. А как найти FILE_OBJECT?

 

В общем случае - никак. Можно через анализ пула, но стабильно это работать не будет.

 

x64
Ух ты... Но система же должна как-то однозначно определять или я чего-то очень не понимаю?

 

Да блин, что тебе там система должна, она тебе всё уже простила, не парься. Служебные файлы типа \$Mft и так далее, они системой в штатном режиме не используются ибо просто не за чем, это внутренние структуры, которыми манипулирует драйвер файловой системы (ntfs.sys). Максимум, кто может использовать эти файлы, - это специализированные дисковые утилиты типа дефрагментаторов, менеджеров разделов и т.п. Т.е. я хочу сказать, что при нормальной работе системы, ни хендла, ни файлового объекта быть не может, а если и может, то только временно, на период работы какой-нибудь системной утилиты. И то, даже в этом случае, я сильно подозреваю, что в большинстве случаев эти файлы не открывают через обычный I/O, а тупо идёт работа с on-disk structures напрямую.

Если подытожить, то чтобы поймать файловый объект для \$Mft, думаю, тебе лучше всего будет написать файловый фильтр и в нём идентифицировать эти файлы. Как именно идентифицировать см. в исходниках FileMon-а, там это всё есть. Но опять же повторюсь, что тебе придётся ждать, пока придёт соответствующий запрос, ну в любом случае придётся ждать. Могу дать подсказку: возьми Process Monitor, включи "Advanced output", настрой фильтр и посмотри, когда система обращается к этим файлам (это лишь идея, не проверял). Но я бы на твоём месте подумал хорошенько, действительно ли тебе это надо.

 

x64
файлы $Mft и ей подобные открыты, для них созданы FILE_OBJECT'ы и они активно используются системой. они весят в кеше и отличны видны командой !filecache windbg, там можно получить адреса FILE_OBJECT.. а вот найти драйвером...

 

На самом деле есть документированный работающий способ: установить в gflags 0x4000, а затем вызывать ZwQuerySystemInformation c параметром SystemObjectInformation. Вообще-то это сделано для отладки, но использовать для своих целей, в принципе, никто не запрещает.

 

Если есть возможность в GlobalFlags поставить FLG_MAINTAIN_OBJECT_TYPELIST и перезагрузится, то все FILE_OBJECTS можно будет перечислить путём перебора соотв. списка в структуре, описывающей тип объектов ядра 'File'.

 

Не системой, не самим ядром, а драйвером файловой системы (ntfs.sys).

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

Ну я уже сказал, я вижу для тебя только два варианта:

1. Анализировать пул.
2. Написать файловый фильтр.

Советую начать с пула.

 

Спасибо, ребята. Отпишусь, как разгребу.

 

AntiFreeze
эм.. а что за glags?

 

Это тоже самое, о чём Cr4sh написал. Почитай msdn. С ддк идёт утилита - gflags.exe. Там выстави FLG_MAINTAIN_OBJECT_TYPELIST. Если утилиты нет, выставь руками - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager, GlobalFlag в 0x4000.

 

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

 

!gflag
Global Flags Dialog Box
Using the Global Flags Utility

Алсо, школоло такое школоло.

 

Можно и через пул, тем более что FILE_OBJECT'ы довольно просто идентифицируются, да и перезагрузка не требуется.
Кстати, файлы $MFT довольно легко найти и прочитать, открыв сырой том. Первые 16 записей в MFT зарезервированы именно для файлов метаданных NTFS.
Кстати, мне тоже не совсем понятно, зачем они могут понадобится автору. Может они и не нужны вовсе? Хотелось бы задачу прояснить..

 

Спасибо!
Штука в том, что винда рабоает с \$Mft через файловый кеш, потому сделанные на томе изменения не будут видны до перезагрузки.
Начал исследовать кеш с помощью windbg, понял, что все файлы в памяти описаны через FILE_OBJECT'ы и проще работать с ними, чем постоянно перезагружаться. А тут еще в висте на сырой том нельзя писать...

 

Ну это как бы не секрет, в MSDN оно документировано..

 

Насчет SAM файлов.
1) Хранятся в System Volume Infromation
2) Элементарно выцепляются с помощью Shadow Copy