Building a Wasm-in-Wasm Virtualizer (with JIT decrypted paged memory)

TrustSig — Mon, 18 May 2026 17:54:34 +0000

Intro

WebAssembly was built for portability and raw speed. It was definitely not built for keeping secrets. To really protect your code, you have to compile it down to a custom, undocumented bytecode and ship it with a tiny internal interpreter to run it securely.

When you compile C, C++, or Rust to native machine code, the compiler strips away a lot of the code's structure. The final assembly is tied deeply to the physical hardware, making it tough to read. But compiling to WebAssembly generates a binary that keeps a highly structured, strictly typed Abstract Syntax Tree (AST).

Anyone with a normal browser debugger can grab a .wasm file, run it through a standard decompiler like WABT, and understand the code. If your app sends sensitive crypto logic, DRM, game anti-cheat, or validation checks to the client, shipping plain WebAssembly is insecure.

What We Will Be Doing

We're going to build a WebAssembly-in-WebAssembly virtualization engine from scratch. Instead of just dumping a giant wall of code on you, we'll build this system step by step. We'll map out the concepts, sketch the execution flow, trace how memory works, and write the code piece by piece.

The End Result

By the end of this massive guide, you'll have a fully working code virtualization pipeline. Your compiler will take a normal binary, pull out a target function, translate it into a custom instruction set, encrypt it heavily, and inject a tiny virtual machine back into the file to run the function safely — without the browser ever knowing.

Prerequisites

You'll need a few tools and some basic knowledge to follow along with the build phases.

A recent installation of the Rust toolchain is required to compile the interpreter.
The wasm32-unknown-unknown compilation target must be installed via rustup.
The walrus crate should be added to your project dependencies for syntax tree manipulation.
You should have a solid grasp on basic systems programming, bitwise math, and raw memory manipulation.

Chapter 1 — Designing the Virtual Instruction Set Architecture

Before we write any compiler code, we need to define the custom language our virtual machine will read, which is called an Instruction Set Architecture (ISA).

Conceptualizing the Execution Model

Our custom virtual machine will run as a stack machine under the hood.

Standard Wasm is also a stack machine. This means an instruction like add doesn't explicitly say which variables to add. It just assumes the two numbers it needs are sitting right on top of the virtual stack. It pops them off, adds them, and pushes the result back on top.

For example, to compute 5 + 10, the machine executes: PUSH 5, PUSH 10, ADD.

Using this exact same setup guarantees that translating from standard WebAssembly into our custom bytecode stays logically consistent and mathematically safe. However, we will completely randomize the numerical opcodes. If a hacker tries to view our binary payload, they won't see standard Wasm bytes. They'll just see an arbitrary sequence of bytes that only our internal, hidden interpreter understands.

Defining the Virtual Opcodes

We define our allowed machine instructions using a strict Rust enum. This will be the absolute foundation of our virtual processor.

// src/isa.rs

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
#[repr(u8)]
pub enum Opcode {
    Push = 0x01,
    Pop = 0x02,
    Dup = 0x03,
    Swap = 0x04,

    // Arithmetic
    Add = 0x10,
    Sub = 0x11,
    Mul = 0x12,
    DivS = 0x13,

    // Bitwise Logic
    BitAnd = 0x20,
    BitOr = 0x21,
    BitXor = 0x22,

    // Memory and Registers
    LoadReg = 0x30,
    StoreReg = 0x31,

    // Control Flow
    Jmp = 0x50,
    Jz = 0x51,
    Exit = 0xFF,
}

Notice the specific instructions for managing registers (LoadReg and StoreReg). While pure math works beautifully on the stack, complex functions usually need local variables to keep track of state (like loop counters). We need a safe way to hold data outside the volatile stack, so we'll use a static array of virtual registers for that.

Control flow instructions (Jmp and Jz — Jump if Zero) are also essential for handling if-statements and while-loops inside the protected code.

The Dispatch Mapping Layer

We need a rock-solid way to turn a raw u8 byte back into our typed Opcode enum at runtime.

impl Opcode {
    pub fn from_u8(v: u8) -> Option<Self> {
        match v {
            0x01 => Some(Opcode::Push),
            0x10 => Some(Opcode::Add),
            0x20 => Some(Opcode::BitAnd),
            0x30 => Some(Opcode::LoadReg),
            0x50 => Some(Opcode::Jmp),
            0xFF => Some(Opcode::Exit),
            // repetitive match arms omitted for brevity
            _ => None,
        }
    }
}

