bla (Blind LLM Agents) is a defensive hardening tool that poisons, exhausts, and misleads AI reverse-engineering agents analyzing your shipped binaries, Electron apps, WASM, and model files during authorized protection workflows.
| Tool | qybaihe/bla — adversarial defense shield that hardens binaries, Electron .asar, JS, WASM, Python, and model files against AI reverse-engineering agents |
| Category | Defensive software hardening / adversarial-AI countermeasures (TypeScript, MIT license, ~1196 stars) |
| Primary Use | Running npx bla-agents harden . or the bla_harden MCP tool so that AI reverse-engineering agents hit resource budgets and follow decoys when analyzing artifacts you own |
| Safe Use | Explicitly a defensive tool for protecting your own software in authorized build pipelines; the README's disclaimer restricts use to artifacts you ship and own |
| Telemetry Note | Leaves format-valid canaries, honey metadata, decoy control flow, and inflated but runtime-equivalent structures (headers, nesting, fuse sentinels) inside the artifact itself — defenders can detect BLA-hardened files by these decoy signatures |
bla — short for Blind LLM Agents — occupies an unusual niche in the security tooling landscape: it is not an attack tool at all, but a defensive countermeasure against a new class of adversary. The project's tagline, "make reverse engineering bankrupt again," captures the thesis: as AI reverse-engineering agents (which the README abbreviates as REAs) become capable of tearing apart release artifacts in a single command, defenders need a way to make that analysis economically unviable. bla does this by transforming the artifacts you ship so that an automated analyzer burns tokens, hits documented resource budgets, and follows decoys — while legitimate runtime behavior stays byte-for-byte equivalent. The repo sits at qybaihe/bla, is written in TypeScript, ships under an MIT license, and is distributed via npm as bla-agents.
The architecture is described as a three-layer model: Poison, Exhaust, and Hallucinate. Poison plants format-valid canaries, honey metadata, and decoy control flow that look like real evidence to an analyzer. Exhaust pushes the artifact past the REA's documented resource budgets — think oversized headers, deep nesting, inflated interface inventories, and excessive fuse sentinels. Hallucinate is the emergent consequence: the analyzer is left with truncated inventories, redaction failures, and ambiguous rabbit holes. The critical constraint threaded through all three layers is runtime equivalence — the README's benchmark reports 14/14 targets as runtime-exact after hardening, meaning users of the protected software should notice nothing.
What makes the project unusually credible for this space is its measurement discipline. Rather than claiming universal protection, the README separates results into empirically verified outcomes against a real REA harness (npm run redteam:rea) from paths that are merely designed-for. For example, a Go buildinfo section grows from 50 KiB to 1.16 MiB and trips the analyzer's MAX_BUILD_INFO_BYTES limit of 1 MiB. An Electron .asar header balloons from 607 B to 16.9 MiB, exceeding DEFAULT_ASAR_MAX_HEADER_BYTES. A Safetensors model file gains JSON metadata nesting beyond the 32-level MODEL_JSON_NESTING cap while remaining HF-loadable with tensor bytes unchanged. Each row pairs a before/after size with the exact error string the analyzer emitted, which is a level of transparency most obfuscation tooling never approaches.
Format coverage is broad and clearly cataloged. Verified categories include JavaScript/TypeScript via Babel AST manipulation with semantic budget exhaustion (alias-selections, getter-expansion, primitive-bytes), Electron .asar and fuses, WASM with custom-section canaries and export-name decoys routed through Wabt, SQLite with honey trap columns that trigger SqliteColumnEvaluationFailure on unknown functions like enclave_unseal_payload(), GGUF model metadata, Erlang BEAM chunks, EVM bytecode densified toward a 4 MiB input cap, PCAP files that blow past TSHARK_JSON_MAX_BYTES, and Go buildinfo mapped into an ELF section. Designed-for but not empirically verified paths include Python .pyc, DEX, IL2CPP, bplist, .NET, JVM, and ZIP containers — the README honestly notes, for instance, that APK resigning is unsupported, so the DEX shield cannot be validated end-to-end.
The honesty extends to a table of things bla explicitly does not claim. Ghidra decompilation depth, Frida/LLDB/GDB/Rizin live sessions, full Android APK pipelines, firmware containers, and GPU object formats like SPIR-V and CUDA fatbin are all listed as skipped or unverified, with the reasoning stated: they need native tooling or device attach that the maintainers did not run. This is a refreshing posture in a category where marketing claims usually outrun evidence, and it tells a professional evaluator exactly which assertions are load-bearing and which are aspirational.
Operationally, the tool is designed for the agentic workflow that modern development teams already use. After npx bla-agents setup registers the MCP server and skill with your coding agent, you can simply tell a tool like claude-code or cursor to "harden my software against REA" and the bla_harden MCP tool takes over. The pipeline auto-discovers common build outputs — dist/, build/, .asar, .wasm, .sqlite, model files — and runs an audit → protect → verify sequence. Explicit stage commands (audit, protect, verify, defend) exist for operators who want control over individual phases, documented in docs/cli-and-mcp.md.
Two install/invocation examples capture the practical surface: npx bla-agents setup for MCP registration, and npx bla-agents harden . for the one-command pass. A third command, npx bla-agents benchmark, runs the 14-target local showcase producing exposure scores, estimated token/cost multipliers, and measured runtime equivalence. The README is careful to label the benchmark's token and dollar figures as internal estimates derived from bla's catalog of REA limits, distinct from the empirical byte-level analyzer failures — and it explicitly warns that npm run verify:rea is a constant-drift harness that must never be cited as protection evidence. That kind of epistemic hygiene is rare and worth respecting when quoting numbers.
Those internal estimates are nonetheless striking. The latest local run on bla-agents v1.4.0 reports aggregate multipliers of roughly 612× in tokens and 292× in cost, with individual targets like the DX-Ball JavaScript sample estimated at 2822× token inflation and an Electron clipboard sample at 2532×. Exposure scores drop from the 80–98 range down to 2–9 out of 100 across all fourteen targets. The framing matters: this is about making automated analysis of your shipped code cost-prohibitive, not about classical cryptographic secrecy.
Environment requirements are modest but specific. Node.js 22.23.4+ or 24.x is recommended, partly because the red-team harness needs zlib.zstd. Optional native tooling — Wabt 1.0.42 for WASM decoding and tshark 4.4 for PCAP — unlocks full coverage, with soft-skips keeping CI green when they are absent. The empirical validation was recorded under Node v24.22.1, and the SQLite shield is capability-gated on Node 22. The project also maintains an impressive twenty-plus language translations of the README, suggesting a deliberately international audience.
From a defensive-detection standpoint, bla's output is observable in interesting ways. Analysts examining a hardening-protected artifact will encounter characteristic fingerprints: honey-trap column names, decoy export names in WASM custom sections, sentinel counts above 32, nesting depths beyond 32 levels, and headers near known budget limits like 16 MiB for .asar. Defenders on the other side of the fence — say, malware analysts triaging a suspicious sample — should be aware that these signatures can indicate either a vendor legitimately protecting IP or an actor trying to defeat automated analysis, and the distinction will hinge on provenance rather than the artifacts alone.
Where bla fits in an authorized workflow is clear: it belongs in the build and release pipeline of software vendors who ship analyzable artifacts — Electron desktop apps, WASM modules, embedded ML models, SQLite entitlement databases — and want to raise the cost of automated extraction of proprietary logic such as license validators. It is explicitly not a tool for protecting malware, and the project's DISCLAIMER.md frames it as defense of your own software only. For teams already using MCP-capable coding agents, the integration cost is essentially one command.
Caveats worth weighing before adoption: the protection is measured against one specific REA implementation and its documented budgets, so durable efficacy depends on how those limits evolve; several format shields remain designed-for rather than empirically validated; and runtime-equivalence testing is the operator's responsibility to confirm on their own stack despite the 14/14 benchmark result. Still, as a documented, measured, defensively-framed response to AI-driven reverse engineering, qybaihe/bla is one of the more rigorous entries in the emerging counter-REA category, and its evidence-first README sets a standard other tool authors would do well to copy.
qybaihe/bla.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.