Разбор Буткита

Всем привет! В связи с запуском курса "Обратный инжиниринг" Мы провели плановый открытый урок.

Он был демонтирован алгоритм буткита на разных этапах его загрузки.

Учитель - Артур Пакулов , вирусный аналитик «Лаборатории Касперского».

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

Подробный разбор самого буткита смотрите в видео.

Bootkit — вредоносная программа, изменяющая Master Boot Record — первый сектор первого физического диска или загрузочного сектора — VBR. Программы такого типа в основном обладают троянским функционалом и используются для выполнения каких-либо скрытых действий в системе.

В нашем примере буткит повышает привилегии до системного уровня для процесса, имя которого начинается с последовательности букв: «inte».

По сути, буткит — это руткит, который начинает работать в защитном кольце 0, которое запускается до начала загрузки операционной системы.

Именно поэтому он представляет большой интерес для исследований.

Для разработки такой программы обычных навыков реверс-инжиниринга недостаточно.

Недостаточно просто прочитать листинг; вам также необходимо понимать такие вещи, как архитектура процессора, адресация памяти и т. д. Ключевые части буткита мы рассмотрели на открытом уроке.

Для этой работы был подготовлен специальный образец bootkit-xp.exe, работающий под управлением Windows XP. Поэтому помимо изучения буткита мы немного поностальгировали по этой операционной системе.

Но в целом ОС XP была выбрана для облегчения обратного хода, поскольку XP предлагает хорошую обзорность и отсутствие ненужных сложностей.

Ну образец писался именно для этой ОС, судя по его коду.

И здесь как выглядит установщик буткита? :

Просто взглянув на это, можно сделать определенные выводы.

Например, сразу заметно, что этот файл имеет небольшой вес.

Если вы посмотрите на точку входа, то заметите, что код получает дескриптор файла с именем символической ссылки на первый физический диск — «PhysicalDrive0»:

Далее для простоты понимания кода переехал в ИДА .

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

Даже таблица импорта подозрительно мала:

Такая картина обычно возникает при анализе упакованных проб.

Но в нашем случае файл не выглядит упакованным.

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

является.

Продолжим изучение кода.

Как мы уже видели в HIEW, функция называется СоздатьФайлА с интересным аргументом в качестве первого параметра.

Что именно здесь делается? Здесь уместно вспомнить такое понятие, как объекты ядра .

Ими нельзя управлять непосредственно из пользовательского режима, но они управляются ядром операционной системы.

В пользовательском режиме программа может только сделать запрос на получение/изменение состояния объекта ядра.

Чтобы указать системе, с каким объектом ядра будет работать программа, необходимо получить хэндл необходимого объекта ядра.

При запросе квитанции, если все проверки пройдены, ОС вернется к нам.

ручка запрошенный ЗП.

И уже используя дескриптор, мы можем работать с ассоциированным с ним объектом.

Таким образом, на изображении выше CreateFile используется для доступа к первому подключенному физическому жесткому диску по символической ссылке.

Если доступ предоставлен, то с таким «файлом» можно работать, как с любым другим простым файлом.

То есть весь жесткий диск будет представлен как один большой файл.

Итак, продолжим.

Хэндл вернулся, и мы оказались здесь:

Что будет дальше? И тогда функция ЧтениеФайла , считывает первые 0x200 байт. И у нас там самый первый сектор первого физического диска.

Как вы уже догадались, это Главная загрузочная запись (МБР).

MBR состоит из трех частей: кодовой части, таблицы разделов и подписи.

В обычной ситуации биос считывает MBR в память по адресу 0:0x7c00h, передавая ему управление.

Итак, часть кода MBR начинает выполняться.

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

В случае с буткитом, если MBR перезаписана, его код теперь возьмет на себя управление.

Ок, MBR прочитан, что дальше ? И тогда буткит снова открывает PhysicalDrive0, но уже с режимом доступа на запись.

Далее указатель устанавливается на 600-е смещение.

То есть исходный сектор читается и копируется в третий сектор .

Зачем создавать резервную копию сектора? Очевидно, это необходимо для того, чтобы оно понадобится в будущем.

Затем начинается цикл.

Естественно, глядя на код, нельзя не обратить внимание на константы типа var_1C, 1BEh и другие.

А заодно следует освежить в памяти структуру MBR, расположенную выше.

В частности, нас интересует столбец «Смещение».

Смотри, буфер чтения первого сектора в порядке.

lpBuffer .

Потом к нему добавляется 1BEh Фактически, указатель направлен на начало раздела таблицы.

Все данные, начиная с таблицы и до конца сектора, вставляются в _маркированные_байты , начиная с того же смещения — 1BE.

То есть в _маркированные_байты вставляются вторая и третья части исходного MBR. Что будет дальше? Так SetFilePointer устанавливает указатель на самое начало нашего «файла», т.е.

на MBR.

Затем сгенерированный файл записывается (WriteFile) _маркированные_байты и освобождение памяти.

На этом функциональность установщика буткита заканчивается.

Но было бы здорово посмотреть, что именно есть в первой части _маркированные_байты .

Для этого сбросьте его на диск и проанализируйте.

Первое, что бросается в глаза, это то, что содержимое переменной по адресу 0x413 уменьшено на 2.

Если посмотреть техническую документацию, то можно обнаружить, что переменная по адресу 0X413 содержит объем установленной физической памяти в килобайтах.

Соответственно, код буткита «отрезает» два килобайта памяти:

Теперь, что бы ни случилось дальше, будет считаться, что памяти стало на 2 килобайта меньше, чем было.

Почему пока не ясно.

Что будет дальше вычисление физического адреса к «откушенному» участку памяти с помощью побитового сдвига влево на 6 бит:

Сдвиг на 6 делает сразу две вещи — преобразует килобайты в байты (путем умножения значения переменной на 2^10), получая тем самым физический адрес откушенного куска памяти, и извлекает из него номер сегмента, разделив результат на 0x10 (2^4).

После этого ваше тело будет скопировано на этот кусок памяти, и, поскольку код буткита находится именно в «откушенном» куске, его больше никто не побеспокоит .

Более того, никакие прерывания не изменят то, что записано в этой области памяти.

Можно сказать, что код становится практически невидимым для системы как будто памяти там не было.

Это только начало буткита.

Дальше будет перехват прерывания, мониторинг сигнатуры ntldr, модификация модуля ядра ОС и т.д. Поэтому не будем портить, так лучше посмотреть вебинар до конца, чтобы ничего не пропустить.

Теги: #обратное проектирование