It might be tempting to just use std::mem::transmute to cast a u8 into an Enum and save some typing, but that's super dangerous in a VM. If a hacker slightly messes with the bytecode, transmute would cause undefined behavior and crash the module instantly. Writing out this explicit match layer guarantees our execution loop only handles opcodes it actually understands.

Chapter 1 Recap

We've mapped out our custom instruction set. By completely decoupling our logic from the standard WebAssembly spec, we've created a setup where normal decompilers are totally useless. In a real-world obfuscation engine, you'd randomly generate the byte assignments inside this from_u8 function on every single build, which instantly ruins signature-based analysis. Next up, let's build the physical memory model to run this instruction set.

Chapter 2 — Architecting the VM State and Memory Model

Our interpreter needs to be completely self-contained, skipping dynamic memory allocators entirely.

Bypassing the Host Allocator

Our custom VM has to allocate all its memory statically at compile time, right inside the Wasm binary's .data segment. This means zero required runtime heap allocations for the Virtual Machine.

Dropping a virtual machine into an already-compiled Wasm module creates a tough memory constraint. The host module already has its own memory allocator (like wee_alloc or malloc) managing the heap.

If we try to bring our own dynamic allocator, we risk overlapping and trashing the host's active memory. Plus, packing a full memory allocator into our VM would make the final binary massive and obvious.

Provisioning Static Execution Arrays

By setting up the stack and registers as raw, contiguous static arrays, we guarantee that booting up the interpreter takes exactly zero clock cycles at runtime.

// interpreter/src/lib.rs

#[inline(always)]
fn abort() -> ! {
    core::arch::wasm32::unreachable();
}

static mut STACK: [i64; 2048] = [0; 2048];
static mut REGS: [i64; 512] = [0; 512];
static mut SP: usize = 0;

The physical memory layout inside the final Wasm module will look roughly like this:

[ Host .data segment ][ VM STACK (2048 × i64) ][ VM REGS (512 × i64) ]

I used 64-bit integers (i64) everywhere so we can comfortably fit standard 32-bit ints, 64-bit ints, and floating-point numbers based on their raw bits.

Using static mut variables in Rust normally requires strict unsafe blocks, because changing global variables across multiple threads causes massive data races. But Wasm currently runs in a strictly single-threaded way by default, and our internal loop is purely synchronous, making this perfectly safe here.

Interfacing with Host Memory APIs

We expose some foreign function interfaces (FFIs) so the host module can pass the right execution arguments and the session key directly into our static arrays.

static mut GLOBAL_SESSION_KEY: u8 = 0;

#[no_mangle]
pub unsafe extern "C" fn vm_set_session_key(key: u32) {
    GLOBAL_SESSION_KEY = key as u8;
}

#[no_mangle]
pub unsafe extern "C" fn vm_set_reg(idx: u32, val: i64) {
    if (idx as usize) < 512 {
        *core::ptr::addr_of_mut!(REGS)
            .cast::<i64>()
            .add(idx as usize) = val;
    }
}

Since our bytecode is going to be heavily encrypted, the VM needs to know the exact decryption key before it runs anything. We can't hardcode this key into the interpreter, since we'll change it on every single build to stop fingerprinting. We need a global state variable for the key, and an exported function (vm_set_session_key) so the host can securely pass it in.

A protected function is pretty useless if it can't handle external arguments. When the host module intercepts a call, it needs to grab the parameters from the browser and push them safely into our VM's registers.

We do this by exporting vm_set_reg. This lets the host populate our register array right before the main loop starts. We use core::ptr::addr_of_mut! because modern Rust prefers explicit raw pointers over creating references to mutable statics.

By manually writing to the register array with raw pointers, we keep strict isolation boundaries. The VM stays totally shielded from the host, working only on the data we explicitly hand it.

Chapter 2 Recap

We've built a super solid, zero-allocation memory model. By relying on static Wasm memory, our engine will run extremely fast while keeping a tiny footprint. With the registers, stack, and APIs ready, it's time to build the actual processor loop.

Chapter 3 — The Fetch-Decode-Execute Loop and Lazy Decryption

State Tracking and Sliding Windows

We'll build a strict execution state object that uses a sliding window and an XOR cipher to decrypt code lazily on the fly.

Maximum decrypted instruction window exposed in memory at any time: 256 bytes

// interpreter/src/lib.rs

const PAGE_SIZE: usize = 256;

struct VmState {
    ptr: u32,
    len: usize,
    pc: usize,
    session_key: u8,
    current_page_id: i32,
    ves: [u8; PAGE_SIZE],
}

