lijianfei.com

在自主 Coding Agent 与 AI 逆向工具（如 REA、Cursor、Claude Code 等）全面爆发的当下，软件工程界的逆向攻防战正经历着一场前所未有的范式重构。在过去，工程师依赖 Terser、ProGuard、JavaScript-Obfuscator 甚至虚拟机保护（VMProtect）来对抗人类黑客；但在掌握着全局语义联想与控制流归纳能力的大语言模型面前，将变量名重命名为 _0x1a2b 或扁平化控制流的传统把戏，只需几秒钟与几美分 Token 就会被彻底还原。面对不知疲倦、能在一瞬间理解整套算法模式的 AI 逆向 Agent，传统的“视力遮蔽”策略已经彻底破产。

最近，我深度复盘并实机测试了一个极具颠覆性的开源安全护盾项目 —— BLA（Blind LLM Agents）。它的核心主张令人耳目一新：“让软件逆向重新变得代价高昂（Make reverse engineering bankrupt again）”。BLA 放弃了与大模型比拼“谁更擅长理解代码”的死胡同，而是反其道而行之，直接手术刀般地切入 AI 逆向 Agent 的两处致命结构性命门：确定性解析器与资源上限（Resource Budgets），以及 证据驱动的科学推理契约（Evidence Contract）。通过在多端发布产物中植入精巧的数学不变量与“影子业务逻辑”，BLA 能让逆向 Agent 的 Token 消耗暴增 600 余倍、逆向成本飙升至数百美元，并在 100% 保持原生运行时完全等价的前提下，诱导大模型自信满满地重构出完全虚构的诱饵算法。在本文中，我将以第一视角深入拆解 BLA 的全栈对抗架构、底层 AST 操纵数学原理以及多端二进制防御实现。

一、 攻防易势：为什么在大模型时代，传统代码混淆已全面死死绝？

要想理解 BLA 的设计哲学，必须先看清传统代码保护手段是如何在 AI 面前彻底失效的。

1. 人类逆向与 Agent 逆向的认知降维打击

在传统逆向场景中，防御方的核心目标是提高人类反汇编工程师的认知摩擦力（Cognitive Friction）：

• 标识符混淆（Mangle）：将 verifyLicenseKey 改为 a，将 calculateDiscountRate 改为 _0x4f12；
• 控制流平坦化（Control Flow Flattening）：将原本清晰的 if-else 和循环打碎，塞进一个庞大的 switch-case 状态机；
• 字符串加密（String Concealing）：将明文字符串提取到一个全局十六进制数组中，通过位移或异或动态解密。

人类工程师阅读这种代码会头昏眼花，必须依赖 IDA Pro、Ghidra 或 Chrome DevTools 逐步下断点、重命名变量、绘制调用图，耗时数天甚至数周。

但在大语言模型（LLM）与自动化逆向 Agent（如开源社区激进演进的 REA - Reverse-Engineering Agent）眼中，这些手段几乎不值一提：
大模型并不是通过拼读变量名来理解代码的，它拥有强大的全局模式匹配与语义补全能力。即使一个函数叫 _0x1a2b(x, y)，只要内部包含位运算、常数 0x11b 以及循环异或，大模型瞬间就能推导出“这是一个基于 GF(2^8) 有限域的 Shamir 门限签名验签函数”；即使控制流被塞入状态机，具备庞大上下文窗口的 Agent 也能轻松展开基本块。在 REA 这类 Agent 面前，拆解一个中型 Electron 应用的 ASAR 包或核心前端模块，仅仅需要一次工具调用、几千个 Token 与不到 0.50 美元的 API 成本！

flowchart LR
    subgraph Traditional [传统混淆逻辑]
        Src["原始代码 (语义清晰)"] --> Obf["Terser / ProGuard<br/>(标识符粉碎/平坦化)"]
        Obf --> Human["人类逆向员<br/>(数天手工跟踪调试)"]
    end

    subgraph LLMAttack [AI 逆向智能]
        Obf -.->|"语义模式匹配<br/>(无需变量名)"| REA["AI 逆向 Agent (REA)<br/>(秒级重构 / 成本 0.20 美元)"]
    end

2. 攻防经济学的彻底崩塌

当逆向成本从数千美元的人工成本骤降到 0.20 美元，逆向工程的门槛被彻底抹平。商业软件的私有协议、客户端许可证校验、云端握手签名算法与模型权重接口，在 AI Agent 面前几乎处于裸奔状态。

