APP加固技術歷程及未來級別方案:虛機源碼保護

傳統App加固技術,前后經歷了四代技術變更,保護級別每一代都有所提升,但其固有的安全缺陷和兼容性問題始終未能得到解決。而下一代加固技術—虛機源碼保護,適用代碼類型更廣泛,App保護級別更高,兼容性更強,堪稱未來級別的保護方案。

undefined

(加固技術發(fā)展歷程)

第一代加固技術—動態(tài)加載

第一代Android加固技術用于保護應用的邏輯不被逆向與分析,最早普遍在惡意軟件中使用,其主要基于Java虛擬機提供的動態(tài)加載技術。

其保護流程是:

開發(fā)階段中將程序切分成加載(Loader)與關鍵邏輯(Payload)兩部分,并分別打包;

undefined

(開發(fā)階段)

運行時加載部分(Loader)會先運行,釋放出關鍵邏輯(Payload),然后java的動態(tài)加載技術進行加載,并轉交控制權。

undefined

(啟動流程)

undefined

(核心代碼)

備注(multidex組件的加固原理):

Android的DEX文件在設計之初程序普遍較小,所以在DEX文件設計時,只允許包含65535個函數引用。而隨著Android應用的發(fā)展,大量的應用的代碼已經超過了65535的限制,為了解決這個問題,Android5.0之后原生支持加載多個dex,而為了對舊版本的兼容,Android提供了multidex組件。該組件的實現原理與上面介紹的是一致的。

缺陷與對抗

第一代加固技術的缺陷是依賴Java的動態(tài)加載機制,而這個機制要求關鍵邏輯(Payload)部分必須解壓,并且釋放到文件系統,這就給了攻擊機會去獲取對應的文件。雖然可以通過關鍵邏輯(Payload)被加載后,被從文件系統刪除,用于防止被復制,但是攻擊者可以攔截對應的刪除函數,阻止刪除。

而關鍵邏輯(Payload)會被加密后保存,可用于對抗靜態(tài)分析,但是攻擊者可以通過自定義虛擬機,攔截動態(tài)加載機制所使用的關鍵函數,在這個函數內部,復制文件系統中的關鍵邏輯(Payload)文件。

第二代加固技術—不落地加載

相對第一代加固技術,第二代加固技術在APK修改方面已經完善,能做到對開發(fā)的零干擾。開發(fā)過程中不需要對應用做特殊處理,只需要在最終發(fā)布前進行保護即可。而為了實現這個零干擾的流程,Loader需要處理好Android的組件的生命周期。

主要流程:

1)Loader被系統加載。

2)系統初始化Loader內的StubApplication。

3)StubApplication解密并且加載原始的DEX文件(Payload)。

4)StubApplication從原始的DEX文件(Payload)中找到原始的Application對象,創(chuàng)建并初始化。

5)將系統內所有對StubApplication對象的引用使用替換成原始Application,此步驟使用JAVA的反射機制實現。6)由Android系統進行其他組件的正常生命周期管理。

undefined

(對開發(fā)零干擾的加固后啟動流程)

另一方面,不落地加載技術是在第一代加固技術的基礎上改進,主要解決第一代技術中Payload必須釋放到文件系統(俗稱落地)的缺陷,其主要的技術方案有兩種:

A.攔截系統IO相關的函數(如read、write),在這些函數中提供透明加解密。具體的流程是:

1)關鍵邏輯(Payload)以加密的方式存儲在APK中。

2)運行時加載部分(Loader)將關鍵邏輯釋(Payload)放到文件系統,此時關鍵邏輯(Payload)還處于加密狀態(tài)。

3)加載部分攔截對應的系統IO函數(read,write等)。

4)加載部分(Loader)正常調用Java動態(tài)加載機制。由于虛擬機的IO部分被攔截,所以虛擬機讀取到已經解密的關鍵邏輯(Payload)。

undefined

(透明加解密方案流程)

B.直接調用虛擬機提供的函數進行不落地的加載,具體流程是:

1)關鍵邏輯(Payload)以加密的方式存儲在APK中。

2)運行時加載部分(Loader)將關鍵邏輯釋(Payload)放到內存。

3)加載部分調用虛擬機內部接口進行加載。

undefined

(不落地加載流程)

關鍵的系統函數如下:

undefined

兼容性

方案A透明加密方案由于其需要攔截系統的IO函數,這部分會使用inline hook或者got hook等技術,其會帶來一定的兼容性問題

方案B的不落地加載方案由于其調需要調用系統內部的接口,而這個接口并不導出,各個廠商在實現時又有各自的自定義修改,導致該方案存在兼容性問題。

缺陷與對抗

第二代加固技術在應用啟動時要處理大量的加解密加載操作,會造成應用長時間假死(黑屏),用戶體驗差。

在加固技術實現上沒有本質區(qū)別,雖然能防止第一代加固技術文件必須落地被復制的缺陷,但是也可以從以下方面進行對抗:

例如內存中的DEX文件頭會被清除,用于防止在dump文件中被找到;DEX文件結構被破壞,例如增加了一些錯誤的數據,提高恢復的成本。

但是Payload被加載之后,在內存中是連續(xù)的,利用gdb等調試工具dump內存后可以直接找到Payload,進行簡單的處理之后可以恢復出100%的Payload文件。

和第一代加固技術的對抗方法一樣,不落地加載也無法對抗自定義虛擬機。只需對上述的關鍵函數進行攔截然后將對應的內存段寫出去,即可恢復Payload。注意,由于IO相關的函數被攔截,所以無法直接調用read/write等函數進行直接的讀寫,需要使用syscall函數進行繞過。