Leaving our custom bytecode unencrypted in memory completely defeats the point of a VM. Hackers can easily use tools like Cheat Engine or automated memory dumpers to scrape the Wasm heap. If the bytecode is just sitting there in plain text, our whole obfuscation plan fails.

To make this truly resilient, we have to ensure the plaintext instructions only exist in memory exactly when the processor needs them, and then vanish immediately.

We slice the encrypted bytecode into 256-byte pages. When the program counter hits a new page, the VM pauses execution, decrypts those specific 256 bytes using the session key, and loads them into a secure buffer. When the program counter leaves that page, the old plaintext gets entirely wiped out and replaced by the next page.

Encrypted bytecode: [ PAGE 0 (256B) ][ PAGE 1 (256B) ][ PAGE 2 (256B) ] ...
                          ↓
                    PC enters page 1
                          ↓
              Decrypt page 1 → load into VES buffer
                          ↓
              Execute from VES until page boundary
                          ↓
              Wipe VES → decrypt page 2 → continue

This struct tracks exactly where the encrypted code lives in the host's memory (ptr), how far along we are in our virtual loop (pc), and securely holds the decrypted bytes (ves, which stands for Virtual Execution Segment).

The JIT Decryption Routine

When we cross into a new page, the VM decrypts that specific chunk of bytes and copies it strictly into our volatile virtual execution segment.

impl VmState {
    unsafe fn decrypt_page(&mut self, page_id: u32) {
        let start_addr = page_id as usize * PAGE_SIZE;

        for i in 0..PAGE_SIZE {
            if start_addr + i < self.len {
                // Calculate physical memory address inside the host Wasm
                let addr = self.ptr + (start_addr + i) as u32;
                let encrypted_byte = *(addr as *const u8);

                // Decryption occurs entirely inside local volatile state
                self.ves[i] = encrypted_byte ^ self.session_key;
            } else {
                // Pad unused memory to obscure the exact file length footprint
                self.ves[i] = 0;
            }
        }

        self.current_page_id = page_id as i32;
    }
}

This Just-In-Time decryption trick ensures that if a hacker freezes the browser to scrape memory, they will only ever see a maximum of 256 bytes of plaintext at any given microsecond. This makes bulk-analyzing the payload practically impossible.

Execution and Opcode Dispatch

The absolute heart of our interpreter handles moving the program counter forward, grabbing bytes through our JIT boundary checker, and running the actual math on our stack.

    unsafe fn fetch_u8(&mut self) -> u8 {
        if self.pc >= self.len { return 0xFF; }

        let page_id = (self.pc / PAGE_SIZE) as u32;
        let offset = self.pc % PAGE_SIZE;

        if self.current_page_id != page_id as i32 {
            self.decrypt_page(page_id);
        }

        let val = self.ves[offset];
        self.pc += 1;
        val
    }

    unsafe fn fetch_i64(&mut self) -> i64 {
        let mut b = [0u8; 8];
        for item in &mut b { *item = self.fetch_u8(); }
        i64::from_le_bytes(b)
    }

#[no_mangle]
pub unsafe extern "C" fn vm_exec(ptr: u32, len: usize) -> i64 {
    let base_sp = SP;
    let mut state = VmState {
        ptr, len, pc: 0, session_key: GLOBAL_SESSION_KEY,
        current_page_id: -1, ves: [0u8; PAGE_SIZE],
    };

    loop {
        let op = state.fetch_u8();
        match op {
            0x01 => { // Push logic
                let val = state.fetch_i64();
                if SP < 2048 {
                    *core::ptr::addr_of_mut!(STACK).cast::<i64>().add(SP) = val;
                    SP += 1;
                }
            }
            0x10 => { // Addition logic
                if SP >= 2 {
                    SP -= 1;
                    let b = *core::ptr::addr_of!(STACK).cast::<i64>().add(SP);
                    SP -= 1;
                    let a = *core::ptr::addr_of!(STACK).cast::<i64>().add(SP);
                    *core::ptr::addr_of_mut!(STACK).cast::<i64>().add(SP) = a.wrapping_add(b);
                    SP += 1;
                }
            }
            0x30 => { // Load Register logic
                let idx = state.fetch_i64() as usize;
                if idx < 512 {
                    let val = *core::ptr::addr_of!(REGS).cast::<i64>().add(idx);
                    *core::ptr::addr_of_mut!(STACK).cast::<i64>().add(SP) = val;
                    SP += 1;
                }
            }
            0x50 => { // Unconditional Jump logic
                let target_pc = state.fetch_i64() as usize;
                if target_pc < state.len { state.pc = target_pc; } else { abort(); }
            }
            0xFF => { // Exit logic
                let ret = if SP > base_sp {
                    SP -= 1;
                    *core::ptr::addr_of!(STACK).cast::<i64>().add(SP)
                } else { 0 };
                SP = base_sp;
                return ret;
            }
            _ => abort(),
        }
    }
}

