淺談安卓apk加固原理和實現
引言：
在安卓開發中，打包釋出是開發的最後一個環節，apk是整個專案的原始碼和資源的結合體；對於懂點反編譯原理的人可以輕鬆編譯出apk的原始碼資源，並且可以修改資原始碼、重新打包編譯，輕輕鬆鬆變成自己的apk或者修改其中一部分竊取使用者資訊。
程式碼被反編譯對於apk的開發者和使用者而言十分苦惱。apk加固、防止反編譯此時顯得尤為重要。雖然有好多給apk加固的第三方，可能並不需要自己做apk加固，但是瞭解apk加固原理還是很有必要的。本文主要向大家介紹apk加固原理和簡單實現。
目錄：
一、apk常見加固方式
二、apk加固原理
三、apk加固實現
四、apk該方式加固後缺陷
一、apk常見加固方式
（1）程式碼層級加密--程式碼混淆
程式碼混淆是一種常用的加密方式。本質是把工程中原來的有具體含義的類名、變數名、方法名，修改成讓人看不懂的名字。常見的程式碼混淆工具proguard（有興趣的可以自己看一下該工具：http://t.cn/ELjgHdi）。該加密方式只是對工程提供了最小的保護，並不是說不能逆向破解；只是說難度增加，需要耐心。
（2） Dex檔案加密
dex是Android工程中的程式碼資原始檔，通過dex可以反編譯出java程式碼。dex的加殼是常見的加密方式。通過對dex檔案加密拼接加殼，可以有效的對工程程式碼進行保護。apk工程在安裝成功後，app啟動時會有dex解密的過程，然後重新載入解密後的dex檔案。
第二種加密方式也就是本文要為大家分享的加密方式。基本原理是在jni層， 使用DexClassLoader動態載入技術完成對加密classex.dex的動態載入，dex檔案可以附屬在assert或raw目錄。
二、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檔案結構
dex檔案可以理解為由java檔案編譯生產的，直觀表現就是dex檔案可以編譯出java原始碼；
dex檔案的作用是記錄整個工程（通常是一個Android工程）的所有類檔案的資訊；
dex檔案是從class檔案演變而來的，class檔案存在冗餘資訊，dex檔案則去掉了冗餘，並且整合了整個工程的類資訊。
檔案頭header包含了dex檔案的資訊，也是大家需要關注的部分。因為下面的操作中會有dex檔案的修改操作，而判斷是否是正確的dex檔案是由header部分決定的。
下面看一下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被正確載入。
三、apk加固實現
準備：
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，然後其他步驟不變。親測沒問題！
四、apk該方式加固後缺陷
（1）首次開啟載入慢的問題。加固後的工程首次開啟會有延時，延時時間會跟源工程的dex大小有關。就拿普元客戶端來說，裡面有兩個dex，總共有8M左右；加固後首次開啟會慢3s左右；而且以後每次開啟會有2s左右的延時。
（2）安全性問題。大家會發現源dex檔案還是會落地，在工程的data/data目錄下面，越獄的手機可以直接看到。拿到dex資源，一樣可以通過反編譯拿到java程式碼。網上有不落地的方法，嘗試一直沒有成功；如果哪位大神有可行方法的話，歡迎分享交流。
原文釋出時間為：2018-12-4
本文作者：張存徵
本文來自雲棲社群合作伙伴“ ofollow,noindex">EAWorld ”，瞭解相關資訊可以關注“EAWorld”微信公眾號