為什麼“BEC”合約中的batchOverflow hack有效？
我目前正在了解目前批次溢出是如何發生的。但是有些地方我不明白。文章說如下：
易受攻擊的函式位於batchTransfer中，程式碼如圖2所示。如第257行所示，amount局部變數計算為cnt和_value的乘積。第二個參數，即_value，可以是任意256位整數，比如0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000(63 0）。通過將兩個 _receiver 傳遞給 batchTransfer()，使用非常大的 _value，我們可以溢出數量並將其設為零。將金額歸零後，攻擊者可以通過第 258-259 行中的健全性檢查，並使第 261 行中的減法無關緊要。最後，有趣的部分出現了：如第 262 到 265 行所示，兩個接收者的餘額將加上極大的 _value，而不會花費攻擊者的口袋裡的一角錢！
文章圖片：
所以現在，當黑客輸入號碼時，得到的號碼非常龐大。在下一步中，這個數字甚至會隨著與接收者數量（假設為 2）的 cnt 相乘而變得更高。
由於黑客轉移的金額遠高於他的餘額，為什麼執行沒有在第 259 行停止？
有人可以向我解釋這裡到底發生了什麼嗎？
由於黑客轉移的金額遠高於他的餘額，為什麼執行沒有在第 259 行停止？
如果使用參數呼叫合約
batchTransfer([addressA,addressB],0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000)第 257 行變為
uint256 amount = 2 * 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000由於溢出，這是 0x0。
所以
amount在隨後的評估中是0。所以第259行的檢查變為：require(0x8000,0... > 0 && balance[msg.sender] >= 0);的參數
require評估為真，因此契約執行將繼續。並且在 for 循環中，大量的0x800....將被轉移到addressAandaddressB並且 0（溢出計算的結果）將從發起者的餘額中減去。代幣總量剛剛增加了 2^256 個代幣。
談論惡性通貨膨脹！