Some instructions need larger parameters (like Push, which needs to know the exact 64-bit number to put on the stack). So, we add a small helper method to fetch eight consecutive bytes and rebuild them into a valid integer. By calling our existing fetch_u8 method under the hood, this multi-byte fetcher automatically gets all the page-boundary checks and lazy decryption logic for free.

The logic inside this massive match statement quietly manages its own isolated context, handles jumps for complex if statements, and safely returns control to the host only when it hits the Exit opcode.

Chapter 3 Recap

Our Wasm virtual machine is fully working. It runs in pure isolation, uses zero allocators, processes math on a stack, and cryptographically hides itself from memory dumpers using a 256-byte rolling JIT window. But a VM is useless without code to run on it. Now we need to build the compiler layer to generate those encrypted payloads.

Chapter 4 — Compiling Intermediate Representation to Custom Bytecode

Parsing the WebAssembly Module with Walrus

We'll use the Walrus crate to parse the target binary and set up a dynamic buffer for compilation.

// src/compiler.rs

use walrus::ir::{Instr, Value};
use walrus::LocalFunction;
use byteorder::{ByteOrder, LittleEndian};
use rand::Rng;

pub struct Compiler {
    pub bytecode: Vec<u8>,
}

Our interpreter engine is finished, but right now it's useless because it has no bytecode to run. We need to build a compiler layer that reads standard Wasm logic from an existing file and deeply translates it into our custom, undocumented format.

We are basically building a backend compiler. We aren't parsing human-readable Rust or C++ source code. We're taking a pre-compiled Wasm binary, extracting the internal instructions, and translating them down into our own specific bytes.

Walrus converts the raw Wasm file into an Intermediate Representation (IR) that we can easily iterate over in Rust. We need a simple struct to hold our output bytes as we generate them. As we walk through the original app's logic step by step, we'll push our custom opcode bytes straight into this vector.

Translating Standard Instructions to Custom Bytecode

Our compiler recursively walks through the function's IR, aggressively crushing the typed Wasm logic down into our randomized, custom byte format.

impl Compiler {
    pub fn compile_paged(&mut self, func: &LocalFunction) -> (Vec<u8>, u8) {
        let entry_id = func.entry_block();
        let block = func.block(entry_id);

        for (instr, _) in block.instrs.iter() {
            self.compile_instr(instr);
        }

        self.bytecode.push(0xFF); // Forcefully append the exit opcode manually
        self.encrypt_and_finalize() // Execute cryptographic pass
    }
}

    fn compile_instr(&mut self, instr: &Instr) {
        match instr {
            // Translating constant variables
            Instr::Const(c) => {
                if let Value::I32(v) = c.value {
                    self.bytecode.push(0x01); // Custom Push Opcode
                    let mut buf = [0u8; 8];
                    LittleEndian::write_i64(&mut buf, v as i64);
                    self.bytecode.extend_from_slice(&buf);
                }
            }

            // Translating arithmetic binary operations
            Instr::Binop(op) => {
                match op.op {
                    walrus::ir::BinaryOp::I32Add => self.bytecode.push(0x10), // Custom Add Opcode
                    walrus::ir::BinaryOp::I32Sub => self.bytecode.push(0x11), // Custom Sub Opcode
                    _ => unimplemented!("Operator not natively mapped"),
                }
            }

            // Translating Variable reading
            Instr::LocalGet(l) => {
                self.bytecode.push(0x30); // Custom LoadReg Opcode
                let mut buf = [0u8; 8];
                LittleEndian::write_i64(&mut buf, l.local.index() as i64);
                self.bytecode.extend_from_slice(&buf);
            }

            // Translating Variable writing
            Instr::LocalSet(l) => {
                self.bytecode.push(0x31); // Custom StoreReg Opcode
                let mut buf = [0u8; 8];
                LittleEndian::write_i64(&mut buf, l.local.index() as i64);
                self.bytecode.extend_from_slice(&buf);
            }

            _ => unimplemented!("Instruction architecture not mapped"),
        }
    }

