vmp-devirt

Recherche sur la dévirtualisation de VMProtect assistée par trace : front-ends de version (1.x gate / 2.x table / 3.x FDJ) alimentant un backend partagé (lift Remill → opt LLVM → cartes sémantiques → dataflow → objets natifs).

Validé contre des binaires VMP 3.9.4 auto-compilés dans plusieurs modes de protection. La compatibilité VMP 3.8.x/3.10.x est expérimentale et dépend de l'échantillon.

Périmètre et limitations (à lire en premier)

Ceci est une plateforme de recherche pour analyser des binaires protégés par VMProtect que vous possédez ou êtes autorisé à rétro-ingénierer — pas un dévirtualiseur universel et automatique :

• VMP 3.7+ nécessite une exécution : les flux de fetch, les clés et les cibles de handlers proviennent de snapshots Unicorn instrumentés, pas d'analyse statique.
• La couverture est liée à la trace : seuls les chemins exécutés sont récupérés. Les exécutions multi-états + la fusion de branches l'étendent ; la récupération complète du CFG du programme pour des cibles complexes reste manuelle.
• L'anti-émulation (gates temporels, pièges d'E/S, vérifications d'environnement) nécessite des stubs par cible — le harnais fournit le mécanisme, vous fournissez les valeurs.
• Les front-ends VMP 1.x/2.x sont des scanners heuristiques ; leurs anciens walkers statiques sont conservés comme oracles de recoupement, pas comme chemins primaires.

Arborescence

src/
  lib.rs               crate root, data_dir()
  pe_loader.rs         PE parsing / VA reads
  opcode_map.rs        canonical 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 helpers
    cryptor_miner.rs   per-site ValueCryptor mining (branch-following)
    site_emulator.rs   sample-specific oracle decoders (legacy)
    handler_classifier.rs  handler classification via legacy patterns
    classifier_legacy.rs   first-bytes patterns (weak; fallback only)
    v1_gate.rs         VMP 1.x gate-scan front-end
    v2_walker.rs       VMP 2.x dispatch-table front-end
    v3_fdj.rs          VMP 3.x FDJ front-end
  backend/
    value_cryptor.rs   ADD/SUB/XOR/ROL/ROR/NOT/NEG/... chains
    lifter.rs          iced-x86 text lift + Remill subprocess backend
    llvm_pipeline.rs   opt -O3 over Remill IR (real passes)
  harness/
    snapshot.rs        Unicorn snapshots: sections+scratch mapping,
                       IN hooks, import stubs, watch hits, memlog,
                       zero-slide fast-forward
tests/
  smoke.rs             synthetic PE64 + hand-built fetch chain (no fixtures)
tools/                 (analysis drivers; each documents its inputs)
scripts/               Triton/angr/Ghidra helpers (external deps)

Compilation

# Debian/Ubuntu (LLVM 22 for optional llvm feature)
sudo apt install llvm-22-dev libclang-22-dev clang-22
cargo build --release          # pure Rust (no LLVM link)
cargo build --release --features llvm   # llvm-sys link check
pip install triton-library capstone pefile   # python helpers
# Remill (optional lifter backend): build upstream, export REMILL_LIFT=<path>/remill-lift
# Souper (optional MBA superoptimizer): external only, wire its `souper` CLI
#   to scripts/triton_handlers.py output if desired; not vendored.

Le Dockerfile reproduit l'environnement complet. La CI exécute cargo build/test --release (fonctionnalités par défaut, pas de lien LLVM, pas de fixtures commerciales ; les tests conditionnés par échantillon sont ignorés, tests/smoke.rs s'exécute toujours). La vérification de lien optionnelle --features llvm s'exécute comme job CI non bloquant (nécessite LLVM 22).

Environnement

Var	Défaut	Signification
DATA_DIR	./data	tous les artefacts de l'outil
WATCH_FILE	$DATA_DIR/watch.txt	VAs de fetch à surveiller
CARDS	open_cards3.json	fichier de cache des cartes Remill
BIN_PATH	chemin du binaire cible (défaut des outils : placeholder ./target.exe)	binaire cible
IAT_JSON	—	map de stubs d'import {api_name: iat_va}
VMP_TEST_BIN / VMP_ORACLE	tests/fixtures/…	tests sur échantillons sous licence
REMILL_LIFT	remill-lift-22 dans le PATH	binaire de lift Remill
DEVIRT / FORCE_EDGE / REPO_ROOT	./target/… / .	binaires appelés par les scripts + racine du dépôt
VMP_WORK_DIR	temp système	répertoire de travail du lift
EFLAGS / IN_RET / DLL_MAIN	—	variantes d'état du snapshot

Méthode (3.x, le chemin éprouvé)

1. Prendre un snapshot du binaire depuis son entrée dans Unicorn (sections + scratch, ret en page zéro, stubs d'import, hook IN).
2. Détecter les sites de fetch (les movzx byte [reg] exécutés surpassent les motifs statiques — les correspondances purement statiques ont mesuré 0 % d'exécution sur des cibles durcies).
3. Miner les cryptors par site depuis le code (worklist avec suivi de branches).
4. Décoder raw^key avec le registre de clé architectural (les balayages libres surajustent — contraindre à la clé minée).
5. Lifter les handlers atteints via Remill, opt -O3, émettre cartes/dataflow, recompiler avec llc (ld -r prouve la composabilité).

Licence

MIT (voir LICENSE) avec notes sur les dépendances (notamment Unicorn GPL-2.0). Usage recherche/éducatif uniquement, sur des binaires que vous possédez ou pouvez analyser.