張建新

摘 要： 通過(guò)加密dex文件和SO庫(kù)文件的方法可以很好地保護(hù)安卓平臺(tái)軟件的安全性，但是將密鑰信息保留在本地文件又將留下安全隱患。為解決這一問(wèn)題，本文提出不將關(guān)鍵信息硬編碼于程序中，而是置于遠(yuǎn)程服務(wù)器，通過(guò)與遠(yuǎn)程服務(wù)通信進(jìn)行關(guān)鍵信息的確認(rèn)，從而達(dá)到保護(hù)安卓軟件的目的。試驗(yàn)結(jié)果表明，該方法可以有效地保護(hù)安卓軟件的安全性，具有較高的可靠性。

關(guān)鍵詞： 安卓軟件安全； 遠(yuǎn)程校驗(yàn)； 加殼技術(shù)； 軟件加密； AES算法

中圖分類(lèi)號(hào)：TP393 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：1006-8228（2017）05-30-04

An Android software protection scheme based on remote verification

Zhang Jianxin

（College of software，North university of China， Taiyuan， Shanxi 030051， China）

Abstract： Encrypting DEX files and SO library files can be a good way to protect the security of Android software， but the key information will remain in the local file and will leave a security risk. In order to solve this problem， this paper proposes that the key information is not hard coded in the program， but is placed on the remote server， and the critical information is confirmed by communicating with the remote service， to achieve the purpose of protecting Android software. The experimental results show that this method can effectively protect the security of Android software and has high reliability.

Key words： Android software security； remote verification； packer technology； software encryption； AES algorithm

0 引言

安卓系統(tǒng)占據(jù)了智能終端市場(chǎng)接近90%占有率[1]，它的開(kāi)源和內(nèi)核的可移植性，既可以吸引愛(ài)好者的關(guān)注也給不法分子留下了機(jī)會(huì)。攻擊者可以利用各種手段對(duì)原始應(yīng)用進(jìn)行破解和篡改，隨著越來(lái)越多的受害者出現(xiàn)，人們開(kāi)始重視安卓平臺(tái)應(yīng)用軟件的保護(hù)。

文獻(xiàn)[2]闡述了安卓各個(gè)層面的細(xì)節(jié)和攻擊方法。文獻(xiàn)[3-4]通過(guò)自定義加載的方法實(shí)現(xiàn)在內(nèi)存中加載核心代碼（SMC代碼字修改）。文獻(xiàn)[5]在設(shè)計(jì)安卓代碼保護(hù)方案時(shí)將MVC的概念引入到方案的設(shè)計(jì)中。文獻(xiàn)[6-8]提出的代碼保護(hù)方法都主要依賴于加密和加殼技術(shù)。文獻(xiàn)[9]是比較有代表性的一種方案，它通過(guò)AES加密算法加密DEX文件并將解密功能放到“傀儡class”文件中來(lái)增強(qiáng)其保密信息的安全性。但是上述方案在加密算法的選擇或者密鑰信息的保護(hù)方面都有漏洞。所以本文采用了一種文件保護(hù)和和遠(yuǎn)程校驗(yàn)相結(jié)合的安卓軟件保護(hù)方案。

1 方案設(shè)計(jì)思路

本文提出一種基于遠(yuǎn)程校驗(yàn)的安卓軟件保護(hù)方案，同時(shí)也用到了關(guān)鍵文件變形和加密的技術(shù)。

在apk包的所有文件中，最重要的是classes.dex文件。了解smali語(yǔ)法的人可以通過(guò)反編譯和靜態(tài)分析技術(shù)來(lái)破解軟件。除了dex文件之外 SO文件也是攻擊的目標(biāo)之一，本文對(duì)SO文件也進(jìn)行相應(yīng)的處理。

對(duì)dex文件和so文件進(jìn)行變形和加密，這樣對(duì)關(guān)鍵文件進(jìn)行保護(hù)，具體的功能模塊示意圖如圖1。