We need a method that takes a Walrus function (LocalFunction), strictly walks through every single instruction in that function's block, and tells our translation layer to output the corresponding virtual bytecode. Once all instructions are translated, we forcefully append our Exit opcode so the VM knows exactly when to stop.

By pulling the initial entry block, we get the true mathematical root of the function's execution path, making sure we capture every single logical step the developer originally wrote.

The actual translation happens step by step. We deeply analyze the Walrus Instr object, match it against known patterns, and emit the custom opcodes we defined back in Chapter 1.

If we hit a hardcoded number, we spit out a push opcode followed by those 8 bytes of data. If we hit a local variable access, we emit a register load opcode followed by the variable's virtual register index.

This destructive translation process completely strips away all the original context. Wasm's incredibly rich typing system and readable operations get mercilessly flattened into a purely mathematical array of secret bytes.

Cryptographic Obfuscation Pass

Finally, we run the bytecode array through a bitwise XOR cipher using a uniquely generated session key to hide its logic.

    fn encrypt_and_finalize(&mut self) -> (Vec<u8>, u8) {
        let mut rng = rand::thread_rng();
        let session_key = rng.gen::<u8>(); // Generate isolated session key

        // Encrypt everything iteratively
        for byte in &mut self.bytecode {
            *byte ^= session_key;
        }

        (self.bytecode.clone(), session_key)
    }

Once the plaintext bytecode is generated, it absolutely has to be encrypted. Leaving it as plain text inside the final Wasm file means advanced reverse-engineers could eventually map out our math, even with the custom ISA.

We generate a random crypto key using Rust's rand crate, loop over the entire bytecode vector, and apply our bitwise XOR cipher. We'll return both the encrypted payload and the key, so our injector can deploy them nicely into the host module.

This one pass completely ruins the binary data for anyone snooping around. To a reverse engineer or malware scanner, the carefully structured logic is instantly replaced by pure high-entropy cryptographic noise.

Chapter 4 Recap

The compiler bridge is finished. We can theoretically take a standard Wasm instruction like LocalGet, map it to our IR, translate it into our virtual LoadReg opcode, append the arguments, and encrypt the result into pure garbage. The final hurdle is wiring this ciphertext back into the original .wasm file.

Chapter 5 — Abstract Syntax Tree Rewriting and VM Injection

Erasing the Original AST

The injector component completely nukes the original execution instructions from the host binary's function.

// src/injector.rs

use walrus::{Module, FunctionId, DataId, MemoryId};

pub fn replace_body_with_thunk(
    module: &mut Module,
    func_id: FunctionId,
    vm_exec_import: FunctionId,
    vm_set_reg_import: FunctionId,
    vm_set_session_key_import: FunctionId,
    bytecode_ptr: i32,
    bytecode_len: i32,
    data_id: DataId,
    mem_id: MemoryId,
    session_key: u8,
) {
    let func = module.funcs.get_mut(func_id);
    let local_func = func.kind.unwrap_local_mut();

    let args = local_func.args.clone();
    let entry = local_func.entry_block();

    // Destroy the original application logic entirely.
    local_func.block_mut(entry).instrs.clear();

If a JavaScript frontend expects to call an exported Wasm function named calculate_secure_hash, we can't just delete it from the file. That would instantly break the integration and crash the web app.

Instead, we have to securely overwrite the guts of calculate_secure_hash. We strictly delete its original syntax tree, wipe out the proprietary algorithms, and replace it entirely with a tiny, automated adapter script called a Thunk.

The flow of our injected Thunk works like this:

JS calls calculate_secure_hash(arg0, arg1)
            ↓
     [Thunk intercepts]
            ↓
  memory.init → deploy encrypted bytecode
            ↓
  vm_set_session_key → load decryption key
            ↓
  vm_set_reg(0, arg0), vm_set_reg(1, arg1)
            ↓
  vm_exec(bytecode_ptr, bytecode_len)
            ↓
     Return result to JS

At this point in the compile process, if the JS app called the function, it would safely do absolutely nothing and return empty. The actual secret logic has been totally eradicated from the standard execution path and can't be decompiled.

Allocating the Bytecode to Linear Memory

The injector immediately writes new bulk-memory operations into that empty block to deploy the encrypted payload securely.

    let mut builder = local_func.builder_mut().func_body();

    // Deploy the encrypted bytecode from the passive data segment
    // into active Wasm linear memory dynamically
    builder
        .i32_const(bytecode_ptr)
        .i32_const(0)
        .i32_const(bytecode_len)
        .memory_init(mem_id, data_id);

    // Securely set the isolated decryption session key for the VM
    builder
        .i32_const(session_key as i32)
        .call(vm_set_session_key_import);

WebAssembly lets us embed raw bytes deep inside passive .data segments. But by default, these passive segments just sit there like a zip file. We have to explicitly tell the host's memory manager to dynamically unpack our encrypted bytecode out of the file and into active linear memory so the VM can actually read and run it.

We initialize a new function builder in Walrus to start writing our replacement Thunk. We use the standard Wasm memory.init instruction to cleanly deploy the payload, and immediately trigger the VM's key initialization hook.

The encrypted ciphertext gets strictly mapped right into active memory, exactly where our core interpreter expects to find it.

Constructing the Execution Thunk

The adapter loop translates the host arguments, fires up the virtual context, and safely returns the mathematical result.

    for (idx, &arg_local) in args.iter().enumerate() {
        builder.i32_const(idx as i32);         // Argument index -> Virtual Register ID
        builder.local_get(arg_local);          // Actual Argument Value

        // Promote 32-bit parameters to 64-bit to match our VM architecture
        builder.unop(walrus::ir::UnaryOp::I64ExtendI32S);

        // Pass the data safely through the isolation barrier
        builder.call(vm_set_reg_import);
    }

    // Trigger the virtual execution loop
    builder
        .i32_const(bytecode_ptr)
        .i32_const(bytecode_len)
        .call(vm_exec_import);

    // Format the VM output back into the expected Host application format
    builder.unop(walrus::ir::UnaryOp::I32WrapI64);
}

