AndroidAPP加固方案的研究

摘 ?要：Android應(yīng)用程序在未經(jīng)任何加固處理的情況下極容易受到反編譯攻擊，存在較大的安全隱患。APP加固技術(shù)為應(yīng)用程序提供了有效的防護措施，增加了反編譯的難度，本文針對目前常用的反編譯手段提出了一種APP加固方案，該方案首先針對需要保護的資源文件進行加密處理;然后針對DEX文件的反編譯，采用混淆代碼技術(shù)加固處理，針對二次打包，本文采用簽名校驗技術(shù)。實驗表明，本文提出的加固方案能夠有效地防患APK被反編譯，加大了二次打包的難度。

關(guān)鍵詞：APP反編譯;DEX加固;加殼保護;二次打包

中圖分類號：TP309.5 ? ? 文獻標(biāo)識碼：A

Abstract：Android applications without any reinforcement are extremely vulnerable to de-compilation attacks，with significant security risks.App reinforcement technology provides effective protection for applications and increases the difficulty of de-compilation.In this paper，an APP reinforcement scheme is proposed against the commonly used de-compilation methods.The scheme first encrypts the resource files to be protected;Then，for the DEX file recompilation，confusion code technology is used to reinforce the DEX file.For the secondary packaging，the signature verification technique is adopted in this paper.Experimental results show that the proposed reinforcement scheme can effectively prevent APK from being decompiled and thus increases the difficulty of secondary packaging.

Keywords：App de-compilation;DEX reinforcement;shell protection;secondary packing

1 ? 引言（Introduction）

Android程序在編譯后形成字節(jié)碼文件，經(jīng)過打包、優(yōu)化、簽名等工具處理后最終形成可發(fā)布的APK文件。然而，未經(jīng)加固處理的APK文件極容易被反編譯工具進行逆向工程處理，暴露程序的實現(xiàn)細節(jié)，甚至被植入惡意代碼[1]。Android APP加固技術(shù)能夠有效地防止程序被反編譯、破解、二次打包、注入等，提高程序的安全性，從而為維護知識版權(quán)增加了一道“防火墻”。

目前，Android APP加固技術(shù)[2]較多，常用的加固方法有混淆代碼、DEX加固、虛擬機加固、加密等。愛加密通過對APP進行漏洞分析并采用DEX加殼保護、內(nèi)存和資源文件等的保護技術(shù)能夠有效地防止APP被二次打包。NAGA·IN[3]通過推出的手機客戶端安全檢測控件為銀行、基金、券商等手機軟件提供了有效的安全保障。360加固保[4]、阿里聚通過簽名校驗、代碼加密壓縮、內(nèi)存動態(tài)跟蹤等技術(shù)為移動應(yīng)用提供專業(yè)性安全保護。本文在研究當(dāng)前各種加固技術(shù)的基礎(chǔ)上提出了一種Android APP加固方案，方案通過加密、混淆代碼、簽名校驗等多種方法對目標(biāo)代碼進行加固操作，經(jīng)實驗驗證，本文提出的加固方案能夠很好地對抗反編譯、二次打包、注入等攻擊。

2 ? APP反編譯概述（Overview of APP de-compilation）

2.1 ? Android APK結(jié)構(gòu)

APP反編譯無非是對Android應(yīng)用程序編譯打包后的APK進行逆向工程，然后分析APK的目錄結(jié)構(gòu)和應(yīng)用程序的行為，并篡改應(yīng)用程序代碼、注入惡意代碼。不同的應(yīng)用程序APK結(jié)構(gòu)不同，但每一個APK中都包含基本目錄結(jié)構(gòu)，也是逆向工程攻擊的目標(biāo)。基本目錄結(jié)構(gòu)如下：

（1）classes.dex文件。該文件是JAVA源碼經(jīng)JDK編譯和DEX優(yōu)化后的DEX字節(jié)碼文件，可以直接運行在Dalvik虛擬機上。DEX文件包括文件頭和文件主體兩部分，DEX文件頭主要包括校驗字段、簽名字段偏移地址和長度信息等，DEX文件的主體部分包括索引區(qū)和數(shù)據(jù)區(qū)。圖1是DEX文件的一個實例。

DEX文件的構(gòu)成如圖2所示。

