李志明,劉壽春,歐陽飛帆,李婷婷,申利民

1(燕山大學 信息科學與工程學院，河北 秦皇島 066004) 2(河北省計算機虛擬技術(shù)與系統(tǒng)集成重點實驗室，河北 秦皇島 066004) 3(河北省軟件工程重點實驗室，河北 秦皇島 066004)

1 引 言

Android系統(tǒng)的開源特性使其快速發(fā)展的同時，也給Android應(yīng)用帶來了嚴重的安全隱患.逆向人員可輕易通過靜態(tài)攻擊、動態(tài)攻擊以及重打包攻擊等多種手段對未加固的Android應(yīng)用進行逆向破解，并植入非法代碼，形成惡意應(yīng)用后再重新發(fā)布到應(yīng)用市場[1].在用戶不知情的情況下，惡意應(yīng)用通過私自扣費、隱私竊取、系統(tǒng)破壞、自動訪問不良信息等行為給用戶造成損失.

通常，軟件開發(fā)者采用多種防護措施保護其應(yīng)用不被逆向破解.目前，主流的防護措施有代碼混淆[2,3]、權(quán)限控制[4,5]以及應(yīng)用加固3類，其中，應(yīng)用加固是Android應(yīng)用安全防護的首選措施.按照加固對象不同，應(yīng)用加固可分為Dex文件加固和so文件加固兩類.

Dex文件，包含Android應(yīng)用的所有源代碼，是逆向人員的主要攻擊對象.為此，眾多研究者針對Dex文件提出了很多加固方法，例如，Dex分塊加載技術(shù)[6]、VMP保護技術(shù)[7]以及加殼技術(shù)[8-10]等，其中，加殼技術(shù)是最為有效且被廣泛應(yīng)用的方法.但是，現(xiàn)有加殼技術(shù)存在兩點缺陷:1)將源apk文件直接放到解殼程序的資源文件中，易于被逆向人員獲??；2)缺乏對解殼程序的保護，導(dǎo)致逆向人員可以通過重打包方式植入非法代碼實現(xiàn)對解殼程序的篡改.盡管Dex文件加固在一定程度上提升了Android應(yīng)用的安全性，但Android系統(tǒng)的開源性使得Dex文件在安全性方面與由c/c++編寫的so文件相比存在一定差距.

JNI (Java Native Interface)機制[11]，使得開發(fā)人員可以在Java代碼中調(diào)用so文件中的Native函數(shù)，這樣，開發(fā)人員便可將Android應(yīng)用的函數(shù)代碼轉(zhuǎn)換為C/C++代碼置于so文件中，以達到進一步保護函數(shù)代碼的目的.但隨著逆向人員技術(shù)水平的提高，so文件被逆向破解的情況也時有發(fā)生，因此，亟需采取相應(yīng)措施對so文件進行加固防護.

從加固原理角度，so文件加固可分為Native函數(shù)混淆[12]、符號表隱藏[13]及自定義so加載器[14]3種方案.這3種方案均以整個so文件作為加固對象，存在對應(yīng)用性能影響過大的問題.

綜上，現(xiàn)有以Dex文件加固為核心的加殼技術(shù)，存在著源apk文件易被獲取以及解殼程序易被篡改的問題；現(xiàn)有so文件加固方案以整個so文件作為加固對象，存在著加固后的Android應(yīng)用運行效率下降等問題[15].

針對上述問題，融合JNI機制、動態(tài)加載技術(shù)[16]以及云平臺理念，提出一種面向Android應(yīng)用的安全加固模型，并對其中涉及的基于JNI機制的函數(shù)代碼加固方案、基于云平臺的加殼解殼方案開展研究工作，進而形成一種基于JNI機制與云平臺的細粒度Android應(yīng)用加固方法.該方法可使得加固應(yīng)用在未顯著增加Dalvik虛擬機的工作負擔的前提下，具有抵御靜態(tài)攻擊及重打包攻擊能力.

2 安全加固模型

為了便于后續(xù)描述，將面向Android應(yīng)用的安全加固模型命名為RMAA(reinforce model for Android App)加固模型，其框架如圖1所示.

