Reverse-engineer custom bytecode VMs in obfuscated JS

This skill provides a workflow for reverse-engineering a custom-bytecode virtual machine embedded inside obfuscated JavaScript - the pattern used by some risk-control and verification engines instead of a standard WASM binary. It starts with recognition: an IIFE entry point with single-letter variables mapped to numeric constants, an interpreter main loop (switch/case over an opcode decoded from a bitfield), a large single-line file with under 1% null bytes (ruling out real WASM), and a constant table indexed like C[9][x] holding function references and strings. It explicitly excludes standard WASM binaries (files starting with the \x00asm magic bytes, or with over 20% null-byte density) and ordinary bundled JS, routing those to other skills instead. The six-phase workflow moves from file classification, to extracting the variable-to-constant mapping table, to enumerating and classifying every opcode by what its case body does (branch, call, arithmetic, store, allocation, exception), to analyzing the constant table's reference range, to tracing an exported function back through its registration call to the bytecode sequence it executes, and finally - only when static analysis alone isn't sufficient - to runtime instrumentation that loads the code in a controlled browser context (via Selenium+CDP or Playwright) to observe what it computes. It documents a reference opcode-to-behavior table built from prior cases and a small set of common numeric status codes such an engine's output tends to use.

Use it when a web asset under authorized security review runs a custom bytecode interpreter rather than standard WASM, and the objective is to recover what its opcodes mean and how its constant table is structured - for example while auditing a risk-control or verification component's own logic. Route to a different reference when the file starts with the WASM magic bytes (that's standard WASM, handled elsewhere), when it's an ordinary bundled JS file with no interpreter loop, or when the work is really about the surrounding network/API protocol rather than the VM's internal bytecode - that belongs to a separate JS reverse-engineering skill.

• File classification script that distinguishes a DSL-VM JS file from standard WASM or ordinary bundled JS using magic bytes, null-byte density, and IIFE variable patterns.
• Scripted extraction of the numeric constant-to-variable mapping, the full opcode case list, and a heuristic classification of each opcode (branch/call/arithmetic/store/allocation/exception) from its code body.
• Constant-table reference analysis to map the range and context of indices used by the interpreter.
• A documented, prior-case-derived reference table of 26 opcode numbers (0 through 25), each mapped to an observed operation category such as branch, call, arithmetic, store, allocation, or exception.
• A small reference table of common numeric status codes an engine's output tends to use: a success code, a block/reject code, two distinct retry-needed codes for different retry reasons, and a generic-failure code.

Security researchers doing authorized reverse engineering of a web asset's obfuscated, VM-based JavaScript components, who are expected to record what they found in the project's field-journal afterward and update routing.md when a new tool or target pattern turns up.