EOSFuzzer: Fuzzing EOSIO 智能合约

脆弱性检测* #
黄玉河计算机科学 Bo Jiang†北京航空航天 W.K.陈
学院 大学计算机科学与工程 计算机科学系
北京航空航天 学院 香港城市大学
大学的工程 中国北京 wkchan@cityu.edu.hk
中国北京 jiangbo@buaa.edu.cn
huangyuhe@buaa.edu.cn

EOSWin 等)导致约 17 万 EOS 代币[28]损失。EOSCast 智能合约中

摘要
的 虚 假 EOS 转 移 漏 洞 已 导 致 约 60K 个 EOS 代 币 [26]损 失 。
EOSIO 是典型的公共区块链平台。它在交易速度方面是可扩展 EOSBet 内部的伪造传输通知漏洞已导致 140K EOS 令牌[27]丢失。
的，并且有一个支持智能合约和去中心化应用的不断增长的生态 根据攻击时 EOS 代币的价格(平均约 5 美元)，仅这三个漏洞造成
系统。然而，EOSIO 智能合约内部的漏洞导致了严重的攻击， 的累计损失就约为 190 万美元。因此，为 EOSIO 智能合约构建有
给其终端用户造成了严重的经济损失。在本工作中，我们系统地 效的漏洞检测工具是有价值的。然而，现有的 fuzzing 工具无法检
分析了三种典型的 EOSIO 智能合约漏洞及其相关攻击。然后， 测 EOSIO 智能合约漏洞。
我们提出了 EOSFuzzer，一种用于检测 EOSIO 智能合约漏洞的 与以太坊智能合约的模糊不同，EOSIO 智能合约的模糊存在两
通用黑箱模糊框架。特别是，EOSFuzzer 提出了针对 EOSIO 智 个主要挑战。首先，EOSIO 智能合约通过 EOSIO 采用一种独特的
能合约 fuzzing 的有效攻击场景和测试 oracle。我们在 3963 EOS 令牌转移和通知机制。 令牌系统智能合约，这可能导致独特
EOSIO 智能合约上的 fuzzer 实验表明，EOSFuzzer 对 EOSIO 智 的 EOSIO 智能合约漏洞。为了有效地触发这些漏洞，我们必须设
能合约漏洞的检测是有效和高效的，并且具有较高的准确性。 计新的攻击者代理来触发这些漏洞，以及新的测试 oracle 来精确
地检测这些漏洞。第二，EOSIO 智能合约由 WASM 虚拟机执行，
CCS 的概念 WASM 虚拟机支持与 EVM 不同的字节码指令集。此外，随着
•安全性和隐私性→软件和应用安全; EOSIO 平台的发展，新的漏洞类型将不断出现。因此，我们必须
•软件及其工程→软件测试与调试; 在 WASM VM 中设计通用的检测方案，以捕获足够的信息，以支
持对不同类型 EOSIO 智能合约漏洞的检测。
关键字 在这项工作中，我们提出了 EOSFuzzer，一种用于检测 EOSIO
Fuzzing，智能合约，漏洞检测，区块链 智能合约漏洞的通用黑盒模糊框架。EOSFuzzer 包括一个 fuzzing
提出了区块链技术作为有限信任的对等体之间的价值转移网络。 输入生成器，一个 fuzzing 执行器，一个仪表化的 Wasm VM，和
目前，区块链技术已经发展成为一个信任机器，不受信任的对等 一个漏洞检测引擎。模糊输入生成器可以根据智能合约的 abi 生成
体可以相互合作。目前大多数区块链平台都支持智能合约，开发 输入，利用 agent 智能合约实现特定的攻击场景。模糊执行器可以
者 可 以 通 过 智 能 合 约 构 建 去 中 心 化 应 用 程 序 (DApps) 。 其 中 ， 在模糊下对智能合约有效地执行生成的输入。仪表化的 Wasm VM
EOSIO 平台生态系统正在稳步增长。dapp 的类型包括游戏、赌博、 将收集对通用漏洞检测有价值的操作码执行、API 调用和其他执
去中心化交易、工具、微博等。 行信息。最后，漏洞检测引擎实现了所提出的测试 oracle 来报告
然而，EOSIO 智能合约的漏洞给终端用户带来了不小的经济 漏洞。我们在 3963 个智能合约上的实验表明，EOSFuzzer 能够有
损 失 。 例 如 ， EOSIO 赌 博 游 戏 ( 包 括 EOSBet 、 EOSCast 、 效地检测 EOSIO 智能合约中的漏洞，并且具有较高的准确性。特
FFGame、EOSDice、 别是，在我们的案例研究中，我们已经成功地使用 EOSFuzzer 对
没有源代码的智能合约进行了攻击，并且没有花费任何 EOS。
*国家重点研发计划项目(2019YFB2102400);，研究资助局研究资助金(研究计
划编号:61772056)。11214116、11200015 和 11201114)。 # EOSFuzzer 是开源的。
https://github.com/gongbell/EOSFuzzer † 所有的信件都应寄给渤江。电子邮
件:gongbell@gmail.com。

