Практические примеры сосредоточены на Intel x86 и 64-битовой x86-64 (x64); обе называются "ISA x86". Обычно используется x64, если не указано иное.

x86 широко распространена на настольных и портативных компьютерах и в исследованиях, поэтому на неё нацелены многие среды анализа. Её сложность позволяет изучить проблемы, отсутствующие в простых архитектурах. Долгая обратная совместимость с 1978 года дала очень плотный набор инструкций: почти любые байты образуют допустимый код операции. Это усугубляет различение кода и данных. Инструкции имеют переменную длину, допускается невыровненный доступ, поэтому возможны перекрывающиеся и смещённые инструкции. Освоив x86, проще перейти к ARM.

Для x86 распространены Intel и AT&T. Используется менее многословный Intel:

Целевой операнд edi стоит первым. Различия объяснены в приложении A.

Все примеры разработаны в Ubuntu Linux, преимущественно на C/C++, немногие на Python, поскольку популярные библиотеки ориентированы на Linux и эти API.

Однако техники и большинство инструментов применимы и в Windows. Основной формат - ELF, хотя многие средства поддерживают PE.

Каждая глава имеет примеры и предварительно настроенную виртуальную машину Ubuntu 16.04 со всеми открытыми инструментами. Она доступна по адресам https://practicalbinaryanalysis.com и https://nostarch.com/binaryanalysis/. Там же есть отдельный архив исходного кода, но без ВМ сложные среды придётся настраивать самостоятельно.

