本發(fā)明屬于信息安全領(lǐng)域，涉及移動應用軟件安全保護技術(shù)，具體涉及一種Android平臺下基于Dex加載器的一種改進優(yōu)化的應用軟件加固保護方法。

背景技術(shù)：

Android應用有Java語言編譯而成，而Java語言編譯成的二進制代碼后很容易被反編譯，代碼的安全性受到極大威脅，同時也為盜版提供了可乘之機。攻擊者下載合法應用，通過反編譯修改配置文件甚至植入惡意代碼，然后利用打包工具對應用進行重打包，最后使用自己的密鑰對應用進行重簽名并發(fā)布到應用市場。對于普通手機用戶，這種重打包的應用很難辨別，盜版或惡意應用很容易被安裝到用戶手機上，任意獲取用戶隱私信息，偷跑流量，惡意扣費等，給用戶帶了很大的損失。

針對這種惡意攻擊，傳統(tǒng)的防護措施如代碼混淆，數(shù)字水印技術(shù)，Android簽名機制等保護方式安全性非常有限。無論采用上述哪種方式，最終攻擊者都能在適當?shù)貢r機獲取到程序源碼，攻擊者可以使用靜態(tài)的分析工具或者將應用程序置于動態(tài)分析的模擬器中獲得代碼，這些保護措施的效果不佳。

Android應用加固是針對應用重打包的有效防范措施，應用加固是對Android應用程序源代碼的加密保護過程，通過利用Android開放的加載機制，動態(tài)啟動被加密后的代碼文件。通過加固的應用，源代碼以密文方式保存在Apk中，攻擊者在不知道加密算法和密鑰的前提下，無從直接獲取源碼。到目前為止，Android應用加固已經(jīng)有了一定的技術(shù)積累，但是隨著Android系統(tǒng)版本一直在迭代更新，現(xiàn)有的Android加固技術(shù)也面臨著一些挑戰(zhàn)：加固應用的啟動速度有待優(yōu)化；加固流程效率低下有待提升；加固程序自身的安全尚未得到重視等。

傳統(tǒng)的基于Dex加載器(DexClassLoader)的加固技術(shù)是近期使用最廣泛的加固方法，該方法需要將Apk中的classes.dex文件加密隱藏，將原Dex文件保存在assets文件夾中，assets文件夾中可以存放不限類型的文件，這樣能避免Dex嵌入加固技術(shù)對Art虛擬機加固不兼容的問題。如圖3所示，其加固流程大致如下：

1)使用反編譯軟件對目標Apk進行解包，獲取其中的classes.dex文件以及AndroidManifest.xml；

2)加密壓縮classes.dex文件，存放到assets目錄中；

3)將自定義的DexClassLoader編譯成殼classes.dex文件放在應用的根目錄中以替換目標應用的classes.dex；

4)修改Manifest，將程序入口改為殼程序；

5)打包簽名發(fā)布。

相應的，如圖4所示，系統(tǒng)運行加固后的流程分析如下：

1)系統(tǒng)運行時首先從Manifest文件中讀取程序入口，加載并啟動殼程序；

2)殼程序?qū)ssets中的密文Dex進行解密和完整性校驗；

3)殼程序動態(tài)加載解密生成的Dex明文文件，將程序的控制權(quán)交還給原程序。

技術(shù)實現(xiàn)要素：

為解決上述技術(shù)問題，本發(fā)明提供了一種基于Dex加載器的Android應用軟件加固保護方法，其包括以下步驟：

S1：解包原應用Apk文件，得到AndroidManifest.xml，classes.dex文件以及assets，META_INF，libs文件夾；

S2：生成隨機密鑰KEY，使用隨機密鑰KEY對Apk中的Dex文件使用128bit的AES算法加密，生成密文文件Reinforce.dex；

S3：將Reinforce.dex移動到在assets文件夾中保存，圖示刪除classes.dex明文文件；

S4:替換加密核心庫libcorn.so中Key密鑰區(qū)域，并將庫文件libcorn.so并保存在libs文件夾中；

S5:將殼源碼編譯成classes.dex文件，并將殼文件dex放在根目錄下替代原程序的classes.dex；

S6:將Manifest中程序入口修改為殼程序具體修改方法為：

a)<application>標簽下的android:name屬性值改為殼程序名稱；

b)建立標簽<meta-data>，在<meta-data>標簽下添加屬性android:name和android:value；

