В первой части статьи мы рассмотрели общие принципы API перехвата, и освоили метод перехвата заменой начальных байт функции. Для перехвата в другом процессе мы использовали метод внедрения DLL. Данный метод прост, но не всегда эффективен и не обеспечивает высокой скрытности внедрения.

В этой статье мы рассмотрим более эффективные способы перехвата, а в особенности приёмы написания внедряемого кода. Также в конце статьи я рассмотрю альтернативные методы внедрения кода в чужой процесс.

Все приемы написания внедряемого кода описанные здесь предназначены для использования в Borland Delphi (6, 7, 2005), но с минимальными изменениями могут быть использованы и в среде Microsoft Visual C++. В среде Borland C++ Builder некоторые приведенные приёмы неосуществимы (в связи с особенностями генерации кода компилятором).

Требования к внедряемому коду:

1) Базонезависимость (адрес загрузки кода в чужой процесс неизвестен заранее).
2) Независимость от RTL (Run Time Library).
3) Использование только библиотек загруженных в АП (адресное пространство) целевого процесса.
4) Наличие в внедряемом коде всех необходимых для него данных.

Внедряемый код не должен содержать переходов по абсолютным адресам, а также абсолютных ссылок на данные, импортировать функции из DLL можно динамически, через LoadLibrary и GetProcAddress.

Адреса функций из ntdll.dll и kernel32.dll можно передавать в внедряемый код из исходного процесса, т.к. эти библиотеки всегда загружаются по одинаковым адресам во всех процессах. Другие системные библиотеки (user32.dll, shell32.dll) тоже часто загружаются по одинаковым адресам, но так происходит только в том случае, если исходный и целевой процессы импортируют эти библиотеки статически, в случае же динамического импорта в следствии коллизии модулей они могут быть загружены по разным адресам. Все остальные библиотеки обычно загружаются по разным адресам в разных процессах даже при использовании статического импорта. При написании внедряемого кода следует учесть, что единственная DLL которая обязательно должна присутствовать в адресном пространстве любого процесса - это ntdll.dll, эта DLL загружается даже при отсутствии импорта в исполнимом файле, и представляет собой слой Native API, переходники к функциям ядра Windows.
Компилятор Delphi обычно генерирует в процедурах короткие переходы (JMP SHORT), но при большом размере процедуры могут появиться переходы по абсолютным адресам, поэтому внедряемый код желательно писать используя короткие процедуры, используя как можно меньше условий и циклов.
В случае возникновения проблем с внедряемым кодом, необходимо воспользоваться отладчиком и убедиться в том, что сгенерированный код удовлетворяет вышеприведенным условиям.

Если писать внедряемый код на delphi, то в нем нельзя использовать объекты, строки типа string, а также любые другие типы данных опирающиеся на функциональность Delphi Run Time Library. Вместо string следует использовать PChar и динамически, с помощью VirtualAlloc выделять память под строку, либо хранить строку в стеке объявляя её в локальных переменных как array of Char.

Использование API из внедряемого кода:

Если внедряемый код использует функции экспортируемые библиотеками отличными от ntdll.dll, то необходимо убедиться в наличии этих библиотек в АП целевого процесса, и при необходимости загрузить их.
Для загрузки библиотеки можно использовать функцию LdrLoadDll из ntdll.dll.

Нас интересует параметр pUniModuleName представляющий из себя указатель на строку типа UnicodeString в которой передается имя загружаемой DLL. По указателю pResultInstance будет сохранен адрес MZ заголовка загруженной DLL (параметр hInstance).

Следующий код загружает DLL аналогично функции kernel32 LoadLibraryW:

Код:

Для получения адреса функции чледует использовать LdrGetProcedureAddress.

Если необходимо обеспечить максимальную скрытность перехвата, то вообще лучше использовать во внедряемом коде только функции Native API.

Внедрение процедуры в процесс:

Так как внедрение участков кода и связанных с ними данных требует большого количества однотипных операций, введем процедуры упрощающие программирование подобных вещей.
Процедура копирования участка памяти в процесс:
Код:

Эта процедура предельно проста, она принимает хэндл открытого процесса, указатель на данные в текущем процессе и размер данных, а возвращает указатель на данные в целевом процессе.

Внедрение процедуры в целевой процесс:
Код:

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

Для облегчения программирования подобных вещей введем еще одну процедуру:
Код:

Эта процедура копирует в целевой процесс внедряемый код и структуру с данными для него, после чего запускает внедренный код.

Принимаемые параметры:

Process  - хэндл открытого процесса.

Thread   - указатель на внедряемый код в текущем процессе.
Info        - указатель на структуру с данными.
InfoLen - размер структуры с данными.

Results - необходимость возврата результата. (если true, то функция ожидает завершения удаленного потока и копирует обратно структуру с данными) .
Для определения размера внедряемого кода используется функция SizeOfProc, которая приведена далее.

Совершенствуем метод перехвата:

В предыдущей статье был описан метод перехвата путем замены первых 5 байт перехватываемой функции своими, для вызова реальной (true) функции нужно было установить обратно замененные байты, а после вызова - снова установить перехват.

