作者：Hcamael@知道創宇404區塊鏈安全研究團隊
時間：2018/09/04

上一篇《以太坊智能合約 OPCODE 逆向之理論基礎篇》，對智能合約的OPCODE的基礎數據結構進行了研究分析，本篇將繼續深入研究OPCODE，編寫一個智能合約的調試器。

Remix調試器

Remix帶有一個非常強大的Debugger，當我的調試器寫到一半的時候，才發現了Remix自帶調試器的強大之處，本文首先，對Remix的調試器進行介紹。

能調試的范圍：

1. 在Remix上進行每一個操作(創建合約/調用合約/獲取變量值)時，在執行成功后，都能在下方的控制界面點擊DEBUG按鈕進行調試

2. Debugger能對任意交易進行調試，只需要在調試窗口輸入對應交易地址

3. 能對公鏈，測試鏈，私鏈上的任意交易進行調試

點擊Environment可以對區塊鏈環境進行設置，選擇Injected Web3，環境取決去瀏覽器安裝的插件

比如我，使用的瀏覽器是Chrome，安裝的插件是MetaMask

通過MetaMask插件，我能選擇環境為公鏈或者是測試鏈，或者是私鏈

當Environment設置為Web3 Provider可以自行添加以太坊區塊鏈的RPC節點，一般是用于設置環境為私鏈

4. 在JavaScript的EVM環境中進行調試

見3中的圖，把Environment設置為JavaScript VM則表示使用本地虛擬環境進行調試測試

在調試的過程中能做什么？

Remix的調試器只提供了詳細的數據查看功能，沒法在特定的指令對STACK/MEM/STORAGE進行操作

在了解清楚Remix的調試器的功能后，感覺我進行了一半的工作好像是在重復造輪子。

之后仔細思考了我寫調試器的初衷，今天的WCTF有一道以太坊智能合約的題目，因為第一次認真的逆向EVM的OPCODE，不熟練，一個下午還差一個函數沒有逆向出來，然后比賽結束了，感覺有點遺憾，如果當時能動態調試，可能逆向的速度能更快。

Remix的調試器只能對已經發生的行為(交易)進行調試，所以并不能滿足我打CTF的需求，所以對于我寫的調試器，我轉換了一下定位：調試沒有源碼，只有OPCODE的智能合約的邏輯，或者可以稱為離線調試。

調試器的編寫

智能合約調試器的編寫，我認為最核心的部分是實現一個OPCODE解釋器，或者說是自己實現一個EVM。

實現OPCODE解釋器又分為兩部分，1. 設計和實現數據儲存器(把STACK/MEM/STORAGE統稱為數據儲存器)，2. 解析OPCODE指令

數據儲存器

STACK

根據OPCODE指令的情況，EVM的棧和計算機的棧數據結構是一個樣的，先入先出，都有PUSH和POP操作。不過EVM的棧還多了SWAP和DUP操作，棧交換和棧復制，如下所示，是我使用Python實現的EVM棧類:

class STACK(Base):
    """
    evm stack
    """
    stack: [int]
    max_value: int
    def __init__(self):
        self.stack = []
        self.max_value = 2**256
    def push(self, data: int):
        """
        OPCODE: PUSH
        """
        self.stack.append(data % self.max_value)
    def pop(self) -> (int):
        """
        OPCODE POP
        """
        return self.stack.pop()
    @Base.stackcheck
    def swap(self, n):
        """
        OPCODE: SWAPn(1-16)
        """
        tmp = self.stack[-n-1]
        self.stack[-n-1] = self.stack[-1]
        self.stack[-1] = tmp
    @Base.stackcheck
    def dup(self, n):
        """
        OPCODE: DUPn(1-16)
        """
        self.stack.append(self.stack[-n])

和計算機的棧比較，我覺得EVM的棧結構更像Python的List結構