The original function took parameters (like ints or pointers) right from the external JS context. We have to gracefully route these parameters deep into our virtual machine so the internal logic has the data it needs to run.

We loop over the arguments the function originally expected. For each one, we push its sequential index (which maps to a Virtual Register ID) and its raw value onto the host stack, cast it up to a 64-bit integer using I64ExtendI32S, and invoke the interpreter's register API.

Our VM instance is now fully hydrated with the incoming request data. The absolute last step is to call the main execution loop, passing it the exact memory address and length of the encrypted bytecode.

Once the VM finishes crunching the math over the JIT sliding window, it reliably returns a 64-bit result, which we intelligently cast back down to match the original 32-bit function signature.

Chapter 5 Recap

The integration is completely seamless. The final binary will cleanly export the exact same functions it did originally. The external JavaScript app stays totally unaware that anything even changed. But when triggered, the engine reliably jumps straight into our custom thunk, populates the virtual context, and securely runs the secret logic via the hidden interpreter.

Final Conclusion

Throughout this huge guide, we've systematically built a hardcore WebAssembly-in-WebAssembly virtualization engine. We started by looking at how transparent standard Wasm binaries are, realizing that shipping secret logic in normal .wasm files is basically handing out plain text.

To fix this, we designed our own custom Instruction Set Architecture, mapping operations onto a completely random numerical layout. We built a hyper-optimized Virtual Machine in Rust that totally avoids memory allocators to keep a tiny footprint, relying entirely on static arrays and raw memory pointers.

We locked this machine down by building a JIT sliding decryption window. Even if a hacker dumped the live browser memory, they'd only ever find a broken 256-byte slice of the app, rendering their automated reverse-engineering tools totally blind.

We built a backend compiler using Walrus to aggressively rip out the original Abstract Syntax Tree, crushing typed Wasm instructions down into encrypted garbage. Finally, we built a slick injection pipeline, replacing the original function with an automated Thunk that translates inputs and outputs between the standard environment and our secure bunker.

Where to Go From Here

While this VM gives us incredible security through obfuscation, software protection is a never-ending arms race. If you want to take this architecture into real-world projects, consider adding these techniques to your compiler.

Control Flow Flattening

Before converting to bytecode, tweak the Walrus IR to crush all if statements and loops into massive, mathematically complex switch statements, completely hiding the real execution paths.

Opaque Predicates

Inject fake math operations into the bytecode that look completely real but always evaluate to zero, forcing attackers to reverse-engineer thousands of useless, garbage instructions.

Dynamic Key Provisioning

Instead of leaving the session key inside the Wasm data segment, make the host server stream the decryption key dynamically over a WebSocket at runtime. This ensures the Wasm file can never be decompiled locally without a live, authenticated connection.

By stacking these advanced tricks on top of the VM architecture we built today, you can guarantee your WebAssembly logic stays fiercely protected no matter where it runs.

DEV Community: TrustSig