KCon議題解讀 | 以太坊智能合約 OPCODE 逆向之調試器篇
責編：gltian ｜2018-09-06 11:01:03Remix調試器
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
內存相關設置的指令分為三類
- MSTORE, 儲存0x20字節長度的數據到內存中
- MSTORE8, 儲存1字節長度的數據到內存中
- 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, 剩下的工作就是實現自己想實現的調試器功能，比如下斷點，查看棧內存儲存數據等