計算機的棧是一個地址儲存一個字節的數據，取值可以精確到一個字節，而EVM的棧是分塊儲存，每次PUSH占用一塊，每次POP取出一塊，每塊最大能儲存32字節的數據，也就是2^256-1，所以上述代碼中，對每一個存入棧中的數據進行取余計算，保證棧中的數據小于2^256-1

MEM

EVM的內存的數據結構幾乎和計算機內存的一樣，一個地址儲存一字節的數據。在EVM中，因為棧的結構，每塊儲存的數據最大為256bits，所以當OPCODE指令需要的參數長度可以大于256bits時，將會使用到內存

如下所示，是我使用Python實現的MEM內存類:

class MEM(Base):
    """
    EVM memory
    """
    mem: bytearray
    max_value: int
    length: int
    def __init__(self):
        self.mem = bytearray(0)
        self.max_value = 2**256
        self.length = 0
        self.extend(1)
    @Base.memcheck
    def set(self, key: int, value: int):
        """
        OPCODE: MSTORE
        """
        value %= self.max
        self.mem[key: key+0x20] = value.to_bytes(0x20, "big")
        self.length += 0x20
    @Base.memcheck
    def set_byte(self, key: int, value: int):
        """
        OPCODE: MSTORE8
        """
        self.mem[key] = value  & 0xff
        self.length += length
    @Base.memcheck
    def set_length(self, key: int, value: int, length: int):
        """
        OPCODE: XXXXCOPY
        """
        value %= (2**(8*length))
        data = value.to_bytes(length, "big")
        self.mem[key: key+length] = data
        self.length += length
    @Base.memcheck
    def get(self, key: int) -> (int):
        """
        OPCODE: MLOAD
        return uint256
        """
        return int.from_bytes(self.mem[key: key+0x20], "big", signed=False)
    @Base.memcheck
    def get_bytearray(self, key: int) -> (bytearray):
        """
        OPCODE: MLOAD
        return 32 byte array
        """
        return self.mem[key: key+0x20]
    @Base.memcheck
    def get_bytes(self, key: int) -> (bytes):
        """
        OPCODE: MLOAD
        return 32 bytes
        """
        return bytes(self.mem[key: key+0x20])
    @Base.memcheck
    def get_length(self, key:int , length: int) -> (int):
        """
        return mem int value
        """
        return int.from_bytes(self.mem[key: key+length], "big", signed=False)
    @Base.memcheck
    def get_length_bytes(self, key:int , length: int) -> (bytes):
        """
        return mem bytes value
        """
        return bytes(self.mem[key: key+length])
    @Base.memcheck
    def get_length_bytearray(self, key:int , length: int) -> (bytearray):
        """
        return mem int value
        """
        return self.mem[key: key+length]
    def extend(self, num: int):
        """
        extend mem space
        """
        self.mem.extend(bytearray(256*num))

使用python3中的bytearray類型作為MEM的結構，默認初始化256B的內存空間，因為有一個OPCODE是MSIZE:

Get the size of active memory in bytes.

所以每次設置內存值時，都要計算active memory的size

內存相關設置的指令分為三類

  1. MSTORE, 儲存0x20字節長度的數據到內存中
  2. MSTORE8, 儲存1字節長度的數據到內存中
  3. CALLDATACOPY(或者其他類似指令)，儲存指定字節長度的數據到內存中

所以對應的設置了3個不同的儲存數據到內存中的函數。獲取內存數據的類似。

STORAGE

EVM的STORAGE的數據結構和計算機的磁盤儲存結構相差就很大了，STORAGE是用來儲存全局變量的，全局變量的數據結構我在上一篇文章中分析過，所以在用Python實現中，我把STORAGE定義為了字典，相關代碼如下:

class STORAGE(Base):
    """
    EVM storage
    """
    storage: {str: int}
    max: int
    def __init__(self, data):
        self.storage = data
        self.max = 2**256
    @Base.storagecheck
    def set(self, key: str, value: int):
        self.storage[key] = value % self.max
    @Base.storagecheck
    def get(self, key: str) -> (int):
        return self.storage[key]

