Модернизация IDA Pro. Debugger-плагин. Часть I. Теория
Всем привет. Я решил попробовать начать цикл статей по модернизации нашей с вами любимой 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 — то, с чего все начинают. Сложно, непонятно.
