0x00 前言

之前對Android的兩個執行時的原始碼做了一些研究，又加上如火如荼的Android加固服務的興起，便產生了打造一個用於脫殼的執行時，於是便有了DexHunter的誕生（原始碼：https://github.com/zyq8709/DexHunter/）。今天，我就通過這篇小文聊聊我的一些簡單的思路，供大家參考和討論。

0x02 相關機制

首先，先來看一看Android執行時的一些相關機制，看看我們來怎麼搞。

首當其衝，要脫殼少不了研究一下Dex檔案的格式，這一點Android的官方文件寫的已經很清晰了，我這裡就簡單再提一下。整個結構便如圖1所示：

圖1 Dex檔案結構

其實就是分割槽段儲存不同的內容，在頭部裡有指向各個區段起始的偏移值。當然我們最關心的就是class_defs和data這兩個段了。

class_defs包含了所有的類，用class_def_item來描述。圖2是對class_def_item展開的一個示意圖：

圖2 class_def_item結構

每個class_def_item指向一個class_data_item，每個class_data_item 包含了一個class的資料，每個方法用encoded_method結構來描述，它又指向了一個code_item，這個裡面就儲存著一個方法的所有指令。

對於ART下，安裝後的dex檔案會被編譯為oat檔案，這個oat檔案其實是一個ELF檔案，圖3是它的一個結構：

圖3 OAT檔案結構

其中可以看到oatdata指向的部分包含了原有的Dex檔案，這個是我們的目標。當然oatexec指向了編譯後的ARM指令，但是對於我們暫時來說沒有什麼卵用。

0x03 四個時機

為了脫殼，我們要建立一個概念，就是“時機”。對於非虛擬機器殼，從記憶體中轉儲是一個最為有效和統用的技巧，那麼就必須要找到一個時機，保證記憶體中的資料是完全正確的。

在Android中呢，便有這麼四個時機：

1. 開啟Dex檔案

   就是把APK中的dex檔案提取並做cache，那麼最終開啟的其實是odex或oat檔案；

2. 載入Class

   執行時讀取儲存在Dex中的每個class，並用來填充一個生成的Class物件，其中包含了class的所有成員，這樣一個class才能被使用；圖4表示了ART和DVM下的Class物件的結構

   

   

   圖4 Class的結構

3. 初始化Class

   如果一個class有static塊，那麼這個部分就會編譯為類的初始化器，具體看說就是方法，在class真正需要被使用的時候就會執行它，當然，殼就可以利用它來做許多事情；

4. 呼叫具體的方法

   不用多說，就是根據生成的Class物件查詢到具體的程式碼指令並執行了。

0x04 兩種載入

好，那我們怎麼做呢？很簡單，我們就從類的載入開始。

總的來說，有兩種可以載入類的方法，一個是顯示載入，主要用於反射，就是通過呼叫Class.forName()或ClassLoader.loadClass()方法來主動載入一個類；另一個是隱式載入，主要是通過建立第一個class的例項或在類產生前訪問靜態成員時發生。這些操作的背後在執行時中是有相應的函式來真正完成的。

在ART中：

顯式載入：

ClassLoader.loadClass 對應DexFile_defineClassNative

Class.forName 對應Class_classForName

隱式載入：

對應artAllocObjectFromCode

圖5表述了這個關係：

圖5 ART中的實現

在DVM中：

顯式載入：

ClassLoader.loadClass對應Dalvik_dalvik_system_DexFile_defineClassNative

Class.forName對應Dalvik_java_lang_Class_classForName

隱式載入：

對應dvmResolveClass

圖6是DVM中的實現表示：

圖6 DVM中的實現

0x05 開始修改

很清晰看到，我們找到了關鍵點，在ART中是DefineClass，DVM中是Dalvik_dalvik_system_DexFile_defineClassNative，我們就從這裡動手，主要的修改就發生在這裡。簡單地說就是主動地一次性載入並初始化所有的類。

這樣做是隱含了幾條原則的：

