Получение "имени" модуля.

А еще можно кижки читать

 

эхехе... ну Riply надеюсь в курсах, за методы попаданию в r0 (и как это делаеться скриптами), так что могу добавить, разве что приём (грязного хака) по нахождению... ну как их там.. ынтимных участков венды штоле...

Код (Text):

1. var
2.     Proc :integer;
3.     code :int64;
4.  
5. procedure R0(Drv:PDRV);
6. begin
7. //
8.     Proc := integer(@Drv.NtCreateFile);
9.     if word(PDWORD(Proc)^) = $25FF // IAT опкод JMP [xxx] ?
10.     then // вычисляем адрес xxx и берем из нее значение
11.        begin
12.           Proc := PDWORD(PDWORD(Proc+2)^)^;
13.           code := pInt64 (Proc)^; // либо наоборот, не забывая про WP в CR0
14.      end;
15. end;

что еще... а! можно выгрести дамп имиджа дрова и посмотреть какие там в нем буковки.

а то малоли - имя модуля гдето там в нем (если не потер канешна).

P.S
кстати еще проверить бы, не перехватил ли он int 2E с sysenter'ом.
P.P.S
хотя... какой r0, сдаеться в нем VT заюзано по полной програме...

(тут даже к телепату не ходи, ну..)^_^

 

Это уже сделано. Анализом лога procmon подозреваемый модуль нашелся. И в дампе дровины нашлась ссылка на pdb-файл с именем того же модуля. Только вот... это atapi.sys. И он (на диске, не дамп) совпадает с тем что в дистрибутиве, ну до байтика.
Вот может Рипли опровергнет. Ну или подтвердит. Если это и правда атапи, то как искать кто его патчит в памяти я вообще не представляю. Такие дела.

 

да уж.. чтож, ладно сенькс всем.. за навеяные мысли, данной темой...
и за нечто, даже большее чем "зло в квадрате" (по выражению одного классика), которое сотворилось... в борьбе с синим экраном.. http://pastebin.com/f754e4949
(а то давно хотел подобный дампер модулей а разгребать руткитовые заморочки на сях и асмах было таааак влом.....)

 

bugaga
NtQuerySystemInformation бесполезен как сервис и как функция для обнаружения руткитов, даже если он не захвачен руткитом, то элементарное удаление записи из базы лоадера и ничего обнаружено не будет.

 

Вроде научилась бегать по HANDLE_TABLE
Т.е. теперь у нас на руках BaseAddress, ImageSize и, примерно,
полторы тысячи HANDLE_TABLE_ENTRY-ев
Как из них выбрать нужный или хотябы отфильтровать лишние ?
Какой тип объекта можно ожидать у нашего пациента ?

 

Поизучала SYSTEM-ый HANDLE_TABLE,
посмотрела "имена" всех Handle`ов, у которых они есть.
Там, конечно, много интересного, но нужного нам нет.
Можно считать что, там нет драйверов (только девайсы).
(Разумеется, если я нигде не допустила ошибки).
Значит надо парсить какую-то другую таблицу или какой нибудь LIST_ENTRY.
Где могут сидеть "загруженные модули" ?
Ведь живут же они где-то, а не бомжуют

 

PsLoadedModuleList.

 

Clerk, угу. Спасибо - попробую

 

Riply
Вы уже пробовали это юзая SystemModuleInformation

 

Да, но есть шанс, что SystemModuleInformation перехвачена,
а я попробую побегать по списку "вручную"
Чем черт не шутит, может и даст что-то.
Тем более, что других идей, пока нет

 

Научилась получать PsLoadedModuleList и бегать по нему.
(Правда, и то и другое без "блокировки", но пока ладно)
Теперь я нахожу нашего подопечного.
Точнее структуру LDR_MODULE_INFO, ему соответствующую.
(Имена в ней, как и ожидалось, затерты пробелами)
Как имея ее на руках (эту стр-ру), получить сам объект ?
Т.е. если это драйвер, то как получить PDRIVER_OBJECT ?
Вообщем нужно вытащить как можно больше информации.
Например имя ключа реестра ему соответствующее или имя файла из которого он загружался.
(Если таковые имеются конечно)

 

Riply

Нет такой структуры.

 

Sorry
Возможно, название стащила у ReactOS-цев. Не помню.
Выглядит она так:

Код (Text):

1. type
2.   PLDR_MODULE_INFO = ^_LDR_MODULE_INFO;
3.   _LDR_MODULE_INFO = packed record
4.     BaseAddress      : PVOID;
5.     EntryPoint       : PVOID;
6.     SizeOfImage      : ULONG;
7.     FullDllName      : UNICODE_STRING;
8.     BaseDllName      : UNICODE_STRING;
9.     Flags            : ULONG;
10.     LoadCount        : USHORT;
11.     TlsIndex         : USHORT;
12.     HashLinks        : _LIST_ENTRY;  //???
13.     SectionPointer   : PVOID;
14.     CheckSum         : ULONG;
15.     TimeDateStamp    : ULONG;
16.     LoadedImports    : PVOID;
17.     EntryPointActivationContext : PVOID;
18.   end;

При пробежке по PsLoadedModuleList, вроде все имена возвращаются в ней корректно.

 

Riply
Оо так вы девочка
Главное чтобы не блондинка..
Вам нужно виндбг поставить и отлаживать загрузку виндоз, там не сложно.

 

И не говори. Вот ведь угораздило

У меня цель не столь поймать зверка, сколь получить знания в процессе ловли.
Поэтому и хотелось бы все сделать (найти его) собственнолапно

 

Вроде, научилась получать из "элемента" PsLoadedModuleList соответствующий ему PDRIVER_OBJECT.
( Правда способ мне не нравится, но для начала (и для начинающей) сойдет )

Теперь встал следующий вопрос: как, имея на руках PDRIVER_OBJECT,
получить максимум информации о нем ?
Попробовала посмотреть что там можно вытащить, но кроме pDriver.DriverExtension.ServiceKeyName
ничего не нашла

А если в нем (в структуре) не "зашита" нужная нам информация, то как можно над ним
поиздеваться, чтобы он сам нам все расказал (как на допросе третьей степени) ?

 

Рипли, а ты уже с чужими расправилась?

 

Никакого отношения к лейтенанту с именем (Ripley), созвучным моему нику,
не имею и в родственных связях не состою

 

Riply
Мне нравятся умные девочки, они редкость ))