details left ambiguous to prevent pre-analysis
Architecture · Mode 1 of 3

Self-Contained
Binary Protection

Every protection mechanism lives inside the binary itself. No servers, no drivers, no network access. One annotation at compile time and the function is replaced by an encrypted virtual machine that is unique to every build.

01

Anatomy of a Protected Binary

Protection is layered from the outside in. Each layer must be penetrated before the next becomes visible. No single layer can be removed without destroying the others.

Protected Binary
The executable contains standard code alongside protected regions. The PE structure can be disguised to resemble output from other commercial protectors.
Encrypted Handler Section
The VM interpreter and all handler functions reside in an encrypted section. Pages are decrypted on-demand at runtime via exception handling. Static disassembly sees only ciphertext.
VM Interpreter + Dispatch
Handlers are directly threaded: each handler resolves and jumps to the next without returning to a central loop. The routing table is encrypted, self-mutating, and unique to each build.
Encrypted Bytecode
0A 3F 91 D7 02 E8 4C 1B A0 55 7E C3 68 B4 09 F6
Each layer is cryptographically dependent on the layers above it. Modifying any layer corrupts all inner layers.
02

Attack Surface

Every realistic attack vector against a standalone-protected binary, and why each one fails or is severely degraded.

Static Disassembly
Attacker opens the binary in IDA Pro or Ghidra and attempts to disassemble the protected region.
Blocked
The VM handler section is fully encrypted. Disassemblers see only ciphertext. Even after decrypting the section, the bytecode uses a custom ISA unique to this build. No public processor module can parse it.
Memory Dump at Runtime
Attacker dumps process memory while the protected function is executing.
Degraded
All intermediate values are encrypted in the virtual register file. Bytecode is decrypted instruction-by-instruction and never fully materialized. The dump contains encrypted fragments with no structural context.
Symbolic Execution
Attacker runs the binary through a symbolic engine (angr, Triton).
Blocked
Pre-virtualization deception primitives inject path explosions and unsolvable constraints. The symbolic engine either times out or explores an exponential number of infeasible paths.
Handler Pattern Matching
Attacker identifies and catalogs VM handler semantics to build a lifter.
Degraded
Multiple structurally-distinct variants exist for each operation. Phantom handlers that are never legitimately reached pollute the analysis. The dispatch table is encrypted and self-mutating.
Bytecode Patching
Attacker modifies the encrypted bytecode to skip a conditional check.
Blocked
Bytecode decryption keys are derived from execution path history. Altering any byte corrupts the decryption stream for all subsequent instructions. Integrity chaining detects the modification silently and cascades wrong results.
Cross-Function Patching
Attacker patches one function while leaving others intact.
Blocked
Protected functions share persistent cryptographic state. Modifying one function's bytecode corrupts a shared accumulator, causing silent failures in all entangled functions.
03

Build Polymorphism

Every compilation produces a structurally unique binary. Two builds of the same source code share nothing at the binary level.

Aspect Build A Build B
Opcode Mapping LOAD → 0x0A, ADD → 0x17 LOAD → 0x1F, ADD → 0x04
Bytecode Format Big-endian, header-swapped Little-endian, interleaved
Handler Layout Variant 2, 3, 1, 4 Variant 4, 1, 3, 2
Dispatch Table 145 entries, seed 0xC4F1 145 entries, seed 0x7B2E
Section Key per-page, derived from seed A per-page, derived from seed B
Data Segment Offsets scrambled, mask 0xA5 Offsets scrambled, mask 0x3C
Same source code. Same annotation. Entirely different binary structure.
04

Compilation Pipeline

Annotated functions pass through six stages that transform source code into an encrypted, self-interpreting binary. Each stage is seeded by a cryptographic PRNG, producing a unique result on every build.

01
Source Code
Developer annotates functions for protection
›
02
LLVM IR
Compiler frontend emits language-independent representation
›
03
Anti-Symbolic
Injects deception primitives that poison automated analysis
›
04
Virtualization
Translates IR to encrypted custom bytecode with embedded interpreter
›
05
Diversification
Generates unique handler variants, phantom decoys, and encrypted routing tables
›
06
Section Encrypt
Encrypts the handler section with per-page derived keys
05