Недостаток этого метода в том, что в многопоточных приложениях в моменты снятия - установки перехвата возможен вызов функции другим потоком напрямую, или возникновение критической ошибки в случае прерывания потока в момент записи участка кода. Эти недостатки можно устранить останавливая и запуская побочные потоки приложения каждый раз при вызове true функции, но это приведет к значительному снижению производительности, либо даже к взаимным блокировкам потоков (например при перехвате WaitForSingleObject).
Для устранения недостатков этого метода, следует его немного модифицировать. Необходимо выделить в памяти буфер, и скопировать туда участок начала перехватываемой функции содержащий целое число команд и имеющий длину >= 5 байт, после чего в его конце поставить jmp на следующую команду перехватываемой функции после сохраненного участка. После чего сформированный таким образом код можно будет вызывать в качестве true функции.
Этот метод имеет все достоинства и лишен недостатков предыдущего. Он обеспечивает корректную работу в многопоточном приложении и быстрый вызов true функций. Написание кода перехватчиков в этом случае также значительно упрощается.

Все эти действия производит следующая функция:
Код:

Для сохранения участка содержащего целое число команд используется функция SaveOldFunction:

Для снятия перехвата достаточно прочитать количество сохраненных байт и записать их обратно в начало перехватываемой функции.

Это делает следующий код:

Так как чаще всего приходиться перехватывать функции экспортируемые DLL, то для упрощения задачи введем еще одну функцию:

Код:

Внедрение процесса целиком:

Рассмотренный здесь метод внедрения отдельных процедур кода непрост по причине необходимости четко разграничить код и данные и формировать их отдельно. Но можно сделать куда проще - внедрить в адресное пространство целевого процесса весь образ текущего процесса целиком (код данные ресурсы и.т.д.) после чего запустить на выполнение и работать также, как и в своем процессе. Этот метод позволяет работать во внедряемом кода с RTL и применять обьектно ориентированное программирование, к тому же сам метод чрезвычайно прост для применения.
Для внедрения образа текущего процесса введем следующую функцию:
Код:

Она копирует полный образ исполнимого файла на диске в АП целевого процесса и запускает его выполнение в отдельном потоке с точки EntryPoint.

То же самое можно произвести и с любым другим образом исполнимого файла:

Приведем пример использования этого метода:

В этом коде следует обратить внимание на директиву {$IMAGEBASE $13140000}, она заставляем компилятор генерировать исполняемый образ с базой загрузки 13140000h. Адрес ImageBase следует выбирать таким, чтобы память в целевом процессе по этому адресу не была занята. Также перед тем, как использовать какие либо API вызовы из внедряемого кода, следует загрузить используемые DLL библиотеки с помощью LoadLibrary, так как в целевом процессе их может не оказаться.

Я думаю, вы уже заметили, что этот метод имеет одно единственное ограничение - это невозможность загрузки по адресу отличному от ImageBase. Если по этому адресу память в целевом процессе будет занята, то можно её освободить с помощью VirtualFree, но ни к чему хорошему это не приведет, так поступать можно только тогда, когда нужно полностью заменить целевой процесс, и перед этим необходимо остановить все его потоки. Тогда после загрузки исполняемого образа можно будет освободить всю связанную с заменяемым процессом память и уничтожить все его потоки.
Также к недостаткам этого метода можно отнести необходимость загрузки библиотек используемых внедряемым процессом, а это значительно снижает скрытность перехвата.

Существует способ преодолеть привязку внедряемого процесса к ImageBase, для этого нужно заставить компилятор генерировать в исполнимом файле reloc секцию, а после загрузки образа по произвольному адресу настраивать релоки (процедура настройки релоков приведена далее).

Усовершенствованный метод DLL Injection:

Для перехвата API в другом процессе весьма удобен и эффективен метод внедрения в него своей DLL, но этот метод имеет некоторые недостатки, так как необходимо хранить DLL на диске, и загрузку лишней DLL легко обнаружить программами типа PE-Tools. Также на лишнюю DLL могут заругаться антивирусы и фаерволлы (например Outpost Fierwall) что тоже нежелательно.
Но существует метод позволяющий загрузить DLL в другой процесс более незаметным способом. Для этого нужно внедрить в процесс образ этой DLL, затем настроить у нее таблицу импорта и релоки, после чего выполнить ее точку входа. Этот метод позволяет не хранить DLL на диске, а проводить действия с ней исключительно в памяти, также эта DLL не будет видна в списке загруженных процессом модулей, и на нее не заругается фаерволл.

Следующий код копирует и настраивает DLL в выделенный участок чужого адресного пространства:
Код:

Теперь для внедрения DLL в целевой процесс этим способом можно использовать следующую функцию:
Код:

В приведенном коде, как вы наверное заметили используется функция GetProcAddressEx для получения адреса API в целевом процессе.

Эта задача также выполняется с помощью внедрения кода и создания удаленных потоков.

Вот полный код этой функции:

Код:

Эта функция используется при заполнении таблицы импорта внедряемой библиотеки адресами API.