安卓APP逆向分析與保護機制是怎樣的-安全-PHP中文網

想知道Android App常見的保護方法及其對應的逆向分析方法嗎？

在本次分享中，探討了多個面向的安卓APP安全，包括混淆程式碼、整體Dex加固、分割Dex加固和虛擬機器加固。這些內容已經成為國內近幾年Android App安全保護的主要趨勢。

一、混淆程式碼

Java程式碼是非常容易反編譯的，作為一種跨平台的、解釋型語言，Java 原始碼被編譯成中間「字節碼」儲存於class文件中。由於需要跨平台，這些字節碼包含大量語意訊息，容易被反編譯成Java原始碼。開發人員通常會對編譯好的class檔案進行混淆以更好地保護Java原始碼。

混淆就是將發佈出去的程式重新組織和處理，使得處理後的程式碼與處理前程式碼完成相同的功能，而混淆後的程式碼很難被反編譯，即使反編譯成功也很難得出程式的真正語意。 ProGuard是一個開源項目，它能對字節碼進行混淆、體積縮減和最佳化等處理。

Proguard處理流程圖如下所示，包含壓縮、最佳化、混淆、預檢四個主要環節：

安卓APP逆向分析與保護機制是怎樣的

壓縮（Shrink）：偵測並移除程式碼中無用的類別、欄位、方法和特性（Attribute）；

優化（Optimize）：對字節碼進行最佳化，移除無用的指令。最佳化程式碼，非入口節點類別會加上private/static/final，沒有用到的參數會被刪除，有些方法可能會變成內聯程式碼；

混淆（Obfuscate）：使用a、b 、c、d這樣簡短而無意義的名稱，對類別、欄位和方法進行重命名；

預檢（Preveirfy）：在Java平台上對處理後的程式碼進行預檢，確保載入的class檔案是可執行的。

在分享中，鐘亞平展示了利用Proguard，對Dex2jar進行反編譯處理後的Apk效果範例：

安卓APP逆向分析與保護機制是怎樣的
Proguard處理後

安卓APP逆向分析與保護機制是怎樣的

Proguard混淆器不僅能夠保護程式碼，而且能夠精簡編譯後的程式大小，減少記憶體佔用。

混淆程式碼逆向分析

鐘亞平分享了一個名為DEGUADR的國外工具，它使用統計方法來解混淆程式碼，以便反編譯。儘管這個工具的準確性不是100%，但它仍能部分地幫助反編譯程式碼。

安卓APP逆向分析與保護機制是怎樣的

##使用DEGUADR解混淆的範例：

安卓APP逆向分析與保護機制是怎樣的

#com.xxxxx. common.util.CryptoUtil網站也提供了一種反編譯服務，如下所示：

java.lang.String a(byte[]) -> encodeToStringjava.lang.String a(byte[],boolean,java.lang.String) -> a byte[] a(byte[],byte[]) -> encrypt byte[] b(byte[]) -> getKey byte[] b(byte[],byte[]) -> decrypt byte[] d(java.lang.String) -> getKey java.lang.String a(byte,char[]) -> a java.lang.String a(java.io.File) -> getHash java.lang.String a(java.lang.String) -> c java.lang.String b(java.lang.String) -> encode

登入後複製

二、整體Dex加固

隨著安全技術的不斷發展，新的「加固技術「已經出現，用以加強Android的保護強度。 DEX加固是對DEX檔進行加殼防護，防止被靜態反編譯工具破解而洩漏源碼，最剛開始出現的是整體加固技術方案。

安卓APP逆向分析與保護機制是怎樣的

整體加固技術的原理如上所示，包括取代application/classes.dex、解密/動態載入原classes.dex、呼叫原application相關方法、將原application物件/名稱設定到系統內部相關變數四大環節。其中最關鍵的一步就是解密/動態載入原classes.dex，透過加密編譯好的最終dex原始碼文件，然後在一個新專案中用新專案的application啟動來解密原專案碼並載入到記憶體中，再把當前進程替換為解密後的程式碼，能夠很好地隱藏原始碼並防止直接性的反編譯。