加密模塊通過(guò)AES算法加密需要保護(hù)的文件，并取得需要保護(hù)的信息部署到遠(yuǎn)程服務(wù)器，然后再重新打包；解密模塊執(zhí)行的時(shí)候通過(guò)殼程序調(diào)用遠(yuǎn)程服務(wù)器上的固定方法完成完整性校驗(yàn)，然后返回密鑰信息對(duì)文件進(jìn)行解密，再執(zhí)行正常流程。本方案采用的方法雖然會(huì)在遠(yuǎn)程通信中耗費(fèi)一定的資源，主要是對(duì)網(wǎng)絡(luò)傳輸?shù)囊蟊容^高，但其他方面都能做到用最少的資源最大限度地增加軟件的安全性。

2 關(guān)鍵技術(shù)闡述

保護(hù)方案主要技術(shù)點(diǎn)包括dex文件保護(hù)技術(shù)、SO文件保護(hù)技術(shù)和遠(yuǎn)程服務(wù)實(shí)現(xiàn)技術(shù)。

2.1 dex文件保護(hù)

本文提出一種自定義代碼替換集的代碼混淆方法用于加密前處理dex文件。自定義代碼替換集可以由軟件使用者自己定義，自己掌控需要替換的代碼及相應(yīng)位置，而替換的規(guī)則只有開(kāi)發(fā)者知道，這就大大增加了分析者的破解難度，而且恢復(fù)替換所消耗的資源也少于大規(guī)模的替換，在資源的占用方面有優(yōu)勢(shì)，主要的工作難度都集中在前期自定義階段。這就使得分析人員即使得到了dex文件也不能充分的了解其中代碼的意義，無(wú)法順利的進(jìn)行分析。具體實(shí)現(xiàn)中可以把代碼替換集置于遠(yuǎn)程服務(wù)器中，使規(guī)則對(duì)程序透明化。當(dāng)然，為了進(jìn)一步增加獲得dex文件的難度，在打包之前還需要通過(guò)加密等其他手段對(duì)其進(jìn)行處理。具體實(shí)現(xiàn)流程如圖2所示。

2.2 SO文件保護(hù)

以現(xiàn)行的分析技術(shù)，如果我們將SO文件直接放在jni目錄下打包發(fā)出，攻擊者可以輕而易舉地破解開(kāi)發(fā)人員寫(xiě)出來(lái)的代碼。本文在研究前人加固方案的基礎(chǔ)上，采用一種核心文件替代的方法。通過(guò)分析java調(diào)用動(dòng)態(tài)鏈接庫(kù)的函數(shù)System.loadLibrary（）發(fā)現(xiàn)接口中調(diào)用本地庫(kù)的關(guān)鍵語(yǔ)句為nativeLoad（name，loader，ldLibraryPath），該方法執(zhí)行的時(shí)候調(diào)用路徑為ldLibraryPath下名字為name的SO文件，由此系統(tǒng)可以自己定義一個(gè)核心SO文件，對(duì)其他SO文件進(jìn)行統(tǒng)一處理，而動(dòng)態(tài)鏈接庫(kù)中的主要實(shí)現(xiàn)邏輯文件則統(tǒng)一置于文件夾中并對(duì)其進(jìn)行變形操作，最后將它放入assets文件夾。密鑰信息并不在本地文件中，而保存在遠(yuǎn)程服務(wù)器中。具體處理與運(yùn)行流程如圖3所示。

2.3 Axis2簡(jiǎn)介

本文基于遠(yuǎn)程獲取校驗(yàn)信息和密鑰信息的功能將通過(guò)Axis2引擎來(lái)實(shí)現(xiàn)。

Apache Axis2項(xiàng)目是一個(gè)基于java的包括服務(wù)端和客戶端的webservice框架。它適合輕量級(jí)的數(shù)據(jù)處理。客戶端可以通過(guò)Axis2接口調(diào)用特定服務(wù)端發(fā)布出來(lái)的指定方法來(lái)實(shí)現(xiàn)某些特定的功能，用戶只需要發(fā)送請(qǐng)求的參數(shù)，它就可以返回最后的結(jié)果。