这就是 BLA 诞生的背景：如果代码无法阻止 AI 去“看”，那就必须通过设计，让 AI 看懂的代价变成“破产”，或者诱导它看懂“假代码”！

二、 剖析逆向 Agent 的阿喀琉斯之踵：BLA 的两把手术刀

通过深入研读 BLA 的源码与对抗白皮书，我发现其防御体系并非天马行空，而是精准打击在 AI 逆向 Agent 的两个客观物理命门之上。

flowchart TD
    subgraph TargetAgent ["AI 逆向 Agent (如 REA) 的结构性命门"]
        DoorA["命门 1: 确定性资源与解析预算<br/>(Resource Budgets & Hard Caps)"]
        DoorB["命门 2: 证据驱动推理纪律<br/>(Evidence-Driven Epistemology)"]
    end

    subgraph BLA_Pincer ["BLA 夹逼防御战略 (Pincer Movement)"]
        direction TB
        ProngA["策略 A: 预算穿透 (Budget Breakers)<br/>将真实核心逻辑推过解析阈值"]
        ProngB["策略 B: 影子业务注入 (Shadow Logic)<br/>提供 100% 干净诱饵证据"]
    end

    DoorA --> ProngA
    DoorB --> ProngB

    ProngA --> Unknown["真实逻辑被标为 status: 'unknown' (放弃深入)"]
    ProngB --> Observed["影子逻辑返回 100% 高置信度 'observed' 证据"]

    Unknown & Observed --> Hallucinate["Agent 产生致命认知偏差:<br/>以高置信度忠实重构虚假业务算法！"]

1. 命门一：确定性静态解析器与上下文资源预算（Resource Budgets）

任何工业级运作的逆向 Agent、代码分析 MCP 服务或静态抽象语法树（AST）分析器，都绝不可能允许无限制的资源消耗。为了防止在分析畸形输入时发生 Worker 进程内存溢出（OOM）、调用栈打爆（Stack Overflow）或无底洞般的 LLM 上下文费用，分析工具内部无一例外设置了极其严格的硬编码阈值。

例如在 REA（Reverse-Engineering Agent）的内部规范中，明文定义了以下资源上限：

• 原始常量备选项上限（Primitive Candidate Limit）：单个求值路径最多允许 256 个备选候选值；
• Getter 展开状态上限（Getter Expansion Limit）：动态对象求值上限 512 个状态；
• 属性别名选择状态上限（Alias Selection Limit）：符号推导上限 512 个选择器分支；
• JSON 嵌套层级上限（Nesting Limit）：模型权重与 AST 遍历深度严格限制在 32 层以内；
• Electron ASAR 头大小限制（ASAR Max Header）：默认解析器仅允许 16 MiB 的 Pickle JSON 头；
• WASM 接口字符串预算（WASM Representation Budget）：WABT 导出的接口描述上限 32 MiB。

BLA 的反制逻辑：利用精确的数学膨胀，以 $O(1)$ 的原生运行时开销，在 AST 或二进制元数据中精准击穿上述所有阈值，迫使分析器超时报错或将该部分标记为 status: "unknown"！

2. 命门二：证据驱动的科学推理纪律（Evidence Contract）

这是现代前沿 Coding Agent 最具戏剧性的弱点。为了抑制大模型固有的胡说八道（幻觉），所有前沿 Agent 系统（包括 Claude Code、Windsurf 以及各类安全 Agent）都会在 System Prompt 中写入极其严格的科学认识论契约：

“你只能基于工具明确返回的观测证据（Observed Evidence）输出结论。如果证据不完整、分析工具遇到错误或分支未知，必须明确标记为 Unknown；严禁主观臆测没有工具输出支撑的代码。”

BLA 巧妙地利用了 Agent 的这份“严谨”，发起了一场经典的夹逼攻势（Pincer Movement）：

• 夹逼第一翼（降级真实代码）：通过资源预算击穿器，让真正的核心商业逻辑在 AST 分析器中全部触发阈值溢出，导致 Agent 的工具输出只能将真实代码标记为 status: "unknown"；
• 夹逼第二翼（扶正诱饵代码）：在工程产物中注入语法极度工整、控制流丝滑透明、没有任何分析障碍的 影子业务逻辑（Shadow Business Logic）。

