代碼抽取——PVM1 虛擬化打包到底是什么？)
Android APK 加固原理三方法級(jí)代碼抽取——PVM1 虛擬化打包到底是什么系列文章?第一篇《Android APK 加固原理一Native Shell 如何隱藏和恢復(fù) DEX》第二篇《Android APK 加固原理二從 DEX 解密到 ART 加載如何縮短代碼明文暴露窗口》第三篇《Android APK 加固原理三方法級(jí)代碼抽取——PVM1 虛擬化打包到底是什么》第四篇《Android APK 加固原理四真正的代碼虛擬化——PVM2 Native Interpreter 技術(shù)解析》第五篇《Android APK 加固原理五SO.text段加密、ELF 加載與運(yùn)行時(shí)動(dòng)態(tài)解密》第六篇《Android APK 加固原理六RASP 運(yùn)行時(shí)安全防護(hù)——如何檢測(cè) Frida、Hook 與運(yùn)行時(shí)攻擊》第七篇《從 APK 加密到代碼虛擬化XopProtector 多層 Android 應(yīng)用保護(hù)體系解析》項(xiàng)目地址https://github.com/xopJack/XopProtector一、前言為什么有了 DEX 加密還需要 PVM1在前兩篇文章中我們已經(jīng)分析了 Android APK 加固最基礎(chǔ)的一層防護(hù)第一層是把原始 DEX 從 APK 中拿走。第二層是把 DEX 加密讓逆向工具無法直接從 APK 中得到完整的 classes.dex。但是僅僅做到 DEX 加密并不能解決所有問題。因?yàn)?Android 應(yīng)用最終還是需要運(yùn)行。無論 DEX 在 APK 中如何加密應(yīng)用啟動(dòng)以后代碼最終還是需要進(jìn)入 Android Runtime也就是 ART 的執(zhí)行體系。因此攻擊者真正關(guān)心的問題會(huì)逐漸從“APK 里面有沒有完整 DEX”轉(zhuǎn)變?yōu)椤斑\(yùn)行時(shí)能不能把 DEX 恢復(fù)出來”進(jìn)一步又會(huì)變成“能不能只針對(duì)關(guān)鍵方法進(jìn)行分析”這也是方法級(jí)保護(hù)存在的意義。XopProtector 在整體保護(hù)體系中增加了 PVM1原始 DEX ↓ 定位目標(biāo)方法 ↓ 抽取方法 Dalvik 指令 ↓ PVM1 編碼 ↓ AES-GCM 加密 ↓ 原方法體替換成安全占位 Stub ↓ 生成 code.bin ↓ 運(yùn)行時(shí) Native Shell 解密 ↓ 恢復(fù) Dalvik 指令 ↓ 寫回 DEX ↓ ART 執(zhí)行因此PVM1 的核心思想并不是“讓代碼永遠(yuǎn)不出現(xiàn)”。而是把關(guān)鍵方法從正常 DEX 的 code_item 中抽離出來讓靜態(tài) DEX 分析工具看到的只是一個(gè)占位方法真正的方法實(shí)現(xiàn)被移動(dòng)到獨(dú)立的加固數(shù)據(jù)區(qū)中并在運(yùn)行時(shí)恢復(fù)。XopProtector 源碼明確將--vmp-prefix定義為 PVM1并特別說明它是 ?**“decode → write Dalvik”**?而不是 Interpreter。二、先搞清楚PVM1 到底是什么很多人看到“VMP”“Virtual Machine”“虛擬化”這些詞第一反應(yīng)就是原始代碼 ↓ 虛擬指令 ↓ Virtual Machine ↓ Interpreter這種理解對(duì)于 XopProtector 的PVM2才成立。對(duì)于 ?PVM1?并不是這樣。XopProtector 的VmCodec.java對(duì) PVM1 的注釋非常直接Lightweight method-level VM packing (PVM1) Dalvik → non-Dalvik image Runtime unpacks inside .bitcode before writing DEX. This is virtualized packing, not a full bytecode interpreter.也就是說PVM1 更準(zhǔn)確的技術(shù)定義應(yīng)該是Method-Level Virtualized Packing方法級(jí)虛擬化打包而不是True Code Virtualization真正的代碼虛擬化。這兩個(gè)概念一定要區(qū)分。三、PVM1 和 PVM2 到底有什么區(qū)別這是整個(gè)系列最容易混淆的地方?？梢灾苯佑孟旅孢@張表理解特性PVM1PVM2保護(hù)粒度方法級(jí)方法級(jí)是否抽取原始指令是是是否生成虛擬化數(shù)據(jù)是是是否存在 Interpreter否是是否恢復(fù) Dalvik是否是否寫回 DEX是否最終執(zhí)行者ARTNative Interpreter核心目的提高靜態(tài)逆向成本改變代碼執(zhí)行模型對(duì)運(yùn)行時(shí) Hook 的抵抗能力中等更強(qiáng)性能開銷相對(duì)較小更高實(shí)現(xiàn)復(fù)雜度較低很高XopProtector README 對(duì)兩者的定義非常明確--vmp-prefix PVM1 unpack → write Dalvik not an interpreter --true-vmp-prefix PVM2 JNI trampoline native interpret因此PVM1 是“代碼搬家 編碼保護(hù) 運(yùn)行時(shí)恢復(fù)”。而PVM2 是“代碼翻譯 自定義指令集 Native Interpreter”。這也是為什么 XopProtector 把 PVM1 和 PVM2 設(shè)計(jì)成兩個(gè)不同階段。四、PVM1 的核心從“類級(jí)保護(hù)”下降到“方法級(jí)保護(hù)”傳統(tǒng) DEX 加密往往是classes.dex ↓ 整體加密運(yùn)行時(shí)整個(gè) DEX ↓ 整體解密 ↓ 交給 ART這種方式的缺點(diǎn)很明顯一旦整個(gè) DEX 被恢復(fù)攻擊者就獲得了大量可分析代碼。而 PVM1 改變了保護(hù)粒度。它不再簡單地把整個(gè) DEX 看成一個(gè)整體而是進(jìn)一步進(jìn)入DEX ├── Class A │ ├── method A() │ ├── method B() │ └── method C() │ ├── Class B │ ├── method D() │ └── method E() │ └── Class C └── method F()然后選擇其中關(guān)鍵方法method B() method D() method F()進(jìn)行抽取。最終形成DEX ├── 普通方法 → 正常保留 │ ├── PVM1 方法 → 抽空 │ ↓ │ code.bin │ └── PVM2 方法 → 后續(xù)真正虛擬化因此PVM1 的第一個(gè)重要思想就是保護(hù)從“DEX 級(jí)”進(jìn)一步下降到了“Method 級(jí)”。五、第一步找到需要保護(hù)的方法XopProtector 的 Packer 是在構(gòu)建階段工作的。源碼中的PackerMain會(huì)讀取 DEX并遍歷其中的 ClassDef、ClassData 以及 DirectMethods / VirtualMethods。核心流程可以抽象為APK ↓ 解包 ↓ classes.dex ↓ 解析 DEX ↓ 遍歷 ClassDef ↓ 定位目標(biāo) Class ↓ 遍歷 DirectMethod ↓ 遍歷 VirtualMethod ↓ 提取 code_item源碼中的walkDexMethods()就承擔(dān)了這一職責(zé)。它會(huì)遍歷dex.classDefs()然后讀取classData.getDirectMethods() classData.getVirtualMethods()再逐個(gè)調(diào)用extractOne(...)處理方法。六、PVM1 并不是所有方法都保護(hù)這是一個(gè)非常重要的設(shè)計(jì)。XopProtector 并不是無腦把所有方法都轉(zhuǎn)換成 PVM1。源碼中存在vmpPrefixes對(duì)應(yīng)--vmp-prefix也就是說可以按照類描述符前綴選擇需要進(jìn)行 PVM1 處理的代碼。例如--vmp-prefix Lcom/example/security/那么Lcom/example/security/Foo; Lcom/example/security/Pay; Lcom/example/security/License;等類中的方法就可能進(jìn)入 PVM1 流程。源碼中明確維護(hù)了vmpPrefixes trueVmpPrefixes hollowPrefixes三個(gè)不同維度。這實(shí)際上構(gòu)成了普通代碼 ↓ Hollow PVM1 代碼 ↓ PVM1 Packing PVM2 代碼 ↓ True VMP因此可以針對(duì)不同代碼價(jià)值選擇不同保護(hù)等級(jí)。七、第二步讀取方法真正的 Dalvik 指令找到目標(biāo)方法以后PVM1 并不是簡單地復(fù)制整個(gè) MethodId。它真正需要保護(hù)的是方法的 code_item 中的 Dalvik instruction stream。源碼中com.android.dex.Codecodedex.readCode(method);然后short[]unitscode.getInstructions();再根據(jù)units.length * 2計(jì)算實(shí)際指令區(qū)域大小。之后通過method.getCodeOffset()16定位到 code_item 中真正的 instructions 區(qū)域。然后raf.seek(insnsOffset);raf.readFully(original);把原始 Dalvik 指令讀取出來。所以這里可以把 PVM1 的第一核心動(dòng)作總結(jié)成Method ↓ CodeItem ↓ instructions ↓ byte[]也就是把原方法的 Dalvik 指令從 DEX 中物理抽取出來。八、第三步PVM1 編碼到底做了什么現(xiàn)在進(jìn)入 PVM1 最核心的VmCodec。XopProtector 的 PVM1 數(shù)據(jù)擁有一個(gè)非常明顯的 MagicPVM1源碼privatestaticfinalbyte[]MAGIC{P,V,M,1};編碼后的數(shù)據(jù)結(jié)構(gòu)可以簡單理解成---------------- | PVM1 | ---------------- | encoded byte 0 | ---------------- | encoded byte 1 | ---------------- | encoded byte 2 | ---------------- | ... | ----------------值得注意的是PVM1 編碼后的數(shù)據(jù)長度基本等于原始 Dalvik 指令長度 4 字節(jié) Magic。它并沒有像真正的虛擬機(jī)那樣把一條 Dalvik 指令重新編譯成復(fù)雜的 VM 指令流。這也是為什么稱它為Virtualized Packing而不是True Virtualization源碼明確說明 PVM1 編碼結(jié)果是same length 4即原始長度加上PVM1四字節(jié)頭。九、PVM1 的第一層編碼基于 Method Index 的 Key StreamPVM1 的編碼并不是簡單byte ^ 0x55它會(huì)根據(jù)methodIdx以及byte offset生成一個(gè)簡單的動(dòng)態(tài)字節(jié)流。源碼keystream(methodIdx, i)其核心計(jì)算為(methodIdx * 131 i * 17 0xA5) 0xff因此Key f(methodIndex, byteOffset)然后encodedByte originalByte ^ key這樣不同 Method Index 的編碼結(jié)果就不會(huì)完全相同。十、PVM1 的第二層Nibble Swap除了 XORPVM1 還做了一層非常輕量的字節(jié)變換。源碼中if((i1)0){b((b4)0xf0)|((b4)0x0f);}也就是對(duì)偶數(shù)位置的字節(jié)進(jìn)行高低 4 bit 交換。例如原始 1010 0011經(jīng)過 Nibble Swap0011 1010所以 PVM1 的實(shí)際編碼邏輯可以抽象為Dalvik Byte ↓ XOR KeyStream ↓ 偶數(shù)位置 Nibble Swap ↓ PVM1 Blob解碼時(shí)反過來PVM1 Blob ↓ Nibble Swap ↓ XOR KeyStream ↓ 原始 Dalvik Byte因此這個(gè)過程本質(zhì)上是為了破壞原始 Dalvik 指令的線性特征讓靜態(tài)掃描器無法直接把這一段數(shù)據(jù)當(dāng)作正常 DEX 指令流解析。十一、但是 PVM1 真正的安全邊界并不在這個(gè) XOR這一點(diǎn)非常重要。如果只看methodIdx i 131 17 0xA5 XOR你會(huì)發(fā)現(xiàn)這并不是現(xiàn)代密碼學(xué)意義上的強(qiáng)加密。實(shí)際上 XopProtector 的真正安全邊界來自后面那一層AES-GCMPVM1 編碼只是Dalvik ↓ PVM1 Transform ↓ AES-GCM源碼中extractOne()的流程非常清楚original Dalvik instructions ↓ VmCodec.encode() ↓ PVM1 blob ↓ CryptoUtils.aesGcmEncrypt() ↓ stored也就是說PVM1 負(fù)責(zé)改變數(shù)據(jù)形態(tài)AES-GCM 負(fù)責(zé)真正的數(shù)據(jù)機(jī)密性。十二、第四步原始方法代碼被真正“抹掉”這是 PVM1 最關(guān)鍵的一步。如果只是復(fù)制一份代碼那么原 DEX 里面仍然存在原始代碼。保護(hù)就沒有意義。所以 XopProtector 在提取完方法指令以后會(huì)直接修改原來的 DEX。流程原始 Method Code ↓ 讀取 ↓ 保存到 PVM1 ↓ 原位置寫入 Stub源碼中writeReturnStub(...)會(huì)把原始 instructions 替換成一個(gè)與返回類型匹配的占位代碼。例如void → return-void int → const/4 v0, 0 → return v0 object → const/4 v0, 0 → return-object v0剩余空間則用nop類指令填充。十三、為什么不能直接把方法體全部清零這是 Android ART 加載過程中的一個(gè)關(guān)鍵問題。DEX 并不是Class Method Code隨便寫什么都可以。ART 在加載、驗(yàn)證以及后續(xù)執(zhí)行過程中會(huì)檢查 Method 的結(jié)構(gòu)和 code_item。如果直接code_item 0或者破壞整個(gè) CodeItem很容易造成DEX 驗(yàn)證失敗 VerifyError Class loading failure Crash所以加固系統(tǒng)常見的思路是不破壞方法結(jié)構(gòu)只替換真正的業(yè)務(wù)指令。XopProtector 也是這樣做的。例如原方法intadd(inta,intb){returnab;}原來的 Dalvik 指令可能類似add-int returnPVM1 后變成const/4 v0, 0 return v0 nop nop ...真正的add-int已經(jīng)被拿走。這就是所謂Hollow / Method Hollowing也就是方法空洞化。十四、因此 PVM1 最重要的結(jié)構(gòu)變化是這樣的加固之前classes.dex Method A ↓ CodeItem ↓ 真正業(yè)務(wù) Dalvik 指令加固之后classes.dex Method A ↓ CodeItem ↓ 安全 Stub與此同時(shí)assets/protector/code.bin ↓ PVM1 ↓ AES-GCM ↓ 真正的 Dalvik 指令形成┌─────────────────────┐ │ classes.dex │ │ │ │ Method A │ │ ↓ │ │ Stub / Hollow │ └──────────┬──────────┘ │ │ runtime restore ↓ ┌─────────────────────┐ │ code.bin │ │ │ │ Method Index │ │ Plain Size │ │ Flags │ │ AES-GCM Blob │ └─────────────────────┘十五、PVM1 的第五步生成 code.bin方法被抽取以后需要一個(gè)地方保存這些方法。XopProtector 使用code.bin作為運(yùn)行時(shí)方法代碼倉庫。源碼中的writeCodeBin()會(huì)將不同 DEX 中的保護(hù)方法進(jìn)行組織。當(dāng)前代碼使用的是code.bin v4。其結(jié)構(gòu)可以抽象為Header ↓ version ↓ dex count ↓ dex offsets ↓ Dex Blob每個(gè)方法記錄大致包含methodIndex plainInsnsSize storedInsnsSize flags insns也就是Method Index ↓ 告訴 Runtime “這個(gè)代碼屬于哪個(gè)方法” Plain Size ↓ 解密以后需要恢復(fù)多少字節(jié) Stored Size ↓ 當(dāng)前加密數(shù)據(jù)長度 Flags ↓ 告訴 Runtime PVM1 / PVM2 / 其他類型 Insns ↓ AES-GCM 加密后的方法數(shù)據(jù)源碼中writeCodeBin()明確寫入了methodIndex plainInsnsSize insns.length flags insns并且支持多 DEX。十六、為什么必須保存 Method Index這是整個(gè)方法級(jí)保護(hù)體系的“索引核心”。DEX 中的方法是通過method_ids進(jìn)行編號(hào)的。例如method_id #100 method_id #101 method_id #102PVM1 不需要在code.bin中保存一套完整的 Java/Kotlin 方法名。它可以直接利用methodIndex關(guān)聯(lián)DEX Method ? code.bin Record因此 Runtime 可以實(shí)現(xiàn)methodIndex 102 ↓ 找到 code.bin 中 #102 ↓ AES-GCM decrypt ↓ PVM1 decode ↓ 得到真實(shí) Dalvik instructions ↓ 恢復(fù) Method #102這就是 PVM1 的“方法級(jí)映射關(guān)系”。十七、PVM1 運(yùn)行時(shí)到底發(fā)生了什么這部分是整個(gè)機(jī)制最值得分析的地方。很多人會(huì)誤以為啟動(dòng) APP ↓ 整個(gè) code.bin 解密 ↓ 整個(gè) DEX 恢復(fù)實(shí)際上從源碼結(jié)構(gòu)來看XopProtector 的 Runtime 是圍繞code.bin code_map Method ART Hook組織起來的。Native Shell 啟動(dòng)以后會(huì)先定位dexes.zip code.bin config.json然后加載相關(guān) Key。之后code.bin ↓ read_file() ↓ codeitem::parse() ↓ state.code_mapRuntime 將保護(hù)方法建立成內(nèi)部映射。源碼protector::codeitem::parse(...)解析完成以后state.code_map就成為運(yùn)行時(shí)的方法保護(hù)索引。十八、Runtime 為什么要 Hook ART這里就涉及 Android 加固真正困難的地方。如果Method A在 DEX 中已經(jīng)被替換成return 0那么 ART 自己執(zhí)行的時(shí)候自然只會(huì)執(zhí)行return 0它不知道真正代碼在哪里。所以必須在ART 加載 / 定義 Class / Method的關(guān)鍵路徑上進(jìn)行干預(yù)。XopProtector 在初始化階段會(huì)protector::hook::install_hooks();然后再解析和應(yīng)用code.bin源碼明確說明在解析 / 應(yīng)用 code.bin 前安裝 ART hooks以便 DefineClass 時(shí)進(jìn)行 patch。因此整個(gè)體系實(shí)際上形成DEX ↓ ART ↓ Hook ↓ 識(shí)別被保護(hù) Method ↓ 查 code_map ↓ 恢復(fù)真實(shí) Dalvik ↓ 交給 ART十九、PVM1 的運(yùn)行時(shí)恢復(fù)流程可以把它完整畫成App 啟動(dòng) │ ▼ Native Shell 初始化 │ ▼ 讀取 code.bin │ ▼ codeitem::parse │ ▼ 建立 code_map │ ▼ 安裝 ART Hook │ ▼ ART 加載目標(biāo) Class │ ▼ 檢查 Method 是否受保護(hù) │ ┌──────┴──────┐ │ │ 否 是 │ │ ▼ ▼ 正常執(zhí)行 查詢 code_map │ ▼ AES-GCM 解密 │ ▼ PVM1 Decode │ ▼ 得到真實(shí) Dalvik 指令 │ ▼ Patch CodeItem │ ▼ ART 執(zhí)行這就是 PVM1 最核心的運(yùn)行時(shí)機(jī)制。二十、PVM1 的“虛擬化”到底體現(xiàn)在哪里現(xiàn)在回到最開始的問題PVM1 到底算不算虛擬化答案是算但屬于非常輕量級(jí)的“虛擬化打包”而不是完整 VM 虛擬化。因?yàn)樗_實(shí)把原始代碼Dalvik instructions轉(zhuǎn)換成了PVM1 image原始代碼不再直接位于原 Method CodeItem 中。但是它沒有Dalvik opcode ↓ PVM opcode ↓ VM Register ↓ VM Stack ↓ Dispatcher ↓ Handler這一整套機(jī)制。因此PVM1 Dalvik → protected image → Dalvik而PVM2 Dalvik → custom VM bytecode → Native Interpreter這才是真正意義上的Code Virtualization二十一、為什么 PVM1 比真正虛擬化簡單很多假設(shè)原始代碼intcalc(inta,intb){intxab;returnx*10;}PVM1 的目標(biāo)只是隱藏 add-int mul-int return然后運(yùn)行時(shí)恢復(fù) add-int mul-int returnART 繼續(xù)執(zhí)行。所以 PVM1 并不需要理解add-int mul-int if goto invoke new-instance monitor try/catch的語義。它只需要保存 ↓ 解碼 ↓ 恢復(fù)因此實(shí)現(xiàn)成本相對(duì)較低。二十二、真正的 PVM2 為什么會(huì)復(fù)雜得多假設(shè) PVM2 也拿到add-int mul-int return它不會(huì)把這些指令恢復(fù)到 DEX。而是轉(zhuǎn)換成自己的VM_ADD VM_MUL VM_RETURN然后Native Interpreter switch(opcode) { case VM_ADD: ... case VM_MUL: ... case VM_RETURN: ... }于是ART ↓ JNI Trampoline ↓ Native Interpreter ↓ VM Opcode ↓ Handler整個(gè)執(zhí)行模型都發(fā)生改變。XopProtector 當(dāng)前 PVM2 文檔也明確說明PVM2 方法不會(huì)恢復(fù)到 Dalvik而是通過 JNI trampoline 進(jìn)入 Native Interpreter讀取code.bin中的 PVM2 image。這就是下一篇文章真正需要討論的內(nèi)容。二十三、PVM1 對(duì)靜態(tài)逆向的意義假設(shè)沒有 PVM1classes.dex ↓ jadx ↓ Java/Kotlin-like code攻擊者可以直接看到calculateToken()validateLicense()checkSignature()generateKey()而加入 PVM1 后classes.dex ↓ 目標(biāo)方法 ↓ Stub靜態(tài)分析工具看到的可能只是return0;或者returnnull;真實(shí)邏輯已經(jīng)不在 Method CodeItem 中。所以靜態(tài)反編譯結(jié)果 ≠ 真實(shí)業(yè)務(wù)邏輯這就是 PVM1 最直接的價(jià)值。二十四、但是 PVM1 并不是“不可逆”這一點(diǎn)在技術(shù)文章中必須客觀說明。PVM1 的最終執(zhí)行路徑仍然是PVM1 ↓ Decode ↓ Dalvik ↓ ART所以從攻擊者角度靜態(tài)分析 ↓ 難度增加 運(yùn)行時(shí)動(dòng)態(tài)分析 ↓ 仍然可以觀察 最終恢復(fù)后的 Dalvik ↓ 仍然存在因此PVM1 的目標(biāo)不是讓代碼永遠(yuǎn)無法獲得而是增加靜態(tài)分析和自動(dòng)化脫殼的成本。這也符合 XopProtector 項(xiàng)目本身的定位加固的作用是提高逆向成本而不是保證應(yīng)用絕對(duì)不可破解。二十五、PVM1 最大的價(jià)值其實(shí)是“方法級(jí)明文控制”如果把保護(hù)過程畫成時(shí)間軸APK │ │ 加密狀態(tài) ▼ App 啟動(dòng) │ ▼ Runtime 解密 │ ▼ PVM1 Method Decode │ ▼ Dalvik Method 明文 │ ▼ ART 執(zhí)行關(guān)鍵區(qū)別是以前整個(gè) DEX ↓ 大量代碼同時(shí)明文PVM1Method A ↓ 需要時(shí)恢復(fù) Method B ↓ 需要時(shí)恢復(fù) Method C ↓ 需要時(shí)恢復(fù)因此保護(hù)對(duì)象從“整個(gè)代碼包”變成“一個(gè)個(gè)關(guān)鍵方法”。這就是方法級(jí)加固最重要的工程價(jià)值。二十六、從源碼看PVM1 實(shí)際上是“三層保護(hù)疊加”如果把 XopProtector 的 PVM1 單獨(dú)拆開可以得到第一層 Method Hollowing ↓ 從 DEX 中移除真實(shí)實(shí)現(xiàn) 第二層 PVM1 Transform ↓ XOR Nibble Swap ↓ 破壞原始 Dalvik 數(shù)據(jù)特征 第三層 AES-GCM ↓ 真正的數(shù)據(jù)機(jī)密性所以它并不是PVM1 XOR也不是PVM1 AES而是Method │ ▼ ┌───────────────┐ │ Method Extract│ └───────┬───────┘ ▼ ┌───────────────┐ │ PVM1 Transform │ │ XOR Nibble │ └───────┬───────┘ ▼ ┌───────────────┐ │ AES-GCM │ └───────┬───────┘ ▼ code.bin而 DEX 中只留下Stub二十七、PVM1 和傳統(tǒng)“代碼抽取”有什么區(qū)別如果只說“PVM1 就是把代碼抽出來?！逼鋵?shí)不夠準(zhǔn)確。因?yàn)槠胀ùa抽取可能只是DEX ↓ 抽取 Method ↓ 保存到其他文件但是 PVM1 還增加了Method Index PVM1 Encoding AES-GCM Method Hollowing ART Runtime Restore所以完整體系是代碼抽取 代碼變形 加密存儲(chǔ) 原位置空洞化 運(yùn)行時(shí)恢復(fù)這才構(gòu)成完整的 PVM1。二十八、PVM1 的完整生命周期把整個(gè)源碼實(shí)現(xiàn)濃縮成一條鏈【構(gòu)建階段】 APK │ ▼ 解包 DEX │ ▼ 遍歷 ClassDef │ ▼ 找到目標(biāo) Method │ ▼ 讀取 CodeItem │ ▼ 提取 Dalvik Instructions │ ▼ VmCodec.encode │ ▼ PVM1 Blob 生成 │ ▼ AES-GCM 加密 │ ▼ code.bin │ ├───────────────┐ │ │ ▼ ▼ 原 Method 被抹掉 Stub │ ▼ DEX 重寫 │ ▼ APK 重新打包 【運(yùn)行階段】 App 啟動(dòng) │ ▼ Native Shell │ ▼ 讀取 code.bin │ ▼ codeitem::parse │ ▼ 建立 code_map │ ▼ 安裝 ART Hook │ ▼ ART 加載 Class │ ▼ 找到受保護(hù) Method │ ▼ 查詢 code_map │ ▼ AES-GCM 解密 │ ▼ PVM1 Decode │ ▼ 得到真實(shí) Dalvik │ ▼ Patch Method │ ▼ ART │ ▼ 正常執(zhí)行這條鏈基本就是 XopProtector PVM1 的核心原理。二十九、PVM1 真正解決了什么問題可以總結(jié)成四個(gè)字靜態(tài)不可見。更準(zhǔn)確地說1. 靜態(tài) DEX 中不再存在完整方法實(shí)現(xiàn)攻擊者拿到 DEX 后目標(biāo)方法已經(jīng)被替換成 Stub。2. 方法實(shí)現(xiàn)被移動(dòng)到獨(dú)立數(shù)據(jù)區(qū)真實(shí)代碼進(jìn)入code.bin而不是繼續(xù)留在原來的 CodeItem 中。3. PVM1 破壞原始 Dalvik 數(shù)據(jù)形態(tài)通過XOR KeyStream Nibble Swap讓數(shù)據(jù)不再表現(xiàn)為正常 Dalvik instruction stream。4. AES-GCM 提供真正的機(jī)密性即使攻擊者找到code.bin也不能簡單通過strings dexdump jadx直接獲得原始代碼。三十、但 PVM1 還有一個(gè)天然弱點(diǎn)這也是為什么 XopProtector 后面還需要 PVM2。PVM1加密 ↓ 恢復(fù) ↓ Dalvik ↓ ART所以最終真實(shí) Dalvik還是要出現(xiàn)。因此攻擊者如果把分析重點(diǎn)從APK 靜態(tài)分析轉(zhuǎn)向Runtime ↓ ART Hook ↓ Method Restore ↓ Memory Dump就可能重新獲取真實(shí)方法。所以 PVM1 的安全模型是提高靜態(tài)分析成本 增加脫殼復(fù)雜度 縮短攻擊者直接獲得代碼的路徑 但是 最終仍然回到 ART Dalvik 執(zhí)行體系這也是 PVM1 與 PVM2 最根本的安全邊界。三十一、PVM1 → PVM2是 Android 加固的一次質(zhì)變可以把整個(gè)演進(jìn)過程理解為第一階段 DEX 加密 攻擊者 APK ↓ 找到解密點(diǎn) ↓ 得到 DEX 第二階段 PVM1 攻擊者 APK ↓ 找到 code.bin ↓ 找到 Runtime Restore ↓ 獲取 Dalvik 第三階段 PVM2 攻擊者 APK ↓ 找到 JNI Trampoline ↓ 找到 Native Interpreter ↓ 理解自定義 VM ↓ 分析 VM Opcode ↓ 恢復(fù)原始語義所以難度是逐層提升的。三十二、PVM1 最值得學(xué)習(xí)的工程設(shè)計(jì)從工程實(shí)現(xiàn)角度看PVM1 并沒有試圖一步做到極端復(fù)雜。它采取的是一種非常實(shí)用的思路DEX 加密 ↓ 解決“APK 靜態(tài)暴露” PVM1 ↓ 解決“關(guān)鍵方法暴露” PVM2 ↓ 解決“恢復(fù)后仍然是 Dalvik” SO 加密 ↓ 解決 Native 代碼暴露 RASP ↓ 解決運(yùn)行時(shí)攻擊也就是說不同保護(hù)技術(shù)解決不同攻擊面。這比單純依賴一種“超級(jí)加密算法”更加符合商業(yè) APK 加固系統(tǒng)的工程思路。三十三、源碼層面的關(guān)鍵文件如果你準(zhǔn)備繼續(xù)深入研究 XopProtector那么 PVM1 最值得看的幾個(gè)源碼位置是packer/ └── src/main/java/com/yqsh/protector/packer/ │ ├── PackerMain.java │ ├── walkDexMethods() │ ├── extractOne() │ ├── writeReturnStub() │ └── writeCodeBin() │ └── VmCodec.java ├── encode() └── decode()其中PackerMain.java負(fù)責(zé)掃描 DEX ↓ 定位 Method ↓ 抽取指令 ↓ 替換 Stub ↓ 生成 code.binVmCodec.java負(fù)責(zé)PVM1 Encode PVM1 DecodeNative 側(cè)則對(duì)應(yīng)native/src/main/cpp/vm/ └── vm_codec.cpp負(fù)責(zé)運(yùn)行時(shí)PVM1 DecodeNative Runtimenative/src/main/cpp/runtime/ └── engine.cpp負(fù)責(zé)初始化 ↓ 加載 code.bin ↓ 建立 code_map ↓ 安裝 Hook ↓ 進(jìn)入運(yùn)行時(shí)保護(hù)流程這些源碼結(jié)構(gòu)可以非常清晰地證明PVM1 并不是一個(gè)獨(dú)立的 VM而是 Packer Native Runtime ART Hook 三者協(xié)同完成的方法級(jí)保護(hù)機(jī)制。三十四、最終總結(jié)一句話理解 XopProtector PVM1如果只用一句話解釋PVM1 就是在構(gòu)建階段把關(guān)鍵方法的 Dalvik 指令從 DEX 中抽出來經(jīng)過 PVM1 變換和 AES-GCM 加密后保存到code.bin原 Method 只留下與返回類型匹配的安全 Stub應(yīng)用運(yùn)行時(shí)由 Native Shell 解析code.bin通過 ART Hook 找到目標(biāo) Method解密并恢復(fù)真實(shí) Dalvik 指令再交給 ART 執(zhí)行。整個(gè)過程可以最終濃縮成PVM1 ┌───────────────────┐ │ 原始 Method │ └─────────┬─────────┘ │ ▼ 提取 Dalvik Code │ ▼ PVM1 Encode XOR NibbleSwap │ ▼ AES-GCM │ ▼ code.bin │ │ ┌─────────▼─────────┐ │ 原 DEX Method │ │ │ │ 真實(shí) Code 被移除 │ │ ↓ │ │ Stub │ └───────────────────┘ Runtime Native Shell │ ▼ code.bin │ ▼ code_map │ ▼ ART Hook │ ▼ 找到目標(biāo) Method │ ▼ AES-GCM Decode │ ▼ PVM1 Decode │ ▼ 恢復(fù) Dalvik │ ▼ Patch Method │ ▼ ART │ ▼ 執(zhí)行代碼所以PVM1 不是“讓代碼不再執(zhí)行”而是讓代碼不再以正常 DEX Method 的形式存在。這就是它和傳統(tǒng) DEX 加密最大的區(qū)別。而下一階段真正值得研究的問題就是如果連“恢復(fù) Dalvik”這一步都不要了能不能讓被保護(hù)方法從始至終都不回到 DEX而是直接由 Native 自己解釋執(zhí)行答案就是PVM2。PVM2 不再是加密 → 解密 → 恢復(fù) Dalvik → ART而會(huì)變成原始 Dalvik ↓ PVM2 Compiler ↓ 自定義 VM Image ↓ JNI Trampoline ↓ Native Interpreter ↓ VM Opcode ↓ 執(zhí)行XopProtector 當(dāng)前源碼中的 PVM2 已經(jīng)進(jìn)一步加入了多 ISA、Opcode Morphing、RASP Gate、解釋執(zhí)行以及 PVM2 Image等機(jī)制。PVM2 v3 還會(huì)為每個(gè) APK 生成 opcode 映射并根據(jù)isa_id選擇不同 Native dispatch 入口。這才是真正意義上的 Android 代碼虛擬化。下一篇《Android APK 加固原理四真正的代碼虛擬化——PVM2 Native Interpreter 技術(shù)解析》將重點(diǎn)拆解Dalvik ↓ PVM2 Compiler ↓ VM Opcode ↓ PVM2 Image ↓ JNI Trampoline ↓ Native Interpreter ↓ Dispatcher ↓ Opcode Handler ↓ 寄存器 / 對(duì)象 / Field / Method ↓ 最終執(zhí)行并重點(diǎn)解釋為什么 PVM2 和 PVM1 已經(jīng)不是同一個(gè)層級(jí)的加固技術(shù)。參考源碼本文分析以 XopProtector 當(dāng)前公開源碼為基礎(chǔ)重點(diǎn)涉及packer/PackerMain.javapacker/VmCodec.javanative/vm/vm_codec.cppnative/runtime/engine.cppPVM2 設(shè)計(jì)文檔項(xiàng)目公開 README 明確將--vmp-prefix定義為 PVM1將--true-vmp-prefix定義為 PVM2。 Android APK 加固原理（三）：方法級(jí)代碼抽取——PVM1 虛擬化打包到底是什么？
Android APK 加固原理三方法級(jí)代碼抽取——PVM1 虛擬化打包到底是什么系列文章?第一篇《Android APK 加固原理一Native Shell 如何隱藏和恢復(fù) DEX》第二篇《Android APK 加固原理二從 DEX 解密到 ART 加載如何縮短代碼明文暴露窗口》第三篇《Android APK 加固原理三方法級(jí)代碼抽取——PVM1 虛擬化打包到底是什么》第四篇《Android APK 加固原理四真正的代碼虛擬化——PVM2 Native Interpreter 技術(shù)解析》第五篇《Android APK 加固原理五SO.text段加密、ELF 加載與運(yùn)行時(shí)動(dòng)態(tài)解密》第六篇《Android APK 加固原理六RASP 運(yùn)行時(shí)安全防護(hù)——如何檢測(cè) Frida、Hook 與運(yùn)行時(shí)攻擊》第七篇《從 APK 加密到代碼虛擬化XopProtector 多層 Android 應(yīng)用保護(hù)體系解析》項(xiàng)目地址https://github.com/xopJack/XopProtector一、前言為什么有了 DEX 加密還需要 PVM1在前兩篇文章中我們已經(jīng)分析了 Android APK 加固最基礎(chǔ)的一層防護(hù)第一層是把原始 DEX 從 APK 中拿走。第二層是把 DEX 加密讓逆向工具無法直接從 APK 中得到完整的 classes.dex。但是僅僅做到 DEX 加密并不能解決所有問題。因?yàn)?Android 應(yīng)用最終還是需要運(yùn)行。無論 DEX 在 APK 中如何加密應(yīng)用啟動(dòng)以后代碼最終還是需要進(jìn)入 Android Runtime也就是 ART 的執(zhí)行體系。因此攻擊者真正關(guān)心的問題會(huì)逐漸從“APK 里面有沒有完整 DEX”轉(zhuǎn)變?yōu)椤斑\(yùn)行時(shí)能不能把 DEX 恢復(fù)出來”進(jìn)一步又會(huì)變成“能不能只針對(duì)關(guān)鍵方法進(jìn)行分析”這也是方法級(jí)保護(hù)存在的意義。XopProtector 在整體保護(hù)體系中增加了 PVM1原始 DEX ↓ 定位目標(biāo)方法 ↓ 抽取方法 Dalvik 指令 ↓ PVM1 編碼 ↓ AES-GCM 加密 ↓ 原方法體替換成安全占位 Stub ↓ 生成 code.bin ↓ 運(yùn)行時(shí) Native Shell 解密 ↓ 恢復(fù) Dalvik 指令 ↓ 寫回 DEX ↓ ART 執(zhí)行因此PVM1 的核心思想并不是“讓代碼永遠(yuǎn)不出現(xiàn)”。而是把關(guān)鍵方法從正常 DEX 的 code_item 中抽離出來讓靜態(tài) DEX 分析工具看到的只是一個(gè)占位方法真正的方法實(shí)現(xiàn)被移動(dòng)到獨(dú)立的加固數(shù)據(jù)區(qū)中并在運(yùn)行時(shí)恢復(fù)。XopProtector 源碼明確將--vmp-prefix定義為 PVM1并特別說明它是 ?**“decode → write Dalvik”**?而不是 Interpreter。二、先搞清楚PVM1 到底是什么很多人看到“VMP”“Virtual Machine”“虛擬化”這些詞第一反應(yīng)就是原始代碼 ↓ 虛擬指令 ↓ Virtual Machine ↓ Interpreter這種理解對(duì)于 XopProtector 的PVM2才成立。對(duì)于 ?PVM1?并不是這樣。XopProtector 的VmCodec.java對(duì) PVM1 的注釋非常直接Lightweight method-level VM packing (PVM1) Dalvik → non-Dalvik image Runtime unpacks inside .bitcode before writing DEX. This is virtualized packing, not a full bytecode interpreter.也就是說PVM1 更準(zhǔn)確的技術(shù)定義應(yīng)該是Method-Level Virtualized Packing方法級(jí)虛擬化打包而不是True Code Virtualization真正的代碼虛擬化。這兩個(gè)概念一定要區(qū)分。三、PVM1 和 PVM2 到底有什么區(qū)別這是整個(gè)系列最容易混淆的地方?？梢灾苯佑孟旅孢@張表理解特性PVM1PVM2保護(hù)粒度方法級(jí)方法級(jí)是否抽取原始指令是是是否生成虛擬化數(shù)據(jù)是是是否存在 Interpreter否是是否恢復(fù) Dalvik是否是否寫回 DEX是否最終執(zhí)行者ARTNative Interpreter核心目的提高靜態(tài)逆向成本改變代碼執(zhí)行模型對(duì)運(yùn)行時(shí) Hook 的抵抗能力中等更強(qiáng)性能開銷相對(duì)較小更高實(shí)現(xiàn)復(fù)雜度較低很高XopProtector README 對(duì)兩者的定義非常明確--vmp-prefix PVM1 unpack → write Dalvik not an interpreter --true-vmp-prefix PVM2 JNI trampoline native interpret因此PVM1 是“代碼搬家 編碼保護(hù) 運(yùn)行時(shí)恢復(fù)”。而PVM2 是“代碼翻譯 自定義指令集 Native Interpreter”。這也是為什么 XopProtector 把 PVM1 和 PVM2 設(shè)計(jì)成兩個(gè)不同階段。四、PVM1 的核心從“類級(jí)保護(hù)”下降到“方法級(jí)保護(hù)”傳統(tǒng) DEX 加密往往是classes.dex ↓ 整體加密運(yùn)行時(shí)整個(gè) DEX ↓ 整體解密 ↓ 交給 ART這種方式的缺點(diǎn)很明顯一旦整個(gè) DEX 被恢復(fù)攻擊者就獲得了大量可分析代碼。而 PVM1 改變了保護(hù)粒度。它不再簡單地把整個(gè) DEX 看成一個(gè)整體而是進(jìn)一步進(jìn)入DEX ├── Class A │ ├── method A() │ ├── method B() │ └── method C() │ ├── Class B │ ├── method D() │ └── method E() │ └── Class C └── method F()然后選擇其中關(guān)鍵方法method B() method D() method F()進(jìn)行抽取。最終形成DEX ├── 普通方法 → 正常保留 │ ├── PVM1 方法 → 抽空 │ ↓ │ code.bin │ └── PVM2 方法 → 后續(xù)真正虛擬化因此PVM1 的第一個(gè)重要思想就是保護(hù)從“DEX 級(jí)”進(jìn)一步下降到了“Method 級(jí)”。五、第一步找到需要保護(hù)的方法XopProtector 的 Packer 是在構(gòu)建階段工作的。源碼中的PackerMain會(huì)讀取 DEX并遍歷其中的 ClassDef、ClassData 以及 DirectMethods / VirtualMethods。核心流程可以抽象為APK ↓ 解包 ↓ classes.dex ↓ 解析 DEX ↓ 遍歷 ClassDef ↓ 定位目標(biāo) Class ↓ 遍歷 DirectMethod ↓ 遍歷 VirtualMethod ↓ 提取 code_item源碼中的walkDexMethods()就承擔(dān)了這一職責(zé)。它會(huì)遍歷dex.classDefs()然后讀取classData.getDirectMethods() classData.getVirtualMethods()再逐個(gè)調(diào)用extractOne(...)處理方法。六、PVM1 并不是所有方法都保護(hù)這是一個(gè)非常重要的設(shè)計(jì)。XopProtector 并不是無腦把所有方法都轉(zhuǎn)換成 PVM1。源碼中存在vmpPrefixes對(duì)應(yīng)--vmp-prefix也就是說可以按照類描述符前綴選擇需要進(jìn)行 PVM1 處理的代碼。例如--vmp-prefix Lcom/example/security/那么Lcom/example/security/Foo; Lcom/example/security/Pay; Lcom/example/security/License;等類中的方法就可能進(jìn)入 PVM1 流程。源碼中明確維護(hù)了vmpPrefixes trueVmpPrefixes hollowPrefixes三個(gè)不同維度。這實(shí)際上構(gòu)成了普通代碼 ↓ Hollow PVM1 代碼 ↓ PVM1 Packing PVM2 代碼 ↓ True VMP因此可以針對(duì)不同代碼價(jià)值選擇不同保護(hù)等級(jí)。七、第二步讀取方法真正的 Dalvik 指令找到目標(biāo)方法以后PVM1 并不是簡單地復(fù)制整個(gè) MethodId。它真正需要保護(hù)的是方法的 code_item 中的 Dalvik instruction stream。源碼中com.android.dex.Codecodedex.readCode(method);然后short[]unitscode.getInstructions();再根據(jù)units.length * 2計(jì)算實(shí)際指令區(qū)域大小。之后通過method.getCodeOffset()16定位到 code_item 中真正的 instructions 區(qū)域。然后raf.seek(insnsOffset);raf.readFully(original);把原始 Dalvik 指令讀取出來。所以這里可以把 PVM1 的第一核心動(dòng)作總結(jié)成Method ↓ CodeItem ↓ instructions ↓ byte[]也就是把原方法的 Dalvik 指令從 DEX 中物理抽取出來。八、第三步PVM1 編碼到底做了什么現(xiàn)在進(jìn)入 PVM1 最核心的VmCodec。XopProtector 的 PVM1 數(shù)據(jù)擁有一個(gè)非常明顯的 MagicPVM1源碼privatestaticfinalbyte[]MAGIC{P,V,M,1};編碼后的數(shù)據(jù)結(jié)構(gòu)可以簡單理解成---------------- | PVM1 | ---------------- | encoded byte 0 | ---------------- | encoded byte 1 | ---------------- | encoded byte 2 | ---------------- | ... | ----------------值得注意的是PVM1 編碼后的數(shù)據(jù)長度基本等于原始 Dalvik 指令長度 4 字節(jié) Magic。它并沒有像真正的虛擬機(jī)那樣把一條 Dalvik 指令重新編譯成復(fù)雜的 VM 指令流。這也是為什么稱它為Virtualized Packing而不是True Virtualization源碼明確說明 PVM1 編碼結(jié)果是same length 4即原始長度加上PVM1四字節(jié)頭。九、PVM1 的第一層編碼基于 Method Index 的 Key StreamPVM1 的編碼并不是簡單byte ^ 0x55它會(huì)根據(jù)methodIdx以及byte offset生成一個(gè)簡單的動(dòng)態(tài)字節(jié)流。源碼keystream(methodIdx, i)其核心計(jì)算為(methodIdx * 131 i * 17 0xA5) 0xff因此Key f(methodIndex, byteOffset)然后encodedByte originalByte ^ key這樣不同 Method Index 的編碼結(jié)果就不會(huì)完全相同。十、PVM1 的第二層Nibble Swap除了 XORPVM1 還做了一層非常輕量的字節(jié)變換。源碼中if((i1)0){b((b4)0xf0)|((b4)0x0f);}也就是對(duì)偶數(shù)位置的字節(jié)進(jìn)行高低 4 bit 交換。例如原始 1010 0011經(jīng)過 Nibble Swap0011 1010所以 PVM1 的實(shí)際編碼邏輯可以抽象為Dalvik Byte ↓ XOR KeyStream ↓ 偶數(shù)位置 Nibble Swap ↓ PVM1 Blob解碼時(shí)反過來PVM1 Blob ↓ Nibble Swap ↓ XOR KeyStream ↓ 原始 Dalvik Byte因此這個(gè)過程本質(zhì)上是為了破壞原始 Dalvik 指令的線性特征讓靜態(tài)掃描器無法直接把這一段數(shù)據(jù)當(dāng)作正常 DEX 指令流解析。十一、但是 PVM1 真正的安全邊界并不在這個(gè) XOR這一點(diǎn)非常重要。如果只看methodIdx i 131 17 0xA5 XOR你會(huì)發(fā)現(xiàn)這并不是現(xiàn)代密碼學(xué)意義上的強(qiáng)加密。實(shí)際上 XopProtector 的真正安全邊界來自后面那一層AES-GCMPVM1 編碼只是Dalvik ↓ PVM1 Transform ↓ AES-GCM源碼中extractOne()的流程非常清楚original Dalvik instructions ↓ VmCodec.encode() ↓ PVM1 blob ↓ CryptoUtils.aesGcmEncrypt() ↓ stored也就是說PVM1 負(fù)責(zé)改變數(shù)據(jù)形態(tài)AES-GCM 負(fù)責(zé)真正的數(shù)據(jù)機(jī)密性。十二、第四步原始方法代碼被真正“抹掉”這是 PVM1 最關(guān)鍵的一步。如果只是復(fù)制一份代碼那么原 DEX 里面仍然存在原始代碼。保護(hù)就沒有意義。所以 XopProtector 在提取完方法指令以后會(huì)直接修改原來的 DEX。流程原始 Method Code ↓ 讀取 ↓ 保存到 PVM1 ↓ 原位置寫入 Stub源碼中writeReturnStub(...)會(huì)把原始 instructions 替換成一個(gè)與返回類型匹配的占位代碼。例如void → return-void int → const/4 v0, 0 → return v0 object → const/4 v0, 0 → return-object v0剩余空間則用nop類指令填充。十三、為什么不能直接把方法體全部清零這是 Android ART 加載過程中的一個(gè)關(guān)鍵問題。DEX 并不是Class Method Code隨便寫什么都可以。ART 在加載、驗(yàn)證以及后續(xù)執(zhí)行過程中會(huì)檢查 Method 的結(jié)構(gòu)和 code_item。如果直接code_item 0或者破壞整個(gè) CodeItem很容易造成DEX 驗(yàn)證失敗 VerifyError Class loading failure Crash所以加固系統(tǒng)常見的思路是不破壞方法結(jié)構(gòu)只替換真正的業(yè)務(wù)指令。XopProtector 也是這樣做的。例如原方法intadd(inta,intb){returnab;}原來的 Dalvik 指令可能類似add-int returnPVM1 后變成const/4 v0, 0 return v0 nop nop ...真正的add-int已經(jīng)被拿走。這就是所謂Hollow / Method Hollowing也就是方法空洞化。十四、因此 PVM1 最重要的結(jié)構(gòu)變化是這樣的加固之前classes.dex Method A ↓ CodeItem ↓ 真正業(yè)務(wù) Dalvik 指令加固之后classes.dex Method A ↓ CodeItem ↓ 安全 Stub與此同時(shí)assets/protector/code.bin ↓ PVM1 ↓ AES-GCM ↓ 真正的 Dalvik 指令形成┌─────────────────────┐ │ classes.dex │ │ │ │ Method A │ │ ↓ │ │ Stub / Hollow │ └──────────┬──────────┘ │ │ runtime restore ↓ ┌─────────────────────┐ │ code.bin │ │ │ │ Method Index │ │ Plain Size │ │ Flags │ │ AES-GCM Blob │ └─────────────────────┘十五、PVM1 的第五步生成 code.bin方法被抽取以后需要一個(gè)地方保存這些方法。XopProtector 使用code.bin作為運(yùn)行時(shí)方法代碼倉庫。源碼中的writeCodeBin()會(huì)將不同 DEX 中的保護(hù)方法進(jìn)行組織。當(dāng)前代碼使用的是code.bin v4。其結(jié)構(gòu)可以抽象為Header ↓ version ↓ dex count ↓ dex offsets ↓ Dex Blob每個(gè)方法記錄大致包含methodIndex plainInsnsSize storedInsnsSize flags insns也就是Method Index ↓ 告訴 Runtime “這個(gè)代碼屬于哪個(gè)方法” Plain Size ↓ 解密以后需要恢復(fù)多少字節(jié) Stored Size ↓ 當(dāng)前加密數(shù)據(jù)長度 Flags ↓ 告訴 Runtime PVM1 / PVM2 / 其他類型 Insns ↓ AES-GCM 加密后的方法數(shù)據(jù)源碼中writeCodeBin()明確寫入了methodIndex plainInsnsSize insns.length flags insns并且支持多 DEX。十六、為什么必須保存 Method Index這是整個(gè)方法級(jí)保護(hù)體系的“索引核心”。DEX 中的方法是通過method_ids進(jìn)行編號(hào)的。例如method_id #100 method_id #101 method_id #102PVM1 不需要在code.bin中保存一套完整的 Java/Kotlin 方法名。它可以直接利用methodIndex關(guān)聯(lián)DEX Method ? code.bin Record因此 Runtime 可以實(shí)現(xiàn)methodIndex 102 ↓ 找到 code.bin 中 #102 ↓ AES-GCM decrypt ↓ PVM1 decode ↓ 得到真實(shí) Dalvik instructions ↓ 恢復(fù) Method #102這就是 PVM1 的“方法級(jí)映射關(guān)系”。十七、PVM1 運(yùn)行時(shí)到底發(fā)生了什么這部分是整個(gè)機(jī)制最值得分析的地方。很多人會(huì)誤以為啟動(dòng) APP ↓ 整個(gè) code.bin 解密 ↓ 整個(gè) DEX 恢復(fù)實(shí)際上從源碼結(jié)構(gòu)來看XopProtector 的 Runtime 是圍繞code.bin code_map Method ART Hook組織起來的。Native Shell 啟動(dòng)以后會(huì)先定位dexes.zip code.bin config.json然后加載相關(guān) Key。之后code.bin ↓ read_file() ↓ codeitem::parse() ↓ state.code_mapRuntime 將保護(hù)方法建立成內(nèi)部映射。源碼protector::codeitem::parse(...)解析完成以后state.code_map就成為運(yùn)行時(shí)的方法保護(hù)索引。十八、Runtime 為什么要 Hook ART這里就涉及 Android 加固真正困難的地方。如果Method A在 DEX 中已經(jīng)被替換成return 0那么 ART 自己執(zhí)行的時(shí)候自然只會(huì)執(zhí)行return 0它不知道真正代碼在哪里。所以必須在ART 加載 / 定義 Class / Method的關(guān)鍵路徑上進(jìn)行干預(yù)。XopProtector 在初始化階段會(huì)protector::hook::install_hooks();然后再解析和應(yīng)用code.bin源碼明確說明在解析 / 應(yīng)用 code.bin 前安裝 ART hooks以便 DefineClass 時(shí)進(jìn)行 patch。因此整個(gè)體系實(shí)際上形成DEX ↓ ART ↓ Hook ↓ 識(shí)別被保護(hù) Method ↓ 查 code_map ↓ 恢復(fù)真實(shí) Dalvik ↓ 交給 ART十九、PVM1 的運(yùn)行時(shí)恢復(fù)流程可以把它完整畫成App 啟動(dòng) │ ▼ Native Shell 初始化 │ ▼ 讀取 code.bin │ ▼ codeitem::parse │ ▼ 建立 code_map │ ▼ 安裝 ART Hook │ ▼ ART 加載目標(biāo) Class │ ▼ 檢查 Method 是否受保護(hù) │ ┌──────┴──────┐ │ │ 否 是 │ │ ▼ ▼ 正常執(zhí)行 查詢 code_map │ ▼ AES-GCM 解密 │ ▼ PVM1 Decode │ ▼ 得到真實(shí) Dalvik 指令 │ ▼ Patch CodeItem │ ▼ ART 執(zhí)行這就是 PVM1 最核心的運(yùn)行時(shí)機(jī)制。二十、PVM1 的“虛擬化”到底體現(xiàn)在哪里現(xiàn)在回到最開始的問題PVM1 到底算不算虛擬化答案是算但屬于非常輕量級(jí)的“虛擬化打包”而不是完整 VM 虛擬化。因?yàn)樗_實(shí)把原始代碼Dalvik instructions轉(zhuǎn)換成了PVM1 image原始代碼不再直接位于原 Method CodeItem 中。但是它沒有Dalvik opcode ↓ PVM opcode ↓ VM Register ↓ VM Stack ↓ Dispatcher ↓ Handler這一整套機(jī)制。因此PVM1 Dalvik → protected image → Dalvik而PVM2 Dalvik → custom VM bytecode → Native Interpreter這才是真正意義上的Code Virtualization二十一、為什么 PVM1 比真正虛擬化簡單很多假設(shè)原始代碼intcalc(inta,intb){intxab;returnx*10;}PVM1 的目標(biāo)只是隱藏 add-int mul-int return然后運(yùn)行時(shí)恢復(fù) add-int mul-int returnART 繼續(xù)執(zhí)行。所以 PVM1 并不需要理解add-int mul-int if goto invoke new-instance monitor try/catch的語義。它只需要保存 ↓ 解碼 ↓ 恢復(fù)因此實(shí)現(xiàn)成本相對(duì)較低。二十二、真正的 PVM2 為什么會(huì)復(fù)雜得多假設(shè) PVM2 也拿到add-int mul-int return它不會(huì)把這些指令恢復(fù)到 DEX。而是轉(zhuǎn)換成自己的VM_ADD VM_MUL VM_RETURN然后Native Interpreter switch(opcode) { case VM_ADD: ... case VM_MUL: ... case VM_RETURN: ... }于是ART ↓ JNI Trampoline ↓ Native Interpreter ↓ VM Opcode ↓ Handler整個(gè)執(zhí)行模型都發(fā)生改變。XopProtector 當(dāng)前 PVM2 文檔也明確說明PVM2 方法不會(huì)恢復(fù)到 Dalvik而是通過 JNI trampoline 進(jìn)入 Native Interpreter讀取code.bin中的 PVM2 image。這就是下一篇文章真正需要討論的內(nèi)容。二十三、PVM1 對(duì)靜態(tài)逆向的意義假設(shè)沒有 PVM1classes.dex ↓ jadx ↓ Java/Kotlin-like code攻擊者可以直接看到calculateToken()validateLicense()checkSignature()generateKey()而加入 PVM1 后classes.dex ↓ 目標(biāo)方法 ↓ Stub靜態(tài)分析工具看到的可能只是return0;或者returnnull;真實(shí)邏輯已經(jīng)不在 Method CodeItem 中。所以靜態(tài)反編譯結(jié)果 ≠ 真實(shí)業(yè)務(wù)邏輯這就是 PVM1 最直接的價(jià)值。二十四、但是 PVM1 并不是“不可逆”這一點(diǎn)在技術(shù)文章中必須客觀說明。PVM1 的最終執(zhí)行路徑仍然是PVM1 ↓ Decode ↓ Dalvik ↓ ART所以從攻擊者角度靜態(tài)分析 ↓ 難度增加 運(yùn)行時(shí)動(dòng)態(tài)分析 ↓ 仍然可以觀察 最終恢復(fù)后的 Dalvik ↓ 仍然存在因此PVM1 的目標(biāo)不是讓代碼永遠(yuǎn)無法獲得而是增加靜態(tài)分析和自動(dòng)化脫殼的成本。這也符合 XopProtector 項(xiàng)目本身的定位加固的作用是提高逆向成本而不是保證應(yīng)用絕對(duì)不可破解。二十五、PVM1 最大的價(jià)值其實(shí)是“方法級(jí)明文控制”如果把保護(hù)過程畫成時(shí)間軸APK │ │ 加密狀態(tài) ▼ App 啟動(dòng) │ ▼ Runtime 解密 │ ▼ PVM1 Method Decode │ ▼ Dalvik Method 明文 │ ▼ ART 執(zhí)行關(guān)鍵區(qū)別是以前整個(gè) DEX ↓ 大量代碼同時(shí)明文PVM1Method A ↓ 需要時(shí)恢復(fù) Method B ↓ 需要時(shí)恢復(fù) Method C ↓ 需要時(shí)恢復(fù)因此保護(hù)對(duì)象從“整個(gè)代碼包”變成“一個(gè)個(gè)關(guān)鍵方法”。這就是方法級(jí)加固最重要的工程價(jià)值。二十六、從源碼看PVM1 實(shí)際上是“三層保護(hù)疊加”如果把 XopProtector 的 PVM1 單獨(dú)拆開可以得到第一層 Method Hollowing ↓ 從 DEX 中移除真實(shí)實(shí)現(xiàn) 第二層 PVM1 Transform ↓ XOR Nibble Swap ↓ 破壞原始 Dalvik 數(shù)據(jù)特征 第三層 AES-GCM ↓ 真正的數(shù)據(jù)機(jī)密性所以它并不是PVM1 XOR也不是PVM1 AES而是Method │ ▼ ┌───────────────┐ │ Method Extract│ └───────┬───────┘ ▼ ┌───────────────┐ │ PVM1 Transform │ │ XOR Nibble │ └───────┬───────┘ ▼ ┌───────────────┐ │ AES-GCM │ └───────┬───────┘ ▼ code.bin而 DEX 中只留下Stub二十七、PVM1 和傳統(tǒng)“代碼抽取”有什么區(qū)別如果只說“PVM1 就是把代碼抽出來?！逼鋵?shí)不夠準(zhǔn)確。因?yàn)槠胀ùa抽取可能只是DEX ↓ 抽取 Method ↓ 保存到其他文件但是 PVM1 還增加了Method Index PVM1 Encoding AES-GCM Method Hollowing ART Runtime Restore所以完整體系是代碼抽取 代碼變形 加密存儲(chǔ) 原位置空洞化 運(yùn)行時(shí)恢復(fù)這才構(gòu)成完整的 PVM1。二十八、PVM1 的完整生命周期把整個(gè)源碼實(shí)現(xiàn)濃縮成一條鏈【構(gòu)建階段】 APK │ ▼ 解包 DEX │ ▼ 遍歷 ClassDef │ ▼ 找到目標(biāo) Method │ ▼ 讀取 CodeItem │ ▼ 提取 Dalvik Instructions │ ▼ VmCodec.encode │ ▼ PVM1 Blob 生成 │ ▼ AES-GCM 加密 │ ▼ code.bin │ ├───────────────┐ │ │ ▼ ▼ 原 Method 被抹掉 Stub │ ▼ DEX 重寫 │ ▼ APK 重新打包 【運(yùn)行階段】 App 啟動(dòng) │ ▼ Native Shell │ ▼ 讀取 code.bin │ ▼ codeitem::parse │ ▼ 建立 code_map │ ▼ 安裝 ART Hook │ ▼ ART 加載 Class │ ▼ 找到受保護(hù) Method │ ▼ 查詢 code_map │ ▼ AES-GCM 解密 │ ▼ PVM1 Decode │ ▼ 得到真實(shí) Dalvik │ ▼ Patch Method │ ▼ ART │ ▼ 正常執(zhí)行這條鏈基本就是 XopProtector PVM1 的核心原理。二十九、PVM1 真正解決了什么問題可以總結(jié)成四個(gè)字靜態(tài)不可見。更準(zhǔn)確地說1. 靜態(tài) DEX 中不再存在完整方法實(shí)現(xiàn)攻擊者拿到 DEX 后目標(biāo)方法已經(jīng)被替換成 Stub。2. 方法實(shí)現(xiàn)被移動(dòng)到獨(dú)立數(shù)據(jù)區(qū)真實(shí)代碼進(jìn)入code.bin而不是繼續(xù)留在原來的 CodeItem 中。3. PVM1 破壞原始 Dalvik 數(shù)據(jù)形態(tài)通過XOR KeyStream Nibble Swap讓數(shù)據(jù)不再表現(xiàn)為正常 Dalvik instruction stream。4. AES-GCM 提供真正的機(jī)密性即使攻擊者找到code.bin也不能簡單通過strings dexdump jadx直接獲得原始代碼。三十、但 PVM1 還有一個(gè)天然弱點(diǎn)這也是為什么 XopProtector 后面還需要 PVM2。PVM1加密 ↓ 恢復(fù) ↓ Dalvik ↓ ART所以最終真實(shí) Dalvik還是要出現(xiàn)。因此攻擊者如果把分析重點(diǎn)從APK 靜態(tài)分析轉(zhuǎn)向Runtime ↓ ART Hook ↓ Method Restore ↓ Memory Dump就可能重新獲取真實(shí)方法。所以 PVM1 的安全模型是提高靜態(tài)分析成本 增加脫殼復(fù)雜度 縮短攻擊者直接獲得代碼的路徑 但是 最終仍然回到 ART Dalvik 執(zhí)行體系這也是 PVM1 與 PVM2 最根本的安全邊界。三十一、PVM1 → PVM2是 Android 加固的一次質(zhì)變可以把整個(gè)演進(jìn)過程理解為第一階段 DEX 加密 攻擊者 APK ↓ 找到解密點(diǎn) ↓ 得到 DEX 第二階段 PVM1 攻擊者 APK ↓ 找到 code.bin ↓ 找到 Runtime Restore ↓ 獲取 Dalvik 第三階段 PVM2 攻擊者 APK ↓ 找到 JNI Trampoline ↓ 找到 Native Interpreter ↓ 理解自定義 VM ↓ 分析 VM Opcode ↓ 恢復(fù)原始語義所以難度是逐層提升的。三十二、PVM1 最值得學(xué)習(xí)的工程設(shè)計(jì)從工程實(shí)現(xiàn)角度看PVM1 并沒有試圖一步做到極端復(fù)雜。它采取的是一種非常實(shí)用的思路DEX 加密 ↓ 解決“APK 靜態(tài)暴露” PVM1 ↓ 解決“關(guān)鍵方法暴露” PVM2 ↓ 解決“恢復(fù)后仍然是 Dalvik” SO 加密 ↓ 解決 Native 代碼暴露 RASP ↓ 解決運(yùn)行時(shí)攻擊也就是說不同保護(hù)技術(shù)解決不同攻擊面。這比單純依賴一種“超級(jí)加密算法”更加符合商業(yè) APK 加固系統(tǒng)的工程思路。三十三、源碼層面的關(guān)鍵文件如果你準(zhǔn)備繼續(xù)深入研究 XopProtector那么 PVM1 最值得看的幾個(gè)源碼位置是packer/ └── src/main/java/com/yqsh/protector/packer/ │ ├── PackerMain.java │ ├── walkDexMethods() │ ├── extractOne() │ ├── writeReturnStub() │ └── writeCodeBin() │ └── VmCodec.java ├── encode() └── decode()其中PackerMain.java負(fù)責(zé)掃描 DEX ↓ 定位 Method ↓ 抽取指令 ↓ 替換 Stub ↓ 生成 code.binVmCodec.java負(fù)責(zé)PVM1 Encode PVM1 DecodeNative 側(cè)則對(duì)應(yīng)native/src/main/cpp/vm/ └── vm_codec.cpp負(fù)責(zé)運(yùn)行時(shí)PVM1 DecodeNative Runtimenative/src/main/cpp/runtime/ └── engine.cpp負(fù)責(zé)初始化 ↓ 加載 code.bin ↓ 建立 code_map ↓ 安裝 Hook ↓ 進(jìn)入運(yùn)行時(shí)保護(hù)流程這些源碼結(jié)構(gòu)可以非常清晰地證明PVM1 并不是一個(gè)獨(dú)立的 VM而是 Packer Native Runtime ART Hook 三者協(xié)同完成的方法級(jí)保護(hù)機(jī)制。三十四、最終總結(jié)一句話理解 XopProtector PVM1如果只用一句話解釋PVM1 就是在構(gòu)建階段把關(guān)鍵方法的 Dalvik 指令從 DEX 中抽出來經(jīng)過 PVM1 變換和 AES-GCM 加密后保存到code.bin原 Method 只留下與返回類型匹配的安全 Stub應(yīng)用運(yùn)行時(shí)由 Native Shell 解析code.bin通過 ART Hook 找到目標(biāo) Method解密并恢復(fù)真實(shí) Dalvik 指令再交給 ART 執(zhí)行。整個(gè)過程可以最終濃縮成PVM1 ┌───────────────────┐ │ 原始 Method │ └─────────┬─────────┘ │ ▼ 提取 Dalvik Code │ ▼ PVM1 Encode XOR NibbleSwap │ ▼ AES-GCM │ ▼ code.bin │ │ ┌─────────▼─────────┐ │ 原 DEX Method │ │ │ │ 真實(shí) Code 被移除 │ │ ↓ │ │ Stub │ └───────────────────┘ Runtime Native Shell │ ▼ code.bin │ ▼ code_map │ ▼ ART Hook │ ▼ 找到目標(biāo) Method │ ▼ AES-GCM Decode │ ▼ PVM1 Decode │ ▼ 恢復(fù) Dalvik │ ▼ Patch Method │ ▼ ART │ ▼ 執(zhí)行代碼所以PVM1 不是“讓代碼不再執(zhí)行”而是讓代碼不再以正常 DEX Method 的形式存在。這就是它和傳統(tǒng) DEX 加密最大的區(qū)別。而下一階段真正值得研究的問題就是如果連“恢復(fù) Dalvik”這一步都不要了能不能讓被保護(hù)方法從始至終都不回到 DEX而是直接由 Native 自己解釋執(zhí)行答案就是PVM2。PVM2 不再是加密 → 解密 → 恢復(fù) Dalvik → ART而會(huì)變成原始 Dalvik ↓ PVM2 Compiler ↓ 自定義 VM Image ↓ JNI Trampoline ↓ Native Interpreter ↓ VM Opcode ↓ 執(zhí)行XopProtector 當(dāng)前源碼中的 PVM2 已經(jīng)進(jìn)一步加入了多 ISA、Opcode Morphing、RASP Gate、解釋執(zhí)行以及 PVM2 Image等機(jī)制。PVM2 v3 還會(huì)為每個(gè) APK 生成 opcode 映射并根據(jù)isa_id選擇不同 Native dispatch 入口。這才是真正意義上的 Android 代碼虛擬化。下一篇《Android APK 加固原理四真正的代碼虛擬化——PVM2 Native Interpreter 技術(shù)解析》將重點(diǎn)拆解Dalvik ↓ PVM2 Compiler ↓ VM Opcode ↓ PVM2 Image ↓ JNI Trampoline ↓ Native Interpreter ↓ Dispatcher ↓ Opcode Handler ↓ 寄存器 / 對(duì)象 / Field / Method ↓ 最終執(zhí)行并重點(diǎn)解釋為什么 PVM2 和 PVM1 已經(jīng)不是同一個(gè)層級(jí)的加固技術(shù)。參考源碼本文分析以 XopProtector 當(dāng)前公開源碼為基礎(chǔ)重點(diǎn)涉及packer/PackerMain.javapacker/VmCodec.javanative/vm/vm_codec.cppnative/runtime/engine.cppPVM2 設(shè)計(jì)文檔項(xiàng)目公開 README 明確將--vmp-prefix定義為 PVM1將--true-vmp-prefix定義為 PVM2。