# Подход

Мы опираемся на ключевую интуицию, что обфусцированная трасса T' (из обфусцированного кода P') объединяет исходные инструкции из исходного кода P (трассу T, соответствующую T' в исходном коде) и инструкции виртуальной машины VM, так что T' = T + VM(T). Если нам удастся различить эти две подпоследовательности инструкций, T и VM(T), мы сможем восстановить один путь исходной программы P из трассы T'. Повторяя эту операцию для покрытия всех путей виртуализированной программы, мы сможем восстановить исходную программу P. В нашем практическом примере исходный код имеет конечное число исполняемых путей, что характерно для многих ситуаций, связанных с защитой интеллектуальной собственности. Для этого мы выполняем следующие шаги:

1. Определить виртуализированную функцию и её аргументы
2. Сгенерировать трассу VMProtect целевой программы
3. Воспроизвести трассу VMP и построить символьные выражения для получения зависимости между входными данными и выходным значением
4. Применить оптимизации к символьным выражениям, чтобы по возможности избежать инструкций VM
5. Поднять наше символьное представление до LLVM-IR, чтобы создать новую незащищённую версию целевой программы

## Пример 1: Простая побитовая операция

В качестве первого примера возьмём следующую функцию: она принимает два входных значения и возвращает `x ^ y`, которая защищена VMProtect.```cpp
int secret(int x, int y) {
  VMProtectBegin("secret");
  int r = x ^ y;
  VMProtectEnd();
  return r;
}

Вы можете увидеть результат [здесь](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/vmp_traces/sample2.vmp.trace). Формат трассировки использует три вида операций: `mr`, `r` и `i`.
`mr` — это чтение из памяти, выполненное инструкцией `i`, а `r` — регистры CPU. Например:```
mr:0x7ffda459d718:8:0x227db4f8
r:0x40200a:0x0:0x7ffda459f571:0x2:0x40200a:0x0:0x0:0x7ffda459d688:0x0:0x0:0x7feee9b80ac0:0x7feee9b8000f:0xad1c3e:0x0:0x0:0x0
i:0x89173e:8:488BB42490000000

После того как трассировка VMP была создана, мы воспроизводим её с помощью скрипта [attack_vmp.py](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/attack_vmp.py). Этот скрипт использует
[Triton](https://github.com/jonathansalwan/Triton) для построения предиката пути трассировки. Обратите внимание, что все выражения, которые
включают символьные переменные (входные данные функции), остаются символьными, тогда как все выражения, не связанные с входными данными, конкретизируются. Другими
словами, наши символьные выражения не содержат ни одной операции, относящейся к виртуальной машине (сам механизм
не зависит от пользователя), а только операции, относящиеся к исходной программе.

Например, ниже показан пример конкретизации. Слева у нас есть AST, содержащий подвыражения, которые не включают
символьную переменную (`1 + 2` и `6 ^ 3`). Поэтому эти ветви конкретизируются и заменяются константами `3` и `5`, что приводит к
AST справа. **Именно так мы девиртуализируем код.**

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/8096/857ed50cfe9cb2347f816ece1d8dc4c13174c971dcb65ebc5621be14269a5ca8.png">
</p>

**Примечание об обратном слайсировании на уровне формул**: Как это принято в символьном исполнении, символьное представление сначала
вычисляется в прямом направлении вдоль пути, затем все логические операции и определения, которые не влияют ни на конечный результат,
ни на пройденный путь, удаляются из символьного выражения (слайсирование формул, также известное как обрезка формул). Это приводит к тому, что
для формулы выполняется эквивалент анализа кода с обратным слайсированием от выхода программы. Таким образом, при возврате из
функции `secret` мы получаем выражение связи между входными данными и выходом без инструкций VMProtect.

Скрипт `./attack_vmp.py` принимает в качестве параметров файл трассировки и размер символьных переменных. Напомним, это были `edi` и
`esi`, то есть они имеют длину 4 байта. Результат работы скрипта выглядит следующим образом:```
$ ./attack_vmp.py --trace1 ./vmp_traces/sample2.vmp.trace --symsize 4
[+] Replaying the VMP trace
[+] Symbolize inputs
[+] Instruction executed: 12462
[+] Emulation done
[+] Return value: 0x3
[+] Devirt expr: (bvor (bvnot (bvor (bvnot (bvnot x)) (bvnot y))) (bvnot (bvor (bvnot x) (bvnot (bvand (bvnot y) (bvnot y))))))
[+] Synth expr: (bvxor x y)

[+] LLVM IR ==============================

; ModuleID = 'tritonModule'
source_filename = "tritonModule"

define i32 @__triton(i32 %SymVar_0, i32 %SymVar_1) {
entry:
  %0 = xor i32 %SymVar_0, %SymVar_1
  ret i32 %0
}

[+] EOF LLVM IR ==============================

Однако нам не удалось восстановить исходное выражение, которое представляло собой простую операцию `XOR`. Похоже, что `XOR` был
преобразован в побитовые операции. К счастью, недавно мы выпустили новые возможности в проекте Triton:
[синтезатор](https://github.com/JonathanSalwan/Triton/issues/1074) и лифтер для
[LLVM-IR](https://github.com/JonathanSalwan/Triton/issues/1078). Таким образом, мы можем синтезировать выражение, которое даёт нам
`(bvxor x y)`. Это хороший результат, и теперь мы можем пойти дальше, преобразовав это выражение в LLVM-IR, а затем скомпилировать новый девиртуализированный
двоичный код.

## Пример 2: Защищённая MBA-операция

Хорошо, теперь давайте рассмотрим другой пример, в котором предпринимается попытка скрыть MBA-операцию. Исходный код выглядит следующим образом:```cpp
// This function is an MBA that computes: (x ^ 92) + y
// We will protect this MBA with VMProtect and see if we can recover "(x ^ 92) + y"
char secret(char x, char y) {
  VMProtectBegin("secret");
  int a = 229 * x + 247;
  int b = 237 * a + 214 + ((38 * a + 85) & 254);
  int c = (b + ((-(2 * b) + 255) & 254)) * 3 + 77;
  int d = ((86 * c + 36) & 70) * 75 + 231 * c + 118;
  int e = ((58 * d + 175) & 244) + 99 * d + 46;
  int f = (e & 148);
  int g = (f - (e & 255) + f) * 103 + 13;
  int r = (237 * (45 * g + (174 * g | 34) * 229 + 194 - 247) & 255) + y;
  VMProtectEnd();
  return r;
}

Как только будет сгенерирована [трассировка VMP](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/vmp_traces/sample3.vmp.trace), запустим скрипт `./attack_vmp.py`.```
$ ./attack_vmp.py --trace1 ./vmp_traces/sample3.vmp.trace --symsize 1
[+] Replaying the VMP trace
[+] Symbolize inputs
[+] A potential symbolic jump found on CF flag: 0x821dac: popfq - Model: {0: x:32 = 0xa3, 1: y:32 = 0xff}
[+] A potential symbolic jump found on CF flag: 0x87f437: popfq - Model: {0: x:32 = 0xa3, 1: y:32 = 0xff}
[+] Instruction executed: 25085
[+] Emulation done
[+] Return value: 0x5f
[+] Devirt expr: In: (bvadd (bvadd (bvshl (bvadd (_ bv1 32) (bvnot (bvlshr (concat (_ bv0 8) (_ bv0 8) ((_ extract 15 8)  ...
[+] Synth expr: In: (bvadd (bvadd (bvshl (bvadd (_ bv1 32) (bvnot (bvlshr (concat (_ bv0 8) (_ bv0 8) ((_ extract 15 8)  ...

[+] LLVM IR ==============================

; ModuleID = 'tritonModule'
source_filename = "tritonModule"

define i32 @__triton(i8 %SymVar_0, i8 %SymVar_1) {
entry:
  %0 = xor i8 %SymVar_0, 92
  %1 = and i8 %SymVar_0, 0
  %2 = zext i8 %1 to i32
  %3 = or i32 0, %2
  %4 = shl i32 %3, 8
  %5 = zext i8 %0 to i32
  %6 = or i32 %4, %5
  %7 = and i8 %SymVar_1, 0
  %8 = zext i8 %7 to i32
  %9 = or i32 0, %8
  %10 = shl i32 %9, 8
  %11 = zext i8 %SymVar_1 to i32
  %12 = or i32 %10, %11
  %13 = zext i8 %7 to i32
  %14 = or i32 0, %13
  %15 = shl i32 %14, 8
  %16 = zext i8 %SymVar_1 to i32
  %17 = or i32 %15, %16
  %18 = lshr i32 %17, 7
  %19 = xor i32 %18, -1
  %20 = add i32 1, %19
  %21 = shl i32 %20, 8
  %22 = add i32 %21, %12
  %23 = add i32 %22, %6
  ret i32 %23
}

[+] EOF LLVM IR ==============================

Используя оптимизации LLVM, мы смогли убрать шум из нашего девиртуализированного вывода и таким образом взломать MBA.
Мы видим операцию `XOR` с её константой (`%0 = xor i8 %SymVar_0, 92`) и `+ y` (`%6 = add nsw i32 %5, %1`).
Инструкции между ними просто обрабатывают знак. Если подвести итог этого примера, мы полностью девиртуализировали функцию `secret`
с помощью скрипта `attack_vmp.py`, а затем полностью взломали MBA с помощью оптимизаций LLVM.

## Пример 3: Более одного базового блока

Мы получили очень хорошие результаты, если функция `secret` содержит только один базовый блок, независимо от его размера. Итак, на данный момент
мы способны девиртуализировать один путь. Чтобы восстановить поведение всей функции, мы должны последовательно девиртуализировать
достижимые пути. Для этого необходимо выполнить покрытие путей на ветвлениях, зависящих от пользовательского ввода. В итоге мы получаем
дерево путей, которое представляет различные пути исходной функции. Дерево путей получается путём введения
конструкции if-then-else из двух трасс T1 и T2 с одинаковым префиксом, за которым следует условие C в T1 и not(C)
в T2. Как только дерево путей построено, мы можем позволить LLVM сгенерировать CFG.

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/8096/fc5d1bf9a1544b9b44ef164247f3fc38d04bf45d7c2d7a3c0b21ea3d6636cd39.png">
</p>

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

Хорошо, давайте рассмотрим следующий пример:```cpp
int secret(int x, int y) {
  VMProtectBegin("secret");
  int r = 0;
  if (x + y == 1001)
    r = x + 1;
  else
    r = y - 1;
  VMProtectEnd();
  return r;
}

Скрипт сообщает нам, что может существовать потенциальный символический переход по флагу `AF` по адресу `0x80d905`.
Он также предоставляет новую модель (использующую символическое выполнение), которая должна пойти по другому пути. Итак, давайте сгенерируем
вторую трассировку с помощью этой модели (если вы посмотрите на модель, она корректна относительно нашего исходного кода).```
$ ./pin/pin -t ./pin/source/tools/VMP_Trace/obj-intel64/VMP_Trace.so -start 4198848 -end 4198928 -- ./vmp_binaries/binaries/sample5.vmp.bin 0 1001 &> ./vmp_traces/sample5.vmp.trace.2

На этом шаге мы девиртуализировали два трейса и объединили их в выражения `if-then-else`.
После подъёма выражения до LLVM-IR мы получаем CFG всего с 480 инструкциями LLVM, что
уже является хорошим выигрышем по сравнению с тысячами инструкций, выполняемых виртуальной машиной.
Но мы можем добиться большего, если используем оптимизации LLVM:```llvm
$ opt -S -O3 ./devirt/sample5.ll
; ModuleID = './devirt/sample5.ll'
source_filename = "tritonModule"

; Function Attrs: mustprogress nofree norecurse nosync nounwind readnone willreturn
define i32 @__triton(i32 %SymVar_0, i32 %SymVar_1) local_unnamed_addr #0 {
entry:
  %0 = add i32 %SymVar_0, 1
  %1 = add i32 %SymVar_1, -1
  %2 = add i32 %SymVar_1, %SymVar_0
  %.not = icmp eq i32 %2, 1001
  %3 = select i1 %.not, i32 %0, i32 %1
  ret i32 %3
}

attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone willreturn }