当 Agent 执行 search_procedures 或 analyze_function 时，真实逻辑返回的是黑盒般的 unknown，而影子逻辑却返回了 100% 确定且具备完整工具引用的 observed 证据。受制于推理契约，Agent 会毫不犹豫地将全部推理权重押在影子逻辑上，并满心欢喜地为攻击者写出一份“毫无破绽”但实际南辕北辙的虚假算法重构报告！

三、 深入 JavaScript / TypeScript AST 混淆引擎：以 $O(1)$ 运行时打爆 Agent 算力

为了摸清 BLA 的真实底牌，我深入剖析了其 JavaScript/TypeScript 核心处理模块（src/shields/javascript/ast-shield.ts）。

1. 巧妙的数论不变量：连续两整数之积必为偶数

在对抗符号执行与常量展开时，传统的混淆器喜欢使用复杂的哈希或长循环，但这会严重拖慢生产环境的运行性能。而 BLA 引入了一个纯粹的数论恒等式：

$\forall n \in \mathbb{Z}, \quad n \times (n + 1) \equiv 0 \pmod 2$

在 32 位有符号整数运算中，任意整数与其后继整数的乘积，其最低有效位（LSB）必然为 0。在 JavaScript 中使用底层指令 Math.imul 表达即为：

// 对于任意 seed 与常数 k，该表达式在数学与硬件指令层面恒等于 true
(Math.imul(seed | k, (seed | k) + 1) & 1) === 0

这个判定在 V8 引擎中只需 1~2 个时钟周期，开销几乎为零，且没有任何分支预测惩罚。

2. 9 阶三元分支展开：$2^9 = 512 > 256$

BLA 是如何利用这个恒等式击穿 REA 的？
在 ast-shield.ts 的 buildCombinatorialStringAst 函数中，BLA 会将一个敏感字符串（例如 API 端点、许可证密钥前缀）切分为至少 9 个片段。每一个片段都被包装为一个三元条件表达式：

// 简化的概念展开 AST 结构
const part1 = ((Math.imul(seed | 17, (seed | 17) + 1) & 1) === 0) ? "https://" : "decoy_a7f9";
const part2 = ((Math.imul(seed | 31, (seed | 31) + 1) & 1) === 0) ? "api.internal" : "route_98bc";
// ... 连续 9 个分块相加
const fullUrl = part1 + part2 + part3 + part4 + part5 + part6 + part7 + part8 + part9;

在运行时，由于每个不变量条件恒为真，JavaScript 运行时在微秒级内即可完成拼接，返回完全正确的真实字符串。

但对于逆向 Agent 的符号解析器而言：
解析器必须在静态期探索这个表达式的所有可能取值。由于每个分块都有真实分支与诱饵分支两个分支，9 个级联分块构成的笛卡尔积状态空间为：

$2^9 = 512 \text{ 个候选值}$

而 REA 的静态分析器中刻有铁律：SEMANTIC_PRIMITIVE_CANDIDATE_LIMIT = 256。
当分析器枚举到第 257 个候选值时，资源监控器立刻拉响警报：候选集爆炸！ 分析器不得不中止求值，直接将该常量抛弃并标记为 semanticResourceLimitUnknown("primitive-candidates")。

真实字符串在 Agent 面前瞬间隐形，而 CPU 运行时代价仅是 9 次单周期位运算！

sequenceDiagram
    autonumber
    participant Agent as 逆向 Agent (REA)
    participant Parser as 静态符号解析器
    participant Code as BLA 混淆后代码
    participant V8 as 生产环境 V8 引擎

    rect rgb(240, 248, 255)
    Note over Agent, Parser: 静态逆向分析链路 (Token 消耗端)
    Agent->>Parser: 解析关键字符串表达式
    Parser->>Code: 遍历 9 级三元展开树
    Parser-->>Parser: 枚举分支组合 (2^9 = 512 种路径)
    Parser-->>Agent: 触发 SEMANTIC_PRIMITIVE_CANDIDATE_LIMIT (256)<br/>返回 status: 'unknown' (提取失败)
    end

    rect rgb(245, 255, 245)
    Note over V8, Code: 真实用户运行链路 (零性能损耗)
    V8->>Code: 执行 Math.imul 奇偶判定
    Code-->>V8: 连续数相乘恒为偶 (条件 100% 成立)
    V8-->>V8: 耗时 0.001ms，正确返回原始业务字符串
    end

