vmp-devirt

Trace-gestützte VMProtect-Devirtualisierungsforschung: Versions-Frontends (1.x Gate / 2.x Tabelle / 3.x FDJ), die ein gemeinsames Backend speisen (Remill-Lift → LLVM-Opt → semantische Karten → Datenfluss → native Objekte).

Validiert gegen selbstgebaute VMP-3.9.4-Binärdateien über mehrere Schutzmodi hinweg. VMP-3.8.x/3.10.x-Kompatibilität ist experimentell und sample-abhängig.

Umfang und Einschränkungen (zuerst lesen)

Dies ist eine Forschungsplattform zur Analyse von VMProtect-geschützten Binärdateien, die Ihnen gehören oder für die Sie eine Reverse-Engineering-Lizenz besitzen — kein universeller Devirtualizer auf Knopfdruck:

• VMP 3.7+ benötigt Ausführung: Fetch-Streams, Schlüssel und Handler-Ziele stammen aus instrumentierten Unicorn-Snapshots, nicht aus statischer Analyse.
• Die Abdeckung ist trace-gebunden: Nur ausgeführte Pfade werden wiederhergestellt. Multi-State-Läufe + Branch-Merging erweitern sie; die vollständige Programm-CFG-Wiederherstellung für komplexe Ziele bleibt manuell.
• Anti-Emulation (Timing-Gates, I/O-Fallen, Umgebungsprüfungen) erfordert zielspezifische Stubs — das Harness stellt den Mechanismus bereit, Sie liefern die Werte.
• VMP-1.x/2.x-Frontends sind heuristische Scanner; ihre alten statischen Walker werden als Cross-Check-Orakel beibehalten, nicht als primäre Pfade.

Layout

src/
  lib.rs               Crate-Root, data_dir()
  pe_loader.rs         PE-Parsing / VA-Reads
  opcode_map.rs        kanonische 3.5.1-Opcode -> Handler-Map
  frontend/
    mod.rs             VmFrontend-Trait (detect/fetch_stream/handler_addrs)
    fetch_finder.rs    movzx-byte-FDJ-Scan + Watchset/Snapshot-Helfer
    cryptor_miner.rs   Per-Site-ValueCryptor-Mining (branch-following)
    site_emulator.rs   sample-spezifische Oracle-Decoder (Legacy)
    handler_classifier.rs  Handler-Klassifizierung über Legacy-Muster
    classifier_legacy.rs   First-Bytes-Muster (schwach; nur Fallback)
    v1_gate.rs         VMP-1.x-Gate-Scan-Frontend
    v2_walker.rs       VMP-2.x-Dispatch-Table-Frontend
    v3_fdj.rs          VMP-3.x-FDJ-Frontend
  backend/
    value_cryptor.rs   ADD/SUB/XOR/ROL/ROR/NOT/NEG/...-Ketten
    lifter.rs          iced-x86-Text-Lift + Remill-Subprozess-Backend
    llvm_pipeline.rs   opt -O3 über Remill-IR (echte Passes)
  harness/
    snapshot.rs        Unicorn-Snapshots: Sections+Scratch-Mapping,
                       IN-Hooks, Import-Stubs, Watch-Hits, Memlog,
                       Zero-Slide-Fast-Forward
tests/
  smoke.rs             synthetisches PE64 + handgebaute Fetch-Kette (keine Fixtures)
tools/                 (Analyse-Treiber; jeder dokumentiert seine Eingaben)
scripts/               Triton/angr/Ghidra-Helfer (externe Abhängigkeiten)

Build

# Debian/Ubuntu (LLVM 22 für optionales llvm-Feature)
sudo apt install llvm-22-dev libclang-22-dev clang-22
cargo build --release          # reines Rust (kein LLVM-Link)
cargo build --release --features llvm   # llvm-sys-Link-Check
pip install triton-library capstone pefile   # Python-Helfer
# Remill (optionales Lifter-Backend): Upstream bauen, REMILL_LIFT=<path>/remill-lift exportieren
# Souper (optionaler MBA-Superoptimizer): nur extern, dessen `souper`-CLI
#   bei Bedarf an scripts/triton_handlers.py-Ausgabe anbinden; nicht mitgeliefert.

Dockerfile reproduziert die vollständige Umgebung. CI führt cargo build/test --release aus (Standard-Features, kein LLVM-Link, keine kommerziellen Fixtures; sample-gated Tests werden übersprungen, tests/smoke.rs läuft immer). Der optionale --features llvm- Link-Check läuft als nicht-blockierender CI-Job (benötigt LLVM 22).

Umgebung

Var	Standard	Bedeutung
DATA_DIR	./data	alle Tool-Artefakte
WATCH_FILE	$DATA_DIR/watch.txt	Fetch-VAs zum Beobachten
CARDS	open_cards3.json	Remill-Card-Cache-Datei
BIN_PATH	Ziel-Binärpfad (Tools-Standard: ./target.exe-Platzhalter)	Ziel-Binärdatei
IAT_JSON	—	{api_name: iat_va}-Import-Stub-Map
VMP_TEST_BIN / VMP_ORACLE	tests/fixtures/…	lizenzierte Sample-Tests
REMILL_LIFT	remill-lift-22 im PATH	Remill-Lift-Binärdatei
DEVIRT / FORCE_EDGE / REPO_ROOT	./target/… / .	skript-aufgerufene Binärdateien + Repo-Root
VMP_WORK_DIR	System-Temp	Lift-Scratch
EFLAGS / IN_RET / DLL_MAIN	—	Snapshot-State-Varianten

Methode (3.x, der bewährte Pfad)

1. Snapshot der Binärdatei von ihrem Entry in Unicorn (Sections + Scratch, Zero-Page-ret, Import-Stubs, IN-Hook).
2. Fetch-Sites erkennen (ausgeführte movzx byte [reg]-Beats statische Muster — rein statische Treffer maßen 0 % Ausführung auf gehärteten Zielen).
3. Per-Site-Cryptors aus dem Code minen (branch-following Worklist).
4. Raw^Key mit dem architektonischen Key-Register dekodieren (freie Sweeps überfitten — auf den geminten Key beschränken).
5. Erreichte Handler via Remill liften, opt -O3, Cards/Dataflow emittieren, mit llc neu kompilieren (ld -r beweist Komponierbarkeit).

Lizenz

MIT (siehe LICENSE) mit Abhängigkeitshinweisen (insbesondere Unicorn GPL-2.0). Nur für Forschungs-/Bildungszwecke, auf Binärdateien, die Ihnen gehören oder die Sie analysieren dürfen.