这项工作的贡献有三方面。首先，据我们所知，这项工作提
出了第一个用于检测 EOSIO 智能合约中的安全漏洞的模糊框架。
其次，本文提出了有效的攻击场景和相应的测试 oracle，能够高
准确性地触发和检测 EOSIO 智能合约中的典型漏洞。第三，我
们通过对真实世界 EOSIO 智能合约的模糊实验，系统地评估了
EOSFuzzer, EOSFuzzer 有效地识别了 EOSIO 智能合约中的超过
450 个漏洞。
其余各节的组织情况如下。在第二节中，我们将介绍
WebAssembly (Wasm)、EOSIO 平台和 EOSIO 智能合约的基础知
识。然后在第 3 节中，我们将介绍 EOSIO 智能合约的 3 个典型
漏洞。在第 4 节中，我们将详细介绍 EOSFuzzer 框架的设计。在
此之后，我们将在第 5 节对 EOSFuzzer 在漏洞检测方面的有效性
和效率进行全面的实验研究。然后，我们将在第 6 节中介绍使用
EOSFuzzer 成功攻击 EOSIO 智能合约的案例研究。最后，我们
将在第 7、8 和 9 节介绍相关的著作、致谢和结论。
2 背景
在本节中，我们将提供 WebAssembly、EOSIO 平台和 EOSIO 智
能合约的背景知识。
2.1 的 WebAssembly
WebAssembly(简称 Wasm)[32]是基于堆栈的虚拟机的二进制
指令格式。Wasm 被设计成一个可移植的目标，用于编译高级语
言(如 C/ c++ /Rust)，支持在 web 上部署客户机和服务器应用程
序。Wasm 被设计为快速、安全且易于调试。而且它可以很容易
地嵌入到 web 和非 web 执行环境中。EOSIO 平台也采用 Wasm
VM 来执行其智能合约。
2.2 EOSIO 平台和 EOSIO 智能合约
EOSIO 平台是一个开源的公共区块链平台，专注于交易速度的
可扩展性。EOS 不仅是 EOSIO 平台的代币，也代表其所有者持有
的股权。EOSIO 平台采用委托证明(Delegated Proof of Stake, DPoS)
协议来达成共识，比比特币等其他平台使用的 PoW (Work Proof of
Work, PoW)共识协议更具扩展性。计算资源也根据用户拥有的
EOS 代币进行分配。此外，EOSIO 平台还对每笔交易的执行时间
设置了上限。超过资源限制将导致事务的回滚，但有例外。
EOSIO 区块链平台的功能和特征被设计得非常灵活，可以修改
以适应特定的业务需求。共识、收费计划、账户创建和修改、
token 经济等区块链核心功能在系统智能合约[30]中实现，系统智
能合约部署在 EOSIO 区块链平台上。为例。eosio。令牌系统智能
合约[24]定义了结构和
黄玉河，江波，陈伟强
允许用户在基于 EOSIO 的区块链上发行和转移令牌的操作。EOS 代
币的管理也由 eosio 执行。令牌系统智能合约。
智能合约是运行在区块链平台上的程序，用于帮助管理终端用
户的资产，或在参与区块链平台的对等方之间强制谈判和执行协
议 。 部 署 在 EOSIO 平 台 上 的 智 能 合 约 [29] 包 含 两 个 部
分:WebAssembly 字节码和应用二进制接口 ABI。智能合约源代码
被编译成 Wasm 字节码，以便在 Wasm VM 中执行。ABIs 描述了
智能合约的公共接口来进行交互。
每个 EOSIO 智能合约必须提供一个应用功能作为入口功能来处
理操作。apply 函数将侦听所有传入的操作，并相应地调用相应的
操作处理程序函数。例如，智能合约的传递函数通常用于处理与合
约[31]相关的传递操作。
apply 函数使用接收方、代码和操作输入参数作为过滤器，将
操作映射到处理[25]的相应函数。接收方是当前正在执行代码的
帐户。代码是操作最初发送到的帐户。动作是动作的名称。理解
代码和接收者之间的区别是很重要的。具体来说，code 始终是操
作的第一个接收者，而接收者是当前执行操作的帐户。在执行智
能合约期间，它可以通过 require_recipient()函数将接收到的操作
转发给其他帐户。apply 函数的代码和操作参数也转发给新契约。
结果，接收者更改为新通知的合同，但代码保持不变。
EOSIO 智能合约中的 3 个安全漏洞
在本节中，我们将简要回顾 EOSIO 智能合约中的安全漏洞。
3.1 虚假 EOS 转账
表 1。EOSBet 合同有伪造的 EOS 传输漏洞
1 …
2 / /应用功能
3. void apply(uint64_t receiver, uint64_t code, uint64_t action){
4 auto self = receiver;
5 if (code == self || code == N(eosio.token) || action == N(onerror)){
6 类型 thiscontract(自我);
7 switch(action) {
8 EOSIO_API(类型、成员 )
9 }}}
在预期情况下，EOSIO 智能合约只接受通过 EOSIO 转移的
EOS。令牌系统合同。如果受到攻击的合同是脆弱的，因为它不检
查代码是 eosio。令牌当动作在其应用函数内传输时，攻击者可以
直接调用契约内的传输函数
2
EOSFuzzer: Fuzzing EOSIO 智能合约漏洞检测
伪造 EOS 转账。因此，脆弱的合约可能会错误地认为攻击者已经
将 EOS 转移给了它。 帐户 B 可以使用 require_recipient 函数故意将转移通知转发给另
如表 1 所示，在 EOSBet 契约的 apply 函数中，它只检查代码 一个合同(本例中为 eosbetcasino)，以便误导它，如表 4 所示。表
是契约本身还是 eosio。令牌，但它不检查动作传输是否最初被发 4。攻击者编码发送伪造的传输
送到 eosio。令牌系统智能合约。因此，攻击者契约可以直接调用 通知
脆弱契约的传递函数进行赌博，而不花费任何 EOS。 1 类别 contractB: public eosio::contract {
2 公众:
表 2。攻击者合同的假冒 EOS 传输漏洞
3. eosio::contract(self) {}
1 类 hackcontract: public eosio::contract { 4 void transfer(uint64_t sender, uint64_t receiver) {
2 … 5 require_recipient (N (eosbetcasino));
3. void hack(account_name self, eosio::资产数量， std::string memo) { 6 }
7 };
4 eosio::操作 (
5 eosio: permission_level {_self, N(活动 )}, 如表 5 所示，eosbetcasino 是脆弱的，因为它不检查目的地(即
6 N
(eosbet), EOS 传递本身就在其传递函数内。那么，它可能会错误地认为自己
7 N(转移), 已经收到了 EOS。因此，它可能错误地记入攻击者的账户 a，而实
8 std::make_tuple(self, N(eosbet)， quantity, 际上攻击者并没有向 eosbetcasino 发送任何信息。
memo)).send();
9 }}; 表 5 所示。智能合约 eosbetcasino
1 class eosbetcasino: public eosio::contract {
如表 2 所示，黑客可以使用攻击者契约来利用假冒的 EOS 传输 2 公众:
漏洞。这种攻击很简单:它直接对 EOSBet 的传输函数执行内联调用。 3. void transfer(uint64_t sender, uint64_t receiver) {
4 自动数据= unpack_action_data<st_transfer>();
表 3。修复了假冒 EOS 转移漏洞
5 if (data.from == _self) //不检查 data.to
1 … 6 返回;
2 / /应用功能 7 doSomething
3. void apply(uint64_t receiver, uint64_t code, uint64_t action){ ();
4 auto self = receiver; 8 }
5 if(code == self || code == N(eosio.token) || action == N(onerror)){ 9 };
6 if(action == N(transfer)){
7 eosio_assert(code == N(eosio.token)， "必须转移 EOS"); 如表 6 所示，对伪造的转账通知漏洞的修复是简单的检查转账的目的
8 } 地(第 5 行)。如果 EOS 转账的目的地不是当前合同，那么合同应该直
9 …
接忽略转账通知。表 6 所示。伪造转账通知的修复
脆弱性
如表 3 所示，建议修复漏洞的方法是在 apply 函数中添加一个
1 class eosbetcasino: public eosio::contract {
check，确保 eosio。token 是传输操作的原始接收者(第 6 行和第 7 2 公众:
行)。换句话说，当操作被传输时，代码必须是 eosio.token。 3. void transfer(uint64_t sender, uint64_t receiver) {
3.2 伪造转账通知 4 自动数据= unpack_action_data<st_transfer>();
当调用合约的传递函数时，智能合约可能永远不会检查目的地 5 if (data.from == _self || data。_self ! =)
(即:，至)的转让。然而，这是容易受到攻击的，因为智能合约可 6 返回;
7 doSomething
能只接收到转移到另一个合约的通知，而不是转移到它自己。 ();
在 正 常 的 EOS 转 账 过 程 中 ， 接 收 方 合 同 可 以 选 择 通 过 8 }
require_recipient 将转账通知转发到其他账户(即发送转账行动的 9 };
副本)。伪造传输通知攻击[22]时，攻击者控制两个账户 a 和 B，
通过系统合约 eosio.token 将 EOS 从 a 转移到 B 进行初始化攻击。 3.3 块信息依赖
当转账成功时，A 和 B 都会收到转账通知。然而，合同部署在
由于缺乏随机性来源，EOSIO 智能合约可能依赖于区块信息
内部
如 tapos_block_prefix 和 tapos_block_num 来生成随机数，这些随
机 数 可 能 决 定 EOS 的 转 移 或 彩 票 的 中 奖 者 。 但 是 ，
tapos_block_prefix 和 tapos_block_num 不是可靠的随机性来源，因
为它们
 黄玉河，江波，陈伟强

可以直接从 ref_block_num 计算，这是最后一个不可逆块的默认 id。 在本节中，我们将首先介绍 EOSFuzzer 的概述。然后我们将

详细讨论 EOSFuzzer 的每个组成部分。
赌博合同可以使用延期诉讼来决定彩票的赢家。在这种情况下，
引用块是在进行打赌的块之前的块。因此，当智能合约直接使用 4.1 EOSFuzzer 概述
tapos_block_prefix 和 tapos_block_num 进行随机生成时，可以预测
生成的随机数。 如图 1 所示，EOSFuzzer 的总体工作流程主要包括四个步骤。
首先，EOSFuzzer 在 ABI(应用程序二进制接口)和被测试智能合约
如表 7 所示，EOSDice 智能合约[28]使用 tapos_block_prefix、 的字节码上执行静态分析。静态分析步骤输出每个 ABI 接口的参
tapos_block_num 、 current_time 、 account_name 、 game_id 、 数的数据类型，以及字符串数据类型和 memo 参数的候选字符串
pool_eos 生成随机数。不幸的是，所有这些变量都可以在下注之前 池。其次，EOSFuzzer 执行输入生成，根据静态分析结果为每个
确定。获取 account_name(契约的名称)、game_id 和 pool_eos(当前 ABI 接口生成 fuzzing 输入。同时，EOSFuzzer 还将使用已部署的
契约的余额)是很容易的。current_time 指的是确定彩票赢家时的时 攻击者代理契约来生成攻击场景，以触发特定的漏洞。第三，
间戳，它是投注时的时间戳和延迟动作的延迟时间的总和。因此， EOSFuzzer 通过 cleos 工具[23]在测试网中进行分析，在智能合约
所有用于随机数生成的变量都可以在投注前计算出来。最后，攻击 上执行 fuzzer。请注意，测试网是一个仪表化的 EOSIO 平台，其
者成功计算了随机数，通过彩票赢得了 2545 个 EOS，大约 13500 上部署了智能合约。通过 instrumentation，将被分析的智能合约
美元。 的执行信息记录到执行日志中。第四，EOSFuzzer 将基于我们提
出的测试 oracle 执行漏洞分析。
表 7 所示。EOSDice 合同与块信息。依赖的脆弱性
4.2 输入发生器
1 uint8_t 随机(account_name name, uint64_t game_id){ 输入生成器负责生成 EOSIO 智能合约 ABI 接口的输入，并与攻
2 … 击者代理生成攻击场景。fuzzing 的最终输入是交叉 ABI 调用和攻
3. auto mixd = tapos_block_prefix() * tapos_block_num() + name + 击场景。
game_id - current_time() + pool_eos.amount;
为不同的数据类型生成输入。 EOSIO 智能合约的 ABI 接口采
4 const char *mixedChar = reinterpret_cast<const char *>(&mixd);
用 JSON 格式。因此，我们的工具解析 JSON 文件以提取每个
5 checksum256 结果;
6 sha256((char *)mixedChar, sizeof(mixedChar)， &result);
参数的数据类型。然后 EOSFuzzer 为每个数据类型生成输入，
7 uint64_t random_num = *(uint64_t *)(&result.hash[0]) + 并将它们连接起来，以构建调用 ABI 接口的最终输入。
* (uint64_t *) (&result.hash [8]) + * (uint64_t *) (&result.hash 基本数字数据类型包括 8 位、16 位、32 位、64 位整数和无符号
[16]) 整数类型，以及 32 位和 64 位浮点类型。对于这些数据类型，
+ * (uint64_t *) (&result.hash EOSFuzzer 可以在输入域中随机生成最大值、最小值或随机值。
[24]);
8 return (uint8_t)(random_num % 100 + 1); 对于布尔数据类型，输入生成算法将随机返回 true(1)或 false(0)
9 } 值。对于字符串数据类型，我们的输入生成算法将首先通过静态分
析构建一个候选字符串池。更具体地说，EOSFuzzer 将迭代定义常
量数据的数据区域，并将该区域中的所有常量字符串收集为候选字
4 EOSFuzzer 的设计 符串池。然后，在输入生成过程中，EOSFuzzer 将从候选池中随机
返回一个字符串作为字符串参数。
对于资产数据类型，算法将返回随机数量的 EOS 代币。对于符
号数据类型，算法将只返回类型 EOS。换句话说，我们将主要针对
EOS token 相关的智能合约功能，而不是其他 token。
名称数据类型表示智能合约的名称。目前，我们的工具将返回
待测智能合约的名称，作为名称数据类型参数的输入。类似地，
对于 public_key 数据类型，我们将返回测试中的当前智能合约的
地址。这是因为许多 abi 只是

图 1 EOSFuzzer 工作流程

4
EOSFuzzer: Fuzzing EOSIO 智能合约漏洞检测
授权在测试中的当前智能合约上工作。使用其他相关智能合约的
常量数据，定位与偏移量对应的字符串(如果它是 string 类型的)，并
名称和 public_key 可能需要进一步分析项目中智能合约之间的关
将其保存在 vector memo 中，作为 memo 参数的候选项(第 9 至 12
系，我们将此作为未来的工作。
行)。
对于数组数据类型，我们的算法将迭代地为其原始数据类型成
当传递函数中存在与传递函数签名相同的函数或传递函数中存在
员生成输入。对于 struct 数据类型，我们的算法将迭代地为其每个
与 memo 参数无关的其他常数字符串时，分析可能会变得不精确。
成员生成输入。如果它的成员是 struct 数据类型，算法也将递归地
然而，我们使用开源契约的分析表明，备忘录向量只包含少量的不
进行，直到遇到基元类型。
相关候选，这仍然是有效的模糊。
对于每个智能合约，输入生成算法将生成一个包含一组测试用
伪造 EOS 传输攻击代理的设计。 一个安全编写的智能合约将检查
例的测试套件。每个测试用例都是 ABI 函数调用和攻击交互(从代
代码是否是 eosio。当动作在 apply 函数中传输时。因此，为了触
理契约)到 fuzzing 下的智能契约的组合。测试用例中的函数调用
发假冒 EOS 传输漏洞，我们使用名为 fakeTransferAgent 的攻击者
和攻击交互的数量是随机长度的，可以在 EOSFuzzer 中配置。
合约，使用不同于 eosio.token 的代码在 fuzzing 下调用智能合约的
为 Memo 参数生成种子。memo 参数是传递函数中使用的一个参 传输函数。调用涉及两个场景，它们都在 fakeTransferAgent 的传递
数。根据我们的分析，我们发现发送方和接收方可以使用字符串
函数中执行。一种是用等于接收者(即模糊下的合同)的代码调用传
类型的 memo 参数来确认和保护一个传输操作。为了为 memo 参
递函数，另一种是用不同于接收者和 eosio.token 的代码调用传递
数生成种子，我们的算法将对测试中的智能合约执行静态分析，
函数。因此，代理合约将在 fuzzing 下对智能合约执行两种可能的
以提取传递函数中使用的字符串。
攻击。
表 8 所示。用于提取候选备忘录字符串的静态分析 一种攻击是在 fuzzing 下对智能合约的传递函数执行内嵌函数调
1 getMemoStrings(vector length, string param) { 用。换句话说，我们的工具故意避免使用 eosio。执行传输操作的
2 向量<字符串>备忘录 令牌契约。在这种攻击中，代码等于接收者(即。fuzzing 下的智能
3. 设置<字符串>补 合约)。
偿 另一种攻击是首先使用 cleos 工具调用 fakeTransferAgent 智能合
4 在所有带有像 param 这样签名的函数中
约 的 传 递 函 数 。 然 后 ， fakeTransferAgent 智 能 合 约 将 通 过
5 for 指令包含" "i32 。const”“{
6 从指令中提取偏移量
require_recipient 在 fuzzing 下将行为转发给智能合约。通过这种方
7 offsets.insert(抵消) 式，fuzzing 下的智能合约将收到一个 transfer action，代码等于
8 } fakeTransferAgent，这与两个 eosio 都不同。令牌及其本身(接收方)。
9 for offset in offsets 最后，如果攻击成功触发了 fuzzing 下的智能合约传递函数，则
10 foreach 指令包含偏移量 { 认为该智能合约是脆弱的。
11 从指令中提取字符串 伪造传输通知攻击者代理的设计。为了有效地触发伪造传输通知
12 memos.insert(字符 漏洞，我们设计了一个通知代理合约来装载攻击。为了发起攻击，
串)
13 } EOSFuzzer 将首先通过 eosio 向通知人合同发送一些 EOS。令牌
14 返回的备忘 智能合同。然后，通知程序合约将通过 require_recipient()函数将
录 传递操作转发给智能合约。最后，EOSFuzzer 漏洞检测模块在收
15 }
到通知后，会对智能合约在 fuzzer 下的行为进行分析，判断其是
否存在漏洞。
如表 8 所示，getMemoStrings 函数提取可能用于与传递函数中
的 memo 参数进行比较的候选字符串。wast 参数是 fuzzing 下智能
4.3 Fuzzing 执行引擎
合约的 WebAssembly 文本格式。EOSFuzzer 使用 wasm2wat 工具 生成了用于 fuzzing 智能合约的输入后，fuzzing 执行引擎负责
[33]将 wasm 字节码转换为 waste 表示。参数是一个字符串，表示 执行针对 EOSIO 智能合约的输入。fuzzing 执行引擎利用 cleos 工
返回值的数据类型和传递函数的参数(即。，字符串" (param i32 i64 具与智能合约进行交互。在我们的设计中，EOSFuzzer 创建了一
i64 i32 i32) "))。在第 4 行，算法迭代所有带有签名的函数，如传 个管道来与 cleos 进程通信。它调用 cleos 工具的 push action 命令
递函数(即，具有相同类型的参数和返回值)。在每个函数中，它迭 来
代代码中包含常量值的每条指令(即:，包含 i32.const)，并在这些
函数中提取相应常量变量的偏移量(第 4 行到第 7 行)

与 fuzzing 下的智能合约 ABI 接口或与代理合约交互。
对于每个智能合约，输入生成算法都会生成一组测试用例。每
个测试用例都是 ABI 函数调用和攻击交互(从代理契约)到 fuzzing
下的智能契约的组合。当一个测试用例完成执行时，EOSFuzzer
将重置测试网。一方面，重置测试网将导致额外的时间成本。另
一方面，重新设置 testnet 将使调试更容易，因为执行跟踪更短。
通过这种方式，我们希望在模糊的效率和模糊后的可调试性之间
做出权衡。
当测试用例执行结束后，EOSFuzzer 将开始读取执行过程中产
生的检测日志，并调用漏洞检测模块对漏洞检测结果进行分析和
报告。
4.4 Wasm 虚拟机插装
为了支持可扩展的漏洞分析，我们必须小心地检测 Wasm VM，
以收集关于执行期间调用的操作码和操作数的信息。这包括那些
与控制流相关的操作码、一元操作码、二进制操作码以及它们的
操作数。每当执行一个操作码时，检测就会在操作码日志文件中
生成一行记录操作码、操作数和结果(如果有的话)。虽然并不是
所有操作码日志文件中的信息都用于检测本研究中研究的漏洞，
但检测日志的设计是为了在未来分析新的漏洞。
特 别 地 ， 调 用 CallIndirect 操 作 码 是 插 装 的 ， 因 为 每 次 调 用
apply 函数中的 execute_action 都会导致调用 indirect 操作码的执行。
因此，这个操作码意味着在测试中的智能合约中调用 ABI 函数。
此外，我们还插装了 Wasm API 接口实现代码，以收集关于在智能
合约执行期间是否查询块信息的信息。具体来说，我们已经插装
了 tapos_block_num()和 tapos_block_prefix()函数。
最后，我们还测量了 eosio 的传递函数。token 系统智能合约，
用于 EOSIO 平台上的 EOS 转移。检测该功能将帮助我们了解
EOS 转移是否真的发生在智能合约执行过程中。
4.5 测试 oracle 的漏洞检测
在本节中，我们为漏洞检测提供了测试 oracle。
假的 EOS 转移。为了触发假冒 EOS 传输漏洞，我们使用了一
个名为 fakeTransferAgent 的攻击者合约，在其自身的传输函数内
执行两个可能的操作。一种是直接对 fuzzing 下的智能合约的传
递函数执行内联函数调用，另一种是使用 require_recipient 将传
递动作转发给 fuzzing 下的智能合约。
在设计的攻击场景下，测试 oracle 检测假冒 EOS 传输漏洞:
黄玉河，江波，陈伟强
CanReceiveEOS & TransferCalled
CanReceiveEOS 测试 oracle 是为了检查智能合约是否可以接收
EOS 而不是其他代币。在我们的实施过程中，我们通过 eosio 在
fuzzing 下向智能合约发送一些 EOS。然后检查是否调用了智能合
约的传递函数。因为在攻击场景中至少会调用两个成员函数(即:，
eosio 的传递函数。token 和 fuzzing 下的智能合约传递函数 ) ，
EOSFuzzer 将检查 CallIndirect 操作码在其实现中是否已被执行至
少 2 次。
TransferCalled test oracle 用于检测 fakeTransferAgent 是否能成
功触发 fuzzing 下智能合约的传递函数。与 CanReceiveEOS 类似，
EOSFuzzer 会检查 CallIndirect 操作码是否至少被执行了 2 次(即:，
一个为 fakeTransferAgent 的传递函数，另一个为 fuzzing 下智能合
约的传递函数)。由于攻击场景由我们的代理合约很好地控制，我
们可以确保传递函数是 fuzzing 下智能合约中调用的唯一 ABI 函
数。因此，第二个调用间接操作码的出现对应于传递函数的调用，
而不是 fuzzing 下智能合约中的其他 ABI 函数。
伪造转让通知。 如前几节所述，为了检测伪造传输通知漏洞，
EOSFuzzer 利用通知代理在 fuzzing 下向智能合约发送伪造通知。
测 试 oracle 来 检 测 伪 造 的 转 移 通 知 如 下 :TransferCalled
& !CheckRecipient
TransferCalled sub-oracle 用于检测在攻击场景中，fuzzing 下智
能合约的传递函数是否被调用。在我们的攻击场景的调用链中，
如果调用了智能合约的传递函数，则必须至少调用三个 ABI 函数。
这些对应于 eosio 的传递函数。 令牌合约、通知人合约和 fuzzing
下的智能合约。 每次调用成员函数都会导致调用间接操作码的执
行。因此，当实现 oracle TransferCalled 时，EOSFuzzer 会检查在
我们的攻击过程中是否至少执行了 3 个 CallIndirect 操作码。同时，
EOSFuzzer 还将第三个 CallIndirect 操作码的行号记录在操作码日
志文件中，便于进一步分析，对应于 fuzzing 下智能合约内传递函
数的起始位置。
CheckRecipient 的条件是检查 fuzzing 下的智能合约，在所有由
通知代理发起的攻击中，尚未检查自己是否是 EOS 转移的真实接收
者。为了实现子 oracle !CheckRecipient, EOSFuzzer 首先检查是否有
执行比较操作码(即:， Eq 或 Ne)之间的通知人合同(EOS 的实际接收
方)和智能合同 fuzzing 下由通知人代理的一轮攻击。比较从上一步
操作码日志文件中记录的 fuzzing 下的智能合约传递函数的起始位置
开始。应该注意的是，直接检查关于比较传递函数的 to 和_self 参数
的说明可以
6
EOSFuzzer: Fuzzing EOSIO 智能合约漏洞检测
不精确，因为 EOSIO 没有强制 ABI 接口和实际实现之间的一致
性。
在我们的智能合约 fuzzer 过程中，EOSFuzzer 会多次发起来自
通知代理的攻击，只有在所有来自通知代理的攻击中没有对 EOS
转移收件人进行检查时，才满足!CheckRecipient 条件。由于 Fuzzer
可能不会遍历接收方检查代码的每一条路径，EOSFuzzer 可能会在
报告伪造传输通知漏洞时产生误报。但是，当模糊尺度较大时，产
生假阳性的概率会非常低，这也被我们的实验评估所证实。
块信息的依赖。检测块信息依赖的测试 oracle 如下:
BlockInfoRead & EOSTransferCalled
block foread 测试 oracle 检查是否有 api 调用读取块信息。在实
现过程中，这是通过检测 tapos_block_num 和 tapos_block_prefix
API 来实现的。EOSTransferCalled oracle 检查 eosio 的传递功能是
否正常。称为令牌智能合约。EOSFuzzer 通过简单地测量 eosio 的
传递函数来实现这一点。令牌系统智能合约，并在 EOSIO 内重新
部署。
4.5 讨论
在本节中，我们从两个方面讨论对 EOSFuzzer 可能的扩展。
首先，EOSFuzzer 被设计为黑盒模糊器，但它也可以扩展为灰
盒模糊器。扩展的关键是在模糊过程中收集代码覆盖信息。目前，
EOSFuzzer 仪器各种字节码指令在 WASM 虚拟机。我们可以通过
在 VM instrumentation 中收集分支覆盖信息来扩展 EOSFuzzer:每当
遇到分支指令时，我们可以记录两个分支的位置以及新分支的覆
盖范围。增量分支覆盖信息可用于指导基于突变的灰盒模糊过程。
新的变异和选择策略可以进一步提高模糊算法的有效性。
其次，EOSFuzzer 也可以扩展到支持新漏洞的检测。例如，回
滚漏洞[10]是赌博 DApp 智能合约中的一个漏洞。本质上，漏洞在
于赌博智能合约的揭示功能，所有的行为都位于单一交易中。因
此，每当攻击者输掉赌博游戏时，就可以恢复整个事务以恢复其
平衡。我们可以扩展 EOSFuzzer，使用另一个攻击者代理来实现上
述攻击场景。通过简单的扩展，EOSFuzzer 框架可以轻松地支持在
fuzzer 下对合同的 EOS 转移、揭示函数的调用、攻击者代理平衡
的检查以及 revert 操作的调用。
5 实验与结果分析
在本节中，我们展示了我们的模糊实验来评估 EOSFuzzer 漏洞检
测的有效性。
5.1 课题项目
我们实验研究中使用的课题程序包括 82 个开源 EOSIO 智能合约
和 3881 个无源代码智能合约。82 开源智能合约主要用于手动验证
我们工具的有效性。然而，收集大量带有源代码的 EOSIO 智能合约
是困难的，因为大多数 EOSIO dapp 都不是开源的。3881 个没有源
代码的智能合约只包含 Wasm 字节码和 ABI 文件，它们用于大规模
评估我们的工具。对于带有源代码的智能合约，我们首先将其编译
成字节码，然后将其部署到我们的测试网中进行 fuzzing。对于只使
用 Wasm 字节码的智能合约，我们直接将它们部署在我们的测试网
中。
5.2 实验设置
实 验 是 在 码 头 内 进 行 的 。 docker 的 主 机 是 一 台 配 备 了 8 核
Intel®Core™i7- 6700 CPU @ 3.4GHz 和 16GB 内存的台式机。该主机
使用的是 Ubuntu 16.04.1 和 Docker 18.06.1 版本。此外，docker 运行
的是 Ubuntu 18.04.4。我们在 docker 的 Ubuntu 操作系统中运行了仪
器化的 EOSIO 客户端(节点)和 EOSFuzzer。使用的 EOSIO 客户端是
nodeos 1.5.2 版本。EOSFuzzer 通过 cleos 工具与 EOSIO 节点对话。
在执行 fuzzing 实验之前，我们必须正确配置 EOSIO 测试网。
首先，我们启动 keosd 钱包来提供密钥管理器服务守护进程，用
于存储私钥和签名数字消息。其次，我们运行插装的 nodeos 守护
进程来启动单节点测试网。第三，我们部署了仪器化的 eosio。令
牌系统智能合约和攻击者代理合约。第四，我们创建了 2 个
EOSIO 账户，与攻击者代理合同合作，在攻击期间执行 EOS 转移。
最后，我们将 fuzzing 下的智能合约部署到 EOSIO 测试网。部署
的智能合约包括 3881 个无源代码智能合约和 82 个带源代码智能
合约。
当 EOSIO 测试网配置好后，我们进一步配置了 EOSFuzzer，
使其在每个智能合约上执行大约 1000 次交叉 ABI 函数调用和代
理合约攻击。最后，我们开始使用 EOSFuzzer 对部署的智能合约
执行 fuzzer。
5.3 实验与结果分析
在本节中，我们首先展示 EOSFuzzer 在有源代码和没有源代
码的契约上的结果。然后进一步比较 EOSFuzzer 和 EVulHunter
工具[17]的漏洞检测效果。EVulHunter 是一款基于静态分析的
EOSIO 智能合约漏洞检测工具。最后，给出了 EOSFuzzer 在漏
洞检测方面的有效性。
EOSFuzzer 结果与源代码的合同。 EOSFuzzer 漏洞检测结果如
表 9 所示。的
 黄玉河，江波，陈伟强

Total 列表示待分析的智能合约的总数。报告漏洞数、FP、FN 分别 表 11 所示。EOSFuzzer 伪造 EOS 转账的假阳性案例

表示对应漏洞类型报告的漏洞数、假阳性案例数和假阴性案例数。 1 eosio:: CONTRACT {
我们手动检查了 82 份智能合约的源代码，以识别假阳性或假阴性情 2 …
况。 3. [[noreturn]]无效(uint64_t 申请 接收器, uint64_t 代码,
uint64_t 动作){
表 9 所示。智能合约的 EOSFuzzer 结果与源代码
4 如果((代码= =的名字
EOSFuzzer (“eosio.token”)。值| |
脆弱性 总计 5 代码= =名称(“vig111111111”)。值|
报道 《外 FN |
交政 6 代码= =名称(“dummytokens1”)value) &
策》 &
块信息。依赖 82 2 0 1 7 action = =名字(“转让”)value) {
伪造转让通知 82 4 0 0 8 eosio:: execute_action(名称(接收器),名称(代码),活力::assetin);
假的 EOS 转移 82 2 1 0 9 }
10 if (code == receiver) {
在 82 个智能合约中，EOSFuzzer 检测到 2 个块依赖漏洞。这两 11 switch (action){//典型的动作映射工作流
个都是我们手工检查确认的 EOSFuzzer 有一个关于块依赖漏洞的 12 EOSIO_DISPATCH_HELPER(活力(创建)(转移)…)
错误否定案例。 13 }
智能合约彩票 10 是 EOSFuzzer 的假阴性案例。如表 10 所示， 14 }
transferact 函数被指定为处理投注 EOS 的转移。然而，该合同只 15 }
接受 EOS 的转让款，并预先确定一定的金额(即。， 1000, 10000,
100000…)。另外，合同中还需要 10th 调用具有预定数量的传递函 如表 11 所示，智能合约 vigor 是 EOSFuzzer 报告的假冒 EOS 转
数实际上可以进行打赌，这使得 EOSFuzzer 很难在没有大规模模 账的假阳性案例。在典型的工作流中，apply 函数将使用 transfer
糊努力的情况下触发。一般来说，针对智能合约执行非常大规模 函数来处理 EOS 令牌的转移，这也是我们测试 oracle 实现的假设。
的 fuzzing 活动或使用 fuzzing 的反馈机制可能有助于暴露漏洞， 然而，在 vigor 合同中，使用的是 assetin 函数(而不是 transfer 函数)
这将留给未来的工作。 来处理 EOS 的转移(第 4 行到第 8 行)。， CallIndirect 操作码至少被
执行了 2 次)。此外，当攻击者代理在 vigor 上执行传递函数的内
表 10。False 阻塞信息的阴性情况。由 EOSFuzzer 依赖
联调用时，传递函数仍然可以通过默认的 dispatcher 宏调用(第 10
1 class loty10: public eosio::contract { 至 12 行 ) 。 因 此 ， 也 可 以 满 足 子 oracle TransferCalled( 因 为
2 … CallIndirect 操作码已经执行了至少 2 次)。由于这两个子 oracle 都
3. 无效 transferact(uint64_t 接收器，uint64_t 代码){ 很满意，我们的 EOSFuzzer 错误地报告了该合同为伪造的 EOS 转
4 //函数处理转移 移漏洞。出现假阳性的原因是 vigor 使用了不同的函数 assetin 而不
5 …
是函数 transfer 来处理 EOS transfer，如果不分析源代码很难知道。
6 int64_t amount = data.quantity.amount;
然而，我们认为使用转账以外的函数来处理 EOS 转账对于 EOSIO
7 if (amount == 1000 || amount == 10000 || amount == 100000 || amount 智能合约来说是不常见的。
== 1000000 || amount == 10000000) {
8 / /接受打赌 EOSFuzzer 和 EVulHunter 的比较。在本节中，我们进一步比较
9 … EOSFuzzer 和 EVulHunter 漏洞检测工具，如表 12 所示。由于
10 }; EVulHunter 工具不支持块信息依赖漏洞的检测，我们仅从伪造转
移 通 知 和 伪 造 EOS 转 移 漏 洞 两 方 面 比 较 EOSFuzzer 和
对于伪造传输通知漏洞，EOSFuzzer 已经识别出 4 个智能合约。 EVulHunter。
在人工检查了所有 82 份智能合约后，我们确认 EOSFuzzer 既不报 表 12。EOSFuzzer 和 EVulHunter 的比较
假阳性也不报假阴性。
EOSFuzzer EVulHunter
对于假冒的 EOS 转移漏洞，EOSFuzzer 在 82 个智能合约中发现 脆弱性 总计
报道 《外 FN 报道 《外 FN
了 2 个漏洞。经过人工检查，我们确认 EOSFuzzer 报告没有误报。 交政 交政
但其中一个被确认的易受攻击合同(称为 vigor)是一个假阳性案例。 策》 策》
伪造转让通知 82 4 0 0 12 10 2

假的 EOS 转移 82 2 1 0 9 8 0

8
EOSFuzzer: Fuzzing EOSIO 智能合约漏洞检测
在 82 个智能合约中，EVulHunter 成功分析了 74 个智能合约。 表 14。EVulHunter 伪造 EOS 转账的假阳性案例
其他 8 个合同都无法输出。在 74 份智能合同中，EVulHunter 报告
了 12 份存在伪造转移通知漏洞的智能合同。但是经过人工检查， 1 类 token:公共契约{
我们发现其中有 10 个是假阳性。此外，EVulHunter 错过了 2 个易 2 …
3. };
受攻击的智能合约。因此，EOSFuzzer 工具在检测伪造传输通知
4 EOSIO_ABI(eosio::token， (create)(issue)(transfer))
漏洞时优于 EVulHunter。
5 //默认动作映射的宏
如表 13 所示，智能合约 salescon 是 EVulHunter 伪造传输通知
漏洞的假阳性案例。它使用断言语句(即:， eosio_assert)执行条
EOSFuzzer 结果没有源代码的合同。 我们还仅使用字节码和
件检查。然而，EVulHunter 工具似乎只适合使用 if 语句进行条
件检查，在使用断言时导致误判。在我们的手动确认过程中，当 ABI 对 3881 EOSIO 智能合约进行了 fuzzing。如表 15 所示，
我们将契约中的断言语句更改为 if 语句时，EVulHunter 工具将 EOSFuzzer 共识别出 3 个块信息依赖漏洞、183 个伪造传输通知
不再生成假阳性。 漏洞、265 个伪造 EOS 传输漏洞。3881 份智能合约中，区块信
息依赖率为 0.07%，伪造转账通知率为 4.72%，伪造 EOS 转账率
表 13。伪造转账通知书的假阳性案例。由 EVulHunter 为 6.83%。没有源代码，很难手动验证那些报告的智能合约，以
1 类[[eosio::contract]] salescon: public eosio::contract { 识别假阳性和假阴性的准确数量。但研究结果给了我们一个估计，
2 … 在野生环境中易受攻击的智能合约的数量。
3. void salescon::transfer(name from, name to, asset quantity, string 考虑到潜在的大量伪造转账通知和假冒 EOS 转账漏洞，建议
memo) 开发人员在公开发布 EOSIO 智能合约之前进行安全检查和加固合
4 {… 同。
5 eosio_assert(from == buyer， "Transfer must come from buyer"); /
/转让必须来自买方 表 15。智能合约的 EOSFuzzer 结果没有
6 eosio_assert(to == _self，“合同不是收件人”);/ / 源代码
7 eosio_assert (quantity.symbol.is_valid(),“无效的数量”);
漏洞检测
8 … 脆弱性 总计 百分比
EVulHunter 工具伪造传输通知漏洞的一个假阴性案例是智能合 块信息。依赖 3881 3. 0.07%
约 vigor。在分析过程中，EVulHunter 工具未能找到任何间接调用 伪造转让通知 3881 183 4.72%
的路径。然而，EOSFuzzer 工具在 fuzzer 过程中确实找到了间接
调用的路径。因此，EVulHunter 在其静态分析过程中似乎不够精 假的 EOS 转移 3881 265 6.83%
确。
对于假冒的 EOS 转移漏洞，EOSFuzzer 发现了 2 个漏洞，而 EOSFuzzer 效 率 。 在 对 每 个 合 约 进 行 fuzzer 时 ， 我 们 将
EVulHunter 工具报告了 9 个漏洞。然而，经过人工检查，我们发现 EOSFuzzer 配置为对每个智能合约执行大约 1000 次交叉 ABI 函
EVulHunter 报告的 9 个漏洞中有 8 个实际上是假阳性的。相反， 数调用和来自代理合约的攻击。对于每个合约，fuzzing 实验平
EOSFuzzer 报告的 2 个漏洞中只有 1 个是假阳性的。因此，对于假 均需要 90 秒左右，基于我们实验的硬件配置，这是很小的。此
冒 EOS 转移漏洞，EOSFuzzer 产生的误阳性率要比 EVulHunter 低 外，平均每秒调用约为 11 次，这对于全面的模糊足够快了。部
得多。 分原因是基于 DPOS 共识协议的 EOS 具有较高的交易速度。因
如表 14 所示，EVulHunter 报告 token 智能合约为虚假 EOS 转 此，EOSFuzzer 对于 EOSIO 智能合约漏洞检测也是非常有效的。
移漏洞。但是，在令牌契约中，它使用 EOSIO_ABI 宏进行默认操
对易受攻击的合同发起攻击
作映射。EOSIO_ABI 只能处理 code 等于 self 的情况。因此，
token 合同不能处理来自 eosio 的 EOS 转移。令牌的合同。它只是 我们还成功地对名为 diamond1 的智能合约发起了攻击，以在我
处理 EOS 以外的代币的合同。因此，token 合同是 EVulHunter 的 们的测试网中获得 EOS。因为 diamond1 没有提供源代码，所以我
一个假阳性案例。 们 基 于 它 的 ABI 接 口 对 它 的 字 节 码 进 行 了 模 糊 处 理 。 除 了
EOSFuzzer 中定义的测试 oracle 外，我们还检查了 diamond1 的
EOS 余额在每次 ABI 调用后是否减少(fuzzer 之前初始化为 1000
EOS)。换句话说，我们想要确保 fuzzing 下的合同资产在攻击中丢
失。

在 7 个 ABI 调用中，EOSFuzzer 不仅成功触发了 Forge Transfer
通知漏洞，而且在不使用单个 EOS 的情况下成功打赌并获得了奖
励(26.46 EOS)。具体攻击过程如下:
在第一次 ABI 调用期间，EOSFuzzer 向 diamond1 智能合约执行
EOS 转 移 ， 并 检 查 其 转 移 功 能 是 否 被 调 用 。 这 是 为 了 检 查
diamond1 是否可以收到 EOS。在接下来的 3 次 ABI 调用中，
EOSFuzzer 通过将发送者账户的 EOS 转移到通知代理合同来执行
伪造的转移通知攻击。通知代理合约将通过 require_recipient 函数
将通知发送到 diamond1 智能合约。3 次调用均触发了伪造的转账
通知，EOSFuzzer 在没有花费任何 EOS 的情况下成功押注。在 5th
调用时，EOSFuzzer 使用代理合约执行假 EOS 转移攻击，以对
diamond1 智能合约执行内联调用。但是，没有触发假冒 EOS 转移
漏洞。在 6th 调用时，EOSFuzzer 调用 diamond1 的 deposit ABI 函数。
然而，它的平衡没有改变。最后，在 7th 调用 ABI 时，EOSFuzzer
调用 diamond1 智能合约的 endlottery ABI 函数，该函数结束投注过
程并宣布投注结果。注意，也可以从赌博游戏的网站上触发
endlottery ABI 函数。
在上次调用结束时，EOSFuzzer 发现 diamond1 智能合约余额减
少到 973.54 EOS，而发送方账户余额从 1000 增加到 1026.46。日
志进一步证实了攻击的成功:diamond1 智能合约认为发件人账户在
伪造转账通知攻击中成功下注，宣布发件人账户为赢家，并向发
件人账户发送了 26.46 个 EOS 作为奖励。然而，发送方账户仅因
串谋向通知方代理合同发送了一些 EOS，其收益为 26.46 EOS，没
有任何股权。
7 相关工作
在本节中，我们将介绍与智能合约漏洞检测和模糊技术密切相关
的工作。
7.1 智能合约漏洞检测
Parizi 等人[15]对以太坊智能合约的当前静态智能合约安全测
试工具进行了广泛的实验性评估。Tsankov 等人提出了用于智能
合约漏洞检测的 Securify 工具。Securify 工具[18]是一个可扩展的
以太坊智能合约安全分析仪，它可以证明合约行为对于给定的属
性是安全/不安全的。Abdellatif 和 Brousmiche[1]使用了一种正式
的建模方法来验证其执行环境中的智能合约行为。他们用统计模
型检查方法进一步分析了合同的安全性。
Luu 等人[12]设计了以太坊智能合约符号验证工具 Oyente。
Oyente 建立智能合约的控制流图，然后在控制流图上进行符号执
行，同时检查是否存在漏洞
黄玉河，江波，陈伟强
模式。Nikolic 等人[14]设计了 MAIAN，这是一个符号执行工具，
用于推理跟踪属性，以检测易受攻击的以太坊智能合约。它基于
跟踪属性指定了三个典型的智能合约漏洞。MAIAN 可以通过象征
性的执行有效地发现贪婪、挥霍和自杀的契约。Hirai[11]使用了
Isabelle/HOL 工具来验证名为契据(Deed)的智能合约，这是以太坊
名称服务实现的一部分。具体来说，该作品验证了只有契约的所
有者才能减少其余额的神谕。此外，他们还发现 EVM 实现在验证
过程中测试得很差。
Chen 等人[5]提出了 TokenScope 工具，该工具可以自动检查令
牌契约的行为是否符合 ERC-20 标准。Nguyen 等人提出了模糊工
具[7]，该工具结合了 AFL 模糊器的策略和针对那些难以覆盖的分
支的高效轻量化多目标自适应策略。评估结果表明，模糊工具在
实现高代码覆盖率和检测漏洞方面是高效和有效的。Wang 等人
[19]提出了 VULTRON 工具，该工具可以精确检测智能合约中由
于各种类型的敌对攻击而产生的不规则交易。为解决智能合约漏
洞检测测试 oracle 问题提供了一种通用的方法。
以上讨论的技术通常对检测以太坊智能合约中的漏洞或漏洞是
有效的。然而，它们并不是专门设计来支持 EOSIO 智能合约漏洞
检测的。
EVulHunter[17]是一个静态分析工具，用于检测 EOSIO 智能
合约中的漏洞。然而，它无法为许多 EOSIO 智能合约生成结果，
并为漏洞报告生成许多假阴性和假阳性。EOSAFE[10]是另一
个静态分析框架，用于检测基于符号执行的 EOSIO 智能合约中
的漏洞。我们认为动态模糊和静态分析是 EOSIO 智能合约漏洞
检测的两种互补技术。
7.2 漏洞检测的模糊技术
针对漏洞检测的模糊技术有很多研究工作。
GodeFroid[9]等人提出了一种基于语法的有效输入规范来增强
复杂结构化输入应用程序的白盒模糊。他们的测试数据生成算
法结合了符号执行和约束求解，改进了模糊过程。Wang 等人提
出了 TaintScope[20]，一种利用动态污染分析和符号执行技术的
自动模糊系统。TaintScope 可以识别输入实例中的校验和字段，
通过使用分支分析技术定位基于校验和的完整性检查，并通过
控制流更改绕过此类检查。
Dai 等人提出了配置模糊技术，在某些执行点随机修改运行应
用程序的配置，以检查漏洞。Ganesh 实现了 BuzzFuzz 工具[8]，
它使用动态污染跟踪
10
EOSFuzzer: Fuzzing EOSIO 智能合约漏洞检测
自动定位原始种子输入文件的区域，影响在关键程序攻击点使用的
值。然后，BuzzFuzz 工具通过模糊原始种子输入文件的这些识别区
域，自动生成新的模糊测试输入文件。
Chen 等人[3]提出了一种名为 Angora 的基于突变的模糊器，
该模糊器提出使用可扩展的字节级污染跟踪、上下文敏感的分支
计数、基于梯度下降的搜索和输入长度探索技术来有效地解决路
径约束。Lyu 等[13]提出了一种新的突变调度方案，使基于突变
的模糊器更有效地发现漏洞。Chen 等人[4]提出了一种全局异步
和局部同步(GALS)种子同步机制来无缝集成基模糊器以获得更
好的性能。
You 等人[21]提出了 ProFuzzer，它可以自动恢复和理解在
fuzzer 过程中对漏洞发现至关重要的输入字段。模糊器可以智能
地调整突变策略，以提高击中零日目标的机会。
一般来说，与 EOSFuzzer 不同，上述 fuzzer 技术并不是专门
为检测 EOSIO 智能合约中的漏洞而设计的。
还有一些关于有状态模糊技术的有趣作品。AFLnet 采用了一种
变异的方法，并使用状态反馈来指导网络协议[16]的模糊过程。
REST-ler[2]是一个有状态的自动智能 REST API 安全测试工具。
REST-ler 通过推断 Swagger 规范中声明的请求类型之间的依赖关系
来智能地生成测试。它还分析在之前的测试执行期间观察到的响应
的动态反馈，以便生成新的测试。目前，EOSFuzzer 执行的 fuzzer
是无状态的。在未来的工作中，我们可以扩展 EOSFuzzer，在数据
流分析的支持下执行有状态的 fuzzer。
9 结论与未来工作
EOSIO 智能合约的漏洞给用户造成了重大损失。因此，需要有
效的工具来检测 EOSIO 智能合约中的漏洞。在这项工作中，我们
提 出 了 EOSFuzzer ， 一 个 黑 匣 子 fuzzer 工 具 ， 可 以 自 动 检 测
EOSIO 智能合约中的漏洞。在 EOSFuzzer 中，我们提出了有效的
攻击场景以及对 ABI 接口的调用，以对 EOSIO 智能合约执行全面
的 fuzzer。此外，我们还定义并实现了测试 oracle 来检测 EOSIO
智能合约的三个典型漏洞。我们的 fuzzer 实验表明，EOSFuzzer 是
有效和高效的检测 EOSIO 智能合约漏洞的实际使用。特别是，
EOSFuzzer 已经成功地在没有源代码的情况下攻击 EOSIO 智能合
约，在不花费任何 EOS 的情况下下注。
对于未来的工作，我们希望扩展 EOSFuzzer，以支持 EOSIO
智能合约中新型漏洞的检测。我们还计划改进 EOSFuzzer 在
fuzzer 中搜索策略，以提高其针对复杂智能合约的漏洞检测效率
参考文献
Abdellatif, T.， Brousmiche, K.L.“基于用户和区块链行为模型的智能合
约正式验证”，《2018 第九届 IFIP 国际新技术、移动和安全会议
论 文 集 》 ， 巴 黎 ， 2018 ， 第 1-5 页 ， doi:
10.1109/NTMS.2018.8328737。
“RESTler:有状态 REST API Fuzzing”，2019 IEEE/ACM 第 41 届软件工程
国际会议(ICSE ' 19)，蒙特利尔，QC，加拿大，
2019, pp. 748-758, doi: 10.1109/ICSE.2019.00083。
Chen, P. and Chen, H.， [3]“基于原则搜索的高效 Fuzzing”，《2018
IEEE 安全与隐私研讨会论文集》(SP’18)，旧金山，2018，第
711-725 页，doi: 10.1109/SP.2018.00046。
Chen, Y.， Jiang, Y.， Ma, J.， Wang, M.， Zhou, C.， Jiao, X.， and Su, Z. Z.
EnFuzz: ensemble fuzzzz with seed synchronization .(通讯作者)在第 28
届 USENIX 安全研讨会会议记录(第 19 章)。USENIX 协会，美国，
1967 - 1983,2019。
陈涛，张勇，罗旭，王涛，曹睿，肖新，张旭。2019。TokenScope:自动检
测以太坊中加密货币令牌的不一致行为。2019 ACM 计算机和通信安全
SIGSAC 会议论文集(CCS ' 19)。计算机器的协会，纽约，纽约，美国，
1503-1520。
Dai, H.， Murphy, C.，和 Kaiser, G.。“用于软件漏洞检测的配置模糊”，
《 2010 可 用 性 、 可 靠 性 和 安 全 性 国 际 会 议 论 文 集 》， 克 拉 科 夫 ，
2010,525-530 页，doi: 10.1109/ ares2010.22。
Duy Tai Nguyen, Long H. Pham, Jun Sun, Yun Lin and Minh Quang
Tran:“fuzzy:一种有效的自适应模糊控制”，第 42 届软件工程国际
会议论文集。IEEE 计算机协会，2020 年。
Ganesh, V.， Leek, T.， and Rinard, M.。“基于污染的定向白箱模糊”，
《IEEE 第 31 届软件工程国际会议论文集》，温哥华，BC, 2009, pp.
474-484, doi: 10.1109/ icce .2009.5070546。
基于语法的白盒模糊法。发表在第 29 届 ACM SIGPLAN 编程语言设计与
实现会议论文集(PLDI ' 08)。计算机器的协会，纽约，纽约，美国，
206-215。
何宁，张睿，吴磊，王辉，罗旭，郭勇，于涛，姜旭" EOSIO 智能合约的安全
分析" .电子商务学报，2014,34 (6):1102 - 1104 . [10]" ArXiv abs/ 2003.06568，
2020.
以太坊名称服务契据合同的正式验证。http://yoichihirai.com/deed.pdf, 2016。
让智能合约更智能。第 23 届计算机与通信安全会议论文集(CCS ' 16)，
254- 269，维也纳，奥地利，2016。
吕超，张超，李勇，李伟，宋勇，和 Beyah, R. MOPT:最优变异调度算法。
在第 28 届 USENIX 安全研讨会会议记录(第 19 章)。USENIX 协会，
美国，1949-1966,2019。
Nikolic, I.， Kolluri, A.， Sergey, I.， Saxena, P.， and Hobor, A. Ivica 2018。
大规模发现贪婪、挥霍和自杀的合同。在第 34 届年度计算机安全应
用会议(ACSAC ' 18)的会议记录。计算机器的协会，纽约，纽约，美
国，653-663。DOI: https://doi.org/10.1145/3274694.3274743
Parizi, R. M.， Dehghantanha, A.， Choo, K. K. R.， and Singh, A. Reza
2018。区块链自动智能合约安全测试的经验漏洞分析。在第 28 届
年度会议上
 黄玉河，江波，陈伟强
计 算 机 科 学 与 软 件 工 程 国 际 会 议 (CASCON ' 18)。 IBM 公 司 ， 美 国 ，
103-113。
[16] Van-Thuan Pham, Marcel Böhme, Abhik Roychoudhury。AFLNet:网络协
议的灰盒模糊器。软件测试，验证与验证:测试工具轨道(ICST'20)。
2020.
全利进，吴磊，王昊宇。“EVulHunter:在 Webassembly 级别检测 EOSIO 智
能合约的虚假传输漏洞。ArXiv abs/1906.10362, 2019。
Tsankov P.， Dan, A.， Drachsler-Cohen, D.， Gervais, A.， Bünzli, F.， and
Vechev M. 2018 。 Securify: 智 能 合 约 的 实 用 安 全 分 析 。 2018 ACM
SIGSAC 计算机和通信安全会议论文集(CCS ' 18)。计算机械协会，
纽 约 ， 纽 约 ， 美 国 ， 67-82 。 DOI:
https://doi.org/10.1145/3243734.3243780
H。[19]王,李,Y。,林,年代,妈,L。,和刘,Y。“VULTRON:一劳永得地捕捉
易受攻击的智能合约”，《IEEE/ACM 第 41 届软件工程国际会议论文
集:新想法和新结果》，蒙特利尔，QC, 2019 年，第 1-4 页。
Wang, T.， Wei, T.， Gu, G.， Zou。“TaintScope:一种用于自动软件漏洞检
测的 checksum 感知定向模糊工具”，发表在 2010 IEEE 安全与隐私
研讨会论文集(SP ' 10)， Berkeley/Oakland, CA, 2010, pp. 497-512, doi:
10.1109/SP.2010.37。
youw .， Wang, X.， Ma, S.， Huang, J.， Zhang, X.， Wang, X.， Liang,
B. .“ProFuzzer:实时输入类型探测以更好地发现零日漏洞”，《2019
IEEE 安全和隐私研讨会论文集》(SP ' 19)，旧金山，美国，2019,pp.
769- 786, doi: 10.1109/SP.2019.00057。
EOS 押 注 [22] 攻 击 。 https://medium.com/leclevietnam/hacking-in-eos-
contracts-and-how-to-prevent-it-b8663c8bffa6。2020 年最后一次访问。
[23]克莱奥的工具。https://eos.io/build-on-eosio/cleos/。2020 年最后一
次访问。
[24] EOSIO.TOKEN。https://developers.eos。io /欢迎/最近/——开始/ smart-
contract-development / deploy-issue-and-transfer-tokens。2020 年最后一
次访问。
[25] EOSIO ABI 宏并应用。https://developers.eos。io / eosio - cpp / v1.2.0 /
docs / abi。2020 年最后一次访问。
EOS 智 能 合 约 中 的 虚 假 EOS 转 移 漏 洞 。
https://blog.peckshield.com/2018/11/02/eos/。2020 年最后一次访问。
EOS 智 能 合 约 中 的 [27] 伪 造 转 账 通 知
https://blog.peckshield.com/2018/10/26/eos/。2020 年最后一次访问。
无 年 龄 [28] 随 机 数 生 成 漏 洞 。
https://github.com/NoneAge/EOS_dApp_Security_Incident_Analysis/tr ee
/主/ noneage - 20181103 eosdice -预测-随机种子。
2020 年 最 后 一 次
访问。
EOS 上的[29]智能合约开发。https://developers.eos.io/welcome/latest/getting-
started/index。2020 年最后一次访问。
EOSIO 上 的 [30] 系 统 智 能 合 约 。
https://developers.eos.io/manuals/eosio.contracts/latest/index 。 2020 年 最
后一次访问。
EOSIO 智能合约[31]传递函数。https://developers.eos.io/manuals/eosio。cdt /
最近/最佳实践/ abi / abi - code-generator-attributes
解 释 / # eosioon_notifyvalid_eosio_account_namevalid_eosio_action
_name。2020 年最后一次访问。
[32] Web 组件。https://webassembly.org/。2020 年最后一次访问。
WebAssembly 二进制工具包。https://github.com/WebAssembly/wabt。2020
年最后一次访问。

12