因為EVM中操作STORAGE的相關指令只有SSTORE和SLOAD，所以使用python的dict類型作為STORAGE的結構最為合適

解析OPCODE指令

對于OPCODE指令的解析難度不是很大，指令只占一個字節，所以EVM的指令最多也就256個指令(0x00-0xff)，但是有很多都是處于UNUSE，所以以后智能合約增加新指令后，調試器也要進行更新，因此現在寫的代碼需要具備可擴展性。雖然解析指令的難度不大，但是仍然是個體力活，下面先來看看OPCODE的分類

OPCODE分類

在以太坊官方黃皮書中，對OPCODE進行了相應的分類:

0s: Stop and Arithmetic Operations (從0x00-0x0f的指令類型是STOP指令加上算術指令)

10s: Comparison & Bitwise Logic Operations (0x10-0x1f的指令是比較指令和比特位邏輯指令)

20s: SHA3 (目前0x20-0x2f只有一個SHA3指令)

30s: Environmental Information (0x30-0x3f是獲取環境信息的指令)

40s: Block Information (0x40-0x4f是獲取區塊信息的指令)

50s: Stack, Memory, Storage and Flow Operations (0x40-0x4f是獲取棧、內存、儲存信息的指令和流指令(跳轉指令))

60s & 70s: Push Operations (0x60-0x7f是32個PUSH指令，PUSH1-PUSH32)

80s: Duplication Operations (0x80-0x8f屬于DUP1-DUP16指令)

90s: Exchange Operations (0x90-0x9f屬于SWAP1-SWAP16指令)

a0s: Logging Operations (0xa0-0xa4屬于LOG0-LOG4指令)

f0s: System operations (0xf0-0xff屬于系統操作指令)

設計可擴展的解釋器

首先，設計一個字節和指令的映射表:

import typing

class OpCode(typing.NamedTuple):
    name: str
    removed: int            # 參數個數
    args: int               # PUSH根據該參數獲取opcode之后args字節的值作為PUSH的參數

_OPCODES = {
    '00': OpCode(name = 'STOP', removed = 0, args = 0),
    ......
}

for i in range(96, 128):
    _OPCODES[hex(i)[2:]] = OpCode(name='PUSH' + str(i - 95), removed=0, args=i-95)
......

# 因為編譯器優化的問題，OPCODE中會出現許多執行不到的，UNUSE的指令，為防止解析失敗，還要對UNUSE的進行處理
for i in range(0, 256):
    if not _OPCODES.get(hex(i)[2:].zfill(2)):
            _OPCODES[hex(i)[2:].zfill(2)] = OpCode('UNUSE', 0, 0)

然后就是設計一個解釋器類:

class Interpreter:
    """
    EVM Interpreter
    """
    MAX = 2**256
    over = 1
    store: EVMIO
    #############
    #  0s: Stop and Arithmetic Operations
    #############
    @staticmethod
    def STOP():
        """
        OPCODE: 0x00
        """
        Interpreter.over = 1
        print("========Program STOP=========")
    @staticmethod
    def ADD(x:int, y:int):
        """
        OPCODE: 0x01
        """
        r = (x + y) % Interpreter.MAX
        Interpreter.store.stack.push(r)
......
  • MAX變量用來控制計算的結果在256bits的范圍內
  • over變量用來標識程序是否執行結束
  • store用來訪問runtime變量: STACK, MEM, STORAGE

在這種設計模式下，當解釋響應的OPCODE，可以直接使用

args = [stack.pop() for _ in OpCode.removed]
getattr(Interpreter, OpCode.name)(*args)

特殊指令的處理思路

在OPCODE中有幾類特殊的指令:

1. 獲取區塊信息的指令，比如:

NUMBER: Get the block’s number