由圖1可知，RMAA加固模型對Android應(yīng)用的加固環(huán)節(jié)主要集中在云平臺的安全加固功能區(qū)，可有效降低逆向人員通過分析加固原理對加固應(yīng)用破解的風險.此外，將源apk的加密Dex文件和簽名的SHA-1值等重要文件及信息存儲于云平臺的持久化區(qū)，保證了校驗機制的有效性及Android應(yīng)用的安全性.其中，基于JNI機制的函數(shù)代碼加固及基于云平臺的加殼解殼技術(shù)方案是實現(xiàn)RMAA加固模型的關(guān)鍵問題，需要開展深入研究.

3 基于JNI機制的函數(shù)代碼加固方案

基于JNI機制的函數(shù)代碼加固方案的流程如圖2所示，其核心思想在于以修改smali指令的方式實現(xiàn)JNI機制，將用戶選取的待加固的Java層函數(shù)與加固后so文件中相應(yīng)Native函數(shù)建立映射關(guān)系，以達到細粒度化加固函數(shù)代碼安全性的目的.

由圖2可知，基于JNI機制的函數(shù)代碼加固方案的優(yōu)勢有兩點:1)細粒度的核心函數(shù)代碼加固方式可有效地減少Dalvik虛擬機的額外工作負擔，從而使得加固應(yīng)用對系統(tǒng)資源的消耗不會有明顯增加;2)通過JNI機制實現(xiàn)Java層函數(shù)與so文件中相應(yīng)Native函數(shù)間建立映射關(guān)系，達到了Dex文件加固與so文件加固的有機結(jié)合目的.

為了實現(xiàn)基于JNI機制的函數(shù)代碼加固方案，需對其中涉及的Dex文件類及成員函數(shù)抽取算法、基于section的細粒度so文件加固方法、基于JNI機制的函數(shù)映射等問題展開研究工作.

3.1 Dex文件類及其成員函數(shù)信息抽取算法

Dex文件中類及其成員函數(shù)信息抽取的目的，在于獲取源apk文件中類及其成員函數(shù)信息，并將獲取到的信息存儲于自定義的ClassInfoMap和MethodInfoMap結(jié)構(gòu)體中，以供用戶在其中選擇其需要加固的核心函數(shù).

針對Dex文件結(jié)構(gòu)[17]，提出Dex文件類及其成員函數(shù)信息抽取的流程如圖3所示，其步驟如下:

1)提取DexHeader結(jié)構(gòu)體中的mapOff屬性值，并根據(jù)mapOff屬性值找到DexMapList后，轉(zhuǎn)至2).

2)判斷是否遍歷DexMapList集合中的所有DexMapItem結(jié)構(gòu)體實例，若是轉(zhuǎn)至11)，否則轉(zhuǎn)至3).

3)在DexMapList集合中獲取一個DexMapItem結(jié)構(gòu)體實例.

4)判斷該DexMapItem結(jié)構(gòu)體實例中的type屬性值與kDexTypeClassDefItem值是否相同，若相同，則根據(jù)其offset屬性值找到描述類信息的DexClassDef結(jié)構(gòu)體實例，轉(zhuǎn)至5)，否則轉(zhuǎn)至2).

圖2 基于JNI機制的函數(shù)代碼加固流程Fig.2 Flow of the function code reinforcement based on JNI mechanism

5)將該DexClassDef結(jié)構(gòu)體實例中的classIds、accessFlags和sourceFilesIdx屬性值存放于自定義ClassInfoMap結(jié)構(gòu)體實例的相應(yīng)屬性中，完成類信息的提取，轉(zhuǎn)至6).

圖3 Dex文件類及成員函數(shù)信息抽取流程Fig.3 Extraction process of Dex file class and member function information

6)根據(jù)該DexClassDef結(jié)構(gòu)體實例的classDataoff屬性值找到DexClassData結(jié)構(gòu)體實例，轉(zhuǎn)至7).

7)讀取DexClassData結(jié)構(gòu)體實例中的direcMethods屬性值找到DexMethod集合，轉(zhuǎn)至8).

8)是否遍歷DexMethod集合中所有DexMethodId結(jié)構(gòu)體實例，若是轉(zhuǎn)至2)，否則轉(zhuǎn)至9).

9)獲取一個DexMethod集合中的DexMethodId結(jié)構(gòu)體實例，轉(zhuǎn)至10).

