Методология перехвата управления и определения адресов API-функций уже рассматривалась нами ранее в [1, 2, 3], поэтому здесь не описывается. Ограничимся тем, что напомним читателю основные моменты.

Перехват управления обычно осуществляется следующими путями:

n  переустановкой точки входа на тело X-кода;

n  внедрением в окрестности оригинальной точки входа команды перехода на X-код (естественно, перед передачей управления X-код должен удалить команду, восстановив исходное содержимое EP);

n  переустановкой произвольно взятой команды JMP/CALL на тело X-кода с последующей передачей управления по оригинальному адресу (этот прием не гарантирует, что X-коду вообще удастся заполучить управление, но зато обеспечивает ему феноменальную скрытность и максимальную защищенность от антивирусов);

n  модификацией одного или нескольких элементов таблицы импорта с целью подмены вызываемых функций своими собственными (этой технологией в основном пользуются stealth-вирусы, умело скрывающие свое присутствие в системе).

Определение адресов API-функций обычно осуществляется следующими путями:

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

n  Поиском LoadLibrary/GetProcAddress в таблице импорта файла-хозяина с последующим импортированием всех необходимых функций вручную (будьте готовы к тому, что и этих функций в таблице импорта также не окажется).

n  Прямым вызовом API-функций по их абсолютным адресам, жестко прописанным внутри X-кода (адреса функций KERNEL32.DLL/NTDLL.DLL меняются от одной версии системы к другой, а адреса USER32.DLL и всех остальных пользовательских библиотек непостоянны даже в рамках одной конкретной системы и варьируются в зависимости от Image Base остальных загружаемых библиотек, поэтому при всей популярности данного способа пользоваться им допустимо только в образовательно-познавательных целях).

n  Добавлением в таблицу импорта необходимых X-коду функций, которыми, как правило, являются LoadLibrary/GetProcAddress, с их помощью можно вытащить из недр системы и все остальные (достаточно надежный, хотя и слишком заметный способ).

n  Непосредственным поиском функций LoadLibrary/GetProcAddress в памяти, поскольку KERNEL32.DLL проецируется на адресное пространство всех процессов, а ее базовый адрес всегда выровнен на границу в 64 Кб, от нас всего лишь требуется просканировать первую половину адресного пространства процесса на предмет поиска сигнатуры «MZ». Если таковая найдена – убеждаемся в наличии сигнатуры «PE», расположенной по смещению e_lfanew от начала базового адреса загрузки. Если она действительно присутствует, анализируем DATA DIRECTORY и определяем адрес таблицы экспорта, в которой требуется найти LoadLibraryA и GetProcAddress. Если же хотя бы одно из этих условий не совпадает, уменьшаем указатель на 64 Кб и повторяем всю процедуру заново. Пара соображений в подмогу: прежде чем что-то читать из памяти, вызовите функцию IsBad ReadPtr, убедившись, что вы вправе это делать; помните, что Windows 2000 Advanced Server и Datacenter Server поддерживают загрузочный параметр /3GB, предоставляющий в распоряжение процесса 3 Гб оперативной памяти и сдвигающий границу сканирования на 1 Гб вверх; для упрощения отождествления KERNEL32.DLL можно использовать поле Name RVA, содержащееся в Export Directory Table и указывающее на имя динамической библиотеки, однако оно может быть и подложным (системный загрузчик его игнорирует).