深入Python解譯器理解Python中的位元組碼

我最近在參與Python位元組碼相關的工作，想與大家分享一些這方面的經驗。更準確的說，我正在參與2.6到2.7版本的CPython解譯器位元組碼的工作。

Python是一門動態語言，在命令列工具下運行時，本質上執行了下面的步驟：

• 當第一次執行到一段代碼時，這段代碼會被編譯（如，作為一個模組載入，或者直接執行）。根據作業系統的不同，這一步產生尾碼名是pyc或者pyo的二進位檔案。
• 解譯器讀取二進位檔案，並依次執行指令（opcodes）。

Python解譯器是基於棧的。要理解資料流向，我們需要知道每條指令的棧效應（如，作業碼和參數）。

探索Python二進位檔案

得到一個二進位檔案位元組碼的最簡單方式，是對CodeType結構進行解碼：

import marshalfd = open('path/to/my.pyc', 'rb')magic = fd.read(4) # 魔術數，與python版本相關date = fd.read(4) # 編譯日期code_object = marshal.load(fd)fd.close()

code_object包含了一個CodeType對象，它代表被負載檔案的整個模組。為了查看這個模組的類定義、方法等的所有嵌套編碼對象（編碼對象，原文為code object），我們需要遞迴地檢查CodeType的常量池。就像下面的代碼：

import types def inspect_code_object(co_obj, indent=''):print indent, "%s(lineno:%d)" % (co_obj.co_name, co_obj.co_firstlineno)for c in co_obj.co_consts:if isinstance(c, types.CodeType):inspect_code_object(c, indent + ' ') inspect_code_object(code_object) # 從第一個對象開始

這個案例中，我們列印出一顆編碼對象樹，每個編碼對象是其父物件的子節點。對下面的代碼：

class A:def __init__(self):passdef __repr__(self):return 'A()'a = A()print a

我們得到的樹形結果是：

(lineno:2) A(lineno:2) __init__(lineno:3) __repr__(lineno:5)

為了測試，我們可以通過compile指令，編譯一個包含Python源碼的字串，從而能夠得到一個編碼對象：

co_obj = compile(python_source_code, '', 'exec')

要擷取更多關於編碼對象的資訊，我們可以查閱Python文檔的co_* fields 部分。

初見位元組碼

一旦我們得到了編碼對象，我們就可以開始對它進行拆解了（在co_code欄位）。從位元組碼中解析出它的含義：

• ? 解釋作業碼的含義
• ? 提取任意參數

dis模組的disassemble函數展示了是如何做到的。對我們前面例子，它輸出的結果是：

