深入EVM-合約分類這件小事背後的風險

在智能合約領域,”以太坊虛擬機EVM” 以及其算法和數據結構就是第一性原理。

本文從合約為什麼要分類出發,結合每個場景可能面對怎樣的惡意攻擊,最終給出一套達成相對安全的合約分類分析算法。

雖然技術含量較高,但亦可作為雜談讀物,一覽去中心化系統間博弈的黑暗森林。

1、合約為什麼要分類?

因為太重要了,可謂是交易所、錢包、區塊鏈瀏覽器、數據分析平台等等 Dapp 的基石!

一筆交易之所以是 ERC 20 轉賬,是因為他的行為符合 ERC 20 標準,至少得有:

  1. 交易的狀態是成功

  2. To 地址為某個符合 ERC 20 標準的合約

  3. 調用了 Transfer 函數,其特點是該交易 CallData 的前 4 位為0x a 9059 cbb

  4. 執行後,在該 To 地址上發出了transfer的事件

分類有誤則交易行為會誤判

以交易行為為基石,則 To 地址能否被準確分類則對其 CallData 的判斷會有截然不然的結論。對 Dapp 而言,鏈上鍊下的信息溝通高度依賴於交易事件的監聽,而同樣的事件編碼也只有在符合標準的合約中發出,才具有可信度。

分類有誤則交易會誤入黑洞

如果用戶進行一筆 Token 轉移,轉入到某個合約中,如果該合約沒有預設 Token 轉出的函數方法,則資金會雷同於 Burn 一樣被鎖定,無法控制

且如今大量項目開始增加內置的錢包支持,要為用戶管理錢包也就不可避免的,需要時刻從鏈上實時分類出最新部署的合約,是否能夠吻合資產標準。

2、分類會有怎樣的風險?

鏈上是一個沒有身份沒有法治的地方,你無法制止一筆正常的交易,哪怕他是惡意的。

他可以是冒充外婆的狼,做出多數符合你預期的外婆行為,但目的是進屋搶劫。

聲明標準,但可能實質不符合

常見的分類方式是直接採用 EIP-165 標準,讀取該地址是否支持 ERC 20 等,當然,這是一個高效率的方法,但是畢竟合約是對方控制,所以終究是可以偽造出一份申明。

165 標準的查詢,只是在鏈上有限的操作碼中,用最低成本去防止資金轉入黑洞的方法。

這也是為什麼我們之前分析 NFT 的時候,特地提及標準中會有一類SafeTransferFrom的方法,其中Safe就是指代了採用 165 標準判斷出對方聲明自己具備了 NFT 的轉移能力。

唯有從合約字節碼出發,做源碼層面的靜態分析,從合約預期的行為出發才有更精準的可能性。

3、合約分類方案設計

接下來咱們將系統的分析整體方案,注意我們的目的是“精度”和“效率”兩項核心指標。

要知道即使方向是對的,但要抵達大洋的彼岸路途也並不明朗,要做字節碼分析的第一站是獲取代碼

3.1、如何獲取到代碼?

從上鍊後的角度講有getCode,一個 RPC 方法,可以從鏈上指定的地址裡獲取到字節碼,單論讀取的話這是非常快捷的,因為從 EVM 的賬號結構中就把 codeHash 放在最頂端的位置。

深入EVM-合約分類這件小事背後的風險

但是這個方法等於是單獨對某個地址做獲取,想要進一步提升精度和效率呢?

如果是部署合約的交易,如何在其剛執行完甚至他還在內存池中便獲取部署的代碼?

如果該筆交易是合約工廠的模式,則交易的 Calldata 裡是否存在源碼呢?

最後的我的方式是,是分類進行一種類似篩子的模式

  1. 對於非合約部署的交易,則直接用getCode獲取其中涉及的地址進行分類,

  2. 對於最新內存池的交易,篩選出 to 地址為空的交易,其 CallData 則是帶有構造函數的源代碼

  3. 對於合約工廠模式的交易,由於其中可能是合約部署出的合約再循環調用其他合約來執行部署,則遞歸的去分析該筆交易的子交易,記錄每個 type 為CREATE或者為CREATE 2 的 Call。

我做了個 demo 實現的時候,發現還好現在 rpc 的版本比較高,因為整個過程最難的便是執行 3 的時候,如何遞歸找到指定 type 的 call,最底層的方式是通過 opcode 還原上下文,我吃了一驚!

還好現在的 geth 版本里有debug_traceTransaction 方法,他可以幫助解決在通過 opcode 操作碼中梳理每一個 call 的上下文信息,整理出核心的字段。

最終可以對多種部署模式的(直接部署,工廠模式單部署,工廠模式批量部署)的原始字節碼都獲取到。

3.2、如何從代碼分類?

最最簡單但不安全的方式,是把 code 直接做字符串匹配,以 ERC 20 為例符合標準的函數則有

深入EVM-合約分類這件小事背後的風險

在函數名之後的,則是該函數的函數簽名,之前在分析的時候提及,交易都是依賴匹配 callData 的前 4 位找到目標函數的,拓展閱讀:

所以合約字節碼裡必然存儲有這 6 個函數的簽名。

當然,這種方法非常快捷 6 個都查到就完事的,但不安全的因素則是,如果我採用 solidity 合約中,單獨設計一個變量,存儲值為0x 18160 ddd 那麼他也會將認為我有了這個函數。

3.3、準確率提升 1-反編譯

