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

• непосредственное значение в регистр;

• из регистра в регистр;

• непосредственное значение в память;

• из регистра в память и наоборот;

• из памяти в память.

Первые четыре способа поддерживаются всеми современными архитектурами, а последний присущ именно x86. Классическая RISC-архитектура, такая как ARM, может читать данные из памяти и записывать их в память только командами загрузки и сохранения (соответственно LDR и STR). Например, для такой простой операции, как увеличение находящегося в памяти значения на единицу, потребуются три команды:

1. Прочитать данные из памяти в регистр (LDR).

2. Прибавить единицу к регистру (ADD).

3. Записать регистр обратно в память (STR).

В x86 для такой операции потребуется всего одна команда (INC или ADD), поскольку она может обращаться к памяти непосредственно. Команда MOVS может одновременно читать память и записывать в неё.

ARM:

x86:

Ещё одна важная особенность x86 заключается в переменной длине команд: команда может занимать от 1 до 15 байт. В ARM длина команды составляет 2 или 4 байта.

В зависимости от ассемблера или дизассемблера код на языке ассемблера x86 может записываться в одном из двух вариантов синтаксиса: Intel или AT&T.

Intel:

AT&T:

Важно отметить, что это одни и те же команды, просто записанные по-разному. Между нотациями Intel и AT&T есть несколько различий, наиболее заметные из которых перечислены ниже.

• В AT&T перед именем регистра ставится %, а перед непосредственным значением - $. В Intel этого нет.

• В AT&T к команде добавляется суффикс, указывающий разрядность операции. Например, MOVL (длинное слово), MOVB (байт) и т. д. В Intel этого нет.

• В AT&T операнд-источник указывается перед операндом-приёмником. В Intel порядок обратный.

Дизассемблеры, ассемблеры и другие средства реверс-инжиниринга в Windows (IDA Pro, OllyDbg, MASM и т. д.) обычно используют нотацию Intel, тогда как программы в UNIX часто придерживаются нотации AT&T (GCC). На практике преобладает нотация Intel, и именно она используется во всей книге.

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

Другой распространённый вариант - перемещение данных в память или из памяти. Как и в других соглашениях языков ассемблера, в x86 обращение к памяти обозначается квадратными скобками ([]). (Единственное исключение - команда LEA: в ней используются [], но фактического обращения к памяти не происходит.) Обращение к памяти можно задать несколькими способами, поэтому начнём с простейшего случая.

Ассемблер:

Псевдокод на C:

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

и используется в следующем контексте.

Ассемблер:

Псевдокод на C:

В строке 1 значение читается из памяти и сохраняется в EAX. В строке 3 это значение присваивается полю DeferredRoutine. В строке 2 поле DpcData очищается посредством операции AND с нулём. В строке 4 из памяти читается ещё одно значение и сохраняется в EAX. В строке 6 это значение присваивается полю DeferredContext.

В строке 5 по базовому адресу структуры записывается значение двойного слова 0x113. Почему по базовому адресу записывается двойное слово, если размер первого поля составляет всего 1 байт? Разве при этом не будут неявно заданы также поля Importance и Number? Да, именно так. На рисунке 1-2 показан результат преобразования 0x113 в двоичное представление.

Рисунок 1-2. Размещение значения 0x113 в полях структуры

Полю Type присваивается 0x13 (биты, выделенные полужирным), полю Importance - 0x1 (подчёркнутые биты), а полю Number - 0x0 (оставшиеся биты). Записав одно значение, код сумел одной командой инициализировать три поля! Этот код можно было бы записать следующим образом:

Компилятор решил свернуть три команды в одну, поскольку значения констант были известны заранее и требовалось сэкономить место. Версия из трёх команд занимает 13 байт (дополнительный байт в строке 7 не показан), а версия из одной команды - 6 байт. Ещё одно интересное наблюдение: к памяти можно обращаться с тремя уровнями гранулярности - байт (строки 5-6), слово (строка 6) и двойное слово (строки 1-4 и 8). По умолчанию гранулярность составляет 4 байта, но с помощью префикса переопределения её можно изменить на 1 или 2 байта. В данном примере байты префиксов переопределения - C6 и 66 (выделены курсивом). Другие префиксы будут рассматриваться по мере их появления.

Следующая форма обращения к памяти часто применяется для доступа к объектам типа массивов. В общем виде она записывается так: [база + индекс * масштаб]. Лучше всего понять её на примерах:

На практике такая конструкция встречается в коде, перебирающем массив в цикле. Например:

В строке 2 двойное слово читается со смещением +4 относительно EDI, а затем в строке 3 используется как базовый адрес массива; следовательно, можно заключить, что EDI, вероятно, указывает на структуру, в которой по смещению +4 находится массив. В строке 7 индекс увеличивается. В строке 8 индекс сравнивается со значением по смещению +0 в той же структуре. С учётом этих сведений небольшой цикл можно декомпилировать следующим образом:

Команды MOVSB, MOVSW и MOVSD перемещают данные между двумя адресами памяти с гранулярностью соответственно 1, 2 или 4 байта. В них неявно используются EDI в качестве адреса назначения и ESI в качестве адреса источника. Кроме того, адреса источника и назначения автоматически изменяются в зависимости от флага направления (direction flag, DF) в регистре EFLAGS. Если DF равен 0, адреса уменьшаются; в противном случае они увеличиваются. Эти команды обычно применяются для реализации функций копирования строк или памяти, когда длина известна во время компиляции. Иногда вместе с ними используется префикс REP, повторяющий команду до ECX раз. Рассмотрим следующий пример:

Ассемблер:

Псевдокод на C:

Строка 2 заслуживает особого внимания. Хотя в команде LEA используются [], фактически она не читает данные по адресу памяти, а лишь вычисляет выражение в квадратных скобках и помещает результат в регистр-приёмник. Например, если бы EBP был равен 0x1000, то после выполнения строки 2 EDI был бы равен 0xF40 (=0x1000 - 0xC0). Главное здесь в том, что, несмотря на вводящий в заблуждение синтаксис, LEA не обращается к памяти.

В следующем примере из nt!KiInitSystem используется префикс REP:

Приблизительный эквивалент на C выглядел бы так:

В последнем примере, взятом из nt!MmInitializeProcessAddressSpace, используется сочетание этих команд, поскольку размер копируемых данных не кратен 4:

После строк 1-2 можно заключить, что EAX и EBX, вероятно, указывают на объекты одного типа, поскольку один используется как источник, другой - как приёмник, а смещение в обоих случаях одинаково. Этот фрагмент кода просто копирует 15 байт из одного поля структуры в другое. Обратите внимание: тот же код можно было записать с помощью команды MOVSB с префиксом REP, установив ECX равным 15. Однако это было бы неэффективно, поскольку привело бы к 15 операциям чтения вместо всего пяти.

К другому классу команд перемещения данных с неявно заданными источником и приёмником относятся SCAS и STOS. Подобно MOVS, эти команды могут работать с гранулярностью 1, 2 или 4 байта. SCAS неявно сравнивает AL, AX или EAX с данными, начинающимися по адресу памяти EDI; EDI автоматически увеличивается или уменьшается в зависимости от бита DF в EFLAGS. В силу своей семантики SCAS обычно применяется вместе с префиксом REP для поиска байта, слова или двойного слова в буфере. Например, функцию C strlen() можно реализовать следующим образом:

STOS действует так же, как SCAS, но записывает значение AL, AX или EAX по адресу EDI. Обычно она используется для заполнения буфера постоянным значением (например, в memset()). Рассмотрим пример:

LODS - ещё одна команда из того же семейства. Она читает значение размером 1, 2 или 4 байта по адресу ESI и сохраняет его соответственно в AL, AX или EAX.

1. В этой функции для выполнения работы используется сочетание SCAS и STOS. Сначала объясните, каковы типы [EBP+8] и [EBP+C] соответственно в строках 1 и 8. Затем объясните, что делает этот фрагмент.

Основные арифметические операции - сложение, вычитание, умножение и деление - поддерживаются набором команд непосредственно. Поразрядным операциям AND, OR, XOR, NOT, а также сдвигам влево и вправо тоже соответствуют отдельные машинные команды. За исключением умножения и деления, применение остальных команд не представляет сложности. Эти операции поясняются следующими примерами:

Команды сдвига влево и вправо (строки 11-12) заслуживают некоторых пояснений, поскольку часто встречаются в реальном коде. Обычно они применяются для оптимизации операций умножения и деления, в которых множитель или делитель является степенью двойки. Такой вид оптимизации иногда называют понижением мощности операций (strength reduction), поскольку вычислительно дорогая операция заменяется более дешёвой. Например, целочисленное деление - сравнительно медленная операция, но если делитель является степенью двойки, её можно свести к сдвигу битов вправо: 100/2 эквивалентно 100>>1. Аналогичным образом умножение на степень двойки можно свести к сдвигу битов влево: 100*2 эквивалентно 100<<1.

Умножение без знака и со знаком выполняется соответственно командами MUL и IMUL. Общий вид команды MUL таков: MUL регистр/память. Иными словами, она может работать только со значениями в регистре или памяти. Значение регистра умножается на AL, AX или EAX, а результат, в зависимости от разрядности операнда, сохраняется в AX, DX:AX или EDX:EAX. Например:

Рассмотрим ещё несколько конкретных примеров:

При 32-разрядном умножении результат сохраняется в EDX:EAX потому, что он потенциально может не поместиться в один 32-разрядный регистр, как показано в строках 4-6.

У IMUL есть три формы:

• IMUL регистр/память - то же, что MUL;

• IMUL регистр1, регистр2/память - регистр1 = регистр1 * регистр2/память;

• IMUL регистр1, регистр2/память, непосредственное_значение - регистр1 = регистр2 * непосредственное_значение.

Некоторые дизассемблеры сокращают список параметров. Например:

Деление без знака и со знаком выполняется соответственно командами DIV и IDIV. Они принимают только один параметр (делитель) и имеют следующий вид: DIV/IDIV регистр/память. В зависимости от размера делителя команда DIV использует в качестве делимого AX, DX:AX или EDX:EAX, а полученные частное и остаток сохраняются соответственно в AL/AH, AX/DX или EAX/EDX. Например:

Стек - фундаментальная структура данных в языках программирования и операционных системах. Например, локальные переменные в C хранятся в пространстве стека функции. Когда операционная система переходит из кольца 3 в кольцо 0, она сохраняет в стеке сведения о состоянии. Концептуально стек представляет собой структуру данных типа «последним пришёл - первым вышел», поддерживающую две операции: помещение в стек и извлечение из стека. Поместить в стек означает положить что-либо на его вершину, а извлечь из стека - удалить элемент с вершины. Если говорить конкретно, в x86 стек - это непрерывная область памяти, на которую указывает ESP и которая растёт в сторону уменьшения адресов. Операции помещения в стек и извлечения из него выполняются командами PUSH и POP, которые неявно изменяют ESP. Команда PUSH уменьшает ESP, а затем записывает данные по адресу, на который указывает ESP; POP читает данные и увеличивает ESP. По умолчанию значение автоматического увеличения или уменьшения равно 4, но с помощью префикса переопределения его можно изменить на 1 или 2. На практике оно почти всегда равно 4, поскольку операционная система требует выравнивания стека по границе двойного слова.

Предположим, что изначально ESP указывает на 0xb20000 и имеется следующий код:

Компоновка стека показана на рисунке 1-3.

Рисунок 1-3. Изменение стека командами PUSH и POP

ESP можно изменять непосредственно и другими командами, например ADD и SUB. Хотя в языках программирования высокого уровня существует понятие функций, которые можно вызывать и из которых можно возвращаться, процессор такой абстракции не предоставляет. На самом низком уровне процессор работает только с конкретными объектами, такими как регистры или данные, поступающие из памяти. Как же функции представляются на машинном уровне? Они реализуются с помощью структуры данных стека! Рассмотрим следующую функцию.

C:

Ассемблер:

Функция вызывается следующим кодом.

C:

Ассемблер:

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

1. Помещает в стек адрес возврата (адрес сразу после команды CALL).

2. Записывает в EIP адрес назначения вызова. Тем самым управление фактически передаётся цели вызова и начинается выполнение кода по этому адресу.

RET просто извлекает хранящийся на вершине стека адрес в EIP и передаёт туда управление (буквально как POP EIP, хотя такой последовательности команд в x86 не существует). Например, если требуется начать выполнение по адресу 0x12345678, достаточно сделать следующее:

Соглашение о вызовах - это набор правил, определяющих работу вызовов функций на машинном уровне. Оно задаётся двоичным интерфейсом приложений (Application Binary Interface, ABI) конкретной системы. Например, следует ли передавать параметры через стек, в регистрах или обоими способами? В каком порядке передавать параметры: слева направо или справа налево? Где хранить возвращаемое значение: в стеке, регистрах или и там и там? Соглашений о вызовах много, но наиболее распространены CDECL, STDCALL, THISCALL и FASTCALL. (Компилятор также может создать собственное нестандартное соглашение о вызовах, однако здесь такие соглашения рассматриваться не будут.) Их семантика обобщена в таблице 1-2.

Таблица 1-2. Соглашения о вызовах

Теперь вернёмся к фрагменту кода и разберём, как вызывается функция addme. В строках 1 и 3 два параметра помещаются в стек; ECX и EAX являются соответственно первым и вторым параметрами. В строке 4 функция addme вызывается командой CALL. При этом в стек немедленно помещается адрес возврата 0x4129FE, после чего начинается выполнение по адресу 0x4113A0. Компоновка стека после выполнения строки 4 показана на рисунке 1-4.

Рисунок 1-4. Стек после вызова функции addme

После выполнения строки 4 мы оказываемся в теле функции addme. В строке 1 EBP помещается в стек. В строке 2 регистру EBP присваивается текущее значение указателя стека. Эта последовательность из двух команд обычно называется прологом функции, поскольку она создаёт новый кадр функции. В строке 4 читается значение по адресу EBP+8 - первый параметр в стеке; в строке 5 читается второй параметр. Обратите внимание: доступ к параметрам осуществляется с использованием EBP в качестве базового регистра. В таком контексте EBP называется базовым указателем кадра (см. строку 2), поскольку он указывает на кадр стека текущей функции, а доступ к параметрам и локальным переменным можно получать относительно него. Посредством оптимизации, называемой исключением указателя кадра (frame pointer omission), компилятору также можно предписать создавать код, в котором EBP не используется как базовый указатель кадра. При такой оптимизации доступ к локальным переменным и параметрам выполняется относительно ESP, а EBP можно использовать как регистр общего назначения, подобный EAX, EBX, ECX и т. д. В строке 6 числа складываются, а результат сохраняется в EAX. В строке 8 указателю стека присваивается значение базового указателя кадра. В строке 9 сохранённое в строке 1 значение EBP извлекается в EBP. Эта последовательность из двух команд обычно называется эпилогом функции, поскольку находится в конце функции и восстанавливает предыдущий кадр функции. Теперь на вершине стека находится адрес возврата, сохранённый командой CALL по адресу 0x4129F9. В строке 10 выполняется RET, которая извлекает адрес из стека и возобновляет выполнение по адресу 0x4129FE. В строке 5 фрагмента размер стека уменьшается на 8, поскольку по правилам соглашения о вызовах CDECL стек должен очищать вызывающий код.

Если бы в функции addme имелись локальные переменные, после строки 2 коду потребовалось бы увеличить стек, вычтя значение из ESP. После этого все локальные переменные были бы доступны по отрицательным смещениям относительно EBP.

1. Исходя из того, что вы узнали о CALL и RET, объясните, как можно прочитать значение EIP. Почему нельзя просто выполнить MOV EAX, EIP?

2. Придумайте не менее двух последовательностей команд, устанавливающих EIP в 0xAABBCCDD.

3. Что произошло бы в функции addme из примера, если бы перед выполнением RET указатель стека не был правильно восстановлен?

4. Во всех рассмотренных соглашениях о вызовах возвращаемое значение хранится в 32-разрядном регистре EAX. Что происходит, если возвращаемое значение не помещается в 32-разрядный регистр? Напишите программу, чтобы провести эксперимент и проверить свой ответ. Изменяется ли этот механизм от компилятора к компилятору?

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

Физическая память компьютерной системы делится на блоки размером 4 Кбайт, называемые страницами. (Размер страницы может превышать 4 Кбайт, однако другие размеры здесь рассматриваться не будут.) Адреса памяти делятся на две категории: виртуальные и физические. Виртуальными называются адреса, которые используются выполняемыми процессором командами при включённой страничной организации памяти. Например:

Физические адреса - это фактические ячейки памяти, которыми процессор пользуется при обращении к памяти. Перед обращением модуль управления памятью процессора (memory management unit, MMU) незаметно преобразует каждый виртуальный адрес в физический. Пользователю виртуальный адрес может казаться просто очередным числом, однако с точки зрения MMU у него есть определённая структура. В системах x86 с поддержкой расширения физических адресов (physical address extension, PAE) виртуальный адрес памяти можно разделить на индексы трёх таблиц и смещение: таблицы указателей каталогов страниц (page directory pointer table, PDPT), каталога страниц (page directory, PD), таблицы страниц (page table, PT) и записи таблицы страниц (page table entry, PTE). PDPT представляет собой массив из четырёх 8-байтовых элементов, каждый из которых указывает на PD. PD - это массив из 512 элементов размером по 8 байт, каждый из которых указывает на PT. PT - массив из 512 элементов размером по 8 байт, каждый из которых содержит PTE. Например, виртуальный адрес 0xBF80EE6B можно представить так, как показано на рисунке 1-5.

Рисунок 1-5. Разбиение виртуального адреса 0xBF80EE6B

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

Процесс преобразования адреса строится вокруг этих трёх таблиц и регистра CR3. В CR3 хранится физический базовый адрес PDPT. В оставшейся части этого раздела пошагово разбирается преобразование виртуального адреса 0xBF80EE6B в реальной системе (см. рисунок 1-5):

Согласно документации, младшие 12 бит записи PDPT отведены под флаги и зарезервированные биты, а остальные используются как физический адрес базы PD. В режиме PAE бит 63 является флагом NX, поэтому его также необходимо сбросить. В данном примере мы этого не делали, поскольку он уже равен 0. (Мы рассматриваем страницы исполняемого кода.)

И снова, согласно документации, младшие 12 бит записи PD используются для флагов и зарезервированных битов, а остальные задают базу PT:

И опять же, младшие 12 бит можно очистить, чтобы получить базу записи страницы:

По завершении всего процесса устанавливается, что виртуальный адрес 0xBF80EE6B преобразуется в физический адрес 0x6694E6B.

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

Здесь прерывания и исключения рассматриваются лишь кратко, поскольку полное описание их реализации приведено в главе 3 «Ядро Windows».

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

Во время выполнения команды процессор может столкнуться с исключениями. Например, команда может вызвать ошибку деления на ноль, обратиться к недопустимому адресу или инициировать переход между уровнями привилегий. Для целей этого обсуждения исключения можно разделить на две категории: сбои (faults) и ловушки (traps). Сбой - это исправимое исключение. Например, когда процессор выполняет команду, обращающуюся к допустимому адресу памяти, но данных нет в основной памяти (они были выгружены), возникает исключение ошибки страницы. Процессор обрабатывает его, сохраняя текущее состояние выполнения, вызывая обработчик ошибки страницы для исправления исключения (путём загрузки данных в память), а затем повторно выполняя ту же команду, которая теперь уже не должна вызвать ошибку страницы. Ловушка - исключение, возникающее при выполнении особых видов команд. Например, команда SYSENTER заставляет процессор начать выполнение общего обработчика системных вызовов; после завершения обработчика выполнение возобновляется с команды, непосредственно следующей за SYSENTER. Таким образом, главное различие между сбоем и ловушкой состоит в том, откуда возобновляется выполнение. Операционные системы обычно реализуют системные вызовы с помощью механизма прерываний и исключений.

Завершим главу пошаговым разбором функции, содержащей менее 100 команд. Это процедура DllMain из образца J. У упражнения две цели. Во-первых, оно задействует почти все понятия, рассмотренные в этой главе (за исключением switch-case). Во-вторых, оно знакомит с важным требованием практического реверс-инжиниринга: умением читать технические руководства и документацию в Интернете. Вот эта функция:

В строках 3-4 формируется пролог функции: сохраняется предыдущий базовый указатель кадра и устанавливается новый. Строка 5 резервирует в стеке 0x130 байт. Строка 6 сохраняет EDI. В строке 7 выполняется команда SIDT, записывающая 6-байтовый регистр IDT в заданную область памяти. Строка 8 читает двойное слово по адресу EBP-6 и сохраняет его в EAX. В строках 9-10 проверяется, меньше ли EAX значения 0x8003F400 или равен ему. Если да, управление передаётся строке 18; в противном случае продолжается выполнение строки 11. В строках 11-12 выполняется похожая проверка, но условием служит «не ниже 0x80047400». Если условие выполняется, управление передаётся строке 18; в противном случае продолжается выполнение строки 13. Строка 13 очищает EAX. Строка 14 восстанавливает значение EDI, сохранённое в строке 6. Строки 15-16 восстанавливают предыдущий базовый указатель кадра и указатель стека. Строка 17 прибавляет к указателю стека 0xC байт, а затем возвращает управление вызывающему коду.

Прежде чем обсуждать следующую часть, отметим несколько особенностей первых 17 строк. Команда SIDT (строка 7) записывает содержимое регистра IDT в 6-байтовую область памяти. Что представляет собой регистр IDT? В справочном руководстве Intel/AMD сказано, что IDT - это массив из 256 записей размером по 8 байт, каждая из которых содержит указатель на обработчик прерывания, селектор сегмента и смещение. При возникновении прерывания или исключения процессор использует номер прерывания как индекс IDT и вызывает обработчик, указанный в соответствующей записи. Регистр IDT имеет размер 6 байт: старшие 4 байта содержат базовый адрес массива, или таблицы, IDT, а младшие 2 байта - предел таблицы. Теперь понятно, что строка 8 в действительности читает базовый адрес IDT. В строках 9 и 11 проверяется, находится ли базовый адрес в диапазоне (0x8003F400, 0x80047400). Что особенного в этих на первый взгляд случайных константах? Поиск в Интернете показывает, что 0x8003F400 - это базовый адрес IDT в 32-разрядной Windows XP. Это можно проверить в отладчике ядра:

Зачем код проверяет такое поведение? Одно из возможных объяснений состоит в том, что разработчик считал базовый адрес IDT, попадающий в этот диапазон, «недопустимым» либо возникающим в результате виртуализации. Если IDTR «недопустим», функция автоматически возвращает ноль. Этот код можно декомпилировать в C следующим образом:

Если базовый адрес IDT выглядит допустимым, выполнение кода продолжается со строки 18. В строках 19-20 EAX очищается, а ECX устанавливается в 0x49. В строке 21 EDI присваивается адрес EBP-0x12C; поскольку EBP является базовым указателем кадра, EBP-0x12C - адрес локальной переменной. Строка 22 записывает ноль по адресу, на который указывает EBP-0x130. В строках 23-24 EAX и 2 помещаются в стек. Строка 25 заполняет нулями буфер размером 0x124 байта, начинающийся с EBP-0x12C. В строке 26 вызывается CreateToolhelp32Snapshot:

Эта функция Win32 API принимает два целочисленных параметра. Как правило, функции Win32 API следуют соглашению о вызовах STDCALL. Следовательно, параметры dwFlags и th32ProcessId равны 0x2 (строка 24) и 0x0 (строка 23). Функция перечисляет все процессы в системе и возвращает дескриптор, который будет использоваться в Process32Next. В строках 27-28 возвращённое значение сохраняется в EDI и сравнивается с -1. Если оно равно -1, возвращаемое значение устанавливается в 0 и функция завершается (строки 30-34); в противном случае выполнение продолжается со строки 35. В строке 36 EAX присваивается адрес локальной переменной, ранее инициализированной нулём в строке 22; строка 40 инициализирует её значением 0x128. В строках 37-39 ESI, EAX и EDI помещаются в стек. В строке 41 вызывается Process32First.

Прототип функции:

Соответствующее определение структуры:

Поскольку эта функция принимает два параметра, hSnapshot - это EDI (строка 39, ранее полученный от CreateToolhelp32Snapshot в строке 27 дескриптор), а lppe - адрес локальной переменной (EBP-0x130). Так как lppe указывает на структуру PROCESSENTRY32, сразу становится понятно, что локальная переменная по адресу EBP-0x130 имеет тот же тип. Это также согласуется с документацией Process32First, где сказано, что перед вызовом функции полю dwSize следует присвоить размер структуры PROCESSENTRY32 (то есть 0x128). Теперь известно, что в строках 19-25 эта структура просто инициализировалась нулями. Кроме того, можно утверждать, что локальная переменная начинается по адресу EBP-0x130 и заканчивается по адресу EBP-0x8.

Строка 42 проверяет возвращённое значение Process32Next. Если оно равно нулю, выполнение начинается со строки 70; в противном случае оно продолжается со строки 43. В строке 44 адрес функции stricmp сохраняется в ESI. В строке 45 ECX присваивается адрес локальной переменной (EBP-0x10C), которая оказывается полем структуры PROCESSENTRY32 (см. предыдущий абзац). В строках 46-48 значения 0x10007C50 и ECX помещаются в стек, после чего вызывается stricmp. Известно, что stricmp принимает в качестве аргументов две символьные строки; следовательно, ECX должен указывать на поле szExeFile структуры PROCESSENTRY32, а 0x10007C50 является адресом строки:

Строка 49 очищает стек, поскольку stricmp использует соглашение о вызовах CDECL. Строка 50 проверяет возвращённое значение stricmp. Если оно равно нулю, то есть строка совпала с "explorer.exe", выполнение начинается со строки 66; в противном случае оно продолжается со строки 52. Теперь строки 18-51 можно декомпилировать следующим образом:

Строки 52-65 почти совпадают с предыдущим блоком, но образуют цикл с двумя условиями выхода. Первое условие выполняется, когда Process32Next возвращает FALSE (строка 58), а второе - когда stricmp возвращает ноль. Строки 52-65 можно декомпилировать следующим образом:

После выхода из цикла выполнение возобновляется со строки 66. В строках 67-68 соответствующие процессу поля th32ParentProcessID и th32ProcessID структуры PROCESSENTRY32 сохраняются в EAX и ECX, после чего выполнение продолжается со строки 37. Обратите внимание: строка 66 также является целью перехода из строки 43.

В строках 70-74 читается параметр fdwReason функции DllMain (EBP+C) и проверяется, равен ли он 0 (DLL_PROCESS_DETACH). Если да, возвращаемое значение устанавливается в 0 и функция завершается; в противном случае выполняется переход к строке 82. В строках 82-85 проверяется, превышает ли fdwReason единицу (то есть равен ли он DLL_THREAD_ATTACH или DLL_THREAD_DETACH). Если да, возвращаемое значение устанавливается в 1 и функция завершается; в противном случае выполнение продолжается со строки 86. В строках 86-92 вызывается CreateThread:

где lpStartAddress равен 0x100032D0. Этот блок можно декомпилировать следующим образом:

Проанализировав функцию, можно заключить, что исходный замысел разработчика был таким:

1. Определить, имеет ли целевая машина «нормальную» IDT.

2. Проверить, запущен ли в системе explorer.exe, то есть вошёл ли кто-либо в систему.

3. Создать основной поток, заражающий целевую машину.

1. Самостоятельно повторите практический разбор. Нарисуйте компоновку стека, включая параметры и локальные переменные.

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

3. В некоторых ассемблерных листингах в имени функции имеется префикс @, за которым следует число. Объясните, когда и почему появляется такое оформление имени.

4. Реализуйте на языке ассемблера x86 следующие функции: strlen, strchr, memcpy, memset, strcmp, strset.

5. Декомпилируйте следующие процедуры ядра Windows:

• KeInitializeDpc;

• KeInitializeApc;

• ObFastDereferenceObject (и объясните используемое соглашение о вызовах);

• KeInitializeQueue;

• KxWaitForLockChainValid;

• KeReadyThread;

• KiInitializeTSS;

• RtlValidateUnicodeString.

6. Образец H. Функция sub_13846 ссылается на несколько структур, типы которых не вполне ясны. Сначала восстановите прототип функции, а затем попытайтесь реконструировать поля структур. Прочитав главу 3, вернитесь к этому упражнению и проверьте, изменилось ли ваше понимание. (Обратите внимание: этот образец предназначен для 32-разрядной Windows XP.)

7. Образец H. В функции sub_10BB6 имеется цикл, который что-то ищет. Сначала восстановите прототип функции, а затем определите типы на основании контекста. Подсказка: вероятно, стоит держать под рукой копию спецификации PE.

8. Образец H. Декомпилируйте sub_11732 и объясните, какая программная конструкция, скорее всего, использовалась в исходном коде.

9. Образец L. Объясните, что делает функция sub_1000CEA0, а затем декомпилируйте её обратно в C.

10. Если текущий уровень привилегий кодируется в CS, который может изменять код пользовательского режима, почему код пользовательского режима не может изменить CS и тем самым сменить CPL?

11. Прочитайте главу Virtual Memory в томе 3 Intel Software Developer Manual и в томе 2 AMD64 Architecture Programmer's Manual: System Programming. Самостоятельно выполните несколько преобразований виртуальных адресов в физические и проверьте результат с помощью отладчика ядра. Объясните, как работает предотвращение выполнения данных (data execution prevention, DEP).

12. Любимая библиотека Брюса для дизассемблирования x86/x64 - BeaEngine от BeatriX (www.beaengine.org). Поэкспериментируйте с ней: напишите программу, дизассемблирующую двоичный файл начиная с его точки входа.

x64 является расширением x86, поэтому большинство свойств архитектуры остаются прежними; небольшие различия касаются размера регистров и отсутствия некоторых команд (например, PUSHAD). В следующих разделах рассматриваются существенные различия.

Набор регистров содержит 18 64-разрядных регистров общего назначения и показан на рисунке 1-6. Обратите внимание: имена 64-разрядных регистров имеют префикс R.

Рисунок 1-6. Регистры общего назначения x64

Хотя RBP по-прежнему можно использовать как базовый указатель кадра, в реальном коде, созданном компилятором, для этой цели он применяется редко. Большинство компиляторов x64 просто рассматривают RBP как ещё один регистр общего назначения, а к локальным переменным обращаются относительно RSP.

x64 поддерживает так называемую адресацию относительно RIP, которая позволяет командам ссылаться на данные, расположенные по смещению относительно RIP. Например:

В строке 1 адрес loc_A (равный 0x7) читается и сохраняется в RAX. Адресация относительно RIP в основном служит для создания позиционно-независимого кода.

Большинство арифметических команд автоматически расширяются до 64 разрядов, даже если операнды имеют размер всего 32 бита. Например:

В x64 виртуальные адреса имеют ширину 64 бита, однако большинство процессоров не поддерживает полное 64-разрядное пространство виртуальных адресов. Современные процессоры Intel и AMD используют для адресного пространства только 48 бит. Все адреса виртуальной памяти должны иметь каноническую форму. Виртуальный адрес находится в канонической форме, если все биты от 63-го до старшего реализованного бита равны либо 1, либо 0. На практике это означает, что биты 48-63 должны совпадать с битом 47. Например:

Если код попытается разыменовать неканонический адрес, система вызовет исключение.

Напомним, что некоторые соглашения о вызовах в x86 требуют передавать параметры в стеке. В x64 большинство соглашений о вызовах передают параметры через регистры. Например, в 64-разрядной Windows существует единственное соглашение о вызовах: первые четыре параметра передаются через RCX, RDX, R8 и R9, а остальные помещаются в стек справа налево. В Linux первые шесть параметров передаются через RDI, RSI, RDX, RCX, R8 и R9.

1. Объясните два способа получить указатель команд в x64. По меньшей мере один из них должен использовать адресацию относительно RIP.

2. Выполните преобразование виртуального адреса в физический в x64. Были ли существенные отличия от x86?

В предыдущем разделе упоминалось, что ARM является архитектурой загрузки и сохранения, а значит, перед выполнением операций данные необходимо загружать в регистры. Обращаться к памяти могут только команды загрузки и сохранения; все остальные команды способны работать лишь с регистрами. Загрузить означает прочитать данные из памяти и сохранить их в регистре; сохранить - записать содержимое регистра в ячейку памяти. В ARM командами загрузки и сохранения являются LDR/STR, LDM/STM и PUSH/POP.

Эти команды могут загружать из памяти и сохранять в неё 1, 2 или 4 байта. Их полный синтаксис довольно сложен, поскольку существует несколько способов задать смещение и побочные эффекты обновления базового регистра. Рассмотрим простейший случай:

В команде из строки 1 R0 является базовым регистром, а R3 - приёмником; значение слова по адресу R0 загружается в R3. В строке 2 R4 является базовым регистром, а R3 - приёмником; значение из R3 сохраняется по адресу памяти R4. Этот пример прост, поскольку адрес памяти задаётся базовым регистром.

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

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

• STR Ra, [Rb, imm]

• LDR Ra, [Rc, imm]

Rb - базовый регистр, а imm - смещение, которое прибавляется к Rb.

Предположим, например, что R0 содержит указатель на структуру KDPC и имеется следующий код.

Определение структуры:

Код:

В данном случае R0 - базовый регистр, а непосредственными значениями являются 0x1, 0x2, 0xC, 0x10 и 0x1C. Фрагмент можно перевести в C следующим образом:

Эта форма смещения подобна MOV Reg, [Reg + Imm] в x86/x64.

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

• STR Ra, [Rb, Rc]

• LDR Ra, [Rb, Rc]

В зависимости от контекста базовым регистром или смещением может быть Rb либо Rc. Рассмотрим два примера.

Пример 1:

Пример 2:

Это подобно форме MOV Reg, [Reg + Reg] в x86/x64.

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

• LDR Ra, [Rb, Rc, <shifter>]

• STR Ra, [Rb, Rc, <shifter>]

Rb является базовым регистром, Rc - непосредственным значением, а <shifter> - операцией над непосредственным значением, обычно сдвигом влево или вправо для его масштабирования. Например:

KeNumberNodes и KeNodeBlock являются соответственно глобальным целым числом и массивом указателей на KNODE.

Строки 1 и 5 просто загружают эти глобальные объекты в регистры (этот синтаксис объясняется далее). Строка 8 перебирает массив KeNodeBlock (база находится в R0), а R3 является индексом, умноженным на 2 (поскольку это массив указателей, а размер указателя на данной платформе составляет 4 байта). В строках 10-13 инициализируются некоторые поля элемента KNODE. Строка 14 увеличивает индекс. В строке 17 индекс сравнивается с размером массива (размер находится в R1; см. строку 4), и, если индекс меньше размера, цикл продолжается.

Этот фрагмент можно приблизительно перевести в C следующим образом:

Это подобно форме MOV, Reg, [Reg + idx * scale] в x86/x64.

Рассмотрев три формы смещения, в оставшейся части раздела обсудим режимы адресации: со смещением, с предварительной индексацией и с последующей индексацией. Они различаются лишь тем, изменяется ли базовый регистр и, если да, каким образом. Во всех предыдущих примерах смещения применялся режим адресации со смещением, при котором базовый регистр никогда не изменяется. Это самый простой и распространённый режим. Его легко узнать по отсутствию восклицательного знака (!) и по тому, что непосредственное значение находится внутри квадратных скобок. (В некоторых публикациях эти режимы называются предварительной индексацией, предварительной индексацией с обратной записью и последующей индексацией. Используемая здесь терминология соответствует официальной документации ARM.) Общий синтаксис режима со смещением: LDR Rd, [Rn, offset].

Режим адресации с предварительной индексацией означает, что базовый регистр будет обновлён окончательным адресом памяти, использованным в операции обращения. По семантике он очень похож на префиксную форму унарного оператора ++ или -- в C. Синтаксис этого режима: LDR Rd, [Rn, offset]!. Например:

Режим адресации с последующей индексацией означает, что базовый регистр используется как окончательный адрес, после чего обновляется вычисленным смещением. Это очень похоже на постфиксную форму унарного оператора ++ или -- в C. Синтаксис этого режима: LDR Rd, [Rn], offset. Например:

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

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

Очевидно, согласно предыдущему разделу такой синтаксис недопустим. С технической точки зрения это псевдокоманды, используемые дизассемблерами для упрощения ручного анализа. Внутри они используют форму LDR с непосредственным смещением и PC в качестве базового регистра; иногда это называется адресацией относительно PC (или относительно RIP в x64). В двоичных файлах ARM обычно имеется пул литералов - область памяти в разделе, где хранятся константы, строки и смещения, на которые другой код может ссылаться позиционно-независимым образом. (Пул литералов является частью кода, поэтому находится в том же разделе.) В предыдущем фрагменте код ссылается на 32-разрядную константу, строку и смещение импортированной функции, хранящиеся в пуле литералов. Эта псевдокоманда удобна тем, что позволяет одной командой поместить 32-разрядную константу в регистр. Для ясности рассмотрим следующий фрагмент:

