- Регистрация
- 7 Фев 2020
- Сообщения
- 525
- Реакции
- 98
- Репутация
- 147
Чтобы полностью понять содержание этой статьи, необходимы знания:
DLL инъекция осуществляется путем внедренияDLL в пространство другого процесса и последующего выполнение его кода.
Примером может послужить следующим фрагментом кода:
Вот пример кода DLL, который я буду использовать для демонстрации:
В предыдущем коде внедрения DLL источник DLL получен по полному пути на диске. Из-за этого такой метод не очень скрытный, а также данная зависимость может быть проблемой в случае разделения.
Эти проблемы могут быть решены с помощью Reflective DLLинъекции,которая позволяет получать DLL в форме необработанных данных.
Чтобы иметь возможность вводить данные в целевой процесс, мы должны вручную отобразить бинарник в виртуальную память, как это делал бы загрузчик образов Windows при вызове LoadLibrary.
Вот краткое описание шагов алгоритма, которые будут выполнены для внедрения DLL в внешний процесс:
Чтобы сохранить DLL вместе с инжектором как единое целое, мы можем воспользоваться разделом ресурсов формата PE.
Извлечение необработанного двоичного файла DLL является тривиальной задачей, которую можно выполнить с помощью API ресурса. Перед извлечением мы должны проверить, существует ли DLL в ресурсах следующим образом:
Отображение в память
Нам понадобится преобразовать его в форму памяти для дальнейшей обработки, для этого мы можем проанализировав его структуру и отобразить его в пространство памяти.
Пересборка и внедрение DLL
Прежде чем пересобрать библиотеку DLL, мы должны сначала проверить, существует ли целевой процесс, и, если он существует, получить дескриптор к нему. Мы можем сделать это, перечислив все запущенные процессы и затем сравнив их имена:
Следующим шагом является перемещение адреса с помощью таблицы перемещения. Дельта фактического выделенного базового адреса в целевом процессе вместе с исходным базовым адресом вычисляется с помощью простого вычитания:
Выполнение почти такое же, как и при обычном внедрении DLL с использованием вызова CreateRemoteThread. Единственная разница здесь в том, что мы не будем использовать LoadLibrary, но вместо этого мы будем использовать адрес значения точки входа непосредственно из DLL, которая должна бытьDllMain.
Демонстрация
В этой демонстрации я буду использовать, putty.exe, потому что я не могу использовать explorer.exe,потому что это 64-битный процесс по сравнению с моим 32-битным инжектором и DLL. Кроме того, у меня нигде нет 32-битной виртуалки. Я также буду использовать инструмент мониторинга Process Hacker для просмотра результата внедрения DLL.
Обычная DLL инъекция
Вот результат обычного метода внедрения DLL:
Мы можем видеть, что он четко отображается в списке загруженных модулей и очевидно, что в затронутом процессе присутствует посторонний код.
Отражающая DLL инъекция
Давайте теперь проверим метод внедрения отражающей DLL:
И здесь нет названия для этого блока памяти. Помимо RWX разрешений, нет никаких явных признаков того, что существует какой-либо сторонний код!
- C/C ++
- WinAPI
- Виртуальная память
- Формат файла PE
DLL инъекция осуществляется путем внедренияDLL в пространство другого процесса и последующего выполнение его кода.
Примером может послужить следующим фрагментом кода:
Первым шагом является выделение места в пространстве виртуальной памяти целевого процесса, что можно сделать с помощью функции VirtualAllocEx, указав дескриптор процесса. Затем мы можем использовать WriteProcessMemoryдля записи данных в процесс, используя полный путь к полезной нагрузке DLL. Чтобы выполнить код, все , что мы должны сделать это восстановить LoadLibraryфункцию из kernel32модуля , а затем вызвать CreateRemoteThreadдля выполнения LoadLibrary в целевом процессе , чтобы заставить загрузить полезную нагрузку DLL в качестве библиотеки. В результате она немедленно выполнит DllMainс указанием.
Вот пример кода DLL, который я буду использовать для демонстрации:
Отражающая DLL инъекция (Reflective DLL Injection)
В предыдущем коде внедрения DLL источник DLL получен по полному пути на диске. Из-за этого такой метод не очень скрытный, а также данная зависимость может быть проблемой в случае разделения.
Эти проблемы могут быть решены с помощью Reflective DLLинъекции,которая позволяет получать DLL в форме необработанных данных.
Чтобы иметь возможность вводить данные в целевой процесс, мы должны вручную отобразить бинарник в виртуальную память, как это делал бы загрузчик образов Windows при вызове LoadLibrary.
Вот краткое описание шагов алгоритма, которые будут выполнены для внедрения DLL в внешний процесс:
- Получение полезной нагрузки DLL
- Отображение DLL в памяти
- После отображения его в память, его таблица импорта должна быть перестроена
- Сопоставление DLL целевому процессу
- Сопоставленный DLL записывается в целевой процесс.
Чтобы сохранить DLL вместе с инжектором как единое целое, мы можем воспользоваться разделом ресурсов формата PE.
Извлечение необработанного двоичного файла DLL является тривиальной задачей, которую можно выполнить с помощью API ресурса. Перед извлечением мы должны проверить, существует ли DLL в ресурсах следующим образом:
Приведенный выше код будет перечислять все ресурсы типа PAYLOAD и, если выполнение будет успешным, то будет взят дескриптор ресурса путем вызова FindResource. Получив дескриптор, мы можем получить указатель на необработанные двоичные данные и скопировать их в память, используя следующую функцию:
Имейте в виду, что после вызова LockResource указатель на ресурс DLL доступен только для чтения, а данные представлены в виде диска, что означает, что все смещения - это смещение файлов, а не смещения памяти.bool Injector::LoadFromResource()
{
DWORD dwSize = ::SizeofResource:GetModuleHandle(NULL), this->payload->hResPayload);
HGLOBAL hResData = ::LoadResource(NULL, this->payload->hResPayload);
if (hResData)
{
LPVOID lpPayload = ::LockResource(hResData);
if (lpPayload)
{
if (MemoryMapPayload(lpPayload))
return true;
}
}
return false;
}
Отображение в память
Нам понадобится преобразовать его в форму памяти для дальнейшей обработки, для этого мы можем проанализировав его структуру и отобразить его в пространство памяти.
Здесь сегмент памяти отображается так, что мы можем преобразовать бинарный файл в его отображенный в памяти аналог. Разделы сначала копируются в память, поскольку они совпадают с объектом диска и образом памяти. Далее перечисляются заголовки разделов, чтобы собрать виртуальные смещения самих разделов, которые используются для вставки разделов в их соответствующие области. После завершения преобразования мы можем просто сохранить его и очистить отображенную память.
Пересборка и внедрение DLL
Прежде чем пересобрать библиотеку DLL, мы должны сначала проверить, существует ли целевой процесс, и, если он существует, получить дескриптор к нему. Мы можем сделать это, перечислив все запущенные процессы и затем сравнив их имена:
Теперь мы можем проверить, можем ли мы выделить некоторую память в адресном пространстве целевого процесса. Для этого мы можем использовать VirtualAllocEx функцию, указав дескриптор процесса и размер изображения:
Как только мы подтвердим, что есть свободное место, мы можем перейти к пересоберем DLL. Пересоберем таблицы импорта:
По сути, таблица импорта получается через структуру необязательного заголовка в формате PE и обходит ее, извлекая имена импортированных функций, а затем перезаписывает FirstThunk адреса. Для этого сначала нужно получить библиотеку, содержащую функцию LoadLibrary, а затем вызвать GetProcAddress для получения соответствующего адреса.
Следующим шагом является перемещение адреса с помощью таблицы перемещения. Дельта фактического выделенного базового адреса в целевом процессе вместе с исходным базовым адресом вычисляется с помощью простого вычитания:
Как и в таблице импорта, данные в таблице перемещения применяются с соответствующим смещением по указанным адресам с использованием вычисленной дельты:
Теперь, когда мы восстановили то, что должно быть восстановлено, и распределили память во внешнем процессе, мы можем просто написать весь двоичный файл, используя WriteProcessMemory:
Выполнение DLL
Выполнение почти такое же, как и при обычном внедрении DLL с использованием вызова CreateRemoteThread. Единственная разница здесь в том, что мы не будем использовать LoadLibrary, но вместо этого мы будем использовать адрес значения точки входа непосредственно из DLL, которая должна бытьDllMain.
Вот и все!)
Демонстрация
В этой демонстрации я буду использовать, putty.exe, потому что я не могу использовать explorer.exe,потому что это 64-битный процесс по сравнению с моим 32-битным инжектором и DLL. Кроме того, у меня нигде нет 32-битной виртуалки. Я также буду использовать инструмент мониторинга Process Hacker для просмотра результата внедрения DLL.
Обычная DLL инъекция
Вот результат обычного метода внедрения DLL:
Мы можем видеть, что он четко отображается в списке загруженных модулей и очевидно, что в затронутом процессе присутствует посторонний код.
Отражающая DLL инъекция
Давайте теперь проверим метод внедрения отражающей DLL:
И здесь нет названия для этого блока памяти. Помимо RWX разрешений, нет никаких явных признаков того, что существует какой-либо сторонний код!