Факультатив по x64dbg. Часть 1. Плагины: ScyllaHide, xAnalyzer, Snowman, PE-Viewer, ApiBreak

03.06.2024 | Категория Информационная безопасность

В данной статье речь пойдёт о плагинах хорошо зарекомендовавшего себя отладчика x64dbg. Материал было решено разделить на 2 части, поскольку этого требует назначение и классификация самих плагинов. Да, в сети уже и без того много самоучителей с рекламными лозунгами типа «Быстрый старт с нуля!». Но это вовсе не означает, что быстрый старт станет «быстрым финишем» на пути освоения реверса. Надеюсь данное чтиво поможет вам сделать хоть один мелкий шаг, и вы найдёте в нём что-то полезное для себя.

..::  Общие сведения  ::..

Плагины расширяют стандартные возможности софта, добавляя непредусмотренный изначально функционал. Хотя отладчик х64dbg вполне самодостаточен, некоторые плаги всё-же стоит к нему прикрутить – для этого нужно просто скачать и забросить плаг в одноимённую его папку \Plugins. При старте, код инициализации проверяет данную папку на наличие в ней файлов с расширением *.dp32/64 и если обнаружит таковые, то прихватит их в своё пространство памяти. После того как отобразится основное окно отладчика, установленные плагины можно будет найти в меню «Модули», хотя некоторые из них интегрируются вкладками прямо в интерфейс:

Если файл *.dp64 положить на анатомический стол, в первых 2-х байтах можно обнаружить в нём сигнатуру  ‘MZ’ , что говорит о его принадлежности к семейству исполняемых РЕ-файлов. Чтобы определиться с типом более конкретно, имеет смысл открыть плагин в любом софте парсинга заголовков – в поле «Characteristics» будет явно указана DLL. Таким образом, плагины представляют собой спрятанные под вуаль обычные библиотеки, в которых реализован дополнительный функционал отладчика:

В штатной поставке x64dbg вроде идёт только плагин «Scylla» (реконструктор таблицы-импорта IAT), а остальные на свой вкус и цвет можем добавить сами. Полный их список лежит здесь: https://github.com/x64dbg/x64dbg/wiki/Plugins, а далее я перечислю лишь те, которые использую в своей практике.

 

 

Когда разработчик софта не хочет, чтобы его секретные алгоритмы стали достоянием общественности, он использует в коде процедуры анти-отладки. Сейчас почти вся малварь юзает антидебаг, обильно посыпая свою тушку всевозможными технологиями стелс. Вариантов тут хоть отбавляй, и большинство из них прекрасно знакомы реверсерам, а вот сами инструменты отладки остаются как-то в стороне. «ScyllaHide» придерживается теневой дипломатии, и пытается скрыть отладчик x64dbg от софта, который не хочет, чтобы его обнаружили. Противоборство брони и снаряда.

Суть в том, что плагин осведомлён, какие протекторы используют какие техники скрытия, и перехватив нужные функции Win32API на пользовательском уровне Ring(3), он возвращает отлаживаему софту фиктивные сведения, мол в Багдаде всё спокойно. В его личной базе имеются алгоритмы антидебага таких протекторов как: Armadillo, Themida, Obsidium и VMProtect. Если автоматика не сработает, можно вручную добавить пункты из представленного списка. Значит качаем плагин по ссылке и расчехляем архив в дир \Plugins отладчика. Обратите внимание, в архивах всегда лежат по 2 плагина – отдельно для x32dbg, и отдельно для x64dbg (см.расширение *.dp64/32).

Помимо прямого назначения, плагин может послужить идейным вдохновителем для большинства из нас, т.к. предоставляет информацию, которую и в сети-то не всегда найдешь. Так, на практике часто встречаются только ламерские варианты типа чекнуть байт «BeingDebug» в структуре РЕВ, хотя как видим лист возможных вариантов гораздо больше. Проверить результат работы этого плагина просто – достаточно прочитать структуру РЕВ в отладчике x64dbg, и проверить в ней флаг «BeingDbg». Если процесс находится под отладкой, он должен принять логическое значение(1), иначе нуль. Упс.. флаг сброшен, а значит плагин исправно воркает:

Теперь, если отключить плаг в опциях, это поле должно принять значение True, что подтверждает скрин ниже. Значит делаем вывод, поскольку работает маскировка на уровне РЕВ, то нет оснований полагать о неработоспособности остальных вариантов. Кстати без предварительных танцев с бубном, на вкладке «Структура» вы не увидите ничего – как её активировать мы рассмотрим в части(3) данного материала.

 

 

В отличии от OllyDbg, наш герой почему-то остался без анализатора, который парсит параметры API-функций и выводит их значения в привычной нам текстовой форме. Может автору (Дункан Огилви, aka @mrexodia) было лень, а может звёзды не так cложились не знаю.. Но без этой фишки нам пришлось-бы постоянно рыться в справочниках, в поисках описания параметров вызываемых API. Особенно это касается флагов, которые передаются в виде двоичной маски.

К примеру на скрине ниже флаг «AllocationType» функции VirtualAlloc() задаёт тип выделяемой памяти mov r8=3000h, и если-бы не плагин, мы-бы судорожно перебирали в уме все возможные варианты. Одним словом как ни крути, но без «xAnalyzer» нам придётся дебажить при свечке. Быстренько качаем, и в ту-же папку \Plugins его.

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

На вкладке «Журнал» рабочей зоны, отладчик отображает логи происходящих в своей тушке событий.

На заключительном этапе инициализации, плагин «xAnalyzer» отчитывается перед нами следующим логом: 

[xAnalyzer]: Extended analysis completed in 0.105000 secs
[xAnalyzer]: Analysis completed in 1.177000 secs
[xAnalyzer]: Execution Summary
---------------------------------------
 - Defined Functions Detected    : 4
 - Undefined Functions Detected  : 0
 - VB DllFuncCalls Stubs Detected: 0
 - Total Functions Detected      : 4
 - Total Loops Detected          : 0
 - Total Comments Set            : 16
 - Total Labels Set              : 0
---------------------------------------

Если в этом логе вы обнаружите не нулевое значение в поле «Undefined Functions», значит плагин не смог найти описание какой-то функции в своей базе. Эта база всегда распространяется вместе с плагином, и лежит в папке «apis_def». Можно попробовать обновить её, или добавить в базу инфу о недостающей функции вручную.

 

 

 

Не смотря на своё глупое название «Снеговик», данный плагин довольно творческая единица. Это незаменимый инструмент для тех, кто плохо разбирается в инструкциях ассма. По сути представляет собой полноценный декомпилятор двоичного кода IA32e и ARM, причём абсолютно бесплатно, хотя автор дизассемблера «IDA-Pro» Ильфак Гильманов требует за аналогичный функционал «Hex-Rays» аж 4000$. Конечно-же райс способен декомпилировать не только инструкции архитектуры х86, но и порядка 60-штук других (например IA64, Alpha, и прочие), только рынок их слишком мал и не идёт ни в какое сравнение с IA32.

Пройдя этап переработки и метаболизма в тушке Snowman, субстанция подозрительного характера в виде бинарного кода каким-то чудом преобразуется в С-подобный исходник, который уже более понятен обычному обывателю. Это реально круто, и можно только догадываться, чего стоило автору добиться таких результатов (кстати им является сам @mrexodia). Для активации плагина выделите нужный участок кода, и нажмите комбинацию клавиш Shift+F5, ну или правым кликом мыши.

 

 

Плагин «PE-Viewer» работает над тем, чтобы в удобной форме представить нам информацию о хидере отлаживаемого РЕ-файла, а если нужно, даже отредактировать его. Не сказать, что плаг необходим, т.к. в природе имеется куча подобных инструментов с более мощным функционалом. Однако весь сторонний софт проводит статический анализ разбирая заголовок файла на диске, в то время как плагином можно запрашивать поля хидера в любой момент, ведь после загрузки образа программы в память, малварь может изменить его.

