Docs
/
VM Obfuscation
/

Direct eval Behavior

Direct eval() Disables VM Obfuscation

If a function contains a direct eval(code) call anywhere in its body (including in nested functions), the entire function and all its nested functionsare skipped by VM obfuscation. This is because direct eval has access to the enclosing function's local variables, which are not available when the function is compiled to VM bytecode.

// ❌ Entire IIFE is NOT VM-obfuscated because of direct eval inside
(function () {
    function loadConfig() {
        eval(decodedLoader); // direct eval - blocks VM for the whole IIFE
    }
    // ... all your code ...
})();

// ✅ Use indirect eval - runs in global scope, does not block VM
(function () {
    function loadConfig() {
        (0, eval)(decodedLoader); // indirect eval - VM obfuscates the IIFE
    }
    // ... all your code ...
})();

// ✅ Or unwrap the IIFE - each top-level function is checked independently
function loadConfig() {
    eval(decodedLoader); // only this function is skipped
}
// ... other top-level functions are still VM-obfuscated ...

Detection catches direct eval (eval(code) and eval?.(code)). Indirect forms like (0, eval)(code) and window.eval(code) run in the global scope and do not block VM obfuscation.

Escape hatch (v6.14.0+): set vmForceCompileDynamicCode: true (or flip the Force Compile Dynamic Code switch under the VM section's Overrides group) to bytecode the surrounding function anyway and suppress VMDynamicCodeSkipped. Only safe when the runtime-built body cannot reference an identifier the obfuscator renames; otherwise the code throws ReferenceError at runtime. See the recipe page for the full trade-off.