Execution Architecture

When a protected function is called, the VM takes over. The following diagram traces the execution path through the direct-threaded handler chain, showing how encryption and integrity verification are woven into every step.

Initialization
Section Decryption
On first access, the CPU triggers a page fault. An exception handler decrypts the faulting code page using a per-page derived key, then resumes execution transparently.
Root Key Derivation
A per-function seed initializes the cryptographic PRNG that generates all encryption keys, dispatch permutations, and integrity parameters for this function.
unique per function, per build
Execution
each basic block
Block Seed Derivation
The execution path history and block index are hashed together to produce a unique seed. This seed determines the decryption stream for all instructions in this block.
path-dependent
each instruction
Bytecode Decryption
The PRNG stream decrypts the next opcode and its operands. Each byte consumed advances the stream state, coupling decryption order to execution order.
Dispatch Routing
The decrypted opcode is resolved through an encrypted, self-mutating routing table. Table entries are individually encrypted and positions shuffle on every dispatch. Each handler directly transfers to the next without returning to a central loop.
direct-threaded, self-mutating
Handler Execution
The selected handler variant performs the operation. Inputs are decrypted from the virtual register file, the computation executes, and the result is re-encrypted before storage.
Integrity Update
The execution path hash, operation MAC, and bytecode state are updated. These values are load-bearing: they feed into future decryption keys and dispatch decisions.
feeds into next seed
Block Transition Verification
A chained MAC over the entire block is verified against the expected value. This proves the block was reached via a legitimate execution path and that no instructions were skipped or replayed.
Return
Function Return
The result is decrypted from the virtual register file and returned to the caller. All ephemeral VM state is discarded. The next invocation re-derives everything from the root seed.
Entanglement
Cross-Function State Update
The execution's cryptographic fingerprint is folded into a persistent accumulator shared across all protected functions. Future function invocations inherit this state, binding their decryption keys to the collective execution history of every protected function that ran before them.
feeds into next function's root derivation
06

Value Lifecycle

How a single data value moves through the VM. Values exist in plaintext only during handler execution. At every other stage, they are encrypted with keys that rotate per basic block.

Load from Memory
Value read from guest memory through the encrypted data segment. The offset is obfuscated by a per-function mask to prevent direct addressing of virtual registers.
Domain Decrypt
Value decrypted from storage domain using a per-instruction Feistel key derived from the one-way ratchet state. A taint-breaking operation injects hardware entropy to sever symbolic dependency chains.
Handler Computation
The operation executes on the plaintext value. This is the only moment the value exists unencrypted. The result is produced in a CPU register, never written to memory in the clear.
Domain Re-Encrypt
Result immediately re-encrypted with the current instruction's Feistel key before storage. The key rotates every dispatch via the one-way ratchet, so input and output ciphertexts are unrelated even for the identity operation.
Integrity Accumulate
The operation hash, value hash, and path hash are updated. These feed future decryption keys and dispatch decisions. Skipping or reordering any step corrupts all downstream state.
Store to Segment
Encrypted result written to the data segment at an obfuscated offset. A chained MAC over the segment is updated, binding this store to the entire execution history of the current block.
07

Protection Layers

Nine independent protection mechanisms operate simultaneously. Each layer independently raises the cost of analysis. Defeating one does not weaken the others.

