{"slug": "ai-agents-defeat-obfuscated-javascript-in-10-minutes", "title": "AI Agents defeat obfuscated JavaScript in 10 minutes", "summary": "In an experiment detailed on the AfterPack blog, an AI agent (Claude Code) successfully deobfuscated two JavaScript files—one from an open-source obfuscator and one from a commercial enterprise product—in 10 and 20 minutes respectively. Rather than attempting to statically reimplement the obfuscator's decoding pipeline (which initially failed), the agent pivoted to an instrumentation strategy, modifying the obfuscated code to log its own runtime execution and thereby recovering clean, functionally equivalent source code. The results demonstrate that while a standard chatbot cannot perform this task, an agent capable of writing and executing scripts can defeat advanced obfuscation techniques, including custom VM interpreters and control-flow flattening.", "body_md": "This is a focused write-up of an experiment I\n\n[ran on the AfterPack blog]- the full four-paragraph prompts, the 883-line script that failed, the bytecode disassembly, the recovered source for both targets. Here I want to get towhyit worked, and what that changes.\n\nAn LLM agent that can run the obfuscated code defeats it in minutes - recovered clean source from two JS obfuscators, on the vendors' own published demo files, in 10 and 20 minutes. One of those was a commercial enterprise product whose own marketing has argued AI can't do this; that argument is accurate about a chatbot, not about an agent that writes and runs scripts.\n\nSo I gave [Claude Code](https://claude.com/claude-code) two obfuscated files and one prompt each, and let it actually execute things.\n\n## Target one: a custom VM with nine defense layers\n\nThe first target: 1,587 lines, 68 KB of obfuscated output (~194× the 13-line `calculatePrice(quantity, unitPrice)`\n\ninput - the function an open-source obfuscator publishes on its landing page to show off VM mode), recovered to source in ~10 minutes. Inside: nine composable defense layers wrapped around a ~1,500-line custom [stack-based VM](https://en.wikipedia.org/wiki/Stack_machine) interpreter.\n\nThe prompt was four short paragraphs - \"deobfuscate this, iterate as long as you need, write whatever temp files help, give me the closest reconstruction plus notes on the techniques\" - and I never told it which obfuscator the file came from. Claude read it four times, recognized it from the structure, and wrote a six-step plan.\n\n*Claude's plan, written before the real work started.*\n\nThe first attempt was the natural one and it failed. Claude wrote an 883-line `deobfuscate.js`\n\nthat statically reimplemented the pipeline - [RC4](https://en.wikipedia.org/wiki/RC4) string decryption, [base64](https://en.wikipedia.org/wiki/Base64), the binary deserializer. It got the ~500 encrypted string calls back. It recovered the environment-fingerprint value. Then it hit a custom [zigzag-varint](https://protobuf.dev/programming-guides/encoding/) bytecode format, picked the wrong version byte, and produced garbage. Reimplementing the deserializer from the outside was a trap.\n\nSo it stopped reimplementing and started instrumenting. A 48-line `instrument2.js`\n\nmade a modified copy of the obfuscated file with a few logging hooks spliced into the VM, ran *that* copy, and let the obfuscator decode its own bytecode at runtime. Out came the function name, the parameters, the locals, the constants `[0.15, 100, 1, \"calculatePrice\"]`\n\n, and the per-function keys it needed: `blockKey=54`\n\n, `jumpKey=9643`\n\n, `seKey=4168320119`\n\n.\n\n*The pivot: don't reimplement the deserializer, let the obfuscator run it for you.*\n\nA `disassemble.js`\n\ntook the captured 22-instruction bytecode stream, named the opcodes (`PUSH_CONST`\n\n, `LOAD_ARG`\n\n, `STORE_LOCAL`\n\n, `MUL`\n\n, `SUB`\n\n, `GT`\n\n, `JMP_FALSE`\n\n, `RETURN`\n\n…), and reconstructed:\n\n``` js\nfunction calculatePrice(price, quantity) {\n  const taxRate = 0.15;\n  const threshold = 100;\n  let total = price * quantity;\n  if (total > threshold) {\n    total = total * (1 - taxRate);\n  }\n  return total;\n}\nconsole.log(calculatePrice(10, 20)); // → 170\n```\n\n`170`\n\n, same as the original, on every input I tried including the boundary case. What *doesn't* survive perfectly are the names - `quantity, unitPrice`\n\ncame back as `price, quantity`\n\n(argument order inferred from behavior), the two `SECRET_*`\n\nconstants came back as `taxRate`\n\nand `threshold`\n\n- because those are inferred from how the code behaves, not literally stored. The literal values `0.15`\n\nand `100`\n\nsurvived untouched, because the VM needs them in the bytecode to run. Total elapsed time: about ten minutes.\n\n## Target two: a commercial enterprise obfuscator, completely different machinery\n\nSame experiment against a commercial enterprise obfuscator (a paid product), using their own published demo - a background sprite-atlas module they ship to advertise their default protection profile. Same shape of prompt, thinking turned up this time.\n\nClaude read the file once and had the structure mapped: a namespace registry, a URL-encoded XOR-keyed string blob, a 3D index table of opaque integer tags, a \"self-replacing decoder\" that primes itself for exactly eight calls and then degrades into a direct lookup, and the actual payload - a [control-flow-flattened](https://en.wikipedia.org/wiki/Obfuscation_(software)) state machine building one object called `BACKGROUND`\n\n. None of that was in the prompt. Different primitives entirely (no bytecode VM, no RC4, no anti-debug timing), but the same six-step arc translated almost directly - and this time the instrumentation pivot wasn't even needed. Static analysis alone took 24,620 bytes down to:\n\n``` js\nvar BACKGROUND = {\n  HILLS: { x: 5, y: 5, w: 1280, h: 480 },\n  SKY: { x: 5, y: 495, w: 1280, h: 480 },\n  TREES: { x: 5, y: 985, w: 1280, h: 480 },\n};\n```\n\n*24 KB in, five lines out, about twenty minutes.*\n\n## Why it didn't hold up\n\nFour structural reasons, and they're the interesting part because they predict what does and doesn't work next.\n\n**1. The inverse has to live in the bundle.** Every defense in this family ships its own undo - the decoder for the encrypted string, the shuffle key for the opcode table, the source values for the environment fingerprint - because if the inverse weren't there, the program couldn't run. That makes the whole family recoverable in principle. The only real question is cost.\n\n**2. Sequential transforms unroll one at a time.** When layers are composed as `t₁ ∘ t₂ ∘ … ∘ tₙ`\n\n, the inverse is just the reverse composition. LLMs are fluent at recognizing and inverting individual transform families - string-array rotation, RC4, base64, [XOR-with-constant](https://en.wikipedia.org/wiki/XOR_cipher), seeded [Fisher-Yates](https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle) - because they've seen thousands of each. Defeating `n`\n\nlayers takes roughly `n`\n\nunits of work, not the `2ⁿ`\n\nyou'd get from genuinely interleaved transforms.\n\n**3. A VM is a single point of failure.** The logical program is in custom bytecode, not JavaScript - but the thing that turns bytecode into behavior, the interpreter, sits right there in the bundle. Instrument its dispatch loop once and every function it will ever run is decoded. The anti-debug timing checks only fire when a human is stepping slowly with a breakpoint; automated instrumentation runs at full speed and never trips them.\n\n**4. The skill floor moved.** None of this was unbreakable before LLMs - there are decade-old papers on reversing control-flow flattening by hand. What changed is who can do it and how fast. \"Expert reverse-engineer with tooling, give it a few days\" became \"any engineer with an API key, give it a coffee break\", and the original names - which used to be the one thing reverse-engineers had to invent from scratch - now come back from semantic context for free. Automated deobfuscators like [webcrack](https://github.com/j4k0xb/webcrack) and [ben-sb/javascript-deobfuscator](https://github.com/ben-sb/javascript-deobfuscator) already handled the static layers; [HumanifyJS](https://github.com/jehna/humanify) showed an LLM could put readable names back. An agent that also *runs the code* closes the gap on the VM-and-anti-debug end. This is the same direction Google went with [CASCADE](https://arxiv.org/abs/2507.17691) - a production LLM deobfuscator - and the [JsDeObsBench](https://arxiv.org/abs/2506.20170) work, and the same trade-off [Elastic's security team](https://www.elastic.co/security-labs/llm-reversing-vs-llm-obfuscation) and the [RSAC piece on the topic](https://www.rsaconference.com/library/blog/llms-save-threat-researchers-time-but-our-obfuscated-javascript-case-study-shows) have been writing about. The honest caveat, which they keep raising and I'll second: LLM-recovered code can be confidently wrong, so you verify.\n\nThe nine layers from the first run, and why each one came apart:\n\n| Layer | What it does | Why it didn't hold |\n|---|---|---|\n| 1. String array + RC4 | All ~500 string literals encrypted, decoded at runtime via `U(idx, key)`\n|\nSelf-contained - evaluate `U()` once, statically decrypt every call |\n| 2. String array rotation | The array is rotated by an IIFE until a checksum matches | Runs on startup. Let it run, read the rotated array |\n3. Environment fingerprinting (`h()` ) |\nXORs `0x5f3759df` with built-in `.length` values |\nThose values are identical on every standard JS engine. No real binding |\n| 4. Bytecode encryption (RC4) | Bytecode blob encrypted with a key derived from `h()`\n|\nOnce `h()` is evaluated, decryption is one line |\n5. Binary serialization (`B()` ) |\nCustom zigzag-varint format with flag-gated conditional fields | Don't reimplement it - instrument it. Let the obfuscator decode itself |\n6. Opcode shuffling (`b3` table + per-function seed) |\nMaps logical opcodes to shuffled indices | Seeded PRNG. Reconstructible once you have the seed and the algorithm |\n7. Operand XOR (`blockKey` , `jumpKey` ) |\nEvery opcode and jump target XORed with a per-function key | Simple XOR. One known-plaintext recovers the key |\n8. Stack value encryption (`seKey` ) |\nInteger values XORed with a key when pushed to the VM stack | Applied only to integers. Floats, strings, objects stored in plaintext |\n| 9. Anti-debug timing + VM interpreter | Timing checks corrupt the opcode table if stepped; ~1,500-line custom VM | Instrumentation runs full-speed. The VM is the inverse - instrument dispatch once, get everything |\n\n## What this actually puts at risk\n\nThe case I keep coming back to is the one where the constants and the control flow *are* the IP: a license-check function, a trial-vs-paid gate, a token validator that decides whether the user gets the feature. The entire defense there is \"make it expensive to read\", and the cost of reading it just dropped by a couple of orders of magnitude. Trading-strategy code, ranking logic, anti-fraud heuristics, recommendation algorithms - anything that's a *function* shipped to the browser is in the same bracket. So is browser-game anti-cheat and [DRM](https://en.wikipedia.org/wiki/Digital_rights_management), where the whole threat model assumed days of attacker work per layer; cheat developers can now iterate inside the patch cycle instead of weeks behind it. (I haven't seen public evidence of LLM-driven cheat development yet - but the cost gradient is pointing the wrong way for defenders.)\n\nA lot of obfuscation purchase decisions were priced on an attacker who needed days of expert work per layer. The defenses that used to buy a year of headroom against the kind of attacker who could be bothered now buy an afternoon against anyone with a Claude account.\n\n## What I haven't tested, and where I land\n\nTwo products, two demo files, both picked by their vendors to advertise their *defaults*. What I haven't touched is the paid stuff sitting on top: environment-bound execution locks, self-defending integrity checks, anti-debugging traps, domain-bound execution gates - each of those adds a real obstacle. And transforms that scatter and entangle the inverses across the bundle so they aren't separable into peelable layers - are a separate experiment. Both deserve a follow-up.\n\nBut for the *default* profiles of mainstream JS obfuscators, including a commercial one, I think the structural claim holds: they don't raise the cost of recovery enough to matter against a capable 2026 LLM. (I wrote about an adjacent version of this - that [minified code was never really hidden either](https://www.afterpack.dev/blog/claude-code-source-leak) - a few weeks ago.) And yes, I'm building a modern obfuscator at [AfterPack](https://www.afterpack.dev) on the other premise: transforms in [Rust](https://www.rust-lang.org/) where the inverses are scattered and entangled across the bundle deeply enough that recovery becomes combinatorial (`n^m`\n\n) rather than linear. JavaScript still runs - the inverses are still there - but you can't peel them out one layer at a time. That's the only answer I currently believe in, and I'm aware \"I'm building the alternative\" is exactly what you'd expect me to say - which is why the prompts and the recovered code are all in the original post, so you can run it yourself.\n\nIf you ship obfuscated JavaScript today, that's the experiment to run before you find out the hard way what's in it.\n\n*Originally published on afterpack.dev. I'm Nikita Savchenko - I build production SaaS and write about Anthropic's tools, JavaScript security, and the things I break on purpose.*", "url": "https://wpnews.pro/news/ai-agents-defeat-obfuscated-javascript-in-10-minutes", "canonical_source": "https://dev.to/nikitaeverywhere/ai-agents-defeat-obfuscated-javascript-in-10-minutes-3kjc", "published_at": "2026-05-20 13:58:51+00:00", "updated_at": "2026-05-20 14:04:21.267922+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "cybersecurity", "developer-tools"], "entities": ["Claude Code", "AfterPack", "Claude"], "alternates": {"html": "https://wpnews.pro/news/ai-agents-defeat-obfuscated-javascript-in-10-minutes", "markdown": "https://wpnews.pro/news/ai-agents-defeat-obfuscated-javascript-in-10-minutes.md", "text": "https://wpnews.pro/news/ai-agents-defeat-obfuscated-javascript-in-10-minutes.txt", "jsonld": "https://wpnews.pro/news/ai-agents-defeat-obfuscated-javascript-in-10-minutes.jsonld"}}