10)將該DexMethodId結(jié)構(gòu)體實例中的nameIdx、protoIdx和returnIdx屬性值提取并存放于自定義MethodInfoMap結(jié)構(gòu)體實例的相應(yīng)屬性中，轉(zhuǎn)至8).

11)結(jié)束.

3.2 基于section的細粒度so文件加固方法

現(xiàn)有so文件加固的方法，多以整個so文件作為加固對象.這種方式，使得加固應(yīng)用運行時給Dalvik虛擬機造成較大的工作負荷，并以應(yīng)用性能下降的形式展現(xiàn)出來.為此，提出一種基于section的細粒度so文件加固方法.該方法選取so文件中承載Native函數(shù)的section作為基本加固對象，從而實現(xiàn)對so文件的細粒度加固.

3.2.1 自定義section聲明

若用戶需要將so文件中的某個Native函數(shù)置于特定的section中，則需在用于編譯so文件的源文件中，在特定函數(shù)名的前面添加__attribute__((section("sectionName")))用以完成編譯后so文件中自定義section的聲明.

3.2.2 自定義section加固

若要對自定義section進行加固，需要首先確定自定義section在so文件中的位置.so文件頭部結(jié)構(gòu)[17]中的e_shoff屬性給出了第一個section的相對位置.

在section結(jié)構(gòu)[17]中，sh_name、sh_size屬性分別代表section的名稱及大小，且各個section在so文件中的存放位置是相鄰的，因此，第i+1個section的起始位置為第i個section的偏移量加上其sh_size屬性的值.

在準確提取section地址的基礎(chǔ)上，形成對單個自定義section加固的步驟如下.

1)讀取so文件頭部結(jié)構(gòu)中的e_shstrnd屬性值，檢索其中是否存在自定義section名稱，若有，則轉(zhuǎn)至2)；若無，則轉(zhuǎn)至6).

2)讀取so文件頭部結(jié)構(gòu)中的e_shoff屬性值，并定位到第一個section的位置.

3)根據(jù)so文件頭部結(jié)構(gòu)中的e_shnum屬性值得到該so文件中存在的section數(shù)量.

4)以e_shnum屬性值為終止條件，按照前述section位置的計算方法逐一比對section名稱與自定義section的名稱是否匹配.若匹配，則將自定義section的內(nèi)容讀取到臨時變量enc_content中，并將該section的位置偏移量及其大小分別存儲于define_section_offset及define_section_size變量中.

5)采用異或算法[18]對enc_content變量中的內(nèi)容進行加密，并用加密后的內(nèi)容替換so文件中自定義section的內(nèi)容.

6)結(jié)束.

3.2.3 自定義section解密

欲對加固后的自定義section解密，則需先確定自定義section在內(nèi)存中的地址空間.so文件被加載到內(nèi)存的起始地址是不固定的，因此，so文件在內(nèi)存起始地址的獲取是確定自定義section在內(nèi)存中地址空間的關(guān)鍵所在.

so文件被加載至內(nèi)存后，Android系統(tǒng)會自動向proc//maps目錄下的內(nèi)存鏡像文件中寫入so文件在內(nèi)存中的相關(guān)信息，并可通過“cat maps|grep xxx.so”命令完成對名稱為xxx的so文件在內(nèi)存中相關(guān)信息的檢索，從而獲取xxx.so文件的內(nèi)存首地址.

在上述基礎(chǔ)上，定義滿足A≤X≤B的內(nèi)存段為自定義section在內(nèi)存空間的地址范圍，記為[A,B]={X|A≤X≤B}，其中A為首地址，B為尾地址，則自定義section在內(nèi)存中地址范圍的計算方式如式(1)所示.

[A,B]={X|sr+es+dso≤x≤sr+es+dso+dss}

(1)

式中，sr表示so文件在內(nèi)存中的起始地址，es表示so文件的頭部結(jié)構(gòu)大小(固定為52字節(jié))，dso表示自定義section在so文件中的位置偏移量，dss表示自定義section的大小.

通過以上分析，形成對單個自定義section的解密步驟如下.

1)通過“cat maps|grep”命令得到so文件在內(nèi)存的相關(guān)信息，并獲取該文件在內(nèi)存中的首地址，賦值給式(1)中sr變量.

2)將對自定義section加固步驟中，記錄的define_section_offset和define_section_size變量分別賦值給式(1)中dso變量和dss變量.