在手機(jī)端發(fā)送密鑰或者校驗(yàn)請(qǐng)求到服務(wù)端，服務(wù)端根據(jù)請(qǐng)求信息找到對(duì)應(yīng)的方法處理數(shù)據(jù)并返回結(jié)果。服務(wù)器端的主要代碼非常簡(jiǎn)單，就是通過(guò)soap消息傳遞當(dāng)前META-INF文件夾簽名或者直接發(fā)送需要的密鑰請(qǐng)求到事先部署到服務(wù)器配置文件中的初始簽名參數(shù)對(duì)比，如果判斷失敗則返回失敗指令，讓App停止運(yùn)行，代碼如表1所示，客戶端發(fā)送請(qǐng)求代碼如表2所示。

代碼中，RPCServiceClient對(duì)象是可以處理發(fā)送與接收數(shù)據(jù)業(yè)務(wù)的專用對(duì)象；Options對(duì)象用來(lái)攜帶可選參數(shù)；EndpointReference對(duì)象裝載服務(wù)端的URL；Object數(shù)組用來(lái)存放需要校驗(yàn)的數(shù)據(jù)，即META-INF文件夾的數(shù)字簽名；Class數(shù)組用來(lái)指定返回值數(shù)據(jù)對(duì)應(yīng)的類(lèi)；Qname對(duì)象限定要調(diào)用的方法和WSDL文件的命名空間。最后通過(guò)業(yè)務(wù)處理對(duì)象調(diào)用接口中的invokeBlocking（）方法實(shí)現(xiàn)與服務(wù)端的通信。

3 方案的實(shí)現(xiàn)流程

本文提出的方案包括PC端處理和遠(yuǎn)程服務(wù)。PC端處理用到代碼集替換、加殼技術(shù)、MD5算法提取哈希值等。本方案將校驗(yàn)信息和加密算法的密鑰都放在遠(yuǎn)程服務(wù)端，運(yùn)行的過(guò)程中通過(guò)殼程序的指令和遠(yuǎn)程服務(wù)端進(jìn)行通信，最終確定軟件是否安全。

3.1 PC端處理

文件保護(hù)主要工作包括代碼集標(biāo)識(shí)符的定義和具體代碼集的選取以及加密功能的實(shí)現(xiàn)。代碼集標(biāo)識(shí)符的定義需要遵循一定的原則，不能使用Dalvik字節(jié)碼的語(yǔ)法指令關(guān)鍵字，也不能選用能夠見(jiàn)文知義的標(biāo)識(shí)符。系統(tǒng)根據(jù)用戶輸入的標(biāo)識(shí)符和代碼集位置，在dex文件中替換相應(yīng)的代碼并創(chuàng)建惟一標(biāo)識(shí)，將一一對(duì)應(yīng)的標(biāo)識(shí)和代碼存儲(chǔ)在一個(gè)資源文件中生成代碼集，然后用AES算法對(duì)替換后的dex文件進(jìn)行加密并將密鑰保留備用。

當(dāng)程序中存在jni代碼時(shí)，apk包中有一個(gè)lib文件夾用來(lái)存放所有的庫(kù)文件，核心文件替換會(huì)先將所有的SO文件用AES算法加密，產(chǎn)生的密鑰會(huì)部署在遠(yuǎn)程服務(wù)端供運(yùn)行時(shí)調(diào)用。然后將lib文件夾壓縮并修改文件名和擴(kuò)展名來(lái)混淆破解者的判斷，最后將其放在資源文件目錄下。為了執(zhí)行調(diào)用，在原位置創(chuàng)建一個(gè)同名的lib文件夾并在里面編寫(xiě)一個(gè)恢復(fù)源文件并執(zhí)行具體調(diào)用的”代理文件”，最后在殼程序中調(diào)用該代理文件處理具體的操作。

