Обратная разработка MCU

Примечание: все программы защищены паролем. После загрузки кода отправьте нам письмо, и MikaTech вышлет вам пароль.

 

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

Исходный код на ассемблере обычно допускает использование констант и комментариев программиста. Они обычно удаляются ассемблером из собранного машинного кода. Если это так, дизассемблер, работающий с машинным кодом, выдаст дизассемблирование без этих констант и комментариев; результат становится труднее интерпретировать человеку, чем исходный аннотированный код. Некоторые дизассемблеры используют символьную отладочную информацию, присутствующую в объектных файлах, таких как ELF. Интерактивный дизассемблер позволяет пользователю вручную задавать мнемонические символы для значений или областей кода в интерактивном режиме: человеческое понимание, применяемое к процессу дизассемблирования, часто сравнимо с творчеством при написании кода.

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

Написание дизассемблера, который выдаёт код, после ассемблирования дающий в точности исходный двоичный код, возможно, но часто возникают различия. Это предъявляет требования к выразительности ассемблера. Например, x86-ассемблер выбирает произвольно между двумя двоичными кодами для такой простой команды, как "MOV AX,BX". Если исходный код использует другой вариант, исходный код просто невозможно воспроизвести в данной точке. Однако даже при получении полностью корректного дизассемблирования остаются проблемы, если программу требуется модифицировать. Например, одна и та же команда машинного перехода может быть сгенерирована кодом ассемблера для перехода по указанному адресу (например, для выполнения конкретного кода) или для перехода на заданное число байт (например, для пропуска нежелательной ветви). Дизассемблер не может знать, что подразумевалось, и может использовать любой синтаксис, генерируя дизассемблирование, которое воспроизводит исходный двоичный код[источник не указан]. Однако если программист хочет добавить инструкции между инструкцией перехода и её целью, необходимо понять работу программы, чтобы определить, должен ли переход быть абсолютным или относительным, т.е. должна ли его цель оставаться в фиксированной позиции или быть сдвинутой, чтобы пропускать как исходные, так и добавленные инструкции.

 

Примеры дизассемблеров

Дизассемблер может быть автономным или интерактивным. Автономный дизассемблер при запуске генерирует файл на ассемблере, который можно изучить; интерактивный немедленно показывает эффект любого изменения, сделанного пользователем. Например, дизассемблер может изначально не знать, что секция программы является кодом, и обрабатывать её как данные; если пользователь указывает, что это код, результат дизассемблирования отображается немедленно, позволяя пользователю изучить его и предпринять дальнейшие действия в том же сеансе.
Любой интерактивный отладчик включает способ просмотра дизассемблирования отлаживаемой программы. Часто тот же инструмент дизассемблирования поставляется как автономный дизассемблер вместе с отладчиком. Например, objdump, часть GNU Binutils, связан с интерактивным отладчиком gdb.

IDA
OllyDbg — это 32-разрядный отладчик с анализом на уровне ассемблера
OLIVER и SIMON включают дизассемблеры для ассемблера, COBOL и PL/1

 

 

Декомпилятор

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

Термин "декомпилятор" чаще всего применяется к программе, которая преобразует исполняемые файлы (выход компилятора) в исходный код на (относительно) высокоуровневом языке, который после компиляции даст исполняемый файл, поведение которого идентично исходному. В отличие от этого, дизассемблер преобразует исполняемый файл в язык ассемблера (и ассемблер может собрать его обратно в исполняемый файл).
Декомпиляция — это процесс использования декомпилятора, хотя этот термин также может относиться к результату работы декомпилятора. Она может использоваться для восстановления утерянного исходного кода, а также полезна в некоторых случаях для компьютерной безопасности, интероперабельности и исправления ошибок.[1][ненадёжный источник] Успех декомпиляции зависит от объёма информации, присутствующей в декомпилируемом коде, и сложности выполняемого анализа. Байт-код, используемый многими виртуальными машинами (такими как Java Virtual Machine или .NET Framework Common Language Runtime), часто содержит обширные метаданные и высокоуровневые возможности, что делает декомпиляцию вполне осуществимой. Наличие отладочных данных может позволить воспроизвести исходные имена переменных и структур, а также номера строк. Машинный язык без таких метаданных или отладочных данных гораздо труднее поддаётся декомпиляции.[2]
Некоторые компиляторы и инструменты пост-компиляции создают обфусцированный код (т.е. пытаются получить выходные данные, которые очень трудно декомпилировать). Это делается для усложнения обратной разработки исполняемого файла.

 

Проектирование

Декомпиляторы можно рассматривать как состоящие из серии этапов, каждый из которых вносит свой вклад в общий процесс декомпиляции.

 

Загрузчик

Первый этап декомпиляции загружает и анализирует входной машинный код или промежуточное представление программы в формате двоичного файла. Он должен уметь обнаруживать основные факты о входной программе, такие как архитектура (Pentium, PowerPC и т.д.) и точка входа. Во многих случаях он должен уметь находить эквивалент функции main программы на C, которая является началом пользовательского кода. Это исключает код инициализации времени выполнения, который по возможности не должен декомпилироваться. Если доступны таблицы символов и отладочные данные, они также загружаются. Внешний интерфейс может определить используемые библиотеки, даже если они связаны с кодом, что даст интерфейсы библиотек. Если он может определить использованный компилятор или компиляторы, это может дать полезную информацию для идентификации идиом кода.

 