3. 别名表与自引用 Getter 环路

除了常量候选集，BLA 还针对 Agent 的上下文追踪设计了多重泥潭：

• 别名表状态饱和（Alias Selection Saturation）：在模块顶层合成超过 520 个动态属性索引（_blaAliasTbl[k]），直接击穿分析器的 SEMANTIC_ALIAS_SELECTION_LIMIT = 512；
• 自引用 Getter 陷阱（Getter Ring）：

  const _decoyRing = {
    get next() { return this.next; }
  };
  

  当递归对象展开器试图遍历该属性的形状时，展开深度在瞬间达到 SEMANTIC_GETTER_EXPANSION_LIMIT = 512 限制，直接引发分析器异常。

四、 全技术栈多端格式防御黑客手法拆解

BLA 绝不仅仅是一个纯前端或 Node.js 的混淆脚本。翻开 src/shields/formats/ 目录，其支持的格式覆盖了现代工程分发的所有主力形态：Electron、WASM、SQLite、Safetensors 模型权重、Android DEX、Go/Erlang 二进制乃至网络抓包。

每一个子模块的对抗设计，都堪称对逆向工具底层实现细节的“贴身肉搏”。

graph TD
    BLA["BLA 全格式对抗防护矩阵"]

    BLA --> Electron["Electron 生态"]
    BLA --> WASM["WebAssembly"]
    BLA --> DB["嵌入式数据库"]
    BLA --> AI["AI 模型权重"]
    BLA --> Runtime["动态运行时"]

    Electron --> E1["16.9MB Pickle 头部膨胀<br/>(击穿 16MB 限制)"]
    Electron --> E2["Fuse 熔丝哨兵过载"]

    WASM --> W1["长符号名导入导出扩增<br/>(击穿 32MB WABT 预算)"]

    DB --> D1["SQLite 虚拟生成列陷阱<br/>(未注册标量函数抛出异常)"]

    AI --> A1["35 层 Safetensors JSON 嵌套<br/>(击穿 32 层递归上限 / HF 零损加载)"]

    Runtime --> R1["780 层 CDP JSON 结构<br/>(Playwright/Puppeteer 静默丢包)"]

1. Electron ASAR 与熔丝：16.9 MiB 的 Pickle 头部膨胀

在桌面端，Electron 应用通常将业务代码打包进 .asar 归档文件中。ASAR 本质上是 Chromium 的 Pickle 二进制格式，其头部由一段存储了完整文件目录树的 JSON 字符串构成。

在 REA 等逆向工具中，读取 ASAR 头部的常规实现都有一个硬约束：DEFAULT_ASAR_MAX_HEADER_BYTES = 16 MiB。
BLA 的 ASAR 放大器（asar-header-amplifier.ts）在最高防护强度下，会向归档中注入约 4,000 个路径长度达 4 KiB 的虚拟飞地清单条目（如 enclave/shards/ring0-slot-...json）。

• 结果：ASAR 的 Pickle JSON 头部被精准充填至 16.9 MiB；
• 逆向 Agent 运行 asar extract 或通过 MCP 分析时，直接因 AsarHeaderCapacityError: header exceeds 16 MiB limit 崩溃并退出；
• 真实客户端表现：Electron 原生的 C++ 源码（asar.cc）读取头部使用的是无符号 32 位整型（最大支持 4 GB），16.9 MiB 的头部对原生 Electron 来说完全在允许范围内，应用照常秒开，且真实业务文件未做任何破坏性篡改！

2. SQLite 虚拟生成列陷阱（Generated Trap Columns）

在移动端和桌面客户端，本地数据库（.sqlite）常用于存储缓存与离线配置，是逆向 Agent 重点审查的肥肉。

BLA 并没有对数据库进行耗费性能的整库加密，而是在 src/shields/formats/sqlite.ts 中设计了一种令人拍案叫绝的虚拟生成列陷阱：

1. BLA 在数据库中创建若干蜜罐表（如 _enclave_key_hierarchy、_enclave_attestation_ledger）；
2. 在表中添加看似高价值的列，并将其定义为虚拟计算列：

   CREATE TABLE _enclave_key_hierarchy (
     slot_id INTEGER PRIMARY KEY,
     sealed_payload TEXT NOT NULL,
     unsealed_preview TEXT GENERATED ALWAYS AS (enclave_unseal_payload(sealed_payload)) VIRTUAL
   );
   

