Мне необходимо сравнить два списка загруженных в процесс модулей. Первый список беру из PEB процесса, а второр из списка VAD'ов процесса, как описано здесь.
Проблема заключается в том, что на x64 платформах для 32-битных процессов способ через VAD показывает мне модули, которых нету в списке PEB.
Например (жирным показаны модули, которых в PEB нет),
Полные имена модулей при получении их через VAD беру из PFILE_OBJECT + IoQueryFileDosDeviceName.
Также учитываю, что у 32-битных процессов под x64 нужно читать 2 PEB'а — 32 битный и 64 битный...
Если кто подскажет, как бы обойти данную проблему, буду крайне благодарен.
P>Мне необходимо сравнить два списка загруженных в процесс модулей. Первый список беру из PEB процесса, а второр из списка VAD'ов процесса, как описано здесь.
Ой какой хардкор. Не проще ли тихо-мирно из юзермода получить тот же эффект через VirtualQueryEx + GetMappedFileName ? Хотя наверное если это — антималвар — то из кернела надежнее. Малоли что малвар похучил.
P>Проблема заключается в том, что на x64 платформах для 32-битных процессов способ через VAD показывает мне модули, которых нету в списке PEB. P>Например (жирным показаны модули, которых в PEB нет),
Во-первых у 32хбитных процессов два PEB'а (32хбитный и 64хбитный), в которых два различных списка модулей. Правда 64хбитный обычно весьма куцый.
Во-первых не обязательно будет совпадение путей и/или наличия модуля в ПЕБе и реального пути откуда его загрузили. Проблемы могут доставить виртуализация — как виндовая так и сторонняя. Да и в принципе никто не мешает 'вручную' подмапить файл через CreateFileMapping(..SEC_IMAGE..) + MapViewOfFile. В PEBе его не появится, а в ядре вы регион не отличите от загруженной длл-ки.
В-третьих конкретно по syswow64\uxtheme.dll — я ее вижу во всех процессах на своей семерке. Возможно у вас баг в парсинге PEB-ldr списка.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Ой какой хардкор. Не проще ли тихо-мирно из юзермода получить тот же эффект через VirtualQueryEx + GetMappedFileName ? Хотя наверное если это — антималвар — то из кернела надежнее. Малоли что малвар похучил.
Да, пример, на котором отлаживаю все, хучит ZwOpenProcess, поэтому сразу решил в ядре.
O>Во-первых у 32хбитных процессов два PEB'а (32хбитный и 64хбитный), в которых два различных списка модулей. Правда 64хбитный обычно весьма куцый.
Да, это учитываю.
O>Во-первых не обязательно будет совпадение путей и/или наличия модуля в ПЕБе и реального пути откуда его загрузили. Проблемы могут доставить виртуализация — как виндовая так и сторонняя. Да и в принципе никто не мешает 'вручную' подмапить файл через CreateFileMapping(..SEC_IMAGE..) + MapViewOfFile. В PEBе его не появится, а в ядре вы регион не отличите от загруженной длл-ки.
Спасиб.
А имея на руках FILE_OBJECT тоже никак не отличить?
O>В-третьих конкретно по syswow64\uxtheme.dll — я ее вижу во всех процессах на своей семерке. Возможно у вас баг в парсинге PEB-ldr списка.
O>>Во-первых не обязательно будет совпадение путей и/или наличия модуля в ПЕБе и реального пути откуда его загрузили. Проблемы могут доставить виртуализация — как виндовая так и сторонняя. Да и в принципе никто не мешает 'вручную' подмапить файл через CreateFileMapping(..SEC_IMAGE..) + MapViewOfFile. В PEBе его не появится, а в ядре вы регион не отличите от загруженной длл-ки. P>Спасиб. P>А имея на руках FILE_OBJECT тоже никак не отличить?
Врядли. LdrLoadDll — она ведь по сути делает то же самое + добавляет промапленный адрес в ldr-list. Но ничто не мешает юзермодному коду промапить и не добавлять в ldr.
O>>В-третьих конкретно по syswow64\uxtheme.dll — я ее вижу во всех процессах на своей семерке. Возможно у вас баг в парсинге PEB-ldr списка.
В PEB'е вроде несколько списков. В InitOrder'е могут запросто отсутствовать некоторые длл-ки. Думаю самое правильное — лопатить MemoryOrder.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>В-третьих конкретно по syswow64\uxtheme.dll — я ее вижу во всех процессах на своей семерке. Возможно у вас баг в парсинге PEB-ldr списка. O>В PEB'е вроде несколько списков. В InitOrder'е могут запросто отсутствовать некоторые длл-ки. Думаю самое правильное — лопатить MemoryOrder.
В MemoryOrder вроде короткие имена модулей. Хотелось бы полный путь. Но раз это более надежный способ, то буду лопатить MemoryOrder.
Спасиб еще раз.
O>>>>В-третьих конкретно по syswow64\uxtheme.dll — я ее вижу во всех процессах на своей семерке. Возможно у вас баг в парсинге PEB-ldr списка. O>>В PEB'е вроде несколько списков. В InitOrder'е могут запросто отсутствовать некоторые длл-ки. Думаю самое правильное — лопатить MemoryOrder. P>В MemoryOrder вроде короткие имена модулей. Хотелось бы полный путь. Но раз это более надежный способ, то буду лопатить MemoryOrder. P>Спасиб еще раз.
MemoryOrder и InitOrder строятся на одних и тех же LDR_DATA_TABLE_ENTRY'ов. Так что быть такого не может чтоб для одной и той же длл в одном путь коротким, а в другом — длинный.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>MemoryOrder и InitOrder строятся на одних и тех же LDR_DATA_TABLE_ENTRY'ов. Так что быть такого не может чтоб для одной и той же длл в одном путь коротким, а в другом — длинный.
Я как раз через MemoryOrder делал... Ща попробовал указать InitOrder и 32хбитный PEB у меня получился такой (ОС VistaSP2 x64):
O>>MemoryOrder и InitOrder строятся на одних и тех же LDR_DATA_TABLE_ENTRY'ов. Так что быть такого не может чтоб для одной и той же длл в одном путь коротким, а в другом — длинный. P>Я как раз через MemoryOrder делал... Ща попробовал указать InitOrder и 32хбитный PEB у меня получился такой (ОС VistaSP2 x64):
P>
(c)
Смещение на 2*sizeof(PVOID) намекает на то что вы забыли правильно подкорректировать смещение между LIST_ENTRY и соответствующим LDR_DATA_TABLE_ENTRY, меняя код с InInitializationOrderLinks на InMemoryOrderLinks. Либо проблемы с выравниванием.
Как много веселых ребят, и все делают велосипед...