3.2 遠(yuǎn)程校驗(yàn)

綜合上述可以知道遠(yuǎn)程服務(wù)端的實(shí)現(xiàn)機(jī)制，在具體的實(shí)現(xiàn)中，校驗(yàn)META-INF完整性的功能可以在整個(gè)安卓應(yīng)用的任何流程之前均執(zhí)行調(diào)用，此功能與前面的文件加密處在軟件運(yùn)行的一前一后進(jìn)行交叉保護(hù)，使得保護(hù)方案更加可靠。在性能方面，該手段對(duì)于資源的要求并不高，整個(gè)過(guò)程中只需要傳送一個(gè)字符串接收一個(gè)字符串，或者發(fā)送一個(gè)請(qǐng)求獲取一個(gè)字符串，對(duì)程序性能的影響基本可以忽略不計(jì)，只要在網(wǎng)絡(luò)暢通的情況下均可執(zhí)行。

4 實(shí)驗(yàn)驗(yàn)證與分析

為了驗(yàn)證本方案的有效性和實(shí)用性，在win7系統(tǒng)下對(duì)本文實(shí)現(xiàn)的系統(tǒng)Xpro v1.0進(jìn)行效果測(cè)試和功能對(duì)比實(shí)驗(yàn)。

4.1 方案效果測(cè)試

系統(tǒng)加固處理發(fā)生在PC端，運(yùn)行環(huán)境采用win7旗艦版系統(tǒng)和常用的反編譯工具。首先進(jìn)行整體的運(yùn)行，打開(kāi)該系統(tǒng)，選擇源文件路徑，把功能模塊都選中，并設(shè)置好替換代碼集，點(diǎn)擊開(kāi)始，執(zhí)行結(jié)束后界面如圖4所示。

本文從不同的應(yīng)用市場(chǎng)的200多個(gè)應(yīng)用中隨機(jī)篩選出了50個(gè)沒(méi)有經(jīng)過(guò)外部加固手段處理的，具有代表性的應(yīng)用，通過(guò)本系統(tǒng)的處理之后，再進(jìn)行安裝和使用。結(jié)果發(fā)現(xiàn)，它的正常使用率達(dá)到93%，并且不受Android系統(tǒng)版本的影響，在不同的版本上測(cè)試，結(jié)果基本一致。剩余的7%，經(jīng)過(guò)進(jìn)一步分析發(fā)現(xiàn)是程序內(nèi)部已經(jīng)存在簽名校驗(yàn)機(jī)制或其他的代碼保護(hù)機(jī)制，所以導(dǎo)致了二次打包之后無(wú)法運(yùn)行，去除這部分之后，用自己新開(kāi)發(fā)出來(lái)的測(cè)試程序去測(cè)，可用率都達(dá)到了100%?？梢?jiàn)本系統(tǒng)是一個(gè)很可靠的加固系統(tǒng)。

4.2 運(yùn)行效率分析

本系統(tǒng)對(duì)空間的消耗在一個(gè)正常的范圍內(nèi)，雖然會(huì)隨著原始文件的大小變化出現(xiàn)小的波動(dòng)但并不會(huì)出現(xiàn)加固后容量超過(guò)應(yīng)用本身的狀況出現(xiàn)，這是由加固的手段決定的，所以，本文只對(duì)加固后應(yīng)用啟動(dòng)時(shí)間和未加固時(shí)的啟動(dòng)時(shí)間做一個(gè)統(tǒng)計(jì)分析。作為對(duì)比本文還使用了網(wǎng)易易盾的免費(fèi)試用版和應(yīng)用樂(lè)固的體驗(yàn)版以及本文的Xpro V1.0版分別對(duì)相同的應(yīng)用進(jìn)行加固，并記錄其啟動(dòng)時(shí)間。