c)將android:name的值設置為APPLICATION_CLASS_NAME；后者的值設置為原<application>標簽下android:name屬性的值，若該原始值不存在，則取系統(tǒng)的缺省程序入口android.app.Application；若該原始值以“.”開頭，則在其前加上包名取完成路徑；

S7:刪除原apk簽名信息META-INF；

S8:用apktool打包文件夾，用自己的密鑰對新打包的apk進行簽名；

經(jīng)過以上的步驟，加固完畢，生成了一個全新的apk文件，加固后的應用和加固前的應用相比，asssts文件家中多了加密Dex文件，classes.dex是替換的殼文件，并且在lib庫中多了用于加載解密的核心so庫。

較佳地，還包括以下步驟：

S9:加固殼應用啟動，殼程序中加載核心so庫文件libcorn.so；

S10:從libcorn.so的密鑰區(qū)域恢復出密鑰KEY。

S11：調(diào)用libcorn.so的解密函數(shù)解密assets文件夾中的Dex文件到內(nèi)存，得到一個字節(jié)數(shù)組byte[]；

S12：使用自定義的Native層的DexClassLoader調(diào)用libdvm.so中接口Dalvik_dalvik_system_DexFile_openDexFile_bytearray()裝載上一步得到的byte數(shù)組并得到一個標記dex的cookie值；

S13：調(diào)用libdvm.so中接口

Dalvik_dalvik_system_DexFile_defineClassNative，根據(jù)上一步得到的cookie值加載原程序；

S14：將系統(tǒng)中運行的應用信息狀態(tài)信息替換為原應用，將程序的控制全交還給原應用，實現(xiàn)原應用程序的正常啟動。

本發(fā)明具有以下有益效果：

本發(fā)明提供的基于Dex加載器的Android應用軟件加固保護方法在加固后的dex結(jié)構(gòu)和傳統(tǒng)dex文件的結(jié)構(gòu)完全不同，不能被成功反編譯為具有可讀性的源文件。加固方案成功保護了關(guān)鍵數(shù)據(jù)的機密性，起到了防反編譯的效果。利用ZjDroid脫殼工具對加固后的apk進行脫殼操作，不能獲取到任何原apk的源碼文件和dex碎片，說明我們的內(nèi)存加載過程對防止java層Hook有很好的效果，同時也避免了dex明文出現(xiàn)在磁盤上被攻擊者劫取。相對于傳統(tǒng)的磁盤加載方式安全性有很大的提高。

針對Android的不同版本，不同的系統(tǒng)架構(gòu)對傳統(tǒng)dex加固方式和本文實現(xiàn)的加固方式做一個橫向的對比。傳統(tǒng)磁盤加載由于各種因素，只能在一定時間段完成加固任務，在Android5.0系統(tǒng)以后，傳統(tǒng)的方法將徹底失效。采用我們提出的dex加載方式加固的應用，能在當前所有主流版本，主流架構(gòu)的終端上正常運行，適配性強。

此外經(jīng)過本文實現(xiàn)的加固處理后的應用啟動時間明顯比傳統(tǒng)加固處理后應用的啟動時間要短。相比原應用，加載時間增量完全在可接受的范圍內(nèi)。加載效率相比傳統(tǒng)加固方法有明顯提高。

當然，實施本發(fā)明的任一產(chǎn)品并不一定需要同時達到以上所述的所有優(yōu)點。

附圖說明

為了更清楚地說明本發(fā)明實施例的技術(shù)方案，下面將對實施例描述所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為傳統(tǒng)DexClassLoader加固流程圖；

圖2為傳統(tǒng)DexClassLoader加固程序執(zhí)行流程圖；

圖3為本發(fā)明實施例提供的加固流程示意圖；

圖4為本發(fā)明實施例提供的加固應用啟動流程示意圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其它實施例，都屬于本發(fā)明保護的范圍。

如圖1所示，本發(fā)明實施例提供了一種基于Dex加載器的Android應用軟件加固保護方法，其包括以下步驟：

S1：解包原應用Apk文件，得到AndroidManifest.xml，classes.dex文件以及assets，META_INF，libs文件夾；

S2：生成隨機密鑰KEY，使用隨機密鑰KEY對Apk中的Dex文件使用128bit的AES算法加密，生成密文文件Reinforce.dex；

S3：將Reinforce.dex移動到在assets文件夾中保存，圖示刪除classes.dex明文文件；

