VM Debug Protection

The vmDebugProtection option adds anti-debugging measures to the VM runtime, making it significantly harder to reverse-engineer your protected code. How each detection reacts is set by the debugger, automation, and sandbox categories of vmDefenseReaction.

With browserEnvironment.hosting set to 'remote' (v7.14.1+), Debug Protection also binds the build to being served from a remote host: a copy served from a local development host is treated as a runtime-environment mismatch, and the automation defenses react.

These defenses also act against your own agents, automation, and debuggers. They may stop execution, throw unrelated errors, or produce incorrect results. Use a separate testing build for functional tests; Testing and CI shows the options that build overrides.

Inspector detection

From obfuscator 8.0.0, vmDebugProtection accepts an object as well as a boolean. Passing an object keeps Debug Protection on while relaxing a single detector:

inspectorDetection (default on) detects and reacts to an attached Chrome DevTools Protocol inspector or an active debugger. Opening the browser's developer tools attaches such a session, so an open inspector is detected and reacted to. Keep it on for production; turn it off only if your users legitimately open developer tools. In the dashboard this is the Inspector Detection sub-switch under VM Debug Protection (v8.0.0+), which appears once Debug Protection is on.

After a detection, only a reload brings the code back. Closing developer tools does not restore the protected code: until the page is reloaded, every later call into it throws errors that explain nothing, such as Uncaught 0, or, under the decoy reaction, returns wrong results. The reload loses anything the user has not saved. To save it or show a message first, run your own response in vmDefenseHook, which is called before the defense reacts. Developer tools and other tools that attach over the same protocol look the same to the protected code, so letting your users open developer tools also lets those tools in.

Automation frameworks. With inspectorDetection on (the default), driving the protected page with a CDP-based tool (Puppeteer, Playwright, Selenium/ChromeDriver) is detected as an attached inspector. vmDebugProtection: { inspectorDetection: false } turns off only the inspector detector; Debug Protection's automation detector can still react to a driven browser. For automated test builds, follow Testing and CI, which disables vmDebugProtection and vmSelfDefending.

Content Security Policy

If your Content Security Policy prohibits dynamic evaluation (no unsafe-eval), use the browser-no-eval target and validate the output under that policy. This target uses a fallback for checks that otherwise rely on dynamic evaluation. The same applies to browser extensions with a restrictive CSP: use browser-no-eval for best compatibility.