Someone Set a Trap for REA: Make AI Decompilation Burn Hundreds of Times More Tokens First

After REA took off, the barrier to decompilation got lowered to a somewhat absurd degree. It is an MCP server plus CLI that plugs into agents such as Claude Code, Codex, Cursor, and Gemini CLI, and runs locally. You ask how a feature is implemented, and it gives you functions, files, call chains, and evidence, tracing all the way down to the binary layer. On GitHub it has 100K+ stars, is MIT-licensed, and free. For developers it is a learning tool; for closed-source products it is cost pressure.

Then BLA appeared. It is a repository by GitHub user qybaihe, with the full name Blind LLM Agents, and a very blunt slogan: Make reverse engineering bankrupt again. The tweet mentions that the author is a student; this information comes from codila's retweet and replies. BLA's positioning is clear: protect the builds you are going to publish, and don't touch other people's software.

BLA Does Three Things

The README breaks the mechanism into three layers:

• Poison: inject format-valid canaries, honeypot metadata, and decoy control flow so analyzers think they have found real evidence.
• Exhaust: push artifacts beyond the resource budgets documented in REA, such as ASAR header size, WASM interface representation, SQLite column evaluation, model JSON nesting, Go buildinfo, BEAM chunk, PCAP JSON, and Electron fuse sentinel.
• Hallucinate: make analyzers get truncated manifests, failed redaction, and vague rabbit holes. Runtime behavior remains unchanged.

It does not add a packer, nor does it rely on commercial packers. The protection is format-native. The official line is that the red line is never to break the behavior, export surface, binary or section integrity, or format validity of the protected program. That claim is much more accurate than absolute anti-cracking.

How to Use It with One Command

The simplest way is to let the coding agent run it itself. The steps given in the tweet are:

1. Open Claude Code in the project folder.
2. Say: install Node.js 24 if I don't have it, build my project, then run npx bla-agents setup and npx bla-agents harden.
3. It will find build artifacts on its own: dist, build, Electron .asar, .wasm, Python, and native binaries.
4. Inject fake keys and decoy code, then check that every protected file runs with identical results.
5. When publishing, ship from the new .bla-hardened folder; do not keep using the old build.
6. In website scenarios, what is protected is the JS received by the browser; server-side code was never going to leave the server in the first place.
7. To see the effect, run npx bla-agents benchmark, which does a before-and-after comparison across 14 targets.

The manual commands are simple too:

npx bla-agents setup
npx bla-agents harden .
npx bla-agents benchmark

Node 22.23.4+ or 24.x is recommended. setup registers the MCP and skill; harden is the default one-click defense workflow; benchmark is a local demonstration. The repository also has staged commands such as audit, protect, verify, and defend.

Look at the Numbers Carefully

BLA's README contains a set of benchmarks: 14 targets, aggregating roughly 639.5x tokens and 304.4x cost, with 14/14 runtime consistency. That number is eye-catching, but the repository itself notes that it is an internal estimate, derived from BLA's catalog of REA limits, and not actual measurements for all paths.

The redteam table that actually ran against real REA is more worth looking at. The records include:

• Go buildinfo pushed from 50 KiB to 1.16 MiB, triggering the 1 MiB cap; REA reports a capacity error.
• Electron ASAR pushed from 607 B to 16.9 MiB, triggering the 16 MiB header cap.
• After adding Wabt to WASM, the interface status becomes partial, exceeding the representation budget.
• JavaScript triggers resourceLimits such as alias-selections, getter-expansion, primitive-bytes, and primitive-candidates.
• SQLite under Node 24 triggers column evaluation failure, with an unknown function on a honeypot column.

These are real error strings, with specific errors that can be checked. But the repository also lists paths that have not been made to work: Ghidra native decompilation depth, Frida/LLDB/GDB/Rizin live sessions, full Android APKs, firmware containers, SPIR-V/CUDA fatbinary/AMD GPU objects. Without the corresponding tools and samples, you cannot say these paths have gone bankrupt. This boundary is written very clearly and is worth preserving.

Whom It Can't Stop

A netizen said it very directly under the tweet: decoys can only burn tokens; until someone diffs what the application actually executes, fake keys are just clutter. Another netizen said that a human with a decompiler can skip the fake keys. codila's reply also acknowledges that BLA is not a safe; it makes cheap cracking more expensive.

This is probably BLA's most reasonable positioning. It does not eliminate reverse engineering, nor does it protect the server side. What it raises is the cost of bulk AI analysis, especially for workflows that clone a feature with a single command. For independent developers, spending a few minutes running harden can at least make people who casually use an agent to unpack things hit a few more walls. For a team that is truly targeting you, fake keys and resource budgets are only a matter of time.

One more detail: a netizen asked whether the fake keys would trigger secret scanners or leak detection. codila replied that by design it does not use real key prefixes, so scanners will not go off. This point is more important than injecting fake keys itself. A protection tool must not create new security alerts for its users.

Worth Trying, but Don't Deify It

BLA is MIT-licensed, free, and can run with one command. It addresses a very real problem: REA has driven down the marginal cost of reverse engineering, and closed-source software being not open source no longer means it is incomprehensible. BLA tries to add the cost back, making AI analyzers spend it on budgets, decoys, and truncated information.

But it is not a safe. Code obfuscation, server-side authentication, key management, and license validation that should be done before release cannot be omitted. BLA is more like a row of fake doors at the entrance: a real thief will go around them, while someone casually pushing doors will get annoyed.

Repository: https://github.com/qybaihe/bla

Official website: https://bla.tools/

Tweet: https://x.com/0xCodila/status/2119147351604601206