一文瞭解安卓APP逆向分析與保護機制

標籤：對象   無法   逆向分析   html   能力   ref   www   帶來   資深   

“知物由學”是網易雲易盾打造的一個品牌欄目，詞語出自漢·王充《論衡·實知》。人，能力有高下之分，學習才知道事物的道理，而後才有智慧，不去求問就不會知道。“知物由學”希望通過一篇篇技術乾貨、趨勢解讀、人物思考和沉澱給你帶來收穫的同時，也希望開啟你的眼界，成就不一樣的你。

 

以下為文章本文：

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

 

                                                    網易雲易盾資深安全工程師 鐘亞平

3月17日，安卓巴士全球開發人員論壇在重慶舉辦，網易資深安全工程師鐘亞平出席交流活動，並做了《安卓APP逆向與保護》的演講。在分享中，他介紹了 Android App常見保護方法及其對應的逆向分析方法，以及分析了常見的加固方案原理與對抗方法。

安卓APP安全性組件含很多內容，本次分享了混淆代碼、整體Dex加固、拆分 Dex 加固、虛擬機器加固等方面。事實上，這些內容也是國內近幾年Android App安全保護的一種主要趨勢。

一、混淆代碼

Java代碼是非常容易反編譯的，作為一種跨平台的、解釋型語言，Java 原始碼被編譯成中間“位元組碼”儲存於class檔案中。由於跨平台的需要，這些位元組碼帶有許多的語義資訊，很容易被反編譯成Java原始碼。為了很好地保護Java原始碼，開發人員往往會對編譯好的class檔案進行混淆處理。

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

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

 

 

壓縮（Shrink）：檢測並移除代碼中無用的類、欄位、方法和特性（Attribute）；
最佳化（Optimize）：對位元組碼進行最佳化，移除無用的指令。最佳化代碼，非入口節點類會加上private/static/final，沒有用到的參數會被刪除，一些方法可能會變成內聯代碼；
混淆（Obfuscate）：使用a、b、c、d這樣簡短而無意義的名稱，對類、欄位和方法進行重新命名；
預檢（Preveirfy）：在Java平台上對處理後的代碼進行預檢，確保載入的class檔案是可執行檔。

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

 

                                                           Proguard處理後

 

 

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

混淆代碼逆向分析

如果想要反編譯混淆代碼，鐘亞平分享了一個國外的工具DEGUADR，它能夠通過統計的方式來解混淆。雖然這個工具的正確率達不到100%，但是能在一定程度上協助反編譯代碼。

 

 

使用DEGUADR解混淆的樣本：

 

 

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

 

java.lang.String a(byte[]) -> encodeToString

java.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檔案進行加殼防護，防止被靜態反編譯工具破解而泄露源碼，最剛開始出現的是整體加固技術方案。

 

 

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

整體Dex加固逆向分析

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

 

 

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

三、拆分Dex加固

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

 

 

但是如上所示，dex檔案在加固時，針對中間缺失的一部分資料會以解密後的資料來替換，有的時候這種拆分替換也會導致資料不準確。那麼到底應該拆分什麼樣的資料呢？就需要瞭解一下dex檔案的資料結構。

Dex檔案結構極為複雜，以示選取了其中較為重要的內容。事實上，dex檔案是一個以class為核心組裝起來的檔案，其中最重要的是classdata和classcode兩部分，有其特定的介面和指令資料，選取這兩部分來拆分的話，即使拆分出來也不會泄露class資料和位元組碼資料，反編譯出來也不完整，安全性較高。

 

 

 

拆分Dex加固逆向分析

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

 

 

 

 

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

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

 

 

 

 

四、虛擬機器加固

虛擬機器加固也屬於dex拆分加固的一種，它是對位元組做了一些變化處理。如下所示，這是一個正常安卓系統中的代碼，在其中進行了虛擬機器加固操作：

 

 

 

 

以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 …
CallStaticVoidMethodACallStaticBooleanMethodA CallStaticShortMethodA CallStaticObjectMethodA …
(byte, int, long,double …)
CallObjectMethodA(JNIEnv* env, jobject object, jmethoID method, …)

 

通過HOOKJNI 介面實現虛擬機器加固逆向分析

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

虛擬機器加固逆向分析—分析指令作業碼映射

另一方面，也可以通過分析指令作業碼映射來逆向分析。在同一加固版本，或者映射關係相同的情況下，可以採取以下所示的方法：

 

 

 

但在實際情況中，每次加固時的映射關係都是隨機變化的，如下所示，這種情況下就無法直接建立映射關係。

 

 

 

 

不依賴於作業碼的映射關係只與虛擬機器結構有關，所以需要根據位移關係建立映射關係，從而進行逆向分析。

 

 

 

 

 

 

 

以上就是此次《安卓APP逆向與保護》主題的全部分享內容。

 

安卓APP逆向保護作為開發工作中的重要內容，一直是網易雲易盾致力於提供的應用服務。“後續，我們將在SO加密保護方面進行更加深入的研究。”鐘亞平最後說道。

*本文網易雲易盾，來自FreeBuf.COM

一文瞭解安卓APP逆向分析與保護機制