3)按式(1)計算自定義section在內(nèi)存中的地址空間范圍.

4)根據(jù)第3)步的計算結(jié)果，提取自定義section內(nèi)容，并將其存放于臨時變量dec_content中.

5)采用異或算法對dec_content變量中的內(nèi)容進行解密，并用解密后的內(nèi)容替換內(nèi)存中so文件的自定義section的內(nèi)容.

6)結(jié)束.

3.3 基于JNI機制的函數(shù)映射

為使Android應(yīng)用能夠正常調(diào)用so文件中的Native函數(shù)，則需建立Java層函數(shù)與so文件中相應(yīng)Native函數(shù)的映射關(guān)系.本文采用修改smali指令[17]實現(xiàn)JNI機制的方式建立函數(shù)映射關(guān)系.

為了敘述方便，假設(shè)用戶選擇的待加固函數(shù)為MainActivity類中的getString()函數(shù)，則建立Java層getString()函數(shù)與so文件中g(shù)etString()函數(shù)之間映射關(guān)系的步驟如下.

1)在反編譯apk文件后形成的smali文件夾下查找MainActivity.smali文件.

2)在MainActivity.smali文件中，根據(jù)正則表達式const(.method)(.*?)*getString.*(.end method).查找getString()函數(shù)的smali指令.

3)刪除smali指令中g(shù)etString()函數(shù)的功能實現(xiàn)部分.

4)在MainActivity.smali文件的getString()函數(shù)功能實現(xiàn)部分，添加相應(yīng)smali指令，實現(xiàn)利用JNI機制調(diào)用加固后so文件中的getString()函數(shù).修改smali指令會導(dǎo)致所需寄存器數(shù)量發(fā)生變化，因此，在修改smali指令后需要重新計算并修改該函數(shù)所需的寄存器數(shù)量[17].

經(jīng)過以上步驟，Java層getString()函數(shù)的功能實現(xiàn)代碼轉(zhuǎn)移到了so文件的相應(yīng)函數(shù)中，并建立起了二者之間映射關(guān)系.至此，即使逆向人員利用apktool、jadx-ju等工具對源apk文件進行反編譯，也不能直接獲得getString()函數(shù)的代碼內(nèi)容.由此可見，該方法可使得Android應(yīng)用Java層函數(shù)代碼的安全性得以提高.

4 基于云平臺的加殼解殼方案

針對現(xiàn)有加殼解殼方案中源apk文件易于獲取及缺乏對解殼程序保護的問題，在RMAA加固模型基礎(chǔ)上，融合簽名校驗及動態(tài)加載技術(shù)，提出一種基于云平臺的加殼解殼方案，其流程如圖4所示.

圖4 基于云平臺的加殼解殼方案流程Fig.4 Flow of the shell and unshell solution based on cloud platform

4.1 平臺端應(yīng)用加殼程序設(shè)計

平臺端應(yīng)用加殼程序的主要功能為，將源apk的Dex文件加密并存儲于云平臺的持久化區(qū)，以供Android端應(yīng)用解殼程序下載；將源apk的剩余文件融合于源解殼程序的Dex文件中形成新Dex文件，并對新Dex文件的相關(guān)參數(shù)值進行修正；采用Jarsigner工具對加固應(yīng)用apk文件進行重簽名，并將該簽名的SHA-1值存放于持久化區(qū)(見圖1).

Dex文件頭部結(jié)構(gòu)中的checksum、signature及file_size是描述Dex文件規(guī)格信息的重要屬性，也是Dalvik虛擬機評判Dex文件是否可以被正常加載的依據(jù).將源apk剩余資源文件與源解殼程序Dex文件融合后形成的新Dex文件的內(nèi)容及規(guī)格勢必發(fā)生變化，因此，需要根據(jù)新Dex文件的規(guī)格對上述3個屬性的值進行修正.

4.2 Android端應(yīng)用解殼程序設(shè)計

Android端應(yīng)用解殼程序的功能為，首先，從加固應(yīng)用apk文件的Dex文件中提取源apk剩余文件；其次，通過云平臺的服務(wù)接口下載源apk加密Dex文件，并利用AES算法對其解密；再次，將源apk剩余文件與解密后的源apk的Dex文件重新整合為源apk文件；最后，利用動態(tài)加載技術(shù)將系統(tǒng)控制權(quán)轉(zhuǎn)交給源apk文件，使源apk文件按原邏輯正常運行.基于此，設(shè)計的解殼程序流程如圖5所示，其中，解殼程序反篡改、動態(tài)加載及其相關(guān)置換是其中的關(guān)鍵環(huán)節(jié).

