Дамп драйверов

На основе статьи Ms-Rem
http://www.wasm.ru/article.php?article=dumping
написал работающий дампер. Его недостаток - невозможность дампа даже простых руткитов вроде патчащих KeServiceDescriptorTable, т.к для получения базы и размера памяти драйвера используется ZwQuerySystemInformation.

Попытки использовать DKOM для перечисления драйверов и получения базы и размера образа пока ни к чему не приводят. Пока отталкивался от структуры MODULE_ENTRY из DRIVER_OBJECT->DriverSection

typedef struct _MODULE_ENTRY {
LIST_ENTRY module_list_entry;
DWORD unknown1[4];
DWORD base;
DWORD driver_start;
DWORD unknown2;
UNICODE_STRING driver_Path;
UNICODE_STRING driver_Name;
//...
} MODULE_ENTRY, *PMODULE_ENTRY;

Однако значение поля base отличается от значения базы моего драйвера полученной через ZwQuerySystemInformation. К тому же нет поля для размера (хотя его можно попробовать получить из PE заголовка).

Вобщем возникло 2 вопроса
1) Как организовать получение базы и размера через DKOM
2) Как организовать получение базы и размера минуя DKOM и ZwQuerySystemInformation, т.к. скрыть от них драйвера относительно просто.

 

Проходи руками PsLoadedModuleList

 

Та попытка использовать DKOM, что я описал в первом посте - это и есть использование PsLoadedModuleList

 

Ээ в DRIVER_OBJECT кажется оно есть

 

ну руткит может просто выделять пул, копировать себя туда, настраивать релоки, и запускать системный поток который будет выполнять DriverEntry, а сам возваращать ошибку, в итоге система сама почистит все его следы) чтоб такое сдампить нужно разве что всю память сканить на предмет наличия сигнатур пе-заголовка, ито не факт чо руткит не забьёт его мусором

 

Cr4sh

сложные руткиты дампить вряд ли он соберется +) в любом случае против лома нет приема

 

Хм, действительно... а слона то я и не приметил. Чтож буду тестить.

Правда в любом случае видимо придется искать по памяти MZ/PE заголовки, как предложил Cr4sh.

 

Rodin
Скажу однозначно. это мёртвая тема. ну как тыт сможешь определить размер и положение модуля в памяти ? если загаловок модуля потёрт, а все ссылки удалены. Единственное что можешь это анализировать содержимое памяти, осмысленные инструкции там или мусор. Но это бред. и никому ненужно.

 

руткит с тридом это огромное палево господа Существуют методы, позволяющие 100% определить место выполнения трида (не через старт адрес ) и соотвественно дампануть его. Впрочем это тоже можно обойти, но придется погемороиться.

 

pushick
ну да ну да. Если кодер не ёжик, то тред он разместит подальше от руткита, а то и вообще внутри левого работающего драйвера. Способы коммуникации можно придумать такие, что искать как это дело координируется можно долго. Да и почему именно весь руткит должен бть алоцирован в одном непрерывном куске памяти? Почему например не использовать несколько драйверов? или вообще разбросать по памяти отдельные процедуры. Так что это бред - дамп руткитов.

 

k3internal
Как Unreal.B между прочим Хер сдампите и хер найдете

 

ну ... попробую. сливаю всю физическую память , по пдб расфасовываю слитое по страницам , и на СРАВНЕНИЕ со слитым уже заблаговременно слепком памяти системы. прячь ... посмотрим.
зы: неужели думаешь что для дампа нужно ваще юзать сервисы нативы ?

 

Какие сервисы, какие нативы? Ты вообще о чем? Хер ты что найдешь по своей описанной схеме, тешь себя дальше

 

Он в L2 кеше?

P.S. ))

 

млин .. нт - по идее - проще пареной репы. есть куча таблиц ссылок (описателей) на структуры , которые описывают соотв. "объекты" + диспечеры по управлению сими объектами через сии структуры. ... ну и ио управляющий (как пробойник ринга) ... усе. что там можно еще спрятать ? то что не по ссылкам - мусор беззащитный.
знать "карту" сборки системы. описать усе ручками , дабы не перехватили и не сунули лажу ...
даж "зараженные" на "горячую" - дрова - при сравнении вылезут. но ... как ты собрался сие делать ... писать в страницы с дровами , помеченные как код - привилегия системы , однако. иначе бсод сей момент.
зы: хотя идея заражать дрова понравилась... чесно. но оставь ее до следующей перезагрузки.

 

EP_X0FF

Ну, теперь унриал.Б не одинок=))

 

Geen

ШАПКА, ТЫ БРЕДИШЬ!!! (цы Красная плесень).

ты про DKOM слышал ? чо ты там собрался описывать и помечать ? Единственное что для всего этого понадобится это выделенная память, которая стессно описана шо она выделена. А вот кто и сколько и где её выделил это для всех дров едино. То есть если ты загрузился , выделил память, затем выгрузился и забыл её освободить, то память эта вместе с драйвером не исчезнет. Так и будет занята до явного освобождения. Это я к чему. Да вот к чему. Современные системы имеют озу на борту до чёрта. Соответственно страницы на ядро мапяца по 4 метра. А в 4х метрах дров может быть дохрена. И у многих из них есть секция .INIT, которая после загрузки драйвера больше не используется, но место занимает. так вот в этих сециях что мешает тебе разместить свой код ? тока это может быть палево, антируткиты имеют привычку также и эту секцию читать и с дискм сравивать, почём зря. Но подобные техники один хрен юзались и буду юзаца. Так что сам видишь, здесь к примеру даже ничево и выделять не надо, система сама позаботилась, и хрен нас оттуда хто выгонит. А вот верхнее своё высказывание перечитай и падумай чо ты ляпнул=))

 

есть такая програмка RkUnhooker , посмотри плиз - есть на сайте ... имеет свойством дампы дров скидывать. глянь что от секции инит остается , если она за 4 кб (это чуть меньше чем 4 метра) вылазит. а все уже описано и помечено само ... если читать внимательно. выделенная память по запросу дровины конечно останется , если в унлоаде о сем не позаботится ... но ты попробуй там разместить код и передай ему управление ... если получится - то снимаю шляпу.

 

Geen
А почему собсно нельзя это сделать?!

 

Снимай. Получилось, примерно год назад у нас Дамп в рку организован очень примитивно и тупо, не тебе мне об этом рассказывать. Но k3internal прав - в р0 возможно все.