（2）AndroidManifest.xml文件。該文件為應(yīng)用程序的配置文件，應(yīng)用程序建立時存在。配置文件描述了應(yīng)用程序的配置信息，如應(yīng)用的名稱、圖標(biāo)、版本、權(quán)限的授予、引用的庫信息等，在打包時配置文件經(jīng)過了壓縮。

（3）META-INF目錄。該目錄存放簽名文件，如CERT.RSA、CERT.SF和MANIFEST.MF。

（4）res目錄和assets目錄。這兩個目錄為應(yīng)用程序的資源文件目錄，目錄下的部分資源將被打包進APK中。

（5）resources.arsc文件。該文件為二進制資源文件的索引文件，程序運行時引用資源ID，通過該索引文件的映射找到對應(yīng)的資源。

2.2 ? 反編譯工具

當(dāng)前，網(wǎng)絡(luò)上有許多反編譯之類的免費工具，Android APP反編譯常用的工具有：

（1）APKTool：APKTool[5]是GOOGLE提供的APK編譯工具，利用該工具能夠獲取APK中的圖片、布局等資源文件和目錄結(jié)構(gòu)。

（2）dex2jar[6]：該工具能夠?qū)PK中的classes.dex文件轉(zhuǎn)換成JAR文件。

（3）JD-GUI：是反編譯工具之一，利用該工具能夠查看dex2jar生成的JAR文件，顯示反編譯后的JAVA源代碼。

利用以上三個工具能夠輕松地將APK反編譯成JAVA源代碼，其實現(xiàn)步驟如下：

步驟一：利用APKTool工具對APK實施第一輪反編譯，反編譯后得到APK的目錄結(jié)構(gòu)及資源文件。

步驟二：利用dex2jar工具將APK目錄下的classes.dex文件轉(zhuǎn)換成JAR文件，生成的JAR文件無法直接查看。

步驟三：利用JD-GUI工具查看將DEX文件轉(zhuǎn)換后的JAR文件，源代碼直接在該工具下查看，反編譯結(jié)束。

3 ? 反編譯分析（Analysis of de-compilation）

針對以上反編譯工具的使用我們不難發(fā)現(xiàn)，沒有經(jīng)過加固的APK極容易被反編譯，應(yīng)用程序代碼的安全性存在巨大的隱患。下面本文分析隱患存在的原因：

（1）APK本身存在一定的開放性[7]。我們將APK文件的后綴名手工改成壓縮文件的后綴名，如.rar或.zip，其目錄結(jié)構(gòu)完全暴露出來。雖然部分文件如AndroidManifest.xml、classes.dex等文件經(jīng)過了編譯，但其目錄下的部分資源文件卻是原封不動地被打包進APK，如res、assets目錄下的資源文件。

（2）JAVA字節(jié)碼易被反編譯[8]。JAVA代碼經(jīng)編譯后形成字節(jié)碼保存在class文件中，而字節(jié)碼本身是一種中間代碼，是解析后的帶有豐富語義的跨平臺編碼，這些語義字節(jié)碼直接表達了程序的行為和動機，經(jīng)過極為簡單的反編譯就能破解其中的語義信息。

（3）Android APP的簽名機制能夠被偽造[9]。在JDK 1.7版本前APK的簽名能夠輕易地被偽造，從而將反編譯后的文件進行二次打包。雖然在后來的版本中使用原APK的簽名進行二次打包是無效的，但二次打包工具卻能夠為反編譯后的文件進行重新簽名，從而誕生了一個全新的偽造的應(yīng)用程序。

4 ? 加固方案（Reinforcement scheme）

經(jīng)過對反編譯過程進行分析我們不難發(fā)現(xiàn)，如果需要提高應(yīng)用程序的安全性，增加APK的反編譯難度，就必須針對反編譯使用的手段采取相應(yīng)的措施來加固APK。本文在研究反編譯技術(shù)的基礎(chǔ)上提出一種加固Android APP的方案，該方案增加了反編譯的難度，能夠有效地防止APK被反編譯。

4.1 ? 加固方案描述

針對反編譯工具能夠輕易地提取APK中的資源文件，本文提出抽取需要保護的資源文件，并對其進行加密處理;針對DEX文件的反編譯，本文采用混淆代碼加固處理;針對二次打包，本文采用簽名校驗技術(shù)防患重簽名，從而加大了二次打包的難度。加固方案的基本操作流程如圖3所示。

4.2 ? 加固方案的實現(xiàn)

