解讀技術大佬對Cetus Protocol黑客攻擊事件的分析

通俗版本：簡單“翻譯”解讀下技術大佬關於 @CetusProtocol

黑客攻擊事件的分析：

這次攻擊暴露的是一個經典的整數溢出問題，具體表現爲類型轉換過程中的數據截斷。

技術細節拆解：

1）漏洞定位：問題出現在get_amount_by_liquidity函數的類型轉換機制中，從u256到u64的強制轉換導致高位數據丟失。

2）攻擊流程：

1、攻擊者通過add_liquidity函數傳入極大的流動性數量參數；

2、系統調用get_delta_b函數計算所需的B代幣數量；

3、在計算過程中，兩個u128類型數據相乘，理論結果應爲u256類型；

關鍵缺陷：函數返回時將u256結果強制轉換爲u64，導致高位128位數據被截斷。

3）利用效果：原本需要大量代幣才能鑄造的流動性額度，現在僅需極少量代幣即可完成。攻擊者以極低成本獲得巨額流動性份額，隨後通過銷毀部分流動性實現資金池套利。

簡單類比：就像用只能顯示8位數的計算器計算10億×10億，20位的計算結果只能顯示後8位，前12位直接消失。攻擊者正是利用了這種"計算精度缺失"漏洞。

需要明確一點：這次漏洞與 @SuiNetwork 的底層安全架構無關，屬於Move語言的安全性“榮光”暫時還可信。Why？

Move語言在資源管理和類型安全方面確實具備顯著優勢，能夠有效防範雙重支付、資源泄露等底層安全問題。但此次Cetus協議出現的是應用邏輯層面的數學計算錯誤，並非Move語言本身的設計缺陷。

具體而言，Move的類型系統雖然嚴格，但對於顯式類型轉換（explicit casting）操作，仍需依賴開發者的正確判斷。當程序主動執行u256到u64的類型轉換時，編譯器無法判斷這是有意設計還是邏輯錯誤。

此外，這次安全事件與Sui的共識機制、交易處理、狀態管理等核心底層功能完全無關。Sui Network只是忠實執行了Cetus協議提交的交易指令，漏洞源於應用層協議本身的邏輯缺陷。

說白了，再先進的編程語言也無法完全杜絕應用層的邏輯錯誤。Move能夠防範大部分底層安全風險，但無法代替開發者進行業務邏輯的邊界檢查和數學運算的溢出保護。

更正：

跟大佬進一步溝通了下，此前對 @CetusProtocol 黑客攻擊的技術分析在具體細節上存在偏差，特此更正。

此前準確識別了這是一個數學計算溢出類漏洞，攻擊者通過構造特殊數值"以小博大"的核心邏輯是對的，對大家關心的Move語言的安全性疑惑解答也是對的。

只不過看到了數學計算錯誤的現象，推測是類型轉換問題，但實際是其他函數的邊界檢查問題。事實上，Move語言對u256到u64等類型轉換有嚴格的審查機制，這類顯式轉換在正常情況下確實會有安全檢查。

具體的漏洞位置和技術實現機制需要修正，如下。

真正的問題出現在get\_delta\_a函數的溢出檢查機制失效：

1）函數作用：計算添加指定流動性時需要的token A數量；

2）關鍵缺陷：checked\_shlw函數的溢出檢查存在編碼錯誤，未能阻止無效的大流動性值；

3）攻擊利用：黑客構造特殊流動性值，繞過失效檢查，最終通過div\_round的向上取整機制，讓所需token A數量變成14）。

攻擊效果：用1個token A鑄造巨額流動性，然後抽幹資金池。