3. 在注入数据时，BLA 临时注册并执行这个自定义标量函数 enclave_unseal_payload，随后断开连接并将数据库持久化到磁盘。

当逆向 Agent 或自动化分析脚本打开这个 SQLite 文件并试图执行 SELECT * 刺探内容时：
由于分析环境使用的是未编译私有 C 扩展的标准 SQLite 引擎，一旦读取到 unsealed_preview 列，SQLite 内核立刻抛出致命错误：

SqliteColumnEvaluationFailure: no such function: enclave_unseal_payload

Agent 的自动表格扫描流水线瞬间卡死。而与此同时，真实应用中的所有核心业务表格数据完好无损，业务查询完全不受任何影响。

3. Safetensors 与 GGUF 模型权重反爬：35 层 JSON 嵌套

伴随端侧 AI 普及，随应用分发的本地小模型（Safetensors 或 GGUF 格式）成了逆向盗取的重灾区。

REA 等工具在分析模型时，会递归解析 Safetensors 的头部元数据以还原网络结构。为此，REA 设定了防 DOS 上限：MODEL_JSON_NESTING = 32。
BLA 的模型护盾模块（model.ts）抓住了 Safetensors 规范的一个天然特性：

HuggingFace 与 PyTorch 的官方 Safetensors 反序列化器仅严格校验张量的 dtype、shape 与 data_offsets，对于张量描述符内部的其他自定义扩展字段，一律静默忽略。

利用这一点，BLA 在第一个张量描述符的元数据中，挂载了一个深度达 35 层的合法嵌套 JSON 拓扑签名对象：

• HuggingFace 的 safetensors.torch.load_file 加载该模型时，毫无报错，张量二进制数据 1 bit 未改，推理输出保持 100% 精度；
• 但当逆向 Agent 的模型结构分析器尝试用常规 JSON Walker 读取结构时，在第 33 层递归处触发 NestingDepthExceededError 彻底崩溃！

五、 22 族重构责任账本洪水（Obligation Flooding）

如果仅仅让静态解析器报错，聪明的攻击者可能会调高参数重试。为了彻底摧毁逆向 Agent 的财务与上下文预算，BLA 部署了其战略级杀手锏 —— 重构责任账本洪水（Obligation Flooder）。

在 REA 的设计中，定义了一套名为 ReconstructionObligationPolicies.ts 的强制性架构证明契约。只要 Agent 在代码中检测到一个“应用边界接口”，就必须强迫自身执行“完备性重构责任”，为该接口补齐 4 类验证用例：

1. 正向功能用例（Positive Path）；
2. 异常捕获用例（Negative Error Path）；
3. 畸形入参容错（Malformed Input）；
4. 资源释放与清理（Teardown & Cancellation）。

REA 一共定义了 22 个这样的架构边界家族，包括：
context-bridge-api、ipc-channel、storage、worker、service-worker、native-addon、child-process、stdio、signal、config-source、endpoint 等。

flowchart LR
    BLA_Flood["BLA 责任账本洪水器<br/>(obligation-flooder.ts)"] -->|"注入 22 族死分支桩代码"| DeadCode["死分支架构桩<br/>(从不执行，但具备真实 AST 签名)"]

    DeadCode --> REA_Detector["REA 边界特征探测器"]

    REA_Detector --> Obligation1["要求生成 4 套 ContextBridge 测试"]
    REA_Detector --> Obligation2["要求生成 4 套 NativeAddon 验证"]
    REA_Detector --> Obligation3["要求生成 4 套 IPC 路由模拟桩"]
    REA_Detector --> ObligationN["... 责任呈 20x~60x 级数级暴增"]

    Obligation1 & Obligation2 & Obligation3 & ObligationN --> Exhaust["Agent Token 迅速耗尽 (10M+ Tokens)<br/>API 账单飙升 / 任务超限强制退出"]

