vmp-devirt

Ricerca sulla devirtualizzazione di VMProtect assistita da trace: front-end per versione (gate 1.x / tabella 2.x / FDJ 3.x) che alimentano un unico backend condiviso (lift Remill → ottimizzazione LLVM → schede semantiche → dataflow → oggetti nativi).

Validato su binari VMP 3.9.4 compilati autonomamente attraverso molteplici modalità di protezione. La compatibilità con VMP 3.8.x/3.10.x è sperimentale e dipende dal campione.

Ambito e limitazioni (leggere per primi)

Questa è una piattaforma di ricerca per analizzare binari protetti con VMProtect di cui siete proprietari o per cui siete autorizzati al reverse engineering — non un devirtualizzatore universale a prova di pulsante:

• VMP 3.7+ richiede esecuzione: stream di fetch, chiavi e target degli handler provengono da snapshot Unicorn strumentati, non da analisi statica.
• La copertura è legata alla trace: vengono recuperati solo i percorsi eseguiti. Esecuzioni multi-stato + merging dei branch la estendono; il recupero completo del CFG per target complessi rimane manuale.
• L'anti-emulazione (gate temporali, trap di I/O, controlli sull'ambiente) richiede stub specifici per target — l'harness fornisce il meccanismo, voi fornite i valori.
• I front-end VMP 1.x/2.x sono scanner euristici; i loro vecchi walker statici sono mantenuti come oracoli di verifica incrociata, non come percorsi primari.

Struttura

src/
  lib.rs               crate root, data_dir()
  pe_loader.rs         PE parsing / VA reads
  opcode_map.rs        legacy handler-type labels (oracle only, see module docs)
  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)

Compilazione

# 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.

Dockerfile riproduce l'ambiente completo. La CI esegue cargo build/test --release (feature predefinite, nessun link LLVM, nessun fixture commerciale; i test con campioni protetti vengono saltati, tests/smoke.rs viene sempre eseguito). Il controllo opzionale del link --features llvm viene eseguito come job CI non bloccante (richiede LLVM 22).

Ambiente

Var	Predefinito	Significato
DATA_DIR	./data	tutti gli artefatti degli strumenti
WATCH_FILE	$DATA_DIR/watch.txt	VA da recuperare da monitorare
CARDS	open_cards3.json	file di cache delle card Remill
BIN_PATH	percorso del binario target (predefinito degli strumenti: segnaposto ./target.exe)	binario target
IAT_JSON	—	mappa degli stub di import {api_name: iat_va}
VMP_TEST_BIN / VMP_ORACLE	tests/fixtures/…	test su campioni con licenza
REMILL_LIFT	remill-lift-22 nel PATH	binario di lifting Remill
DEVIRT / FORCE_EDGE / REPO_ROOT	./target/… / .	binari richiamati dagli script + radice del repository
VMP_WORK_DIR	temp di sistema	area di lavoro per il lifting
EFLAGS / IN_RET / DLL_MAIN	—	varianti dello stato dello snapshot

Metodo (3.x, il percorso collaudato)

1. Cattura uno snapshot del binario dal suo entry point in Unicorn (sezioni + scratch, ret su pagina azzerata, stub di import, hook IN).
2. Rileva i siti di fetch tramite esecuzione, non tramite la forma dell'opcode: osserva quale reg alimenta un caricamento di byte eseguito, qualunque sia il suo mnemonico. I pattern statici movzx sono solo il seme di fallback — i riscontri solo statici hanno misurato lo 0% di esecuzione su target rafforzati. Copertura delle forme di fetch: movzx ✓, movsx ✓ (SMC alterna tra loro a metà esecuzione; il miner accetta entrambi), fetch con gate AND/co-byte ✓ tramite cattura live. Bias misurato (3.9.4, back-slice ancorate al dispatch di devirt fetch vs scansione statica rigorosa): popolazioni disgiunte — il sensore ha trovato 8 siti di byte a forma di fetch che il gate pattern+mov-imm32 non aveva mai proposto (forme indicizzate/scalate come movzx edx,[r9+riz-1]), 1 ha estratto una catena verificata (Rol→Inc→Xor52→Ror, chiave r10l); il resto sono caricamenti in contesto VM che il miner rifiuta correttamente. Altre forme (es. operazioni su stringhe): porta i byte, ottieni un caso per il miner — apri una issue con i byte dell'opcode attorno al fetch. Il fetch vincolato al pattern è un non-metodo documentato in questo contesto.
3. Estrai i cryptor per sito dal codice (worklist che segue i rami).
4. Decodifica raw^key con il registro chiave architetturale (sweep liberi causano overfitting — vincola alla chiave estratta).
5. Esegui il lifting degli handler raggiunti tramite Remill, opt -O3, emetti card/dataflow, ricompila con llc (ld -r dimostra la componibilità).

Lavori correlati (cosa è preso in prestito, cosa è diverso)

• VTIL (Can Bölük, BSD-3): regole di semplificazione guidate da tabelle portate come sottoinsieme lineare in synth (simplify_chain, attribuito nel codice). Abbiamo mantenuto Remill+LLVM come lifter; nessuno scambio di IR.
• Pushan (deoffuscamento VM senza trace, validato su 3.5.0): la nostra architettura di cattura live risponde all'SMC che le loro regioni statiche presuppongono assente. Preso in prestito: il ragionamento sull'identificazione del VPC, i passaggi di semplificazione in stile S2/S3.
• SATURN (pipeline Remill+LLVM+Souper): il nostro backend segue la stessa forma; abbiamo portato le idee di constant-pool e stack-brightening come devirt brighten (il pool non si attiva su 3.9 — documentato).
• MBA-Blast (Liu et al., USENIX '21): Table-2 + Algorithm-1 portati come backend/mba.rs (derivati dal paper, nessun codice vendorizzato).
• Tigress (Collberg, Arizona): seconda famiglia di target, non una dipendenza. Accademico/gratuito, il nostro gruppo di controllo cross-protector.

Licenza

MIT (vedi LICENSE) con note sulle dipendenze (in particolare Unicorn GPL-2.0). Solo per uso di ricerca/educativo, su binari di cui sei proprietario o che puoi analizzare.

Realizzato con l'assistenza dell'IA (design, codice, documentazione — diretti dall'uomo, verificati dalla macchina: ogni numero in docs/coverage.md è riproducibile dai comandi ad esso affiancati).