那進一步的準確方法則是做 Opcode 的反編譯!反編譯則是將獲取到的字節碼轉到操作碼的過程,更高級的反編譯則是再轉成偽代碼,更利於人的閱讀,這次我們用不上,反編譯的方法列於文末的附錄中。

solidity(高級語言)->bytecode(字節碼)->opcode(操作碼)

我們就可以清晰的發現一個特徵,函數簽名都會被PUSH 4 這個操作碼所執行,所以進一步的方法則是從全文中提取PUSH 4 後的內容,與函數標準做匹配。

深入EVM-合約分類這件小事背後的風險

我也簡單做了下性能實驗,不得不說 Go 語言的效率很強大, 1 W 次反編譯只需要 220 ms。

接下來的內容會有一定難度

3.4、準確率提升 2-找代碼塊

上文中準確率有所提升但還不夠,因為是全文搜索PUSH 4 的,因為我們仍然可以構建一個變量,是byte 4 的類型,這樣一來也會觸發PUSH 4 的指令。

在我苦惱的時候,想到一些開源項目的實現,ETL 是一個讀取鏈上數據做分析的工具,其中會解析出 ERC 20、 721 的轉移單獨成表,所以必然具備分類合約的能力。

深入EVM-合約分類這件小事背後的風險

分析下來,可以發現他是基於代碼塊的分類,只處理第一個basic_blocks[ 0 ]裡的push 4 指令

那問題來到了,如何準確判斷代碼塊了

代碼塊的概念源於REVERT + JUMPDEST 這 2 個連續的操作碼,這裡必然需要連續的 2 個,因為在整個函數選取器的 opcode 區間裡,如果函數數量過多,則會出現翻頁的邏輯,那也會出現JUMPDEST 這個指令。

深入EVM-合約分類這件小事背後的風險

3.5、準確率提升 3-找函數選擇器

函數選擇器的作用是,讀取該筆交易的 Calldata 的前 4 位字節,並與代碼中預設有的合約函數簽名進行匹配,協助指令跳轉到存儲了該函數方法指定的內存位置

讓我們嘗試一個最小的模擬執行

這部分是兩個函數的選擇器store(uint 256)和retrieve(),可算出簽名是2 e 64 cec 1 , 6057361 d

深入EVM-合約分類這件小事背後的風險

進行反編譯後,則會得到如下的操作碼串,可以說分兩個部分

第一部分:

在編譯器中在合約中僅函數選擇器部分會去獲取到 callData 的內容,寓意是獲取其 CallData 的函數調用簽名,註釋如下圖。

深入EVM-合約分類這件小事背後的風險

我們可以通過模擬 EVM 的內存池變化來看看效果

深入EVM-合約分類這件小事背後的風險

第二部分:

判斷是否與選擇器的值匹配的過程

1、將 retrieve()的 4 字節函數簽名(0x 2 e 64 cec 1)傳入 stack 上,

2、EQ 操作碼從 stack 區彈出 2 個變量,即0x 2 e 64 cec 1 和0x 6057361 d,並檢查它們是否相等

3、PUSH 2 將 2 個字節的數據(這里為0x 003 b,十進制為 59)傳入 stack,stack 區有一個叫做程序計數器的東西,它規定了下一個執行命令在字節碼中的位置。這裡我們設置 59 ,因為那是 retrieve()字節碼的起始位置

4、JUMPI 代表”如果…,則跳轉至…”,它從 stack 中彈出 2 個值作為輸入,如果條件為真,程序計數器將被更新至 59 。

這就是 EVM 是如何根據合約中的函數調用,來確定它需要執行的函數字節碼的位置的原理。

實際上,這只是一組簡單的“if 語句”,用於合約中的每個函數以及它們的跳轉位置。

深入EVM-合約分類這件小事背後的風險

4、方案總結

整體簡述如下

  1. 每個合約地址可以通過 rpc getcode 或者debug_traceTransaction,獲取到部署後的bytecode ,採用 GO 中 VM 和 ASM 庫,反編譯後即獲取到opcode

  2. 合約在 EVM 運行原理中,會有以下特徵

    • 採用REVERT+JUMPDEST這 2 個連續的opcode 作為代碼塊的區分

    • 合約必然具備函數選擇器的功能,該功能也必然在第一個代碼塊上

    • 函數選擇器中,其函數方法均採用PUSH 4 作為 opcode ,

    • 該選擇器所包含的 opcode 中,會出現連續的PUSH 1 00; CALLDATALOAD; PUSH 1 e 0; SHR; DUP 1 ,核心功能是加載 callDate 數據並進行位移操作,從合約功能上其他語法不會產生

3. 對應的函數簽名在 eip 中定義,並且有必选和可選的明確說明

4.1、唯一性證明

走到這裡我們就可以說,基本實現高效率,高準確率的合約分析方法了,當然既然已經嚴謹了這麼久,不妨再嚴謹一些,我們上文方案里中基於 REVER+JUMPDEST 來做代碼塊的區分,結合其中必然的 CallDate 加載和位移來做唯一性判斷,那是否存在,我可以用 solidity 合約也實現出類似的操作碼序列呢?

我做了下對照實驗,從 solidity 語法層面雖然亦有 msg.sig 等獲取 CallData 的方法,但編譯後其 opcode 的實現方法不同

深入EVM-合約分類這件小事背後的風險

Total
0
Shares
Related Posts