Как дизассемблер сократил первую команду из LDR R3, [PC, #0xD4] до альтернативной формы? Поскольку код находится в состоянии Thumb, PC равен адресу текущей команды плюс 4, то есть 0x0100B138; используется форма с непосредственным смещением относительно PC, а значит, выполняется попытка прочитать слово по адресу 0x0100B20C (=0x100B138+0xD4), где как раз и находится требуемая константа.

Ещё одна связанная с этим команда - ADR, которая получает адрес метки или функции и помещает его в регистр. Например:

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

LDM и STM подобны LDR/STR, но загружают и сохраняют несколько слов по заданному базовому адресу. Они удобны для перемещения нескольких блоков данных из памяти и в память. Общий синтаксис выглядит так:

• LDM<mode> Rn[!], {Rm}

• STM<mode> Rn[!], {Rm}

Rn является базовым регистром и содержит адрес памяти, из которой выполняется загрузка или в которую выполняется сохранение; необязательный восклицательный знак (!) означает, что базовый регистр следует обновить новым адресом (обратная запись). Rm - диапазон регистров для загрузки или сохранения. Существует четыре режима:

• IA (увеличение после, Increment After) - данные сохраняются начиная с ячейки памяти, заданной базовым адресом. При обратной записи записывается адрес на 4 байта выше последней ячейки. Если режим не указан, по умолчанию используется именно этот.

• IB (увеличение до, Increment Before) - данные сохраняются начиная с ячейки памяти на 4 байта выше базового адреса. При обратной записи записывается адрес последней ячейки.

• DA (уменьшение после, Decrement After) - данные сохраняются таким образом, что последней ячейкой является базовый адрес. При обратной записи записывается адрес на 4 байта ниже самой младшей ячейки.

• DB (уменьшение до, Decrement Before) - данные сохраняются таким образом, что последняя ячейка расположена на 4 байта ниже базового адреса. При обратной записи записывается адрес первой ячейки.

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

Строка 5 сохраняет адрес памяти в R6; содержимое этой области памяти (0x1050c) представляет собой три слова (строка 17). В строках 6-8 регистрам R0-R2 присваиваются несколько констант. Строка 9 загружает три слова в R3-R5, начиная с ячейки памяти, заданной R6. Как показано в строках 24-26, R3-R5 содержат ожидаемые значения. Строка 10 сохраняет R0-R2, начиная с ячейки памяти, заданной R6. Строка 29 показывает, что были записаны ожидаемые значения. Результат предыдущих операций показан на рисунке 2-2.

Рисунок 2-2. Загрузка и сохранение нескольких регистров без обратной записи

Ниже приведён тот же эксперимент с обратной записью:

В строке 9 используется режим IA с обратной записью, поэтому R6 обновляется адресом на 4 байта выше последней ячейки (строка 23). То же можно наблюдать в строках 10, 27 и 30. Результат предыдущего фрагмента показан на рисунке 2-3.

Рисунок 2-3. Загрузка и сохранение нескольких регистров с обратной записью

Поскольку LDM и STM могут перемещать сразу несколько слов, они обычно используются в операциях блочного копирования или перемещения. Например, иногда с их помощью встраивается memcpy, если длина копируемых данных известна во время компиляции. Они подобны команде MOVS с префиксом REP в x86. Рассмотрим следующие фрагменты кода, созданные двумя разными компиляторами из одного исходного файла.

Компилятор A:

Компилятор B:

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

Ещё одно распространённое место, где встречаются LDM/STM, - начало и конец функций в состоянии ARM. В таком контексте они используются как пролог и эпилог. Например:

STMFD и LDMFD являются псевдокомандами соответственно STMDB и LMDIA/LDM.

Последний набор команд загрузки и сохранения - PUSH и POP. Они подобны LDM/STM, за исключением двух особенностей:

• в качестве базового адреса неявно используется SP;

• SP обновляется автоматически.

Как и в архитектуре x86/x64, стек растёт вниз, в сторону меньших адресов. Общий синтаксис: PUSH/POP {Rn}, где Rn может быть диапазоном регистров.

PUSH сохраняет регистры в стеке таким образом, что последняя ячейка находится на 4 байта ниже текущего указателя стека, и обновляет SP адресом первой ячейки. POP загружает регистры начиная с текущего указателя стека и обновляет SP адресом на 4 байта выше последней ячейки. Фактически PUSH/POP эквивалентны STMDB/LDMIA с обратной записью и SP в качестве базового указателя. Ниже приведён краткий пошаговый пример работы команд:

Предыдущий фрагмент показан на рисунке 2-4.

Рисунок 2-4. Работа команд PUSH и POP

Чаще всего PUSH/POP встречаются в начале и конце функций. В таком контексте они служат прологом и эпилогом (подобно STMFD/LDMFD в состоянии ARM). Например:

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

Все рассмотренные до сих пор примеры выполнялись линейно. В большинстве программ присутствуют условия и циклы. На уровне языка ассемблера эти конструкции реализуются с помощью флагов условий, хранящихся в регистре состояния прикладной программы (APSR). APSR является псевдонимом CPSR и подобен регистру EFLAG в x86. На рисунке 2-5 показаны соответствующие флаги, описанные ниже:

• N (флаг отрицательного значения) - устанавливается, когда результат операции отрицателен (старший значащий бит результата равен 1).

• Z (флаг нуля) - устанавливается, когда результат операции равен нулю.

• C (флаг переноса) - устанавливается, когда результат операции над двумя беззнаковыми значениями вызывает переполнение.

• V (флаг переполнения) - устанавливается, когда результат операции над двумя знаковыми значениями вызывает переполнение.

• IT (биты If-then) - кодируют различные условия для команды Thumb IT. Они рассматриваются далее.

Биты N, Z, C и V идентичны битам SF, ZF, CF и OF регистра EFLAG в x86. Они используются для реализации условий и циклов языков высокого уровня, а также условного выполнения на уровне отдельных команд. Равенство описывается через эти флаги. В таблице 2-1 приведены распространённые отношения и соответствующие им флаги.

Рисунок 2-5. Поля регистров CPSR и APSR

Таблица 2-1. Коды условий и их значение

Команды можно выполнять условно, добавляя в конец один из этих суффиксов. Например, BLT означает переход, если условие LT истинно. (Это аналог JL в x86.) По умолчанию команды не обновляют флаги условий, если не указан суффикс S; команды сравнения (CBZ, CMP, TST, CMN и TEQ) обновляют флаги автоматически, поскольку обычно используются перед командами перехода.

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

ARM:

Псевдокод на C:

Следующая по распространённости команда сравнения - TST; её синтаксис совпадает с CMP. Семантика идентична TEST в x86: выполняется Rn & X, устанавливаются соответствующие флаги, а результат отбрасывается. Обычно она служит для проверки значения на равенство другому значению или для проверки флагов. Как и после большинства команд сравнения, за ней обычно следует условный переход. Например:

В состоянии Thumb-2 есть две популярные команды сравнения: CBZ и CBNZ. Их синтаксис прост: CBZ/CBNZ Rn, label, где Rn - регистр, а label - смещение, к которому следует перейти при истинном условии. CBZ переходит к label, если регистр равен нулю. CBNZ действует так же, но проверяет условие неравенства нулю. Обычно эти команды используются, чтобы определить, равно ли число нулю или указатель NULL. Типичный пример:

ARM:

Псевдокод на C:

Другие команды сравнения - CMN и TEQ; они выполняют над операндами соответственно сложение и исключающее ИЛИ. Поскольку применяются они редко, здесь они не рассматриваются.

Как было показано, команду перехода B можно превратить в условный переход, добавив суффикс (BEQ, BLE, BLT, BLS и т. д.). В действительности таким же способом можно условно выполнять большинство команд ARM. Если условие не выполняется, команду можно считать не выполняющей никаких действий. Условное выполнение на уровне команд способно сократить количество переходов и тем самым ускорить выполнение. Например:

ARM:

Псевдокод на C:

Благодаря команде LDR в строке 3 сразу понятно, что R0 является указателем. В строке 1 проверяется, равен ли R0 значению NULL. Если да (EQ), строка 2 устанавливает R0 в 1; в противном случае NEQ загружает в R0 значение по адресу R0+0x68 (строка 3), после чего выполняется возврат. Поскольку EQ и NEQ не могут быть истинны одновременно, будет выполнена только одна из этих команд. Обратите внимание: команд перехода здесь нет.

В отличие от большинства команд ARM, команды Thumb (за исключением B) нельзя выполнять условно без команды IT (if-then). Эта команда, характерная для Thumb-2, позволяет условно выполнить до четырёх следующих за ней команд. Общий синтаксис: ITxyz cc, где cc - код условия для первой команды, а x, y и z описывают условия соответственно второй, третьей и четвёртой команд. Условия для команд после первой обозначаются одной из двух букв: T или E. T означает, что для выполнения условие должно совпадать с cc; E означает, что команда выполняется только при условии, обратном cc. Рассмотрим пример.

ARM:

Псевдокод на C:

Строка 1 выполняет сравнение и устанавливает флаг условия. Строка 2 задаёт условия и начинает блок if-then. NE является условием выполнения первой команды; первая E (после IT) показывает, что условие выполнения второй команды обратно условию первой. (EQ обратно NE.) Вторая E задаёт то же самое для третьей команды. Строки 3-5 находятся внутри блока IT.

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

Операторы switch-case можно представить как множество объединённых операторов if-else. Поскольку проверяемое выражение и целевая метка известны во время компиляции, компиляторы обычно создают таблицу переходов для хранения адресов (ARM) или смещений (Thumb) каждого обработчика варианта. Определив индекс таблицы переходов, компилятор косвенно переходит к адресу назначения, загружая его в PC. В состоянии ARM это обычно выполняется командой LDR, где PC является регистром-приёмником и базовым регистром. Рассмотрим пример:

В строке 2 проверяется, находится ли вариант в диапазоне; если нет, выполняется обработчик по умолчанию (строка 4). Строка 3 выполняется условно, если R1 находится в диапазоне; она переходит к обработчику варианта, индексируя таблицу переходов, и загружает адрес назначения в PC. Напомним, что в состоянии ARM PC находится на 8 байт дальше текущей команды, поэтому таблица переходов обычно хранится в 8 байтах от команды LDR.

В режиме Thumb применяется та же идея, но таблица переходов содержит смещения, а не адреса. Для поддержки переходов по таблицам со смещениями размером в байт или полуслово в ARM были добавлены команды TBB и TBH. Для TBB записи таблицы являются байтовыми значениями, а для TBH - полусловами. Чтобы получить окончательный адрес назначения перехода, запись таблицы нужно умножить на два и прибавить к PC. Ниже предыдущий пример представлен с использованием TBB:

Поскольку код находится в состоянии Thumb, PC расположен на 4 байта дальше текущей команды; следовательно, для варианта 8 запись таблицы находится по адресу 0x0101E612 (=0x0101E60A+8) и равна 0x6d, а обработчик расположен по адресу 0x101E6E4 (=PC+(0x6d*2)). Как и в предыдущем примере, таблица переходов обычно размещается после команды TBB/TBH. Обратите внимание: TBB/TBH используются только в состоянии Thumb.

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

ARM поддерживает JIT-компиляцию (just-in-time, JIT) и самомодифицирующийся код (self-modifying code, SMC). JIT-код - это машинный код, динамически созданный JIT-компилятором. Например, языки Microsoft .NET компилируются в промежуточный язык (MSIL), который для выполнения ядром ЦП преобразуется в машинный код конкретной архитектуры (x86, x64, ARM и т. д.). SMC - код, создаваемый или изменяемый текущим потоком команд. Распространённый пример SMC - закодированный шелл-код, который декодируется и выполняется во время работы. И JIT, и SMC требуют записать в память новые данные, которые впоследствии выбираются для выполнения.

В ядре ARM существуют отдельные строки кэша для команд (i-cache) и данных (d-cache): команды выполняются из i-cache, а обращения к памяти проходят через d-cache. Согласованность этих строк кэша не гарантируется, то есть данные, записанные в один кэш, могут стать видимыми другому не сразу. Предположим, например, что i-cache содержит четыре команды из потока команд, а пользователь создаёт новые или изменённые команды в том же месте (тем самым обновляя d-cache). Поскольку кэши не согласованы, i-cache может не узнать о недавнем изменении и выполнить устаревшие команды, что способно привести к загадочным сбоям или неправильным результатам. При разработке JIT-систем или шелл-кода такая ситуация явно нежелательна. Решение состоит в том, чтобы явно заставить i-cache обновиться (это также называют сбросом кэша). В ARM это делается обновлением регистра сопроцессора управления системой (CP15):

Большинство операционных систем предоставляет интерфейс для этой операции, поэтому писать её самостоятельно не требуется. В Linux используется __clear_cache, а в Windows - FlushInstructionCache.

В ARM нет команды, подобной cmpxchg (сравнение и обмен) в x86; вместо неё используются две команды: LDREX и STREX. Они подобны LDR/STR, но перед загрузкой или сохранением получают исключительный доступ к адресу памяти. Вместе они обычно применяются для реализации встроенных операций сравнения и обмена. Например:

ARM:

Псевдокод на C:

Строка 3 выполняет атомарную загрузку в R2 и сравнивает значение с 0; если оно равно нулю, то обменивается на ноль, а результат возвращается в R3. В действительности это реализация InterlockedCompareExchange в Windows.

Иногда встречается код с командами DMB, DSB и ISB. Это барьерные команды, которые перед выполнением последующих команд обеспечивают синхронизацию обращений к памяти и выборки команд. В некоторых случаях это необходимо, поскольку обращения к памяти и команды могут выполняться не по порядку (то есть ЦП способен выполнить команды в порядке, отличном от представленного в ассемблерном коде), а другие выполняющиеся потоки могут не увидеть обновлённый результат и, следовательно, получить несогласованное представление данных. Поэтому эти команды часто встречаются в коде, реализующем блокировки.

При загрузке ядро ARM начинает выполнять код в состоянии ARM по адресу памяти 0x00000000 или 0xFFFF0000 в зависимости от параметра сопроцессора 15. Это определяется битом вектора (V) регистра управления системой (CP15, C1/C0). Если он равен 0, вектор исключения находится по адресу 0x00000000; в противном случае - по адресу 0xFFFF0000. Этот адрес обычно расположен во флеш-памяти (оперативная память ещё не инициализирована и использовать её нельзя), а находящееся там содержимое обычно называется векторами исключений. В ARM существует список предопределённых векторов, начинающийся по базовому адресу. Обработчик исключения RESET стоит в таблице первым, поэтому выполняется после события сброса. Поскольку это первый выполняемый код, обычно он начинает с базовой настройки оборудования и запускает процесс загрузки. Ниже приведён вектор исключений из реального устройства:

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

Операционная система управляет аппаратными ресурсами и предоставляет пользователям службы. Поскольку пользовательский код (обычно работающий в режиме USR) имеет меньше привилегий, чем код ядра или операционной системы (обычно работающий в режиме SVC), для запроса службы ОС ему необходимо использовать определённый интерфейс. На практике такой интерфейс предоставляется через программное прерывание или специальную команду ловушки процессора, а служба обычно реализуется в виде системных вызовов. (Например, в 32-разрядной Linux x86 для системного вызова можно использовать прерывание 0x80 или специальную команду SYSENTER; в x64 это обеспечивает команда SYSCALL.) В ARM специальной команды системного вызова нет, поэтому системные вызовы реализуются посредством программного прерывания. При возникновении программного прерывания процессор переключается в режим супервизора для его обработки. Программные прерывания могут вызываться командой SWI/SVC. (Эти команды идентичны и отличаются лишь названием.)

Обе команды принимают непосредственное значение как параметр: некоторые операционные системы используют его как индекс таблицы системных вызовов, а другие не используют параметр, но требуют поместить номер системного вызова в регистр (например, Windows использует для этого R12). В некоторых системах Linux номер системного вызова помещается в R7, а аргументы передаются через R0-R2. Например:

Linux (Ubuntu):

Windows RT:

SVC переходит в режим супервизора, копирует соответствующие пользовательские регистры в их собственную область, выполняет запрошенную функцию и после завершения возвращает управление. Как SVC узнаёт, куда возвращаться? Обычно управление возвращается к команде после SVC. Перед обработкой исключения режим SVC копирует адрес возврата в R14_svc - банковый регистр режима SVC. Банковыми называются регистры, имеющие значение только в контексте определённого режима процессора. Например, R13_svc и R14_svc являются банковыми регистрами режима SVC, поэтому их значения отличаются от R13-R14 в режиме USR.

Хотя для программной точки останова существует специальная команда BKPT, реализовать её можно несколькими способами. Первый - команда BKPT, которая вызывает обработчик исключения аварийного завершения предварительной выборки; затем обработчик может передать управление отладчику. Другой распространённый способ - вызвать обработчик исключения неопределённой команды с помощью неопределённой команды. В кодировке команд ARM имеется зарезервированный диапазон, который гарантированно является неопределённым.

Каждая команда в состоянии ARM кодирует арифметическое условие для поддержки условного выполнения. По умолчанию используется условие AL (выполнять всегда). Это условие кодируется в четырёх старших значащих битах кода операции (биты 28-31); AL определяется как 0b1110, то есть 0xE. Если внимательно посмотреть на фрагменты ассемблерного кода (в состоянии ARM), можно заметить, что байт-код обычно заканчивается последовательностью вида 0xE*. Более того, при просмотре команд в шестнадцатеричном редакторе видно, что 0xE* часто встречается через каждые четыре байта. Например:

Почему важно знать эту закономерность? Потому что код ARM иногда встроен в ПЗУ или флеш-память и может не соответствовать определённому формату файла. В ходе реверс-инжиниринга порой предоставляется лишь необработанный дамп памяти почти без контекста, и тогда бывает полезно угадать архитектуру по кодам операций. Другая причина связана с эксплойтами. Шелл-код может быть встроен в эксплойт, доставляемый по сети или внутри документа; для анализа шелл-код необходимо извлечь из остального сетевого трафика. Иногда это просто и его границы очевидны, иногда - нет. Однако умение распознать закономерность позволяет быстро предположить начало и конец кода. Способность узнавать границы команд в кажущейся случайной массе данных важна. Возможно, позже вы оцените её по достоинству.

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

Подобно многим операционным системам, Windows делит виртуальное адресное пространство на две части: пространство ядра и пользовательское пространство. На x86 и ARM верхние 2 Гбайт зарезервированы для ядра, а нижние 2 Гбайт - для пользовательских процессов. Следовательно, виртуальные адреса от 0 до 0x7fffffff находятся в пользовательском пространстве, а адреса 0x80000000 и выше - в пространстве ядра. На x64 действует тот же принцип, за исключением того, что пользовательское пространство простирается от 0 до 0x000007ff`ffffffff, а пространство ядра начинается с 0xffff0800`00000000. На рисунке 3-1 показана общая компоновка для x86 и x64. Пространство памяти ядра в основном одинаково во всех процессах. Однако выполняющиеся процессы имеют доступ только к своему пользовательскому адресному пространству; код режима ядра может обращаться к обоим пространствам. (Некоторые диапазоны адресов ядра, например находящиеся в сеансовом и гиперпространстве, различаются от процесса к процессу.) Этот факт важно помнить, поскольку мы вернемся к нему позже при обсуждении контекста выполнения. Страницы режима ядра и пользовательского режима различаются специальным битом в элементе таблицы страниц.

Когда поток процесса планируется к выполнению, ОС изменяет регистр, зависящий от конкретного процессора, так, чтобы он указывал на каталог страниц именно этого процесса. Благодаря этому все преобразования виртуальных адресов в физические относятся к этому процессу, а не к другим. Именно так ОС может поддерживать несколько процессов, каждый из которых пребывает в иллюзии, что владеет всем адресным пространством пользовательского режима. В архитектурах x86 и x64 регистром базы каталога страниц является CR3; на ARM это регистр базы таблицы трансляции (translation table base register, TTBR).

Рисунок 3-1. Общая компоновка адресного пространства на x86 и x64

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

Область управления процессором (processor control region, PCR) - это отдельная для каждого процессора структура, в которой хранятся критически важные сведения о ЦП и его состояние. Например, на x86 она содержит базовый адрес IDT и текущий IRQL. Внутри PCR находится другая структура данных, называемая блоком управления областью процессора (processor region control block, PRCB). Это отдельная для каждого процессора структура, содержащая сведения о процессоре: тип, модель и скорость ЦП, текущий выполняемый им поток, следующий поток для выполнения, очередь DPC для выполнения и так далее. Как и PCR, эта структура не документирована, однако ее определение все равно можно просмотреть с помощью отладчика ядра:

PCR текущего процессора всегда доступна из режима ядра через специальные регистры. Она хранится в сегменте FS (x86), сегменте GS (x64) или одном из регистров системного сопроцессора (ARM). Например, ядро Windows экспортирует две процедуры для получения текущих EPROCESS и ETHREAD: PsGetCurrentProcess и PsGetCurrentThread. Эти процедуры работают, запрашивая PCR/PRCB:

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

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

Windows описывает и хранит сведения о системных вызовах с помощью двух структур данных: дескриптора таблицы служб и массива указателей на функции/смещений. Дескриптор таблицы служб - это структура, содержащая метаданные о системных вызовах, поддерживаемых ОС; ее определение официально не документировано, однако многие исследователи восстановили посредством обратного анализа следующие важные поля. (Эти поля также можно выяснить, проанализировав процедуры KiSystemCall64 или KiSystemService.)

Base - указатель на массив указателей на функции или смещений (в зависимости от процессора); номер системного вызова является индексом в этом массиве. Limit - количество элементов в массиве. Ядро хранит два глобальных массива KSERVICE_DESCRIPTOR_DESCRIPTOR: KeServiceDescriptorTable и KeServiceDescriptorTableShadow. Первый содержит собственную таблицу системных вызовов; второй содержит те же данные, а также таблицу системных вызовов для потоков GUI. Кроме того, ядро хранит два глобальных указателя на массивы адресов/смещений: KiServiceTable указывает на таблицу системных вызовов, не относящихся к GUI, а W32pServiceTable - на таблицу GUI. На рисунке 3-2 показано, как эти структуры данных связаны друг с другом на x86.

Рисунок 3-2. Связи таблиц системных вызовов на x86

На x86 поле Base представляет собой массив указателей на функции системных вызовов:

Однако на x64 и ARM это массив 32-разрядных целых чисел, в которых закодированы смещение системного вызова и количество аргументов, передаваемых через стек. Смещение содержится в старших 20 битах, а количество аргументов в стеке - в младших 4 битах. Для получения действительного адреса системного вызова смещение прибавляется к базе KiServiceTable. Например:

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

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

Ядро Windows использует абстрактное понятие, называемое уровнем запроса прерывания (interrupt request level, IRQL), для управления прерываемостью системы. Прерывания можно разделить на две общие категории: программные и аппаратные. Программные прерывания - синхронные события, инициируемые условиями в выполняющемся коде (деление на 0, выполнение команды INT, страничный сбой и т. д.); аппаратные прерывания - асинхронные события, инициируемые устройствами, подключенными к ЦП. Аппаратные прерывания асинхронны, поскольку могут возникнуть в любой момент; обычно они используются для сообщения процессору об операциях ввода-вывода. Подробности работы аппаратных прерываний зависят от оборудования, поэтому их скрывает уровень аппаратных абстракций (hardware abstraction layer, HAL) Windows.

Если говорить конкретно, IRQL - это просто число (определяемое типом KIRQL, который в действительности является UCHAR), назначенное процессору. Windows связывает IRQL с прерыванием и определяет порядок его обработки. Точное число, соответствующее каждому IRQL, может различаться от платформы к платформе, поэтому мы будем ссылаться на них только по именам. Общее правило состоит в том, что прерывания на IRQL X маскируют все прерывания с уровнем ниже X. После обработки прерывания ядро понижает IRQL, чтобы иметь возможность выполнять другие задачи. Поскольку IRQL является отдельным для каждого процессора значением, несколько процессоров могут одновременно работать на разных IRQL.

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

• PASSIVE_LEVEL (0) - самый низкий IRQL в системе. На этом IRQL выполняется весь код пользовательского режима и большая часть кода ядра.

• APC_LEVEL (1) - IRQL, на котором выполняются асинхронные вызовы процедур (asynchronous procedure calls, APC). (См. раздел «Асинхронные вызовы процедур».)

• DISPATCH_LEVEL (2) - самый высокий программный IRQL в системе. На этом IRQL работают диспетчер потоков и отложенные вызовы процедур (deferred procedure calls, DPC). (См. раздел «Отложенные вызовы процедур».) Код на этом IRQL не может ожидать.

Хотя IRQL может показаться свойством планирования потоков, это не так. IRQL - свойство процессора, тогда как приоритет потока - свойство потока.

Поскольку IRQL является программной абстракцией приоритета прерываний, нижележащая реализация напрямую связана с аппаратным обеспечением. Например, на x86/x64 локальный контроллер прерываний (local interrupt controller, LAPIC) в процессоре имеет программируемый регистр приоритета задач (task priority register, TPR) и доступный только для чтения регистр приоритета процессора (processor priority register, PPR). TPR определяет приоритет прерывания; PPR представляет текущий приоритет прерывания. Процессор доставляет только те прерывания, приоритет которых выше PPR. На практике, когда Windows требуется изменить приоритет прерывания, она вызывает функции ядра KeRaiseIrql/KeLowerIrql, которые программируют TPR локального APIC. Это можно увидеть в определении для x64 (на x64 CR8 - теневой регистр, обеспечивающий быстрый доступ к TPR LAPIC; системы x86 для задания TPR должны программировать LAPIC):

KeRaiseIrql

KeLowerIrql

Изложенные выше понятия объясняют, почему код, выполняющийся на высоком IRQL, не может быть вытеснен кодом с более низким IRQL.

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

Это различие важно, поскольку оно имеет последствия для кода, выполняющегося на высоких IRQL. Предположим, поток ядра в данный момент выполняется на DISPATCH_LEVEL и обращается к памяти, которая была выгружена и должна быть обработана обработчиком страничного сбоя; поскольку обработчику страничного сбоя (см. MmAccessFault) требуется отправить запрос для загрузки страницы с диска, а диспетчер потоков работает на DISPATCH_LEVEL, обработчик не может устранить исключение, в результате чего возникает bugcheck. Это одна из причин, по которым код, выполняющийся на DISPATCH_LEVEL, должен находиться только в памяти невыгружаемого пула и обращаться только к ней.

Память пула выделяется и освобождается семействами функций ExAllocatePool* и ExFreePool*. По умолчанию память невыгружаемого пула (тип NonPagedPool) отображается с разрешениями на чтение, запись и выполнение на x86/x64, но без разрешения на выполнение на ARM; в Windows 8 можно запросить неисполняемую память невыгружаемого пула, указав тип пула NonPagedPoolNX. Память выгружаемого пула отображается с разрешениями на чтение, запись и выполнение на x86, но без разрешения на выполнение на x64/ARM.

Список дескрипторов памяти (memory descriptor list, MDL) - структура данных, используемая для описания набора физических страниц, отображаемых виртуальным адресом. Каждый элемент MDL описывает один непрерывный буфер, а несколько элементов можно связать друг с другом. После построения MDL для существующего буфера физические страницы можно закрепить в памяти (то есть они не будут использованы повторно) и отобразить по другому виртуальному адресу.

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

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

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

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

Планировщик Windows работает с потоками.

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

Процессы

Потоки

Существуют также аналогичные структуры данных пользовательского режима, в которых хранятся сведения о процессах и потоках. Для процессов это блок окружения процесса (process environment block, PEB/ntdll!_PEB), хранящий такие основные сведения, как базовый адрес загрузки, загруженные модули, кучи процесса и так далее. Для потоков это блок окружения потока (thread environment block, TEB/ntdll!_TEB), хранящий данные планирования потока и сведения о связанном процессе. Код пользовательского режима всегда может обращаться к TEB через сегмент FS (x86), сегмент GS (x64) или сопроцессор 15 (ARM). Эти объекты часто встречаются в системном коде, поэтому ниже перечислены способы доступа к ним:

Текущий поток (режим ядра)

x86

x64

ARM

TEB (пользовательский режим)

x86

x64

ARM

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

• Контекст потока - контекст определенного потока (или, как правило, контекст запрашивающего потока, если поток пользовательского режима запрашивает обслуживание у ядра).

• Системный контекст - контекст потока, выполняющегося в процессе System.

• Произвольный контекст - контекст того потока, который выполнялся до того, как планировщик взял управление на себя.

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

• При загрузке драйвера его точка входа (DriverEntry) выполняется в системном контексте.

• Когда приложение пользовательского режима отправляет запрос (IOCTL) драйверу, обработчик IOCTL драйвера работает в контексте потока (то есть в контексте потока пользовательского режима, инициировавшего запрос).

• APC выполняются в контексте потока (то есть в контексте потока, в очередь которого была помещена APC).

• DPC и таймеры выполняются в произвольном контексте.

• Рабочие элементы выполняются в системном контексте.

• Системные потоки выполняются в системном контексте, если параметр ProcessHandle равен NULL (обычный случай).

Например, точка входа драйвера имеет доступ только к адресному пространству процесса System, а потому не может обратиться к пространству какого-либо другого процесса, не вызвав нарушения доступа. Если поток режима ядра хочет изменить свой контекст выполнения на контекст другого процесса, он может использовать документированный API KeStackAttachProcess. Это полезно, когда драйверу необходимо читать или записывать память определенного процесса.

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

Объекты событий используются для обозначения состояния операции. Например, когда в системе остается мало памяти невыгружаемого пула, ядро может уведомить драйвер с помощью событий. Событие может находиться в одном из двух состояний: сигнальном или несигнальном. Значение сигнального и несигнального состояния зависит от сценария использования. Внутренне событие является объектом, определенным структурой KEVENT и инициализированным API KeInitializeEvent. После инициализации события поток может ожидать его с помощью KeWaitForSingleObject или KeWaitForMultipleObjects. События часто используются в драйверах, чтобы уведомить другие потоки о завершении обработки или выполнении определенного условия.

Таймеры используются для обозначения того, что прошел определенный интервал времени. Например, при каждом наступлении нового столетия ядро выполняет некоторый код для обновления времени; нижележащим механизмом для этого служат таймеры. Внутренне объекты таймеров определяются структурой KTIMER и инициализируются процедурой KeInitializeTimer/Ex. При инициализации таймеров можно указать необязательную процедуру DPC, которая будет выполнена по истечении времени. По определению, каждый процессор имеет собственный таймер очереди; в частности, поле TimerTable в PRCB представляет собой список таймеров данного процессора. Таймеры часто используются для периодического выполнения действий или их выполнения в определенное время. И таймеры, и DPC подробнее рассматриваются далее в этой главе.

Мьютексы используются для монопольного доступа к общему ресурсу. Например, если два потока одновременно изменяют общий связанный список без мьютекса, они могут повредить список; решение заключается в том, чтобы обращаться к связанному списку только при удержании мьютекса. Хотя основная семантика мьютекса не меняется, ядро Windows предлагает два разных вида мьютексов: защищенный мьютекс и быстрый мьютекс. Защищенные мьютексы быстрее быстрых мьютексов, но доступны только в Windows 2003 и более новых версиях. Внутренне мьютекс определяется структурой FAST_MUTEX или GUARDED_MUTEX и инициализируется функцией ExInitialize{Fast,Guarded}Mutex. После инициализации их можно захватывать и освобождать с помощью различных API; дополнительные сведения см. в документации Windows Driver Kit.

Спин-блокировки также используются для монопольного доступа к общему ресурсу. Хотя концептуально они похожи на мьютексы, они применяются для защиты общих ресурсов, к которым обращаются на DISPATCH_LEVEL или более высоком IRQL. Например, ядро захватывает спин-блокировку перед изменением критически важных глобальных структур данных, таких как список активных процессов; это необходимо потому, что в многопроцессорной системе несколько потоков могут одновременно обращаться к списку и изменять его. Внутренне спин-блокировки определяются структурой KSPIN_LOCK и инициализируются функцией KeInitializeSpinLock. После инициализации их можно захватывать и освобождать с помощью различных документированных API; дополнительные сведения см. в документации WDK. Обратите внимание, что код, удерживающий спин-блокировку, выполняется на DISPATCH_LEVEL или выше; следовательно, выполняемый код и память, к которой он обращается, всегда должны находиться в физической памяти.

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

Windows использует пакеты запросов ввода-вывода (I/O request packets, IRP) для описания запросов ввода-вывода к компонентам режима ядра (например, драйверам). Когда приложение пользовательского режима вызывает API для запроса данных, диспетчер ввода-вывода создает IRP, описывающий запрос, и определяет, какому устройству отправить IRP для обработки. С момента создания IRP до его завершения драйвером он может пройти через несколько устройств, а для выполнения запроса могут быть созданы дополнительные IRP. IRP можно рассматривать как фундаментальную единицу обмена данными между устройствами для запросов ввода-вывода. В заголовках WDK IRP определяется частично непрозрачной структурой IRP, однако большинство ее полей не документированы (отсюда частичная непрозрачность):

С точки зрения программирования IRP можно разделить на две области: статическую и динамическую. Статическая часть - структура IRP с основными сведениями о запросе, например о том, кто запросил операцию (ядро или пользователь), запрашивающем потоке и данных, переданных пользователем. Поля Overlay и Tail являются объединениями, содержащими метаданные запроса. Динамическая часть находится непосредственно после заголовка; это массив структур IO_STACK_LOCATION, содержащих сведения о запросе для конкретных устройств. IO_STACK_LOCATION содержит основную и дополнительную функции IRP, параметры запроса и необязательную процедуру завершения. Как и IRP, это частично непрозрачная структура:

Поле Parameters является объединением, поскольку параметр зависит от номера основной и дополнительной функции. Windows имеет предопределенный список универсальных основных и дополнительных функций для описания всех типов запросов. Например, запрос чтения файла приводит к созданию IRP с основной функцией IRP_MJ_READ; когда Windows запрашивает ввод у драйвера класса клавиатуры, она также использует IRP_MJ_READ. При создании IRP диспетчер ввода-вывода определяет, сколько структур IO_STACK_LOCATION выделить, исходя из количества устройств в текущем стеке устройств. Каждое устройство отвечает за подготовку IO_STACK_LOCATION для следующего устройства. Напомним, что драйвер может задать процедуру завершения с помощью API IoSetCompletionRoutine; в действительности это встроенная процедура, задающая поле CompletionRoutine в IO_STACK_LOCATION.

На рисунке 3-8 показана связь между этими двумя структурами в IRP.

Рисунок 3-8. Статическая и динамическая части IRP и связь с IO_STACK_LOCATION

Обратите внимание, что «следующее» расположение стека является элементом непосредственно над «текущим» (а не после него). Это важно знать, поскольку процедуры расположения стека, такие как IoGetCurrentIrpStackLocation, IoSkipCurrentIrpStackLocation, IoGetNextIrpStackLocation и другие, просто возвращают указатели на эти элементы массива с помощью арифметики указателей.

Хотя IRP обычно создаются диспетчером ввода-вывода в ответ на запросы пользователей или других устройств, их также можно создавать с нуля и отправлять другим устройствам для обработки. Драйвер может выделить IRP с помощью IoAllocateIrp, связать его с потоком, заполнить основной и дополнительный коды IRP, задать количество/размер IO_STACK_LOCATION, заполнить параметры и отправить его целевому устройству для обработки с помощью IoCallDriver. Некоторые руткиты используют этот механизм, чтобы напрямую отправлять запросы драйверу файловой системы и тем самым обходить перехват системных вызовов. В упражнении вы проанализируете один такой руткит.

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

• Устаревший программный драйвер - программное обеспечение, которое работает в кольце 0 и взаимодействует с ядром через документированные и недокументированные интерфейсы. К этому типу относится большинство руткитов и драйверов безопасности.

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

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

Стандартной моделью драйверов Windows является Windows Driver Model (WDM). WDM определяет как набор интерфейсов, которые должны реализовывать драйверы, так и правила, которым следует подчиняться для безопасного взаимодействия с ядром. Эта модель определена со времен Windows 2000, и все анализируемые вами драйверы основаны на ней. Поскольку писать надежные аппаратные драйверы Plug and Play с полноценным управлением питанием и обработкой всех особенностей синхронизации, используя только интерфейсы WDM, чрезвычайно сложно, Microsoft представила инфраструктуру Windows Driver Foundation (WDF). По сути, WDF - это набор библиотек, построенных поверх WDM, который упрощает разработку драйверов, ограждая разработчиков от непосредственного взаимодействия с WDM. WDF делится на две категории: инфраструктуру драйверов режима ядра (kernel-mode driver framework, KMDF) и инфраструктуру драйверов пользовательского режима (user-mode driver framework, UMDF). KMDF предназначена для драйверов режима ядра (например, клавиатур и USB-устройств), а UMDF - для драйверов пользовательского режима (например, драйверов принтеров). В этой книге рассматриваются только драйверы, основанные на модели WDM.

Драйвер можно рассматривать как DLL, загружаемую в адресное пространство ядра и выполняющуюся с теми же привилегиями, что и ядро. У него есть четко определенная точка входа, и он может регистрировать процедуры диспетчеризации для обслуживания запросов пользователей или других драйверов. Обратите внимание, что у драйвера нет главного потока выполнения; он просто содержит код, который ядро может вызывать при определенных обстоятельствах. Именно поэтому драйверам обычно приходится регистрировать процедуры диспетчеризации у диспетчера ввода-вывода (см. следующий раздел). При анализе драйверов первая и самая важная задача - найти эти процедуры диспетчеризации и понять, как они взаимодействуют с ядром.

Все драйверы имеют точку входа DriverEntry, определяемую следующим образом:

DriverEntry

DRIVER_OBJECT

Когда требуется загрузить драйвер, его образ отображается в память пространства ядра, для него создается объект драйвера, регистрируемый у диспетчера объектов, а затем диспетчер ввода-вывода вызывает точку входа. DRIVER_OBJECT - структура, заполняемая диспетчером ввода-вывода в процессе загрузки драйвера; официальная документация указывает, что это частично непрозрачная структура, однако ее полное определение можно увидеть в заголовочных файлах. Полю DriverInit присваивается точка входа драйвера, и диспетчер ввода-вывода непосредственно вызывает это поле. Основная обязанность DriverEntry - инициализировать параметры, специфичные для драйвера, и при необходимости зарегистрировать процедуры диспетчеризации IRP. Эти процедуры хранятся в массиве MajorFunction. Как упоминалось ранее, Windows имеет предопределенный набор основных функций IRP для универсального описания каждого запроса ввода-вывода; когда драйверу поступает запрос ввода-вывода, диспетчер ввода-вывода вызывает обработчик соответствующей основной функции IRP для обработки запроса. Поэтому в DriverEntry часто встречается код следующего вида:

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

Если таблица MajorFunction не инициализирована, она содержит стандартный обработчик IopInvalidDeviceRequest, который просто возвращает запрашивающей стороне ошибку.

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

RegistryPath - путь драйвера в реестре. Он создается как часть обычного процесса установки драйвера.

В предыдущем разделе говорилось, что диспетчер ввода-вывода создает DRIVER_OBJECT для каждого драйвера, загруженного в систему. Драйвер может создать один или несколько объектов устройств. Объекты устройств определяются частично непрозрачной структурой DEVICE_OBJECT:

DriverObject - объект драйвера, связанный с этим объектом устройства. Если драйвер создал несколько объектов устройств, NextDevice указывает на следующий объект устройства в цепочке. Драйвер может создать несколько объектов устройств для управления различными обрабатываемыми им аппаратными ресурсами. Если объекты устройств не созданы, никто не сможет отправлять устройству запросы. Обычно драйверы создают объекты устройств в DriverEntry с помощью API IoCreateDevice.

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

Драйвер может «подключить» один из собственных объектов устройств к другому объекту устройства, чтобы получать запросы ввода-вывода, предназначенные целевому объекту устройства. Например, если устройство A подключается к устройству B, все запросы IRP, отправленные B, сначала направляются A. Этот механизм подключения используется для поддержки драйверов-фильтров, чтобы они могли изменять или проверять запросы к другим драйверам. Поле AttachedDevice указывает на устройство, к которому подключен текущий объект устройства. Подключение устройств выполняется семейством API IoAttachDevice.

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

Для достижения своих целей многие разработчики руткитов прибегают к перехвату функций в ядре. Однако весь код ядра отображается только для чтения, поэтому попытка его исправления приведет к bugcheck. На x86/x64 этот механизм защиты в действительности обеспечивается на аппаратном уровне специальным управляющим регистром CR0. CR0 определяет несколько важных параметров процессора, например работает ли он в защищенном режиме и включена ли страничная адресация; кроме того, он определяет, может ли ЦП записывать данные на страницы только для чтения (бит WP). CR0 доступен только коду, выполняющемуся в кольце 0. По умолчанию Windows включает бит WP, запрещающий запись на страницы, помеченные только для чтения.

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

Строки 2-3 копируют CR0 в EAX и сохраняют его в локальной переменной. Строки 4-5 отключают бит 16 в EAX и записывают значение обратно в CR0. Бит 16 в CR0 является битом WP.

Существуют как минимум два других решения, которые не изменяют CR0 напрямую. Они используют MDL и знания MMU платформы. Вам потребуется реализовать это в одном из упражнений.

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

Ядро экспортирует символ KeServiceDescriptorTable, содержащий структуру KSERVICE_TABLE_DESCRIPTOR со сведениями о системных вызовах. (Напомним, что на x64 этот символ не экспортируется.) Именно так большинство руткитов обращается к таблице системных вызовов. Следующий шаг - определить расположение целевого системного вызова. Напомним, что системные вызовы идентифицируются номером, а не именем. У авторов руткитов есть несколько способов найти нужный системный вызов. Один способ - жестко задать индекс системного вызова. Другой - дизассемблировать заглушку системного вызова и получить индекс из нее. Оба метода имеют компромисс: их просто реализовать, но они опираются на шаблоны кода или данных, которые могут меняться от пакета обновления к пакету обновления; на некоторых платформах они могут быть надежными, а на других наверняка приведут к нестабильности системы. Несмотря на ненадежность, оба метода часто применяются руткитами в реальных условиях. Например, образец G содержит следующий код:

Строки 5-10 сохраняют адрес KiServiceTable в ECX, сохраняют адрес ZwQuerySystemInformation в ESI и отключают бит WP. Строка 12 получает второй байт ZwQuerySystemInformation; это делается потому, что код предполагает: первая команда функции перемещает номер системного вызова в регистр, а потому 32-разрядное значение после кода операции содержит фактический номер системного вызова (см. следующую врезку). Строки 13-14 перезаписывают этот элемент таблицы служб новой функцией sub_1123e. Теперь все вызовы ZwQuerySystemInformation будут перенаправляться в sub_1123e.

Раздел - это объект, используемый для описания памяти, поддерживаемой некоторым видом хранилища. Раздел может поддерживаться обычным файлом или файлом подкачки. Раздел, поддерживаемый файлом, - это раздел, содержимое памяти которого соответствует содержимому файла на диске; изменения раздела записываются непосредственно на диск. Раздел, поддерживаемый файлом подкачки, - это раздел, содержимое которого поддерживается файлом подкачки; изменения такого раздела отбрасываются после его закрытия. Драйвер может создать раздел с помощью API ZwCreateSection, а затем отобразить его представление в другой процесс с помощью ZwMapViewOfSection. Каждое представление, по сути, является диапазоном виртуальных адресов, через который можно обращаться к памяти, представленной связанным объектом раздела. Следовательно, раздел может иметь несколько представлений.

Теперь, когда вы хорошо усвоили понятия ядра Windows и драйверов, пришло время применить эти знания при анализе настоящих руткитов. Этот раздел преследует две цели: объяснить ход мыслей при обратном анализе режима ядра и продемонстрировать применение методов разработки драйверов к пониманию руткитов.

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

1. Найдите DriverEntry и определите обработчики диспетчеризации IRP, если они имеются.

2. Определите, подключается ли драйвер к другому устройству для фильтрации/перехвата его запросов ввода-вывода. Если да, каково целевое устройство?

3. Если драйвер создает объект устройства, определите имя и размер расширения устройства.

4. Восстановите структуру расширения устройства, наблюдая за использованием ее полей.

5. Если драйвер поддерживает IOCTL, найдите все коды IOCTL и соответствующие им функции. Определите используемый ими метод буферизации.

6. Найдите DPC, рабочие элементы, APC, таймеры, процедуры завершения, функции обратного вызова и системные потоки.

7. Постарайтесь понять, как все части сочетаются друг с другом.

Пошаговый разбор начинается с образца A.

Его DriverEntry начинается по адресу 0x105F0 и заканчивается по адресу 0x106AD. Сначала она инициализирует структуру UNICODE_STRING строками \Device\fsodhfn2m и \DosDevices\fsodhfn2m. В режиме ядра большинство строк описывается структурой UNICODE_STRING:

Она инициализируется с помощью API RtlInitUnicodeString. Строка «Device» - имя устройства в диспетчере объектов; строка «DosDevices» используется как символическая ссылка на фактическое имя устройства. Диспетчер объектов Windows хранит и организует объекты в структуре, похожей на файловую систему, с корнем в \. Существуют четко определенные каталоги, например \Devices, \BaseNamedObjects, \KernelObjects и так далее. \DosDevices - псевдоним каталога \??; он существует потому, что, когда приложения пользовательского режима задают путь к объекту, к которому хотят обратиться, к нему добавляется префикс \??\; каталог \?? содержит символические ссылки, указывающие на настоящие объекты. Например, когда пользователь хочет обратиться к "c:\test.txt" через API CreateFile, фактическим путем, отправляемым ядру, является "\??\c:\test.txt"; поскольку "c:" - символическая ссылка на \Device\HarddiskVolume2 (в вашей системе она может отличаться), весь путь в конечном итоге разрешается в \Device\HarddiskVolume2\test.txt. Символическая ссылка необходима потому, что API пользовательского режима обычно обращаются к устройствам через каталог \??; если бы символических ссылок там не было, устройство могло бы оказаться недоступным приложениям пользовательского режима.

После инициализации двух строк функция переходит к созданию фактического объекта устройства. IoCreateDevice определяется следующим образом:

DriverObject - DRIVER_OBJECT вызывающей стороны; это объект драйвера, с которым связан новый объект устройства. DeviceExtensionSize - количество байтов памяти невыгружаемого пула, которое следует выделить для структуры, специфичной для драйвера. Поскольку это структура, определяемая пользователем, восстановить ее поля очень важно. DeviceName - собственное имя устройства. DeviceType - один из предопределенных типов FILE_DEVICE_*; если устройство не относится ни к одной универсальной категории, вместо этого используется FILE_DEVICE_UNKNOWN. DeviceCharacteristics обозначает характеристику устройства; чаще всего встречается FILE_DEVICE_SECURE_OPEN. Exclusive определяет, может ли существовать более одного дескриптора устройства. DeviceObject получает фактический объект устройства.

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

NT_SUCCESS() - распространенный макрос, проверяющий, что status больше или равен 0. После успешного создания объекта выполнение переходит к следующему коду:

Строки 1-8 присваивают некоторым полям DRIVER_OBJECT два указателя на функции. Что находится по смещениям 0x38, 0x40, 0x70 и 0x34?

По смещению 0x34 находится процедура DriverUnload; теперь мы знаем, что драйвер поддерживает динамическую выгрузку, а sub_10580 является процедурой выгрузки. Смещение 0x38 - начало массива MajorFunction; напомним, что это массив обработчиков диспетчеризации IRP. Поскольку существует не более 28 универсальных основных функций IRP, массив MajorFunction имеет 28 элементов. Первый индекс равен 0 и соответствует IRP_MJ_CREATE; следовательно, мы знаем, что sub_10300 является обработчиком этого IRP. Смещение 0x40 - третий элемент массива MajorFunction (индекс 2); он соответствует IRP_MJ_CLOSE, и sub_10300 повторно используется как обработчик. Смещение 0x70 - 16-й элемент массива (индекс 0xe), соответствующий IRP_MJ_DEVICE_CONTROL, и его обработчиком также является sub_10300. На этом этапе мы знаем, что sub_10300 является обработчиком IRP чтения, закрытия и управления устройством.

Строки 10-13 удаляют существующую символическую ссылку и создают новую, указывающую на ранее созданный объект устройства.

Теперь можно продолжить декомпиляцию этого блока в DriverEntry следующим образом:

Чтобы облегчить дальнейшую работу, можно переименовать sub_10300 в IRP_ReadCloseDeviceIo, а sub_10580 - в DRV_Unload.

Следующий блок по адресу 0x1068F удаляет ранее созданный объект устройства, если создать символическую ссылку не удалось. Обратите внимание, что он получает объект устройства из объекта драйвера, а не использует указатель, переданный IoCreateDevice. Этот блок можно декомпилировать следующим образом:

На этом декомпиляция DriverEntry данного руткита завершена. Подведем итог уже полученным сведениям:

• Драйвер создает объект устройства с именем \Device\fsodhfn2m.

• Он поддерживает динамическую выгрузку, а процедурой выгрузки является sub_10580 (переименованная в DRV_Unload).

• Он поддерживает операции IRP_MJ_READ, IRP_MJ_WRITE и IRP_MJ_DEVICE_CONTROL, а обработчиком является sub_10300 (переименованная в IRP_ReadCloseDeviceIo).

• Он создает символическую ссылку на объект устройства. Если это не удается, драйвер возвращает ошибку.

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

После небольшой обработки наша процедура выгрузки выглядит так:

Предыдущий код можно декомпилировать следующим образом:

Как уже говорилось, важнейшим ключом к пониманию функциональности драйвера служат его обработчики диспетчеризации IRP. Начиная анализ _IRP_ReadCloseDeviceIo, рассмотрим ее начало:

Ее прототип нам уже известен, поскольку он одинаков для всех обработчиков IRP. При анализе обработчиков IRP необходимо помнить несколько фактов:

• IRP - динамическая структура, после заголовка которой находится массив IO_STACK_LOCATION.

• Большинство параметров IRP находится в IO_STACK_LOCATION (включая номер основной/дополнительной функции IRP).

• Драйвер обращается к своей IO_STACK_LOCATION с помощью процедуры IoGetCurrentIrpStacLocation. Поскольку эта процедура принудительно встраивается,

необходимо распознавать ее по встроенным шаблонам. Получение IO_STACK_LOCATION в начале обработчика IRP - распространенный шаблон программирования.

Строки 15-17 читают структуру IRP и записывают 0 в поле по смещению 0x18. Рассмотрев структуру IRP, можно увидеть следующее:

Структура IO_STATUS_BLOCK хранит сведения о состоянии IRP:

Обработчик IRP обычно задает поле Status, чтобы указать, был ли IRP выполнен успешно или требует дальнейшей обработки. Information хранит специфичные для запроса сведения IRP; драйвер может использовать его для хранения указателя на буфер или задания состояния завершения. Pointer зарезервирован.

Следовательно, мы знаем, что строка 17 задает полю IRP->IoStatus.Status значение 0, а локальная переменная var_4 имеет тип NTSTATUS. Строки 18-19 обращаются к структуре IRP и записывают 0 по смещению 0x1c, то есть в поле Information структуры IoStatus. Это просто присваивание IRP->IoStatus.Information значения 0. Строки 20-22 обращаются по смещению 0x60 структуры IRP и сохраняют его адрес в локальной переменной. Структура IRP заполнена объединениями в поле Tail (начинающемся со смещения 0x40), поэтому определить, к какому полю объединения выполняется обращение, может быть непросто. Выведем некоторые из объединений:

Это показывает, что смещение 0x60 может быть либо указателем на IO_STACK_LOCATION, либо беззнаковым целым числом, обозначающим тип пакета. На основании контекста кода (обращение происходит в начале обработчика IRP) можно обоснованно предположить, что это поле CurrentStackLocation. Кроме того, мы знаем, что встроенная процедура IoGetCurrentIrpStackLocation определяется следующим образом:

Следовательно, строки 20-22 сохраняют текущую IO_STACK_LOCATION в локальной переменной. Локальная переменная _var_10 имеет тип PIO_STACK_LOCATION.

Строки 23-25 обращаются к первому байту по смещению 0 в IO_STACK_LOCATION с помощью команды MOVZX. Это указывает, что поле имеет тип unsigned char. Из раздела об IRP мы знаем, что это поле MajorFunction. Строка 5 проверяет, равен ли номер MajorFunction значению 0xe, то есть IRP_MJ_DEVICE_CONTROL.

Теперь первый блок IRP_ReadCloseIo можно декомпилировать следующим образом:

Далее проанализируем блок 0x10334, выполняемый, если основной код равен IRP_MJ_DEVICE_CONTROL:

В предыдущем абзаце мы заключили, что var_10 имеет тип PIO_STACK_LOCATION. Строки 1-2 обращаются по смещению 0xC структуры IO_STACK_LOCATION. Снова напомним, что IO_STACK_LOCATION содержит параметры запроса ввода-вывода, которые хранятся в объединениях. Как определить нужное объединение? Мы знаем, что будет использоваться поле DeviceIoControl, поскольку обрабатывается запрос IRP_MJ_DEVICE_CONTROL. Кроме того, IoControlField находится по смещению 0xC относительно базы IO_STACK_LOCATION:

Следовательно, строки 1-3 получают поле IoControlCode и сохраняют его в var_C, которая, как теперь известно, имеет тип ULONG.

Строки 4-6 обращаются по смещению 0xC в IRP и сохраняют указатель в локальной переменной var_8. Из предыдущего раздела мы знаем, что по смещению 0xC находится объединение AssociatedIrp:

Какое из трех полей следует использовать? По имеющимся сведениям определить это невозможно. Контекст, необходимый для выбора правильного поля, содержится в строках 9-12, которые получают сохраненный код IOCTL (var_C) и сравнивают его с 0x22c004. Мы знаем, что код IOCTL кодирует тип устройства, код функции, доступ и метод буферизации. Поэтому после декодирования 0x22c004 становятся известны следующие сведения:

• Тип устройства - FILE_DEVICE_UNKNOWN (0x22).

• Код IOCTL - 0x1.

• Доступ - (FILE_READ_DATA | FILE_WRITE_DATA).

• Метод буферизации - METHOD_BUFFERED.

Напомним, что мы находимся в обработчике IOCTL и при определении кода IOCTL драйверы должны указывать метод буферизации. Для буферизованного ввода-вывода поле SystemBuffer указывает на буфер невыгружаемого пула, хранящий пользовательские входные данные. Теперь можно утверждать, что строки 4-6 обращаются к полю SystemBuffer.

Строки 7-8 записывают 0x644 по смещению 0x1c внутри IRP, то есть в поле IRP->IoStatus.Information. Неясно, почему автор выбрал это значение.

Учитывая эти сведения, мы знаем, что код управления должен был быть построен следующим образом:

Поскольку мы еще не полностью проанализировали и не поняли операцию IOCTL, ей дано универсальное имя IOCTL_1. Теперь этот блок можно декомпилировать следующим образом:

Чтобы понять, что делает IOCTL, нужно проанализировать loc_10361 и функцию sub_103B0. Однако прежде закончим с соседними блоками (они проще):

В 0x1035F выполнение попадает, если код IOCTL не совпадает. Там сразу происходит переход к строке 7, которая присваивает локальной переменной состояния значение 0xC0000010, то есть STATUS_INVALID_OPERATION, а Irp->IoStatus.Information - значение 0. Затем в строке 11 проверяется, равно ли локальное состояние 0x103 (STATUS_PENDING); в действительности этот блок избыточен, поскольку переменная состояния в этой функции может иметь только два значения (STATUS_SUCCESS или STATUS_INVALID_OPERATION). Когда IRP помечен STATUS_PENDING, это означает, что операция не завершена и ожидает завершения другим драйвером. Такое часто встречается в драйверах, поэтому полезно запомнить магическую константу 0x103. Если состояние равно STATUS_PENDING, обработчик немедленно возвращает его (строки 13 и 20). В противном случае он вызывает IoCompleteRequest, чтобы пометить IRP завершенным, сохраняет состояние в IRP->IoStatus.Status (строка 19) и возвращает его. В действительности это ошибка, поскольку драйвер должен задавать поле IoStatusBlock до завершения запроса; после завершения IRP к нему больше нельзя обращаться. Эти блоки можно декомпилировать следующим образом:

Возвращаясь к процедуре IOCTL_1_handler, обратите внимание, что она вызывает только две другие функции: sub_10460 и sub_10550. sub_10550 - небольшая листовая процедура, поэтому сначала проанализируем ее:

Эта функция отменяет отображение MDL, снимает его закрепление и освобождает его. Неясно, что описывают MDL, поскольку другие процедуры еще не проанализированы. Функцию можно декомпилировать следующим образом:

sub_10460 - еще одна листовая процедура, работающая с MDL; ее основная функция - создать, закрепить и отобразить MDL для заданного буфера и длины. Ее прототип выглядит следующим образом:

По умолчанию дизассемблер не смог вывести тип первого параметра. Мы можем определить, что это PMDL *, по команде по адресу 0x1049D. Ассемблерный листинг приведен ниже без построчных комментариев, поскольку он очень прост:

Хотя эта функция кажется длинной и сложной, понять ее нетрудно, если посмотреть, как API используются вместе. IoAllocateMdl, MmProbeAndLockPages и MmMapLockedPagesSpecifyCache - процедуры для создания, закрепления и отображения MDL; MmProbeAndLockPages должна выполняться внутри блока try/except, поэтому в начале генерируется дополнительный код, настраивающий обработчик исключений (то есть строки с fs:0). По существу, эта процедура отображает буфер в пространство ядра с правом записи и возвращает адрес нового отображения этого буфера. В общих чертах всю процедуру можно декомпилировать следующим образом:

Разобравшись с этими двумя процедурами, теперь можно перейти к обработчику. Обратите внимание, что он принимает один параметр - Irp->AssociatedIrp.SystemBuffer. Напомним: после завершения IRP содержимое этого буфера может быть скопировано обратно в режим пользователя:

Сначала эта функция повышает IRQL до DISPATCH_LEVEL (строка 7), что фактически приостанавливает диспетчер потоков на текущем процессоре. Что бы ни делала эта функция, она не может ожидать или вызвать страничное исключение; иначе произойдет аварийная остановка машины. Того же эффекта можно добиться с помощью KeRaiseIrql. Строка 8 сохраняет прежний IRQL, чтобы позднее его можно было восстановить (см. строку 61). Строки 9-11 извлекают недокументированное поле записи KeServiceDescriptorTable и умножают его на 4. Строки 12-18 передают KiServiceTable, длину (в четыре раза превышающую размер таблицы системных вызовов) и указатель MDL функции MapMdl. Поскольку мы уже проанализировали MapMdl, нам известно, что она просто отображает буфер от KiServiceTable до KiServiceTable+(NumberOfSyscalls*4). В строке 12 сохраняется виртуальный адрес вновь отображенного буфера. Строки 20-22 проверяют состояние отображения; если оно оказалось неуспешным, IRQL понижается и код возвращает управление (строки 60-65); в противном случае начинается цикл, счетчик которого определяется пользовательским вводом (строки 29-31). Тело цикла занимает строки 33-50, и его можно представить следующим образом:

После многих страниц объяснений и декомпиляции всего драйвера теперь можно понять назначение образца. По какой-то причине разработчик этого драйвера хотел при помощи IOCTL перезаписать таблицу собственных системных вызовов NT произвольными адресами. Буфер режима пользователя представляет собой структуру следующего формата:

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

• Будет ли этот драйвер работать в многоядерной системе? Объясните свои рассуждения.

• Почему автор считает, что IRQL необходимо повысить до DISPATCH_LEVEL? Действительно ли это необходимо?

• Как обычный пользователь может применить этот драйвер для выполнения произвольного кода в контексте кольца 0?

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

Этот драйвер очень мал и прост, однако в нем присутствует большинство важных конструкций, обычно встречающихся в программных драйверах: диспетчерские процедуры, управление вводом-выводом устройства из режима пользователя, методы буферизации, символические ссылки, повышение и понижение уровней IRQL, управление MDL, структуры IO_STACK_LOCATION и так далее. Те же приемы анализа, которые были показаны здесь, можно применять к другим драйверам. Только не подражайте его приемам разработки в реальной жизни.

Мы считаем, что лучший способ учиться - сочетать обсуждение концепций, практические руководства и самостоятельные упражнения. Первые два элемента были рассмотрены в предыдущих разделах. Следующие самостоятельные упражнения призваны помочь вам обрести уверенность, закрепить понимание концепций ядра Windows, исследовать и расширить знания в областях, не рассмотренных в книге, а также продолжить анализ реальных драйверов. Как и в других главах, все упражнения взяты из реальных ситуаций. Файлы обозначаются как образец A, B, C и так далее. SHA1-хеш каждого образца приведен в приложении.

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

1. Объясните, почему код, выполняющийся на уровне DISPATCH_LEVEL, не может вызвать страничное исключение. Объяснений может быть несколько. Вы должны суметь привести как минимум два.

2. Предположим, вы прочитали в Интернете статью о ядре Windows, в которой утверждается, что потоки режима ядра всегда имеют более высокий приоритет, чем потоки режима пользователя; следовательно, если написать все в режиме ядра, оно будет работать быстрее. Оцените справедливость этого утверждения, используя свои знания об IRQL, диспетчеризации потоков и приоритетах потоков.

3. Напишите драйвер для Windows 7/8, который выводит базовый адрес каждого вновь загруженного образа. Повторите то же самое для процессов и потоков. Этому драйверу не нужно задавать обработчик IRP, поскольку ему не требуется обрабатывать запросы пользователей или других драйверов.

4. Объясните последствия использования METHOD_NEITHER для безопасности и то, что разработчики драйверов делают для их смягчения.

5. Имея виртуальный адрес режима ядра, вручную преобразуйте его в физический адрес. Проверьте ответ с помощью расширения !vtop отладчика ядра.

6. Разработайте драйвер, использующий все операции со списками, и найдите все встроенные процедуры работы со списками в ассемблерном виде. Есть ли для каждой процедуры общий шаблон? Если да, объясните их. Если нет, объясните почему.

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

8. Объясните, как работает макрос FIELD_OFFSET.

9. Экспортируемая функция ExGetCurrentProcessorCpuUsage не документирована, однако документированный API NDIS NdisGetCurrentProcessorCpuUsage использует ее внутри. Объясните, как ExGetCurrentProcessorCpuUsage работает в Windows x64 и x86.

10. Объясните, как KeGetCurrentIrql работает на x86 и x64.

11. Объясните, как следующие API работают в Windows 7/8 на x86/x64/ARM:

• IoThreadToProcess

• PsGetThreadProcessId

• PsIsSystemThread

• PsGetCurrentThreadId

• PsGetCurrentThreadPreviousMode

• PsGetCurrentThreadProcess

• PsGetCurrentThreadStackBase

• PsGetCurrentThreadWin32Thread

• PsGetThreadId

• PsGetThreadSessionId

• PsIsSystemProcess

• PsGetProcessImageFileName

12. Структуры PCR, PRCB, EPROCESS, KPROCESS, ETHREAD и KTHREAD хранят много полезной информации. К сожалению, все они непрозрачны и могут меняться от одной версии Windows к другой. Поэтому многие руткиты жестко задают смещения в этих структурах. Исследуйте эти структуры в Windows XP, 2003, Vista и 7 и отметьте различия. Можете ли вы разработать способы универсального получения смещений некоторых полезных полей без жесткого задания? Если да, можете ли вы сделать так, чтобы они работали на всех перечисленных платформах? (Подсказка: можно использовать дизассемблер, сопоставление шаблонов и относительное расстояние.)

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

14. Настройте режим тестовой подписи на своих 32- и 64-разрядных машинах и подпишите драйвер тестовой подписью. Убедитесь, что он работает.

15. Объясните, как работает AuxKlibGetImageExportDirectory. Затем объясните, как работают RtlImageNtHeader и RtlImageDirectoryEntryToData.

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

17. Где в процессе хранится таблица каталогов страниц (CR3 в x86 и TTBR в ARM)?

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

1. Многие современные операционные системы поддерживают функцию предотвращения выполнения данных (Data Execution Prevent, DEP). Иногда ее называют Never Execute (NX) или Execute Never (XN). Эта функция просто блокирует выполнение кода на страницах памяти, которые не помечены как исполняемые. Исследуйте, как эта функция реализована в аппаратуре (x86, x64 и ARM) и как операционная система обеспечивает ее поддержку. Затем исследуйте, как эту функцию можно было бы реализовать без какой-либо аппаратной поддержки.

2. Хотя мы рассмотрели основную идею APC, мы не объяснили, как ими пользоваться. Исследуйте (недокументированные) API, связанные с APC режима ядра, и способы их применения. Напишите драйвер, который их использует.

3. Разработайте и реализуйте как минимум два способа запуска процесса режима пользователя из драйвера режима ядра. Оцените преимущества и недостатки каждого способа.

4. Предположим, вы работаете в SMP-системе с четырьмя процессорами и хотите изменить общий глобальный ресурс. Глобальный ресурс находится в невыгружаемом пуле, и любой процессор может изменить его в любой момент. Разработайте механизм синхронизации, позволяющий безопасно изменить этот ресурс. (Подсказка: подумайте об IRQL и диспетчере потоков.)

5. Напишите драйвер, блокирующий загрузку всех будущих драйверов с именем bda.sys.

6. Исследуйте работу стека ввода Windows и реализуйте регистратор нажатий клавиш. Кейлоггер можно реализовать несколькими разными способами (с перехватом и без него). Оцените преимущества и недостатки каждого способа регистрации нажатий. Можно ли определить приложение, которое получает нажатия клавиш?

7. Реализуйте функцию, которая принимает виртуальный адрес и изменяет защиту его страницы на чтение, запись и выполнение. Повторите ту же задачу для виртуального адреса в пространстве сеанса (например, win32k.sys).

8. Мы объяснили, что DriverEntry - первая функция, вызываемая в драйвере. Объясните, какая функция в действительности вызывает эту процедуру. Как вы это выяснили?

9. Отладчик ядра Microsoft предоставляет механизм, который передает управление отладчику при загрузке драйвера. Для этого используется команда sxe ld:drivername. Соберите простой драйвер и поэкспериментируйте с этой командой. Объясните, как она работает. Перечислите все различные причины, по которым она может не сработать.

10. Отладчики режима пользователя могут легко "замораживать" потоки процесса, однако в отладчике ядра такой возможности нет. Разработайте способ замораживания и размораживания потока режима пользователя из ядра.

11. Периодические таймеры используются драйверами для регулярного выполнения определенных действий. Разработайте драйвер, который каждые 10 минут будет выводить "hello". Затем разработайте способ изменения времени срабатывания таймера после его постановки в очередь. Для этого можно использовать отладчик.

12. Реализуйте драйвер, устанавливающий собственный обработчик прерывания, и убедитесь, что его можно активировать из режима пользователя. В Windows x64 вы столкнетесь с PatchGuard, поэтому обязательно проверяйте его только в режиме отладки.

13. Привилегии процессов определяются с помощью маркеров доступа. Наивысшая привилегия - LocalSystem (процесс SYSTEM выполняется в этом контексте). Разработайте драйвер, изменяющий привилегию работающего процесса так, чтобы тот выполнялся с привилегией LocalSystem.

14. Windows Vista и более поздние версии поддерживают криптографические операции в режиме ядра через драйвер KSECDD. Хотя он не документирован в официальном WDK, его описание есть на MSDN в разделе библиотеки bcrypt режима пользователя. Разработайте драйвер, использующий AES, RSA, MD5, SHA1 и генератор случайных чисел.

15. Разработайте драйвер, перечисляющий адреса и имена всех экспортируемых символов в NTDLL, KERNEL32 и KERNELBASE. Повторите то же самое для USER32 и GDI32. Столкнулись ли вы с какими-либо трудностями? Если да, как вы их устранили?

16. Разработайте драйвер, который перехватывает экспортируемую функцию NTDLL в процессе explorer.exe. Оцените достоинства своего метода. Исследуйте и оцените другие методы.

17. Разработайте драйвер, который присоединяется к процессу SMSS.EXE и исправляет системный вызов win32k, находясь в контексте этого процесса. Объясните, с какими проблемами вы столкнулись и как их решили.

18. Предположим, кто-то утверждает, что исключения режима пользователя никогда не переходят в ядро. Исследуйте, как в Windows x86 и x64 работает обработка исключений режима пользователя, и оцените приведенное утверждение.

19. Предположим, в системе имеется вредоносный драйвер, который перехватывает INT 1 и INT 3, чтобы затруднить отладку и трассировку. Разработайте способ получить

трассу выполнения (или отладить код), даже когда эти перехваты действуют. Никаких ограничений у вас нет. Какие особые случаи необходимо обработать?

20. Команда INT 3 может быть представлена в двух формах. Наиболее распространена однобайтовая форма 0xCC. Менее распространенная двухбайтовая форма - 0xCD03. Объясните, что происходит при использовании двухбайтовой формы в Windows.

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

1. (Образец D.) Проанализируйте и объясните, что делает функция 0x10001277. Откуда берется второй аргумент и может ли он когда-либо оказаться недопустимым? Что делают функции по смещениям 0x100012B0 и 0x100012BC?

2. (Образец E.) Этот файл довольно велик и сложен; некоторые его структуры огромны (их размер близок к 4000 байт). Однако в нем есть функции, выполняющие интересные задачи, рассмотренные в этой главе, поэтому из него взято несколько упражнений. Для этого упражнения восстановите прототипы функций 0x40400D, 0x403ECC, 0x403FAD, 0x403F48, 0x404088, 0x4057B8, 0x404102 и 0x405C7C, а также объясните различия и связи между ними (если они есть); расскажите, как вы пришли к решению. Затем объясните значение выделения 30-байтового невыгружаемого пула в функциях 0x403F48, 0x403ECC и 0x403FA; заодно восстановите его тип. Кроме того, объясните, почему в некоторых из предыдущих процедур в начале выполняется освобождение пула. Эти процедуры используют недокументированные функции, поэтому вам, возможно, придется поискать прототип в Интернете.

3. (Образец E.) В DriverEntry найдите все системные рабочие потоки. По смещению 0x402C12 создается системный поток, который делает нечто обыденное интересным способом. Проанализируйте и объясните назначение функции 0x405775 и всех вызываемых ею функций. В частности, объясните механизм, используемый в функции 0x403D65. Поняв механизм, напишите драйвер, выполняющий тот же трюк (но применительно к другому запросу ввода-вывода). Завершите упражнение декомпиляцией всех четырех процедур. Это упражнение очень поучительно и принесет вам большую пользу.

4. (Образец E.) Функция 0x402CEC принимает в качестве одного из параметров объект устройства, связанный с \Device\Disk\DR0, и отправляет ему запрос с помощью IoBuildDeviceIoControlRequest. Этот объект устройства описывает первый раздел вашего загрузочного диска. Декодируйте используемый IOCTL и найдите его содержательное имя. (Подсказка: выполните поиск по всем файлам, входящим в WDK, включая файлы режима пользователя.) Определите структуру, связанную с этим запросом.

Затем приведите вывод IDA в порядок, назначив каждой локальной переменной тип и содержательное имя. Наконец, декомпилируйте процедуру обратно в C и объясните, что она делает (возможно, даже напишите другой драйвер, использующий этот метод).

5. (Образец E.) Декомпилируйте функцию 0x401031 и дайте ей содержательное имя. Если вы не знакомы с работой SCSI, рекомендуется прочитать SCSI Commands Reference Manual ("Справочное руководство по командам SCSI").

6. (Образец F.) Объясните, что делает функция 0x100051D2 и почему. Чем так примечательно смещение 0x38 в структуре расширения устройства? Восстановите как можно больше типов и декомпилируйте эту процедуру. Наконец, найдите все таймеры, DPC и рабочие элементы, используемые драйвером.

Пакет Debugging Tools for Windows представляет собой набор отладочных утилит, который можно бесплатно загрузить с веб-сайта Microsoft. В комплект входят четыре отладчика, основанные на одном и том же движке отладки (DbgEng).

DbgEng - это COM-объект, позволяющий другим программам использовать расширенные API отладки, а не только обычные Windows Debugging APIs. Более того, пакет Debugging Tools включает SDK, показывающий, как создавать расширения для DbgEng или размещать его в собственных программах.

Пакет Debugging Tools for Windows включает следующие отладчики:

• NTSD/CDB - Microsoft NT Symbolic Debugger (NTSD) и Microsoft Console Debugger (CDB) идентичны за исключением того, что первый при запуске создает новое окно консоли, а второй наследует окно консоли, из которого был запущен.

• WinDbg - графический интерфейс к DbgEng. Он поддерживает отладку на уровне исходного кода и сохранение рабочих пространств.

• KD - Kernel Debugger (KD) используется для отладки ядра.

У отладчиков есть богатый набор параметров командной строки. Один из особенно полезных параметров - -z, применяемый для анализа аварийных дампов (*.dmp) и CAB-файлов (*.cab), содержащих файл аварийного дампа. Еще одно применение параметра -z - анализ PE-файлов (исполняемых файлов или DLL), при котором DbgEng отображает их так, словно они находятся в аварийном дампе.

В следующем примере отладчик CDB запускается с параметром -z, чтобы отобразить calc.exe в отладчике:

Обратите внимание на две вещи:

• Calc.exe был отображен в отладчике, а EIP указывает на его точку входа (в отличие от живых целевых процессов, где он указывает внутрь ntdll.dll).

• Многие команды отладчика будут недоступны, особенно команды управления процессом (поскольку программа отображена для анализа/исследования, а не для динамической трассировки/отладки).

Используя параметр -z, можно писать мощные сценарии для анализа программ и извлечения информации.

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

Перед запуском любого из отладчиков (WinDbg, CDB, NTSD или KD) настроим переменную среды _NT_SYMBOL_PATH:

Ее также можно настроить из самого отладчика при помощи команды .sympath:

В WinDbg доступны следующие окна (в соответствующих случаях указаны сочетания клавиш):

• Окно команд/вывода (Alt+1) - в этом окне можно вводить команды и просматривать результаты операций. Хотя выполнять отладку можно с помощью других окон и пунктов меню, окно команд позволяет использовать всю мощь встроенных команд DbgEng и доступных расширений.

• Окно регистров (Alt+4) - отображает настроенные регистры. Это представление можно настроить, указав, какие регистры показывать или скрывать.

• Память (Alt+5) - окно дампа памяти. В нем можно просматривать содержимое памяти, прокручивать, копировать и даже редактировать его.

• Вызовы (Alt+6) - отображает сведения о стеке вызовов.

• Дизассемблирование (Alt+7) - окно команд показывает дизассемблерный листинг текущей команды, тогда как окно дизассемблирования отображает целую страницу дизассемблированного кода. В этом окне также можно выполнять действия с помощью сочетаний клавиш:

• добавлять или удалять точки останова на выбранной строке (F9);

• управлять процессом (пошаговое выполнение - F11, продолжение - F5 и т. д.);

• перемещаться по коду (Page Up/Page Down для исследования дизассемблированного кода).

Отладчик понимает два синтаксиса вычисления выражений: Microsoft Macro Assembler (MASM) и C++.

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

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

или:

Для вычисления выражений (в синтаксисе по умолчанию) используется команда ?.

Команда ?? служит для вычисления выражения C++ (независимо от выбранного синтаксиса по умолчанию).

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

При использовании синтаксиса MASM число можно записать в выбранной системе счисления при помощи следующих префиксов:

• 0n123 - десятичное число;

• 0x123 - шестнадцатеричное число;

• 0t123 - восьмеричное число;

• 0y10101 - двоичное число.

В отличие от вычисления в синтаксисе MASM, при использовании ?? для вычисления команд переопределить основание нельзя:

Как и в языке C++, синтаксис вычислителя C++ допускает только префикс 0x для шестнадцатеричных чисел и префикс 0 для восьмеричных. Если префикс не задан, используется основание 10.

Для сочетания выражений разных типов применяются формы @@c++(expression) и @@masm(expression):

Префикс @@ - сокращенная форма, которой можно обозначить альтернативный синтаксис вычисления выражений (не тот, который установлен в данный момент):

Указывать @@c++(...) необязательно: когда по умолчанию выбран MASM, форма @@(...) использует синтаксис C++, и наоборот.

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

Используется обозначение "оператор (синтаксис выражения)", где синтаксисом выражения будет либо C++, либо MASM. Обратите внимание: в следующих примерах по умолчанию установлен вычислитель выражений MASM.

• Pointer->Field (C++) - как и в предыдущем примере, оператор-стрелка используется для доступа к значению поля, на которое указывает $peb, и смещению поля ImageSubsystemMajorVersion.

• sizeof(type) (C++) - этот оператор возвращает размер структуры. Он может пригодиться при разборе структур данных или создании мощных условных точек останова:

• #FIELD_OFFSET(Type, Field) (C++) - этот макрос возвращает байтовое смещение поля в типе:

• Тернарный оператор (C++) - он ведет себя так же, как в языке C++:

• (type) Value (C++) - приведение типов позволяет преобразовывать один тип в другой:

Обратите внимание: перед прибавлением смещения BeingDebugged значение @$peb приводится к (char*).

• *(pointer) (C++) - оператор разыменования:

Обратите внимание: перед разыменованием указателю нужно назначить правильный тип (путем приведения).

• poi(address) (MASM) - разыменование указателя:

• hi|low(number) (MASM) - возвращает старшее или младшее 16-разрядное значение числа:

• by/wo/dwo(address) (MASM) - возвращает значение типа byte/word/dword при разыменовании адреса:

• pointer[index] (C++) - оператор индексирования массива позволяет разыменовывать память с использованием индексов:

Того же результата можно добиться с помощью синтаксиса MASM и poi() или by():

• $scmp("string1", "string2")/$sicmp("String1", "String2") (MASM) - сравнение строк (с учетом/без учета регистра). Возвращает -1, 0 или 1, как функции C strcmp()/stricmp():

• $iment(address) (MASM) - возвращает точку входа образа, находящегося по этому адресу. Для этого разбирается и используется заголовок PE:

• $vvalid(address, length) (MASM) - проверяет доступность памяти от указанного адреса до address + length (возвращает 1, если она доступна, и 0, если недоступна):

• $spat("string", "pattern") (MASM) - использует сопоставление с шаблоном, чтобы определить, присутствует ли шаблон в строке, и возвращает истину или ложь.

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

Ниже перечислены некоторые команды, позволяющие управлять ходом выполнения в отладчике:

• t (F11) - шаг с заходом.

• gu (Shift+F11) - переход вверх. Выходит из текущей функции и возвращается к вызывающей.

• p (F10) - шаг с обходом.

• g (F5) - продолжить. Возобновляет выполнение программы.

• Ctrl+Break - когда отлаживаемая программа выполняется, это сочетание клавиш приостанавливает ее.

Обратите внимание: приведенные команды работают только с живыми целями.

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

• [t|p]a Address - шаг с заходом. Выполняет шаги с обходом, пока не будет достигнут указанный адрес.

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

• g[h|n] - применяется для возобновления выполнения с пометкой исключения как обработанного или необработанного.

Еще один набор команд трассировки/пошагового выполнения полезен для обнаружения базовых блоков:

• [p|t]c - выполнять шаги с обходом/заходом до встречи команды CALL.

• [p|t]h - выполнять шаги с обходом/заходом до встречи команды ветвления (любого перехода, возврата или вызова).

• [p|t]t - выполнять шаги с обходом/заходом до встречи команды RET.

• [p|t]ct - выполнять шаги с обходом/заходом до встречи команды CALL или RET.

Большинство приведенных команд (трассировки и шагов с обходом) неявно работает в контексте текущего потока.

Чтобы вывести все потоки, используйте команду ~:

Первый столбец - номер потока (назначенный DbgEng), за которым следует пара SystemProcessId.SystemThreadId в шестнадцатеричном формате.

Команды DbgEng работают с идентификаторами DbgEng, а не с идентификаторами процессов/потоков операционной системы.

Чтобы переключиться на другой поток, используйте команду ~Ns, где N - номер потока, на который требуется переключиться:

В приглашении отладчика также отображается выбранный идентификатор потока в форме ProcessID:ThreadId>.

Перед выполнением команды переключаться на поток необязательно. Например, чтобы вывести регистры потока с идентификатором 3, используйте префикс ~3, за которым следует нужная команда отладчика (в данном случае команда r):

Чтобы вывести значения регистров всех потоков, просто передайте * в качестве номера потока.

Если вы отлаживаете несколько процессов режима пользователя (то есть отладчик запущен с параметром -o), переключаться между процессами можно командой |. В следующем примере используется Internet Explorer, поскольку обычно он порождает несколько дочерних процессов (с разными уровнями целостности и для разных целей):

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

Чтобы переключиться с одного процесса на другой, введите |Ns, где N - номер процесса:

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

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

DbgEng может приостановить целевой процесс и дать пользователю возможность решить, какое действие предпринять, в следующих двух случаях:

• Исключения - эти события возникают, когда в контексте приложения срабатывает исключение (нарушение доступа, деление на ноль, исключение одиночного шага и т. д.).

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

Чтобы вывести все события, используйте команду sx. Если вы работаете в WinDbg, можно также перейти в меню Debug/Event Filters и настроить события графически, как показано на рисунке 4-1.

Рисунок 4-1. Окно Event Filters и вывод команды sx

На снимке экрана показаны два набора параметров для управления событиями:

• Execution - определяет, что делать при возникновении события.

• Continue - определяет способ продолжения после события или исключения.

• Handled - помечает исключение как обработанное (обработчик исключений приложения не сработает). Это полезно, когда отладчик останавливается, вы вручную исправляете ситуацию, а затем возобновляете приложение командой gh.

• Not Handled - позволяет обработчику исключений приложения обработать исключение. Для продолжения используйте команду gn.

Для управления обработкой событий/исключений используются следующие команды:

• sxe event - включает остановку при событии;

• sxd event - отключает остановку при событии;

• sxr event - включает только вывод события;

• sxi event - игнорирует событие (ничего не выводит).

Параметром event может быть числовой код исключения, сокращенное имя события или *, означающая любое событие.

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

Чтобы связать с событием команду, используйте команду sx- -c command event. Например, чтобы выводить стек вызовов при каждой загрузке модуля, используйте:

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

Команда r применяется для вывода или изменения значений регистров.

Общий синтаксис команды r выглядит следующим образом:

Вот простейший синтаксис команды r:

Если выражение или значение опущено, r выводит текущее значение регистра:

Чтобы вывести регистры, задействованные в текущей команде, используйте r.:

К команде r можно добавить суффикс M, за которым следует 32-разрядное значение маски. Маска определяет, какие регистры выводятся, когда r вводится без параметров. В таблице 4-1 приведен краткий перечень значений маски.

Таблица 4-1. Значения маски регистров

Чтобы увидеть текущую маску, введите rm:

Теперь при выполнении r должны выводиться только регистры общего назначения и сегментные регистры:

Чтобы вывести все возможные регистры, задайте единицами все биты параметра маски (маска 0x1ff):

Чтобы задать маску по умолчанию, используйте команду rm, после которой укажите нужное значение маски:

DbgEng предоставляет сокращенные флаги для некоторых масок, а именно для регистров с плавающей запятой и MMX.

Чтобы вывести регистры с плавающей запятой, используйте rF, а для вывода регистров XMM - rX:

Команда вывода селектора имеет следующий синтаксис:

Она выводит сведения о заданном селекторе (или диапазоне селекторов). В данном случае нас интересуют значения селекторов, установленные в одном из регистров x86/x64, а именно в регистрах cs, ds, ss, gs и fs.

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

В следующем примере команда dg выполняется соответственно для cs, ds, ss, gs и fs:

В приложениях MS Windows режима пользователя селекторы cs, ds, es, ss и gs имеют нулевое базовое значение, поэтому линейный адрес совпадает с виртуальным.

Напротив, регистр fs изменчив: его значение меняется от потока к потоку. Сегмент fs в процессах режима пользователя указывает на структуру TEB (Thread Environment Block):

Следующие команды позволяют исследовать символы и структурированные данные:

• dt [type] [address] - очень удобная команда для вывода типа элемента по заданному адресу:

• dv [flags] [pattern] - выводит сведения о локальных переменных.

• x [options] [module_pattern]![symbol_pattern] - выводит символ или символы в заданном модуле либо модулях.

• !dh [options] Address - выводит заголовки образа PE.

• !drvobj DriverObjectPtr [Flags] - выводит сведения об объекте DRIVER_OBJECT.

• !heap - выводит сведения о куче.

• !pool - выводит сведения о пуле ядра.

DbgEng позволяет исследовать работающие процессы, загруженные/выгруженные модули и загруженные драйверы режима ядра.

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

Аналогично, при отладке в режиме ядра команда lm выводит список загруженных драйверов устройств:

Чтобы просмотреть сведения о модуле (версию, размер, базовый адрес и т. д.), используйте параметр v для подробного режима и m, чтобы задать имя модуля для сопоставления:

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

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

Затем для переключения в контекст нужного процесса используйте команду .process /r /p EPROCESS:

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

В следующем примере для данного EPROCESS устанавливается точка останова на kernel32!CreateFileW:

В метке 1 командой bp /p EPROCESS устанавливается фильтр EPROCESS, чтобы точка останова срабатывала только для процесса explore.exe. Метка 2 выводит список точек останова. Обратите внимание: совпадение произойдет только для определенного EPROCESS. На метке 3 мы возобновляем выполнение и ожидаем срабатывания точки останова. На метке 4 выводится имя файла, к которому был выполнен доступ. Метка 4 станет гораздо понятнее после того, как далее в этой главе вы прочитаете раздел "Язык".

Теперь предположим, что вы хотите вывести все процессы, вызвавшие API CreateFileW, и имена файлов, к которым они обращались:

Точка будет срабатывать всякий раз, когда любой процесс режима пользователя достигнет ее, после чего связанная с точкой останова команда вызовет !process с текущим EPROCESS (заданным в предопределенном псевдорегистре $proc), выведет сведения о контексте текущего процесса и имя файла, а затем возобновит выполнение командой gc.

После возобновления выполнения вы увидите следующий сокращенный вывод:

В этом разделе показаны важные возможности написания сценариев в DbgEng, полезные для автоматизации задач обратной разработки и отладки.

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

SDK находится в подкаталоге sdk каталога установки средств отладки. Он имеет следующую структуру каталогов:

• Help - содержит справочные материалы по библиотеке DbgHelp.

• Inc - содержит включаемые файлы, необходимые при использовании SDK.

• Lib - содержит соответствующие библиотечные файлы, используемые на этапе компоновки сборки. В нем имеются библиотеки для WOA (Windows on ARM), AMD64 и i386.

• Samples - содержит примеры, написанные с использованием различных каркасов, которые можно применять для создания расширений отладчика. Есть также примеры использования DbgEng вместо написания для него расширения.

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

Для начала следует знать, что SDK предоставляет три каркаса, с помощью которых можно создавать расширения:

• Каркас расширений WdbgExts - первоначальные расширения WinDbg. Для взаимодействия с DbgEng им необходимо экспортировать несколько обратных вызовов, чтобы работать с API расширений WinDbg, а не с интерфейсом клиента отладчика. Позднее программист может по требованию получить интерфейс клиента отладчика или другие интерфейсы, если нужна дополнительная функциональность.

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

• Расширения EngExtCpp - построенные поверх каркаса расширений DbgEng, эти расширения создаются путем наследования от базового класса ExtExtension. Класс ExtExtension предоставляет множество вспомогательных функций, позволяющих расширению выполнять сложные задачи.

В следующих разделах кратко показано создание расширений с помощью каркаса расширений WdbgExts. Обратите внимание: создание расширений с использованием любого из двух других каркасов довольно прямолинейно и может быть освоено по примерам SDK, поставляемым с пакетом Debugging Tools.

В предыдущем разделе вы познакомились с концепциями SDK; теперь можно подробнее рассмотреть, как выглядит расширение WdbgExts и как написать самое простое расширение.

Расширение отладчика - это обычная DLL Microsoft Windows. DLL должна экспортировать две обязательные функции, необходимые DbgEng, а затем столько функций, сколько команд расширение предоставляет отладчику.

Первая экспортируемая функция - WinDbgExtensionDllInit. Она вызывается, когда отладчик загружает расширение:

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

Вторая экспортируемая функция - ExtensionApiVersion. DbgEng вызывает ее, когда хочет запросить сведения о версии расширения:

После определения обязательных функций (или обратных вызовов) можно переходить к объявлению команд расширения.

Команда расширения имеет следующее объявление:

Наиболее примечательны следующие передаваемые аргументы:

• dwProcessor - индекс текущего процессора.

• dwCurrentPc - текущий указатель команд.

• args - переданные аргументы (если есть).

Еще один предпочтительный способ объявить функцию расширения - использовать макрос DECLARE_API(api_s):

Последний шаг - экспортировать две обязательные функции и команды расширения, которые вы собираетесь предоставить DbgEng. Обычный способ - создать файл .def и вызвать компоновщик с дополнительным параметром /DEF:filename.def. Вот как выглядит DEF-файл написанного нами тестового расширения:

Поместите полученную DLL в каталог средств отладки (либо в его подкаталог winext) или в системный каталог Windows. Команда !load extname загружает скомпилированное расширение, а !extension_command или !extname.ext_command выполняет команду расширения.

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

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

Это явление легко показать на конкретном примере. Одна из целей оптимизатора компилятора - уменьшить объем вычислительных ресурсов, затрачиваемых на выполнение задачи, и 50 лет исследований наделили оптимизаторы впечатляющими возможностями в этом направлении, поэтому в переводе исходного кода на язык ассемблера редко встречается очевидная неэффективность. Например, если исходный код предписывает увеличить некоторую переменную на пять (например, оператором x += 5;), компилятор, скорее всего, сгенерирует ассемблерный код, похожий на один из следующих вариантов:

В обфусцированном коде вместо этого можно встретить следующий код, если предположить, что EAX соответствует переменной x, а значение EBX можно свободно перезаписать (или "затереть"):

В этом примере можно увидеть множество действующих методов обфускации:

• В строках 1-3 для обмена содержимым двух мест - в данном случае регистров EAX и EBX - используется "трюк обмена XOR".

• Строка 4 показывает присваивание регистру EAX, которое в действительности является "мусором" (поскольку в строке 8 EAX перезаписывается константой).

• В строках 5-6 регистр EBX меняет знак, после чего к нему прибавляется константа 0A6098326h: EBX = -EAX + 0A6098326h.

• В строке 7 EAX сравнивается с ESP. Команда CMP изменяет только флаги, а на последующих строках флаги перезаписываются до следующего использования, поэтому этот код является мусором.

• В строках 8-9 константа 59F67CD5h помещается в регистр EAX и подвергается операции XOR с -1h (которое в двоичном виде состоит из одних единичных битов). XOR со всеми единицами эквивалентен операции NOT; следовательно, результат этой последовательности - помещение константы 0A609832Ah в EAX.

• Строка 10 вычитает константу в EAX из EBX: EBX = -EAX + 0A6098326h - 0A609832Ah, или EBX = -EAX - 5, или EBX = -(EAX + 5).

• Строка 11 изменяет EAX с помощью команды RCL. Эта команда является мусором, поскольку EAX перезаписывается в строке 18.

• Строки 12-13 помещают в стек константу 0F9CBE47Ah, а затем прибавляют к ней константу 6341B86h, в результате чего в вершине стека оказывается значение 0h.

• Строка 14 изменяет EAX с помощью команды SBB, задействуя посторонний регистр EBP. Эта команда является мусором, поскольку EAX перезаписывается в строке 18.

• Строка 15 вычитает EBX из значения, находящегося в данный момент на вершине стека (то есть 0h). Следовательно, dword ptr [ESP] = 0 - -(EAX + 5), или dword ptr [ESP] = EAX + 5.

• Строки 16-19 демонстрируют операции со стеком: в него помещаются девять двойных слов, одно извлекается в EAX, после чего указатель стека корректируется так, чтобы указывать на то же место, что и до выполнения последовательности.

• Строка 20 проверяет EBX относительно регистра EAX и соответствующим образом задает флаги. Если флаги переопределяются до следующего использования, эта команда является мертвой.

• Строка 21 извлекает значение с вершины стека (где хранится EAX + 5) в регистр EAX.

Итак, код вычисляет EAX = EAX + 5.

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

• обфускация на основе шаблонов;

• развертывание констант;

• вставка мусорного кода;

• обфускация на основе стека;

• использование необычных команд, таких как RCL, SBB, PUSHF и PUSHAD.

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

• локальная оптимизация;

• свертывание констант;

• удаление мертвых операторов;

• оптимизация стека.

Рассмотрим следующую последовательность команд:

Предположим, вы хотите построить "правильный", классический граф потока управления для программы, содержащей подобные последовательности. Чтобы определить, какая команда будет следующей после выполнения строки 2, - или, возможно, множество потенциальных последующих команд, - нужно определить множество возможных значений регистра EAX в этой точке. Иными словами, поток управления этого фрагмента зависит от потока данных, относящегося к местоположению [EBP-10h] в точке программы l1 (строка 1). Однако для определения потока данных относительно [EBP-10h] требуется определить поток управления относительно местоположения строки 1: нужно знать все возможные команды передачи управления (и связанный поток данных, ведущий к этим местоположениям), которые способны быть нацелены на местоположение строки 1. Невозможно содержательно говорить о потоке управления, не говоря одновременно о потоке данных, и наоборот.

Ситуация еще сложнее, чем может показаться на первый взгляд. Анализ программы пытается отвечать на вопросы вроде: "Какие значения местоположение [EBP-10h] может принимать при любых возможных обстоятельствах?" Для борьбы с вычислительной неразрешимостью и проблемами разрешимости многие формы анализа программ используют приближения пространства состояний. Некоторые приближения являются точными (например, приближение множества {1,3} множеством {1,2,3}), а некоторые - грубыми (например, приближение того же множества множеством {0,1,...,2^32 - 1}). (В этом абзаце "точные" и "грубые" не являются техническими терминами.) Если невозможно точно приблизить множество потенциальных значений местоположения [EBP-10h] (например, если приходится предположить, что местоположение может принимать любое возможное значение), то неизвестно, куда будет указывать переход, поэтому приходится считать, что он может быть нацелен на любое место в адресном пространстве. Тогда факты о потоке данных из местоположения строки 2 необходимо распространить на каждое другое местоположение. В практических условиях такое решение серьезно повлияет на анализ и, скорее всего, заставит его консервативно заключить, что во всех местоположениях возможны все состояния; это верно, но бесполезно.

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

Академические работы в этой области, например Киндера^[30] и Такура с соавторами^[41], стремятся построить системы, способные возвращать правильные ответы для всех возможных входных данных. Такие системы предпочитают сообщить пользователям, что не могут определить точные сведения, вернуть правильные, но крайне неточные результаты или погибнуть в попытке (например, исчерпав всю доступную память или не завершившись из-за проблем вычислимости), но не выдавать ответ, который не полностью обоснован. Эта цель похвальна, учитывая исходную мотивацию этих дисциплин: обеспечить абсолютную правильность программ и анализов. Однако она не соответствует нашей мотивации как исследователей обфускации.

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

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

Свертывание констант - одна из самых ранних и основных оптимизаций компилятора. Цель этой оптимизации - заменить вычисления, результаты которых известны во время компиляции, этими результатами. Например, в операторе C x = 4 * 5; выражение 4 * 5 состоит из бинарного арифметического оператора (*), которому передаются два операнда со статически известными значениями (соответственно 4 и 5). Компилятору было бы расточительно генерировать код, вычисляющий этот результат во время выполнения, поскольку он может вывести результат во время компиляции. Компилятор может просто заменить присваивание на x = 20;.

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

Если не учитывать изменения флагов этой последовательностью, было установлено, что она эквивалентна push 0h.

Принципиальный недостаток этого метода в том, что константы необходимо динамически декодировать (тем самым раскрывая как их самих, так и функцию декодирования) во время выполнения до обработки. Имеется функция кодирования f(x) = x - 6341B86h, результат которой f(x) помещается в стек, после чего применяется декодирующая функция: f^-1(x) = x + 6341B86h.

Эта конструкция тривиальна; деобфускация выполняется простым применением стандартной оптимизации компилятора - свертывания констант.

Предпринимались попытки укрепить такие операторы и предложить более устойчивые схемы кодирования. Некоторые методы, например полиномиальное кодирование и кодирование вычетами, описаны в патенте US6594761 B1 Чоу, Джонсона и Гу^[11]. Также часто используются аффинные отображения.

Что, если удастся найти такое кодирование, при котором для манипуляций с переменными их необязательно декодировать (эквивалентную операцию можно определить над закодированными переменными)? Это свойство, называемое гомоморфизмом, обсуждалось с точки зрения обфускации, равно как и усовершенствование метода кодирования вычетами, в таких работах, как труды Чжу и Томборсона^[44].

В абстрактной алгебре гомоморфизм - это сохраняющее операции отображение между двумя алгебраическими структурами. Рассмотрим, например, две группы G и H, снабженные соответственно операциями +g и +h. Мы хотим построить отображение f между множествами, лежащими в основе G и H, и хотим, чтобы наше отображение учитывало операции +g и +h. В частности, должно выполняться f(x +g y) = f(x) +h f(y).

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

Полностью гомоморфные отображения имеют естественное применение в обфускации.

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

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

Еще одна распространенная оптимизация компилятора называется удалением мертвого кода и отвечает за удаление операторов программы, не влияющих на ее работу. Например, рассмотрим следующую функцию C:

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

Обфускаторы выполняют обратную операцию, вставляя мертвый код, чтобы затруднить чтение кода: специалисту по обратной разработке приходится вручную решать, участвует ли данная команда в вычислении какого-либо значимого результата. Возможность вставлять "мертвый" код требует от обфускатора знать, какие регистры являются "живыми" в каждой точке программы; например, если EAX содержит важное значение (он живой), а EBX - нет (он мертвый), можно вставить операторы, изменяющие EBX.

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

Можно сформулировать математические утверждения, связывающие результаты одних операторов с результатами сочетаний других операторов. Один пример этого общего явления уже встречался в мотивирующем примере: команда XOR EAX, 0FFFFFFFFh (двоичное представление 0FFFFFFFFh состоит из одних единичных битов). Поскольку 0 XOR 1 = 1, а 1 XOR 1 = 0, эта команда в действительности инвертирует каждый бит EAX; иными словами, она синонимична оператору NOT. Аналогично можно сформулировать следующие утверждения:

• -x = ~x + 1 (по определению дополнительного кода);

• rotate left(x,y) = (x << y) | (x >> (bits(x)-y));

• rotate right(x,y) = (x >> y) | (x << (bits(x)-y));

• x-1 = ~-x;

• x+1 = -x.

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

в следующую последовательность (назовем ее #1):

Или он может преобразовать ту же последовательность в следующую (#2):

Либо в эту (#3):

Шаблоны могут быть сколь угодно сложными. Более сложный пример может заменить шаблон

следующим шаблоном (#4):

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

Представим, что он преобразуется с помощью замены #3:

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

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

Обратите внимание на несколько особенностей этих замен. #1 и #2 сохраняют семантическую эквивалентность: после выполнения этих последовательностей процессор будет находиться в том же состоянии, в котором он оказался бы после выполнения исходной команды. #3 не сохраняет семантическую эквивалентность, поскольку использует команду sub, изменяющую флаги, тогда как исходная push их не изменяет. Что касается последовательности #4, исходная команда изменяет флаги, а замена - нет; кроме того, исходная команда вообще не изменяет память, тогда как замена записывает значение ESP на вершину стека (поэтому ее также можно считать эквивалентной команде PUSH ESP).

Эти соображения показывают трудность обфускации ассемблерного кода после компиляции. Защита может безопасно выполнить замену #3 лишь в том случае, если известно, что измененные командой флаги не используются до следующего изменения этих флагов. Замена #4 аналогично безопасна, если флаги мертвы и результирующий код безразличен к содержимому [ESP] после исходной операции SUB ESP, 4. Обеспечение живости флагов требует построения графа потока управления функции, что может быть трудно из-за косвенных ветвлений. Убедиться в безопасности изменения памяти стека было бы чрезвычайно трудно из-за наложения памяти. Эти конкретные опасения вряд ли повлияют на обычные функции, сгенерированные компилятором, для которых можно построить графы потока управления, но мы надеемся, что они показывают риски применения к скомпилированному коду преобразований, не являющихся семантически эквивалентными.

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

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

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

При обратной разработке кода, сгенерированного компилятором, специалисты могут полагаться на предсказуемость того, как компилятор переводит конструкции потока управления. Благодаря этому они быстро определяют структуру потока управления исходного кода на уровне абстракции выше языка ассемблера. В процессе специалист по обратной разработке опирается на множество предположений о том, как компиляторы генерируют код. В чисто скомпилированной программе весь код базового блока чаще всего расположен последовательно (интенсивные оптимизации компилятора могут сделать эту основную предпосылку недействительной). Связанные во времени блоки обычно также расположены рядом. Команда CALL всегда соответствует вызову некоторой функции. Команда RET тоже почти всегда означает конец некоторой функции и возврат к вызывающему коду. Косвенные переходы, например реализующие операторы switch, встречаются редко и следуют стандартным схемам.

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

• Команда CALL используется только для вызова функций, а функция начинается по адресу, на который нацелен вызов.

• Большинство вызовов возвращает управление, и, если они это делают, возврат происходит в местоположение непосредственно после команды CALL; операторы ret и RETN обозначают границы функций.

• Встретив условный переход, дизассемблеры предполагают, что он помещен в код "добросовестно", в частности:

• обе ветви перехода могут быть практически выбраны;

• по обеим ветвям перехода расположен код, а не данные.

• Они смогут легко определить цели косвенных переходов.

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

• Все передачи управления нацелены на местоположения кода, а не данных.

• Исключения будут использоваться предсказуемыми способами.

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

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

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

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

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

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

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

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

Этот пример показывает отсутствие последовательной локальности команд внутри базового блока, но не временной локальности нескольких базовых блоков. На практике большие объемы кода программы будут переплетены таким образом (обычно в каждом базовом блоке более одной команды, в отличие от предыдущего примера).

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

Для большинства процессоров двумя важнейшими примитивами перемещения являются ветвление наподобие JMP и сохранение указателя команд с ветвлением наподобие CALL. Эти примитивы можно обфусцировать с помощью динамически вычисляемых адресов ветвления или их эмуляции. Один из самых простых методов - пара PUSH-RET, используемая как команда JMP:

Она (почти) семантически эквивалентна следующему:

Команда CALL является легкой целью для обфускаторов, поскольку большинство дизассемблеров предполагает следующее о ее высокоуровневой семантике:

• целевой адрес является точкой входа подфункции;

• вызов возвращает управление (то есть выполняется команда после CALL).

На самом деле эти предположения легко нарушить. Рассмотрим следующий пример:

CALL используется как JMP; управление никогда не вернется к строке 2. Стек исправляется (адрес возврата удаляется из стека) в строке 3. Теперь рассмотрим следующие два элемента:

и:

Команда CALL в строке 2 basic_block_b указывает на basic_block_a, который в действительности является лишь заглушкой, обновляющей (см. строку 2 basic_block_a) адрес возврата, сохраненный на вершине стека, прежде чем команда RET использует его (строка 3 basic_block_a). В этих двух примерах результатом является промежуток между естественным (ожидаемым) и фактическим адресами возврата CALL; обфускатор может (и будет) использовать его для вставки кода, который мешает дизассемблерам и создает путаницу.

Следующий пример является интересным развитием стандартной пары PUSH-RET, ранее использованной как JMP:

Основой этой конструкции в действительности является PUSH-RET. Строка 7 записывает целевой адрес в стек; он используется командой RET в строке 10. Помещаемый в стек адрес берется из EBX (строка 7), который условно обновляется командой CMOVZX в строке 6. Если условие выполняется (проверяется флаг Z), команда действует как стандартная MOV (EBX перезаписывается значением EDX, содержащим целевой адрес ветвления); в противном случае она действует как NOP (поэтому EBX содержит стандартный адрес ветвления). В итоге ясно видно, что этот шаблон представляет условный переход (JZ).

Программа может использовать примитивы операционной системы (хотя это может означать потерю переносимости). В Windows для обфускации потока управления часто применяются Structured Exception Handler (SEH), Vectored Exception Handler (VEH) и Unhandled Exception Handler, а в Unix - обработчики сигналов и функции setjmp/longjmp.

Основной алгоритм можно разложить на следующие этапы:

1. Обфусцированный код вызывает исключение (используя недопустимый указатель, недопустимую операцию, недопустимую команду и т. д.).

2. Операционная система вызывает зарегистрированный обработчик (или обработчики) исключения.

3. Обработчик исключения распределяет поток команд согласно своей внутренней логике и возвращает программу в чистое состояние.

Следующий пример миллиарды раз встречался в двоичных файлах x86:

Строки 1-3 настраивают SEH. Затем в виде нарушения доступа вызывается исключение: строка 5 пытается выполнить запись по адресу 0x0. Если программа не отлаживается, операционная система передаст выполнение обработчику SEH. Обратите также внимание: при вызове обработчика SEH он получает в качестве одного из аргументов копию контекста потока, а значение регистра указателя команд можно изменить, чтобы еще сильнее обфусцировать перенаправление потока управления.

Что еще интереснее, эту концепцию можно обратить. Что, если защита вставляет исключения в исходную программу и перехватывает их собственным подключенным отладчиком? Защищенная программа состоит из отлаживаемой программы и отладчика. Известный пример - возможность namomites в Armadillo. Namomites фактически заменяют (условные) переходы командой INT 3. Исключение перехватывается отладчиком защиты, который соответствующим образом обновляет контекст отлаживаемой программы для эмуляции (условных) переходов. Нельзя просто отсоединить отладчик от отлаживаемой программы: в противном случае исключения не будут обработаны и программа аварийно завершится. Реализация этой концепции была предложена Дероко^[19].

Непрозрачный предикат (введенный Коллбергом в работах "A Taxonomy of Obfuscating Transformations"^[12] и "Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs"^[13]) - это специальная условная конструкция (логическое выражение), которая всегда вычисляется либо в истину, либо в ложь (обозначаются соответственно PT и PF). Его значение известно только во время компиляции/обфускации и должно быть неизвестно атакующему, а его доказательство должно быть вычислительно трудным, чтобы обеспечить достаточную степень устойчивости.

В сочетании с командой условного перехода он вводит дополнительную ложную ветвь, то есть дополнительное ребро в графе потока управления (control-flow graph, CFG). Эту мертвую ветвь можно использовать для вставки мусорного кода или специальных свойств, например циклов в CFG, чтобы усложнить анализ. Однако ложная ветвь должна выглядеть достаточно правдоподобно, чтобы избежать простого обнаружения человеком-атакующим (например, только одна из двух ветвей содержит необходимые инициализации переменных).

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

Проектирование устойчивых непрозрачных предикатов - трудная задача. Это лишние фрагменты кода, смешанные с существующим кодом, имеющим собственную логику/стиль; без особой осторожности их легко обнаружить. Хорошая практика - создавать зависимости между предикатом и состоянием/переменными программы. Человек-атакующий (вы) обычно весьма эффективно обнаруживает сомнительные шаблоны. Абсурдно сложный предикат может эффективно помешать инструменту статического анализа, но, скорее всего, будет легко обнаружен человеком-атакующим.

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

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

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

Самый тривиальный пример вставки мусорного кода может выглядеть так:

Вот нечто чуть более сложное, использующее фиктивный непрозрачный предикат:

Условный переход в строке (адресе) 3 всегда истинен, поскольку регистр EAX обнуляется командой XOR в строке 1. Это означает, что имеется шесть байтов мусорного кода. Этот мусорный блок использует команды, которые повлияют на дизассемблер, создавая новую ветвь и, по всей видимости, вставляя конец функции (команду RET в строке 9).

При правильной генерации блоки мусорного кода бывает довольно трудно заметить с первого взгляда. Чаще всего они удаляются из области досягаемости дизассемблера как побочный эффект деобфускации потока управления (см. Control Flow Deobfuscation via Abstract Interpretation). В последнем примере, если непрозрачный предикат распознан как таковой, к блоку мусорного кода больше не ведет ни одного пути. Как и все остальные методы, если он недостаточно диверсифицирован - например, использует ограниченную базу статических шаблонов, - его устойчивость и сила обычно минимальны.

Основная идея выравнивания графа - заменить все структуры управления одним оператором switch, называемым диспетчером. Выбирается подграф графа потока управления программы (реализации часто работают на уровне функций) и преобразуется; при этом базовые блоки могут перерабатываться (разделяться или объединяться). Затем каждый базовый блок отвечает за обновление контекста диспетчера (то есть состояния подпрограммы), чтобы диспетчер мог связаться со следующим базовым блоком (см. рисунок 5-1). Связи между базовыми блоками теперь "скрыты" внутри операций манипулирования контекстом диспетчера. Условные переходы (как в блоке d) можно легко эмулировать с помощью проверки флагов и команд IMUL либо простых команд CMOV.

Рисунок 5-1. Исходный и выровненный графы потока управления

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

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

Если вы хотите самостоятельно увидеть выровненный код, просто возьмите копию подключаемого модуля Flash (например, NPSWF32.dll), дизассемблируйте файл и найдите функции самого большого размера. Выровненные функции легко распознать.

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

К примерам известных защит, основанных на VM, относятся VMProtect и CodeVirtualizer. Позднее мы углубимся в восхитительное занятие анализа VM. Пока достаточно сказать, что атакующему необходимо понять интерпретатор, чтобы проанализировать байт-код и в конечном счете создать компилятор с целевой архитектуры на родную (девиртуализация).

Когда защищаемое приложение не может основывать свою безопасность на использовании аппаратного компонента или сетевого сервера, приходится предположить наличие атакующего, способного выполнять приложение в полностью контролируемой им или ею среде. Соответствующая этой ситуации модель атакующего, называемая контекстом атаки белого ящика (white-box attack context, WBAC), требует особой программной реализации классических криптографических примитивов.

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

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

Вероятностный алгоритм O является обфускатором, если он удовлетворяет следующим свойствам, приведенным Бараком с соавторами^[2]:

• P и O(P) вычисляют одну и ту же функцию.

• Рост времени выполнения и пространства O(P) не более чем полиномиален относительно времени выполнения и пространства программы P.

• Для любого вероятностного алгоритма A с полиномиальным временем существует вероятностный алгоритм S с полиномиальным временем и пренебрежимо малая функция m (пренебрежимо малая функция растет намного медленнее обратной величины любого полинома), такие, что для всех программ P:

Свойство виртуального черного ящика выражает тот факт, что распределение выходов любого вероятностного алгоритма анализа A, примененного к обфусцированной программе O(P), почти всюду равно распределению выходов симулятора S, имеющего оракульный доступ к программе P. (Программа S не имеет доступа к описанию программы P, но для любого входа x ей предоставляется доступ к P(x) за время, полиномиальное относительно размера P. Оракульный доступ к программе P эквивалентен доступу только к входным/выходным данным программы P.)

Интуитивно свойство виртуального черного ящика просто требует, чтобы все, что можно вычислить из обфусцированной версии O(P), можно было также вычислить через оракульный доступ к P.

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

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

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

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

Обфускация с помощью сети закодированных таблиц поиска позволяет получить версии алгоритмов DES и AES, более устойчивые в контексте атаки белого ящика. Однако эффективный криптоанализ реализаций белого ящика DES (например, выполненный Губеном^[24]) и AES (Бийе^[5])

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

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

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

Был опубликован метод (Чоу^[9]), затрудняющий извлечение ключа в контексте белого ящика. Принцип состоит в реализации специализированной версии алгоритма DES, в которую встроен ключ K и которая способна выполнять лишь одну из двух операций: шифрование или расшифрование. Эта реализация устойчива в контексте белого ящика, поскольку трудно извлечь ключ K путем наблюдения за выполняемыми программой операциями, а также трудно создать функцию расшифрования на основе реализации функции шифрования и наоборот.

Основная идея - выразить алгоритм как последовательность (или сеть) таблиц поиска и обфусцировать эти таблицы путем кодирования их входов/выходов. Все операции блочного шифра, например сложение по модулю 2 с раундовым ключом, встраиваются в эти таблицы поиска. Таблицы рандомизируются, чтобы обфусцировать их работу.

Обфускация AES (описанная Чоу^[10]) выполняется аналогично DES. Цель по-прежнему состоит во встраивании раундовых ключей в код алгоритма, чтобы не хранить ключ в статической памяти и не загружать его в динамическую память во время выполнения. Для безопасного встраивания этих ключей применяется тот же метод, что и для DES: представить AES как сеть таблиц поиска и применить кодирование входов/выходов, чтобы скрыть ключи.

До сих пор вы познакомились с большим числом методов обфускации. Большинство из них - простые преобразования, которые на первый взгляд кажутся довольно слабыми, и по отдельности они действительно слабы. Как построить безопасность или доверие из таких примитивов? Сила системы обфускации (или обфускатора) возникает из итеративного и совместного применения набора этих методов. Каждое последовательное применение простого метода накапливается в сильное неразличимое глобальное преобразование (во всяком случае, такова цель). Якубовский с соавторами^[26] предложил интересную аналогию между раундовой криптографией и итеративной обфускацией. Раунд криптографического алгоритма состоит из базовых арифметических операций (сложения, исключающего ИЛИ и т. д.), выполняющих тривиальные преобразования входных данных. Взятый отдельно, раунд слаб и подвержен многим формам атак. Тем не менее многократное применение набора раундов может дать достаточно безопасный алгоритм. Именно это является целью обфускатора. Цель атакующего - различить раунды в глобальной обфусцированной форме и атаковать их в самых слабых местах.

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

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

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

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

• понятие разрешимого приближения;

• некоторые статические или динамические методы, которые можно применять, и преимущества гибридных статико-динамических методов (некоторые из них представлены позднее с помощью специализированных инструментов);

• некоторые критерии, которые всегда можно применять для оценки алгоритма анализа и из которых можно вывести критерии безопасности относительно устойчивости обфускации (и, двойственным образом, эффективности преобразования деобфускации);

• открытые проблемы и новые тенденции в области гибридного динамического/статического анализа и формализации деобфускации.

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

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

В оставшейся части этого раздела обсуждаются как "синергия", так и "двойственность" статического и динамического анализа (также рассмотренные Майклом Д. Эрнстом^[20]): сначала вводится формальная модель абстрактной интерпретации, а затем приводятся несколько примеров анализа в связи с деобфускацией.

Цель любого анализа программы - проверить, удовлетворяет ли программа определенному свойству. К сожалению, для любого нетривиального свойства этот вопрос в общем случае неразрешим, то есть нельзя разработать алгоритм, определяющий, выполняется ли свойство для программы. Чтобы преодолеть эту трудность, одним из решений является абстрагирование конкретных вариантов поведения программы в разрешимое приближение. Цель абстрактной интерпретации - формализовать эту идею приближения в единой системе. (Читатели могут обратиться к статье Патрика Кузо и Радии Кузо^[14].)

Семантика программы представляет все возможные конкретные варианты ее поведения, включая взаимодействие с любой возможной средой компьютерной системы. К наиболее точным (конкретным) семантикам относятся так называемые семантики трасс. Эта семантика включает все конечные и бесконечные последовательности состояний и переходов. Если X - множество трасс выполнения (конечных и бесконечных), семантику трасс можно выразить как наименьшее решение (для вычислительного частичного порядка) уравнения неподвижной точки X=F(X).

Абстрактный домен - это абстракция конкретной семантики. Цель абстрактной интерпретации - предоставить вычислимые приближения неподвижной точки абстрактных доменов, тем самым определяя вычислимые абстрактные семантики. Очевидно, чем грубее абстрактная семантика, тем на меньшее число вопросов она способна ответить.

Все абстракции семантики можно организовать в иерархию (описанную Кузо^[16]) от самых точных до самых грубых. Точнее, абстрактные семантики можно разместить на решетке, а частичный порядок приближения этой решетки можно использовать для характеристики конкретности (или точности) абстрактных семантик и, следовательно, множеств вопросов, на которые они способны ответить.

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

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

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

Среди множества методов оптимизации в контексте обратной разработки следует помнить о методах частичного вычисления (описанных Бекманом с соавторами^[3]). Частичный вычислитель специализирует программу относительно части ее входных данных. Ожидается, что процесс специализации сохранит конкретную семантику программы, а синтаксическое представление результирующей программы будет оптимизировано для используемого класса входов и в результате станет проще для понимания.

Другой важный класс методов оптимизации включает методы срезов (описанные Вайзером^[42]), которые также стремятся упростить рассматриваемую программу, но в данном случае путем удаления частей программы, не относящихся к критерию, предоставленному аналитиком. Критерий статического среза включает множество переменных и выбранную точку интереса. Критерий динамического среза дополняет статический критерий сведениями, соответствующими некоторому конкретному выполнению. Срезы представляют большой интерес в контексте обратной разработки, поскольку они отражают то, как специалист по обратной разработке мысленно создает срез программы, пытаясь понять ее внутреннюю работу.

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

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

Чтобы расширить охват динамического тестирования, принцип символьного выполнения (описанный Бойером^[6]) использует символьные значения вместо конкретных входов. В каждой точке символьного выполнения обновляется символьное состояние программы. Это символьное состояние состоит из символьного хранилища и ограничения пути. Символьное хранилище содержит символьные значения, а ограничение пути - формулу, фиксирующую историю всех условных ветвлений, выбранных до текущей команды.

В заданной команде программы можно использовать решатель ограничений (решатель SMT или SAT) для определения соответствующего ограничения пути. Удовлетворяющее присваивание предоставляет конкретные входные данные, с которыми программа достигает данной команды. Генерируя новые тесты и исследуя новые пути, можно увеличить охват динамического тестирования.

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

Конколическое выполнение (описанное Годфруа^[23] и Сеном^[37]) во многих ситуациях решает эту проблему. Идея заключается в одновременном символьном и конкретном выполнении программы. Когда ограничение пути слишком сложно для решателя, можно использовать конкретные сведения для упрощения ограничения (обычно заменяя некоторые символьные значения конкретными). После этого можно ожидать нахождения удовлетворяющего присваивания упрощенного ограничения.

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

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

Оно опирается на более абстрактную семантику, но также на приближение снизу. Абстрактный интерпретатор приближает конкретную семантику программы сверху.

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

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

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

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

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

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

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

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

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

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

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

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

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

Абстрактную интерпретацию можно использовать для моделирования любого преобразования программы (см. статью Патрика и Радии Кузо^[15]). Рассматривая синтаксис программы как абстракцию ее конкретной семантики, мы можем формализовать любое синтаксическое преобразование программы как абстрактную интерпретацию соответствующего семантического преобразования.

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

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

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

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

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

• Это не основное назначение IDA. Обфусцированный код - очень особый случай, а обработка каждой конкретной ситуации/уловки стала бы бесконечной работой; поэтому лучше не вступать на этот путь.

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

• Сама IDA не предлагает никакого промежуточного представления (intermediate representation, IR) или хотя бы семантики команд, поэтому расширенный анализ ее вывода нетривиален.

В 2008 году на семинаре ICAR (презентация) Ильфак Гильфанов предложил несколько полезных советов по использованию конкретных возможностей IDA:

• объединять блоки на уровне графа для упрощения CFG;

• изменять граф динамически по событиям с помощью перехватчиков вроде grcode_changed_graph (см. graph.hpp в SDK);

• разрабатывать специальные подключаемые модули.

IDA можно расширять с помощью сценариев (IDC или IDAPython) или подключаемых модулей (см. SDK IDA). Именно там можно было бы взаимодействовать с IDA при реализации расширенного анализа.

Для этого были разработаны некоторые подключаемые модули в качестве каркасов деобфускации (например, модуль Optimice Бранко Спасоевича, http://optimice.googlecode.com). Пытаясь решить некоторые из упомянутых ранее проблем, включая семантику команд на основе x86 Opcode and Instruction Reference (http://ref.x86asm.net/), этот модуль предлагает сокращение CFG, локальные оптимизации и удаление мертвого кода.

Miasm (http://code.google.com/p/smiasm) - каркас обратной разработки, разработанный Фабрисом Декло и предоставляющий манипулирование PE/ELF, ассемблирование и дизассемблирование (в настоящее время поддерживает Ia32, ARM, PPC и байт-код Java). Как и Metasm, Miasm имеет открытый исходный код и выпущен под GNU Lesser GPL v2, поэтому вы можете углубиться в его движок и настроить его под конкретные потребности. Примеры в этом разделе основаны на последней доступной на момент написания ревизии MIASM (changeset:270:6ee8e9a58648).

Каркас опирается на промежуточный язык. Это означает, что семантика большинства распространенных команд закодирована как список выражений. Слово "список" следует понимать в смысле Python (то есть упорядоченное множество объектов).

Грамматика IR Miasm использует девять базовых типов выражений, наиболее важные из которых:

• ExprInt - числовое значение;

• ExprId - идентификатор/символ, все, что не является числовым значением; например, регистры определяются как ExprId;

• ExprAff - присваивание a = b;

• ExprCond - тернарный/условный оператор a ? b : c;

• ExprMem - косвенное обращение к памяти;

• ExprOp - операция op(a,b,...).

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

Для каждого поддерживаемого процессора файл с суффиксом sem описывает семантику большинства распространенных команд. Например, вот семантика ADD, определенная в miasm/arch/ia32 sem.py:

Эта функция строит семантику команды на основе двух ее операндов (a и b). Эти возможности легко продемонстрировать небольшим сценарием:

Вот вывод:

Семантика команды ADD выглядит наиболее сложной из-за обновления флагов. Вот семантика команды MOV с явным указанием типа объекта:

Это очень ценная и мощная возможность. Поверх IR построена возможность JIT-компиляции, при которой код сначала дизассемблируется, переводится в IR, а затем повторно генерируется как родной код для выполнения. Документация и примеры показывают случаи использования Miasm для анализа упаковщиков/VM, а также для двоичного инструментирования.

В этом разделе обсуждались лишь четыре инструмента (причем с уклоном в статический анализ). Наряду с каркасами Metasm и Miasm можно было бы, например, упомянуть каркас Radare (http://www.radare.org/y/). Заслуживают внимания и усилия Рольфа Роллеса по расширению IDA с помощью его интерпретатора idaocaml (https://code.google.com/p/idaocaml/). Существует множество других инструментов, которые здесь не упоминались или упоминались лишь кратко, и мы призываем вас опробовать их самостоятельно.

Если взглянуть на эти инструменты в перспективе, IDA - хороший дизассемблер, однако при работе с обфусцированным кодом она мало чем может помочь. Каркасы Metasm и Miasm идут на шаг дальше, предоставляя больше контроля, IR для экспериментов и так далее. Такие инструменты, как VxStripper, идут еще дальше. Вероятно, вы уже ощущаете это: идет гонка вооружений. На разработку обфускаторов затрачиваются огромные усилия, поэтому и наши инструменты должны развиваться.

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

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

Первое предлагаемое упражнение - создать генератор ключей для двоичного файла из практического примера этой главы. Это замечательная отправная точка:

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

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

После прочтения этой главы самостоятельная работа с задачей даст бесценный опыт. Ваше задание:

1. На основе предложенной методики (или придуманной вами) создайте собственный инструмент для анализа байт-кода VM.

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

Чтобы познакомиться с Metasm, среди материалов, поставляемых с книгой, вы найдете два сценария упражнений: symbolic-execution-lvl1.rb и symbolic-execution-lvl2.rb. Ответы на вопросы отправят вас в путешествие по внутренностям Metasm. Сценарии можно найти по адресу www.wiley.com/go/practical-reverseengineering.com.