Карта Выделенной памяти в АП процесса...

В олли в 32 битных программах можно посмотреть адресное пространство, т.е. по каким адресам загружены модули (и их размер), по каким адресам стек, и тд.

Нужно составить такую "карту" памяти для другого процесса.
В 32 битах решается так:
OpenProcess в цикле от 0х00000000 до 0х7ffff000 с шагом 0х1000 вызывается VirtualQueryEx и таким образом если там что-то выделено, то можно узнать размер региона, аттрибуты и так далее.

А в 64 битах такая штука не прокатывает, т.к. даипазон там намного больше и уходит нереальное количество времени чтобы все просканить. В тоже время process Explorer прекрасно пишет по каким аресам какие модули загружены. Я понимаю, что он через драйвер работает, у меня нет подписанного 64 битного драйвера, и вообще на этот момент я нахожусь только в режиме пользователя.

Вопрос: как-то можно составить "карту" памяти для другого процесса, по каким адресам загружены библиотеки, где посто выделенная память и т.д.?

 

долбить VirtualQueryEx большими диапазонами

 

Не 'большими', а выровненными по границам страниц.

 

Ну границы страниц кратны 0х1000 ?
Я с таким шагом и сканирую.. Все равно получается много.

Кажется (пока не проверя) функция QueryWorkingSet делает то что нужно.

 

test555
Региона базу чекать нужно. Если вам модуль нужен, то тут механизма два - взять модуль из загрузчика, либо получить имя файла связанного с проекцией секции. Обычно решается через промежуточный функционал нэйтивный загрузочный, типо LdrFindEntryForAddress() или LdrEnumerateLoadedModules() etc. Задача поставлена не чётко.

 

test555, что тебе мешает чекать с шагом 1МБ или 128 МБ? в случае если наткнёшься на непустой диапазон, то сканить с более малым шагом

 

Есть вероятность что с таким шагом я пропущу что-то.

Malfoy

Мне нужно знать, какая память и по какому адресу выделена у соседнего процесса. Туда войдет образ самого ехе, библиотеки, стек, та память которая когда-либо была выделена через VirtualAlloc, прочие Mapping... и тд..


Ну если открыть Олли - Мемори Мэп то для ОТЛАЖИВАЕМОГО процесса видим где какая память и для чего.
Мне нужен упрощенный аналог, который бы давал адреса памяти, размеры и аттрибуты, причем соседнего процесса и без "отладки".



А вообще проблема решена через QueryWorkingSet.

 

самому интересно стало. как будет время запилю прогу сканящую АП по такому методу и сюда выложу

 

test555
Ну а в чём ваша проблема, не можите вызвать сервис ?

rpy3uH
Зачем оно нужно. MemoryBasicInformation возвратит инфу также и для не аллоцированной памяти, без разницы её состояние - можно получить инфу про любой регион памяти. Делаем примитивный цикл:

Код (Text):

1. !Pe
2.     Ip = SYSTEM_BASIC_INFORMATION.MinimumUserModeAddress
3.     Do
4.         Mm = MEMORY_BASIC_INFORMATION(Ip)
5.         if (Mm.Type = MEM_IMAGE) & (Mm.State = MEM_COMMIT) & (Mm.AllocationBase <> Pe)
6.             Pe = Mm.AllocationBase
7.             NtFileName$ = MemoryMappedFilenameInformation(Mm.BaseAddress)
8.             DbgPrint(NtFileName$)
9.         fi
10.         Ip = Mm.BaseAddress + Mm.RegionSize
11.     Loop Ip < SYSTEM_BASIC_INFORMATION.MaximumUserModeAddress
12.     End

А для каждой страницы дёргать сискол не годно.

 

ТС, говорил про то что сканить АП 64-битного процесса долго. моё предложение заключалось в том что сканить большими регионами, а потом при детекте сканить более малыми.

в принципе уже по барабану, так как проблема решена

 

а мое предложение - сканить количеством потоков == число голов * число процов

 

это в 10 раз тяжелее, чем даже мой алгоритм

 

rpy3uH
Вы оба не правы.

 

А почему не с учетом гранулярности аллоцирования регионов (65536) ?

 

Malfoy
озарите Знанием?

 

sn0w
#9. Проще - ознакомтесь с VAD. Затем вы должны изучить сервисы, NtProtectVM etc. После этого будет профит и вы поймёте как нужно енумить регионы, учитывая экспорт ядра.