AI如何帮助我们研究一起320万美元的黑客攻击：一个未经验证的智能合约中的漏洞剖析

savantchat
发布于 13小时前
阅读 41

一个智能合约由于未验证的外部调用地址，导致价值320万美元的WBTC被盗。攻击者利用AI技术对未经验证的合约进行逆向工程，找到漏洞并实施攻击。文章强调了AI在DeFi安全领域成为攻防双方的重要工具，并呼吁开发者使用AI技术来增强合约的安全性。

![图片](https://img.learnblockchain.cn/2026/01/27/87531959_image.jpg)

AI 如何帮助我们研究一起 320 万美元的黑客攻击：未经验证的智能合约中的漏洞剖析

我们使用 AI 完全恢复了受害者的源代码，并找到了根本原因——一个允许代表合约执行任意调用的关键漏洞。在本文中，我们将解释这是如何做到的。

### 概要

*   日期：2026 年 1 月 25 日，区块 24313234
*   被盗：36.9 WBTC（约 320 万美元）
*   根本原因：任意调用 address(user_input).call(user_data) 而未进行验证
*   独特之处：合约未经验证，使用 AI 恢复代码
*   攻击模式：准备好的攻击，带有混淆和 MEV 机器人保护
*   状态：资金未追回

### 事件概述

*   受害者合约：[0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913](https://etherscan.io/address/0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913)
*   黑客 (EOA): [0xe3E73f1E6acE2B27891D41369919e8F57129e8eA](https://etherscan.io/address/0xe3E73f1E6acE2B27891D41369919e8eA)
*   攻击合约：[0x5c92884dFE0795db5ee095E68414d6aaBf398130](https://etherscan.io/address/0x5c92884dFE0795db5ee095E68414d6aaBf398130) (selfdestruct)
*   受害者用户：[0x5240B03Be5Bc101A0082074666dd89aD883e1f9d](https://etherscan.io/address/0x5240B03Be5Bc101A0082074666dd89aD883e1f9d)
*   主要 TX: [0x8f28a7f6...f25a](https://etherscan.io/tx/0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a)

时间线

*   2025-12-15 23:27:59 UTC — 受害者合约部署
*   2026-01-25 17:10:35 UTC — 主要攻击：36.9 WBTC（约 320 万美元）被盗
*   2026-01-25 17:23+ UTC — 来自其他地址的次要攻击浪潮

在主要攻击之后，出现了一些模仿者——MEV 机器人和试图利用相同漏洞的模仿者。然而，他们只得到了一些残羹剩饭——总共不超过主要攻击的几个百分点。

### 这是什么协议？

受害者合约是一个 Multi-DEX Liquidity Manager(多 DEX 流动性管理器)，允许管理跨多个 DEX（Uniswap V3/V4，PancakeSwap）的 LP 头寸。该代码未在 Etherscan 上验证，这使得分析变得复杂。

### 漏洞分析

根本原因：任意外部调用

该漏洞位于合约的内部函数中，该函数旨在执行 swap(交换)操作。问题在于，被调用合约的地址和调用数据完全由用户控制，没有任何验证。

让我们看一下反编译的代码（通过 [Dedaub](https://app.dedaub.com/) ):

易受攻击的调用 — 第 735-750 行：

```javascript
    
    // victim_decompiled.dedaub, lines 735-750
    // Internal swap function (function 0x1d33)
    
        }                                           
        if (0 != !v5) {     // v5 = input token address
        }
        
        // <<<< VULNERABILITY HERE >>>>
        // varg2.word5 = "router" address (controlled by user!)
        // MEM[v1d9f.data:...] = calldata for the call (also controlled!)
        // No validation — can call ANYTHING on ANY address
        
        v32, /* uint256 */ v33 = address(varg2.word5).call(
            MEM[v1d9f.data:v1d9f.data + v1d9f.length]
        ).value(v0).gas(msg.gas);
        
        if (RETURNDATASIZE()) {
            require(RETURNDATASIZE() <= uint64.max, Panic(65));
            v34 = new bytes[](RETURNDATASIZE());
            // ... result handling ...
        }
        require(v32, SwapFailure());  // If call fails — revert
```

这里：

*   varg2.word5 — 这是用户传递的“路由器”地址
*   MEM[ [v1d9f.data](//v1d9f.data) :...] — 这是 calldata，也由用户控制
*   地址或数据均未经验证

## 如何利用此漏洞？

攻击者传递：

*   varg2.word5 = WBTC token(代币) 地址 (0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599)
*   data = transferFrom(victim_user, hacker, amount)

由于受害者用户先前已批准受害者合约，因此 transferFrom 调用成功执行——token(代币) 被转移到黑客。

### 入口点：公共函数

易受攻击的内部函数从公共函数 0x67b34120 调用：

公共函数 — 第 1387-1400 行：

```javascript
    
    // victim_decompiled.dedaub, lines 1387-1400
    
    // Public payable function — attack entry point
    function 0x67b34120(
        uint256 varg0,      // existingTokenId
        uint256 varg1,      // amount1Desired  
        struct(5) varg2,    // <<SwapParams — ALL FIELDS CONTROLLED >>
                            //   word0 = isNativeOut
                            //   word1 = amountIn
                            //   word2 = minAmountOut  
                            //   word3 = usePermit2
                            //   word4 = spender (for approve!)
                            //   word5 = router (address for .call()!)
                            //   word6 = data (calldata for .call()!)
        uint256 varg3,      // feeNumerator
        ... 
    ) public payable {
```

### 为什么这很关键？

任何人调用函数 0x67b34120 都可以代表合约执行任意调用——包括对用户已批准合约的 token(代币) 执行 transferFrom。

### 方法论：AI 如何帮助恢复代码

受害者合约未在 Etherscan 上验证，并且攻击者的合约在漏洞利用后立即 self-destruct(自毁)。这产生了一个问题：如何在没有源代码的情况下了解根本原因？

步骤 1：在本地 Fork 上重放攻击

我们在攻击之前的区块上 fork(分叉)了 Ethereum Mainnet(以太坊主网)，并使用 Foundry 在本地重放了交易：

```text
forge test --fork-url [$ETH](https://x.com/search?q=%24ETH&src=cashtag_click) _RPC --fork-block-number 24313233
```

这让我们能够看到：

*   攻击与哪些合约交互
*   发生了哪些内部调用
*   发出了哪些事件

步骤 2：通过 Dedaub 进行反编译

我们将受害者合约的 bytecode(字节码)加载到 [Dedaub Decompiler](https://app.dedaub.com/) 中。Dedaub 创建了可读的伪代码，但变量名被混淆了（varg2.word5 而不是 params.router）。

步骤 3：使用 AI 恢复 Solidity

这才是真正有趣的地方。我们使用 SWE agent(软件工程师代理) 从 Dedaub 反编译的输出中恢复完整的 Solidity 代码。

方法论：

1.  从简单到复杂——从构造函数开始，然后是简单的 view(视图) 函数，然后是复杂的函数
2.  每个方法都经过测试——编写单元测试和模糊测试
3.  与 bytecode(字节码) 比较——在原始 bytecode(字节码) 上运行相同的测试
4.  等效性——如果测试以相同的方式通过，则该方法已正确恢复

步骤 4：创建概念验证

恢复代码后，我们创建了一个 PoC，它：

*   适用于原始 bytecode(字节码)——重放真实的攻击
*   适用于恢复的 Solidity——证明恢复的正确性

两个测试都成功窃取了 WBTC，证实了已正确识别出该漏洞。

为什么这很重要？

以前，闭源代码是针对研究人员的相对可靠的防御——反编译需要花费大量精力。但 AI 极大地降低了这些成本：

重要提示：黑客进行的现代 AI 反编译是完全自动的，无需人工干预。AI 代理接收 bytecode(字节码) 作为输入，并输出可读的 Solidity。这意味着攻击者可以大规模扫描未经验证的合约。

通过模糊性实现安全不再有效。

### 攻击流程

逐步重建

步骤 1：准备

黑客部署攻击智能合约 0x5c92884dFE0795db5ee095E68414d6aaBf398130。此合约：

*   包含带有编码的漏洞利用参数的混淆 payload(有效载荷)
*   使用 MEV 机器人保护——检查区块链状态，如果任何内容发生更改则恢复
*   从其 init(初始化) 代码加载参数，使静态分析变得困难

步骤 2：调用易受攻击的函数

攻击智能合约以专门设计的参数在受害者智能合约上调用函数 0x67b34120：

```markdown
    
    router: 0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599 (WBTC)
    data: transferFrom(
        0x5240B03Be5Bc101A0082074666dd89aD883e1f9d,  // victim user
        0xe3E73f1E6acE2B27891D41369919e8F57129e8eA,  // hacker
        3691897652                                    // 36.9 WBTC
    )
```

步骤 3：漏洞利用执行

受害者合约执行 [params.router.call](//params.router.call) ( [params.data](//params.data) )，这导致：

```text
WBTC.transferFrom(victim_user, hacker, 36.9 WBTC)
```

由于 victim_user(受害者用户) 先前已批准受害者合约管理他们的 WBTC，因此交易成功。

步骤 4：掩盖踪迹

攻击智能合约执行 SELFDESTRUCT(自毁)，销毁其代码并使分析更加困难。

### 攻击图

![图片](https://img.learnblockchain.cn/2026/01/27/70117922_image.jpg)

### 准备好的攻击的迹象

攻击似乎是预先计划好的：

1.  攻击智能合约混淆——代码难以分析，参数是动态加载的
2.  MEV 机器人保护——多个状态检查，更改时恢复
3.  SELFDESTRUCT(自毁) ——执行后销毁代码
4.  精确的目标定位——黑客知道谁有大量的批准

这不是随机发现，而是在未经验证的合约中进行系统性漏洞寻找的结果。

### 经验教训和建议

1. 检查你批准的内容

在批准不熟悉的合约之前：

*   检查代码是否经过验证
*   研究合约可以调用哪些函数
*   使用有限的批准，而不是 type(uint256).max

2. 监控你的批准

定期监控并撤销不必要的批准。

3. 不要存储具有活动批准的大量金额

如果你不需要永久批准——请在使用后撤销它。

### 为什么这次黑客攻击与 AI 有关

此事件表明了 DeFi 安全的新现实：AI 正在改变攻击者和防御者之间的力量平衡。

黑客如何使用 AI

受害者合约未经验证。以前，这意味着分析需要有经验的逆向工程师进行数周的工作。现在：

1.  全自动反编译——AI 代理接收 bytecode(字节码) 作为输入，并输出可读代码，无需人工干预
2.  大规模筛选——可以自动检查数千个未经验证的合约
3.  模式匹配——AI 在不熟悉的代码中找到已知的漏洞
4.  漏洞利用生成——自动创建 PoC

黑客的准入门槛已大大降低。

AI 如何在调查中帮助我们

我们使用了相同的工具，但用于防御：

1.  完整的 Solidity 代码恢复——SWE agent(软件工程师代理) 恢复了约 1000 行代码
2.  自动测试覆盖率——模糊测试以验证等效性
3.  PoC 创建——工作漏洞利用以确认漏洞
4.  文档——结构化报告

军备竞赛

现实是：

*   黑客已经在使用 AI 查找漏洞——自动地，大规模地
*   闭源不再是保护——AI 反编译是完全自动化的
*   传统的审计无法跟上部署速度

### SavantChat：用于防御 AI 黑客的 AI 审计员

在 [SavantChat](https://savant.chat/)，我们开发用于 DeFi 安全研究的 AI 工具。

我们的结果

我们分析了自 2025 年 8 月以来所有主要的 DeFi 黑客攻击，并：

*   重现了 100% 案例中的根本原因
*   在大多数情况下恢复了完整的攻击路径
*   为每个事件创建了可用的 PoC

这次黑客攻击也不例外。

关键论点

> 如果黑客使用 AI 进行攻击，防御者必须使用 AI 进行防御。

我们无法阻止黑客 AI 工具的开发。但是我们可以将相同的工具提供给防御者——并使它们变得更好。

试试 SavantChat

一切都是完全自动化的，摩擦最小：

1.  在 [S](https://savant.chat/) avantChat 上上传你的代码
2.  获取详细的漏洞报告

没有表格、电话、谈判——只有代码和结果。

### 结论

这起 320 万美元的 WBTC 黑客攻击不仅仅是另一起事件。它证明了 DeFi 安全领域的格局发生了怎样的变化：

1.  闭源不是保护。AI 反编译是完全自动化的，无需人工干预。
2.  黑客提前做好准备。混淆、MEV 保护、精确的目标定位——专业攻击的迹象。
3.  AI 是一把双刃剑。黑客已经在使用它。防御者必须跟上。

保护自己的唯一方法是在黑客使用 AI 进行攻击之前，先使用 AI 进行防御。

>- 原文链接： [x.com/savantchat/status/...](https://x.com/savantchat/status/2015636957204783384)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～