8BTCCI: 12277.89 -1.39% 8BTCVI: 6763.31 -0.04% 24H成交额: ¥4650.82亿 +6.82% 总市值: ¥16983.54亿 -1.17%
一行代码蒸发了¥6,447,277,680 人民币!

一行代码蒸发了¥6,447,277,680 人民币!

高金 发布在 区块链 61748

现在进入你还是先行者,最后观望者进场才是韭菜。

美图董事长蔡文胜曾在三点钟群,高调的说出了这句话,随即被大众疯传。

在他发表完言论没多久,2月美链(BEC)上交易所会暴涨4000%,后又暴跌。尽管他多次否认,聪明的网友早已扒出,他与BEC千丝万缕的关系。

1

庄家坐庄操控币价,美图的股价随之暴涨,蔡文胜顺利完成了他的韭菜收割大计。

但在币圈,割人者,人恒割之。

随着BEC智能合约的漏洞的爆出,被黑客利用,瞬间套现抛售大额BEC,60亿在瞬间归零。

而这一切,竟然是因为一个简单至极的程序Bug。

背景

今天有人在群里说,Beauty Chain 美蜜 代码里面有bug,已经有人利用该bug获得了 57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000.792003956564819968 个 BEC

那笔操作记录是 0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f

2

下面我来带大家看看,黑客是如何实现的!

我们可以看到执行的方法是 batchTransfer

那这个方法是干嘛的呢?(给指定的几个地址,发送相同数量的代币)

整体逻辑是

你传几个地址给我(receivers),然后再传给我你要给每个人多少代币(value)

然后你要发送的总金额 = 发送的人数* 发送的金额

然后 要求你当前的余额大于 发送的总金额

然后扣掉你发送的总金额

然后 给receivers 里面的每个人发送 指定的金额(value)

从逻辑上看,这边是没有任何问题的,你想给别人发送代币,那么你本身的余额一定要大于发送的总金额的!

但是这段代码却犯了一个很傻的错!

代码解释

3

这个方法会传入两个参数

  1. _receivers
  2. _value
_receivers 的值是个列表,里面有两个地址

0x0e823ffe018727585eaf5bc769fa80472f76c3d7

0xb4d30cac5124b46c2df0cf3e3e1be05f42119033

_value 的值是 8000000000000000000000000000000000000000000000000000000000000000

我们再查看代码(如下图)

4

我们一行一行的来解释

uint cnt = _receivers.length;

是获取 _receivers 里面有几个地址,我们从上面可以看到 参数里面只有两个地址,所以 cnt=2,也就是 给两个地址发送代币

uint256 amount = uint256(cnt) * _value;

uint256

首先 uint256(cnt) 是把cnt 转成了 uint256类型

那么,什么是uint256类型?或者说uint256类型的取值范围是多少...

uintx 类型的取值范围是 0 到 2的x次方 -1

也就是 假如是 uint8的话

则 uint8的取值范围是 0 到 2的8次方 -1

也就是 0 到255

那么uint256 的取值范围是

0 - 2的256次方-1 也就是 0 到115792089237316195423570985008687907853269984665640564039457584007913129639935

python 算 2的256次方是多少

5

那么假如说 设置的值超过了 取值范围怎么办?这种情况称为 溢出

举个例子来说明

因为uint256的取值太大了,所以用uint8来 举例。。。

从上面我们已经知道了 uint8 最小是0,最大是255

那么当我 255 + 1 的时候,结果是啥呢?结果会变成0

那么当我 255 + 2 的时候,结果是啥呢?结果会变成1

那么当我 0 - 1 的时候,结果是啥呢?结果会变成255

那么当我 0 - 2 的时候,结果是啥呢?结果会变成254

那么 我们回到上面的代码中,

amount = uint256(cnt) * _value

则 amount = 2* _value

但是此时 _value 是16进制的,我们把他转成 10进制

(python 16进制转10进制)

6

可以看到 _value = 57896044618658097711785492504343953926634992332820282019728792003956564819968

那么amount = _value*2 = 115792089237316195423570985008687907853269984665640564039457584007913129639936

可以在查看上面看到 uint256取值范围最大为 115792089237316195423570985008687907853269984665640564039457584007913129639935

此时,amout已经超过了最大值,溢出 则 amount = 0

下一行代码 require(cnt > 0 && cnt <= 20); require 语句是表示该语句一定要是正确的,也就是 cnt 必须大于0 且 小于等于20 我们的cnt等于2,通过! require(_value > 0 && balances[msg.sender] >= amount);

这句要求 value 大于0,我们的value是大于0 的 且,当前用户拥有的代币余额大于等于 amount,因为amount等于0,所以 就算你一个代币没有,也是满足的!

balances[msg.sender] = balances[msg.sender].sub(amount);

这句是当前用户的余额 - amount

当前amount 是0,所以当前用户代币的余额没有变动

  1. for (uint i = 0; i < cnt; i++) {
  2. balances[_receivers[i]] = balances[_receivers[i]].add(_value);
  3. Transfer(msg.sender, _receivers[i], _value);
  4. }
这句是遍历 _receivers中的地址, 对每个地址做以下操作

balances[_receivers[i]] = balances[_receivers[i]].add(_value); _receivers中的地址 的余额 = 原本余额+value

所以 _receivers 中地址的余额 则加了57896044618658097711785492504343953926634992332820282019728792003956564819968 个代币!!!

Transfer(msg.sender, _receivers[i], _value); } 这句则只是把赠送代币的记录存下来!!!

总结1

就一个简单的溢出漏洞,导致BEC代币的市值接近归0

那么,开发者有没有考虑到溢出问题呢?

其实他考虑了,

7

可以看如上截图

除了amount的计算外, 其他的给用户转钱 都用了safeMath 的方法(sub,add)

那么 为啥就偏偏这一句没有用safeMath的方法呢。。。

这就要用写代码的人了。。。

啥是safeMath

8

safeMath 是为了计算安全 而写的一个library

我们看看他干了啥?为啥能保证计算安全.

  1. function mul(uint256 a, uint256 b) internal constant returns (uint256) {
  2. uint256 c = a * b;
  3. assert(a == 0 || c / a == b);
  4. return c;
  5. }
如上面的乘法. 他在计算后,用assert 验证了下结果是否正确!

如果在上面计算 amount的时候,用了 mul的话, 则 c / a == b 也就是 验证 amount / cnt == _value

这句会执行报错的,因为 0 / cnt 不等于 _value

所以程序会报错!

也就不会发生溢出了...

那么 还有一个小问题,这里的 assert 好 require 好像是干的同一件事

都是为了验证 某条语句是否正确!

那么他俩有啥区别呢?

用了assert的话,则程序的gas limit 会消耗完毕

而require的话,则只是消耗掉当前执行的gas

总结2

那么 我们如何避免这种问题呢?

我个人看法是

  1. 只要涉及到计算,一定要用safeMath
  2. 代码一定要测试!
  3. 代码一定要review!
  4. 必要时,要请专门做代码审计的公司来 测试代码
这件事后需要如何处理呢?

目前,该方法已经暂停了(还好可以暂停)所以看过文章的朋友 不要去测试了...

9

不过已经发生了的事情咋办呢?

我能想到的是,快照在漏洞之前,所有用户的余额情况

然后发行新的token,给之前的用户 发送等额的代币...

文章标签: BEC
评论(32)
登录 账号发表你的看法,还没有账号?立即免费 注册
  • a524206010 2018-04-23
    说的太专业 小韭菜表示蒙逼
  • 蘭のテーマ 2018-04-23
    这是用的Cpp写的吗,还是Go
    • bsqql123: 2018-04-23
      都不是,应该是ETH上的solidity智能合约语言
  • 410326a4233 2018-04-23
    您好我们是专业区块链媒体31区:http://block001.cn/ 可不可以授权转载引用这篇文章呢?
    • 野比大雄: 2018-04-23
      请留下联系方式,谢谢
  • blockmeta_r00 2018-04-23
    书中自有黄金屋
  • 凯特_星人 2018-04-23
    昨天刚巧在群里听有人要抄底美链,还懵逼了下,感觉这币听都没听过,现在一看。。。。还好没听过[doge]
  • 张三疯程序员七段 2018-04-23
    黑客如何套现的?
  • 神威丨卡卡西 2018-04-23
    赞一下
  • logxing区块猿 2018-04-23
    故意留后门将成为常态
  • 二黄韭菜 2018-04-23
    故意留给自己的吧[doge]
  • 比特币哪吒 2018-04-23
    这个……了解下。
  • JEX老铁 2018-04-23
    [二哈][二哈][二哈]公链不是那么好做的
  • 爱囤比特币的大侠 2018-04-23
    BEC一开始就说不要碰了,这有点太刺激了吧,维权吧[允悲]
  • BTC狂热 2018-04-23
    所以是个程序员都能写?[吃瓜]
  • 森杉荒筱 2018-04-23
    喜闻乐见:传统互联网行业 不懂区块链 却想进来捞一笔,臭了自己。
  • 币老大 2018-04-23
    你就知道他们不是故意的?
  • 比特币国际玩家 2018-04-23
    所以,很多币,代码写得很垃圾,迟早有几个币因为漏洞归0。
  • 逆水寒 2018-04-23
    连写个最简单的智能合约都出这么大的漏洞,还指望这些人做公链吗,99%的ICO都是骗炮的,pumb and dump游戏而已。
  • 一路心橙 2018-04-23
    我想知道套的是什么现?是法币还是比特币?[嘻嘻]
  • 我是来围观你们炒比特币的 2018-04-23
    代码是核心
  • 小宁大大 2018-04-23
    凉犊子了吧!瞬间增发砸到归零!
  • 1
  • 2