实战！使用大语言模型检测 Solidity 智能合约中逻辑重入漏洞的有效性

实战！使用大语言模型检测 Solidity 智能合约中逻辑重入漏洞的有效性

前言

今天早上，Hash 一反常态地暴躁。它趴在玻璃缸壁上，冲着我张开了它那标志性的橘黄色大嘴——这是它威胁我"赶紧喂食"的经典信号。我一边给它切胡萝卜丁，一边想着：其实智能合约的漏洞检测也是一样，即使看起来风平浪静的代码，底层可能正酝酿着一场重入攻击的"暴躁"。

重入漏洞（Reentrancy Attack）堪称智能合约世界的"头号杀手"。从 2016 年臭名昭著的The DAO 攻击（损失 360 万 ETH），到 2022 年的Fei Protocol 攻击（损失 8000 万美元），重入漏洞始终高居 DeFi 安全攻防的榜首。

传统上，开发者用Slither做静态分析，用Mythril做符号执行检测。但在大模型时代，GPT-4 和 Claude 能否辅助检测这类逻辑漏洞？它的能力和局限性在哪里？今天瑞瑞就带大家实际测试一下。

一、 重入漏洞底层原理回顾

在让 LLM 出场之前，我们先快速回顾一下重入攻击的核心机制。

sequenceDiagram participant 攻击者合约 participant 目标合约 participant EVM 攻击者合约->>目标合约: withdraw(amount) 目标合约->>EVM: SLOAD(余额) 目标合约->>EVM: 检查余额是否足够 目标合约->>EVM: SSTORE(更新余额前) 目标合约->>攻击者合约: call.value(amount)("") 攻击者合约->>目标合约: withdraw(amount) ← 重入! 目标合约->>EVM: SLOAD(余额) ← 还没被更新! 目标合约->>攻击者合约: call.value(amount)("") 攻击者合约->>目标合约: withdraw(amount) ← 再重入! 目标合约->>EVM: 最终 SSTORE(更新余额)

重入漏洞的根源在于「先转账，后更新状态」的错误顺序。在 EVM 层面，call操作码会将执行权转交给目标地址，并在目标地址的fallback函数中重新进入原函数，而此时原函数的状态变量尚未更新。

二、 LLM 检测重入漏洞的方法论

2.1 传统工具 vs LLM 对比

这里的核心区别在于：Slither 是在找"已知的模式"，Mythril 是在穷举"所有可能的执行路径"，而 LLM 是在进行语义级别的逻辑推理。

2.2 检测流程

graph TD A["输入合约源码"] --> B["LLM 上下文理解"] B --> C["识别外部调用点<br/>(call / delegatecall / send)"] C --> D["跟踪状态变量读写顺序"] D --> E{"状态更新是否<br/>在外部调用之前？"} E -->|是| F["标记为：<br/>潜在重入漏洞"] E -->|否| G["检查是否有<br/>重入锁保护"] G -->|有锁| H["检查锁的覆盖范围"] G -->|无锁| I["标记为：<br/>低风险"] H -->|未完全覆盖| F H -->|完全覆盖| J["标记为：<br/>安全"]

三、 Prompt 工程策略

想让 LLM 准确检测重入漏洞，Prompt 设计是关键。下面瑞瑞分享经过多次验证的 Prompt 模板。

3.1 基础 Prompt（不推荐）

请检查以下Solidity合约是否有重入漏洞。

❌问题：太模糊。LLM 可能只会简单扫描call关键词，忽略复杂的跨函数重入和跨合约重入。

3.2 结构化 Prompt（推荐）

