BugTraq.Ru: форум / programming / [Win32] Win32 это вряд ли

информационная безопасность
без паники и всерьез

подробно о проекте

Spanning Tree Protocol: недокументированное применение

Анализ криптографических сетевых...

Модель надежности двухузлового...

Специальные марковские модели надежности...

Ядро Linux избавляется от российских...

20 лет Ubuntu

Tailscale окончательно забанила...

bugtraq.ru / форум / programming

Имя

Пароль

если вы видите этот текст, отключите в настройках форума использование JavaScript


ФОРУМ


регистрация

Легенда:

новое сообщение

закрытая нитка

новое сообщение

в закрытой нитке

старое сообщение

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

[Win32] Win32 это вряд ли 04.02.05 14:25 Число просмотров: 1744
Автор: amirul <Serge> Статус: The Elderman

<"чистая" ссылка>

> Как получить список всех отображаемых в память файлов
> процесса?
Под NT можно сделать при помощи Native API. В частности ZwQuerySystemInformation() с InformationClass-ом 16 (SystemHandlesInformation)

Получить все хендлы и выбрать из них хендлы секций (Section) - winapi-шный file mapping представляется в ядре объектом-секцией

[Win32] memory mapped files 03.02.05 13:43
Автор: AS Статус: Незарегистрированный пользователь

<"чистая" ссылка>

Как получить список всех отображаемых в память файлов процесса?

[Win32] Win32 это вряд ли 04.02.05 14:25
Автор: amirul <Serge> Статус: The Elderman

<"чистая" ссылка>

Ну это я знаю. Юзал по такой схеме: NtQuerySystemInformation... 04.02.05 16:31
Автор: AS Статус: Незарегистрированный пользователь

<"чистая" ссылка>

Ну это я знаю. Юзал по такой схеме: NtQuerySystemInformation ... DuplicateHandle ... NtQueryObject
Но вот как путь к файлу получить? \BaseNamedObjects\*** не устраивает.

Все равно, спасибо

Эх. Как из нулевого кольца вытащить из секции файл я знаю 04.02.05 16:59
Автор: amirul <Serge> Статус: The Elderman

<"чистая" ссылка>

> Все равно, спасибо
А вот в 3-м кольце это скорее всего нереально. Если это ОЧЕНЬ необходимо, то возможно тебе придется писать сопутствующий драйвер, который будет заниматься грязной работой

Да, наверное, драйвер... 04.02.05 17:11
Автор: AS Статус: Незарегистрированный пользователь
Отредактировано 04.02.05 17:17 Количество правок: 1

<"чистая" ссылка>

