为了挖掘智能合约的漏洞来拆解以太坊（USENIX 2018）

原文提出一种可以自动检测智能合约漏洞的工具，并且讲述了大致的设计思路（可以拆分不同多种方法使用）

像比特币这样的加密数字货币不仅提供去中心化的货币流通，还给交易提供程序化方法。以太坊，紧接着比特币第二大的加密数字货币，它是首先提出用图灵完备语言去列举交易过程，因此能被称为智能合约。这就为攻击者提供很好的目标，因为安全漏洞经常跟随着金融目标。在这篇论文里，我们考虑智能合约漏洞自动识别和漏洞生成这样的目标。我们利用合约漏洞通用的定义，并使用它去制作TEETHER(文章描述漏洞检测的系统名)，这是一个只在给定二进制字节码时候才会形成一个漏洞的工具。对于38757个不同的以太坊我们做了大规模的分析，发现有815个运行时候的漏洞（全自动的）
正是随着以太坊变得越来越流行和有很大的利用价值，有关智能合约攻击的也只会增加而不会下降。在这篇文章中我们的工作就是让智能合约自动漏洞挖掘更加准确。这篇文章在攻击者假定为没有任何特权的以太坊用户，他们的目标是从已经产生的合约中偷取信息。对于这些首先给合约漏洞一个通用的定义。我们的定义是基于这样一个观察，即货币账户(合约)向其他账户的价值转移只能在少数明确定义的条件下发生。尤其是，我们定义四个原则关于低级EVM结构在金钱交易的时候是必须参与的：一个是用于创建标准的交易，另一个是合约终止，最后两个是允许代码注入。
这个工具的主要流程是：在合约中找到几个非常重要的控制流路径。我们找的路径是容易被攻击的路径，这些路径可以被攻击者控制。一旦这样的路径被发现，就利用符号执行将这一路径转入一系列的约束。利用符号执行我们可以推断出攻击者不得不执行需要触发的漏洞。智能合约这个特殊的执行环境可以完成这样的不常见的测试。值得一提的是，我们展示了如何象征性地处理散列值，这在智能合约中广泛的使用。

还不太了解符号执行，大概去看看

大概看了一下这一类自动检测智能合约漏洞都以来一种———智能合约自动化审计方法

目前智能合约自动化审计方法主要有三种：特征代码匹配，基于形式化验证的自动化审计，基于符号执行，符号抽象的自动化审计。

1特征代码匹配

我们首先看这一项，特定代码匹配。大家从名字上来看应该就能理解到，其实它就是对恶意代码进行一些提取抽象，像我们之前做的代码静态检测，我们抽样成一种语义匹配，然后再去匹配它的静态源代码。
这种审计的方法的优点是显而易见的，比如说速度很快，因为它就是对原码进行一个字符串的匹配。第二是它能够迅速的响应新的漏洞，因为这种审计方法大部分是以插件形式开发，比如出现了一个新的漏洞，我们就可以快速提交一些新的匹配模式。
那么它的缺点在哪里呢？我们所理解的现在的区块链都应该是公开透明的，但实际情况并不是这样，我们大概做了一个统计，目前代码的开源率仅仅只占48.62%，也就是在以太坊上其实有超过一半的智能合约是不开源的，只暴露它的一个OPCODE。对于OPCODE的分析对于安全人员来说其实也是面临着巨大的挑战，有些人费了十分大的力气，去逆向OPCODE，这就导致了它的适用范围极为有限。
其次就是漏报率高。因为它的一些静态审计方法其实并不和传统的静态代码审计方法一致，传统的静态审计方法，比如说APP检测，我会调用库里面，确定稳定的一些函数，来对它进行审计，但智能合约里面它的一些函数、它一些特征等等，还是变化性比较多的，所以说它的漏报率会比较高。

2 基于形式化验证的自动化审计方法

形式化验证来审计智能合约安全，最早是在16年，由Hirai提供的，当时拿Isabelle高阶逻辑交互定理证明器，然后交EVM的一些OPCODE ，通过它的一个lem language转化成了一个形式化的model，然后通过形式化model的验证来去判断它代码中的逻辑是否存在问题。
而基于这项工作，之后由两个学家把形式化方法进行了进一步的改正，也就是说他们放弃了lem language这种比较低效的转换方式，采用了F-framework 和K-framework将DVM转化为一个formal model，而F-framework就是NASA他们经常在航空航天领域当中做一些形式化漏洞验证的框架，而K-framework就是语意的一些整合框架。

3基于符号执行，符号抽象的自动化审计

我们在分析一个智能合约的时候，我们首先要明确我们的分析对象是什么。也就像我们刚才在解释的那个特征匹配代码当中，我们知道其实现在EVM上合约代码大部分是不公开的。我们就确认应该是一个EVM OPCODE，通过一些源码，编译，可以形成一个OPCODE，然后输入到我们自动化分析引擎。在这种基于符号执行和符号抽象化的自动化审计框架里面，其实它有些共有的特性，就是它在OPCODE或者在输到这个引擎之后，都会转化成一个CFG，就是我们的一个Control flow graph，即控制流程图。可以简单了解一下这个CFG是什么意思。CFG就是说他把合约代码里面的逻辑包装成每个块，然后有逻辑有分叉的时候，比如说有IF等等这种判断的时候，就把它分叉。
CFG Builder主要是对OPCODE这种智能合约代码，把它形成一个十分庞大完善的一个CFG，然后让程序员更好的去了解它里面执行的一些逻辑。再有CFG生成了之后，就是这样两种分析方法。

举例：Oyente符号执行验证

Oyente的逻辑是在CFG build形成之后，首先是一个EXPLORER，EXPLORER的意思就是说我会把代码当中的每一个流程都去验证一遍，进行一个之外的验证。我们的验证就是是否有一个X，使得X不仅满足C1、C2、C3三个条件，并且Z=X+2，那么这时候我们可以判断他的状态是no还是yes，然后以此来验证整个逻辑的一个流程。
之后就是（code analysis）这一部分其实是这个Oyente最为核心的一个部分，就是它将刚刚输出的EXPLORSE这种路径把它转化，至始至终只包含Ether的一些路径，进行一些漏洞验证，而他目前只提供包括TOD、Timestamp dependence、Mishandled exceptions这三种验证，最后系统为了保证误报率和漏报率，采用了微软的Z3 Bit-Vector Solver 开源的验证器，然后来进行整体架构的一个封装。

举例：Securify符号抽象分析

Securify他们就提供了另外一种方法，它们认为现在合约代码其实是特别容易解耦合的，不像我们传统的代码一样，它的耦合性特别高，但像合约代码里面，就有transfer等等一些比较固定解耦合的一些结构和模块，我们并不是需要对整个合约的逻辑进行的校验，可能我们就是对合约解耦合的各个模块进行校验分析，因此可以提高它的自动化程度。
它们把contract bytecode转化成一种他们自定义的一种语义语言，然后通过自定义的语义语言，它们之后有一个验证模块，这个验证模块就特别像我们之前说的那种模式匹配，就是把一些漏洞转化成一种它验证语言的模式匹配的框架，然后去验证它这个语意在此是否满足他这个比较，最终会生成一个安全报告。
回到论文，谈到这篇文章的主要贡献。
1.提供了一个基于底层EVM指令的易受攻击的合约的通用定义
2.开发出一个工具TEETHER，它仅从合同的字节码提供端到端漏洞。为此，我们解决了几个特定于EVM的挑战，例如以符号方式处理哈希值的新方法
3.给来自以太坊区块链的38757个独立不同的合约进行大范围漏洞分析