zydak/leetobfuscatorVerschleiert C/C++ durch LLVM-Pässe: String-Verschlüsselung, Kontrollfluss-Abflachung, MBA-Rewriting und Anti-Analyse, um Reverse Engineering zu vereiteln.
██╗ ███████╗███████╗████████╗
██║ ██╔════╝██╔════╝╚══██╔══╝
██║ █████╗ █████╗ ██║
██║ ██╔══╝ ██╔══╝ ██║
███████╗███████╗███████╗ ██║
╚══════╝╚══════╝╚══════╝ ╚═╝
██████╗ ██████╗ ███████╗██╗ ██╗███████╗ ██████╗ █████╗ ████████╗ ██████╗ ██████╗
██╔═══██╗██╔══██╗██╔════╝██║ ██║██╔════╝██╔════╝██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗
██║ ██║██████╔╝█████╗ ██║ ██║███████╗██║ ███████║ ██║ ██║ ██║██████╔╝
██║ ██║██╔══██╗██╔══╝ ██║ ██║╚════██║██║ ██╔══██║ ██║ ██║ ██║██╔══██╗
╚██████╔╝██████╔╝██║ ╚██████╔╝███████║╚██████╗██║ ██║ ██║ ╚██████╔╝██║ ██║
╚═════╝ ╚═════╝ ╚═╝ ╚═════╝ ╚══════╝ ╚═════╝╚═╝ ╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚═╝
A simple obfuscator for C/C++ x64 and x86 code
Das ist als LLVM-Fork umgesetzt, daher benötigt man den tatsächlichen Quellcode, um zu obfuskieren. Es ist kein Obfuskator für beliebige ausführbare Dateien. Es ist eine modifizierte Version des Compilers.
Wenn du dir die Ergebnisse ansehen möchtest, habe ich damit 2 Crackmes erstellt und obfuskiert. Du findest sie in den releases zusammen mit dem vorkompilierten clang-Binary.
All dies wurde mit dem Flag -O3 kompiliert und alle Screenshots stammen aus IDA Pro 9.4. Ich habe es auch mit Binary Ninja und Ghidra getestet, die Ergebnisse waren entweder gleich oder schlechter.
Verschlüsselt Strings zur Kompilierzeit und fügt bei jeder Verwendung des verschlüsselten Strings eine Entschlüsselungsfunktion ein. Dies macht die Möglichkeit, im Binary nach beliebigen Strings zu suchen, vollständig zunichte. Und jeder String hat seinen eigenen eindeutigen Schlüssel, der in der Entschlüsselungsfunktion fest codiert ist, was das Dumpen und Entschlüsseln erheblich erschwert. Diese Entschlüsselungsfunktionen werden außerdem inlined. (unten nur zur Demonstration nicht inlined)
 Vor dem Pass |
 Danach |
Ersetzt arithmetische Operationen durch ihre MBA-Äquivalente. Es ist praktisch unmöglich zu erkennen, was die ursprüngliche Operation bewirkt hat, es sei denn, man führt sie zuerst durch einen MBA-Deobfuskator. Natürlich ist diese Obfuskierung ziemlich schwach, da MBA der älteste Trick überhaupt ist, sodass es viele Tools gibt, die damit umgehen können, zum Beispiel CoBRA, das dies erfolgreich in den ursprünglichen Ausdruck deobfuskieren wird:
./cobra-cli --mba "((x^y) - (((x^y)&0xFF)&0xA) + 10) * ((x^y) - ((x^y)|0xA) + 10) + ((x^y) - (((x^y)&0xFF)|0xFFFFFFF5) - 11) * (~(x^y) - (~(x^y)|0xA) + 10)" --bitwidth 32
10 * (x ^ y)
Deshalb habe ich den AAMBA-Pass erstellt.
 Vor dem Pass |
 Danach |
Ersetzt Operanden von Binäroperationen durch ADC(X, 255) - 255 - CF und SBB(X, 255) + 255 + CF. Natürlich ergibt das immer X, aber es macht den Ausdruck vom Carry-Flag abhängig. Sofern der Decompiler den Zustand von CF nicht verfolgt (was manchmal unmöglich ist), wird er stark verwirrt und kann diese Ausdrücke nicht zusammenfalten. Es passt sehr gut zum vorherigen MBA-Pass, der die Arithmetik noch weiter verschleiert. Wie unten zu sehen ist, hat der Decompiler einige zusätzliche Variablen erzeugt und verwendet viele __PAIR64__- und __CFADD__-Aufrufe, sodass es deutlich schwieriger wird (aber immer noch nicht unmöglich), das in Tools wie CoBRA einzufügen; auch IDAs gooMBA-Plugin hilft nicht beim Vereinfachen. Zudem verfolgt IDAs Decompiler das Carry-Flag bis zu einem gewissen Grad, aber in Kombination mit Control-Flow-Obfuskation wird das Verfolgen ohne Ausführung praktisch unmöglich, da man nicht weiß, was die vorherige Operation war – vielleicht hat sie CF auf 1 gesetzt, vielleicht auch nicht –, sodass spätere Pässe zu diesem noch mehr hinzufügen.
|
Vor dem Pass |
 Danach |
Sammelt alle Blöcke innerhalb einer Funktion und macht daraus eine einzige riesige Zustandsmaschine; es erstellt eine Sprungtabelle am Anfang der Funktion und platziert alle Blockzeiger darin. Dann wird statt eines normalen Sprungs am Ende jedes Blocks alles über den Dispatcher geleitet, der indirekte Sprünge verwendet; diese sind ohne Ausführung praktisch unmöglich statisch aufzulösen. Außerdem werden Register auf den Stack verlagert, sodass beim Halbieren eines Blocks alle Variablen des vorherigen Blocks auf dem Stack liegen, was bedeutet, dass es in jedem Ausdruck SEHR VIELE Variablen geben wird. Wenn man die Operationen eines einzelnen Blocks durch CoBRA laufen lässt, wird es nicht viel deobfuskieren können, da es zu viele unbekannte Variablen geben wird.
Erzeugt eine Reihe von Scheinblöcken mit ungültigem Assembly. Das bringt Disassembler enorm durcheinander, denn wenn der Disassembler auf ein technisch ungültiges Byte trifft, das nie ausgeführt wird, versucht er trotzdem, daraus einen Sinn zu machen. Ist das Byte unvollständig, erzeugt er aus den nachfolgenden Bytes eine Anweisung und verbraucht sie dabei im Wesentlichen. Das erzeugt eine Desynchronisation, die jede Anweisung danach zerstört. Bei Windows-Binaries kann IDA sich davon einigermaßen erholen und in seltenen Fällen einen Graphen erzeugen und das dekompilieren, was es kann (allerdings fehlerhaft und unvollständig), während bei Linux-Binaries die Graphansicht vollständig zerstört und die Dekompilierung deaktiviert wird. Zusätzlich fügt es einen RDTSC-Timer und einige andere Anti-Debug-Prüfungen ein; wenn ein Debugger erkannt wird, stürzt das Programm ab.