Идентификация сегмента данных в Win32 / Win64
Я DLL загружен в памяти какого-то процесса. Я являюсь частью ряда библиотек DLL, которые присутствуют в этом процессе, некоторые загружаются динамически, а некоторые статически.
Мне осталось найти «драгоценный камень данных», чтобы найти его где-то в пространстве этого процесса, и мы предположим, что он находится в сегменте «данных» (т.е. не в каком-то странном самомодифицирующемся коде).
Мне нужно найти это. Мне нужно искать память, например, сделать memcmp (), но я не знаю, с чего начать поиск. Может быть, я могу перебрать принудительный поиск от 0 до нескольких гигабайт, но это вызовет исключения для чтения или только для выполнения, и, возможно, я смогу обработать эти исключения, чтобы не останавливать весь процесс. Но это звучит хитро.
Есть ли более разумный способ поиска? Вдобавок ко всему, я мог бы взглянуть на сегменты данных основного процесса, потому что есть способ как-то получить диапазоны адресов из заголовка NT, и я знаю процесс, в который я загружен. Тогда я мог бы Перечислите все загруженные библиотеки DLL и загляните внутрь их пробелов.
Кто-нибудь может предложить метод или даже сказать мне, если я на правильном пути?
Решение
Вы можете перечислить все загруженные модули в вашем процессе через EnumProcessModules с помощью GetCurrentProcess как дескриптор процесса. Тогда для каждого модуля вы можете позвонить GetModuleInformation который вернет вам MODULEINFO Структура, которая говорит вам точно, где в памяти загружен модуль и его размер. Или вы можете позвонить GetModuleFileNameEx
и изучите модуль на диске.
Обратите внимание, что чтение произвольной памяти в процессе, даже в том, в котором вы в данный момент работаете, может иметь проблемы. Например, если другой поток работает одновременно с вашим, он может повлиять на таблицу модулей, когда вы выполняете итерации по ней.
Другие решения
После некоторого тестирования процесс Win32 может использовать память, которую он получил несколькими способами, я думаю, что все заканчивается использованием VirtualAlloc и немного более высоким уровнем с HeapCreate et al. В конце концов, камень данных может находиться в сегментах «данных» модуля или в куче, даже в стеке — оба выделены с помощью VirtualAlloc. Вполне могут быть и другие способы выделения памяти.
Когда мы посмотрим на процесс Windows, у него будет загружено несколько библиотек DLL, многие из которых будут использовать свои собственные «кучи» и / или прямые вызовы VirtualAlloc. Другие будут делиться кучей основного процесса.
Я перечислил кучи процесса, используя GetProcessHeaps, а затем HeapWalk, концентрируясь только на PROCESS_HEAP_ENTRY_BUSY, и, к счастью, нашел то, что искал. Мой «подиум» ни в коем случае не является исчерпывающим поиском.
Я не нашел способа, и сейчас для меня академично связывать запись (блок) кучи с конкретным модулем. Точно так же, если бы я заглянул во все VirtualAllocs, я бы не знал, как отследить выделенные блоки до некоторого кода, работающего внутри модуля. Но этот шаг академический.