• 當類被載入時，dex中對應的部分必須有效；
• 類初始化的時候，dex中的內容包括生成的Class物件是可以被修改的；
• 只有在執行一個方法時，才要求code_item是有效的。

圖7就是DexHunter的一個工作流程：

圖7 DexHunter原理

下面就分這幾個步驟來說：

（1） 定位記憶體

對於之前提到的入口函式，都有一個引數表示在操作的檔案。

ART中，這個引數是DexFile物件，其中有一個location_成員，是一個字串，可以簡單的理解為此檔案的路徑。那麼DVM中是DexOrJar，相對的字串成員是fileName。這下我們就好整了，只要我們指定了目標字串，我們就可以從可能使用的眾多dex檔案中找出我們想要的那個，而且方便的是，通過這兩個物件，我們還能很容易找到操作的檔案在記憶體中的起始地址和長度。

（2） 主動載入並初始化

這個就是遍歷dex檔案中class_defs區段裡每一個class_def_item，並逐一載入和初始化，在ART裡我們使用FindClass函式來載入類，EnsureInitialized進行初始化；在DVM中用dvmDefineClass載入，dvmIsClassInitialized 和dvmInitClass來初始化。

（3） 轉儲並自動修復

最後就是真正抓取dex了。把dex分為三部分：

• Part 1: class_defs之前的內容
• Part 2: class_defs段
• Part 3: class_defs後邊的部分

我們把Part 1存在part1檔案裡，Part 3存在data檔案中，Part 2先不要急。

現在我們要解析class_defs的東東了。不整程式碼了，用文字簡單來說，就是模仿Android的過程，我們把每個class_data_item解碼為記憶體中的物件（有LEB128編碼），便於我們的修復。

下邊就要進行一些判斷看需不需要修復：

看class_def_item中的 class_data_off是不是在之前拿到的dex檔案的記憶體範圍內，如果跑出去了，就需要把這個類的class_data_item給放到dex尾部去，修改class_def_item並儲存。

比較解析出來的accessflag、codeoff和執行時生成的方法物件的accessflag、codeoff，如果不一致，以執行時中的為準，並修改儲存。

同樣，檢查code_item_off是否出界了，一旦出界，把code_item收回來，繼續向尾部新增，並修改class_def_item的相關內容重新儲存。

當然了，所謂放到尾部，只是先保證偏移值從尾部開始的，真正的內容先存在extra檔案了。被修改過的class_defs段，就儲存在classdef檔案中了。

然後我們把四個檔案重新拼起來，就得到原始的dex或odex了。

0x06 有趣的現象

最後聊一下我們看到的一些有趣的現象。

360基本上是把原始的dex加密存在了一個so中，載入之前解密。

阿里把一些class_data_item和code_item拆出去了，開啟dex時會修復之間的關係。同時一些annotation_off是無效的的來防止靜態解析。

百度是把一些class_data_item拆走了，與阿里很像，同時它還會抹去dex檔案的頭部；它也會選擇個別方法重新包裝，達到呼叫前還原，呼叫後抹去的效果。我們可以通過對DoInvoke (ART)和dvmMterp_invokeMethod (DVM)監控來獲取到相關程式碼。

梆梆和愛加密與360的做法很像，梆梆把一堆read,write, mmap等libc函式hook了，防止讀取相關dex的區域，愛加密的字串會變，但是隻是檔名變目錄不變。

騰訊針對於被保護的類或方法造了一個假的class_data_item，不包含被保護的內容。真正的class_data_item會在執行的時候釋放並連線上去，但是code_item卻始終存在於dex檔案裡，它用無效資料填充annotation_off和debug_info_off來實現干擾反編譯。

0x07 參考

https://source.android.com/devices/tech/dalvik/dex-format.html
/libcore/libart/src/main/java/java/lang/ClassLoader.java
/libcore/libdvm/src/main/java/java/lang/ClassLoader.java
/libcore/dalvik/src/main/java/dalvik/system/DexClassLoader.java
/libcore/dalvik/src/main/java/dalvik/system/PathClassLoader.java
https://github.com/anestisb/oatdump_plus#dalvik-opcode-changes-in-art