:( ладно, шас пошарюсь в исходниках ntoskrnl, посморю формат Section, может все просто - хэндл файла
выдрать и ObQueryNameString
хотя какой в задницу хэндл... он тогда должен был быть в списке, возвращенном NtQerySystemInformation

Ну тогда все просто [upd] 04.02.05 17:35
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 04.02.05 17:40 Количество правок: 2

<"чистая" ссылка>

> :( ладно, шас пошарюсь в исходниках ntoskrnl, посморю
> формат Section, может все просто - хэндл файла
> выдрать и ObQueryNameString
> хотя какой в задницу хэндл... он тогда должен был быть в
> списке, возвращенном NtQerySystemInformation

lkd> dt nt!_section_object
nt!_SECTION_OBJECT
   +0x000 StartingVa       : Ptr32 Void
   +0x004 EndingVa         : Ptr32 Void
   +0x008 Parent           : Ptr32 Void
   +0x00c LeftChild        : Ptr32 Void
   +0x010 RightChild       : Ptr32 Void
   +0x014 Segment          : Ptr32 _SEGMENT_OBJECT
lkd> dt nt!_segment
nt!_SEGMENT
   +0x000 ControlArea      : Ptr32 _CONTROL_AREA
   +0x004 TotalNumberOfPtes : Uint4B
   +0x008 NonExtendedPtes  : Uint4B
   +0x00c WritableUserReferences : Uint4B
   +0x010 SizeOfSegment    : Uint8B
   +0x018 SegmentPteTemplate : _MMPTE
   +0x01c NumberOfCommittedPages : Uint4B
   +0x020 ExtendInfo       : Ptr32 _MMEXTEND_INFO
   +0x024 SystemImageBase  : Ptr32 Void
   +0x028 BasedAddress     : Ptr32 Void
   +0x02c u1               : __unnamed
   +0x030 u2               : __unnamed
   +0x034 PrototypePte     : Ptr32 _MMPTE
   +0x038 ThePtes          : [1] _MMPTE
lkd> dt nt!_control_area
nt!_CONTROL_AREA
   +0x000 Segment          : Ptr32 _SEGMENT
   +0x004 DereferenceList  : _LIST_ENTRY
   +0x00c NumberOfSectionReferences : Uint4B
   +0x010 NumberOfPfnReferences : Uint4B
   +0x014 NumberOfMappedViews : Uint4B
   +0x018 NumberOfSubsections : Uint2B
   +0x01a FlushInProgressCount : Uint2B
   +0x01c NumberOfUserReferences : Uint4B
   +0x020 u                : __unnamed
   +0x024 FilePointer      : Ptr32 _FILE_OBJECT
   +0x028 WaitingForDeletion : Ptr32 _EVENT_COUNTER
   +0x02c ModifiedWriteCount : Uint2B
   +0x02e NumberOfSystemCacheViews : Uint2B

---

Пусть тебя не смущает, что в _SECTION_OBJECT-е указан тип _SEGMENT_OBJECT, а я указал _SEGMENT. Не знаю почему но там валяется именно _SEGMENT (проверено).

Просто на всякий случай приведу

nt!_SEGMENT_OBJECT
   +0x000 BaseAddress      : Ptr32 Void
   +0x004 TotalNumberOfPtes : Uint4B
   +0x008 SizeOfSegment    : _LARGE_INTEGER
   +0x010 NonExtendedPtes  : Uint4B
   +0x014 ImageCommitment  : Uint4B
   +0x018 ControlArea      : Ptr32 _CONTROL_AREA
   +0x01c Subsection       : Ptr32 _SUBSECTION
   +0x020 LargeControlArea : Ptr32 _LARGE_CONTROL_AREA
   +0x024 MmSectionFlags   : Ptr32 _MMSECTION_FLAGS
   +0x028 MmSubSectionFlags : Ptr32 _MMSUBSECTION_FLAGS
lkd> dt nt!_large_control_area
nt!_LARGE_CONTROL_AREA
   +0x000 Segment          : Ptr32 _SEGMENT
   +0x004 DereferenceList  : _LIST_ENTRY
   +0x00c NumberOfSectionReferences : Uint4B
   +0x010 NumberOfPfnReferences : Uint4B
   +0x014 NumberOfMappedViews : Uint4B
   +0x018 NumberOfSubsections : Uint2B
   +0x01a FlushInProgressCount : Uint2B
   +0x01c NumberOfUserReferences : Uint4B
   +0x020 u                : __unnamed
   +0x024 FilePointer      : Ptr32 _FILE_OBJECT
   +0x028 WaitingForDeletion : Ptr32 _EVENT_COUNTER
   +0x02c ModifiedWriteCount : Uint2B
   +0x02e NumberOfSystemCacheViews : Uint2B
   +0x030 StartingFrame    : Uint4B
   +0x034 UserGlobalList   : _LIST_ENTRY
   +0x03c SessionId        : Uint4B

---

Как видишь разница в положении ControlArea. При этом проверено, что из _SEGMENT-а она читается правильно.

Ну а получить имя из _SECTION_OBJECT-а можно при помощи функции ObGetObjectName()

-------------------------------------

Да кстати, получить _FILE_OBJECT из HANDLE-а можно при помощи ObReferenceObjectByHandle
И еще. Все структуры даны для XP SP0. На других виндах скорее всего не поменялись - но это нуждается в проверке

thx еще раз. 04.02.05 18:11
Автор: AS Статус: Незарегистрированный пользователь
Отредактировано 04.02.05 18:17 Количество правок: 1

<"чистая" ссылка>

thx еще раз.
> Ну а получить имя из _SECTION_OBJECT-а можно при помощи
> функции ObGetObjectName()
А будет ли действительно возвращен путь к файлу для _FILE_OBJECT?
> Да кстати, получить _FILE_OBJECT из HANDLE-а можно при
> помощи ObReferenceObjectByHandle
Знаю, но если бы был хэндл, то и проблем бы не было :)

ЗЫ
Это LiveKd? Hи разу не юзал, но по листингу впечатляет. Лучше, чем SoftIce?

Будет. Только в виде... 04.02.05 20:04
Автор: amirul <Serge> Статус: The Elderman

<"чистая" ссылка>

> thx еще раз.
> > Ну а получить имя из _SECTION_OBJECT-а можно при
> помощи
> > функции ObGetObjectName()
> А будет ли действительно возвращен путь к файлу для
> _FILE_OBJECT?
Будет. Только в виде \Device\HarddiskVolume0\Path\To\File.ext

> > Да кстати, получить _FILE_OBJECT из HANDLE-а можно при
> > помощи ObReferenceObjectByHandle
> Знаю, но если бы был хэндл, то и проблем бы не было :)
Ну дык, ObOpenObjectByPointer и будет тебе хендл :-)
Только на фига

> ЗЫ
> Это LiveKd? Hи разу не юзал, но по листингу впечатляет.
> Лучше, чем SoftIce?
Ага. Только в последних WinDbg/KD этот самый LiveKD уже не нужен - они и сами умеют коннектиться к локальной сессии (правда с кучей ограничений). А структуры - из символов винды, в софтайс их тоже можно проимпортить (SymbolRetriever-ом). И отвечая на вторую часть вопроса, да WinDbg гораздо мощнее софтайса

Page build time: 0 s

Design: Vadim Derkach