Все адреса в РЕ-Header всегда указываются в формате относительных RVA (Relative Virtual Address), и если в ОС выключен механизм рандомизации ASLR (Advanced Space Layout Randomize, а для файлов юзера он как-правило выключен), фактический адрес VA вычисляется по схеме Base + RVA которые хранятся в заголовке. Теперь, если на скрине ниже сложить значения в полях ImageBase + EntryPoint = 0x00478001, то в аккурат получим точку-входа в программу OEP «Original-Entry-Point». В плагине можно просматривать импорт, сведения о всех секциях, править записи каталога, ресурсы и многое другое. На мой взгляд очень удобная вещь.

 

 

Точки-останова, или на английский манер «BreakPoint» – обязательная часть процедуры отладки приложений, а данный плагин предоставляет нам простой способ их установки на функции Win32API системных библиотек. Список api для таргета вычисляется динамически на основе таблицы-импорта отлаживаемого софта, и нам остаётся лишь тыкнуть в них мышкой. Не забудьте в параметрах выставить галку LoadLibrary(), чтобы была возможность ставить шунт на цепочки GetProcAddress().

Но такой метод установки брейков подходит лишь для начинающих реверсеров, поскольку имеет весьма ограниченные возможности – мы не можем задействовать аппаратные точки на чтение/запись ячеек памяти, условные «Conditional-Break», и многое другое. Сам факт поддержки командной строки любым инструментом (в т.ч. и отладчиком x64dbg) свидетельствует о его высоком либидо и буйном темпераменте. Игра типа «Нажал на кнопку – получил банан» явно не наш вариант. А вот если ввести в окно «Команда» всего два символа bp, то синтаксический анализатор сам подскажет нам поддерживаемые команды из списка (их назначения можно прочитать в штатной справке x64dbg.chm).

Кстати небольшой ликбез по точкам-останова..

Известно, что они бывают всего 2-х типов: программные и аппаратные. В первых нет ничего заумного – это просто инструкция int-3 по заданному адресу. В x64dbg такой бряк можно поставить по F2, предварительно установив курсор на нужный адрес (повторное нажатие анулирует точку). При этом отладчик запоминает у себя инструкцию по данному адресу, а вместо неё записывает 1-байтный опкод прерывания int3 = 0xCC. Для пользователя действо происходит прозрачно, и он даже не замечает подмены, хотя она по факту существует.

А вот с аппаратными точками всё намного сложнее, поскольку к решению проблем подключается сам процессор. Это реализованный аппаратно большой механизм, для которого выделяется специальный набор из 8-ми регистров DR0-DR7, хотя два из них DR4:5 отправлены в резерв и не используются. В библии Интела том(3) можно найти описание этих регистров, и в близком приближении они распределены так:

Здесь видно, что под адреса точек выделяются всего 4-регистра DR0:3, и соответственно мы не сможем за один раз установить более четырёх хард-точек HBP. Отладчик способен отображать состояние дебаг-регистров в своём окне, а потому если задать аппаратную точку командой bph [address] или правой кнопкой мыши, то сможем увидеть их значения прямо в процессе отладки.

Теперь если расшифровать по таблице выше значение регистра DR7=415h = 0100.00.01.01.01, то выходит всё верно – включены только точки 0,1,2, а четвёртая свободна. Ради эксперимента можно заполнить все, после чего попытаться установить ещё и пятую. Тогда отладчик предупредит, что лимит исчерпан и нужно освободить любую из занятых. Как говорится «дефицит не ждёт, а поджидает момента». Имейте ввиду, что хоть под юзером прямая запись в регистры mov dr7,xxxx и вызывает исключение, хитрый софт всё-же способен оперировать ими через чтение/запись контекста потока функциями Get/SetThreadContext().

 

Заключение

Все перечисленные выше плагины просто собирают информацию, и не производят над ней никаких действий. В следующей части мы рассмотрим уже плагины тяжёлой артилерии, сместив центр в сторону ручной распаковки UPX и ASPack, с всегда сопроваждающей их правкой таблицы-импорта IAT.

Для досконального погружения в тему и практику навыков реверсинга могу порекомендовать курс Академии Реверсивный инжиниринг ПО под ОС Windows.
Или, если для вас это новая тема, есть курс дающий полноценную базу для тех, кто только входит в тему реверсинга Введение в реверс инжиниринг

Телефон: +7 499 444 17 50 | 8 800 444 17 50 бесплатно по России | E-mail: school@codeby.email
Все курсы Партнерам Возврат Контакты