информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[Win32] memory mapped files 03.02.05 13:43  
Автор: AS Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Как получить список всех отображаемых в память файлов процесса?
[Win32] Win32 это вряд ли 04.02.05 14:25  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Как получить список всех отображаемых в память файлов
> процесса?
Под NT можно сделать при помощи Native API. В частности ZwQuerySystemInformation() с InformationClass-ом 16 (SystemHandlesInformation)

Получить все хендлы и выбрать из них хендлы секций (Section) - winapi-шный file mapping представляется в ядре объектом-секцией
Ну это я знаю. Юзал по такой схеме: 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 гораздо мощнее софтайса
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach