導讀
就一個簡單的batchTransfer批量轉賬函數溢出漏洞，導致BEC的市值接近歸零。
至於其他建立在ETH智能合約基礎上開發的2000多個項目的代幣，裡面有沒有類似的bug，小蔥相信也會有的。
美圖董事長蔡文勝曾在三點鐘群，高調的說出了這句話：
“現在進入你還是先行者，最後觀望者進場才是韭菜。”
隨即被大眾瘋傳。在他發表完言論沒多久，2018年2月，美鏈（BEC）上交易所會暴漲4000%，後又暴跌。儘管他多次否認，但是聰明的網友早已扒出，他與BEC有著千絲萬縷的關係。
今天有人在電報群裡說，BEC（美蜜）的代碼裡面有bug，已經有人利用該bug獲得了 57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000.792003956564819968 個 BEC
小蔥咋看到這個消息，嚇了一跳，BEC（美蜜）整個盤的代幣總額才70億，現在黑客一下之轉走了5後面58個零的幣，這下BEC直接清盤了吧？
難道這是幣圈流行的漫天假消息？
不過小蔥發現，徐明星的OKex隨即緊急發佈了一個公告。
如果說這個公告和這筆接近60億獲利的黑客攻擊沒有關聯，我是不相信的。
不過黑客到底是如何實現的呢？好奇的小蔥就來帶大家一起觀摩學習下，黑客是如何實現的！
我們發現，原來那個黑客的那筆操作記錄是 0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f
黑客所採取的攻擊方法是BEC智能合約
(https://etherscan.io/address/0xc5d105e63711398af9bbff092d4b6769c82f793d)中
batchTransfer批量轉賬函數存在的漏洞
小蔥再來科普一下：batchTransfer批量轉賬函數有什麼漏洞
批量轉賬，言下之意也就是說給可以按事先指定的幾個錢包地址，發送相同數量
我們假設一個批量轉賬的交易場景
首先，小蔥和你達成了一次批量轉賬交易，你要向小蔥我批量發放BEC的代幣。
那麼小蔥肯定得先告訴你，我作為代幣接收者（receivers），會向你提供代幣接收地址。
然後，小蔥得再告訴你，你得向我提供的每個接收地址，發多少指定的代幣金額？（value：金額)
一般情況下，你要發送的代幣總金額（amount） = 發放的人數* 發送的金額
當然，這裡肯定有個先覺條件，你的錢包餘額肯定要多過你要發送的代幣總金額，否則你就不夠錢向小蔥我進行撒幣了！
從邏輯上看，上述的批量轉賬流程肯定沒有任何問題的，除非你的數學是體育老師教的！我想給別人發送代幣，那麼我本身的餘額一定要大於發送的總金額的！
但是，但是！
這段代碼卻犯了一個很傻的錯!
代碼解釋
這個方法會傳入兩個參數
_receivers（代幣接收者）
_value（轉賬金額）
_receivers 的值是個列表，我們發現這個列表裡面有兩個錢包地址
0x0e823ffe018727585eaf5bc769fa80472f76c3d7
0xb4d30cac5124b46c2df0cf3e3e1be05f42119033
而_value （轉賬金額）的值是 8000000000000000000000000000000000000000000000000000000000000000嚇尿小蔥了，黑客要搞這麼大筆的轉賬金額是為了什麼？
我們回頭再查看代碼（如下圖）
我們一行一行的來解釋
uint cnt = _receivers.length;
是獲取 _receivers 裡面有幾個地址，我們從上面可以看到 參數裡面只有兩個地址，所以 cnt=2，也就是 給兩個地址發送代幣
uint256 amount = uint256(cnt) * _value;
黑客攻擊者，就是充分利用了這個uint256，他傳入很大的_value （轉賬金額）：8000000000000000000000000000000000000000000000000000000000000000
這樣他就使 cnt * value 後超過 unit256 的最大值，最後使其溢出導致 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，所以當前用戶代幣的餘額沒有變動
所以 _receivers 中，黑客地址的餘額 則加了57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000.792003956564819968 個 BEC，市值接近60億！
就一個簡單的batchTransfer批量轉賬函數溢出漏洞，導致BEC的市值接近歸零
至於其他建立在ETH智能合約基礎上開發的2000多個項目的代幣，裡面有沒有類似的bug，小蔥相信也會有的。
不過話說回來，這次的Bug，不知道和最近風頭正猛的EOS有沒有關係？畢竟柚子可是朝著姨太開火的。
閱讀更多 區塊連線 的文章