S4:替換加密核心庫libcorn.so中Key密鑰區(qū)域，并將庫文件libcorn.so并保存在libs文件夾中；

S5:將殼源碼編譯成classes.dex文件，并將殼文件dex放在根目錄下替代原程序的classes.dex；

S6:將Manifest中程序入口修改為殼程序具體修改方法為：

a)<application>標簽下的android:name屬性值改為殼程序名稱；

b)建立標簽<meta-data>，在<meta-data>標簽下添加屬性android:name和android:value；

c)將android:name的值設置為APPLICATION_CLASS_NAME；后者的值設置為原<application>標簽下android:name屬性的值，若該原始值不存在，則取系統(tǒng)的缺省程序入口android.app.Application；若該原始值以“.”開頭，則在其前加上包名取完成路徑；

S7:刪除原apk簽名信息META-INF；

S8:用apktool打包文件夾，用自己的密鑰對新打包的apk進行簽名；

經(jīng)過以上的步驟，加固完畢，生成了一個全新的apk文件，加固后的應用和加固前的應用相比，asssts文件家中多了加密Dex文件，classes.dex是替換的殼文件，并且在lib庫中多了用于加載解密的核心so庫。

如圖2所示，還包括以下步驟：

S9:加固殼應用啟動，殼程序中加載核心so庫文件libcorn.so；

S10:從libcorn.so的密鑰區(qū)域恢復出密鑰KEY。

S11：調(diào)用libcorn.so的解密函數(shù)解密assets文件夾中的Dex文件到內(nèi)存，得到一個字節(jié)數(shù)組byte[]；

S12：使用自定義的Native層的DexClassLoader調(diào)用libdvm.so中接口Dalvik_dalvik_system_DexFile_openDexFile_bytearray()裝載上一步得到的byte數(shù)組并得到一個標記dex的cookie值；

S13：調(diào)用libdvm.so中接口

Dalvik_dalvik_system_DexFile_defineClassNative，根據(jù)上一步得到的cookie值加載原程序；

S14：將系統(tǒng)中運行的應用信息狀態(tài)信息替換為原應用，將程序的控制全交還給原應用，實現(xiàn)原應用程序的正常啟動。

本發(fā)明提供的基于Dex加載器的Android應用軟件加固保護方法在加固后的dex結(jié)構(gòu)和傳統(tǒng)dex文件的結(jié)構(gòu)完全不同，不能被成功反編譯為具有可讀性的源文件。加固方案成功保護了關(guān)鍵數(shù)據(jù)的機密性，起到了防反編譯的效果。利用ZjDroid脫殼工具對加固后的apk進行脫殼操作，不能獲取到任何原apk的源碼文件和dex碎片，說明我們的內(nèi)存加載過程對防止java層Hook有很好的效果，同時也避免了dex明文出現(xiàn)在磁盤上被攻擊者劫取。相對于傳統(tǒng)的磁盤加載方式安全性有很大的提高。

針對Android的不同版本，不同的系統(tǒng)架構(gòu)對傳統(tǒng)dex加固方式和本文實現(xiàn)的加固方式做一個橫向的對比。傳統(tǒng)磁盤加載由于各種因素，只能在一定時間段完成加固任務，在Android5.0系統(tǒng)以后，傳統(tǒng)的方法將徹底失效。采用我們提出的dex加載方式加固的應用，能在當前所有主流版本，主流架構(gòu)的終端上正常運行，適配性強。

此外經(jīng)過本文實現(xiàn)的加固處理后的應用啟動時間明顯比傳統(tǒng)加固處理后應用的啟動時間要短。相比原應用，加載時間增量完全在可接受的范圍內(nèi)。加載效率相比傳統(tǒng)加固方法有明顯提高。

以上公開的本發(fā)明優(yōu)選實施例只是用于幫助闡述本發(fā)明。優(yōu)選實施例并沒有詳盡敘述所有的細節(jié)，也不限制該發(fā)明僅為所述的具體實施方式。顯然，根據(jù)本說明書的內(nèi)容，可作很多的修改和變化。本說明書選取并具體描述這些實施例，是為了更好地解釋本發(fā)明的原理和實際應用，從而使所屬技術(shù)領(lǐng)域技術(shù)人員能很好地理解和利用本發(fā)明。本發(fā)明僅受權(quán)利要求書及其全部范圍和等效物的限制。