TinyLoad v6: Mehr Schutz für Windows-PE-Packer durch verschlüsselte Opcodes

Mit TinyLoad v6 präsentiert der gleichnamige Open-Source-Packer für Windows-PE-Dateien eine deutliche Aufwertung seiner Anti-Analyse-Methoden. Die aktualisierte Version konzentriert sich auf zwei zentrale Schwachstellen früherer Ausgaben: die statische Sprungtabelle des virtuellen Maschinen-Interpreters und die zentrale Opcode-Tabelle. Beide wurden durch dynamische, verschlüsselte Alternativen ersetzt, die eine statische Analyse nahezu unmöglich machen sollen.

Die Grenzen klassischer Switch-Anweisungen im VM-Interpreter

Bis zur Version 5 setzte TinyLoad in seiner virtuellen Maschine auf eine klassische switch(op)-Anweisung, um 28 verschiedene Opcode-Handler zu verwalten. Diese Struktur ist jedoch ein bekanntes Muster für Reverse-Engineering-Tools. Disassembler erkennen solche Switch-Anweisungen sofort und können anhand der Handler-Layouts Rückschlüsse auf die Funktionsweise einzelner Opcodes ziehen – selbst ohne Ausführung des Codes.

TinyLoad v6 ersetzt diese ineffiziente Methode nun durch eine computed-goto-Dispatch-Tabelle, die auf die GCC-Erweiterung &&label zurückgreift. Die Sprungadressen der Handler werden zur Laufzeit aus dem Arbeitsspeicher des Packers ausgelesen, mit einem zufälligen Schlüssel verschlüsselt und in der Binärdatei abgelegt. Der verschlüsselte Stub entschlüsselt die Tabelle erst im Speicher und springt dann dynamisch zu den jeweiligen Handlern.

static void* s_tbl[32] = {}; // Tabelle der Handler-Adressen

// Verschlüsselung zur Packzeit
uint64_t dispKey = rng3();
for (int i = 0; i < 32; i++) {
    uintptr_t addr = (uintptr_t)s_tbl[i];
    s_tbl[i] = (void*)(addr ^ dispKey);
}

// Laufzeit-Dispatch
uint8_t raw = vmCode[ip++];
uint8_t sub = raw >> 3, slot = raw & 7;
uint8_t op = decodeOp(sub, slot);
void* handler = (void*)((uintptr_t)s_tbl[op] ^ dispKey);

// Sprung zum Handler
__builtin_goto(*handler);

Durch diese Methode existiert keine statische Sprungtabelle mehr im gepackten Binärfile. Selbst bei einer Speicherdump-Analyse bleibt die ursprüngliche Struktur verborgen.

Aufgeteilte Opcode-Decoder für höhere Resistenz

In Version 5 verschlüsselte TinyLoad seine Opcode-Tabelle mit einem einzigen Schlüssel. Ein erfolgreicher Angriff auf diesen Schlüssel ermöglichte den Zugriff auf alle 28 Opcodes. Version 6 geht einen Schritt weiter und unterteilt die Opcodes in vier unabhängige 8-Einträge-Tabellen, die jeweils mit einem eigenen Schlüssel verschlüsselt werden.

Die Schlüssel für die Subtabellen werden aus unterschiedlichen Datenabschnitten des Packers, der virtuellen Maschine und der Payload abgeleitet. Dadurch entsteht ein komplexes, dateispezifisches Verschlüsselungssystem, bei dem ein erfolgreicher Angriff auf eine Subtabelle maximal acht Opcodes preisgibt. Die verbleibenden 20 Opcodes bleiben durch drei weitere, voneinander unabhängige Schlüssel geschützt.

BYTE sub0[8], sub1[8], sub2[8], sub3[8]; // Vier verschlüsselte Subtabellen