雖然廠商會自己實現可能上述函數,從而繞過上述函數的攔截。但是Android的類加載器必須能找到對于的結構體才能正常執(zhí)行,攻擊者可以以類加載器做為起點,找到對應的Payload在內存中的位置。

第三代加固技術—指令抽離

由于第二代加固技術僅僅對文件級別進行加密,其帶來的問題是內存中的Payload是連續(xù)的,可以被攻擊者輕易獲取。第三代加固技術對這部分進行了改進,將保護級別降到了函數級別。

主要的流程是:發(fā)布階段將原始DEX內的函數內容(Code Item)清除,單獨移除到一個文件中。

undefined

(發(fā)布階段)

運行階段將函數內容重新恢復到對應的函數體。恢復的時間點有幾個方式:

A.加載之后恢復函數內容到DEX殼所在的內存區(qū)域

undefined

(運行階段)

B.加載之后將函數內容恢復到虛擬機內部的結構體上:虛擬機讀取DEX文件后內部對每一個函數有一個結構體,這個結構體上有一個指針指向函數內容(CodeItem),可以通過修改這個指針修改對應的函數內容。

undefined

C.攔截虛擬機內與查找執(zhí)行代碼相關的函數,返回函數內容。

兼容性

指令抽離技術使用了大量的虛擬內部結構與未被文檔的特性,再加上Android復雜的廠商定制,帶來大量的兼容性問題。

缺陷與對抗

指令抽離技術的某些方案與虛擬機的JIT性能優(yōu)化沖突,無法達到最佳的運行性能。依舊使用了java虛擬機進行函數內容的執(zhí)行。攻擊者可以通過自定義Android虛擬機,在解釋器的代碼上做記錄一個函數的內容(CodeItem)。接下來遍歷觸發(fā)所有函數,從而獲取到全部的函數內容。最終重新組裝成一個完整的DEX文件。目前已經有自動化工具可以指令抽離技術中脫殼。

undefined

(第三代加固DEX文件脫殼流程)

第四代加固技術—指令轉換/VMP

第三代加固技術在函數級別的保護,使用Android虛擬機內的解釋器執(zhí)行代碼,帶來可能被記錄的缺陷,第四代加固技術使用自己的解釋器來避免第三代的缺陷。而自定義的解釋器無法對Android系統內的其他函數進行直接調用,必須使用JAVA的JNI接口進行調用。其主要實現由兩種:

A.DEX文件內的函數被標記為native,內容被抽離并轉換成一個符合JNI要求的動態(tài)庫。 動態(tài)庫內通過JNI和Android系統進行交互。

undefined

B.DEX文件內的函數被標記為native,內容被抽離并轉換成自定義的指令格式,該格式使用自定義接收器執(zhí)行,和A一樣需要使用JNI和Android系統進行調用。

undefined

兼容性

第四代VMP加固技術一般配合第三代加固技術使用,所以第三代的所有兼容性問題,指令轉換/VMP加固也存在。

缺陷與對抗

不論使用指令轉換/VMP加固的A方案或者B方案,其必須通過虛擬機提供的JNI接口與虛擬機進行交互,攻擊者可以直接將指令轉換/VMP加固方案當作黑盒,通過自定義的JNI接口對象,對黑盒內部進行探測、記錄和分析,進而得到完整DEX程序。

undefined

(第四代加固DEX文件恢復)

另外,第四代VMP加固技術只實現Java代碼保護,沒有做到使用VMP技術來保護C/C++等代碼,安全保護能力有所欠缺。

下一代加固技術—虛機源碼保護

跟第四代的VMP加固技術,虛機源碼保護加固是用虛機技術保護所有的代碼,包括Java,Kotlin,C/C++,Objective-C,Swift等多種代碼,具備極高的兼容性;使App得到更高安全級別的保護,運行更加穩(wěn)定。

虛機源碼保護為用戶提供一套完整的工具鏈,首先把用戶待保護的核心代碼編譯成中間的二進制文件,隨后生成獨特的虛機源碼保護執(zhí)行環(huán)境和只能在該環(huán)境下執(zhí)行的運行程序。

虛機源碼保護會在App內部隔離出獨立的執(zhí)行環(huán)境,該核心代碼的運行程序在此獨立的執(zhí)行環(huán)境里運行。即便App本身被破解,這部分核心代碼仍然不可見。

undefined

(虛機源碼保護加固流程)

生成的虛機源碼保護擁有獨特的可變指令集,極大的提高了指令跟蹤、逆向分析的難度。同時,虛機源碼保護還提供了反調試能力和監(jiān)控能力。虛機源碼保護可以通過自身的探針感知到環(huán)境的變化,實時探測到外界對本環(huán)境的調試、注入等非正常執(zhí)行流程變化,將調試動作引入程序陷阱,并發(fā)出警報,進而進行實時更新,提高安全強度。

加固技術發(fā)展及其攻防對抗的更迭,伴隨著互聯網技術發(fā)展不斷升級,我們深信邪不能勝正,而虛機源碼保護加固作為當前領先的加固技術,在未來很長一段時間,能夠為App提供足夠強度的保護,為企業(yè)和開發(fā)者的業(yè)務發(fā)展保駕護航。

原文地址: https://www.dingxiang-inc.com/blog/post/2

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

友情鏈接更多精彩內容