4.2.1 解殼程序反篡改方案

在現(xiàn)有Android應(yīng)用加殼解殼方案中，通常，應(yīng)用的簽名校驗邏輯存放在Android應(yīng)用Java層，逆向人員可通過API分析法[17]等手段找到簽名校驗邏輯的代碼位置，然后刪除簽名校驗邏輯或者將校驗結(jié)果改為真，從而實現(xiàn)對解殼程序的逆向篡改.

針對上述問題，提出一種基于云平臺技術(shù)的解殼程序反篡改方案，具體流程如下.

首先以加固應(yīng)用簽名的SHA-1值為參數(shù)訪問云平臺提供下載源apk加密Dex文件的服務(wù)接口，若該SHA-1值與云平臺保存的SHA-1值一致則簽名校驗通過，允許下載源apk的Dex文件，否則退出加固應(yīng)用.

圖5 解殼程序流程Fig.5 Flow of the unshell

由此可見，在基于云平臺的加殼解殼方案中，若逆向人員通過非法手段對解殼程序進行逆向篡改后，由于篡改前后解殼程序的簽名SHA-1值發(fā)生了變化，導(dǎo)致無法從云平臺下載源apk加密Dex文件，從而有效防范加固應(yīng)用的非法運行.

4.2.2 動態(tài)加載及其相關(guān)置換

由圖5可知，為了使源apk文件能夠正常運行，需要利用反射機制置換Dalvik虛擬機的默認類加載器為自定義類加載器，以達到動態(tài)加載源apk文件的目的.

在動態(tài)加載源apk文件之后，Dalvik虛擬機將源apk文件加載至解殼程序所在的進程中，但由于此時內(nèi)存中Application實例是解殼程序的Applicaiton對象，Dalvik虛擬機無法找到源apk文件的入口.因此，需要將此時的Application實例置換為源apk文件的Application對象.

此外，為了使源apk文件能夠正常運行，還需要利用反射機制置換Resource類中的mAssetsManager實例為自定義AsseManager對象，以保證Dalvik虛擬機可以正常訪問源apk文件的資源文件.此處，自定義AsseManager對象是AssetsManager類的一個實例，其addAssetPath()方法可以獲得相應(yīng)資源文件的訪問路徑.

5 實驗驗證

在RMAA加固模型總體框架的指引下，在基于JNI機制的函數(shù)代碼加固方案及基于云平臺的加殼解殼方案的研究基礎(chǔ)上，設(shè)計并開發(fā)了RMAA加固系統(tǒng)原型，并從基于section的細粒度so文件加固有效性、基于JNI機制的函數(shù)映射有效性，以及應(yīng)用加固前后性能變化3個方面對基于JNI機制與云平臺的細粒度Android應(yīng)用加固方法的有效性進行驗證.

5.1 基于section的細粒度so文件加固有效性

以自主開發(fā)的用于人體健康風險評測的Android應(yīng)用healthEvl.apk文件作為測試用例，并輸入RMAA加固系統(tǒng).在RMAA加固系統(tǒng)完成對healthEvl.apk文件的反編譯、類及其成員函數(shù)的信息抽取環(huán)節(jié)后，以用戶選擇用于疾病風險評估的Java層disRiskByMeridian函數(shù)為例，驗證基于section的細粒度so文件加固的有效性.

利用IDAPro逆向工具反匯編加固前后的so文件，分別得到如圖6、圖7所示的逆向視圖.

圖6 so文件加固前的逆向視圖Fig.6 Reverse view of so file before reinforcing

由圖6可知，反匯編未加固前的so文件，可顯示disRiskByMeridian()函數(shù)的完整匯編代碼；逆向人員可以通過對匯編代碼的分析掌握disRiskByMeridian()函數(shù)的實現(xiàn)過程.由圖7可知，對so文件中承載disRiskByMeridian()函數(shù)的section加密后，再次反匯編加固后的so文件時發(fā)生錯誤，且無法得到disRiskByMeridian()函數(shù)的匯編代碼.由此，可驗證基于section的細粒度so文件加固的有效性.

