本文摘要：本篇反击手法技术分析基于 EOS 1.8 以前版本，在新版本中并未做到测试。

本篇反击手法技术分析基于 EOS 1.8 以前版本，在新版本中并未做到测试。0x01 事件总结根据快雾区情报，EOS DApp EOSPlay 中的 DICE 游戏于9月14日晚遭到新型随机数反击，损失金额低约数万 EOS。经过快雾安全性团队的分析，找到攻击者（账号：muma******mm）在此次反击过程中利用 EOS 中的经济模型的缺失，用于了一种新型的随机数反击手法对项目方展开反击。

在开始详尽的细节剖析之前，必须再行理解一些技术背景作为铺垫。0x02 技术背景我们告诉，在 EOS 系统中，资源是确保整个 EOS 系统安全运营的关键，在 EOS 上收到的每一笔交易都要消耗对应的资源，如 CPU、NET 或 RAM，而这些资源都是必须一定量的 EOS 作为抵押交换条件的，如果抵押的 EOS 的数量过于，则无法交换条件充足的资源发动交易。而本次的攻击行为则是利用了 EOS 资源里面的 CPU 资源模型展开反击。我们告诉，在 EOS 上 CPU 是一个十分最重要，也是消耗最少的资源。

在 EOS DApp 活跃的时候，不会经常出现 CPU 严重不足的情况，为此，还费伊许多做到 CPU 抵押的第三方 DApp，减轻资源用于紧绷的问题。那么 CPU 资源的份额明确是怎么计算出来的呢？参照 MEETONE 的文章(https://github.com/meet-one/documentation/blob/master/docs/EOSIO-CPU.md) 我们可以看见 CPU 的计算出来方式为：max_block_cpu_usage *(account_cpu_usage_average_window_ms / block_interval_ms)* your_staked_cpu_count / total_cpu_count其中，max_block_cpu_usage * (account_cpu_usage_average_window_ms / block_interval_ms) 是一个相同的变量，也就是常量。那么确实影响帐号的 CPU 用于情况的是后面的公式 your_staked_cpu_count / total_cpu_count，这里的意思就是，你抵押的 CPU 总量除以总的 CPU 抵押总量，那么，如果总量变多了，如果你的抵押数量没有跟上去，能用的 CPU 就不会显得越来越少。而 CPU 严重不足，则无法长时间地发动交易。

在理解完了 CPU 的涉及科学知识后，就可以开始涉及的分析了。0x03 反击细节剖析本次的反击帐号为 muma******mm,通过分析该帐号不道德，找到该帐号通过 start 操作者发送到了大量的 defer 交易，这些 defer 操作者里面又发动了另一个 start 操作者，然后无限循环下去。由于这些大量的交易弥漫着区块，为分析工作带给了艰难，所以首先要对这些交易展开检验。

查阅攻击者帐号的接管开奖通报的交易，通过查找游戏的开奖区块，我们找到一个问题，网卓新闻网，就是在多个开奖区块内只有系统的 onblock 一笔交易，解释这个区块为空块。很显著，这是因为 CPU 价格的太高造成交易无法收到而经常出现的情况。而本次不受反击的 EOS Play 使用的是用于未来区块哈希展开开奖。

那么攻击者为什么要自由选择这样做到呢？我们来分析下区块哈希的计算方法。通过上图我们可以看见，区块哈希的计算出来最后调用了 digest() 方法，而 digest() 方法的构建为对 block_header 结构体本身展开哈希。我们之后看 block_header 的定义。可以看见 block_header 结构体的变量分别有1、confrimed2、previous3、transaction_mroot4、action_mroot5、schedule_version6、new_producers7、header_extensions其代表的含义分别为：1、每一轮开始前必须证实的上一轮生产的区块数2、之前区块的区块哈希3、区块 transaction 的默克尔根哈希4、区块 action 的默克尔根哈希5、节点出块顺序表格版本，这个在一段时间内是会转变的6、新的出块节点，可为空7、扩展，1.8 之前这个变量为空到了这里，我们可以确切的看见，除了 action_mroot 和 transaction_mroot 外，所有的其他变量都是可以精彩提供的，然后我们之后了解看下 transaction_mroot 和 action_mroot 的计算方法。

本文来源：BB贝博ballbet-www.hljlqhb.com