本方案的實現(xiàn)分三個步驟進行：

第一步：對資源文件進行加密、加殼處理。處理過程如下 ：

（1）將APK文件的后綴名改成.zip或.rar，并將修改后的APK文件解壓至一文件下。

（2）抽取需要保護的資源文件。編寫JAVA文件讀取程序，由文件讀取程序以文件流方式讀取需要保護的資源文件。

（3）對抽取的文件采用加密處理，并隱藏加密文件。在文件讀取的過程中采用MD5加密算法對文件流進行加密處理，并設(shè)置文件的屬性為隱藏。

（4）編寫資源解密恢復(fù)程序，并將代碼放置Application類的入口。在Application類的入口處編寫MD5解密算法，在程序正式執(zhí)行前調(diào)用解密算法，恢復(fù)加密的資源文件，以保證程序能夠正常訪問資源文件。

經(jīng)過以上步驟處理，APK中的資源文件已經(jīng)被加密，反編譯工具得到的將是加密后的資源文件。而APK在正式執(zhí)行前已經(jīng)調(diào)用解密算法恢復(fù)了被加密的資源文件，加密方案并不影響程序?qū)Y源的正常訪問。

第二步：對classes.dex進行代碼混淆加固處理。處理過程如下：

（1）利用反編譯工具對classes.dex文件實施反編譯。常用的反編譯工具dex2jar和JD-GUI能夠輕松地對DEX文件進行反編譯，反編譯后生成jar文件，從JD-GUI工具中能夠查看該jar文件中的源碼文件。以新建一個“HelloWorld”應(yīng)用程序為例，將該程序APK中的classes.dex文件經(jīng)反編譯后在JD-GUI中打開，我們能看到，未經(jīng)代碼混淆處理的APK經(jīng)反編譯后，其源代碼暴露無遺，圖4是“HelloWorld”應(yīng)用程序經(jīng)反編譯后的結(jié)果。

（2）利用ProGuard工具對反編譯后的應(yīng)用程序?qū)嵤┐a混淆。在Android SDK中集成了一個ProGuard免費工具，也可使用其他版本的ProGuard工具，利用該工具可以對反編譯后的jar文件實施代碼混淆。ProGuard的執(zhí)行過程由六個步驟組成：

第一步：輸入：將原DEX文件反編譯后的jar文件作為輸入值。

第二步：壓縮：檢測并移除代碼中無用的類、字段、方法等。

第三步：優(yōu)化：移除無用指令，對字節(jié)碼進行優(yōu)化。

第四步：混淆：使用a、b、c這樣的簡短字母對類、字段和方法進行重命名。

第五步：預(yù)檢：在Java平臺上對處理后的代碼進行預(yù)檢，確保加載的class文件是可執(zhí)行的。

第六步：輸出：最后將混淆后的代碼以jar文件形式輸出。

ProGuard工具執(zhí)行過程如圖5所示。

第七步：重新打包和簽名。處理過程如下：

（1）新建文件夾，將反編譯后的所有工程文件夾和文件放置在該文件夾下。

（2）利用打包工具生成目標(biāo)APK，并利用重簽名工具對目標(biāo)APK實施重簽名。打包工具可以使用apktool，重簽名工具可以使用signapk工具。

5 ? 實驗驗證（Experimental verification）

為了驗證本方案是否可行，本文以未經(jīng)任何加固處理的APK為實驗對象，采用本方案提供的操作步驟，對實驗對象實施加固處理。

（1）實驗?zāi)康?/p>

通過方案提供的操作步驟驗證采用本方案能否對目標(biāo)APK實施加固處理，并通過對加固處理后的APK實施反編譯，驗證反編譯能否成功。

（2）實驗預(yù)期結(jié)果

如果對加固后的APK實施反編譯不能成功，表明本方案的加固操作能夠有效地防患APK被反編譯，加大了二次打包的難度。

（3）實驗過程

本實驗以名為“Helpme.apk”的APK為實驗對象，該APK未經(jīng)任何加固處理，其源代碼目錄結(jié)構(gòu)如圖6所示。

為了對APK中的需要保護的資源文件進行加密處理，本文選擇APK中的圖片資源作為重要的保護資源，并對其實施MD5加密處理。加密過程調(diào)用事先編寫好的方法，以其中一張圖片“s4.png”為例，加密前后對比的結(jié)果如圖7所示。

