The open-source tool REA — “reverse engineer anything with agents” — lets AI coding agents unpack apps, trace their internals and reconstruct business logic in minutes. Now a solo developer has released the counter-move. BLA (Blind LLM Agents) modifies a program’s release build so that AI reverse-engineering agents hit their own resource limits, chase decoy code and fake credentials, and burn tokens — while, its author says, real users run exactly the same app. Viral threads over the weekend declared REA “bankrupt.” The repository’s own documentation is more careful, and that gap is the story.
Quick Take
- What it is: An MIT-licensed CLI and MCP server (npm: bla-agents) that audits, “hardens” and verifies build artifacts — JavaScript bundles, Electron .asar archives, WebAssembly, Python, SQLite, model files and native binaries.
- How it works: “Poison → Exhaust → Hallucinate”: plant plausible decoys and canary keys, inflate artifacts past documented REA limits, and steer agents toward shadow logic.
- The claims: The README says hardened artifacts make analyzers burn “300×–2,800× more tokens,” and that 14 of 14 bundled benchmark targets pass runtime-equivalence checks. It labels the token and dollar figures “internal estimates.”
- The traction: Created on October 25, the GitHub repo had more than 3,900 stars and 480 forks by November 9, helped by near-identical promotional threads on X.
What happened
BLA has been public since late October, but it took off on X after November 7, when the account @0xCodila posted a setup guide headlined “REA (reverse engineer anything) – F*CKED by chinese student…” that drew about 6,000 likes. Several other accounts followed with almost the same wording. The developer, Timo Zhang (@xteam3301), who publishes as qybaihe on GitHub, described himself as a Chinese student and the project as “built solo.” He wrote that BLA reached “3,278★ in weeks” with 407 forks; GitHub’s API showed 3,937 stars and 485 forks on November 9. npm lists the latest version as 3.2.1.
The usage pattern in the threads is simple: install via npx, run npx bla-agents setup to register BLA with a coding agent such as Claude Code, Cursor, Codex or Gemini CLI, then npx bla-agents harden, and ship the files from the new .bla-hardened folder instead of the original build.
Background: why REA made developers nervous
REA (morluto/rea) describes itself as a tool to “reverse engineer anything with agents, from app behavior down to native binaries.” BLA’s README summarizes the threat from the defender’s side: AI reverse-engineering agents “unpack .asar archives, recover SourceMaps, trace IPC bridges, inspect .wasm / .sqlite / .safetensors, and clone core business logic in seconds for ~$0.20.” For makers of desktop apps, games and paid features shipped in client code, that turns reverse engineering from a specialist’s job into a one-command task.
Classic obfuscation does not help much. As BLA’s documentation argues, renaming variables to strings like _0x1a2b is something “modern LLMs effortlessly summarize.” Model-extraction and IP-protection questions have been a recurring theme on i10x, from AI model extraction defenses to this week’s Claude Code secrets leak.
How it works
BLA’s README describes four pillars. Poison plants “format-valid canaries,” fake enclave manifests, honey source maps and “plausible shadow state machines.” Exhaust deliberately trips the exact limits REA documents — for example a 16 MiB ASAR header limit or 32-level nesting for model metadata — so analysis downgrades from “COMPLETE” to “LIMITED” or fails. Entangle binds JavaScript, WebAssembly and native sidecars with runtime hashes so decoys cannot simply be stripped. A runtime layer detects debuggers such as Chrome DevTools Protocol or Frida and serves “believable synthetic telemetry.” A 24-vector matrix maps each REA source-code limit to a BLA countermeasure.
The decoy logic sits behind opaque predicates that always evaluate the same way at runtime, which is how BLA claims “100% runtime equivalence.”
| Format | Size before → after | REA outcome after BLA (per BLA) |
|---|---|---|
| Electron ASAR | 607 B → 16.9 MiB | Capacity error at the 16 MiB header limit |
| JavaScript | 761 B → 116 KiB | Budget rejected (alias, getter, primitive limits) |
| WASM + Wabt | 54 B → 6.56 MiB, 251 exports | Partial interface decoding |
| SQLite (Node 24) | 12 KiB → 56 KiB | Evaluation trap on virtual columns |
| Go buildinfo | 50 KiB → 1.16 MiB | Capacity error at 1 MiB build-info limit |
| Safetensors | 128 B → 10.1 KiB | Capacity error: JSON nesting over 32 levels |
The table above lists results BLA reports from running the real REA against hardened samples. A separate 14-target “showcase” reports token multipliers from 105.6× to 2,822.7× (about 639.5× on aggregate); the README states those columns are “internal estimates derived from BLA’s catalog of REA limits.”
Pros and cons
For users
- Pro: If it works as described, apps behave the same while competitors find it costlier to clone paid features.
- Con: Hardened artifacts can grow dramatically — an ASAR from 607 bytes to 16.9 MiB in BLA’s own test — which may affect download size and startup.
For developers
- Pro: Free, local, one command, with an MCP integration for common coding agents and bundler plugins for Vite, Rollup, Webpack and esbuild.
- Con: Tests pass on 14 bundled fixtures; for real projects the README says to “run your project’s test suite.” Debugging hardened builds and handling crash reports from decoy code paths adds work.
For companies
- Pro: Raises the cost of automated cloning of client-side logic, the cheapest attack REA enables.
- Con: Defenses tuned to one tool’s published limits can be undone by a new REA release; anti-debugging and decoy credentials may also trip app-store review, security scanners or customers’ own audits.
What X is saying
REA (reverse engineer anything) – F*CKED by chinese student… solo dev just dropped protection for your app & site & game from reverse-engineering and AI hackers, for free
— codila (@0xCodila) November 7, 2026 · View on X
REA is the most dangerous repo on the internet… so I built the thing that blinds it. 🛡️ 3,278★ in weeks. 407 forks. built solo by a chinese student. it’s called BLA (Blind LLM Agents).
— Timo Zhang (@xteam3301) November 8, 2026 · View on X
ONE CHINESE STUDENT JUST MADE REA 100× MORE ANNOYING TO USE… A solo dev released BLA – Blind LLM Agents, a free hardening layer built to make reverse-engineering tools and AI agents waste time on the wrong things.
— Ricker (@0xRicker) November 8, 2026 · View on X
The author himself pushed back on the hype in a reply: “BLA is Counter-REA (poison/exhaust/hallucinate against agent budgets), not classic human obfuscation. We don’t claim Ghidra/IDA sessions are bankrupt unless measured.” Skeptics were blunter; one user replied simply: “just rea the bla and bypass it lmao.”
Critical analysis
BLA is a clever idea with honest documentation and an overheated marketing wave. The repository is careful: it says token and cost figures in its showcase are estimates, that “empirically verified” refers only to the REA paths it ran, and that it is “not a claim about Ghidra/Frida/LLDB/Rizin/JADX sessions we did not run here.” The viral threads drop every one of those qualifiers. Many of them share the same template text — one even ends with the leftover line “Want a more aggressive, shorter, or more technical version? Just say,” a strong hint that it was pasted from an AI assistant.
Technically, BLA attacks the analyzer rather than the analyst. That is effective as long as REA keeps the same limits, and fragile once it doesn’t: raising a 16 MiB cap or ignoring files over a size threshold is a small patch. Decoys work against agents that trust what they read; a well-instructed agent — or a human — that verifies behavior at runtime may still get through, especially as BLA’s runtime shield only fools debugging tools it detects.
The bigger picture is an arms race in which both sides are open source and both are driven by AI agents. That favors whoever updates faster, and it means BLA’s protection is best seen as raising cost, not providing security. Anything truly secret — keys, pricing logic, license checks — still belongs on a server.
What’s still open
- Will REA’s maintainers adjust limits or add decoy detection, and how quickly can BLA respond?
- Do independent tests on real-world apps confirm runtime equivalence and acceptable size and performance overhead?
- How will app stores and enterprise security scanners treat builds containing fake credentials and anti-debugging code?
- Will commercial obfuscation vendors adopt “agent budget exhaustion” as a standard feature?
About the analysis
Researched and written with AI assistance under the editorial responsibility of the i10X News team. The title image is an AI-generated illustration. Read our AI Use Policy. Spotted an error? Request a correction.
This independent, research-based i10x analysis is based on the BLA GitHub repository and README (qybaihe/bla), the project’s website, GitHub and npm metadata retrieved on November 9, 2026, the REA repository description, and public posts on X from November 5–9. i10x did not run BLA or REA. Performance figures are the project’s own and partly labeled as estimates.
i10x Perspective
AI agents have made reverse engineering cheap, and BLA shows the natural response: make it expensive again by attacking the agent’s budget and trust. Expect this to become a product category — “anti-agent hardening” — alongside traditional obfuscation and code signing. But developers should read the README, not the threads. A defense tuned to one open-source tool’s published limits is a speed bump, and the only durable protection for valuable logic is not shipping it to the client in the first place.