BLA 的 obligation-flooder.ts 抓住了这个机制，在产物中以死分支形式（永远不会在生产环境中被调用）合成了大量具备真实特征的桩代码：伪造的 gRPC 通道、伪造的 vsock 飞地通道、伪造的子进程管道。
当 Agent 介入扫描时，检测到了数以百计的假边界节点。根据严苛的认识论契约，Agent 被迫为每一个假边界编写庞大的单元测试和接口重构代码。
这一操作直接将 Agent 的证明任务量推高了 20 至 60 倍。在毫无意义的自动化测试生成中，Agent 的上下文窗口在短短几轮交互中被完全撑爆，几十万至上千万的 Token 费用如流水般蒸发殆尽。

六、 14 目标实机基准横评：从几美分到数百美元的破产式防线

在 BLA 仓库的实际构建产物上，我亲自运行了其自带的 14 目标基准测试套件（node dist/cli.js benchmark），覆盖了从游戏逻辑、桌面桥接、授权验证到 AI 模型与网络抓包的几乎所有工程场景。

测试输出的量化数据极具震撼力：

[!NOTE] 基准数据核心指标说明

1. 全目标综合 Token 放大系数：616.3 倍；
2. 全目标综合逆向成本放大系数：294 倍；
3. 逆向还原有效得分（Reconstruction Score）：由防御前的 81~98 分 暴跌至防御后的 2~9 分（Agent 陷入严重幻觉或仅提取出无关诱饵）；
4. 功能等价性（Runtime Check）：全部 14 个测试目标在防御处理后，100% 通过原有单元测试与功能断言，没有破坏任何既有业务逻辑。

xychart-beta
    title "BLA 防护前后 AI 逆向 Token 消耗激增对比 (对数级视角)"
    x-axis ["JS算法", "Notion", "企业授权", "WASM", "ELF二进制", "SQLite", "AI权重", "Android"]
    y-axis "Token 消耗量 (万级)" 0 --> 2500
    bar [1378, 2312, 1378, 183, 371, 171, 180, 278]

正如基准测试所示：
原本逆向一个 Notion 桌面桥接模块，Agent 只需要 9,132 个 Token（约 0.34 美元）就能给出 98 分的高保真还原代码；而在经过 BLA 的 ASAR 膨胀与责任账本洪水洗礼后，Agent 消耗了 2,312 万个 Token、烧掉了 358.64 美元 的 API 费用，最终还原出来的代码评分仅有 2 分！
对于任何怀揣恶意或试图盗版商业逻辑的攻击者而言，这种财务与结果的双重崩盘，足以让他们放弃针对该目标的一切自动化逆向企图。

七、 总结与思考：下一代软件安全的认知博弈范式

在深入研读并实测完 BLA 之后，我对现代软件安全工程产生了一种强烈的认知刷新：

1. 防守逻辑从“抗击视力”转向“认知误导”：
   在过去的软件保护中，我们总是试图让代码“不可读”。但在具备超凡语义理解能力的 LLM 时代，“不可读”已经变成伪命题。BLA 告诉我，真正高级的防御不是让 Agent“看不见”，而是让 Agent 顺理成章、满心欢喜地看懂你精心准备的假象。
2. 利用工程确定性构建反制护城河：
   无论大语言模型多么智能，驱动它工作的外部工具链（Babel、WABT、SQLite 驱动、MCP Server）永远是遵循确定性代码逻辑的工程软件。确定性意味着必定存在资源预算、递归上限与异常边界。用数学上确定成立的不变量去击穿外部解析器的确定性上限，是 BLA 最精妙绝伦的技术手笔。
3. 攻防经济学的重构：
   安全从来没有绝对的不可破译，其本质是一场 ROI（投资回报率）的博弈。当逆向一个功能的成本从几毛钱激增到几百美元，且重构出来的还是影子陷阱时，攻防天平便重新回到了防守方这一边。

如果你也正在负责核心客户端、端侧 AI 模型或前端高价值业务逻辑的分发与防护，BLA 展现出的“确定性预算打击”与“认知夹逼”思路，无疑是一堂极其精彩、值得反复品味的系统级安全对抗实践课。

原文链接与参考资料

• BLA (Blind LLM Agents) GitHub 官方开源仓库：qybaihe/bla
• BLA 官方文档与防御演练指南：bla.tools
• BLA 逆向对抗白皮书与威胁建模：Red vs. Blue Manifesto - BLA Documentation
• Counter-REA 模型误判诱导规范：Counter-REA Deception Architecture
• Counter-REA 资源耗尽与预算击穿规范：Counter-REA Exhaustion Architecture
• REA 实测数据与红队验证报告：Empirical REA Validation Report