找出文件大小處于不同區(qū)間的十個(gè)應(yīng)用的apk文件，分別在不加固、本系統(tǒng)加固和兩個(gè)免費(fèi)的商業(yè)加固系統(tǒng)試用版本進(jìn)行加固和啟動(dòng)，記錄應(yīng)用啟動(dòng)時(shí)間，統(tǒng)計(jì)分析結(jié)果如圖5所示。

從圖5中可以看出，無(wú)論是哪種加固系統(tǒng)處理之后的apk啟動(dòng)時(shí)間都會(huì)有一定的延長(zhǎng)，這是因?yàn)楸Ｗo(hù)措施在正式的源程序加載之前需要一定的時(shí)間和資源來(lái)處理前面的加載工作，在本系統(tǒng)中，無(wú)論是對(duì)dex文件的解密還是SO文件恢復(fù)，這一系列操作都需要占用一定時(shí)間。不過(guò)，通過(guò)延長(zhǎng)一定的初始化時(shí)間，仍在用戶可以接受的范圍之內(nèi)的話就是值得的。本系統(tǒng)的效率雖然達(dá)不到商業(yè)加固應(yīng)用的頂級(jí)水平，但跟它們的試用版本在效率方面也在伯仲之間，很好的完成了加固的任務(wù)。

5 結(jié)束語(yǔ)

本文提出基于遠(yuǎn)程校驗(yàn)和本地關(guān)鍵文件加密的安卓軟件保護(hù)方案，很好的平衡了安全性和軟件工作效率之間的矛盾，將校驗(yàn)及解密信息存放于遠(yuǎn)程服務(wù)器中，并選擇了效率及安全性都很優(yōu)秀的加密算法。實(shí)驗(yàn)證明，本方案能夠有效抵抗靜態(tài)，有效地保護(hù)了APK文件，在實(shí)際的應(yīng)用中，本方案往往會(huì)與其他保護(hù)手段結(jié)合使用，使其發(fā)揮更大的作用。本方案的不足之處是未能考慮到遠(yuǎn)程服務(wù)器交互過(guò)程中的信息安全問(wèn)題及遠(yuǎn)程服務(wù)器本身的安全問(wèn)題，這也將是下一步優(yōu)化的方向。

參考文獻(xiàn)（References）：

[1] 騰訊移動(dòng)安全實(shí)驗(yàn)室.騰訊安全實(shí)驗(yàn)室2016年上半年手機(jī)安全報(bào)告，2016.7.

[2] 豐生強(qiáng).Android軟件安全與逆向分析[M].人民郵電出版社，2013.

[3] 董航.移動(dòng)應(yīng)用程序檢測(cè)與防護(hù)技術(shù)研究[D].北京郵電大學(xué)博士學(xué)位論文，2014.

[4] 張曉，李林，許家樂(lè)等.基于SMC的Android軟件保護(hù)研究與實(shí)現(xiàn)[J].信息網(wǎng)絡(luò)安全，2014.11：74-78

[5] 史成潔.Android平臺(tái)應(yīng)用軟件保護(hù)技術(shù)的研究與實(shí)現(xiàn)[D].北京郵電大學(xué)碩士學(xué)位論文，2015.

[6] 徐劍，武爽，孫琦等.面向Android應(yīng)用程序的代碼保護(hù)方法研究[J].信息網(wǎng)絡(luò)安全，2014.10：11-17

[7] 朱洪軍，陳灝，華保健等.移動(dòng)應(yīng)用代碼保護(hù)現(xiàn)狀與技術(shù)研究[J].計(jì)算機(jī)應(yīng)用與軟件，2016.33（3）：314-319，333

[8] 張譯恬，王純.基于安卓系統(tǒng)JNI機(jī)制的SO庫(kù)加固方案設(shè)計(jì)[J].電信技術(shù)，2014.10：90-93

[9] 錢(qián)海龍.移動(dòng)終端應(yīng)用安全加固關(guān)鍵技術(shù)研究[D].北京郵電大學(xué)碩士學(xué)位論文，2014.