This is a focused write-up of an experiment I 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 to why it worked, and what that changes.

An 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.

So I gave Claude Code two obfuscated files and one prompt each, and let it actually execute things.

Target one: a custom VM with nine defense layers

The first target: 1,587 lines, 68 KB of obfuscated output (~194× the 13-line calculatePrice(quantity, unitPrice) input - 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 interpreter.

The 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.

Claude's plan, written before the real work started.

The first attempt was the natural one and it failed. Claude wrote an 883-line deobfuscate.js that statically reimplemented the pipeline - RC4 string decryption, 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 bytecode format, picked the wrong version byte, and produced garbage. Reimplementing the deserializer from the outside was a trap.

So it stopped reimplementing and started instrumenting. A 48-line instrument2.js made 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"], and the per-function keys it needed: blockKey=54, jumpKey=9643, seKey=4168320119.

The pivot: don't reimplement the deserializer, let the obfuscator run it for you.

A disassemble.js took the captured 22-instruction bytecode stream, named the opcodes (PUSH_CONST, LOAD_ARG, STORE_LOCAL, MUL, SUB, GT, JMP_FALSE, RETURN…), and reconstructed:

function calculatePrice(price, quantity) {
  const taxRate = 0.15;
  const threshold = 100;
  let total = price * quantity;
  if (total > threshold) {
    total = total * (1 - taxRate);
  }
  return total;
}
console.log(calculatePrice(10, 20)); // → 170

170, same as the original, on every input I tried including the boundary case. What doesn't survive perfectly are the names - quantity, unitPrice came back as price, quantity (argument order inferred from behavior), the two SECRET_* constants came back as taxRate and threshold - because those are inferred from how the code behaves, not literally stored. The literal values 0.15 and 100 survived untouched, because the VM needs them in the bytecode to run. Total elapsed time: about ten minutes.

Target two: a commercial enterprise obfuscator, completely different machinery

Same 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.

Claude 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 state machine building one object called BACKGROUND. 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:

var BACKGROUND = {
  HILLS: { x: 5, y: 5, w: 1280, h: 480 },
  SKY: { x: 5, y: 495, w: 1280, h: 480 },
  TREES: { x: 5, y: 985, w: 1280, h: 480 },
};

24 KB in, five lines out, about twenty minutes.

Why it didn't hold up

Four structural reasons, and they're the interesting part because they predict what does and doesn't work next.

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.

2. Sequential transforms unroll one at a time. When layers are composed as t₁ ∘ t₂ ∘ … ∘ tₙ, 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, seeded Fisher-Yates - because they've seen thousands of each. Defeating n layers takes roughly n units of work, not the 2ⁿ you'd get from genuinely interleaved transforms.

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.

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 and ben-sb/javascript-deobfuscator already handled the static layers; HumanifyJS 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 - a production LLM deobfuscator - and the JsDeObsBench work, and the same trade-off Elastic's security team and the RSAC piece on the topic 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.

The nine layers from the first run, and why each one came apart:

What this actually puts at risk

The 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, 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.)

A 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.

What I haven't tested, and where I land

Two 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.

But 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 - a few weeks ago.) And yes, I'm building a modern obfuscator at AfterPack on the other premise: transforms in Rust where the inverses are scattered and entangled across the bundle deeply enough that recovery becomes combinatorial (n^m) 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.

If you ship obfuscated JavaScript today, that's the experiment to run before you find out the hard way what's in it.

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.