qybaihe/bla

如果你会发布编译后的 bundle 或 Electron 产物，又不希望 AI 智能体轻易拆开，BLA 值得看一眼；但请把它当作对抗性威慑实验，而不是成熟的安全控件——它上线仅两天，且除 JS 等少数格式外，多数防护尚未对真实 AI 智能体验证。

解决什么问题

你手里有一个要发布的产物——Electron 应用、JS bundle 或 WebAssembly 模块——想让它内部逻辑不那么容易被低成本提取。逆向工程智能体（REA）用一条命令就能打开产物、遍历其结构。BLA 改变的是构建产物这一步：对准备发布的目录跑一次加固，产物再被打开时会带有植入的诱饵和被放大的结构，而不是干净的攻击面。用户运行时行为不变，但分析器拿到的清单会被截断、变得含糊，或者直接撞上预算上限。

有什么不同

BLA 主要利用分析智能体的资源上限，而不只是传统混淆。它分三层：Poison（格式合法的诱饵、蜂蜜元数据和诱饵控制流）、Exhaust（把头部、嵌套层级和接口清单推到 REA 记录的预算之外）、Hallucinate（让分析器留下被截断的清单和模糊的岔路）。README 报告了在 Go buildinfo（1 MiB 上限）、Erlang BEAM chunk 数量和 EVM 字节码输入大小上触发的真实 REA 预算失败，并附有本地 redteam:rea 运行得到的字节级错误信息，见实证验证报告。这个关卡很重要：作者明确说明常量漂移检查 verify:rea 不能作为防护证据，14 个目标 benchmark 的 token/费用倍率也只是内部估算，而非实测防护效果。

代价在于覆盖范围和可信度。已验证的格式是 JavaScript/TypeScript、Electron .asar、Electron fuses 和 WASM；Ghidra/原生反编译、Frida/LLDB/GDB/Rizin 会话、JADX/APK 流程（不支持 APK 重签名）和固件容器虽有设计，但这里未对真实 REA 验证。运行时等价性按 benchmark 目标逐项检查，但没有任何保证说未来的分析器不能针对这些诱饵做适配。

谁值得试

适合：发布 Electron 或 JS/WASM 产品、希望抬高自动分析成本，并且愿意每次发布都重跑验证的团队。不适合：保护原生二进制或 Android APK、并期待得到同等验证效果的人；或者需要经过审计、可长期依赖的安全控制的人——那些层有单元测试，但 README 明确标注未对真实工具跑通。如果不想走一条命令的路径，README 也在CLI 与 MCP 文档中提供了 audit/protect/verify/defend 分阶段流程。

使用条件与边界

推荐运行时是 Node.js ^22.23.4 || 24.x；Node 22.23+ 是跑 REA 红队探测所需，可选的 Wabt 和 tshark 用于解锁 WASM/PCAP 的实证检查，而非防护本身。保护文件并不需要 Ghidra、Hopper、IDA 或 Wabt。初始化用 npx bla-agents setup 把 MCP server 或 SKILL.md 技能注册给 Claude Code、Cursor、Codex、Gemini CLI 等编程智能体。

更大的限制是日常维护：每次发布都需要重新加固并验证，能依赖的结论只限于你自己跑 redteam:rea 复现出来的部分。较旧或未验证的格式，在有对应报告之前都应视为未证实。

HotRepo 点评

仓库只有两天历史；HotRepo 在 2026-10-28 的新项目榜（TypeScript）记录到它排第 25、共 114 颗星——这只是一个快照，不是单日增长数据。由于只有一个记录日期，还无法判断其热度能否持续。采用前，请先确认你的产物格式出现在项目 README的“实证验证”表中，而不是“设计了但未验证”的列表里。