淺談安卓apk加固原理和實現

（1）apk檔案結構

解壓一個apk包，可以看到如下目錄結構：

assets：存放工程資源(圖片、本地html等)檔案的目錄

Lib：存放ndk編譯出來的so檔案（so:C/C++編譯出的檔案）

META-INF：

該目錄下存放的是簽名資訊，用來保證apk包的完整性和系統的安全性：

CERT.RSA：儲存著該應用程式的證照和授權資訊

CERT.SF：儲存著SHA-1資訊資源列表

MANIFEST.MF：清單資訊

res：存放資源（佈局xml、佈局xml引用圖片等）檔案的目錄

AndroidManifest.xml：清單檔案，它描述了應用的名字、版本、許可權、註冊的服務等資訊

classes.dex：java原始碼編譯經過編譯後生成的dalvik位元組碼檔案，主要在Dalvik虛擬機器上執行的主要程式碼部分

resources.arsc：編譯後的二進位制資原始檔

META-INF檔案主要是跟簽名有關的檔案，保證了apk的完整性和安全性。apk每次重新簽名需要刪除該資料夾。

需要大家主要關注的是classes.dex檔案：因為apk加固主要是對dex檔案進行的加密。

 (2)Dex檔案結構

Java原始檔生成Dex檔案的對映關係

dex檔案可以理解為由java檔案編譯生產的，直觀表現就是dex檔案可以編譯出java原始碼；

dex檔案的作用是記錄整個工程（通常是一個Android工程）的所有類檔案的資訊；

dex檔案是從class檔案演變而來的，class檔案存在冗餘資訊，dex檔案則去掉了冗餘，並且整合了整個工程的類資訊。

Dex檔案結構

檔案頭header包含了dex檔案的資訊，也是大家需要關注的部分。因為下面的操作中會有dex檔案的修改操作，而判斷是否是正確的dex檔案是由header部分決定的。

下面看一下header部分的資訊：

struct DexFile { 
	DexHeader     header;
 	DexStringId     StringIds[StringIdsSize];
 	DexTypeId      TypeIds[typeIdsSize];
	DexProtoId     ProtoIds[protoIdsSize]; 
	DexFieldId      FieldIds[fieldIdsSize]; 
	DexMethodId   MethodIds[methodIdsSize];
 	DexClassDef    Data[]; 
	DexLink        LinkData;
 }

Dex檔案header部分結構體資訊

Header部分有需要注意的三個欄位：checksum欄位、signature欄位、filesize欄位。

checksum欄位： checksum是校驗碼欄位，校驗dex資料的完整性

signature欄位： signature是SHA-1簽名欄位，dex資料完整性校驗

signature欄位：儲存classes.dex檔案總長度

之所以關注這三個欄位，是因為後面會有對dex的重新拼接。dex拼接後要修改這三個欄位，欄位修改正確後才可以保證dex的正確載入。

 (3)Dex檔案整體加固原理

上圖物件解析：

源apk：需要加密的apk程式，源dex來自於源apk

殼程式：Android工程，提供殼dex，殼dex主要作為工程入口，解密出源dex，對映到源dex等操作

加密程式：java工程，主要是做對源dex加密且和殼dex合併成新dex的操作

 (4)整個工程載入原理

APP啟動——>自定義Application中attachBaseContext()方法——>自定義Application工程onCreate()方法——>源Application

1、自定義Application來自於殼程式的dex，加密合成的新dex前半部分就是殼程式的dex，這部分是沒任何問題，可以正常載入。該Application中attachBaseContext方法會做解密操作，解密出源dex並放置在固定目錄下，新增dex的載入對映；對映到源dex目錄。

2、自定義Application工程onCreate()方法新增源dex載入的入口；即源dex的application和mainActivity。

3、程式正常啟動；源dex被正確載入。

準備：

SourceProject：

需要加密源程式,自定義application為：

com. targetapk

MyApplication，主activity為：

com. targetapk.MainActivity

jiaguApk：java工程，dex加密合並操作

shellApk：android工程，提供殼dex；自定義Application設定為：

org.hackcode.ProxyApplication

SourceProject是簡單的Android工程demo，編譯生成生成被殼加密的sourceProject.apk

jiaguApk是主要作用是加密源sourceProject.apk中dex檔案；然後拼接到殼dex後面生成新的dex

shellApk是殼工程，主要是作為加密後apk的偽入口，加密後的apk工程會先載入殼工程提供Application：org.hackcode.ProxyApplication，解密、對映等操作

整體加密步驟：

1.反編譯目標app(sourceProject.apk)，得到sourceProject檔案；sourceProject.apk來源於SourceProject工程

2.修改sourceProject檔案中的manifest檔案，將自定義Application設定為“org.hackcode.ProxyApplication”

3.拿到sourceProject檔案中的dex檔案，壓縮為TargetApk.zip

4.反編譯殼apk：apktool.bat d shellApk.apk，得到shellApk檔案

5.拿到shellApk檔案下的classes.dex和TargetApk.zip，加密合成新的classes.dex檔案

6.新合成的class.dex替換sourceProject檔案中的class.dex

7.刪除sourceProject檔案中的META-INF檔案，重壓縮成zip檔案

8.重新簽名

步驟2主要是是為了載入殼dex中的程式碼；正確解析dex。

步驟6主要是jiaguApk工程的工作。

jiaguApk關鍵程式碼

以上程式碼主要作用是源程式dex壓縮成TargetApk.zip後加密，加密後拼接在殼dex的後面，然後生成新的dex檔案，dex檔案修改頭部引數，保證dex檔案正確讀取。

此時生成的新的dex檔案前部分是能正確被執行的殼dex的程式碼。

shellApk殼工程關鍵程式碼

attachBaseContext方法：

主要作用是程式apk中dex拷貝、解密出源dex放在data/data目錄下；設定dex載入目錄對映。

onCreate：

主要作用替換源應用dex的application，使解密出的源dex正確載入；保證源入口正確，保證專案正確載入。

以上就是apk加殼實現整個過程。實現起來基本沒什麼問題，需要注意的點是源工程有多dex問題：源程式中有多個dex的時候，多個dex同時一塊壓縮成TargetApk.zip，然後其他步驟不變。親測沒問題！

（1）首次開啟載入慢的問題。加固後的工程首次開啟會有延時，延時時間會跟源工程的dex大小有關。就拿普元客戶端來說，裡面有兩個dex，總共有8M左右；加固後首次開啟會慢3s左右；而且以後每次開啟會有2s左右的延時。

（2）安全性問題。大家會發現源dex檔案還是會落地，在工程的data/data目錄下面，越獄的手機可以直接看到。拿到dex資源，一樣可以通過反編譯拿到java程式碼。網上有不落地的方法，嘗試一直沒有成功；如果哪位大神有可行方法的話，歡迎分享交流。