整體Dex加固逆向分析

整體Dex加固逆向分析有兩種常用的方法。其一是在記憶體中暴力搜尋 dex\n035，再 dump。以下是32位元系統中效果的範例：

安卓APP逆向分析與保護機制是怎樣的

另一種方法是透過HookdvmDexFileOpenPartial(void* addr, int len, DvmDex**)。

三、拆分Dex加固

隨著業務規模發展到一定程度，不斷地加入新功能、增加新的類別庫，程式碼在急劇膨脹的同時，對應的apk包的大小也急劇增加，那麼簡單的整體加固方案就不能很好地滿足安全需求，在整體加固方案之外又出現了分割加固的技術方案。

安卓APP逆向分析與保護機制是怎樣的

但是如上所示，dex檔案在加固時，針對中間缺少的一部分資料會以解密後的資料來替換，有的時候這種拆分替換也會導致數據不準確。需要了解dex檔案的資料結構，才能確定應該拆分哪種類型的資料。

Dex檔案結構極為複雜，以下圖示選取了其中較為重要的內容。事實上，dex文件是一個以class為核心組裝起來的文件，其中最重要的是classdata和classcode兩部分，有其特定的接口和指令數據，選取這兩部分來拆分的話，即使拆分出來也不會洩漏class數據和字節碼數據，反編譯出來也不完整，安全性較高。

安卓APP逆向分析與保護機制是怎樣的

拆分Dex加固逆向分析

對於dex拆分加固的反向分析，如下所示，可用classdata替換從而組裝成新的dex文件，雖然和原來的dex文件不會完全一致，但也在一定程度上復原了被拆分資料的樣子。

安卓APP逆向分析與保護機制是怎樣的

但要注意的是，這種方法只適用於被分割出去的資料變形一次完成，也就是說，在有其他保護思路的情況下盡量避免使用，而且即使有需要也盡量選在用到這個類的時候才去恢復。

此外還有一個更底層一些的工具dexhunter，這個工具較為前衛，但同時也有一些局限性，譬如部分指令數據會被優化，形成的代碼界面不是很美觀等等。

安卓APP逆向分析與保護機制是怎樣的

四、虛擬機器加固

對位元組進行處理是虛擬機器加固的一種方式，也可視為dex分加固的一種。以下是經過虛擬機器加固處理的常規的Android系統程式碼

## 安卓APP逆向分析與保護機制是怎樣的

以add-int v0, v1, v2、sub-int v0, v1, v2 、mul-int v0, v1, v2這三條指令進行替換，然後進行加固編譯，這樣子操作後，即使把替換後的資料恢復了，也不會以add-int v0, v1, v2、sub-int v0, v1, v2、mul-int v0, v1, v2這三條指令進行替換，然後進行加固編譯，這樣子操作後，即使把替換後的資料恢復了，也不會變形成為之前的字節碼，安全係數較高。

虛擬機器加固逆向分析—HOOK JNI 介面

這種方式下的逆向分析，一方面可以透過HOOK JNI 介面來實現，它有兩種實作方式。

其一是類別成員/靜態變數操作相關接口，例如：

GetStaticDoubleFieldSetStaticDoubleField GetDoubleField SetDoubleField …
(byte, object, int,long…)

其二是反射呼叫類別方法，例如：

CallVoidMethodACallBooleanMethodA CallShortMethodA CallObjectMethodA …
CallStaticVoidMethodACallStaticBoolean,A CallStaticShort#A CallStaticObjectMethodMethod#fby#; int, long,double …)
CallObjectMethodA(JNIEnv* env, jobject object, jmethoID method, …)

透過HOOKJNI 介面實現虛擬機器加固分析

安卓APP逆向分析與保護機制是怎樣的使用HOOK JNI介面可以了解APP大致的呼叫流程，無需進行底層逆向。但對於複雜的呼叫過程，或是虛擬化方法數量較多的情況，這種逆向分析手段看起來會比較混亂；對於不需要返射到Java層執行的指令，如算術、邏輯運算等，則無法監控到。