該指令是獲取當前交易打包進的區塊的區塊數(區塊高度)，解決這個指令有幾種方案:

  • 設置默認值
  • 設置一個配置文件，在配置文件中設置該指令的返回值
  • 調試者手動利用調試器設置該值
  • 設置RPC地址，從區塊鏈中獲取該值

文章的開頭提過了對我編寫的調試器的定位問題，也正是因為遇到該類的指令，才去思考調試器的定位。既然已經打包進了區塊，說明是有交易地址的，既然有交易地址，那完全可以使用Remix的調試器進行調試。

所以對我編寫的調試器有了離線調試器的定位，采用上述方法中的前三個方法，優先級由高到低分別是，手動設置>配置文件設置>默認設置

2. 獲取環境信息指令，比如:

ADDRESS: Get address of currently executing account.

獲取當前合約的地址，解決方案如下:

  • 設置默認值
  • 設置一個配置文件，在配置文件中設置該指令的返回值
  • 調試者手動利用調試器設置該值

獲取環境信息的指令，因為調試的是OPCODE，沒有源碼，不需要部署，所以是沒法通過RPC獲取到的，只能由調試者手動設置

3. 日志指令

LOG0-LOG4: Append log record with no topics.

把日志信息添加到交易的回執單中

> eth.getTransactionReceipt("0xe32b3751a3016e6fa5644e59cd3b5072f33f27f10242c74980409b637dbb3bdc")
{
  blockHash: "0x04b838576b0c3e44ece7279b3b709e336a58be5786a83a6cf27b4173ce317ad3",
  blockNumber: 6068600,
  contractAddress: null,
  cumulativeGasUsed: 7171992,
  from: "0x915d631d71efb2b20ad1773728f12f76eeeeee23",
  gasUsed: 81100,
  logs: [],
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  status: "0x1",
  to: "0xd1ceeeefa68a6af0a5f6046132d986066c7f9426",
  transactionHash: "0xe32b3751a3016e6fa5644e59cd3b5072f33f27f10242c74980409b637dbb3bdc",
  transactionIndex: 150
}

上述就是獲取一個交易的回執單，其中有一個logs列表，就是用來儲存日志信息

既然是在調試OPCODE，那么記錄日志的操作就是沒有必要的，因為調試的過程中能看到儲存器/參數的情況，所以對于這類指令的操作，完全可以直接輸出，或者不做任何處理(直接pass)

4. 系統操作指令

這類指令主要是外部調用相關的指令，比如可以創建合約的CREATE, 比如能調用其他合約的CALL, 比如銷毀自身，并把余額全部轉給別人的SELFDESTRUCT

這類的指令我認為的解決辦法只有: 調試者手動利用調試器設置該指令的返回值

調用這類函數的時候，我們完全能看到詳細的參數值，所以完全可以手動的進行創建合約，調用合約等操作

總結

在完成一個OPCODE的解釋器后，一個調試器就算完成了3/4, 剩下的工作就是實現自己想實現的調試器功能，比如下斷點，查看棧內存儲存數據等

下面放一個接近成品的演示gif圖:

智能合約審計服務

針對目前主流的以太坊應用，知道創宇提供專業權威的智能合約審計服務，規避因合約安全問題導致的財產損失，為各類以太坊應用安全保駕護航。

知道創宇404智能合約安全審計團隊： https://www.scanv.com/lca/index.html

聯系電話：(086) 136 8133 5016(沈經理，工作日:10:00-18:00)

歡迎掃碼咨詢：

區塊鏈行業安全解決方案

黑客通過DDoS攻擊、CC攻擊、系統漏洞、代碼漏洞、業務流程漏洞、API-Key漏洞等進行攻擊和入侵，給區塊鏈項目的管理運營團隊及用戶造成巨大的經濟損失。知道創宇十余年安全經驗，憑借多重防護+云端大數據技術，為區塊鏈應用提供專屬安全解決方案。

歡迎掃碼咨詢：

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/693/