Модернизация IDA Pro. Debugger-плагин. Часть I. Теория +15
C++, Assembler, Реверс-инжиниринг
Рекомендация: подборка платных и бесплатных курсов C++ - https://katalog-kursov.ru/
Всем привет. Я решил попробовать начать цикл статей по модернизации нашей с вами любимой
IDA Pro.
В каждом из туториалов я попытаюсь раскрыть довольно таки сложную и мало изученную тему: написание различных модулей:
- загрузчики;
- плагины;
- дебагер-плагины;
- процессорные модули;
- скрипты.
И, если
процессорные модули,
плагины и
скрипты — тема все таки более менее раскрытая, то все остальное — практически полный мрак (
в конце статьи я дам список литературы и проектов, где есть хоть что-то).
Итак, первая статья из цикла будет посвящена написанию
плагина-отладчика, а точнее предварительной теории. В штатной поставке
IDA SDK уже имеются исходники основных дебагеров (
Windows,
Linux,
Mac). Но как быть, например, с
Amiga,
M68000?
Данная статья скорее будет посвящена скучной и не очень теории. Настоятельно рекомендуется с ней ознакомиться, т.к. многие моменты в дальнейшем могут быть непонятны именно из-за невозможности представить общую концепцию.
Для начала, определимся с тем, какие бывают плагины-отладчики.
Типы дебагер-плагинов
У плагинов-отладчиков для
IDA бывает два основных типа:
- локальный — исполняется на той же машине, на которой происходит процесс отладки;
- удаленный (RPC) — исполняется удаленно. Придется дергать его локальным плагином.
Еще есть кое-какие другие, но они не будут рассмотрены в данных статьях (или будут?). Я опишу здесь только
локальный отладчик, т.к.
удаленный требует в два раза больше кода (клиент и сервер), и еще не достаточно хорошо мной изучен.
Составляющие дебагер-плагина
- Собственно, IDA. Посылает команды, принимает и реагирует на сообщения от дебагера, отображает текущее состояние отладки;
- Эмулятор нужного нам процессора или кода. Допустим, он умеет выполнять инструкции, сообщать о брейкпоинтах, приостанавливать и продолжать процесс эмуляции, стартовать и завершать процесс;
- Ну и сам дебагер-плагин. Он должен взаимодействовать с эмулятором, посылать сообщения в IDA, читать текущее состояние регистров, памяти.
Итак, обо всех составляющих по порядку.
IDA — визуальный интерфейс
Собственно, сама
IDA является переходником между интерфейсом пользователя и
дебагером, посылая ему
команды, и ожидая какой-либо реакции (
сообщений). Команды могут быть такими:
- Завершение обработки текущего события;
- Начало / пауза / завершение процесса или потока;
- Шаг (Step Into, Step Over, Step Until Return);
- Установка / удаление бряков;
- Чтение / запись памяти или регистров;
Дебагер-плагин
Задача плагина — реагировать на команды от
IDA (
см. выше), и посылать ей события следующих типов, сработавших в
эмуляторе:
- Старт / приостановка / присоединение / отсоединение от / завершение процесса;
- Старт / завершение потока;
- Брейкпоинт;
- Шаг (Step Into, Step Over, Step Until Return);
- Исключение.
Посылать сообщения нужно, чтобы
IDA знала, что сейчас происходит, и отображала текущее состояние отладки. При наступлении, например, событий бряка или шага, должно отобразиться окно отладчика, с целью ожидания дальнейших действий от пользователя.
Эмулятор — всему голова
Каково назначение
эмулятора? Конечно, выполнение инструкций. Еще он умеет хранить контекст. Иногда, держит информацию о брейкпоинтах (а бывает, что и нет — тогда приходится их реализовывать на уровне
дебагера). Так же, бывает, что функции приостановки / продолжения исполнения сам
эмулятор не имеет, и приходится ее как-то реализовывать. Одно радует — обычно исходники эмуляторов для многих платформ уже существуют, и, зачастую, их нужно только чуть-чуть модернизировать под нашу задачу.
Итак,
эмулятор сообщает в
дебагер о наступлении в себе событий:
- Произошел запуск / завершение процесса или потока;
- Сработал брейкпоинт;
- Был выполнен шаг;
- Сработало исключение.
События
Разберем событие Шага:
- Я нажимаю в IDA клавишу F7 (Step Into);
- В дебагер попадает команда завершения последнего наступавшего до этого события. Обычно дебагер в этом случае должен будет сказать эмулятору продолжить исполнение;
- Далее дебагер получает команду выполнения шага в потоке, реагирует на это выполнением одной инструкции эмулятора;
- Эмулятор сообщает обратно в дебагер о том, что событие STEP наступило, помещая его в очередь событий (об очереди событий читайте ниже);
- Дебагер достает из очереди событий отправленное событие, и сообщает о нем в IDA;
- IDA реагирует на наступившее событие. В данном случае, осознает, что шаг был выполнен, и показывает текущий адрес EIP, на который мы встали после выполнения шага;
- После того, как мы насмотрелись на окно IDA с состоянием регистров и прочего, и хотим что-то сделать дальше (например, другой шаг, нажимая F7), происходит снова цикл на первый пункт.
Очередь событий:
Такая штука, которая постоянно крутится в отдельном потоке
дебагера, в ожидании наступления новых событий
эмулятора. Получая новое событие, необходимо приостановить эмуляцию (т.к. шаг подразумевает фриз процесса), а затем передать событие в
IDA. Когда
IDA сообщит, что событие обработано, в
дебагер придет команда завершения обработки текущего события.
Как видите, тема очень мутная, и, не очень простая. Но, это так кажется на первый взгляд. В следующей статье мы приступим собственно к написанию дебагер-плагина, заодно и разберемся, что да как.
— Список литературы и проектов:
- The IDA Book — лучшая в своем роде книга по IDA Pro. Там есть практически все (ну, кроме как о дебагерах).
MUST HAVE!;
- deci3dbg — один из двух публичных дебагер-модулей.
Отладчик для PS3;
- idados — второй дебагер-модуль, хоть и жутко кривой (но автора можно простить, т.к. тема мало изучена и сейчас).
Отладчик MS-DOS;
- idados_dosbox — мой форк предыдущего проекта. Хотя бы собирается нормально, и не так бажит;
- IDASDK\plugins\debugger — то, с чего все начинают. Сложно, непонятно.
К сожалению, не доступен сервер mySQL