Дизассемблирование

Следующий логический этап — дизассемблирование инструкций машинного кода в машинно-независимое промежуточное представление (IR). Например, инструкция Pentium
mov eax, [ebx+0x04]
может быть переведена в IR
eax := m[ebx+4];

 

Идиомы

Идиоматические последовательности машинного кода — это последовательности кода, чья комбинированная семантика не очевидна из семантики отдельных инструкций. Либо как часть фазы дизассемблирования, либо в рамках последующего анализа, эти идиоматические последовательности должны быть переведены в эквивалентное IR. Например, следующий код x86:
cdq eax ; edx устанавливается в знаковое расширение eax
xor eax, edx
sub eax, edx
может быть переведён в
eax := abs(eax);
Некоторые идиоматические последовательности машинно-независимы; некоторые включают только одну инструкцию. Например, xor eax, eax очищает регистр eax (устанавливает его в ноль). Это может быть реализовано с помощью машинно-независимого правила упрощения, такого как a xor a = 0.
В общем случае лучше отложить обнаружение идиоматических последовательностей, если это возможно, до более поздних этапов, которые менее подвержены влиянию порядка инструкций. Например, этап планирования инструкций компилятора может вставлять другие инструкции в идиоматическую последовательность или изменять порядок инструкций в ней. Процесс сопоставления образов на этапе дизассемблирования, скорее всего, не распознает изменённый образец. Более поздние этапы группируют выражения инструкций в более сложные выражения и преобразуют их в каноническую (стандартизированную) форму, что повышает вероятность того, что даже изменённая идиома будет соответствовать шаблону более высокого уровня на более поздних этапах декомпиляции.
Особенно важно распознавать идиомы компилятора для вызовов подпрограмм, обработки исключений и операторов switch. Некоторые языки также имеют обширную поддержку строк или длинных целых чисел.

 

Анализ программы

К IR могут быть применены различные анализы программы. В частности, распространение выражений объединяет семантику нескольких инструкций в более сложные выражения. Например,
mov eax,[ebx+0x04]
add eax,[ebx+0x08]
sub [ebx+0x0C],eax

может привести к следующему IR после распространения выражений:
m[ebx+12] := m[ebx+12] - (m[ebx+4] + m[ebx+8]);

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

 

Анализ потока данных

Места, где определяются и используются содержимое регистров, должны быть отслежены с помощью анализа потока данных. Тот же анализ может быть применён к местам, используемым для временных переменных и локальных данных. Затем для каждого такого связного множества определений и использований значений может быть сформировано различное имя. Возможно, что одно и то же место локальной переменной использовалось для разных переменных в разных частях исходной программы. Более того, возможно, что анализ потока данных выявит путь, по которому значение может перетекать между двумя такими использованиями, даже если на самом деле это никогда не произойдёт или не будет иметь значения. В плохих случаях это может привести к необходимости определить место как объединение типов. Декомпилятор может позволить пользователю явно разорвать такие неестественные зависимости, что приведёт к более чистому коду. Это, конечно, означает, что переменная потенциально используется без инициализации, что указывает на проблему в исходной программе.

 

Анализ типов

Хороший декомпилятор машинного кода должен выполнять анализ типов. Здесь способ использования регистров или ячеек памяти накладывает ограничения на возможный тип ячейки. Например, инструкция and подразумевает, что операнд является целым числом; программы не используют такую операцию над значениями с плавающей точкой (кроме специального библиотечного кода) или над указателями. Инструкция add приводит к трём ограничениям, поскольку операнды могут быть оба целыми, или один целый и один указатель (с целым и указателем в результате соответственно; третье ограничение связано с порядком двух операндов, когда типы различны).

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

Пример из предыдущего раздела может привести к следующему высокоуровневому коду:
struct T1 *ebx;
struct T1 {
int v0004;
int v0008;
int v000C;
};
ebx->v000C -= ebx->v0004 + ebx->v0008;

 

Структуризация

Предпоследний этап декомпиляции включает структурирование IR в более высокоуровневые конструкции, такие как циклы while и условные операторы if/then/else. Например, машинный код
xor eax, eax
l0002:
or ebx, ebx
jge l0003
add eax,[ebx]
mov ebx,[ebx+0x4]
jmp l0002
l0003:
mov [0x10040000],eax
может быть переведён в:
eax = 0;
while (ebx < 0) {
eax += ebx->v0000;
ebx = ebx->v0004;
}
v10040000 = eax;

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

 

Генерация кода

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

Непосредственно перед генерацией кода может быть желательным разрешить интерактивное редактирование IR, возможно, с использованием некоторой формы графического интерфейса пользователя. Это позволило бы пользователю вводить комментарии и нестандартные имена переменных и функций. Однако их почти так же легко ввести после декомпиляции в текстовом редакторе. Пользователь может захотеть изменить структурные аспекты, например, преобразовать цикл while в цикл for. Это менее просто изменить с помощью простого текстового редактора, хотя инструменты рефакторинга исходного кода могут помочь в этом процессе. Пользователю может потребоваться ввести информацию, которая не была идентифицирована на этапе анализа типов, например, изменить выражение памяти на выражение массива или структуры. Наконец, неправильное IR может потребовать исправления, или могут быть внесены изменения, чтобы выходной код был более читаемым.