ВМ предназначена для бесплатного VirtualBox (https://www.virtualbox.org/) на Windows, Linux и macOS. Установите VirtualBox, выберите File → Import Appliance, импортируйте ВМ и запустите зелёной кнопкой Start. Имя пользователя и пароль: binary. Терминал открывается Ctrl-Alt-T.

В ~/code находится каталог каждой главы и ~/code/inc с общим кодом. Расширения: .cc - C++, .c - C, .h - заголовки, .py - Python. Для сборки главы перейдите в каталог и выполните make, кроме отдельно оговорённых случаев.

Важные образцы подробно обсуждаются. Если листинг существует в ВМ, перед ним указано имя файла; прочие подписи могут быть описаниями без соответствующего файла.

Пример:

filename.c

Если не указано иное, файл находится в каталоге своей главы. Короткие образцы без файла могут не иметь подписи.

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

Иногда вывод редактируется для удобочитаемости, поэтому в ВМ он может немного отличаться.

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

Бинарные файлы создаются посредством компиляции - процесса перевода понятного человеку исходного кода, например на Си или C++, в машинный код, который способен исполнять процессор.^[1] На рис. 1-1 показаны этапы типичного процесса компиляции программы на Си (для C++ они аналогичны). Компиляция кода на Си включает четыре этапа, один из которых (как ни странно) тоже называется компиляцией, как и весь процесс в целом. Это препроцессорная обработка, компиляция, ассемблирование и компоновка. На практике современные компиляторы нередко объединяют некоторые или все эти этапы, однако в учебных целях я рассмотрю каждый из них отдельно.

Рис. 1-1. Процесс компиляции программы на Си

Процесс компиляции начинается с некоторого количества исходных файлов, которые требуется скомпилировать (на рис. 1-1 они обозначены как file-1.c - file-n.c). Исходный файл может быть всего один, но крупные программы обычно состоят из множества файлов. Это не только упрощает управление проектом, но и ускоряет компиляцию: если изменился один файл, достаточно перекомпилировать только его, а не весь код.

Исходные файлы на Си содержат макросы (обозначаемые директивой #define) и директивы #include. С помощью директив #include подключаются заголовочные файлы (с расширением .h), от которых зависит исходный файл. На этапе препроцессорной обработки раскрываются все директивы #define и #include в исходном файле, и в результате остаётся чистый код на Си, готовый к компиляции.

Рассмотрим конкретный пример. В нём используется компилятор gcc, который установлен по умолчанию во многих дистрибутивах Linux.

К их числу относится Ubuntu - операционная система, установленная на виртуальной машине. Другие компиляторы, например clang или Visual Studio, дали бы сходный результат. Как отмечалось во введении, если не указано иное, все примеры кода в этой книге (включая текущий) я буду компилировать в код x86-64.

Предположим, требуется скомпилировать исходный файл на Си из листинга 1-1, который выводит на экран всем известное сообщение «Hello, world!».

Листинг 1-1. compilation_example.c

Вскоре вы увидите, что происходит с этим файлом на остальных этапах компиляции, а пока рассмотрим лишь результат препроцессорной обработки. По умолчанию gcc автоматически выполняет все этапы компиляции, поэтому ему нужно явно указать остановиться после препроцессорной обработки и показать промежуточный результат. В gcc для этого служит команда gcc -E -P: параметр -E предписывает gcc остановиться после препроцессорной обработки, а -P заставляет компилятор опустить отладочные сведения, чтобы результат выглядел немного чище. В листинге 1-2 показан сокращённый результат препроцессорной обработки. Запустите виртуальную машину и повторите эти действия, чтобы увидеть полный вывод препроцессора.

Листинг 1-2. Результат работы препроцессора Си для программы «Hello, world!»

Заголовок stdio.h подключается целиком: все его определения типов, глобальные переменные и прототипы функций как бы «копируются» в исходный файл. Поскольку это происходит с каждой директивой #include, вывод препроцессора может быть весьма объёмным. Кроме того, препроцессор полностью раскрывает все случаи использования макросов, определённых с помощью #define. В нашем примере это означает, что оба аргумента функции printf (FORMAT_STRING ❶ и MESSAGE ❷) вычисляются и заменяются соответствующими строковыми константами.

После завершения препроцессорной обработки исходный текст готов к компиляции. На этом этапе препроцессорный код переводится на язык ассемблера. (Большинство компиляторов здесь же выполняет значительную оптимизацию, уровень которой обычно задаётся параметрами командной строки, например от -O0 до -O3 в gcc. Как вы увидите в главе 6, степень оптимизации во время компиляции способна существенно повлиять на дизассемблирование.)

Почему результатом этапа компиляции служит текст на языке ассемблера, а не машинный код? Если рассматривать только один язык (в данном случае Си), такое решение кажется нелогичным, но оно приобретает смысл, если вспомнить обо всех прочих языках. Среди популярных компилируемых языков можно назвать Си, C++, Objective-C, Common Lisp, Delphi, Go и Haskell. Создание компилятора, который непосредственно выдавал бы машинный код для каждого из этих языков, стало бы чрезвычайно сложной и трудоёмкой задачей. Гораздо разумнее выдавать ассемблерный код (что само по себе уже достаточно сложно), а окончательный перевод с языка ассемблера в машинный код для всех языков поручить одному специализированному ассемблеру.

Итак, результат этапа компиляции - ассемблерный текст в достаточно понятном человеку виде, в котором сохранена символьная информация. Как уже говорилось, обычно gcc автоматически выполняет все этапы компиляции. Поэтому, чтобы увидеть ассемблерный текст, полученный на этапе компиляции, нужно указать gcc остановиться после этого этапа и сохранить ассемблерные файлы на диске. Для этого служит параметр -S (расширение .s традиционно используется для ассемблерных файлов). Кроме того, программе gcc передаётся параметр -masm=intel, чтобы она выдавала ассемблерный код в синтаксисе Intel, а не в принятом по умолчанию синтаксисе AT&T. В листинге 1-3 показан результат этапа компиляции для нашей программы.^[2]

Листинг 1-3. Ассемблерный код, созданный на этапе компиляции программы «Hello, world!»

Пока я не стану подробно разбирать этот ассемблерный код. В листинге 1-3 важно отметить, что его сравнительно легко читать благодаря сохранённым символам и функциям. Например, у констант и переменных вместо одних лишь адресов имеются символьные имена (пусть даже автоматически созданные, как LC0 ❶ для безымянной строки «Hello, world!»), а функция main ❷ снабжена явной меткой.

В данном случае это единственная функция. Все ссылки на код и данные также представлены символически - например, ссылка на строку «Hello, world!» ❸. Позднее, при работе с бинарными файлами, из которых удалены символы, такой роскоши у вас не будет!

На этапе ассемблирования наконец-то создаётся настоящий машинный код! На вход поступает набор файлов на языке ассемблера, полученных на этапе компиляции, а результатом становится набор объектных файлов, которые иногда также называют модулями. Объектные файлы содержат машинные инструкции, в принципе уже исполнимые процессором. Однако, как я вскоре объясню, до получения готового к запуску исполняемого бинарного файла предстоит выполнить ещё несколько действий. Обычно каждому исходному файлу соответствует один ассемблерный файл, а каждому ассемблерному файлу - один объектный. Чтобы создать объектный файл, программе gcc передают параметр -c, как показано в листинге 1-4.

Листинг 1-4. Создание объектного файла с помощью gcc

С помощью утилиты file (к этому удобному средству мы вернёмся в главе 5) можно убедиться, что полученный файл compilation_example.o действительно является объектным. Именно это и видно в листинге 1-4: файл определяется как перемещаемый 64-разрядный файл ELF с порядком байтов LSB (ELF 64-bit LSB relocatable).

Что именно это означает? Первая часть вывода file показывает, что файл соответствует спецификации ELF для исполняемых бинарных файлов, подробно рассматриваемой в главе 2. Точнее, это 64-разрядный файл ELF (поскольку в данном примере выполняется компиляция для x86-64) с порядком байтов LSB, то есть числа размещаются в памяти начиная с наименее значимого байта. Но важнее всего то, что файл является перемещаемым.

Перемещаемые файлы не зависят от размещения по какому-либо определённому адресу памяти: их можно свободно перемещать, не нарушая заложенных в код предположений. Увидев слово relocatable в выводе file, можно понять, что перед вами объектный, а не исполняемый файл.^[3]

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

Позднее в этой главе, когда придёт время впервые дизассемблировать файл, вы увидите содержимое объектного файла.

Компоновка - заключительный этап процесса компиляции. Как следует из названия, на этом этапе все объектные файлы связываются в единый исполняемый бинарный файл. В современных системах компоновка иногда включает дополнительный проход оптимизации, называемый оптимизацией времени компоновки (link-time optimization, LTO).^[4]

Нетрудно догадаться, что программа, выполняющая этот этап, называется компоновщиком, или редактором связей. Обычно она отделена от компилятора, который, как правило, реализует все предшествующие этапы.

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

Задача компоновщика - взять все объектные файлы программы и объединить их в единый согласованный исполняемый файл, обычно предназначенный для загрузки по определённому адресу памяти. Поскольку теперь расположение всех модулей в исполняемом файле известно, компоновщик может разрешить и большинство символьных ссылок. Ссылки на библиотеки разрешаются полностью или частично - в зависимости от типа библиотеки.

Статические библиотеки (в Linux они обычно имеют расширение .a, как показано на рис. 1-1) объединяются с исполняемым бинарным файлом, что позволяет полностью разрешить все ссылки на них. Существуют также динамические (разделяемые) библиотеки, которые совместно используются в памяти всеми работающими в системе программами. Иными словами, вместо копирования библиотеки в каждый использующий её бинарный файл динамическая библиотека загружается в память всего один раз, а любой бинарный файл, которому она нужна, обращается к этой общей копии. На этапе компоновки адреса размещения динамических библиотек ещё неизвестны, поэтому ссылки на них разрешить невозможно. Вместо этого компоновщик оставляет символьные ссылки на библиотеки даже в итоговом исполняемом файле; они разрешаются лишь тогда, когда бинарный файл действительно загружается в память для исполнения.

Большинство компиляторов, включая gcc, автоматически вызывают компоновщик в конце процесса компиляции. Поэтому для создания полного исполняемого бинарного файла достаточно вызвать gcc без специальных параметров, как показано в листинге 1-5.

Листинг 1-5. Создание исполняемого бинарного файла с помощью gcc

По умолчанию исполняемый файл называется a.out, однако это имя можно изменить, передав gcc параметр -o, за которым следует имя выходного файла. Теперь утилита file сообщает, что перед нами 64-разрядный исполняемый файл ELF с порядком байтов LSB ❶, а не перемещаемый файл, каким был результат этапа ассемблирования. Ещё одна важная деталь: файл скомпонован динамически ❷, то есть он использует библиотеки, которые не объединены с исполняемым файлом, а совместно используются всеми программами, работающими в той же системе. Наконец, строка interpreter /lib64/ld-linux-x86-64.so.2 ❸ в выводе file указывает, какой динамический компоновщик будет применяться для разрешения последних зависимостей от динамических библиотек при загрузке исполняемого файла в память. Запустив бинарный файл командой ./a.out, можно увидеть ожидаемый результат - строку «Hello, world!» в стандартном выводе. Это подтверждает, что создан работоспособный бинарный файл.

Но что означает сообщение о том, что из бинарного файла не «удалены символы» ❹? Об этом и пойдёт речь далее.

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

Чтобы вы представляли, как выглядит символьная информация, в листинге 1-6 показаны некоторые символы из нашего бинарного файла.

Листинг 1-6. Символы бинарного файла a.out, показанные программой readelf

В листинге 1-6 я использовал readelf для отображения символов ❶. К утилите readelf и разбору всего её вывода мы вернёмся в главе 5. Пока лишь обратите внимание, что среди множества незнакомых символов присутствует символ функции main ❷. Для него указан адрес 0x400526, по которому main будет находиться после загрузки бинарного файла в память. В выводе также приведён размер кода main - 32 байта - и указано, что это символ функции (тип FUNC).

Символьная информация может входить в состав бинарного файла, как в только что рассмотренном примере, либо храниться в отдельном файле символов; кроме того, существует несколько её разновидностей. Компоновщику достаточно основных символов, но для отладки можно создать гораздо более подробные сведения. Отладочные символы способны полностью связывать строки исходного кода с инструкциями на уровне бинарного файла, а также описывать параметры функций, сведения о кадрах стека и многое другое. Для бинарных файлов ELF отладочные символы обычно создаются в формате DWARF,^[5] а бинарные файлы PE, как правило, используют закрытый формат Microsoft Program Database (PDB).^[6] Сведения DWARF обычно встраиваются в бинарный файл, тогда как PDB хранится в отдельном файле символов.

Как нетрудно представить, символьная информация чрезвычайно полезна при бинарном анализе. Приведём лишь один пример: наличие набора чётко определённых символов функций существенно упрощает дизассемблирование, поскольку каждый такой символ можно использовать как начальную точку. Это, в частности, значительно снижает вероятность случайно дизассемблировать данные как код, что привело бы к появлению ложных инструкций в листинге. Знание того, какие части бинарного файла относятся к определённой функции и как она называется, также заметно облегчает специалисту по обратной разработке разделение кода на смысловые части и понимание его работы. Даже

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

Как уже упоминалось, символы можно разбирать утилитой readelf или программно с помощью библиотеки наподобие libbfd, что будет показано в главе 4. Существуют также библиотеки, специально предназначенные для разбора отладочных символов DWARF, например libdwarf, однако в этой книге они не рассматриваются.

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

Возможно, вы помните, что из нашего бинарного файла символы пока не удалены - это видно в выводе утилиты file в листинге 1-5. По-видимому, по умолчанию gcc не удаляет символы из только что скомпилированных бинарных файлов автоматически. Если вам интересно, как же бинарные файлы с символами превращаются в файлы без символов, то для этого достаточно одной команды с говорящим названием strip, как показано в листинге 1-7.

Листинг 1-7. Удаление символов из исполняемого файла

Вот и всё: теперь из нашего бинарного файла удалены символы ❶, что подтверждает вывод file ❷. В таблице символов .dynsym осталось лишь несколько символов ❸. Они используются для разрешения динамических зависимостей, например ссылок на динамические библиотеки, при загрузке бинарного файла в память, но почти бесполезны при дизассемблировании. Все остальные символы, включая показанный в листинге 1-6 символ функции main, исчезли.

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

Пока для всех операций дизассемблирования я буду использовать утилиту objdump (другие средства дизассемблирования рассматриваются в главе 6). Это простой и удобный дизассемблер, входящий в состав большинства дистрибутивов Linux и идеально подходящий для быстрого знакомства с кодом и данными бинарного файла. В листинге 1-8 показана дизассемблированная версия нашего объектного файла compilation_example.o.

Листинг 1-8. Дизассемблирование объектного файла

Если внимательно изучить листинг 1-8, можно заметить, что я дважды вызвал objdump. В первый раз, в точке ❶, я поручил objdump показать содержимое раздела .rodata. Его название означает «данные только для чтения» (read-only data); именно в этой части бинарного файла хранятся все константы, включая строку «Hello, world!». Более подробно .rodata и другие разделы бинарных файлов ELF рассматриваются в главе 2, посвящённой формату ELF. Пока обратите внимание, что содержимое .rodata представляет собой строку в кодировке ASCII, показанную в левой части вывода. Справа приведено понятное человеку представление тех же байтов.

Второй вызов objdump в точке ❷ дизассемблирует в синтаксисе Intel весь код объектного файла. Как видите, файл содержит только код функции main ❸, поскольку это единственная функция, определённая в исходном файле. За исключением нескольких макросов уровня ассемблера, вывод в основном довольно точно соответствует ассемблерному коду, ранее созданному на этапе компиляции. Интересно, что указателю на строку «Hello, world!» в точке ❹ присвоено нулевое значение. Следующий вызов ❺, который должен вывести строку на экран с помощью puts, тоже указывает в бессмысленное место - на смещение 19 в середине main.

Почему вызов, который должен ссылаться на puts, вместо этого указывает в середину main? Ранее я упоминал, что ссылки на данные и код из объектных файлов ещё не разрешены полностью, потому что компилятор не знает, по какому базовому адресу впоследствии будет загружен файл. Именно поэтому в объектном файле вызов puts пока не разрешён правильно: файл ожидает, что компоновщик подставит верное значение этой ссылки. В этом можно убедиться, попросив readelf показать все символы перемещения, присутствующие в объектном файле, как сделано в листинге 1-9.

Листинг 1-9. Символы перемещения, показанные программой readelf

Символ перемещения в точке ❶ сообщает компоновщику, что ссылку на строку следует разрешить так, чтобы она указывала на тот адрес, по которому строка в итоге окажется в разделе .rodata. Аналогично строка, отмеченная ❷, указывает компоновщику, как разрешить вызов puts.

Возможно, вы заметили, что из символа puts вычитается значение 4. Пока это можно оставить без внимания: вычисление перемещений компоновщиком несколько сложно, а вывод readelf способен сбить с толку, поэтому здесь я опущу подробности перемещения и сосредоточусь на общей картине дизассемблирования бинарного файла. Более подробные сведения о символах перемещения приведены в главе 2.

Крайний левый столбец каждой строки вывода readelf, выделенный в листинге 1-9, содержит смещение в объектном файле, по которому следует записать разрешённую ссылку. Если вы внимательно следили за изложением, то могли заметить, что в обоих случаях оно на единицу больше смещения инструкции, которую требуется исправить. Например, в выводе objdump вызов puts находится по смещению кода 0x14, но символ перемещения вместо этого указывает на смещение 0x15. Дело в том, что перезаписать требуется лишь операнд инструкции, а не её код операции. Так получилось, что у обеих исправляемых инструкций код операции занимает 1 байт, поэтому символ перемещения должен пропустить этот байт и указать на операнд инструкции.

Теперь, когда вы увидели внутреннее устройство объектного файла, пришло время дизассемблировать полный бинарный файл. Начнём с примера, содержащего символы, а затем перейдём к его эквиваленту без символов и посмотрим, чем различаются результаты дизассемблирования. Между дизассемблированием объектного и исполняемого бинарного файла существует значительная разница, как видно из вывода objdump в листинге 1-10.

Листинг 1-10. Дизассемблирование исполняемого файла с помощью objdump

Как видите, бинарный файл содержит гораздо больше кода, чем объектный. Теперь в нём находится не только функция main и даже не один-единственный раздел кода. Появилось несколько разделов с такими именами, как .init ❶, .plt ❷ и .text ❸. Все они содержат код, выполняющий разные задачи, например инициализацию программы или роль заглушек для вызова разделяемых библиотек.

Раздел .text является основным разделом кода и содержит функцию main ❹. В нём также находится ряд других функций, например _start, которые отвечают за подготовку аргументов командной строки и среды выполнения для main, а также за очистку после завершения main. Эти дополнительные функции являются стандартными и присутствуют в любом бинарном файле ELF, созданном gcc.

Кроме того, видно, что ранее незавершённые ссылки на код и данные теперь разрешены компоновщиком. Например, вызов puts ❺ указывает на правильную заглушку в разделе .plt для разделяемой библиотеки, содержащей puts. (Работа заглушек PLT объясняется в главе 2.)

Таким образом, полный исполняемый бинарный файл содержит значительно больше кода и данных, хотя данные здесь не показаны, чем соответствующий объектный файл. Однако пока интерпретировать вывод ненамного труднее. Всё меняется после удаления из бинарного файла символов, как показано в листинге 1-11, где objdump дизассемблирует версию нашего файла без символов.

Листинг 1-11. Дизассемблирование исполняемого файла без символов с помощью objdump

Главный вывод из листинга 1-11 состоит в том, что различные разделы по-прежнему чётко различимы (они отмечены ❶, ❷ и ❸), а функции - нет. Вместо этого все функции слиты в одну большую массу кода. Функция _start начинается в точке ❹, а deregister_tm_clones - в точке ❻. Функция main начинается в точке ❼ и заканчивается в точке ❽, однако ни в одном из этих случаев нет никаких особых признаков того, что инструкции у соответствующих маркеров являются началами функций. Единственное исключение - функции в разделе .plt, имена которых сохраняются, как и прежде; это видно по вызову __libc_start_main в точке ❺. Во всём остальном разбираться в листинге придётся самостоятельно.

Даже в этом простом примере уже легко запутаться. Представьте, насколько трудно понять крупный бинарный файл, в котором сотни различных функций слиты воедино! Именно поэтому точное автоматическое обнаружение функций так важно во многих областях бинарного анализа, что подробно обсуждается в главе 6.

Напишите программу на Си, содержащую несколько функций, и последовательно скомпилируйте её в ассемблерный файл, объектный файл и исполняемый бинарный файл. Попробуйте найти написанные функции в ассемблерном файле, а также в дизассемблированных объектном и исполняемом файлах. Видите ли вы соответствие между кодом на Си и ассемблерным кодом? Наконец, удалите символы из исполняемого файла и снова попытайтесь определить функции.

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

Каждый файл ELF начинается с исполняемого заголовка - структурированной последовательности байтов, которая сообщает, что перед нами файл ELF, к какому типу ELF он относится и где искать остальное его содержимое. Формат исполняемого заголовка можно узнать из определения его типа, как и определений других связанных с ELF типов и констант, в файле /usr/include/elf.h или в спецификации ELF.^[1] В листинге 2-1 приведено определение типа исполняемого заголовка 64-разрядного ELF.

Листинг 2-1. Определение ELF64_Ehdr в /usr/include/elf.h

Здесь исполняемый заголовок представлен структурой Си Elf64_Ehdr. Если найти её в /usr/include/elf.h, можно заметить, что в приведённом там определении struct используются такие типы, как Elf64_Half и Elf64_Word. Это всего лишь псевдонимы typedef для целочисленных типов наподобие uint16_t и uint32_t. Для простоты на рис. 2-1 и в листинге 2-1 я раскрыл все определения typedef.

Исполняемый заголовок, а вместе с ним и весь файл ELF, начинается с 16-байтового массива e_ident. Первые 4 байта e_ident всегда содержат «магическое значение», определяющее файл как бинарный файл ELF. Оно состоит из шестнадцатеричного числа 0x7f, за которым следуют ASCII-коды букв E, L и F. Расположение этих байтов в самом начале удобно тем, что позволяет таким утилитам, как file, и специализированным средствам наподобие загрузчика бинарных файлов быстро установить, что перед ними файл ELF.

За магическим значением находятся несколько байтов с более подробными сведениями об особенностях конкретного файла ELF. В elf.h индексы этих байтов - позиции с 4-й по 15-ю в массиве e_ident - символически обозначаются соответственно как EI_CLASS, EI_DATA, EI_VERSION, EI_OSABI, EI_ABIVERSION и EI_PAD. Их наглядное представление показано на рис. 2-1.

В действительности поле EI_PAD занимает несколько байтов, а именно элементы e_ident с индексами от 9 до 15. Сейчас все они отведены под заполнение: зарезервированы для возможного будущего использования, но пока имеют нулевое значение.

Байт EI_CLASS обозначает то, что в спецификации ELF называется «классом» бинарного файла. Название не слишком удачно: слово «класс» настолько общее, что может означать почти что угодно. На самом деле байт показывает, предназначен ли бинарный файл для 32- или 64-разрядной архитектуры. В первом случае EI_CLASS принимает значение константы ELFCLASS32, равное 1, а во втором - ELFCLASS64, равное 2.

С разрядностью архитектуры связан порядок байтов. Иными словами, располагаются ли многобайтовые значения, например целые числа, в памяти сначала наименее значимым байтом (little-endian) или наиболее значимым (big-endian)? Байт EI_DATA задаёт порядок байтов бинарного файла. Значение ELFDATA2LSB, равное 1, обозначает прямой порядок от младшего байта к старшему, а ELFDATA2MSB, равное 2, - обратный порядок от старшего байта к младшему.

Следующий байт, EI_VERSION, задаёт версию спецификации ELF, использованную при создании бинарного файла. Сейчас единственное допустимое значение - EV_CURRENT, определённое как 1.

Наконец, байты EI_OSABI и EI_ABIVERSION содержат сведения о двоичном интерфейсе приложений (application binary interface, ABI) и операционной системе (ОС), для которых скомпилирован бинарный файл. Ненулевое значение EI_OSABI означает, что файл ELF использует расширения, зависящие от ABI или ОС; это может изменить смысл некоторых других полей бинарного файла или указывать на наличие нестандартных разделов. Нулевое значение по умолчанию сообщает, что бинарный файл предназначен для ABI UNIX System V. Байт EI_ABIVERSION задаёт конкретную версию указанного в EI_OSABI интерфейса ABI, на которую рассчитан бинарный файл. Обычно здесь стоит ноль, поскольку при использовании стандартного значения EI_OSABI сведения о версии указывать не требуется.

Массив e_ident любого бинарного файла ELF можно исследовать, просмотрев его заголовок с помощью readelf. Например, в листинге 2-2 приведён вывод для бинарного файла compilation_example из главы 1. К этому выводу мы будем обращаться и при рассмотрении остальных полей исполняемого заголовка.

Листинг 2-2. Исполняемый заголовок, показанный программой readelf

В листинге 2-2 массив e_ident показан в строке Magic ❶. Он начинается со знакомых четырёх магических байтов, за которыми следуют значение 2, обозначающее ELFCLASS64, затем 1 (ELFDATA2LSB) и ещё одна единица (EV_CURRENT). Все остальные байты равны нулю, поскольку EI_OSABI и EI_ABIVERSION имеют стандартные значения, а все байты заполнения также обнулены. Сведения, содержащиеся в некоторых из этих байтов, явно повторены в отдельных строках Class, Data, Version, OS/ABI и ABI Version, отмеченных маркером ❷.

За массивом e_ident следует последовательность многобайтовых целочисленных полей. Первое из них, e_type, задаёт тип бинарного файла. Чаще всего здесь встречаются значения ET_REL, обозначающее перемещаемый объектный файл, ET_EXEC - исполняемый бинарный файл - и ET_DYN - динамическая библиотека, которую также называют файлом разделяемого объекта. В выводе readelf для нашего бинарного файла видно, что перед нами исполняемый файл: Type: EXEC ❸ в листинге 2-2.

Следующее поле, e_machine, задаёт архитектуру, для которой предназначен бинарный файл ❹. В этой книге оно обычно будет иметь значение EM_X86_64, как и в выводе readelf, поскольку работать мы главным образом будем с 64-разрядными бинарными файлами x86. Среди других часто встречающихся значений - EM_386 для 32-разрядной архитектуры x86 и EM_ARM для бинарных файлов ARM.

Поле e_version выполняет ту же роль, что и байт EI_VERSION в массиве e_ident: оно задаёт версию спецификации ELF, использованную при создании бинарного файла. Поскольку ширина поля составляет 32 бита, можно предположить, что допустимых значений множество, однако на деле разрешено только значение 1 (EV_CURRENT), обозначающее первую версию спецификации ❺.

Поле e_entry задаёт точку входа бинарного файла - виртуальный адрес, с которого должно начинаться исполнение; см. также раздел 1.4. В нашем примере исполнение начинается по адресу 0x400430, отмеченному ❻ в выводе readelf из листинга 2-2. Именно сюда интерпретатор, обычно ld-linux.so, передаст управление после завершения загрузки бинарного файла в виртуальную память. Точка входа также служит удобной отправной точкой для рекурсивного дизассемблирования, которое рассматривается в главе 6.

Как показано на рис. 2-1, бинарные файлы ELF, помимо прочего, содержат таблицы программных заголовков и заголовков разделов. К назначению этих типов заголовков мы вернёмся после рассмотрения исполняемого заголовка, однако уже сейчас можно открыть один факт: таблицы программных заголовков и заголовков разделов не обязаны располагаться по какому-либо определённому смещению внутри бинарного файла. Единственная структура данных с фиксированным местоположением в бинарном файле ELF - исполняемый заголовок, который всегда находится в начале.

Как же узнать, где искать программные заголовки и заголовки разделов? Для этого в исполняемом заголовке имеются два специальных поля, e_phoff и e_shoff, содержащие файловые смещения начала таблиц программных заголовков и заголовков разделов. В нашем бинарном файле эти смещения равны соответственно 64 и 6632 байтам; это две строки у маркера ❼ в листинге 2-2. Нулевое смещение может означать, что таблица программных заголовков или заголовков разделов в файле отсутствует. Важно понимать, что данные поля содержат файловые смещения - количество байтов, которое нужно отсчитать от начала файла, чтобы добраться до заголовков. Иными словами, в отличие от рассмотренного выше поля e_entry, e_phoff и e_shoff не являются виртуальными адресами.

В поле e_flags предусмотрено место для флагов, зависящих от архитектуры, под которую скомпилирован бинарный файл. Например, в бинарных файлах ARM, предназначенных для встраиваемых платформ, в e_flags могут устанавливаться специфичные для ARM флаги с дополнительными сведениями об интерфейсе, ожидаемом от встраиваемой операционной системы: соглашениях о формате файлов, организации стека и так далее. В бинарных файлах x86 поле e_flags обычно равно нулю и потому не представляет интереса.

Поле e_ehsize задаёт размер исполняемого заголовка в байтах. Для 64-разрядных бинарных файлов x86 он всегда равен 64 байтам, как видно из вывода readelf, а для 32-разрядных бинарных файлов x86 составляет 52 байта; см. маркер ❽ в листинге 2-2.

Теперь вы знаете, что поля e_phoff и e_shoff указывают файловые смещения начала таблиц программных заголовков и заголовков разделов. Но чтобы компоновщик, загрузчик или другая программа, работающая с бинарным файлом ELF, действительно могла пройти по этим таблицам, нужны дополнительные сведения. В частности, необходимо знать размер отдельных программных заголовков и заголовков разделов в таблицах, а также количество заголовков в каждой таблице. Для таблицы программных заголовков эти сведения находятся в полях e_phentsize и e_phnum, а для таблицы заголовков разделов - в e_shentsize и e_shnum. В бинарном файле из листинга 2-2 имеется девять программных заголовков по 56 байт и 31 заголовок раздела по 64 байта ❾.

Поле e_shstrndx содержит индекс в таблице заголовков разделов, соответствующий заголовку специального раздела таблицы строк .shstrtab. Это особый раздел с таблицей ASCII-строк, завершающихся нулевым байтом, в которых хранятся имена всех разделов бинарного файла. Такие средства обработки ELF, как readelf, используют его для правильного отображения имён разделов. Раздел .shstrtab, как и другие разделы, будет описан далее в этой главе.

В нашем бинарном файле из листинга 2-2 заголовок раздела .shstrtab имеет индекс 28 ❿. Содержимое .shstrtab можно просмотреть в виде шестнадцатеричного дампа с помощью readelf, как показано в листинге 2-3.

Листинг 2-3. Раздел .shstrtab, показанный программой readelf

В правой части листинга 2-3 у маркера ❶ видны содержащиеся в таблице строк имена разделов, например .symtab, .strtab и другие. Теперь, когда вы познакомились с форматом и содержимым исполняемого заголовка ELF, перейдём к заголовкам разделов.

Код и данные бинарного файла ELF логически делятся на непрерывные непересекающиеся фрагменты, называемые разделами. У разделов нет заранее установленной структуры: строение каждого зависит от содержимого. Более того, у раздела вообще может не быть какой-либо определённой структуры; зачастую это просто неструктурированная масса кода или данных. Каждый раздел описывается заголовком раздела, в котором указаны свойства раздела и местоположение относящихся к нему байтов. Заголовки всех разделов бинарного файла находятся в таблице заголовков разделов.

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

Поскольку разделы предназначены исключительно для представления файла компоновщику, таблица заголовков разделов является необязательной частью формата ELF. Файлы ELF, которым не требуется компоновка, могут не иметь такой таблицы. При её отсутствии поле e_shoff в исполняемом заголовке равно нулю.

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

Сначала рассмотрим формат заголовков разделов, а затем перейдём к содержимому разделов. В листинге 2-4 показан формат заголовка раздела ELF, определённый в /usr/include/elf.h.

Листинг 2-4. Определение Elf64_Shdr в /usr/include/elf.h

Как видно из листинга 2-4, первое поле заголовка раздела называется sh_name. Если оно задано, то содержит индекс в таблице строк. Нулевой индекс означает, что у раздела нет имени.

В разделе 2.1 мы рассмотрели специальный раздел .shstrtab, содержащий массив строк, завершающихся NULL, - по одной для каждого имени раздела. Индекс заголовка раздела, описывающего эту таблицу строк, находится в поле e_shstrndx исполняемого заголовка. Благодаря этому такие средства, как readelf, могут легко найти .shstrtab, а затем использовать поле sh_name каждого заголовка раздела, включая заголовок самого .shstrtab, как индекс строки с именем соответствующего раздела. Это позволяет специалисту без труда определить назначение каждого раздела.^[2]

Каждый раздел имеет тип, заданный целочисленным полем sh_type, который сообщает компоновщику некоторые сведения о структуре содержимого раздела. На рис. 2-1 показаны наиболее важные для нас типы разделов. Рассмотрим каждый из них по очереди.

Разделы типа SHT_PROGBITS содержат данные программы, например машинные инструкции или константы. У них нет особой структуры, которую компоновщику требовалось бы разбирать.

Существуют также специальные типы разделов для таблиц символов (SHT_SYMTAB для статических таблиц и SHT_DYNSYM для таблиц, используемых динамическим компоновщиком) и таблиц строк (SHT_STRTAB). Таблицы символов содержат символы в строго определённом формате - если вам интересно, он задан структурой Elf64_Sym в elf.h, - которая, помимо прочего, описывает символьные имена и типы для конкретных файловых смещений или адресов.

Например, в бинарном файле без символов статическая таблица символов может отсутствовать. Как уже говорилось, таблица строк представляет собой простой массив строк, завершающихся NULL; по принятому соглашению первый байт таблицы строк также равен NULL.

Разделы типов SHT_REL и SHT_RELA особенно важны для компоновщика, поскольку содержат записи перемещения в строго определённом формате - структуры Elf64_Rel и Elf64_Rela в elf.h, - которые компоновщик может разобрать, чтобы выполнить необходимые перемещения в других разделах. Каждая запись сообщает компоновщику о конкретном месте бинарного файла, где требуется перемещение, и о символе, относительно которого его следует разрешить. Сам процесс перемещения довольно сложен, и сейчас мы не станем углубляться в подробности. Главное, что нужно запомнить: разделы SHT_REL и SHT_RELA используются для статической компоновки.

Разделы типа SHT_DYNAMIC содержат сведения, необходимые для динамической компоновки. Они оформлены в виде структур Elf64_Dyn, определённых в elf.h.

Флаги раздела, заданные в поле sh_flags, содержат дополнительные сведения о разделе. Для нас важнее всего флаги SHF_WRITE, SHF_ALLOC и SHF_EXECINSTR.

Флаг SHF_WRITE означает, что во время исполнения раздел доступен для записи. Благодаря ему легко отличить разделы со статическими данными, например константами, от разделов с переменными. Флаг SHF_ALLOC указывает, что при исполнении бинарного файла содержимое раздела следует загрузить в виртуальную память, хотя фактически загрузка выполняется через представление бинарного файла в виде сегментов, а не разделов. Наконец, SHF_EXECINSTR сообщает, что раздел содержит исполняемые инструкции; это полезно знать при дизассемблировании бинарного файла.

Поля sh_addr, sh_offset и sh_size описывают соответственно виртуальный адрес раздела, его файловое смещение в байтах от начала файла и размер в байтах. На первый взгляд поле наподобие sh_addr, описывающее виртуальный адрес раздела, кажется здесь неуместным: ведь я говорил, что разделы используются только при компоновке, а не при создании и исполнении процесса. Это по-прежнему верно, однако для выполнения перемещений компоновщику иногда требуется знать, по каким адресам во время исполнения окажутся конкретные фрагменты кода и данных. Эти сведения и предоставляет sh_addr. У разделов, которые не должны загружаться в виртуальную память при подготовке процесса, значение sh_addr равно нулю.

Иногда компоновщику необходимо знать о связях между разделами. Например, с разделом SHT_SYMTAB, SHT_DYNSYM или SHT_DYNAMIC связана таблица строк, содержащая символьные имена соответствующих символов.

Подобным образом разделы перемещений типов SHT_REL и SHT_RELA связаны с таблицей символов, описывающей участвующие в перемещениях символы. Поле sh_link явно задаёт такие связи, указывая индекс связанного раздела в таблице заголовков разделов.

Поле sh_info содержит дополнительные сведения о разделе, смысл которых зависит от его типа. Например, для раздела перемещений sh_info задаёт индекс раздела, к которому следует применить перемещения.

Для эффективного доступа к памяти некоторые разделы требуется выравнивать в памяти определённым образом. Например, раздел может загружаться только по адресу, кратному 8 или 16 байтам. Требования к выравниванию задаются в поле sh_addralign. Если оно равно 16, базовый адрес раздела, выбранный компоновщиком, должен быть кратен 16. Значения 0 и 1 зарезервированы для обозначения отсутствия особых требований к выравниванию.

Некоторые разделы, например таблицы символов или перемещений, содержат таблицу строго определённых структур данных, таких как Elf64_Sym или Elf64_Rela. Для таких разделов поле sh_entsize задаёт размер каждого элемента таблицы в байтах. Если поле не используется, оно равно нулю.

Теперь, когда вы знакомы со структурой заголовка раздела, рассмотрим некоторые конкретные разделы бинарного файла ELF. Типичные файлы ELF в системе GNU/Linux организованы в последовательность стандартных или фактически стандартных разделов. В листинге 2-5 приведён вывод readelf со списком разделов нашего бинарного файла.

Листинг 2-5. Список разделов бинарного файла из примера

Для каждого раздела readelf показывает основные сведения: индекс в таблице заголовков разделов, имя и тип. Кроме того, видны виртуальный адрес, файловое смещение и размер раздела в байтах. Для разделов, содержащих таблицу, например таблицу символов или перемещений, имеется также столбец с размером каждого элемента. Наконец, readelf показывает соответствующие флаги каждого раздела, индекс связанного раздела при его наличии, дополнительные сведения, зависящие от типа раздела, и требования к выравниванию.

Как видите, вывод точно соответствует структуре заголовка раздела. Стандарт ELF требует, чтобы первый элемент таблицы заголовков разделов каждого файла ELF был пустым элементом NULL. Его тип - SHT_NULL ❶, а все поля заголовка раздела обнулены. Это означает, что у него нет имени и связанных с ним байтов, то есть это заголовок раздела без самого раздела. Теперь рассмотрим подробнее содержимое и назначение наиболее интересных из оставшихся разделов, которые, вероятно, встретятся вам при бинарном анализе.^[3]

Раздел .init, имеющий индекс 11 в листинге 2-5, содержит исполняемый код, который выполняет задачи инициализации и должен запускаться до любого другого кода бинарного файла. О наличии исполняемого кода свидетельствует флаг SHF_EXECINSTR, который readelf обозначает буквой X в столбце Flg ❷. Система исполняет код раздела .init до передачи управления основной точке входа бинарного файла. Поэтому, если вы знакомы с объектно-ориентированным программированием, этот раздел можно представить как конструктор. Раздел .fini, имеющий индекс 15, аналогичен .init, но выполняется после завершения основной программы и фактически играет роль своеобразного деструктора.

В разделе .text с индексом 14 находится основной код программы, поэтому при бинарном анализе или обратной разработке именно он часто будет главным объектом внимания. Как видно из вывода readelf в листинге 2-5, раздел .text имеет тип SHT_PROGBITS ❸, поскольку содержит код, определённый пользователем. Обратите внимание и на флаги: раздел исполняемый, но не доступный для записи ❹. Как правило, исполняемые разделы почти никогда не должны быть доступны для записи, и наоборот, поскольку иначе злоумышленник, использующий уязвимость, смог бы легко изменить поведение программы, непосредственно перезаписав код.

Помимо кода приложения, скомпилированного из исходного текста программы, раздел .text типичного бинарного файла, созданного gcc, содержит несколько стандартных функций, выполняющих задачи инициализации и завершения, например _start, register_tm_clones и frame_dummy. Пока самой важной из них будет функция _start. Из листинга 2-6 станет понятно почему. Не беспокойтесь, если не понимаете весь приведённый ассемблерный код: далее я укажу на главное.

Листинг 2-6. Дизассемблирование стандартной функции _start

Когда вы пишете программу на Си, в ней всегда присутствует функция main, с которой начинается программа. Но если исследовать точку входа бинарного файла, окажется, что она указывает не на main по адресу 0x400526 ❹, а на адрес 0x400430 - начало _start ❶.

Как же исполнение в итоге достигает main? При внимательном рассмотрении видно, что по адресу 0x40044d в _start находится инструкция, помещающая адрес main в регистр rdi ❷ - один из регистров, используемых на платформе x64 для передачи параметров при вызове функций. Затем _start вызывает функцию __libc_start_main ❸. Она находится в разделе .plt, а значит, входит в разделяемую библиотеку; подробнее это рассматривается в разделе 2.3.4.

Как следует из имени, функция __libc_start_main в конечном счёте вызывает адрес main, начиная исполнение кода, определённого пользователем.

Поскольку разделы кода обычно недоступны для записи, переменные хранятся в одном или нескольких специальных записываемых разделах. Постоянные данные, как правило, тоже помещаются в отдельный раздел, чтобы бинарный файл оставался аккуратно организованным, хотя иногда компиляторы всё же размещают постоянные данные в разделах кода. Современные версии gcc и clang обычно не смешивают код с данными, но Visual Studio иногда это делает. Как вы увидите в главе 6, такое смешение способно существенно усложнить дизассемблирование, поскольку не всегда ясно, какие байты представляют инструкции, а какие - данные.

Раздел .rodata, название которого означает «данные только для чтения» (read-only data), предназначен для хранения постоянных значений. Поскольку это константы, .rodata недоступен для записи. Исходные значения инициализированных переменных находятся в разделе .data, помеченном как доступный для записи, поскольку значения переменных могут изменяться во время исполнения. Наконец, раздел .bss резервирует место для неинициализированных переменных. Исторически его имя расшифровывается как «блок, начинающийся с символа» (block started by symbol) и связано с резервированием блоков памяти для символьных переменных.

В отличие от .rodata и .data, имеющих тип SHT_PROGBITS, раздел .bss относится к типу SHT_NOBITS. Причина в том, что .bss не занимает байтов в бинарном файле на диске: это всего лишь указание выделить при подготовке среды исполнения блок памяти подходящего размера для неинициализированных переменных. Обычно переменные в .bss инициализируются нулями, а сам раздел помечен как доступный для записи.

Как видно из дампа заголовков разделов нашего бинарного файла, полученного readelf, в нём имеется несколько разделов с именами вида .rela.*. Они относятся к типу SHT_RELA, то есть содержат сведения, которые компоновщик использует для перемещений.

По существу, каждый раздел типа SHT_RELA представляет собой таблицу записей перемещения. Каждая запись подробно описывает конкретный адрес, по которому нужно применить перемещение, а также способ вычисления значения, подставляемого по этому адресу. В листинге 2-8 показано содержимое разделов перемещений нашего бинарного файла. Как вы увидите, в нём остались только динамические перемещения, которые должен выполнить динамический компоновщик: все статические перемещения, существовавшие в объектном файле, уже разрешены при статической компоновке. Разумеется, в настоящем бинарном файле, в отличие от этого простого примера, динамических перемещений было бы гораздо больше.

Листинг 2-8. Разделы перемещений бинарного файла из примера

Здесь представлены два типа перемещений: R_X86_64_GLOB_DAT и R_X86_64_JUMP_SLO. В реальных файлах вам может встретиться множество других типов, однако эти относятся к наиболее распространённым и важным. Общая черта всех типов перемещений - наличие смещения, по которому применяется перемещение. Способ вычисления значения, подставляемого по этому смещению, зависит от типа перемещения и иногда бывает довольно сложным. Все подробности приведены в спецификации ELF, но для обычных задач бинарного анализа знать их не требуется.

Первое перемещение в листинге 2-8, имеющее тип R_X86_64_GLOB_DAT, указывает смещение в разделе .got ❶. Это можно определить, сравнив смещение с базовым адресом .got из вывода readelf в листинге 2-5. Обычно перемещение данного типа применяется для вычисления адреса символа данных и записи результата по нужному смещению в .got.

Элементы R_X86_64_JUMP_SLO называются слотами перехода ❷ и ❸. Их смещения находятся в разделе .got.plt, и они представляют места для записи адресов библиотечных функций. Если вернуться к дампу PLT нашего бинарного файла в листинге 2-7, можно увидеть, что каждая заглушка PLT обращается к одному из этих слотов, чтобы получить цель косвенного перехода. Адреса слотов перехода, вычисленные как относительные смещения от регистра rip, показаны в правой части вывода листинга 2-7 сразу после символа #.

При загрузке и подготовке бинарного файла ELF к исполнению раздел .dynamic служит для операционной системы и динамического компоновщика своеобразной «дорожной картой». Если вы забыли, как работает загрузка, вернитесь к разделу 1.4.

Раздел .dynamic содержит таблицу структур Elf64_Dyn, определённых в /usr/include/elf.h; их также называют тегами. Существуют разные типы тегов, и с каждым связано некоторое значение. В качестве примера рассмотрим содержимое .dynamic нашего бинарного файла, показанное в листинге 2-9.

Листинг 2-9. Содержимое раздела .dynamic

Как видите, тип каждого тега раздела .dynamic указан во втором столбце вывода. Теги типа DT_NEEDED сообщают динамическому компоновщику о зависимостях исполняемого файла. Например, наш бинарный файл использует функцию puts из разделяемой библиотеки libc.so.6 ❶, поэтому при его исполнении библиотека должна быть загружена. Теги DT_VERNEED ❷ и DT_VERNEEDNUM ❸ задают начальный адрес и количество элементов таблицы зависимостей от версий, в которой указаны ожидаемые версии различных зависимостей исполняемого файла.

Помимо перечисления зависимостей, раздел .dynamic содержит указатели на другие важные сведения, необходимые динамическому компоновщику. В частности, теги типов DT_STRTAB, DT_SYMTAB, DT_PLTGOT и DT_RELA указывают соответственно на динамическую таблицу строк, динамическую таблицу символов, раздел .got.plt и раздел динамических перемещений.

Раздел .init_array содержит массив указателей на функции, используемые в качестве конструкторов. При инициализации бинарного файла, до вызова main, каждая из этих функций вызывается по очереди. Рассмотренный выше раздел .init содержит единственную функцию запуска, выполняющую критически важную инициализацию, без которой исполняемый файл не сможет начать работу. В отличие от него, .init_array является разделом данных и может содержать сколько угодно указателей на функции, в том числе на собственные конструкторы. В исходных файлах на Си функции можно помечать как конструкторы gcc с помощью атрибута __attribute__((constructor)).

В нашем бинарном файле .init_array содержит всего один элемент. Это указатель на ещё одну стандартную функцию инициализации frame_dummy, как видно из вывода objdump в листинге 2-10.

Листинг 2-10. Содержимое раздела .init_array

Первый вызов objdump показывает содержимое .init_array ❶. Как видите, там находится единственный указатель на функцию, представленный выделенными в выводе байтами 00 05 40 00 00 00 00 00 ❷. На языке прямого порядка байтов это всего лишь адрес 0x400500, полученный обращением порядка байтов и удалением ведущих нулей. Второй вызов objdump показывает, что это действительно начальный адрес функции frame_dummy ❸.

Как вы, вероятно, уже догадались, .fini_array аналогичен .init_array, но содержит указатели на деструкторы, а не конструкторы. Указатели в .init_array и .fini_array легко изменить, поэтому эти разделы служат удобными местами для внедрения перехватчиков, добавляющих в бинарный файл код инициализации или завершения и тем самым изменяющих его поведение. Обратите внимание:

бинарные файлы, созданные старыми версиями gcc, могут содержать разделы .ctors и .dtors вместо .init_array и .fini_array.

Как упоминалось при рассмотрении заголовков разделов, .shstrtab представляет собой простой массив завершающихся NULL строк с именами всех разделов бинарного файла. Заголовки разделов обращаются к нему по индексам, благодаря чему такие средства, как readelf, могут определять имена разделов.

Раздел .symtab содержит таблицу символов - таблицу структур Elf64_Sym, каждая из которых связывает символьное имя с фрагментом кода или данных в другой части бинарного файла, например с функцией или переменной. Сами строки с символьными именами находятся в разделе .strtab, а структуры Elf64_Sym содержат указатели на них. На практике бинарные файлы, встречающиеся при анализе, часто лишены символов, а значит, таблицы .symtab и .strtab из них удалены.

Разделы .dynsym и .dynstr аналогичны .symtab и .strtab, но содержат символы и строки, необходимые для динамической, а не статической компоновки. Поскольку эти сведения требуются при динамической компоновке, удалить их невозможно.

Обратите внимание: статическая таблица символов имеет тип раздела SHT_SYMTAB, а динамическая - SHT_DYNSYM. Благодаря этому такие средства, как strip, легко определяют, какие таблицы символов можно безопасно удалить из бинарного файла, а какие нельзя.

Таблица программных заголовков представляет бинарный файл в виде сегментов, тогда как таблица заголовков разделов даёт представление в виде разделов. Рассмотренное ранее представление бинарного файла ELF в виде разделов предназначено только для статической компоновки. Представление в виде сегментов, к которому мы теперь переходим, используется операционной системой и динамическим компоновщиком при загрузке ELF в процесс для исполнения: с его помощью они находят нужный код и данные и решают, что следует загрузить в виртуальную память.

Сегмент ELF охватывает ноль или более разделов, фактически объединяя их в единый фрагмент. Поскольку сегменты дают представление файла во время исполнения, они нужны только исполняемым файлам ELF, но не таким неисполняемым файлам, как перемещаемые объекты. Таблица программных заголовков кодирует это представление с помощью программных заголовков типа Elf64_Phdr. Каждый из них содержит поля, показанные в листинге 2-11.

Листинг 2-11. Определение Elf64_Phdr в /usr/include/elf.h

Каждое из этих полей описано в следующих разделах. В листинге 2-12 показана таблица программных заголовков нашего бинарного файла в представлении readelf.

Листинг 2-12. Типичная таблица программных заголовков, показанная программой readelf

Обратите внимание на соответствие разделов сегментам в нижней части вывода readelf: оно наглядно показывает, что сегменты - это просто группы объединённых разделов ❶. Такое соответствие характерно для большинства бинарных файлов ELF, которые вам встретятся. В оставшейся части этого раздела мы рассмотрим поля программного заголовка из листинга 2-11.

Поле p_type определяет тип сегмента. К его важным значениям относятся PT_LOAD, PT_DYNAMIC и PT_INTERP.

Сегменты типа PT_LOAD, как следует из названия, предназначены для загрузки в память при подготовке процесса. Размер загружаемого фрагмента и адрес его размещения задаются остальными полями программного заголовка. Как видно из вывода readelf, обычно существует не менее двух сегментов PT_LOAD: один охватывает разделы, недоступные для записи, а второй содержит записываемые разделы данных.

Сегмент PT_INTERP содержит раздел .interp, в котором указано имя интерпретатора для загрузки бинарного файла. В свою очередь, сегмент PT_DYNAMIC включает раздел .dynamic, сообщающий интерпретатору, как разобрать бинарный файл и подготовить его к исполнению. Стоит также упомянуть сегмент PT_PHDR, охватывающий таблицу программных заголовков.

Флаги задают права доступа к сегменту во время исполнения. Существуют три важных флага: PF_X, PF_W и PF_R. Флаг PF_X означает, что сегмент исполняемый, и устанавливается для сегментов кода; в столбце Flg листинга 2-12 программа readelf отображает его буквой E, а не X. Флаг PF_W указывает, что сегмент доступен для записи; обычно он устанавливается только для записываемых сегментов данных и никогда - для сегментов кода. Наконец, PF_R обозначает доступность сегмента для чтения, что обычно верно как для сегментов кода, так и для сегментов данных.

Поля p_offset, p_vaddr и p_filesz из листинга 2-11 аналогичны полям sh_offset, sh_addr и sh_size заголовка раздела. Они задают соответственно файловое смещение начала сегмента, виртуальный адрес его загрузки и размер сегмента в файле. Для загружаемых сегментов значения p_vaddr и p_offset должны быть сравнимы по модулю размера страницы, который обычно составляет 4096 байт.

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

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

Поле p_align аналогично sh_addralign в заголовке раздела. Оно задаёт необходимое выравнивание сегмента в памяти в байтах. Как и для sh_addralign, значение 0 или 1 означает отсутствие особых требований к выравниванию. Если p_align не равно 0 или 1, его значение должно быть степенью двойки, а p_vaddr и p_offset - сравнимы по модулю p_align.

С помощью шестнадцатеричного просмотрщика, например xxd, отобразите байты бинарного файла ELF в шестнадцатеричном виде. Например, команда xxd /bin/ls | head -n 30 показывает первые 30 строк байтов программы /bin/ls. Сможете ли вы определить байты, представляющие заголовок ELF? Попробуйте найти в выводе xxd все поля заголовка ELF и проверить, кажутся ли вам осмысленными их значения.

С помощью readelf просмотрите разделы и сегменты бинарного файла ELF. Как разделы отображаются в сегменты? Нарисуйте представление бинарного файла на диске и в памяти. Каковы основные различия между ними?

С помощью readelf дизассемблируйте два бинарных файла: один, созданный из исходного текста на Си, и другой, полученный из исходного текста на C++. Чем они различаются?

С помощью objdump дизассемблируйте раздел PLT бинарного файла ELF. Какие элементы GOT используют заглушки PLT? Теперь просмотрите содержимое этих элементов GOT, снова воспользовавшись objdump, и проанализируйте их связь с PLT.

Заголовки PE можно считать аналогом исполняемого заголовка ELF, но в PE «исполняемый заголовок» разделён на три части: 32-разрядную сигнатуру, файловый заголовок PE и необязательный заголовок PE. В WinNT.h имеется структура IMAGE_NT_HEADERS64, охватывающая все три компонента. Можно сказать, что IMAGE_NT_HEADERS64 в целом представляет версию исполняемого заголовка для PE. Однако на практике сигнатуру, файловый и необязательный заголовки считают отдельными сущностями.

Рис. 3-1. Общее устройство бинарного файла PE32+

В следующих разделах мы рассмотрим каждый компонент заголовка. Чтобы увидеть все элементы в действии, обратимся к hello.exe - версии программы compilation_example из главы 1 в формате PE. В листинге 3-1 приведён дамп важнейших элементов заголовка и массива DataDirectory файла hello.exe. Назначение DataDirectory будет объяснено чуть позже.

Листинг 3-1. Пример дампа заголовков PE и DataDirectory

Сигнатура PE - это строка из ASCII-символов PE, за которыми следуют два символа NULL. Она аналогична магическим байтам в поле e_ident исполняемого заголовка ELF.

Файловый заголовок описывает общие свойства файла. Его важнейшие поля - Machine, NumberOfSections, SizeOfOptionalHeader и Characteristics. Два поля, описывающие таблицу символов, устарели: файлам PE больше не следует содержать встроенные символы и отладочные сведения. Вместо этого символы при необходимости записываются в отдельный отладочный файл.

Подобно e_machine в ELF, поле Machine описывает архитектуру компьютера, для которого предназначен файл PE. В нашем случае это x86-64, определённая константой 0x8664 ❶. Поле NumberOfSections содержит число элементов таблицы заголовков разделов, а SizeOfOptionalHeader - размер в байтах необязательного заголовка, следующего за файловым. Поле Characteristics содержит флаги, описывающие, среди прочего, порядок байтов бинарного файла, принадлежность к DLL и наличие или отсутствие символов. Как показано в выводе objdump, флаги Characteristics нашего файла отмечают его как исполняемый файл с поддержкой большого адресного пространства ❷.

Вопреки названию, необязательный заголовок PE для исполняемых файлов на самом деле обязателен, хотя в объектных файлах он может отсутствовать. Скорее всего, он встретится вам в каждом исполняемом файле PE. Заголовок содержит множество полей; здесь мы рассмотрим самые важные.

Первым идёт 16-разрядное магическое значение, равное 0x020b для 64-разрядных файлов PE ❸. Несколько полей задают старшие и младшие номера версии компоновщика, создавшего бинарный файл, а также минимальную версию операционной системы, необходимую для его запуска. Поле ImageBase ❻ описывает адрес загрузки бинарного файла: файлы PE рассчитаны на определённый виртуальный адрес. Другие поля-указатели содержат относительные виртуальные адреса (relative virtual addresses, RVA), которые требуется прибавить к базовому адресу, чтобы получить виртуальный. Например, поле BaseOfCode ❺ задаёт базовый адрес разделов кода как RVA. Следовательно, их базовый виртуальный адрес вычисляется как ImageBase + BaseOfCode. Как вы, вероятно, догадались, поле AddressOfEntryPoint ❹ содержит адрес точки входа бинарного файла, также заданный как RVA.

Пожалуй, наименее очевидное поле необязательного заголовка - массив DataDirectory ❼. Он содержит элементы типа IMAGE_DATA_DIRECTORY, в каждом из которых находятся RVA и размер. Каждый элемент массива описывает начальный RVA и размер важной части бинарного файла; точное толкование зависит от индекса элемента. Самые важные из них: элемент с индексом 0, описывающий базовый RVA и размер каталога экспорта, то есть таблицы экспортируемых функций; элемент с индексом 1, описывающий каталог импорта - таблицу импортируемых функций; и элемент с индексом 5, описывающий таблицу перемещений. К таблицам экспорта и импорта мы вернёмся при рассмотрении разделов PE. По существу, DataDirectory служит загрузчику сокращённым путём, позволяя быстро находить определённые части данных без последовательного обхода таблицы заголовков разделов.

Многие разделы файлов PE непосредственно соответствуют разделам ELF и зачастую даже имеют почти такие же имена. В листинге 3-2 приведён обзор разделов hello.exe.

Листинг 3-2. Обзор разделов бинарного файла PE из примера

Как видно из листинга 3-2, здесь имеется раздел .text с кодом, раздел .rdata с данными только для чтения, примерно соответствующий .rodata в ELF, и раздел .data с данными, доступными для чтения и записи. Обычно присутствует и .bss для данных, инициализированных нулями, хотя в нашем простом бинарном файле его нет. Также имеется раздел .reloc со сведениями о перемещениях. Важно отметить, что компиляторы PE, например Visual Studio, иногда помещают данные только для чтения в раздел .text вперемешку с кодом, а не в .rdata. Это способно вызвать проблемы при дизассемблировании, поскольку постоянные данные можно случайно принять за инструкции.

Важнейшие разделы PE, не имеющие прямого аналога в ELF, - .edata и .idata, содержащие соответственно таблицы экспортируемых и импортируемых функций. На них ссылаются элементы каталогов экспорта и импорта массива DataDirectory. Раздел .idata задаёт символы - функции и данные, - которые бинарный файл импортирует из разделяемых библиотек, или DLL в терминологии Windows. Раздел .edata перечисляет экспортируемые бинарным файлом символы и их адреса. Поэтому для разрешения ссылок на внешние символы загрузчик должен сопоставить требуемые импорты с таблицей экспорта предоставляющей их DLL.

На практике отдельных разделов .idata и .edata может не оказаться. Их нет даже в бинарном файле из листинга 3-2! В таком случае они обычно объединены с .rdata, но содержимое и принцип работы остаются прежними.

При разрешении зависимостей загрузчик записывает полученные адреса в таблицу адресов импорта (Import Address Table, IAT). Как и глобальная таблица смещений ELF, IAT представляет собой таблицу разрешённых указателей с одним слотом для каждого указателя. IAT также входит в раздел .idata и первоначально содержит указатели на имена или идентификационные номера импортируемых символов. Затем динамический загрузчик заменяет их указателями на фактические импортированные функции или переменные. Вызов библиотечной функции реализуется как вызов её переходника (thunk), который представляет собой всего лишь косвенный переход через соответствующий функции слот IAT. В листинге 3-3 показано, как такие переходники выглядят на практике.

Листинг 3-3. Примеры переходников PE

Переходники часто сгруппированы, как в листинге 3-3. Обратите внимание: целевые адреса переходов ❶-❺ находятся в каталоге импорта, расположенном в разделе .rdata, который начинается по адресу 0x140002000. Это слоты перехода IAT.

При дизассемблировании файлов PE вы можете заметить множество инструкций int3. Visual Studio использует их как заполнение вместо инструкций nop, применяемых gcc, чтобы выровнять функции и блоки кода в памяти для эффективного доступа.^[2] Обычно отладчики используют инструкцию int3 для установки точек останова: она передаёт управление отладчику либо приводит к сбою программы, если отладчика нет. Для кода заполнения это допустимо, поскольку такие инструкции не должны исполняться.

Как и для бинарных файлов ELF в главе 2, с помощью шестнадцатеричного просмотрщика наподобие xxd отобразите байты бинарного файла PE. Можно использовать прежнюю команду xxd program.exe | head -n 30, где program.exe - ваш бинарный файл PE. Сможете ли вы найти байты заголовка PE и понять значения всех его полей?

С помощью readelf просмотрите содержимое бинарного файла PE. Затем изобразите его представление на диске и в памяти. Каковы основные различия?

С помощью objdump дизассемблируйте бинарные файлы ELF и PE. Используются ли в них разные конструкции кода и данных? Можете ли вы найти шаблоны кода или данных, характерные соответственно для применяемых вами компиляторов ELF и PE?

Прежде чем реализовывать загрузчик, спроектируем удобный интерфейс. В конце концов, его назначение - максимально упростить загрузку бинарных файлов для всех средств анализа, которые будут создаваться далее в книге. Интерфейс предназначен для программ статического анализа. Не путайте его с динамическим загрузчиком операционной системы, задача которого - загружать бинарные файлы в память для исполнения, как обсуждалось в главе 1.

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

В листинге 4-1 приведён заголовочный файл C++, описывающий основной API загрузчика. Обратите внимание: на виртуальной машине он находится в каталоге inc, а не в chapter4 вместе с остальным кодом этой главы. Причина в том, что загрузчик совместно используется во всех главах книги.

Листинг 4-1. inc/loader.h

Как видите, API предоставляет несколько классов, представляющих разные компоненты бинарного файла. Корневой класс Binary абстрагирует весь бинарный файл ❸. Помимо прочего, он содержит вектор объектов Section и вектор объектов Symbol. Классы Section ❷ и Symbol ❶ представляют соответственно разделы и символы бинарного файла.

В основе всего API лежат лишь две функции. Первая, load_binary ❹, принимает имя загружаемого бинарного файла (fname), указатель на объект Binary, в котором будет храниться загруженный файл (bin), и описание типа бинарного файла (type). Она загружает запрошенный файл в параметр bin и возвращает целое значение 0 при успешной загрузке либо значение меньше нуля при ошибке. Вторая функция, unload_binary ❺, принимает указатель на ранее загруженный объект Binary и выгружает его.

Теперь, когда вы знакомы с API загрузчика, рассмотрим его реализацию. Начнём с класса Binary.

Как следует из названия, класс Binary абстрагирует полный бинарный файл. В нём хранятся имя файла, тип, архитектура, разрядность, адрес точки входа, разделы и символы. Тип имеет двойное представление: член type содержит числовой идентификатор, а type_str - строковое название типа бинарного файла. Аналогичное двойное представление используется для архитектуры.

Допустимые типы бинарных файлов перечислены в enum BinaryType: ELF (BIN_TYPE_ELF) и PE (BIN_TYPE_PE). Кроме того, существует значение BIN_TYPE_AUTO, которое можно передать функции load_binary, чтобы она сама определила, является файл ELF или PE. Допустимые архитектуры аналогичным образом перечислены в enum BinaryArch. Для наших целей существует только архитектура ARCH_X86, охватывающая и x86, и x86-64. Различие между ними задаёт член bits класса Binary: 32 бита для x86 и 64 бита для x86-64.

Обычно доступ к разделам и символам класса Binary осуществляется перебором векторов sections и symbols. Поскольку бинарный анализ часто сосредоточен на коде в разделе .text, предусмотрена также вспомогательная функция get_text_section, которая, как следует из имени, автоматически находит и возвращает этот раздел.

Разделы представлены объектами типа Section. Класс Section является простой оболочкой над основными свойствами раздела: именем, типом, начальным адресом - членом vma, - размером в байтах и содержащимися в разделе необработанными байтами. Для удобства имеется и обратный указатель на объект Binary, которому принадлежит Section. Тип раздела задаётся значением enum SectionType, указывающим, содержит раздел код (SEC_TYPE_CODE) или данные (SEC_TYPE_DATA).

Во время анализа часто требуется выяснить, к какому разделу относится конкретная инструкция или фрагмент данных. Поэтому у класса Section есть функция contains, которая принимает адрес кода или данных и возвращает bool, сообщающий, входит ли адрес в раздел.

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

Загрузчик представляет символы классом Symbol. Он содержит тип символа в виде enum SymbolType, единственным допустимым значением которого является SYM_TYPE_FUNC, а также символьное имя и начальный адрес описываемой символом функции.

Теперь, когда у загрузчика есть чётко определённый интерфейс, реализуем его! Именно здесь в дело вступает libbfd. Полный код загрузчика довольно велик, поэтому я разделю его на фрагменты и рассмотрю по очереди. В следующем коде функции API libbfd легко узнать по префиксу bfd_; есть также несколько функций с суффиксом _bfd, но они определены самим загрузчиком.

Прежде всего, разумеется, нужно подключить все необходимые заголовочные файлы. Я не стану перечислять стандартные заголовки Си и C++, используемые загрузчиком, поскольку они здесь не представляют интереса; при желании их можно посмотреть в исходном файле загрузчика на виртуальной машине. Важно другое: любая программа, использующая libbfd, должна подключать bfd.h, как в листинге 4-2, и компоноваться с libbfd посредством параметра компоновщика -lbfd. Помимо bfd.h, загрузчик подключает заголовочный файл с созданным в предыдущем разделе интерфейсом.

Листинг 4-2. inc/loader.cc

Теперь можно перейти к следующим логичным частям кода - load_binary и unload_binary, двум входным функциям интерфейса загрузчика. Их реализация показана в листинге 4-3.

Листинг 4-3. inc/loader.cc (продолжение)

Задача load_binary ❶ - разобрать бинарный файл с указанным именем и загрузить его в переданный объект Binary. Процесс довольно утомителен, поэтому load_binary благоразумно поручает работу другой функции, load_binary_bfd ❷. Вскоре мы её рассмотрим.

Сначала разберём unload_binary ❸. Как и во многих других случаях, уничтожить объект Binary гораздо проще, чем создать. Чтобы выгрузить его, загрузчик должен освободить с помощью free все динамически выделенные компоненты Binary. К счастью, их немного: динамически, посредством malloc, выделяется лишь член bytes каждого Section. Поэтому unload_binary просто перебирает все объекты Section ❹ и освобождает массив bytes каждого из них ❺. Теперь, когда вы увидели, как выгружается бинарный файл, подробно рассмотрим реализацию загрузки с помощью libbfd.

В предыдущем разделе я обещал показать функцию load_binary_bfd, использующую libbfd для выполнения всей работы по загрузке бинарного файла. Но прежде нужно выполнить ещё одно предварительное условие: чтобы разобрать и загрузить файл, его сначала следует открыть. Код открытия реализован в функции open_bfd, показанной в листинге 4-4.

Листинг 4-4. inc/loader.cc (продолжение)

Функция open_bfd использует libbfd, чтобы определить свойства бинарного файла с именем из параметра fname, открыть его и вернуть дескриптор. До использования libbfd необходимо вызвать bfd_init ❶, инициализирующую внутреннее состояние библиотеки - или, как сказано в документации, «магические внутренние структуры данных». Это требуется сделать только один раз, поэтому open_bfd хранит факт инициализации в статической переменной.

После инициализации libbfd бинарный файл открывается по имени функцией bfd_openr ❷. Второй параметр bfd_openr позволяет задать целевую платформу, то есть тип бинарного файла, но здесь оставлен равным NULL, чтобы libbfd определила его автоматически. bfd_openr возвращает указатель на файловый дескриптор типа bfd - корневую структуру данных libbfd, которую можно передавать всем прочим функциям библиотеки для выполнения операций над бинарным файлом. При ошибке bfd_openr возвращает NULL.

При возникновении любой ошибки её последний тип можно получить вызовом bfd_get_error. Эта функция возвращает объект bfd_error_type, который можно сравнить с предопределёнными идентификаторами ошибок, например bfd_error_no_memory или bfd_error_invalid_target, и выбрать способ обработки. Часто достаточно завершить работу с сообщением. Для этого bfd_errmsg преобразует bfd_error_type в строку с описанием ошибки, которую можно вывести на экран ❸.

Получив дескриптор бинарного файла, следует проверить его формат функцией bfd_check_format ❹. Она принимает дескриптор bfd и значение bfd_format, которое может быть равно bfd_object, bfd_archive или bfd_core. Здесь загрузчик передаёт bfd_object, чтобы проверить, действительно ли открытый файл является объектом - в терминологии libbfd это исполняемый файл, перемещаемый объект или разделяемая библиотека.

Убедившись, что перед ним bfd_object, загрузчик вручную устанавливает состояние ошибки libbfd в bfd_error_no_error ❺. Это обход проблемы некоторых версий libbfd, которые устанавливают ошибку bfd_error_wrong_format до определения формата и оставляют её активной даже тогда, когда формат распознан без проблем.

Наконец, загрузчик проверяет, что бинарный файл имеет известную «разновидность», вызывая bfd_get_flavour ❻. Функция возвращает объект bfd_flavour, который просто указывает вид бинарного файла: ELF, PE и так далее. К допустимым значениям bfd_flavour относятся bfd_target_msdos_flavour, bfd_target_coff_flavour и bfd_target_elf_flavour. Если формат неизвестен или произошла ошибка, bfd_get_flavour возвращает bfd_target_unknown_flavour; тогда open_bfd выводит сообщение об ошибке и возвращает NULL.

Если все проверки пройдены, допустимый бинарный файл успешно открыт и можно загружать его содержимое. Функция open_bfd возвращает открытый дескриптор bfd, чтобы последующие вызовы API libbfd, показанные в следующих листингах, могли его использовать.

Теперь, когда вы увидели код открытия файла, пора рассмотреть функцию load_binary_bfd из листинга 4-5. Напомним: именно она выполняет всю фактическую работу по разбору и загрузке от имени load_binary. Наша цель - поместить все интересующие сведения о бинарном файле в объект Binary, на который указывает параметр bin.

Листинг 4-5. inc/loader.cc (продолжение)

Функция load_binary_bfd начинает с вызова только что реализованной open_bfd, чтобы открыть файл из параметра fname и получить его дескриптор bfd ❶. Затем она задаёт некоторые основные свойства bin: копирует имя бинарного файла, а с помощью libbfd находит и сохраняет адрес точки входа ❷.

Для получения адреса точки входа вызывается bfd_get_start_address, которая просто возвращает значение поля start_address объекта bfd. Начальный адрес имеет тип bfd_vma, на деле представляющий собой обычное 64-разрядное беззнаковое целое.

Затем загрузчик собирает сведения о типе бинарного файла: ELF это, PE или иной неподдерживаемый формат? Информация находится в структуре bfd_target, которой управляет libbfd. Чтобы получить указатель на неё, достаточно обратиться к полю xvec дескриптора bfd. Иными словами, выражение bfd_h->xvec возвращает указатель на структуру bfd_target.

Помимо прочего, структура содержит строку с именем целевого типа. Загрузчик копирует её в объект Binary ❸, затем проверяет поле bfd_h->xvec->flavour оператором switch и устанавливает соответствующий тип Binary ❹. Поддерживаются только ELF и PE, поэтому любое другое значение bfd_h->xvec->flavour приводит к сообщению об ошибке.

Теперь тип ELF или PE известен, но архитектура ещё нет. Для её определения используется функция bfd_get_arch_info из libbfd ❺. Как следует из имени, она возвращает указатель на структуру со сведениями об архитектуре бинарного файла. Эта структура называется bfd_arch_info_type и содержит удобную печатную строку с описанием архитектуры, которую загрузчик копирует в объект Binary ❻.

В bfd_arch_info_type имеется также поле mach ❼ - целочисленный идентификатор архитектуры, в терминологии libbfd называемой машиной. Такое числовое представление позволяет удобно реализовать обработку разных архитектур через switch. Значение bfd_mach_i386_i386 означает 32-разрядный бинарный файл x86, и загрузчик соответствующим образом задаёт поля Binary. Значение bfd_mach_x86_64 обозначает файл x86-64 и приводит к установке других подходящих значений. Любой иной тип не поддерживается и вызывает ошибку.

После разбора основных сведений о типе и архитектуре приходит время настоящей работы: загрузки символов и разделов бинарного файла. Как нетрудно представить, это сложнее уже рассмотренных действий, поэтому загрузчик делегирует работу специализированным функциям, описанным далее. Символы загружают две функции: load_symbols_bfd и load_dynsym_bfd ❽. Как объясняется в следующем разделе, они читают соответственно статическую и динамическую таблицы символов. Для загрузки разделов реализована отдельная функция load_sections_bfd ❾, которую мы рассмотрим в разделе 4.3.4.

После загрузки символов и разделов все интересующие сведения скопированы в собственный объект Binary, а значит, libbfd больше не нужна. Поскольку дескриптор bfd теперь не требуется, загрузчик закрывает его функцией bfd_close ❿. Дескриптор также закрывается, если до окончания загрузки бинарного файла возникает ошибка.

В листинге 4-6 приведён код load_symbols_bfd, загружающей статическую таблицу символов.

Листинг 4-6. inc/loader.cc (продолжение)

В libbfd символы представлены структурой asymbol, что является кратким именем для struct bfd_symbol. Таблица символов, в свою очередь, имеет тип asymbol**, то есть представляет массив указателей на символы. Поэтому задача load_symbols_bfd - заполнить массив указателей asymbol, объявленный у маркера ❶, а затем скопировать интересующие сведения в объект Binary.

Входными параметрами load_symbols_bfd служат дескриптор bfd и объект Binary, куда следует сохранить символьные сведения. Прежде чем загружать указатели на символы, нужно выделить достаточно памяти для их хранения. Функция bfd_get_symtab_upper_bound ❷ сообщает, сколько байтов для этого требуется. Отрицательное количество означает ошибку, а нулевое - отсутствие таблицы символов. Если таблицы нет, load_symbols_bfd просто завершает работу.

Если всё в порядке и таблица символов занимает положительное количество байтов, выделяется достаточное пространство для всех указателей asymbol ❸. После успешного malloc можно наконец поручить libbfd заполнить таблицу символов. Это делает функция bfd_canonicalize_symtab ❹, принимающая дескриптор bfd и заполняемую таблицу asymbol**. Библиотека заполняет её и возвращает число помещённых символов; отрицательное значение снова означает ошибку.

Получив заполненную таблицу, можно перебрать все содержащиеся в ней символы ❺. Напомним, загрузчику нужны только символы функций. Поэтому для каждого символа проверяется флаг BSF_FUNCTION, указывающий на символ функции ❻. Если он установлен, в векторе всех загруженных символов объекта Binary резервируется место для Symbol - собственного класса загрузчика. Новый Symbol помечается как символ функции ❼, затем копируются символьное имя ❽ и адрес ❾. Значение символа функции, то есть её начальный адрес, получается с помощью функции bfd_asymbol_value из libbfd.

Когда все интересующие символы скопированы в объекты Symbol, представление libbfd больше не требуется. Поэтому в конце load_symbols_bfd освобождает память, выделенную для символов libbfd ❿. После этого функция возвращается, и загрузка символов завершается.

Именно так с помощью libbfd загружаются символы из статической таблицы. А как быть с динамической? К счастью, процесс почти полностью совпадает, что видно из листинга 4-7.

Листинг 4-7. inc/loader.cc (продолжение)

Показанная в листинге 4-7 функция загрузки символов из динамической таблицы вполне уместно называется load_dynsym_bfd. Как видите, libbfd представляет статические и динамические символы одной и той же структурой asymbol ❶. Отличий от рассмотренной ранее load_symbols_bfd всего два. Во-первых, количество байтов, которое требуется зарезервировать для указателей на символы, определяется функцией bfd_get_dynamic_symtab_upper_bound ❷ вместо bfd_get_symtab_upper_bound. Во-вторых, таблица заполняется функцией bfd_canonicalize_dynamic_symtab ❸ вместо bfd_canonicalize_symtab. Вот и всё! Остальная процедура загрузки динамических символов совпадает с загрузкой статических.

После символов остаётся выполнить всего одно действие, хотя, возможно, самое важное: загрузить разделы бинарного файла. В листинге 4-8 показана реализация этой возможности функцией load_sections_bfd.

Листинг 4-8. inc/loader.cc (продолжение)

Для хранения разделов libbfd использует структуру asection, также известную как struct bfd_section. Внутри библиотека представляет все разделы связным списком структур asection. Загрузчик резервирует указатель asection*, чтобы перебирать этот список ❶.

Перебор начинается с первого раздела, на который указывает bfd_h->sections, голова списка разделов libbfd, после чего выполняется переход по указателю next каждого объекта asection ❷. Значение NULL у next означает конец списка.

Для каждого раздела загрузчик сначала проверяет, нужно ли его вообще загружать. Поскольку он читает только разделы кода и данных, сначала с помощью bfd_get_section_flags получает флаги раздела ❸ и проверяет наличие SEC_CODE или SEC_DATA ❹. Если нет ни одного из них, раздел пропускается. В противном случае загрузчик задаёт тип соответствующего объекта Section и продолжает загрузку.

Помимо типа загрузчик копирует виртуальный адрес, размер в байтах, имя и необработанные байты каждого раздела кода или данных. Виртуальный базовый адрес раздела libbfd возвращает функция bfd_section_vma ❺. Аналогично, размер и имя раздела возвращают bfd_section_size ❻ и bfd_section_name ❼. У раздела может не быть имени, и тогда bfd_section_name вернёт NULL.

Теперь загрузчик копирует фактическое содержимое раздела в объект Section. Для этого он добавляет новый Section в Binary ❽ и копирует все только что прочитанные поля, после чего выделяет в члене bytes объекта Section достаточно памяти для всех байтов раздела ❾. Если malloc завершается успешно, функция bfd_get_section_contents копирует все байты из объекта раздела libbfd в Section ❿. Она принимает дескриптор bfd, указатель на нужный объект asection, целевой массив для содержимого раздела, начальное смещение копирования и количество копируемых байтов. Чтобы скопировать весь раздел, начальное смещение задаётся равным 0, а количество байтов - размеру раздела. При успешном копировании bfd_get_section_contents возвращает true, иначе - false. Если всё прошло успешно, загрузка завершена!

Ради краткости текущая версия loader_demo не отображает содержимое разделов. Расширьте её так, чтобы она принимала бинарный файл и имя раздела, а затем выводила содержимое этого раздела на экран в шестнадцатеричном виде.

Некоторые символы являются слабыми: их значение может быть переопределено другим, неслабым символом. Сейчас загрузчик этого не учитывает и просто сохраняет все символы. Измените его так, чтобы после переопределения слабого символа более поздним символом сохранялась только последняя версия. Чтобы определить нужные для проверки флаги, изучите /usr/include/bfd.h.

Расширьте загрузчик и программу loader_demo, чтобы они обрабатывали локальные и глобальные символы данных наряду с символами функций. Потребуется добавить обработку символов данных в загрузчик, новый тип SymbolType в класс Symbol и код вывода символов данных в loader_demo. Обязательно проверьте изменения на бинарном файле с символами, чтобы гарантировать наличие символов данных. В терминологии символов элементы данных называются объектами. Если вы сомневаетесь в правильности вывода, проверьте его с помощью readelf.

В этой главе я познакомил вас со всеми основными инструментами анализа бинарных файлов Linux, необходимыми эффективному специалисту. Большинство этих инструментов довольно просты, однако, сочетая их, можно в считанные минуты реализовывать мощные методы анализа бинарных файлов! В следующей главе вы изучите несколько основных инструментов дизассемблирования и другие, более продвинутые методы анализа.

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

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

1. Загрузить бинарный файл для обработки с помощью загрузчика, подобного реализованному в главе 4.

2. Найти в бинарном файле все машинные инструкции.

3. Дизассемблировать эти инструкции в форму, удобочитаемую человеком или машиной.

К сожалению, на практике шаг 2 часто оказывается очень трудным, что приводит к ошибкам дизассемблирования. Существуют два основных подхода к статическому дизассемблированию, и каждый по-своему старается избегать таких ошибок: линейное дизассемблирование и рекурсивное дизассемблирование. К сожалению, ни один из них не идеален во всех случаях. Обсудим компромиссы между этими двумя методами статического дизассемблирования. К динамическому дизассемблированию мы вернёмся позднее в этой главе.

На рис. 6-1 показаны основные принципы линейного и рекурсивного дизассемблирования. Кроме того, выделены некоторые типы ошибок, возможных при каждом подходе.

Рис. 6-1. Линейное и рекурсивное дизассемблирование. Стрелки показывают ход дизассемблирования. Серые блоки обозначают пропущенный или повреждённый код

Начнём с линейного дизассемблирования - концептуально самого простого подхода. Оно последовательно проходит по всем сегментам кода бинарного файла, декодирует каждый байт и преобразует байты в список инструкций. Этот подход применяют многие простые дизассемблеры, включая знакомый по главе 1 objdump.

Риск линейного дизассемблирования состоит в том, что не все байты обязательно являются инструкциями. Например, некоторые компиляторы, в том числе Visual Studio, перемежают код данными, такими как таблицы переходов, не оставляя никаких указаний на точное расположение этих данных. Если дизассемблер случайно примет такие встроенные данные за код, ему могут встретиться недопустимые коды операций. Хуже того, байты данных могут случайно соответствовать допустимым кодам операций, и тогда дизассемблер выведет ложные инструкции. Особенно вероятно это для плотных архитектур наборов команд, таких как x86, где большинство байтовых значений представляют допустимый код операции.

Кроме того, в архитектурах с кодами операций переменной длины, таких как x86, встроенные данные способны даже нарушить синхронизацию дизассемблера с настоящим потоком инструкций. Обычно дизассемблер вновь синхронизируется самостоятельно, но до этого он может пропустить несколько первых настоящих инструкций после встроенных данных, как показано на рис. 6-2.

Рис. 6-2. Рассинхронизация дизассемблирования из-за встроенных данных, принятых за код. Серым выделена инструкция, на которой дизассемблер восстанавливает синхронизацию

На рисунке показана рассинхронизация дизассемблера в части секции кода бинарного файла. Видно несколько байтов встроенных данных (0x8e 0x20 0x5c 0x00), за которыми следуют инструкции (push rbp, mov rbp,rsp и другие). Правильное декодирование всех байтов, которое выполнил бы идеально синхронизированный дизассемблер, показано слева под заголовком «Синхронизировано». Но наивный линейный дизассемблер принимает встроенные данные за код и потому декодирует байты, как показано в столбце «Смещение на -4 байта». Встроенные данные превращаются в инструкцию mov fs,[rax], за которой следуют pop rsp и add [rbp+0x48],dl. Последняя инструкция особенно неприятна, поскольку выходит за область встроенных данных и захватывает настоящие инструкции! Тем самым add «съедает» часть байтов настоящих инструкций, и дизассемблер полностью пропускает первые две настоящие инструкции. Похожие трудности возникают, если дизассемблер начинает на 3 байта раньше - столбец «Смещение на -3 байта»; такое может случиться, если он пытается пропустить встроенные данные, но распознаёт их не полностью.

К счастью, на x86 дизассемблированный поток инструкций обычно сам синхронизируется уже через несколько инструкций. Но пропуск даже нескольких инструкций может иметь серьёзные последствия при любом автоматизированном анализе или изменении бинарного файла на основе дизассемблированного кода. Как вы увидите в главе 8, вредоносные программы иногда намеренно содержат байты, предназначенные для рассинхронизации дизассемблеров и сокрытия настоящего поведения программы.

На практике линейные дизассемблеры, такие как objdump, можно безопасно применять к бинарным файлам ELF, скомпилированным современными версиями компиляторов вроде gcc или clang из LLVM. Версии этих компиляторов для x86 обычно не создают встроенных данных. Visual Studio, напротив, создаёт их, поэтому при исследовании бинарных файлов PE с помощью objdump стоит следить за ошибками дизассемблирования. То же относится к анализу бинарных файлов ELF для архитектур, отличных от x86, например ARM. А при анализе вредоносного кода линейным дизассемблером вообще нельзя ни на что полагаться: такой код может содержать куда более серьёзную обфускацию, чем встроенные данные!

В отличие от линейного, рекурсивное дизассемблирование учитывает поток управления. Оно начинает с известных точек входа в бинарный файл - например, с главной точки входа и экспортируемых символов функций, - а затем рекурсивно следует потоку управления, то есть переходам и вызовам, обнаруживая код. Благодаря этому рекурсивное дизассемблирование обходит байты данных во всех случаях, кроме нескольких граничных.^[1] Недостаток подхода в том, что не всякий поток управления легко проследить. Например, статически определить возможные цели косвенных переходов или вызовов зачастую трудно, если вообще возможно. В результате дизассемблер может пропустить блоки кода или даже целые функции, такие как f1 и f2 на рис. 6-1, на которые направлены косвенные переходы либо вызовы, если не воспользуется специальной - зависящей от компилятора и подверженной ошибкам - эвристикой разрешения потока управления.

Во многих областях обратной разработки, например при анализе вредоносных программ, рекурсивное дизассемблирование фактически стало стандартом. IDA Pro, показанный на рис. 6-3, - один из самых развитых и широко применяемых рекурсивных дизассемблеров. Название IDA является сокращением от Interactive DisAssembler - интерактивный дизассемблер. Он рассчитан на интерактивное использование и предоставляет множество возможностей для визуализации и исследования кода, написания сценариев на Python и даже декомпиляции,^[2] которых нет в простых инструментах вроде objdump. Разумеется, цена соответствует возможностям: на момент написания книги лицензии IDA Starter - упрощённой редакции IDA Pro - стоили от 739 долларов, а полноценные лицензии IDA Professional - от 1409 долларов. Но не беспокойтесь: покупать IDA Pro для работы с этой книгой не нужно. Книга посвящена не интерактивной обратной разработке, а созданию собственных автоматизированных инструментов анализа бинарных файлов на основе бесплатных программных каркасов.

Рис. 6-3. Графическое представление IDA Pro

На рис. 6-4 показаны некоторые трудности, с которыми рекурсивные дизассемблеры наподобие IDA Pro сталкиваются на практике. В частности, рисунок демонстрирует, как простая функция из opensshd версии 7.1p2 компилируется gcc версии 5.1.1 из C в код x64.

Рис. 6-4. Пример дизассемблированного оператора switch из opensshd версии 7.1p2, скомпилированного gcc 5.1.1 для x64; исходный код сокращён. Интересные строки выделены серым

Как видно в левой части рисунка, представляющей функцию на C, она не делает ничего особенного. Цикл for проходит по массиву, а на каждой итерации оператор switch определяет, что делать с текущим элементом: пропустить неинтересный элемент, вернуть индекс элемента, соответствующего некоторым критериям, либо при неожиданном событии напечатать ошибку и завершить работу. Несмотря на простоту кода C, скомпилированную версию этой функции, показанную справа, далеко не просто дизассемблировать правильно.

Как видно на рис. 6-4, реализация оператора switch для x64 основана на таблице переходов - конструкции, которую часто создают современные компиляторы. Такая реализация позволяет обойтись без сложного переплетения условных переходов. Инструкция по адресу 0x4438f9 использует входное значение switch, чтобы вычислить в rax индекс таблицы, в которой по этому индексу хранится адрес соответствующего блока case. Благодаря этому для передачи управления по любому адресу case, определённому таблицей переходов, достаточно единственного косвенного перехода по адресу 0x443901.

При всей своей эффективности таблицы переходов усложняют рекурсивное дизассемблирование, поскольку используют косвенный поток управления. В косвенном переходе нет явного адреса цели, поэтому дизассемблеру трудно проследить поток инструкций за этой точкой. В итоге все инструкции, на которые может указывать косвенный переход, останутся необнаруженными, если дизассемблер не реализует специальные, зависящие от компилятора эвристические методы поиска и разбора таблиц переходов.^[3] В нашем примере рекурсивный дизассемблер без эвристики обнаружения switch вообще не найдёт инструкции по адресам 0x443903-0x443925.

Ситуация ещё сложнее из-за нескольких инструкций ret внутри switch, а также вызовов функции fatal, которая выдаёт ошибку и никогда не возвращается. В общем случае нельзя считать, что после инструкции ret или невозвращающегося call обязательно находятся инструкции: за ними могут следовать данные или байты заполнения, не предназначенные для разбора в качестве кода. Однако противоположное предположение - что после них кода нет - может заставить дизассемблер пропустить инструкции и выдать неполный результат.

Это лишь некоторые трудности рекурсивных дизассемблеров; существует множество более сложных случаев, особенно в функциях, которые сложнее приведённого примера. Как видите, ни линейное, ни рекурсивное дизассемблирование не идеально. Для невредоносных бинарных файлов ELF x86 линейное дизассемблирование - хороший выбор, поскольку даёт полный и точный результат: такие файлы обычно не содержат встроенных данных, способных сбить дизассемблер, а линейный подход не пропустит код из-за неразрешённого косвенного потока управления. С другой стороны, если встречаются встроенные данные или

вредоносный код, вероятно, лучше применить рекурсивный дизассемблер: его не так легко обманом заставить выдать ложный результат, как линейный.

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

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

Как ни удивительно, в Linux нет общепринятого стандартного инструмента для автоматической трассировки выполнения по принципу «запустил и забыл» - в отличие от Windows, где доступны превосходные инструменты вроде OllyDbg.^[4] Проще всего обойтись несколькими командами gdb из стандартного набора, как показано в листинге 6-1.

Листинг 6-1. Динамическое дизассемблирование с помощью gdb

В этом примере /bin/ls загружается в gdb, после чего создаётся трасса всех инструкций, выполненных при выводе содержимого текущего каталога. После запуска gdb можно вывести сведения о загруженных файлах - здесь это только исполняемый файл /bin/ls. Так становится известен адрес точки входа бинарного файла, где можно установить точку останова, которая приостановит выполнение сразу после запуска. Затем отключается постраничный вывод, а gdb настраивается на запись журнала в файл вместо стандартного вывода. По умолчанию файл журнала называется gdb.txt. При постраничном выводе gdb приостанавливается через определённое число строк, чтобы пользователь успел прочитать весь текст на экране, прежде чем продолжить. Этот режим включён по умолчанию. При записи в файл такие остановки не нужны: иначе пришлось бы постоянно нажимать клавишу продолжения, что очень быстро надоедает.

После завершения настройки запускается бинарный файл. Он сразу приостанавливается при достижении точки входа. Теперь можно предписать gdb записать в файл первую инструкцию, а затем войти в цикл while, который непрерывно выполняет по одной инструкции за раз - этот процесс называется пошаговым выполнением - пока инструкции не закончатся. Каждая выполненная по шагам инструкция автоматически печатается в файл журнала в том же формате. Когда выполнение завершится, журнал будет содержать все выполненные инструкции. Как и следовало ожидать, вывод очень велик: даже простой запуск небольшой программы проходит через десятки или сотни тысяч инструкций, как показано в листинге 6-2.

Листинг 6-2. Вывод динамического дизассемблирования с помощью gdb

Подсчитав строки журнала с помощью wc, вы увидите, что файл содержит 614 390 строк - слишком много, чтобы приводить их здесь целиком. Чтобы получить представление о выводе, команда head показывает первые 20 строк журнала. Собственно трасса выполнения начинается после сообщения о точке останова. Для каждой выполненной инструкции gdb печатает команду, использованную для регистрации инструкции, затем саму инструкцию и, наконец, некоторые сведения о её расположении - оно неизвестно, поскольку символы из бинарного файла удалены. С помощью grep можно отфильтровать всё, кроме строк с выполненными инструкциями, поскольку интерес представляют только они. Получится вывод из листинга 6-3.

Листинг 6-3. Отфильтрованный вывод динамического дизассемблирования с помощью gdb

Как видите, этот вывод гораздо удобнее читать, чем неотфильтрованный журнал gdb.

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

Как вы видели, дизассемблеры автоматически распознают разные виды структур кода, помогая анализировать бинарный файл. К сожалению, о структурах данных этого сказать нельзя. Автоматическое обнаружение структур данных в бинарных файлах с удалёнными символами - печально известная своей сложностью задача, и, если не считать некоторых исследовательских работ,^[11] дизассемблеры обычно даже не пытаются её решать.

Но бывают исключения. Например, если ссылка на объект данных передаётся хорошо известной функции - скажем, библиотечной, - дизассемблер наподобие IDA Pro может автоматически вывести тип данных из спецификации этой функции. Пример показан на рис. 6-8.

В нижней части базового блока находится вызов хорошо известной функции send, которая отправляет сообщение по сети. Поскольку IDA Pro знает параметры send, он может подписать их имена (flags, len, buf, s) и вывести типы данных регистров и объектов памяти, использованных для загрузки этих параметров.

Кроме того, примитивные типы иногда можно вывести из регистров, в которых они хранятся, или инструкций, обрабатывающих данные. Например, если используется регистр или инструкция с плавающей точкой, значит, соответствующие данные представляют число с плавающей точкой. Инструкция lodsb (загрузить байт строки) или stosb (сохранить байт строки), скорее всего, работает со строкой.

В случае составных типов, таких как struct или массивы, никаких гарантий нет и приходится полагаться на собственный анализ. Чтобы понять, почему автоматически распознать составные типы трудно, посмотрим, как следующая строка C компилируется в машинный код:

Рис. 6-8. IDA Pro автоматически выводит типы данных на основе использования функции send

Это строка из исходного кода nginx версии 1.8.0, где целочисленное поле одной структуры struct присваивается полю другой структуры. При компиляции gcc версии 5.1 с уровнем оптимизации -O2 получается следующий машинный код:

Теперь рассмотрим следующую строку C, которая копирует целое число из выделенного в куче массива b в другой массив a:

Вот результат её компиляции gcc версии 5.1, снова с уровнем оптимизации -O2:

Как видите, шаблон кода в точности совпадает с присваиванием структур struct! Следовательно, автоматический анализ не способен определить по такой последовательности инструкций, представляет ли она обращение к массиву, доступ к struct или что-то совсем иное. Подобные проблемы делают точное обнаружение составных типов данных трудным, если не невозможным в общем случае. Учтите, что этот пример очень прост; представьте обратную разработку программы с массивом элементов struct или вложенными struct и попытку определить, какие инструкции индексируют какую структуру данных! Очевидно, это сложная задача, требующая глубокого исследования кода. Учитывая трудность точного распознавания нетривиальных типов данных, легко понять, почему дизассемблеры не пытаются обнаруживать структуры данных автоматически.

Для ручного структурирования данных IDA Pro позволяет определять собственные составные типы - их приходится выводить при обратной разработке кода - и назначать их элементам данных. Прекрасным источником сведений о ручной обратной разработке структур данных с помощью IDA Pro служит книга Криса Игла «The IDA Pro Book» (No Starch Press, 2011).

Как следует из названия, декомпиляторы пытаются «обратить процесс компиляции». Обычно они начинают с дизассемблированного кода и переводят его на язык более высокого уровня - чаще всего в разновидность C-подобного псевдокода. Декомпиляторы полезны при обратной разработке крупных программ, поскольку декомпилированный код читать проще, чем множество инструкций ассемблера. Однако декомпиляторы пригодны лишь для ручной обратной разработки: процесс декомпиляции слишком подвержен ошибкам, чтобы служить надёжной основой автоматического анализа. Хотя в этой книге декомпиляция не применяется, листинг 6-6 даст представление о том, как выглядит декомпилированный код.

Самый широко используемый декомпилятор - Hex-Rays, подключаемый модуль, поставляемый с IDA Pro.^[12] В листинге 6-6 приведён вывод Hex-Rays для функции, показанной ранее на рис. 6-5.

Листинг 6-6. Функция, декомпилированная с помощью Hex-Rays

Как видно из листинга, декомпилированный код читать намного проще, чем необработанный ассемблер. Декомпилятор предполагает сигнатуру функции и локальные переменные. Вместо мнемоник ассемблера арифметические и логические операции выражаются понятнее, обычными операторами C. Декомпилятор также пытается восстановить конструкции потока управления: ветви if/else, циклы и вызовы функций. Имеется даже оператор return в стиле C, который позволяет легче увидеть конечный результат функции.

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

Наборы команд вроде x86 и ARM содержат множество различных инструкций со сложной семантикой. Например, на x86 даже кажущаяся простой инструкция add имеет побочные эффекты: устанавливает флаги состояния в регистре eflags. Огромное число инструкций и побочных эффектов затрудняет автоматическое рассуждение о бинарных программах. Например, как вы увидите в главах 10-13, механизмы динамического анализа помеченных данных и символьного выполнения должны реализовать явные обработчики, отражающие семантику потока данных всех анализируемых инструкций. Точно реализовать все эти обработчики - чрезвычайно трудная задача.

Промежуточные представления (intermediate representations, IR), также называемые промежуточными языками, предназначены для снятия этой нагрузки. IR - простой язык, абстрагирующий низкоуровневые машинные языки вроде x86 и ARM. Среди популярных IR - Reverse Engineering Intermediate Language (REIL) и VEX IR, применяемый в каркасе инструментирования Valgrind.^[13] Существует даже инструмент McSema, переводящий бинарные файлы в битовый код LLVM, также называемый LLVM IR.^[14]

Идея языков IR заключается в автоматическом переводе настоящего машинного кода, например x86, в IR, который сохраняет всю семантику машинного кода, но гораздо проще для анализа. Для сравнения: в REIL всего 17 различных инструкций, тогда как в x86 их сотни. Кроме того, языки REIL, VEX и LLVM IR выражают все операции явно, без неочевидных побочных эффектов инструкций.

Реализация перевода низкоуровневого машинного кода в IR всё равно требует большой работы, но после неё значительно проще создавать новые методы анализа бинарных файлов поверх переведённого кода. Вместо написания обработчиков каждой инструкции отдельно для каждого вида анализа при использовании IR это требуется сделать лишь однажды - при реализации перевода. Более того, можно написать трансляторы для разных архитектур наборов команд, например x86, ARM и MIPS, и отображать их все в одно IR. Тогда любой инструмент анализа бинарных файлов, работающий с этим IR, автоматически получает поддержку всех архитектур, поддерживаемых представлением.

Компромисс при переводе сложного набора команд вроде x86 в простой язык наподобие REIL, VEX или LLVM IR заключается в том, что язык IR гораздо менее компактен. Это неизбежное следствие выражения сложных операций со всеми побочными эффектами ограниченным набором простых инструкций. Для автоматического анализа это обычно не проблема, но человеку промежуточные представления читать трудно. Чтобы увидеть, как выглядит IR, рассмотрим листинг 6-7, где показан перевод инструкции x86-64 add rax,rdx в VEX IR.^[15]

Листинг 6-7. Перевод инструкции x86-64 add rax,rdx в VEX IR

Как видите, одна инструкция add порождает 10 инструкций VEX и дополнительные метаданные. Сначала метаданные сообщают, что перед нами суперблок IR (IRSB), соответствующий одной машинной инструкции. IRSB содержит четыре временных значения t0-t3, все типа Ity_I64, то есть 64-разрядные целые числа. Затем следует IMark - метаданные, которые среди прочего задают адрес и длину машинной инструкции.

Далее идут собственно инструкции IR, моделирующие add. Сначала две инструкции GET извлекают 64-разрядные значения из rax и rdx во временные хранилища t2 и t1 соответственно. Обратите внимание: здесь rax и rdx - лишь символьные имена частей состояния VEX, моделирующих эти регистры. Инструкции VEX извлекают значения не из настоящих регистров rax и rdx, а из их зеркального состояния в VEX. Само сложение выполняется инструкцией VEX Add64, которая складывает два 64-разрядных целых t2 и t1 и сохраняет результат в t0.

После сложения несколько инструкций PUT моделируют побочные эффекты add, например обновление флагов состояния x86. Затем ещё одна PUT сохраняет результат сложения в часть состояния VEX, представляющую rax. Наконец VEX IR моделирует обновление счётчика команд до следующей инструкции. Подсказка потока управления Ijk_Boring (Jump Kind Boring - «скучный вид перехода») сообщает, что add никак интересно не влияет на поток управления: поскольку это не инструкция ветвления, управление просто «проваливается» к следующей инструкции в памяти. Инструкции ветвления, напротив, могут помечаться подсказками вроде Ijk_Call или Ijk_Ret, сообщающими анализу, например, о вызове или возврате.

При создании инструментов поверх существующего каркаса анализа бинарных файлов обычно не приходится непосредственно работать с IR: каркас сам обрабатывает всё связанное с промежуточным представлением. Тем не менее знать об IR полезно, если вы когда-нибудь захотите реализовать собственный каркас анализа бинарных файлов или изменить существующий.

Изученные в этой главе методы дизассемблирования составляют фундамент анализа бинарных файлов. На них основаны многие продвинутые методы последующих глав, например инструментирование бинарных файлов и символьное выполнение. Но прежде чем переходить к ним, я хочу рассмотреть несколько «стандартных» видов анализа, поскольку они широко применимы. Это не самостоятельные методы анализа бинарных файлов, однако их можно использовать как составляющие более сложного анализа.

Если не указано иное, обычно они реализуются в виде статического анализа, хотя их можно приспособить и для динамических трасс выполнения.

Теперь вы знакомы с внутренним устройством дизассемблеров и основными методами анализа бинарных файлов, необходимыми для понимания остальной части книги. Вы готовы перейти к методам, позволяющим не только дизассемблировать, но и изменять бинарные файлы. В главе 7 начнём с основных способов модификации!

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

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

И всё же иногда шестнадцатеричного редактирования вполне достаточно. Например, вредоносные программы применяют методы против отладки, проверяя среду выполнения на признаки анализирующего программного обеспечения. Заподозрив анализ, программа отказывается запускаться или атакует среду исследования. Если вы предполагаете, что исследуемый образец содержит проверки против отладки, их можно отключить шестнадцатеричным редактором, заменив инструкции проверок на nop, то есть инструкции без действия. Иногда таким редактором удаётся исправить даже простые ошибки. В качестве примера я воспользуюсь hexedit - открытым редактором для Linux, заранее установленным в виртуальной машине, - чтобы устранить ошибку на единицу в простой программе.

Ошибки на единицу обычно возникают в циклах, когда программист задаёт неправильное условие, из-за которого цикл читает или записывает на один байт меньше либо больше. Пример из листинга 7-1 шифрует файл, но по ошибке оставляет последний байт незашифрованным. Чтобы исправить дефект, сначала дизассемблируем бинарный файл с помощью objdump и найдём проблемный код. Затем изменим его в hexedit и устраним ошибку на единицу.

Листинг 7-1. xor_encrypt.c

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

Ошибка находится в следующей части программы, где байты файла шифруются простым алгоритмом на основе xor. Программа входит в цикл for, проходит по буферу со всеми байтами файла и шифрует каждый байт, вычисляя его xor с переданным ключом. Обратите внимание на условие цикла: он начинается с i = 0, но выполняется только пока i < n-1. Следовательно, последний зашифрованный байт имеет индекс n-2, а финальный байт с индексом n-1 остаётся незашифрованным! Это и есть ошибка на единицу, которую мы исправим редактированием бинарного файла.

Зашифровав буфер файла, программа открывает выходной файл, записывает в него зашифрованные байты и наконец закрывает его. Листинг 7-2 показывает пример запуска программы, скомпилированной посредством Makefile из виртуальной машины, где ошибка на единицу видна в действии.

Листинг 7-2. Наблюдение за ошибкой на единицу в программе xor_encrypt

В этом примере программа xor_encrypt шифрует собственный исходный файл ключом foobar и записывает результат в файл encrypted. В выводе xxd для исходного файла видно, что тот заканчивается байтом 0x0a. В зашифрованном файле искажены все байты, кроме последнего, который совпадает с последним байтом исходного файла. Причина в ошибке на единицу, оставляющей последний байт незашифрованным.

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

LD_PRELOAD - имя переменной окружения, влияющей на динамический компоновщик. Она позволяет указать одну или несколько библиотек, которые компоновщик загрузит раньше всех остальных, включая стандартные системные библиотеки вроде libc.so. Если предварительно загруженная библиотека содержит функцию с тем же именем, что и функция в загруженной позднее библиотеке, во время выполнения будет применяться первая. Таким образом, библиотечные функции - даже стандартные вроде malloc или printf - можно переопределять собственными версиями. Это полезно не только для модификации бинарных файлов, но и для программ с доступным исходным кодом: возможность изменить поведение библиотечной функции избавляет от кропотливого редактирования всех мест исходного кода, где она используется. Рассмотрим пример изменения поведения бинарного файла посредством LD_PRELOAD.

В этом примере будет изменена программа heapoverflow, содержащая уязвимость переполнения кучи, которую можно исправить с помощью LD_PRELOAD. Её исходный код приведён в листинге 7-6.

Листинг 7-6. heapoverflow.c

Программа heapoverflow принимает два аргумента командной строки: число и строку. Число интерпретируется как длина буфера, после чего malloc выделяет буфер такого размера. Затем strcpy копирует в него заданную строку, а содержимое буфера печатается на экране. Наконец буфер освобождается функцией free.

Уязвимость переполнения находится в операции strcpy: длина строки не проверяется, поэтому она может не поместиться в буфере. Тогда копирование вызовет переполнение кучи, способное повредить другие данные в куче, привести к аварийному завершению и даже позволить эксплуатацию программы. Если строка помещается в буфере, всё работает правильно, как в листинге 7-7.

Листинг 7-7. Поведение программы heapoverflow с безопасными входными данными

Здесь программе предписано выделить 13-байтовый буфер и скопировать в него сообщение Hello world!. Буфер имеет ровно достаточный размер для строки вместе с завершающим символом NULL, поэтому программа выделяет его, копирует сообщение и ожидаемым образом печатает его обратно. В листинге 7-8 показано, что произойдёт с сообщением, не помещающимся в буфер.

Листинг 7-8. Аварийное завершение heapoverflow при слишком длинных входных данных

И снова программе предписано выделить 13 байт, но теперь сообщение слишком велико для буфера: это строка из 100 букв A подряд. Программа выделяет 13-байтовый буфер, как и раньше, а затем копирует в него сообщение и печатает его. Ошибка проявляется при вызове free для освобождения буфера: вышедшее за границы сообщение перезаписало метаданные кучи, с помощью которых malloc и free отслеживают буферы. Повреждённые метаданные в итоге вызывают аварийное завершение. В худшем случае такое переполнение позволяет злоумышленнику захватить уязвимую программу с помощью специально составленной строки. Теперь посмотрим, как обнаружить и предотвратить переполнение посредством LD_PRELOAD.

Основная идея - реализовать разделяемую библиотеку, переопределяющую malloc и free, чтобы они самостоятельно отслеживали размеры всех выделенных буферов, а также переопределяющую strcpy, чтобы перед копированием она автоматически проверяла, достаточно ли велик буфер.

Ради простоты примера решение намеренно упрощено и не должно применяться в рабочей среде. Например, оно не учитывает изменение размеров буферов посредством realloc и использует простую систему учёта, способную отслеживать лишь последние 1024 выделенных буфера. Но этого достаточно, чтобы показать применение LD_PRELOAD к настоящим задачам. В листинге 7-9 приведён код библиотеки heapcheck.c с альтернативными реализациями malloc, free и strcpy.

Листинг 7-9. heapcheck.c

Прежде всего обратите внимание на заголовок dlfcn.h, который часто включают при написании библиотек для LD_PRELOAD, поскольку он предоставляет функцию dlsym. С её помощью можно получать указатели на функции разделяемых библиотек. Здесь она обеспечивает доступ к исходным функциям malloc, free и strcpy, чтобы не пришлось полностью реализовывать их заново. Набор глобальных указателей на функции хранит найденные посредством dlsym оригинальные функции.

Для отслеживания размеров выделенных буферов определён тип struct с именем alloc_t, способный хранить адрес и размер буфера. Глобальный циклический массив таких структур allocs отслеживает последние 1024 выделения.

Теперь рассмотрим изменённую функцию malloc. Сначала она проверяет, инициализирован ли указатель на исходную версию malloc из libc, названный orig_malloc. Если нет, указатель ищется посредством dlsym.

Обратите внимание: для dlsym применяется флаг RTLD_NEXT, заставляющий её вернуть указатель на следующую версию malloc в цепочке разделяемых библиотек. Предварительно загруженная библиотека находится в начале цепочки. Поэтому следующей версией malloc, на которую вернёт указатель dlsym, будет оригинальная версия из libc, поскольку libc загружена позже.

Затем изменённая malloc вызывает orig_malloc для фактического выделения памяти и сохраняет адрес и размер буфера в глобальном массиве allocs. Благодаря сохранённым сведениям strcpy сможет позднее проверить безопасность копирования строки в заданный буфер.

Новая версия free похожа на новую malloc. Она просто разрешает и вызывает исходную free (orig_free), а затем аннулирует метаданные освобождённого буфера в массиве allocs.

Наконец рассмотрим новую strcpy. Она также начинает с разрешения оригинальной strcpy (orig_strcpy). Однако перед её вызовом функция проверяет безопасность копирования, разыскивая в глобальном массиве allocs запись с размером буфера назначения. Если метаданные найдены, strcpy проверяет, достаточно ли велик буфер для строки. При достаточном размере копирование разрешается. В противном случае печатается сообщение об ошибке, а программа прерывается, чтобы злоумышленник не смог воспользоваться уязвимостью. Если метаданные не найдены, поскольку буфер назначения не входит в число последних 1024 выделений, strcpy разрешает копирование. На практике такой ситуации лучше избегать, применяя более сложную структуру метаданных без ограничения в 1024 или иное фиксированное число выделений.

В листинге 7-10 показано практическое применение библиотеки heapcheck.so.

Листинг 7-10. Применение heapcheck.so для предотвращения переполнения кучи

Главное здесь - определение переменной окружения LD_PRELOAD при запуске heapoverflow. Благодаря ей компоновщик предварительно загружает указанную библиотеку heapcheck.so, содержащую изменённые функции malloc, free и strcpy. Пути в LD_PRELOAD должны быть абсолютными: при относительном пути динамический компоновщик не найдёт библиотеку, и предварительной загрузки не произойдёт.

Параметры heapoverflow совпадают с листингом 7-8: 13-байтовый буфер и 100-байтовая строка. Теперь переполнение кучи не вызывает сбоя. Изменённая strcpy успешно обнаруживает небезопасное копирование, печатает ошибку и безопасно прерывает программу, не позволяя злоумышленнику эксплуатировать уязвимость.

Если внимательно посмотреть Makefile программы heapoverflow, можно заметить, что она собрана gcc с флагом -fno-builtin. Для основных функций наподобие malloc компилятор gcc иногда использует встроенные версии, которые он статически компонует со скомпилированной программой. Флаг -fno-builtin гарантирует, что этого не произойдёт, поскольку статически скомпонованные функции нельзя переопределить посредством LD_PRELOAD.

Изученные до сих пор способы модификации бинарных файлов довольно ограниченны. Шестнадцатеричное редактирование полезно для небольших изменений, но не позволяет добавить много нового кода или данных, если вообще что-либо позволяет. LD_PRELOAD упрощает добавление нового кода, но годится лишь для изменения библиотечных вызовов. Прежде чем в главе 9 перейти к более гибким способам, рассмотрим внедрение совершенно новой секции кода в бинарный файл ELF. Этот сравнительно простой приём гибче предыдущих.

В виртуальной машине имеется готовый инструмент elfinject, реализующий такое внедрение. Его исходный код довольно велик, поэтому здесь разбирать его не будем, но приложение B содержит описание реализации для заинтересованных читателей. Оно одновременно служит введением в libelf - популярную открытую библиотеку разбора бинарных файлов ELF. Для понимания остальной книги знание libelf не требуется, но она полезна при создании собственных инструментов анализа, поэтому советую прочитать приложение B.

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

Чтобы сделать метод внедрения через PT_NOTE более конкретным, посмотрим, как использовать предоставленный в виртуальной машине инструмент elfinject. В листинге 7-11 показано внедрение секции кода в бинарный файл.

Листинг 7-11. Использование elfinject

В каталоге кода этой главы на виртуальной машине находится файл hello.bin с новым внедряемым кодом в необработанном бинарном виде, без заголовков ELF. Как вы вскоре увидите, код печатает сообщение hello world!, а затем передаёт управление исходной точке входа файла-носителя, возобновляя его обычное выполнение. Если вы заинтересованы, ассемблерные инструкции внедряемого кода находятся в файле hello.s и в разделе 7.4.

Теперь рассмотрим использование elfinject. Как видно, инструмент ожидает пять аргументов: путь к бинарному файлу-носителю, путь к внедряемому файлу, имя и адрес внедрённой секции, а также смещение точки входа внедряемого кода - либо -1, если точки входа нет. Файл hello.bin внедряется в носитель с указанными именем, адресом и точкой входа.

В примере носителем служит копия /bin/ls. До внедрения ls работает обычным образом и печатает содержимое текущего каталога. С помощью readelf видно, что бинарный файл содержит секцию .note.ABI-tag и сегмент PT_NOTE, которые будут перезаписаны.

Теперь пора внедрить код. В примере elfinject помещает файл hello.bin в бинарный файл ls, задавая внедрённой секции имя .injected и адрес загрузки 0x800000; саму секцию инструмент дописывает в конец файла. В качестве точки входа используется 0, поскольку точка входа hello.bin находится в самом его начале.

После успешного завершения elfinject вывод readelf показывает в ls секцию кода .injected и новый исполняемый сегмент типа PT_LOAD, содержащий эту секцию. Секция .note.ABI-tag и сегмент PT_NOTE исчезли, поскольку были перезаписаны. Похоже, внедрение удалось!

Проверим поведение внедрённого кода. При запуске изменённого ls видно, что программа выполняет новый код в самом начале и печатает hello world!. Затем внедрённый код передаёт выполнение исходной точке входа бинарного файла, и тот возобновляет обычное поведение, печатая содержимое каталога.

В предыдущем разделе вы научились внедрять новую секцию кода в существующий бинарный файл посредством elfinject. Чтобы новый код выполнялся, была изменена точка входа ELF: код запускался сразу после передачи управления загрузчиком. Но выполнять внедрённый код непосредственно при запуске нужно не всегда. Иногда он требуется для других целей, например как замена существующей функции.

В этом разделе будут рассмотрены способы передачи управления внедрённому коду без изменения точки входа ELF. Кроме того, мы повторим изменение точки входа, на этот раз пользуясь для него только шестнадцатеричным редактором. Так можно перенаправить точку входа не только в код, добавленный elfinject, но и в код, вставленный иначе - например, путём перезаписи мёртвого кода вроде инструкций заполнения. Все методы данного раздела подходят для любого способа внедрения кода, а не только для перезаписи PT_NOTE.

Сначала кратко повторим метод изменения точки входа ELF. В следующем примере управление передаётся секции кода, внедрённой с помощью elfinject, но саму точку входа вместо elfinject обновляет шестнадцатеричный редактор. Это покажет, как обобщить метод на код, внедрённый разными способами.

В листинге 7-12 приведены ассемблерные инструкции внедряемого кода - тот же пример «hello world» из предыдущего раздела.

Листинг 7-12. hello.s

Код записан в синтаксисе Intel и предназначен для сборки ассемблером nasm в 64-разрядном режиме. Первые инструкции сохраняют регистры rax, rcx, rdx, rsi и rdi, помещая их в стек. Ядро может изменить эти регистры, поэтому их понадобится восстановить до исходных значений после завершения внедрённого кода, чтобы не мешать другому коду.

Следующие инструкции подготавливают аргументы системного вызова sys_write, который напечатает на экране hello world!. Сведения о номерах и аргументах всех стандартных системных вызовов Linux приведены на справочной странице syscall. Номер sys_write, помещаемый в rax, равен 1; вызов принимает три аргумента: файловый дескриптор для записи - 1 для stdout, - указатель на печатаемую строку и её длину. После подготовки аргументов инструкция syscall выполняет системный вызов и печатает строку.

После sys_write код восстанавливает ранее сохранённые регистры. Затем помещает в стек адрес исходной точки входа 0x4049a0, найденный посредством readelf, и возвращается по этому адресу, начиная выполнение исходной программы.

После ассемблерных инструкций объявлены строка hello world и целое число с её длиной; оба значения используются системным вызовом sys_write.

Чтобы код подходил для внедрения, его нужно собрать в необработанный бинарный файл, содержащий только бинарные представления инструкций и данных. Полноценный ELF с заголовками и другими ненужными для внедрения накладными данными создавать не следует. Собрать hello.s в необработанный файл позволяет параметр -f bin ассемблера nasm, как показано в листинге 7-13. В Makefile этой главы есть цель hello.bin, автоматически выполняющая команду.

Листинг 7-13. Сборка hello.s в hello.bin посредством nasm

В результате создаётся hello.bin с необработанными бинарными инструкциями и данными, пригодными для внедрения. Теперь внедрим его с помощью elfinject, а точку входа ELF перенаправим шестнадцатеричным редактором, чтобы новый код выполнялся при запуске. Действия приведены в листинге 7-14.

Листинг 7-14. Вызов внедрённого кода перезаписью точки входа ELF

Сначала бинарный файл /bin/ls копируется в ls.entry, который послужит носителем. Затем только что подготовленный код внедряется посредством elfinject с адресом загрузки 0x800000, в точности как в разделе 7.3.2, но с одним важным отличием: последний аргумент elfinject равен -1, поэтому инструмент не меняет точку входа - мы перезапишем её вручную.

readelf показывает исходную точку входа бинарного файла: 0x4049a0. Именно на этот адрес переходит внедрённый код после печати hello world, как в листинге 7-12. Кроме того, из readelf видно, что внедрённая секция фактически начинается по адресу 0x800e78, а не 0x800000. Причина в том, что elfinject немного изменил адрес для соблюдения требований ELF к выравниванию, подробнее описанных в приложении B. Здесь важно, что именно 0x800e78 должен заменить адрес точки входа.

Поскольку точка входа пока не изменена, ls.entry работает как обычная команда ls, не печатая в начале hello world. Для изменения точки входа бинарный файл открывается в hexedit, после чего выполняется поиск исходного адреса. Напомним: диалог поиска открывается клавишей /, затем вводится искомый адрес. Адрес хранится в формате с обратным порядком байтов, поэтому вместо 4049a0 нужно искать байты a04940. Найдя точку входа, замените её новой, снова записанной в обратном порядке: 780e80. Затем нажмите CTRL-X для выхода и Y для сохранения.

Теперь readelf показывает обновлённую точку входа 0x800e78, указывающую на начало внедрённого кода. При запуске ls.entry сначала печатает hello world, а затем содержимое каталога. Точка входа успешно перезаписана!

Рассмотрим другой способ однократно вызвать внедрённый код за время жизни бинарного файла - в начале или конце выполнения. Вспомните из главы 2, что бинарные файлы x86 ELF, скомпилированные gcc, содержат секции .init_array и .fini_array с указателями на последовательности конструкторов и деструкторов соответственно. Перезаписав один из указателей, можно вызвать внедрённый код до или после функции main, в зависимости от того, перехватывается конструктор или деструктор.

Разумеется, после завершения внедрённого кода управление нужно вернуть перехваченному конструктору или деструктору. Для этого внедряемый код немного изменяется, как показано в листинге 7-15. Здесь предполагается возврат к конкретному конструктору, адрес которого будет найден посредством objdump.

Листинг 7-15. hello-ctor.s

Код листинга 7-15 совпадает с листингом 7-12, но вместо адреса точки входа для возврата вставлен адрес перехваченного конструктора. Команда сборки в необработанный бинарный файл остаётся прежней. В листинге 7-16 показано, как внедрить код в бинарный файл и перехватить конструктор.

Листинг 7-16. Вызов внедрённого кода перехватом конструктора

Как и раньше, сначала копируется /bin/ls, а новый код внедряется в копию без изменения точки входа. readelf подтверждает наличие секции .init_array.^[4] Секция .fini_array тоже присутствует, но здесь перехватывается конструктор, а не деструктор.

Содержимое .init_array можно посмотреть посредством objdump: в нём находится единственный указатель на функцию-конструктор со значением 0x404a70, хранящимся в обратном порядке байтов. Затем этот адрес разыскивается в hexedit и меняется на адрес входа внедрённого кода 0x800e78.

После изменения единственный указатель в .init_array направлен на внедрённый код вместо исходного конструктора. Помните, что по завершении внедрённый код передаёт управление обратно исходному конструктору. После перезаписи указателя обновлённый ls начинает работу с сообщения hello world, а затем обычным образом печатает содержимое каталога. Этот метод позволяет выполнить код один раз при запуске или завершении бинарного файла, не меняя точку входа.

Два рассмотренных метода - изменение точки входа и перехват конструктора или деструктора - позволяют выполнить внедрённый код только один раз при запуске либо завершении бинарного файла. А что, если требуется многократно вызывать внедрённую функцию, например для замены существующей библиотечной функции? Сейчас мы перехватим запись GOT, заменив библиотечный вызов внедрённой функцией. Вспомните из главы 2: Global Offset Table (GOT) содержит указатели на функции разделяемых библиотек и используется динамической компоновкой. Перезапись одной или нескольких записей даёт почти такой же контроль, как LD_PRELOAD, но не требует внешней библиотеки с новой функцией и позволяет сохранить самодостаточность бинарного файла. Кроме того, перехват GOT подходит не только для постоянной модификации, но и для эксплуатации бинарного файла во время выполнения.

Метод требует небольшого изменения внедряемого кода, показанного в листинге 7-17.

Листинг 7-17. hello-got.s

При перехвате GOT библиотечная функция полностью заменяется, поэтому по завершении внедрённого кода не нужно возвращать управление исходной реализации. Следовательно, листинг 7-17 не содержит жёстко заданного адреса, на который передаётся управление в конце, а завершается обычным возвратом.

Рассмотрим практическую реализацию перехвата GOT. В листинге 7-18 запись GOT библиотечной функции fwrite_unlocked в бинарном файле ls заменяется указателем на функцию hello world из листинга 7-17. Именно fwrite_unlocked программа ls использует для печати сообщений на экране.

Листинг 7-18. Вызов внедрённого кода перехватом записи GOT

Создав свежую копию ls и внедрив в неё код, можно с помощью objdump посмотреть записи PLT, где используются записи GOT, и найти запись для fwrite_unlocked. Она начинается по адресу 0x402800, а используемая ею запись GOT расположена по адресу 0x61e2a0 в секции .got.plt.

В содержимом .got.plt, выведенном objdump, виден исходный адрес в записи GOT: 0x402806, закодированный с обратным порядком байтов.

Как объяснялось в главе 2, это адрес следующей инструкции в записи PLT функции fwrite_unlocked; его нужно заменить адресом внедрённого кода. Поэтому запускается hexedit, выполняется поиск строки 062840, и она обычным образом заменяется адресом нового кода 0x800e78. Изменение подтверждается ещё одним просмотром записи GOT через objdump.

После перенаправления записи GOT на функцию hello world программа ls печатает это сообщение при каждом вызове fwrite_unlocked, заменяя весь обычный вывод ls копиями строки. Разумеется, в реальной ситуации fwrite_unlocked следовало бы заменить более полезной функцией.

Преимущество перехвата GOT не только в простоте, но и в возможности легко выполнить его во время работы. В отличие от секций кода, .got.plt доступна для записи во время выполнения. Поэтому перехват GOT популярен как при постоянной статической модификации, показанной здесь, так и в эксплойтах, изменяющих поведение работающего процесса.

Следующий способ вызова внедрённого кода - перехват PLT - похож на перехват GOT. Он также позволяет заменить существующую библиотечную функцию. Разница лишь в том, что вместо адреса функции в записи GOT, используемой заглушкой PLT, меняется сама заглушка. Поскольку PLT является секцией кода, этот метод не подходит для изменения поведения бинарного файла во время выполнения. Пример приведён в листинге 7-19.

Листинг 7-19. Вызов внедрённого кода перехватом записи PLT

Как и прежде, сначала создаётся копия ls, куда внедряется новый код. В этом примере используется та же полезная нагрузка, что и при перехвате GOT. Функция fwrite_unlocked снова заменяется функцией hello world.

Посмотрим в objdump запись PLT для fwrite_unlocked. Но теперь интересует не адрес используемой заглушкой записи GOT, а бинарное представление первой инструкции самой заглушки. Согласно objdump, это ff259aba2100, то есть косвенная инструкция jmp со смещением относительно регистра rip. Запись PLT можно перехватить, заменив её инструкцией прямого перехода к внедрённому коду.

В hexedit разыскивается последовательность ff259aba2100, соответствующая первой инструкции заглушки PLT, и заменяется на e973e63f00 - представление прямой jmp по адресу внедрённого кода 0x800e78. Первый байт e9 - код операции прямого перехода, а следующие четыре байта - смещение до нового кода относительно самой инструкции jmp.

После изменения PLT снова дизассемблируется посредством objdump. Первая инструкция записи fwrite_unlocked теперь имеет вид jmp 800e78: прямой переход к внедрённому коду. За ней дизассемблер показывает несколько ложных инструкций из оставшихся байтов исходной записи PLT, которые не были перезаписаны. Они не представляют проблемы, поскольку выполняться всегда будет только первая инструкция.

При запуске изменённого ls сообщение hello world ожидаемым образом печатается при каждом вызове fwrite_unlocked, давая тот же результат, что и перехват GOT.

До сих пор внедрённый код запускался при старте или завершении бинарного файла либо при вызове библиотечной функции. Но для замены внедрённой функцией небиблиотечной функции перехват записи GOT или PLT не подходит. В таком случае дизассемблером находят изменяемые вызовы, а затем шестнадцатеричным редактором заменяют их вызовами внедрённой функции вместо исходной.

Процесс шестнадцатеричного редактирования совпадает с изменением записи PLT, поэтому повторять действия здесь не будем.

При перенаправлении косвенного вызова - в отличие от прямого - проще всего заменить его прямым. Однако это возможно не всегда, поскольку представление прямого вызова может быть длиннее косвенного. Тогда сначала требуется найти адрес заменяемой функции, вызываемой косвенно: например, установить в gdb точку останова на инструкции косвенного вызова и проверить адрес цели.

Узнав адрес заменяемой функции, можно посредством objdump или шестнадцатеричного редактора поискать его в секции .rodata бинарного файла. При удачном стечении обстоятельств там обнаружится указатель на функцию с целевым адресом. Шестнадцатеричным редактором этот указатель можно заменить адресом внедрённого кода. Если не повезёт, указатель вычисляется каким-либо способом во время выполнения, и для замены вычисленной цели адресом внедрённой функции потребуется более сложное редактирование.

В этой главе вы изучили несколько простых способов модификации бинарных файлов ELF: шестнадцатеричное редактирование, LD_PRELOAD и внедрение секции ELF. Эти методы не очень гибки, поэтому подходят лишь для небольших изменений. Глава должна была ясно показать настоящую потребность в более общих и мощных способах модификации бинарных файлов. К счастью, такие методы существуют и будут рассмотрены в главе 9!

Большинство известных дизассемблеров, например IDA Pro, предназначено для ручной обратной разработки. Это мощные механизмы с обширным графическим интерфейсом, множеством вариантов визуализации дизассемблированного кода и удобной навигацией по огромным массивам ассемблерных инструкций. Если требуется лишь понять назначение бинарного файла, универсальный дизассемблер прекрасно подходит, но универсальным инструментам не хватает гибкости для продвинутого автоматического анализа. Многие дизассемблеры позволяют писать сценарии для последующей обработки кода, однако не дают настраивать сам процесс дизассемблирования и не предназначены для эффективной пакетной обработки бинарных файлов. Поэтому для специализированного автоматического анализа нескольких файлов одновременно понадобится собственный дизассемблер.

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

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

Перекрытие возможно благодаря переменной длине инструкций x86. В отличие от некоторых других платформ, например ARM, инструкции x86 состоят из разного числа байтов. Поэтому процессор не навязывает определённого выравнивания инструкций в памяти, и одна инструкция может занимать набор адресов, уже занятых другой. На x86 дизассемблирование можно начать с середины инструкции и получить другую инструкцию, частично или полностью перекрывающую первую.

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

В листинге 8-1 приведён пример перекрывающихся инструкций. Исходный код, создавший этот пример, находится в overlapping_bb.c. Чтобы дизассемблировать перекрывающийся код, параметр objdump --start-address=<addr> позволяет начать с заданного адреса.

Листинг 8-1. Дизассемблирование overlapping_bb (1)

В листинге показана простая функция с входным параметром i и локальной переменной j. После нескольких вычислений функция возвращает j.

При внимательном рассмотрении заметна странность: инструкция jne по адресу 0x40060a условно переходит в середину инструкции, начинающейся с 0x400610, а не к началу одной из перечисленных инструкций! Большинство дизассемблеров, включая objdump и IDA Pro, показывает только инструкции листинга 8-1. Перекрывающаяся инструкция по адресу 0x400612 будет пропущена, поскольку её байты уже заняты инструкцией, достигаемой при проваливании из jne. Подобное перекрытие скрывает пути кода, способные радикально изменить общий результат программы.

Если переход по адресу 0x40060a не выполняется (i == 0), достигнутые проваливанием инструкции вычисляют и возвращают значение 148. Если же переход выполняется (i != 0), запускается скрытый в листинге 8-1 путь. Посмотрим в листинге 8-2, как он возвращает совершенно другое значение.

Листинг 8-2. Дизассемблирование overlapping_bb (2)

Листинг 8-2 показывает путь, выполняемый при срабатывании jne. Переход пропускает два байта по адресам 0x400610 и 0x400611 и направляется к 0x400612, находящемуся посередине инструкции xor, которая достигается при проваливании из jne. Получается другой поток инструкций. В частности, арифметические операции над j теперь иные, поэтому функция возвращает i + 4, а не 148. Легко представить, насколько подобная обфускация затрудняет понимание кода, особенно когда применяется во многих местах.

Обычно дизассемблер можно заставить раскрыть скрытые инструкции, начав дизассемблирование заново с другого смещения, как было сделано параметром objdump --start-address в предыдущих листингах. Повторный запуск с адреса 0x400612 раскрывает спрятанную там инструкцию, но при этом скрывает инструкцию по адресу 0x400610. Некоторые обфусцированные программы переполнены подобными перекрывающимися последовательностями, и исследовать их вручную чрезвычайно утомительно и трудно.

Пример листингов 8-1 и 8-2 показывает, что специализированный инструмент деобфускации, автоматически «распутывающий» перекрывающиеся инструкции, значительно облегчает обратную разработку. Если обфусцированные бинарные файлы приходится исследовать часто, затраты на создание такого инструмента окупятся в долгосрочной перспективе.^[1] Позднее в этой главе вы научитесь строить рекурсивный дизассемблер, способный работать с перекрывающимися базовыми блоками наподобие показанных выше.

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

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

Иногда, напротив, требуется исключить из дизассемблирования некоторые пути, а не найти все возможные последовательности. Например, это полезно для игнорирования ложных путей, созданных обфускатором,^[2] или

для построения гибридного статико-динамического анализа, сосредоточивающего дизассемблирование на конкретных путях, уже исследованных динамически.

Иногда собственный инструмент не обязателен по чисто техническим причинам, но всё равно выбирается ради эффективности или снижения стоимости. Например, автоматизированным средствам анализа бинарных файлов часто нужны лишь базовые возможности дизассемблирования. Самая сложная часть их работы - специализированный анализ полученных инструкций, которому не требуются обширный пользовательский интерфейс и удобства интерактивных дизассемблеров. В таких случаях можно построить собственный инструмент только на бесплатных открытых библиотеках, не завися от крупных коммерческих дизассемблеров стоимостью до нескольких тысяч долларов.

Ещё одна причина - производительность. Сценарии стандартных дизассемблеров обычно требуют как минимум двух проходов по коду: первоначального дизассемблирования и последующей обработки сценарием. Кроме того, сценарии обычно написаны на языке высокого уровня вроде Python и работают сравнительно медленно. Поэтому при сложном анализе множества крупных файлов производительность нередко можно значительно увеличить, создав нативный инструмент, который выполняет весь необходимый анализ за один проход.

Теперь, когда ясна польза собственного дизассемблирования, посмотрим, как его реализовать. Начнём с краткого знакомства с Capstone - одной из самых популярных библиотек для создания собственных инструментов.

Capstone - каркас дизассемблирования с простым и лёгким API, прозрачно работающим с большинством популярных архитектур, включая x86/x86-64, ARM и MIPS. Он предоставляет привязки для C/C++ и Python - существуют и другие, но мы, как обычно, воспользуемся C/C++ - и работает на всех популярных платформах: Windows, Linux и macOS. Кроме того, он совершенно бесплатный и открытый.

Создавать инструменты на Capstone довольно просто, а возможности чрезвычайно гибки. API сосредоточен вокруг нескольких функций и структур данных, но простота не достигается ценой удобства. Capstone позволяет без труда получать практически все важные сведения о дизассемблированной инструкции: код операции, мнемонику, класс, читаемые и записываемые регистры и многое другое. Лучше всего изучать Capstone на примерах, поэтому сразу приступим.

Capstone 3.0.5 заранее установлен в виртуальной машине книги. Установить его на другую машину также довольно просто. На сайте Capstone^[4] имеются готовые пакеты, в частности для Windows и Ubuntu, а также архив исходного кода для остальных платформ.

Как обычно, инструменты на Capstone мы будем писать на C/C++, но для быстрых экспериментов библиотеку удобно исследовать и из Python. Для этого нужны привязки Capstone Python. Они тоже заранее установлены в виртуальной машине, а на собственную машину легко ставятся менеджером пакетов pip, если уже установлен основной пакет Capstone:

После установки привязок можно запустить интерпретатор Python и начать эксперименты с дизассемблированием, как в листинге 8-3.

Листинг 8-3. Исследование привязок Capstone для Python

В примере импортируется пакет capstone, а встроенная команда Python help используется для его исследования. Основные возможности предоставляет класс capstone.Cs. Важнее всего доступ к функции disasm, которая дизассемблирует буфер кода и возвращает результат. Остальные возможности привязок Capstone для Python можно изучить встроенными командами help и dir. Далее в этой главе мы сосредоточимся на инструментах C/C++, однако соответствующий API очень похож на Python API Capstone.

Познакомившись с основными функциями и структурами Capstone, вы можете спросить, где описана остальная часть API. К сожалению, исчерпывающей документации Capstone пока не существует. Ближайшая замена - заголовочные файлы. Они снабжены хорошими комментариями и не слишком сложны, поэтому с несколькими базовыми указаниями их можно быстро просмотреть и найти необходимое для проекта. В листинге 8-8 перечислены все заголовки C из Capstone 3.0.5; в оригинале самые важные для наших целей выделены серым.

Листинг 8-8. Заголовочные файлы Capstone для C

Как вы уже видели, capstone.h - главный заголовочный файл. Он содержит снабжённые комментариями определения всех функций API и независимых от архитектуры структур данных, таких как cs_insn и cs_err. Здесь же определены все возможные значения перечислений cs_arch, cs_mode и cs_err. Например, чтобы добавить в линейный дизассемблер поддержку ARM, в capstone.h можно найти правильные параметры архитектуры (CS_ARCH_ARM) и режима (CS_MODE_ARM) для cs_open.^[5]

Зависящие от архитектуры структуры и константы определены в отдельных заголовках, например x86.h для x86 и x86-64. Эти файлы задают возможные значения поля id структуры cs_insn; для x86 это перечисленные значения типа x86_insn. Для

большей части архитектурно-зависимые заголовки понадобятся, чтобы выяснить, какие подробности доступны через поле detail типа cs_insn. Если включён режим подробного дизассемблирования, это поле указывает на структуру cs_detail.

Структура cs_detail содержит объединение (union) архитектурно-зависимых структурных типов, предоставляющих подробные сведения об инструкции. Связанный с x86 тип называется cs_x86 и определён в x86.h. Чтобы показать это на практике, создадим рекурсивный дизассемблер, который применяет режим подробного дизассемблирования Capstone для получения архитектурно-зависимой информации об инструкциях x86.

Все рассмотренные до сих пор примеры были специализированными реализациями известных методов дизассемблирования. Однако Capstone позволяет сделать гораздо больше! В этом разделе вы познакомитесь с более узким видом инструмента, потребности которого не покрываются стандартным линейным или рекурсивным дизассемблированием. В частности, речь пойдёт об инструменте, незаменимом для создания современных эксплойтов: сканере, способном находить гаджеты для эксплойтов ROP. Сначала разберём, что это означает.

Почти в каждом введении в эксплуатацию уязвимостей рассматривается классическая статья Алефа Уана "Smashing the Stack for Fun and Profit", объясняющая основы эксплуатации переполнений стекового буфера. Когда эта статья была опубликована в 1996 году, эксплуатация была сравнительно простой: найти уязвимость, загрузить вредоносный шелл-код в буфер целевого приложения - обычно стековый - и с помощью уязвимости перенаправить поток управления на шелл-код.

С тех пор в мире безопасности многое произошло, и эксплуатация чрезвычайно усложнилась. Одна из самых распространённых защит от подобных классических эксплойтов - предотвращение выполнения данных (data execution prevention, DEP), также известное как W⊕X или NX. Оно появилось в Windows XP в 2004 году и препятствует внедрению шелл-кода предельно прямым способом: DEP гарантирует, что никакая область памяти никогда не будет одновременно доступна для записи и исполнения. Поэтому, внедрив шелл-код в буфер, атакующий не сможет его выполнить.

К сожалению, вскоре хакеры нашли способ обойти DEP. Новая защита предотвращала внедрение шелл-кода, но не могла помешать атакующему воспользоваться уязвимостью и перенаправить поток управления на уже существующий код в атакуемом бинарном файле или используемых им библиотеках. Впервые эта слабость была использована в классе атак, известных как возврат в libc (return-to-libc, ret2libc): поток управления перенаправляется в чувствительные функции широко применяемой библиотеки libc, например в execve, с помощью которой можно запустить новый процесс по выбору атакующего.

В 2007 году появился обобщённый вариант ret2libc - возвратно-ориентированное программирование (return-oriented programming, ROP). Вместо ограничения атаки существующими функциями ROP позволяет реализовать произвольную вредоносную функциональность, связывая в цепочку короткие существующие последовательности кода из адресного пространства целевой программы. В терминологии ROP эти короткие последовательности называются гаджетами.

Каждый гаджет завершается инструкцией возврата и выполняет основную операцию, например сложение или логическое сравнение.^[6] Тщательно выбирая гаджеты с чётко определённой семантикой, атакующий может создать, по существу, собственный набор команд, в котором каждый гаджет играет роль инструкции, а затем с помощью этого набора реализовать произвольную функциональность - программу ROP - без внедрения нового кода. Гаджеты могут быть частью обычного потока инструкций основной программы, но могут представлять и невыровненные последовательности инструкций, подобные показанным в обфусцированном коде из листингов 8-1 и 8-2.

Программа ROP состоит из последовательности адресов гаджетов, тщательно размещённых в стеке так, чтобы завершающая каждый гаджет инструкция возврата передавала управление следующему гаджету цепочки. Для запуска программы ROP выполняется исходная инструкция возврата - например, вызванная посредством эксплойта, - которая переходит по адресу первого гаджета. Пример цепочки ROP показан на рис. 8-1.

Рис. 8-1. Пример цепочки ROP. Гаджет g1 загружает константу в eax, после чего g2 прибавляет её к esi

Как видно на рисунке, указатель стека - регистр esp - изначально указывает на адрес первого гаджета g1 в цепочке. При выполнении исходной инструкции возврата этот адрес извлекается из стека, и на него передаётся управление, в результате чего запускается g1. Гаджет g1 выполняет инструкцию pop, которая загружает размещённую в стеке константу в регистр eax и увеличивает esp, чтобы

он указывал на адрес гаджета g2. Затем инструкция ret гаджета g1 передаёт управление g2, который прибавляет константу из eax к регистру esi. После этого гаджет g2 возвращается в гаджет g3, и так далее, пока не будут выполнены все гаджеты g1, ..., gn.

Как вы, вероятно, уже поняли, для создания эксплойта ROP атакующему сначала нужно подобрать подходящий набор гаджетов. В следующем разделе мы реализуем инструмент, который сканирует бинарный файл в поисках пригодных гаджетов ROP и создаёт их обзор, помогающий строить эксплойты ROP.

Все рассмотренные в этой главе инструменты настраивали Capstone только для дизассемблирования кода x64. Для этого в cs_open передавались архитектура CS_ARCH_X86 и режим CS_MODE_64.

Обобщите эти инструменты, чтобы они автоматически выбирали правильные параметры Capstone для других архитектур, проверяя тип загруженного бинарного файла по полям arch и bits класса Binary, предоставленного загрузчиком. Чтобы определить, какие значения архитектуры и режима передавать Capstone, помните: файл /usr/include/capstone/capstone.h содержит списки всех возможных значений cs_arch и cs_mode.

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

При компиляции программы из исходного кода полученный бинарный файл может существенно различаться в зависимости от версии компилятора, параметров компиляции или целевой архитектуры. Кроме того, процесс эксплуатации усложняют стратегии рандомизации, укрепляющие бинарные файлы изменением распределения регистров или перестановкой кода. Это означает, что при разработке эксплойта - например, ROP - не всегда известно, какой бинарный "вариант" программы работает на целевой системе. Например, целевой сервер скомпилирован с помощью gcc или llvm? Он 32-разрядный или 64-разрядный? При неверном предположении эксплойт, скорее всего, не сработает.

В этом упражнении нужно расширить средство поиска гаджетов ROP, чтобы оно принимало два или более бинарных файла, представляющих разные варианты одной программы. Оно должно выводить список VMA, содержащих пригодные гаджеты во всех вариантах. Новое средство должно сканировать каждый входной бинарный файл, но выводить только те адреса, где гаджет присутствует во всех файлах, а не лишь в некоторых. Для каждого выданного VMA гаджеты также должны выполнять сходные операции. Например, они будут содержать инструкцию add или mov. Реализация пригодного понятия сходства - часть задачи. В результате должно получиться межвариантное средство поиска гаджетов, с помощью которого можно разрабатывать эксплойты, одновременно работающие с несколькими вариантами одной программы!

Чтобы проверить средство, создайте варианты выбранной программы, несколько раз скомпилировав её с разными параметрами или разными компиляторами.

Вставка нового кода в любую точку существующего бинарного файла для наблюдения за его поведением или какого-либо изменения этого поведения называется инструментированием бинарного файла. Место добавления нового кода называется точкой инструментирования, а добавленный код - инструментирующим кодом.

Предположим, например, что нужно узнать, какие функции бинарного файла вызываются чаще всего, чтобы сосредоточиться на их оптимизации. Для этого можно инструментировать все инструкции call в бинарном файле,^[1] добавив код, который записывает адрес назначения вызова, чтобы при исполнении инструментированный файл выдавал список вызванных функций.

Хотя этот пример лишь наблюдает за поведением бинарного файла, поведение можно и изменять. Например, защиту от атак с перехватом потока управления можно усилить, инструментировав все косвенные передачи управления - такие как call rax и ret - кодом, проверяющим, входит ли адрес назначения в набор ожидаемых адресов. Если нет, исполнение прекращается и подаётся сигнал тревоги.^[2]

Универсальное бинарное инструментирование, позволяющее добавлять новый код в любую точку бинарного файла, гораздо труднее правильно реализовать, чем простые методы модификации из главы 7. Вспомните: нельзя просто вставить новый код в существующую секцию кода, поскольку он сдвинет старый код на другие адреса и тем самым нарушит ссылки на него. Найти и исправить все существующие ссылки после перемещения кода практически невозможно: бинарные файлы не содержат сведений о расположении этих ссылок, а надёжно отличить адреса, на которые действительно ссылаются, от похожих на адреса констант нельзя.

К счастью, существуют универсальные платформы бинарного инструментирования, которые берут на себя все сложности реализации и предоставляют сравнительно простые API для создания инструментов. Как правило, эти API позволяют устанавливать обратные вызовы инструментирующего кода в выбранных вами точках инструментирования.

Позднее в этой главе вы увидите два практических примера бинарного инструментирования с помощью Pin, популярной платформы бинарного инструментирования. Сначала Pin будет использована для реализации профилировщика, который собирает статистику исполнения бинарного файла, помогающую оптимизации. Затем с её помощью будет создан автоматический распаковщик, упрощающий деобфускацию упакованных бинарных файлов.^[3]

Платформы бинарного инструментирования делятся на два класса: статические и динамические. Сначала обсудим различия между ними, а затем разберём низкоуровневые принципы их работы.

Статическое и динамическое бинарное инструментирование по-разному решают проблемы вставки и перемещения кода. SBI применяет методы переписывания бинарных файлов, чтобы навсегда изменять файлы на диске. Различные подходы к переписыванию, используемые платформами SBI, будут рассмотрены в разделе 9.2.

DBI, напротив, вообще не изменяет бинарные файлы на диске, а наблюдает за ними во время исполнения и на лету вставляет новые инструкции в поток команд. Преимущество этого подхода в отсутствии проблем перемещения кода. Инструментирующий код внедряется только в поток команд, а не в секцию кода бинарного файла в памяти, поэтому ссылки не нарушаются. Обратная сторона в том, что инструментирование DBI во время исполнения требует больше вычислений, и инструментированный файл замедляется сильнее, чем при SBI.

В табл. 9-1 сведены основные преимущества и недостатки SBI и DBI: преимущества отмечены знаком +, а недостатки - знаком -.

Таблица 9-1. Компромиссы динамического и статического бинарного инструментирования

Как видно, анализ и инструментирование DBI во время исполнения замедляют программу в четыре раза или более, тогда как SBI даёт замедление от 10 процентов до двух раз. Учтите, что это приблизительные цифры: фактическое замедление может значительно различаться в зависимости от потребностей инструментирования и качества реализации инструмента. Кроме того, инструментированные посредством DBI бинарные файлы сложнее распространять: вместе с самим файлом необходимо поставлять платформу DBI и инструмент, содержащий инструментирующий код. Инструментированные посредством SBI файлы, напротив, автономны, и после инструментирования их можно распространять обычным образом.

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

Кроме того, платформы DBI обычно могут динамически подключаться к процессам и отключаться от них подобно отладчикам. Это удобно, например, если требуется наблюдать лишь часть исполнения долго работающего процесса. С DBI можно просто подключиться к процессу, собрать нужные сведения, а затем отключиться, вновь оставив процесс работать в обычном режиме. При SBI это невозможно: инструментируется либо всё исполнение, либо ничего.

Наконец, DBI гораздо менее подвержено ошибкам, чем SBI. Для инструментирования SBI дизассемблирует бинарный файл, а затем вносит необходимые изменения. Поэтому ошибки дизассемблирования легко приводят к ошибкам инструментирования, потенциально вызывая неверные результаты или даже нарушая работу файла. У DBI такой проблемы нет, поскольку дизассемблирование ей не требуется: она просто наблюдает инструкции в момент их исполнения и потому гарантированно видит правильный поток команд.^[4] Чтобы уменьшить вероятность ошибок дизассемблирования, многие платформы SBI требуют наличия символов, тогда как у DBI такого требования нет.^[5]

Как уже говорилось, переписывание бинарных файлов в SBI и инструментирование во время исполнения в DBI можно реализовать разными способами. В следующих двух разделах рассмотрим наиболее распространённые способы реализации SBI и DBI соответственно.

Статическое бинарное инструментирование дизассемблирует бинарный файл, добавляет необходимый инструментирующий код и навсегда сохраняет обновлённый файл на диске. Среди известных платформ SBI - PEBIL^[6] и Dyninst,^[7] причём последняя поддерживает как DBI, так и SBI. PEBIL требует наличия символов, а Dyninst - нет. Учтите, что и PEBIL, и Dyninst являются исследовательскими инструментами, поэтому их документация уступает документации продукта промышленного качества.

Главная сложность реализации SBI - найти способ добавить инструментирующий код и переписать бинарный файл, не нарушив существующие ссылки на код или данные. Рассмотрим два распространённых решения этой задачи, которые я называю подходом int 3 и подходом с трамплином. На практике механизмы SBI могут сочетать элементы обоих методов или применять совершенно иной метод.

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

На рис. 9-4 показана архитектура современных систем DBI, таких как Pin и DynamoRIO. Все они основаны на одном высокоуровневом подходе, хотя различаются деталями реализации и оптимизации. В оставшейся части главы я сосредоточусь на "чистых" системах DBI, показанных на рисунке, а не на гибридных платформах наподобие Dyninst, которые поддерживают и SBI, и DBI посредством методов исправления кода, таких как трамплины.

Механизмы DBI динамически инструментируют процессы, наблюдая и управляя всеми исполняемыми инструкциями. Механизм DBI предоставляет API, позволяющий создавать пользовательские инструменты DBI - часто в виде разделяемой библиотеки, загружаемой механизмом, - которые определяют, какой код и как следует инструментировать. Например, инструмент DBI в правой части рис. 9-4 реализует в псевдокоде простой профилировщик, подсчитывающий число исполненных базовых блоков. Для этого он через API механизма DBI инструментирует последнюю инструкцию каждого базового блока обратным вызовом функции, увеличивающей счётчик.

Перед запуском главного процесса приложения - или возобновлением его работы при подключении к существующему процессу - механизм DBI позволяет инструменту DBI инициализироваться. На рис. 9-4 функция инициализации инструмента DBI регистрирует в механизме функцию instrument_bb. Она сообщает механизму DBI, как инструментировать каждый базовый блок; здесь она добавляет обратный вызов bb_callback после последней инструкции базового блока. Затем функция инициализации сообщает механизму DBI, что инициализация завершена и можно запускать приложение.

Рис. 9-4. Архитектура системы DBI

Механизм DBI никогда не исполняет процесс приложения напрямую. Вместо этого он запускает код из кэша кода, содержащего весь инструментированный код. Изначально кэш кода пуст, поэтому механизм DBI получает блок кода из процесса и инструментирует его согласно указаниям инструмента DBI. Обратите внимание: механизмы DBI не обязательно получают и инструментируют код на уровне базовых блоков.

Подробнее это будет объяснено в разделе 9.4. Но для данного примера предположим, что механизм инструментирует код на уровне базовых блоков, вызывая instrument_bb.

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

Теперь инструментированный и JIT-компилированный код исполняется в кэше, пока не встретится инструкция передачи управления, требующая получить новый код или найти в кэше другой фрагмент. Механизмы DBI наподобие Pin и DynamoRIO сокращают накладные расходы времени исполнения, по возможности переписывая инструкции передачи управления так, чтобы они переходили прямо к следующему блоку в кэше без посредничества механизма DBI. Когда это невозможно - например, для косвенных вызовов, - переписанные инструкции возвращают управление механизму DBI, который подготавливает и запускает следующий фрагмент кода.

Хотя большинство инструкций исполняется в кэше нативно, некоторые инструкции механизм DBI может эмулировать вместо непосредственного исполнения. Например, Pin так поступает с системными вызовами наподобие execve, требующими специальной обработки механизмом DBI.

Инструментированный код содержит обратные вызовы функций инструмента DBI, наблюдающих или изменяющих поведение кода. Например, на рис. 9-4 функция instrument_bb инструмента DBI добавляет в конец каждого базового блока обратный вызов bb_callback, который увеличивает счётчик базовых блоков инструмента. При передаче управления в функцию обратного вызова инструмента DBI или из неё механизм автоматически сохраняет и восстанавливает состояние регистров.

Теперь, когда вы знакомы с работой механизмов DBI, обсудим Pin - механизм, используемый в примерах этой главы.

Средство профилирования записывает статистику исполнения программы, чтобы помочь её оптимизировать. В частности, оно подсчитывает число исполненных инструкций и количество вызовов базовых блоков, функций и системных вызовов.

Теперь вы знаете, как инициализировать Pintool и регистрировать процедуры инструментирования и другие обратные вызовы. Подробно рассмотрим только что зарегистрированные функции обратного вызова, начав с parse_funcsyms из листинга 9-2.

Листинг 9-2. profiler.cpp (продолжение)

Вспомните, что parse_funcsyms - процедура инструментирования уровня образа, о чём говорит первый аргумент IMG. Такие процедуры вызываются при загрузке нового образа - исполняемого файла или разделяемой библиотеки - и позволяют инструментировать образ целиком. В частности, можно перебрать все функции образа и добавить процедуры анализа, выполняемые до или после каждой функции. Учтите, что инструментирование функций надёжно только при наличии в бинарном файле символьной информации, а инструментирование после функции не работает с некоторыми оптимизациями, например хвостовыми вызовами.

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

Перед использованием аргумента IMG функция parse_funcsyms вызывает IMG_Valid, проверяя допустимость образа. Если он допустим, parse_funcsyms перебирает все объекты SEC, представляющие секции образа. IMG_SecHead возвращает первую секцию, а SEC_Next - следующую; цикл продолжается, пока SEC_Valid не вернёт false, показывая, что секций больше нет.

Для каждой секции parse_funcsyms перебирает все функции, представленные объектами RTN - сокращение от routine, - и сопоставляет адрес каждой функции, возвращаемый RTN_Address, её символьному имени из RTN_Name в карте funcnames. Если имя функции неизвестно - например, в бинарном файле нет таблицы символов, - RTN_Name возвращает пустую строку.

После завершения parse_funcsyms карта funcnames содержит соответствие всех известных адресов функций их символьным именам.

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

Листинг 9-5. profiler.cpp (продолжение)

Как видите, процедуры анализа просты и содержат лишь минимально необходимый код для сбора требуемой статистики. Это важно, поскольку во время исполнения приложения они вызываются часто и потому существенно влияют на производительность Pintool.

Первая процедура анализа count_bb_insns вызывается при исполнении базового блока и просто увеличивает insn_count на число инструкций в нём. Аналогично count_cflow увеличивает cflow_count при исполнении инструкции передачи управления. Кроме того, она записывает исходный и целевой адреса перехода в карту cflows и увеличивает счётчик этой конкретной пары адресов. Для хранения адресов в Pin применяется целочисленный тип ADDRINT. Процедура count_call, записывающая сведения о вызовах, аналогична count_cflow.

Последняя функция листинга 9-5, log_syscall, не является обычной процедурой анализа, а служит обратным вызовом события входа в системный вызов. Обработчики системных вызовов в Pin принимают четыре аргумента: THREADID, определяющий поток, совершивший вызов; CONTEXT*, содержащий такие сведения, как номер, аргументы и возвращаемое значение системного вызова - последнее только для обработчиков выхода; аргумент SYSCALL_STANDARD, определяющий соглашение вызова; и, наконец, уже знакомый void*, позволяющий передать пользовательскую структуру данных.

Назначение log_syscall - учитывать частоту каждого системного вызова. Для этого посредством PIN_GetSyscallNumber она получает номер текущего вызова и записывает его в карту syscalls.

Теперь, когда весь важный код профилировщика рассмотрен, проверим его!

В этом примере будет показано, как посредством Pin создать Pintool, автоматически распаковывающий упакованные бинарные файлы. Но сначала кратко обсудим, что они собой представляют, чтобы следующий пример был понятнее.

Начнём с кода настройки и основных структур данных распаковщика. В листинге 9-8 показана первая часть кода без стандартных включений C++.

Листинг 9-8. unpacker.cpp

Распаковщик отслеживает активность памяти, записывая байты, в которые производилась запись или которые исполнялись, в структуре mem_access_t. Она хранит вид доступа к памяти - запись или исполнение - и значение записанных байтов. Позднее, при сохранении памяти на диск, соседние байты потребуется объединять в кластеры. Для этого используется вторая структура mem_cluster_t, хранящая базовый адрес, размер и права доступа кластера памяти.

Есть четыре глобальные переменные. Первая - файл журнала, куда распаковщик записывает сведения о ходе распаковки и записанных областях памяти. Далее идёт глобальная карта std::map с именем shadow_mem: это "теневая память", сопоставляющая адресам объекты mem_access_t со сведениями о доступах и записях по каждому адресу. Вектор std::vector с именем clusters хранит все найденные распакованные кластеры памяти, а временная переменная saved_addr нужна для передачи состояния между двумя процедурами анализа.

clusters может содержать несколько распакованных областей памяти, поскольку бинарный файл иногда имеет несколько слоёв упаковки. Иными словами, уже упакованный файл можно снова упаковать другим упаковщиком. Обнаружив передачу управления в ранее записанную область памяти, распаковщик не может знать, является ли это переходом к OEP или всего лишь переходом к загрузочному коду следующего упаковщика. Поэтому он сохраняет на диск все найденные области-кандидаты, а определить, какой файл является окончательно распакованным бинарным файлом, предстоит вам.

У распаковщика есть лишь один параметр командной строки: ручка типа string, задающая имя файла журнала. По умолчанию он называется unpacker.log.

Как вы вскоре увидите, распаковщик регистрирует одну функцию завершения fini, которая вызывает print_clusters, чтобы записать в журнал сводку всех найденных кластеров памяти. Листинг этой функции здесь не приводится, поскольку она не использует возможности Pin, но при проверке распаковщика вы увидите её вывод.

Функция main распаковщика похожа на уже рассмотренную функцию профилировщика. Она инициализирует Pin, пропуская инициализацию символов, поскольку распаковщик их не использует. Затем открывает файл журнала, регистрирует процедуру инструментирования уровня инструкций instrument_mem_cflow и функцию завершения, после чего запускает упакованное приложение.

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

В листинге 9-9 показано, как instrument_mem_cflow инструментирует записи в память и инструкции передачи управления.

Листинг 9-9. unpacker.cpp (продолжение)

Первые три обратных вызова анализа, вставляемые instrument_mem_cflow, предназначены для отслеживания записей в память. Они добавляются только к инструкциям, для которых и INS_IsMemoryWrite, и INS_hasKnownMemorySize возвращают true. Первая функция сообщает, записывает ли инструкция в память, а вторая - известен ли размер записи в байтах. Это важно, поскольку распаковщик записывает изменённые байты в shadow_mem и может скопировать правильное число байтов, только если известен размер записи. Поскольку записи неизвестного размера выполняют лишь специальные инструкции, например MMX и SSE, распаковщик их просто игнорирует.

Для каждой записи в память распаковщику нужны адрес и размер, чтобы сохранить все записанные байты. К сожалению, в Pin адрес записи известен лишь до её выполнения - в точке IPOINT_BEFORE, - но скопировать байты можно только после записи. Поэтому instrument_mem_cflow вставляет для каждой записи несколько процедур анализа.

Сначала перед каждой записью добавляется обратный вызов queue_memwrite, сохраняющий эффективный адрес записи IARG_MEMORYWRITE_EA в глобальную переменную saved_addr. Затем для инструкций записи, имеющих ребро естественного продолжения, instrument_mem_cflow инструментирует это ребро обратным вызовом log_memwrite, который записывает все изменённые байты в shadow_mem. Параметр IARG_MEMORYWRITE_SIZE сообщает log_memwrite, сколько байтов нужно записать, начиная с saved_addr, сохранённого queue_memwrite перед записью. Аналогично, для записей в составе инструкции перехода или вызова распаковщик добавляет обратный вызов log_memwrite на выбранное ребро, гарантируя запись независимо от направления, выбранного приложением во время исполнения.

Как вы помните, задача распаковщика - обнаружить передачу управления исходной точке входа, а затем сохранить распакованный бинарный файл на диск. Для этого instrument_mem_cflow инструментирует косвенные переходы и вызовы обратным вызовом check_indirect_ctransfer - процедурой анализа, которая проверяет, направлен ли переход в прежде доступную для записи область памяти. Если да, она помечает его как возможный переход к OEP и сохраняет целевую область на диск.

Для оптимизации instrument_mem_cflow инструментирует только косвенные передачи управления, поскольку многие упаковщики используют косвенные переходы или вызовы для перехода к распакованному коду. Это верно не для всех упаковщиков; instrument_mem_cflow легко изменить так, чтобы она инструментировала все передачи управления, а не только косвенные, но ценой будет существенное падение производительности.

В листинге 9-10 показаны уже упоминавшиеся процедуры анализа, отвечающие за регистрацию записей в память.

Листинг 9-10. unpacker.cpp (продолжение)

Первая процедура анализа, queue_memwrite, вызывается перед каждой записью в память и сохраняет её адрес в глобальной переменной saved_addr. Это необходимо потому, что Pin позволяет исследовать адрес записи только в точке IPOINT_BEFORE.

После каждой записи в память - на ребре естественного продолжения или выбранном ребре - вызывается log_memwrite, которая записывает все изменённые байты в shadow_mem. Сначала она получает базовый адрес записи, читая saved_addr, а затем перебирает все записанные адреса. Каждый адрес помечается в shadow_mem как записанный, после чего PIN_SafeCopy копирует значение изменённого байта из памяти приложения в shadow_mem.

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

Возможно, вы заметили, что распаковщик игнорирует возвращаемое значение PIN_SafeCopy, показывающее число успешно прочитанных байтов. Если распаковщику не удалось прочитать память приложения, сделать уже ничего нельзя: распакованный код просто окажется повреждён. В других Pintool следует проверять возвращаемое значение и корректно обрабатывать ошибки.

Конечная задача распаковщика - обнаружить переход к OEP и сохранить распакованный код. Реализующая это процедура анализа показана в листинге 9-11.

Листинг 9-11. unpacker.cpp (продолжение)

Обнаружив предполагаемый переход к OEP, check_indirect_ctransfer строит кластер памяти из всех последовательных байтов вокруг OEP и сохраняет его на диск. Поскольку эта функция вызывается только на инструкциях передачи управления, она всегда помечает целевой адрес как исполняемый. Если адрес назначения лежит в области памяти, которая прежде была доступна для записи, это может быть переход к OEP; тогда распаковщик сохраняет целевую область, если ещё не делал этого. Для проверки он вызывает in_cluster, которая определяет, существует ли уже кластер памяти с данным адресом. Код in_cluster здесь не обсуждается, поскольку он не использует возможности Pin.

Рис. 9-7. Построение кластера памяти после передачи управления кандидату в OEP

Если целевая область ещё не распакована, check_indirect_ctransfer вызывает set_cluster, чтобы объединить память вокруг предполагаемой OEP в непрерывный фрагмент, пригодный для сохранения на диск, а затем добавляет его в clusters - глобальный список всех распакованных областей. Код set_cluster здесь не рассматривается, но рис. 9-7 показывает, как функция просто ищет в shadow_mem назад и вперёд от предполагаемой OEP, расширяя кластер на все соседние записанные байты, пока не встретит "пробел" из адресов памяти, куда не производилась запись.

Затем check_indirect_ctransfer распаковывает только что построенный кластер памяти, сохраняя его на диск. Вместо того чтобы считать распаковку успешной и завершать приложение, распаковщик продолжает работать как прежде: возможно, предстоит обнаружить и распаковать ещё один слой.

Проверим автоматический распаковщик, применив его к исполняемому файлу, упакованному известным упаковщиком UPX, который в Ubuntu устанавливается командой apt install upx. В листинге 9-12 показано, как упаковать тестовый бинарный файл с помощью UPX; Makefile этой главы делает это автоматически.

Листинг 9-12. Упаковка /bin/ls посредством UPX

Для этого примера скопируем /bin/ls в файл packed, а затем упакуем его посредством UPX. UPX сообщает, что бинарный файл успешно упакован и сжат до 45,18 процента исходного размера. Убедиться, что файл упакован, можно, открыв его в IDA Pro, как на рис. 9-8. В упакованном файле гораздо меньше функций, чем в большинстве бинарных файлов: IDA находит лишь четыре, поскольку все остальные упакованы. С помощью IDA также можно увидеть большую область данных с упакованным кодом и данными, не показанную на рисунке.

Рис. 9-8. Упакованный бинарный файл в IDA Pro

Теперь проверим, сможет ли распаковщик восстановить исходные код и данные ls из упакованного бинарного файла. Способ применения распаковщика показан в листинге 9-13.

Листинг 9-13. Проверка распаковщика бинарных файлов

Чтобы воспользоваться распаковщиком, вызовите pin с распаковщиком в качестве Pintool и упакованным файлом packed в качестве приложения. Приложение запускается с инструментированием распаковщика и, поскольку является копией /bin/ls, печатает содержимое каталога. В нём видно несколько распакованных файлов; схема их имён указывает начальный и конечный адреса сохранённой области и адрес точки входа, обнаруженный инструментирующим кодом.

Файл журнала unpacker.log подробно описывает извлечённые области и перечисляет все найденные распаковщиком кластеры памяти, даже не распакованные. Подробнее рассмотрим крупнейший распакованный файл unpacked.0x400000-0x41da64_entry-0x40000c.^[15] Команда file показывает, что это бинарный файл ELF, хотя и несколько "повреждённый": представление ELF в памяти напрямую не соответствует дисковому представлению, ожидаемому такими утилитами, как file. Например, таблица заголовков секций во время исполнения недоступна, поэтому распаковщик не может её восстановить. Тем не менее проверим, способны ли IDA Pro и другие утилиты разобрать распакованный файл.

Как видно на рис. 9-9, IDA Pro удаётся найти в распакованном бинарном файле гораздо больше функций, чем в упакованном, что обнадёживает.

Рис. 9-9. Распакованный бинарный файл в IDA Pro

Кроме того, утилита strings показывает, что распакованный бинарный файл содержит много удобочитаемых строк, указывающих на успешную распаковку, как в листинге 9-14.

Листинг 9-14. Строки, найденные в распакованном бинарном файле

Как вы помните из главы 5, strings - утилита Linux, показывающая найденные в любом файле удобочитаемые строки. Для распакованного бинарного файла она, среди множества других строк, выводит инструкцию по применению /bin/ls.

В качестве последней проверки здравого смысла сравним распакованный код с исходным кодом ls посредством objdump. В листинге 9-15 приведена часть исходной функции main из /bin/ls, а в листинге 9-16 - соответствующий распакованный код.

Исходный бинарный файл можно дизассемблировать обычным вызовом objdump, но для распакованного файла понадобятся специальные параметры: они велят objdump считать файл необработанным бинарным содержимым с кодом x86-64 и дизассемблировать всё содержимое файла (-D вместо обычного -d). Это необходимо потому, что в распакованном файле нет таблицы заголовков секций, по которой objdump мог бы определить расположение секций кода.

Листинг 9-15. Частичное дизассемблирование main в исходном /bin/ls

Листинг 9-16. Частичное дизассемблирование main в распакованном бинарном файле

Сравнив листинги 9-15 и 9-16 построчно, можно увидеть, что код идентичен, кроме адресов кода в инструкциях call. Причина в том, что из-за отсутствующей таблицы заголовков секций objdump не знает ожидаемый адрес загрузки распакованного бинарного файла. Кроме того, для распакованного файла objdump не может автоматически снабдить вызовы заглушек PLT именами соответствующих функций. К счастью, такие дизассемблеры, как IDA Pro, позволяют вручную задать адрес загрузки, и после некоторой настройки распакованный файл можно исследовать точно так же, как обычный!

Профилировщик записывает все системные вызовы, даже происходящие за пределами главного приложения. Измените профилировщик так, чтобы он проверял источник системного вызова и профилировал только вызовы из главного приложения. Чтобы узнать, как это сделать, потребуется обратиться к руководству пользователя Pin в интернете.

При проверке распаковщик сохранил несколько файлов, один из которых был распакованным /bin/ls. Исследуйте содержимое остальных файлов и выясните, почему распаковщик сохранил их.

Добавьте в автоматический распаковщик параметр командной строки, при включении которого он инструментирует все передачи управления, а не только косвенные, и ищет переход к OEP. Сравните время работы распаковщика с включённым и выключенным параметром. Как будет работать упаковщик, переходящий к OEP посредством прямой передачи управления?

Создайте Pintool, способный наблюдать за приложением, автоматически обнаруживать момент расшифрования данных с помощью RC4 - или выбранного вами криптографического алгоритма - и сохранять эти данные. Pintool разрешено выдавать ложноположительные результаты - посторонние данные, которые в действительности не были расшифрованы, - но он должен стремиться свести их число к минимуму.

На высоком уровне анализ помеченных данных состоит из трёх шагов: определения источников меток, определения приёмников меток и отслеживания распространения меток. При разработке инструмента на основе DTA первые два шага - определение источников и приёмников - выполняете вы. Третий шаг - отслеживание распространения - обычно берёт на себя существующая библиотека DTA, например libdft, хотя большинство таких библиотек позволяет при желании настраивать и его. Рассмотрим каждый из трёх шагов.

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

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

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

Аналогично, если требуется отслеживать данные, прочитанные из файла, источником меток служат системные вызовы наподобие read. Чтобы отслеживать числа, являющиеся произведением двух других чисел, можно помечать выходные операнды инструкций умножения, которые тогда становятся источниками меток, и так далее.

Приёмники меток - места программы, проверяемые на возможность влияния помеченных данных. Например, для обнаружения атак с перехватом потока управления можно инструментировать косвенные вызовы, косвенные переходы и инструкции возврата обратными вызовами, которые проверяют, влияют ли помеченные данные на адреса назначения этих инструкций. Такие инструментированные инструкции будут приёмниками меток. Библиотеки DTA предоставляют функции для проверки, помечены ли регистр или область памяти. Обычно при обнаружении метки в приёмнике требуется определённая реакция, например сигнал тревоги.

Как уже отмечалось, для отслеживания потока помеченных данных через программу необходимо инструментировать все инструкции, обрабатывающие данные. Инструментирующий код определяет, как метки распространяются с входных операндов инструкции на выходные. Например, если входной операнд инструкции mov помечен, инструментирующий код пометит и выходной операнд, поскольку на него явно влияет входной. Так помеченные данные могут в итоге распространиться от источника меток до приёмника.

Отслеживание меток сложно, поскольку не всегда очевидно, какие части выходного операнда следует помечать. Распространение подчиняется политике меток, определяющей отношения между входными и выходными операндами. Как будет объяснено в разделе 10.4, в зависимости от потребностей можно применять разные политики. Чтобы избавить вас от написания инструментирующего кода для всех инструкций, распространением обычно занимается специальная библиотека DTA, например libdft.

Теперь вы в общих чертах понимаете работу отслеживания меток. Рассмотрим на конкретном примере применение DTA для обнаружения утечки информации. В главе 11 вы научитесь создавать собственный инструмент для выявления именно такой уязвимости!

Чтобы увидеть практическую пользу DTA, рассмотрим обнаружение уязвимости Heartbleed в OpenSSL. OpenSSL - широко применяемая криптографическая библиотека, защищающая обмен данными в интернете, в том числе соединения с веб-сайтами и почтовыми серверами. Heartbleed позволяет извлекать информацию из систем, использующих уязвимую версию OpenSSL. Среди неё могут быть чрезвычайно чувствительные сведения, например закрытые ключи, имена пользователей и пароли, находящиеся в памяти.

Heartbleed использует классическое чтение за границами буфера в реализации протокола Heartbeat в OpenSSL. Учтите: Heartbeat - название эксплуатируемого протокола, а Heartbleed - название эксплойта. Протокол Heartbeat позволяет устройствам проверять, активно ли ещё соединение с сервером SSL, отправляя серверу запрос Heartbeat с произвольной строкой символов, заданной отправителем. Если всё в порядке, сервер отвечает сообщением Heartbeat, возвращающим ту же строку.

Помимо строки символов, запрос Heartbeat содержит поле, задающее её длину. Именно неправильная обработка этого поля приводит к уязвимости Heartbleed. Уязвимые версии OpenSSL позволяют атакующему указать длину, намного превышающую фактическую длину строки, из-за чего при копировании строки в ответ сервер раскрывает дополнительные байты памяти.

Код OpenSSL, ответственный за ошибку Heartbleed, показан в листинге 10-1. Кратко разберём его работу, а затем рассмотрим, как DTA обнаруживает связанные с Heartbleed утечки информации.

Листинг 10-1. Код, вызывающий уязвимость Heartbleed в OpenSSL

Код листинга 10-1 входит в функцию OpenSSL, которая готовит ответ Heartbeat после получения запроса. Три важнейшие переменные - pl, payload и bp. pl - указатель на строку полезной нагрузки в запросе Heartbeat, которая будет скопирована в ответ. Несмотря на вводящее в заблуждение имя, payload - не указатель на строку, а значение unsigned int, задающее её длину. И pl, и payload берутся из сообщения запроса Heartbeat, поэтому в контексте Heartbleed ими управляет атакующий. bp - указатель внутрь буфера ответа, куда копируется строка.

Сначала код выделяет буфер ответа и направляет bp в его начало. Обратите внимание: размером буфера через переменную payload управляет атакующий. Первый байт содержит тип пакета TLS1_HB_RESPONSE, то есть ответ Heartbeat. Следующие 2 байта содержат длину полезной нагрузки, просто скопированную макросом s2n из управляемой атакующим переменной payload.

Затем выполняется основная операция уязвимости Heartbleed: memcpy копирует payload байтов по указателю pl в буфер ответа. Вспомните, что и payload, и строка по адресу pl находятся под контролем атакующего. Поэтому, передав короткую строку и большое значение payload, можно заставить memcpy продолжить копирование за пределами строки запроса и раскрыть всё, что случайно находится в соседней памяти. Так можно получить до 64 Кбайт данных. Наконец, после добавления в конец ответа нескольких случайных байтов заполнения ответ с раскрытой информацией отправляется атакующему по сети.

На рис. 10-1 показано, как DTA позволяет обнаружить такую утечку информации, и изображено происходящее в памяти системы, атакуемой через Heartbleed. Для этого примера предположим, что запрос Heartbeat хранится в памяти рядом с секретным ключом и что ключ помечен, чтобы можно было отследить его копирование. Также предположим, что системные вызовы send и sendto служат приёмниками меток и обнаруживают все помеченные данные, готовые к отправке по сети. Для простоты на рисунке показаны только относящиеся к делу строки в памяти без полей типа и длины сообщений запроса и ответа.

На рис. 10-1a показано состояние сразу после получения запроса Heartbeat, подготовленного атакующим. Запрос содержит строку полезной нагрузки foobar, которая оказалась в памяти рядом с несколькими случайными байтами, обозначенными ?, и секретным ключом. Переменная pl указывает на начало строки, а атакующий установил payload в 21, чтобы раскрыть 15 байтов рядом со строкой.^[1] Секретный ключ помечен, чтобы обнаружить его утечку по сети, а буфер ответа выделен в другом месте памяти.

Рис. 10-1. Чтение за границами буфера Heartbleed раскрывает секретный ключ в буфер ответа, который отправляется по сети. Метка ключа позволяет обнаружить чтение за границами при отправке раскрытой информации. (a) Полученный запрос Heartbeat хранится в памяти рядом со случайными данными и помеченным секретным ключом. (b) Полезная нагрузка Heartbeat копируется в буфер ответа с чтением за границами в секретный ключ, из-за чего метка распространяется в буфер

Далее на рис. 10-1b показано выполнение уязвимой memcpy. Как и положено, сначала она копирует строку foobar, но поскольку атакующий установил payload в 21, копирование продолжается и после 6 байтов строки полезной нагрузки. memcpy читает за границами сначала случайные данные рядом со строкой, а затем секретный ключ. В результате ключ попадает в буфер ответа, готовый к отправке по сети.

Без анализа помеченных данных на этом всё было бы кончено: буфер ответа вместе с раскрытым секретным ключом отправился бы атакующему. К счастью, в этом примере утечку предотвращает DTA. Когда копируется секретный ключ, механизм DTA замечает копирование помеченных байтов и помечает выходные байты. После завершения memcpy проверка перед сетевым вызовом send обнаруживает помеченную часть буфера ответа и тем самым выявляет атаку Heartbleed.

Это лишь одно из множества применений динамического анализа помеченных данных; некоторые другие будут рассмотрены в главе 11. Как уже отмечалось, из-за значительного замедления запускать такой DTA на промышленном сервере не стоит. Однако описанный анализ хорошо сочетается с фаззингом - проверкой безопасности приложения или библиотеки наподобие OpenSSL посредством псевдослучайно сгенерированных входных данных, например запросов Heartbeat, в которых строка полезной нагрузки и поле длины не соответствуют друг другу.

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

В этом примере метка распространялась просто: помеченный секретный ключ напрямую копировался в выходной буфер. Далее будут рассмотрены более сложные виды распространения меток через более сложные потоки данных.

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

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

Гранулярность меток - единица информации, на уровне которой система DTA отслеживает метки. Например, система с побитовой гранулярностью хранит сведения о метке каждого отдельного бита регистра или памяти, а система с побайтовой гранулярностью - лишь каждого байта. Если в определённом байте помечен хотя бы 1 бит, побайтовая система пометит весь байт. Аналогично, система с гранулярностью машинного слова хранит сведения для каждого слова памяти, и так далее.

Чтобы наглядно показать различие между побитовой и побайтовой гранулярностью, рассмотрим распространение метки через побитовую операцию И (&) над двумя байтовыми операндами, один из которых помечен. В следующем примере все биты каждого операнда показаны отдельно. Каждый бит заключён в рамку: белые рамки обозначают непомеченные биты, серые - помеченные. Сначала посмотрим на распространение метки в системе с побитовой гранулярностью:

Как видно, все биты первого операнда помечены, а во втором не помечен ни один. Поскольку выполняется побитовая операция И, каждый выходной бит может стать равным 1, только если соответствующие биты обоих входных операндов равны 1. Иными словами, если атакующий управляет только первым входным операндом, то повлиять он может лишь на те позиции выходного результата, где во втором операнде находится 1. Все остальные выходные биты всегда будут равны 0. Поэтому в примере помечен только один выходной бит: это единственная позиция, которой может управлять атакующий, поскольку только там во втором операнде находится 1. Фактически непомеченный второй операнд служит "фильтром" метки первого.^[2]

Теперь сравним с той же операцией в системе DTA с побайтовой гранулярностью. Входные операнды остаются прежними.

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

Как видно, гранулярность системы DTA - важный фактор точности: в зависимости от входных данных побайтовая система может быть менее точна, чем побитовая. С другой стороны, гранулярность существенно влияет и на производительность. Инструментирующий код для отдельного отслеживания каждого бита сложен и создаёт большие накладные расходы. Побайтовые системы менее точны, но допускают простые правила распространения, требующие лишь простого инструментирующего кода. В общем случае побайтовые системы намного быстрее побитовых. На практике большинство систем DTA выбирает побайтовую гранулярность как разумный компромисс между точностью и скоростью.

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

Аналогично, в системах DTA иногда требуется знать не только наличие метки, но и её источник. Несколько цветов меток позволяют назначить отдельный цвет каждому источнику, чтобы при достижении приёмника точно определить, какой источник на него влияет.

В побайтовой системе DTA с одним цветом для метки каждого байта памяти нужен лишь один бит. Для поддержки нескольких цветов требуется хранить больше сведений на каждый байт. Например, для восьми цветов нужен 1 байт меток на каждый байт памяти.

На первый взгляд может показаться, что в 1 байте информации о метке можно хранить 255 разных цветов, поскольку байт имеет 255 различных ненулевых значений.

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

Для поддержки смешивания каждому цвету нужен отдельный бит. Например, имея 1 байт сведений о метке, можно поддерживать цвета 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40 и 0x80. Если определённое значение помечено сразу цветами 0x01 и 0x02, объединённая метка будет равна 0x03 - результату побитового ИЛИ двух цветов. Для удобства цвета меток можно представлять как реальные цвета: например, называть 0x01 "красным", 0x02 - "синим", а объединённый цвет 0x03 - "фиолетовым".

Политика меток системы DTA описывает, как система распространяет метки и объединяет их цвета при слиянии нескольких потоков. В табл. 10-1 показано распространение через несколько разных операций в примере политики для побайтовой системы DTA с двумя цветами: "красным" (R) и "синим" (B). Все операнды примеров состоят из 4 байтов. Возможны и другие политики, особенно для сложных операций, выполняющих нелинейные преобразования операндов.

Таблица 10-1. Примеры распространения меток для побайтовой системы DTA с двумя цветами: красным (R) и синим (B)

В первом примере значение переменной a присваивается переменной c, что эквивалентно инструкции x86 mov. Для такой простой операции правила распространения столь же прямолинейны: поскольку выход c - всего лишь копия a, сведения о метке c копируются из a. Иными словами, оператор объединения здесь :=, то есть присваивание.

Следующий пример - операция xor, c = a ⊕ b. Просто назначить выходу метку одного из входных операндов нельзя, поскольку результат зависит от обоих. Распространённая политика - побайтовое объединение (∪) меток входных операндов. Например, старший байт первого операнда помечен красным (R), а второго - синим (B). Поэтому метка старшего выходного байта представляет собой их объединение: одновременно красный и синий (RB).

Та же политика побайтового объединения применяется к сложению в третьем примере. Здесь есть особый случай: сумма двух байтов может породить бит переполнения, переходящий в младший значащий бит соседнего байта. Предположим, атакующий управляет лишь младшим байтом одного операнда. Тогда в особом случае он способен вызвать перенос 1 бита в соседний байт и тем самым частично повлиять на его значение. Политика может учитывать это явной проверкой переполнения и помечать соседний байт при его возникновении. На практике многие системы DTA ради простоты и скорости такую проверку не выполняют.

Четвёртый пример - особый случай xor. Операция операнда с самим собой, c = a ⊕ a, всегда даёт ноль. Даже если атакующий управляет a, выход c ему неподконтролен. Поэтому политика очищает метку каждого выходного байта, устанавливая её в пустое множество (∅).

Далее показан сдвиг влево на постоянное значение: c = a << 6. Поскольку второй операнд постоянен, атакующий, даже частично управляя входом a, не всегда способен повлиять на все выходные байты. Разумная политика распространяет входную метку лишь на те выходные байты, которые частично или полностью покрываются одним из помеченных входных байтов, фактически "сдвигая метку влево". Здесь атакующий управляет только младшим байтом a, который сдвигается влево на 6 бит, поэтому его метка распространяется на два младших выходных байта.

В последнем примере и сдвигаемое значение a, и величина сдвига b являются переменными. Атакующий, управляющий b, как в примере, способен повлиять на все выходные байты. Поэтому метка b назначается каждому выходному байту.

Библиотеки DTA наподобие libdft имеют заранее определённую политику, избавляя вас от реализации правил для всех видов инструкций. Однако для конкретного инструмента можно скорректировать правила тех инструкций, для которых политика по умолчанию не вполне подходит. Например, в инструменте обнаружения утечек информации можно повысить производительность, отключив распространение через инструкции, изменяющие данные до неузнаваемости.

В зависимости от политики система DTA может страдать от недостаточного помечивания, избыточного помечивания или обеих проблем.

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

Например, библиотеки DTA наподобие libdft обычно не имеют встроенной поддержки инструкций x86 MMX или SSE, поэтому проходящая через них метка может потеряться. К недостаточному помечиванию приводят и зависимости управления, которые будут рассмотрены ниже.

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

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

Вспомните, что отслеживание меток применяется для наблюдения за потоками данных. Однако иногда на потоки данных неявно влияют управляющие конструкции наподобие ветвлений, образуя так называемый неявный поток. Практический пример встретится в главе 11, а пока рассмотрим искусственный:

Здесь атакующий, управляющий условием цикла cond, способен определить значение var. Это называется зависимостью управления. Хотя через cond атакующий управляет var, явного потока данных между переменными нет. Поэтому система DTA, отслеживающая только явные потоки, не заметит зависимость и оставит var непомеченной, даже если cond помечена, что приведёт к недостаточному помечиванию.

Некоторые исследовательские работы пытались решить проблему распространением меток из условий ветвлений и циклов на операции, выполняемые вследствие этого ветвления или цикла. В нашем примере это означало бы распространение метки из cond в var. К сожалению, такой подход приводит к огромному избыточному помечиванию, поскольку ветвления по помеченным условиям распространены даже без атаки. Например, рассмотрим следующую проверку очистки пользовательского ввода:

Предположим, весь пользовательский ввод помечается для проверки атак, а метка user_input распространяется на возвращаемое значение функции is_safe, используемое как условие ветвления. Если пользовательский ввод очищается правильно, листинг совершенно безопасен, несмотря на помеченное условие ветвления.

Но системы DTA, пытающиеся отслеживать зависимости управления, не могут отличить эту ситуацию от опасной в предыдущем листинге. Они всегда в итоге помечают funcptr - указатель на функцию-обработчик пользовательского ввода. При последующем вызове помеченной funcptr могут возникать ложные сигналы тревоги. Столь массовые ложноположительные результаты способны сделать систему совершенно непригодной.

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

Уязвимости форматной строки - хорошо известный класс эксплуатируемых ошибок программ на C-подобных языках. Они возникают, когда функция printf получает управляемую пользователем форматную строку, как в printf(user), вместо правильного printf("%s", user). Хорошее введение в уязвимости форматной строки дано в статье "Exploiting Format String Vulnerabilities", доступной по адресу http://julianor.tripod.com/bc/formatstring-1.2.pdf.

Спроектируйте инструмент DTA, способный обнаруживать эксплойты форматной строки, запускаемые из сети или командной строки. Какими должны быть источники и приёмники меток и какие распространение и гранулярность нужны? В конце главы 11 вы сможете реализовать своё средство обнаружения эксплойтов!

Поскольку DTA остаётся предметом активных исследований, существующие библиотеки отслеживания меток на уровне бинарного кода являются исследовательскими инструментами; не ожидайте от них промышленного качества. Это относится и к разработанной в Колумбийском университете libdft, которая будет использоваться в оставшейся части главы.

Libdft - построенная на Intel Pin система отслеживания меток с побайтовой гранулярностью и одна из самых простых в применении библиотек DTA на сегодняшний день. Многие исследователи безопасности предпочитают именно её, поскольку она позволяет легко создавать одновременно точные и быстрые инструменты DTA. Libdft предустановлена на виртуальной машине в каталоге /home/binary/libdft. Её также можно загрузить по адресу https://www.cs.columbia.edu/~vpk/research/libdft/.

Как и все доступные на момент написания библиотеки DTA бинарного уровня, libdft имеет несколько недостатков. Самый очевидный: поддерживается только 32-разрядная x86. Библиотеку можно использовать на 64-разрядной платформе, но анализировать лишь 32-разрядные процессы. Она также зависит от устаревших версий Pin - должны работать версии с 2.11 по 2.14. Другое ограничение: libdft поддерживает только "обычные" инструкции x86, но не расширенные наборы MMX или SSE. Поэтому при прохождении меток через такие инструкции возможно недостаточное помечивание. Если анализируемая программа собирается из исходного кода, применяйте параметры компиляции gcc -mno-{mmx, sse, sse2, sse3}, чтобы бинарный файл не содержал инструкций MMX или SSE.

Несмотря на ограничения, libdft остаётся отличной библиотекой DTA для создания надёжных инструментов. Поскольку её исходный код открыт, библиотеку сравнительно легко расширить поддержкой 64-разрядной архитектуры или дополнительных инструкций. Чтобы вы могли полноценно пользоваться libdft, рассмотрим важнейшие детали её реализации.

Политика распространения libdft определяет следующие пять классов инструкций.^[2] Каждый класс распространяет и объединяет метки по-своему.

ALU. Арифметические и логические инструкции с двумя или тремя операндами, например add, sub, and, xor, div и imul. Для этих операций libdft объединяет метки так же, как в примерах add и xor из табл. 10-1 на странице 299: выходная метка представляет собой объединение (∪) меток входных операндов. Как и в табл. 10-1, непосредственные значения считаются непомеченными, поскольку атакующий не может на них повлиять.

XFER. Класс XFER содержит все инструкции, копирующие значение в другой регистр или область памяти, например mov. Они обрабатываются так же, как пример mov в табл. 10-1, посредством операции присваивания (:=). Libdft просто копирует метку исходного операнда в операнд назначения.

CLR. Как следует из названия, инструкции этого класса всегда снимают метку с выходных операндов. Иными словами, libdft устанавливает выходную метку в пустое множество (∅). Класс включает некоторые особые случаи инструкций других классов, например xor операнда с самим собой или вычитание операнда из себя. Сюда входят и инструкции наподобие cpuid, на выходы которых атакующий не может повлиять.

SPECIAL. Инструкции, требующие специальных правил распространения, не охваченных другими классами. Среди них xchg и cmpxchg, где метки двух операндов меняются местами, а также lea, метка которой является результатом вычисления адреса памяти.

FPU, MMX, SSE. Этот класс включает инструкции, пока не поддерживаемые libdft: FPU, MMX и SSE. Когда метка проходит через такую инструкцию, libdft не может её отследить, поэтому сведения не распространяются на выходные операнды, приводя к недостаточному помечиванию.

Теперь, познакомившись с libdft, создадим с её помощью несколько инструментов DTA!

Первый инструмент DTA предназначен для обнаружения некоторых видов удалённых атак с перехватом управления. В частности, он обнаруживает атаки, где полученные из сети данные управляют аргументами вызова execve. Поэтому источниками меток будут сетевые функции приёма recv и recvfrom, а системный вызов execve - приёмником. Полный исходный код, как обычно, находится на виртуальной машине в ~/code/chapter11.

Чтобы обсуждение было понятнее, я сделал пример как можно проще. Это неизбежно требует упрощающих предположений, и инструмент обнаружит не все виды атак с перехватом. В полномасштабном инструменте DTA следует определить дополнительные источники и приёмники. Например, помимо данных из recv и recvfrom, нужно учитывать данные, прочитанные из сети системным вызовом read. А чтобы не помечать безобидное чтение файлов, придётся отслеживать файловые дескрипторы, читающие из сети, перехватывая сетевые вызовы наподобие accept.

Разобравшись с работой следующего примера, вы сможете усовершенствовать его самостоятельно. Кроме того, libdft содержит более сложный пример инструмента DTA, реализующий многие из этих усовершенствований. Он находится в файле tools/libdft-dta.c каталога libdft.

Многие инструменты DTA на libdft перехватывают системные вызовы, используя их как источники и приёмники меток. В Linux у каждого системного вызова свой номер, которым libdft индексирует массив syscall_desc. Список доступных системных вызовов и номеров находится в /usr/include/x86_64-linux-gnu/asm/unistd_32.h для 32-разрядной x86 или /usr/include/asm-generic/unistd.h для x64.^[3]

Рассмотрим пример инструмента dta-execve. Первая часть исходного кода приведена в листинге 11-1.

Листинг 11-1. dta-execve.cpp

Здесь показаны только заголовочные файлы, специфичные для инструментов DTA на libdft; опущенный код можно найти в исходном файле на виртуальной машине.

Первый заголовок - pin.H, поскольку все инструменты libdft являются Pintool, скомпонованными с библиотекой libdft. Затем идут несколько заголовков, совместно предоставляющих доступ к API libdft. Первый, branch_pred.h, содержит макросы likely и unlikely, которыми можно давать компилятору подсказки для предсказания ветвлений. Далее libdft_api.h, syscall_desc.h и tagmap.h предоставляют доступ соответственно к базовому API libdft, интерфейсу перехвата системных вызовов и карте тегов - теневой памяти.

После включений объявлен внешний массив syscall_desc - структура данных libdft для отслеживания перехватчиков системных вызовов. Доступ к ней нужен для подключения источников и приёмников меток. Фактическое определение syscall_desc находится в исходном файле libdft syscall_desc.c.

Рассмотрим функцию main инструмента dta-execve. Сначала она инициализирует обработку символов Pin на случай, если в бинарном файле есть символы, а затем саму Pin. Код инициализации Pin встречался в главе 9, но теперь возвращаемое значение PIN_Init проверяется оптимизированным ветвлением, помеченным макросом unlikely, который сообщает компилятору, что ошибка PIN_Init маловероятна. Это знание помогает предсказывать ветвление и может позволить компилятору выдать немного более быстрый код.

Затем main инициализирует libdft посредством libdft_init, снова с оптимизированной проверкой результата. Инициализация настраивает важнейшие структуры, например карту тегов. При ошибке libdft_init возвращает ненулевое значение; тогда нужно вызвать libdft_die, чтобы освободить все ресурсы, которые могла выделить библиотека.

После инициализации Pin и libdft можно установить перехватчики системных вызовов - источники и приёмники меток. Помните, что соответствующий перехватчик вызывается всякий раз, когда инструментированное приложение выполняет системный вызов. Здесь dta-execve устанавливает два: последующий обработчик post_socketcall_hook, выполняемый после каждого socketcall, и предварительный pre_execve_hook, выполняемый перед execve. Системный вызов socketcall охватывает все связанные с сокетами события в 32-разрядной Linux x86, включая recv и recvfrom. Его обработчик различает виды сетевых событий, как будет объяснено далее.

Для установки обработчика вызывается syscall_set_post для последующего либо syscall_set_pre для предварительного. Обе функции принимают указатель на запись массива syscall_desc, куда устанавливается обработчик, и указатель на саму функцию. Нужная запись получается индексированием syscall_desc номером перехватываемого системного вызова. Здесь номера представлены символьными именами __NR_socketcall и __NR_execve, которые для x86-32 находятся в /usr/include/i386-linux-gnu/asm/unistd_32.h.

Наконец, PIN_StartProgram запускает инструментированное приложение. Как вы помните из главы 9, эта функция никогда не возвращает управление, поэтому return 0 в конце main недостижим.

Хотя в примере это не используется, libdft позволяет перехватывать инструкции почти так же, как системные вызовы:

Для перехвата инструкций в инструменте DTA глобально объявляется внешний массив ins_desc, аналогичный syscall_desc, а затем посредством ins_set_pre или ins_set_post устанавливаются предварительные или последующие обработчики. Вместо номеров системных вызовов ins_desc индексируется символьными именами библиотеки Intel XED, поставляемой с Pin. XED определяет эти имена в перечислении xed_iclass_enum_t; каждое обозначает класс инструкции, например X86_ICLASS_RET_NEAR. Имена классов соответствуют мнемоникам. Полный список доступен на https://intelxed.github.io/ref-manual/ или в поставляемом с Pin заголовке xed-iclass-enum.h.^[4]

В предыдущем разделе вы увидели, как main инструмента dta-execve выполняет всю необходимую инициализацию, настраивает перехватчики системных вызовов - источники и приёмники меток, - а затем запускает приложение. Здесь приёмником служит pre_execve_hook, который проверяет, помечены ли аргументы execve, что указывает на атаку с перехватом управления. Если да, он подаёт сигнал тревоги и останавливает атаку, аварийно завершая приложение. Поскольку проверка повторяется для каждого аргумента execve, она вынесена в функцию check_string_taint.

Сначала разберём check_string_taint, а затем в разделе 11.2.3 перейдём к pre_execve_hook. В листинге 11-2 приведена check_string_taint вместе с функцией alert, вызываемой при обнаружении атаки.

Листинг 11-2. dta-execve.cpp (продолжение)

Функция alert просто печатает сообщение с подробностями о помеченном адресе, а затем вызывает exit, останавливая приложение и предотвращая атаку. Сама логика проверки реализована в check_string_taint, принимающей две строки. Первая, str, проверяется на наличие меток, а вторая, source, является диагностической строкой, передаваемой в alert и печатаемой ею; она задаёт источник первой строки: путь execve, аргумент execve или параметр окружения.

Для проверки str функция check_string_taint перебирает все её байты. Для каждого состояние метки проверяется функцией libdft tagmap_getb. Если байт помечен, вызывается alert, которая печатает ошибку и завершает программу.

tagmap_getb принимает адрес байта памяти в форме uintptr_t и возвращает теневой байт с цветом метки этого адреса. Цвет, названный в листинге tag, имеет тип uint8_t, поскольку libdft хранит один теневой байт на байт памяти. Если tag равен нулю, байт не помечен; иначе он помечен, а по цвету можно определить источник. Поскольку у этого инструмента DTA только один источник - сетевой приём, - используется единственный цвет.

Иногда требуется получить тег нескольких байтов памяти сразу. Для этого libdft предоставляет функции tagmap_getw и tagmap_getl, аналогичные tagmap_getb, но возвращающие соответственно два или четыре последовательных теневых байта в форме uint16_t или uint32_t.

Теперь вы знаете, как проверять цвет метки заданного адреса памяти. Рассмотрим первоначальное помечивание байтов. В листинге 11-3 показан код post_socketcall_hook - источника меток, вызываемого сразу после каждого системного вызова socketcall и помечающего байты, полученные из сети.

Листинг 11-3. dta-execve.cpp (продолжение)

В libdft перехватчики системных вызовов наподобие post_socketcall_hook - функции void, принимающие единственный аргумент syscall_ctx_t*. В листинге аргумент назван ctx и служит дескриптором только что произошедшего системного вызова. Помимо прочего, он содержит переданные вызову аргументы и возвращаемое значение. Перехватчик исследует ctx, чтобы определить, какие байты, если они есть, следует пометить.

Системный вызов socketcall принимает два аргумента, что можно проверить командой man socketcall. Первый - целое call, определяющее вид socketcall, например recv или recvfrom. Второй, args, содержит блок аргументов для socketcall в форме unsigned long*. Сначала post_socketcall_hook извлекает call и args из контекста ctx. Аргумент читается из соответствующей записи поля arg, например ctx->arg[SYSCALL_ARG0], и приводится к правильному типу.

Затем dta-execve посредством switch различает возможные виды call. Если это событие SYS_RECV или SYS_RECVFROM, инструмент подробнее исследует полученные байты, которые нужно пометить. Все прочие события просто игнорируются в ветви default.

Если событие является приёмом, dta-execve проверяет возвращаемое значение socketcall в ctx->ret. Значение меньше или равное нулю означает, что байты не получены, поэтому помечивать нечего и перехватчик возвращает управление. Исследовать возвращаемое значение можно только в последующем обработчике: в предварительном системный вызов ещё не произошёл.

Если байты получены, нужно разобрать массив args, обратиться к аргументам recv или recvfrom и найти адрес приёмного буфера. Массив содержит аргументы в том же порядке, что и соответствующая виду call сокетная функция. Для recv и recvfrom элемент args[0] содержит номер файлового дескриптора сокета, а args[1] - адрес приёмного буфера. Остальные аргументы здесь не нужны. Имея адрес буфера и возвращаемое значение socketcall, указывающее число полученных байтов, post_socketcall_hook может пометить все байты.

После диагностической печати post_socketcall_hook вызывает tagmap_setn - функцию libdft, помечающую произвольное число байтов. Первый параметр uintptr_t представляет начальный адрес памяти, второй size_t задаёт число байтов, а третий uint8_t - цвет метки. Здесь используется цвет 0x01. Теперь все полученные байты помечены, и если они повлияют на какой-либо вход execve, dta-execve заметит это и подаст сигнал.

Для пометки небольшого фиксированного числа байтов libdft также предоставляет tagmap_setb, tagmap_setw и tagmap_setl, помечающие соответственно один, два или четыре последовательных байта. Их аргументы эквивалентны tagmap_setn, кроме отсутствующего параметра длины.

Наконец, рассмотрим pre_execve_hook - перехватчик, выполняемый перед каждым execve и проверяющий отсутствие меток во входных данных. Код приведён в листинге 11-4.

Листинг 11-4. dta-execve.cpp (продолжение)

Сначала pre_execve_hook разбирает входные данные execve из параметра ctx: имя файла запускаемой программы, массив аргументов и массив окружения. Если любой из этих входов помечен, перехватчик подаст сигнал тревоги.

Для проверки каждого входа применяется функция check_string_taint из листинга 11-2. Сначала она проверяет, что параметр имени файла execve не помечен. Затем pre_execve_hook перебирает все аргументы execve и проверяет каждый. Наконец, перебирается массив окружения и проверяется каждый его параметр. Если ни один вход не помечен, pre_execve_hook завершается и системный вызов execve продолжается без сигнала тревоги. Если же найден помеченный вход, программа аварийно завершается и печатает сообщение об ошибке.

Это весь код инструмента dta-execve! Как видите, libdft позволяет реализовывать DTA лаконично. В данном случае пример состоит всего из 165 строк, включая комментарии и диагностическую печать. Рассмотрев весь код dta-execve, проверим, насколько хорошо он обнаруживает атаки.

Предыдущему инструменту был нужен лишь один цвет: байты либо управляются атакующим, либо нет. Теперь создадим многоцветный инструмент для обнаружения утечек информации из файлов, позволяющий определить, какой именно файл утёк. Идея похожа на защиту от Heartbleed из главы 10, но источником служит чтение файлов, а не буферы памяти.

Первая часть нового инструмента dta-dataleak показана в листинге 11-10. Стандартные заголовки C снова опущены.

Листинг 11-10. dta-dataleak.cpp

Как и предыдущий инструмент, dta-dataleak включает pin.H и все нужные заголовки libdft. Есть и знакомое внешнее объявление массива syscall_desc для перехвата системных вызовов, служащих источниками и приёмниками. Кроме того, определены новые структуры данных.

Первая, fd2color, - карта C++, сопоставляющая файловые дескрипторы цветам меток. Вторая, color2fname, сопоставляет цвета именам файлов. Их назначение станет понятно из следующих листингов.

Определена и константа MAX_COLOR - максимально возможное значение цвета 0x80.

Функция main почти идентична функции dta-execve: она инициализирует Pin и libdft, а затем запускает приложение. Различаются лишь источники и приёмники. Устанавливаются два последующих обработчика post_open_hook и post_read_hook, выполняемые после open и read. Перехватчик open отслеживает открытые файловые дескрипторы, а read служит собственно источником и помечает прочитанные из открытых файлов байты.

Кроме того, dta-dataleak устанавливает предварительный обработчик socketcall pre_socketcall_hook. Это приёмник меток, который перехватывает данные, готовые к отправке по сети, чтобы проверить отсутствие меток перед разрешением отправки. Если готовятся к утечке помеченные данные, pre_socketcall_hook вызывает функцию alert, которую мы сейчас рассмотрим.

Помните, что пример упрощён. В реальном инструменте для полноты следует перехватывать дополнительные источники, например системный вызов readv, и приёмники, например write в сокет. Также нужны правила, определяющие, какие файлы разрешено отправлять по сети, а какие нет, вместо предположения, что любая утечка файла вредоносна.

Рассмотрим функцию alert из листинга 11-11, вызываемую перед утечкой помеченных данных по сети. Поскольку она похожа на функцию dta-execve, описание будет кратким.

Листинг 11-11. dta-dataleak.cpp (продолжение)

Сначала alert выводит сообщение с адресом и цветами метки. Утекающие данные могут зависеть от нескольких файлов и потому иметь несколько цветов. Поэтому функция перебирает все возможные цвета и проверяет, какие присутствуют в теге байта, вызвавшего сигнал. Для каждого включённого цвета печатаются сам цвет и соответствующее имя файла из color2fname. Наконец, alert вызывает exit, останавливая приложение и предотвращая утечку.

Теперь рассмотрим источники меток dta-dataleak.

Наконец, в листинге 11-14 показан приёмник dta-dataleak - обработчик socketcall, перехватывающий сетевые отправки и проверяющий попытки утечки данных. Он похож на обработчик dta-execve, но проверяет метки отправляемых байтов вместо помечивания полученных.

Листинг 11-14. dta-dataleak.cpp (продолжение)

Сначала pre_socketcall_hook получает параметры call и args системного вызова. Затем применяется switch по call, подобный обработчику dta-execve, но теперь исследуются SYS_SEND и SYS_SENDTO, а не SYS_RECV и SYS_RECVFROM. При перехвате отправки разбираются аргументы: файловый дескриптор сокета, буфер и число отправляемых байтов. После диагностической печати код перебирает все байты буфера и получает состояние каждого посредством tagmap_getb. При обнаружении метки pre_socketcall_hook вызывает alert, которая печатает предупреждение и останавливает приложение.

Это весь код dta-dataleak. В следующем разделе вы увидите, как он обнаруживает попытку утечки и как объединяются цвета, когда утекающие данные зависят от нескольких источников.

Для демонстрации возможностей dta-dataleak реализован ещё один простой сервер dataleak-test-xor. Ради простоты он "выдаёт" помеченные файлы в сокет добровольно, но инструмент точно так же обнаружит утечку через эксплойт. Относящийся к делу код сервера показан в листинге 11-15.

Листинг 11-15. dataleak-test-xor.c

Сервер открывает сокет на localhost, порт 9999, и принимает сообщение со списком имён файлов. Он разделяет список посредством опущенной функции split_filenames. Затем открывает все запрошенные файлы и случайно выбирает два. В реалистичном сценарии dta-dataleak доступ к файлам происходил бы через эксплойт, а не добровольно предоставлялся сервером. Для этого примера сервер построчно читает два выбранных файла и объединяет каждую пару строк операцией XOR. Это заставит dta-dataleak объединить их цвета, демонстрируя слияние меток. Наконец, результат XOR двух строк отправляется по сети, создавая "утечку", которую должен обнаружить инструмент.

Посмотрим, как dta-dataleak обнаруживает попытку и объединяет цвета, когда утекающие данные зависят от нескольких файлов. Вывод защищённой программы dataleak-test-xor показан в листинге 11-16. Повторяющиеся части сокращены до ....

Листинг 11-16. Обнаружение попытки утечки данных посредством dta-dataleak

В примере сервер dataleak-test-xor запускается с Pin и dta-dataleak в качестве Pintool для защиты от утечек. Сразу происходит первый read, связанный с загрузкой dataleak-test-xor. Поскольку байты читаются из разделяемой библиотеки без назначенного цвета, инструмент игнорирует чтение.

Затем начинается сеанс netcat с подключением к серверу и отправляется список открываемых файлов. dta-dataleak перехватывает события open и назначает каждому цвет. Сервер случайно выбирает два файла для утечки; здесь это дескрипторы 8 и 5.

Для обоих файлов dta-dataleak перехватывает read и помечает прочитанные байты цветами 0x08 и 0x01. Затем он перехватывает попытку отправить содержимое файлов, объединённое XOR, по сети.

Проверяя метки отправляемых байтов, инструмент замечает тег 0x09, печатает сигнал тревоги и прерывает программу. Тег 0x09 - объединение цветов 0x01 и 0x08. По сообщению видно, что им соответствуют файлы dta-execve.cpp и echo.c.

Как видите, анализ меток позволяет легко обнаруживать утечки и точно определять выданные файлы. Объединённые цвета показывают, какие источники внесли вклад в значение байта. Даже всего с восемью цветами можно создавать бесчисленное множество мощных инструментов DTA.

С помощью libdft реализуйте спроектированное в предыдущей главе средство обнаружения эксплойтов форматной строки. Создайте уязвимую программу и эксплойт для проверки. Также создайте программу с неявным потоком, позволяющим эксплойту сработать, несмотря на средство обнаружения.

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

Практический пример перехвата на уровне инструкций можно найти в поставляемом с libdft инструменте libdft-dta.c.

Символьное исполнение, сокращённо symbex, - метод анализа программ, представляющий состояние в форме логических формул, о которых можно автоматически рассуждать, отвечая на сложные вопросы о поведении программы.

Например, NASA применяет символьное исполнение для генерации тестов критически важного кода, а производители оборудования - для проверки кода на языках описания аппаратуры Verilog и VHDL. Символьное исполнение позволяет автоматически увеличивать покрытие динамического анализа, создавая новые входные данные, ведущие по ещё не исследованным путям, что полезно при тестировании ПО и анализе вредоносных программ. В главе 13 вы увидите практические примеры: реализацию покрытия кода, обратного среза и даже автоматической генерации эксплойтов!

К сожалению, при всей мощности символьное исполнение приходится применять умеренно и осторожно из-за проблем масштабируемости. В зависимости от задачи сложность может расти экспоненциально, пока вычисление решения не станет совершенно неосуществимым. Способы уменьшения этих проблем описаны в разделе 12.1.3, но сначала рассмотрим основы работы метода.

Символьное исполнение описывает операции программы символьными формулами и применяет решатель, чтобы автоматически решать формулы и отвечать на вопросы о программе. Для понимания symbex и его ограничений нужно знать процесс решения.

В этом разделе важнейшие аспекты объясняются на примере популярного решателя Z3. Он разработан Microsoft Research и свободно доступен на https://github.com/Z3Prover/z3/.

Z3 является решателем выполнимости по модулю теорий (satisfiability modulo theories, SMT), то есть специализируется на задачах выполнимости формул относительно определённых математических теорий, например теории целочисленной арифметики.^[4] В отличие от решателей чистой булевой выполнимости (SAT), не имеющих встроенных сведений о теоретически специфичных операциях, например целочисленных + и <, Z3 умеет решать формулы с операциями над целыми и битовыми векторами - представлениями данных бинарного уровня - и другими объектами. Эти предметные знания полезны для формул symbex, содержащих именно такие операции.

Решатели наподобие Z3 являются отдельными программами, а их назначение не ограничено символьным исполнением. Некоторые механизмы позволяют подключать несколько решателей по выбору. Z3 популярен, поскольку его возможности идеально подходят symbex, а API для C/C++ и Python просты. Есть и средство командной строки, которое вскоре будет показано.

Важно понимать, что Z3 не является волшебным универсальным лекарством. Хотя он и похожие решатели полезны для определённых классов разрешимых формул, за их пределами решение может быть невозможно. Даже поддерживаемые формулы могут решаться долго, особенно если содержат множество переменных. Поэтому ограничения следует сохранять как можно более простыми.

Здесь рассматриваются лишь важнейшие возможности Z3; более полные руководства доступны в интернете.^[5]

В модели из листинга 12-3 значение y отрицательно. Оказывается, baz достижима, если x и y знаковые, но недостижима, если они беззнаковые. Докажем это на примере невыполнимой системы утверждений. Листинг 12-4 снова моделирует путь к baz, теперь с дополнительным требованием неотрицательности x и y.

Листинг 12-4. Доказательство недостижимости baz при беззнаковых входах

Листинг полностью совпадает с 12-3, кроме добавленных утверждений x >= 0 и y >= 0. Теперь check-sat возвращает unsat, доказывая, что при беззнаковых x и y функция baz недостижима. Модель невыполнимой задачи получить нельзя, поскольку она не существует.

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

Применим эту идею для доказательства общезначимости двунаправленной леммы - известной формулы логики высказываний. Заодно познакомимся с логическими операторами Z3 и булевым типом Bool.

Двунаправленная лемма утверждает: ((p → q) ∧ (r → s) ∧ (p ∨ ¬s)) ⊢ (q ∨ ¬r). В листинге 12-5 она моделируется в Z3 и доказывается.

Листинг 12-5. Доказательство двунаправленной леммы посредством Z3

Листинг объявляет четыре константы Bool: p, q, r и s, по одной для каждой переменной леммы. Затем посредством логических операторов Z3 утверждается сама лемма. Поддерживаются обычные операторы and (∧), or (∨), xor (⊕), not (¬) и импликация => (→). Эквиваленция (↔) выражается знаком равенства (=). Есть и оператор "если-то-иначе" ite с синтаксисом ite условие значение-если-истина значение-если-ложь. Знак логического следования ⊢ в листинге смоделирован импликацией =>.

Сначала подтверждается выполнимость двунаправленной леммы посредством check-sat, а get-model получает модель. Она назначает лишь true для r, чего достаточно, чтобы сделать утверждение истинным независимо от p, q и s. Это доказывает выполнимость, но не общезначимость.

Чтобы доказать общезначимость, стек утверждений Z3 сбрасывается, те же константы объявляются снова, а затем утверждается отрицание леммы. check-sat подтверждает невыполнимость отрицания, доказывая общезначимость.

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

Z3 также умеет упрощать выражения, как показано в листинге 12-6.

Листинг 12-6. Упрощение формулы посредством Z3

В примере объявляются целые x и y, а затем командой simplify упрощается формула 3x + 2y + 5 + x + y. Z3 приводит её к 5 + 4x + 3y. Здесь использована возможность передать оператору + более двух операндов и сложить их за один раз. В простых примерах команда работает хорошо, но в сложных может справляться хуже. Упрощение Z3 в первую очередь предназначено для программ наподобие механизмов symbex, автоматически обрабатывающих формулы, а не для повышения удобочитаемости.

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

Для операций над ними используются специальные операторы bvadd, bvsub, bvmul вместо обычных +, -, ×. В табл. 12-1 приведены самые распространённые. Вы часто увидите их при исследовании ограничений и выражений, которые механизмы наподобие Triton передают решателю. Знание операторов пригодится и при создании собственных инструментов в главе 13. Рассмотрим их практическое применение.

Z3 позволяет создавать битовые векторы любой ширины. Несколько способов показаны в первой части табл. 12-1. Четырёхбитовая константа с битами 1101 записывается как #b1101, а #xda создаёт восьмибитовый вектор со значением 0xda.

Для двоичных и шестнадцатеричных констант Z3 автоматически выводит минимальную необходимую ширину. Для десятичных нужно явно задать значение и ширину. Например, (_ bv10 32) создаёт 32-битовый вектор со значением 10. Неопределённая константа объявляется как (declare-const x (_ BitVec 32)), где x - имя, а 32 - ширина.

Таблица 12-1. Распространённые операторы битовых векторов Z3

Z3 поддерживает арифметические операторы битовых векторов, отражающие примитивные операции языков C/C++ и наборов команд наподобие x86. Например, команда (assert (= y (bvadd x #x10)))

утверждает, что битовый вектор y должен быть равен битовому вектору x + 0x10. Для многих операций Z3 предоставляет знаковый и беззнаковый варианты. Например, (bvsdiv x y) выполняет знаковое деление x/y, а (bvudiv x y) - беззнаковое. Учтите также, что Z3 требует одинаковой битовой ширины обоих операндов арифметической операции над битовыми векторами.

В столбце "Пример" табл. 12-1 приведены примеры всех распространённых операций Z3 над битовыми векторами. Точки с запятой обозначают комментарии, показывающие эквивалент на C/C++ или арифметический результат операции Z3.

Помимо арифметических операторов Z3 реализует распространённые побитовые операторы: ИЛИ (эквивалент | в C), И (&), исключающее ИЛИ (^) и НЕ (~). Реализованы и сравнения: = для проверки равенства битовых векторов, bvult для беззнакового сравнения "меньше" и так далее. Поддерживаемые сравнения очень похожи на условные переходы x86 и особенно полезны в сочетании с оператором Z3 ite. Например, (ite (bvsge x y) 22 44) вычисляется в 22, если x >= y, иначе в 44.

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

Теперь, познакомившись с операторами Z3 для битовых векторов, рассмотрим практический пример их применения.

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

В некоторых случаях решатель ограничений наподобие Z3 позволяет доказать, что ветвь непрозрачно истинна или ложна. Например, рассмотрим непрозрачно ложную ветвь, использующую тот факт, что ∀x ∈ Z, 2 | (x + x²). Иными словами, для любого целого x результат x + x² равен нулю по модулю два. На этом можно построить ветвь if((x + x*x) % 2 != 0), которая не будет выбрана ни при каком значении x, хотя это не сразу очевидно. Затем в "выбранный" путь ветви можно вставить запутывающий фиктивный код, чтобы сбить специалистов по обратной разработке с толку.

Листинг 12-7 показывает, как смоделировать эту ветвь в Z3 и доказать, что она никогда не может быть выбрана.

Листинг 12-7. Решение непрозрачного предиката посредством Z3

Сначала объявляется 64-битовый вектор x, который будет использоваться в условии ветвления. Затем утверждается само условие ветвления, после чего его выполнимость проверяется командой check-sat. Поскольку check-sat возвращает unsat, условие ветвления никогда не может быть истинным, поэтому при обратной разработке любой код внутри этой ветви можно безопасно игнорировать.

Как видите, даже ручное моделирование и доказательство такого простого непрозрачного предиката утомительно. Но посредством символьного исполнения подобные задачи можно решать автоматически.

Рассмотрите следующий код:

Создайте древовидную диаграмму, показывающую, как символьное состояние развивается для каждого пути исполнения этого кода (аналогично рис. 12-1). Выражение 2**z означает 2^z.

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

1. Создать на диаграмме отдельную копию двух последних инструкций для каждого пути.

2. Снова объединить все пути у этих последних инструкций и смоделировать символьное значение z условным выражением "если-то-иначе", зависящим от выбранного пути.

Посредством Z3 выясните, какие из вызовов foo, bar и baz достижимы в листинге из предыдущего упражнения. Смоделируйте соответствующие операции и ветви посредством битовых векторов.

Посредством Z3 проверьте, являются ли какие-либо условия в предыдущем листинге непрозрачными предикатами. Если да, они непрозрачно истинны или ложны? Какой код недостижим и поэтому может быть безопасно удалён из листинга?

И в режиме эмуляции, и в конколическом режиме Triton поддерживает глобальный набор символьных выражений, отображение регистров и адресов памяти на эти символьные выражения и список ограничений пути, как на рис. 12-1 из главы 12. Triton представляет символьные выражения и ограничения в виде абстрактных синтаксических деревьев (abstract syntax tree, AST), по одному AST на выражение или ограничение. AST - это древовидная структура данных, изображающая синтаксические отношения между операциями и операндами. Узлы AST содержат операции и операнды на языке SMT решателя Z3.

Например, рис. 13-1 показывает, как развивается AST регистра eax при следующей последовательности из трёх инструкций:

Для каждой инструкции на рисунке рядом показаны два AST: полное слева и AST со ссылками справа. Сначала обсудим левую сторону рисунка, а затем я объясню AST со ссылками.

На рисунке предполагается, что изначально eax и cl отображаются на неограниченные символьные выражения, соответствующие 32-битовому символьному значению α₁ и 8-битовому символьному значению α₂. Например, исходное состояние eax - это AST с корневым узлом bv (битовый вектор) и двумя дочерними узлами, содержащими значения α₁ и 32. Это соответствует неограниченному 32-битовому вектору Z3, как в (declare-const alpha1 (_ BitVec 32)).

Инструкция shr eax,cl выполняет логический сдвиг вправо, используя eax и cl как операнды и сохраняя результат в eax. Поэтому после этой инструкции полное AST регистра eax имеет в корне узел bvlshr (логический сдвиг вправо), а его дочерние деревья представляют исходные AST для eax и cl. Обратите внимание: правое дочернее дерево, представляющее содержимое cl, имеет в корне операцию concat, добавляющую перед значением cl 24 нулевых бита. Это необходимо, поскольку ширина cl составляет лишь 8 бит, но её нужно увеличить до 32 бит (ширины eax): формат SMT-LIB 2.0, используемый Z3, требует одинаковой битовой ширины обоих операндов bvlshr.

После инструкции xor eax,0x1 AST регистра eax превращается в узел bvxor, левым поддеревом которого служит предыдущее AST eax, а правым - постоянный битовый вектор со значением 1. Аналогично, результатом and eax,0x1 становится AST с корневым узлом bvand, прежним AST eax в качестве левого поддерева и постоянным битовым вектором в качестве правого.

Рис. 13-1. Влияние инструкций на абстрактные синтаксические деревья регистров

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

В этой схеме каждое AST имеет имя наподобие ref!1, ref!2 и так далее, по которому на него можно ссылаться из другого AST. Тогда вместо копирования всего предыдущего AST достаточно сослаться на него, включив в новое AST узел ссылки. Например, правая сторона рис. 13-1 показывает, как всё левое поддерево AST регистра eax после инструкции and eax,0x1 заменяется одним узлом ссылки на предыдущее AST, сжимая 15 узлов до одного.

Triton предоставляет функцию API unrollAst, позволяющую развернуть AST со ссылками в полное AST, чтобы вручную исследовать или изменить его либо передать в Z3. Теперь, познакомившись с основами работы Triton, научимся практически применять unrollAst и другие функции Triton на нескольких примерах.

В первом примере реализован обратный слайсинг в режиме символьной эмуляции Triton. Это обобщённая версия примера, поставляемого с Triton и расположенного в ~/triton/pin-2.14-71313-gcc.4.4.7-linux/source/tools/Triton/src/examples/python/backward_slicing.py. Исходный инструмент Triton использует Python API, но здесь я применю API Triton для C/C++. Пример инструмента Triton на Python вы увидите в разделе 13.5.

Напомню: обратный слайсинг - метод анализа бинарного кода, сообщающий, какие предшествующие инструкции повлияли в определённой точке исполнения на значение заданного регистра или адреса памяти. Допустим, требуется вычислить обратный слайс в адресе 0x404b1e относительно rcx во фрагменте кода /bin/ls из листинга 13-1.

Листинг 13-1. Фрагмент дизассемблированного кода /bin/ls

Обратный слайс состоит из всех инструкций, влияющих на значение rcx в адресе 0x404b1e. Следовательно, слайс должен включать инструкции из следующего листинга:

Теперь посмотрим, как автоматически вычислять подобные обратные слайсы посредством Triton. Сначала вы научитесь создавать инструмент обратного слайсинга, а затем примените его к фрагменту кода из листинга 13-1 и получите тот же результат, что и при только что выполненном ручном слайсинге.

Поскольку Triton выражает символьные выражения как AST, ссылающиеся друг на друга, вычислить обратный слайс заданного выражения несложно. В листинге 13-2 показана первая часть реализации инструмента обратного слайсинга. Как обычно, включение стандартных заголовочных файлов C/C++ в листинге опущено.

Листинг 13-2. backward_slicing.cc

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

Назначение файла символьной конфигурации я объясню чуть позже. Учтите: здесь адрес точки входа - просто адрес первой инструкции, которую будет эмулировать инструмент слайсинга; он не обязан совпадать с точкой входа бинарного файла. Например, для слайсинга кода из листинга 13-1 в качестве адреса точки входа используется 0x404b00, чтобы анализ эмулировал все показанные в листинге инструкции вплоть до адреса слайса.

Вывод backward_slicing представляет собой список ассемблерных инструкций, входящих в слайс. Теперь подробнее рассмотрим, как backward_slicing создаёт программный слайс, начав с более подробного обсуждения необходимых включаемых файлов и функции main.

Первое, что можно заметить в листинге 13-2, - включение ../inc/loader.h, поскольку backward_slicing использует загрузчик бинарных файлов, разработанный в главе 4. Также включены triton_util.h и disasm_util.h, предоставляющие служебные функции, которые я вскоре опишу. Наконец, есть два специфичных для Triton заголовочных файла, оба с расширением .hpp: triton/api.hpp предоставляет основной API Triton для C++, а triton/x86Specifications.hpp - определения, относящиеся к x86, например определения регистров. Помимо включения этих заголовков, для режима символьной эмуляции Triton необходимо выполнить компоновку с -ltriton.

Функция main начинает с загрузки анализируемого бинарного файла посредством функции load_binary из загрузчика. Затем она настраивает Triton на архитектуру бинарного файла посредством функции set_triton_arch, определённой в backward_slicing.cc и подробно рассматриваемой в разделе 13.3.4. Она также вызывает функцию Triton api.enableMode, чтобы включить режим Triton ALIGNED_MEMORY, где api - объект типа triton::API, основного класса Triton, предоставляющего C++ API.

Напомню: символьный доступ к памяти способен значительно увеличить размер и сложность символьного состояния, поскольку механизм symbex должен смоделировать все возможные результаты доступа. Режим Triton ALIGNED_MEMORY - оптимизация, снижающая взрывной рост символьной памяти за счёт предположения, что загрузки и сохранения обращаются к выровненным адресам памяти. Эту оптимизацию можно безопасно включить, если известно, что обращения к памяти выровнены, или если точные адреса не важны для анализа.

В большинстве инструментов symbex потребуется сделать некоторые регистры и адреса памяти символьными либо назначить им конкретные значения. Выбор символьных частей состояния и конкретных значений зависит от анализируемого приложения и исследуемых путей. Поэтому жёстко заданные решения о символизации и конкретизации состояния сделают инструмент symbex специфичным для приложения.

Чтобы избежать этого, создадим простой формат файла символьной конфигурации, позволяющий настраивать такие решения. В triton_util.h определена служебная функция parse_sym_config, посредством которой можно разбирать файлы символьной конфигурации и загружать их в инструмент symbex. Ниже показан пример такого файла:

В формате файла символьной конфигурации регистры обозначаются как %имя, а адреса памяти - как @адрес. Каждому регистру или байту памяти можно назначить конкретное целое значение либо сделать его символьным, назначив $. Например, этот файл сначала назначает rax конкретное значение 0, затем делает rax символьным и назначает значение 5 байту по адресу памяти 0x1000. Обратите внимание: rax является символьным, но одновременно имеет конкретное значение, направляющее эмуляцию по нужному пути.

Вернёмся к листингу 13-2. После загрузки анализируемого бинарного файла и настройки Triton backward_slicing вызывает parse_sym_config, чтобы разобрать указанный в командной строке файл символьной конфигурации. Эта функция принимает имя файла конфигурации, за которым следуют два параметра-ссылки на объекты std::map, куда parse_sym_config загружает конфигурацию. Первый std::map отображает имена регистров Triton (перечислимого типа triton::arch::registers_e) на конкретные значения uint64_t, содержащие данные регистров, а второй отображает адреса памяти на конкретные значения байтов.

В действительности parse_sym_config принимает ещё два необязательных параметра, в которые загружает списки символьных регистров и адресов памяти. Здесь они не используются, поскольку для вычисления слайсов интерес представляют лишь строящиеся Triton деревья AST, а по умолчанию Triton строит AST даже для регистров и участков памяти, которые явно не были сделаны символьными.^[4] Пример, где некоторые части состояния действительно нужно явно символизировать, приведён в разделе 13.4.

Сразу после вызова parse_sym_config функция main инструмента backward_slicing содержит два цикла for. Первый перебирает только что загруженное отображение конкретных значений регистров и предписывает Triton назначить эти конкретные значения его внутреннему состоянию. Для этого вызывается api.setConcreteRegisterValue, принимающая регистр Triton и конкретное целое значение. Регистры Triton имеют тип triton::arch::Register; получить их из имени регистра Triton (перечислимого типа triton::arch::registers_e) можно посредством функции api.getRegister. Каждое имя регистра имеет вид ID_REG_имя, где имя - записанное прописными буквами имя регистра наподобие AL, EBX, RSP и так далее.

Аналогично, второй цикл for перебирает отображение конкретных значений памяти и сообщает их Triton посредством api.setConcreteMemoryValue, принимающей адрес памяти и конкретное значение байта.^[5]

Загрузка файла символьной конфигурации - последняя часть кода настройки backward_slicing. После неё начинается основной цикл эмуляции: он эмулирует инструкции бинарного файла от заданного пользователем адреса точки входа до инструкции, в которой должен быть вычислен слайс. Подобный цикл типичен почти для всех инструментов символьной эмуляции, создаваемых посредством Triton.

Цикл эмуляции представляет собой обычный цикл while, завершающийся после вычисления слайса либо при встрече адреса инструкции за пределами раздела .text бинарного файла. Текущий адрес инструкции отслеживается эмулируемым счётчиком команд pc.

Каждая итерация начинается с дизассемблирования текущей инструкции посредством disasm_one - ещё одной предоставленной мной служебной функции из disasm_util.h. Она использует Capstone, чтобы получить строки с мнемоникой и операндами инструкции, которые вскоре понадобятся.

Затем backward_slicing создаёт для текущей инструкции объект инструкции Triton типа triton::arch::Instruction и посредством функции setOpcode заполняет его байтами кода инструкции из раздела .text бинарного файла. Функцией setAddress адресу объекта Instruction назначается текущий pc.

Создав для текущей инструкции объект Triton Instruction, цикл эмуляции обрабатывает его вызовом функции api.processing. Несмотря на общее имя, api.processing играет центральную роль в инструментах символьной эмуляции Triton: именно она эмулирует инструкцию и обновляет символьное и конкретное состояние Triton в соответствии с результатом.

После обработки текущей инструкции Triton построит внутренние абстрактные синтаксические деревья, представляющие символьные выражения состояний регистров и памяти, затронутых инструкцией. Позже вы увидите, как применять эти выражения для вычисления обратного слайса. Чтобы получить слайс с инструкциями x86, а не с символьными выражениями в формате SMT-LIB 2.0, необходимо отслеживать, с какой инструкцией связано каждое символьное выражение. Инструмент backward_slicing делает это, перебирая список всех символьных выражений только что обработанной инструкции и добавляя к каждому выражению комментарий со строками мнемоники и операндов, ранее полученными функцией disasm_one.

Для доступа к списку символьных выражений Instruction служит его член symbolicExpressions, являющийся объектом типа std::vector<triton::engines::symbolic::SymbolicExpression*>. Класс SymbolicExpression предоставляет функцию setComment, позволяющую задать строку комментария для символьного выражения.

Когда эмуляция достигает адреса слайса, backward_slicing вызывает функцию print_slice, вычисляющую и печатающую слайс, а затем выходит из цикла эмуляции. get_triton_regnum - ещё одна служебная функция из triton_util.h, возвращающая соответствующий идентификатор регистра Triton по удобочитаемому имени регистра. Здесь она возвращает идентификатор регистра, относительно которого вычисляется слайс, для передачи в print_slice.

При вызове функции Triton processing библиотека внутренне обновляет конкретное значение указателя команд, направляя его на следующую инструкцию. В конце каждой итерации цикла эмуляции новое значение указателя команд получается посредством api.getConcreteRegisterValue и назначается собственному программному счётчику (pc в этом примере), управляющему циклом эмуляции. Для 32-битовых программ x86 необходимо получить содержимое eip, тогда как для программ x64 указателем команд является rip. Теперь посмотрим, как упомянутая ранее функция set_triton_arch настраивает переменную ip, назначая ей идентификатор правильного регистра указателя команд, который будет использовать цикл эмуляции.

Функция main инструмента backward_slicing вызывает set_triton_arch, чтобы настроить Triton на набор инструкций бинарного файла и получить имя регистра указателя команд этой архитектуры. Реализация set_triton_arch показана в листинге 13-3.

Листинг 13-3. backward_slicing.cc (продолжение)

Функция принимает три параметра: ссылку на объект Binary, возвращённый загрузчиком бинарных файлов, ссылку на API Triton и ссылку на triton::arch::registers_e, куда сохраняется имя регистра указателя команд. При успехе set_triton_arch возвращает 0, а при ошибке -1.

Сначала set_triton_arch проверяет, что имеет дело с бинарным файлом x86 (32- или 64-битовым). В противном случае она возвращает ошибку, поскольку сейчас Triton не способен работать с архитектурами помимо x86.

Если ошибки нет, set_triton_arch проверяет битовую ширину бинарного файла. Для 32-битового x86 она настраивает Triton на 32-битовый режим x86 (triton::arch::ARCH_X86) и назначает ID_REG_EIP как имя регистра указателя команд. Аналогично, для бинарного файла x64 архитектуре Triton назначается triton::arch::ARCH_X86_64, а указателю команд - ID_REG_RIP. Архитектура Triton настраивается функцией api.setArchitecture, единственным параметром которой служит тип архитектуры.

Чтобы вычислить и напечатать сам слайс, при достижении адреса слайса backward_slicing вызывает функцию print_slice. Её реализация показана в листинге 13-4.

Листинг 13-4. backward_slicing.cc (продолжение)

Напомню: слайсы вычисляются относительно конкретного регистра, заданного параметром reg. Для вычисления слайса нужно символьное выражение, связанное с этим регистром сразу после эмуляции инструкции по адресу слайса. Чтобы получить выражение, print_slice вызывает api.getSymbolicRegisters, которая возвращает отображение всех регистров на связанные с ними символьные выражения, а затем индексирует это отображение, получая выражение reg. После этого посредством api.sliceExpressions функция получает слайс всех символьных выражений, влияющих на выражение reg; результатом служит std::map, отображающий целочисленные идентификаторы выражений на объекты triton::engines::symbolic::SymbolicExpression*.

Теперь имеется слайс символьных выражений, но в действительности нужен слайс ассемблерных инструкций x86. Именно для этого служат комментарии символьных выражений, связывающие каждое выражение со строками мнемоники и операндов породившей его инструкции. Поэтому для печати слайса print_slice просто перебирает символьные выражения, получает их комментарии посредством getComment и выводит на экран. Для полноты print_slice также дизассемблирует и печатает инструкцию, в которой вычисляется слайс.

Испытать программу backward_slice в виртуальной машине можно, запустив её как в листинге 13-5.

Листинг 13-5. Вычисление обратного слайса в 0x404b1e относительно rcx

Здесь backward_slicing применяется для вычисления слайса фрагмента кода /bin/ls, приведённого в листинге 13-1. Использован пустой файл символьной конфигурации (empty.map), а 0x404b00, 0x404b1e и rcx заданы соответственно как адрес точки входа, адрес слайса и регистр слайсинга. Как видите, вывод совпадает с ранее вычисленным вручную слайсом.

Пустой файл символьной конфигурации допустим в этом примере потому, что анализ не зависит от символьности каких-либо конкретных регистров или участков памяти, а для направления исполнения не нужны определённые конкретные значения: анализируемый фрагмент кода не содержит ветвлений. Теперь рассмотрим другой пример, где для исследования нескольких путей одной программы понадобится непустая символьная конфигурация.

Поскольку примеру обратного слайсинга требовалась лишь способность Triton отслеживать символьные выражения регистров и участков памяти, он не использовал главную силу символьного исполнения - рассуждение о свойствах программы посредством решения ограничений. В этом примере вы познакомитесь с возможностями Triton по решению ограничений в классическом варианте применения symbex - покрытии кода.

В листинге 13-6 показана первая часть исходного кода инструмента code_coverage. Значительная его часть совпадает с предыдущим примером или похожа на него. Функция set_triton_arch вовсе опущена, поскольку полностью совпадает с функцией инструмента backward_slicing.

Листинг 13-6. code_coverage.cc

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

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

Как видно из листинга, code_coverage включает те же служебные и Triton-специфичные заголовочные файлы, что и предыдущий пример. Более того, функция main инструмента code_coverage почти полностью совпадает с main инструмента backward_slicing. Как и там, она сначала загружает бинарный файл и настраивает архитектуру Triton, после чего включает оптимизацию ALIGNED_MEMORY.

Одно из отличий от предыдущего примера состоит в том, что код разбора файла символьной конфигурации передаёт parse_sym_config два необязательных аргумента (symregs и symmem). Это выходные аргументы, куда parse_sym_config записывает списки регистров и участков памяти, которые следует символизировать согласно файлу конфигурации. В нём нужно символизировать все регистры и участки памяти с пользовательскими входами, чтобы возвращаемая решателем модель содержала конкретное значение каждого такого входа.

Назначив конкретные значения из файла конфигурации, main перебирает список предназначенных для символизации регистров и символизирует их посредством функции Triton api.convertRegisterToSymbolicVariable. Та же строка кода, которая символизирует регистр, сразу добавляет комментарий к только что созданной символьной переменной, указывая удобочитаемое имя регистра. Благодаря этому, позднее получив модель от решателя ограничений, вы будете знать, как отобразить назначения символьных переменных из модели обратно на настоящие регистры и память.

Цикл символизации участков памяти устроен аналогично. Для каждого участка создаётся объект triton::arch::MemoryAccess, задающий адрес и размер участка в байтах. Здесь размер жёстко задан равным одному байту, поскольку формат файла конфигурации позволяет обращаться к участкам памяти лишь с байтовой гранулярностью. Чтобы символизировать адрес, заданный в объекте MemoryAccess, применяется функция Triton api.convertMemoryToSymbolicVariable. После этого цикл добавляет комментарий, связывающий новую символьную переменную с удобочитаемой строкой, содержащей адрес памяти.

Теперь рассмотрим пример, требующий более сложного решения ограничений. В этом разделе вы научитесь посредством Triton автоматически создавать входы, эксплуатирующие уязвимость программы путём перехвата сайта косвенного вызова и перенаправления его на выбранный адрес.

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

Как вы узнали в главе 12, символьное исполнение слишком дорого в вычислительном отношении для грубого фаззинга, пытающегося найти эксплойт для каждого сайта косвенного вызова программы. Вместо этого можно сначала провести более традиционный фаззинг, подавая программе множество псевдослучайно созданных входов и посредством анализа помеченных данных определяя, влияют ли они на опасное состояние программы, например на сайты косвенных вызовов. Затем символьное исполнение можно применять для создания эксплойтов лишь для тех сайтов вызова, которые анализ помеченных данных признал потенциально управляемыми. Именно этот вариант использования предполагается в следующем примере.

Сначала рассмотрим эксплуатируемую программу и содержащийся в ней уязвимый сайт вызова. В листинге 13-12 показан исходный файл уязвимой программы icall.c. Makefile компилирует её в бинарный файл icall с setuid root,^[7] содержащий сайт косвенного вызова, который вызывает одну из нескольких функций-обработчиков. Это напоминает использование указателей функций веб-серверами наподобие nginx для выбора подходящего обработчика полученных данных.

Листинг 13-12. icall.c

Программа icall построена вокруг глобальной структуры, также называемой icall. Эта структура содержит массив icall.functions с местом для двух указателей функций и массив char с именем icall.hash, хранящий 4-байтовый хеш с завершающим символом NULL. Функция main инициализирует первый элемент icall.functions указателем на функцию forward, а второй - указателем на reverse. Обе функции принимают хеш как char* и печатают его байты соответственно в прямом или обратном порядке.

Программа icall принимает два аргумента командной строки: целочисленный индекс и строку. Индекс определяет вызываемый элемент icall.functions, а строка служит входом для создания хеша, как вы вскоре увидите.

Есть и секретный третий аргумент командной строки, не упомянутый в строке использования. Это пароль административной области, предоставляющей оболочку root. Для проверки пароля icall хеширует его функцией GNU crypt (из crypt.h), и при правильном хеше пользователь получает доступ к оболочке root. Цель эксплойта - перехватить сайт косвенного вызова и перенаправить его в эту секретную административную область, не зная пароля.

Если секретный пароль не передан, icall вызывает функцию hash, которая вычисляет 4-байтовый хеш пользовательской строки и помещает его в icall.hash. После вычисления хеша icall разбирает индекс из командной строки и применяет его для индексирования массива icall.functions, косвенно вызывая обработчик с этим индексом и передавая только что вычисленный хеш как аргумент. Именно этот косвенный вызов будет использован в эксплойте. Для диагностики icall печатает адрес вызываемой функции, что пригодится при создании эксплойта.

В нормальном случае косвенный вызов обращается к forward или reverse, после чего функция печатает хеш:

Здесь в качестве индекса функции использовано значение 1, что приводит к вызову reverse, а входной строкой служит foo. Видно, что косвенный вызов направлен в адрес 0x400974 (начало reverse), а хеш foo, напечатанный в обратном порядке, равен 0x22295079.

Возможно, вы заметили уязвимость косвенного вызова: пользовательский индекс не проверяется на нахождение в границах icall.functions, поэтому, передав индекс за пределами массива, пользователь может заставить icall использовать данные вне icall.functions как цель косвенного вызова! Поле icall.hash расположено в памяти рядом с icall.functions, поэтому индекс 2 заставляет icall использовать icall.hash как цель косвенного вызова:

Обратите внимание: вызываемый адрес соответствует хешу, интерпретированному как адрес с порядком байтов от младшего к старшему! Кода в этом адресе нет, поэтому программа аварийно завершается с ошибкой сегментации. Однако пользователь управляет не только индексом, но и строкой, служащей входом хеша. Задача состоит в поиске строки, хеш которой в точности равен адресу секретной административной области, после чего косвенный вызов нужно заставить использовать этот хеш как цель, передав управление в административную область и получив оболочку root без знания пароля.

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

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

Листинг 13-13. Фрагмент дизассемблированного кода ~/code/chapter13/icall

Код секретной административной области начинается в адресе 0x400b3b, поэтому именно туда нужно перенаправить управление. Область узнаваема по вызовам setgid и setuid, где icall подготавливает привилегии root для оболочки, и по вызову execl, создающему саму оболочку. Уязвимый сайт косвенного вызова, который предстоит перехватить, находится в адресе 0x400bef.

Теперь, располагая нужными адресами, создадим инструмент symbex для генерации эксплойта.

В листинге 13-18 показано практическое применение exploit_callsite.py для создания эксплойта программы icall.

Листинг 13-18. Попытка найти эксплойт icall с длиной входа 3

Сначала выполняется переход в основной каталог Triton в виртуальной машине, где находится сценарий-обёртка triton. Напомню: Triton предоставляет его для автоматической настройки Pin, необходимой конколическим инструментам. В сущности, обёртка запускает анализируемую программу (icall) в Pin, используя конколическую библиотеку Triton как Pintool. Эта библиотека принимает пользовательский конколический инструмент (exploit_callsite.py) как аргумент и запускает его.

Чтобы начать анализ, достаточно вызвать обёртку triton, передав имя сценария exploit_callsite.py, а также имя и аргументы анализируемой программы (icall с индексом 2 и входной строкой AAA). Обёртка обеспечивает запуск icall с заданными аргументами в Pin под управлением exploit_callsite.py. Строка AAA не является эксплойтом - это произвольная строка, направляющая конколическое исполнение.

Сценарий перехватывает функцию main программы icall и символизирует все байты пользовательского ввода в argv. Достигнув сайта косвенного вызова, icall использует как цель адрес 0x223c625e, являющийся хешем AAA. Это фиктивный адрес, который обычно привёл бы к аварийному завершению, но здесь это неважно, поскольку exploit_callsite.py вычисляет модель эксплойта до выполнения косвенного вызова.

Перед выполнением косвенного вызова exploit_callsite.py пытается найти модель, дающую набор пользовательских входов, хеширующихся в целевой адрес 0x400b3b секретной административной области. Этот шаг может занять до нескольких минут в зависимости от аппаратной конфигурации. К сожалению, решатель не находит модель, поэтому exploit_callsite.py завершается без эксплойта.

Однако это не обязательно означает, что эксплойта нет. Конколическому исполнению icall передана строка AAA, и exploit_callsite.py создаёт отдельную символьную переменную для каждого из трёх входных байтов. Следовательно, решатель ищет модель эксплойта на основе пользовательской строки длиной 3. Неспособность найти эксплойт означает лишь отсутствие подходящей строки такой длины; с другой длиной может повезти больше. Вместо ручного перебора длин процесс можно автоматизировать, как в листинге 13-19.

Листинг 13-19. Сценарий попыток эксплуатации с переменной длиной входа

Здесь оператор for оболочки bash перебирает все целые i от 1 до 100. На каждой итерации цикл создаёт строку из i букв A, а затем пытается создать эксплойт с этой строкой длины i как пользовательским вводом, как в листинге 13-18 для длины 3.^[8]

Чтобы сократить вывод, посредством grep можно показывать лишь строки со словом SymVar. Тогда отображаются только строки успешных моделей, а не давшие модель попытки завершаются без вывода.

Вывод цикла начинается с Trying input len 1. Для длин от 1 до 3 модель найти не удаётся, но поиск успешен для длины 4 и снова для длины 5. После этого исполнение остановлено, поскольку при уже найденном эксплойте проверять следующие длины незачем.

Испытаем первый эксплойт из вывода (длиной 4). Чтобы превратить вывод в строку эксплойта, нужно конкатенировать символы ASCII, назначенные решателем символьным переменным argv[2][0] - argv[2][3], поскольку именно эти байты пользовательского ввода поступают в хеш-функцию icall. Как видно в листинге 13-19, решатель выбрал соответственно 0x24, 0x2A, 0x58 и 0x26. Байт argv[2][4] должен быть завершающим NULL пользовательской строки, но решатель этого не знает и выбрал для него случайный входной байт 0x40, который можно безопасно игнорировать.

Назначенные в модели байты argv[2][0] - argv[2][3] соответствуют строке эксплойта ASCII $*X&. Передадим её программе icall, как в листинге 13-20.

Листинг 13-20. Эксплуатация программы icall

Для испытания эксплойта выполняется переход обратно в каталог кода этой главы, где находится icall, после чего программа вызывается с индексом 2 за пределами массива и только что созданной строкой эксплойта. Как видно, строка хешируется точно в 0x400b3b - адрес секретной административной области. Благодаря отсутствию проверки границ пользовательского индекса указателя функции удалось заставить icall вызвать этот адрес и предоставить оболочку root. Команда whoami печатает root, подтверждая получение привилегированной оболочки. Эксплойт автоматически создан посредством символьного исполнения!

В каталоге кода этой главы находится программа license.c, которая принимает серийный номер и проверяет его правильность (подобно проверке лицензионного ключа в коммерческом программном обеспечении). Создайте инструмент символьного исполнения посредством Triton, способный генерировать действительные лицензионные ключи, принимаемые license.c.

В листинге A-1 показана простая программа на C, а в листинге A-2 - соответствующая программа на ассемблере, созданная gcc 5.4.0. (В главе 1 объясняется, как компиляторы преобразуют программы C в ассемблерные листинги, а затем в бинарные файлы.)

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

Листинг A-1. "Hello, world!" на C

Листинг A-2. Ассемблерный код, созданный gcc

Листинг A-1 состоит из функции main, вызывающей printf для печати постоянной строки "Hello, world!". На высоком уровне соответствующая программа на ассемблере состоит из компонентов четырёх типов: инструкций, директив, меток и комментариев.

В табл. A-1 показаны примеры компонентов каждого типа. Точный синтаксис каждого зависит от ассемблера или дизассемблера. Для целей книги не требуется подробно знать синтаксические особенности конкретного ассемблера; нужно лишь научиться читать и анализировать дизассемблированный код, а не писать собственный ассемблерный код. Здесь применяется синтаксис, создаваемый gcc с параметром -masm=intel.

Таблица A-1. Компоненты программы на ассемблере

Инструкции - фактические операции, выполняемые процессором. Директивы - команды, предписывающие ассемблеру создать определённый фрагмент данных, поместить инструкции или данные в заданный раздел и так далее. Метки - символьные имена для обращения к инструкциям или данным ассемблерной программы, а комментарии - удобочитаемые строки документации. После ассемблирования и компоновки программы в бинарный файл все символьные имена заменяются адресами.

Ассемблерная программа из листинга A-2 предписывает ассемблеру поместить строку "Hello, world!" в раздел .rodata, предназначенный для постоянных данных. Директива .section сообщает, в какой раздел помещать последующее содержимое, а .string позволяет определить строку ASCII. Есть и директивы для других типов данных: .byte (байт), .word (2-байтовое слово), .long (4-байтовое двойное слово) и .quad (8-байтовое четверное слово).

Функция main помещается в раздел .text, предназначенный для кода. Директива .text - сокращение для .section .text, а main: вводит символьную метку функции main.

За меткой следуют сами инструкции main. Они могут символически обращаться к ранее объявленным данным, например к .LC0 (символьному имени, выбранному gcc для строки "Hello, world!"). Поскольку программа печатает постоянную строку без переменных аргументов, gcc заменяет вызов printf вызовом более простой функции puts, печатающей заданную строку на экран.

Из листинга A-2 можно сделать важное наблюдение: компиляторы обычно разделяют код и данные по разным разделам. Это удобно при дизассемблировании или анализе бинарного файла, поскольку известно, какие байты программы интерпретировать как код, а какие - как данные. Однако архитектура x86 не запрещает смешивать код и данные в одном разделе, и на практике некоторые компиляторы или вручную написанные ассемблерные программы именно так и делают.

Как упоминалось, разные ассемблеры используют разный синтаксис. Кроме того, для представления машинных инструкций x86 применяются два формата: Intel и AT&T.

В синтаксисе AT&T перед именем каждого регистра явно ставится %, а перед каждой константой - $; в синтаксисе Intel эти символы отсутствуют. В книге используется менее многословный синтаксис Intel. Важнейшее различие состоит в прямо противоположном порядке операндов. В AT&T исходный операнд предшествует целевому, поэтому перемещение константы в edi выглядит так:

В синтаксисе Intel та же инструкция представляется с целевым операндом на первом месте:

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

Теперь, получив представление о структуре ассемблерных программ, рассмотрим формат ассемблерных инструкций. Вы также увидите устройство машинных инструкций, представляемых ассемблерным кодом.

На уровне ассемблера инструкции x86 обычно имеют вид мнемоника назначение, источник. Мнемоника - удобочитаемое представление машинной инструкции, а источник и назначение - её операнды. Например, инструкция mov rbx, rax копирует значение из регистра rax в rbx. Не все инструкции имеют ровно два операнда; у некоторых их вообще нет, как вы вскоре увидите.

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

ISA x86 использует инструкции переменной длины: некоторые инструкции x86 состоят всего из одного байта, но существуют и многобайтовые инструкции длиной до максимальных 15 байт. Кроме того, инструкция может начинаться в любом адресе памяти. Процессор не требует определённого выравнивания кода, хотя компиляторы часто выравнивают его для оптимизации извлечения инструкций из памяти. На рис. A-1 показана машинная структура инструкции x86.

Рис. A-1. Структура инструкции x86

Инструкция x86 состоит из необязательных префиксов, кода операции и нуля или нескольких операндов. Все части, кроме кода операции, необязательны.

Код операции - основной идентификатор типа инструкции. Например, 0x90 кодирует ничего не делающую инструкцию nop, а коды 0x00-0x05 - различные инструкции add. Префиксы способны изменять поведение инструкции, например заставлять её многократно повторяться или обращаться к другому сегменту памяти. Операнды - данные, над которыми работает инструкция.

Байт режима адресации, также называемый MOD-R/M или MOD-REG-R/M, содержит метаданные о типах операндов. Байты SIB (scale/index/base - масштаб/индекс/база) и смещение кодируют операнды памяти, а поле непосредственного значения может содержать непосредственный операнд (постоянное числовое значение). Вскоре эти поля будут рассмотрены подробнее.

Помимо явных операндов на рис. A-1, у некоторых инструкций есть неявные. Они не кодируются явно, а присущи коду операции. Например, целевой операнд кода 0x05 (инструкции add) всегда rax; изменяется и явно кодируется лишь исходный операнд. Инструкция push, например, неявно обновляет rsp (регистр указателя стека).

В x86 операнды бывают трёх типов: регистровые, операнды памяти и непосредственные. Рассмотрим каждый допустимый тип.

Операнд памяти задаёт адрес, откуда процессор должен извлечь один или несколько байтов. ISA x86 поддерживает лишь один явный операнд памяти на инструкцию: нельзя одной инструкцией mov напрямую переместить байты из одного участка памяти в другой; регистр должен служить промежуточным хранилищем.

Операнд памяти x86 задаётся как [база + индекс*масштаб + смещение], где база и индекс - 64-битовые регистры, масштаб равен 1, 2, 4 или 8, а смещение - 32-битовая константа либо символ. Все компоненты необязательны. Процессор вычисляет выражение, получая итоговый адрес памяти. База, индекс и масштаб кодируются в байте SIB, смещение - в одноимённом поле. По умолчанию масштаб равен 1, смещение - 0.

Формат достаточно гибок для прямого выражения распространённых конструкций. Например, mov eax, DWORD PTR [rax*4 + arr] обращается к элементу массива: arr - смещение с начальным адресом массива, rax содержит индекс, а каждый элемент занимает 4 байта. DWORD PTR сообщает ассемблеру, что из памяти нужно получить 4 байта. Для доступа к полю структуры можно сохранить её начальный адрес в базовом регистре и прибавить смещение нужного поля.

В x86-64 разрешено использовать rip как базу операнда памяти, но тогда индексный регистр недоступен. Компиляторы часто применяют эту возможность для позиционно-независимого кода и доступа к данным, поэтому в бинарных файлах x86-64 часто встречается адресация относительно rip.

Непосредственные операнды - постоянные целые значения, жёстко закодированные в инструкции. В add rax, 42 значение 42 является непосредственным.

В x86 они кодируются с порядком байтов от младшего к старшему: младший байт многобайтового целого первым размещается в памяти. Поэтому ассемблерная инструкция mov ecx, 0x10203040 кодирует непосредственное значение на машинном уровне байтами в обратном порядке: 0x40302010.

Знаковые целые x86 кодирует в дополнительном коде: для отрицательного значения берётся положительное, все его биты инвертируются, после чего прибавляется 1 с игнорированием переполнения. Чтобы закодировать 4-байтовое -1, берут 0x00000001, инвертируют биты в 0xfffffffe и прибавляют 1, получая 0xffffffff. Непосредственное значение или значение памяти, начинающееся с множества байтов 0xff, часто является отрицательным.

Теперь, зная общий формат и работу инструкций x86, рассмотрим семантику распространённых инструкций, которые встретятся в книге и собственных проектах бинарного анализа.

В табл. A-3 описаны распространённые инструкции x86. Не указанную в таблице инструкцию можно найти в сеточном справочнике http://ref.x86asm.net/ или руководстве Intel https://software.intel.com/en-us/articles/intel-sdm/. Большинство инструкций понятны без объяснений, но некоторые заслуживают подробного обсуждения.

Таблица A-3. Распространённые инструкции x86

Следует отметить, что имя mov немного неточно: инструкция не перемещает исходный операнд в целевой, а копирует его, сохраняя исходный. Инструкции push и pop имеют особое значение для управления стеком и вызовов функций, как вы вскоре увидите.

Инструкция cmp важна для условных ветвлений. Она вычитает второй операнд из первого, но не сохраняет результат, а устанавливает по нему флаги в rflags. Последующие условные ветвления проверяют флаги и решают, выбирать ли ветвь. Важны флаг нуля (ZF), знака (SF) и переполнения (OF), показывающие соответственно нулевой, отрицательный результат или переполнение.

Инструкция test похожа на cmp, но устанавливает флаги по результату побитового И операндов, а не вычитания. Флаги устанавливают и некоторые другие инструкции. Руководство Intel или сеточный справочник точно сообщает, какие флаги устанавливает каждая.

Для системного вызова применяется syscall. Предварительно нужно выбрать его номер и настроить операнды согласно требованиям ОС. Например, для read в Linux в rax загружается 0 (номер read), затем дескриптор файла, адрес буфера и число читаемых байтов загружаются соответственно в rdi, rsi и rdx, после чего выполняется syscall.

Сведения о настройке системных вызовов Linux см. в man syscalls или https://filippo.io/linux-syscall-table/. В 32-битовом x86 системный вызов выполняется посредством sysenter или int 0x80 (программного прерывания для вектора 0x80) вместо syscall. В других ОС соглашения могут отличаться.

Инструкции условного перехода реализуют ветвления вместе с предшествующими инструкциями установки флагов наподобие cmp или test. При выполнении условия они переходят к адресу или метке, иначе продолжают со следующей инструкции. Например, переход к label, если rax < rbx в беззнаковом сравнении, обычно выглядит так:

Аналогично, переход к label, если rax не равен нулю:

Инструкция lea (load effective address - загрузка эффективного адреса) вычисляет адрес, получаемый из операнда памяти вида [база + индекс*масштаб + смещение], и сохраняет его в регистре, не разыменовывая. Она эквивалентна оператору взятия адреса (&) C/C++. Например, lea r12, [rip+0x2000] загружает адрес, полученный выражением rip+0x2000, в r12.

Теперь, познакомившись с важнейшими инструкциями x86, посмотрим, как из них складываются распространённые конструкции C/C++.

Компиляторы gcc, clang и Visual Studio создают распространённые шаблоны кода для вызовов функций, ветвей if/else и циклов. Те же шаблоны встречаются в написанном вручную ассемблерном коде. Их знание помогает быстро понимать ассемблерный или дизассемблированный код. Рассмотрим шаблоны gcc 5.4.0; другие компиляторы применяют сходные.

Первой конструкцией будут вызовы функций. Но для понимания их ассемблерной реализации нужно знать, как устроен стек x86.

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

Название происходит от способа доступа. Значения записываются не в произвольные места, а в порядке "последним вошёл - первым вышел" (LIFO): их помещают на вершину стека и извлекают оттуда. Это соответствует вызовам функций: последняя вызванная функция возвращается первой. Шаблон доступа показан на рис. A-3.

На рис. A-3 стек начинается в адресе 0x7fffffff8000^[1] и изначально содержит пять значений: a-e. Остальная память не инициализирована и отмечена "?". В x86 стек растёт к меньшим адресам, поэтому новые значения имеют меньшие адреса, чем старые.

Регистр указателя стека (rsp) всегда направлен на вершину, где находится последнее помещённое значение. Изначально это e в адресе 0x7fffffff7fe0.

Рис. A-3. Помещение значения f в стек и последующее извлечение в rax

При помещении нового значения f оно оказывается на вершине, а rsp уменьшается и указывает на него. Специальные инструкции x86 push и pop добавляют или удаляют значение и автоматически обновляют rsp. Инструкция call автоматически помещает в стек адрес возврата, а ret извлекает его и возвращается туда.

Инструкция pop копирует значение с вершины в свой операнд, затем увеличивает rsp согласно новой вершине. Например, pop rax на рис. A-3 копирует f из стека в rax и обновляет rsp, направляя его на e. До извлечения можно поместить в стек произвольное число значений с учётом доступной выделенной памяти.

Извлечение не очищает значение: оно лишь копируется, а rsp обновляется. После pop значение f технически остаётся в памяти, пока его не перезапишет последующий push. Поэтому конфиденциальные данные могут остаться доступными, если явно не очистить их.

Теперь, зная работу стека, рассмотрим использование его вызовами функций для хранения аргументов, адреса возврата и локальных переменных.

Рассмотрим другую важную конструкцию. В листинге A-5 программа C с ветвью if/else печатает argc > 5, если argc больше 5, иначе argc <= 5. В листинге A-6 показана соответствующая ассемблерная реализация gcc 5.4.0 со стандартными параметрами, восстановленная objdump.

Листинг A-5. Условная ветвь на C

Листинг A-6. Условная ветвь на ассемблере