接下來利用反編譯工具dex2jar對classes.dex文件實施反編譯。在cmd命令窗口定位到dex2jar所在的文件夾，并輸入如下命令：

d2j-dex2jar.bat classes.dex

命令執(zhí)行完畢后在dex2jar文件夾下新生成一個classes-dex2jar.jar文件，該文件為反編譯后生成的壓縮文件，不能直接打開，可以利用JD-GUI工具查看該文件的目錄結(jié)構(gòu)和文件，JD-GUI工具下查看的目錄結(jié)構(gòu)如圖8所示。

下面利用ProGuard工具對反編譯后的jar文件實施代碼混淆，為了代碼混淆的實施能夠順利進行，并且能夠看到混淆后的結(jié)果，在實施混淆之前需要對相關(guān)參數(shù)進行設(shè)置。

支持庫參數(shù)：添加三項支持庫，即：rt.jar、cocos2d-android.jar和android.jar。

輸出參數(shù)：設(shè)置輸入文件為classes-dex2jar_pro.jar。

利用ProGuard工具實施代碼混淆的結(jié)果如圖9所示。

從圖8和圖9的對比可以看出，實施代碼混淆后的目錄結(jié)構(gòu)發(fā)生了變化，原目錄結(jié)構(gòu)下的文件被不能表達任何語義的簡短字母代替，源代碼中的類、字段和方法等也被簡短字母代替，從而增加了反編譯的難度。

雖然我們對DEX文件實施了代碼混淆，但利用相關(guān)工具依然能夠?qū)嵤┐a混淆后的DEX文件實施二次反編譯，為此，本文利用signapk工具進行簽名校驗，由于篇幅所限，本文不再對簽名校驗的過程做詳細說明。

本文最后將加密后的資源文件和代碼混淆后的文件進行重新打包，并使用簽名校驗技術(shù)實施重簽名，將新打包的APK再次實施反編譯，最后實驗結(jié)果表明，反編譯過程出現(xiàn)錯誤，由此證明了本文提出的APP加固方案能夠有效地防患APK被反編譯，加大了二次打包的難度。再次對加固后的APK文件實施反編譯實驗結(jié)果如圖10所示。

6 ? 結(jié)論（Conclusion）

本文系統(tǒng)地介紹了一種Android APP加固方案，方案為了對APP中的資源進行有效的保護，采用了加密方式對重要資源進行加密處理，為了防止DEX文件被反編譯，采用了混淆代碼技術(shù)加固處理，為了防止APK被二次打包，采用了簽名校驗技術(shù)。最后通過實驗驗證了本方案的可行性。

參考文獻（References）

[1] 吳敬征，武延軍，武志飛，等.基于有向信息流的Android隱私泄露類惡意應(yīng)用檢測方法[J].中國科學(xué)院大學(xué)學(xué)報，2015，32（06）：807-815.

[2] 宋言言，羅森林，尚海，等.函數(shù)Native化的Android APP加固方法[J].浙江大學(xué)學(xué)報（工學(xué)版），2019，53（03）：555-562.

[3] 梆梆安全.梆梆加固[EB/OL].http：//blog.csdn.net/justfwd/article/dct-ails/51164281，2018-02-10.

[4] 趙躍華，劉佳.安卓APP安全加固系統(tǒng)的分析與設(shè)計[J].計算機工程，2018，44（02）：187-192.

[5] 鄭興生.Android應(yīng)用程序反編譯工具研究與設(shè)計[D].北京理工大學(xué)，2016.

[6] 梁丹.基于動態(tài)字節(jié)碼注入的Android沙盒模型[D].上海交通大學(xué)，2015.

[7] 章宗美，桂盛霖，任飛.基于N-gram的Android惡意檢測[J].計算機科學(xué)，2019，46（02）：145-151.

[8] 劉奧，過辰楷，王偉靜，等.Android應(yīng)用Activity啟動環(huán)研究[J/OL].計算機學(xué)報，2019：1-18.

[9] 汪潤，唐奔宵，王麗娜.DroidFAR：一種基于程序語義的Android重打包應(yīng)用抗混淆檢測方法[J].武漢大學(xué)學(xué)報（理學(xué)版），2018，64（05）：407-414.

作者簡介：

彭守鎮(zhèn)（1979-），男，碩士，講師.研究領(lǐng)域：計算機應(yīng)用技術(shù)，信息安全，軟件技術(shù).