Building a Solid Mindset for Auditing Move Contracts | DeFi Security Summit 2025

本場演講的核心命題是：傳統 EVM 安全工程師在轉向 Move 生態（Aptos、Sui）時，若照搬既有思維，將會錯過 Move 獨有的漏洞模式。講者將內容分為兩大部分：語言無關的通用漏洞方法論，以及 Move 架構本身帶來的特殊攻擊面。

首先從架構差異切入。EVM 以合約為中心，狀態資料直接存於合約本身；而 Aptos 將資料與合約分開，儲存在帳戶層級；Sui 則更進一步，將資料封裝為獨立存在於鏈上的物件（Object），這些物件不從屬於任何智能合約。這種資料模型的根本差異，直接影響了攻擊路徑的分析方式。此外，Move 的編譯器會在編譯期就攔截潛在的執行時錯誤，這讓許多 EVM 常見的執行期漏洞在 Move 中從源頭被消除。至於重入攻擊，Move 傳統上也因為其執行模型而天然免疫——而 EVM 的重入防護機制甚至直到演講前數天才正式推出，突顯了兩者的設計哲學差距。

在語言無關的審計方法論上，講者強調必須以狀態機框架來分析去中心化協議。一個 DeFi 協議通常會經歷「開放 → 活躍 → 高風險 → 關閉」等狀態，審計員需要在每個狀態轉換邊界上窮舉異常情境。配合狀態機分析的，是不變量（invariant）的定義：先明確列出協議的核心不變量（例如「總抵押物永遠大於總借款」），再系統性地尋找能使其失效的反例，找到的即為漏洞所在。

進入 Move 特有漏洞，講者重點介紹兩個模式。第一是 Capability Object：Sui 使用能力物件來門控特定函式，概念上等同於 EVM 的 `onlyOwner` modifier，但以物件傳遞而非地址比對實現。能力物件通常在合約初始化時建立，且只有管理員能持有。安全審計的關鍵問題是：是否存在某條程式路徑可以「強制建立」這類能力物件？若有，攻擊者便能繞過所有權限控制。第二是 Hot Potato 模式：這是 Move 用來強制回調的設計——建立一個無法被丟棄（drop）的物件，要求呼叫方必須呼叫特定函式來消耗它。閃電貸即是典型應用：借款時建立 Hot Potato 物件，還款函式消耗該物件以完成交易。審計重點在於：是否存在某個錯誤的程式路徑，讓該物件被隱式丟棄？若有，攻擊者便可借款而不還款。