Feature: method virtualization (VM-based protection)

[mcpolo99]

Summary

Add method virtualization — translate selected methods' CIL into a custom bytecode executed by an embedded interpreter (VM), so the original IL never exists in the output assembly. This is the strongest form of .NET code protection and the natural high-end complement to our existing protections.

It also fills the conceptual gap left by removing the broken JIT anti-tamper mode (#110): where JIT tried (and failed, see #22) to keep method bodies hidden via a fragile native JIT hook, virtualization achieves the same goal — original code never materializes — in pure managed code, cross-runtime, with no native hooking.

Motivation

• Strongest protection tier. Unlike encrypt-at-rest anti-tamper (which decrypts full method bodies into memory at load), a virtualized method's original IL is gone: a decompiler sees only the VM interpreter loop plus opaque bytecode. No public spec, no decompiler support.
• Replaces the JIT concept properly. The JIT hook was removed because it is unmaintainable on modern .NET (version-locked JIT-EE interface, tiered compilation, ReadyToRun, NativeAOT) and never actually hid bodies (JIT AntiTamper does not actually hide method bodies (upstream #102) #22). A managed VM sidesteps all of that.
• Synergy with the identity work (Unique Obfuscation Identity System — per-build and per-project fingerprint elimination #69). The VM's opcode↔handler mapping can be randomized per build, so every protected assembly ships a different VM. That is the same per-build-uniqueness principle as the Level-2 constant randomization, applied to the whole instruction set — extremely hostile to generic devirtualizers.

Prior art

• KoiVM — the open-source ConfuserEx virtualization plugin (originally by Sq/"Koi", later open-sourced; many forks: DarksVM, TheProxyRE/KoiVM, oddmario/KoiVM). It is the direct precedent: a register-based VM (R0–Rn + stack + flags, which resists devirtualization better than a stack VM), shipped as a ConfuserEx plugin — a translator (CIL → "Koi" bytecode stream) plus an injected runtime interpreter (RT), with a method's body replaced by a call into the VM entry with a pointer into the stream.
  • Known limits we would inherit/design around: no calli/jmp (and a few others), open generics are hard, ref-structs (Span<T>) conflict with the VM stack model, a documented memory-leak risk on heavily-looped virtualized methods, large performance penalty (→ selective use), and original support limited to .NET Framework + CoreCLR on Windows — not validated on .NET 5–10.
• Commercial references for scope/behavior: Eazfuscator.NET, .NET Reactor, ByteHide — all offer selective code virtualization with the same tradeoffs.

Proposed architecture (this fork)

1. Translator (a new protection phase): lift each targeted method's CIL to a register-based IR, then emit our bytecode. Operands (tokens, constants) encoded/encrypted.
2. Runtime interpreter (injected stub, must run net20 → net10): a dispatch loop over the bytecode with handlers for each virtual opcode; bridges back to the CLR for call/newobj/field access via metadata tokens.
3. Per-method opt-in: given the perf cost, virtualization is applied only to methods the user selects (rule/attribute), like every other protection here.
4. Per-build VM randomization (hardening): shuffle the opcode↔handler map and encode constants per build (ties into Unique Obfuscation Identity System — per-build and per-project fingerprint elimination #69).

Cross-framework & hard problems (must be scoped honestly)

Area	Concern
Runtimes	The interpreter is pure managed, so it can target net20 → net10 — but it must avoid APIs missing on old TFMs and must be tested on each.
NativeAOT / trimming / single-file	A token-driven VM relies on metadata/reflection-ish bridging; will not work under full AOT/trimming. Document as unsupported.
Exception handling	Mapping try/catch/finally/filter regions into the VM is the single hardest part (EH metadata, unwinding, rethrow). Likely phase 2.
Generics	Open generic methods can't be virtualized cleanly; closed instantiations are OK.
ref structs	Span<T>/ref locals conflict with a boxed VM stack model — exclude.
Unsupported opcodes	calli, jmp, arglist, tail calls, etc. — fall back to leaving those methods un-virtualized.
Perf / memory	Interpretation overhead + KoiVM's known leak pattern → selective use + careful handler lifetime.
Debuggability	Stack traces/PDBs across the VM boundary (KoiVM exposes stackwalk/dbgInfo toggles for this).

Suggested phased plan

• Phase 0 — decision: modernize/vendor an open-source KoiVM (ConfuserEx-native, big head start, but old and messy) vs. build a fresh register VM against our dnlib/runtime stack. Prototype devirtualization resistance + perf on a sample.
• Phase 1 — core: virtualize straight-line + branching + arithmetic + call/field/ldstr for non-generic, EH-free methods, net48 + one modern TFM. Round-trip test (virtualize → run → assert).
• Phase 2 — coverage: exception handling, closed generics, more opcodes; broaden TFM matrix.
• Phase 3 — hardening: per-build opcode randomization, constant encryption, anti-devirt tricks (opaque predicates, handler duplication).

Non-goals / risks

• Not a substitute for the working normal/anti anti-tamper — it's an additional, heavier tier.
• Large, ongoing subsystem; real performance cost; AOT-incompatible. Worth it as a headline capability, but should land incrementally behind opt-in.

Acceptance for an MVP (Phase 1)

• A method marked for virtualization has no original CIL in the output, runs correctly on net48 + a modern TFM, and survives a round-trip integration test. de4dot/decompilers show only the interpreter + bytecode.

Related: #110 (removed the broken JIT mode this supersedes), #22 (why the JIT approach failed), #69 (per-build uniqueness the VM randomization would extend).

[mcpolo99]

https://github.com/Washi1337/OldRod

[mcpolo99]

Research: building a devirtualization-resistant VM

Research on how to build this well — every aspect with ups/downs — with the central goal of making the VM far harder to reverse than KoiVM, which the public OldRod devirtualizer fully undoes.

0. The lesson from OldRod (why KoiVM is reversible)

OldRod devirtualizes vanilla KoiVM automatically because KoiVM is a fixed, public VM: the same ~119-constant instruction set, the same register machine, the same handler table and virtual-program-counter (VPC) logic in every build. A devirtualizer author reverse-engineers that VM once, hardcodes the opcode to semantics mapping, then lifts any KoiVM'd assembly.

The takeaway that should drive our whole design: a fixed, known VM is the vulnerability. Everything below is really about denying an analyst that fixed target.

1. Starting point — adopt vs build (ups/downs)

Option	Ups	Downs
Modernize KoiVM / neo-ConfuserEx	Real, ConfuserEx-native reference; register VM already designed; integration patterns exist	Built against old yck1509 ConfuserEx + old dnlib (ours is mkaring-based, net10); RT never validated on .NET 5-10; it is exactly what OldRod defeats, so we must diverge heavily anyway
Build a fresh register VM (KoiVM only as reference)	No legacy API/dnlib debt; no public devirtualizer targets it; per-build uniqueness designed in from day one; native fit with our stack	More upfront design; must get CIL lifting + RT correctness right ourselves

References to study (not drop in): yck1509/KoiVM, XenocodeRCE/neo-ConfuserEx, chainski/neo-ConfuserEx (selective KoiVM). All are older, none net10-ready, all OldRod-reversible.

2. How automated devirtualizers actually work (what we must defeat)

Modern generic devirtualization (OldRod, VMPredator, Triton/VMProtect-devirt, Thalium's LLVM devirt, Syntia/QSynth) follows a pipeline:

1. Identify the dispatch loop and handlers; recover the opcode-to-handler correspondence.
2. Symbolically execute / taint each handler to extract its semantics as expressions (pre/post state).
3. Program-synthesise the simplified expression for each handler (beats naive MBA and arithmetic obfuscation).
4. Lift recovered semantics to an IR (often LLVM), run compiler optimizations to simplify, then re-emit clean code.

Every resistance technique below targets one of these steps — mostly steps 1 and 3, the correspondence recovery and the synthesis.

3. Resistance techniques (the core — each with ups/downs)

Technique	What it denies the attacker	Downside / cost
Per-build randomized instruction set + handler codegen	The single biggest lever. "Scarce reuse of deobfuscation knowledge" — a devirtualizer cannot be pre-built because opcodes, encodings and handlers differ every build. Directly removes KoiVM's fatal fixed-VM property.	Requires a generator (handlers from templates), and per-build test/verification
Handler diversification / polymorphism	Multiple semantically-equivalent handler variants + randomized register/operand assignment break the 1:1 opcode-to-handler correspondence devirt relies on	Bigger output; handler-equivalence must be provably correct
Opaque predicates + bogus control flow inside handlers	Path explosion for symbolic execution; frustrates trace analysis	Perf; weak/known predicates get pattern-matched, so they must be varied
Obfuscated VPC updates + non-switch dispatch (direct-threaded / interleaved / call-threaded)	Removes the clean dispatch table and obvious PC arithmetic that lifters key on	Harder to implement correctly; some perf
Dynamic bytecode scheduling / multi-VM (DSVMP)	Non-determinism + multiple cooperating VMs, so no single static bytecode stream to recover	Complexity; careful state management
MBA (mixed boolean-arithmetic) on handler semantics	Obscures arithmetic/logic semantics	Naive MBA is beaten by program synthesis (Syntia/QSynth). Only formally-verified, high-complexity expressions (LOKI-style) meaningfully resist — and even LOKI only reduces synthesis success, not to zero
Nested virtualization (VM-in-VM)	Compounds analysis cost multiplicatively	Significant perf/size; correctness risk
Context/key-derived handler semantics	Handler behavior depends on runtime keys/state, hiding static semantics (point-function style)	Complexity; must not break determinism of results
Anti-emulation / anti-symbolic-execution (self-checks, environment/timing sensitivity)	Raises cost of the dynamic analysis step	Fragile across runtimes; risk of false positives

Design synthesis: the strongest, most tractable combination is per-build-unique ISA + diversified handlers + obfuscated non-switch dispatch + opaque predicates, layering DSVMP / nested-VM / verified-MBA selectively where the perf budget allows.

4. VM architecture choices (ups/downs)

• Register-based (KoiVM): harder to lift than a stack VM, closer to real hardware — but OldRod still lifted it; the win comes from irregularity + per-build change, not register-vs-stack alone.
• Stack-based: simpler CIL mapping (CIL is stack-based) — but a clean stack VM is the easiest to lift.
• Irregular hybrid + state-dependent instruction decoding: hardest to model generically — most complex to build and verify.
• Dispatch: switch (easy, easiest to recover) then direct-threaded then interleaved/call-threaded (progressively harder to recover, progressively harder to implement).

5. Hard .NET subsystems (all aspects)

• Exception handling — the hardest part: mapping try/catch/finally/filter and unwinding across the VM boundary. Research-grade (see XuanJia's ABI-compliant EH shadowing, which hides EH metadata behind VM dispatch). Likely a later phase.
• Generics — closed instantiations feasible; open generics generally excluded.
• ref struct/Span<T>, calli, jmp, arglist, tail calls — conflict with a boxed VM stack model / unsupported; affected methods fall back to un-virtualized.
• Token & metadata bridging — call/newobj/ldfld/box must resolve real members at runtime; must cooperate with the renamer / constants / control-flow ordering.
• GC / value types on the VM stack — boxing strategy must stay GC-safe and type-correct.

6. Cross-framework / runtime-model aspects

• A pure-managed interpreter can target net20 to net10, x86/x64, Framework + CoreCLR — but must avoid APIs missing on old TFMs and be tested per TFM.
• NativeAOT / aggressive trimming / single-file+trim: a token-driven VM needs runtime metadata resolution that AOT/trimming strip, so it is not supported; must be enforced by the per-framework capability-gating (tracked separately in the intake).

7. The honest ceiling — what "un-reversible" can and cannot mean

This must be stated plainly: VM obfuscation is not provably unbreakable, and "impossible to reverse" is not an achievable goal. The literature is an arms race — symbolic execution + program synthesis + compiler-based lifting have devirtualized even commercial VMs (VMProtect, Themida) for pure functions; the strongest research defense (LOKI) is "resilient against all known automated attacks," yet still only reduces synthesis success (to ~19%), not to zero. Manual RE always remains possible given enough effort.

So the realistic, worth-pursuing goal is two-fold:

1. Kill generic / automated devirtualization (the OldRod class) outright — achievable by not being a fixed, public VM: a per-build-unique instruction set, diversified handlers, and non-regular dispatch mean no reusable devirtualizer can exist for our output.
2. Make manual reverse engineering extremely costly — via the layered resistance techniques above.

That is a dramatically stronger position than KoiVM, and it is honestly the ceiling any VM protection can claim.

8. Our natural advantage

This fork already ships the exact infrastructure KoiVM lacked and OldRod exploited the absence of: seeded per-build randomization (RandomGenerator) and per-build mutation-key injection (the #69 constant-randomization work). Extending that philosophy from constants to a whole per-build-unique instruction set and handler set is the single biggest, most natural lever we have toward point (1) above — and it is precisely what a fixed VM like KoiVM could never do.

---

Sources

• KoiVM: yck1509/KoiVM; TheProxyRE/KoiVM; neo-ConfuserEx (XenocodeRCE, chainski)
• Devirtualization: OldRod (KoiVM), VMPredator, JonathanSalwan/VMProtect-devirtualization (Triton), THALIUM "LLVM-powered devirtualization", Syntia/QSynth (program synthesis)
• Resistance research: "Enhance VM-based code obfuscation through dynamic bytecode scheduling" (DSVMP, Computers & Security 2018); XuanJia (arXiv 2601.10261); LOKI (synthesis-resilient obfuscation); "Symbolic Deobfuscation: From Virtualized Code Back to the Original"; Blazytko, "Writing Disassemblers for VM-based Obfuscators"

[mcpolo99]

Research (cont.): structural metamorphism, native hardening, deception

Follow-on research to the devirt-resistance note above, covering the surrounding ideas and how they fit the VM.

1. Structural metamorphism — change the structure, not just the signature

Re-encrypting a wrapper each time only changes the signature (defeats file-hash AV, nothing more). What actually raises RE cost is genuine structural difference:

Where	Mechanism	Notes
Per build (main lever)	Every obfuscation emits different structure — different VM instruction set + handler layout, different control-flow shape, different constant encoding, different names	Direct extension of the seeded per-build randomization (#69) and the per-build-unique VM above
Per launch (add-on)	Regenerate the VM interpreter / handlers via Reflection.Emit each run, so the dispatch structure differs every execution	JIT runtimes only (not NativeAOT); defeats cross-run correlation and cached analysis

Full runtime re-obfuscation of arbitrary code is impractical (it would mean embedding the whole engine in every app). Regenerating the VM interpreter itself per launch is the tractable form of runtime structural diversity.

2. Native hardening tier — per-RID, not "Windows-only"

Correction to an earlier framing: native code is not Windows-only. What is Windows/x86-x64-only is the specific C++/CLI mixed-mode packaging (one PE with IL+native via IJW). Portable native protection is done differently:

Platform	Native format	Bridge
Linux	ELF .so	P/Invoke or embedded position-independent blob
macOS	Mach-O .dylib	P/Invoke or embedded blob
Windows	PE .dll	P/Invoke, embedded blob, or C++/CLI

The real constraint is that IL is portable; native is per-OS-per-arch: one native payload runs on exactly one RID (win-x64, linux-x64, linux-arm64, osx-arm64, …), whereas one IL blob runs everywhere. So a native VM core / native stubs are viable on every OS — but only for the RIDs we compile for, chosen at obfuscation time and enforced by the per-framework capability-gating (in the intake). A native interpreter is the strongest form of the VM here, because it removes the managed IL that OldRod-class devirtualizers read; the cost is multiplying native codegen per RID and gating per target, with a managed fallback elsewhere (and none of it under NativeAOT/trimming).

3. Runtime self-modification (in-memory) — narrow, native, heavy

Literally mutating executing code at runtime is a native-level technique (the CLR JITs IL and does not allow in-place IL patching). It fights the platform: W^X/DEP page permissions (VirtualProtect/mprotect), mandatory instruction-cache flush on ARM, macOS hardened-runtime restrictions, per-OS-per-arch engines, higher AV/EDR detection, and no NativeAOT support. It is a real but narrow, fragile tier — worth it only for a single-target deployment, never a portable default. The managed approximation is regenerating stubs/handlers via Reflection.Emit (see §1), which sidesteps the OS constraints.

4. On-disk self-repacking — considered, why not

The idea of the app writing a fresh, byte-different copy of itself and swapping its own file on exit:

• It is an anti-signature trick (defeats file-hash AV), not code protection — the inner code is identical every copy, so it adds zero reverse-engineering resistance.
• It behaves exactly like polymorphic-malware droppers: self-copy + reboot-delayed self-replacement + write-to-own-path are high-signal behavioral IOCs, so it trips behavioral AV/EDR (often net-worse than doing nothing), breaks code signing (the rewritten copy is unsigned), and risks bricking the app (permission/lock/write races).

The legitimate goal it reaches for — "every copy is a unique, hard-to-fingerprint binary" — is delivered cleanly at build time by the structural metamorphism in §1, with none of those downsides and with actual RE-cost gains. So on-disk self-repacking is not pursued.

5. Deception layer — split out to #112

Sending reverse engineers into rabbit holes (decoy code, honeypot data, synthesis-resistant opaque predicates) is a legitimate, separable line of work. A source analysis of the current control-flow protection (junk code is invalid-IL and disabled on CLR 4.0+; no decoy methods/honeypots; opaque predicates are reversible arithmetic) and the proposed improvements are tracked in #112. The strongest decoys live inside a per-build-unique VM's dispatched paths (so they survive reachability/dead-code pruning), which is where #112 and this issue reinforce each other.

Honest ceiling (unchanged)

None of the above makes RE impossible. The realistic, worth-pursuing goal remains: kill generic/automated devirtualization by being per-build-unique and irregular, put the sensitive core in native where the target allows, and make manual RE expensive and demoralizing.