# Der Ansatz

Wir stützen uns auf die grundlegende Erkenntnis, dass eine verschleierte Ablaufspur T' (aus dem verschleierten Code P') die ursprünglichen Anweisungen des Originalcodes P (die Ablaufspur T, die T' im Originalcode entspricht) und Anweisungen der virtuellen Maschine VM kombiniert, sodass T' = T + VM(T). Wenn wir in der Lage sind, zwischen diesen beiden Untersequenzen von Anweisungen T und VM(T) zu unterscheiden, können wir einen Pfad des Originalprogramms P aus einer Ablaufspur T' rekonstruieren. Durch Wiederholung dieses Vorgangs, um alle Pfade des virtualisierten Programms abzudecken, können wir das Originalprogramm P rekonstruieren. In unserem praktischen Beispiel hat der Originalcode eine endliche Anzahl ausführbarer Pfade, was in vielen Situationen des Schutzes geistigen Eigentums der Fall ist. Dazu gehen wir wie folgt vor:

1. Identifizieren der virtualisierten Funktion und ihrer Argumente
2. Erzeugen einer VMProtect-Ablaufspur des Ziels
3. Abspielen der VMP-Ablaufspur und Konstruktion symbolischer Ausdrücke, um die Beziehung zwischen Eingaben und Ausgabe zu erhalten
4. Anwenden von Optimierungen auf symbolische Ausdrücke, um nach Möglichkeit Anweisungen der VM zu vermeiden
5. Heben unserer symbolischen Darstellung auf LLVM-IR, um eine neue ungeschützte Version des Ziels zu erstellen

## Beispiel 1: Eine einfache bitweise Operation

Nehmen wir als erstes Beispiel die folgende Funktion: Sie nimmt zwei Eingaben entgegen und gibt `x ^ y` zurück, die durch VMProtect geschützt ist.```cpp
int secret(int x, int y) {
  VMProtectBegin("secret");
  int r = x ^ y;
  VMProtectEnd();
  return r;
}

Sie können das Ergebnis [hier](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/vmp_traces/sample2.vmp.trace) sehen. Das Trace-Format verwendet drei Arten von Operationen: `mr`, `r` und `i`.  
`mr` ist ein Speicherlesezugriff, der von der Instruktion `i` durchgeführt wird, und `r` sind die CPU-Register. Zum Beispiel:```
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

Sobald die VMP-Ablaufverfolgung generiert wurde, spielen wir sie mit dem Skript [attack_vmp.py](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/attack_vmp.py) erneut ab. Dieses Skript verwendet [Triton](https://github.com/jonathansalwan/Triton), um das Pfadprädikat der Ablaufverfolgung zu erstellen. Beachten Sie, dass alle Ausdrücke, die symbolische Variablen (Eingaben der Funktion) betreffen, symbolisch bleiben, während alle nicht damit zusammenhängenden Eingabeausdrücke konkretisiert werden. Mit anderen Worten: Unsere symbolischen Ausdrücke enthalten keine Operationen, die sich auf die virtuelle Maschine beziehen (die Maschinerie selbst hängt nicht vom Benutzer ab), sondern nur Operationen, die sich auf das ursprüngliche Programm beziehen.

Zum Beispiel folgt unten ein Beispiel für eine Konkretisierung. Links haben wir einen AST, der Unterausdrücke enthält, die keine symbolische Variable involvieren (`1 + 2` und `6 ^ 3`). Diese Zweige werden also konkretisiert und durch die Konstanten `3` und `5` ersetzt, was zum AST rechts führt. **So devirtualisieren wir Code.**

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

**Ein Hinweis zum rückwärtsgerichteten Slicing auf Formelebene**: Wie bei der symbolischen Ausführung üblich, wird die symbolische Darstellung zunächst vorwärts entlang des Pfades berechnet. Anschließend werden alle logischen Operationen und Definitionen, die weder das Endergebnis noch den verfolgten Pfad beeinflussen, aus dem symbolischen Ausdruck entfernt (Formel-Slicing, auch Formel-Pruning genannt). Dies führt auf der Formel zu einer Analyse, die dem rückwärtsgerichteten Slicing des Codes aus der Programmausgabe entspricht. Somit haben wir bei der Rückkehr der `secret`-Funktion einen Ausdruck für die Beziehung zwischen den Eingaben und der Ausgabe ohne die Anweisungen von VMProtect.

Das Skript `./attack_vmp.py` nimmt als Parameter die Ablaufverfolgungsdatei und die Größe der symbolischen Variablen entgegen. Erinnern Sie sich, es waren `edi` und `esi`, also sind sie 4 Bytes lang. Das Ergebnis des Skripts ist das Folgende:```
$ ./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 ==============================

Allerdings gelang es uns nicht, den ursprünglichen Ausdruck wiederherzustellen, der eine einfache `XOR`-Operation war. Es scheint, dass das `XOR` in bitweise Operationen übersetzt wurde. Glücklicherweise haben wir kürzlich neue Funktionen im Triton-Projekt veröffentlicht, nämlich einen [Synthesizer](https://github.com/JonathanSalwan/Triton/issues/1074) und einen Lifter zu [LLVM-IR](https://github.com/JonathanSalwan/Triton/issues/1078). Somit können wir den Ausdruck synthetisieren, der den Ausdruck `(bvxor x y)` ergibt. Das ist ein guter Erfolg, und jetzt können wir weitergehen, indem wir diesen Ausdruck nach LLVM-IR liften und dann einen neuen devirtualisierten Binärcode kompilieren.

## Beispiel 2: Eine geschützte MBA-Operation

Ok, schauen wir uns nun ein weiteres Beispiel an, das versucht, eine MBA-Operation zu verbergen. Der ursprüngliche Quellcode ist der folgende:```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;
}

Sobald die [VMP-Spur](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/vmp_traces/sample3.vmp.trace) erzeugt wurde, führen wir das Skript `./attack_vmp.py` aus.```
$ ./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 ==============================

Unter Verwendung von LLVM-Optimierungen gelang es uns, Rauschen aus unserer devirtualisierten Ausgabe zu entfernen und so die MBA zu brechen.
Wir sehen die `XOR`-Operation mit ihrer Konstanten (`%0 = xor i8 %SymVar_0, 92`) und das `+ y` (`%6 = add nsw i32 %5, %1`).
Anweisungen dazwischen beschäftigen sich lediglich mit dem Vorzeichen. Um dieses Beispiel zusammenzufassen: Wir haben die `secret`-Funktion mit Hilfe des `attack_vmp.py`-Skripts vollständig devirtualisiert und dann die MBA mit LLVM-Optimierungen vollständig gebrochen.

## Beispiel 3: Mehr als ein Basisblock

Wir haben sehr gute Ergebnisse erzielt, wenn die `secret`-Funktion unabhängig von ihrer Größe nur einen Basisblock enthält. An diesem Punkt
sind wir in der Lage, einen Pfad zu devirtualisieren. Um das gesamte Funktionsverhalten zu rekonstruieren, müssen wir nacheinander erreichbare
Pfade devirtualisieren. Dazu müssen wir eine Pfadabdeckung auf benutzerabhängigen Verzweigungen durchführen. Als Ergebnis erhalten wir
einen Pfadbaum, der die verschiedenen Pfade der ursprünglichen Funktion darstellt. Ein Pfadbaum wird durch Einführung von
If-Then-Else-Konstruktionen aus zwei Spuren T1 und T2 mit demselben Präfix, gefolgt von einer Bedingung C in T1 und einem not(C)
in T2, erhalten. Sobald ein Pfadbaum erstellt ist, können wir LLVM einen CFG generieren lassen.

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

Beim Tigress-Software-Schutz wurden virtuelle Sprünge mit echten `jcc`-Anweisungen implementiert, die es uns ermöglichten,
die Sprungbedingung schnell zu identifizieren. Die Dinge werden jedoch komplexer, wenn virtuelle Sprünge bei
VMProtect involviert sind, da es keine `jcc`-Anweisungen zum Springen zu einem anderen virtuellen Block verwendet. Wir mussten
Marker auf einer dynamischen Spur definieren, um die an einer benutzerabhängigen Verzweigung beteiligte Bedingung zu lokalisieren. Dies ist der experimentelle Teil
dieses Angriffs, da Marker nicht sehr genau sind, aber für unsere Beispiele funktionierten.

Ok, betrachten wir das folgende Beispiel:```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;
}

Das Skript teilt uns mit, dass möglicherweise ein potenzieller symbolischer Sprung am `AF`-Flag an der Adresse `0x80d905` gefunden wurde.
Es stellt auch ein neues Modell (unter Verwendung symbolischer Ausführung) bereit, das den anderen Pfad nehmen sollte. Lassen Sie uns also eine
zweite Ablaufverfolgung mit diesem Modell generieren (wenn Sie sich das Modell ansehen, ist es bezüglich unseres Quellcodes korrekt).```
$ ./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

Bei diesem Schritt haben wir die beiden Traces entvirtualisiert und zu `if-then-else`-Ausdrücken zusammengeführt.
Nach dem Anheben des Ausdrucks auf LLVM-IR erhalten wir einen CFG mit nur 480 LLVM-Instruktionen, was bereits ein guter Gewinn im Vergleich zu den Tausenden von Instruktionen ist, die von der virtuellen Maschine ausgeführt werden.
Aber wir können noch besser werden, wenn wir LLVM-Optimierungen nutzen:```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 }