qybaihe/bla

BLA is worth a look if you ship compiled bundles or Electron artifacts and worry about an AI agent pulling them apart; treat it as an adversarial-deterrence experiment, not a finished security control, since it is two days old and most non-JS shields are untested against a real agent.

The problem

You have a release artifact — an Electron app, a JS bundle, a WebAssembly module — and you want to keep its internals from being cheaply extracted. A reverse-engineering agent (REA) can open the artifact and walk through its structure in one command. The step that changes with BLA is the build output: you run the harden pass over the directory you ship, and the artifact opens with planted decoys and oversized structures instead of a clean surface. You get the same runtime behavior, but the analyzer's inventory is truncated, ambiguous or budget-blocked.

What's different

BLA works on the resource limits of the analyzing agent rather than on classic obfuscation alone. Its three layers are Poison (format-valid canaries, honey metadata, decoy control flow), Exhaust (push headers, nesting and inventories past documented REA budgets) and Hallucinate (leave the analyzer with truncated inventories and ambiguous paths). The README reports real REA budget failures on Go buildinfo (1 MiB cap), Erlang BEAM chunk counts and EVM bytecode input size, with byte-level error strings from a local redteam:rea run in the empirical validation report. That gate matters: the author explicitly says the constant-drift harness verify:rea must not be cited as protection evidence, and the 14-target benchmark's token/cost multipliers are internal estimates, not measured protection.

The trade-off is scope and confidence. Verified formats are JavaScript/TypeScript, Electron .asar, Electron fuses and WASM; Ghidra/native decompilation, Frida/LLDB/GDB/Rizin sessions, the JADX/APK pipeline (APK resigning unsupported) and firmware containers are designed-for but not verified against a real REA here. The runtime-equivalence claim is checked per benchmark target, but nothing guarantees a future analyzer cannot be adapted to these decoys.

Who should try it

Good fit: a team shipping an Electron or JS/WASM product who wants to raise the cost of automated inspection and can afford to re-run a verification pass on each release. Poor fit: anyone protecting native binaries or Android APKs expecting the same tested behavior, or anyone who needs an audited, long-lived security control — those layers are unit-tested but flagged unimplemented against real tools. If you want a different workflow, the README also exposes explicit audit/protect/verify/defend stages in the CLI and MCP docs, not just the one-command path.

Requirements and limitations

Node.js ^22.23.4 || 24.x is the recommended runtime; Node 22.23+ is needed for the REA red-team probes, while optional Wabt and tshark enable empirical WASM/PCAP checks rather than protection itself. Ghidra, Hopper, IDA or Wabt are not required to protect files. Setup uses npx bla-agents setup to register the MCP server or SKILL.md skill with coding agents such as Claude Code, Cursor, Codex or Gemini CLI.

The larger limit is upkeep: each release needs a fresh harden-and-verify pass, and the claims you can rely on are the ones your own redteam:rea run reproduces. Older or unverified formats should be treated as unproven until a report exists for them.

HotRepo's take

The repository is two days old and HotRepo recorded it on the NEW-REPOSITORY board (TypeScript) at #25 with 114 total stars on 2026-10-28 — a snapshot, not a daily-growth measurement. With only one recorded date, persistence cannot be judged. Before adopting, check whether your specific artifact format appears in the empirically verified table rather than the designed-for list in the project README.