審計工具沒有報錯,合約就安全了嗎?本系列以 DeFiHackLabs 公開的真實案例為題材,依序使用 Slither 靜態分析、Foundry 動態測試與 Certora Rule 形式化驗證,比較不同方法能發現什麼、需要哪些前提,以及為何可能誤報或漏報。最後討論 LLM 在審計流程中的角色,整理出一套從 Detect 到 Prove 的實作方法。
區塊鏈的出現,讓金融有了更多有別於傳統的操作方式,但卻也帶來前所未有的風險與安全問題。這些安全問題可能導致金錢的直接損失。光是 2026 上半年,CertiK...
上一篇提到,這個系列會先聚焦 EVM 智慧合約。但馬上遇到另一個問題:同一種安全問題,在不同網站上可能有不同名稱;有些文件列的是弱點類型,有些整理的是具體漏洞,...
上一篇整理了漏洞的分類,接下來就要開始實際檢查合約了。在跑工具以前,先介紹主要使用到的幾個智慧合約審計工具和一個資料集。 這三個工具會交出不同的東西:Slith...
上一篇介紹了三個工具和 DeFiHackLabs,今天開始實際跑,先從最容易上手的 Slither 開始。案例從 DeFiHackLabs 挑了一個很小的,受害...
上一篇用 Slither 掃了 FlippazOne,找到沒有加 onlyOwner 的 ownerWithdrawAllTo。這篇來看 Slither 在報出...
上一篇的 Slither 輸出有 40 個 Findings,並且說明其中一個是已知攻擊的根因,今天說明 Slither 評估方式與優缺點。 評估指標 要計算這...
上一篇提到,Slither 的 detector 只能找已經寫成規則的問題。Level Finance 的重複領取漏洞就是一個沒有 Finding 的案例。 歷...
上一篇的 Level Finance 合約有業務邏輯漏洞,但 Slither 沒有對應的 detector。今天換一個 reentrancy-eth 能直接找到...