圖7 so文件加固后的逆向視圖Fig.7 Reverse view of so file after reinforcing

5.2 基于JNI機制的函數(shù)映射有效性

以RMAA加固系統(tǒng)加固healthEvl.apk文件中的ReasoningCenter類的disRiskByMeridian函數(shù)得到的reinforce.apk文件為例，驗證基于JNI機制的函數(shù)映射有效性.在驗證reinforce.apk應(yīng)用功能正常的基礎(chǔ)上，利用jadx-gui逆向工具反編譯healthEvl.apk和reinforce.apk文件，分別得到如圖8和圖9所示的逆向視圖.

圖8 healthEvl.apk逆向視圖Fig.8 Reverse view on healthEvl.apk

對比圖8與圖9可知，healthEvl.apk經(jīng)加固后，disRiskByMeridian()函數(shù)的函數(shù)體由實現(xiàn)代碼變?yōu)榱薐NIManager.disRiskByMeridian()，從而驗證了函數(shù)映射機制的有效性.

5.3 應(yīng)用加固前后性能對比

從理論角度分析，經(jīng)RMAA加固系統(tǒng)加固后的應(yīng)用，在apk文件大小、內(nèi)存占用量及啟動時間等方面均會有所增加.apk文件大小增加的主要原因是在原有apk文件基礎(chǔ)上增加了解殼程序代碼和so文件；加固應(yīng)用在解殼過程中，對源apk的Dex文件解密以及對源apk文件的動態(tài)加載環(huán)節(jié)需要開辟額外的內(nèi)存空間，因此，在加固應(yīng)用的啟動階段，內(nèi)存占用量及啟動時間均會明顯增加.此外，下載Dex文件時消耗在網(wǎng)絡(luò)傳輸上的時間是啟動時間增加的主要影響因素.

圖9 reinforce.apk逆向視圖Fig.9 Reverse view on reinforce.apk

為了測試應(yīng)用加固前后實際的apk文件大小、啟動階段內(nèi)存占用量及啟動時間等方面的變化，從開源社區(qū)Gitee下載5個未加固的apk文件.在經(jīng)RMAA加固系統(tǒng)加固過程中，每個應(yīng)用均選取1個函數(shù)進行基于JNI機制的函數(shù)代碼加固.5個應(yīng)用加固前后apk文件大小、啟動階段內(nèi)存占用量、啟動時間的變化情況如表1所示.

由表1可知，加固應(yīng)用apk文件的大小增量變化平緩，穩(wěn)定在0.2MB左右，啟動階段內(nèi)存增量穩(wěn)定在8MB左右，啟動時間增量在500ms以下.由此可見，在內(nèi)存增量方面，對于目前存儲容量為幾十乃至上百GB級別的Android終端的影響可以忽略不計；在啟動時間增量方面，用戶是難以感知的.

表1 應(yīng)用加固前后性能指標對比Table 1 Comparison of performance indexes before and after reinforcing

6 結(jié) 論

本文針對現(xiàn)有Android應(yīng)用加固技術(shù)或方法的不足，提出一種基于JNI機制與云平臺的細粒度Android應(yīng)用加固方法.該方法采用基于JNI機制的函數(shù)代碼加固方案實現(xiàn)了so文件的細粒度加固，從而使得逆向人員不能通過逆向工具輕易獲取應(yīng)用的核心函數(shù)代碼，且加固應(yīng)用并未顯著增加Dalvik虛擬機工作負擔；采用基于云平臺的加殼解殼方案，通過解殼程序運行時以加固應(yīng)用簽名的SHA-1值為參數(shù)訪問云平臺提供下載源apk加密Dex文件的服務(wù)接口方式，有效解決了源apk文件易被獲取以及解殼程序易被篡改的問題.通過RMAA加固系統(tǒng)驗證了基于JNI機制與云平臺的細粒度Android應(yīng)用加固方法的有效性，且加固應(yīng)用的啟動時間、內(nèi)存占用量等并未顯著增加.

在后續(xù)的研究工作中，可采用機器學習手段開展根據(jù)smali指令語義自動生成相應(yīng)so文件的研究工作，從而進一步提升該加固方法的自動化程度.