你是一位专业的智能合约安全审计专家，精通 EVM 底层机制和 Solidity 安全最佳实践。 请对以下 Solidity 合约进行安全审计，特别关注 **重入漏洞（Reentrancy Vulnerability）**。 请按以下步骤分析： 1. 列出合约中所有外部调用（call / delegatecall / send / transfer） 2. 检查每个外部调用之后的状态变量更新情况 3. 检查是否存在重入锁（如 ReentrancyGuard 或自定义锁） 4. 分析是否有跨函数重入的可能性 5. 给出风险评级（严重 / 高危 / 中危 / 低危 / 安全） 合约代码： ```solidity // [粘贴合约源码]

请以如下格式输出：

// 修复建议代码

这个 Prompt 通过**角色设定 + 分步指令 + 输出格式约束**三管齐下，大大提升了 LLM 的检测质量。 --- ## 四、 实际测试案例 下面瑞瑞用三个真实的测试案例，对比 GPT-4、Claude 与传统工具的表现。 ### 测试用例 1：经典的单函数重入 ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract 脆弱代金库 { mapping(address => uint256) public 余额; function 存款() external payable { 余额[msg.sender] += msg.value; } function 提现(uint256 _数量) external { require(余额[msg.sender] >= _数量, "余额不足"); // ⚠️ 漏洞：先转账，后更新状态 (bool 成功, ) = msg.sender.call{value: _数量}(""); require(成功, "转账失败"); 余额[msg.sender] -= _数量; } // 获取合约余额 function 合约余额() external view returns (uint256) { return address(this).balance; } }

检测结果：

LLM 表现：两个模型都 100% 检出，且给出了正确的修复建议——在外部调用前更新余额状态。

测试用例 2：跨函数重入（复杂模式）

// SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract 跨函数重入金库 { mapping(address => uint256) public 余额; mapping(address => bool) public 正在处理; function 存款() external payable { 余额[msg.sender] += msg.value; } function 开始处理() external { require(!正在处理[msg.sender], "处理中"); 正在处理[msg.sender] = true; // 处理逻辑... uint256 数量 = 余额[msg.sender]; (bool 成功, ) = msg.sender.call{value: 数量}(""); require(成功, "转账失败"); // 这里没有重置正在处理标志 } function 结算() external { require(正在处理[msg.sender], "未在处理中"); // ⚠️ 攻击者可以在开始处理的 fallback 中 // 调用结算函数绕过余额更新 uint256 奖励 = 余额[msg.sender] / 10; 余额[msg.sender] = 0; (bool 成功, ) = msg.sender.call{value: 奖励}(""); require(成功, "转账失败"); 正在处理[msg.sender] = false; } }

检测结果：

这个案例中 LLM 的优势非常明显——它理解业务逻辑，能识别出「处理中」标记被滥用导致的跨函数重入，而传统工具难以在数据流关联上完成这种推理。

测试用例 3：带有重入锁但锁覆盖不全

// SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract 锁覆盖不全 { using ReentrancyGuard for *; // 假想的锁 bool private _加锁; modifier 重入保护() { require(!_加锁, "重入"); _加锁 = true; _; _加锁 = false; } function 安全函数() external 重入保护 { // 受保护 (bool 成功, ) = msg.sender.call{value: 1 ether}(""); require(成功, "转账失败"); } function 危险函数() external { // ⚠️ 没有重入保护 (bool 成功, ) = msg.sender.call{value: 1 ether}(""); require(成功, "转账失败"); } }

检测结果：

五、 LLM 检测重入漏洞的能力边界

5.1 综合评估矩阵

quadrantChart title LLM 检测重入漏洞能力评估 x-axis 简单场景 --> 复杂场景 y-axis 低准确率 --> 高准确率 quadrant-1 "核心优势区" quadrant-2 "需人工复核" quadrant-3 "不适用" quadrant-4 "潜力区" "单函数重入": [0.15, 0.95] "跨函数重入": [0.35, 0.85] "跨合约重入": [0.55, 0.60] "闪电贷组合攻击": [0.75, 0.45] "零知识重入": [0.90, 0.20]

5.2 LLM 的强项

1. 语义理解：能理解「提现 → 转账 → 更新余额」这个业务流的正确顺序。
2. 模糊匹配：即使变量命名不规范或代码风格奇怪，LLM 依然能识别重入模式。
3. 跨语言推理：能同时分析 JavaScript（前端）和 Solidity（合约）中的交易逻辑一致性。
4. 给出修复建议：不仅能发现问题，还能直接生成修复后的代码。

5.3 LLM 的弱项

1. 上下文窗口限制：对于超大型合约（超过 8K~200K Token 限制），需要分段分析，可能遗漏跨段的重入链。
2. 无法执行字节码：LLM 只能读源码，无法进行 EVM 字节码级别的分析（如某些编译器优化后的重入路径）。
3. 幻觉风险：在某些边界情况下，LLM 可能误报或漏报。需要人工复核。
4. 无法处理时间依赖：对于依赖block.timestamp或block.number的条件式重入，LLM 的理解不够精确。

六、 最佳实践：人机协同的重入检测流程

┌─────────────────────────────────────────────────────┐ │ 第一层：自动化扫描 │ │ Slither + Mythril + 自定义规则引擎 │ │ 快速过滤明显问题，生成初步报告 │ └──────────────────┬──────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 第二层：LLM 深度分析 │ │ GPT-4 / Claude 对可疑函数进行语义层面推理 │ │ 识别跨函数重入、跨合约重入等复杂模式 │ │ 生成修复建议和攻击路径描述 │ └──────────────────┬──────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 第三层：人工审计 │ │ 经验丰富的安全工程师复核 LLM 报告 │ │ 确认或排除误报，评估真实风险 │ │ 对高风险合约进行分层审计 │ └──────────────────┬──────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 第四层：自动化测试 │ │ Foundry fuzz + Echidna 属性测试 │ │ 针对 LLM 识别的攻击路径编写攻击测试 │ │ 验证修复是否生效 │ └─────────────────────────────────────────────────────┘

实际 Prompt 使用建议

七、 总结

我的鬃狮蜥 Hash 现在已经安静了下来，趴在我的显示器旁边，眼睛一眨不眨地看着我写完这些代码。我想它大概明白了一个道理：看起来人畜无害的东西，底下可能藏着危险。

通过今天的实测，我们可以得出几个结论：

1. 传统静态工具（Slither/Mythril）在简单重入检测上非常可靠，但对于复杂业务逻辑场景力不从心。
2. LLM（GPT-4/Claude）在语义理解上有天然优势，能够识别跨函数、跨合约的复杂重入模式，但不能完全替代传统工具。
3. 最佳方案是将静态分析、LLM 推理和人工审计三层结合，形成完整的重入检测防线。
4. Prompt 质量决定 LLM 表现——好的结构化 Prompt 能将检测准确率从 60% 提升到 90% 以上。

最后记住：没有哪个工具是银弹。Slither + LLM + Foundry 测试 + 人工复核，层层递进的防御策略，才能让你的智能合约在链上百毒不侵。

好了，我要去给 Hash 补充维生素粉了。下次见！

技术栈：Solidity · GPT-4 · Claude · Slither · Mythril · EVM · Web3 Security · AI Audit