В поисках самого себя
Снятие дампа начинается с определения региона памяти, принадлежащего исполняемому файлу (или динамической библиотеки). Приемы, описанные выше, всецело опираются на PE-заголовок и таблицу секций, используемую операционной системой практически только на стадии загрузки файла. В частности, нас интересуют поля ImageBase (адрес базовой загрузки), SizeOfImage (размер образа) и содержимое таблицы секций. Протекторы любят затирать эти поля после завершения распаковки или подсовывать заведомо некорректные значения. Дамперы первого поколения от этого сходили с ума, но PE-TOOLS в большинстве случаев восстанавливает недостающую информацию самостоятельно, но иногда он все-таки не срабатывает. И что тогда?
Самое простое — исследовать карту памяти подопытного процесса, возвращаемую API-функциями VirtualQuery/VirtualQueryEx. Регионы, помеченные как MEM_IMAGE принадлежат исполняемому файлу или одной из используемых им DLL (в PE-TOOLS за построение карты отвечает команда "dump region".
Рисунок 5 просмотр карты памяти в PE-TOOLS
Активные защиты могут перехватывать эти функции, подсовывая подложные данные и тогда приходится спускаться на один уровень вглубь, обращаясь к функции NtQueryVirtualMemory, которая, как и следует из ее названия, существует только в NT-подобных операционных системах и экспортируется библиотекой NTDLL.DLL, но в некоторых случаях перехватывается и она, вынуждая нас обращаться к недокументированной функции NtQuerySystemInformation. Долгое время она оставалась совершенно недокументированной и многие протекторы о существовании подобной лазейки даже и не подозревали. Теперь же ее описание доступно на MSDN http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/ntquerysysteminformation.asp, c грозным предупреждением, что поведение функции может измениться в любой новой версии, а потому в долгосрочных продуктах на нее лучше не закладываться.
В самом крайнем случае (когда перехвачена и NtQuerySystemInformation) приходится прибегать к ручному разбору структур данных, относящихся к памяти процесса (soft-ice именно так и поступает), однако, гораздо проще и надежнее просто скопировать кусок адресного пространства. Если образ не был перемещен, базовый адрес загрузки тоже самый, что и в PE-заголовке exe файла. При работе с перемещенным образом, базовый адрес приходится определять вручную путем поиска сигнатур PE и MZ, двигаясь от OEP вверх (т. е. в сторону младших адресов). К нашему счастью, полностью затереть PE-заголовок защита не может, поскольку тогда перестанут работать некоторые API-функции, взаимодействующие с ресурсами и т. д.
Если ни одним из способов определить границы образа не удается, приходится дампить фрагменты адресного пространства, загружая их в IDA Pro как двоичный файл, естественно, с сохранением начального адреса фрагмента. Для анализа работы защитного механизма этого в большинстве случаев оказывается вполне достаточно, тем более, что IDA Pro позволяет подгружать недостающие куски "налету".