// Schlüsselableitung aus verschiedenen Datenabschnitten
uint32_t k0 = fnv(origSz, packSz, vmCode[0..7]);
uint32_t k1 = fnv(packSz, vmCodeSz, payload[0..7]);
uint32_t k2 = fnv(vmCodeSz, origSz, vmCode[8..15]);
uint32_t k3 = fnv(origSz ^ packSz, vmCodeSz, payload[8..15]);

// Entschlüsselung der Subtabellen
for (int i = 0; i < 8; i++) {
    sub0[i] ^= (uint8_t)(k0 >> (i % 4 * 8));
    sub1[i] ^= (uint8_t)(k1 >> (i % 4 * 8));
    // ... weitere Subtabellen
}

Jede gepackte Datei erhält dadurch eine einzigartige Opcode-Kodierung, die sich dynamisch ändert und statische Muster verhindert.

Kontrollflussverflachung und Rauschen zur Täuschung

TinyLoad v6 führt zudem eine stufenweise Ausführung seiner Hauptfunktionen ein. Funktionen wie tryRun und runInMem werden in mehrere Phasen unterteilt, die über Funktionszeigertabellen gesteuert werden. Dadurch entsteht kein linearer Kontrollfluss mehr, der sich leicht nachverfolgen lässt.

tryRun: s_chk → s_ld → s_prs → s_vm → s_dc → s_ex
runInMem: sp_hdr → sp_map → sp_reloc → sp_import → sp_go

Zusätzlich wird bei jedem Phasenübergang und alle 64 VM-Iterationen die Funktion noiseDecrypt() aufgerufen. Diese führt scheinbar sinnlose Entschlüsselungsoperationen auf temporären Buffern mit zufälligen Schlüsseln durch. In einer dynamischen Analyse sind die echten Entschlüsselungsaufrufe (z. B. für IAT-Hooks) dadurch nur schwer von den Rauschfunktionen zu unterscheiden.

Weitere Verbesserungen in v6

• Vollständige Ressourcen-Klonung: Die Version ersetzt die bisherige harte Kodierung bekannter Ressourcentypen wie RT_ICON oder RT_VERSION durch eine dynamische Erkennung über EnumResourceTypesA. Dadurch bleiben alle Ressourcentypen nach dem Packen erhalten.

• Behebung eines LZ-Kompressionsfehlers: Ein bisher unentdeckter Fehler in der Hash-Ketten-Logik führte zu einer leichten Verschlechterung der Kompressionsqualität. Dieser wurde behoben, was zu einer durchschnittlichen Verbesserung von etwa 2 % bei den getesteten Dateien führte.

• Erweiterte PE-Loader-Härtung: Neue Sicherheitsmaßnahmen umfassen eine Überprüfung von SizeOfBlock gegen Unterläufe, eine Validierung von Relokationsgrenzen, eine Ablehnung negativer e_lfanew-Werte sowie eine Begrenzung der Import-Thunk-Iterationen.

Praktische Anwendung von TinyLoad v6

Die Nutzung von TinyLoad v6 erfolgt über eine einfache Kommandozeile:

TinyLoad.exe --i myapp.exe --vm --c

Der Packer kann direkt aus dem Quellcode mit folgendem Befehl kompiliert werden:

g++ -o TinyLoad.exe TinyLoad.cpp -static -O2 -s

Die fertigen Binärdateien stehen in den Releases zum Download bereit.

Ausblick auf Version 7

Die Entwickler planen für TinyLoad v7 eine weitere Herausforderung: die Integration einer Run-in-RAM-Logik, die sicherstellt, dass ein Speicherdump der Payload ohne den Original-Packer unbrauchbar wird. Diese Funktion soll die letzte große Lücke in der Anti-Dump-Strategie schließen.

Zusätzlich wird über die Einführung weiterer opaker Prädikate sowie eine zusätzliche Verschlüsselungsebene für den Bytecode nachgedacht. Feedback und Fehlerberichte aus der Community sind willkommen und können über das Issue-Tracking-System eingereicht werden.