Code Virtualization
Native instructions are translated into a custom bytecode ISA executed by an embedded interpreter. The ISA is unique to each build. Standard disassemblers and decompilers produce no meaningful output.
Compile-time Full ISA coverage
Bytecode Encryption
Each basic block is encrypted with a unique key derived from execution path history. Bytecode is decrypted instruction-by-instruction during execution. Memory dumps reveal no plaintext patterns.
Per-block keys Path-dependent
Anti-Symbolic Execution
Deception primitives are injected before virtualization: mixed boolean-arithmetic expressions, opaque predicates with high symbolic complexity, and hash-dependent control flow that resists automated constraint solving.
Pre-virtualization Anti-SMT
Handler Diversification
Multiple structurally-distinct implementations exist for each operation. Handlers are direct-threaded: each resolves and jumps to the next without a central dispatch point. Phantom handlers that are never legitimately reached fill the routing table alongside real variants, defeating pattern-matching attacks.
Direct-threaded Phantom decoys
Value Domain Encryption
All intermediate values in the virtual register file are encrypted at rest. Encryption keys rotate on every instruction dispatch via a one-way ratchet, giving each instruction a unique bijection. Format-preserving transforms and taint-breaking operations prevent symbolic tracking.
In-memory Per-instruction rotation
Integrity Chaining
Execution path, operation history, and bytecode state are continuously hashed into load-bearing cryptographic values. These values feed directly into future decryption keys. Any deviation silently corrupts all subsequent computation.
Chained MAC Load-bearing
Section Encryption
The entire VM interpreter is stored in an encrypted section of the executable. Code pages are decrypted on-demand via exception handling when first accessed. Static analysis tools see only ciphertext.
Per-page keys On-demand
Anti-Tamper
Tampering does not produce error messages. Instead, cryptographic state silently diverges, causing progressively incorrect results. The exact point of detection is ambiguous, making reverse engineering a process of chasing cascading failures.
Silent corruption Cascading
Binary Impersonation
The protected binary's PE structure can be reshaped to match the forensic signatures of other commercial protectors. Rich headers, debug directories, import tables, section entropy, and embedded dispatch patterns are all synthesized to match a target profile. Automated classifiers misidentify the protection technology, directing analysts toward the wrong toolchain.
Post-link 10+ profiles Anti-forensic
08

Security Properties

The combination of virtualization, encryption, and integrity chaining produces the following guarantees without any external dependencies.

✓ No External Dependencies
Protection is entirely self-contained. No servers, drivers, network access, or runtime libraries are required. The binary runs anywhere the target platform runs.
✓ Polymorphic Builds
Every compilation produces a cryptographically unique binary. No two builds share the same bytecode format, encryption scheme, or dispatch layout.
✓ Unfingerprintable
Protected binaries contain no strings, constants, or byte patterns that identify the protection technology. The only observable traits are structural characteristics shared by all VM-based protectors.
✓ Full ISA Coverage
Operating on LLVM IR means every instruction the compiler can generate is captured. No unsupported edge cases. Full C++ exception, SIMD, and atomics support.
✓ Per-Function Isolation
Each protected function receives independent encryption keys, dispatch tables, and integrity parameters. Analyzing one function reveals nothing about another.
✓ Load-Bearing Integrity
Integrity verification is not a removable check. Cryptographic values produced during verification are mathematically required for correct execution of subsequent instructions.
✓ Silent Degradation
Tampering causes silent data corruption rather than obvious crashes. The exact point of detection is ambiguous, making attack iteration slow and expensive.
✓ Anti-Symbolic Resistance
Injected deception primitives defeat SMT solvers and symbolic execution engines. Path explosion and constraint poisoning make automated analysis impractical.
✓ Multi-Language Support
Any language that compiles through LLVM is supported: C, C++, Rust, Zig, Objective-C, Fortran, D, and others. No source-level modifications beyond the annotation.
✓ Defense in Depth
Nine independent protection layers operate simultaneously. Defeating one layer does not weaken the others. Each layer independently raises the cost of analysis.
✓ Cross-Function Entanglement
When multiple functions are protected, they share persistent cryptographic state. Each function's execution feeds entropy into a shared accumulator. Breaking one function's protection corrupts the others.
✓ Key Concealment
The VM's bytecode decryption key can be split into multiple secret shares that are proactively re-shared during execution. The actual key never materializes in memory. Scanners see only meaningless share fragments.
✓ Recursive Nesting
Functions can be virtualized multiple times, creating nested VMs. Each layer has independent encryption keys. An attacker who defeats the outer VM faces an entirely new inner VM.
✓ Thread Safety
All VM state is thread-local. Protected functions are fully reentrant and can execute concurrently across any number of threads without synchronization.
✓ Mode Upgradeability
Standalone protection is the foundation. It can be extended with either Always-Online DRM (server-bound licensing) or Ring-0 Enforcement (hardware-bound kernel driver) without changing application code.