Содержание статьи
В хакерской практике достаточно часто возникает потребность
внедрить в готовый exe-файл свой код (необязательно вредоносный) так, чтобы он получал управление первым, не вызывал ругательств со стороны антивирусов и вообще по возможности вел себя максимально скрытно, не бросаясь в глаза. Как это сделать? Мы знаем, как, и сейчас обстоятельно тебе это объясним.
Существует целое семейство утилит, предназначенных для склейки нескольких программ в один файл, с общим названием «джойнеры» (от английского «joiner» — «соединитель»):
Joiner by Blade, SuperGlue, MicroJoiner, Juntador и множество других. Их подробный обзор можно отрыть в статье «Клейкий софт». Однако качество склейки оставляет желать лучшего. Большинство джойнеров просто помещают внедряемый файл в оверлей основного exe-файла и при запуске копируют его на диск во временную папку или, еще чаще, в системный каталог Windows, прав записи в который у простого пользователя, не сидящего под администратором, разумеется, нет, и операция накрывается медным тазом. В любом случае копирование занимает какое-то время, замедляя загрузку программ, что рождает в голове пользователе смутные подозрения.
Более совершенные джойнеры работают по принципу
упаковщиков исполняемых файлов и проецируют внедренный exe непосредственно в оперативную
память, что не только ускоряет загрузку, но и, с точки зрения PE-формата, выглядит намного более
политкорректно («честный» PE-файл с оверлеем — это редкость).
Однако все джойнеры без исключения рано или поздно попадают в антивирусные базы, поскольку представляют собой готовые утилиты, в которых легко выделить постоянную сигнатуру (даже если они выполнены на полиморфной основе).
Правильные хакеры так себя не ведут и склеивают программы самостоятельно. И это совсем нетрудно! Нужны лишь верный друг hiew и минимальные навыки программирования на Си. Но прежде чем брать быка за рога, сделаем одно важное уточнение. Внедряемый код не обязательно должен быть вирусом, червем, руткитом или любой другой вредоносной заразой, поэтому, во избежание недоразумений, условимся называть его X-кодом.
Как мы будем действовать
Всякий exe-файл импортирует одну или несколько динамических библиотек (Dynamic Link Library, или сокращенно DLL), прописанных в таблице импорта. При запуске exe-файла системный загрузчик анализирует таблицу импорта, загружает все перечисленные в ней динамические библиотеки, вызывая функцию DllMain для инициализации каждой DLL, и только после этого передает управление на оригинальную точку входа (Original Entry Point, или сокращенно OEP) запускаемого exe-файла.
Таким образом, если мы добавим в таблицу импорта подопытного exe-файла свою DLL, проблема внедрения X-кода будет успешно решена. Самое замечательное, что DLL может быть написана на любом языке (хоть на ассемблере, хоть на DELPHI) и совершенно неподвластна антивирусам, поскольку они органически неспособны распознавать неизвестную заразу. Ах да… Эвристические анализаторы. Но эти штуки очень легко обойти (чему посвящено множество статей, в том числе и моих, которые можно найти на
http://nezumi.org.ru).
Подготовка к экспериментам
Прежде чем вторгаться в базовые структуры PE-файла, неплохо бы получить общее представление о его устройстве. В MSDN входит спецификация на PE-формат («Microsoft Portable Executable and Common Object File Format Specification»), написанная на враждебном для нас английском языке и ориентированная преимущественно на честных программистов. Мыщъх исправил этот недостаток, переведя спецификацию на русский язык и переориентировав ее на хакеров. Электронная копия доступна для бесплатной скачки по адресу
http://nezumi.org.ru/souriz/PE-desc-n-inject.zip
и на диске к журналом.
Ок, теперь подготовим «дрозофилу», предназначенную для внедрения X-кода. Ее пример, написанный на языке Си, приведен ниже:
#include <stdio.h>
main()
{
printf("I'm nezumi\n"); // выводим что-нибудь на экран
}
Компилируем ее любым подходящим компилятором (например, в случае Microsoft Visual C++ командная строка будет выглядеть так: «$cl.exe inject.c»). После этого на диске образуется файл inject.exe, при запуске выдающий на экран следующее приветствие (обращаем внимание, что это консольная программа, которая должна запускаться из-под FAR'а или штатного командного интерпретатора cmd.exe; при запуске из проводника окно консоли автоматически закроется сразу же после завершения программы, и мы ни хвоста не увидим):
$inject.exe
I'm nezumi
Разобравшись с «дрозофилой», займемся подготовкой динамической библиотеки, то есть того самого X-кода, который мы будем внедрять внутрь inject.exe. В простейшем случае исходный код будет выглядеть так:
#include <stdio.h>
#include <windows.h>
// создаем фиктивную экспортируемую функцию,
// которую потом будет импортировать «дрозофила»
__declspec(dllexport) int dummy(){ return 0;}
/* точка входа в dll, получающая управление при различных обстоятельствах */
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason,LPVOID lpvReserved)
{
// приветствие, выводимое до запуска «дрозофилы»
if (fdwReason==DLL_PROCESS_ATTACH) printf("hello,world!\n");
// приветствие, выводимое перед завершением работы «дрозофилы»
if (fdwReason==DLL_PROCESS_DETACH) printf("good-bye,world!\n");
}
Обрати внимание, что DllMain, в отличие от EntryPoint, вызывается многократно: а) при подключении к процессу; б) при завершении процесса или выгрузки динамической библиотеки API-функцией FreeLibrary; в) при создании процессом нового потока; г) при завершении одного из существующих потоков процесса. Другими словами, DllMain позволяет отслеживать определенные системные события и адекватно реагировать на них. В данном случае мы выводим «hello, world!» перед запуском «дрозофилы» и «good-bye, world!» перед завершением ее работы.
Компиляция динамической библиотеки осуществляется следующим образом: «$cl.exe injected_dll.c /LD», где ключ ‘/LD’ сообщает компилятору, что необходимо сгенерировать именно DLL, а не EXE (как это происходит по умолчанию).
Внедрение X-DLL в таблицу импорта «дрозофилы»
Берем в свои загребущие лапы hiew, открываем файл inject.exe, переходим в hex-режим по <ENTER>, давим <F8> для отображения PE-заголовка, нажимаем <F10> (Dir) и среди прочих элементов IMAGE_DATA_DIRECTORY выбираем секцию импорта (Import), расположенную в нашем случае по RVA-адресу, равному 5484h и раскинувшуюся в ширину на целых 28h байт (смотри рисунок 1).
Клавиша <ENTER> переносит нас к структуре Import Directory Table, о которой мы поговорим чуть позже. А пока обсудим, как найти указатель на Import Directory Table при отсутствии hiew'а.
Двойное слово, лежащее по смещению 80h от начала PE-заголовка (легко опознаваемого визуально по сигнатуре PE), и есть RVA-адрес, указывающий на Import Directory Table, а следующее двойное слово хранит ее размер. Так что для поиска таблицы
импорта hiew совсем необязателен.
Таблица импорта представляет собой достаточно сложное сооружение иерархического типа. Вершину иерархии занимает структура Import Directory Table, фактически являющаяся массивом подчиненных структур типа IMAGE_IMPORT_DESCRIPTOR, каждая из которых содержит RVA-указатель на имя загружаемой динамической библиотеки, ссылки на OriginalFirstThunk и FirstThunk с именами/ординалами импортируемых функций (причем поле OriginalFirstThunk не является обязательным и может быть равно нулю). Два других поля — TimeDateStamp (временная отметка) и ForwarderChain (форвардинг) - также необязательны, и потому для подключения своей собственной DLL нам необходимо заполнить всего лишь два поля структуры IMAGE_IMPORT_DESCRIPTOR: Name и FirstThunk, а также создать таблицу Import Address Table (сокращено IAT), импортирующую по меньшей мере одно имя (в данном случае
dummy).
typedef struct _IMAGE_IMPORT_DESCRIPTOR {
union {
DWORD Characteristics; // 0 for terminating null import descriptor
DWORD OriginalFirstThunk; // RVA to original unbound IAT
};
DWORD TimeDateStamp; // TimeDateStamp
DWORD ForwarderChain; // -1 if no forwarders
DWORD Name; // name of the dll
DWORD FirstThunk; // RVA to IAT
} IMAGE_IMPORT_DESCRIPTOR;
Если вместо стройной иерархии структур в нашей голове образовалась каша, не стоит волноваться — это нормально! Постепенно она утрясется и все структуры встанут на свои места, так что оставим их дозревать, а сами сосредоточимся на текущих проблемах. Чтобы внедрить X-DLL в Import Directory Table, необходимо добавить еще один экземпляр структуры IMAGE_IMPORT_DESCRIPTOR. Но просто так сделать это не получится, поскольку сразу же за концом Import Directory Table начинается IAT первой динамической библиотеки, и нам просто некуда втиснуться, если, конечно, не перенести Import Directory Table в какое-нибудь другое место! А что?! И перенесем!
Повторяем описанную последовательность действий с hiew'ом еще раз, идя в начало таблицы импорта (а точнее, как мы уже знаем, на первый элемент Import Directory Table), давим <Gray-*> («звездочку» на цифровой клавиатуре) и, перемещаясь курсорными клавишами, выделяем бордовым цветом 28h байт (размер Import Directory Table). После этого давим <Gray-*> еще раз и, нажав <F2>, сохраняем блок в файл, для определенности назвав его idt-org.
Теперь, прокручивая файл, клацаем <PageDown> до тех пор, пока не выйдем на оперативный простор свободного места, оккупированного длинной вереницей нулей. В нашем случае это место располагается по адресу 405810h, непосредственно за концом таблицы импорта.
Далее нам необходимо скопировать оригинальную Import Directory Table на новое место, не забыв при этом зарезервировать место для одного элемента структуры типа IMAGE_IMPORT_DESCRIPTOR, в который мы чуть позже поместим нашу динамическую библиотеку. Она будет проинициализирована самой первой, что очень полезно для борьбы с антивирусами, иммунизирующими exe-файлы путем прививки им специальной dll-вакцины, выполняющей проверку целостности содержимого образа исполняемого файла.
Поскольку, как нетрудно подсчитать, размер структуры IMAGE_IMPORT_DESCRIPTOR составляет 14h байт, а незанятая область начинается с адреса 405810h, мы должны передвинуть курсор по адресу 405824h, нажать <Gray-*>, выделить 28h байт (размер оригинальной Import Directory Table) и нажать <Gray-*> еще раз, а потом обязательно переместить курсор в начало выделенного блока. Далее жмем <Ctrl-F2> (Get Block), вводим имя файла, в который мы только что сохранили блок, - idt-org и считываем его с диска.
Теперь возвращаемся в начало файла и корректируем RVA-адрес таблицы импорта, который в данном случае составит 5824h. У тебя может возникнуть вопрос: почему 5824h, а не 405824h?! Да потому что RVA-адреса получаются путем вычитания базового адреса (прописанного в заголовке PE-файла и в нашем случае равного 400000h) из виртуального адреса (равного 405824h). Причем, с учетом порядка старшинства байт, принятого на процессорах x86 (младшие биты располагаются по меньшим адресам), мы должны записать 24 58, а не 58 24, как делают многие начинающие хакеры, удивляясь потом, почему оно не работает.
Значит, открываем файл inject.exe в hiew'e, находим PE-сигнатуру, опускаем курсор вниз на 80h байт, видим там 84 54 (смотри рисунок 1), нажимаем <F3> для разрешения редактирования, меняем адрес на 24 58, сохраняем изменения по <F9> и выходим… за пивом. Пиво для хакеров — это святое!
Проверяем работоспособность файла — а вдруг она пострадала?! Запускаем inject.exe и (если все операции были проделаны правильно) на экране появится триумфальное приветствие. В противном же случае система откажется загружать файл или выбросит исключение.
Смочив пересохшее горло, приступаем к самой сложной и самой ответственной части — заполнению структуры IMAGE_IMPORT_DESCRIPTOR. Начнем с того, что переместим курсор в конец Import Directory Table, подогнав его к адресу 405850h, и запишем имя функции-пустышки (dummy), оканчивающееся нулем и предваренное двумя нулями, а следом за ним – имя внедряемой динамической библиотеки injected_dll.dll. Впрочем, порядок их расположения может быть и другим, системному загрузчику на такие мелочи уже давно положить.
Сделав это, перемещаемся на первый байт, ранее зарезервированный нами для структуры IMAGE_IMPORT_DESCRIPTOR, и начинаем колдовать. Первое двойное слово оставляем равным нулю. За ним идут 4 байта, отведенные для TimeDataStamp, и мы, желая слегка поизвращаться, занесем сюда IAT, то есть двойное слово, содержащее RVA-адрес импортируемой функции. В нашем случае эта функция зовется dummy, а ее имя (предваренное двумя нулями!) начинается с RVA-адреса 5850h. Учитывая обратный порядок байт на x86, пишем: 50 58. Пропустив следующее двойное слово (Forwarder Chain), в поле Name записываем RVA-адрес имени внедряемой динамической библиотеки injected_dll.dll, в нашем случае равный 5858h. Остается заполнить последнее поле — Import Address Table, содержащее RVA-адрес таблицы IAT, размещенной нами поверх поля TimeDateStamp с RVA-адресом, равным 5814h.
Вот, собственно говоря, и все… После добавления новой структуры IMAGE_IMPORT_DESCRIPTOR в массив Import Directory Table, последний будет выглядеть так:
.00405810:00 00 00 00-50 58 00 00-00 00 00 00-58 58 00 00 PX XX .00405820:14 58 00 00-AC 54 00 00-00 00 00 00-00 00 00 00 ¶X мT .00405830:00 58 00 00-00 50 00 00-00 00 00 00-00 00 00 00 X P .00405840:00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 .00405850:00 00 64 75-6D 6D 79 00-69 6E 6A 65-63 74 65 64 dummy injected .00405860:5F 64 6C 6C-2E 64 6C 6C-00 00 00 00-00 00 00 00 _dll.dll
Остается сущая мелочь. Надо вернуться в начало файла, отсчитать от PE-заголовка 80h байт, исправив указатель на таблицу импорта с 5824h на 5810h и увеличив ее размер до 3Сh. Сохраняем проделанные изменения и, набрав побольше воздуха в грудь, запускаем файл
inject.exe:
$inject.exe
hello,world!
I'm nezumi
good-bye,world!
Это работает! Причем не просто работает, а очень даже хорошо работает. Внедренная динамическая библиотека послушно выводит «hello, world!» еще до запуска файла-«дрозофилы» и «good-bye, world!» непосредственно перед ее завершением! Красота! Вот только… посторонняя DLL нам очень сильно мешает, вызывая естественное желание задвинуть ее куда-нибудь подальше. И тут мы плавно переходим ко второй части нашего рассказа.
Копирование X-DLL в NTFS-stream
Файловая система NTFS выгодно отличается от FAT'а тем, что поддерживает потоки (streams). Их еще называют атрибутами (attributes), но чтобы не путать их с атрибутами типа «только на чтение», мы будем придерживаться первого термина. Каждый файл имеет минимум один безымянный поток, хранящий актуальные данные файла. Именно его размер высвечивает проводник Windows и продвинутые файловые менеджеры типа FAR'а. Однако мы можем создавать и дополнительные потоки, отделяя их имя от имени файла знаком двоеточия («:»), например: my_file:my_stream1, my_file:my_stream2. Штатные средства Windows не поддерживают работу с именованными потоками, и потому добраться до их содержимого не так-то просто. Не существует никакой (стандартной) возможности определить, имеет ли данный файл именованные потоки или нет.
Чувствуешь, куда я клоню? Давай спрячем X-DLL внутрь inject.exe, поместив ее в именованный поток. Внимание! Это совсем не то же самое, что тупо склеить два файла, как поступает большинство джойнеров. При копировании X-DLL в NTFS-поток видимый размер «дрозофилы» не увеличивается, и при открытии файла inject.exe функцией fopen("inject.exe", "rb"), никаких следов присутствия X-DLL в ней не окажется! Более того, при передаче файла через http для проверки антивирусной службой в online, передается только безымянный поток (содержащий полезную программу без X-DLL), и, естественно, антивирусы в ней ничего не обнаружат. Кстати говоря, большинство антивирусов сканирует только безымянный поток! Так что X-DLL может чувствовать себя в относительной безопасности, тепле, сухости и комфорте.
Расклад ясен? Тогда действуем. Открываем inject.exe в hiew'е, привычным движением переходим к таблице импорта: <ENTER>, <F8>, <F10>, <стрелка «вниз»>, <ENTER>. Меняем имя динамической библиотеки injected_dll.dll на inject.exe:x.dll, где inject.exe — имя подопытного файла, в который мы собираемся внедрить X-DLL, а x.dll – имя самой внедряемой динамической библиотеки.
Теперь необходимо скопировать injected_dll.dll в inject.exe:x.dll, что легко осуществить с помощью FAR'а. Подогнав курсор к динамической библиотеке injected_dll.dll, нажимаем <Shift-F5> и пишем «inject.exe:x.dll». Все! По завершении копирования исходную динамическую библиотеку injected_dll.dll можно удалить. Больше она нам не понадобится. Кстати говоря, размер файла inject.exe после создания нового именованного потока не увеличился ни на байт! Дисковые ревизоры (вместе с прочими системами контроля) тут просто отдыхают.
Теперь запускаем файл inject.exe и убеждаемся, что его работоспособность в результате последних манипуляций ничуть не пострадала.
Переход от теории к практике
Внедрение своей собственной динамической библиотеки - это, конечно, очень хорошо, но на практике гораздо чаще приходится сталкиваться с тем, что требуется
внедрить чужой исполняемый файл. Что делать?! Преобразовывать его в DLL?! Конечно же нет! Достаточно просто слегка доработать нашу X-DLL, научив ее запускать exe-файлы посредством API-функции CreateFile, при этом сами исполняемые файлы можно (и нужно) поместить в именованные NTFS-потоки, число которых фактически неограниченно. Причем, если внедряемый exe тащит за собой динамические библиотеки или другие компоненты, они также могут быть внедрены в NTFS-потоки (естественно, в текущем каталоге их уже не окажется, и потому исполняемый файл придется подвергнуть правке на предмет изменения всех путей). Если же этот файл упакован (а большинство боевых утилит типа систем удаленного администрирования редко поставляются в открытом виде), наша X-DLL может перехватить API-функции CreateFile/LoadLibrary, автоматически отслеживая обращения к отсутствующим файлам и подсовывая вместо них соответствующие им именованные NTFS-потоки.
Другой немаловажный момент. Отправляя exe-файл с внедренной в него X-DLL по почте, записывая его на лазерный диск или любой другой не-NTFS-носитель, мы теряем все именованные потоки, и программа тут же отказывает в работе, ругаясь на то, что не может найти dll.
Ситуация кажется критической, можно даже сказать, драматической, но на помощь приходит благородный архиватор RAR, обладающий уникальной способностью сохранять все имеющиеся в файле NTFS-потоки. Запускаем RAR, выбираем inject.exe, нажимаем кнопку «Добавить» (или давим <CTRL-A>), после чего в свойствах архива взводим галочку «Сохранять файловые потоки» (вкладка «Дополнительно»). Также при желании можно создать SFX-архив на тот случай, если у получателя не окажется RAR'а, но это уже технические детали.
Повторяем процедуру пересылки файла по электронной почте еще раз, распаковываем полученный архив, запускаем inject.exe, и… о чудо! Он работает!
Заметай за собой следы (для грамотных парней)
Некоторые файлы (особенно упакованные протекторами) скрупулезно следят за своей целостностью и на попытку внедрения реагируют, прямо скажем, не совсем адекватно. Однако поскольку X-DLL получает управление вперед остальных, она может восстановить таблицу импорта в памяти, как будто все так и было, словно к ней никто и не прикасался. Для этого достаточно вызывать API-функцию
VirtualProtect, присвоив соответствующим регионами памяти атрибут
PAGE_READWRITE, восстановить таблицу импорта (оригинал которой легко сохранить в
X-DLL), а затем заново установить атрибут PAGE_READONLY с помощью все той же
VirtualProtect. Более того, X-DLL может выделить блок памяти из кучи с помощью API-функции VirtualAlloc и скопировать туда свое тело, которое, естественно, должно быть полностью перемещаемо, то есть сохранять работоспособность независимо от базового адреса загрузки. Далее остается только выгрузить ставшую ненужной X-DLL вызовом FreeLibrary (на тот случай, если какой-то хитрый механизм проверки целостности решит перечислить список загруженных модулей).
Маленький технический нюанс: на процессорах с поддержкой битов
NX/XD, запрещающий исполнение кода в страницах памяти, не имеющих соответствующих атрибутов, выделяемому блоку памяти следует присвоить атрибут
PAGE_EXECUTE_READWRITE. В противном случае, если у пользователя задействован аппаратный DEP для всех приложений (а не только для системных компонентов, как это происходит по умолчанию), вместо выполнения машинного кода система выбросит исключение, и выполнение троянизированной программы завершится в аварийном режиме.
В заголовке PE-файла имеется специальное поле, содержащее контрольную сумму. В подавляющем большинстве случаев оно равно нулю, но если это не так, то после вмешательства в таблицу импорта контрольную сумму необходимо пересчитать. Этим занимается утилита
EDITBIT.EXE, запущенная с ключом ‘/RELEASE’. Она входит как в штатную поставку компилятора Microsoft Visual
Studio, так и в Platform SDK, так что проблем с ее поиском возникнуть не должно.
Заключение
Технологии внедрения в исполняемые файлы не стоят на месте и развиваются вместе с защитными механизмами и операционными системами. Извечная проблема меча и щита — кто усовершенствуется первым. Использование готовых утилит, работающих в полностью автоматическом режиме, во-первых, непрестижно, а во-вторых, слишком ненадежно. Разработчики антивирусов даром свой хлеб не едят! Чтобы не погореть на мелочах, весь X-код следует писать самостоятельно. До тех пор пока он существует в единственном экземпляре, у защитных систем не остается никакого шанса предотвратить атаку!
|
|