2 0 LOAD_CONST 0 ('A') 3 LOAD_CONST 3 (()) 6 LOAD_CONST 1 (", line 2>) 9 MAKE_FUNCTION 0 12 CALL_FUNCTION 0 15 BUILD_CLASS 16 STORE_NAME 0 (A) 8 19 LOAD_NAME  0 (A) 22 CALL_FUNCTION 0 25 STORE_NAME 1 (a) 9 28 LOAD_NAME  1 (a) 31 PRINT_ITEM 32 PRINT_NEWLINE 33 LOAD_CONST 2 (None) 36 RETURN_VALUE

我們得到了：

• 行號（當它改變時）
• 指令的序號
• 當前指令的作業碼
• 巨集指令引數（oparg），作業碼用它來計算實際的參數。例如，對於LOAD_NAME作業碼，巨集指令引數指向tuple co_names的索引。
• 計算後的實際參數（圓括弧內）

對於序號為6的指令，作業碼LOAD_CONST的巨集指令引數，指向需要從tuple co_consts載入的對象。這裡，它指向A的類型定義。同樣的，我們能夠繼續並反編譯所有的代碼對象，得到模組的全部位元組碼。

位元組碼的第一部分（序號0到16），與A的類型定義有關；其他的部分是我們執行個體化A，並列印它的代碼。

有趣的位元組碼構造

所有的作業碼都是相當直接易懂的，但是由於下面的原因，在個別情況下會顯得奇怪：

• 編譯器最佳化
• 解譯器最佳化（因此會導致加入額外的作業碼）

順序變數賦值

首先，我們看看順序地對多個元素賦值，會發生什麼：


(1) a, b = 1, '2'(2) a, b = 1, e(3) a, b, c = 1, 2, e(4) a, b, c, d = 1, 2, 3, e

這4中語句，會產生差別相當大的位元組碼。

第一種情況最簡單，因為賦值操作的右值（RHS）只包含常量。這種情況下，CPython會建立一個(1, ‘a') 的t uple，使用UNPACK_SEQUENCE作業碼，把兩個元素壓到棧上，並對變數a和b分別執行STORE_FAST操作：


0 LOAD_CONST 5 ((1, '2'))3 UNPACK_SEQUENCE 26 STORE_FAST 0 (a)9 STORE_FAST 1 (b)

而第二種情況，則在右值引入了一個變數，因此一般情況下，會調用一條取值指令（這裡簡單地調用了LOAD_GLOBAL指令）。但是，編譯器不需要在棧上為這些值建立一個新的tuple，也不需要調用UNPACK_SEQUENCE（序號18）；調用ROT_TWO就足夠了，它用來交換棧頂的兩個元素（雖然交換指令19和22也可以達到目的）。


12 LOAD_CONST 1 (1)15 LOAD_GLOBAL 0 (e)18 ROT_TWO19 STORE_FAST 0 (a)22 STORE_FAST 1 (b)

第三種情況變得很奇怪。把運算式放到棧上與前一種情況的處理方式相同，但是在交換棧頂的3個元素後，它再次交換了棧頂的2個元素：


25 LOAD_CONST 1 (1)28 LOAD_CONST 3 (2)31 LOAD_GLOBAL 0 (e)34 ROT_THREE35 ROT_TWO36 STORE_FAST 0 (a)39 STORE_FAST 1 (b)42 STORE_FAST 2 (c)

最後一種情況是通用的處理方式，ROT_*操作看起來行不通了，編譯器建立了一個tuple，然後調用UNPACK_SEQUENCE把元素放到棧上：


45 LOAD_CONST 1 (1)48 LOAD_CONST 3 (2)51 LOAD_CONST 4 (3)54 LOAD_GLOBAL 0 (e)57 BUILD_TUPLE 460 UNPACK_SEQUENCE 463 STORE_FAST 0 (a)66 STORE_FAST 1 (b)69 STORE_FAST 2 (c)72 STORE_FAST 3 (d)

函數調用構造

最後一組有趣的例子是關於函數調用構造，以及建立調用的4個作業碼。我猜測這些作業碼的數量是為了最佳化解譯器代碼，因為它不像Java，有invokedynamic，invokeinterface，invokespecial，invokestatic或者invokevirtual之一。

Java中，invokeinterface，invokespecial和invokevirtual都是從靜態類型語言中借鑒來的（invokespecial只被用來調用建構函式和父類AFAIK）。Invokestatic是自我描述的（不需要把接收方放在棧上），在Python中沒有類似的概念（在解譯器層面上，而不是裝飾者）。簡短的說，Python調用都能被轉換成invokedynamic。

在Python中，不同的CALL_*作業碼確實不存在，原因是類型系統，靜態方法，或者特殊訪問構造器的需求。它們都指向了Python中一個函數調用是如何確定的。從文法來看：

調用結構允許代碼這些寫：



func(arg1, arg2, keyword=SOME_VALUE, *unpack_list, **unpack_dict)

關鍵字參數允許通過形式參數的名稱來傳遞參數，而不僅僅是通過位置。*符號從一個可迭代的容器中取出所有元素，作為參數傳入（逐個元素，不是以tuple的形式），而**符號處理一個包含關鍵字和值的字典。

這個例子用到了調用構造的幾乎所有特性：
? 傳遞變數參數列表（_VAR）：CALL_FUNCTION_VAR, CALL_FUNCTION_VAR_KW
? 傳遞基於字典的關鍵字（_KW）：CALL_FUNCTION_KW, CALL_FUNCTION_VAR_KW

位元組碼是這樣的：


0 LOAD_NAME 0 (func)3 LOAD_NAME 1 (arg1)6 LOAD_NAME 2 (arg2)9 LOAD_CONST 0 ('keyword')12 LOAD_NAME 3 (SOME_VALUE)15 LOAD_NAME 4 (unpack_list)18 LOAD_NAME 5 (unpack_dict)21 CALL_FUNCTION_VAR_KW 258

通常，CALL_FUNCTION調用將oparg解析為參數個數。但是，更多的資訊被編碼。第一個位元組（0xff掩碼）儲存參數的個數，第二個位元組（(value >> 8) & 0xff）儲存傳遞的關鍵字參數個數。為了要計算需要從棧頂彈出的元素個數，我們需要這麼做：



na = arg & 0xff # num argsnk = (arg >> 8) & 0xff # num keywordsn_to_pop = na + 2 * nk + CALL_EXTRA_ARG_OFFSET[op]

CALL_EXTRA_ARG_OFFSET包含了一個位移量，由叫用作業碼確定（對CALL_FUNCTION_VAR_KW來說，是2）。這裡，在訪問函數名稱前，我們需要彈出6個元素。

對於其他的CALL_*調用，完全依賴於代碼是否使用列表或者字典傳遞參數。只需要簡單的組合即可。

構造一個極小的CFG

為了理解代碼是如何啟動並執行，我們可以構造一個控制流程程圖（control-flow graph，CFG），這個過程非常有趣。我們通過它，查看在什麼條件下，哪些無條件判斷的作業碼（基本單元）序列會被執行。

即使位元組碼是一門真正的小型語言，構造一個運行穩定的CFG需要大量的細節工作，遠超出本部落格的範圍。因此如果需要一個真實的CFG實現，你可以看看這裡equip。

在這裡，我們只關注沒有迴圈和異常的代碼，因此控制流程程只依賴與if語句。

只有少數幾個作業碼能夠執行地址跳轉（對沒有迴圈和異常的情況）；它們是：

JUMP_FORWARD：在位元組碼中跳轉到一個相對位置。參數是跳過的位元組數。
JUMP_IF_FALSE_OR_POP，JUMP_IF_TRUE_OR_POP，JUMP_ABSOLUTE，POP_JUMP_IF_FALSE，以及POP_JUMP_IF_TRUE：參數都是位元組碼中的絕對位址。

為一個函數夠造CFG，意味著要建立基本的單元（不包含條件判斷的作業碼序列——除非有異常發生），並且把它們與條件和分支連在一起，構成一個圖。在我們的例子中，我們只有True、False和無條件分支。

讓我們來考慮下面的程式碼範例（在實際中絕對不要這樣用）：



def factorial(n):if n <= 1:return 1elif n == 2:return 2return n * factorial(n - 1)

如前所述，我們得到factorial方法的代碼對象：



module_co = compile(python_source, '', 'exec')meth_co = module_co.co_consts[0]

反組譯碼結果是這樣的（<<<後是我的注釋）：



3  0 LOAD_FAST  0 (n)  3 LOAD_CONST  1 (1)  6 COMPARE_OP  1 (<=)  9 POP_JUMP_IF_FALSE 16  <<< control flow 4  12 LOAD_CONST  1 (1)  15 RETURN_VALUE    <<< control flow 5 >> 16 LOAD_FAST  0 (n)  19 LOAD_CONST  2 (2)  22 COMPARE_OP  2 (==)  25 POP_JUMP_IF_FALSE 32  <<< control flow 6  28 LOAD_CONST  2 (2)  31 RETURN_VALUE    <<< control flow 7 >> 32 LOAD_FAST  0 (n)  35 LOAD_GLOBAL  0 (factorial)  38 LOAD_FAST  0 (n)  41 LOAD_CONST  1 (1)  44 BINARY_SUBTRACT  45 CALL_FUNCTION  1  48 BINARY_MULTIPLY  49 RETURN_VALUE    <<< control flow

在這個位元組碼中，我們有5條改變CFG結構的指令（添加約束條件，或者允許快速退出）：

POP_JUMP_IF_FALSE：跳轉到絕對位址16和32；
RETURN_VALUE：從棧頂彈出一個元素，並返回。

提取基本單元很簡單，因為我們只關心那些改變控制流程程的指令。在我們的例子中，我們沒有遇到強制跳轉指令，如JUMP_FORWARD或JUMP_ABSOLUTE。

提取這類結構的程式碼範例：

import opcodeRETURN_VALUE = 83JUMP_FORWARD, JUMP_ABSOLUTE = 110, 113FALSE_BRANCH_JUMPS = (111, 114) # JUMP_IF_FALSE_OR_POP, POP_JUMP_IF_FALSE def find_blocks(meth_co): blocks = {} code = meth_co.co_code finger_start_block = 0 i, length = 0, len(code) while i < length: op = ord(code[i]) i += 1 if op == RETURN_VALUE: # We force finishing the block after the return,    # dead code might still exist after though... blocks[finger_start_block] = { 'length': i - finger_start_block - 1, 'exit': True } finger_start_block = i elif op >= opcode.HAVE_ARGUMENT: oparg = ord(code[i]) + (ord(code[i+1]) << 8) i += 2 if op in opcode.hasjabs: # Absolute jump to oparg blocks[finger_start_block] = {  'length': i - finger_start_block } if op == JUMP_ABSOLUTE: # Only uncond absolute jump  blocks[finger_start_block]['conditions'] = {  'uncond': oparg  } else:  false_index, true_index = (oparg, i) if op in FALSE_BRANCH_JUMPS else (i, oparg)  blocks[finger_start_block]['conditions'] = {  'true': true_index,  'false': false_index  } finger_start_block = i elif op in opcode.hasjrel: # Essentially do the same... pass  return blocks

我們得到了下面的基本單元：



Block 0: {'length': 12, 'conditions': {'false': 16, 'true': 12}}Block 12: {'length': 3, 'exit': True}Block 16: {'length': 12, 'conditions': {'false': 32, 'true': 28}}Block 28: {'length': 3, 'exit': True}Block 32: {'length': 17, 'exit': True}

以及單元的當前結構：



Basic blocks start_block_index := length := size of instructions condition := true | false | uncond -> target_index exit* := true

我們得到了控制流程程圖（除了入口和隱式的退出單元），之後我們可以把它轉化成可視化的圖形：



def to_dot(blocks):cache = {} def get_node_id(idx, buf):if idx not in cache:cache[idx] = 'node_%d' % idxbuf.append('%s [label="Block Index %d"];' % (cache[idx], idx))return cache[idx] buffer = ['digraph CFG {']buffer.append('entry [label="CFG Entry"]; ')buffer.append('exit [label="CFG Implicit Return"]; ') for block_idx in blocks:node_id = get_node_id(block_idx, buffer)if block_idx == 0:buffer.append('entry -> %s;' % node_id)if 'conditions' in blocks[block_idx]:for cond_kind in blocks[block_idx]['conditions']:target_id = get_node_id(blocks[block_idx]['conditions'][cond_kind], buffer)buffer.append('%s -> %s [label="%s"];' % (node_id, target_id, cond_kind))if 'exit' in blocks[block_idx]:buffer.append('%s -> exit;' % node_id) buffer.append('}')return 'n'.join(buffer)

可視化的流程式控制製圖：


為什麼有這篇文章？

需要訪問Python位元組碼的情況確實很少見，但是我已經遇到過幾次這種情形了。我希望，這篇文章能夠協助那些開始研究Python逆向工程的人們。

然而現在，我正在研究Python代碼，尤其是它的位元組碼。由於目前在Python中尚不存在這樣的工具（並且檢測原始碼通常會留下非常低效的裝飾器檢測代碼），這就是為什麼equip會出現的原因。

