Русский перевод практического руководства по ассемблеру Arm, формату ELF, статическому и динамическому анализу и обратной разработке программ.
Больше крутых материалов в моём телеграм-канале @grogrigs
Если вы читаете эту книгу, то, вероятно, уже слышали о языке ассемблера Arm и знаете, что его понимание служит ключом к анализу двоичных файлов, выполняемых на Arm. Но что это за язык и зачем он существует? В конце концов, программисты обычно пишут код на языках высокого уровня, таких как C/C++, и почти никто не программирует непосредственно на ассемблере. Ведь языки высокого уровня гораздо удобнее для программистов.
К сожалению, языки высокого уровня слишком сложны, чтобы процессоры могли интерпретировать их непосредственно. Поэтому программисты компилируют программы на языках высокого уровня в двоичный машинный код, который способен выполнять процессор.
Этот машинный код - не совсем то же самое, что язык ассемблера. Если открыть его непосредственно в текстовом редакторе, он будет выглядеть непонятным. Процессоры также не выполняют язык ассемблера: они выполняют только машинный код. Почему же тогда ассемблер так важен в обратной разработке?
Чтобы понять назначение ассемблера, совершим краткий экскурс в историю вычислительной техники и посмотрим, как мы пришли к современному положению дел и как всё связано между собой.
В незапамятные времена, когда всё только начиналось, люди решили создавать компьютеры и поручать им простые задачи. Компьютеры не говорят на человеческих языках - в конце концов, это всего лишь электронные устройства, - поэтому нам понадобился способ общаться с ними посредством электрических сигналов.
На самом нижнем уровне компьютеры работают с электрическими сигналами, которые формируются переключением электрического напряжения между двумя уровнями: включено и выключено.
Первая проблема состоит в том, что для общения, хранения данных и простого описания состояния системы нам необходимо как-то обозначать эти состояния включения и выключения. Поскольку состояний два, естественным решением стало применение двоичной системы для кодирования их значений. Каждая двоичная цифра (или бит) могла иметь значение 0 либо 1. Хотя один бит способен хранить лишь минимально возможный объём информации, соединение нескольких битов в последовательность позволяет представлять гораздо большие числа. Например, число 30 284 334 537 можно представить всего 35 битами:
Такая система уже позволяет кодировать большие числа, но теперь возникает новая проблема: где в памяти (или на магнитной ленте) заканчивается одно число и начинается следующее? Современному читателю этот вопрос может показаться странным, однако во времена проектирования первых компьютеров он был весьма серьёзным. Простейшее решение заключалось в создании групп битов фиксированного размера. Специалисты по вычислительной технике, не желавшие упускать удачную игру слов, назвали такую группу двоичных цифр, то есть битов, байтом (byte).
Итак, сколько битов должно быть в байте? Для современного человека ответ кажется совершенно очевидным: все мы знаем, что современный байт состоит из 8 битов. Но так было не всегда.
Первоначально в разных системах по-разному определяли количество битов в байте. Предшественником известного нам сегодня 8-битного байта был 6-битный формат двоично-десятичного кода для обмена информацией (Binary Coded Decimal Interchange Code, BCDIC), применявшийся для представления буквенно-цифровой информации в ранних компьютерах IBM, например в IBM 1620 1959 года. До этого байты часто имели длину 4 бита, а ещё раньше словом "байт" обозначали произвольное количество битов, превышающее 1. Лишь позднее, после появления в 1960-х годах 8-битного расширенного двоично-десятичного кода для обмена информацией (Extended Binary Coded Decimal Interchange Code, EBCDIC) в линейке мейнфреймов IBM System/360 с побайтово адресуемой памятью и 8-битными байтами, размер байта начал стандартизироваться на уровне 8 битов. Затем 8-битный размер единицы хранения был принят и в других широко распространённых компьютерных системах, включая Intel 8080 и Motorola 6800.
Ниже приведён отрывок из опубликованной в 1962 году книги
1. Полная ёмкость в 256 символов считалась достаточной для подавляющего большинства областей применения.
2. В пределах этой ёмкости один символ представляется одним байтом, поэтому длина конкретной записи не зависит от сочетания символов в этой записи.
3. 8-битные байты достаточно экономно расходуют пространство хранения.
8-битный байт может содержать одно из 256 различных значений - от 00000000 до 11111111. Разумеется, интерпретация этих значений зависит от использующего их программного обеспечения. Например, в таких байтах можно хранить положительные числа, представляя значения от 0 до 255 включительно. С помощью дополнительного кода можно также представлять знаковые числа от -128 до 127 включительно.
Разумеется, компьютеры использовали байты не только для кодирования и обработки целых чисел. Они также часто хранили и обрабатывали понятные человеку буквы и цифры, называемые символами.
В ранних кодировках символов, таких как ASCII, решили использовать по 7 битов на байт, однако это давало лишь ограниченный набор из 128 возможных символов. Такой набор позволял кодировать буквы и цифры английского языка, а также несколько знаков и управляющих символов, но не мог представлять многие буквы, используемые в других языках. Стандарт EBCDIC с его 8-битными байтами выбрал совершенно другой набор символов и использовал кодовые страницы для "переключения" между языками. Однако в конечном счёте этот набор символов оказался слишком громоздким и негибким.
Со временем стало ясно, что необходим по-настоящему универсальный набор символов, поддерживающий все живые языки мира и специальные знаки. Итогом стало создание в 1987 году проекта Unicode. Существует несколько различных кодировок Unicode, но в Интернете преобладает UTF-8. Символы из набора ASCII входят в UTF-8 без изменений, а "расширенные символы" могут занимать несколько последовательных байтов.
Поскольку теперь символы кодируются байтами, их можно представлять двумя шестнадцатеричными цифрами. Например, символы A, R и M обычно кодируются октетами, показанными на рис. 1.1.
Рисунок 1.1. Буквы A, R и M и их шестнадцатеричные значения
Каждую шестнадцатеричную цифру можно закодировать 4-битовой комбинацией в диапазоне от 0000 до 1111, как показано на рис. 1.2.
Рисунок 1.2. Шестнадцатеричные значения ASCII и их 8-битные двоичные эквиваленты
Поскольку для кодирования символа ASCII требуются два шестнадцатеричных значения, 8 битов представлялись идеальным размером для хранения текста на большинстве письменных языков мира, а для символов, которые невозможно представить лишь 8 битами, подходил размер, кратный 8 битам.
Благодаря такой схеме гораздо проще истолковать смысл длинной последовательности битов. Следующая битовая комбинация кодирует слово Arm:
Одна из исключительно мощных особенностей компьютеров, отличающая их от предшествовавших им механических калькуляторов, состоит в том, что логику их работы также можно закодировать в виде данных. Такой код можно хранить в памяти или на диске, обрабатывать либо изменять по мере необходимости. Например, обновление программного обеспечения способно полностью изменить операционную систему компьютера без покупки новой машины.
Мы уже увидели, как кодируются числа и символы, но как кодируется логика? Здесь в дело вступают архитектура процессора и его набор инструкций.
Если бы мы создавали собственный компьютерный процессор с нуля, то могли бы разработать собственную кодировку инструкций, сопоставив двоичные комбинации машинным кодам, которые наш процессор способен интерпретировать и на которые способен реагировать, то есть фактически создали бы собственный "машинный язык". Поскольку машинные коды предназначены для того, чтобы "предписывать" электронной схеме выполнение некоторой "операции", их также называют кодами инструкций, а чаще - кодами операций (operation codes, opcodes).
На практике большинство людей пользуются существующими компьютерными процессорами и, следовательно, кодировками инструкций, определёнными производителем процессора. В Arm кодировки инструкций имеют фиксированный размер - 32 или 16 битов в зависимости от набора инструкций, используемого программой. Процессор извлекает и интерпретирует каждую инструкцию, а затем поочерёдно выполняет их, воплощая логику программы. Каждая инструкция представляет собой двоичную комбинацию, или кодировку инструкции, составленную по конкретным правилам архитектуры Arm.
В качестве примера предположим, что мы создаём крошечный 16-битный набор инструкций и определяем внешний вид каждой инструкции. Сначала необходимо выделить часть кодировки, которая будет точно указывать тип выполняемой инструкции; эта часть называется кодом операции. Например, можно отвести под код операции первые 7 битов инструкции и задать коды операций сложения и вычитания, как показано в табл. 1.1.
Таблица 1.1. Коды операций сложения и вычитания
Писать машинный код вручную возможно, но это неоправданно громоздко. На практике удобнее записывать ассемблерные инструкции на некотором понятном человеку "языке ассемблера", который будет преобразован в эквивалентный машинный код. Для этого необходимо также определить сокращённое обозначение инструкции, называемое мнемоникой инструкции, как показано в табл. 1.2.
Таблица 1.2. Мнемоники
Разумеется, недостаточно просто велеть процессору выполнить "сложение". Нужно также сообщить ему, какие две величины следует сложить и что сделать с результатом. Например, если мы пишем программу, выполняющую операцию a = b + c, значения b и c до начала инструкции должны где-то храниться, а инструкция должна знать, куда записать результат a.
В большинстве процессоров, и в частности в процессорах Arm, такие временные значения обычно хранятся в регистрах, вмещающих небольшое количество "рабочих" значений. Программы могут загружать данные из памяти (или с диска) в регистры, подготавливая их к обработке, а после обработки выгружать результирующие данные обратно в долговременное хранилище.
Количество регистров и правила их именования зависят от архитектуры. По мере усложнения программного обеспечения программам всё чаще приходится одновременно манипулировать большим количеством значений. Хранить и обрабатывать эти значения в регистрах быстрее, чем непосредственно в памяти; следовательно, регистры уменьшают количество обращений программы к памяти и ускоряют выполнение.
Вернёмся к предыдущему примеру. Мы разрабатывали 16-битную инструкцию, выполняющую операцию, которая прибавляет значение к регистру и записывает результат в другой регистр. Поскольку под саму операцию (ADD/SUB) используются 7 битов, оставшиеся 9 битов можно отвести для кодирования регистра-источника, регистра назначения и постоянного значения, которое требуется прибавить или вычесть. В этом примере мы поровну делим оставшиеся биты и назначаем сокращения и соответствующие машинные коды, показанные в табл. 1.3.
Таблица 1.3. Назначение машинных кодов вручную
Вместо создания этих машинных кодов вручную можно написать небольшую программу, которая преобразует синтаксическую конструкцию ADD R1, R0, #2 (R1 = R0 + 2) в соответствующую комбинацию машинного кода, а затем передаёт эту комбинацию нашему условному процессору. См. табл. 1.4.
Таблица 1.4. Программирование машинных кодов
Составленная нами битовая комбинация представляет одну из кодировок 16-битных инструкций ADD и SUB, входящих в набор инструкций T32. На рис. 1.3 показаны её составные части и порядок их расположения в кодировке инструкции.
Рисунок 1.3. 16-битная кодировка Thumb для инструкций ADD и SUB с непосредственным операндом
Разумеется, это лишь упрощённый пример. Современные процессоры предоставляют сотни возможных инструкций, зачастую с более сложными вложенными кодировками. Например, Arm определяет инструкцию загрузки в регистр (с мнемоникой LDR), которая загружает 32-битное значение из памяти в регистр, как показано на рис. 1.4. В этой инструкции "адрес", с которого производится загрузка, указывается в регистре 2 (называемом R2), а прочитанное значение записывается в регистр 3 (называемый R3).
Рисунок 1.4. Инструкция LDR загружает значение с адреса в R2 в регистр R3
Квадратные скобки вокруг R2 в записи инструкции означают, что значение в R2 следует интерпретировать как адрес в памяти, а не как обычное значение. Иными словами, требуется не скопировать значение из R2 в R3, а получить содержимое памяти по адресу, заданному в R2, и загрузить это значение в R3. Программа может обращаться к области памяти по многим причинам, в том числе для вызова функции или загрузки значения из памяти в регистр.
В сущности, именно в этом состоит различие между машинным кодом и ассемблерным кодом. Язык ассемблера - это понятный человеку синтаксис, показывающий, как следует интерпретировать каждую закодированную инструкцию. Машинный код, напротив, представляет собой фактические двоичные данные, которые принимает и обрабатывает реальный процессор; его кодировка точно задаётся разработчиком процессора.
Если процессоры понимают только машинный код, но не язык ассемблера, то как выполнить преобразование между ними? Для этого необходима программа, которая преобразует написанные нами вручную ассемблерные инструкции в эквивалентный машинный код. Программы, выполняющие такую задачу, называются ассемблерами.
На практике ассемблеры способны не только понимать и переводить отдельные инструкции в машинный код, но и интерпретировать директивы ассемблера[2], предписывающие ассемблеру другие действия, например переключение между данными и кодом или ассемблирование разных наборов инструкций. Таким образом, английские термины
Эти директивы и выражения представляют собой удобные сокращения, которые можно использовать в ассемблерной программе. Однако, строго говоря, они являются не частью самого языка ассемблера, а указаниями о том, как должен работать ассемблер.
Для разных платформ доступны разные ассемблеры: например, ассемблер GNU as, который также применяется для ассемблирования ядра Linux; ассемблер armasm из набора инструментов ARM Toolchain; или одноимённый ассемблер Microsoft armasm, входящий в Visual Studio.
В качестве примера предположим, что требуется ассемблировать следующие две 16-битные инструкции, записанные в файле myasm.s:
В этой программе первые три строки являются директивами ассемблера. Они сообщают ассемблеру, где следует разместить ассемблированные данные (в данном случае в разделе .text), определяют метку точки входа нашего кода (в данном случае _start) как глобальный символ и, наконец, указывают, что необходимо использовать кодировку инструкций Thumb. Набор инструкций Thumb (T32) входит в архитектуру Arm и допускает инструкции шириной 16 битов.
Чтобы скомпилировать эту программу на машине с операционной системой Linux и процессором Arm, можно воспользоваться ассемблером GNU as.
Ассемблер читает программу на языке ассемблера myasm.s и создаёт объектный файл myasm.o. Этот файл содержит 4 байта машинного кода, соответствующего двум нашим двухбайтовым инструкциям в шестнадцатеричной форме.
Ещё одной особенно полезной возможностью ассемблеров является понятие метки, которая ссылается на конкретный адрес в памяти, например на адрес цели перехода, функции или глобальной переменной.
Рассмотрим в качестве примера следующую ассемблерную программу:
Эта программа начинает с занесения значений в два регистра, а затем выполняет ветвление, то есть переход, к метке mylabel, чтобы исполнить инструкцию ADD. После исполнения ADD программа переходит к метке result, выполняет инструкцию перемещения и завершается переходом к метке _exit. Ассемблер использует эти метки как подсказки для компоновщика, который назначает им относительные адреса в памяти. Поток выполнения программы показан на рис. 1.5.
Рисунок 1.5. Поток выполнения примера ассемблерной программы
Метки полезны не только для ссылок на инструкции, к которым требуется перейти: с их помощью можно также получать содержимое области памяти. Например, следующий фрагмент ассемблерного кода использует метки, чтобы получить содержимое области памяти или перейти к другим инструкциям в коде:
Инструкция ADR загружает адрес переменной myvalue в регистр R2, а инструкция LDR загружает содержимое по этому адресу в регистр R3. Затем программа переходит к инструкции, на которую ссылается метка mylabel, выполняет инструкцию ADD и переходит к инструкции, на которую ссылается метка result, как показано на рис. 1.6.
Рисунок 1.6. Иллюстрация логики инструкций ADR и LDR
В качестве несколько более интересного примера ниже приведён ассемблерный код, который выводит в консоль Hello World!, а затем завершается. В нём метка используется для обращения к строке hello: инструкция ADR помещает относительный адрес её метки mystring в регистр R1.
После ассемблирования и компоновки этой программы на процессоре, который поддерживает архитектуру Arm и используемый нами набор инструкций, при выполнении она выводит Hello.
Современные ассемблеры часто входят в наборы инструментов компилятора и предназначены для создания файлов, которые можно объединять в более крупные исполняемые программы. Поэтому ассемблерные программы обычно не просто преобразуют ассемблерные инструкции непосредственно в машинный код, а создают объектный файл, содержащий ассемблерные инструкции, сведения о символах и подсказки для программы-компоновщика, входящей в компилятор. В конечном счёте именно компоновщик отвечает за создание полных исполняемых файлов, предназначенных для запуска в современных операционных системах.
Что произойдёт, если запустить нашу программу Arm на процессоре с другой архитектурой? Попытка выполнить программу myasm2 на процессоре Intel x86-64 приведёт к ошибке, сообщающей, что двоичный файл невозможно выполнить из-за ошибки формата исполняемого файла.
Мы не можем запустить двоичный файл Arm на машине x64, потому что на этих двух платформах инструкции кодируются по-разному. Даже если на разных архитектурах требуется выполнить одну и ту же операцию, язык ассемблера и назначенные машинные коды могут существенно различаться. Допустим, на трёх разных архитектурах процессоров требуется выполнить инструкцию, помещающую десятичное число 1 в первый регистр. Хотя сама операция одна и та же, кодировка инструкции и язык ассемблера зависят от архитектуры. Рассмотрим в качестве примера три общих типа архитектуры.
Armv8-A: 64-битный набор инструкций (AArch64)
Armv8-A: 32-битный набор инструкций (AArch32)
Набор инструкций Intel x86-64
Различается не только синтаксис: соответствующие байты машинного кода также существенно различаются в разных наборах инструкций. Это означает, что байты машинного кода, ассемблированные для 32-битного набора инструкций Arm, имеют совершенно иной смысл на архитектуре с другим набором инструкций (например, x64 или A64).
Обратное тоже верно. Одна и та же последовательность байтов может совершенно по-разному интерпретироваться разными процессорами. Например:
Armv8-A: 64-битный набор инструкций (AArch64)
Armv8-A: 32-битный набор инструкций (AArch32)
Иными словами, ассемблерная программа должна быть написана на языке ассемблера той архитектуры, на которой её требуется выполнять, и должна быть ассемблирована ассемблером, поддерживающим соответствующий набор инструкций.
Однако, вопреки возможным ожиданиям, двоичные файлы Arm можно создавать без машины Arm. Разумеется, сам ассемблер должен понимать синтаксис Arm, но если он скомпилирован для x64, то его запуск на машине x64 позволит создавать двоичные файлы Arm. Такая программа называется кросс-ассемблером и позволяет ассемблировать код для целевой архитектуры, отличной от архитектуры машины, на которой вы сейчас работаете.
Например, на машине x86-64 с Ubuntu можно загрузить ассемблер для AArch32 и ассемблировать код с его помощью.
С помощью команды Linux file можно увидеть, что мы создали 32-битный исполняемый файл ARM.
Почему же язык ассемблера не стал господствующим языком программирования для разработки программного обеспечения? Одна из главных причин заключается в том, что язык ассемблера непереносим. Представьте, что вам пришлось бы переписывать всю кодовую базу приложения для каждой архитектуры процессора, которую вы хотите поддерживать! Это огромная работа. Вместо этого появились более новые языки, абстрагирующиеся от подобных особенностей конкретного процессора и позволяющие легко компилировать одну и ту же программу для нескольких разных архитектур. Их часто называют языками более высокого уровня, противопоставляя низкоуровневому языку ассемблера, который ближе к аппаратному обеспечению и архитектуре конкретного компьютера.
При этом понятие "высокий уровень" по своей сути относительно. Изначально C и C++ считались языками высокого уровня, а ассемблер - языком низкого уровня. После появления более новых и абстрактных языков, таких как Visual Basic или Python, C/C++ нередко называют низкоуровневыми. В конечном счёте всё зависит от точки зрения и от того, кого вы спросите.
Как и язык ассемблера, исходный код высокого уровня процессоры непосредственно не понимают. Программистам необходимо преобразовывать программы высокого уровня в машинный код с помощью компилятора. Как и прежде, нужно указать архитектуру, на которой будет выполняться двоичный файл; и, как и прежде, двоичные файлы Arm можно создавать в системах без Arm, воспользовавшись кросс-компилятором.
Результатом работы компилятора обычно является исполняемый файл, который можно запустить в конкретной операционной системе. Как правило, заказчикам распространяют именно такие двоичные исполняемые файлы, а не исходный код программы. Поэтому, когда требуется проанализировать программу, в нашем распоряжении часто имеется лишь сам скомпилированный исполняемый файл.
К несчастью для специалистов по обратной разработке, обратить процесс компиляции и восстановить первоначальный исходный код обычно невозможно. Компиляторы не только представляют собой чудовищно сложные программы со множеством уровней итераций и абстракций, разделяющих первоначальный исходный код и получившийся двоичный файл, но и на многих этапах этого процесса отбрасывают понятные человеку сведения, которые помогают программистам осмысливать программу.
Если исходного кода анализируемой программы нет, то в зависимости от необходимой степени подробности анализа у нас есть два основных варианта: декомпилировать или дизассемблировать исполняемый файл.
Дизассемблирование двоичного файла включает восстановление выполняемых им ассемблерных инструкций: машинный код преобразуется в понятный человеку язык ассемблера. Чаще всего дизассемблирование используют для анализа вредоносных программ, проверки производительности компилятора и правильности его выходных данных, а также для анализа уязвимостей и разработки эксплойтов либо демонстрационных примеров, использующих дефекты программного обеспечения с закрытым исходным кодом.
Из перечисленных задач именно разработка эксплойтов, вероятно, больше всего зависит от анализа фактического ассемблерного кода. Уязвимости нередко удаётся обнаруживать такими методами, как фаззинг, однако создание эксплойтов на основе выявленных сбоев или выяснение причин, по которым фаззеры не достигают определённых участков кода, часто требует глубокого знания ассемблера.
В таких случаях критически важно посредством чтения ассемблерного кода досконально понять точные условия возникновения уязвимости. Конкретные решения компилятора о размещении переменных и структур данных зачастую имеют решающее значение для разработки эксплойтов, и именно здесь по-настоящему необходимы глубокие знания ассемблера. Нередко уязвимость, которая кажется "непригодной для эксплуатации", в действительности удаётся эксплуатировать, если проявить немного изобретательности и усердно разобраться во внутренних механизмах работы уязвимой функции.
Дизассемблировать исполняемый файл можно несколькими способами; подробнее мы рассмотрим их во второй части книги. Пока же отметим, что одним из простейших инструментов для быстрого просмотра дизассемблированного представления исполняемого файла является утилита Linux objdump[3].
Скомпилируем и дизассемблируем следующую программу, использующую write():
Этот код можно скомпилировать с помощью GCC, указав параметр -c. Он предписывает GCC создать объектный файл, не запуская процесс компоновки, чтобы затем мы могли применить objdump только к нашему скомпилированному коду и не видеть дизассемблированное представление всех окружающих объектных файлов, например среды выполнения C. Дизассемблированное представление функции main выглядит следующим образом:
Утилиты Linux наподобие objdump удобны для быстрого дизассемблирования небольших программ, но для крупных программ требуется более подходящее решение. Существуют различные дизассемблеры, повышающие эффективность обратной разработки: от бесплатных инструментов с открытым исходным кодом, таких как Ghidra[4], до дорогостоящих решений вроде IDA Pro[5]. Подробнее они будут рассмотрены во второй части книги.
Сравнительно новым достижением в обратной разработке стало применение декомпиляторов. Декомпиляторы идут на шаг дальше дизассемблеров. Если дизассемблеры просто показывают понятный человеку ассемблерный код программы, то декомпиляторы пытаются восстановить по скомпилированному двоичному файлу эквивалентный код на C/C++.
Одно из достоинств декомпиляторов состоит в том, что они создают псевдокод, значительно сокращая и упрощая дизассемблированное представление. Благодаря этому при беглом просмотре функции легче в общих чертах понять, что делает программа.
Обратная сторона, разумеется, заключается в том, что при таком преобразовании могут потеряться важные подробности. Кроме того, поскольку преобразование исходного кода в исполняемый файл, выполняемое компилятором, по своей природе сопровождается потерями, декомпиляторы не могут полностью восстановить первоначальный исходный код. В процессе компиляции безвозвратно уничтожаются имена символов, локальные переменные, комментарии и значительная часть структуры программы. Аналогично, попытки автоматически присвоить имена либо новые метки локальным переменным и параметрам могут вводить в заблуждение, если компилятор с агрессивной оптимизацией повторно использует одни и те же области хранения.
Рассмотрим пример функции на C, скомпилируем её с помощью GCC, а затем декомпилируем декомпиляторами IDA Pro и Ghidra, чтобы увидеть практический результат.
На рис. 1.7 показана функция file_record из файла ihex2fw.c[6], находящегося в репозитории исходного кода Linux.
Рисунок 1.7. Исходный код функции file_record в исходном файле ihex2fw.c
После компиляции файла C для архитектуры Armv8-A (без каких-либо специальных параметров компилятора) и загрузки исполняемого файла в IDA Pro 7.6 декомпилятор создал для предыдущей функции псевдокод, показанный на рис. 1.8.
Рисунок 1.8. Результат декомпиляции скомпилированной функции file_record в IDA 7.6
На рис. 1.9 показана та же функция, декомпилированная в Ghidra 10.0.4.
В обоих случаях, если хорошенько прищуриться, в полученном тексте можно отчасти различить призрак исходного кода, однако этот код гораздо менее читабелен и значительно менее понятен, чем оригинал. Иными словами, хотя декомпиляторы во многих случаях действительно позволяют быстро получить общее высокоуровневое представление о программе, они вовсе не панацея и не заменяют умения погрузиться в ассемблерный код конкретной программы.
Рисунок 1.9. Результат декомпиляции скомпилированной функции file_record в Ghidra 10.0.4
Вместе с тем декомпиляторы постоянно развиваются и всё лучше восстанавливают исходный код, особенно для простых функций. Результаты декомпиляции полезны как вспомогательное средство при высокоуровневом анализе функций, которые вы хотите подвергнуть обратной разработке, но, пытаясь глубже понять происходящее, не забывайте заглядывать и в дизассемблированное представление.
[1] [назад]
[2] [назад] ftp.gnu.org
[3] [назад] web.mit.edu
[5] [назад] hex-rays.com
Эта глава служит справочным материалом для понимания основ процесса компиляции и внутреннего устройства формата файлов ELF. Если вы уже знакомы с этими понятиями, то можете пропустить главу и обращаться к ней как к справочнику за подробностями, которые понадобятся во время анализа.
Прежде чем погружаться в ассемблерные инструкции и способы обратной разработки двоичных файлов программ, стоит прежде всего посмотреть, откуда берутся эти двоичные файлы.
Программы начинаются с исходного кода, написанного разработчиками программного обеспечения. Исходный код описывает компьютеру, как должна вести себя программа и какие вычисления она должна выполнять при различных входных условиях.
Выбор языка программирования, которым пользуется программист, в значительной степени определяется его предпочтениями. Одни языки хорошо подходят для математических задач и машинного обучения. Другие оптимизированы для разработки веб-сайтов или создания приложений для смартфонов. Третьи, например C и C++, достаточно гибки для широкого круга приложений: от низкоуровневого системного программного обеспечения, такого как драйверы устройств и микропрограммы, через системные службы и вплоть до крупных приложений вроде видеоигр, веб-браузеров и операционных систем. Поэтому многие программы, с которыми мы сталкиваемся при анализе двоичных файлов, начинают свою жизнь в виде кода на C/C++.
Компьютеры не выполняют файлы исходного кода непосредственно. Прежде чем программу можно будет запустить, её необходимо преобразовать в машинные инструкции, которые умеет выполнять процессор. Программы, осуществляющие такое преобразование, называются компиляторами. В Linux широко используется набор компиляторов GCC, включающий компилятор C, который преобразует код C в двоичные файлы ELF, непосредственно загружаемые и выполняемые Linux. Его аналогом для компиляции кода C++ служит G++. Общая схема компиляции показана на рис. 2.1.
Рисунок 2.1. Общая схема компиляции
В некотором смысле обратная разработка выполняет задачу, противоположную задаче компилятора. При обратной разработке мы начинаем с двоичного файла программы и движемся в обратном направлении, пытаясь на более высоком уровне восстановить замысел программиста относительно поведения программы. Поэтому полезно понимать составные части формата файлов ELF и их назначение.
C и C++ часто называют языками высокого уровня, поскольку они позволяют программисту определять структуру и поведение программы, не обращаясь непосредственно к самой машинной архитектуре. Программист может писать код на C/C++ в терминах абстрактных понятий программирования, таких как блоки if-else, циклы while и локальные переменные с заданными программистом именами, не задумываясь о том, как в конечном коде эти переменные будут сопоставлены машинным регистрам, областям памяти или конкретным машинным инструкциям.
Такая абстракция обычно приносит программистам большую пользу. Благодаря программистским абстракциям и высокоуровневым понятиям потока выполнения писать программы на C/C++ зачастую гораздо быстрее и безопаснее с точки зрения ошибок, чем создавать эквивалентные программы непосредственно на ассемблере. Кроме того, поскольку C и C++ не привязаны жёстко к конкретной машинной архитектуре, один и тот же код на C/C++ можно компилировать для выполнения на нескольких разных целевых процессорах.
Язык программирования C++ отличается от C добавлением множества новых синтаксических конструкций, средств программирования и высокоуровневых абстракций, которые упрощают и ускоряют создание крупных программ. Например, C++ добавляет непосредственную поддержку объектно-ориентированного программирования на уровне языка и делает конструкторы, деструкторы и создание объектов непосредственной частью самого языка. C++ также вводит такие программные абстракции, как интерфейсы, исключения C++ и перегрузка операторов, а кроме того, обеспечивает дополнительную проверку правильности программы во время компиляции благодаря более строгой системе проверки типов и поддержке шаблонов, недоступным в первоначальном языке программирования C.
По соглашению основная логика программ на C и C++ начинается в функции main. Обычно эта функция обрабатывает аргументы командной строки программы, подготавливает программу к выполнению, а затем приступает к исполнению самой основной логики. Для программ командной строки это может означать обработку файлов и потоков ввода-вывода. Графические программы тоже могут обрабатывать файлы и входные потоки, но зачастую они также создают окна, выводят на экран графику, с которой взаимодействует пользователь, и настраивают обработчики событий, реагирующие на пользовательский ввод.
Вместо языков высокого уровня, таких как C и C++, программисты могут выбрать для написания кода низкоуровневый "язык ассемблера". Такие языки ассемблера тесно связаны с целевым процессором, для которого они предназначены, но предоставляют программистам гораздо больше свободы в точном определении машинных инструкций, которые должен выполнить процессор, и порядка их выполнения.
Помимо личных предпочтений существует множество причин, по которым программист может решить написать всю программу или отдельные её части на языке низкого уровня. В табл. 2.1 приведено несколько вариантов применения низкоуровневых языков.
Таблица 2.1. Варианты применения программирования на ассемблере
Прежде чем рассматривать ассемблирование языков низкого уровня, сначала посмотрим, как компиляторы преобразуют программы, написанные на языках высокого уровня вроде C/C++, в низкоуровневый ассемблерный код.
Основная задача компилятора - преобразовать программу, написанную на языке высокого уровня, таком как C/C++, в эквивалентную программу на языке низкого уровня, например на языке набора инструкций A64, входящего в архитектуру Armv8-A[1]. Начнём с простой программы на C.
В Linux часто применяется компилятор C из набора GNU Compiler Collection, GCC. По умолчанию GCC не просто компилирует программу на C в ассемблерный код:
он управляет всем процессом компиляции, ассемблирует и компонует полученный результат и создаёт окончательный двоичный файл программы ELF, который операционная система может выполнить непосредственно. Чтобы создать из исходного кода двоичный файл программы с помощью GCC, можно воспользоваться следующей командой:
Можно также указать драйверу компилятора GCC вывести подробные сведения о том, что происходит за кулисами, передав параметр -v:
Эта команда выдаёт большой объём данных, но ближе к концу вывода можно увидеть, что на завершающем этапе процесса GCC вызывает ассемблер для ассемблерного файла, записанного во временную область, например:
Это объясняется тем, что GCC является набором компиляторов. Собственно компилятор C преобразует код C в ассемблерный листинг, который передаётся ассемблеру для преобразования в объектный файл и последующей компоновки в целевой двоичный файл.
С помощью параметра командной строки -S, например вызвав gcc main.c -S, можно перехватить этот ассемблерный листинг и посмотреть, что создаёт сам компилятор. В таком случае GCC скомпилирует программу из main.c в ассемблерный листинг и запишет его в файл main.s.
Поскольку C++ по большей части является надмножеством языка C, этот же пример можно скомпилировать так, будто он написан на C++. Для этого воспользуемся компилятором C++ g++ и следующей командой, создающей целевой двоичный файл:
С помощью параметра командной строки -S, то есть команды g++ main.cpp -S, можно также предписать g++ вывести ассемблерный листинг.
Если позволить GCC завершить работу, в конце концов он создаст исполняемый файл ELF, который можно запустить непосредственно из командной строки. Например, программу можно запустить с двумя параметрами командной строки Arm-devs и reverse-engineers, после чего она выведет в консоль следующий результат:
Одно из главных преимуществ написания программы на языке высокого уровня, таком как C/C++, состоит в том, что по умолчанию исходный код не привязан жёстко к конкретной архитектуре процессора.
Благодаря этому один и тот же исходный код программы можно компилировать для выполнения на разных целевых платформах. В конфигурации по умолчанию GCC и G++ создают целевые двоичные файлы, рассчитанные на ту же машинную архитектуру, на которой производится компиляция. Например, если выполнить gcc main.c -o example.so на 64-битной машине Arm с Linux, полученный двоичный файл example.so будет файлом ELF, предназначенным для работы на 64-битных машинах Arm. Если выполнить ту же команду на машине x86_64 с Linux, полученный двоичный файл будет предназначен для машин x86_64.
Архитектуру, для которой скомпилирован двоичный файл ELF, можно определить, в частности, командой file:
Обычно создание двоичного файла программы, соответствующего используемой системе, - полезная возможность: как правило, мы хотим, чтобы компилятор создавал двоичные файлы, которые можно немедленно запускать на машине разработки. Но что делать, если архитектура машины разработки отличается от архитектуры целевой машины? Например, если машина разработки основана на x86_64, а требуется создать целевой двоичный файл для 64-битного процессора Arm? В таких случаях необходимо воспользоваться кросс-компилятором.
В табл. 2.2 перечислены наиболее распространённые кросс-компиляторы Arm из состава GCC и G++, предназначенные для создания двоичных файлов, которые могут выполняться на 32- и 64-битных машинах Arm с Linux.
Таблица 2.2. Кросс-компиляторы GCC
В системах, где основным диспетчером пакетов служит apt-get, эти кросс-компиляторы Arm можно установить следующей командой:
После установки этих кросс-компиляторов можно создавать 32- и 64-битные двоичные файлы Arm непосредственно на машине разработки с другой архитектурой. Для этого gcc заменяется вариантом, предназначенным для требуемой цели. Например, на машине x86_64 можно создать 64-битный двоичный файл Arm из кода на C или C++ следующим образом:
Целевые двоичные файлы для 32-битных систем Arm можно создавать почти так же, только с помощью 32-битных кросс-компиляторов Arm:
Если проверить эти выходные двоичные файлы командой file, можно увидеть, что они скомпилированы соответственно для 64- и 32-битной архитектуры Arm.
Компиляторы и программисты, пишущие ассемблерный код вручную, создают ассемблерные листинги, которые поступают на вход ассемблера. Задача ассемблера - преобразовать понятные человеку описания машинных инструкций в эквивалентные инструкции с двоичной кодировкой, а также вывести данные и метаданные программы в другие разделы её двоичного файла в соответствии с указаниями, вручную заданными программистом или компилятором. Результатом работы ассемблера является объектный файл. Объектные файлы кодируются как файлы ELF, хотя, возможно, правильнее считать их частичными файлами ELF: в ходе завершающей компоновки их необходимо объединить в единое целое, чтобы создать окончательный исполняемый целевой двоичный файл.
По соглашению ассемблерный код записывается в файлах .s. Эти файлы можно ассемблировать в объектный файл с помощью ассемблера, например GNU Assembler (GAS), входящего в набор инструментов GCC/G++.
В последующих главах книги мы познакомимся с инструкциями, доступными в архитектуре Armv8-A, и разберёмся в их работе. Пока же полезно определить пару шаблонных ассемблерных программ, которыми вы сможете пользоваться для самостоятельного создания простых программ на ассемблере.
Следующая простая ассемблерная программа использует системный вызов write() для вывода строки, после чего завершается. Первые три строки определяют архитектуру, раздел и глобальную точку входа программы. Функция write() принимает три аргумента: файловый дескриптор, указатель на буфер, где хранятся данные (например, строка), и количество байтов, которые требуется записать из буфера. Эти аргументы задаются в первых трёх регистрах: x0, x1 и x2. Регистр x8 должен содержать номер системного вызова write, а инструкция SVC вызывает его. Строку ASCII можно разместить в конце раздела .text (в так называемом пуле литералов) либо в разделе .data или rodata.
Шаблон программы на ассемблере A64 write64.s
Того же результата можно добиться с помощью библиотечных функций. Обе следующие программы выполняют одну и ту же основную задачу: одна предназначена для 64-битной, а другая - для 32-битной архитектуры Arm. Обе определяют функцию _start в разделе .text полученного файла ELF и помещают строку Hello world\n с нулём в конце в раздел .rodata (данные только для чтения) полученного двоичного файла. В обоих случаях функция main загружает адрес этой строки в регистр, вызывает printf, чтобы вывести строку в консоль, а затем вызывает exit(0) для завершения программы.
Шаблон программы на ассемблере A64 print64.s
Шаблон программы на ассемблере A32 print32.s
Если архитектура машины разработки совпадает с архитектурой, для которой выполняется компиляция, эти программы можно ассемблировать непосредственно с помощью AS:
Если архитектура машины разработки не совпадает с целевой, вместо этого можно воспользоваться версиями AS из состава кросс-компиляторов GCC.
Попытка выполнить объектный файл непосредственно обычно заканчивается неудачей. Сначала двоичный файл необходимо скомпоновать. В наборе GCC двоичный файл компоновщика называется ld (либо, в зависимости от обстоятельств, aarch64-linux-gnu-ld или arm-linux-gnueabihf-ld). Компоновщику нужно передать все объектные файлы, необходимые для создания полного двоичного файла программы, а затем указать его выходной файл параметром -o.
Для программы write64.s требуется только один объектный файл с именем write64.o, никаких дополнительных библиотек указывать не нужно, и полученную программу можно запустить непосредственно.
Если ассемблерная программа использует определённые библиотечные функции, а не обращается непосредственно к системным вызовам, необходимо включить требуемые объектные файлы.
В примере printf64.s мы указываем print64.o в качестве входного объектного файла, однако, прежде чем программу удастся запустить, потребуется добавить ещё несколько объектных файлов. Один из них - libc.so, предоставляющий программе доступ к библиотечным функциям libc printf и exit. Кроме того, нужны три объектных файла, которые вместе образуют среду выполнения C, необходимую для начальной загрузки процесса перед вызовом нашей функции main. Требуемые объектные зависимости описаны в табл. 2.3.
Таблица 2.3. Требуемые объектные файлы и их назначение
Таким образом, окончательная команда компоновщика имеет следующий вид:
Полученный целевой двоичный файл print64.so после этого можно запустить на 64-битной машине Arm.
Окончательным результатом компиляции и компоновки является файл в формате исполняемых и компонуемых файлов (Executable and Linkable Format, ELF), содержащий всю информацию, необходимую операционной системе и загрузчику для загрузки и запуска программы. На самом абстрактном уровне файл ELF можно представить как совокупность таблиц, описывающих программу и способ её запуска. В формате ELF существует три типа таблиц: заголовок файла ELF, расположенный в начале файла, а также заголовки программы и заголовки разделов, описывающие соответственно загрузку программы ELF в память и логические разделы файла ELF, по которым загрузчик определяет порядок её подготовки к выполнению.
В начале файла ELF находится заголовок файла ELF. Заголовок ELF описывает глобальные атрибуты программы, в том числе архитектуру, для выполнения на которой она предназначена, точку входа программы, а также указатели на другие таблицы файла и их размеры.
Атрибуты и разделы файла ELF, например собранных и скомпонованных нами ранее в разделе "Ассемблирование и компоновка" программ print32.so и print64.so, можно просмотреть с помощью такой программы, как readelf. Для просмотра заголовка файла ELF служит параметр -h программы readelf:
Поля заголовка файла ELF делятся на четыре основные группы: сведения заголовка файла ELF, сведения о целевой платформе программы, поле точки входа программы и поля расположения таблиц.
Первая из этих групп сообщает загрузчику тип файла ELF и начинается с поля магического значения. Поле магического значения представляет собой постоянную 16-байтовую двоичную комбинацию, называемую идентификационной комбинацией (0x7f, а за ним - 3 байта, соответствующие символам ASCII ELF.
Поле класса сообщает загрузчику, какой формат используется самим файлом ELF: 32- или 64-битный. Обычно 32-битные программы используют 32-битный формат, а 64-битные - 64-битный. В нашем примере видно, что это справедливо и для программ Arm: 32-битный двоичный файл Arm использует 32-битный формат ELF, а 64-битный - 64-битный формат.
Поле данных сообщает загрузчику, в каком порядке следует читать собственные поля файла ELF: от старшего к младшему или от младшего к старшему. Файлы ELF для Arm обычно используют кодирование самого формата ELF с порядком от младшего к старшему. Далее в книге мы увидим, как работает порядок байтов и каким образом процессор иногда может динамически переключаться между режимами от младшего к старшему и от старшего к младшему. Пока достаточно знать, что это поле изменяет лишь способ чтения структур файла ELF операционной системой и загрузчиком; на поведение процессора во время выполнения программы оно не влияет.
Наконец, поле версии сообщает загрузчику, что используется версия 1 формата файлов ELF. Это поле предназначено для обеспечения будущей совместимости формата ELF.
Следующая группа полей сообщает загрузчику тип машины, для выполнения на которой предназначен файл ELF.
Поле машины сообщает загрузчику класс процессора, для выполнения на котором предназначена программа. В нашей 64-битной программе это поле имеет значение AArch64, указывающее, что файл ELF будет выполняться только на 64-битных процессорах Arm. В 32-битной программе указано значение ARM, поэтому она может выполняться только на 32-битных процессорах Arm либо как 32-битный процесс на 64-битной машине с Linux, использующей 32-битное состояние выполнения процессора AArch32.
Поле флагов содержит дополнительные сведения, которые могут потребоваться загрузчику. Это поле зависит от архитектуры. Например, для нашей 64-битной программы флаги, относящиеся к архитектуре, не определены, поэтому данное поле всегда содержит нулевое значение. Напротив, в 32-битной программе Arm это поле сообщает загрузчику, что программа скомпилирована с применением встроенного профиля ABI (embedded ABI, EABI) версии 5 и рассчитывает на аппаратную поддержку операций с плавающей точкой. Спецификация Arm определяет четыре относящихся к Arm значения, которые можно помещать в поле e_flags заголовка программы ELF[2][3], как показано в табл. 2.4.
Таблица 2.4. Значения 32-битного поля Arm e_flags
Наконец, поле типа указывает назначение файла ELF. В данном случае оно показывает, что эти программы являются динамически скомпонованными двоичными файлами, которые системный загрузчик может подготовить и затем выполнить.
Поле точки входа в заголовке ELF сообщает загрузчику, где находится точка входа программы. После того как операционная система или загрузчик подготовит программу в памяти и она будет готова к выполнению, это поле указывает начальную позицию.
Хотя по соглашению программы на C и C++ "начинаются" с функции main, фактически их выполнение начинается не здесь. Оно начинается с небольшой заглушки ассемблерного кода, традиционно обозначаемой символом _start. При компоновке со стандартной средой выполнения C функция _start обычно представляет собой небольшую заглушку кода, которая передаёт управление вспомогательной функции libc __libc_start_main. Затем эта функция подготавливает параметры для функции main программы и вызывает её. Функция main выполняет основную логику программы; если main возвращает управление в __libc_start_main, то возвращённое main значение передаётся функции exit, чтобы корректно завершить программу.
Остальные поля заголовка ELF обычно не представляют интереса для аналитиков двоичных файлов - если только вы не хотите написать код, который будет разбирать файлы ELF вручную. Они описывают загрузчику расположение и количество заголовков программы и разделов в файле, а также предоставляют указатели на специальные разделы, содержащие таблицу строк и таблицу символов, которые мы опишем позднее. С помощью этих полей загрузчик подготавливает файл ELF в памяти к выполнению.
В сущности, таблица заголовков программы описывает загрузчику способ эффективной загрузки двоичного файла ELF в память.
Заголовки программы отличаются от заголовков разделов тем, что, хотя и те и другие описывают компоновку программы, заголовки программы делают это с точки зрения отображения, тогда как заголовки разделов описывают более мелкие логические единицы. Заголовки программы определяют последовательность сегментов, каждый из которых сообщает ядру, как первоначально запустить программу. Эти сегменты указывают, как и куда загрузить данные файла ELF в память, требуется ли программе загрузчик времени выполнения для начальной загрузки, как должна выглядеть первоначальная компоновка локального хранилища потока для основного потока, а также другие метаданные, важные для ядра, например следует ли предоставить программе исполняемые стеки потоков.
Сначала просмотрим заголовки программы нашей 64-битной программы print64.so с помощью команды readelf.
У этой программы девять заголовков программы, каждый из которых имеет связанный с ним тип, например PHDR или INTERP, определяющий способ интерпретации заголовка. В перечне соответствий между разделами и сегментами показано, какие логические разделы находятся внутри каждого сегмента. Например, здесь видно, что сегмент INTERP содержит только раздел .interp.
PHDR (Program HeaDeR, заголовок программы) - это метасегмент, содержащий сами таблицы заголовков программы и метаданные.
Заголовок INTERP сообщает операционной системе, что файлу ELF для загрузки в память требуется помощь другой программы. Почти всегда такой программой является файл загрузчика операционной системы; в данном случае он находится по пути /lib/ld-linux-aarch64.so.1.
При выполнении программы операционная система использует этот заголовок, чтобы загрузить вспомогательный загрузчик в память, и назначает первоначальным объектом выполнения именно загрузчик, а не саму программу. Внешний загрузчик необходим, если программа использует динамически компонуемые библиотеки. Он управляет глобальной таблицей символов программы, соединяет двоичные файлы в ходе процесса, называемого перемещением, а затем, когда всё готово, наконец вызывает точку входа программы.
Поскольку это справедливо почти для всех нетривиальных программ, кроме самого загрузчика, практически все программы используют данное поле для указания системного загрузчика. Заголовок INTERP имеет значение только для собственно файлов программ; для разделяемых библиотек, загружаемых либо при первоначальной загрузке программы, либо динамически во время её выполнения, это значение игнорируется.
Заголовки LOAD сообщают операционной системе и загрузчику, как можно эффективнее поместить данные программы в память. Каждый заголовок LOAD предписывает загрузчику создать область памяти заданного размера, с заданными разрешениями доступа и требованиями к выравниванию, а также указывает, какие байты файла следует поместить в эту область.
Если снова взглянуть на заголовки LOAD из предыдущего примера, можно увидеть, что программа определяет две области памяти, которые должны быть заполнены данными из файла ELF.
Первая из этих областей имеет длину 0xa3c байта, должна быть выровнена по границе 64 Кбайт и отображена с разрешениями на чтение и выполнение, но не на запись. Эту область следует заполнить байтами с 0 по 0xa3c самого файла ELF.
Вторая область имеет длину 0x290 байт, должна быть загружена в позицию, расположенную на 0x10db8 байта после первого раздела, и помечена как доступная для чтения и записи. Она будет заполнена 0x288 байтами, начинающимися со смещения 0xdb8 в файле.
Стоит отметить, что заголовки LOAD не обязательно заполняют байтами файла всю определяемую ими область. Например, второй заголовок LOAD заполняет только первые 0x288 байт области размером 0x290. Оставшиеся байты заполняются нулями. В данном случае последние 8 байт соответствуют разделу .bss двоичного файла; компилятор применяет такую стратегию загрузки, чтобы заранее обнулить этот раздел в ходе загрузки.
Главное назначение сегментов LOAD - помочь операционной системе и загрузчику эффективно перенести данные из файла ELF в память; логическим разделам двоичного файла они соответствуют лишь приблизительно. Например, если ещё раз взглянуть на предыдущий вывод readelf, можно увидеть, что первый из двух заголовков LOAD загрузит данные, соответствующие 17 логическим разделам файла ELF, включая данные только для чтения и код программы. Второй заголовок LOAD предписывает загрузчику загрузить остальные 7 разделов, в том числе разделы, отвечающие за глобальную таблицу смещений, а также разделы .data и .bss:
Заголовок программы DYNAMIC используется загрузчиком для динамической компоновки программ с разделяемыми библиотеками, от которых они зависят, а также для применения к программе перемещений, исправляющих код программы и указатели, если программа загружена по адресу, отличному от ожидаемого. Динамический раздел, а также процессы компоновки и перемещения мы рассмотрим далее в этой главе.
Заголовок программы NOTE применяется для хранения относящихся к поставщику метаданных о самой программе. По существу, этот раздел описывает таблицу пар "ключ-значение", где каждой записи с текстовым именем сопоставлена последовательность байтов, описывающая эту запись[5]. Перечень общеизвестных значений NOTE и их смысл приведены на странице руководства ELF[6].
С помощью readelf можно также просмотреть понятное человеку описание записей NOTE в заданном файле ELF. Например, для файла print64.so это можно сделать следующим образом:
Здесь видно, что записи NOTE нашего исполняемого файла описывают версию GNU ABI, которую рассчитывает использовать программа (в данном случае Linux ABI 3.7.0), и уникальное значение идентификатора сборки, присвоенное двоичному файлу. Обычно оно применяется для сопоставления дампов сбоев с вызвавшими их двоичными файлами при диагностике и первичном анализе сбоев[7].
Хотя наша программа не использует этот заголовок, ещё одним распространённым заголовком программы является заголовок TLS. Он определяет таблицу записей TLS, в которых хранятся сведения о локальных переменных потоков, используемых программой[8]. Локальное хранилище потока - более сложная тема, затрагивающая несколько разделов; компоновку этой таблицы мы обсудим далее в этой главе, в разделе "Локальное хранилище потока".
Этот заголовок определяет расположение в памяти таблиц раскрутки стека программы. Таблицы раскрутки стека используются как отладчиками, так и функциями среды выполнения для обработки исключений C++, которые внутренне применяются процедурами, отвечающими за обработку ключевого слова C++ throw. Эти процедуры также обрабатывают конструкции try..catch..finally, чтобы раскручивать стек, сохраняя при этом семантику автоматических деструкторов C++ и обработки исключений.
Исторически процессоры не предоставляли защиту памяти от выполнения, с помощью которой можно было бы запретить исполнение инструкций программы внутри определённых областей памяти. Поэтому код можно было записать в стек и выполнить непосредственно оттуда. На практике легитимные программы почти никогда так не поступали. Зато злоумышленники часто использовали дефекты повреждения памяти в программе, выполняя специально подготовленные инструкции непосредственно из исполняемых областей стека.
С появлением разрешения памяти "без выполнения" (no-execute, NX), поддерживаемого как 32-, так и 64-битными процессорами Arm, а также процессорами других производителей, стек стало возможно явно помечать как область без выполнения, блокируя атаки такого рода. В терминологии Arm этим средством защиты управляет бит Execute Never (XN). Если он включён (равен 1), попытка выполнить инструкции в такой неисполняемой области приводит к ошибке разрешения доступа[9].
К сожалению, проблема для Linux заключалась в том, что, хотя легитимных программ, записывавших исполняемые инструкции в стек для последующего выполнения, было очень мало, их количество всё же не равнялось нулю. Это создавало проблему совместимости приложений. Операционная система не могла по умолчанию принудительно включить для стека NX, не нарушив работу небольшого количества программ, которым требовался исполняемый стек.
Решением стал заголовок программы GNU_STACK. Содержимое самого заголовка GNU_STACK игнорируется, однако его поле защиты памяти используется для определения видов защиты, предоставляемых стекам потоков программы. Благодаря этому большинство программ, которые никогда не выполняют код из стека потока, могут сообщить операционной системе, что стеки потоков программы можно безопасно пометить как неисполняемые[10][11].
За создание заголовка GNU_STACK отвечает компоновщик LD. Поэтому при компиляции программы с помощью GCC можно управлять исполняемостью стека параметрами командной строки GCC: -z noexecstack запрещает исполняемые стеки, а -z execstack принудительно выделяет стек как исполняемый.
Чтобы увидеть этот механизм в действии, можно повторно скомпилировать программу с намеренно исполняемым стеком, а затем просмотреть заголовок GNU_STACK с помощью readelf:
Последствия такого поведения во время выполнения можно увидеть для работающих в данный момент программ, просмотрев карту памяти процесса. С предыдущими примерами это несколько затруднительно, поскольку они завершаются очень скоро после запуска. Вместо них можно воспользоваться следующей двухстрочной программой, которая просто спит вечно, чтобы мы могли изучить её память во время выполнения, не прибегая к отладчику:
Если скомпилировать эту программу с параметром -z execstack, то при её запуске стек должен быть помечен как исполняемый. Сначала скомпилируем программу.
Затем запустим программу в другом окне терминала командой ./execstack.so, а ещё в одном окне терминала найдём идентификатор её процесса. Один из простых способов сделать это - команда pidof.
Теперь, зная идентификатор выполняющегося процесса, можно просмотреть его карту памяти через псевдофайл /proc/pid/maps, в данном случае /proc/7784/maps. Ниже приведено содержимое этого файла (для удобства чтения строки немного сокращены):
Здесь видно, что стек помечен разрешениями rwx, то есть является исполняемым. Если повторить предыдущие действия без параметра компилятора -z execstack, то стек, напротив, окажется помечен как rw-, то есть будет неисполняемым, как показано в следующей строке:
Изучить память программ с коротким временем жизни несколько сложнее. В подобных случаях следует воспользоваться отладчиком, например GDB, и командой info proc mappings, чтобы просмотреть память процесса во время его выполнения.
Как и GNU_STACK, заголовок программы GNU_RELRO служит реализуемым компилятором средством защиты от эксплойтов. В общем случае назначение Relocation Read-Only (RELRO) состоит в том, чтобы предписать загрузчику пометить определённые критически важные области двоичного файла программы как доступные только для чтения после загрузки программы, но до начала её выполнения. Это мешает эксплойтам без труда перезаписывать содержащиеся там критические данные. RELRO применяется для защиты глобальной таблицы смещений (Global Offset Table, GOT), а также таблиц init и fini, содержащих указатели на функции, которые программа выполняет соответственно до запуска функции main и во время заключительного вызова exit (либо после возврата из main).
Конкретный механизм заголовка программы RELRO прост. Заголовок определяет область памяти и окончательный вид защиты, который следует применить к ней посредством вызова mprotect, когда программа будет готова к выполнению. Снова просмотрим заголовки программы с помощью readelf и посмотрим, как они соотносятся с заголовком RELRO.
Если посмотреть на соответствие разделов сегментам, видно, что RELRO предписывает загрузчику перед запуском программы пометить разделы двоичного файла .init_array, .fini_array, .dynamic и .got как доступные только для чтения. Тем самым защищаются соответственно инициализаторы программы, деинициализаторы, весь динамический раздел и глобальная таблица смещений. Если бы программа определяла ещё и данные TLS, шаблонные данные TLS в разделе .tdata обычно также защищались бы областью RELRO.
Средство защиты RELRO существует в двух вариантах: частичный RELRO (Partial RELRO) и полный RELRO (Full RELRO)[12]. С помощью показанных в табл. 2.5 параметров командной строки компоновщику можно предписать включить частичный RELRO, включить полный RELRO или вообще отключить RELRO.
Таблица 2.5. Параметры RELRO
Главное различие между частичным и полным RELRO заключается в том, что частичный RELRO не защищает часть глобальной таблицы смещений, отвечающую за управление таблицей компоновки процедур (обычно она называется .plt.got) и используемую для отложенного связывания импортированных символов функций. Полный RELRO принудительно связывает все вызовы библиотечных функций во время загрузки, поэтому может пометить как .got, так и .got.plt как доступные только для чтения. Это предотвращает распространённый способ эксплуатации потока управления, при котором указатели на функции в разделе .got.plt перезаписываются для перенаправления потока выполнения программы. Платой за это становится небольшое снижение быстродействия при запуске крупных программ.
Проверить, включён ли для конкретного двоичного файла программы полный, частичный RELRO или RELRO вообще отсутствует, можно с помощью таких инструментов командной строки, как инструмент с открытым исходным кодом checksec.sh (входит в Fedora)[13], применив следующий синтаксис:
В отличие от заголовков программы, представляющих файл ELF с точки зрения данных и сообщающих операционной системе, как эффективно поместить программу непосредственно в память, заголовки разделов делят двоичный файл ELF на логические единицы. Заголовок программы ELF указывает количество и расположение таблицы заголовков разделов в файле ELF.
Заголовки разделов заданного двоичного файла можно просмотреть с помощью readelf:
Ещё один способ просмотреть эти заголовки с флагами в несколько более удобочитаемом формате - воспользоваться утилитой objdump (для краткости вывод здесь сокращён и показывает только основные разделы).
Как и в случае заголовков программы, каждый заголовок раздела описывает область памяти в загруженном двоичном файле, определяемую адресом и размером области. У каждого заголовка раздела также есть имя, тип и, при необходимости, ряд вспомогательных полей флагов, описывающих способ его интерпретации. Например, раздел .text помечен как код только для чтения, а раздел .data - как данные, которые не являются ни кодом, ни данными только для чтения, поэтому он будет помечен для чтения и записи.
Некоторые из этих разделов однозначно соответствуют эквивалентному заголовку программы, и здесь мы не будем рассматривать их повторно. Например, раздел .interp содержит только данные, используемые заголовком программы INTERP, а разделы NOTE представляют собой две записи из заголовка программы NOTE.
Другие разделы, например .text, .data и .init_array, описывают логическую структуру программы и используются загрузчиком для её инициализации перед выполнением. В следующих разделах мы рассмотрим наиболее важные разделы ELF, встречающиеся при обратной разработке, и разберёмся в их работе.
Два раздела двоичного файла являются метаразделами: они имеют особое значение для файла ELF и используются для поиска в других таблицах разделов. Это таблица строк, определяющая строки, используемые файлом ELF, и таблица символов, определяющая символы, на которые ссылаются другие разделы ELF.
Первым рассмотрим раздел таблицы строк. Таблица строк определяет все строки, необходимые формату файла ELF, но обычно не содержит строковых литералов, используемых программой. Она представляет собой непосредственную конкатенацию всех строк, используемых файлом ELF, причём каждая строка завершается нулевым байтом.
Таблицей строк пользуются структуры файла ELF, в которых имеется строковое поле. Такие структуры задают значение строки в виде смещения в таблице строк. Одной из таких структур является таблица разделов. Каждому разделу присваивается имя, например .text, .data или .strtab. Если, например, строка .strtab находится в таблице строк по смещению 67, то заголовок раздела .strtab будет содержать в поле имени число 67.
В определённой степени это создаёт для загрузчика проблему курицы и яйца. Как загрузчику узнать, какой раздел является таблицей строк, если он не может проверить имена разделов, пока не узнает, где находится таблица строк? Для решения этой проблемы заголовок программы ELF предоставляет непосредственный указатель на таблицу строк. Благодаря ему загрузчик может найти таблицу строк до разбора остальных разделов файла ELF.
Следующий интересующий нас раздел - таблица символов. Таблица символов определяет символы, которые использует или определяет двоичный файл программы. Каждый символ в таблице содержит:
• уникальное имя (задаваемое смещением в таблице строк);
• адрес (или значение) символа;
• размер символа;
• вспомогательные метаданные о символе, например его тип.
Таблица символов активно используется в формате файлов ELF. Другие таблицы, ссылающиеся на символы, делают это посредством поиска в таблице символов.
Многие из самых известных разделов файла ELF просто определяют область, в которую код или данные загружаются в память. С точки зрения загрузчика содержимое этих разделов вообще не интерпретируется: они помечены как PROGBITS (или NOBITS). Однако при обратной разработке важно уметь находить и распознавать эти разделы.
По соглашению все созданные компилятором инструкции машинного кода помещаются в раздел .text двоичного файла программы. Раздел .text помечается как доступный для чтения и выполнения, но не для записи. Поэтому, если программа случайно попытается изменить собственный программный код, произойдёт ошибка сегментации.
Обычным глобальным переменным, определённым в программе явно как глобальные переменные либо как статические локальные переменные функции, необходимо назначить уникальный адрес, остающийся постоянным на протяжении всего времени жизни программы. По умолчанию этим глобальным переменным назначаются адреса в разделе .data файла ELF, а сами переменные получают свои начальные значения.
Например, если определить в программе глобальную переменную int myVar = 3, символ myVar будет находиться в разделе .data, занимать 4 байта и иметь начальное значение 3, записанное в самом разделе .data.
Обычно раздел .data защищён с разрешениями на чтение и запись. Хотя начальные значения глобальных переменных определены в разделе .data, во время выполнения программа может свободно читать и перезаписывать эти глобальные переменные.
Для глобальных переменных, которые программист оставил неинициализированными либо инициализировал нулём, файл ELF предоставляет оптимизацию - раздел Block Starting Symbol (.bss). Он работает так же, как раздел .data, за исключением того, что находящиеся в нём переменные перед запуском программы автоматически инициализируются нулём. Благодаря этому в файле ELF не приходится хранить несколько "шаблонов" глобальных переменных, содержащих одни нули. Файл ELF получается меньше, а при запуске программы устраняются лишние обращения к файлу для загрузки нулей с диска в память.
Раздел данных только для чтения .rodata используется для хранения глобальных данных программы, которые не должны изменяться во время её выполнения. В нём хранятся глобальные переменные, помеченные как const, а также, как правило, постоянные строковые литералы C, используемые в программе.
Например, с помощью утилиты objdump можно вывести содержимое раздела данных только для чтения нашей демонстрационной программы и увидеть, что строковые литералы Hello, and, %s и ! попали в раздел rodata окончательного двоичного файла.
Разделы .tdata и .tbss используются компилятором, когда программисты применяют локальные переменные потоков. Локальные переменные потоков - это глобальные переменные, аннотированные ключевым словом __thread_local в C++ либо специфичным для GCC или clang ключевым словом __thread.
Прежде чем рассматривать раздел .dynamic, необходимо понять символы ELF.
В формате файлов ELF символ - это именованная (и, при необходимости, версионированная) позиция в программе либо символ, определённый извне. Символы, определённые в программе или разделяемом двоичном файле, задаются в основной таблице символов файла ELF. Символьные имена могут быть связаны как с функциями, так и с глобальными объектами данных, но символы также можно назначать локальным переменным потоков, внутренним объектам среды выполнения, например глобальной таблице смещений, и даже меткам внутри конкретной функции.
Один из способов просмотреть таблицу символов заданного двоичного файла программы - воспользоваться командой readelf -r. Например, при просмотре двоичного файла ld-linux-aarch64.so.1 обнаруживаются следующие символы:
Ещё одним средством просмотра символов файла ELF является инструмент командной строки nm. У него имеются некоторые дополнительные возможности, которые порой полезны при просмотре символов скомпилированных программ C++. Например, параметр -g позволяет ограничить перечень только экспортируемыми символами, а параметр -C предписывает nm автоматически демаскировать символы C++. Ниже приведён такой перечень символов из libstdc++ (вывод сокращён):
Каждая запись в таблице символов определяет следующие атрибуты:
• имя символа;
• атрибуты связывания символа, например является ли он слабым, локальным или глобальным;
• тип символа, обычно принимающий одно из значений, приведённых в табл. 2.6;
• индекс раздела, в котором находится символ;
• значение символа, обычно являющееся его адресом в памяти;
• размер символа: для объектов данных это обычно размер объекта в байтах, а для функций - длина функции в байтах.
Таблица 2.6. Типы символов
Атрибуты связывания символа определяют, должен ли он быть виден другим программам в ходе компоновки. Символ может быть локальным (STB_LOCAL), глобальным (STB_GLOBAL) либо не относиться ни к одной из этих категорий.
Локальные символы не должны быть видны программам за пределами текущего файла ELF. При динамической компоновке загрузчик игнорирует их. Глобальные символы, напротив, явно предоставляются за пределы программы или разделяемой библиотеки. Во всей программе допускается только один такой символ.
Символы также могут быть определены как слабые. Слабые символы полезны для создания реализаций функции по умолчанию, которые могут быть переопределены другими библиотеками. Программы на C и C++, скомпилированные GCC, могут помечать функции и данные как слабые посредством синтаксиса атрибута __attribute__((weak)) либо директивы #pragma weak symbol в коде C/C++.
Пример применения слабых символов: malloc и другие процедуры выделения памяти часто определяются с их помощью.
Благодаря этому программы могут заменить такие реализации по умолчанию собственным вариантом без перехвата функций. Например, программа может компоноваться с библиотекой, которая выполняет дополнительную проверку ошибок, связанных с выделением памяти. Поскольку эта библиотека определяет для соответствующих процедур выделения памяти сильный символ, она переопределяет реализацию по умолчанию из GLIBC.
Версионирование символов - сложная тема, которая обычно не нужна при написании или обратной разработке программ, но иногда встречается при обратной разработке системных библиотек, таких как glibc. В рассмотренном ранее примере символы, оканчивающиеся на @GLIBC_PRIVATE, относятся к версии GLIBC_PRIVATE, а символы, оканчивающиеся на @GLIBC_2.17, - к версии GLIBC_2.17.
На абстрактном уровне версии символов работают следующим образом[14]. Иногда возникает веская причина обновить программу таким образом, что её существующий двоичный интерфейс приложения окажется нарушен. Например, функция получает дополнительный параметр, но должна сохранить прежнее имя.
Подобные изменения создают проблему, если программа является основной системной библиотекой: изменения, нарушающие ABI, потребуют повторно скомпилировать все зависящие от неё программы. Одно из решений - версионирование символов. Программа определяет одновременно новый и старый символы, но явно помечает их разными версиями. После этого программы, скомпилированные для новой версии, незаметно получают новый символ, а программы, скомпилированные для старой версии, продолжают использовать старый символ, сохраняя совместимость ABI.
Ещё одно применение версионирования - экспорт из разделяемой библиотеки символа, который не должны случайно использовать никакие библиотеки, кроме нескольких определённых. В этом случае символ GLIBC_PRIVATE служит для "сокрытия" внутренних символов glibc: вызывать соответствующие функции могут лишь внутренние системные библиотеки GLIBC, а другие программы не смогут случайно импортировать такой символ. Определениями таблиц версий символов и назначением версий управляют разделы файла ELF .gnu.version_d и .gnu.version.
Отображающие символы - это специальные символы, свойственные архитектуре Arm. Они существуют потому, что разделы .text в двоичных файлах Arm иногда содержат данные нескольких разных типов. Например, 32-битный двоичный файл Arm может содержать инструкции, закодированные в 32-битном наборе инструкций Arm, инструкции, закодированные в наборе Thumb, и константы. Отображающие символы помогают отладчикам и дизассемблерам определить, как следует интерпретировать байты в разделе кода. Эти символы носят только информационный характер и не изменяют способ интерпретации данных раздела процессором.
В табл. 2.7 показаны отображающие символы для 32- и 64-битной архитектуры Arm[15].
Таблица 2.7. Отображающие символы
После отображающего символа можно дополнительно указать точку и любую последовательность символов, не изменяя его смысла. Например, символ $d.realdata также указывает, что следующая за ним последовательность представляет данные.
Раздел .dynamic в формате файла ELF сообщает загрузчику, как скомпоновать и подготовить двоичный файл к выполнению.
Подробно просмотреть динамический раздел файла ELF можно командой readelf -d.
Эти разделы обрабатываются загрузчиком, и в итоге программа становится готова к выполнению. Как и в других уже рассмотренных таблицах, у каждой записи есть соответствующий тип, определяющий способ её интерпретации, и расположение её данных относительно начала динамического раздела.
Несколько сбивает с толку то, что динамический заголовок также ведёт собственные таблицы символов и строк, независимые от основных таблиц строк и символов файла ELF. Их расположение указывают записи таблицы STRTAB и SYMTAB, а размеры определяются соответственно полем STRSZ, содержащим размер таблицы строк в байтах, и полем SYMENT, содержащим количество записей символов в динамической таблице символов.
Первой важной записью динамической таблицы, которую обрабатывает загрузчик, является NEEDED. Большинство современных программ не являются полностью изолированными единицами: они зависят от функций, импортированных из системных и других библиотек. Например, программе, которой требуется выделить память в куче, может понадобиться malloc, однако программист вряд ли станет писать собственную реализацию malloc, а просто воспользуется предоставляемой системой реализацией по умолчанию, входящей в операционную систему.
При загрузке программы загрузчик также рекурсивно загружает все разделяемые библиотеки, от которых зависит программа, и все их зависимости. Программа сообщает загрузчику о своих библиотечных зависимостях посредством директив NEEDED в динамическом разделе. Каждой используемой программой зависимости соответствует отдельная директива NEEDED, и загрузчик поочерёдно загружает каждую из них. Обработка директивы NEEDED завершается, когда разделяемая библиотека полностью работоспособна и готова к использованию.
Вторая задача загрузчика после загрузки зависимостей программы - выполнить этап перемещения и компоновки. Таблицы перемещений могут иметь один из двух форматов: REL или RELA, немного различающихся кодировкой. Количество перемещений указывается соответственно в полях RELSZ или RELASZ динамического раздела. Таблицу перемещений программы можно просмотреть командой readelf -r.
Типы перемещений в конкретном двоичном файле программы существенно зависят от архитектуры набора инструкций. Например, видно, что все перемещения в этой программе относятся к 64-битной архитектуре Arm.
В целом перемещения делятся на три основные категории:
• статические перемещения, которые обновляют указатели и динамически переписывают инструкции внутри двоичного файла программы, если программу приходится загружать по адресу, отличному от заданного по умолчанию;
• динамические перемещения, ссылающиеся на внешние символы в зависимой разделяемой библиотеке;
• локальные перемещения потоков, содержащие смещение в области локального хранилища каждого потока, которое будет использовать конкретная локальная переменная потока. Локальное хранилище потока мы рассмотрим далее в этой главе.
Мы уже видели, что файлы ELF определяют последовательность заголовков программы, указывающих операционной системе и загрузчику, как и куда следует загружать файл ELF в память. Традиционно файлы программ ELF использовали этот механизм для точного указания адреса памяти, по которому их следует загрузить, - предпочтительного адреса программы. Например, файлы программ обычно запрашивали загрузку по адресу памяти 0x400000, а разделяемые библиотеки выбирали другой фиксированный адрес, расположенный значительно выше в адресном пространстве.
По разным причинам загрузчик и операционная система могут решить загрузить программу или разделяемую библиотеку по адресу, отличному от предпочтительного. Например, область по предпочтительному адресу может быть недоступна, поскольку её уже занимает что-то другое: отображённый файл или иная разделяемая библиотека. Ещё одна распространённая причина загрузки по другому адресу заключается в том, что программа и операционная система поддерживают рандомизацию размещения адресного пространства (address space layout randomization, ASLR). ASLR - это средство защиты от эксплойтов, которое рандомизирует адреса кода и данных в адресном пространстве программы, чтобы удалённые злоумышленники не могли легко предсказать расположение критически важных данных и кода программы при эксплуатации уязвимостей повреждения памяти, например переполнения буфера.
В обоих случаях программу невозможно загрузить по предпочтительному адресу. Вместо этого операционная система или загрузчик выбирает для двоичного файла другое подходящее место в памяти и загружает его туда. Разность между предпочтительным и фактическим адресами загрузки называется смещением перемещения двоичного файла.
Простая загрузка программы по неверному адресу создаёт проблемы. В программе часто закодированы указатели на её собственный код и данные, распределённые по различным разделам кода и данных. Например, виртуальные методы C++ определяются с помощью виртуальных таблиц, содержащих указатели на конкретные реализации виртуальных функций, определённых классом C++. Если файл ELF отображён по предпочтительному адресу, эти указатели правильно указывают на соответствующие функции. Но если файл ELF по какой-либо причине отображён по другому адресу, указатели перестают быть действительными.
Эту проблему можно решить одной из двух стратегий. Первая состоит в том, чтобы скомпилировать программу как позиционно-независимый код. В этом случае компилятор избегает статических перемещений, создавая код, который динамически определяет собственное расположение и при загрузке по другому адресу вообще не требует перемещений.
Второе решение - "исправления" перемещения, которые необходимо применить, если программа загружена по другому адресу. По существу, каждое перемещение слегка "корректирует" программу, обновляя указатель или инструкцию, чтобы после этапа перемещения программа работала по-прежнему.
В уже рассмотренном выводе readelf -r видно, что перемещения могут иметь разные типы, например R_AARCH64_RELATIV. Такой тип перемещения ссылается на адрес в двоичном файле программы, который необходимо обновить во время перемещения. Для этого типа перемещённый адрес равен сумме смещения перемещения и параметра слагаемого перемещения; результат записывается по адресу, указанному записью перемещения.
Каждая архитектура определяет собственный набор типов статических перемещений, и количество различных типов может быть велико[16]. В их число входит даже динамическое переписывание инструкций или вставка "заглушек"-трамплинов, если адрес цели перехода находится слишком далеко и его невозможно закодировать непосредственно в инструкции.
Во время первоначальной обработки программы, а затем каждой зависимой разделяемой библиотеки и каждой динамически загружаемой разделяемой библиотеки загрузчик отслеживает определённые в них нелокальные символы, создавая базу данных всех символов текущей программы.
На этапе перемещения программы динамический компоновщик может обнаружить перемещение, которое ссылается не на внутренний указатель, требующий обновления, а на символ, определённый за пределами двоичного файла программы или разделяемой библиотеки. Для таких динамических перемещений загрузчик проверяет запись символа перемещения, узнаёт имя импортируемого символа и ищет его в базе данных всех символов текущей программы.
Если загрузчик находит совпадение в базе данных, он записывает абсолютный адрес символа по адресу, указанному записью перемещения. Обычно это будет позиция ячейки в разделе глобальной таблицы смещений двоичного файла ELF.
Рассмотрим конкретный пример. Предположим, программа program.so использует функцию malloc, определённую в libc.so. Во время инициализации программы загрузчик видит, что program.so ссылается на libc.so посредством директивы NEEDED, и начинает загружать libc.so. На этом этапе загрузчик добавляет в глобальную базу данных символов все видимые извне символы из libc.so. Допустим, libc.so загружена по адресу 0x1000000, а malloc находится в этом файле по смещению 0x3000. Следовательно, адрес символа malloc будет сохранён в базе данных как 0x1003000. Позднее, обрабатывая перемещения program.so, загрузчик встретит запись динамического перемещения, ссылающуюся на символ malloc. Он проверит базу данных, увидит, что символ malloc имеет адрес 0x1003000, и запишет это значение по адресу, указанному записью перемещения в глобальной таблице смещений program.so.
Позднее, когда program.so попытается вызвать функцию malloc, произойдёт косвенный вызов через глобальную таблицу смещений program.so. Поэтому вызов malloc из program.so продолжит выполнение с определения функции malloc внутри libc.so.
Как мы видели в предыдущем разделе, динамические перемещения указывают позицию в программе, которой следует присвоить адрес импортированного символа, например адрес malloc внутри libc. Однако на практике программа может импортировать конкретный символ, такой как malloc, очень много раз. В принципе, для каждого вызова допускается создавать отдельный поиск символа, но это неидеальное решение: поиск символов отнимает время и требует поиска по строке в глобальной таблице символов.
Решением служит раздел глобальной таблицы смещений (Global Offset Table, .got) двоичного файла ELF. GOT объединяет разрешение внешних символов, поэтому каждый символ требуется искать только один раз. Таким образом, программа, использующая malloc в 256 разных местах, создаст лишь одно перемещение, которое просит загрузчик найти malloc и поместить его адрес в соответствующую ячейку GOT. После этого во время выполнения для вызова malloc достаточно загрузить адрес из этой ячейки и перейти по нему.
Ещё одна распространённая оптимизация этого процесса использует другой раздел - таблицу компоновки процедур, предназначенную для отложенного связывания символов.
Отложенное связывание основано на наблюдении, что программа может импортировать множество символов, но не обязательно использует каждый из них при каждом запуске. Если отложить разрешение символа до момента непосредственно перед его первым использованием, можно "сэкономить" затраты производительности на разрешение всех неиспользуемых символов. Для функций такая оптимизация отложенного разрешения выполняется посредством PLT.
Заглушки PLT - это микрофункции, в конечном счёте предназначенные для вызова импортированной функции. Компоновщик переписывает вызовы импортированных функций так, чтобы вместо них вызывалась PLT. Поэтому вызовы malloc в программе заменяются вызовами соответствующей заглушки PLT для malloc, обычно называемой malloc@plt. При первом вызове заглушки malloc@plt PLT вызывает процедуру отложенной загрузки, которая разрешает символ malloc в его фактический адрес, а затем переходит по этому адресу, вызывая malloc. Последующие вызовы заглушки PLT непосредственно используют ранее разрешённый адрес. В итоге каждый символ функции загружается один раз за запуск программы непосредственно перед первым вызовом этой функции.
После того как программа загружена в память, её зависимости удовлетворены, а сама она правильно перемещена и скомпонована со своими зависимостями от разделяемых библиотек, загрузчик может готовиться к запуску основного программного кода. Но сначала ему необходимо выполнить процедуры инициализации программы.
С точки зрения семантики программы на C и C++ начинают выполнение с функции main, содержащей основную логику программы, и завершаются сразу после возврата из main. Однако в действительности всё несколько сложнее.
В языке программирования C система типов сравнительно ограниченна. При определении глобальных переменных их можно либо статически инициализировать некоторым постоянным значением, либо оставить неинициализированными. В предыдущем разделе мы видели: если переменная инициализирована, её начальное значение помещается в раздел .data, а неинициализированные переменные помещаются в раздел .bss. Этот процесс называется статической инициализацией глобальных переменных.
Язык программирования C++ устроен сложнее. Переменные C++ могут использовать сложные типы, определённые программистом, например классы. Такие типы могут определять конструкторы, автоматически выполняемые при входе переменной в область видимости, и деструкторы, автоматически выполняемые при выходе переменной из области видимости. Глобальные переменные входят в область видимости до вызова функции main, а выходят из неё при завершении программы или выгрузке разделяемой библиотеки. Этот процесс называется динамической инициализацией.
Рассмотрим конкретный пример:
Эта программа определяет глобальную переменную типа AutoInit. AutoInit - это класс C++, определяющий конструктор и деструктор, каждый из которых выводит строку в консоль. Кроме того, программа определяет функцию main, которая выводит строку в консоль, а затем завершается.
Если скомпилировать и запустить программу, получится следующий вывод:
Внутри этот механизм работает так: как и прежде, C++ выделяет место для глобальных переменных в разделах .data и .bss, но отслеживает все конструкторы и деструкторы каждой глобальной переменной, которые потребуется вызвать до запуска функции main программы, в двух списках - соответственно __CTOR_LIST__ и __DTOR_LIST__. Затем при безопасном завершении программы вызываются соответствующие деструкторы в обратном порядке.
Хотя списки конструкторов и деструкторов прежде всего предназначены для таких языков, как C++, ими могут пользоваться и программы на C. Программист, пишущий код на C, может применить расширение GNU __attribute__((constructor)), чтобы добавить ссылку на функцию в список конструкторов, и, наоборот, пометить функцию как __attribute__((destructor)), чтобы добавить её в список деструкторов[17].
Файл ELF определяет две стратегии, с помощью которых компилятор может обеспечить выполнение этого процесса до вызова точки входа программы[18]. Более старая стратегия состоит в том, чтобы компилятор создал две функции: функцию init, вызываемую до main, и функцию fini, вызываемую при безопасном завершении программы или выгрузке разделяемой библиотеки. Если компилятор выбирает эту стратегию, функции init и fini указываются в динамическом разделе соответственно как INIT и FINI, а по соглашению сами функции помещаются соответственно в разделы init и fini двоичного файла ELF. Для правильной работы программы оба раздела должны быть помечены как исполняемые.
Вторая, более новая стратегия заключается в том, что компилятор просто ссылается в файле ELF на списки __CTOR_LIST__ и __DTOR_LIST__ целиком. Для этого используются записи INIT_ARRAY и FINI_ARRAY динамического раздела, а длины соответствующих массивов задаются записями INIT_ARRAYSZ и FINI_ARRAYSZ. Каждая запись массива представляет собой указатель на функцию, которая не принимает аргументов и не возвращает значения. При запуске программы загрузчик поочерёдно вызывает каждую запись списка.
Загрузчик также гарантирует, что при корректном завершении программы или выгрузке разделяемой библиотеки он воспользуется списком записей массива деструкторов, чтобы вызвать все статические деструкторы программы.
Последнее усложнение этой схемы состоит в том, что файлы ELF могут также определять список PREINIT_ARRAY. Эта таблица идентична INIT_ARRAY с единственным отличием: все функции из PREINIT_ARRAY вызываются раньше любых записей из INIT_ARRAY.
Программы могут свободно сочетать любые из описанных выше стратегий инициализации. Если используется несколько стратегий, порядок инициализации будет следующим[19]:
• Сначала программа загружается в память с помощью заголовков программы. В ходе этого процесса выполняется предварительная инициализация всех глобальных переменных. На данном этапе инициализируются глобальные переменные, включая глобальные переменные C++, имеющие статические начальные значения, а неинициализированные переменные в .bss обнуляются.
• Прежде чем начинать последовательность динамической компоновки, загрузчик убеждается, что все зависимости программы или разделяемой библиотеки полностью загружены и инициализированы.
• Загрузчик регистрирует через функцию atexit каждую ненулевую запись в FINI_ARRAY, а также саму функцию FINI, если она определена. Для разделяемых библиотек функция регистрируется для выполнения во время dlclose (либо во время exit, если к этому моменту разделяемая библиотека всё ещё загружена).
• Если программа определяет запись PREINIT_ARRAY, последовательно вызывается каждая ненулевая запись этого массива.
• Если программа определяет запись INIT_ARRAY, следом вызывается каждая ненулевая запись этого массива.
• Наконец, если программа определяет запись INIT, загрузчик непосредственно вызывает первую инструкцию соответствующего раздела, запуская заглушку init.
• Теперь модуль инициализирован. Если это разделяемая библиотека, функция dlopen может вернуть управление. В противном случае, если модуль является запускаемой программой, загрузчик вызывает точку входа программы, чтобы запустить среду выполнения C и начать первоначальную загрузку программы, ведущую к вызову main.
Помимо глобальных переменных данных, программы на C и C++ могут определять локальные переменные данных потоков. С точки зрения программиста глобальные переменные, локальные для потока, в основном выглядят и ведут себя точно так же, как обычные глобальные переменные, за исключением того, что они аннотируются ключевым словом __thread_local в C++ либо ключевым словом расширения GNU __thread.
В отличие от традиционных глобальных переменных, для которых во всей программе существует одна переменная, доступная всем потокам для чтения и записи, каждый поток содержит уникальную область хранения для собственных локальных переменных потока. Поэтому операции чтения и записи локальной переменной потока не видны другим потокам программы.
На рис. 2.2 показано различие между обращением программы к локальной переменной потока и к глобальной переменной. Оба потока воспринимают глобальную переменную как ссылку на один и тот же адрес памяти. Поэтому запись в переменную одним потоком видна другому, и наоборот. Локальная переменная потока, напротив, для этих двух потоков обеспечивается разными адресами памяти. Запись в локальную переменную потока не изменяет значение этой переменной, видимое другим потокам программы.
Как и обычные глобальные переменные, локальные переменные потоков можно импортировать из зависимой разделяемой библиотеки. Например, хорошо известная переменная errno, используемая для отслеживания ошибок различных функций стандартной библиотеки, является локальной переменной потока[20]. Локальные переменные потоков могут быть инициализированы нулём или статически.
Рисунок 2.2. Локальные переменные потоков и глобальные переменные
Чтобы увидеть работу этого механизма, рассмотрим следующую программу tls.c, определяющую две локальные переменные TLS: myThreadLocal и myUninitializedLocal.
Скомпилируем программу и посмотрим, как она выглядит в readelf.
Здесь видно, что программа теперь определяет заголовок программы TLS, охватывающий два логических раздела: .tdata и .tbss.
Каждой определённой в программе локальной переменной потока соответствует запись в таблице TLS файла ELF, на которую ссылается заголовок программы TLS. В этой записи указывается размер каждой локальной переменной потока в байтах, а самой переменной назначается "смещение TLS" - смещение, которое она будет использовать в локальной области данных потока.
Точные смещения TLS этих переменных можно просмотреть в таблице символов. _TLS_MODULE_BASE - символ, используемый для ссылки на базовый адрес данных локального хранилища потока (TLS) конкретного модуля. Этот символ служит базовым указателем для данных TLS данного модуля и указывает на начало области памяти, содержащей все локальные данные потоков конкретного модуля. $d - отображающий символ. Если не считать двух этих особых случаев, видно, что программа содержит только две наши локальные переменные потоков: myThreadLocal имеет смещение TLS 0, а myUninitializedLocal - смещение TLS 4.
Если локальная переменная инициализирована статически, соответствующая запись TLS этой переменной также указывает на "начальный шаблон" локальной переменной, хранящийся в разделе .tdata файла ELF на диске. Неинициализированные записи TLS указывают в раздел данных .tbss, благодаря чему в файле ELF не приходится хранить лишние нули. Конкатенация этих двух областей образует образ инициализации TLS программы или разделяемой библиотеки. В нашем примере это означает, что образ инициализации TLS программы представляет собой последовательность из восьми байтов 03 00 00 00 00 00 00 00[21].
Механизм локального хранилища потока во время выполнения может показаться несколько сложным, но в сущности работает следующим образом; он показан на рис. 2.3:
Рисунок 2.3. Механизм локального хранилища потока во время выполнения
• Каждый поток имеет доступ к регистру указателя потока. В 64-битной архитектуре Arm это системный регистр TPIDR_EL0, а в 32-битной - системный регистр TPIDRURW[22].
• Регистр указателя потока указывает на блок управления потоком (thread-control block, TCB), выделенный для соответствующего потока. В 64-битной архитектуре Arm TCB занимает 16 байт, а в 32-битной - 8 байт.
• Сразу после TCB находятся локальные переменные потоков основного двоичного файла программы, то есть они начинаются со смещения 16 байт (или 8 байт в 32-битной архитектуре) от адреса, хранящегося в указателе потока.
• Далее хранятся области TLS зависимых разделяемых библиотек основного двоичного файла программы.
• TCB также содержит по нулевому смещению указатель на массив DTV. Массив DTV начинается с поля поколения, а остальные его элементы представляют собой указатели на локальное хранилище потока каждой библиотеки.
• Локальные переменные потоков библиотек, загружаемых во время выполнения с помощью dlopen, выделяются в отдельном хранилище, но на них по-прежнему указывает массив DTV.
Такая схема реализации TLS позволяет программам обращаться не только к локальным переменным потоков, определённым в собственном программном модуле, но и к переменным, определённым в разделяемых библиотеках. Когда во время компиляции встречается операция загрузки из локальной переменной потока или сохранения в неё, компилятор создаёт обращение TLS по одной из четырёх моделей доступа TLS. Обычно компилятор выбирает модель на основе сведений из табл. 2.8, но её можно также переопределить вручную параметром командной строки -ftls-model либо для отдельной переменной атрибутом __attribute__((tls_model("name"))) в C и C++[23].
В табл. 2.8 описаны модели и накладываемые ими ограничения. Модели, расположенные в таблице выше, эффективнее во время выполнения, чем расположенные ниже.
Таблица 2.8. Модели TLS
Модель local-exec - самая быстрая, но и самая ограничительная модель доступа к локальным данным потоков. Её можно использовать только тогда, когда основной двоичный файл программы обращается к локальным переменным потоков, определённым в нём самом.
Модель local-exec основана на том, что указатель потока конкретного потока непосредственно указывает на его TCB, а вслед за метаданными TCB расположены локальные данные текущего потока, принадлежащие основной программе. В 64-битных программах эти метаданные TCB занимают 16 байт, а в 32-битных - 8 байт. Поэтому, например, в 64-битной программе обращение к переменной со смещением TLS 4 выполняется следующим образом:
• получить локальный указатель текущего потока;
• прибавить к нему 16 или 8, чтобы пропустить TCB, а затем ещё 4 - смещение TLS переменной;
• прочитать данные по этому адресу или записать их туда, обращаясь к переменной.
Такая модель подходит только для двоичного файла программы. Разделяемые библиотеки не могут применять этот способ; основной двоичный файл программы также не может использовать эту модель для обращения к локальным данным потоков, определённым в разделяемой библиотеке. Для подобных обращений необходимы другие модели.
Модель доступа TLS initial-exec применяется, когда локальная переменная потока, к которой выполняется обращение, определена в разделяемой библиотеке, загружаемой во время последовательности инициализации программы, то есть не во время выполнения посредством dlopen. Для этой модели это строгое требование, поэтому скомпилированные таким образом программы устанавливают в динамическом разделе флаг DF_STATIC_TLS, запрещающий загрузку библиотеки посредством dlopen.
В данном случае во время компиляции программа не может наверняка знать смещение TLS переменной, к которой обращается. Неоднозначность разрешается с помощью перемещений TLS. Такое перемещение используется загрузчиком, чтобы сообщить программе смещение TLS переменной, к которой выполняется обращение через границу модулей. Поэтому во время выполнения обращение к переменной происходит следующим образом:
• получить указатель потока;
• загрузить из глобальной таблицы смещений значение смещения TLS, помещённое туда соответствующим требуемой переменной перемещением TLS;
• сложить эти два значения;
• прочитать данные по полученному указателю или записать их туда, обращаясь к переменной.
Модель доступа TLS general-dynamic - наиболее универсальный, но одновременно самый медленный способ обращения к переменным TLS. Её может использовать любой программный модуль для обращения к переменной TLS, определённой в любом модуле, включая собственный или внешний.
Для этого программа пользуется вспомогательной функцией __tls_get_addr. Она принимает единственный параметр - указатель на пару целых чисел, содержащих идентификатор модуля, в котором находится локальная переменная потока, и смещение TLS переменной, к которой выполняется обращение, - и возвращает точный локальный адрес потока, на который ссылается эта структура. Сами структуры хранятся в разделе глобальной таблицы смещений (GOT) двоичного файла программы. Идентификатор модуля в такой структуре - уникальный индекс в структуре DTV, соответствующий выполняемому модулю. Ниже приведено определение структуры, одинаковое для 32- и 64-битной архитектуры Arm[24]:
Разумеется, возникает естественный вопрос: каким образом во время компиляции программа вообще может знать идентификатор модуля TLS или смещение TLS переменной? Смещение TLS может быть известно для локальных переменных потоков внутри собственного двоичного файла программы, но для внешних символов до времени выполнения его определить невозможно.
Для решения этой проблемы файл ELF меняет назначение перемещений. Возможных перемещений чрезвычайно много, но приведённые в табл. 2.9 перемещения дают общее представление о работе этого процесса.
Таблица 2.9. Основные типы перемещений TLS для файлов ELF Arm
Функция __tls_get_addr выполняет следующие операции, представленные ниже псевдокодом[25]:
Проверка версии DTV нужна для обработки случая, когда один поток динамически открывает разделяемую библиотеку посредством dlopen, после чего другой поток пытается обратиться к локальной переменной потока внутри этой библиотеки. Благодаря такой проверке во время dlopen не приходится приостанавливать все потоки и динамически изменять размер их массивов DTV. Во время dlopen и dlclose обновляется глобальная версия DTV. Затем при следующем вызове __tls_get_addr потоки обновляют собственные массивы DTV, освобождая локальное хранилище потока, связанное с уже закрытыми разделяемыми библиотеками, и гарантируя, что сам массив DTV достаточно длинен для хранения записи каждой открытой разделяемой библиотеки.
Отложенное выделение раздела TLS служит небольшой оптимизацией производительности. Оно гарантирует, что потоки выделяют память для локальных переменных потока динамически открытой разделяемой библиотеки лишь в том случае, если конкретный поток действительно будет пользоваться этими переменными.
Общий результат процесса состоит в том, что компилятор создаёт код для обращения к локальной переменной потока посредством вызова __get_tls_addr. С помощью перемещений загрузчик сообщает идентификатор модуля и смещение TLS переменной, к которой выполняется обращение. Наконец, система времени выполнения использует саму функцию __get_tls_addr, чтобы по требованию выделить локальное хранилище потока и вернуть программе адрес локальной переменной потока.
Модель доступа TLS local-dynamic применяется разделяемыми библиотеками, которым требуется обращаться к собственным локальным переменным потоков, независимо от того, загружены эти библиотеки статически или динамически. В сущности, это упрощённая форма модели доступа TLS global-dynamic. Она основана на наблюдении: при обращении к собственным локальным переменным потоков программа уже знает смещение конкретной переменной внутри своей области TLS; неизвестно ей лишь точное расположение самой области TLS.
В таком случае компилятор иногда может создать немного более быструю последовательность. Допустим, программа поочерёдно обращается к двум локальным переменным потока: одна имеет смещение 16, а другая - 256. Вместо двух вызовов __get_tls_addr компилятор создаёт один вызов __get_tls_addr для текущего потока, передавая идентификатор текущего модуля и смещение 0, чтобы получить адрес TLS собственного потока для текущего модуля. Прибавив к нему 16, программа получает адрес первой переменной, а прибавив 256 - адрес второй.
[3] [назад] github.com
[8] [назад] Первоначальная документация TLS, подготовленная сопровождающим Glibc: akkadia.org
[10] [назад] openwall.com
[11] [назад] wiki.gentoo.org
[12] [назад] redhat.com
[13] [назад] trapkit.de
[14] [назад] refspecs.linuxbase.org
[15] [назад] developer.arm.com
[16] [назад] github.com
[17] [назад] gcc.gnu.org
[18] [назад] gcc.gnu.org
[19] [назад] docs.oracle.com
[20] [назад] uclibc.org
[21] [назад] uclibc.org
[22] [назад] developer.arm.com
[23] [назад] gcc.gnu.org
[24] [назад] code.woboq.org
[25] [назад] code.woboq.org
Программы, которые мы хотим подвергнуть обратной разработке, почти никогда не выполняются в вакууме. Обычно они работают в контексте выполняющейся операционной системы, например Linux, Windows или macOS. Поэтому, чтобы правильно понять поведение программы после запуска, необходимо знать основы того, как операционные системы предоставляют программам службы, системную память и аппаратную изоляцию.
Разные операционные системы зачастую работают существенно по-разному, однако, как ни удивительно, среды выполнения обычных программ обычно во многом похожи. Например, различия в разделении режимов ядра и пользователя, доступе к памяти, планировании и механизмах вызова системных служб, как правило, сравнительно невелики, даже если внутренняя реализация и семантика слегка меняются от платформы к платформе.
В этом разделе мы кратко рассмотрим несколько фундаментальных понятий операционных систем. Хотя основное внимание будет уделено Linux, многие из тех же базовых понятий применимы и к другим операционным системам, с которыми вы можете столкнуться при обратной разработке.
Перед обратной разработкой двоичного файла программы важно понять контекст, в котором программы выполняются в операционной системе Linux. Центральные процессоры Armv8-A предоставляют операционной системе не менее двух режимов выполнения. Привилегированный режим, используемый ядром операционной системы, называется режимом ядра, а непривилегированный режим пользовательских программ - режимом пользователя. В архитектуре Armv8-A различие между кодом режима ядра и кодом режима пользователя обеспечивается аппаратно. Программы в режиме пользователя работают на непривилегированном уровне исключений 0 (Exception Level 0, EL0), а ядро операционной системы - на привилегированном уровне исключений 1 (EL1).
Код режима ядра обычно имеет полный доступ ко всему в системе: периферийным устройствам, системной памяти и памяти любой выполняющейся программы. За такую свободу приходится платить: ошибки в программах режима ядра способны вывести из строя всю систему, а уязвимости ядра ставят под угрозу безопасность системы целиком. Чтобы защитить код и данные ядра в памяти от вредоносных или неисправных программ, они изолированы от процессов пользовательского режима системы в адресном пространстве ядра. Более высокие уровни исключений архитектуры Armv8-A, а именно EL2 и EL3, будут рассмотрены в главе 4 "Архитектура Arm".
Процессы режима пользователя, напротив, имеют лишь косвенный доступ к ресурсам системы и работают каждый в собственном изолированном адресном пространстве. Если процессу режима пользователя требуется обратиться к устройствам или другим процессам, он направляет ядру запрос через предоставляемые операционной системой API в форме так называемых системных вызовов. Ядро операционной системы может ограничить опасные API, разрешив их применение только привилегированным процессам, либо предоставить абстракции системных устройств вместо непосредственного доступа. Например, операционная система обычно позволяет программам обращаться к собственным логическим файлам в файловой системе, но запрещает непривилегированным программам доступ к отдельным секторам данных жёсткого диска.
Подавляющее большинство приложений работает в режиме пользователя. Каждый процесс пользовательского режима изолирован в собственном адресном пространстве виртуальной памяти, где находится весь код и все данные программы.
При создании каждому процессу назначается уникальный идентификатор процесса (process identifier, PID). В Linux существует несколько команд для вывода сведений о процессах. Одна из самых распространённых команд просмотра сведений о процессах в Linux - ps. С помощью ps[1] можно просмотреть все процессы системы, используя параметры aux.
Команда ps axjf выводит полное дерево процессов. Ниже показан сокращённый вывод этой команды:
Команда ps удобна для просмотра состояния выполняющихся в системе процессов в конкретный момент, но иногда требуется наблюдать за их состоянием в реальном времени. Например, на рис. 3.1 показано, как команда htop позволяет динамически просматривать использование процессами центрального процессора и памяти.
Рисунок 3.1. Команда htop
Для просмотра более подробных сведений о производительности можно также воспользоваться интерактивным монитором процессов atop[2]. Эта программа отображает сведения о производительности, а также нагрузку на центральный процессор и память со стороны отдельных процессов всей системы. Пример вывода atop показан на рис. 3.2.
Рисунок 3.2. Вывод atop
Каждый процесс режима пользователя работает изолированно от остального кода системы: он не видит непосредственно код и данные других процессов или самого ядра операционной системы. Кроме того, процессы режима пользователя не имеют прямого доступа к аппаратному обеспечению устройств, если только ядро операционной системы явно его не разрешило. Когда пользовательской программе всё же требуется взаимодействовать с другими процессами, обращаться к файлам и иным системным ресурсам либо взаимодействовать с аппаратным обеспечением, она должна делать это через предоставляемые ОС API в форме так называемых системных вызовов.
В Armv8-A процесс режима пользователя запрашивает предоставляемую ядром службу, вызывая системный вызов с помощью инструкции вызова супервизора (supervisor call, SVC). Эта инструкция заставляет процессор создать исключение SVC, в результате чего процесс приостанавливается, а управление немедленно переходит зарегистрированному ядром обработчику SVC, работающему в режиме ядра. Затем ядро может определить, какой системный вызов был запрошен, и вызвать соответствующую процедуру режима ядра для обслуживания запроса. После завершения процедуры системного вызова его результат передаётся обратно процессу, а процесс режима пользователя возобновляет работу с инструкции, непосредственно следующей за SVC, которая инициировала запрос.
Динамически просматривать системные вызовы конкретного процесса можно с помощью команды strace. Эта программа перехватывает и записывает вызываемые процессом системные вызовы, а также отображает получаемые программой сигналы. Команда strace -p <PID> присоединяется к процессу с указанным идентификатором (PID) и отслеживает используемые им системные вызовы. Параметр -c ограничивает вывод количеством вызовов каждого типа и предоставляет сводку: сколько раз был выполнен каждый системный вызов и сколько времени в среднем занимало его выполнение внутри ядра. В следующем примере strace присоединяется к процессу с идентификатором 1 и возвращает сводку:
На практике программисты на C и C++ обычно выполняют системные вызовы косвенно, обращаясь к системным библиотекам, которые делают это от их имени. Например, если программа хочет вызвать функцию write, чтобы записать данные в файл, сокет или канал, обычно она вызывает функцию write из соответствующей библиотеки libc, а та немедленно выполняет системный вызов для обработки запроса.
На рис. 3.3 показан поток выполнения программы, которая косвенно выполняет системный вызов, вызывая функцию из библиотеки libc.
Рисунок 3.3. Вызов функции внутри библиотеки libc
В следующем фрагменте кода показано дизассемблированное представление функции write внутри libc:
Сначала эта функция помещает постоянное число 64 (0x40) в регистр x8, а затем выполняет инструкцию SVC, которая передаёт управление обработчику системных вызовов ядра. В 64-битном состоянии AArch64 регистр x8 сообщает операционной системе, какой именно системный вызов выполняется. В Linux номера системных вызовов определены в заголовочном файле Linux unistd.h[3], хотя точное расположение и имя файла зависят от конкретной архитектуры. Например, для Linux AArch64 этот заголовочный файл находится по пути /usr/include/asm-generic/unistd.h. Если найти в нём строку write, будут выведены номера всех системных вызовов, в именах которых присутствует write. В первой строке следующего вывода видно, что номер системного вызова write для архитектуры AArch64 равен 64:
Номера системных вызовов зависят от архитектуры. Например, в архитектуре AArch32 заголовочный файл не только находится по другому пути и имеет немного иное имя, но и содержит другие номера системных вызовов. Здесь номера можно найти в файле /usr/include/arm-linux-gnueabihf/asm/unistd-common.h. Поиск номера системного вызова write возвращает 4 вместо 64.
Вернёмся к нашему примеру. После заполнения регистра x8 номером системного вызова следующей выполняется инструкция SVC. Она заставляет процессор создать исключение вызова супервизора, из-за чего процессор временно переключается в режим ядра и выполняет зарегистрированный обработчик SVC ядра в пространстве ядра[4]. Этот обработчик сохраняет состояние выполняющейся программы, определяет номер запрошенного системного вызова, а затем вызывает соответствующую этому системному вызову процедуру ядра - в данном случае процедуру write, определённую в файле fs/read_write.c ядра Linux[5]. Поскольку процедура работает в режиме ядра, она имеет доступ к подключённому аппаратному обеспечению и может выполнить фактическую запись на диск. После завершения процедуры системного вызова ядро передаёт результат обратно программе в режиме пользователя и возобновляет её выполнение непосредственно после инструкции SVC, инициировавшей запрос системного вызова.
Процедуры системных вызовов работают в ядре операционной системы, поэтому имеют полный доступ к устройствам и другим процессам. Следовательно, именно эти процедуры должны проверять разрешения, прежде чем по запросу непривилегированного процесса режима пользователя выполнять привилегированное или потенциально нарушающее устойчивость системы действие. Например, хотя ничто не мешает ядру перезаписывать критически важные файлы на диске, оно всё равно должно запрещать делать это непривилегированным программам.
Архитектура Armv8-A предоставляет несколько механизмов защиты устойчивости и безопасности системы. Например, набор инструкций содержит непривилегированные инструкции загрузки и сохранения, такие как LDTR и STTR, позволяющие привилегированному коду, выполняемому на EL1, обращаться к памяти с разрешениями EL0. Благодаря этому можно разыменовывать указатели, переданные системным вызовам, а ОС может проверить, предназначен ли запрос для обращения к привилегированным или непривилегированным данным и доступны ли эти данные приложению. Иными словами, когда ОС требуется обратиться к памяти от имени непривилегированного приложения, такие инструкции ведут себя так, будто выполняются на EL0, и тем самым предотвращают обращения к привилегированным данным, не предназначенным для запросившего их приложения.
В Linux и других Unix-подобных системах эти проверки безопасности обычно абстрагируются понятием пользователей. Каждый процесс системы работает с привилегиями определённого пользователя. При системном вызове ядро может проверить, разрешено ли пользователю текущего процесса выполнить запрошенное действие, и отклонить системный вызов, если проверка разрешений не пройдена.
Помимо atop, процессы, созданные в системе определённым пользователем, можно просмотреть с помощью htop[6] и параметра командной строки -u <user>. Например, показанная на рис. 3.4 команда htop -u root выводит все процессы, работающие от имени пользователя root.
Для вывода процессов конкретного пользователя системы можно также воспользоваться командой ps, как показано на рис. 3.5.
В Linux и других Unix-подобных операционных системах пользователь root работает с максимальными разрешениями в системе. Поэтому, если программа выполняется от имени root, большинство проверок разрешений режима ядра для процесса во время системного вызова неявно завершаются успешно, что делает такие программы особенно привилегированными в системе.
Хотя процессы с разрешениями root обладают чрезвычайно широкими привилегиями, они всё же выполняются в режиме пользователя: ядро может разрешать им очень привилегированные действия, но они по-прежнему должны обращаться к нему с запросом. Этим они отличаются от программ, выполняемых в самом ядре: те могут просто обращаться к памяти или устройствам непосредственно, не передавая запрос через API операционной системы.
Рисунок 3.4. Команда htop -u root
Рисунок 3.5. Команда ps
Многие API системных вызовов, например связанные с доступом к сети или файлам, принимают параметры либо возвращают результаты, являющиеся дескрипторами ранее выделенного ресурса режима ядра, например файла или сокета. Обычно дескриптор представлен обычным целым числом, которое однозначно ссылается на ресурс, выделенный ядром для конкретного процесса.
Системные вызовы наподобие open, открывающего файл для чтения или записи, обычно выделяют объект файла в режиме ядра, присоединяют его к таблице дескрипторов процесса и возвращают целочисленный дескриптор как результат системного вызова. Позднее процесс может использовать этот дескриптор, например в последующем системном вызове read или write, чтобы указать ядру конкретный файл, который требуется прочитать или записать. Ядро сопоставляет дескрипторы режима пользователя с фактическими объектами режима ядра посредством таблицы дескрипторов процесса, которая сама хранится в ядре.
На рис. 3.6 показано разрешение дескрипторов в ядре. Здесь 32-битный пользовательский режим выполняет системный вызов read. Первым аргументом служит дескриптор, ссылающийся на ранее открытый файл, - в данном случае дескриптор с числовым значением 8. Когда программа выполняет инструкцию SVC, центральный процессор передаёт управление зарегистрированному ОС обработчику SVC в ядре, который в конце концов переходит к функции ksys_read, выполняющей логику системного вызова[7].
Рисунок 3.6. Разрешение дескрипторов
Чтобы выполнить запрос, ksys_read должна определить, какой файл программа хочет прочитать. В данном случае она ищет дескриптор с номером 8 в таблице дескрипторов текущего процесса, чтобы установить, к какому файлу выполняется обращение. Сопоставление дескриптора с объектом здесь выполняет fdget_pos[8]. Полученный объект описывает способ выполнения запроса чтения файла, обычно реализуемый драйвером файловой системы в ядре. Этот драйвер, также работающий в режиме ядра, может затем непосредственно обратиться к подключённому жёсткому диску, чтобы прочитать файл в память. Наконец, после выполнения запроса чтения управление возвращается процессу режима пользователя, который возобновляет работу с инструкции, непосредственно следующей за SVC.
Большинство дескрипторов процесса создаётся самим процессом во время работы, однако несколько дескрипторов неявно создаются в ходе создания процесса: это псевдофайловые дескрипторы стандартного ввода (stdin), стандартного вывода (stdout) и стандартного потока ошибок (stderr). По соглашению эти псевдодескрипторы представлены соответственно значениями 0, 1 и 2. Такие псевдофайлы позволяют программам передавать данные друг другу по каналам или взаимодействовать с пользователем через консоль.
Когда ресурсы режима ядра перестают быть нужны процессу, объект можно закрыть системным вызовом наподобие close[9]. Он уведомляет ядро о том, что программа больше не использует ресурс. После закрытия всех ссылок на соответствующий объект ядра ядро может начать освобождать данный ресурс. Если процесс завершится или будет аварийно прерван, не закрыв открытый дескриптор, ядро неявно закроет его в ходе завершения процесса, чтобы объект не "утёк".
При первом запуске программы создаётся новый процесс, которому выделяется один поток. Этот начальный поток отвечает за инициализацию процесса и последующий вызов функции main программы. Многопоточные программы могут запрашивать добавление в процесс дополнительных потоков для выполнения фоновой работы[10]. Например, многопоточный сервер веб-приложения может использовать отдельный поток для каждого входящего запроса, чтобы длительные запросы не мешали другим пользователям обращаться к сайту.
У процесса всегда есть по меньшей мере один поток. Когда завершается последний поток процесса, завершается и сам процесс. Один из способов просмотреть потоки внутри программы - использовать программу top[11] с синтаксисом top -H -p <pid>. Например, на рис. 3.7 показаны потоки, выполняющиеся внутри программы rsyslogd.
Рисунок 3.7. Выполняющиеся потоки
Каждый поток выполняет код независимо от остальных и логически работает так, словно является отдельным ядром процессора. У каждого потока имеется собственный набор регистров и собственное состояние процессора, включая собственные счётчик команд, указатель стека и арифметические флаги, а также собственные внутренне управляемые локальные переменные и стек вызовов. Однако обратите внимание: в отличие от процессов, потоки не изолированы друг от друга. Код и данные каждого потока загружаются в один процесс. Хотя соглашения программирования обычно предписывают одному потоку не вмешиваться непосредственно в закрытые данные другого, это обеспечивается только соглашением, а не аппаратно. На рис. 3.8 показан упрощённый пример адресного пространства процесса с тремя выполняющимися потоками режима пользователя.
Рисунок 3.8. Три выполняющихся потока режима пользователя
Каждому процессу назначается уникальное виртуальное адресное пространство. Блок управления памятью (memory management unit, MMU) процессора преобразует виртуальные адреса в физические, соответствующие областям системной памяти, где хранятся данные. Операционная система программирует MMU отдельно для каждого процесса. С помощью таблиц страниц он описывает компоновку и преобразование каждой доступной области памяти процесса, расположение соответствующих данных в памяти и разрешения каждой области. Точная компоновка таблиц страниц и порядок программирования MMU выходят за рамки этой книги, но подробно описаны в разделе "D5.2 - Система преобразования адресов VMSAv8-64"
В Linux компоновку адресного пространства процесса можно просмотреть через псевдофайл /proc/<pid>/maps для заданного идентификатора процесса либо через /proc/self/maps для выполняющейся в данный момент программы. Например, команда cat /proc/self/maps запускает программу cat, которая обращается к собственной карте виртуальной памяти и выводит её в терминал. Ниже приведён пример такого вывода (с добавленными именами столбцов):
Каждая область памяти представляет собой неперекрывающийся диапазон адресов вместе со сведениями о защите и типе области. Например, первый диапазон охватывает виртуальные адреса памяти в шестнадцатеричном интервале от 0x00400000 до 0x00410000. Он отображён из файла /usr/bin/cat и помечен защитой памяти r-xp.
Области, не описанные в карте адресов процесса, называются неотображённой памятью. Попытка прочитать, записать или выполнить память в таком неотображённом пространстве заставляет MMU сообщить центральному процессору об ошибке. Центральный процессор приостанавливает программу и передаёт управление зарегистрированному обработчику исключения в ядре. Затем ядро обычно уведомляет подключённый отладчик либо аварийно завершает программу с ошибкой сегментации.
В предыдущей карте адресов можно заметить, что области памяти всегда выровнены по значениям, кратным 0x1000, то есть адреса всегда оканчиваются нулями. Причина в том, что MMU выполняет преобразование адресов и защиту памяти для страниц, а не для отдельных байтов, поэтому размер и расположение каждой области памяти выровнены по границам страниц. В Armv8-A гранула преобразования[13] всегда равна 4 Кбайт (0x1000), 16 Кбайт (0x4000) или 64 Кбайт (0x10000)[14]. Операционные системы на основе Linux часто используют гранулярность преобразования 4 Кбайт[15], но могут быть скомпилированы и для гранулярности 64 Кбайт[16][17]. Другие операционные системы, например ядро 64-битной iOS, используют гранулярность 16 Кбайт[18]. Иногда ради производительности или по иным причинам операционные системы также используют страницы, размер которых превышает заданную архитектурой гранулу преобразования. Например, некоторые операционные системы применяют так называемые огромные страницы размером от 2 Мбайт до 1 Гбайт для серверных нагрузок и высокопроизводительных вычислений (high-performance computing, HPC).
В Linux размер страницы текущей системы можно определить командой getconf PAGESIZE. Она выводит размер страницы в байтах. Например, Red Hat Enterprise Linux Server на AArch64 может использовать страницы размером 64 Кбайт, что видно из следующего вывода:
Та же команда в системе Debian Linux ARMv8-A, напротив, показывает, что даже на том же процессоре система скомпилирована для страниц размером 4 Кбайт:
Каждой области памяти соответствует набор видов защиты. Самые основные из них - разрешения на чтение, запись и выполнение. В карте процесса первые три буквы защиты области обозначают её разрешения буквами RWX, а дефис указывает на отсутствие конкретного разрешения. Разрешения описаны в табл. 3.1.
Таблица 3.1. Разрешения защиты памяти
В модели памяти AArch64 разрешениями доступа управляет атрибут разрешения доступа (access permission, AP)[19]. Различия между разрешениями доступа на EL0 и EL1/2/3 описаны в табл. 3.2.
Таблица 3.2. Атрибуты разрешений
Если программа попытается использовать данные области способом, не разрешённым её защитой, например записать данные в область памяти только для чтения или выполнить код из области, помеченной как неисполняемая, MMU создаст ошибку разрешения. Управление перейдёт зарегистрированному обработчику исключений ядра. Если ядро определит, что ошибка вызвана ошибкой программы, оно обычно аварийно завершит программу с ошибкой сегментации.
Операционная система предоставляет каждой программе собственное адресное пространство, определённое отдельной для процесса таблицей страниц, загружаемой в MMU на время выполнения программы. Поскольку таблицами страниц процесса управляет операционная система, процесс должен обращаться к ней, если хочет добавить или удалить области памяти либо изменить разрешения существующей области памяти в собственном адресном пространстве.
Самый простой тип области памяти в адресном пространстве процесса - пустая память, обеспечиваемая файлом подкачки. Обычно операционная система заполняет такие области нулями, а программа динамически заносит туда данные во время работы. Большинство операционных систем позволяет свободно выделять такую память и повторно назначать ей любую комбинацию флагов защиты на выполнение, чтение и запись, хотя некоторые ОС в рамках строгой политики подписывания кода запрещают создавать исполняемую память во время выполнения.
Анонимная память часто применяется как разделяемая память нескольких процессов, но у неё есть и другие назначения. Например, диспетчер кучи программы выделяет анонимную память и управляет ею, добавляя в программу новые адресуемые диапазоны памяти для обслуживания динамического выделения функциями malloc и new. Диспетчер кучи периодически выделяет у ядра крупные "фрагменты" памяти, выровненные по границам страниц, посредством системных вызовов brk[20] и mmap с флагом MAP_ANONYMOUS[21]. Затем он по требованию разделяет эти крупные "плиты" на отдельные блоки. Благодаря этому программа может быстро выделять динамическую память во время выполнения, не выравнивая каждый блок по границе страницы и не выполняя для него отдельный системный вызов.
Помимо памяти, обеспечиваемой файлом подкачки, операционные системы позволяют обеспечивать области памяти логическими файлами на диске посредством механизма, называемого файлами, отображёнными в память. Обычно программы Linux создают отображённые в собственное адресное пространство процесса представления файла с помощью системного вызова mmap.
С точки зрения программы область, отображённая в память, выглядит так же, как обычная "анонимная" память, за исключением того, что она удобно предварительно заполнена данными с диска, а не нулями. Благодаря этому не приходится вручную читать данные с диска дополнительными вызовами read. После отображения к файлу можно обращаться точно так же, как к любой другой области памяти, с помощью обычных инструкций загрузки и сохранения. Как и другим областям памяти, отображённым областям можно назначать определённую комбинацию разрешений на чтение, запись или выполнение; кроме того, они могут совместно использоваться несколькими процессами.
За кулисами отображённые в память области дают системе множество преимуществ производительности. Они загружаются с диска по требованию, а операционные системы могут снижать общую нагрузку на память, неявно совместно используя неизменённые части отображённых файлов только для чтения между несколькими процессами, даже если файлы отображены как закрытые. Чтение из отображённого представления концептуально просто: если файл отображён по адресу 0x100000, то по адресу 0x100100 находится байт файла со смещением 0x100, и так далее.
Поведение операций записи в область памяти зависит от способа создания области, отображённой в память. По умолчанию данные, записанные в память такого отображения, переносятся обратно в исходный файл. То есть если файл отображён по адресу 0x100000, а программа записывает байт 2 по адресу 0x100100, то байту файла со смещением 0x100 присваивается значение 2. Исключение возникает, если файл отображён посредством mmap с аргументом MAP_PRIVATE. В таком случае записанные в область данные сохраняются только в памяти, а файл на диске не изменяется. Это позволяет программам отображать в память файлы, которые им разрешено читать, но не записывать.
Просмотр карты адресного пространства процесса позволяет увидеть, какие области памяти являются отображёнными файлами и какие именно файлы они отображают. Например, если выполнить cat /proc/self/maps для просмотра собственной карты адресов, можно увидеть, что файл /usr/lib/locale/locale-archive отображён в память программы как доступный только для чтения по адресу 0xffff7b510000, а куча выделена как доступная для чтения и записи, неисполняемая и закрытая.
Помимо обычных файлов программы часто отображают посредством областей памяти собственные библиотеки и программные файлы. В Linux такие программы и библиотеки обычно хранятся на диске в формате ELF[22]. В разных операционных системах используются разные форматы файлов. Например, macOS и iOS обычно используют формат Mach-O[23], а программы Windows обычно хранят библиотеки и исполняемые файлы в формате переносимых исполняемых файлов (Portable Executable, PE)[24].
Хотя внутреннее устройство каждого из этих форматов различается в разных операционных системах, их основное назначение сходно: такие двоичные файлы содержат код и постоянные данные программы, определяют расположение и начальные значения глобальных переменных и сообщают операционной системе и компоновщику режима пользователя, как отобразить эти данные в память и подготовить модуль к выполнению.
Точный механизм загрузки модулей сложнее и выходит за рамки книги. Вкратце: каждый файл сам описывает ряд разделов, причём каждый раздел отображает данные из файла непосредственно в память и задаёт виды защиты, которые следует применить к этой памяти. В файлах ELF это обычно выполняется посредством разделов LOAD, а загрузчик модулей LD отображает соответствующие данные из файла в память с помощью mmap[25].
Один из способов просмотреть разделы внутри файла ELF - команда readelf. Например, команда readelf -lW /usr/bin/cat, выводящая заголовки программы cat, возвращает следующее:
В этом файле две области LOAD. Первая указывает, что программу следует отобразить с разрешениями на чтение и выполнение, загрузить по адресу памяти 0x400000 и назначить ей длину 0xa80c байт; область содержит байты файла с 0 по 0x00a80c. Как мы видели ранее, Arm требует выравнивать области памяти, поэтому загрузчик округлит эти значения вверх в соответствии с выравниванием страниц текущей системы.
Второй заголовок загрузки описывает вторую область памяти: её следует загрузить по адресу 0x41fbe8, предоставить разрешения на чтение и запись и назначить длину 0x001060 байт. Первые 0x0006e8 байт будут взяты из файла начиная со смещения 0x00fbe8, а остальные байты второй области заполнятся нулями.
Сразу после загрузки программы cat в память будут отображены только две эти области: первая - с разрешениями на чтение и выполнение, вторая - на чтение и запись. Однако по мере работы программа может запрашивать изменения разрешений отображённой области памяти. Изменение разрешений части области отображённого файла (или области памяти другого типа) приводит к её "разбиению" на подобласти. Если снова взглянуть на вывод cat /proc/self/maps, можно увидеть, что именно это и произошло. В данном случае первая часть отображённого раздела чтения и записи была помечена как доступная только для чтения, поэтому создаётся впечатление, что /usr/bin/cat отображён трижды:
Эти три смежные области вместе образуют программу cat, загруженную в память. В данном случае говорят, что программа cat загружена по адресу 0x400000 - адресу первой отображённой области.
Исторически двоичные файлы программ сами описывали, по какому адресу их следует загружать в память. Загрузчик по возможности старался загрузить модуль именно по этому адресу, благодаря чему расположение данных в памяти во время выполнения оставалось в определённой степени постоянным. Однако в современных системах библиотеки, двоичные файлы программ и другие данные в памяти обычно намеренно загружаются по случайным адресам посредством механизма, называемого рандомизацией размещения адресного пространства (address space layout randomization, ASLR).
Назначение ASLR - усложнить эксплуатацию переполнений буфера и других уязвимостей повреждения памяти в приложении. Для этого удалённый злоумышленник лишается сведений о возможном расположении кода и данных в процессе-жертве после загрузки[26]. ASLR не предотвращает все эксплойты повреждения памяти: разработчики эксплойтов часто могут обходить ASLR с помощью других методов или уязвимостей. Однако ASLR работает эффективно и сравнительно легко включается программистами на C и C++ без изменений исходного кода приложения, поэтому в современных операционных системах этот механизм часто включён для процессов. Подробное объяснение методов эксплуатации и обхода ASLR выходит за рамки этой книги; подробнее они будут рассмотрены в моей следующей книге, посвящённой средствам защиты от эксплойтов с точки зрения нападения и обороны.
Тем не менее стоит упомянуть, что конкретная реализация ASLR зависит от операционной системы. В опубликованной в 2017 году работе[27] обнаружено, что энтропия разных реализаций ASLR различается в разных операционных системах, причём большинство из них демонстрирует меньшую энтропию в 32-битной версии ОС по сравнению с 64-битной. В табл. 3.3 показаны изменяющиеся биты (обозначенные единицами) и общая энтропия реализаций ASLR в трёх операционных системах, для каждой из которых приведены 32- и 64-битная версии.
Таблица 3.3. Сравнение энтропии реализаций ASLR
В контексте обратной разработки обычно не требуется понимать назначение или механизм ASLR, но важно знать о его существовании. Из-за ASLR адреса, в том числе адреса символов и фрагментов кода в памяти, часто меняются при каждом запуске программы. Например, если при одном запуске во время отладки интересная функция находилась по адресу памяти 0x0000ffffabcd1234, то при следующем запуске та же функция может оказаться по адресу 0x0000ffffbe7d1234.
В качестве примера воспользуемся командой Linux ldd, выводящей разделяемые библиотеки, которые требуются указанному двоичному файлу, в данном случае программе /bin/bash. При включённой ASLR команда покажет используемые программой разделяемые библиотеки, причём при каждом запуске bash они будут отображены по разным адресам.
Чтобы справиться с этой недетерминированностью во время анализа программы, у специалиста по обратной разработке есть два варианта. Первый - временно отключить ASLR в системе, присвоив числовому значению в псевдофайле /proc/sys/kernel/randomize_va_space значение 0[28]. ASLR будет отключена до следующей перезагрузки системы. Чтобы включить ASLR, этому значению присваивают 1 для частичной или 2 для полной ASLR.
Второй вариант - отключить ASLR в отладчике на время сеанса отладки. Более того, некоторые версии отладчика проекта GNU (GDB) по умолчанию отключают ASLR для загруженного двоичного файла на время сеанса. В GDB этим поведением управляет параметр disable-randomization[29].
Ещё одна возможность - записывать адреса в форме смещений. Например, если библиотека libc загружена по адресу 0x0000ffffbe7d0000, а интересующий символ находится по адресу 0x0000ffffbe7d1234, то смещение этого символа внутри библиотеки равно 0x1234. ASLR изменяет только базовый адрес загрузки двоичных файлов программ и библиотек, но не расположение кода и данных внутри двоичного файла. Поэтому с помощью смещения можно ссылаться на интересующую точку внутри библиотеки или программы независимо от адреса загрузки библиотеки.
В ходе выполнения своих задач потокам необходимо отслеживать локальные переменные и сведения о потоке управления, например текущий стек вызовов. Эти сведения принадлежат состоянию выполнения потока, но слишком велики, чтобы целиком храниться в регистрах. Поэтому каждому потоку предоставляется специальная локальная для потока "рабочая" область памяти, называемая стеком потока. Стеки потоков выделяются в адресном пространстве программы при выделении потока и освобождаются при его завершении. Каждый поток отслеживает расположение своего стека с помощью специального регистра, называемого указателем стека (stack pointer, SP).
Архитектура Arm поддерживает четыре реализации стека[30]:
• полный возрастающий;
• полный убывающий;
• пустой возрастающий;
• пустой убывающий.
Чтобы отличать полные реализации стека от пустых, нужно помнить, куда указывает SP:
• полный: SP указывает на последний элемент, помещённый в стек;
• пустой: SP указывает на следующую свободную позицию в стеке.
Направление роста стека и положение верхнего элемента зависят от того, является реализация возрастающей или убывающей:
• возрастающая: стек растёт в сторону больших адресов памяти (при помещении элемента в стек SP увеличивается);
• убывающая: стек растёт в сторону меньших адресов памяти (при помещении элемента в стек SP уменьшается).
В возрастающих стеках инструкция помещения в стек увеличивает SP, а в убывающих - уменьшает его. Четыре реализации стека показаны на рис. 3.9. Обратите внимание: меньшие адреса на рисунке расположены сверху, а большие - снизу. Именно в таком направлении стек отображается в представлении стека большинства отладчиков.
Рисунок 3.9. Реализации стека
В A32 значения можно сохранять в стеке инструкцией PUSH, а затем загружать обратно в регистры инструкцией POP. Указатель стека сообщает программе, из какой области памяти можно загрузить данные или в какую область их можно сохранить. Однако обе инструкции являются псевдоинструкциями, то есть псевдонимами других инструкций. В AArch32 PUSH - это псевдоним определённой формы инструкции сохранения нескольких значений (store multiple, STM), а POP - псевдоним определённой инструкции загрузки нескольких значений (load multiple, LDM)[31]. В дизассемблированном представлении вы, скорее всего, увидите базовые инструкции, а не их псевдонимы. Мнемоника конкретной инструкции LDM/STM, лежащей в основе PUSH и POP, указывает, какая реализация стека применяется. Стандарт вызова процедур для архитектуры ARM (Procedure Call Standard for the ARM Architecture, AAPCS32) всегда использует полный убывающий стек[32]. Подробно инструкции доступа к памяти рассматриваются в главе 6 "Инструкции доступа к памяти".
По умолчанию адресные пространства памяти предназначены для полной изоляции памяти процессов. Ядро обеспечивает её, выделяя каждому процессу непересекающуюся физическую память. Поэтому каждое чтение или запись памяти и каждая выборка инструкции используют часть системной памяти, отличную от памяти любого другого процесса или самого ядра. Однако существует одно исключение - разделяемая память[33].
Разделяемая память - это область памяти двух или нескольких процессов, намеренно использующая одну и ту же базовую физическую память. Поэтому данные, записанные одним процессом в разделяемую область, немедленно становятся видны другому процессу через его представление этой области. Ниже приведён сокращённый фрагмент адресного пространства другой программы:
Обе области отображены как доступные только для чтения, на что указывают первые три буквы разрешений памяти. За разрешениями следует одна буква: p или s. p означает, что память закрытая, а s - разделяемая.
Когда память разделяется между двумя процессами, ядро просто помечает записи таблиц страниц (page table entries, PTE) в обоих адресных пространствах так, чтобы они использовали одну и ту же базовую физическую память. Когда один процесс записывает данные в свою разделяемую область, запись попадает в физическую память и становится видна другому процессу при чтении из его представления области, поскольку обе области ссылаются на одну физическую память.
Обратите внимание: хотя разделяемая память обязательно использует один базовый физический адрес, два совместно использующих память процесса могут отображать свои представления этих данных по разным виртуальным адресам в собственных адресных пространствах и даже с разными разрешениями памяти. Например, в многопроцессном приложении один процесс может записывать данные в разделяемую память, которая в другом процессе является исполняемой и доступной для чтения, но не для записи. Так происходит, например, при выполнении вынесенной в отдельный процесс JIT-компиляции в веб-браузере с усиленной защитой.
В системах, использующих доверенные среды выполнения (trusted execution environments, TEE) в TrustZone, разделяемая память также служит для обмена данными между доверенным приложением, работающим в аппаратно изолированной среде TrustZone в безопасном мире, и обычным приложением, работающим в стандартной операционной системе в нормальном мире. В этом случае код нормального мира отображает некоторую физическую память в своё адресное пространство, а код безопасного мира отображает ту же область физической памяти в собственное адресное пространство. Данные, записанные в этот буфер разделяемой памяти из любого мира, видны обоим процессам. Разделяемая память является эффективным способом обмена, поскольку позволяет быстро передавать данные в среду TrustZone и из неё без переключения контекста[34]. Подробнее об Arm TrustZone рассказывается в главе 4 "Архитектура Arm".
[2] [назад] linux.die.net
[6] [назад] linux.die.net
[11] [назад] linux.die.net
[12] [назад]
[13] [назад] developer.arm.com
[14] [назад] armv8-ref.codingbelief.com
[15] [назад] wiki.debian.org
[16] [назад] kernel.org
[17] [назад] lxr.linux.no
[18] [назад] opensource.apple.com (см. определение PAGE_SHIFT_CONST).
[19] [назад] developer.arm.com
[23] [назад] developer.apple.com
[24] [назад] docs.microsoft.com
[25] [назад] github.com
[26] [назад] P. Team, "Pax address space layout randomization (aslr)", pax.grsecurity.net, 2003 (дата обращения: 20 декабря 2020 г.).
[27] [назад] J. Ganz and S. Peisert, "ASLR: How Robust Is the Randomness?", 2017 IEEE Cybersecurity Development (SecDev), Cambridge, MA, USA, 2017, pp. 34-41, doi: 10.1109/SecDev.2017.19.
[28] [назад] kernel.org
[29] [назад] visualgdb.com
[30] [назад] www-mdp.eng.cam.ac.uk
[32] [назад] github.com
[34] [назад]
В этой главе вы познакомитесь с профилями архитектуры Arm, уровнями исключений и двумя состояниями выполнения, поддерживаемыми архитектурой Armv8-A: AArch64 и AArch32.
В экосистеме Arm существуют десятки разных процессоров, отличающихся возможностями, производительностью, энергопотреблением и другими характеристиками. Чтобы обеспечить единообразие этих процессоров и позволить существующим скомпилированным приложениям выполняться на новых процессорах после их выпуска, каждый процессор экосистемы Arm соответствует определённой архитектуре и профилю.
Архитектура задаёт поддерживаемые наборы инструкций, доступный набор регистров и различные уровни привилегий как части модели исключений, программной модели и модели памяти системы. Она определяет основные возможности, которые процессоры обязаны поддерживать, а также возможности, которые они могут поддерживать дополнительно.
Вероятно, вы слышали термин "микроархитектура" и задаётесь вопросом, чем она отличается от архитектуры. Перед тем как погружаться в ассемблерный код при обратной разработке исполняемого файла с устройства на основе Arm, необходимо выяснить две вещи:
• какова микроархитектура процессора;
• какую архитектуру реализует процессор.
Архитектура представляет собой описание поведения процессора и определяет такие компоненты, как набор инструкций. Микроархитектура определяет устройство процессора. К ней относятся количество и размеры кешей, реализованные возможности, компоновка конвейера и даже реализация системы памяти.
Процессоры с разными микроархитектурами могут реализовывать одну архитектуру и выполнять один и тот же код. Например, архитектуру Armv8-A реализуют следующие процессорные ядра, различающиеся на уровне микроархитектуры: Cortex-A32, Cortex-A35, Cortex-A72, Cortex-A65 и Cortex-A78 - это лишь несколько примеров. Определив микроархитектуру целевого устройства, можно найти техническое справочное руководство, установить реализованную процессором архитектуру и ознакомиться с подробностями микроархитектуры, важными для конкретной задачи.
Ещё одно важное различие - профиль. Название процессорного ядра часто уже раскрывает конкретный профиль: например, Cortex-A72 относится к профилю A, Cortex-R82 - к профилю R и так далее.
В архитектуре Armv8 существуют три профиля[1]: A, R и M.
• A. Это "прикладной" профиль (Armv8-A). Armv8-A предназначен для полноценных операционных систем в таких устройствах, как мобильные телефоны, устройства Интернета вещей, ноутбуки и серверы.
• R. Это профиль "реального времени" (Armv8-R), который также поддерживает состояния выполнения AArch64[2] и AArch32[3]. Armv8-R предназначен для систем жёсткого реального времени или критически важных для безопасности систем, например медицинских устройств, авионики и электронных тормозов транспортных средств. Процессоры профиля R выполняют 32-битный код и поддерживают значительно более ограниченную архитектуру памяти по сравнению с профилем A.
• M. Это профиль "микроконтроллера" (Armv8-M)[4]. Armv8-M предназначен для применения в качестве микроконтроллера в недорогих глубоко встроенных системах, например промышленных устройствах и некоторых недорогих устройствах Интернета вещей. Armv8-M выполняет только 32-битные программы с набором инструкций Thumb.
Хотя профили A, R и M существовали ещё до архитектуры Armv8, новая архитектура значительно расширяет варианты применения, для которых были предназначены эти профили.
Возьмём, к примеру, архитектуру Armv8-R. Новое процессорное ядро Arm Cortex-R82[5] заменяет прежнее Cortex-R8 - 32-битное ядро, применяемое в современных модемах, контроллерах жёстких дисков и твердотельных накопителей и способное адресовать не более 4 Гбайт DRAM. Новая 64-битная архитектура Armv8-R с 40 разрядами адреса позволяет адресовать до 1 Тбайт DRAM, что особенно полезно для современных твердотельных накопителей большой ёмкости и обработки данных Интернета вещей непосредственно в хранилище. Разумеется, это не единственное усовершенствование профиля Armv8-R. Более подробный обзор приведён в дополнении к справочному руководству Armv8-R.
В этой книге основное внимание уделяется процессорам Armv8 на основе профиля A - профиля основного центрального процессора в современных устройствах с полноценной ОС, такой как Android. Однако важно помнить, что современные смартфоны содержат процессоры всех трёх типов. Например, процессоры профиля R обеспечивают сотовую связь, а процессоры профиля M используются в компонентах камеры, системах управления питанием, сенсорных экранах и концентраторах датчиков, Bluetooth, GPS и контроллере флеш-памяти. В SIM-картах и смарт-картах применяется процессор профиля M с дополнительными средствами безопасности, называемый SecureCore.
С момента выпуска архитектура Armv8 значительно совершенствовалась, получая новые расширения и средства безопасности и становясь всё более пригодной для мощных вариантов применения. В результате производители процессоров начали разрабатывать серверные микропроцессорные архитектуры на основе Arm, чтобы воспользоваться потенциалом архитектуры Arm как энергоэффективной, производительной и масштабируемой альтернативы процессорам Intel и AMD. Это привело к дальнейшему развитию рынка процессоров и расширению портфеля облачных служб экземплярами на основе Arm. Поэтому для специалистов по обратной разработке ещё никогда не было более подходящего времени, чтобы познакомиться с основами архитектуры Armv8-A и нового набора инструкций A64.
По состоянию на январь 2021 года последней используемой версией архитектуры Arm была Armv8 вместе с расширениями вплоть до Armv8.7. В марте 2021 года Arm представила новую архитектуру Armv9-A[6], основанную на Armv8-A и обратно совместимую с ней. В число новых возможностей Armv9-A входят масштабируемое векторное расширение версии 2 (Scalable Vector Extension v2, SVE2), расширение транзакционной памяти (Transactional Memory Extension, TME) и расширения буфера записей ветвлений (Branch Record Buffer Extensions, BRBE).
Архитектура Armv8-A предоставляет два состояния выполнения: 64-битное AArch64 и 32-битное AArch32. Они будут представлены в разделе "Состояния выполнения Armv8-A" и подробно рассмотрены соответственно в разделах "Состояние выполнения AArch64" и "Состояние выполнения AArch32".
Уровень исключений программы в общих чертах обозначает номер иерархического уровня, на котором происходит выполнение. На самом низком уровне EL0 обычно выполняются обычные пользовательские приложения. На более высоких уровнях выполняется более привилегированный код[7]; каждый из них концептуально находится "выше" и помогает управлять программами, работающими на более низких уровнях, как показано на рис. 4.1[8].
Рисунок 4.1. Уровни исключений с разделением "безопасного" и "небезопасного" состояний, предоставляемым расширением TrustZone
В старых версиях архитектуры, например Armv7, применялся термин "уровни привилегий", обозначавшиеся PL0, PL1 и PL2. В архитектуре Armv8 вместо него используется термин "уровни исключений" - от EL0 до EL3.
Одна из самых распространённых моделей применения такого логического разделения привилегий выполнения программ выглядит следующим образом[9]:
• EL0 - наименее привилегированный режим выполнения программы, используемый обычными приложениями режима пользователя. Программа на EL0 может выполнять базовые вычисления и обращаться к собственному адресному пространству памяти, но не способна непосредственно взаимодействовать с периферийными устройствами или системной памятью, если только такое взаимодействие явно не разрешено программным обеспечением более высокого уровня исключений.
• EL1 обычно используется ядрами операционных систем и драйверами устройств, например ядром Linux.
• EL2 обычно используется гипервизорами, управляющими одной или несколькими гостевыми операционными системами, например KVM.
• EL3 используется процессорами с расширением TrustZone и поддерживает переключение между двумя состояниями безопасности посредством безопасного монитора.
Иногда критически важному для безопасности коду операционной системы необходимо обрабатывать и надёжно хранить конфиденциальные данные даже в тех случаях, когда сама операционная система может быть скомпрометирована. К таким задачам относятся проверка целостности самой операционной системы, управление учётными данными пользователя с помощью датчика отпечатков пальцев, а также хранение ключей шифрования устройства и управление ими. Ценные ресурсы не ограничиваются компонентами режима ядра. Приложения управления цифровыми правами (DRM), банковские приложения и защищённые мессенджеры также могут стремиться защитить свой код и данные на устройствах, где может быть установлено вредоносное ПО.
Для таких сценариев профиль Armv8-A поддерживает расширение TrustZone[10]. Это аппаратное расширение процессоров Arm позволяет создавать доверенные системы и разделяет аппаратные и программные ресурсы устройства на два мира: безопасный мир для подсистемы безопасности и обычный мир для всего остального. При этом обращения безопасного мира к шине памяти полностью отделены от кода и устройств обычного мира. Эти миры также называют безопасным и небезопасным состояниями.
В безопасном состоянии обрабатывающий элемент (processing element, PE), то есть поведение абстрактной машины, может обращаться как к безопасным, так и к небезопасным пространствам физических адресов и системным регистрам. В небезопасном состоянии PE может обращаться только к небезопасному пространству физических адресов и небезопасным системным регистрам.
В процессорах Armv8-A с расширением TrustZone каждое логическое процессорное ядро работает так, словно оно содержит два разных "виртуальных ядра": одно действует внутри TrustZone, другое - вне её. Ядро обычного мира, как и прежде, выполняет традиционную операционную систему со всей её богатой функциональностью и обычными приложениями. В терминологии TrustZone вся эта среда называется богатой средой выполнения (rich execution environment, REE). В отличие от неё виртуальное ядро TrustZone размещает и выполняет доверенную среду выполнения (trusted execution environment, TEE) в безопасном мире. На практике виртуальные ядра TrustZone реализуются быстрым переключением контекста, которое выполняет безопасный монитор на самом высоком уровне привилегий.
Защищённые TrustZone код и данные изолированы от вредоносных периферийных устройств и кода вне TrustZone. На этой основе можно построить полнофункциональную TEE, включающую ОС TEE, работающую на S-EL1, доверенные драйверы (trusted drivers, TD), безопасно взаимодействующие с периферийными устройствами, и даже доверенные приложения (trusted applications, TA), работающие на S-EL0. TrustZone также предусматривает безопасный монитор, работающий на высшем уровне привилегий S-EL3 и имеющий полный доступ к устройству во всех режимах, как показано на рис. 4.2. Обратите внимание, что уровни исключений этих программных компонентов могут различаться в зависимости от реализации ОС TEE.
Рисунок 4.2. Компоненты уровней исключений в системе с поддержкой TrustZone
Уровни безопасных исключений S-EL0...S-EL3 имеют следующее назначение:
• S-EL0 выполняет непривилегированные доверенные приложения[11] или доверенные службы[12] в безопасном мире. В некоторых реализациях TEE доверенные драйверы также работают на S-EL0. Как и их аналоги на EL0, по умолчанию TA не могут обращаться к памяти других выполняющихся TA, к обычным программам на EL0 или непосредственно взаимодействовать с периферийными устройствами. Вместо этого TA выполняются внутри ОС TEE и управляются ею. Приложения S-EL0 отличаются от приложений EL0 тем, что их память может размещаться на защищённых TrustZone физических страницах, обеспечивая коду и данным дополнительный уровень защиты от вредоносного или неисправного кода обычного мира даже на высоких уровнях разрешений, таких как EL1 или EL2.
• S-EL1 является аналогом EL1 в безопасном мире и выполняет код операционной системы доверенной среды выполнения. В зависимости от реализации TEE доверенные драйверы также могут работать на S-EL1.
• S-EL2 допускает виртуализацию внутри безопасного мира. Он доступен только начиная с Armv8.4-A. S-EL2 используется диспетчером безопасных разделов (Secure Partition Manager), который можно рассматривать как минимальный гипервизор для разделения[13]. Это также позволяет разделить микропрограмму на более и менее привилегированные части: небольшой набор наиболее доверенных драйверов работает на S-EL2, а менее доверенные драйверы микропрограммы - на S-EL1.
• S-EL3 выполняет код безопасного монитора, соответствующий высшему уровню привилегий центрального процессора. Безопасный монитор выполняет код доверенной микропрограммы Arm (Arm Trusted Firmware, ATF), предоставленной изготовителем устройства[14]. Безопасный монитор является корнем доверия системы и содержит код, который выполняет переключение контекста между ядрами обычного и безопасного миров. Он также предоставляет обоим мирам базовые службы через обработчик вызова безопасного монитора (secure monitor call, SMC), к которому могут обращаться программы обычного и безопасного миров, работающие на более низких уровнях разрешений.
Обратите внимание: этот раздел не является исчерпывающим перечнем возможностей и вариантов настройки архитектуры TrustZone, а служит лишь введением и общим обзором. Полное рассмотрение этой темы, включая поверхность атаки TEE, выходит за рамки книги.
Программы, работающие на определённом уровне выполнения, непрерывно выполняются на этом уровне, пока процессор не встретит "исключение". Исключения можно разделить на два типа: синхронные и асинхронные. Синхронные исключения могут возникать из-за ошибки программы, например при выполнении недопустимой инструкции или попытке обращения к невыровненному адресу памяти. Их также могут вызывать инструкции генерации исключений, направленные на другие уровни исключений и используемые для реализации интерфейсов системных вызовов, посредством которых менее привилегированный код запрашивает службы у более высокого уровня привилегий, как показано на рис. 4.3. К ним относятся инструкции вызова супервизора (SVC), вызова гипервизора (HVC) и вызова безопасного монитора (SMC).
Рисунок 4.3. Вызовы SVC, HVC и SMC на соответствующих уровнях исключений
Асинхронные исключения могут быть вызваны физическими или виртуальными прерываниями и оставаться в состоянии ожидания. Это означает, что такие исключения не синхронизированы с текущим потоком инструкций, поэтому их и называют асинхронными.
При принятии исключения вызывается вектор исключения из таблицы векторов на целевом уровне исключений. Вектор исключения - это адрес обработчика исключения, заданный как смещение относительно базового адреса таблицы векторов, определённого в регистре базового адреса таблицы векторов (VBAR)[15], связанном с уровнем исключений, то есть VBAR_ELn.
В таблице 4.1 приведены смещения векторов относительно базового адреса таблицы в зависимости от EL, с которого принимается исключение[16].
Таблица 4.1. Смещения векторов относительно базового адреса таблицы векторов
Встретив исключение, процессор приостанавливает выполняемую задачу и передаёт выполнение программы зарегистрированному обработчику исключения на более высоком уровне исключений. Затем привилегированный код может вручную "вернуться" к менее привилегированной программе с помощью инструкции возврата из исключения eret[17]. Переключение контекста между безопасным и небезопасным состояниями происходит посредством аппаратных прерываний-исключений или инструкции SMC, которая вызывает исключение вызова безопасного монитора, направленное на EL3 к соответствующему обработчику исключения[18]. Вызовы SMC могут запрашивать службы доверенной микропрограммы на EL3 или службы, размещённые в TEE.
В обоих случаях вызывается диспетчер SMC на EL3, перенаправляющий вызов соответствующей точке входа. Если запрошенная служба находится в TEE, диспетчер SMC вызывает точку входа обработчика доверенных служб, как показано на рис. 4.4. Во время этого перехода небезопасный бит SCR_EL3.NS устанавливается в 0, указывая, что возврат из исключения должен произойти на Secure-EL1. Перед продолжением безопасный монитор сохраняет небезопасное состояние регистров и восстанавливает безопасное состояние регистров[19].
Рисунок 4.4. Вход в исключение SMC и возврат из него
Архитектура Armv8-A позволяет проектировать процессоры, которые могут изначально выполнять как 64-битные, так и 32-битные программы. Процессоры с такой функциональностью выполняют 64-битные программы в состоянии выполнения AArch64, а 32-битные - в состоянии выполнения AArch32[20][21]. Не все процессоры Armv8-A поддерживают оба состояния выполнения[22]. Например, Cortex-A32 поддерживает только AArch32, а Cortex-A34 - только AArch64. Другие процессоры, такие как Cortex-A77 и Cortex-A78, могут поддерживать AArch32 лишь на EL0.
Программы, работающие в AArch64, всегда используют набор инструкций A64, состоящий из инструкций шириной 32 бита. Эти инструкции доступны программам AArch64, которые могут использовать 64-битные регистры для обработки и хранения адресов.
Состояние выполнения AArch32 - новая концепция, введённая в архитектуре Armv8 ради совместимости с 32-битным набором инструкций Armv7-A. Программы, работающие в состоянии AArch32, используют два основных набора инструкций, первоначально определённых для более ранней архитектуры Armv7 и обновлённых в Armv8-A с целью поддержки дополнительных возможностей и новых инструкций.
Это означает, что процессоры Armv8-A совместимы с большинством программ, написанных для прежней архитектуры Armv7-A, и могут выполнять их непосредственно.
В предыдущих версиях архитектуры Arm два основных набора инструкций назывались Arm и Thumb. Чтобы избежать путаницы с новым 64-битным набором инструкций Arm, A64, эти наборы задним числом переименовали в A32 и T32[23]. Как и в прежних поколениях процессоров Arm, архитектура AArch32 допускает переходы между A32 и T32 с помощью механизма, называемого взаимной работой (interworking), который будет рассмотрен далее в этой главе.
Программы на Armv8-A всегда работают либо в AArch32, либо в AArch64, но никогда в их смеси. При этом 64-битные операционные системы способны выполнять 32-битные программы, а 64-битные гипервизоры - 32-битные гостевые операционные системы. Переходы из AArch64 в AArch32 разрешены только тогда, когда текущий уровень исключений процессора понижается при возврате из исключения. Переходы из AArch32 в AArch64 разрешены только тогда, когда при принятии исключения процессор повышает уровень исключений до более высокого уровня привилегий, например при обработке системного вызова, ошибки или внешнего аппаратного события.
Следствием такого устройства является то, что 64-битная операционная система может выполнять как 64-битные, так и 32-битные приложения, а 64-битные гипервизоры могут выполнять как 64-битные, так и 32-битные гостевые операционные системы. Однако 32-битные операционные системы и гипервизоры не могут выполнять 64-битные программы или операционные системы, как показано на рис. 4.5.
Рисунок 4.5. Пример выполнения 32-битных и 64-битных приложений на 32-битных и 64-битных гипервизорах
AArch64 - 64-битное состояние выполнения архитектуры Armv8, предоставляющее один набор инструкций: A64. Ширина инструкций A64 в памяти составляет 32 бита. Виртуальные адреса имеют 64-битный формат и могут храниться в 64-битных регистрах, то есть инструкции базового набора A64 могут использовать для обработки регистры шириной 64 бита.
Набор инструкций A64 был разработан для преодоления ограничений наборов A32 и T32 путём добавления новых возможностей и создания энергоэффективного 64-битного процессора. В результате такие компании, как Samsung и Qualcomm, начали проектировать 64-битные процессоры на основе Arm для мобильных устройств.
Этот раздел представляет обзор набора инструкций A64 и его отличий от прежних наборов A32. Особенности отдельных инструкций и принципы их работы будут рассмотрены в следующих главах.
Инструкции набора A64 можно разделить на следующие основные типы:
• инструкции обработки данных;
• инструкции доступа к памяти;
• инструкции потока управления;
• системное управление и прочие инструкции:
• доступ к системным регистрам;
• обработка исключений;
• инструкции отладки и подсказки;
• инструкции NEON;
• инструкции с плавающей точкой;
• криптографические инструкции.
Эта книга не ставит целью привести полный перечень всех инструкций, входящих в наборы A64 и A32/T32. Главы об инструкциях представляют обзор наиболее распространённых инструкций, встречающихся при обратной разработке. Поэтому мы сосредоточимся на трёх основных типах: обработке данных, доступе к памяти и потоке управления.
Читатели, уже знакомые с наборами инструкций A32 и T32, заметят сходство с набором A64: кодировки инструкций шириной 32 бита и похожий синтаксис. Однако между этими наборами есть множество различий. К ним относятся следующие:
• доступен более широкий набор регистров общего назначения: 31 64-битный регистр вместо 16 32-битных регистров в A32;
• нулевой регистр доступен только в A64;
• счётчик команд (PC) не доступен в A64 как именованный регистр и используется неявно в некоторых инструкциях, связанных с относительными загрузками и формированием адресов;
• диапазон смещений пула литералов относительно PC расширен до +/-1 МиБ, что уменьшает количество пулов литералов;
• увеличены смещения для загрузки/сохранения и формирования адресов относительно PC (диапазон +/-4 ГиБ), что сокращает необходимость загружать и сохранять смещения из пула литералов;
• инструкции работы с несколькими регистрами, такие как LDM, STM, PUSH и POP, заменены парными регистровыми инструкциями STP и LDP;
• инструкции A64 предоставляют более широкий выбор вариантов представления констант;
• указатели AArch64 имеют ширину 64 бита, позволяя адресовать более широкие диапазоны виртуальной памяти, при этом виртуальные адреса ограничены максимумом в 48 бит до Armv8.2-A и 52 бита начиная с Armv8.2-A[24];
• блок IT в наборе A64 признан устаревшим и заменён инструкциями CSEL и CINC;
• редко используемые варианты инструкций сдвига и вращения удалены, чтобы освободить место для новых инструкций, способных выполнять более сложные операции сдвига;
• T32 поддерживает смесь 16-битных и 32-битных инструкций, тогда как инструкции A64 имеют фиксированную длину;
• инструкции A64 могут работать с 32-битными или 64-битными значениями в 64-битных регистрах общего назначения. При обращении к 32-битному значению имя регистра начинается с W, а при обращении к 64-битному - с X;
• A64 использует стандарт вызова процедур (procedure call standard, PCS)[25], который передаёт через регистры X0-X7 до восьми параметров, тогда как A32 и T32 позволяют передать в регистрах только четыре аргумента, а остальные параметры передаются через стек.
AArch64 предоставляет 31 регистр общего назначения шириной 64 бита с именами x0...x30. Каждый 64-битный регистр также имеет соответствующую 32-битную форму с именем w0...w30. Чтение из 32-битного регистра Wn обращается к младшим 32 битам соответствующего 64-битного регистра Xn. Например, чтение w5 обращается к младшим 32 битам регистра x5.
Запись 32-битного значения в регистр Wn неявно обнуляет старшие 32 бита соответствующего 64-битного регистра Xn[26], как показано на рис. 4.6.
Рисунок 4.6. Ширина регистров Xn и Wn
Хотя на архитектурном уровне регистры общего назначения равноправны и взаимозаменяемы, на практике их роли при вызове функций определяются стандартом вызова процедур архитектуры Arm (Arm Architecture Procedure Call Standard, AAPCS64)[27].
• X0-X7 используются как регистры аргументов для передачи параметров и возврата результата.
• X8 может использоваться для передачи адреса косвенного результата.
• X9-X15 - временные регистры, сохраняемые вызывающей стороной и используемые для сохранения значений при вызове другой функции. Затрагиваемые регистры сохраняются в кадре стека вызывающей функции, что позволяет подпрограмме изменять эти регистры.
• X16-X18 - временные регистры внутрипроцедурного вызова, которые могут применяться для временного хранения непосредственных значений между вызовами подпрограмм.
• X19-X28 - регистры, сохраняемые вызываемой стороной. Они сохраняются в кадре стека вызываемой подпрограммы, что позволяет ей изменять эти регистры, но требует восстановить их перед возвратом вызывающей стороне.
• X29 используется как указатель кадра (frame pointer, FP) для отслеживания кадра стека.
• X30 - регистр связи (link register, LR), содержащий адрес возврата из функции.
В синтаксисе инструкций A64 64-битные целочисленные операции обычно используют 64-битные регистры Xn, но операции меньшей ширины могут использовать регистры Wn. Например, если программист хочет загрузить из памяти только один байт, регистром назначения будет 32-битный регистр Wn, в младшие 8 бит которого помещается значение.
AArch64 также определяет несколько архитектурно предобъявленных основных регистров, оптимизированных для конкретного назначения и не подходящих для арифметики общего назначения. Например, регистры счётчика команд и указателя стека не являются регистрами общего назначения и оптимизированы для своих специальных функций в программе. За исключением регистра связи x30, эти регистры не входят в стандартный набор регистров общего назначения x0-x30 и в ассемблерном коде обозначаются соответствующими именами, приведёнными в табл. 4.2[28].
Таблица 4.2. Специальные регистры A64
В AArch64 нет регистра x31. Вместо этого инструкции с регистровыми аргументами резервируют кодировку регистра 31, то есть 0b11111, для обращения к нулевому регистру, регистру указателя стека или некоторому другому значению, зависящему от контекста.
Регистр счётчика команд PC содержит адрес текущей инструкции. Концептуально каждая инструкция перед выполнением загружается из области памяти, на которую указывает PC. Если PC не изменяется явно при обычном выполнении инструкции, например при переходе, он автоматически продвигается к следующей инструкции. В Armv8 к PC нельзя обращаться непосредственно или задавать его как назначение инструкций загрузки либо обработки данных. Явно обновлять PC можно только при генерации исключений, возврате из исключений и переходах[29].
Единственными обычными инструкциями, способными читать PC, являются:
• инструкции перехода со связью BL и BLR, которым необходимо прочитать PC, чтобы сохранить адрес возврата в регистре связи LR;
• инструкции формирования адреса относительно PC, например ADR и ADRP, прямые переходы и загрузки литералов.
Регистр указателя стека SP отслеживает положение стека текущего потока и обычно указывает на логическую "вершину" стека. Область стека используется программами для эффективного хранения локальных переменных конкретной функции и доступа к ним, а также как универсальная "черновая" память для таких данных, как адреса возврата из функций.
В AArch64 SP является специальным регистром, и большинство инструкций не может обращаться к нему так же, как к регистрам общего назначения. Читать или записывать SP можно только с помощью специальных форм инструкций. Например, арифметическая форма инструкции ADD или SUBTRACT может изменять SP в прологе или эпилоге функции. У SP также есть 32-битное "представление" WSP, хотя при обратной разработке реальных программ оно встречается редко.
В AArch64 регистр SP предназначен для трёх основных сценариев:
• загрузка и сохранение данных в памяти с использованием SP как базового адреса;
• выравнивание SP в прологе или эпилоге функции с помощью определённых форм арифметических инструкций;
• выравнивание SP по границе учетверённого слова, то есть 16 байт.
Значение SP всегда должно быть выровнено как минимум по границе учетверённого слова. Если SP используется как базовый регистр для загрузок и сохранений без 16-байтного выравнивания, может возникнуть исключение выравнивания стека[30].
Процессор может использовать специальный 64-битный указатель стека, связанный с текущим уровнем исключений, либо указатель стека, связанный с EL0. У каждого уровня исключений есть собственный указатель стека: SP_EL0, SP_EL1, SP_EL2 и SP_EL3.
На уровне архитектуры нулевой регистр определён как всегда содержащий ноль. Любое чтение из него возвращает 0, а записи в него игнорируются. К этому регистру можно обращаться в 64-битной форме XZR или в 32-битной форме WZR.
Это обманчиво мощный инструмент набора инструкций A64. На поверхностном уровне XZR, конечно, освобождает регистр в операциях, которые иначе требовали бы загрузить ноль в обычный регистр, например при записи буквального нулевого значения в память.
Однако настоящая сила XZR заключается в гибкости кодирования, благодаря которой набор A64 сводит десятки отдельных инструкций к псевдонимам гораздо меньшего набора универсальных инструкций, которые процессору необходимо реализовать в кремнии. Он также используется в инструкциях, назначение которых - установить флаги условий, не изменяя участвующие в операции регистры. Например, инструкция сравнения CMP, применяемая для сравнения двух целых чисел, внутренне вычитает один операнд из другого и устанавливает арифметические флаги процессора согласно результату, после чего результат отбрасывается. Благодаря наличию XZR набору A64 не нужна отдельная инструкция CMP. Вместо неё используется псевдоним формы инструкции SUBS, выполняющей вычитание и устанавливающей арифметические флаги, но отбрасывающей результат путём назначения регистром результата XZR.
Регистр связи LR является синонимом регистра общего назначения x30. Этот регистр можно свободно использовать для обычных вычислений, однако его основное назначение в AArch64 - хранить адреса возврата при вызове функции.
В A64 функции можно вызывать инструкциями перехода со связью BL или BLR. Эти инструкции устанавливают PC для выполнения перехода, одновременно устанавливая LR. В PC помещается адрес первой инструкции вызываемой функции, а в LR - адрес возврата, к которому функция вернётся по завершении, то есть адрес инструкции, непосредственно следующей за BL или BLR. В A64 завершившаяся функция возвращается вызывающей стороне с помощью инструкции RET. Она копирует значение x30 обратно в PC, позволяя вызывающей функции продолжить работу с места остановки.
Указатель кадра x29 - регистр общего назначения, определённый стандартом вызова процедур архитектуры Arm (AAPCS)[31]. Поэтому его можно использовать для обычных вычислений, однако компиляторы часто выбирают x29 для явного отслеживания кадров стека. Такие компиляторы вставляют в начало функции инструкции выделения кадра стека, обычно посредством явного или неявного вычитания из текущего SP, после чего задают x29 так, чтобы он указывал на предыдущий указатель кадра в стеке. Во время выполнения функции обращения к локальным переменным происходят относительно регистра x29.
Когда x29 не используется для отслеживания кадров стека, компилятор может применять его как полностью универсальный арифметический регистр, уменьшая программу и повышая производительность. С другой стороны, отказ от указателей кадров усложняет раскрутку состояния программы при создании исключения C++[32].
Например, компилятор GCC предоставляет параметры времени компиляции, определяющие, будет ли скомпилированная программа использовать указатели кадров. Параметр командной строки -fomit-frame-pointer заставляет программу не использовать x29 как указатель кадра, а применять его как регистр общего назначения. Напротив, параметр -fno-omit-frame-pointer вынуждает компилятор всегда использовать x29 для отслеживания кадров стека[33].
В AArch64 x18 является регистром общего назначения и может применяться для универсальных вычислений. Однако AAPCS резервирует x18 в качестве регистра платформы, указывающего на платформенно-зависимые данные. Например, в Microsoft Windows программы режима пользователя используют x18 как указатель на блок окружения текущего потока, а программы режима ядра - как указатель на блок управления процессором режима ядра (KPCR)[34]. В режиме ядра Linux x18 указывает на структуру выполняемой в данный момент задачи[35]. По умолчанию Linux не использует x18 особым образом в режиме пользователя, однако некоторые компиляторы могут применять его для платформенно-зависимых задач, например для реализации защиты от эксплуатации уязвимостей с помощью теневого стека вызовов[36].
В системах, где этот регистр не является платформенно-зависимым, x18 можно свободно использовать как обычный регистр общего назначения. Например, компилятору LLVM можно указать зарезервировать x18 и не применять его как регистр общего назначения с помощью параметра -ffixed-x18[37].
Регистры x16 и x17 в AArch64 являются регистрами общего назначения, которые можно использовать для обычных вычислений внутри любой функции. Такое название они получили потому, что AAPCS разрешает подпрограммам хранить значения в x16 и x17 между вызовами подпрограмм.
Например, если программа вызывает определённую в общей библиотеке функцию, такую как malloc, этот вызов может быть реализован через таблицу компоновки процедур (procedure linkage table, PLT), чтобы вызвать реализацию malloc внутри другого модуля. Заглушка PLT, отвечающая за поиск подпрограммы malloc в другой библиотеке и передачу ей управления, может свободно использовать x16 и x17 как регистры внутрипроцедурного вызова, не заботясь о сохранности их значений. Например, LLVM компилирует заглушки PLT, использующие x16 и x17[38].
Помимо 64-битных целочисленных регистров общего назначения, AArch64 предоставляет 32 векторных регистра шириной 128 бит для оптимизированных операций "одна инструкция, множество данных" (single instruction multiple data, SIMD) и арифметики с плавающей точкой. Каждый из этих регистров имеет длину 128 бит и имя от v0 до v31. Интерпретация этих 128 бит зависит от инструкции.
В синтаксисе Armv8-A к регистрам Vn обычно обращаются через псевдонимы, описывающие число используемых в операции битов. При работе со значением шириной 128, 64, 32, 16 или 8 бит регистры Vn называются соответственно Qn, Dn, Sn, Hn и Bn, как показано на рис. 4.7.
Рисунок 4.7. Ширина регистров Vn
Поскольку инструкции SIMD и инструкции с плавающей точкой в этой книге не рассматриваются, подробности о регистрах SIMD и FP выходят за её рамки.
Armv8-A определяет ряд системных регистров, иногда называемых регистрами специального назначения (special-purpose registers, SPR), которые используются для наблюдения за поведением процессора и управления им. Эти регистры непосредственно не участвуют в обычных арифметических операциях и не могут быть регистрами назначения или источника инструкций обработки данных. Вместо этого их необходимо явно читать или устанавливать специальными инструкциями доступа к регистрам mrs и msr.
В AArch64 существуют сотни системных регистров[39]. Большинство из них используется только привилегированным кодом операционной системы, гипервизора или безопасной микропрограммы для изменения состояния системы: настройки состояния MMU и управления им, настройки процессора и наблюдения за ним или даже выключения и повторного включения машины. Некоторые регистры определены архитектурой и присутствуют во всех процессорах Arm. Другие определяются реализацией и выполняют функции, зависящие от микроархитектуры. Полный список этих системных регистров огромен и выходит за рамки книги, однако небольшое число системных регистров доступно обычным программам режима пользователя и иногда встречается при их обратной разработке.
Например, при обратной разработке процесса часто встречаются специальные регистры TPIDR_EL0 и TPIDRRO_EL0. Суффикс EL0 в их именах обозначает минимальный уровень исключений, с которого можно обращаться к регистру, чем и объясняется их появление при обратной разработке программ, работающих на EL0.
Системные регистры TPIDR_EL0 и TPIDRRO_EL0 архитектурно определены как доступные операционной системе и часто используются ОС и системными библиотеками для хранения базового адреса области локальной памяти потока. Поэтому при обратной разработке программы, обращающейся к локальным переменным потока, часто можно увидеть доступ к одному из этих регистров. Различие состоит в том, что программы режима пользователя могут читать и записывать TPIDR_EL0, тогда как код EL0 может только читать TPIDRRO_EL0, а устанавливать его можно лишь с EL1.
Специальные регистры читаются инструкцией MRS и записываются инструкцией MSR. Например, чтение и запись TPIDR_EL0 выполняются так:
В Armv8-A PSTATE хранит сведения о выполняющейся в данный момент программе[40]. PSTATE не является регистром как таковым: это набор независимо доступных компонентов, которые при возникновении исключения сериализуются в видимый операционной системе специальный регистр SPSR_ELx.
В AArch64 из PSTATE доступны следующие поля:
• флаги условий N, Z, C и V (NZCV);
• флаг текущей ширины регистра nRW;
• бит выбора указателя стека SPSel;
• флаги запрета прерываний DAIF;
• текущий уровень исключений EL;
• бит состояния пошагового выполнения SS;
• бит недопустимого возврата из исключения IL.
Из них программам, работающим на EL0, непосредственно доступны только поля NZCV. При этом операционные системы часто позволяют отладчикам, работающим на EL0, устанавливать бит SS в инструментируемых программах, а когда текущим состоянием выполнения является AArch64, флаг nRW устанавливается в 0.
Состояние процессора сохраняется в SPSR_ELx, содержащем значение PSTATE до принятия исключения, как показано на рис. 4.8[41].
Рисунок 4.8. Компоненты регистра PSTATE
Арифметические флаги условий N, Z, C и V обычно неявно устанавливаются многими арифметическими инструкциями и инструкциями сравнения и неявно используются при условном выполнении.
Флаги имеют следующие значения:
• N: операция дала отрицательный результат, то есть установлен старший значащий бит;
• Z: операция дала нулевой результат;
• C: операция дала перенос, то есть результат был усечён;
• V: операция дала знаковое переполнение.
Хотя явное обращение к флагам N, Z, C и V встречается редко, оно возможно через системный регистр NZCV. Ниже показаны компоновка этого специального регистра и синтаксис его явного чтения и изменения:
Остальные поля и флаги PSTATE нельзя устанавливать непосредственно из обычного кода режима пользователя. Они определяют поведение процессора при выполнении программы:
• Флаг текущей ширины регистра nRW. Он сообщает процессору, в каком состоянии выполнения должна работать программа. Если флаг равен 0, после возобновления программа будет работать в AArch64. Если флаг равен 1, программа будет работать в AArch32.
• Биты уровня исключений EL. При выполнении в AArch64 эти биты описывают уровень исключений, с которого произошло исключение. Для программы режима пользователя на EL0 поле содержит 0.
• Флаг пошагового выполнения SS. Отладчики используют его для пошагового выполнения программы. Для этого операционная система перед "возобновлением" программы посредством возврата из исключения устанавливает флаг SS в SPSR_ELx равным 1. Программа выполняет одну инструкцию, после чего немедленно создаёт исключение одиночного шага, возвращающее управление операционной системе. Затем ОС может передать обновлённое состояние программы подключённому отладчику.
• Флаг недопустимого состояния исключения IL. Процессор использует его для отслеживания недопустимых переходов между уровнями исключений, выполняемых привилегированным кодом. Если привилегированное ПО совершает недопустимый переход, например из-за того, что восстанавливаемое из SPSR_ELx значение PSTATE недопустимо, процессор устанавливает IL в 1. Этот флаг предписывает процессору немедленно создать исключение недопустимого состояния и передать его зарегистрированному обработчику до выполнения следующей инструкции.
• Флаги DAIF. Они позволяют привилегированной программе выборочно маскировать определённые внешние исключения. Обычно это поле недоступно программам режима пользователя.
• Флаги выбора указателя стека. Привилегированные программы на EL1 и выше могут бесшовно переключаться между собственным регистром указателя стека и указателем стека режима пользователя, то есть между SP_ELx и SP_EL0. Для такого переключения привилегированные процессы записывают специальный регистр SPSel. Программы на EL0 не могут переключать указатель стека, и специальный регистр SPSel им недоступен.
Armv8-A поддерживает выполнение 32-битных программ, предназначенных для более ранней архитектуры Armv7. Они работают в состоянии выполнения AArch32 архитектуры Armv8-A. В отличие от AArch64, программы AArch32 могут использовать один из двух наборов инструкций: A32 или T32. Во время выполнения они могут динамически переключаться между ними с помощью механизма взаимной работы (interworking). Привилегированная 64-битная программа, такая как 64-битная операционная система или гипервизор, может запланировать выполнение 32-битной программы, выполнив переход уровня исключений к менее привилегированной 32-битной программе после установки соответствующего бита SPSR[4] в 1. Это указывает, что программа будет работать в состоянии AArch32.
AArch32 необычна тем, что поддерживает два отдельных набора инструкций, A32 и T32, между которыми можно свободно переключаться во время выполнения программы. Оба набора используют одни и те же регистры и содержат инструкции, работающие в целом сходным образом, но применяют разные кодировки с разными ограничениями на доступные регистры, непосредственные значения и возможности. Переключение происходит посредством interworking, что позволяет программам, скомпилированным для A32, вызывать библиотеки, скомпилированные для T32, и наоборот с очень небольшими накладными расходами.
Архитектура Armv8-A добавила в наборы A32 и T32 новые усовершенствованные инструкции следующих категорий:
• инструкции загрузки с захватом и сохранения с освобождением;
• скалярные инструкции VFP с плавающей точкой;
• усовершенствованные инструкции SIMD с плавающей точкой;
• криптографические инструкции;
• системные инструкции.
Armv8-A поддерживает выполнение наборов A32 и T32 32-битными программами в состоянии AArch32 и спроектирована с обратной совместимостью с более ранней архитектурой Armv7. Архитектура Armv8-A добавила в эти наборы новые инструкции, соответствующие новым возможностям A64.
Как и в A64, каждая инструкция A32 имеет уникальную кодировку в виде последовательности из 4 байт. В инструкции кодируются как её тип, например сохранение, загрузка или математическая операция, так и используемые регистры, смещения и особенности поведения.
В A32 большинство операций можно настроить так, чтобы они устанавливали в CPSR ряд флагов условий на основе результата. Например, инструкция ADD складывает два входных значения и помещает результат в регистр назначения. Инструкция ADDS выполняет ту же операцию, но дополнительно устанавливает флаги N, Z, C и V по вычисленному результату.
Для повышения плотности инструкций в 1994 году был представлен набор Thumb[42]. В первоначальной версии каждая инструкция Thumb всегда кодировалась всего 16 битами, то есть занимала вдвое меньше соответствующей инструкции A32. Это повысило плотность инструкций ценой уменьшения объёма информации, кодируемой в каждой инструкции, и неизбежно снизило гибкость инструкций Thumb по сравнению с аналогами A32. Кроме того, в уменьшенной кодировке Thumb для регистра отводилось лишь 3 бита, поэтому многие инструкции могли обращаться только к восьми младшим регистрам.
Чтобы смягчить эти ограничения, примерно в 2003 году Arm представила в ядре ARM1156 расширение набора Thumb под названием Thumb-2[43]. Thumb-2 добавило 32-битные кодировки многих инструкций и позволило свободно смешивать их с 16-битными инструкциями Thumb. Оно также добавило в набор инструкции манипулирования битовыми полями и табличные переходы.
Thumb-2 также добавило в режим Thumb условное выполнение инструкций с помощью группы инструкций If-Then (IT) и битов ITSTATE в CPSR.
Вместе с Armv7-A компания Arm примерно в 2005 году анонсировала среду выполнения Thumb (Thumb Execution Environment, ThumbEE). Она также называлась Jazelle-RCT и предназначалась для динамически создаваемого кода JIT-компиляторов. Представленное в 2000 году расширение Jazelle, Jazelle DBX (Direct Bytecode eXecution), было разработано для ускорения интерпретаторов байт-кода Java. ThumbEE признали устаревшей в 2011 году, а в Armv8 её поддержку полностью удалили. Набор Jazelle в основном устарел, и архитектура Armv8 не поддерживает аппаратное ускорение байт-кода Java.
Одно из следствий устройства Armv8-A состоит в том, что один процессор часто способен выполнять все три набора: A64 состояния AArch64 и наборы A32 и T32 состояния AArch32. На рис. 4.9[44] показаны переходы процессора между этими наборами.
Обратите внимание: переключение между T32 и A32 посредством interworking может происходить непосредственно или при возврате из исключения из кода более высокого уровня исключений, но переключение между AArch32 и AArch64 всегда должно происходить при возврате из исключения с более высокого уровня.
Рисунок 4.9. Абстрактная схема переключения состояний наборов инструкций
В Armv8-A программы всегда работают либо в AArch64 и используют A64, либо в AArch32 и используют один или оба набора A32 и T32. Переходы между AArch32 и AArch64 разрешены только при изменении уровня исключений.
Переход из AArch64 в AArch32 может происходить, когда уровень исключений понижается при возврате из исключения. Привилегированный процесс управляет переходом, настраивая специальный регистр SPSR_ELx, когда поток процесса AArch32 готов к выполнению. Операционная система устанавливает бит 4 SPSR_ELx в 1, сообщая процессору, что менее привилегированный процесс работает в AArch32, а остальная часть SPSR_ELx хранит CPSR программы AArch32, который подробнее описан далее в главе. Когда привилегированный процесс выполняет инструкцию ERET, процессор переходит в AArch32 и входит в A32 или T32 в зависимости от состояния набора инструкций в CPSR.
Обратный переход в AArch64 разрешён только тогда, когда позднее при принятии исключения уровень исключений повышается, например при обработке системного вызова, ошибки или внешнего аппаратного события. Такой переход происходит автоматически при принятии исключения, возвращающего управление привилегированному процессу A64.
Процессоры Arm позволяют программам AArch32 свободно переключаться во время выполнения между наборами инструкций AArch32 посредством interworking. Это даёт программам, скомпилированным для A32, возможность динамически загружать и выполнять библиотеки, скомпилированные для Thumb, и наоборот.
A32 и T32 используют несовместимые кодировки инструкций, поэтому процессор должен отслеживать текущий набор. Для этого служат биты J и T регистра CPSR, которые вместе образуют состояние набора инструкций, приведённое в табл. 4.3.
Таблица 4.3. Режимы инструкций, задаваемые битами J и T для состояний A32 и T32
Этот флаг не устанавливается вручную непосредственным изменением CPSR, а задаётся неявно при выполнении инструкций перехода с interworking, таких как инструкции перехода с обменом, а также большинства инструкций, в которых счётчик команд является регистром назначения.
Переход с interworking могут выполнять следующие инструкции:
• инструкция перехода BX или BLX;
• инструкция LDR, LDM или POP, в которой PC является регистром назначения;
• арифметическая инструкция, где PC задан регистром назначения, если только эта инструкция одновременно не устанавливает флаги условий;
• инструкция MOV или MVN, где PC задан регистром назначения, если только эта инструкция одновременно не устанавливает флаги условий.
Переходы interworking работают с адресами, кодирующими как целевой адрес перехода, так и режим инструкций, на который нужно переключиться во время перехода. Старший 31 бит кодирует целевой адрес. Младший значащий бит задаёт набор инструкций, на который следует перейти, и копируется в бит T регистра CPSR, а не в PC.
Например, предположим, что переход interworking использует адрес 0x1000. В PC загружается 0x1000, а набором инструкций становится A32. Если же адрес равен 0x1001, в PC загружается 0x1000, а набором становится T32. Последний бит никогда не копируется в PC, поскольку инструкции обоих наборов A32 и T32 всегда выровнены как минимум по границе 2 байт.
При написании ассемблерного кода переключиться в Thumb можно всего двумя инструкциями: вычислить PC + 1 в регистре, а затем выполнить переход interworking к этой инструкции. Это может показаться запутанным, поэтому сначала рассмотрим код, а затем разберём, почему он работает.
Исходный код на ассемблере
В этом коде сначала определяется метка _start, являющаяся точкой входа программы, а затем следует директива .code 32, сообщающая препроцессору, что мы пишем инструкции A32. Первая настоящая инструкция складывает PC + 1 и помещает результат в регистр r4. Вопреки ожиданиям, в A32 чтение PC возвращает не адрес выполняемой инструкции, а этот адрес плюс 8. Поскольку каждая инструкция A32 занимает 4 байта, PC как будто указывает на расположенную далее инструкцию MOV R0, #0. Прибавив 1, мы вычисляем этот адрес и устанавливаем его младший бит в 1, подготавливая адрес к переходу interworking следующей инструкцией.
Следующая инструкция, BX r4, выполняет переход interworking по только что вычисленному адресу. Младший бит равен 1, поэтому процессор переключается в режим Thumb. После выполнения этой инструкции PC указывает на MOV R0, #0, которая теперь выполняется в режиме Thumb.
Следующая строка, .code 16, является инструкцией препроцессора ассемблера. Она предписывает ассемблеру начать выдавать инструкции Thumb. Переход interworking велел процессору начать обрабатывать инструкции Thumb, а строка .code 16 лишь велит ассемблеру выдавать инструкции Thumb, которые процессор будет правильно интерпретировать с этого места ассемблерного файла.
Результат дизассемблирования
В AArch32 процессор предоставляет для приложений 16 32-битных регистров общего назначения (r0...r15). Регистр r15 всегда кодирует счётчик команд, а остальные регистры r0...r14 можно свободно использовать для хранения данных и вычислений.
Регистры с r0 по r14 взаимозаменяемы при обработке данных, однако по соглашению многие из них выполняют строго определённые роли и имеют псевдонимы, отражающие эти роли. Например, r13 обычно используется как указатель стека, поэтому при чтении или написании ассемблерного кода часто обозначается SP.
В табл. 4.4 перечислены псевдонимы регистров общего назначения AArch32.
Таблица 4.4. Псевдонимы регистров AArch32
Регистры общего и специального назначения также имеют банковские копии, доступные в разных режимах процессора, причём каждая копия использует физически отдельное хранилище. Они называются банковскими регистрами и выделены более тёмным фоном на рис. 4.10. Это особенно полезно для ускорения переключения контекста при обработке исключений и привилегированных операциях, поскольку позволяет не сохранять и не восстанавливать вручную значения всех регистров.
Основная идея практической работы такова: при принятии исключения снимок текущего состояния процессора из CPSR сохраняется в SPSR того режима процессора, в который принимается исключение. При этом банковскими становятся и другие регистры, например регистр связи LR, содержащий адрес возврата из исключения. Процессор переходит к соответствующей записи таблицы векторов исключений, которая обычно содержит инструкцию перехода к обработчику этого исключения. При возврате из исключения регистр состояния CPSR восстанавливается из банковского SPSR, а PC обновляется адресом возврата, ранее сохранённым в банковском LR.
Эти режимы подробнее объясняются в разделе "Биты режима и маски исключений" этой главы.
Счётчик команд PC в AArch32 - 32-битный целочисленный регистр, хранящий адрес следующей инструкции, которую должен выполнить процессор. По историческим причинам при выполнении инструкции A32 чтение PC в AArch32 возвращает адрес текущей инструкции плюс 8, а при выполнении инструкции T32 - плюс 4. В AArch32 многие инструкции обработки данных могут записывать PC и даже перенаправлять поток программы, перезаписывая PC адресом, по которому программа может перейти.
Использование PC как регистра назначения инструкции фактически превращает её в инструкцию перехода. В зависимости от состояния набора инструкций записываемые в PC значения выравниваются соответствующим образом, поскольку PC игнорирует младший значащий бит и считает его равным 0.
Рисунок 4.10. Обзор регистров AArch32 в соответствующих режимах
Указатель стека SP (r13) используется программами для хранения ссылки на вершину занятой текущим потоком временной области памяти, называемой стеком. Этот регистр позволяет эффективно сохранять во временном стеке и извлекать из него такие данные, как локальные переменные, а также эффективно сохранять и восстанавливать регистры и адреса возврата в начале и конце функции.
Указатель кадра FP (r11) отслеживает текущий активный кадр стека, используемый функцией для хранения локальных переменных. Локальные переменные можно эффективно читать и записывать с помощью загрузок и сохранений относительно FP.
Регистр связи LR (r14) используется для хранения адреса возврата из функции. В обоих наборах A32 и T32 функция вызывается инструкцией BL или BLX. Эти инструкции устанавливают PC на первую инструкцию вызываемой функции и неявно помещают в LR адрес, по которому функция вернётся после завершения, то есть адрес инструкции, непосредственно следующей за BL или BLX. В A32 завершившаяся функция часто возвращается вызывающей стороне с помощью BX LR или похожей инструкции, копирующей адрес возврата из LR обратно в PC и позволяющей вызывающей функции продолжить работу с места остановки.
Внутри функции регистр внутрипроцедурного вызова IP (r12) ничем не отличается от любого другого регистра общего назначения. Его название связано с тем, что компиляторы и компоновщики используют r12 как временный регистр при реализации внутрипроцедурных "трамплинов". Самый распространённый пример такого трамплина - вызов функции в другом модуле через PLT, однако трамплины также применяются при переходах на огромные расстояния, которые невозможно непосредственно закодировать инструкцией BL или BLX. В таких случаях программа переходит к трамплину, который вычисляет адрес назначения и перенаправляет туда поток выполнения. Для этого трамплину нужен как минимум один временный регистр, и обычно выбирается r12. Из-за этого значение r12 может измениться после выхода из одной функции, но до прибытия в следующую, если вызов функции выполнялся через внутрипроцедурный трамплин, что может показаться нелогичным.
В AArch32 регистр текущего состояния программы (current program status register, CPSR) содержит различные поля состояния процессора и управления им. Он работает аналогично PSTATE в AArch64 и также сохраняется в SPSR_ELx при каждом принятии исключения.
На рис. 4.11 показана компоновка CPSR с номерами битов каждого поля.
Рисунок 4.11. Абстрактный обзор битов CPSR и их значений
Для программ режима пользователя на EL0 поля CPSR в целом делятся на две группы: регистр состояния прикладной программы (application program status register, APSR), который хранит арифметические флаги и непосредственно доступен программам на EL0, и регистры состояния выполнения, управляющие поведением процессора и находящиеся под управлением операционной системы.
Как показано на рис. 4.12, APSR состоит из трёх групп флагов внутри CPSR, кратко перечисленных ниже и подробно объясняемых в следующих разделах:
• арифметические флаги N, Z, C и V, используемые обычными арифметическими инструкциями и инструкциями сравнения;
• флаг насыщения Q, используемый специальными инструкциями арифметики с насыщением;
• биты GE, используемые специальными инструкциями параллельного сложения и вычитания.
Рисунок 4.12. Компоненты APSR в составе CPSR
При обычном выполнении программы, как правило, нет необходимости непосредственно читать и записывать флаги APSR. Однако это возможно, а иногда и необходимо, например при использовании бита Q регистра APSR. Синтаксис чтения битов N, Z, C, V, Q и GE из APSR выглядит так:
Программы режима пользователя также могут непосредственно записывать биты NZCVQ и GE в APSR. Существуют три формы в зависимости от того, нужно ли установить группу NZCVQ, группу GE или обе группы одновременно.
Чаще группа флагов NZCV в APSR устанавливается неявно при выполнении вычислительной инструкции или инструкции сравнения. Флаги имеют следующие значения:
• N: операция дала отрицательный результат, то есть установлен старший значащий бит;
• Z: операция дала нулевой результат;
• C: операция дала перенос, то есть результат был усечён;
• V: операция дала знаковое переполнение.
В режиме A32 большинство инструкций можно закодировать для условного выполнения на основе состояния флагов NZCV регистра APSR. Поэтому флаги NZCV лежат в основе условного выполнения.
Накопительный флаг насыщения Q устанавливается при выполнении специальных инструкций арифметики с насыщением. В обычном коде они встречаются редко, но довольно часто появляются в приложениях цифровой обработки сигналов. Если во время одной из таких инструкций происходит целочисленное насыщение, Q устанавливается в 1. Q действует как "липкий флаг": после установки в 1 он сохраняет это значение, пока не будет вручную сброшен в 0.
В отличие от флагов NZCV, инструкции нельзя закодировать для непосредственного условного выполнения по состоянию Q: его необходимо вручную извлечь из APSR. Аналогично, сброс Q выполняется ручной записью в APSR. Эти операции выполняются так:
Четыре флага "больше или равно" (greater than or equal, GE) в APSR используются специальными векторными инструкциями "параллельного сложения" и "параллельного вычитания". Эти инструкции выполняют векторные операции над упакованными наборами данных. Например, инструкция UADD8 складывает два 32-битных операнда так, словно каждый из них состоит из четырёх последовательных независимых байтов, а затем упаковывает четыре результата обратно в 32-битный регистр назначения. Эта инструкция также устанавливает четыре бита GE в APSR согласно результатам сложения.
Как и флаги N, Z, C, V и Q, флаги GE можно непосредственно прочитать из APSR инструкцией MRS. Однако одна инструкция использует GE неявно: инструкция выбора байтов SEL, которая может выполнять частичное условное перемещение на основе состояния флагов GE.
Регистры состояния выполнения - битовые поля CPSR, которые вместе сообщают процессору, как выполнять инструкции по адресу счётчика команд. Эти поля описаны в следующих разделах.
На рис. 4.13 биты T и J регистра CPSR вместе образуют состояние набора инструкций процесса.
В Armv8-A на уровне архитектуры бит J определён как 0, поэтому допустимы только два режима, приведённые в табл. 4.5.
Рисунок 4.13. Биты состояния набора инструкций в CPSR
Таблица 4.5. Режимы инструкций, задаваемые битами J и T для состояний A32 и T32
Программы режима пользователя не могут непосредственно читать и записывать биты состояния набора инструкций так же, как APSR. Вместо этого программы переключаются между A32 и T32 с помощью переходов interworking.
В прежних версиях архитектуры Arm бит J использовался вместе с битом T для выполнения аппаратно ускоренного байт-кода Java в режиме "Jazelle" или входа в набор инструкций T32EE (ThumbEE). Оба режима признаны устаревшими в Armv8-A, а бит J зафиксирован в нуле.
Флаги PSTATE.IT регистра CPSR (см. рис. 4.14) описывают коды условий для последовательности инструкций, выполняемых внутри группы с префиксом IT в режиме Thumb (T32). Старшие три бита 8-битного PSTATE.IT представляют "базовое условие" блока IT. Остальные четыре бита кодируют длину и последовательность чередования максимум четырёх инструкций, составляющих PSTATE.IT.
Рисунок 4.14. Расположение битов IT в CPSR
Изначально блок IT предназначался для того, чтобы сделать 16-битные инструкции Thumb условными. Почти все инструкции A32 могут быть условными, но в кодировках инструкций T16 недостаточно битов для кода условия. Блок IT позволяет сделать условными до четырёх последующих инструкций внутри него. Однако на практике производительность предикатных инструкций в современных архитектурах масштабировалась хуже, чем предполагалось изначально, поэтому в Armv8 инструкция IT была частично признана устаревшей.
Armv8 позволяет процессорам дополнительно поддерживать динамическое переключение порядка байтов во время выполнения программ AArch32. Такие программы могут предписать процессору переключаться между прямым и обратным порядком байтов во время выполнения, изменяя порядок загрузки и сохранения данных.
Процессор отслеживает выбранный порядок байтов с помощью бита E в CPSR, показанного на рис. 4.15. Значение 1 означает, что программа работает с обратным порядком байтов, а 0 - с прямым.
Рисунок 4.15. Расположение бита порядка байтов в CPSR
Программы не устанавливают этот флаг непосредственно в CPSR, а задают текущий порядок байтов инструкцией SETEND. Программы более высокого уровня выполнения также могут вручную установить этот бит через соответствующий сохранённый SPSR программы. Выборка инструкций всегда выполняется с прямым порядком байтов и игнорирует этот бит.
Биты режима PSTATE.M определяют текущее состояние выполнения, как показано на рис. 4.16. Назначение одного из этих битов вполне очевидно. Бит 4 определяет, будет соответствующая программа 32-битной или 64-битной. Значение 1 означает AArch32, а 0 - AArch64.
Чтобы полностью понять остальные биты PSTATE.M и биты маскирования исключений AIF, требуется дополнительный контекст. Поэтому кратко вспомним исключения центрального процессора и обстоятельства их возникновения.
При продвижении по программе процессор иногда может столкнуться с исключительным состоянием, в котором он больше не знает, как продолжать работу. Это может произойти из-за недопустимой инструкции, ошибочного чтения или записи памяти либо вызова программой службы ПО более высокого уровня исключений. Такие события называются синхронными исключениями, поскольку возникают на конкретной инструкции программы.
Рисунок 4.16. Биты режима в CPSR
Асинхронные события, напротив, поступают извне процессора в виде системных ошибок SError, запросов прерывания IRQ и быстрых запросов прерывания FIQ. Обычно их создают подключённые периферийные устройства. Например, сетевое оборудование может создать запрос прерывания, чтобы уведомить операционную систему о прибытии сетевого пакета, готового к немедленной обработке.
В нормальных обстоятельствах процессор отвечает на такие запросы, немедленно приостанавливая выполняемую программу, повышая уровень исключений и передавая управление соответствующему зарегистрированному обработчику исключения, который может направить запрос нужному драйверу устройства. Обработчики регистрируются системным программным обеспечением, работающим на высоком уровне исключений.
Если это системное ПО работает в AArch32, остальные биты PSTATE.M определяют используемый режим исключений, причём эти режимы образуют строгую иерархию приоритетов внешних прерываний. Например, обычная программа может встретить инструкцию SVC, из-за которой процессор приостановит программу и перейдёт в режиме SVC к операционной системе AArch32 на EL1 для обработки запроса системного вызова. Если поступит внешний IRQ, системный вызов будет приостановлен до завершения подпрограммы IRQ. Затем сам IRQ может быть прерван прерыванием FIQ. Но FIQ не может быть прерван IRQ, поскольку FIQ имеет более высокий "приоритет". При каждом возврате из исключения режим понижается, а прерванная задача возобновляется. В табл. 4.6 перечислены режимы AArch32 и их представление в PSTATE.M[45].
Таблица 4.6. Кодировки битов режимов AArch32
Как и AArch64, состояние AArch32 позволяет программному обеспечению операционной системы временно отключать определённые внешние исключения посредством битов AIF в PSTATE. Значение 1 в соответствующем поле означает, что центральный процессор ответит на внешнее исключение, а 0 - что он отложит ответ, пока ПО операционной системы позднее не снимет маскирование исключения.
• A: отвечать на асинхронные аварийные завершения;
• I: отвечать на внешние аппаратные запросы прерывания IRQ;
• F: отвечать на внешние быстрые запросы прерывания FIQ.
Показанные на рис. 4.17 биты маски исключений устанавливаются при возникновении исключения в AArch32.
Рисунок 4.17. Биты маски исключений в CPSR
[1] [назад]
[2] [назад]
[3] [назад]
[4] [назад]
[5] [назад]
[6] [назад]
[7] [назад]
[8] [назад]
[9] [назад]
[10] [назад]
[11] [назад]
[12] [назад]
[13] [назад]
[14] [назад]
[15] [назад]
[16] [назад]
[17] [назад]
[18] [назад]
[19] [назад]
[20] [назад]
[21] [назад]
[22] [назад]
[23] [назад]
[24] [назад]
[25] [назад] https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst.
[26] [назад]
[27] [назад] https://github.com/ARM-software/abi-aa/blob/f52e1ad3f81254497a83578dc102f6aac89e52d0/aapcs64/aapcs64.rst.
[28] [назад]
[29] [назад]
[30] [назад]
[31] [назад]
[32] [назад]
[33] [назад] https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html.
[34] [назад] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019.
[35] [назад] https://patchwork.kernel.org/patch/9836893.
[36] [назад] https://clang.llvm.org/docs/ShadowCallStack.html.
[37] [назад] https://clang.llvm.org/docs/ClangCommandLineReference.html.
[38] [назад] https://github.com/llvm-mirror/lld/blob/master/ELF/Arch/AArch64.cpp#L218.
[39] [назад]
[40] [назад]
[41] [назад]
[42] [назад]
[43] [назад]
[44] [назад]
[45] [назад]
В этой главе представлены инструкции обработки данных и их формы, включая арифметические, логические операции, операции сдвига и работы с битовыми полями, а также инструкции умножения и деления. Инструкции обработки данных выполняют операции над значениями в регистрах общего назначения, а их базовый синтаксис обычно состоит из двух исходных операндов и одного регистра назначения:
Операнды конкретной инструкции зависят от её типа. В инструкциях обработки данных первым всегда указывается регистр назначения, за которым следуют входные операнды. В этой главе регистры назначения обозначаются как Rd для A32/T32 и Xd или Wd для инструкций A64. Входные регистры обозначаются Rm, Rn или Ra для A32/T32 и Xn или Xm для A64. Поскольку синтаксис различных инструкций содержит не только регистры источника и назначения, в начале каждого раздела будет приведён обзор синтаксических символов для соответствующей группы или класса инструкций.
При чтении или написании ассемблерного кода сначала указывается код операции инструкции, то есть операция, затем регистры назначения и, наконец, исходные операнды. В следующем примере инструкция ADD складывает значения двух 64-битных исходных регистров X1 и X2 и сохраняет 64-битный результат в регистре x0.
В A64 арифметические инструкции могут устанавливать арифметические флаги на основе результата. Некоторые инструкции, например инструкции сравнения и проверки CMP и TST, всегда делают это неявно. Другие устанавливают флаги только по явному запросу. Такие инструкции записываются с суффиксом s. Обратите внимание: при перечислении синтаксических форм отдельных инструкций в этой главе форма с установкой флагов отдельно не приводится, поскольку единственным отличием является суффикс s, не влияющий на базовый синтаксис. Ниже показан пример формы с установкой флагов на основе предыдущей инструкции сложения:
Иногда две разные инструкции имеют одну кодировку, и тогда одна из них считается псевдонимом другой. Псевдоинструкции, или псевдонимы инструкций, облегчают программистам и специалистам по обратной разработке чтение и написание ассемблерного кода, представляя хорошо известные частные случаи сложной инструкции в более понятной форме.
Многие инструкции имеют несколько форм, позволяющих изменить исходный регистр до его использования в операции инструкции. На низком уровне эти формы используют разные кодировки. Иными словами, конкретную инструкцию можно закодировать так, чтобы её исходные регистры обрабатывались разными способами. Например, инструкции A32 допускают все или некоторые из следующих форм исходного операнда:
• регистровая форма;
• форма с непосредственной константой;
• форма с регистром, подвергаемым сдвигу;
• форма с регистром, сдвигаемым на значение из другого регистра;
• форма с расширенным регистром.
Ниже приведены три примера инструкций ADD набора A64 в регистровой форме, форме с непосредственным значением и форме со сдвинутым регистром:
Для распознавания и понимания инструкций при обратной разработке важно знать их различные формы. Однако запоминать конкретные кодировки инструкций необязательно, хотя они могут дать некоторое представление о происходящем на низком уровне. Рассмотрим, например, инструкцию ADD с непосредственным значением, кодировка которой приведена на рис. 5.1. Из неё видно, почему эта инструкция ADD не позволяет складывать произвольные константы: если константу невозможно закодировать 12 битами, ей не хватит места в кодировке инструкции.
Рисунок 5.1. Инструкция ADD
Обратите внимание, что на рис. 5.1 используются символы Rn и Rd, что может вводить в заблуждение, поскольку обычно ими описывают синтаксис A32/T32. Однако в данном случае кодировка относится к инструкции A64[1]. В этой кодировке Rd задаёт номер регистра назначения операции, а Rn - номер первого исходного регистра. S определяет, будут ли установлены арифметические флаги, то есть будет инструкция иметь вид add или adds, а sf определяет ширину операции: 32 бита при sf = 0 или 64 бита при sf = 1. Поле imm12 кодирует 12-битную константу, "непосредственное значение", которое прибавляет инструкция. Следовательно, наибольшим допустимым числом для этой инструкции является 4095, эквивалентное двенадцати единицам (1111 1111 1111). Однако однобитное поле sh кодирует необязательный неявный сдвиг непосредственного значения, позволяя расширить число до 4096. У этого поля возможны лишь два состояния: при значении 0 сдвиг не применяется, а при значении 1 непосредственное значение сдвигается влево на 12 разрядов.
Следующий пример показывает, как непосредственное значение 4096 с 13-битным представлением кодируется 12 битами:
После ассемблирования следующих двух инструкций в результате дизассемблирования можно увидеть, что вторая инструкция кодирует число 1 как непосредственное значение и сдвигает его на 12 с помощью логического сдвига влево LSL, формируя значение 4096.
Многие формы инструкций содержат операции сдвига и вращения. Кроме того, сдвиги и вращения существуют как отдельные инструкции. Поэтому сначала рассмотрим, как эти операции работают на низком уровне.
Операции сдвига и вращения перемещают двоичные биты внутри регистра влево или вправо на другие позиции. Сдвиг может выполняться явно специальной инструкцией, такой как LSL, или неявно над операндом другой инструкции.
Набор A64 поддерживает четыре основных типа сдвига:
• логический сдвиг влево (LSL);
• логический сдвиг вправо (LSR);
• арифметический сдвиг вправо (ASR);
• вращение вправо (ROR).
Наборы A32 и T32 предоставляют пятый тип: вращение вправо с расширением (RRX).
В этом разделе мы кратко рассмотрим каждый тип сдвига, а затем подробнее изучим формы инструкций и операции с битовыми полями.
Операция логического сдвига влево перемещает битовую последовательность внутри регистра влево на n позиций. При её перемещении биты, "выпадающие за край", отбрасываются, а освободившиеся справа позиции заполняются нулями. См. рис. 5.2. Например, при сдвиге значения влево на 1 бит входной бит 0 перемещается в позицию 1, бит 1 - в позицию 2 и так далее. Старший значащий бит входного значения отбрасывается, а младшие значащие биты результата становятся нулевыми.
Рисунок 5.2. Операция логического сдвига влево
Математически сдвиг представленного в двоичном виде числа влево на n битов эквивалентен умножению значения на 2^n, или операции << в C. Поскольку аппаратно сдвиги реализуются гораздо эффективнее универсального умножения, компиляторы часто заменяют умножение на константу, являющуюся степенью двойки 2^n, сдвигом значения влево на n.
Ниже показан пример логического сдвига влево на 3 позиции:
Операция логического сдвига вправо перемещает битовую последовательность внутри регистра вправо на n позиций. При её перемещении биты, "выпадающие за край", отбрасываются, а освободившиеся слева позиции заполняются нулями, как показано на рис. 5.3.
Рисунок 5.3. Операция логического сдвига вправо
Математически LSR эквивалентен беззнаковому делению на 2^n, или операции >> над беззнаковыми значениями в C. При компиляции компиляторы часто заменяют деление беззнаковых целых чисел на постоянную степень двойки логическим сдвигом вправо.
Ниже показан пример логического сдвига вправо на 3 позиции:
Операция арифметического сдвига вправо похожа на LSR: все биты исходного регистра сдвигаются вправо, а выходящие за границу биты отбрасываются. Отличие состоит в том, что слева в значение сдвигаются копии знакового, то есть старшего значащего, бита исходного значения. См. рис. 5.4.
Рисунок 5.4. Операция арифметического сдвига вправо
Математически ASR эквивалентен знаковому делению на 2^n. В C эта операция представляется оператором >> над знаковыми числами, например значениями типа signed int.
Ниже показан пример арифметического сдвига вправо на 3 позиции:
Помните, что результат этой операции зависит от размера регистра. В данном примере знаковым битом предыдущего входного значения в 32-битном регистре является бит 31, а в 64-битном - бит 63.
Операция вращения вправо выполняет циклический сдвиг битовой последовательности, как показано на рис. 5.5. Значение сдвигается вправо, как при логическом сдвиге вправо, но биты, "выпадающие за край", возвращаются в крайние левые, то есть старшие значащие, позиции значения.
Рисунок 5.5. Операция вращения вправо
Ниже показан пример вращения вправо на 3 позиции:
Наборы A32/T32 предоставляют операцию вращения вправо с расширением. Она сдвигает все биты вправо на 1 и помещает старый флаг переноса в бит 31. В отличие от других операций сдвига, RRX всегда выполняет сдвиг на 1 бит. Предположим, что регистр R0 равен 0x10, а флаг переноса установлен в 1. Ниже показано изменение битов при выполнении RRX над значением R0 и обновлении R0 результатом каждой итерации:
При использовании с суффиксом S вытесненный из регистра бит, bit[0], устанавливает флаг переноса, как показано на рис. 5.6.
Рисунок 5.6. Вращение вправо с расширением
Как и большинство инструкций обработки данных, инструкции сдвига могут получать входные данные в разных форматах. Величина сдвига n может задаваться константой, непосредственно закодированной в инструкции, либо регистром, в который n загружается во время выполнения. В этой главе мы рассмотрим разные формы инструкций и их синтаксис. В начале каждого раздела будут приведены синтаксические символы соответствующего типа инструкций. В табл. 5.1 описаны символы текущего раздела.
Таблица 5.1. Синтаксические символы
В Armv8-A большинство сдвигов на константу реализованы как псевдонимы других инструкций. Псевдонимы имеют ту же кодировку, что и лежащие в их основе формы. В табл. 5.2 непосредственные формы различных операций сдвига приведены рядом с соответствующими базовыми формами.
Таблица 5.2. Инструкции сдвига и вращения: непосредственная форма
При дизассемблировании всегда предпочитаются инструкции-псевдонимы. Например, ассемблерная инструкция MOV Rd, Rn, RRX при дизассемблировании всегда преобразуется в псевдоним RRX Rd, Rn.
Следующий код показывает примеры ассемблерных инструкций A32, которые в результате дизассемблирования преобразуются в псевдонимы. Сначала код устанавливает r0 в постоянное значение 14, а затем четырьмя разными способами выполняет сдвиг вправо на 1 бит. Обратите внимание, что RRX действует как сдвиг вправо на 1, когда флаг переноса, как здесь, равен нулю. Хотя все четыре инструкции выполняют одну операцию, в результате дизассемблирования формы инструкции перемещения преобразуются в псевдонимы.
Пример псевдонимов инструкций для непосредственных сдвигов A32
Исходный код на ассемблере
Результат дизассемблирования
Рассмотрим пример для A64. В следующем фрагменте регистр x0 сначала заполняется значением 14, а затем используется как исходный операнд в четырёх операциях сдвига. В каждом случае x0 сдвигается на 3 позиции, а результат записывается в регистр назначения x1, при этом исходные регистры остаются неизменными. Чтобы показать, что при дизассемблировании предпочитаются псевдонимы, последние четыре инструкции представляют базовые инструкции со значениями, удовлетворяющими условиям псевдонима для каждой из предыдущих инструкций сдвига и вращения. Пока можно не обращать внимания на инструкции SBFM/UBFM/EXTR: они объясняются в разделе "Перемещение битового поля".
Пример псевдонимов инструкций для непосредственных сдвигов A64
Исходный код на ассемблере
Результат дизассемблирования
Иногда программе требуется выполнить сдвиг, величина которого вычисляется во время выполнения. В таком случае применяется регистровая форма инструкций сдвига, показанная в табл. 5.3.
Таблица 5.3. Инструкции сдвига и вращения: регистровая форма
Как видно из следующего примера, при использовании эквивалентных инструкций для операций сдвига A32 дизассемблер преобразует их в псевдонимы.
Пример псевдонимов для сдвига на значение из регистра (A32)
Исходный код на ассемблере
Дизассемблирование
То же относится к операциям сдвига набора A64. Большинство инструкций преобразуются в псевдоним только при выполнении определённых условий, но регистровые формы инструкций сдвига и вращения A64 ASR, LSL, LSR и ROR предпочитаются всегда. Причина в том, что у этих инструкций есть разные формы, например ASR с регистром или ASR с непосредственным значением, а эквивалентные инструкции, оканчивающиеся на V, например ASRV, представляют самостоятельную форму сдвига регистра на значение из регистра.
Пример псевдонимов для сдвига на значение из регистра (A64)
Исходный код на ассемблере
Результат дизассемблирования
В предыдущем разделе мы увидели, что многие инструкции сдвига реализованы как псевдонимы более гибких инструкций. Например, в наборе A64 сдвиги на непосредственную константу могут быть преобразованы в инструкцию перемещения битового поля, такую как UBFM, которая относится к группе инструкций работы с битовыми полями.
Эта группа инструкций позволяет выполнять обобщённое перемещение и перестановку битов внутри значения, которые нельзя представить простым сдвигом или вращением. В табл. 5.4 приведены синтаксические символы наборов A32 и A64.
Таблица 5.4. Синтаксические символы
Инструкции перемещения битового поля, приведённые в табл. 5.5, копируют биты 0...n значения и помещают их в позиции m..m+n регистра назначения. В их синтаксисе задаются крайняя левая позиция бита #s, перемещаемого из исходного регистра, и величина вращения вправо #r, по которой вычисляется положение битового поля в регистре назначения. Остальные биты регистра назначения устанавливаются в зависимости от того, является инструкция знаковой SBFM или беззнаковой UBFM. SBFM заполняет биты слева от битового поля копиями знакового бита, а биты справа от поля - нулями. UBFM заполняет нулями обе стороны битового поля.
Таблица 5.5. Инструкции перемещения битового поля A64
Группа инструкций перемещения битовых полей доступна только в наборе A64 и обычно используется через псевдонимы, например операции сдвига и инструкции расширения, приведённые в табл. 5.6. Выбор псевдонима при дизассемблировании зависит от выполнения его условий.
Таблица 5.6. Псевдонимы инструкций перемещения битового поля A64
На рис. 5.7 показана работа инструкции SBFM, копирующей биты 3..29 из исходного регистра в регистр назначения и заполняющей крайние левые биты знаком. Если справа от битового поля остаётся свободное место, находящиеся справа биты устанавливаются в ноль.
Рисунок 5.7. Инструкция SBFM
Эта инструкция ведёт себя точно так же, как ASR, сдвигая значение вправо на 3 позиции, как показано на рис. 5.8.
Рисунок 5.8. Сдвиг значения на 3 бита
Инструкция перемещения беззнакового битового поля UBFM (см. рис. 5.9) работает сходным образом, но биты слева от поля заполняются нулями, а не копиями знакового бита.
Рисунок 5.9. Инструкция перемещения беззнакового битового поля (UBFM)
Предыдущая инструкция UBFM эквивалентна операции LSR, как показано на рис. 5.10.
Рисунок 5.10. Операция LSR
Хотя EXTR, строго говоря, не является операцией извлечения битового поля, она "извлекает" биты из указанной пары регистров. Для вычисления результата EXTR сначала объединяет два исходных операнда. Затем из объединённого значения извлекаются биты диапазона <lsb+size-1:lsb> и помещаются в регистр назначения. Здесь size - ширина регистра, то есть 32 для Wd и 64 для Xd. На рис. 5.11 это показано на примере инструкции, где из объединённого значения извлекается диапазон <3+32-1:3>, или сокращённо <34:4>.
Рисунок 5.11. Пример операции извлечения
Инструкция вращения вправо определена как псевдоним EXTR и предпочитается, когда оба исходных регистра совпадают, как показано в табл. 5.7.
Таблица 5.7. Псевдонимы инструкции извлечения регистра A64
Обратите внимание: в следующем примере кода и X0, и X1 инициализируются значением 14, однако условие преобразования EXTR в псевдоним ROR выполняется только тогда, когда регистры одинаковы, а не когда два разных регистра содержат одно значение.
Пример псевдонима инструкции вращения вправо (A64)
Исходный код на ассемблере
Результат дизассемблирования
На рис. 5.12 наглядно представлена седьмая инструкция предыдущего ассемблерного кода.
Рисунок 5.12. Иллюстрация инструкции EXTR в строке 7
При дизассемблировании эта инструкция преобразована в псевдоним. Как видно на рис. 5.13, операция эквивалентна инструкции ROR, вращающей биты исходного регистра W0 на 3 позиции.
Рисунок 5.13. Инструкция ROR
Операции знакового и нулевого расширения применяются для расширения байта, полуслова или слова со знаком либо нулями до естественной целочисленной ширины процессора. Компиляторы часто используют расширение, поскольку арифметические операции обычно выполняются над 32-битными или 64-битными, а не над 8-битными или 16-битными значениями. Например, чтобы использовать 8-битное знаковое целое число в сложении или умножении, программе необходимо сначала расширить его со знаком до 32 или 64 бит, преобразовав в 32-битное или 64-битное знаковое целое, и лишь затем выполнить арифметическую операцию.
В A64 операции нулевого и знакового расширения реализуются с помощью SBFM и UBFM. Эти инструкции извлекают байт, полуслово или слово из исходного регистра и расширяют его до размера регистра назначения, который может составлять 64 или 32 бита в зависимости от указанных регистров. Исключением является SXTW, которая обязательно всегда расширяет до 64-битного регистра. Существуют знаковые и беззнаковые версии, внутренне реализованные через SBFM и UBFM. В табл. 5.8 инструкции нулевого и знакового расширения A64 приведены рядом с их базовой реализацией через SBFM или UBFM.
Таблица 5.8. Инструкции расширения A64
Можно заметить, что в некоторых 64-битных инструкциях расширения форма псевдонима как будто принимает 32-битный источник, а соответствующая фактическая реализация - 64-битный. Например, псевдоним знакового расширения 8-битного значения до 64 бит имеет вид SXTB Xd, Wn, но внутренне реализован как SBFM Xd, Xn, #0, #7. Это может показаться ошибкой. Как эти формы могут принимать исходные регистры разных типов?
Причина заключается в различии семантического смысла SXTB и SBFM. Семантически SXTB означает "расширить это знаковое байтовое значение до 64 бит". В соответствии с другими частями синтаксиса A64 байтовые значения обозначаются 32-битной формой Wn. Но фактически SXTB реализуется обобщённой инструкцией SBFM, где исходный регистр и регистр назначения должны иметь одинаковую ширину. Поэтому 64-битная форма SXTB реализована 64-битной инструкцией SBFM, которая расширяет со знаком биты 0-8 соответствующего регистра Xn и помещает результат в соответствующий 64-битный регистр назначения. Этим и объясняется различие двух синтаксических форм.
Псевдонимы перемещения битового поля в A64
Исходный код на ассемблере
Результат дизассемблирования
На рис. 5.14 показано знаковое расширение из 8 в 32 бита в A64 с помощью инструкции SXTB. Знаковый бит 8-битного значения находится в позиции 7 и копируется в старшие 24 бита результата.
Рисунок 5.14. Знаковое расширение из 8 в 32 бита инструкцией SXTB
Та же логика применяется при знаковом расширении из 16 в 32 бита инструкцией SXTH. Здесь 16-битное значение расширяется со знаком до 32 бит, поэтому знаковый бит находится в позиции 15. На рис. 5.15 он содержит 0, следовательно, старшие 16 бит результата очищаются нулями.
Рисунок 5.15. Старшие 16 бит результата очищены
В отличие от знакового расширения, нулевое расширение преобразует небольшие беззнаковые целые числа в 32-битные или 64-битные значения. Поскольку эти целые числа строго положительны, старшие биты всегда очищаются нулями, а их предыдущее содержимое отбрасывается. На рис. 5.16 показано различие между расширением 32-битного значения до 64 бит нулями UXTW и со знаком SXTW.
Рисунок 5.16. Различие между UXTW и SXTW
В наборе A64 операции над битовыми полями, такие как знаковое и нулевое расширение, могут неявно применяться к одному из исходных операндов других инструкций. Это называется формой с расширенным регистром и заставляет исходный операнд перед основной операцией инструкции неявно сдвигаться, расширяться или выполнять оба действия.
Например, следующая инструкция сложения перед выполнением сложения неявно расширяет второй операнд нулями из 8 в 32 бита и сдвигает его влево:
На рис. 5.17 показана работа этой инструкции. Сначала из второго исходного регистра W2 берутся 8 бит, которые затем по указанию части UXTB расширяются нулями до 32 бит. Полученные биты сдвигаются влево на закодированную в инструкции неявную величину от 0 до 4, в данном случае на 4. Затем результат складывается с первым исходным регистром W1 и записывается в регистр назначения W4.
Рисунок 5.17. Инструкция ADD с операндом UXTB
В наборах A32/T32 инструкции расширения определены не как псевдонимы, а как самостоятельные инструкции. Это делает A32/T32 менее гибкими, например для выполнения 9-битного знакового расширения, но взамен операции знакового и нулевого расширения A32 и T32 могут дополнительно применять неявное вращение значения на 8, 16 или 24 позиции. Благодаря этому можно расширить со знаком или нулями внутренний байт значения. В табл. 5.9 показаны четыре базовые формы расширения битового поля A32.
Таблица 5.9. Формы расширения битового поля A32
A32 также предоставляет более сложные операции знакового и нулевого расширения для векторных расширений и совмещённых операций расширения со сложением. Они приведены в табл. 5.10.
Некоторые из этих инструкций помечены как "двойные" и содержат в мнемонике число 16, например SXTB16, SXTAB16, UXTB16 и UXTB16. Они не расширяют извлечённые биты до 32 бит. Вместо этого из исходного регистра извлекаются два 8-битных значения, каждое из которых расширяется нулями до 16 бит.
Таблица 5.10. Инструкции знакового и нулевого расширения A32
Инструкции извлечения и вставки битового поля копируют поле из заданного исходного регистра в регистр назначения. Их синтаксис приведён в табл. 5.11.
Таблица 5.11. Инструкции извлечения и вставки битового поля
Хотя эти инструкции выглядят довольно сложными, расшифровать их проще, чем кажется. Каждая копирует непрерывную последовательность битов из исходного регистра и помещает её в некоторое место регистра назначения. Число извлекаемых битов всегда задаётся непосредственной константой width, закодированной в инструкции. В зависимости от выбранной инструкции операция может:
• поместить биты в результат, не изменяя окружающие биты; заменить все остальные биты нулями; либо заменить биты слева от поля копиями знакового бита, а биты справа - нулями;
• использовать lsb для задания позиции бита в исходном регистре либо позиции в регистре назначения, куда будет скопирована последовательность.
Чтобы определить, изменятся ли биты до и после поля в регистре назначения, сначала посмотрите на первую букву мнемоники. U означает беззнаковую операцию, S - знаковую, а B - отсутствие обоих вариантов.
• U: беззнаковая операция. Биты вокруг поля устанавливаются в ноль.
• S: знаковая операция. Биты слева от поля заполняются копиями знакового бита, а справа - нулями.
• B: операция над битовым полем. Окружающие биты не изменяются.
На рис. 5.18 показан пример вставки битового поля BFI. Здесь width равно 5, а lsb равно 10: из исходного регистра копируются 5 битов и помещаются в позиции 10-14 регистра назначения без изменения окружающих битов.
Рисунок 5.18. Вставка битового поля (BFI)
Далее нужно определить, описывает ли lsb позицию, из которой следует копировать в исходном регистре, то есть операцию извлечения, или позицию назначения, куда следует копировать, то есть операцию вставки. Мнемоники операций извлечения содержат X, а вставки - I. В операциях извлечения битового поля SBFX, UBFX и BFXIL параметр lsb задаёт начальную позицию копирования в исходном регистре, а в операциях вставки SBFIZ, UBFIZ и BFI - начальную позицию вставки поля в регистре назначения.
Единственное исключение из правила мнемоник - инструкция извлечения битового поля и вставки в младшие биты BFXIL, имя которой содержит и X, и I. Достаточно помнить, что L означает "младшие": эта инструкция извлекает (X) битовое поле (BF) и вставляет (I) его в младшие (L) биты регистра назначения.
На рис. 5.19 показаны примеры инструкций вставки и извлечения битового поля. В каждом случае заданы одинаковые lsb и width, но положение поля в регистре назначения зависит от того, выполняется вставка или извлечение.
Рисунок 5.19. Инструкции вставки и извлечения битового поля
В A64 все операции извлечения и вставки битового поля внутренне определены через три мощные обобщённые инструкции: BFM и её знаковый и беззнаковый варианты SBFM и UBFM. Операции извлечения и вставки являются их псевдонимами и предпочитаются, когда выполняются приведённые в табл. 5.12 условия. Значения синтаксических символов, например #r и #s, остаются теми же, что перечислены в табл. 5.4.
Таблица 5.12. Инструкции перемещения битового поля A64
Логические инструкции работают на уровне битов, выполняя побитовую операцию над одним или несколькими входными значениями. В A64 логические операции с двумя операндами, такие как AND и ORR, могут получать входные данные из двух регистров, из регистра и непосредственно закодированной в инструкции константы либо из двух регистров, один из которых перед использованием неявно сдвигается.
По умолчанию логические инструкции A64 не устанавливают флаги условий. Однако AND и BIC могут дополнительно устанавливать их по результату, если к инструкции добавить суффикс S, то есть использовать ANDS или BICS. Инструкция TST всегда устанавливает флаги условий по результату.
Операция побитового И вычисляет результат, выполняя логическое И для каждой пары битов двух входных значений во всех позициях, как показано в табл. 5.13.
Таблица 5.13. Таблица истинности операции И
Концептуально побитовое И можно рассматривать как операцию выбора определённых битов значения с очисткой остальных до нуля. Например, чтобы оставить только восемь младших битов и отбросить остальные, можно выполнить побитовое И значения с маской 0b11111111 (255).
Различные формы AND для наборов A64 и A32/T32 перечислены в табл. 5.14. ANDS имеет те же формы, но, в отличие от AND, устанавливает флаги условий. По результату операции ANDS устанавливает арифметические флаги N и Z, а V сбрасывает в ноль. Обычно C также сбрасывается в ноль, однако если второй операнд вычисляется, а не берётся непосредственно из регистра или константы, C может быть установлен по результату этого вычисления.
Таблица 5.14. Операции побитового И
В формах со сдвинутым регистром операцией сдвига может быть LSL, LSR, ASR или ROR.
Инструкция побитовой проверки TST используется для выяснения, равен ли единице хотя бы один бит из заданного набора. Например, чтобы выполнить условный переход, если один из двух младших битов равен 1, программист может использовать tst x0, #3, а затем условный переход на основе арифметических флагов.
TST устанавливает арифметические флаги так, словно над теми же входными значениями была выполнена ANDS, но не сохраняет результат в регистре. В A32/T32 TST определена как самостоятельная инструкция, а в A64 является псевдонимом ANDS с нулевым регистром назначения, как показано в табл. 5.15.
Таблица 5.15. Псевдонимы инструкции побитового И A64
Инструкция побитовой очистки BIC выполняет задачу, сходную с AND. Она используется для очистки определённых битов входного значения. BIC Rd, Rn, Rm функционально эквивалентна присваиванию Rd результата побитового И Rn и побитовой инверсии значения Rm. Синтаксис BIC в A32/T32 и A64 приведён в табл. 5.16.
Таблица 5.16. Синтаксис инструкции побитовой очистки
Операция побитового ИЛИ ORR вычисляет результат, выполняя логическое ИЛИ для каждой пары битов двух входных значений во всех позициях. Таблица истинности логического ИЛИ приведена в табл. 5.17.
Концептуально побитовое ИЛИ полезно для принудительной установки заданных битов значения в 1 без изменения остальных. Например, чтобы установить два младших бита и сохранить прочие, можно выполнить побитовое ИЛИ результата со значением 0b11 (3).
Таблица 5.17. Таблица истинности операции ИЛИ
В табл. 5.18 приведены формы инструкций ИЛИ и соответствующий синтаксис. В A32/T32 для обновления флагов условий по результату также можно использовать ORRS.
Таблица 5.18. Синтаксис инструкции побитового ИЛИ
При использовании форм со сдвинутым регистром операцией сдвига может быть LSL, LSR, ASR или ROR.
Инструкция побитового ИЛИ-НЕ ORN похожа на ORR, но сначала инвертирует второй параметр, а затем применяет логическую операцию ИЛИ. Компиляторы часто используют её для побитового ИЛИ с непосредственным значением, которое нельзя эффективно закодировать непосредственно в ORR, но можно представить в ORN.
В табл. 5.19 показаны результат операции ИЛИ над двумя битами a и b и инвертированные биты после операции НЕ.
Таблица 5.19. Таблица истинности операции ИЛИ-НЕ
В наборах A32/T32 инструкция ORNS выполняет ту же операцию, что и ORN, но устанавливает арифметические флаги условий по результату.
В табл. 5.20 приведены формы операций ИЛИ-НЕ и соответствующий синтаксис.
Таблица 5.20. Синтаксис инструкции побитового ИЛИ-НЕ
В форме со сдвинутым регистром операцией сдвига может быть LSL, LSR, ASR или ROR. В наборе A64 эта форма ORN используется псевдонимом MVN. Операция записывает в регистр назначения побитовую инверсию исходного регистра, как показано в табл. 5.21.
Таблица 5.21. Форма инструкции побитового ИЛИ-НЕ со сдвинутым регистром
Операция побитового исключающего ИЛИ (EOR, или XOR) вычисляет результат, выполняя логическое исключающее ИЛИ для каждой пары битов двух входных значений во всех позициях. Таблица истинности приведена в табл. 5.22.
Таблица 5.22. Таблица истинности исключающего ИЛИ
Концептуально исключающее ИЛИ полезно, когда требуется переключить определённые биты значения из 1 в 0 или из 0 в 1. Например, для кнопки, которая при каждом нажатии включает или выключает светодиод, программа может прочитать состояние светодиода, переключить его операцией исключающего ИЛИ и записать обратно в контроллер.
В табл. 5.23 приведены формы EOR и соответствующий синтаксис.
Таблица 5.23. Синтаксис инструкции побитового исключающего ИЛИ
Инструкция побитовой проверки эквивалентности TEQ используется для проверки, равны ли 1 все биты заданного набора. Например, чтобы выполнить условный переход, если оба младших бита равны 1, программист может использовать инструкцию teq x0, #3, а затем условный переход на основе арифметических флагов.
TEQ устанавливает арифметические флаги так, словно над теми же входными значениями была выполнена EOR, но не сохраняет результат в регистре. TEQ реализована как самостоятельная инструкция и в A32/T32, и в A64, а не как частный случай EOR, поскольку в A64 нет инструкции EORS.
Набор A64 также поддерживает инструкцию исключающего ИЛИ-НЕ EON, хотя на практике она используется редко. EON Xd, Xn, Xm выполняет исключающее ИЛИ значения Xn и побитовой инверсии Xm, после чего записывает результат в Xd.
В табл. 5.24 приведены формы операций исключающего ИЛИ-НЕ и соответствующий синтаксис.
Таблица 5.24. Синтаксис инструкции побитового исключающего ИЛИ-НЕ
Самые распространённые и простые для понимания арифметические инструкции - сложение и вычитание. Возможно, вы задаётесь вопросом, почему они не были представлены первыми. В этом разделе вы увидите, что синтаксис арифметических инструкций включает операции сдвига и вращения. Теперь, когда вы понимаете их работу, будет проще разобраться в их сочетании с арифметическими инструкциями. Поэтому в табл. 5.25 представлены синтаксические символы сдвига и расширения, используемые для описания форм арифметических инструкций этого раздела. Некоторые инструкции содержат в синтаксисе операнд в фигурных скобках, что обозначает необязательный операнд.
Операции сложения и вычитания часто встречаются при обратной разработке программ. На первый взгляд они очевидны: складывают или вычитают входные значения. Однако существуют более сложные формы, заслуживающие рассмотрения.
Разные формы инструкций сложения и вычитания перечислены в табл. 5.26.
Таблица 5.25. Синтаксические символы
Таблица 5.26. Формы инструкций ADD и SUB
Следующий код, скомпилированный для A32, сначала задаёт значения регистров r1, r2 и r3, а затем использует их в серии операций сложения и вычитания. Поскольку безусловные арифметические инструкции выполняются последовательно, необходимо помнить: после изменения регистра его прежнее значение стирается, а в следующих инструкциях используется новое. При выполнении инструкции меняется только регистр назначения, исходные регистры остаются неизменными.
Пример инструкций ADD и SUB в A32
Следующий пример показывает инструкции сложения и вычитания A64. Обратите внимание: в A64 операции сложения и вычитания могут неявно сдвигать и расширять операнды во время выполнения.
Пример инструкций ADD и SUB в A64
Операция обратного вычитания RSB, как следует из названия, выполняет вычитание с переставленными операндами. То есть RSB Rd, Rn, #const задаёт Rd равным const - Rn. Эта инструкция существует только в наборах A32/T32. Её также можно использовать с суффиксом S в форме RSBS для установки флагов условий по результату. Синтаксис форм инструкции RBS в A32 показан в табл. 5.27.
Таблица 5.27. Формы инструкции RBS в A32
Инструкция сравнения CMP сравнивает два числа, чтобы определить, равны ли они, а если нет, какое больше, обычно в контексте условного выполнения. Условное выполнение подробнее рассматривается в главе 7.
Внутренне CMP устанавливает арифметические флаги так, словно была выполнена SUBS с теми же исходными аргументами, и отбрасывает результат. В A64 CMP определена как псевдоним SUBS с нулевым регистром назначения. Формы инструкции сравнения приведены в табл. 5.28.
Таблица 5.28. Формы инструкции сравнения CMP
Инструкция сравнения с отрицательным значением CMN складывает два операнда и устанавливает флаги по результату вместо выполнения вычитания. Она полезна, когда у программиста есть значения m и n и требуется узнать, выполняется ли m = -n. CMN также может быть полезна, если n нельзя закодировать в CMP как непосредственную константу, но -n можно закодировать в CMN. В таком случае компилятор может выбрать CMN вместо CMP.
Синтаксис CMN в A64 и A32/T32 похож на синтаксис CMP из табл. 5.28.
В A64 CMN определена как псевдоним ADDS. Вместо сохранения результата регистром назначения служит нулевой регистр WZR или XZR, отбрасывающий результат, как показано в табл. 5.29.
Таблица 5.29. Формы и псевдонимы инструкции сравнения с отрицательным значением CMN в A64
Инструкции, устанавливающие флаги, такие как CMP, CMN и инструкции с суффиксом S, например ADDS и SUBS, могут устанавливать следующие флаги условий:
• Флаг отрицательного результата N:
• 1, если результат отрицательный;
• 0, если результат положительный или нулевой.
• Флаг нулевого результата Z:
• 1, если результат равен нулю, что указывает на равенство;
• 0 в остальных случаях.
• Флаг переноса C:
• 1, если инструкция дала перенос, например беззнаковое переполнение при сложении;
• 0 в остальных случаях.
• Флаг переполнения V:
• 1, если инструкция дала переполнение, например знаковое переполнение при сложении.
Использование флагов условий при условном выполнении подробнее рассматривается в главе 7. Следующий код показывает примеры флагов, устанавливаемых инструкциями сравнения CMP и CMN набора A64, и демонстрирует, как их эквивалентные инструкции SUBS или ADDS интерпретируются при дизассемблировании.
Примеры инструкций CMN и CMP в A64
Исходный код на ассемблере
Результат дизассемблирования
В Armv8-A инструкции умножения и их более сложные формы, такие как умножение со сложением, всегда получают операнды из регистров, а не из непосредственных констант. В табл. 5.30 перечислены основные инструкции умножения наборов A32/T32 и A64.
Хотя это главные инструкции умножения и именно они чаще всего встречаются при обратной разработке, 32-битные наборы Armv8-A также предоставляют множество вариантов умножения для оптимизированных векторных упакованных операций. Например, A32/T32 позволяют умножить два 32-битных исходных операнда, получив 64-битный результат, разделённый между двумя 32-битными регистрами назначения.
Таблица 5.30. Основные инструкции целочисленного умножения
В A64 доступны дополнительные инструкции для знакового или беззнакового умножения 32 на 32 бита либо 64 на 64 бита, иногда с последующим сложением, вычитанием или отрицанием результата. Они строятся на базовых инструкциях умножения со сложением и умножения с вычитанием[2]. Например, умножение с отрицанием кодируется как умножение с вычитанием, где первым исходным операндом служит нулевой регистр.
Эти инструкции и выполняемые ими внутренние операции приведены в табл. 5.31.
Таблица 5.31. Инструкции знакового и беззнакового умножения A64
Кроме того, A64 позволяет умножить 64 на 64 бита и получить 128-битный результат. Поскольку 64-битные регистры A64 не вмещают 128-битное значение, программист должен выбрать для регистра назначения старшие или младшие 64 бита результата. UMULL и UMULH выполняют такое беззнаковое умножение и выбирают соответственно младшие и старшие 64 бита 128-битного результата, а SMULL и SMULH выполняют ту же функцию для знаковых 64-битных входных значений.
Пример умножений в A64
По сравнению с A64 наборы A32/T32 предоставляют головокружительное множество инструкций для разных видов умножения. В табл. 5.32 приведены все инструкции умножения A32/T32, их синтаксис и базовое действие.
Таблица 5.32. Инструкции умножения A32
* Используются старшие 32 бита 48-битного произведения. Младшие биты отбрасываются.
** Используются старшие 32 бита 64-битного произведения. Младшие биты отбрасываются.
Вместо отдельного рассмотрения каждого варианта умножения их можно объединить в сходные категории. Каждая инструкция может работать с полными или частичными значениями регистров, выдавая 32-битный или 64-битный результат:
• умножения младших значащих слов;
• умножения старших значащих слов;
• умножения полуслов, то есть 16-битных значений;
• векторные, или двойные, умножения;
• длинные, то есть 64-битные, умножения.
Только три инструкции умножения в этих группах являются беззнаковыми, остальные работают со знаковыми входными значениями.
Начнём с умножений младших и старших значащих слов. Они получают два 32-битных входных значения, создают 64-битный результат и сохраняют в регистре его младшие или старшие 32 бита.
Инструкции умножения младших значащих слов A32/T32 получают два 32-битных значения, перемножают их с получением 64-битного результата и сохраняют его младшие 32 бита, иногда дополнительно прибавляя или вычитая третье 32-битное значение. Они приведены в табл. 5.33.
Таблица 5.33. Умножения младших значащих слов A32
Как показано на рис. 5.20, MUL умножает два хранящихся в регистрах 32-битных входных значения с получением 64-битного результата и сохраняет его младшие 32 бита в регистре назначения. В синтаксисе A32/T32 второй исходный регистр можно опустить, если регистр назначения также служит одним из исходных. То есть MUL Rd, Rn эквивалентна MUL Rd, Rn, Rd и кодируется так же. Мнемоника MULS также позволяет установить арифметические флаги по результату.
Рисунок 5.20. Инструкция MUL
Как показано на рис. 5.21, инструкция умножения с накоплением MLA расширяет MUL, выполняя дополнительное сложение после вычисления произведения. Она умножает два 32-битных значения из регистров, прибавляет третье 32-битное значение из третьего исходного регистра и записывает итоговый 32-битный результат в регистр назначения. Как и MUL, MLA может устанавливать по результату арифметические флаги N и Z с помощью мнемоники MLAS.
Рисунок 5.21. Инструкция умножения с накоплением (MLA)
Инструкция MLS умножает два 32-битных входных значения, сохраняет младшие 32 бита 64-битного результата и вычитает это значение из третьего исходного регистра. Здесь важен порядок: произведение вычитается из Ra, а не наоборот, как показано на рис. 5.22.
Рисунок 5.22. Инструкция умножения с вычитанием (MLS)
Инструкции умножения старших значащих слов A32/T32 получают два 32-битных значения, перемножают их с получением 64-битного результата и сохраняют его старшие 32 бита, иногда дополнительно прибавляя или вычитая третье 32-битное значение. Они приведены в табл. 5.34.
Таблица 5.34. Умножения старших значащих слов A32
* Используются старшие 32 бита 64-битного произведения. Младшие биты отбрасываются.
Инструкция SMMUL выполняет знаковое умножение двух 32-битных входных значений с получением 64-битного результата и сохраняет его старшие 32 бита в регистре назначения, как показано на рис. 5.23.
Рисунок 5.23. Инструкция SMMUL
В отличие от MUL, SMMUL не может устанавливать арифметические флаги по результату. Однако мнемоника SMMULR позволяет округлить результат вместо усечения. Математически это эквивалентно прибавлению 0x80000000 к 64-битному результату до извлечения старшего 32-битного слова.
Как и формы для младших значащих слов, умножения старших слов могут выполнять дополнительное сложение. Поэтому SMMLA вычисляет произведение двух 32-битных значений с получением 64-битного результата, сохраняет его старшие 32 бита и прибавляет 32-битное значение из третьего регистра, как показано на рис. 5.24. Итоговый 32-битный результат записывается в регистр назначения.
Рисунок 5.24. Инструкция SMMLA
Как и SMMUL, SMMLA не может устанавливать арифметические флаги по результату, но мнемоника SMMLAR позволяет округлить результат вместо простого усечения. Математически это эквивалентно прибавлению 0x80000000 к 64-битному результату до извлечения старшего 32-битного слова.
Инструкция SMMLS выполняет знаковое умножение двух 32-битных входных значений с получением 64-битного результата, сохраняет его старшие 32 бита, а затем вычитает это произведение из 32-битного значения третьего исходного регистра и записывает результат в регистр назначения. Процесс показан на рис. 5.25.
Рисунок 5.25. Инструкция SMMLS
Как и SMMUL, SMMLS не может устанавливать арифметические флаги по результату, но мнемоника SMMLSR позволяет округлить результат вместо усечения. Математически это эквивалентно прибавлению 0x80000000 к 64-битному результату до извлечения старшего 32-битного слова.
Инструкции умножения полуслов позволяют умножать на 16-битное значение. Они представлены двумя формами: умножением 16 на 16 бит и умножением 32 на 16 бит.
Группа умножения 16 на 16 бит предоставляет четыре варианта каждой инструкции, позволяя использовать старшие или младшие 16 бит каждого входного значения. Выбор обозначается двумя последними буквами инструкции: BB, BT, TB или TT. B означает использование младших 16 бит исходного регистра, а T - старших. Например, TB указывает, что первое 16-битное значение берётся из старших 16 бит Rn, а второе - из младших 16 бит Rm.
Группа умножения 32 на 16 бит предоставляет два варианта каждой инструкции в зависимости от того, берётся ли 16-битное значение из старшей или младшей половины второго операнда. Такие инструкции оканчиваются на WT или WB, обозначая умножение слова соответственно на старшее либо младшее полуслово.
Как и другие инструкции умножения, эти операции могут дополнительно выполнять неявное сложение, хотя неявное вычитание при умножении полуслов невозможно. Синтаксис и операции умножения полуслов A32 показаны в табл. 5.35.
Таблица 5.35. Умножения полуслов A32
* Используются старшие 32 бита 48-битного произведения. Младшие биты отбрасываются.
Все инструкции группы знакового умножения полуслов SMULBB, SMULBT, SMULTB и SMULTT умножают два 16-битных полуслова с получением 32-битного результата и записывают его в регистр назначения, как показано в табл. 5.36 и на рис. 5.26.
Таблица 5.36. Инструкции знакового умножения полуслов A32
Рисунок 5.26. Группа инструкций знакового умножения полуслов SMULBB, SMULBT, SMULTB и SMULTT
Инструкции SMLABB, SMLABT, SMLATB и SMLATT умножают два 16-битных полуслова с получением 32-битного результата, а затем прибавляют его к другому 32-битному значению, указанному в Ra. Итоговый результат записывается в Rd, как показано в табл. 5.37 и на рис. 5.27.
Таблица 5.37. Инструкции знакового умножения полуслов с накоплением A32
Эта инструкция выполняет знаковое умножение 32-битного значения из первого исходного регистра Rn на старшее или младшее 16-битное полуслово второго исходного регистра Rm. Умножение 32 на 16 бит даёт 48-битный результат, старшие 32 бита которого записываются в Rd. См. табл. 5.38 и рис. 5.28.
Рисунок 5.27. Группа инструкций знакового умножения полуслов с накоплением SMLABB, SMLABT, SMLATB и SMLATT
Таблица 5.38. Инструкции знакового умножения слова на полуслово A32
* Используются старшие 32 бита 48-битного произведения. Младшие биты отбрасываются.
Рисунок 5.28. Инструкция знакового умножения слова на полуслово
Эта группа работает аналогично знаковому умножению слова на полуслово, но выполняет заключительное 32-битное сложение.
Как видно из табл. 5.39, инструкции умножают 32-битное значение на 16-битное, взятое из старших или младших 16 бит второго операнда, и получают 48-битный результат. Затем инструкция сохраняет старшие 32 бита этого произведения, прибавляет к нему 32-битное значение и записывает итог в Rd. См. рис. 5.29.
Таблица 5.39. Инструкции умножения слова на полуслово с накоплением A32
* Используются старшие 32 бита 48-битного произведения. Младшие биты отбрасываются.
Рисунок 5.29. Группа инструкций знакового умножения слова на полуслово с накоплением
Векторные, или двойные, инструкции выполняют два 16-битных умножения, получая два 32-битных результата, после чего объединяют их другой математической операцией.
Двойное умножение прибавляет произведение старших полуслов обоих исходных регистров к произведению младших полуслов. Существуют два способа указать полуслова. Если инструкция оканчивается на D, умножаются старшие полуслова Rn и Rm, а результат складывается с произведением младших половин. Если инструкция оканчивается на X, полуслова второго регистра Rm меняются местами, создавая умножения старшего на младшее и младшего на старшее.
Группа векторного, или двойного, умножения содержит четыре группы инструкций:
• знаковое двойное умножение со сложением SMUAD{X};
• знаковое двойное умножение с вычитанием SMUSD{X};
• знаковое двойное умножение с накоплением SMLAD{X};
• знаковое двойное умножение с вычитанием и накоплением SMLSD{X}.
SMUAD знаково умножает старшие 16 бит значений Rn и Rm, а затем прибавляет результат к произведению младших полуслов. SMUADX перед умножением меняет местами полуслова Rm. См. табл. 5.40 и рис. 5.30.
Таблица 5.40. Инструкции знакового двойного умножения со сложением A32
Рисунок 5.30. Инструкция SMUAD
SMUSD работает сходным с SMUAD образом, но произведения младших и старших полуслов вычитаются друг из друга, а не складываются. См. табл. 5.41 и рис. 5.31.
Таблица 5.41. Инструкции знакового двойного умножения с вычитанием A32
Рисунок 5.31. Инструкция SMUSD
Инструкция SMLAD, представленная в табл. 5.42, складывает произведение старших полуслов обоих исходных регистров с произведением младших полуслов. Результат прибавляется к накопительному значению Ra и записывается в Rd. Буква X в конце инструкции указывает, что перед операцией старшая и младшая половины второго исходного регистра Rm меняются местами. См. рис. 5.32.
Таблица 5.42. Инструкции знакового двойного умножения с накоплением A32
Рисунок 5.32. Инструкция знакового двойного умножения с накоплением (SMLAD)
Инструкция SMLSD, представленная в табл. 5.43, вычитает произведение младших полуслов из произведения старших. Результат прибавляется к накопительному значению Ra и записывается в Rd. Буква X в конце указывает, что перед операцией старшая и младшая половины Rm меняются местами. См. рис. 5.33.
Таблица 5.43. Инструкции знакового двойного умножения с вычитанием и накоплением A32
Рисунок 5.33. Инструкция знакового двойного умножения с вычитанием и накоплением (SMLSD)
Все рассмотренные до сих пор умножения A32/T32 работают с входными значениями шириной не более 32 бит. Для 64-битных умножений в A32/T32 нужны "длинные" инструкции. Они необычны тем, что используют два регистра назначения: RdLo для младших 32 бит и RdHi для старших 32 бит результата. Синтаксис приведён в табл. 5.44.
Таблица 5.44. Обзор длинных умножений A32
Инструкция знакового длинного умножения SMULL и её беззнаковый аналог UMULL перемножают два значения с получением 64-битного произведения. Результат разделяется между двумя 32-битными регистрами назначения: RdLo получает младшие 32 бита, а RdHi - старшие. Синтаксис приведён в табл. 5.45, а работа показана на рис. 5.34.
Таблица 5.45. Инструкции знакового длинного умножения A32
Рисунок 5.34. Инструкция знакового длинного умножения (SMULL)
Рассмотрим пример, где r5 и r6 служат регистрами назначения для умножения r1 и r2. Внутренне значения исходных регистров расширяются со знаком до 64 бит в дополнительном коде и перемножаются с получением 64-битного значения. Затем результат разделяется между регистрами назначения, как показано на рис. 5.35:
Рисунок 5.35. Результат, разделённый между r5 и r6
Беззнаковая версия этой инструкции, беззнаковое длинное умножение, выполняет ту же операцию, но без знака.
Группа SMLAL и UMLAL выполняет знаковое или беззнаковое умножение двух исходных регистров, а затем прибавляет к произведению 64-битное значение. Синтаксис этой инструкции, что может сбить с толку, не содержит пятого исходного регистра для накопительного значения. Причина в том, что исходное 64-битное накопительное значение находится в самих регистрах назначения. Иными словами, операция вычисляет RdHi:RdLo += Rn*Rm. Итог разделяется между двумя регистрами назначения, перезаписывая прежнее накопительное значение. См. рис. 5.36.
В табл. 5.46 приведён синтаксис длинного умножения с накоплением A32/T32.
Таблица 5.46. Инструкции длинного умножения с накоплением A32
Рисунок 5.36. Инструкция длинного умножения с накоплением A32/T32
A32/T32 также предоставляет, несмотря на несколько запутанное название, инструкцию длинного умножения с двойным накоплением UMAAL. Она перемножает два беззнаковых 32-битных значения с получением 64-битного значения, прибавляет два 32-битных значения и разделяет итоговые 64 бита между двумя 32-битными регистрами назначения.
Синтаксис UMAAL приведён в табл. 5.47.
Таблица 5.47. Инструкция беззнакового длинного умножения с двойным накоплением A32
Работа UMAAL показана на рис. 5.37.
Рисунок 5.37. Инструкция UMAAL
Группа инструкций знакового длинного умножения полуслов с накоплением SMLALxx умножает выбранное полуслово каждого исходного регистра на выбранное полуслово другого. Отдельные полуслова обозначаются B для младших и T для старших 16 бит каждого исходного регистра. Произведение прибавляется к 64-битному накопительному значению в двух регистрах назначения, которые затем перезаписываются результатом. Инструкции перечислены в табл. 5.48, а их работа показана на рис. 5.38.
Таблица 5.48. Инструкции знакового длинного умножения полуслов с накоплением A32
Рисунок 5.38. Группа инструкций знакового длинного умножения полуслов с накоплением
Эта инструкция прибавляет произведение знаковых старших половин обоих исходных регистров к произведению их знаковых младших половин. Результат прибавляется к 64-битному накопительному значению, разделённому между RdHi и RdLo. Затем 64-битный результат записывается обратно в эти же регистры назначения.
Синтаксис приведён в табл. 5.49.
Таблица 5.49. Инструкции знакового длинного двойного умножения с накоплением A32
На рис. 5.39 показана работа SMLALD.
Рисунок 5.39. SMLALD
Ниже приведён пример внутреннего вычисления результата для читателей, которым интересны подробности. Предположим, SMLALD получает следующие регистры:
Сначала SMLALD разделяет значения исходных регистров, извлекает их старшие полуслова, умножает как знаковые значения и использует младшие 32 бита результата. Перед умножением старшие полуслова r1 и r2 расширяются со знаком:
Та же процедура применяется к младшим полусловам: второе умножение 16 на 16 бит даёт 32-битный результат:
Эти два 32-битных результата складываются и расширяются со знаком до 64 бит:
Наконец, расширенный со знаком результат прибавляется к 64-битному накопительному значению, составленному из R5 и R6. R5 содержит его младшие 32 бита, а R6 - старшие:
Эта инструкция работает так же, как её вариант с накоплением, но выполняет вычитание вместо сложения. Синтаксис приведён в табл. 5.50.
Таблица 5.50. Инструкции знакового длинного двойного умножения с вычитанием A32
Внутренняя работа SMLSLD показана на рис. 5.40.
Рисунок 5.40. Инструкция знакового длинного двойного умножения с вычитанием
Удивительно, но при всём разнообразии и сложности умножений Armv8-A деление во всех трёх наборах инструкций устроено очень просто. Оно всегда получает два входных значения из регистров, делит первое на второе и помещает результат в регистр назначения. Деление может быть знаковым или беззнаковым, всегда использует регистровые входные значения и всегда округляет к нулю, а не к минус бесконечности. Если второй параметр равен нулю и должно произойти деление на ноль, архитектура Armv8-A определяет результат операции равным нулю, который записывается в регистр назначения.
Обзор инструкций деления приведён в табл. 5.51.
Таблица 5.51. Обзор инструкций деления
Инструкция MOV устанавливает значение регистра назначения в непосредственную константу, что называется перемещением непосредственного значения, или копирует значение одного регистра в другой, что называется регистровым перемещением. В Armv8-A большинство встречающихся при дизассемблировании инструкций перемещения непосредственного значения фактически реализованы через несколько базовых инструкций перемещения и скрыты за псевдонимом MOV. Например, в A64 такие инструкции всегда являются псевдонимами MOVZ, MOVN или ORR. В табл. 5.52 приведены синтаксические символы инструкций перемещения A32 и A64.
Таблица 5.52. Синтаксические символы
ISA Armv8-A предоставляет удивительно разнообразные способы перемещения непосредственной константы в регистр. Причина в том, что в зависимости от набора инструкции имеют ширину 2 или 4 байта. Поэтому в кодировке недостаточно места для универсальной инструкции "переместить любую 32-битную константу в регистр". Вместо неё ISA предоставляет несколько инструкций типа MOV для загрузки часто встречающихся констант одной инструкцией, а произвольные константы строятся в регистре отдельными инструкциями, распределёнными по двум или более командам.
В табл. 5.53 приведены синтаксис базовых инструкций MOV в A32 и T32 и их интерпретация при дизассемблировании.
Таблица 5.53. Инструкции перемещения непосредственного значения A32
A32 предоставляет две кодировки перемещения константы в регистр: MOV и MOVW. MOVW дословно загружает в регистр 16-битное непосредственное значение от 0 до 65535. MOV, напротив, загружает 8-битное непосредственное значение, а затем применяет к нему настраиваемое вращение вправо, охватывая другой диапазон возможных значений. T32 предоставляет три кодировки: MOV, MOV.W и MOVW. Они загружают соответственно базовую 16-битную непосредственную константу; 8-битное значение с преимуществом более короткой 16-битной кодировки; либо константу, которую согласно сложным правилам можно выразить через 8-битную последовательность с определённым повторяющимся узором или вращением.
Внутренняя механика этих инструкций не особенно важна для обратной разработки. Главное понимать, что не все константы можно непосредственно закодировать в MOV, а даже определение точного множества констант, представимых одной инструкцией, обманчиво сложно. Если при ручном написании ассемблерного кода указать для MOV константу, которую невозможно закодировать ни в одной форме, ассемблер выдаст ошибку, например:
В таких случаях на помощь приходит MOVT. Она устанавливает старшие 16 бит регистра в заданное 16-битное непосредственное значение, не изменяя младшие 16 бит. Поэтому и в A32, и в T32 любое 32-битное значение можно загрузить в регистр двумя инструкциями. Первая выполняет 16-битную MOV, заполняя младшие 16 бит, а вторая устанавливает старшие 16 бит инструкцией MOVT:
Все инструкции A64 кодируются 32 битами, поэтому сталкиваются с той же основной проблемой, что и A32: не всякую константу можно загрузить одной инструкцией. В A64 существуют три основные формы непосредственного перемещения: перемещение широкого непосредственного значения, перемещение инвертированного непосредственного значения и перемещение непосредственной битовой маски. Внутренне они реализованы соответственно инструкциями MOVZ, MOVN и ORR. Формы приведены в табл. 5.54.
Таблица 5.54. Инструкции перемещения непосредственного значения A64
Инструкция широкого перемещения с нулём MOVZ кодирует 16-битное непосредственное значение, копируемое в регистр назначения, и устанавливает остальные биты регистра в ноль. Величина сдвига интерпретируется как <shift>/16 и может быть равна 0 или 16. Значения, отличающиеся от 0, 16, 32 или 48, округляются вниз. Поэтому MOVZ можно закодировать так, чтобы 16-битное значение оказалось в позициях 0...15, 16...31, 32...47 или 48...63 регистра назначения.
Инструкция широкого перемещения с НЕ MOVN помещает в регистр назначения инверсию необязательно сдвинутого 16-битного непосредственного значения, устанавливая остальные биты в единицы. MOVN можно закодировать для помещения 16-битного значения в позиции 0...15, 16...31, 32...47 или 48...63.
Наконец, перемещение непосредственной битовой маски позволяет эффективно загружать определённые константы, часто используемые в операциях битового маскирования, то есть такие, двоичное представление которых можно выразить короткой битовой последовательностью с некоторым вращением. Внутренне эти инструкции реализованы через ORR.
Как и в A32, от специалиста по обратной разработке эти подробности реализации обычно скрыты псевдонимом MOV. Но не все константы можно выразить через MOVN, MOVZ или ORR. В таких случаях на помощь приходит широкое перемещение с сохранением MOVK.
MOVK фактически обобщает инструкцию MOVT из A32. Она записывает 16-битное значение в позиции 0...15, 16...31, 32...47 или 48...63 регистра назначения, сохраняя остальные биты неизменными. Поэтому произвольное 64-битное число можно построить в 64-битном Xn максимум одной MOV и тремя MOVK, а произвольное 32-битное число в Wn - максимум одной MOV и одной MOVK. Обзор инструкций перемещения приведён на рис. 5.41.
В простейшей форме инструкция регистрового перемещения MOV дословно копирует значение одного регистра в другой, как показано в табл. 5.55.
Для A64 синтаксис очевиден: MOV Xd, Xn копирует Xn в Xd, а MOV Wd, Wn копирует 32-битное значение Wn в Wd.
Рисунок 5.41. Инструкции перемещения
Таблица 5.55. Инструкции регистрового перемещения A32 и A64
Хотя базовое регистровое перемещение встречается чаще всего, A32 также позволяет MOV неявно сдвигать или расширять исходный регистр перед копированием в назначение. ISA использует это устройство для определения многих операций сдвига и вращения, описанных ранее в разделе "Операции сдвига и вращения". Следующий пример показывает все четыре формы из табл. 5.55 в A32 и T32 и демонстрирует, как после ассемблирования и дизассемблирования большинство сложных MOV заменяются более простыми псевдонимами.
Исходный код на ассемблере
Результат дизассемблирования
Инструкция MVN копирует значение из исходного регистра в регистр назначения, предварительно выполняя побитовое отрицание. Исходный регистр может быть сдвинут, повёрнут или расширен, как показано в табл. 5.56.
Таблица 5.56. Синтаксис инструкции перемещения с НЕ
[1] [назад]
[2] [назад]
Архитектура Arm относится к архитектурам загрузки-сохранения. Это означает, что инструкции обработки данных не работают непосредственно с данными в памяти. Если программа хочет изменить хранящиеся в памяти данные, она должна сначала загрузить их из памяти в регистры процессора инструкцией загрузки, изменить инструкциями обработки данных, а затем записать результат обратно в память инструкцией сохранения. Каждый набор инструкций Armv8-A предлагает различные формы загрузки и сохранения, которые рассматриваются в этой главе.
В наборах Arm существует множество видов инструкций загрузки и сохранения, включая несколько более сложных форм. В первой части главы рассматриваются поддерживаемые ими режимы адресации и формы смещений. Вторая часть посвящена логике инструкций и их синтаксису.
Начнём с базовых инструкций загрузки и сохранения. Инструкция загрузки регистра LDR загружает 32-битное значение из адреса памяти в регистр, как показано на рис. 6.1. Регистр R1 содержит адрес памяти, из которого выполняется загрузка, а загруженное 32-битное значение помещается в R0.
Рисунок 6.1. Инструкция LDR
Адрес памяти для загрузки или записи задаётся операндом в квадратных скобках. В данном случае это значение R1. Операнды памяти выводятся из регистра, называемого базовым регистром обращения к памяти. Полученный адрес используется для выборки данных из памяти, а найденное значение записывается в регистр передачи инструкции, в данном случае R0.
В 32-битных программах базовым регистром может быть любой регистр общего назначения, включая сам счётчик команд. В 64-битных программах им может быть любой 64-битный регистр общего назначения или указатель стека. При использовании указателя стека он должен быть выровнен по границе 16 байт, иначе возможна ошибка выравнивания стека. В A64 PC не является регистром общего назначения, поэтому доступ к памяти относительно PC разрешён только специальными инструкциями, например инструкциями загрузки литерала. Базовая форма инструкции сохранения показана на рис. 6.2.
Рисунок 6.2. Инструкция STR
Синтаксис STR в целом похож на LDR. Здесь R1 содержит адрес сохранения данных, а R0 - значение, которое будет сохранено по этому адресу. Обратите внимание на тонкое отличие от базового синтаксиса инструкций обработки данных из главы 5, где первый регистр обычно является регистром назначения, получающим результат операции. Здесь это не так: R0 содержит сохраняемое значение и не является регистром назначения. Следовательно, STR записывает 32-битное значение R0 по адресу памяти, вычисленному из базового регистра R1.
Регистр слева от операнда памяти, содержащий записываемое значение, называется регистром передачи и обычно обозначается Rt в инструкциях A32 либо Wt/Xt в A64. В инструкциях загрузки регистр передачи получает прочитанное из памяти значение, а в инструкциях сохранения содержит значение, записываемое в память.
Количество байтов, читаемых или записываемых LDR и STR, определяется размером регистра передачи. В A32 это всегда 32-битная загрузка или запись, а в A64 операция может быть 32-битной или 64-битной в зависимости от того, используется 32-битный Wt или 64-битный Xt:
С помощью специальных инструкций загрузки и сохранения можно передавать и другие типы данных, размер которых меньше регистра. Например, инструкция сохранения байта регистра STRB берёт младший байт регистра и записывает его по заданному адресу памяти. Аналогично 16-битное полуслово можно сохранить инструкцией STRH, причём записываются младшие 16 бит регистра передачи. Отдельные инструкции загрузки и сохранения, включая доступ к малым типам, будут рассмотрены далее, но сначала необходимо изучить режимы адресации и формы смещений при доступе к памяти.
В этом разделе рассматриваются различные виды и режимы доступа к памяти. Общие синтаксические обозначения и их значения приведены в табл. 6.1.
Таблица 6.1. Синтаксические символы
Режим адресации операции загрузки или сохранения определяет способ вычисления адреса доступа, а в режимах с предындексацией и постиндексацией - также способ обновления базового регистра во время операции. Эти режимы придают инструкциям гибкость, позволяя формировать адрес памяти с различными смещениями и увеличивать или уменьшать его в рамках одной операции.
Наборы A32 и A64 поддерживают следующие режимы адресации, хотя не каждая инструкция загрузки и сохранения поддерживает все режимы:
• только базовый регистр, без смещения;
• адресация со смещением, база плюс смещение;
• адресация с предындексацией;
• адресация с постиндексацией;
• литерал, относительно PC.
В режиме только базового регистра адрес берётся непосредственно из базового регистра без применения смещения.
При адресации со смещением инструкция вычисляет адрес памяти, прибавляя к базовому регистру положительное или отрицательное смещение. В зависимости от инструкции смещение может быть константой или вычисляться динамически.
При предындексации адрес вычисляется как значение базового регистра плюс смещение, и во время инструкции базовый регистр также обновляется результатом вычисления.
При постиндексации для операции с памятью используется адрес из базового регистра. Затем к нему применяется смещение, и результатом обновляется базовый регистр.
Адресация литерала относительно PC используется для загрузок позиционно-независимого кода и данных. Адрес доступа равен PC этой инструкции плюс смещение до метки относительно PC.
В табл. 6.2 показано, какие режимы обновляют базовый регистр.
Таблица 6.2. Сводка режимов адресации
Смещением может быть непосредственное значение, регистр со значением или сдвинутое регистровое значение. В табл. 6.3 приведены поддерживаемые режимы и формы смещений обычных инструкций загрузки и сохранения одного регистра A32.
Таблица 6.3. Режимы адресации и формы смещений одного регистра A32
Поддерживаемые режимы A64 и A32 различаются из-за различий кодировки даже у инструкций с одинаковым именем. Формы смещений A64 также отличаются. В табл. 6.4 приведены основные режимы и формы смещений обычных инструкций загрузки и сохранения одного регистра A64.
Таблица 6.4. Режимы адресации и формы смещений одного регистра A64[1]
Инструкции загрузки и сохранения с адресацией со смещением прибавляют смещение к базовому регистру, формируя адрес доступа к памяти. Результат этого вычисления используется только как адрес текущей инструкции, после чего отбрасывается.
A32 поддерживает следующие формы смещений:
• беззнаковое непосредственное постоянное смещение;
• регистровое смещение;
• смещение сдвинутого регистра.
A64 поддерживает:
• знаковое и беззнаковое непосредственное постоянное смещение;
• регистровое смещение, 64-битное или 32-битное;
• смещение сдвинутого или расширенного регистра, 64-битного или 32-битного.
В табл. 6.5 приведён синтаксис этих форм.
Таблица 6.5. Режим адресации со смещением и формы смещений
Простейшая форма - непосредственное постоянное смещение. Это константа, закодированная непосредственно в инструкции. Она прибавляется к адресу базового регистра, формируя адрес доступа. Синтаксис A64 требует 64-битного базового регистра Xn даже при 32-битном регистре передачи Wt.
Проще всего читать такие инструкции, считая первую запятую внутри операнда памяти знаком +. Следовательно, [Rn, #imm] означает "обратиться к памяти по адресу Rn + #imm". Поскольку непосредственная константа должна быть закодирована в самой инструкции, а инструкции имеют фиксированный размер, не все значения представимы напрямую. A32 допускает только беззнаковые константы, ограниченные 12 или 8 битами в зависимости от инструкции. Примеры размеров и диапазонов приведены в табл. 6.6. Знак + или - определяет, прибавляется ли беззнаковое смещение к базовому регистру или вычитается.
Если вам интересно, как различается кодировка положительных и отрицательных смещений LDR, рассмотрите рис. 6.3. Единственное различие двух инструкций - один бит.
Таблица 6.6. Диапазоны непосредственных смещений A32
Рисунок 6.3. Кодировка инструкции LDR с непосредственным значением A32
Инструкция LDRH использует другую кодировку, где для непосредственного смещения доступны только 8 бит, разделённые на две части. На рис. 6.4 видно, что изменяется лишь один бит кодировки, а биты непосредственного значения остаются прежними.
Рисунок 6.4. Кодировка инструкции LDRH с непосредственным значением A32
Набор A64 предоставляет инструкциям загрузки и сохранения большую гибкость непосредственных смещений. В зависимости от инструкции смещение может быть масштабированным или немасштабированным, знаковым или беззнаковым. Как указано в табл. 6.7, масштабированные непосредственные смещения поддерживают 12-битные беззнаковые значения, закодированные как кратное размеру передачи в байтах. Для базовых LDR/STR смещение перед прибавлением к базовому регистру масштабируется до числа, кратного 4 для Wt, то есть 4-байтного регистра, и кратного 8 для Xt, то есть 8-байтного регистра передачи.
Таблица 6.7. Диапазоны масштабированных непосредственных смещений A64
Кодировки[2] вариантов A64 LDR и STR с непосредственным значением резервируют один бит для указания размера регистра передачи: 4 байта Wt или 8 байт Xt. Поэтому при ассемблировании непосредственное байтовое смещение может быть кратным 4 в диапазоне 0-16380 для 32-битного варианта либо кратным 8 в диапазоне 0-32760 для 64-битного, что показано на кодировке LDR[3] на рис. 6.5.
Рисунок 6.5. Кодировка инструкции LDR с непосредственным значением A64
Немасштабированные смещения являются знаковыми 9-битными значениями в диапазоне от -256 до 255, как показано в табл. 6.8. Главное преимущество знакового смещения состоит в возможности формировать адрес ниже адреса базового регистра.
Таблица 6.8. Диапазоны немасштабированных непосредственных смещений A64
Инструкции загрузки и сохранения с немасштабированными смещениями имеют немного другие имена, например LDUR вместо LDR, но не поддерживают адресацию с предындексацией и постиндексацией. На рис. 6.6 сопоставлены биты кодировки двух инструкций LDUR и их знаковые непосредственные смещения.
Рисунок 6.6. Кодировка инструкции LDUR с непосредственным значением A64
В табл. 6.9 приведены немасштабированные инструкции загрузки и сохранения A64 и их масштабированные аналоги.
Таблица 6.9. Инструкции A64 с масштабированным и немасштабированным смещением
При необходимости дизассемблер преобразует LDR в LDUR. В следующем примере это происходит, когда смещение немасштабировано или отрицательно. Если оно масштабировано, то есть кратно 4 байтам для Wt или 8 байтам для Xt, положительно и находится в диапазоне 0-4095, в дизассемблировании отображается LDR. В противном случае инструкция интерпретируется как LDUR.
Исходный код на ассемблере
Результат дизассемблирования
Для LDRB и LDRH смещение масштабируется соответственно до числа, кратного 1 или 2 байтам. Если непосредственное смещение не масштабировано, ассемблер или дизассемблер преобразует инструкцию в немасштабированный вариант, например LDRH в LDRUH.
Следующий фрагмент ассемблерного кода и его дизассемблированный эквивалент демонстрируют это поведение.
Исходный код на ассемблере
Результат дизассемблирования
Доступ к памяти со смещением часто встречается при обратной разработке функции, обращающейся к элементам данных на фиксированном расстоянии от начала объекта. Базовый регистр содержит адрес начала объекта, а смещение задаёт расстояние до конкретного элемента. Например, в следующей программе форма со смещением применяется к полю структуры:
Если скомпилировать программу с оптимизацией, например командой gcc setfield.c -o setfield.o -O2, в дизассемблировании SetField будет виден такой код:
Согласно стандарту вызова процедур Arm параметр param в этом примере передаётся функции через R0. В функции две основные инструкции. Сначала в R3 загружается число 4, затем STR записывает его в память. STR получает адрес R0 + 8, поскольку 8 является смещением поля c внутри структуры Foo. Следовательно, инструкция записывает 4 по адресу param + 8, то есть по адресу param->c в памяти.
Другой сценарий - доступ к локальным переменным в стеке, где SP служит базовым регистром, а смещение обращается к отдельным элементам стека.
Иногда смещение относительно базового адреса не является константой, а динамически вычисляется в регистре. Значение смещения можно поместить в регистр общего назначения, который прибавляется к базовому адресу или вычитается из него. Такая форма часто встречается при доступе к массивам или блокам данных. Например, код C/C++ char c = my_string[i] обращается к одному байту i-го элемента массива my_string, при этом i, скорее всего, хранится или загружается в регистр.
Сначала рассмотрим различия форм регистрового смещения A32 и A64.
Форма A32 позволяет задать смещение регистром общего назначения. Rn является базовым регистром, а Rm - регистром смещения.
Форма масштабированного регистрового смещения A32 позволяет сдвинуть регистр смещения на непосредственное значение перед применением к базовому адресу. Она часто используется в программах C/C++ для масштабирования индекса массива по размеру элемента. Доступны LSL, LSR, ASR, ROR и RRX.
Регистровым смещением A64 служит один из 64-битных регистров общего назначения X0-X30, обозначаемый Xm. Базовый регистр A64 всегда имеет ширину 64 бита и обозначается Xn. SP в данном случае нельзя использовать как регистр смещения.
Сдвинутое регистровое смещение A64 умножает регистр смещения на размер передачи в байтах. При 4-байтном Wt значение смещения сдвигается влево на 2, то есть умножается на 4. При 8-байтном Xt оно сдвигается влево на 3, то есть умножается на 8.
Форма с расширенным регистровым смещением A64 позволяет расширить 32-битный регистр смещения со знаком или нулями до 64 бит. Затем смещение сдвигается влево так же, как в форме со сдвинутым регистром. Тип расширения задаётся синтаксисом и может быть UXTW, SXTW или SXTX. Эти операции подробнее описаны в главе 5. Синтаксис:
В табл. 6.10 приведены формы регистрового смещения A32 и A64 на основе синтаксиса LDR. Тот же синтаксис поддерживается STR и большинством, но не всеми другими инструкциями загрузки и сохранения.
Таблица 6.10. Формы регистрового смещения
В качестве практического примера рассмотрим функцию C/C++, которая записывает 4 в i-й элемент массива 32-битных целых чисел; массив и индекс i передаются параметрами:
Если скомпилировать программу для A64 с базовой оптимизацией, дизассемблирование arraymod будет выглядеть так:
Соглашение о вызовах A64 определяет, что в данном случае адрес массива передаётся в X0, а индекс - в X1. Первая инструкция загружает элемент массива:
• вычисляет адрес элемента как x0 + (x1 << 2), то есть x0 + x1 * 4, поскольку sizeof(uint32_t) равен 4;
• загружает 32-битное слово по этому адресу в W2.
Следующая инструкция прибавляет к значению 4. Наконец, результат записывается обратно в память:
• повторно вычисляется адрес элемента x0 + (x1 << 2);
• результат сложения сохраняется по этому адресу.
В режиме адресации со смещением адрес операции вычисляется с применением смещения к базовому регистру. Результат используется только для доступа к памяти и не изменяет исходное значение базового регистра.
Предындексация применяется, когда инструкция должна в рамках операции обновить базовый регистр результатом вычисления. Как и при адресации со смещением, смещение прибавляется к базовому значению для формирования адреса памяти, но дополнительно результат записывается в базовый регистр. Индексированная адресация часто используется, например, для автоматического последовательного обхода массива или блока памяти.
Инструкции с предындексацией обычно обозначаются восклицательным знаком после операнда памяти. Базовый синтаксис загрузки с предындексацией для A32 и A64 приведён в табл. 6.11.
Таблица 6.11. Синтаксис режима с предындексацией
Предындексацию можно сочетать с различными формами смещений из предыдущего раздела. В табл. 6.12 показаны примеры для LDR. Хотя большинство базовых инструкций загрузки и сохранения поддерживает предындексацию, некоторые в этом режиме допускают только одну форму смещения. Другие, например немасштабированные загрузки LDUR в A64, вообще её не поддерживают.
Таблица 6.12. Примеры адресации с предындексацией
Рассмотрим пример. Инструкция LDR R0, [R1, #8]!, показанная на рис. 6.7, выполняет следующие действия:
1. Вычисляет адрес памяти как значение R1 + 8.
2. Читает 32-битное значение по этому адресу.
3. Помещает 32-битное значение в R0.
4. Обновляет R1 вычисленным адресом памяти.
Для более конкретного примера рассмотрим следующие дизассемблированные инструкции. Сначала R0 получает адрес метки <somedata>, содержащей буквы ABCDEFGHIJKLMNOPQRST. Первая инструкция загрузки помещает содержимое адреса R0 в R1. Следующая загружает содержимое адреса R0 + 4 (0x10070) в R2 и обновляет базовый регистр R0 новым адресом 0x10070. Последующие загрузки выполняют то же действие: загружают слово по адресу базового регистра плюс смещение и обновляют базовый регистр новым адресом.
Рисунок 6.7. Адресация LDR A32 с предындексацией
Конкретный пример предындексации - помещение одного регистра, например LR, в стек:
Инструкция вычисляет адрес SP - 4 и записывает по нему LR. Затем вычисленный адрес SP - 4 записывается обратно в SP. Фактически в A32 инструкция PUSH {Rn}, по крайней мере при помещении единственного регистра, внутренне реализована как псевдоним STR Rn, [SP, #-4]!. Её можно рассматривать как оптимизированную последовательность:
Форма предындексации с обратной записью используется не только для инструкций, подобных PUSH. Функции A64 часто начинают работу с резервирования кадра стека и немедленного сохранения энергозависимых регистров, обычно регистра связи X30 и регистра кадра родительской функции X29. Поэтому в начале функции при дизассемблировании A64 может встречаться:
STP, которая подробнее рассматривается далее, сохраняет два регистра в соседних участках памяти. В данном случае она использует предындексацию, на что указывает восклицательный знак.
Инструкция:
• вычисляет адрес памяти SP - 64;
• записывает X29 и X30 рядом в памяти по этому адресу;
• записывает адрес памяти обратно в SP.
Таким образом, она одновременно сохраняет X29 и X30 в стек и резервирует кадр функции размером 64 байта. Её можно рассматривать как оптимизированный эквивалент:
В режимах со смещением и предындексацией инструкции доступа к памяти вычисляют адрес по простой логике. В форме со смещением адрес после использования отбрасывается. При предындексации вычисленный адрес применяется для доступа к памяти и записывается обратно в базовый регистр.
Постиндексация устроена иначе. Вычисление базы плюс смещение выполняется, но результат записывается только в базовый регистр, тогда как память доступна по исходному значению базы до применения смещения. В некотором смысле этот режим полностью разделяет логику вычисления смещения и часть инструкции, обращающуюся к памяти. Постиндексацию можно распознать по синтаксису: смещение находится не внутри квадратных скобок с базовым регистром, а за их пределами.
Например, LDR R0, [R1], #8, показанная на рис. 6.8:
1. Читает 32-битное значение по адресу из R1.
2. Помещает его в R0.
3. Обновляет R1 адресом R1 + 8.
Рисунок 6.8. Адресация A32 с постиндексацией
Синтаксис приведён в табл. 6.13.
Таблица 6.13. Синтаксис режима с постиндексацией
Постиндексацию можно сочетать с разными формами смещений. В A32 доступны непосредственное, регистровое и масштабированное регистровое смещения. В A64 разрешено только непосредственное смещение с неявным сложением знаковой 9-битной константы. Формы приведены в табл. 6.14.
Таблица 6.14. Примеры адресации с постиндексацией
Хороший пример - извлечение одного регистра из стека инструкцией POP в A32, например POP {pc}. При одном регистре POP реализована как псевдоним LDR, в данном случае LDR pc, [sp], #4. Она выполняет следующее:
1. Адрес памяти равен значению SP.
2. 32-битное слово читается по этому адресу в регистр назначения, в данном случае PC, что вызывает переход.
3. Дополнительная операция записывается обратно в базовый регистр операнда памяти: вычисляется SP = SP + 4.
Другой распространённый пример - завершение функции A64, где за одну атомарную операцию восстанавливаются регистр связи и указатель кадра и удаляется кадр функции. Последними инструкциями могут быть:
LDP, инструкция загрузки пары, подробнее рассматривается далее. Сначала она загружает X29 и X30 из памяти по адресу SP, затем увеличивает SP на 64.
Иногда программе нужно обратиться к данным, адрес которых известен относительно текущего PC. Распространённые примеры - позиционно-независимый код и чтение данных из пула литералов. Компиляторы и ассемблеры часто хранят константы в конце блока кода. Поскольку расстояние между литералом и обращающейся к нему инструкцией фиксировано, его можно загрузить по адресу инструкции плюс постоянное смещение. Такой режим называется адресацией относительно PC.
Другой сценарий - ссылка инструкции на находящиеся рядом глобальные переменные посредством метки. Ассемблер вычисляет смещение от текущей инструкции, адрес которой будет находиться в PC, до метки. Поэтому инструкции загрузки с меткой обычно неявно преобразуются ассемблером в загрузку относительно PC:
Имя label не кодируется в инструкции: ассемблер заменяет его постоянным числом. Читаемая человеком метка лишь облегчает чтение и написание ассемблерного кода. При дизассемблировании инструмент может вывести или создать имя метки, например если адрес имеет имя символа в таблице ELF, либо явно представить инструкцию как PC плюс закодированное постоянное смещение.
LDR также может загрузить постоянное значение или адрес метки специальным синтаксисом LDR Rn,=value. Он полезен и тогда, когда при написании ассемблерного кода константу нельзя непосредственно закодировать в MOV.
Этот синтаксис является директивой ассемблеру поместить константу в ближайший пул литералов[4] и преобразовать инструкцию в загрузку константы относительно PC во время выполнения, как видно из дизассемблирования:
Ассемблер группирует и дедуплицирует константы в пуле литералов и записывает их в конце раздела либо явно "сбрасывает" при встрече директивы LTORG в ассемблерном файле[5][6].
Пул литералов нельзя размещать где угодно в памяти: он должен находиться рядом с использующей его инструкцией. Допустимые расстояние и направление зависят от инструкции и архитектуры и приведены в табл. 6.15.
Таблица 6.15. Требования к расположению пула литералов LDR[7]
По умолчанию ассемблер пытается переписать загрузку литерала в эквивалентную MOV или MVN. LDR относительно PC используется лишь тогда, когда это невозможно. Например, 16-битная кодировка MOV в Thumb отводит значению только 8 бит, а 32-битная MOV - 16 бит.
Внутренняя кодировка MOV набора A32 сравнительно сложна, поэтому определить возможность непосредственного кодирования константы бывает трудно. A32 позволяет загружать константу с помощью схемы вращения непосредственного значения. Кодировка содержит 8-битное поле константы и 4-битное поле величины вращения. Базовая константа лежит в диапазоне 0-255, после чего встроенный барабанный сдвигатель вращает её на чётное число от 0 до 30, закодированное четырьмя битами как rotate/2, формируя итоговую константу регистра назначения. Если непосредственное значение нельзя получить из 4-битной величины вращения и 8-битной константы, оно недопустимо для этой кодировки.
Рассмотрим примеры, поскольку при работе со старыми архитектурами Arm это ограничение встречается часто. Значение 511 недопустимо: его битовый шаблон имеет длину 9 бит, и никакое вращение не позволит вместить его в 8-битное поле. А значение 384 допустимо, как показано на рис. 6.9, поскольку его можно получить из 6 или 26, где 26 - величина вращения. Поскольку 6 представимо 8 битами, число можно непосредственно закодировать в MOV A32.
Рисунок 6.9. Кодировка MOV с непосредственным значением 384
Таким образом, решающим фактором является не величина непосредственного значения, а возможность получить его вращением константы от 0 до 255 на чётное число от 0 до 30. На рис. 6.10 показано значение 370, которое меньше допустимого 384.
Рисунок 6.10. Кодировка MOV с непосредственным значением 370
Теперь ясно, что для этой кодировки подходит не каждое 12-битное значение. К счастью, в современных наборах Arm есть и другие кодировки MOV. A32 в ARMv8-A предоставляет вторую кодировку A2, позволяющую перемещать в регистр 16-битные значения от 0 до 65535. В старых наборах можно использовать следующий синтаксис загрузки констант:
Здесь 511 помещается в пул литералов и загружается в Rn адресацией относительно PC.
Адрес символа можно загрузить в регистр через пул литералов или инструкцией ADR. По сути, ADR выполняет сложение относительно PC: вычисляет адрес метки с относительным смещением и записывает его прямо в регистр общего назначения. Точнее, ADR прибавляет к PC знаковое 21-битное непосредственное значение.
Другая инструкция A64 для вычисления адреса относительно PC - ADRP. Она вычисляет адрес 4-килобайтной страницы с относительным смещением: сдвигает знаковое 21-битное непосредственное значение влево на 12, прибавляет к PC и записывает результат в регистр общего назначения[8].
Рассмотрим отличие ADR от LDR с литералом. Следующий код вызывает системный вызов write и выводит строку. Первые три параметра write передаются в X0, X1 и X2:
• X0 - файловый дескриптор записи, STDOUT = 1;
• X1 - указатель на строку;
• X2 - число записываемых байтов.
После настройки регистров номер системного вызова write (64) помещается в X8, а SVC отправляет запрос операционной системе. Требуется вывести строку "Hi!" с переводом строки, помещённую в пул литералов с меткой mystring. Чтобы присвоить её адрес X1, можно использовать ADR, формирующую относительный адрес метки прибавлением смещения к PC.
Чтобы показать различие LDR и ADR при адресации относительно PC, LDR загрузит из пула литералов значение вместо непосредственного перемещения числа в регистр.
Ассемблируем и компонуем код и рассмотрим дизассемблирование:
В дизассемблировании ADR и LDR на первый взгляд выполняют одну операцию, но между ними есть важное различие. ADR вычисляет адрес метки и загружает адрес в регистр, а LDR загружает в регистр слово по адресу метки.
Инструкции
Результаты в регистрах
Дизассемблирование для справки
При компиляции программы для 32-битного набора в дизассемблировании видно вычисление относительно PC. Та же программа для A32:
В следующем дизассемблировании A32 ADR преобразована в add r1, pc, #20, которая складывает PC и смещение #20 и помещает результат в R1, а LDR загружает память по адресу базового регистра PC плюс #20. Помните, что в A64 читать PC разрешено только инструкциям формирования адреса относительно PC, таким как ADR, ADRP, LDR с литералом, LDRW с литералом, прямым переходам с непосредственным смещением и безусловным переходам со связью[9].
Для лучшего понимания вычисления смещения относительно PC рассмотрим рис. 6.11.
Рисунок 6.11. Смещение относительно PC
При выполнении ADD эффективный PC указывает на текущую инструкцию плюс 8 для A32 и плюс 4 для T32. Поскольку каждая инструкция A32 выровнена по 4 байтам, подсчёт инструкций от PC + 8 до метки даёт 20, то есть 5 x 4. При достижении LDR PC перемещается к SVC. Поскольку метка len расположена на 4 байта после mystring, получается то же смещение.
До сих пор в главе рассматривались режимы и формы смещений, сочетаемые с разными инструкциями загрузки и сохранения. Теперь перейдём к самим инструкциям для операций с памятью.
Существует множество типов инструкций загрузки и сохранения, поэтому будем изучать их по частям, начиная с базовой формы: загрузки или сохранения 32-битного слова либо 64-битного двойного слова. Базовые инструкции доступа к памяти работают с объёмом данных размером в регистр. A32 позволяет загружать или сохранять 32-битное слово, два 32-битных слова или 64-битное двойное слово, как показано в табл. 6.16.
Таблица 6.16. Загрузка и сохранение слова или двойного слова A32
Отдельные инструкции различаются поддерживаемыми режимами адресации и формами смещений. Таблица на рис. 6.12 показывает доступность режимов для инструкций A32.
В табл. 6.17 приведены инструкции загрузки или сохранения 32-битного слова либо 64-битного двойного слова в A64. Размер доступа зависит от регистра передачи.
Хотя тип данных этих инструкций определяется регистром передачи, специальными инструкциями можно загрузить знаковое 32-битное слово в 64-битный регистр в базовой, немасштабированной или непривилегированной форме, как показано в табл. 6.18. Загруженное слово расширяется со знаком до 64 бит.
Рисунок 6.12. Доступные режимы адресации и формы смещений инструкций загрузки и сохранения A32/T32
Таблица 6.17. Загрузка и сохранение слова или двойного слова A64
Таблица 6.18. Загрузка знакового слова A64
Для доступа к данным в памяти меньшей ширины, чем регистр, служат специальные инструкции. Например, байт или полуслово можно загружать и сохранять инструкциями LDRB, LDRH, STRB и STRH. Они имеют ту же базовую форму, что LDR и STR, но обращаются только к одному или двум байтам.
Поскольку в Arm нет 8-битных или 16-битных регистров, возникает вопрос о судьбе остальных битов регистра при загрузке байта или полуслова. Значение автоматически расширяется со знаком или нулями на весь регистр назначения. Например, LDRB загружает байт с нулевым расширением, а LDRSB расширяет со знаком. LDRSH выполняет 16-битную загрузку со знаком, а LDRH является её аналогом с нулевым расширением.
При обратной разработке часто встречаются оба типа загрузки. Знаковое расширение используется компилятором для знаковых целых типов short, char и int, а нулевое - для беззнаковых unsigned short, unsigned char и unsigned int.
В A32 инструкции полуслова загружают полуслово из памяти в регистр. Например, LDRH Rt, [Rn] загружает полуслово по адресу базового регистра Rn и расширяет нулями до 32-битного Rt. STRH Rt, [Rn] сохраняет ровно два байта, взятые из младшего полуслова Rt, по адресу Rn.
В A64 эти инструкции работают сходным образом. Загрузки из 8-битных и 16-битных участков памяти могут расширяться со знаком до 32 или 64 бит в зависимости от регистра передачи Wt или Xt. Поскольку запись в 32-битный регистр автоматически обнуляет старшие 32 бита соответствующего 64-битного регистра, отдельного различия между 32-битным и 64-битным нулевым расширением не требуется: всегда выполняются оба. По соглашению загрузки с нулевым расширением используют 32-битный регистр передачи.
Примеры инструкций полуслова приведены в табл. 6.19.
Таблица 6.19. Примеры загрузки и сохранения полуслова A32 и A64
Инструкции загрузки байта читают байт из памяти и расширяют нулями до размера регистра передачи. Например, LDRB Rt, [Rn, Rm] загружает один байт по адресу Rn + Rm и расширяет его нулями до 32 бит. Для знакового байта используется LDRSB. Для 16-битных чтений LDRH расширяет нулями, а LDRSH - со знаком.
В отличие от загрузки, при сохранении не требуется расширять записываемое значение, поэтому нет различия между записью знаковых и беззнаковых значений. Инструкции сохранения байта или полуслова всегда записывают младшие данные регистра передачи. Например, STRB Rt, [Rn] сохраняет младший байт Rt по адресу Rn.
Примеры байтовых инструкций приведены в табл. 6.20.
Таблица 6.20. Примеры загрузки и сохранения байта A32 и A64
Каждая инструкция поддерживает подмножество режимов адресации и форм смещений. Точные детали различаются между наборами. Например, инструкции полуслова или байта A64 с адресацией со смещением могут иметь непосредственное смещение, масштабированное до числа, кратного 2, либо необязательно сдвинутый или расширенный регистр. Формы с предындексацией и постиндексацией допускают только одну форму смещения: немасштабированное знаковое 9-битное непосредственное значение.
На рис. 6.13 показаны режимы адресации, доступные конкретным инструкциям загрузки и сохранения байта или полуслова A32 и A64.
Рисунок 6.13. Доступные режимы адресации и формы смещений конкретных инструкций A32 и A64
Множество типов инструкций загрузки и сохранения Arm часто встречается не только при обратной разработке, но и при ручном написании ассемблерных программ в обычной разработке или создании эксплойтов, например во встроенном ассемблере или "шелл-коде".
При создании шелл-кода часто требуется написать ассемблер, который не только выполняет полезное действие, но и удовлетворяет ограничениям, например не содержит определённых байтовых последовательностей, таких как нулевые байты.
Предположим, требуется написать шелл-код, пытающийся выполнить программу через функцию system. Она принимает указатель на строку команды, которая должна завершаться нулём. Дополнительно предположим, что шелл-код не может содержать нулевых байтов, поскольку вход обрабатывается строковой функцией. Одно решение - поставить в конце строки команды заполнитель, а во время выполнения динамически заменить его нулевым байтом, чтобы system отработала правильно.
Для простоты пусть команда /bin/sh запускает локальную копию стандартного терминала bash. Она передаётся system и должна завершаться нулём. В пул литералов шелл-кода включим /bin/sh/, но вместо завершающего нуля используем заполнитель X. Во время выполнения STRB динамически заменит его нулевым байтом.
На рис. 6.14 слева показан синтаксис строки в ассемблере, посередине - возможное дизассемблирование, справа - байты в памяти. Видно, что строка с заполнителем не содержит нулевых байтов.
Рисунок 6.14. Строка в ассемблере
Затем STRB может динамически заменить X нулём. R2 обнуляется через EOR, поскольку машинная кодировка MOV R2, #0 содержит нулевой байт, недопустимый в этом примере, и требуется эквивалентная альтернатива.
На рис. 6.15 показано, как STRB перезаписывает X нулём.
Рисунок 6.15. Замена X нулём инструкцией STRB
Иногда в Arm требуется одновременно загрузить или сохранить несколько регистров. В A32 и T32 это можно сделать инструкциями загрузки и сохранения нескольких регистров, которые за одну операцию передают множество регистров в память или из неё.
Традиционные инструкции загружают и сохраняют только один регистр за раз. Например, чтобы сохранить R1, R2 и R3 в стеке с помощью STR, можно применить предындексацию, уменьшая SP на 4 перед каждым сохранением и каждый раз записывая уменьшенное значение обратно:
Работа последовательности в памяти показана на рис. 6.16.
Рисунок 6.16. Работа предыдущего примера STR
В 32-битной Arm эту последовательность можно улучшить инструкциями загрузки и сохранения нескольких регистров. Инструкции A32 загружают несколько регистров из последовательных адресов памяти, заданных базовым регистром, либо сохраняют их туда. Синтаксис приведён в табл. 6.21.
Таблица 6.21. Синтаксис LDM/STM в A32
Синтаксис LDM/STM отличается от LDR/STR. Сравним STR и STM на рис. 6.17. Первый регистр Rt инструкции STR является регистром передачи со значением для памяти, а регистр в квадратных скобках Rn - базовым регистром с адресом назначения. STM работает наоборот: первый Rn служит базовым регистром адреса назначения, а регистры в фигурных скобках содержат значения для памяти.
Рисунок 6.17. Логика инструкций STR и STM
Список передачи может содержать два и более регистра общего назначения, включая LR и PC. В Armv8 по сравнению с Armv7 действуют ограничения:
• при загрузке нескольких регистров PC может входить в список, но Arm не рекомендует одновременно включать LR и PC;
• при сохранении нескольких регистров PC может входить в список, но Arm не рекомендует инструкции, содержащие PC.
Регистры в списке должны идти по возрастанию. Попытка ассемблировать STM sp, {r1, r4, r2, r3} вызывает предупреждение, после чего ассемблер автоматически упорядочивает регистры, как видно далее.
Ассемблирование LDM и STM с неупорядоченным списком регистров
Исходный код
Предупреждение ассемблера
Дизассемблирование показывает регистры по возрастанию
Чтобы сохранить R1, R2 и R3 в стеке, можно использовать:
Значение R1 сохраняется по адресу SP, R2 - по SP + 4, R3 - по SP + 8, как показано на рис. 6.18. SP при этом не обновляется.
Рисунок 6.18. Пример инструкции STM
Большинство режимов обычных загрузок и сохранений, таких как LDR и STR, имеет аналоги для LDM/STM. Базовый регистр можно автоматически обновить, поставив после него восклицательный знак, как на рис. 6.19.
Рисунок 6.19. Пример STM с обновлением SP
В этом примере значения сохраняются вниз, а не вверх, как в предыдущем примере STR. Направлением можно управлять суффиксами адресации. Сначала необходимо понять контекст, в котором направление роста имеет значение.
Наиболее известные инструкции памяти A32 - PUSH и POP для сохранения значений в стек и загрузки из него. Это псевдоинструкции, основанные на вариантах загрузки и сохранения нескольких регистров. PUSH основана на STM, а POP - на LDM. Архитектура Arm поддерживает четыре реализации стека, определяющие направление роста и положение SP после массовой передачи.
Полный восходящий (FA)
• Стек растёт в сторону более высоких адресов.
• SP указывает на верхний элемент стека.
Полный нисходящий (FD)
• Стек растёт в сторону более низких адресов.
• SP указывает на верхний элемент стека.
Пустой восходящий (EA)
• Стек растёт в сторону более высоких адресов.
• SP указывает на пустой элемент после верхнего элемента стека.
Пустой нисходящий (ED)
• Стек растёт в сторону более низких адресов.
• SP указывает на пустой элемент после верхнего элемента стека.
LDM и STM имеют общий базовый синтаксис и различаются суффиксом, как показано в табл. 6.22.
Таблица 6.22. Синтаксис загрузки и сохранения нескольких регистров A32
Рассмотрим примеры. Суффиксы увеличения после IA и увеличения до IB определяют, увеличивается базовый регистр после или до загрузки либо сохранения первого значения. На рис. 6.20 SP обозначает исходное положение. LDMIA загружает 3 в R0 до перехода к следующей позиции. LDMIB сначала переходит к следующей позиции и затем загружает 4 в R0. Верх рисунка соответствует арифметически меньшим адресам, низ - большим.
Рисунок 6.20. Пример инструкций LDMIA и LDMIB
Суффиксы уменьшения после DA и уменьшения до DB работают сходным образом, определяя, уменьшается ли базовый регистр после или до загрузки либо сохранения первого значения. В примере на рис. 6.21 LDMDA сначала загружает значение по адресу SP, а затем переходит к следующей позиции на 4 байта ниже. Исходное значение SP остаётся неизменным и используется только для временных уменьшений.
Рисунок 6.21. Пример инструкций LDMDA и LDMDB
Каждая мнемоника LDM и STM с адресным суффиксом имеет эквивалентную мнемонику для реализации стека. Например, STMDB эквивалентна STMFD, где FD означает полный нисходящий стек, используемый стандартом вызова процедур Arm AAPCS. В табл. 6.23 приведены инструкции LDM/STM с адресным суффиксом и их эквиваленты.
Таблица 6.23. Эквиваленты A32
Базовые мнемоники LDM/STM псевдоинструкций PUSH и POP зависят от реализации стека. Поскольку AAPCS использует полный нисходящий стек, PUSH и POP преобразуются в STMFD и LDMFD с обратной записью и SP как базовым регистром. LDMFD эквивалентна LDMIA, где IA означает увеличение базового регистра после каждой загрузки, а STMFD эквивалентна STMDB, где DB означает уменьшение базового регистра до каждого сохранения.
Но если POP эквивалентна LDMFD, а та - LDMIA, выполняют ли они одну операцию? Да. То же относится к PUSH и её эквивалентам, показанным на рис. 6.22. Когда LDM/STM имитируют стековые PUSH и POP, базовым регистром служит SP, а суффикс определяется реализацией стека. В других сценариях суффиксы дают больше гибкости при массовой загрузке и сохранении данных.
Рисунок 6.22. Эквивалентные PUSH и POP формы LDM и STM
В табл. 6.24 приведены альтернативные синтаксические формы PUSH и POP. При записи этих форм в ассемблере они преобразуются в эквиваленты PUSH или POP.
Таблица 6.24. Синтаксис PUSH и POP в A32
Альтернативные синтаксические формы PUSH и POP
Исходный код
Дизассемблирование
Хотя PUSH и POP внутренне используют STM и LDM, этим применение последних не ограничивается. Программы часто используют их для крупных копирований. Рассмотрим базовую программу, определяющую функцию CopyStruct, которая копирует 16-байтную структуру с одного адреса на другой:
Если скомпилировать программу с оптимизацией командой gcc copystruct.c -o copystruct.o -O2 и дизассемблировать, CopyStruct выглядит так:
Согласно соглашению о вызовах в начале функции R0 содержит адрес a, а R1 - адрес b. Функция помещает R4 в стек, освобождая регистр для хранения адреса a, который копируется инструкцией MOV. Затем LDMIA выполняет 16-байтную загрузку из b, то есть из R1, в четыре регистра R0-R3. После этого STMIA записывает эти 16 байт обратно в память по адресу R4, то есть a.
Наконец, постиндексированная LDR фактически извлекает исходное значение R4 из стека, после чего BX LR возвращает управление.
STM и LDM часто используются в оптимизированных библиотечных подпрограммах быстрой передачи памяти. Например, следующий фрагмент взят из основной части написанного вручную 32-битного ассемблерного кода memcpy библиотеки libc Android[10]. Вся подпрограмма велика, но это её основной горячий цикл массовой передачи по 32 байта:
Большой цикл копирования является горячим циклом массовой передачи крупных блоков из одной области памяти в другую внутри memcpy. На этом этапе данные копируются из указателя R1 в указатель R0, а R2 задаёт число оставшихся байтов.
Что именно делает цикл? Сначала код сохраняет R6 и R7 в стек инструкцией STMFD. Ранее было показано, что STMFD эквивалентна STMIA, а STMIA с SP как базовым регистром и предындексацией эквивалентна PUSH, то есть первая инструкция помещает R6 и R7 в стек.
Затем программа вычитает 32 из R2 и входит в горячий цикл. Первая инструкция LDMIA загружает R4-R7 из последовательной памяти, на которую указывает R1. Она загружает 16 байтов непосредственно в R4-R7. Предындексация автоматически продвигает R1 на 16 байт. Следующая STMIA немедленно записывает данные обратно в память, но по адресу R0, также увеличивая R0 на 16.
Вместе эти две инструкции выполняют быстрое 16-байтное копирование памяти из R0 в R1, продвигая оба регистра на 16. Следующие LDMIA и STMIA делают то же самое со следующими 16 байтами, хотя между ними находится SUBS.
SUBS, уже рассмотренная в главе 5, вычитает 32 из R2 и устанавливает флаги. Её расположение посередине второй 16-байтной передачи может сбивать с толку, но это микрооптимизация: инструкция уменьшает R2 на 32 и готовит флаги для условного перехода в конце блока.
BGE рассматривается в главе 7. Она перезапускает цикл, если вычитание 32 из R2 дало отрицательное число. Это продолжается, пока не останется меньше 32 байтов, после чего другая логика memcpy копирует последние байты.
После выхода программа выполняет LDMFD. Ранее было показано, что LDMFD эквивалентна LDMDB, а с SP как базовым регистром и предындексацией логически эквивалентна POP {r6, r7}. Это парная операция для логического PUSH в начале примера: она восстанавливает R6 и R7 перед продолжением.
Масштабированные и немасштабированные смещения уже рассматривались в разделе "Адресация со смещением", но массовая передача памяти A64 использует иной тип непосредственного смещения, чем передача одного регистра, как показано в табл. 6.25.
Таблица 6.25. Типы загрузки и сохранения A64 и формы смещений
В A64 нет прямого аналога STM и LDM или псевдоинструкций PUSH и POP. Вместо них программы используют загрузку и сохранение пары LDP и STP. Также доступна загрузка пары со знаковым расширением LDPSW.
LDP, LDPSW и STP похожи на LDR и STR, но одновременно записывают или загружают два регистра. LDP и STP поддерживают формы со смещением, предындексацией и постиндексацией, как показано в табл. 6.26. При работе с 64-битными регистрами постоянное смещение должно быть кратно 8 и лежать в диапазоне -512-504. Для 32-битных регистров оно должно быть кратно 4 в диапазоне -256-252.
Невременные парные варианты[11] допускают только адресацию со смещением, а исключительные парные варианты[12] вообще не поддерживают смещений. Эти варианты в книге не рассматриваются.
Таблица 6.26. Адресация и смещения парных инструкций A64
Синтаксис LDP и STP приведён в табл. 6.27.
Обе инструкции имеют 32-битный и 64-битный варианты. Регистры передачи задают передачу двух 32-битных слов либо двух 64-битных двойных слов. Базовым регистром может быть 64-битный регистр общего назначения или SP. Если используется SP, в начале инструкции он должен быть выровнен по границе 16 байт. Непосредственное смещение должно быть кратно 8 для 64-битного варианта и 4 для 32-битного.
Таблица 6.27. Синтаксис LDP/STP в A64
На рис. 6.23 показаны две STP: без смещения и с непосредственным смещением 8. Первая сохраняет два двойных слова X1 и X2 по адресу SP: X1 первым, X2 по SP + 8. SP не обновляется.
Вторая применяет смещение 8 к адресу SP. X3 сохраняется по SP + 8, X4 - по SP + 16. SP также не обновляется.
Рисунок 6.23. Пример STP A64 с базой и базой со смещением
Следующие два примера показывают STP с постиндексацией и предындексацией на рис. 6.24. Первая инструкция использует постиндексацию со смещением #16: X1 сохраняется по адресу SP, а X2 - по SP + 8. После записи двух двойных слов базовый регистр SP обновляется смещением #16.
Вторая инструкция использует предындексацию, поэтому #16 сначала применяется к SP. Два двойных слова сохраняются по новому адресу SP + 16. На рисунке SP + 16 и SP + 24 обозначают расстояние от исходного SP до обновления.
Рисунок 6.24. STP A64 с постиндексацией и предындексацией
32-битные варианты загружают или сохраняют два последовательных слова. На рис. 6.25 показана 32-битная LDP, загружающая из памяти по адресу X0 два слова в W1 и W2. Младшие 32 бита загружаются в W1, следующие 32 бита по X0 + 4 - в W2.
Рисунок 6.25. 32-битный вариант LDP A64
LDPSW загружает из памяти два 32-битных слова и расширяет их со знаком до 64-битных двойных слов, как показано в табл. 6.28. Непосредственное смещение должно быть кратно 4 в диапазоне -256-252. Эквивалентной инструкции сохранения нет.
Таблица 6.28. Синтаксис LDPSW в A64
Инструкция на рис. 6.26 загружает два последовательных слова по адресу X0 и расширяет их со знаком соответственно в X1 и X2.
Рисунок 6.26. Иллюстрация LDPSW A64
[1] [назад]
[2] [назад]
[3] [назад]
[4] [назад] https://developer.arm.com/documentation/dui0473/c/writing-arm-assembly-language/literal-pools.
[5] [назад] https://www.keil.com/support/man/docs/armasm/armasm_dom1359731147386.htm.
[6] [назад] https://sourceware.org/binutils/docs/as/AArch64-Directives.html.
[7] [назад]
[8] [назад]
[9] [назад]
[10] [назад] https://android.googlesource.com/kernel/lk/+/master/lib/libc/string/arch/arm/memcpy.
[11] [назад]
[12] [назад]
В этой главе представлен обзор флагов условий Arm, способов их установки и использования инструкциями, а также работы инструкций условного выбора и сравнения.
В предыдущих главах были рассмотрены многие инструкции Arm для обработки и изменения данных в регистрах, а также загрузки данных из памяти и сохранения в неё. Однако обработка данных - лишь часть работы современных программ. Программы также реализуют сложную логику, динамически меняя поведение во время выполнения в зависимости от встреченных данных.
Разработчики на C и C++ часто используют высокоуровневые конструкции, например if, циклы while и for, чтобы определить реакцию программы на различные условия. Например:
В этом примере поведение функции динамически зависит от argc. Условие if является логическим вопросом с ответом "да" или "нет": "равен ли argc как минимум 2?" Ответ определяется во время выполнения, и заключённые в if инструкции выполняются только при ответе "да".
К сожалению для специалистов по обратной разработке, этих высокоуровневых конструкций на уровне процессора не существует, и в скомпилированном коде их нет. Компиляторы преобразуют их в последовательности простых инструкций процессора, таких как CMP, ANDS и BNE, кодирующие ту же логику в форме, которую Arm эффективно выполняет. При обратной разработке необходимо проделать обратное: прочитать скомпилированные инструкции и вывести исходный замысел программиста. В этой главе рассматриваются коды условий и их использование инструкциями. Переходы и логика потока управления описаны в главе 8.
В Arm большинство условных логических конструкций разделено между двумя или более инструкциями. Первая устанавливает флаги: проверяет одно или несколько значений в регистрах и соответственно задаёт NZCV внутри PSTATE. Затем следует условная инструкция, поведение которой зависит от кода условия, а тот - от состояния NZCV.
Инструкции установки флагов делятся на две основные категории:
• специальные инструкции проверки и сравнения, такие как CMP, TST и TEQ, которые устанавливают NZCV на основе одного или нескольких регистров;
• инструкции обработки данных с суффиксом S, например ADDS, которые выполняют обычную арифметическую операцию и дополнительно устанавливают NZCV по результату.
Условные инструкции также делятся на две основные категории:
• обычные условно выполняемые инструкции с кодом условия в конце имени. Они выполняются тогда и только тогда, когда условие истинно; иначе процессор игнорирует инструкцию и переходит к следующей. Примеры: ORREQ, MOVNE и ADDLT, а также условные переходы BEQ и BGE, подробно рассматриваемые в главе 8;
• набор A64 не поддерживает условное выполнение каждой инструкции. Вместо этого он предоставляет специальные условные инструкции, такие как CSEL и CCMP. Код условия передаётся им как параметр, а не добавляется к имени. Эти инструкции выполняются всегда, но их поведение зависит от истинности условия.
Как было показано в главе 4, процессоры Armv8-A хранят состояние процесса, включая NZCV, в структуре PSTATE, которая абстрагирует сведения о состоянии. Флаги находятся в битах [31:28] PSTATE, как показано на рис. 7.1[1].
Рисунок 7.1. Биты флагов условий в PSTATE
Основные значения арифметических флагов NZCV:
• N, отрицательный результат: операция дала отрицательное значение.
• Z, ноль: операция дала нулевой результат.
• C, перенос, или беззнаковое переполнение: значение зависит от контекста. Для сложения и вычитания C означает беззнаковое переполнение. Для сдвига содержит последний вытесненный и отброшенный бит. Иногда C сообщает об ошибке. Например:
• инструкции генератора случайных чисел Armv8.5 RDNR и RNDRRS устанавливают C в 1, если аппаратный генератор не смог выдать число за разумное время[2];
• некоторые операционные системы устанавливают C в 1, если запрошенный системный вызов вернул ошибку[3];
• сравнения с плавающей точкой устанавливают C в 1, если один или оба операнда являются NaN.
• V, переполнение: используется инструкциями сложения и вычитания и означает знаковое целочисленное переполнение.
После сложения или вычитания флаги C и V указывают соответственно на беззнаковое или знаковое целочисленное переполнение. Переполнение означает, что операция дала математически "неправильный" результат.
Но что именно происходит на низком уровне? Как процессор "узнаёт" об ошибочном результате и почему, если он это знает, просто не вычисляет правильный?
Для понимания вспомним внутреннее выполнение сложения и вычитания. Процессоры считают почти так же, как людей учат складывать большие числа в столбик. При длинном сложении начинают с младших цифр, единиц, складывая соответствующие цифры и получая следующую цифру результата. Если сумма превышает 10, например 9 + 4, единица "переносится" в следующий старший разряд и прибавляется там. Процесс продолжается до исчерпания входных цифр.
Процессор делает то же в двоичной, а не десятичной системе. На рис. 7.2 показано, как 4-битный процессор складывает 0b1011 (11) и 0b1010 (10).
Рисунок 7.2. Перенос
Если двигаться справа налево, каждый элемент цепочки складывает два двоичных разряда входных значений с учётом переноса из предыдущего элемента. Он суммирует два входных бита и входной перенос, получая "цифру суммы" данного столбца. Это даёт выходной бит и, если сумма двух входов и переноса равна как минимум 2, выходной перенос для следующего элемента.
В упрощённом примере 4-битный сумматор создаёт 4 выходных бита 0b0101 и итоговый перенос 1. Вместе они дают правильный 5-битный результат 0b10101, поскольку 11 + 10 = 21.
32-битные и 64-битные процессоры делают то же в большем масштабе. 32-битное сложение получает два 32-битных значения и выдаёт 32 бита результата и итоговый перенос из последнего, старшего, элемента цепочки. Биты сумматора становятся арифметическим результатом в регистре назначения, а последний перенос копируется в C. Значение C = 1 означает, что "настоящий" результат имел 33 бита, либо 65 бит для 64-битной операции, и был усечён для помещения в регистр. Иными словами, произошло беззнаковое переполнение.
Логика знакового переполнения сложнее, но основана на двух наблюдениях. Во-первых, если входные значения имеют разные знаки, знаковое переполнение невозможно, поскольку модуль результата строго уменьшается. Во-вторых, если знаки одинаковы, знак результата совпадает со знаком входных значений, кроме случая переполнения, когда знаковый бит неожиданно инвертируется.
Поэтому знаковое переполнение можно быстро и надёжно определить, исследуя только однобитный элемент цепочки, вычисляющий знаковый бит. Затем можно построить таблицу истинности всех обстоятельств переполнения, как на рис. 7.3.
Рисунок 7.3. Знаковое переполнение и таблица истинности
Сведение таблицы к минимальной логической форме даёт итог: V устанавливается в результат исключающего ИЛИ входного и выходного переносов этого однобитного сумматора, то есть тогда и только тогда, когда при вычислении произошло знаковое переполнение.
Для условного выполнения Arm определяет 16 четырёхбитных кодов. Они позволяют выполнять инструкцию условно на основе NZCV в PSTATE.
В табл. 7.1[4] приведены коды и их значения.
Таблица 7.1. Коды условий
AL означает "всегда". Это необязательное расширение мнемоники A32, указывающее на безусловное выполнение. По соглашению AL всегда опускается: безусловное сложение записывается ADD, а не ADDAL.
Кодировка 0b1111, обозначенная в табл. 7.1 как NV, зарезервирована. В A64 она предоставлена только для корректного дизассемблирования кода условия 0b1111[5]. В A32 ей не назначено конкретное значение[6]. В обоих случаях она не предназначена для ручного ассемблерного кода и не встречается при обычной обратной разработке.
Условно выполняемые инструкции создаются непосредственным добавлением кода условия к имени, как в примерах A32:
Набор инструкций, допускающих такое условие, зависит от используемого набора. Если код условия истинен, инструкция выполняется.
В A32 большинство инструкций резервирует в двоичной кодировке место для кода условия. Поэтому почти любую обычную инструкцию можно сделать условной, просто добавив код к имени.
T32 применяет радикально иной подход. Место для кода условия имеют только переходы, поэтому непосредственным суффиксом можно сделать условными лишь BNE, BGE и подобные. Другие инструкции используют уникальную специальную IT. Она настраивает поле ITSTATE процессора и позволяет максимум четырём следующим инструкциям выполняться по условию или его отрицанию. Синтаксис IT сложен и подробно рассматривается далее.
A64 использует ещё один подход. Как и в T32, непосредственный код условия допускают только переходы, а IT для других инструкций отсутствует. Вместо этого A64 предоставляет две новые группы: условные сравнения и условные выборы, которые служат мощной и гибкой альтернативой условному выполнению других инструкций.
IT[7] означает If-Then и существует только в Thumb (см. главу 4). Она превращает до четырёх последующих обычных инструкций в условно выполняемые на основе кода условия или его логического отрицания. IT и изменяемые ею от одной до четырёх инструкций вместе образуют условный блок IT[8].
В T32 коды условий, за исключением условных переходов, не кодируются непосредственно в инструкциях, а хранятся и обрабатываются полем ITSTATE процессора, входящим в PSTATE. См. рис. 7.4.
Рисунок 7.4. Биты ITSTATE в PSTATE
Концептуально ITSTATE работает как "очередь" максимум из четырёх ожидающих кодов условий. IT лишь инициализирует это состояние, настраивая очередь. При декодировании каждая инструкция проверяет, ожидается ли код условия. Если да, инструкция "присоединяется" к нему, становится условной и "потребляет" код из очереди. После опустошения очереди инструкции работают в обычном безусловном состоянии.
Базовый синтаксис IT:
Здесь cond - "базовое условие", которое "присоединится" к следующей инструкции. Например, так в Thumb создаётся addeq:
Здесь IT инициализирует очередь кодов условий ITSTATE одной записью EQ. Следующая инструкция закодирована как ADD, но получает EQ из очереди и становится ADDEQ.
Важно: хотя в предыдущем примере addeq явно записана с кодом условия, такой двоичной кодировки инструкции не существует. На двоичном уровне это ADD, а EQ кодируется только через IT. Для удобочитаемости большинство ассемблеров требует явно писать условия, закодированные IT, а дизассемблеры и отладчики автоматически распространяют коды из IT на последующие инструкции.
IT может сделать условной не одну, а до четырёх последующих инструкций. Для каждой дополнительной инструкции после первой к имени IT добавляется буква. Так формируются условия If-Then-Else, где T относится к базовому условию cond, а E - к ветви Else. Каждая инструкция внутри блока должна указывать базовое условие либо его логическую инверсию для Else по синтаксису:
Символы x, y и z могут быть T (Then) или E (Else). T обозначает инструкцию, выполняемую по базовому условию, например EQ, а E - по его логической инверсии, например NE. В табл. 7.2 приведены условия и их противоположности.
Таблица 7.2. Коды условий и их инверсии
Рассмотрим IT, делающую условными две инструкции. В первой группе обе зависят от EQ. Поэтому имя IT дополнено T, означающей: "вторая инструкция также использует базовое условие EQ".
Теперь построим If-Then-Else, где две инструкции условны, но вторая использует отрицание базового кода, то есть addne. Для этого к IT добавляется E.
Тот же подход обобщается на блок из четырёх инструкций, например ITTEE означает If-Then-Then-Else-Else. Инструкция ITETE EQ делает первую и третью инструкции группы условными по EQ, а вторую и четвёртую - по отрицанию EQ, то есть NE.
Последовательность логически эквивалентна псевдокоду:
В предыдущем разделе условные инструкции выполнялись на основе кодов, проверяющих NZCV. Теперь рассмотрим инструкции, устанавливающие эти флаги по результату вычисления.
К именам многих, хотя и не всех, инструкций обработки данных можно добавить S. Это предписывает процессору наряду с обычным поведением установить NZCV[9] во время вычисления. Например, ADDS работает точно как ADD, но дополнительно задаёт NZCV по результату[10].
Точное обновление и значение NZCV зависят от инструкции и архитектуры. На рис. 7.5 показаны все инструкции с суффиксом S в каждой архитектуре, тематически сгруппированные по взаимодействию с NZCV. Далее группы рассматриваются по отдельности.
Рисунок 7.5. Инструкции с суффиксом S
Для группы "прочих инструкций" A32 флаг C почти всегда устанавливается в 0, кроме одного случая: если операция неявно сдвигает второй операнд, C получает последний бит, вытесненный блоком сдвига при вычислении второго операнда. Причина в том, что большинство сдвигов A32 внутренне являются псевдонимами MOVS с неявным сдвигом.
И в A32, и в A64 инструкции сложения и вычитания с суффиксом S обновляют при вычислении все четыре флага NZCV.
Вместо абстрактного описания рассмотрим конкретный пример ADDS и заодно разберём смысл знакового и беззнакового переполнения. Сложим 0xffffffff и 1:
На рис. 7.6 показана работа ADDS и обновление флагов.
Рисунок 7.6. Обновление флагов в примере ADDS
Сначала ADDS складывает R0 и R1 и получает 0, который копируется в регистр назначения R0. Поскольку используется S, процессор также обновляет флаги.
Z и N очень просты. Результат равен нулю, поэтому Z = 1. Он не отрицателен, поскольку старший бит равен 0, поэтому N = 0.
C и V сложнее. Для их определения проверяется "правильность" результата при беззнаковой и знаковой интерпретации входов и выхода.
Сначала рассмотрим беззнаковый случай. Вычисленный результат неверен: 2147483647 + 1 не равно 0. Произошло беззнаковое переполнение, поэтому C = 1.
При знаковой интерпретации результат правилен: 0xffffffff означает -1 в дополнительном коде, а -1 + 1 равно 0. Знакового переполнения нет, поэтому V = 0.
Теперь сложим 0x7fffffff с самим собой инструкцией ADDS:
Полная схема показана на рис. 7.7.
Рисунок 7.7. Знаковое переполнение
Арифметический результат равен 0xfffffffe и записывается в R0. Из-за суффикса S процессор также обновляет флаги.
Z и N снова просты. Результат не ноль, значит Z = 0. Знаковый бит установлен, значит N = 1. Остаётся определить C и V.
При беззнаковой интерпретации операция даёт правильный результат: 2147483647 + 2147483647 = 4294967294. Беззнакового переполнения нет, поэтому C = 0. При знаковой интерпретации результат неверен. В дополнительном коде 0xfffffffe означает -2, а 2147483647 + 2147483647 не равно -2. Произошло знаковое переполнение, поэтому V = 1.
Итак:
• N = 1, поскольку бит 31 результата установлен;
• Z = 0, поскольку результат не ноль;
• C = 0, поскольку беззнакового переполнения не было;
• V = 1, поскольку произошло знаковое переполнение.
В A32, но не в A64, инструкции логического сдвига ASRS, LSLS, LSRS, RORS и RRXS также могут использовать S[11]. Z и N сохраняют прежний смысл, а C и V работают иначе. C получает последний вытесненный при сдвиге бит, а V не изменяется.
Например, выполним 32-битный сдвиг 0xdc000001 влево на пять бит инструкцией LSLS, как показано на рис. 7.8.
Рисунок 7.8. Флаги PSTATE в примере LSLS
Как показано в главе 5, LSL сдвигает каждый бит входного значения на фиксированное число позиций влево. В примере 32-битное значение сдвигается на пять, из-за чего старшие пять бит "выпадают" и отбрасываются, а новые младшие пять позиций заполняются нулями. Арифметический результат равен 0x80000020.
Для обычной LSL анализ закончился бы здесь, но LSLS также обновляет NZCV:
• N = 1, поскольку старший бит результата равен 1;
• Z = 0, поскольку результат не нулевой;
• C = 1, поскольку последний вытесненный бит равен 1;
• V не изменяется.
В A32, но не в A64, инструкции MULS, MLAS, SMLALS, SMULLS, UMLALS и UMULLS могут использовать S для установки флагов[12]. Z и N обновляются по результату, а C и V всегда остаются неизменными.
В A32 суффикс S также поддерживают ANDS, BICS, EORS, MOVS, MVNS, ORNS и ORRS. Флаги устанавливаются так:
• Z устанавливается, если результат равен нулю;
• N устанавливается, если результат отрицателен;
• C обычно сбрасывается в 0, кроме случая неявного сдвига второго операнда: тогда C получает последний вытесненный при этом сдвиге бит;
• V не изменяется.
В A64 к этой категории относятся только ANDS и BICS:
• Z устанавливается при нулевом результате;
• N устанавливается при отрицательном результате;
• C всегда сбрасывается в 0;
• V всегда сбрасывается в 0.
Помимо инструкций обработки данных с суффиксом S, CMP, CMN, TST и TEQ позволяют непосредственно исследовать данные и устанавливать NZCV, не записывая промежуточный результат в регистр[13].
В табл. 7.3 приведены четыре базовые инструкции, эквивалентные арифметические операции и обычный семантический смысл.
Таблица 7.3. Инструкции проверки и сравнения
CMP сравнивает два значения и определяет, какое больше. Внутренне она вычитает операнды, устанавливает NZCV по результату и отбрасывает его. См. рис. 7.9.
Рисунок 7.9. Логика CMP и эквивалент SUBS
При обратной разработке CMP часто управляет потоком программы. Самый распространённый случай - сравнение двух регистров на равенство или величину либо проверка регистра относительно константы:
CMP также предоставляет более сложные формы, где второй операнд перед сравнением неявно преобразуется сдвигом или расширением. Полный синтаксис приведён в табл. 7.4.
Таблица 7.4. Формы инструкции CMP
Для понимания кода с CMP необходимо изучать не только саму инструкцию, но и последующие инструкции, чтобы увидеть, как NZCV проверяется кодом условия. Например:
CMP сообщает, что сравниваются R0 и R1. Но чтобы понять интересующий программу тип сравнения, нужно найти инструкцию, которая использует NZCV. Здесь следующая ADDNE зависит от NE. Семантический смысл CMP: "r0 не равно r1?" Если условие истинно, ADDNE устанавливает r0 = r1 + r2; иначе пропускается.
Теперь предположим другую последовательность:
CMP та же, но проверяемое логическое условие другое. LT семантически спрашивает: "r0 меньше r1?" При истинном условии выполняется сложение, иначе пропускается.
CMN почти идентична CMP, но перед сравнением второй операнд отрицается. Она поддерживает все те же формы синтаксиса и внутренне реализована как сложение, устанавливающее NZCV и отбрасывающее результат. См. рис. 7.10.
Рисунок 7.10. Логика CMN и эквивалент ADDS
При обратной разработке CMN обычно встречается, когда компилятор не может использовать эквивалентную CMP. Например:
argument передаётся в W0, и компилятору нужно быстро проверить его на -1. Наивная CMP w0, #-1 недопустима: константа -1 вне диапазона. Вместо неё компилятор может использовать допустимую CMN w0, #1, кодирующую тот же смысл.
TST выполняет побитовое И двух операндов, устанавливает флаги по результату и отбрасывает вычисленный результат, как показано на рис. 7.11.
Рисунок 7.11. Логика TST и эквивалент ANDS
TST проверяет, установлены ли определённые биты значения. Это особенно полезно для логических значений, упакованных в поле флагов, или для проверки выравнивания числа по степени двойки путём проверки младших битов на ноль.
Полный синтаксис приведён в табл. 7.5.
TST устанавливает NZCV по результату внутреннего побитового И[14][15]:
• N устанавливается, если старший бит результата равен 1;
• Z устанавливается, если результат равен нулю;
• C обычно устанавливается в ноль, кроме A32 с неявным сдвигом второго операнда: тогда C получает последний вытесненный бит;
• V игнорируется в A32 и устанавливается в 0 в A64.
Таблица 7.5. Формы инструкции TST
Рассмотрим пример. Пусть R0 содержит 0xffff0010, и встречается код:
Механически последовательность работает так. TST выполняет побитовое И R0 с 0x10, получая 0x10. Результат не ноль, поэтому Z = 0. Следующая MOVNE использует условие NE, истинное при Z = 0. Значит, MOVNE выполняется и копирует -1 в R0. Процесс показан на рис. 7.12.
Рисунок 7.12. Поведение инструкций TST и MOVNE
Такой механический подход вполне пригоден для обратной разработки, но есть более простой. Вместо сосредоточения на действиях инструкций можно искать типичные шаблоны, раскрывающие исходный замысел. Сначала анализируется TST и аргументам назначается семантика. Когда TST используется с постоянной константой, как на рис. 7.13, она обычно описывает биты, интересующие программу. Второй аргумент - исследуемое значение.
Рисунок 7.13. Компоненты инструкции TST
Теперь известно, что программу интересует бит 0x10 регистра R0. Далее ищется инструкция, использующая код условия. Обычно это следующая инструкция, как здесь, но не всегда. MOVNE зависит от NE. Затем можно выяснить контекстное значение NE после TST, как показано на рис. 7.14.
Рисунок 7.14. Код условия NE в контексте TST
Этого достаточно для восстановления логики. Программу интересует бит 0x10 R0. Если он установлен, MOVNE записывает -1 в R0. Значит:
Инструкция TEQ[16] существует только в A32, устанавливает флаги по результату побитового исключающего ИЛИ двух значений и отбрасывает результат. См. рис. 7.15.
Рисунок 7.15. Логика инструкции TEQ
TEQ устанавливает:
• N, если старший бит результата равен 1;
• Z, если результат равен нулю;
• C не изменяется, кроме случая неявного сдвига operand2, когда он получает перенос операции сдвига;
• V всегда остаётся неизменным.
Полный синтаксис приведён в табл. 7.6.
Таблица 7.6. Формы инструкции TST
При обратной разработке за TEQ r0, r1 почти всегда следует инструкция, зависящая от EQ или NE. EQ истинно при точном равенстве, NE - только при неравенстве. TEQ часто взаимозаменяема с CMP для точной проверки равенства, но отличается тем, что явно не устанавливает C или V[17].
Хотя на практике это редко, TEQ также может быстро проверить одинаковость арифметических знаков двух входов, то есть оба отрицательны или оба положительны. TEQ r0, r1 выполняет исключающее ИЛИ R0 и R1 и устанавливает флаги по временному результату. Поэтому N получает исключающее ИЛИ знаковых битов обоих входов: 0 при одинаковых знаках и 1 при разных. Затем это проверяется кодами MI или PO.
В отличие от A32 и T32, большинство обычных инструкций обработки данных A64 нельзя сделать условными добавлением кода к имени: ADDEQ и MOVEQ в A64 не существуют. Вместо этого с появлением A64 была добавлена группа условного выбора[18].
Инструкции группы условного выбора достаточно очевидны и имеют сходный синтаксис: регистр назначения, один или два входных регистра и код условия в конце. Каждая поддерживает 32-битные или 64-битные регистры.
В табл. 7.7 перечислены инструкции и их поведение при истинном и ложном условии. Для краткости показаны только 64-битные формы.
Таблица 7.7. Поведение инструкций условного выбора
Рассмотрим полный пример расшифровки CSEL и восстановления семантики:
Разбор начинается с CMP. На рис. 7.16 видно, что W0 сравнивается с W1, но главный вопрос - какой это тип сравнения?
Рисунок 7.16. Семантический смысл инструкции CMP
Для определения типа сравнения нужно найти следующий используемый код условия. Здесь CSEL использует EQ. После CMP EQ семантически означает точную проверку A == B, как показано на рис. 7.17.
Рисунок 7.17. Семантический смысл EQ после CMP
Затем A и B заменяются параметрами CMP, то есть W0 и W1, после чего можно расшифровать CSEL. См. рис. 7.18.
Рисунок 7.18. Значение CSEL
Остаётся заменить EQ в шаблоне ранее установленным семантическим смыслом, получив итог на рис. 7.19.
Рисунок 7.19. Итоговый результат CMP и CSEL
Специфичные для A64 условное сравнение CCMP и условное сравнение с отрицательным значением CCMN[19] используются для построения сложных логических условий, соединённых булевыми И или ИЛИ.
Поскольку CCMP и CCMN часто встречаются при обратной разработке и довольно сложны для чтения и написания, стоит рассмотреть их подробно.
Базовый синтаксис:
arg1 всегда является регистром, а arg2 - регистром того же размера или константой. Поле nzcv является числом от 0 до 15, а cond - кодом условия, например EQ или LT.
Двоичная логика CCMP обманчиво проста, а семантика обманчиво сложна. Механическое поведение:
CCMN использует тот же синтаксис и логику, но при истинном условии выполняет CMN вместо CMP.
Удобный способ понять семантику и замысел программиста - разобрать несколько примеров. Сначала построим условие с булевым И, затем с булевым ИЛИ. Это создаст основу для восстановления смысла сложных инструкций при обратной разработке.
Построим условный переход, выполняемый тогда и только тогда, когда w0 == w1 && w2 < w3. Предположим, все значения являются знаковыми 32-битными целыми. Условные переходы подробнее объясняются в главе 8.
Сначала разложим булево выражение в дерево решений, показанное на рис. 7.20.
Рисунок 7.20. Дерево решений булева выражения
Теперь дерево можно переводить в код сверху вниз. Начало условия просто: w0 == w1 проверяется CMP w0, w1, а результат - условием EQ, как показано на рис. 7.21.
Рисунок 7.21. Условия EQ и NE
Сила CCMP заключается в одновременной обработке обеих сторон дерева. Однако для ясности построим инструкцию по частям, начиная с левой стороны, где w0 == w1.
Следуя по левой ветви, нужно проверить w2 < w3. Отдельно это делается CMP w2, w3 и условием LT. Но здесь проверка должна выполняться только на левой ветви. Поэтому CMP "повышается" до CCMP для условного сравнения. Левая ветвь соответствует установленному EQ, значит:
Логика двух инструкций показана на рис. 7.22.
Левая часть дерева завершена. Она вычисляет w0 == w1 && w2 < w3 для случая w0 == w1, выводя результат через LT.
Теперь перейдём к правой стороне и непростому полю nzcv. Механически это значение, помещаемое в NZCV, если EQ не выполнено. Но какое значение выбрать?
Сначала определим выходной код условия. Левая сторона выводит результат через LT, значит правая должна делать то же.
Правая сторона дерева должна всегда выдавать ложь. Следовательно, нужно выбрать nzcv, при котором последующая проверка LT всегда ложна. Тогда LT после CCMP будет истинно тогда и только тогда, когда w0 == w1 && w2 < w3.
Рисунок 7.22. Логика инструкций
Какое nzcv выбрать? Ранее было показано, что на уровне флагов LT означает N != V. Для ложного результата нужно N == V, например значение 0, где N = Z = C = V = 0. См. рис. 7.23.
Рисунок 7.23. Логика инструкций на основе условий LT и GE
Теперь все пути дерева завершены. Последующая условная инструкция LT выполняется только при w0 == w1 && w2 < w3.
Например, переход к _label выполняется тогда и только тогда, когда w0 == w1 && w2 < w3:
Проверим пошагово. Если w0 == w1, CMP устанавливает флаги так, что EQ инструкции CCMP истинно. Затем CCMP удовлетворяет LT, если w2 < w3. Если w0 != w1, EQ ложно, NZCV устанавливается в 0 и последующая LT также ложна. Значит, LT перехода выполняется тогда и только тогда, когда истинны оба условия.
CCMP и CCMN могут создавать не только соединители И, но и ИЛИ.
Рассмотрим тот же пример с w0 == w1 || w2 < w3. Дерево решений показано на рис. 7.24.
Рисунок 7.24. Дерево решений с булевым ИЛИ
Начало такое же: выполняется CMP w0, w1, после чего EQ истинно при w0 == w1. См. рис. 7.25.
Обе стороны сравнения второго уровня снова обрабатываются одной CCMP. Сначала определяется отдельная проверка w2 < w3: CMP w2, w3 с последующим LT. Затем CMP "повышается" до CCMP и соединяется с деревом.
Рисунок 7.25. Дерево решений CMP
Рисунок 7.26. Условие CCMP
Для ИЛИ особенно важно правильно выбрать код условия. w2 < w3 проверяется на ветви неравенства, поэтому условие CCMP - NE, а не EQ, как показано на рис. 7.26.
Наконец, нужно выбрать nzcv для другой ветви, где w0 == w1. В исходном дереве она должна сделать всё условие истинным. Поскольку результат выражается через LT, требуется nzcv, удовлетворяющее LT, то есть N != V. Подходит число 8: 8 = 0b1000, значит N = 1, V = 0. См. рис. 7.27.
Булево ИЛИ полностью построено. Последующая условная LT выполняется тогда и только тогда, когда w0 == w1 || w2 < w3.
Рисунок 7.27. Инструкция CCMP со значением nzcv
Проверим логику ещё раз. Если w0 != w1, условие NE инструкции CCMP истинно, поэтому CCMP сравнивает W2 с W3. LT устанавливается при w2 < w3 и не устанавливается иначе. Если w0 == w1, NE ложно, CCMP устанавливает NZCV в 8, и последующая LT автоматически становится истинной. Иными словами, переход выполняется, если w0 == w1 или w2 < w3, и не выполняется иначе.
[1] [назад]
[2] [назад]
[3] [назад] https://opensource.apple.com/source/xnu/xnu-4570.31.3/libsyscall/custom/SYS.h.auto.html, комментарий об интерфейсе системных вызовов ARM.
[4] [назад]
[5] [назад]
[6] [назад]
[7] [назад]
[8] [назад]
[9] [назад]
[10] [назад]
[11] [назад]
[12] [назад]
[13] [назад]
[14] [назад]
[15] [назад]
[16] [назад]
[17] [назад]
[18] [назад]
[19] [назад]
Инструкции выполняются последовательно. Но что происходит, когда программа использует условный оператор или вызывает подпрограмму? В первом разделе этой главы рассматривается, как инструкции перехода изменяют поток выполнения. Как вы узнаете во второй части главы, эти инструкции главным образом применяются для вызова функций и подпрограмм, которые будут рассмотрены подробнее.
Инструкции перехода изменяют поток выполнения, записывая в счётчик команд адрес назначения, указанный в инструкции перехода. В языке ассемблера этот адрес можно задать либо меткой, либо регистром, содержащим адрес. На двоичном уровне метки кодируются в инструкциях как непосредственное смещение, которое при выполнении инструкции прибавляется к PC. Совместно эти инструкции перехода позволяют кодировать условную логику, циклы и вызовы подпрограмм.
В таблице 8.1 приведён обзор инструкций перехода к указанной метке.
Таблица 8.1. Переходы с непосредственным адресом
В таблице 8.2 показаны инструкции, записывающие в PC значение из указанного регистра.
Таблица 8.2. Переходы по регистру
Простейшая инструкция перехода A32 - инструкция B. Она безусловно записывает в PC адрес назначения, однако её можно сделать условной, добавив к имени инструкции код условия, например EQ, как показано на рисунке 8.1.
Рисунок 8.1. Пример условного перехода
В A64 также можно использовать инструкцию перехода B, но при условных переходах синтаксис A64 требует ставить перед кодом условия точку.
Условные переходы вместе с инструкциями сравнения, устанавливающими флаги условий, используются для таких конструкций потока программы, как циклы while и for, а также операторы if-then и if-then-else. В таблице 8.3 перечислены инструкции условного перехода и проверяемые ими флаги, а в таблице 8.4 сведены условные переходы для сравнения знаковых и беззнаковых чисел.
Таблица 8.3. Инструкции условного перехода
Таблица 8.3. Инструкции условного перехода (продолжение)
Таблица 8.4. Условные переходы для знаковых и беззнаковых чисел
Рассмотрим несколько примеров условных переходов в конструкциях потока программы. В таблице 8.5 значения двух регистров сравниваются как в наборе инструкций A32, так и в A64. Если выполняется условие NE, то есть сравниваемые значения не равны, программа переходит к метке inc и увеличивает значение регистра на 1. Если условие не выполняется, программа вместо этого переходит к метке _exit.
Те же инструкции перехода позволяют создавать циклы while. В таблице 8.6 сравниваются значения двух регистров, и значение X1 увеличивается, пока не станет равным значению X2. Обратите внимание, что в этом примере переход к метке exit необязателен: если условие NE не выполняется, будут выполнены инструкции процедуры выхода.
Таблица 8.5. Примеры if-else на ассемблере
Таблица 8.6. Примеры цикла while на ассемблере
Если удалить первый переход к метке while, получится цикл do-while, который выполняет сравнение после первого увеличения X1, как показано в таблице 8.7.
Таблица 8.7. Примеры цикла do-while на ассемблере
Как видно из таблицы 8.8, запись циклов for на ассемблере похожа на уже рассмотренные примеры. Эта процедура сравнивает регистры X1 и X2 и, пока их значения не равны, записывает их сумму в регистр X3 и увеличивает X2.
Таблица 8.8. Примеры цикла for на ассемблере
В A64 инструкция перехода по регистру BR передаёт управление по адресу, указанному в регистре общего назначения, но не может выполняться условно. Если применить её к предыдущему примеру if-else, можно выполнить переход к метке compare посредством BR, предварительно загрузив её адрес в X2 инструкцией ADR.
Обратите внимание, что инструкции B и BR не подходят для вызова подпрограмм, поскольку они не заносят неявно в регистр связи адрес возврата из вызова. Из этого общего правила есть два исключения: во-первых, если подпрограмма никогда не возвращается, и, во-вторых, если в регистр связи явно записан особый адрес, не совпадающий с адресом инструкции сразу после перехода. Однако на практике при дизассемблировании скомпилированного кода оба этих крайних случая встречаются редко, и почти все вызовы функций выполняются одной из инструкций группы перехода с сохранением адреса возврата.
В процедурах, проверяющих нулевое значение, наборы инструкций T32 и A64 позволяют упростить код с помощью CBNZ и CBZ. Эти инструкции сравнивают регистр с нулём и выполняют условный переход, не изменяя флаги условий. В наборе A32 их нет. См. таблицу 8.9.
Таблица 8.9. Инструкции сравнения и перехода
Инструкция CBNZ сравнивает указанный регистр с нулём и переходит к метке, если это условие ложно.
Эта инструкция эквивалентна следующим двум операциям:
Инструкция CBZ сравнивает указанный регистр с нулём и переходит к метке, если это условие истинно.
Эта инструкция эквивалентна следующим двум операциям:
Инструкции A64 Test bit and Branch if Zero (TBZ, "проверить бит и перейти, если ноль") и Test bit and Branch if Nonzero (TBNZ, "проверить бит и перейти, если не ноль") проверяют значение позиции бита, заданной через #imm, и в зависимости от результата переходят к метке, как показано в таблице 8.10.
Таблица 8.10. Инструкции A64 проверки и перехода
В наборе инструкций T32 предусмотрены инструкции табличного перехода TBB и TBH. Они выполняют относительные к PC переходы вперёд через таблицы переходов, где Rn - базовый регистр, указывающий на таблицу из одно- или двухбайтовых смещений, а Rm задаёт индекс в таблице. Обе инструкции доступны только в наборе T32. См. таблицу 8.11.
Таблица 8.11. Условные переходы, доступные только в T32
Эта инструкция иногда встречается в дизассемблированном коде оптимизированных операторов switch. Рассмотрим следующую простую функцию с конструкцией switch-case:
Если скомпилировать эту программу для набора инструкций A32/T32 с параметром компилятора -O1, в дизассемблированном выводе можно увидеть инструкцию TBB.
Инструкции перехода не только изменяют поток выполнения, но и могут менять состояние набора инструкций. Как вам уже известно, AArch32 поддерживает два набора инструкций: A32 для 32-разрядных инструкций ARM и T32 для 32- и 16-разрядных кодировок инструкций Thumb.
Jazelle - ещё одно, менее распространённое состояние, в котором байт-коды Java выполняются непосредственно; оно реализовано в более старых архитектурах Arm. Однако в архитектуре Armv8 это состояние инструкций устарело: аппаратное ускорение байт-кодов Java больше не поддерживается. Реализация AArch32 в Armv8 поддерживает только тривиальную реализацию Jazelle.
В AArch32 инструкция перехода и переключения BX и инструкция перехода с сохранением адреса возврата и переключением BLX служат межрежимными переходами между состояниями наборов инструкций A32 и T32. Межрежимный переход также можно выполнить некоторыми, но не всеми, операциями загрузки PC. Такие инструкции загрузки PC действуют как переход, сохраняя описанную выше семантику переключения. К ним относятся LDR с PC в качестве регистра передачи, инструкции POP и LDM, включающие PC в список регистров, а также многие инструкции обработки данных, использующие PC как регистр назначения. Прямая запись в PC поддерживается только в AArch32, поскольку в AArch64 PC может обновляться лишь при переходе, входе в исключение или возврате из исключения.
Примеры действующих подобно переходу инструкций, которые могут записывать значение непосредственно в PC и вести себя как межрежимный переход:
Прежде чем переходить к особенностям этих инструкций, рассмотрим, зачем вообще нужны особые инструкции для смены набора инструкций. Предположим, требуется написать небольшую ассемблерную программу, смешивающую инструкции Arm и Thumb. В главе 4 "Архитектура Arm" говорилось, что директивы .ARM и .THUMB предписывают ассемблеру переводить последующие инструкции соответственно в коды операций A32 или T32. Посмотрим, что произойдёт при использовании этих директив без инструкций, переключающих набор инструкций.
Исходный текст на ассемблере:
Результат дизассемблирования:
Результат дизассемблирования выглядит так, как было задумано: первые три инструкции относятся к A32, а последние три интерпретируются как инструкции T32. Однако при выполнении этого кода процессор ожидает выравнивания каждой инструкции по границе 4 байт и выполняет коды операций T32 как инструкции A32, поскольку бит Thumb в CPSR не установлен. Иными словами, при написании ассемблерного кода в дизассемблированном выводе можно увидеть ожидаемые инструкции, но процессор выполнит не их. Поэтому важно понимать внутренний механизм. Разберём его подробнее.
Поскольку каждая инструкция A32 выровнена по границе 4 байт, а процессор всё ещё находится в состоянии A32, для каждой инструкции он выбирает 4 байта кодов операций в порядке little-endian и интерпретирует их как инструкцию A32. Рассмотрим первую инструкцию T32. Она не помещается в 16-разрядную кодировку Thumb, поэтому разбивается на два полуслова. При выборке этой инструкции в порядке little-endian процессор первым извлекает младшее полуслово следующего слова, то есть полуслова меняются местами. В результате получается совершенно иная кодировка инструкции.
Как наша первая инструкция T32 mov превратилась в andeq? Ответ прост: процессор интерпретирует биты каждого кода операции в соответствии с текущим состоянием набора инструкций. Сравним исходный и получившийся варианты на рисунке 8.2.
Рисунок 8.2. До и после
При изучении ассемблера полезно рассматривать внутреннюю интерпретацию инструкций и понимать их на более глубоком уровне. В справочном руководстве по архитектуре Arm приведены кодировки инструкций и определения синтаксиса, помогающие найти нужный ответ. В этом примере мы сосредоточимся на побитовой кодировке инструкций обработки данных A32, чтобы увидеть, как 0x0001F04F превращается в инструкцию andeq. Таблица 8.12 представляет собой сокращённый перечень обязательных состояний битов, при которых инструкция интерпретируется как инструкция обработки данных.
Таблица 8.12. Таблица кодировок групп инструкций обработки данных
Рассмотрев биты наших кодов операций, мы видим, что они соответствуют кодировке регистровых инструкций обработки данных с непосредственным сдвигом. См. рисунок 8.3.
Рисунок 8.3. Кодировка инструкции
Пока всё сходится. А что означают оставшиеся биты? Далее следует рассмотреть кодировки класса инструкций обработки данных с непосредственным сдвигом и определить компоненты, представленные оставшимися битовыми шаблонами. К ним относятся код условия, регистр назначения, исходные операнды и операция регистрового сдвига с величиной сдвига.
В итоге рисунок 8.4 показывает положения оставшихся компонентов этого класса инструкций и интерпретацию их битовых шаблонов, дающую ровно ту инструкцию, которую мы уже видели.
Рисунок 8.4. Компоненты кодировки инструкции
Две следующие 16-разрядные инструкции T32 из исходной ассемблерной программы интерпретируются как одна 32-разрядная инструкция A32. См. рисунок 8.5.
Рисунок 8.5. Преобразование кодировки инструкции T32 в A32
Поэтому процессор должен переключиться в состояние набора инструкций T32, чтобы эти коды операций интерпретировались и выполнялись как инструкции Thumb. Как упоминалось в главе 4 "Архитектура Arm", состояние набора инструкций определяется битами состояния набора инструкций в CPSR. Чтобы процессор выполнял инструкции T32, необходимо установить бит Thumb.
Возвращаясь к тому месту, на котором мы остановились: в таблице 8.13 показаны инструкции перехода A32, способные при необходимости переключаться между состояниями наборов инструкций A32 и T32.
Таблица 8.13. Инструкции A32 перехода и переключения
Различие между этими инструкциями состоит в том, что BLX дополнительно сохраняет адрес возврата в LR и поэтому используется для вызовов подпрограмм. Подробнее о подпрограммах будет рассказано далее.
Когда BLX переходит к метке, состояние набора инструкций и относительное к PC смещение целевой инструкции кодируются непосредственно в инструкции. Если адрес назначения задан в регистре, это не так. Поскольку инструкции выравниваются по границе 4 или 2 байт, младший значащий бит адресов инструкций, записываемых в PC, всегда равен нулю. Когда инструкции BX и BLX переходят по значению регистра, целевое состояние набора инструкций определяется его младшим значащим битом. Если этот бит равен 0, последующие инструкции выполняются как A32; если он равен 1 - как T32.
• Переключиться в состояние A32 или остаться в нём, если бит [0] = 0.
• Переключиться в состояние T32 или остаться в нём, если бит [0] = 1.
Это приобретает особое значение при написании собственного ассемблерного кода, смешивающего инструкции A32 и T32. Если просто записать в регистр адрес инструкции T32, к которой требуется перейти, и выполнить переход, младший значащий бит будет равен 0, поэтому бит Thumb не установится. Решение состоит в том, чтобы перед переходом установить младший бит значения регистра в 1. В примере на рисунке 8.6 требуется выполнить инструкцию сразу после перехода как T32. Для этого достаточно прибавить 1 к значению PC, записать результат в регистр и перейти по нему. Напомним: в режиме A32 PC фактически указывает на текущую инструкцию плюс 8.
Рисунок 8.6. Переключение в Thumb
Сделать это можно несколькими способами, например инструкцией ADR загрузить в регистр адрес метки и прибавить к нему 1.
Переходы к подпрограммам подчиняются иному правилу, чем рассмотренные ранее прямые переходы. Когда программа вызывает подпрограмму и ожидает, что та вернёт управление вызывающей функции, ей нужен способ сохранить адрес возврата. В этом разделе мы рассмотрим работу подпрограмм и инструкции перехода, используемые для их вызова.
Вызовы подпрограмм выполняются специализированной группой инструкций, называемых инструкциями перехода с сохранением адреса возврата. Они не только изменяют счётчик команд, направляя его на начало вызываемой функции, но и сохраняют для этой функции адрес возврата в регистре связи. Адрес возврата - адрес инструкции, непосредственно следующей за инструкцией перехода с сохранением адреса возврата. Завершив работу, подпрограмма возвращает выполнение по этому адресу, и оно продолжается в вызывающей функции.
Функции и подпрограммы будут подробнее рассмотрены в следующем разделе, а сначала познакомимся с применяемыми в этом контексте инструкциями перехода.
Инструкции AArch32 и AArch64 из таблицы 8.14 выполняют вызовы подпрограмм.
Таблица 8.14. Инструкции вызова подпрограмм
Обе инструкции AArch32, BL и BLX, записывают в регистр связи LR адрес следующей по порядку инструкции, который служит адресом возврата. В PC записывается заданный адрес назначения, и вызывается подпрограмма.
На рисунке 8.7 BL используется для вызова подпрограммы func, при этом адрес следующей инструкции (0x10060) записывается в LR. Младший бит LR устанавливается в 0, если инструкции вызывающей функции выполнялись в состоянии Arm, и в 1, если они выполнялись в состоянии Thumb. Поэтому подпрограмма func заканчивается инструкцией BX LR, которая записывает в PC адрес из LR и при необходимости переключает состояние набора инструкций в соответствии с младшим битом адреса назначения.
Рисунок 8.7. Вызов подпрограммы инструкцией BL (A32)
Инструкция BLX используется, чтобы при переходе дополнительно переключить состояние набора инструкций для подпрограммы. Пример вызова подпрограммы посредством BLX показан на рисунке 8.8.
Рисунок 8.8. Вызов подпрограммы инструкцией BLX (A32)
Программа начинает работу в состоянии A32, заполняет регистры R1 и R2, а затем инструкцией BLX переходит к подпрограмме func. Поскольку инструкции подпрограммы func предназначены для выполнения как T32, процессор переключает состояние набора инструкций и выполняет их как инструкции T32. Инструкция BX LR записывает в PC адрес из LR, младший бит которого равен 0, инициируя переключение из текущего состояния T32 в состояние A32 вызывающей функции.
В AArch64 для вызовов подпрограмм применяются инструкции BLR и BL, записывающие адрес возврата в регистр X30. Инструкция RET выполняет возврат из подпрограммы и используется, когда вход в неё был выполнен инструкцией BL или BLR. Внутренне RET выполняет ту же операцию, что и BR X30, но дополнительно содержит подсказку о том, что это возврат из подпрограммы. См. рисунок 8.9.
Рисунок 8.9. Переход к подпрограмме в A64
Практически во всех современных программах код организован в функции, реализующие логику определённой задачи. Функции могут выполнять условную логику, циклы и обработку данных, а также вызывать другие функции или даже самих себя рекурсивно для решения подзадач. Каждая функция может принимать входные параметры и при возврате необязательно передавать результат вызывающей стороне, после чего выполнение продолжается в вызывающей функции.
Определение функции, включая её параметры и возвращаемые значения, называется сигнатурой функции. Сигнатура используется процедурой, то есть вызывающей стороной, чтобы правильно оформить и эффективно передать аргументы вызываемой функции, то есть подпрограмме, а после завершения функции вернуть её результат вызывающей стороне.
Примечание. В этом разделе термины "аргумент" и "параметр" используются как взаимозаменяемые, а термин "функция" обозначает процедуры как с возвращаемым значением, так и без него. Обозначение A32 используется для обоих наборов инструкций, A32 и T32.
Двоичный интерфейс приложений (Application Binary Interface, ABI) для архитектуры Arm - совокупность стандартов, определяющих протоколы взаимодействия двоичных файлов и средств разработки в различных средах выполнения на базе Arm. Эти стандарты позволяют функциям эффективно взаимодействовать как внутри двоичного модуля, так и между модулями.[2]
В таблице 8.15 перечислены основные стандарты ABI, большая часть которых важнее для авторов компиляторов C и C++, компоновщиков и библиотек времени выполнения. Для обратной разработки двоичных файлов Arm мы сосредоточимся на основах стандарта вызова процедур для архитектуры Arm (AAPCS).
Таблица 8.15. Стандарты ABI
Стандарт AAPCS задаёт основу для группы вариантов стандарта вызова процедур (PCS) и определяет обязательства вызывающих и вызываемых процедур, а также среды их выполнения, необходимые для создания, сохранения и изменения состояний программы. Он определяет, какие регистры разрешается свободно изменять, а какие должны сохраняться между вызовами, а также компоновку, выравнивание и размер типов данных C и C++.
Механизм передачи, посредством которого функция, то есть вызывающая сторона, передаёт аргументы вызываемой функции, а возвращаемые значения передаются обратно, называется соглашением о вызовах.
В таблице 8.16 сведены регистры общего назначения, видимые набору инструкций A64, и их назначение в стандарте AAPCS64. Обратите внимание, что обозначения x0...x30 в этой таблице относятся как к 64-разрядным регистрам Xn, так и к 32-разрядным регистрам Wn.
Таблица 8.16. Регистры общего назначения A64 и их использование в AAPCS64
В таблице 8.17 перечислены основные регистры общего назначения, то есть целочисленные регистры, видимые наборам инструкций A32, и их роль в стандарте вызова процедур.
Таблица 8.17. Регистры общего назначения A32 и их использование в AAPCS32
Стандарт AAPCS также определяет, какие регистры требуется сохранять между вызовами функций, а какие вызываемая сторона может свободно изменять. Регистры делятся на энергозависимые, сохраняемые вызывающей стороной, и энергонезависимые, сохраняемые вызываемой стороной. Энергозависимый регистр - регистр, значение которого подпрограмма может свободно изменять во время выполнения. Напротив, значения энергонезависимых регистров должны сохраняться при вызове подпрограммы. Иными словами, если подпрограмма изменяет энергонезависимые регистры, перед возвратом к вызывающей функции она обязана сохранить и восстановить их содержимое. См. таблицу 8.18.
Таблица 8.18. Энергозависимые и энергонезависимые регистры
Предположим, например, что функция хранит важное значение в X7 и собирается вызвать подпрограмму. Поскольку регистр X7 энергозависим, функция не может гарантировать, что после возврата из подпрограммы его значение останется прежним. Поэтому перед вызовом подпрограммы вызывающая функция может сохранить значение X7 во временной области стека или скопировать его содержимое в энергонезависимый регистр, например X20. Так как X20 определён как энергонезависимый, его содержимое сохраняется между вызовами подпрограмм.
Единственным исключением среди этих регистров являются зависящие от платформы R9 и X18. Их назначение и требования к сохранению определяются платформой. Например, в Windows на базе Arm X18 - энергонезависимый регистр, указывающий в пользовательском режиме на блок окружения потока (Thread Environment Block, TEB), а в режиме ядра - на управляющую область процессора ядра (Kernel Processor Control Region, KPCR). В большинстве операционных систем на базе Linux этот регистр используется для локального хранилища потока (Thread Local Storage, TLS).
Аналогично, в A32 назначение и требования к сохранению R9 зависят от платформы. Например, U-Boot хранит в R9 указатель на глобальную область данных,[3] тогда как на многих других платформах R9 используется как энергонезависимый регистр общего назначения.
AAPCS определяет несколько целочисленных регистров, которые можно использовать для передачи аргументов. Каждый аргумент передаётся непосредственно в целочисленных регистрах слева направо: в X0...X7 для A64 и в R0...R3 для A32.
Эти регистры также могут служить временными, то есть содержать непосредственное значение как часть вычисления. Если функции требуется сохранить содержимое временного регистра на протяжении вызова другой функции, она должна сохранить, а затем восстановить это значение.
В A32 целочисленные и указательные возвращаемые значения передаются в R0, а составные структуры размером 8 и 16 байт, включая 64-разрядные целочисленные возвращаемые значения, передаются в R0-R4. В таблице 8.19 показано, что ABI подразумевает под целочисленными типами данных.[4]
Таблица 8.19. Размер целочисленных типов данных в байтах
Порядок битов эквивалентен загрузке значения из памяти инструкцией LDM: при порядке little-endian R0 содержит младшие 32 бита значения.
В A64 целочисленные и указательные возвращаемые значения передаются в X0, а 16-байтовые составные структуры, возвращаемые по значению, передаются в X0 и X1, причём X0 содержит младшие 64 бита.
Рассмотрим пример A32 на основе следующего фрагмента кода C:
Подпрограмма func1 принимает два аргумента, a и b. Перед вызовом func1 вызывающая функция записывает значения аргументов в первые два регистра.
func1 использует эти значения для простого вычисления и возвращает результат вызывающей стороне через регистр R0. См. рисунок 8.10.
Рисунок 8.10. Вызов подпрограммы с аргументами
В отличие от A64, наборы инструкций A32 предъявляют более строгие требования к знаковому и нулевому расширению малых целочисленных значений. Если первый параметр функции принимает 8-разрядное знаковое значение, перед передачей через R0 вызывающая сторона должна знаково расширить его до 32 бит. Знаковые значения должны расширяться со знаком, а беззнаковые - нулями.
Рассмотрим, например, следующую сигнатуру функции:
Здесь функция ожидает три параметра. Первый - 32-разрядное целое число, которое передаётся через R0. Второй - знаковый char, поэтому 8-разрядное значение требуется знаково расширить до 32 бит и передать через R1. Третий параметр - беззнаковый short, поэтому 16-разрядное значение необходимо расширить нулями до 32 бит и передать через R2. Затем функция выполнится и в конце вернёт 32-разрядное значение int, передав его вызывающей стороне в R0.
Типы массивов преобразуются в указатели и передаются по ссылке. Переданное значение указателя указывает на адрес в памяти первого элемента массива, то есть элемента с индексом 0.
Для аргументов с плавающей точкой A64 использует регистры v0-v7 или их соответствующие представления. Иными словами, функция с двумя параметрами float передаёт их через младшие 32 бита v0 и v1. В A32 первые четыре аргумента с плавающей точкой передаются через v0-v3. Исключение - применение ABI с программной плавающей точкой, при котором операции с плавающей точкой эмулируются целочисленными операциями вместо сопроцессора, способного работать с плавающей точкой. В таких случаях значения с плавающей точкой рассматриваются как соответствующие целочисленные типы, например float - как 32-разрядный int, и подчиняются основным правилам обработки целых чисел.
Если значение больше одного регистра, оно разбивается между несколькими целочисленными регистрами, когда доступно достаточно регистров передачи параметров. В A32 значения размером с двойное слово делятся между двумя целочисленными регистрами: либо R0 и R1, либо R2 и R3.
Рассмотрим конкретный пример на основе двух следующих сигнатур функций:
Первая функция определяет два 64-разрядных аргумента. Они помещаются в регистры A64, но в A32/T32 каждый из них приходится разделить между двумя целочисленными регистрами. См. рисунок 8.11.
Рисунок 8.11. Регистры аргументов для двух 64-разрядных целых чисел
Вторая сигнатура определяет три 32-разрядных аргумента, за которыми следует 64-разрядный аргумент d2. См. рисунок 8.12. В A32 остаётся только один регистр аргумента, а значит, это 64-разрядное целое нельзя разделить между двумя регистрами. Его приходится "вытеснить", то есть сохранить, в стек в области "стековых аргументов", на которую в момент вызова функции указывает SP.
Рисунок 8.12. Регистры аргументов для трёх 32-разрядных и одного 64-разрядного целого числа
Аргументы вытесняются в стек слева направо в порядке убывания адресов памяти, поэтому в момент вызова SP указывает на крайний левый вытесненный аргумент. Каждая запись в списке вытесненных аргументов дополняется как минимум до 32 бит в A32 и до 64 бит в A64 либо до естественного выравнивания своего типа, если оно больше.
Если скомпилировать следующую простую программу-заглушку, можно увидеть, что перед вызовом функции func аргумент uint64_t сохраняется в стеке:
На рисунке 8.13 показан фрагмент ассемблерного кода, отвечающий за подготовку аргументов к вызову функции. Первые три регистра заполняются первыми тремя аргументами uint32_t с помощью инструкций MOV. Однако значение uint64_t хранится в пуле литералов, а инструкция ADR записывает в регистр R4 адрес этого места. Затем инструкция LDRD загружает двойное слово оттуда в регистры R3 и R4.
Рисунок 8.13. Подготовка аргументов на ассемблере инструкциями MOV и LDRD
После этого инструкция STRD сохраняет двойное слово из R3 и R4 по адресу стека, на который указывает SP. См. рисунок 8.14.
Составные типы размером более 16 байт, возвращаемые по значению, обрабатываются иначе. Вызывающая сторона резервирует в стеке место для результата, а указатель на это место передаётся вызываемой стороне через X0/R0 либо через X1/R1, если X0/R0 используется для передачи параметра this при вызове функции-члена C++.
В C++ функции-члены определены в классах и структурах и вызываются объектно-ориентированным способом непосредственно для экземпляра объекта, обозначаемого ключевым словом this. Указатель на объект this передаётся вызову как скрытый "первый" параметр-указатель в X0 или R0 соответственно. Для таких функций первый явный целочисленный параметр или указатель передаётся в X1 или R1, второй - в X2 или R2 и так далее.
Рисунок 8.14. Сохранение двойного слова из регистров r3 и r4 инструкцией STRD
Теперь, когда в общих чертах рассмотрена передача аргументов и возвращаемых значений между функциями и подпрограммами, необходимо понять различие между листовыми и нелистовыми функциями, а также их прологи и эпилоги. В предыдущем разделе мы узнали, что инструкции перехода к подпрограмме, например BL и BLX, сохраняют адрес возврата в специальном регистре, чтобы вызываемая сторона могла вернуться к вызывающей. В этом разделе станет ясно, почему LR является энергонезависимым регистром и при каких обстоятельствах его требуется сохранять в прологе и восстанавливать в эпилоге подпрограммы.
Листовые функции не вызывают других подпрограмм. В следующем примере функция main вызывает func и сохраняет адрес возврата в LR. Подпрограмма func является листовой функцией и, не вызывая по пути другую функцию, возвращается к вызывающей стороне переходом по LR. См. рисунок 8.15.
Рисунок 8.15. Возврат из листовой функции переходом по LR
Но что произойдёт, если func вызовет другую подпрограмму? Согласно описанному механизму, LR, содержащий адрес возврата в функцию main, будет перезаписан, как только func вызовет ещё одну подпрограмму инструкцией BL или BLR. Поэтому при вложенных вызовах функций, как в предыдущем примере, требуется сохранить исходное значение LR перед вызовом другой подпрограммы, который запишет в LR новый адрес возврата. См. рисунок 8.16.
Рисунок 8.16. Вызов нелистовой функции с сохранением значения LR
В начале пролога функция помещает в стек значения регистров, которые собирается изменить, но обязана сохранить. Она корректирует SP, освобождая место для локальных переменных, и обновляет регистр указателя кадра для текущего кадра стека.
Одно из значений, помещаемых нелистовой функцией в стек в начале пролога, - LR, поскольку при вызове другой подпрограммы оно будет перезаписано. Затем в эпилоге функции это значение восстанавливается в PC.
В зависимости от реализации платформы указатель кадра (FP/R7) используется для отслеживания текущего кадра стека, поэтому его также необходимо сохранять.
Рассмотрим пример на основе следующего кода C:
Если скомпилировать этот код для набора инструкций A32 и дизассемблировать его с помощью objdump, получится следующий вывод:
Разобьём его на меньшие части и рассмотрим прологи и эпилоги функций. Пролог main помещает в стек как R7, так и LR. Затем он изменяет указатель стека SP, освобождая место для локальных переменных, и настраивает R7 на текущий кадр стека. После этой подготовки переданные подпрограмме аргументы сохраняются в стеке, как показано на рисунке 8.17, а затем снова загружаются в регистры аргументов для вызова функции sum.
Рисунок 8.17. Иллюстрация пролога функции
При вызове sum в стек помещается только R7. Причина в том, что sum - листовая функция и не вызывает другую подпрограмму. Как показано на рисунке 8.18, SP и R7 настраиваются для текущего кадра стека, а переданные аргументы сохраняются в стеке. Затем значения аргументов загружаются в другие регистры, используемые для сложения, а результат копируется в R0. Эпилог возвращает SP исходное значение и восстанавливает R7 из стека, после чего подпрограмма возвращается к вызывающей стороне переходом по LR.
Программа продолжает выполнение в функции main: сохраняет результат в стеке, устанавливает R0 в 0, корректирует R7 и SP и возвращается к вызывающей функции, записывая сохранённый адрес возврата в PC инструкцией POP. См. рисунок 8.19.
Рисунок 8.18. Настройка кадра стека
Рисунок 8.19. Эпилог функции
Хотя только что рассмотренный пример относится к A32, логика прологов и эпилогов функций A64 очень похожа.
Чтобы увидеть, как выглядит дизассемблированный код программы при использовании разных компиляторов и их версий, можно воспользоваться Compiler Explorer на сайте Godbolt.org.[5] Он выделяет отдельные участки исходного кода и отображает соответствующий им дизассемблированный код теми же цветами. См. рисунок 8.20.
Рисунок 8.20. Снимок экрана Godbolt.org
[1] [назад] Устарела в Armv8.
[3] [назад] github.com
[4] [назад] Procedure Call Standard for the Arm Architecture, раздел 5.1 "Fundamental Data Types" (IHI 0042J).
[5] [назад] Compiler Explorer: godbolt.org.
Для статического анализа двоичных файлов Arm обычно не нужна полноценная среда Arm. Например, Ghidra и IDA без труда анализируют двоичные файлы Arm на машинах с другой архитектурой, поскольку умеют интерпретировать и показывать содержащийся в них дизассемблированный машинный код. Но что делать, если в рамках динамического анализа требуется запустить эти программы Arm? Для этого исполняемые файлы Arm необходимо настроить и запустить в среде на базе Arm.
При создании среды Arm обычно есть три варианта. Первый очевиден: локальная среда на физическом оборудовании Arm, например ноутбуке, сервере или специальной плате Arm. До недавнего времени исследователям приходилось приобретать отдельные платы Arm, и самым доступным вариантом была Raspberry Pi. За последние несколько лет положение изменилось: ноутбуки и серверы с наборами микросхем Arm становятся всё более распространёнными. После выпуска разработанной Apple микросхемы M1 большинство устройств Mac теперь основано на архитектуре Arm.
Второй вариант - эмулятор. С помощью QEMU и подобных эмуляторов можно создать виртуальную среду Arm, которая декодирует и выполняет программы Arm полностью программными средствами. Целевой двоичный файл работает внутри виртуализированной среды, не подозревая, что его процессор Arm реализован программно и выполняется процессором совершенно другой архитектуры.
Третий вариант - облачная среда Arm, например экземпляры EC2 A1 в Amazon Web Services (AWS).[1] В 2020 году AWS запустила экземпляры EC2 C6g и R6g на собственном серверном процессоре Graviton2,[2] использующем архитектуру Armv8-A. Облачные экземпляры - самый доступный способ создать среду Arm для тестирования и исследований.
У каждого из трёх вариантов свои компромиссы, а правильный выбор зависит от задачи. Например, если собственного оборудования Arm нет, покупать новую машину Arm не хочется, а требуется лишь выполнить простую программу Arm, программной эмуляции, скорее всего, хватит. Если же нужна чистая производительность, например для фаззинга программ в поисках уязвимостей, издержки полной эмуляции процессора, вероятно, склонят выбор в пользу физического оборудования. Даже тогда выбор между облачным и локальным тестированием будет зависеть от ожидаемой нагрузки и предпочтения: самостоятельно купить оборудование и управлять им либо платить по мере использования.
Самый прямой способ запускать программы Arm - физическое устройство Arm, например плата Arm. Такие платы объединяют процессор Arm с основными компонентами компьютера, включая память и несколько периферийных устройств вывода, и образуют полноценную среду Arm. Выбор плат пугающе велик: они различаются ценой, микроархитектурой, архитектурой и предоставляемой периферией.[3]
Между потребительской платой и платой разработки также есть существенная разница. Платы разработки неизбежно дороже, поскольку предоставляют среду для разработки проектов систем на кристалле, программных и аппаратных приложений, а также доступ к более развитым средствам отладки и периферийным устройствам. Например, ARM Development Platform Juno r2[4] предназначена для разработки ядер и инструментов Armv8-A и основана на многоядерных процессорных кластерах Cortex A72 и A53 MPCore.
Хотя плата Juno относится к дорогому сегменту, для других задач существуют более доступные варианты. Например, Hikey 960[5] оснащена процессором Huawei Kirin 960 с четырьмя ядрами Arm Cortex-A73 и четырьмя ядрами Arm Cortex-A53.
Это была первая 64-разрядная плата разработки Arm, официально поддержанная в Android Open Source Project (AOSP). Хотя Hikey по-прежнему полезна, разработка AOSP начала смещаться к более новым платам, например DragonBoard 820c,[6] основанной на совместимой с Armv8-A системе на кристалле Qualcomm Snapdragon 820E. В зависимости от времени чтения книги уже могут существовать более новые и мощные платы разработки. Поэтому, прежде чем покупать плату для разработки и тестирования ядра и драйверов AOSP, сравните варианты и проверьте поддержку AOSP.
Выбирая плату Arm, учитывайте задачу, которую она должна решать. Существует множество других плат разработки специального назначения с различными архитектурами процессоров, основанными на разных микроархитектурах и архитектурах.
Самая известная потребительская плата Arm - несомненно Raspberry Pi, разработанная Raspberry Pi Foundation.[7] Изначально Pi создавалась как простой недорогой компьютер Arm для обучения информатике, однако эта автономная платформа Arm, оставаясь дешёвой, обладает заметной мощностью и легко справляется с задачами общего назначения, например с полноценной графической средой рабочего стола.
Новейшей версией Pi является Raspberry Pi 4 Model B.[8] В этой плате объединены мощный четырёхъядерный процессор Armv8-A Cortex-A72, от 2 до 8 Гбайт ОЗУ, встроенная двухдиапазонная беспроводная сеть 802.11ac, гигабитный Ethernet, Bluetooth 5.0, несколько портов USB 3.0 и USB 2.0, поддержка вывода 4K на два монитора, а также аппаратно ускоренная графика и декодирование видео.
Настройка Raspberry Pi 4 Model B проста и сводится к подготовке карты MicroSD с операционной системой. Система по умолчанию - Raspberry Pi OS, ранее называвшаяся Raspbian и основанная на Debian Linux,[9] однако можно использовать и другие дистрибутивы, совместимые с оборудованием и архитектурой процессора платы, например Ubuntu[10] или FreeBSD.[11]
Для первоначальной настройки нужны монитор, клавиатура и мышь. После загрузки ОС и получения доступа к терминалу можно настроить SSH для удалённого входа либо продолжить работу локально.
Ещё одна распространённая потребительская плата Arm - ROCK64,[12] основанная на системе на кристалле Rockchip RK3399.[13] Она содержит двухъядерный Cortex-A72 и четырёхъядерный Cortex-A53 с отдельным сопроцессором NEON, а также графический процессор ARM Mali-T864.
Конкретная плата Arm выбирается в зависимости от задачи и, что важнее всего, требуемой архитектуры процессора. Если планируется выполнять двоичные файлы, скомпилированные для Armv8-A, нужна плата с поддержкой этой архитектуры. Плата Armv7-A не сможет нативно запускать 64-разрядные двоичные файлы Arm, поскольку Armv7-A - 32-разрядная архитектура набора инструкций.
При обратной разработке двоичных файлов Arm покупка и настройка полноценной физической среды Arm нередко кажется лишней обузой. Особенно если основной компьютер построен не на Arm и не нужна чистая производительность для ресурсоёмких процессорных задач. Сценариев эмуляции среды Arm множество. Одно из главных преимуществ - возможность загружать процессорные ядра разных типов и разные архитектуры процессоров. Самый популярный эмулятор процессора для создания такой виртуальной среды - QEMU, свободный эмулятор и виртуализатор с открытым исходным кодом, работающий в Linux, macOS и Windows.[14] QEMU поддерживает два основных "вида" эмуляции: полносистемную и пользовательского режима.
В режиме полносистемной эмуляции QEMU создаёт полную автономную "виртуальную машину". Вместе с процессором Arm эта ВМ эмулирует десятки виртуализированных периферийных устройств: жёсткие диски, сетевые адаптеры, устройства ввода и так далее. На ВМ можно установить операционную систему, скопировать в неё тестовый двоичный файл и выполнить его в виртуализированной среде Arm.
Полносистемная эмуляция полезна, особенно если запускаемому ПО нужна выделенная среда, например при эмуляции встроенного ПО, или если требуется динамический анализ вредоносного ПО. Если же нужно лишь поэкспериментировать с ассемблером Arm, проверить невредоносные двоичные файлы Arm или выполнить простую отладку, а полноценная система не нужна, QEMU предоставляет другой режим: эмуляцию пользовательского режима.
В этом режиме QEMU запускает один двоичный файл, скомпилированный для архитектуры, отличной от поддерживаемой основной системой, например AArch64 на x86_64. Внутренне QEMU эмулирует процессор Arm, программно декодируя и выполняя каждую инструкцию Arm. Системные вызовы программы перехватываются и передаются основной системе, благодаря чему программа прозрачно взаимодействует с остальной системой.
В этом примере основная ОС - Ubuntu 20.04.1 LTS на архитектуре процессора x86_64. Настроим эмуляцию пользовательского режима для запуска двоичных файлов, скомпилированных для 32- и 64-разрядных архитектур Arm. Сначала установим следующие пакеты:
Для 32-разрядной Arm нужны двоичные утилиты Arm и совместимая с Arm версия GCC.
Для AArch64 установите:
Теперь, когда QEMU установлен, скомпилируем простую программу для AArch64 и запустим её на основной системе Linux x64 с процессором Intel посредством эмуляции пользовательского режима QEMU. Код тестовой программы состоит из следующих двух строк и сохранён в hello64.c:
Теперь программу можно кросс-компилировать версией GCC для AArch64, создав статический исполняемый файл:
Следующая быстрая проверка показывает, что основная система - машина Ubuntu на базе x64, а двоичный файл правильно скомпилирован в исполняемый файл Arm AArch64:
Теперь двоичный файл можно запустить непосредственно средствами эмуляции пользовательского режима QEMU:
Здесь эмуляция пользовательского режима QEMU берёт двоичный файл Arm и эмулирует его напрямую, программно обрабатывая и выполняя каждую инструкцию Arm. Когда виртуализированная программа Arm пытается вызвать системный вызов write, чтобы вывести сообщение на консоль, она делает это через интерфейс системных вызовов Arm. QEMU незаметно перехватывает запрос и переводит его в эквивалентный системный вызов x64 Ubuntu, в результате чего программа печатает сообщение в консоли.
В предыдущей командной строке эмуляция пользовательского режима QEMU вызывалась непосредственно через qemu-aarch64, но у QEMU есть ещё одна хитрость. Двоичный файл можно запустить прямо из командной строки:
Возможно, вы удивились или решили, что здесь ошибка. Как Linux x64 внезапно научился запускать двоичный файл Arm? Секрет скрыт в пакете qemu-user-binfmt. Если заглянуть в /proc/sys/fs/binfmt_misc, станет видно, откуда берётся эта магия.
Этот файл сообщает ядру Linux, как интерпретировать файлы, соответствующие определённой сигнатуре. В данном случае сигнатура соответствует файлу ELF, в заголовке которого поле e_machine равно EM_AARCH64 (0xb7). При выполнении подходящего файла Linux запускает соответствующий интерпретатор, в данном случае программу эмуляции пользовательского режима AArch64, а та уже запускает программу. Та же логика применима к 32-разрядным двоичным файлам.
Для динамически скомпонованных исполняемых файлов путь к интерпретатору ELF и библиотекам можно передать параметром командной строки -L.
Для 32-разрядных двоичных файлов Arm это выглядит так:
Теперь, зная, как компилировать код для архитектуры Arm и запускать его на основной системе x86_64, попробуем сделать то же с исходным текстом на ассемблере. Предположим, требуется собрать следующую 64-разрядную программу Arm:
Поскольку собственные ассемблер и компоновщик основной системы не понимают ассемблер Arm, необходимо использовать ранее установленную версию для AArch64.
Для проверки 32-разрядных двоичных файлов можно использовать следующий код:
После сборки и компоновки утилитами arm-linux-gnueabihf-* программу можно выполнить в основной системе.
QEMU - мощный эмулятор с большим набором возможностей и параметров, описанных в руководстве пользователя по системной эмуляции QEMU.[15] Выполнить системную эмуляцию можно многими способами: вручную создать образ, загрузить ISO-образ и настроить установку либо использовать готовый образ. Поскольку параметры командной строки постоянно меняются, а некоторые даже объявляются устаревшими, создать вневременное руководство по настройке невозможно. Поэтому рассмотрим лишь один короткий пример с официальной страницы Debian Wiki, используя готовый образ Debian.[16]
Для этой эмуляции нужны следующие пакеты:
Руководство Arm64Qemu[17] на сайте Debian предлагает перед первой загрузкой подключить образ и добавить ключ SSH. Однако в некоторых случаях каталог пользователя ещё отсутствует в готовом образе и автоматически создаётся при его первой загрузке. Поэтому сначала запустим системную эмуляцию, не добавляя ключ.
После загрузки образа вы заметите, что войти в систему невозможно. Завершите эмуляцию и выполните следующие команды, чтобы добавить ключ SSH, который будет использоваться для входа:
Затем снова загрузите систему и подключитесь к ней по SSH.
После успешного входа по SSH в среду QEMU её можно использовать как собственную небольшую среду Arm и устанавливать инструменты так же, как в основной системе.
Если требуется эмулировать более старую среду Arm, например Debian Armv7-A, нужно загрузить соответствующие образы.[18]
Один из сценариев полносистемной эмуляции QEMU - эмуляция встроенного ПО маршрутизатора. Исследователь безопасности, желающий изучить встроенное ПО маршрутизатора, может динамически анализировать его службы в собственной системе, отлаживая потенциальные уязвимости. Рассмотрим пример и с нуля эмулируем встроенное ПО маршрутизатора.
В этом примере вы научитесь эмулировать встроенное ПО маршрутизатора Tenda AC6 в среде QEMU. Сначала необходимо получить встроенное ПО. Многие поставщики позволяют загрузить его версии со своего сайта; в иных случаях его приходится извлекать из самого устройства. После загрузки пакета его следует распаковать, а двоичный файл извлечь с помощью binwalk.[19]
Главный компонент, который требуется из распакованного пакета встроенного ПО, - файловая система Squashfs.
Следующий шаг - перенести эту файловую систему в эмулируемую среду Armv7-A. В данном случае важна именно эмуляция Armv7, поскольку встроенное ПО собрано для процессора Armv7.
В каталоге Tenda-AC6, содержащем файловую систему Squashfs, создайте сценарий запуска эмуляции. В большинстве случаев, например для большей части встроенного ПО DLINK, этот процесс прост и работает со следующим сценарием:
Эмуляция встроенного ПО маршрутизатора может оказаться столь же простой, как запуск предыдущего сценария. Однако исключения бывают всегда. Если выполнить его для Tenda AC6, процесс будет постоянно аварийно завершаться, даже не начав загрузку. Я решил эту проблему довольно неаккуратно: выполнил обратную разработку встроенного ПО и проследил, на отсутствие каких параметров оно жаловалось. Затем написал следующую программу,[20] которая просто выдаёт ему желаемое, и это сработало.
К моему удивлению, при эмуляции другой версии встроенного ПО Tenda, AC15, возникла та же проблема, и перехватчики, созданные для AC6, по-прежнему работали.
Например, для встроенного ПО DLINK эти перехватчики не нужны. Но если вы эмулируете встроенное ПО Tenda, которому они необходимы, вот как выполнить кросс-компиляцию:
В среде Arm перейдите в каталог, куда перенесён squashfs-root, и создайте следующий сценарий emulate.sh. Он похож на упомянутый ранее, но запускается с файлом hooks.so.
Перед запуском сценария следует знать, что эта эмуляция выдаст множество ошибок и продолжит их выдавать. Их можно игнорировать, поскольку большинство вызвано поиском несуществующей аппаратной периферии. После запуска эмуляции окно терминала можно свернуть. Нас интересуют только службы встроенного ПО, которые должны заработать через пару минут после запуска сценария.
Чтобы проверить успешность эмуляции, можно воспользоваться netstat и проследить за появлением новых процессов.
Увидев эти процессы, убедитесь, что встроенное ПО успешно эмулируется: откройте интерфейс маршрутизатора по адресу 192.168.0.1. Должен появиться интерфейс администрирования эмулируемого маршрутизатора; см. рисунок 9.1.
Рисунок 9.1. Интерфейс администрирования
Теперь можно исследовать интерфейс, подключаться к процессам и отлаживать их. Чтобы подключиться к процессу HTTPD с помощью GDB, используйте следующую команду:
[3] [назад] microcontrollershop.com
[6] [назад] developer.qualcomm.com
[10] [назад] ubuntu.com
[11] [назад] freebsdfoundation.org
[12] [назад] pine64.org
[13] [назад] opensource.rock-chips.com
[16] [назад] cdimage.debian.org
[17] [назад] wiki.debian.org
[18] [назад] people.debian.org
[19] [назад] github.com
[20] [назад] github.com
В части I "Внутреннее устройство ассемблера Arm" вы познакомились с наиболее распространёнными инструкциями, встречающимися в дизассемблированном коде. Теперь пора применить эти знания и научиться анализировать поток выполнения двоичного файла. Примеры в этой главе просты и понятны, а подробный разбор поможет связать воедино уже изученные фрагменты.
Но что такое статический анализ? В зависимости от собеседника этот термин имеет разное значение. Однако с одной характеристикой согласны все: это анализ файла в статической форме, без выполнения. В этой главе под статическим анализом понимается низкоуровневый анализ двоичного файла.
Статический анализ предшествует динамическому. Чтобы исследовать программу во время выполнения, сначала требуется понять её основные свойства. В частности, нужно знать, какие среда и ресурсы необходимы программе для запуска. Поверхностный статический анализ позволяет подготовить правильную среду и инструменты с учётом типа файла и понять его структуру по формату.
Нередко сведений об основных свойствах файла недостаточно для перехода к динамическому анализу. В таких случаях следует определить места кода, где нужно наблюдать за взаимодействием программы с системой, чтобы глубже понять её возможности. Например, если вредоносный двоичный файл выполняет сетевые операции, расшифровывает данные или изменяет файлы в файловой системе, необходимо знать, где искать и за какими потоками данных следить во время выполнения.
Для этого требуется анализировать дизассемблированный код программы и понимать поток её выполнения. Такой анализ не только раскрывает назначение функций, но и может выявить возможности, активируемые лишь при определённых условиях.
При анализе уязвимостей умение проводить низкоуровневый анализ является базовым навыком. Анализ дизассемблированного кода уязвимой функции помогает понять, при каких условиях она вызывается и какой именно поток данных нужен, чтобы воспользоваться уязвимостью, не вызвав аварийного завершения программы.
В этом разделе приведён краткий обзор инструментов статического анализа для обратной разработки. В зависимости от задачи и операционной системы может быть удобна комбинация средств командной строки и графического интерфейса. Командные инструменты полезны для поверхностного статического анализа, общего сбора сведений о двоичном файле и быстрого анализа небольших файлов. Графические дизассемблеры и декомпиляторы - мощные средства, которые можно расширять дополнениями и собственными сценариями.
Инструменты командной строки могут быть полезной частью процесса обратной разработки, особенно на начальном этапе сбора сведений. В Linux полезны команда strings, перечисляющая строки внутри файла в порядке их появления, команда file, показывающая тип файла, и readelf, выводящая полезные сведения о файлах формата ELF.
Для дизассемблирования файла в Linux также достаточно одной команды. Параметр -d программы objdump выводит дизассемблированный код каждой функции в разделах исполняемого кода. Однако командные инструменты подходят не только для поверхностного статического анализа. Программу можно отлаживать из командной строки с помощью GDB или ещё более мощных средств, например Radare2.
Дизассемблеры используются для просмотра низкоуровневого кода программы и различаются возможностями и ценой: от бесплатных инструментов с открытым исходным кодом Radare2 и Ghidra до коммерческих Binary Ninja и IDA Pro. Некоторые из них умеют декомпилировать код, пытаясь восстановить высокоуровневый исходный текст дизассемблированной программы.
Ниже перечислены распространённые дизассемблеры и декомпиляторы:
• IDA Pro[1] - мощный дизассемблер и отладчик и самый дорогой вариант на рынке. Он поддерживает множество архитектур процессоров, графическое представление с обзором блоков кода и их потока управления, а также сценарии для собственных дополнений. Hex-Rays - декомпилятор C и C++, приобретаемый как дополнение к IDA Pro.
• Binary Ninja[2] - интерактивный дизассемблер, декомпилятор и платформа анализа двоичных файлов, значительно более доступная по цене, чем IDA Pro. Среди её многочисленных возможностей - дизассемблирование, декомпиляция, автоматизация посредством мощных API, представления промежуточных языков и даже облачный дизассемблер.[3] Декомпилятор имеет необычную структуру. Он использует древовидную архитектуру и промежуточное представление машинного кода Binary Ninja Intermediate Language (BNIL)[4] и показывает дизассемблированный код на трёх уровнях абстракции: Low Level IL, Medium Level IL и High Level IL. Это особенно полезно тем, кто хочет сохранить при анализе часть подробностей, предоставляемых ассемблером.
• Ghidra - набор инструментов обратной разработки с открытым исходным кодом, созданный исследовательским управлением NSA.[5] Он позволяет дизассемблировать, собирать, декомпилировать и отлаживать код, а также писать сценарии.
• Radare2[6] - мощный дизассемблер и отладчик командной строки с открытым исходным кодом и множеством возможностей для анализа двоичных файлов и обратной разработки.
Binary Ninja - мощный инструмент обратной разработки и один из моих любимых. Он обладает необычными возможностями, в том числе облачной версией, которую стоит выделить. Binary Ninja Cloud незаменим, если обычный дизассемблер недоступен или требуется удобно исследовать двоичный файл прямо в браузере. Кратко рассмотрим его возможности.
После загрузки двоичного файла появляется список функций и графическое представление дизассемблированного кода. На рисунке 10.1 показана функция main.
Рисунок 10.1. Представление функции main в Binary Ninja
Можно также включить отображение адресов, байтов кодов операций и типов переменных, как показано на рисунке 10.2.
Рисунок 10.2. Параметры отображения Binary Ninja
В Binary Ninja также предусмотрено отображение строк двоичного файла, как показано на рисунке 10.3.
Рисунок 10.3. Отображение строк
На рисунке 10.4 показана функция Triage, предоставляющая сведения о файле: заголовки, импортируемые и экспортируемые символы, сегменты и разделы двоичного файла.
Стоит выделить некоторые необычные возможности декомпиляции Binary Ninja. Как говорилось ранее, дизассемблированный код можно показывать на разных уровнях абстракции: Low Level IL, Medium Level IL и High Level IL.
Другие дизассемблеры способны отображать лишь необработанный дизассемблированный код программы и, если в них есть декомпилятор, высокоуровневый псевдокод. Однако в зависимости от анализа иногда нужны определённые подробности, но не настолько подробные, чтобы читать каждую инструкцию в исходной дизассемблированной форме. Если требуется видеть пошаговое изменение конкретных регистров и областей памяти, не разбирая каждую приводящую к нему инструкцию, может пригодиться представление Low Level IL. Если такая детализация не нужна и достаточно увидеть результат для определённых регистров перед их использованием в вызове функции, подойдёт Medium IL. Высокоуровневую перспективу псевдокода даёт High Level IL.
Рассмотрим функцию main в Low Level IL. На рисунке 10.5 видно, как изменился уровень абстракции. Детализация ассемблерного кода сохранилась. Каждая строка показывает изменение регистров в более удобочитаемом виде, без мнемоники инструкции. Сначала представление может показаться запутанным, но обратите внимание: каждая строка точно описывает изменение содержимого регистра и памяти. Например, строка 1 показывает, что SP уменьшается на 0x20. Строка 2 указывает, что значение регистра x29 сохраняется в стеке по адресу SP плюс смещение с меткой __saved_x29, и так далее.
Рисунок 10.4. Функция Triage
Рисунок 10.5. Low Level IL
Так ассемблерный код становится гораздо удобнее для чтения. Но что, если не требуется пошагово видеть изменение каждого регистра? Представление Medium Level IL на рисунке 10.6 показывает более упрощённую версию кода.
Рисунок 10.6. Medium Level IL
Обратите внимание, что код сокращён до важнейших составляющих. Подробности вроде мест хранения значений переменных в стеке не показаны, но они не всегда важны для анализа. В этом представлении видны значения переменных a и b, а главное - в регистры аргументов X0 и X1 записываются адреса a и b.
Если поднять IL ещё на один уровень, до High Level IL, получится декомпилированная версия исходного кода, как показано на рисунке 10.7.
Рисунок 10.7. High Level IL
Условный поток программы также можно упростить до более удобочитаемой формы. На рисунке 10.8 показана ассемблерная версия условного потока. В представлении Medium IL тот же код сокращается до основной логики и становится гораздо понятнее, как видно на рисунке 10.9.
Несмотря на то что такие инструменты, как Binary Ninja, упрощают анализ, не следует забывать: понимание подробностей ассемблерных инструкций по-прежнему остаётся основным навыком любого специалиста по обратной разработке. Поэтому следующие разделы посвящены обратной разработке конструкций потока управления и функций на уровне ассемблера.
Теперь мы рассмотрим каждую инструкцию, глубже разберёмся в работе указателей, научимся анализировать условный поток программы и попрактикуемся в чтении ассемблера, исследуя алгоритм с нуля. Дизассемблированный код на рисунках этого раздела получен в IDA Pro.
Рисунок 10.8. Графическое представление условного потока
Рисунок 10.9. Графическое представление Medium IL
При изучении программирования на C указатели могут казаться пугающей темой. Независимо от опыта в C, взгляд на операции с указателями на уровне ассемблера помогает углубить их понимание.
Начнём с примера, часто встречающегося при обратной разработке: передачи по ссылке. При этом способе значение передаётся функции по ссылке, то есть передаётся его адрес, а функция разыменовывает скопированные адреса и получает доступ к исходным объектам. Иными словами, вместо самих значений функции передаются их адреса.
Когда переменные объявляются в функции main, а их значения передаются другой функции, эта функция получает в аргументах лишь копии значений и не может изменить исходные переменные.
Вывод:
При передаче по ссылке аргументами функции становятся адреса объектов (&a, &b). Функция объявляет эти аргументы как указатели на int (int *pa, int *pb) и разыменовывает скопированные адреса, получая доступ к исходным объектам.
Иными словами, когда функции передаётся адрес переменной, операции внутри функции выполняются над значениями, хранящимися по адресу исходной переменной.
Вывод:
Примечание. В C оператор ссылки & означает "адрес", а оператор разыменования * - "значение, на которое указывает указатель".
Начнём с функции main. Сначала переменные a и b инициализируются значениями 21 и 17 соответственно. На ассемблере для этого регистр W0 инициализируется значением переменной, после чего значение сохраняется в выделенной области стека. В IDA смещение этой области снабжено отдельной меткой для каждой переменной. На рисунке 10.10 эти метки переименованы для удобства чтения.
Рисунок 10.10. Инициализация переменных a и b
Функция swap принимает адреса переменных a и b как аргументы. Следовательно, в регистры аргументов X0 и X1 требуется записать адреса a и b, а не хранящиеся по ним значения. На рисунке 10.11 видно, что инструкции ADD записывают в X0 и X1 адреса областей стека этих переменных.
Рисунок 10.11. Подготовка аргументов функции swap
Параметры функции swap объявлены как указатели на int. Поскольку аргументами были переданы адреса a и b, теперь pa и pb содержат копии этих адресов и ссылаются на те же объекты.
Иными словами, pa и pb содержат адреса и потому указывают на содержимое переменных a и b. Это содержимое можно получить, разыменовав (*) указатели pa и pb.
На рисунке 10.12 видно, что адреса, переданные в регистрах аргументов X0 и X1, сохраняются в выделенных для них областях стека. Область [SP,#0x20+pa] теперь содержит адрес значения переменной a, а [SP,#0x20+pb] - адрес значения переменной b.
Рисунок 10.12. Вызов функции swap, сохранение аргументов в выделенных областях стека и инициализация переменной t
Первая строка функции swap инициализирует переменную t значением, на которое указывает pa. На ассемблере первая инструкция LDR загружает в регистр X0 адрес, хранящийся в [SP,#0x20+pa].
Вторая инструкция LDR загружает в W0 содержимое по этому адресу.
Чтобы инициализировать этим значением переменную t, инструкция STR сохраняет ранее загруженное значение в выделенной для переменной области стека. На рисунке 10.13 схематично показаны области стека переменных и их содержимое.
Рисунок 10.13. Области стека переменных
Вторая строка функции swap изменяет значение, на которое указывает pa, присваивая ему значение, на которое указывает pb. Помните: мы разыменовываем указатели, чтобы получить доступ к значениям, на которые они указывают, и изменить их, а не сами адреса. Поэтому pa и pb по-прежнему содержат те же адреса, но значение, на которое указывает pa, изменилось.
На рисунке 10.14 видно, что программа разыменовывает указатели в два этапа. Поскольку адрес значения хранится в [SP,#0x20+pb], программа сначала загружает этот адрес в X0, а затем использует регистр как исходный адрес для загрузки значения в W1. Регистр назначения W1 выбран потому, что значение хранится в первых 32 битах области стека. После первых двух инструкций X0 и X1 содержат:
Рисунок 10.14. Разыменование указателей и присваивание значения *pb значению *pa
Чтобы изменить значение, на которое указывает pa, программа сначала загружает адрес из [SP,#0x20+pa] в X0, а затем использует его как адрес назначения для сохранения значения W1. После последних двух инструкций X0 и X1 содержат:
На рисунке 10.15 показано, как изменилось содержимое областей памяти этих переменных. Обратите внимание: в pa и pb по-прежнему находятся те же адреса, однако содержимое переменной a изменилось, и потому адрес из pa теперь указывает на другое значение.
Рисунок 10.15. Адреса памяти переменных a и b теперь содержат одинаковое значение
Последняя строка функции swap присваивает значению, на которое указывает pb, значение переменной t, равное 21.
На рисунке 10.16 видно, что первая инструкция LDR загружает содержимое pb в X0. Теперь X0 содержит адрес, указывающий на содержимое переменной b.
Рисунок 10.16. Присваивание значения t значению, на которое указывает pb
Вторая инструкция LDR загружает первые 32 бита из области стека переменной t в W1, после чего STR сохраняет W1 по адресу из X0. После этих трёх инструкций X0 и X1 содержат:
На рисунке 10.17 показано изменение содержимого областей переменных.
Рисунок 10.17. Изменения содержимого областей переменных
В конце программа возвращается в функцию main и получает команду вывести переменные a и b. На рисунке 10.18 видно, что в первый регистр аргумента X0 записывается адрес строки формата, а два других регистра аргументов заполняются содержимым областей стека переменных a и b.
Рисунок 10.18. Подготовка аргументов вызова printf
Поскольку функции swap были переданы копии адресов переменных, а не их значения, перестановка выполнялась над исходными значениями. После вызова printf на экран выводится:
Если бы a и b были переданы как обычные целочисленные значения функции swap, работающей с целыми числами, в контексте функции main они не изменились бы.
Чтобы показать, как анализировать и понимать конструкции потока управления в дизассемблированном коде, выполним обратную разработку небольшой программы с циклом while, операторами if и else и циклом for. Исследуемая программа[7] реализует алгоритм преобразования десятичного числа в шестнадцатеричное представление.
Для статического анализа в этом примере используется дизассемблированный вывод IDA Pro. Как показано на рисунке 10.19, функция main печатает строку Enter decimal number: и получает пользовательский ввод через scanf со спецификатором long int (%ld). Затем ввод передаётся функции decimal2Hexadecimal.
Рисунок 10.19. Дизассемблированный вывод функции main
До вызова printf инструкция ADRL записывает в X0 адрес первой строки с меткой aEnterDecimalNu и передаёт его функции printf как аргумент.
Для scanf программа подготавливает два аргумента: адрес строки %ld в X0 и область памяти, куда следует сохранить ввод. Для этого инструкция ADD записывает в X0 адрес SP плюс смещение (#0x20+var_8) к выбранной области хранения. Поскольку это должен быть второй аргумент, MOV копирует X0 в X1, прежде чем ADRL запишет в X0 адрес строки %ld.
После вызова scanf инструкция LDR загружает из стека значение пользовательского ввода в X0, и оно передаётся как аргумент вызову decimal2Hexadecimal.
В начале функции decimal2Hexadecimal видно, что IDA назначила различным смещениям метки. Эти смещения используются для определения положения переменных функции относительно указателя стека SP.
На рисунке 10.20 видно, что я уже переименовал стандартные метки в соответствии с именами переменных функции. Переименование переменных выполняется по ходу анализа, когда шаг за шагом выясняется их назначение. Для удобства чтения далее используется версия с новыми именами.
Рисунок 10.20. Переименование локальных переменных в IDA Pro
Вычислив расстояния между этими значениями, можно представить вид стека и положение каждой переменной. На рисунке 10.21 показана компоновка стека с положениями и размерами переменных.
Рисунок 10.21. Компоновка стека
Начнём анализ функции decimal2Hexadecimal. Как видно на рисунке 10.22, первая инструкция STR сохраняет переданный вызывающей функцией main аргумент в выделенной области стека. Можно уверенно предположить, что это преобразуемое десятичное число (num). Вторая STR сохраняет то же значение в области стека decimalnum, поскольку обе переменные инициализируются одинаковым значением. Затем регистр WZR сохраняет 4 нулевых байта в позиции j. Переменная i будет задана позднее. Наконец, значение decimalnum сначала загружается в X0, а затем сохраняется в позиции quotient, поскольку quotient = decimalnum.
Рисунок 10.22. Начало функции decimal2Hexadecimal
Переход к следующему блоку инструкций (while) безусловный. Как показано на рисунке 10.23, этот блок загружает quotient в X0 и сравнивает его с #0. Переход к блоку if_statement выполняется при условии NE (Not Equal, не равно). Для примера допустим, что преобразуемое десятичное число равно 32. К этому моменту num, decimalnum и quotient равны 32. Следовательно, частное не равно нулю, и выполняется переход к if_statement.
Блок if_statement вычисляет остаток от деления частного на 16. Разберём инструкции по очереди. На рисунке 10.24 показана каждая инструкция и соответствующее используемое или изменяемое значение регистра. Первая LDR загружает текущее частное в X0. Хотя предыдущая инструкция загрузки уже поместила частное в X0, программы часто загружают его повторно на случай, если X0 был изменён до достижения этого блока. Инструкция NEGS меняет знак значения X0, записывает результат в X1 и при необходимости устанавливает флаг Negative. Она эквивалентна SUBS X1, XZR, X0.
Рисунок 10.23. Расчёт остатка на основе загруженного частного
Рисунок 10.24. Инструкции и значения регистров
Две инструкции AND записывают в X0 и X1 результаты соответствующих операций. В нашем примере обе дают 0x0.
Инструкция CSNEG (Conditional Select Negation, условный выбор с отрицанием) проверяет истинность заданного условия MI, то есть установлен ли флаг Negative. Если условие истинно, в регистр назначения X0 записывается значение первого исходного регистра X0. Если оно ложно, в X0 записывается значение второго исходного регистра X1 с изменённым знаком.
Результат становится новым остатком. В нашем примере он равен 0, поскольку 32 % 16 = 0. Инструкция STR сохраняет новый остаток в его позиции стека, после чего значение снова загружается в X0. Наконец, CMP сравнивает X0 с 9. Условный переход проверяет, установил ли результат CMP флаги, требуемые условием GT, что фактически означает знаковое >. Если условие истинно, выполняется переход к блоку else.
Примечание. Выражение if (remainder < 10) эквивалентно if !(remainder > 9), и даже если в исходном коде использована первая форма, компилятор может выбрать альтернативную, например вторую.
Возможно, вы задаётесь вопросом, почему я назвал этот блок if_statement, хотя большинство его инструкций задают remainder результатом quotient % 16. Переименование блока зависит от того, какую логику требуется выделить и вспомнить при последующем анализе. В данном случае именно из этого блока программа либо переходит к логике else, либо продолжает следующей инструкцией логики внутри if, что показывает условный переход B.GT else. В графическом представлении IDA Pro эти участки разделены на два блока инструкций, как видно на рисунке 10.25. Однако метка есть только у блока else. Дело в том, что инструкция сразу после условного перехода является первой инструкцией левого блока: если условие не выполняется, программа просто пропускает переход и продолжает последовательное выполнение.
В нашем примере текущее значение остатка равно 0. CMP внутренне вычисляет 0 - 9 = -9 и устанавливает только флаг N (Negative). Поэтому условие GT ложно, и переход к блоку else пропускается. Иными словами, 0 не больше 9, и выполнение продолжается со следующей инструкции.
Рисунок 10.25. Условный переход на основе оператора if-else
Прежде чем переходить к блокам if и else, сделаем шаг назад и повторим, что здесь происходит. Почему алгоритм прибавляет к остатку 48, если остаток меньше 10, и 55, если больше? Чтобы понять причину, нужно помнить две вещи: мы заполняем массив char, и ожидаемый вывод - последовательность символов.
Предположим, требуется преобразовать десятичное значение 171 в шестнадцатеричное. Расчёт:
Берём остатки, начиная с последнего, и преобразуем в шестнадцатеричные цифры.
Для нас это очевидно, но для компьютера не столь очевидно. Всё зависит от формата вывода, в данном случае последовательности символов из массива char. Если массив содержит значения 10 (0xA) и 11 (0xB) и получает команду вывести соответствующие символы, результатом будут новая строка и вертикальная табуляция. Согласно таблице ASCII эти значения представляют символы \n и \v, как показано в таблице 10.1.
Таблица 10.1. ASCII
Как этого избежать? Из таблицы ASCII видно: чтобы вывести символы A и B, массив должен содержать представляющие их значения. Поэтому к обоим остаткам необходимо прибавить 55 (0x37), получив 65 (0x41) для 10 и 66 (0x42) для 11, как показано в таблице 10.2.
Таблица 10.2. ASCII
Это объясняет прибавление к остатку 55, но зачем прибавлять 48, если остаток меньше 10? Ответ прост, когда его видишь.
Предположим, требуется преобразовать десятичное значение 32 в шестнадцатеричное. Берём остатки, начиная с последнего, и преобразуем в шестнадцатеричные цифры.
Из таблицы ASCII видно, что расстояние между символами цифр и их десятичными и шестнадцатеричными эквивалентами равно 48, а не 55. См. таблицу 10.3.
Таблица 10.3. ASCII
Однако при остатке больше 9 получились бы специальные символы вроде < или = (см. таблицу 10.4). Например, если остаток равен 10 и прибавить 48, получится 58 в десятичной системе и 0x3A в шестнадцатеричной, что соответствует двоеточию. Поэтому такие символы пропускаются: если остаток больше 9, к нему прибавляется 55 (0x37), а не 48 (0x30). Мы всегда остаёмся в диапазонах 0-9 и A-F, поскольку остаток рассчитывается делением частного по модулю 16 (remainder = quotient % 16).
Таблица 10.4. ASCII
Переходя к логике кода внутри if, рассмотрите рисунок 10.26.
Рисунок 10.26. Оператор if
На этом этапе расчёта текущий остаток равен 0 (remainder = 32 % 16), а стек выглядит как на рисунке 10.27.
Рисунок 10.27. Стек
На рисунке 10.28 видно, что первая инструкция загружает остаток в X0, после чего AND присваивает W1 результат remainder & 255, гарантируя, что значение останется в пределах одного байта. Следующие три инструкции загружают из стека текущее значение j, равное 0, увеличивают его на единицу и сохраняют результат для следующей итерации.
Затем ADD прибавляет 0x30 (48) к значению остатка в W1. Операция AND берёт новое значение остатка из W1, применяет AND 0xFF (255), чтобы удержать его в однобайтовом диапазоне, и записывает результат в W2. Инструкция SXTW знаково расширяет первые 32 бита W0 до 64 бит X0, чтобы гарантировать нулевую вторую половину 64-разрядного X0, поскольку ранее изменялись лишь 32 бита W0.
Рисунок 10.28. Оператор if в дизассемблированном коде
Пора сохранить первый результат в массиве. Как показано на рисунке 10.29, ADD записывает в X1 адрес массива hexadecimalnum. Инструкция STRB сохраняет значение W2 по адресу X1, то есть базовому адресу массива в стеке, плюс X0, то есть смещение j. Обратите внимание: хотя значение j увеличено на 1 и обновлено в стеке, значение сохраняется в элементе j = 0.
Рисунок 10.29. Сохранение первого результата в массиве
Рисунок 10.29. Сохранение первого результата в массиве
Далее код достигает строки, задающей новое частное делением текущего частного на 16 (рисунок 10.30). В нашем примере текущее частное всё ещё равно 32.
Рисунок 10.30. Деление частного
Подготавливая это деление, ADD прибавляет 15 к значению частного в X0 и записывает результат в X1, как показано на рисунке 10.31. CMP сравнивает частное с #0 и устанавливает флаги условий для инструкции CSEL.
Рисунок 10.31. Деление частного: разбор дизассемблированного кода
Инструкция CSEL (Conditional Select) проверяет истинность условия LT. Если оно истинно, значение первого исходного регистра X1 записывается в регистр назначения X0. Если условие ложно, то есть частное не отрицательно, в X0 записывается значение второго исходного регистра X0. В нашем случае предыдущая CMP не установила флаг Negative, поэтому условие ложно и значение X0 остаётся неизменным.
Инструкция ASR применяет к значению X0, то есть частному, арифметический сдвиг вправо на 4, что фактически делит значение на 16. STR сохраняет новое частное в его области стека.
После деления частного выполнение возвращается к блоку, проверяющему условие цикла while, как показано на рисунке 10.32. Поскольку текущее частное равно 0x2, расчёт остатка повторяется и программа достигает if, который прибавляет к остатку 48, а затем снова выполняет рассмотренное деление частного. В нашем примере блок else не достигается, поскольку остаток всегда меньше 10.
Рисунок 10.32. Проверка условия цикла while
После второй итерации новое частное равно 0x0, а остаток - 0x2. Поэтому программа выходит из цикла while и переходит к for. Текущая компоновка стека показана на рисунке 10.33. Массив hexadecimalnum заполнен значениями 0x00, 0x30 и 0x32, а j равна 0x2.
Рисунок 10.33. Текущая компоновка стека
Цикл for присваивает i текущее значение j и проверяет, больше или равно ли i нулю, как показано на рисунке 10.34.
Рисунок 10.34. Цикл for
Присвоение переменной i значения j сводится к сохранению одного значения в области стека другой переменной. LDR загружает j в W0, а STR сохраняет его в позиции i, находящейся на 4 байта ниже позиции j; затем следует безусловный переход к следующему блоку.
Именно там проверяется условие for. Текущее значение i снова загружается в W0, после чего CMP сравнивает W0 с #0 и соответственно устанавливает флаги. Если они указывают, что i больше или равно (GE) #0, выполняется переход к блоку loc_8FC.
В нашем примере i = 2, поэтому условие GE (N == V) истинно и переход выполняется.
Достигается блок, отвечающий за вывод символа массива hexadecimalnum в позиции i и уменьшение i, как показано на рисунке 10.35.
Рисунок 10.35. Вывод символа массива hexadecimalnum
Разберём инструкции по очереди. На рисунке 10.36 видно, что первая инструкция LDRSW загружает знаковое слово, то есть 32 бита, в X0.
Рисунок 10.36. Разбор дизассемблированного кода
Это текущее значение i (0x2), используемое как смещение в массиве. ADD записывает в X1 адрес массива hexadecimalnum, служащий базовым адресом. Функция putchar ожидает символ в аргументе X0/W0. Поэтому LDRB загружает один байт из базового адреса X1 со смещением i из X0 в W0. Если порядок элементов в стеке вызывает вопросы, рассмотрите рисунок 10.37. Базовый адрес указывает на первый элемент массива со значением 0x30. Поскольку текущее i равно 2, LDRB извлекает hexadecimalnum[2] = 0x00.
Рисунок 10.37. Порядок элементов
После вызова putchar значение i нужно уменьшить. LDR загружает его в W0, SUB вычитает 1, а затем новое значение сохраняется обратно в его позицию стека.
Цикл продолжается, пока i не станет меньше 0 и условие GE инструкции перехода не перестанет выполняться. Тогда программа достигает строки printf("\n"), показанной на рисунке 10.38. Здесь MOV задаёт первым аргументом putchar шестнадцатеричный эквивалент символа новой строки (\n), после чего следует переход к putchar.
Рисунок 10.38. Вывод строки
В предыдущих разделах мы увидели работу указателей на уровне ассемблера, проанализировали поток управления программы и сопоставили фрагменты исходного и дизассемблированного кода. В этом разделе рассматривается неизвестный алгоритм без доступа к исходному коду или декомпилированному псевдокоду. Цель - попрактиковаться в анализе условного потока дизассемблированного кода и разборе смысла каждой инструкции.
Перед началом анализа ниже для справки приведён полученный из objdump дизассемблированный код функций main и algoFunc:
Прежде чем углубляться в алгоритм algoFunc, важно определить аргументы, передаваемые этой функции вызывающей стороной, то есть main.
На рисунке 10.39 видны функция main и три локальные переменные, на которые имеются ссылки в кадре стека. Они обозначены var_x, где x - шестнадцатеричное смещение области в кадре стека.
Рисунок 10.39. Дизассемблированное представление функции main
Первый вызов функции - printf, печатающий строку Pick a number. Области этой строки назначена метка aPickANumber; ADRL загружает её в X0 как аргумент вызова printf.
Вызов scanf принимает два аргумента, подготавливаемых в X0 и X1. После выполнения трёх инструкций, следующих за printf, первый аргумент X0 указывает на спецификатор формата %d, а второй X1 содержит адрес стека, куда будет сохранён пользовательский ввод.
После scanf программа загружает пользовательский ввод из выделенной области [SP,#0x20+var_8] в W0. Функция algoFunc принимает только один аргумент - пользовательский ввод в W0.
Когда algoFunc возвращается, один байт возвращённого значения сохраняется в стеке и сравнивается с 0. Если значение равно 0, программа переходит к блоку, который печатает строку о том, что число не соответствует условиям; это правый блок на рисунке 10.40. Если значение равно 1, программа переходит к блоку, выводящему The answer is Yes!.
Рисунок 10.40. Условный переход по возвращённому значению algoFunc
Нужно восстановить алгоритм функции algoFunc и выяснить, какие числа она ожидает, чтобы вывести строку о правильном ответе. Граф потока управления algoFunc показан на рисунке 10.41.
Рисунок 10.41. Граф потока управления algoFunc
Рисунок 10.41. Граф потока управления функции algoFunc
Начнём разбирать его логику. На рисунке 10.42 видно, что IDA назначила метки четырём локальным переменным, используемым функцией. Первая, var_30, - область, где инструкция STP сохраняет исходные значения X29 и X30 в стеке. Область пользовательского ввода, переданного функции через W0, обозначена var_14.
Рисунок 10.42. Метки локальных переменных, назначенные IDA Pro
На этом этапе сведений недостаточно, чтобы понять назначение var_10 и var_4. После сохранения ввода в стеке CMP сравнивает его с числом 2, затем при неравенстве NE выполняется переход к loc_884. Если ввод равен 2, W0 устанавливается в 1, а программа переходит к loc_910, который возвращается в main и передаёт возвращаемое значение через W0.
Итак, известны следующие сведения:
• var_14 соответствует пользовательскому вводу.
• В var_30 внутри кадра стека сохраняются X29 и X30.
• Подпрограмма возвращает 1, если ввод равен 2.
Первый фрагмент псевдокода:
После сохранения ввода CMP сравнивает его с 2, а B.NE при условии NE переходит к loc_884. Иными словами, если W0 не равен 2, программа переходит к правому блоку.
Для упрощения вычислений выберем произвольное число 14. Программа переходит к loc_884, поскольку 14 и 2 не равны.
Здесь ввод загружается в W0 и сравнивается с 1. Если W0 меньше или равен (LE) 1, программа переходит к loc_8A0. Как видно на рисунке 10.43, это нежелательный блок: он устанавливает W0 в 0 и переходит к loc_910, который возвращается в main. Напомним, если algoFunc возвращает 0, ввод неверен.
В нашем случае 14 не меньше и не равно 1, поэтому выполнение продолжается инструкцией LDR после перехода. Перед следующим переходом к вводу применяется операция AND 1, и результат сравнивается с 0.
Рисунок 10.43. loc_8A0
Для числа 14 результат AND равен 0. Поэтому B.NE не выполняется, и программа достигает loc_910, возвращающего в main значение 0. Теперь известно, что 14 не соответствует критериям алгоритма. Кроме того, нам уже известно:
• Число 2 является правильным.
• Число должно быть больше 1.
• Операция x & 1 не должна возвращать 0.
Чтобы не возвращать в main значение 0, будем отслеживать ведущую к нему логику. Полученные сведения можно выразить псевдокодом:
Или альтернативно:
Известно, что 2 - одно из правильных чисел. Каким ещё условиям должно соответствовать число, чтобы функция вернула 1?
Начнём с конца algoFunc и проследим, как получается 1. На рисунке 10.44 видно: чтобы достичь блока, устанавливающего 1, нужно перейти к loc_8A8, откуда выполняется переход к loc_8F8. Затем условие B.GE должно оказаться ложным, и правая стрелка должна привести к MOV, задающей возвращаемое значение 1. Пока непонятно, как туда попасть, поэтому пойдём по шагам.
Рисунок 10.44. Переход к блоку loc_8A8
Помните операцию AND 1, которую не прошло число 14? Выберем другое число и продолжим вычисление. Число 13 удовлетворяет уже найденным критериям, поскольку 13 & 1 = 1. Мы попадаем в loc_8A8 и встречаем незнакомую инструкцию SCVTF.
В книге рассмотрены наиболее распространённые инструкции, но незнакомые всё равно будут встречаться. В таких случаях полезно иметь под рукой руководство Arm. В нём можно найти два варианта SCVTF[8], показанные на рисунке 10.45.
Рисунок 10.45. Инструкция SCVTF
Определить нужный вариант помогает синтаксис. В данном случае регистр назначения - D0, исходный - W0, а непосредственного значения нет. Значит, подходит SCVTF (скалярная, целочисленная), её 32-разрядный вариант с двойной точностью. В описании сказано:[9]
SCVTF (скалярная, целочисленная). Преобразование знакового целого числа в число с плавающей точкой (скалярное). Инструкция преобразует знаковое целое значение из исходного регистра общего назначения в значение с плавающей точкой, используя режим округления из FPCR, и записывает результат в регистр назначения SIMD&FP.
Существует 32 регистра с плавающей точкой, пронумерованных от 0 до 31. Их можно обозначать Q0, D0, S0 или H0. В нашем случае D0 представляет 64-разрядные типы C double и long double. Хотя это кажется сложным, для понимания происходящего все подробности не нужны. Достаточно знать, что SCVTF преобразует знаковое целое из W0 в 64-разрядное значение double. Это логично, поскольку следующая инструкция вызывает sqrt, вычисляющую квадратный корень ввода и возвращающую результат с плавающей точкой. Блок можно переименовать в compute_sqrt, а var_10 - в sqrtX, поскольку именно там сохраняется результат.
Результат sqrt(13) равен приблизительно 3,60 и сохраняется в стеке. На рисунке 10.46 видно, что MOV записывает в W0 число 3, не связанное с этим результатом, и сохраняет его в стеке. Затем выполняется безусловный переход к loc_8F8.
Рисунок 10.46. Блок вычисления sqrt
Программа достигает ещё одной SCVTF, преобразующей 3 в форму с плавающей точкой. LDR загружает предыдущий результат sqrt в D1, после чего FCMPE[10] сравнивает значения с плавающей точкой в D0 и D1. Если результат квадратного корня больше или равен (GE) 3, выполняется переход к следующему блоку. Итого:
• Сохранить в стеке результат sqrt(13).
• Сохранить в стеке целое число 3.
• Преобразовать 3 в число с плавающей точкой.
• Сравнить версии результата sqrt и числа 3 с плавающей точкой.
• Если результат больше или равен, перейти к loc_8C4.
Попробуем понять, зачем результат сравнивается с числом 3. Для чего используется это значение? Если отдалить граф и рассмотреть блоки на рисунке 10.47, видны другие места, где читается значение из var_4.
Рисунок 10.47. Другие места обращения к значению var_4
Начнём с loc_8F8. Он завершается сравнением и переходом в зависимости от того, больше или равно ли значение sqrtX значению var_4. Если условие истинно, достигается loc_8C4, выполняющий вычисления с вводом и var_4. Если результат не равен (NE) 0, выполняется переход к loc_8EC, нижнему правому блоку. Единственное назначение loc_8EC - увеличить var_4 на 2 и немедленно вернуться к loc_8F8. Не углубляясь пока в промежуточные действия, получаем логику рисунка 10.48.
Рисунок 10.48. Логика
Может ли var_4 быть счётчиком цикла for? Это разумно: блок compute_sqrt задаёт var_4 фиксированным числом 3, которое затем обрабатывается и увеличивается, пока выполняется некоторое условие. Условие можно выразить так:
Для удобства чтения переименуем loc_8F8 в for_loop_condition, loc_8EC в increment_i, а var_4 в i. Напомним, в IDA Pro циклические переходы отмечаются толстыми синими стрелками. Здесь это крайняя правая стрелка от increment_i к for_loop_condition.
Перейдём к логике loc_8C4. Блок начинается с записи ввода в W0 и значения i в W1, как показано на рисунке 10.49.
Рисунок 10.49. Блок loc_8C4 с окружающим контекстом
SDIV делит ввод W0 на i в W1 и записывает результат в W2. Затем MUL умножает результат деления на i и помещает произведение в W1. Произведение вычитается из ввода, а результат записывается в W0. В нашем примере:
Блок loc_8C4 завершается CMP и условным переходом. Он проверяет, не равен ли результат W0 нулю, и при истинном NE переходит к increment_i. Иначе эту логику можно выразить так:
Помните, что блок работает не со значениями с плавающей точкой, иначе результат был бы другим.
Если вы знакомы с операцией остатка от деления, предыдущая логика покажется знакомой. Она эквивалентна:
Если результат равен 0, функция возвращает 0. Если он не равен 0, i увеличивается на 2, и выполнение продолжается в for_loop_condition. Этот блок сравнивает значения с плавающей точкой результата sqrt(x), равного 3,6, и нового счётчика 5 и продолжает цикл, если sqrt(x) больше или равен 5.
Поскольку 3,6 не больше и не равно 5, программа переходит к MOV, которая наконец задаёт возвращаемое значение 1. Логика этих блоков показана на рисунке 10.50.
Рисунок 10.50. Логика
Рисунок 10.50. Логика (продолжение)
Соберём полученные фрагменты в псевдокод:
Иными словами, значение проходит проверку, если оно больше 1, а его единственные делители - 1 и оно само. Звучит знакомо? Вероятно, вы уже догадались: это алгоритм проверки простого числа!
Проверим его на нескольких простых числах, а затем на составном:
[1] [назад] hex-rays.com
[2] [назад] binary.ninja
[3] [назад] cloud.binary.ninja
[5] [назад] github.com
[7] [назад] github.com
[8] [назад] C3-242, таблица C3-67, инструкции преобразования чисел с плавающей точкой и целых или чисел с фиксированной точкой.
[9] [назад] C7.2.236 SCVTF (скалярная, целочисленная).
[10] [назад] C7.2.67 FCMPE.
В предыдущих главах вы изучили основы ассемблера Arm и статического анализа дизассемблированного кода. Эти знания помогают распознавать шаблоны потока управления, отслеживать управляемый пользователем ввод и анализировать функции с конкретной целью. Теперь пора сделать следующий шаг и исследовать программу в динамическом, активно выполняющемся состоянии.
Отладчики в основном используются с одной из двух целей: исследовать образы памяти, также называемые дампами ядра, аварийно завершившейся программы или процесса либо контролируемо исследовать выполнение программы или процесса.
Отладка особенно полезна начинающим, изучающим язык ассемблера. Обучение может быть утомительным и подавляющим, особенно когда перед вами справочное руководство на 6000 страниц. По моему опыту, лучший способ выучить ассемблер - понять самые распространённые инструкции, а более экзотические изучать по мере встречи с ними. Открыв двоичный файл в дизассемблере, вы наверняка увидите незнакомые инструкции. Найти их в справочном руководстве Arm - хорошее начало, но наблюдение за ними в действии и за их поведением закрепляет знания.
Статический и динамический анализ идут рука об руку. Если просто запустить программу в отладчике, она выполнится и завершится либо аварийно завершится при срабатывании ошибки. Необходимое условие отладки - хотя бы минимальное понимание исследуемого двоичного файла. Поэтому первым шагом всегда является статический анализ. Он позволяет определить части программы для подробного исследования и соответственно установить точки останова. Достигнув такой точки, отладчик приостанавливает выполнение.
После остановки можно наблюдать текущее состояние обработки, пошагово выполнять следующие инструкции и следить, как на каждом шаге меняются значения регистров и области памяти.
Важно отметить существование разных видов динамического анализа. Например, есть автоматизированные инструменты специально для анализа вредоносного ПО. Они запускают вредоносную программу в изолированной среде, где средства мониторинга фиксируют изменения в разных частях операционной системы и формируют отчёт. В этой главе рассматривается не такой анализ. Вместо него мы познакомимся с разными отладчиками, позволяющими пошагово выполнять определённые части программы. Поскольку графические отладчики довольно понятны, основное внимание будет уделено GNU Debugger, GDB.
Глава не претендует на полное описание всех возможностей упомянутых отладчиков: это вышло бы за рамки книги. Отладчик Ghidra не рассматривается, поскольку во время написания главы он ещё разрабатывался. Более подробное введение в рассматриваемые дизассемблеры и отладчики можно найти в следующих книгах:
•
•
•
•
Сначала будет дано краткое введение в отладчики командной строки и их основные команды, а также в полезные расширения, делающие вывод понятнее. Вы также научитесь отлаживать повреждение памяти и уязвимый процесс и удалённо отлаживать программы, когда необходимая им среда не совпадает с локальной.
Самый известный отладчик командной строки - официальный GNU Debugger, или GDB.[5] Его применяют не только специалисты по обратной разработке для отладки низкоуровневых языков, но и разработчики программ для отладки кода на высокоуровневых языках C, C++ и Java. По умолчанию GDB использует интерфейс командной строки, однако расширения делают его вывод понятнее и добавляют специализированные команды.
В этом разделе основное внимание уделяется GDB и одному из его расширений - GEF. Затем следует краткое введение в платформу обратной разработки командной строки Radare2 с открытым исходным кодом.[6]
GDB предоставляет обширный набор команд, перечисляемых через справочную функцию. Чтобы получить обзор команд, используйте аргумент --help.
Команды можно перечислять и внутри сеанса отладки. Чтобы показать классы команд, введите help, а для списка команд определённого класса - help и имя класса. В таблице 11.1 приведены основные команды GDB, необходимые для начала работы.
Таблица 11.1. Основные команды GDB
Таблица 11.1. Основные команды GDB (продолжение)
Прежде чем переходить к расширениям GDB и отдельным командам, рассмотрим отладку двоичных файлов Arm на основной системе x86_64. Как уже известно, непосредственно запустить двоичный файл Arm на другом процессоре нельзя, поскольку коды операций разных архитектур различаются. Однако QEMU позволяет эмулировать среду Arm на x86_64 посредством полносистемной или непосредственной пользовательской эмуляции. В этом разделе показано, как с помощью qemu-user и gdb-multiarch запускать и отлаживать двоичный файл Arm без полносистемной эмуляции.
Для отладки Arm на x86_64 нельзя использовать обычную установку GDB. Следует установить gdb-multiarch и другие пакеты:
Компиляция C с флагом -ggdb3 добавляет отладочную информацию для GDB. Для примера соберём статически скомпонованный исполняемый файл:
Для динамически скомпонованного файла Arm компилируйте без -static. Запуск выполняется через qemu-aarch64, а библиотеки AArch64 передаются параметром -L.
Один из способов отладки - запустить двоичный файл в qemu-user и подключить GDB по TCP. Для этого qemu-aarch64 запускается с флагом -g и номером порта ожидания соединения GDB.
В другом окне терминала выполните:
Флаг --nh запрещает читать .gdbinit, а параметры -ex задают команды, которые gdb-multiarch выполнит в начале сеанса. Первая устанавливает целевую архитектуру arm64 (для 32-разрядных файлов используйте arm), затем указываются сам двоичный файл и хост с портом экземпляра qemu-aarch64. Последние два параметра -ex разделяют и показывают окна исходного кода, дизассемблированного кода, команд и регистров. В результате открывается сеанс отладки, похожий на рисунок 11.1.
Для динамически скомпонованных файлов gdb-multiarch может сообщить об отсутствующих библиотеках. В таком случае внутри сеанса укажите путь к нужным библиотекам:
Для AArch64:
Для AArch32:
Рисунок 11.1. Разделённое представление GDB multiarch
В исходном виде интерфейс GDB довольно неинформативен. Исследователям, использующим отладку для низкоуровневого анализа и поиска уязвимостей, более полное представление текущего состояния обработки упрощает отладку и делает её продуктивнее. Поэтому существуют расширения GDB с более информативным представлением и дополнительными командами. Одно из них - GDB Enhanced Features (GEF).[7] Это проект с открытым исходным кодом на GitHub и подробной документацией возможностей.[8] Он поставляется как единый сценарий GDB, не зависит от ОС и не требует сторонних зависимостей. Нужны лишь GDB версии 8.0 или новее и Python 3.6 или новее.
Обратите внимание: многие команды этого раздела не являются уникальными для GEF и доступны в обычном GDB.
Существуют и другие расширения, похожие на GEF. Самые популярные - Python Exploit Development Assistance for GDB (PEDA)[9] и Pwndbg.[10] Их интерфейсы похожи, и многие команды совпадают. Выбор зависит от задачи и личных предпочтений.
В свежей Ubuntu Arm64 нужны GCC для компиляции, Python 3 или новее, который, скорее всего, уже установлен, и GDB версии 8 или новее.
Для установки GEF используйте:
Проверим установку, скомпилировав простую программу Hello World.
Интерфейс GEF запускается автоматически, когда двоичный файл открывается в GDB.
Видно, что отсутствуют команды, требующие дополнительных пакетов. Они необязательны. Если эти команды нужны, можно установить требуемые пакеты.
В сеансе GDB-GEF можно командой disassemble быстро посмотреть функцию main, затем установить на ней точку останова и запустить программу.
На рисунке 11.2 показано представление после достижения точки останова. Сначала идут имена регистров и их значения. Стрелка от значения показывает значение, на которое оно указывает. Если регистр содержит адрес, видно значение по этому адресу, а если оно тоже является адресом - ещё одна стрелка к следующему значению.
Ниже регистров показан стек. Крайний левый адрес - адрес области стека, за которым следует значение по этому адресу. Если значение является адресом, стрелка снова показывает значение, на которое он указывает. Рядом со значениями стека видны стрелки с именами регистров: эти регистры содержат адреса стека, на которые направлены стрелки.
Под стеком находится фрагмент дизассемблированного кода. Адрес со стрелкой - текущий адрес PC. Следовательно, инструкция по этому адресу будет выполнена следующей.
В таблице 11.2 приведён небольшой список полезных команд GEF.
Таблица 11.2. Полезные команды GEF
Как и обычный GDB, GEF предоставляет понятную справку. Получить сведения о командах или классах команд можно так:
Рисунок 11.2. Представление GEF при достижении точки останова
Например, запросим дополнительные сведения о команде memory.
Чтобы получить сведения о подкоманде, добавьте её после имени команды.
Для поиска связанных команд используйте apropos и имя команды:
Одна из самых полезных возможностей, имеющаяся и в самом GDB, - исследование содержимого памяти в разных форматах. Синтаксис команды начинается с x/, после чего указываются число единиц, длина единицы и формат. Обзор синтаксиса приведён на рисунке 11.3.
Рисунок 11.3. Разбор команды исследования памяти
Предположим, требуется исследовать память по адресу 0x00fffffffff759. Первая команда ниже извлекает по этому адресу одну строку. Вторая показывает 10 слов в шестнадцатеричном виде. Третья показывает то же содержимое, но параметры единицы и формата переставлены местами, поскольку их порядок несущественен. Последняя команда показывает 10 байт в шестнадцатеричном виде.
Шестнадцатеричные значения по умолчанию показываются в порядке little-endian. На рисунке 11.4 "гигантское слово" размером 8 байт по указанному адресу начинается с 0x61, за которым следует 0x6c. Если преобразовать шестнадцатеричные значения в ASCII, получится alaireza, а не azeriala.
Рисунок 11.4. Исследование двух гигантских слов в шестнадцатеричном виде
В действительности адрес указывает на последний байт. Если рассмотреть адреса с шагом в один байт, символы идут в порядке чтения:
Как показано на рисунке 11.5, просмотр памяти по этому адресу в виде шестнадцатеричных байтов показывает символы в обычном порядке чтения. Об этом следует помнить при исследовании памяти.
Рисунок 11.5. Исследование 10 байтов в шестнадцатеричном виде
По умолчанию GEF показывает только первые восемь адресов стека с шагом 8 байт, начиная с адреса текущего SP. Иногда программа сохраняет значения за пределами этого диапазона. Чтобы следить за определённой областью, команда memory watch добавляет дополнительный раздел памяти для наблюдения.
Синтаксис:
Здесь <ADDRESS> - наблюдаемый адрес памяти, [SIZE] - размер диапазона, после которого указывается формат.
Например, для наблюдения за первыми пятью четырёхсловными значениями из области стека:
Когда при пошаговом выполнении SP изменится и будет указывать на другой блок в представлении стека, заданная область всё равно останется в контексте под дизассемблированным кодом с пометкой memory:<ваш адрес>, как показано на рисунке 11.6.
Рисунок 11.6. Команда GEF memory watch
Наблюдать можно и за другими областями, например таблицей GOT. Команда got показывает записи GOT, после чего можно установить наблюдение за первыми пятью записями с указанного смещения:
На рисунке 11.7 область GOT видна в контекстном представлении под дизассемблированным кодом.
Рисунок 11.7. Наблюдение области GOT
Ещё одна полезная возможность GEF - heap-analysis-helper,[11] отслеживающая и анализирующая выделение и освобождение блоков памяти кучи. Хотя она ещё разрабатывается, она пытается отслеживать:
• освобождение NULL;
• использование после освобождения;
• двойное освобождение;
• перекрытие кучи.
Проверим эту возможность на уязвимой программе. Установив точку останова на main и запустив программу, начнём отслеживание командой heap-analysis-helper.
Мы уже находимся в точке останова внутри main. Если продолжить без других точек останова, GEF остановится, как только обнаружит потенциальную уязвимость кучи. Следующий вывод показывает обнаруженное двойное освобождение и адрес освобождённого объекта, вызвавшего проблему.
Команда format-string-helper помогает обнаруживать потенциально небезопасные вызовы со строкой формата. Для включения просто выполните её в GEF:
После продолжения программа останавливается на вызове printf. В следующем выводе помощник обнаружил потенциальную уязвимость и показал дополнительный контекст. Для удобства представления стека и регистров опущены.
Команда checksec определяет включённые средства защиты. В следующем выводе видны активные меры и значение канарейки стека. Чтобы определить место хранения этого значения, используется canary.
Сведения о процессе, включая идентификатор, файловые дескрипторы и сетевые соединения, можно получить командой process-status.
Команда xinfo полезна, когда нужны сведения о конкретном адресе памяти. Она показывает страницу и её размер, разрешения, область памяти и смещение от начала страницы.
Шаблон в памяти можно искать командой search-pattern.
Не путайте её с командой pattern search. В некоторых сценариях требуется создать циклический шаблон, использовать его как пользовательский ввод и определить смещение части шаблона, попавшей в регистр, например PC. Для создания применяется pattern create с размером в байтах. Здесь ввод передаётся аргументом программе.
Если шаблон попал в регистр, pattern search определяет смещение значения. Например, x29 и x30 содержат шаблон, но неизвестно, сколько символов им предшествовало.
Команда pattern search с именем регистра после знака доллара и необязательным размером шаблона возвращает смещение.
Radare2[12] - открытый набор инструментов обратной разработки, включающий средства статического анализа, дизассемблер и встроенный отладчик.[13] Он предоставляет командный интерфейс со встроенным графическим представлением и доступен в Windows, Linux и macOS. Здесь даётся лишь краткое введение, а не полный обзор. Radare2 - мощная платформа с множеством возможностей и крутой кривой обучения. Дополнительные сведения приведены в официальной книге Radare2.[14]
Проект Radare2 предоставляет набор утилит командной строки, которые можно использовать отдельно. Они перечислены в таблице 11.3.
Таблица 11.3. Утилиты командной строки Radare2
Отладчик Radare2 запускается командой radare2 или сокращением r2 с параметром -d и именем двоичного файла, здесь armstrong. Адрес в скобках - текущий PC. Знак ? показывает список команд.
Первая подходящая команда - анализ a. Чем больше букв a, тем подробнее анализ; более трёх относятся к экспериментальному анализу.
Чтобы перейти в визуальный режим и получить интерактивное представление с регистрами и стеком, используйте v! (рисунок 11.8).
Рисунок 11.8. Интерактивное представление Radare2
Ввод : открывает консоль команд, где, например, v? показывает дополнительные команды визуального режима. Нажатие Enter без команды возвращает в полноразмерный визуальный режим.
Список команд отладки показывает d?.
Команда db связана с точками останова. Для дополнительных сведений:
Точка останова на main устанавливается так:
Теперь можно начинать сеанс отладки. В таблице 11.4 приведены некоторые клавиши визуального режима.
Таблица 11.4. Клавиши визуального режима Radare2
Другие полезные команды отладки:
F9 в визуальном режиме запускает отладку и останавливает программу на main, где была установлена точка останова, как показано на рисунке 11.9. Клавиши F7 и F8 пошагово выполняют программу, показывая изменение регистров и стека.
Графическое представление открывается вводом VVV. Оно удобно при статическом анализе для обзора потока управления, как показано на рисунке 11.10.
В зависимости от задачи двоичный файл бывает удобнее отлаживать удалённо, а не локально. Особенно если операционная система или архитектура основной системы отличается от целевой: например, основная система x86_64, средства анализа работают только в Windows, а целевому файлу нужна Linux на Arm.
В других случаях целевой файл следует отлаживать в родной среде из-за особых зависимостей. Например, процесс маршрутизатора можно отлаживать либо в локально эмулируемом встроенном ПО, либо удалённо внутри самого маршрутизатора.
Рисунок 11.9. Представление сеанса отладки Radare2
В этом разделе даётся обзор нескольких инструментов удалённой отладки.
Для удалённой отладки через GDB или другие отладчики на целевой машине необходимо установить сервер gdbserver.
В основной системе Linux запустите gdbserver со следующим синтаксисом:
Рисунок 11.10. Представление потока управления Radare2
На удалённой машине запустите GDB и укажите удалённый хост и IP-адрес.
Подключение к gdbserver поддерживают многие отладчики, включая Radare2 и IDA Pro. В Radare2 используется:
IDA Pro может подключаться к сеансу gdbserver на удалённом хосте. В этом примере IDA Pro работает на macOS с M1, а удалённый хост - виртуальная машина Parallels с Debian Arm Linux.
Внутри ВМ запускаем gdbserver, указывая порт и отлаживаемый файл.
В IDA выберите Remote ARM Mac OS debugger, как показано на рисунке 11.11.
Рисунок 11.11. Выбор типа отладчика в IDA Pro
Будет предложено задать параметры отладки, показанные на рисунке 11.12: путь к программе, IP-адрес удалённого хоста и порт gdbserver.
Рисунок 11.12. Параметры отладки IDA Pro
После нажатия OK откроется представление отладки IDA, показанное на рисунке 11.13.
Рисунок 11.13. Представление отладки IDA Pro
При анализе уязвимостей исследуется потенциально эксплуатируемая ошибка, которая привела к сбою и была найдена динамическими методами, например фаззингом, либо вручную при статическом анализе. Следующий шаг - определить, можно ли её эксплуатировать и при каких условиях. Статический анализ помогает найти уязвимую функцию и понять размещение компилятором переменных и их отношения. Динамический анализ позволяет подтвердить гипотезу, наблюдая состояние программы в определённых точках и движение управляемого ввода во время выполнения.
Рассмотрим повреждение памяти через strcpy, не проверяющую размер пользовательского ввода. Цель - вызвать уязвимость, получить контроль над PC и перенаправить выполнение к функции secret(), которая иначе никогда не достигается.
Программа ожидает ввод аргументом. При обычном выполнении выводится Hello from the main function. Если строка длиннее выделенного буфера, программа аварийно завершается.
Строки двоичного файла можно проверить через rabin2.
Перед отладкой быстро посмотрим дизассемблированные исполняемые функции через objdump:
Функция main вызывает func, которая принимает ввод и вызывает уязвимую strcpy. В начале main STP сохраняет x29 и x30 в стеке. Это важно: x30 содержит адрес, который RET скопирует в PC для возврата из функции. Если перезаписать сохранённый адрес, программа перейдёт по указанному нами адресу.
Перед вызовом strcpy, помещающей ввод в выделенный 80-байтовый буфер, func сохраняет в стеке свои значения возврата.
На рисунке 11.14 показаны позиции возвращаемых значений относительно строкового буфера в стеке. Видно, что строка длиннее буфера повредит адрес возврата, сохранённый main.
Рисунок 11.14. Представление буфера и возвращаемых значений в стеке
Начнём сеанс отладки. Перед попыткой эксплуатации полезно узнать о мерах защиты. В данном случае checksec показывает, что отключены все меры, кроме PIE и RelRO.
Создаём циклический шаблон длиной 100, устанавливаем точку останова на func и запускаем программу с шаблоном в качестве аргумента.
После достижения точки останова продолжаем выполнение и проверяем повреждение PC. Программа аварийно завершается, а x29, x30 и PC заполнены шаблоном.
Искать шаблон в PC нельзя, потому что значение усечено. Однако RET по умолчанию записывает в PC значение x30. Поэтому можно определить смещение шаблона для x30.
Следовательно, байты после первых 88 байт ввода, скорее всего, попадут в x30 и затем в PC. Проверим: создадим шаблон длиной 88 и добавим 8 байт AAAABBBB.
После продолжения x30 и PC ожидаемо содержат AAAABBBB.
Теперь известно правильное смещение, и после 88 символов можно поместить произвольный адрес. Чтобы выполнить secret(), сначала определим адрес её первой инструкции командой disassemble.
Итоговая полезная нагрузка состоит из 88 байт A, за которыми следует адрес secret(). Для удобства экспортируем её в переменную окружения.
Откроем двоичный файл в новом сеансе, установим точку останова на func и запустим с сохранённой нагрузкой.
Перед возвратом func видно, куда нагрузка попала в стеке. Функция возвращается нормально, потому что LDP заполняет x29 и x30 двумя верхними значениями стека, где адрес возврата ещё не повреждён.
Но после извлечения двух верхних значений в x29 и x30 SP увеличивается на #112. Исследование этой области показывает, что SP будет указывать на нагрузку.
func возвращается нормально, и выполнение оказывается в main на инструкции после вызова.
Через несколько шагов встречается LDP, восстанавливающая сохранённые main значения возврата и ожидающая адрес инструкции, переходящей к exit.
Однако нагрузка перезаписала эти значения. Теперь область адреса возврата содержит адрес secret, как показано на рисунке 11.15.
Рисунок 11.15. Буфер переполнен, а адрес возврата перезаписан адресом secret
После LDP x30 содержит адрес secret(), а PC - адрес следующей RET, которая запишет в PC значение x30.
После RET PC содержит адрес secret().
Для запуска нагрузки вне GDB необходимо отключить ASLR, иначе адрес secret изменится.
Запуск двоичного файла с нагрузкой выводит You should not be here, подтверждая успешное выполнение secret().
Для отладки процесса в GDB достаточно подключиться к его идентификатору и убедиться, что у GDB есть необходимые разрешения.
В этом разделе на примере показана важность отладки для анализа уязвимостей и разработки эксплойтов. Рассматривается повреждение памяти, вызывающее сбой, но не из-за того, что пользовательский ввод напрямую делает PC недопустимым. То есть ввод не приводит непосредственно к контролю PC. Чтобы установить причину, необходима отладка.
Уязвимость[15] находится в HNAP, часто используемом производителями маршрутизаторов для связи с веб-интерфейсом, и срабатывает через запрос входа. Подробности уязвимости и разработка эксплойта выходят за рамки раздела. Цель - показать ситуацию, когда отладка нужна для преодоления препятствий, вызывающих сбой.
Некоторые процессы порождают дочерние процессы. Здесь уязвимость срабатывает в дочернем процессе, создаваемом событием. Чтобы GDB следовал за дочерним ответвлением, используйте set follow-fork-mode child.
Процесс ожидает входящий запрос. С другой машины отправляется вредоносный запрос.
Дочерний процесс завершился с ошибкой сегментации. Но пользовательский ввод не повредил PC. Сбой произошёл на STRB, пытающейся сохранить R2 по адресу из R3. Это означает, что часть ввода использовалась при вычислении адреса, который в итоге стал недопустимым значением R3.
Следующий шаг - поставить точку останова за несколько инструкций до сбоя и пошагово выяснить, какая часть ввода участвовала в вычислении. Предшествующие STRB инструкции можно исследовать командой GDB просмотра памяти. Здесь выводятся пять инструкций от текущего PC минус 16 байт.
Перед перезапуском создадим циклический шаблон, который станет новым вводом и позволит определить смещение значения, попадающего в вызывающие сбой регистры.
Теперь перезапускаем отладку, указываем GDB следовать за дочерним ответвлением, ставим точку останова на 0x19810 и продолжаем.
После отправки эксплойта с циклическим шаблоном достигается точка останова. Но это цикл, и ввод обрабатывается лишь на итерации Captcha, поэтому продолжаем, пока не достигнем именно её.
Теперь циклический шаблон виден в R2. Это значение участвует в расчёте адреса, который в итоге попадает в R3 и вызывает сбой.
R1 выглядит неповреждённым. Его значение прибавляется к R2 с шаблоном, а результат затем прибавляется к R3. Точное смещение значения в R2 вычисляет pattern search.
Смещение равно 1024: следующие 4 байта после 1024 символов ввода попадут в R2. Далее требуется определить подходящее значение R2. Здесь проблему можно обойти значением минус 1 (0xffffffff). Изменяем эксплойт: 1024 символа, шестнадцатеричное минус 1 и ещё 300 символов A, которые в идеале вызовут сбой в PC.
Повторное подключение и отправка нового ввода наконец приводят к сбою в PC.
Теперь PC находится под нашим контролем, и в него можно поместить адрес ROP-гаджета, выполняющего следующую требуемую инструкцию.
[3] [назад] hex-rays.com
[4] [назад] book.rada.re
[6] [назад] github.com
[7] [назад] github.com
[9] [назад] github.com
[10] [назад] github.com
[11] [назад] hugsy.github.io
[12] [назад] github.com
[13] [назад] book.rada.re
[14] [назад] book.rada.re
[15] [назад] CVE-2016-6563.
До недавнего времени в основе любого Mac находился процессор Intel. Теперь все новые Mac оснащаются "Apple Silicon". Начиная с M1, эти системы на кристалле используют набор инструкций Arm. Чтобы сохранить нативную совместимость с новыми системами Apple, авторы вредоносного ПО начали распространять свои творения в виде 64-разрядных двоичных файлов Arm.
Для аналитиков вредоносного ПО Mac появление таких файлов создаёт определённые трудности. Важнее всего то, что они дизассемблируются не в привычные инструкции Intel, а в набор A64.
К этому моменту у вас уже есть базовое понимание данного набора инструкций. В этой главе мы разовьём знания и предоставим сведения, необходимые для становления квалифицированным аналитиком вредоносного ПО arm64 для macOS.
Глава начинается с вводных тем, например способов распознавания нативных двоичных файлов arm64 macOS. Эти знания помогут искать вредоносное ПО arm64 macOS и действительно применялись при обнаружении первого вредоносного ПО с нативной поддержкой Apple Silicon. Остальная часть посвящена инструментам и методам анализа, особенно логике противодействия анализу, которая пытается сорвать исследования.
Примечание. Apple называет 64-разрядные двоичные файлы Arm для macOS словом arm64. VirusTotal аналогично использует тег ARM64. В этой главе применяется терминология Apple и обозначение arm64.
Примечание. Глава написана совместно с Патриком Уордлом, основателем некоммерческого фонда Objective-See. Уордл много лет исследует вредоносное ПО macOS, а обнаружение им в 2021 году первого вредоносного ПО, скомпилированного нативно для Apple Silicon, привело его в мир arm64. Если вас интересует анализ вредоносного ПО macOS, Патрик написал цикл книг
Вместе со стремительным ростом популярности macOS увеличивается и распространённость вредоносного ПО для настольной ОС Apple. Причины этой синхронной динамики неоднозначны, но бесспорно одно: больше систем macOS означает больше целей. Авторы вредоносного ПО оппортунистичны и потому посвящают всё больше времени и ресурсов созданию средств заражения macOS. Настолько, что уже в 2018 году по некоторым показателям[1] число обнаруженных угроз на одну конечную точку Mac превысило Windows.
Интересно, хотя и неудивительно, что многие недавние образцы вредоносного ПО для macOS не являются полностью новыми. Рост macOS побуждает авторов переносить вредоносные программы с Windows или Linux. Среди недавних примеров Dacls, IPStorm и GravityRAT.[2] Теперь все они нативно работают в macOS. При этом специфическое для Mac вредоносное ПО продолжает циркулировать, становясь распространённее и сложнее.
Как отмечалось, движущая сила увеличения числа вредоносных программ Mac - резкий рост популярности систем Mac. В отчёте начала 2022 года утверждалось, что в 2021 году "поставки Mac росли вдвое быстрее общих поставок ПК".[3]
Рост популярности объясняется большей востребованностью в организациях, увеличением удалённой рабочей силы и, наконец, появлением высокопроизводительной микросхемы Apple M1. Выпущенная в 2020 году M1 - система на кристалле Arm, которая "объединяет множество мощных технологий на одной микросхеме и использует унифицированную архитектуру памяти для резкого повышения производительности и эффективности".[4]
В контексте главы важнейший аспект M1 - это система на кристалле Arm, процессор которой поддерживает A64. Чтобы двоичный файл нативно работал на M1, он должен быть скомпилирован как 64-разрядный Mach-O Arm. Двоичные файлы Intel всё ещё работают на новых Mac, но не нативно. Apple понимала, что обратная совместимость необходима для широкого принятия M1, и выпустила Rosetta(2).[5]
Rosetta - процесс трансляции, позволяющий запускать на Apple Silicon приложения с инструкциями x86_64.
Для пользователя Rosetta в основном прозрачна. Если исполняемый файл содержит только инструкции Intel, macOS автоматически запускает Rosetta и начинает трансляцию. После её завершения система запускает переведённый исполняемый файл вместо исходного. Но трансляция требует времени, поэтому переведённые приложения иногда запускаются или работают медленнее.
Итак, Rosetta(2) прозрачно переводит инструкции x86_64 (Intel) в нативные A64 и позволяет старым приложениям работать на M1. Однако важны два момента:
• Двоичные файлы не Arm 64 не работают на Apple Silicon нативно, поскольку процессор понимает только A64. Сначала Rosetta(2) должна их перевести. Хотя переводы кэшируются, последующие запуски всё равно несут накладные расходы и будут медленнее нативных 64-разрядных Arm.
• Двоичные файлы Arm 64 с инструкциями A64 не требуют трансляции и связанных с Rosetta(2) расходов. Приложения, перекомпилированные для M1, работают нативно и быстрее и не подвержены проблемам и особенностям Rosetta(2).
Поскольку нативные файлы Arm 64 быстрее, а первая Rosetta(2) имела проблемы, мешавшие некоторым приложениям Intel, Apple рекомендует[6] перекомпилировать приложения для нативной работы на Apple Silicon. Неудивительно, что разработчики и авторы вредоносного ПО теперь поставляют файлы arm64.
Стоит отметить, что вредоносное ПО arm64 - просто вредоносное ПО Mac, скомпилированное для нативной работы на Apple Silicon. По возможностям и функциям оно не отличается от вредоносного ПО Mac для Intel. Более того, значительная часть современных образцов arm64 изначально распространялась как x86_64 и была лишь перекомпилирована для Apple Silicon.
Создание вредоносного ПО arm64, например GoSearch22, первого образца, нативно скомпилированного для Apple Silicon,[7] примечательно по двум основным причинам. Во-первых, оно показывает, что авторы вредоносного ПО и их творения продолжают развиваться в прямой ответ на аппаратные и программные изменения Apple. Распространение нативных файлов arm64 даёт множество преимуществ, так зачем злоумышленникам от них отказываться?
Вскоре будет рассмотрено обнаружение первого вредоносного ПО, нативно скомпилированного для Apple Silicon. Оно подтвердило предположение, что злоумышленники действительно будут компилировать и распространять вредоносное ПО как arm64. После его обнаружения в начале 2021 года нашли множество других образцов. Среди заметных:
• SilverSparrow, заразивший десятки тысяч систем macOS;[8]
• Bundlore, который Apple по ошибке нотариально удостоверила, то есть "одобрила".[9]
Во-вторых, что тревожнее, инструменты статического анализа и антивирусные движки могут плохо справляться с arm64. На рисунке 12.1 показаны результаты VirusTotal для файлов x86_64 и arm64 из вредоносного универсального приложения, то есть содержавшего двоичные файлы нескольких архитектур.
Теоретически оба файла должны обнаруживаться с одинаковой частотой, поскольку содержат логически эквивалентный вредоносный код. К сожалению, число срабатываний на версии arm64 снизилось более чем на 10 процентов по сравнению с отдельной x86_64. Несколько ведущих антивирусов, обнаруживших x86_64, не пометили arm64.
Предположительно их сигнатуры основывались на специфичных для Intel инструкциях, то есть кодах операций. У вредоносного ПО Arm инструкции совершенно иные, поэтому сигнатуры на основе архитектурных инструкций могут не сработать. Более того, некоторые движки, правильно отметившие обе версии, присвоили логически одному файлу разные имена.
Рисунок 12.1. Число антивирусных обнаружений вредоносного образца arm64 снижается
Одним движком с конфликтующими именами был Microsoft, назвавший архитектурные файлы Trojan:MacOS/Bitrep.B и Trojan:Script/Wacatac.C!ml. Такие конфликты могут указывать на непоследовательную обработку разных форматов двоичных файлов. Они способны вызвать путаницу в идентификации и отчётности, имеющую реальные последствия.
Наконец, хотя в ближайшее время вредоносное ПО для Apple Silicon, вероятно, будет распространяться универсальными файлами, так будет не всегда. В будущем, когда Apple Silicon станет распространённее, появятся образцы macOS только с кодом arm64.
Для аналитиков macOS наличие исключительно arm64 создаёт трудности, прежде всего потому, что код дизассемблируется не в привычные инструкции Intel, а в A64. Хорошая новость: сведения из предыдущих глав возвращают аналитиков в строй, и анализ arm64 в основном будет простым.
Прежде чем анализировать вредоносный GoSearch22, всесторонне исследуем классическую программу Hello World, скомпилированную как arm64 macOS. Это подготовит нас к более сложным файлам и подчеркнёт особенности macOS, встречающиеся при анализе вредоносного ПО arm64.
Используем код, автоматически создаваемый Xcode при создании проекта командной строки:
Код можно скомпилировать через Xcode или непосредственно clang: clang main.m -fmodules -o helloWorld.
После компиляции откройте файл Hello World в выбранном дизассемблере. Получится примерно такой код:
Перед подробным разбором нужны два замечания.
Во-первых, блок @autoreleasepool, управляющий памятью в контексте времени жизни объектов Objective-C, скомпилирован в парные вызовы objc_autoreleasePoolPush и objc_autoreleasePoolPop. Во-вторых, кратко рассмотрим соглашение о вызовах macOS. Это особенно важно при анализе вредоносного ПО: часто не нужно полностью восстанавливать образец, достаточно понять вызываемые API и передаваемые им параметры.
Вызовы функций и методов подчиняются строгим правилам использования регистров: какие передают параметры, а какие возвращают значение. Они сформулированы в ABI. Поскольку правила применяются последовательно, мы понимаем низкоуровневую организацию вызовов.
Нативная архитектура набора инструкций Apple Silicon - AArch64, 64-разрядное состояние выполнения ARMv8. Как изучено в первой части, X0-X7 содержат первые восемь аргументов, а возвращаемое значение находится в X0 и в X1, если оно 128-разрядное.
Таким образом, единственный параметр вызова метода или функции всегда передаётся в X0. Если вызов возвращает 64-разрядное значение, после возврата оно находится в X0.
Перейдём к дизассемблированному Hello World.
Сначала встречается пролог: код вычитает 0x30 из указателя стека, освобождая место для локальных переменных и сохраняемых значений. Затем STP сохраняет X29 и X30 в стеке, а X29 получает SP+0x20.
Через несколько инструкций BL вызывает objc_autoreleasePoolPush. Напомним, перед передачей управления через BL регистр связи X30 получает адрес следующей инструкции, чтобы функция знала, куда возвращаться. Согласно документации компилятора,[10] objc_autoreleasePoolPush возвращает указатель на объект пула, который позднее должен передаваться objc_autoreleasePoolPop для освобождения. Такой пул обеспечивает автоматический подсчёт ссылок (ARC), управляющий временем жизни объектов Objective-C. Поскольку возвращаемое значение функции находится в X0, инструкция str x0, [sp, #0x20 + var_20] сохраняет указатель в выделенной области стека.
Далее код инициализирует X0 адресом строки Hello, World!, которая служит первым аргументом следующей функции. Адрес вычисляется ADRP и ADD, затем помещается в X0. BL вызывает NSLog, печатающую строку.
После вызова objc_autoreleasePoolPop выполняется выход из пула автоосвобождения. Согласно документации, функция принимает освобождаемый объект пула. Инструкция ldr x0, [sp, #0x20 + var_20] загружает его из ранее использованной области стека.
Наконец достигается эпилог main. Эпилоги обычно восстанавливают регистры, корректируют стек и возвращаются к вызывающей стороне. Сначала W0 инициализируется 32-разрядным возвращаемым значением из стека. В начале кода эта область была обнулена MOVZ и STR, что ожидаемо: исходный код всегда возвращает 0.
После настройки возвращаемого регистра функция восстанавливает X29 и X30 посредством LDP. Они были сохранены в прологе. Затем указатель стека возвращается к исходному значению.
Вычисление адреса строки заслуживает внимания: ADRP формирует адрес страницы, содержащей литерал, а ADD прибавляет внутристранничное смещение #0x8. До самого вызова адрес временно находится в X9 и лишь затем копируется в X0 в соответствии с соглашением о первом аргументе. Аналогично значение, возвращённое objc_autoreleasePoolPush, нельзя оставлять только в энергозависимом X0, потому что последующий NSLog его перезапишет; поэтому указатель заранее сохраняется в стеке и загружается обратно непосредственно перед objc_autoreleasePoolPop.
Эпилог является зеркалом пролога. LDP одной инструкцией возвращает оба сохранённых регистра, X29 и регистр связи X30. Прибавление 0x30 освобождает зарезервированный кадр стека. После этого RET использует восстановленный адрес возврата и передаёт управление вызывающей стороне, а W0 уже содержит предусмотренный исходным кодом нулевой результат.
Для этого к SP прибавляется 0x30. Наконец, RET возвращает управление из main.
Прежде чем анализировать вредоносное ПО, нужно научиться находить образцы для нативной работы на Apple Silicon. В этом разделе показано, как определить наличие в файле нативного кода Apple Silicon и какими поисковыми запросами сузить поиск.
Один из простых способов определить архитектуру кода - встроенная в macOS утилита file; также подходят otool и lipo. С её помощью можно проверить наличие скомпилированного arm64.
Рассмотрим приложение Apple Calculator:
Calculator пересобран для нативной работы на Apple Silicon и содержит arm64 (Mach-O 64-bit executable arm64e). Для совместимости со старыми системами он также содержит нативный код Intel x86_64.
Нативный формат исполняемых файлов Apple - Mach-O. Такой файл содержит код одной архитектуры. Чтобы единый файл выполнялся на разных архитектурах, например Intel 64 и Apple Silicon, разработчики встраивают несколько Mach-O в универсальный, или "толстый", файл.
При запуске универсального файла ОС автоматически выбирает архитектуру хоста. На 64-разрядном Intel запускается встроенный Mach-O x86_64, а на Apple Silicon - Mach-O arm64.
Обнаружение arm64 или arm64e, расширения arm64 от Apple, - хороший первый шаг. Однако Mach-O используется и в iOS, а нас интересует только macOS. Их можно различить по командам загрузки в заголовке Mach-O. LC_BUILD_VERSION с платформой 1 (macOS) либо LC_VERSION_MIN_MACOSX подтверждает macOS; для iOS платформа равна 2.
Также можно исследовать зависимости. Файл, зависящий от специфичных для macOS фреймворков, например AppKit, а не UIKit iOS, является файлом macOS. Встроенная otool показывает команды загрузки параметром -l, а зависимости - -L; -v преобразует константы вроде платформы 1 в строку MACOS.
Для поиска вредоносного ПО arm64 в природе можно использовать VirusTotal,[11] располагающий огромной коллекцией отправленных файлов. Он предоставляет поисковые модификаторы для ограничения по типу, архитектуре и другим свойствам. Модификаторы для нативной совместимости с Apple Silicon показаны в таблице 12.1.
Таблица 12.1. Поисковые модификаторы
Таблица 12.1. Поисковые модификаторы (продолжение)
Примечание. Результаты всё ещё могут включать универсальные файлы iOS. Рекомендуется вручную отсеивать ложные результаты. В VirusTotal можно игнорировать универсальные файлы без x86_64: iOS работает только на Arm, поэтому наличие Intel указывает на macOS. Также работают ранее упомянутые методы, например просмотр LC_BUILD_VERSION через otool.
Предыдущие модификаторы возвращают преимущественно файлы macOS с A64. Однако среди более чем 100 000 совпадений подавляющее большинство безвредно, как показано на рисунке 12.2.
Для поиска любого вредоносного ПО с нативной поддержкой Apple Silicon можно добавить positives, ограничивающий результаты файлами, отмеченными заданным числом антивирусов. Поскольку поиск ориентирован на универсальные файлы и предполагает желание злоумышленников сохранить работу на Intel, разумно ожидать, что текущие сигнатуры обнаружат хотя бы код Intel. Запрос пропустит новое, ещё не обнаруженное ПО, но нам для иллюстрации нужно найти любое вредоносное ПО, нативно работающее на Apple Silicon.
Запрос:
Он возвращает гораздо более короткий список вредоносных универсальных файлов со встроенным arm64, как показано на рисунке 12.3.
Рисунок 12.2. Предыдущие модификаторы поиска включают доброкачественные результаты
Рисунок 12.3. Изменённый запрос возвращает результаты более чем с двумя обнаружениями вредоносности
Примечание. Подробнее о модификаторах см. документацию VirusTotal.[12]
Этот запрос в начале 2021 года помог обнаружить GoSearch22.[13] Он оказался первым найденным в природе вредоносным ПО, нативно скомпилированным для новых микросхем Apple. Пример поиска показан на рисунке 12.4.
Рисунок 12.4. Поиск вредоносного ПО macOS arm64 GoSearch22 в VirusTotal
Утилита file подтверждает универсальный файл со встроенными Intel x86_64 и Apple Silicon arm64.
otool также подтверждает macOS наличием LC_VERSION_MIN_MACOSX.
Прежде чем анализировать противодействие анализу GoSearch22, рассмотрим ещё один пример поиска. Образы дисков DMG популярны для распространения вредоносного ПО Mac. Их ищут модификатором type:dmg. Один образ Parallels-desktop-16-5-crack-with-keygen-download-2021.dmg[14] по данным VirusTotal заражён рекламным ПО Bundlore.
Рисунок 12.5. Результаты VirusTotal для рекламного ПО Bundlore
Чтобы подтвердить наличие arm64 в образе с помощью file, сначала подключим его встроенной утилитой macOS hdiutil в /Volumes/Install.
Помимо VirusTotal, вредоносное ПО arm64 уже могут содержать другие сетевые хранилища файлов. Простое посещение сомнительных сайтов также часто помогает найти образцы. Нередко они предлагаются как "обязательное" обновление, показанное на рисунке 12.6.
Для проверки заражения системы arm64 можно начать с перечисления неподписанных выполняющихся процессов, закрепившихся объектов, например агентов или демонов запуска, и дополнений браузеров. Неизвестные или подозрительные объекты можно отправить в VirusTotal[15] для проверки более чем 50 ведущими антивирусами.
Рисунок 12.6. "Обязательное" обновление обманом заставляет пользователей заразить себя
Понимание ассемблера и низкоуровневая обратная разработка - основные навыки аналитика вредоносного ПО.
Существуют инструменты автоматизированного анализа в изолированной среде, регистрирующие изменения во время выполнения. Для углублённого анализа применяется сочетание статических и динамических средств: дизассемблеров, декомпиляторов, системного мониторинга и отладчиков, позволяющих обходить противодействие анализу и обфускацию и собирать сведения для обнаружения и устранения.
Динамический анализ подразумевает выполнение файла, например вредоносного, для наблюдения за действиями. Всегда выполняйте его в изолированной виртуальной машине, а лучше на отдельной машине анализа. Не проводите динамический анализ в основной системе! Подробная настройка ВМ описана в статье "How to Reverse Malware on macOS Without Getting Infected".[16]
Примечание. GoSearch22 анализировался на отдельной машине. У виртуальных систем есть преимущества, например быстрые снимки и откат, но поддержка виртуализированной macOS на Apple Silicon пока недостаточна. Кроме лучшей изоляции и безопасности, отдельная машина полностью избегает антивиртуализационной логики вредоносного ПО.
Предположим, требуется определить, как образец закрепляется в заражённой системе. Часто достаточно выполнить его вместе с монитором процессов или файлов, который быстро выявит способ установки. Дополнительные подходы, инструменты и методы динамического анализа macOS описаны в главе 7 "Dynamic Analysis Tools" книги
В предыдущем разделе мы искали вредоносное ПО с нативной поддержкой Apple Silicon. Теперь проанализируем его. Если оно встроено в универсальный файл, как GoSearch22, сначала нужно извлечь arm64. Это просто делается встроенной lipo.
Примечание. Для самостоятельного повторения загрузите образец по адресу objective-see.com.
Примечание. Это вредоносное ПО; запускайте его только в изолированной среде.
Сначала перечислим архитектуры универсального файла параметром -archs, отметив arm64.
Затем параметром -thin извлечём arm64 и подтвердим результат через file.
Авторы вредоносного ПО знают типичные методы анализа и реализуют логику, метко называемую "противодействием анализу", чтобы помешать исследованию или усложнить его. Существует много её разновидностей. Например, противодействие отладке пытается выяснить, отлаживается ли программа. Антивиртуализационная логика определяет, работает ли она в виртуальной машине анализа. Оба подхода встречаются в GoSearch22 и далее рассматриваются подробнее.
Можно встретить и другие виды: противодействие эмуляции мешает эмулировать вредоносное ПО, а противодействие дампам - создавать снимок его памяти.
Один из признаков обнаружения аналитической среды - преждевременное завершение при запуске в виртуальной машине или отладчике. Если такая логика подозревается, главная цель - найти отвечающий за неё код. После обнаружения его можно обойти патчем либо пропустить выполнение в отладчике.
Для поиска полезны средства статического анализа, например дизассемблер. GoSearch22 реализует множество методов и является прекрасным примером: файл завершается в виртуальной машине или отладчике, мешая понять закрепление и полезную нагрузку. Наша цель - обнаружить и понять это противодействие. Многие его методы встречаются и в несвязанных образцах. Дополнительные сведения приведены в главе 9 "Anti-Analysis" книги
Один из самых мощных инструментов аналитика - отладчик. Вредоносное ПО отвечает логикой, которая либо полностью запрещает отладку, либо обнаруживает её и преждевременно завершает процесс.
Сначала рассмотрим GoSearch22 с системным вызовом ptrace, затем подход через API sysctl. При запуске в lldb GoSearch22 преждевременно завершается.
Кроме противодействия отладке и виртуальным машинам встречаются проверки эмуляции, не позволяющие эмулировать вредоносный файл, и меры против снятия дампа, препятствующие созданию снимка памяти. Сам по себе ранний выход при динамическом анализе ещё не доказывает наличие такой логики, но является сильным признаком. Обнаружив подозрительное поведение, аналитик должен локализовать точные инструкции, которые его вызывают, и только затем либо исправить их в файле, либо управляемо миновать в сеансе отладки.
Статический анализ особенно полезен для сужения поиска, но требует узнавать характерные шаблоны. GoSearch22 удобен как учебный образец именно потому, что содержит сразу несколько таких проверок. Они не позволяют напрямую наблюдать закрепление программы в системе и возможности её полезной нагрузки. Более того, реализованные им приёмы не уникальны и встречаются в других семействах вредоносного ПО macOS.
Примечание. lldb[18] - фактический стандартный отладчик систем Apple. Он запускается из командной строки или встроен в средства обратной разработки. Здесь используется дизассемблер и декомпилятор Hopper.
Код 45 (0x2d) показателен: это результат вызова ptrace с флагом PT_DENY_ATTACH. Флаг запрещает отладку процесса. После вызова последующие подключения не удаются, а уже отлаживаемый процесс завершается с кодом 45.
Это нестандартный запрос ptrace, добавленный Apple. Исходный код XNU (bsd/sys/ptrace.h) показывает значение PT_DENY_ATTACH 0x1F.
Логику легко обойти, пропустив вызов. Но сначала его нужно найти. Декомпиляция GoSearch22 содержит огромное число мусорных инструкций, например бессмысленные вложенные проверки и ложные вызовы dlsym:
Флаг PT_DENY_ATTACH поддерживается именно операционными системами Apple, а не стандартной реализацией ptrace. Если процесс уже находится под управлением отладчика, запрос не просто запрещает новое подключение: он немедленно прекращает текущий сеанс, что и объясняет редкий код 0x2d. Если же отладчика ещё нет, последующая попытка подключения завершится неудачно.
Такое поведение вполне отвечает интересам автора вредоносного ПО. Однако вызов можно не исполнять вообще. Основная трудность состоит не в самом обходе, а в поиске скрытого места вызова среди обфусцированного потока управления и многочисленных ложных операций.
Примечание. Подробнее см. "Using LLVM to Obfuscate Your Code During Compilation" (apriorit.com).
Как видно на рисунке 12.7, в списке вызываемых API нет пользовательского ptrace.
Рисунок 12.7. Вредоносное ПО не содержит вызовов пользовательского API ptrace
Программа маскирует вызов, непосредственно вызывая SYS_ptrace. В сопоставлении системных вызовов ptrace имеет номер 26 (0x1a).
Отсутствие импортированного символа ptrace поэтому не означает отсутствия проверки. Непосредственный системный вызов минует пользовательскую обёртку API и не появляется в обычном списке вызываемых функций. Сопоставление номера системного вызова с заголовками SDK позволяет всё же распознать его.
Системный вызов arm64 выполняется SVC, поэтому найдём эту инструкцию поиском дизассемблера.
Рисунок 12.8. Поиск инструкции svc
Hopper находит первый экземпляр по адресу 0x00000001000541fc.
X0 получает номер SYS_ptrace, X1 - PT_DENY_ATTACH, X2 и X3 обнуляются. SVC выполняет вызов, запрещающий отладку либо завершающий процесс с кодом 45.
Поиск Hopper переносит главное окно дизассемблирования прямо к найденной SVC. Последовательность перед ней полностью раскрывает назначение вызова: первые четыре аргумента системного вызова передаются в X0-X3, и два характерных значения 0x1a и 0x1f однозначно указывают на ptrace(PT_DENY_ATTACH, ...). Нулевые X2 и X3 соответствуют неиспользуемым в этом запросе аргументам.
Установим точку останова на SVC:
Когда CPU готов выполнить SVC, отладчик останавливается. Теперь PC можно изменить на адрес следующей инструкции 0x0000000100054200 командой reg write.
SVC не выполняется, и SYS_ptrace обходится. Но это ещё не всё.
Точка останова срабатывает непосредственно перед инструкцией, поэтому изменение PC не имитирует её результат, а полностью исключает вызов. Адрес следующей инструкции был заранее определён в дизассемблере. Команда reg write применима к любому регистру, и здесь явная запись нового PC заставляет процесс продолжить выполнение с 0x0000000100054200.
Даже после обхода проверки программа при продолжении преждевременно завершается.
Дополнительная логика использует sysctl: с его помощью программа проверяет, отлаживается ли она.
Из-за обфускации статически не очевидно, что вызов приводит к завершению. Но в отладчике после него программа вскоре выходит, а при пропуске продолжает работу.
Это наблюдение связывает sysctl с оставшейся проверкой: при разрешённом вызове процесс прекращается, а без него проходит дальше. В отличие от ptrace, API не запрещает отладку сам по себе. Он предоставляет программе сведения о собственном состоянии, после чего уже логика GoSearch22 принимает решение о выходе.
Объявление sysctl:
Функция получает разные сведения, включая состояние текущего процесса и флаг отладки:
Сначала объявляются kinfo_proc, её размер и массив, предписывающий получить сведения о процессе. sysctl заполняет структуру, включая p_flag, который проверяется на P_TRACED.
Четыре элемента массива последовательно выбирают пространство ядра, сведения о процессе, поиск по PID и сам текущий PID. Третий параметр указывает на буфер результата, а четвёртый содержит его размер. После успешного вызова поле processInfo.kp_proc.p_flag отражает флаги текущего процесса. Побитовое AND с P_TRACED оставляет ненулевой результат только при трассировке отладчиком.
Вызов GoSearch22 по адресу 0x0000000100054ff0:
Две MOVZ обнуляют пятый и шестой аргументы X4 и X5.
Второй аргумент устанавливается в 4:
Побитовое OR нулевого WZR с 4 задаёт W1 значение 4, размер массива name.
Первый, третий и четвёртый аргументы X0, X2 и X3 загружаются LDUR:
X0 получает указатель на массив. В отладчике:
Значения соответствуют CTL_KERN (0x1), KERN_PROC (0xe), KERN_PROC_PID (0x1) и текущему PID. X2 - выходной указатель на kinfo_proc. X3 получает размер структуры 0x288:
Соглашение о вызовах объясняет назначение регистров: X0 содержит первый указательный параметр, W1 - 32-разрядную длину массива, X2 - адрес выходной структуры, X3 - указатель на переменную её размера, а X4 и X5 соответствуют нулевым newp и newlen. Таким образом, подготовка аргументов в дизассемблированном коде точно совпадает с ранее приведённым вызовом C.
LDUR загружает адрес переменной размера var_B8 в X8. MOVZ помещает 0x288 в W9, STR сохраняет значение по адресу X8, а LDUR загружает его в X3.
После sysctl программа проверяет бит P_TRACED в p_flag; если он установлен, она преждевременно завершается.
Следующие инструкции извлекают p_flag из kinfo_proc, адрес которой сохранён в var_90:
Адрес структуры загружается в X8, 32-разрядный p_flag по смещению 0x20 - в W8, а STUR сохраняет его в var_88.
P_TRACED равен 0x00000800, то есть установлен бит 11. В отладчике:
Инструкции извлечения:
LDUR загружает p_flag в W8. UBFX извлекает беззнаковое битовое поле из W8 с индексом 0xb, то есть 11, и шириной 1 - именно бит P_TRACED. STURB сохраняет результат.
Последовательность подготовки размера также важна: X8 сначала получает адрес переменной размера, W9 - непосредственное 0x288, затем STR записывает размер по этому адресу. Только после этого адрес переменной попадает в X3. После возврата sysctl вредоносное ПО читает структуру по сохранённому адресу var_90, а не полагается на временные значения регистров.
Поле p_flag имеет смещение 0x20 в kinfo_proc, поэтому используется именно ldr w8, [x8, #0x20]. Сохранение в var_88 позволяет проверить его значительно позднее, среди другой логики. UBFX извлекает одиннадцатый бит в младший разряд, а STURB записывает только полученный байт в var_81, который затем удобно сравнить с нулём.
Позднее проверяется, что бит P_TRACED не установлен.
Если он установлен, вредоносное ПО преждевременно завершается, поскольку его отлаживают.
Чтобы обойти вторую проверку и продолжить сеанс, снова пропустим проблемный вызов. Когда программа собирается выполнить BL к sysctl, изменим PC на следующую инструкцию. Без вызова kinfo_proc остаётся неинициализированной, заполненной нулями, и проверка P_TRACED возвращает ложь.
Теперь обе проверки противодействия отладке найдены и обезврежены, поэтому сеанс может продолжаться. Но впереди остаётся другая логика.
STURB сохраняет ровно извлечённый однобайтовый результат. Позднее LDURB снова загружает его, а CMP сравнивает с нулём. Ненулевой результат означает установленный P_TRACED и приводит к ветви преждевременного выхода. Чтобы не позволить структуре получить правдивые сведения об отладчике, достаточно заранее пропустить сам BL к sysctl: тогда исходный нулевой буфер остаётся неизменным и последующая проверка считает, что процесс не трассируется.
Динамический анализ должен выполняться в изолированной ВМ или на отдельной машине. Такие среды позволяют отключить механизмы безопасности ОС, мешающие отладке.
Авторы знают, что аналитики используют особые среды, и добавляют код их обнаружения. GoSearch22 также пытается определить аналитическую среду. Проанализируем эту логику, чтобы динамический анализ мог продолжаться.
При отладке полезно одновременно запускать монитор процессов: он обнаруживает дополнительные процессы. Вредоносное ПО часто запускает команды оболочки, исследующие окружение. Из-за обфускации дизассемблер и отладчик сначала не помогли обнаружить такую логику GoSearch22, но монитор процессов легко её выявил.
Изолированные среды не только защищают основную систему, но и позволяют аналитикам намеренно изменять конфигурацию, например отключать механизмы безопасности ОС, мешающие инструментам. Именно такие изменения становятся признаками анализа. Поэтому противник проверяет не только факт виртуализации, но и нетипичное состояние системы.
Монитор процессов особенно ценен при сильной статической обфускации: даже если код запуска команды скрыт мусорными ветвлениями, создание дочернего /bin/sh остаётся видимым системным событием. Связь родительского и дочернего PID позволяет уверенно приписать команду самому вредоносному процессу.
Монитор[19] фиксирует запуск вредоносного процесса с PID 1032, а затем утилиты csrutil macOS через /bin/sh:
Вредоносное ПО запустило csrutil, поскольку PPID равен PID 1032. Утилита определяет состояние System Integrity Protection (SIP), часто отключаемой на аналитических системах.
Зная, что программа выполняет команды, вернёмся в отладчик и установим точки останова на API запуска дочерних процессов, например system или posix_spawn. Точка на posix_spawn срабатывает:
Обратная трассировка bt показывает последовательность вызовов: posix_spawn вызван методом launchWithDictionary:error: класса NSConcreteTask, который вызван вредоносным ПО перед адресом 0x00000001000538e0.
Команда x/s печатает строку из X1 - путь запускаемого процесса /bin/sh.
В дизассемблере предыдущая инструкция находится по адресу 0x00000001000538dc. Она вызывает функцию из X8 посредством BLR.
Адрес назначения находится в X8, а параметры готовятся LDR. Из-за обфускации статически неясно, куда указывает X8, но после обхода противодействия это легко выяснить в отладчике.
Поставим точку на BLR и прочитаем X8.
X8 содержит адрес objc_msgSend. Сделаем отступление: любой вызов метода Objective-C компилятор направляет через эту функцию или её вариант. При обратной разработке macOS, в основном написанной на Objective-C или Swift, она встречается постоянно.
По документации Apple[20] функция "отправляет сообщение с простым возвращаемым значением экземпляру класса". Аргументы описаны на рисунке 12.9.
Рисунок 12.9. Аргументы Objc_msgSend и их описания в документации Apple
Первый аргумент self - указатель на объект Objective-C, для которого вызывается метод. Второй op - имя метода как строка с нулевым завершением. Далее идут аргументы конкретного метода.
В отладчике исследуем регистры при переходе к objc_msgSend, чтобы определить объект и метод.
Команда печати объекта po показывает первый аргумент: экземпляр NSConcreteTask, способный запускать внешние процессы.
Второй аргумент, строка с нулевым завершением, показывает метод launch. Какой внешний процесс будет запущен?
Именно соглашение о вызовах arm64 делает этот анализ прямолинейным. Перед objc_msgSend X0 всегда содержит получателя сообщения, а X1 - селектор метода. Поэтому po $x0 использует интроспекцию Objective-C и печатает сам объект, тогда как x/s $x1 интерпретирует селектор как строку с нулевым завершением.
Получатель NSConcreteTask является конкретной реализацией документированного NSTask. Название launch указывает на запуск уже настроенной задачи, но само по себе не показывает исполняемый путь и аргументы, поскольку этот метод не принимает дополнительных параметров.
Метод launch не принимает аргументов, поэтому нужно исследовать инициализацию объекта. Документация NSTask, документированного суперкласса NSConcreteTask, описывает свойства с путём процесса и аргументами.
Благодаря интроспекции Objective-C запросим их у объекта из X0.
Свойства задачи уже были заполнены до вызова launch. Обращения [$x0 launchPath] и [$x0 arguments] фактически отправляют исследуемому объекту дополнительные сообщения прямо из отладчика. Это позволяет восстановить намерение программы, не разбирая всю обфусцированную логику, которая создавала и настраивала объект.
Объект показывает выполнение через /bin/sh:
csrutil status сообщает, включена ли SIP. Поскольку SIP мешает отладке и другим инструментам, аналитики часто отключают её. Авторы реализовали проверку "отключена ли SIP?" как способ определить среду анализа и преждевременно выйти.
Командная цепочка сначала проверяет наличие csrutil, затем запрашивает состояние и отбрасывает строки со словом enabled. В зависимости от результата оболочка печатает 1 или 0. Таким образом, код получает простой логический признак вместо необходимости самостоятельно разбирать полный текстовый ответ утилиты.
После обнаружения проверку легко пропустить командой reg write, изменив поток управления мимо objc_msgSend.
Пропуск можно выполнить только после точной локализации вызова: изменение PC должно направить выполнение на безопасную инструкцию после BLR, не нарушив остальную настройку текущей функции. Более постоянным вариантом мог бы стать патч соответствующей ветви в копии образца.
Последняя логика пытается определить виртуальную машину. Это распространено: выполнение в виртуальной среде, вероятно, означает наблюдение аналитика.
Снова выполняется переход к objc_msgSend. Исследование регистров показывает очередной вызов NSConcreteTask для запуска внешнего процесса. Интроспекция:
Этот шаблон уже знаком по проверке SIP: объект задачи находится в X0, селектор launch в X1, а реальная команда скрыта в свойствах объекта. Поэтому тот же приём интроспекции сразу раскрывает путь /bin/sh и длинный сценарий проверки виртуализации.
Выполняется длинный набор команд, ищущих артефакты VirtualBox, Oracle, VMware, Parallels и QEMU. Если имя модели или продукта совпадёт, программа распознает виртуальную среду и выйдет.
После обнаружения логику легко обойти в отладчике, пропустив код, либо долговременно изменить среду ВМ так, чтобы проверка её не находила.
На этом логика противодействия анализу заканчивается. После обхода можно продолжать исследование. Оно выходит за рамки книги, поскольку достаточно традиционных, не специфичных для arm64 методов. Например, монитор файлов и процессов показывает попытку установить вредоносное расширение Safari, подменяющее сеансы просмотра рекламным поведением.
Популярность Mac продолжает расти, во многом благодаря впечатляющей M1. Обнаружив вредоносный код, нативно работающий на архитектуре ARM, мы подтвердили, что авторы быстро адаптируются. Поэтому адаптироваться должны и мы.
Вредоносное ПО для Apple Silicon дизассемблируется в arm64, поэтому понимать этот набор инструкций крайне важно. Необходимые сведения были представлены в предыдущих главах.
В этой главе мы развили их: сначала показали поиск вредоносного ПО arm64 для macOS, затем его анализ. В частности, исследовали логику противодействия анализу первого нативно совместимого с M1 вредоносного ПО и получили практический пример анализа дизассемблированного arm64.
Обладая твёрдым пониманием тем этой главы, вы уже на пути к квалифицированному анализу вредоносного ПО arm64 для macOS.
[3] [назад] 9to5mac.com
[5] [назад] developer.apple.com
[6] [назад] developer.apple.com
[8] [назад] redcanary.com
[10] [назад] clang.llvm.org
[11] [назад] virustotal.com
[12] [назад] support.virustotal.com
[13] [назад] SHA-256: b94e5666d0afc1fa49923c7a7faaa664f51f0581ec0192a08218d68fb079f3cf.
[14] [назад] SHA-256: 0c11f67594ef334c0a6d94e752c32eaacbff37d2a54339521312fbedfd9c509b.
[15] [назад] virustotal.com
[16] [назад] sentinelone.com
[18] [назад] lldb.llvm.org
[19] [назад] objective-see.com