1
基礎知識
EVM虛擬機器在解析合約的位元組碼時，依賴的是ABI的定義，從而去識別各個欄位位於位元組碼的什麼地方。關於ABI，可以閱讀這個文件：
一般ERC-20 TOKEN標準的代幣都會實現transfer方法，這個方法在ERC-20標籤中的定義為：function transfer(address to, uint tokens) public returns (bool success);
第一引數是傳送代幣的目的地址，第二個引數是傳送token的數量。
當我們呼叫transfer函式向某個地址傳送N個ERC-20代幣的時候，交易的input資料分為3個部分：
4 位元組，是方法名的雜湊：a9059cbb
32位元組，放以太坊地址，目前以太坊地址是20個位元組，高危補0 000000000000000000000000abcabcabcabcabcabcabcabcabcabcabcabcabca
32位元組，是需要傳輸的代幣數量，這裡是1*10^18 GNT 0000000000000000000000000000000000000000000000000de0b6b3a7640000
所有這些加在一起就是交易資料：
a9059cbb000000000000000000000000abcabcabcabcabcabcabcabcabcabcabcabcabca0000000000000000000000000000000000000000000000000de0b6b3a7640000
2
以太坊短地址
當呼叫transfer方法提幣時，如果允許使用者輸入了一個短地址，這裡通常是交易所這裡沒有做處理，比如沒有校驗使用者輸入的地址長度是否合法。
如果一個以太坊地址如下，注意到結尾為0：
0x1234567890123456789012345678901234567800
當我們將後面的00省略時，EVM會從下一個引數的高位拿到00來補充，這就會導致一些問題了。
這時，token數量引數其實就會少了1個位元組，即token數量左移了一個位元組，使得合約多傳送很多代幣出來。我們看個例子：
這裡呼叫sendCoin方法時，傳入的引數如下：
0x90b98a11 00000000000000000000000062bec9abe373123b9b635b75608f94eb8644163e 0000000000000000000000000000000000000000000000000000000000000002
這裡的0x90b98a11是method的hash值，第二個是地址，第三個是amount引數。
如果我們呼叫sendCoin方法的時候，傳入地址0x62bec9abe373123b9b635b75608f94eb8644163e，把這個地址的“3e”丟掉，即扔掉末尾的一個位元組，引數就變成了：
0x90b98a11 00000000000000000000000062bec9abe373123b9b635b75608f94eb86441600 00000000000000000000000000000000000000000000000000000000000002 ^^ 缺失1個位元組
這裡EVM把amount的高位的一個位元組的0填充到了address部分，這樣使得amount向左移位了1個位元組，即向左移位8。
這樣，amount就成了2 << 8 = 512。
3
構造短地址攻擊
（1）首先生成一個ETH的靚號，這個賬號末尾為2個0
使用一些跑號工具就可以做到，比如MyLinkToken工具，可以很輕易跑出末尾兩個0的。
（2）找一個交易所錢包，該錢包裡token數量為256000
（3）往這個錢包傳送1000個幣
（4）然後再從這個錢包中提出1000個幣，當然這時候寫地址的時候把最後兩個0去掉
如果交易所並沒有校驗使用者填入的以太坊地址，則EVM會把所有函式的引數一起打包，會把amount引數的高位1個位元組吃掉。
（5）這三個引數會被傳入到msg.data中，然後呼叫合約的transfer方法，此時，amount由於高位的1個位元組被吃掉了，因此amount = amount << 8，即擴大了256倍，這樣就把25600個幣全部提出來了。
4
總結
針對這個漏洞，說實話以太坊有不可推卸的責任，因為EVM並沒有嚴格校驗地址的位數，並且還擅自自動補充消失的位數。此外，交易所在提幣的時候，需要嚴格校驗使用者輸入的地址，這樣可以儘早在前端就禁止掉惡意的短地址。
Reference
內容來源：知道創宇
作者：隱形人真忙