基于軟件分析的Android應(yīng)用重打包檢測與防御研究

劉天一 周延森 崔見泉

(國際關(guān)系學(xué)院信息科技學(xué)院 北京 100091)

0 引 言

Android作為智能手機(jī)主流操作系統(tǒng),其惡意軟件數(shù)量在移動惡意軟件中所占比重超過50%且快速上升。攻擊者將重新打包的應(yīng)用程序作為其惡意行為的傳播媒介,降低了其本應(yīng)自行開發(fā)的成本與難度,同時也利用了原合法軟件的受歡迎度和可信度。文獻(xiàn)[1-2]表明Android應(yīng)用市場中5%～15%的應(yīng)用是被重新打包過的。

國內(nèi)外針對Android應(yīng)用重打包的研究目前多集中在相似度比對上。Kim等[3]提出的RomaDroid工具使用最長公共子序列(LCS)算法來測量兩個應(yīng)用程序之間的相似性;Hu等[4]提出了一種基于UI結(jié)構(gòu)相似性的克隆程序檢測方法;Wu等[5]提出的MSimDroid 方法基于多維相似性,包括整個應(yīng)用程序相似度、資源相似度、代碼相似度、聯(lián)合策略進(jìn)行相似度計算;汪潤等[6]提出了一種基于深度學(xué)習(xí)的Android重打包應(yīng)用檢測方法,并利用 Siamese LSTM 網(wǎng)絡(luò)學(xué)習(xí)程序的語義特征表示,實(shí)現(xiàn)重打包應(yīng)用的檢測;沈月東[7]提出的Android重打包行為分析技術(shù),通過進(jìn)行非第三方庫代碼部分的API調(diào)用的統(tǒng)計和聚類,以應(yīng)用對的形式檢測出重打包和被重打包的應(yīng)用;熊鷹[8]提出的基于用戶角度的重打包檢查方法,通過用戶端特征提取以及服務(wù)端相似應(yīng)用匹配實(shí)現(xiàn)重打包檢測。

基于相似度的重打包檢測方式面臨的最大問題是需要有足夠的數(shù)據(jù)集來對比分析,如未能與原合法應(yīng)用程序匹配則難以判定,且基于相似度的軟件水印、軟件胎記多數(shù)只能作為知識產(chǎn)權(quán)侵權(quán)行為被發(fā)現(xiàn)后的追責(zé)依據(jù),并不能從根本上解決剽竊、重打包攻擊等問題。同時,隨著軟件分析技術(shù)的發(fā)展,僅依靠相似度的重打包檢測為攻擊者繞過或欺騙檢測所設(shè)定的門檻與難度也在隨之降低。

1 相關(guān)研究工作

1.1 Android重打包原理

1) Android逆向。Android應(yīng)用程序通常由Java語言開發(fā)編寫,編譯成.class文件,轉(zhuǎn)換為一個可以在Android平臺的Dalvik虛擬機(jī)上運(yùn)行的.dex文件,最后將字節(jié)碼.dex文件、描述權(quán)限信息等內(nèi)容的AndroidManifest.xml文件、資源文件打包在一個.apk文件中。作為解釋型語言,Java高度抽象的特性也意味著其易被反編譯,隨之衍生出的逆向工具也在很大程度上降低了Android應(yīng)用重打包行為的工作量。

其逆向流程如圖1所示,其中,Apktool是被最廣泛使用的開源APK逆向工程軟件,可以將Dalvik字節(jié)碼反編譯成.smali代碼,然后再生成App的重打包版本;Jadx或商用軟件JEB可以對.smali代碼進(jìn)行直接處理與調(diào)試,并能展示出與源代碼幾乎相同的Java代碼;dex2jar可以借助baksmali等反匯編方式生成.jar文件進(jìn)而解壓得到Java代碼。

圖1 dex文件逆向

2) Android重打包。Android應(yīng)用程序的開發(fā)周期普遍較長,原軟件開發(fā)者付出了大量成本。然而,重打包App的成本普遍較低,難度也較小,圖2展示了Android應(yīng)用程序重打包的基本流程。

圖2 Android應(yīng)用程序重打包流程

應(yīng)用程序開發(fā)者發(fā)布App,用戶通過Google Play或第三方應(yīng)用市場下載軟件到移動設(shè)備,由于“下載”行為不存在身份鑒別,攻擊者同樣能夠以合法用戶身份從應(yīng)用市場下載.apk文件到本地。通過自動化反編譯或人工分析,從.apk文件中能夠獲取到可讀性較強(qiáng)的.smali代碼、Manifest文件與資源文件等,并經(jīng)由逆向工具進(jìn)一步獲得接近于原程序的Java代碼?；谝陨衔募?攻擊者通過修改.dex代碼、lib庫或向其他資源文件添加惡意代碼片段或針對廣告進(jìn)行增添或替換,將修改后的文件再通過Apktool等工具重新打包成.apk文件,使用官方的Android開源項(xiàng)目私鑰將重打包軟件簽名合法化,上傳到應(yīng)用市場,誘導(dǎo)用戶下載使用。

重打包后的應(yīng)用會保留一些特性,如與原App有一定程度上的代碼相似性、與原App有著不同的開發(fā)者簽名。應(yīng)用市場多以此為依據(jù),結(jié)合惡意行為分析和短時間段內(nèi)的模擬運(yùn)行,判別一個App是否安全和能否被發(fā)布。目前重打包的防御措施多集中于提升攻擊者的攻擊難度以及重打包行為發(fā)生后的判定上。

1.2 自解密代碼

自解密代碼SDC(Self Decryption Code)是在程序特定分支中依賴于分支內(nèi)常量通過加密或Hash等方式對代碼塊進(jìn)行處理,保障語義等價的前提下重寫原分支,替換后僅可以通過動態(tài)運(yùn)行實(shí)現(xiàn)自動解密恢復(fù),文獻(xiàn)[9]論證了其可靠性的基礎(chǔ)理論依據(jù)。

在借鑒文獻(xiàn)[10-11]的基礎(chǔ)上,本文所設(shè)計的SDC結(jié)構(gòu)如圖3所示。首先對條件分支中表達(dá)式的常量(記為w)使用不可逆的處理(如單向Hash)得到一個新常量es,以此實(shí)現(xiàn)對原常量w的隱藏。之后將常量w與實(shí)時計算生成的校驗(yàn)碼c一同作為密鑰對分支中全部代碼和劃分后的部分水印信息進(jìn)行加密操作,并用加密得到的亂碼形式代碼替換源代碼。

圖3 SDC結(jié)構(gòu)

當(dāng)運(yùn)行到該分支時,程序會實(shí)時計算校驗(yàn)碼并執(zhí)行解密操作從而完成自動解密,還原源代碼和這部分的水印信息。其中變量v是程序運(yùn)行到這一分支時變量中所存儲的值,理論上應(yīng)與w相等,因而用同樣隨機(jī)串對變量v的值進(jìn)行同樣處理,會得到一個與es相等的值,以上做到了對含有常量w的原表達(dá)式的等價轉(zhuǎn)換。

由于原常量w已經(jīng)通過es的替換實(shí)現(xiàn)了不可逆的隱藏,且由原常量w生成es的過程存在著一個無法預(yù)測的隨機(jī)值,再加上Hash算法的單向性,從而提高了從es到w的還原難度,作為密鑰組成部分的w就成為了只有原開發(fā)者知道的信息。因此,預(yù)測常量w的方法一種是根據(jù)程序上下文語義結(jié)合數(shù)據(jù)流分析等方式合理推斷,但由于通過SDC算法轉(zhuǎn)換程序最后的呈現(xiàn)大部分是無實(shí)際意義的亂碼,難以完成單純的靜態(tài)分析;另一種是在動態(tài)運(yùn)行過程中從變量v進(jìn)行突破。

1.3 軟件水印

軟件水印是將特定數(shù)據(jù)w作為水印嵌入程序P中,得到一個其水印難以被輕易檢測和移除的新程序Pw。水印的目的不是阻止應(yīng)用程序被非法使用,而是證明其所使用的軟件和算法的所有權(quán),從而輔助知識產(chǎn)權(quán)權(quán)益保護(hù)、打擊盜版。水印分為靜態(tài)和動態(tài)、明顯可見和隱藏不可見,文獻(xiàn)[7]利用SDC構(gòu)造的水印即屬于無須加以隱藏的動態(tài)軟件水印。

2 基于軟件分析的Android重打包檢測研究

本文針對Android應(yīng)用重打包檢測在軟件分析領(lǐng)域所面臨的挑戰(zhàn),分析其檢測方式在目前可預(yù)計的規(guī)避策略,從而設(shè)計開發(fā)出更為可靠的重打包防御方案。

2.1 實(shí)驗(yàn)設(shè)計

由于多數(shù)Android重打包檢測研究并未公開代碼和數(shù)據(jù)集,本文首先使用合法應(yīng)用程序集借助混淆、自解密代碼等技術(shù)構(gòu)造特定數(shù)據(jù)樣本,并簡要實(shí)現(xiàn)了基于代碼相似度的檢測算法,復(fù)現(xiàn)了WuFan、AndroidSOO等開源重打包檢測工具的檢測過程。

實(shí)驗(yàn)具體流程如圖4所示。針對不同類型的重打包防御方式,論文相應(yīng)地設(shè)計了不同的繞過檢測或妨礙防御的策略,以此來對重打包檢測算法進(jìn)行有針對性的測試及分析。

圖4 實(shí)驗(yàn)設(shè)計

2.2 自解密代碼的實(shí)現(xiàn)及數(shù)據(jù)集構(gòu)造

本實(shí)驗(yàn)數(shù)據(jù)集分為合法App、簡單處理的重打包App、利用混淆等處理意圖繞過檢測的重打包App三部分。其中,本文默認(rèn)從Google官方應(yīng)用市場下載得到的應(yīng)用均為合法應(yīng)用(實(shí)際上可能會存在約1.2%的重打包應(yīng)用),對其進(jìn)行簡單的逆向、修改和重打包后即構(gòu)成了第二部分?jǐn)?shù)據(jù)集,而構(gòu)造第三部分?jǐn)?shù)據(jù)樣本時的處理如下:

1) 混淆相關(guān)處理。本文首先對重打包程序進(jìn)行基礎(chǔ)混淆操作,包括:① 名字改編,即將域名、方法名、類名、包名等有實(shí)際意義的標(biāo)志符替換成無意義的相對較短的字符串。② 在不影響程序語義的前提下修改修飾符。③ 加入無效代碼對方法的實(shí)現(xiàn)結(jié)構(gòu)進(jìn)行調(diào)整。④ 方法參數(shù)轉(zhuǎn)換。⑤ 常量計算替換。

2) 自解密代碼構(gòu)造。本文通過自解密代碼技術(shù)為意圖繞過重打包檢測的數(shù)據(jù)集構(gòu)造提供進(jìn)一步的輔助。SDC[10-11]作為一種有效的重打包防御方式,但本文認(rèn)為其主要思想同樣也可以成為攻擊者對抗重打包檢測的技術(shù)之一。

本文在Java代碼層面,借助第二節(jié)中SDC的自加密-自解密框架和信息不對稱理論,實(shí)現(xiàn)了一個簡易版本的自解密代碼轉(zhuǎn)換器,其中,利用的單向函數(shù)為MD5,對稱加解密算法為DES,隨機(jī)串的添加在本文所編寫的md5enc方法中實(shí)現(xiàn)。

以程序1為例,其在Java代碼層面經(jīng)過混淆、自解密代碼轉(zhuǎn)換等處理后得到的等價代碼如程序2所示,可以看出二者直觀結(jié)構(gòu)呈現(xiàn)不同,但二者功能上并不存在差異,編譯運(yùn)行后得到同樣的運(yùn)行結(jié)果。

程序1原始代碼

while(k

{

if(x[k]= =1) R=(s*y)%n

else R=s;

s=R*R%n; L=R; k++;

}

return L;

程序2經(jīng)過混淆、自解密代碼轉(zhuǎn)換等處理后的代碼

int next=0;

for ( ; ; )

{

switch(md5enc(next))

{

case “4548cce2e2d7fbdea1afc51c7c6ad26”:

k=Integer.parseInt(desdec(String.format("%08d",next),"nISR6pPU35Y="));

s=Integer.parseInt(desdec(String.format("%08d",next),"B/4RM7/980M="));

next=Integer.parseInt(desdec(String.format("%08d",next),"B/4RM7/980M=")); break;

case "aab3238922bcc25a6f606eb525ffdc56":

s=R*R%n; L=R; k++;

next=Integer.parseInt(desdec(String.format("%08d",next),"4km57CcZvD8=")); break;

……

case "9bf31c7ff062936a96d3c8bd1f8f2ff3": return L;

另一方面,對于較為復(fù)雜的程序,本實(shí)驗(yàn)利用開源的混淆工具,從編譯器層面而非直觀的代碼層面進(jìn)行混淆等處理。

2.3 實(shí)驗(yàn)及結(jié)果分析

檢測算法的主要思想是在開發(fā)者簽名不同的前提下對于一個從非官方渠道獲取的未知來源的App,通過在已知是合法、非重打包的眾多數(shù)據(jù)集中逐一兩兩進(jìn)行相似性比對,計算其相似度。相似度越高(即越接近1.0)則說明這個未知來源的App是重打包的可能性更大,相似度最高值所對應(yīng)的合法App被認(rèn)定為其重打包的對象。

本文利用前文所構(gòu)造的數(shù)據(jù)樣本對基于相似度的重打包檢測算法進(jìn)行對抗測試,具體步驟為:

1) 從可靠性較高的應(yīng)用市場隨機(jī)選取.apk文件(記作app-ori)下載到本地。

2) 借助Apktool工具對.apk文件進(jìn)行解包與反編譯,如圖5所示。

圖5 對.apk文件進(jìn)行反編譯與重打包

3) 使用逆向工具得到Java代碼。

4) 添加或修改代碼片段得到文件re1。

5) 對re1采用前文所述混淆等方法進(jìn)行轉(zhuǎn)換,用于妨礙重打包檢測,得到re2。

6) 使用Apktool分別對re1、re2重打包生成.apk文件app-re1、app-re2。

7) 將生成的兩個.apk文件分別放入重打包檢測系統(tǒng)中檢測,分別記錄各系統(tǒng)關(guān)于是否為重打包應(yīng)用所做出的判定。

8) 通過Android Studio平臺模擬器驗(yàn)證應(yīng)用程序本身功能完整性是否被破壞。

9) 對檢測算法的表現(xiàn)進(jìn)行評估與分析。

上述相似度重打包檢測步驟如圖6所示。

圖6 相似度重打包檢測流程

實(shí)驗(yàn)主機(jī)為:CPU Intel Core i5 @2.30 GHz和8 GB的RAM。由于一個完整的Android應(yīng)用規(guī)模較大,包含上萬個文件,盡管本文復(fù)現(xiàn)算法時已盡可能簡化了檢測過程,基于相似度的檢測算法仍需數(shù)小時的判定時間?；诖宋覀儍H在小規(guī)模測試集中實(shí)驗(yàn),針對實(shí)驗(yàn)的分析主要基于代碼層面。

圖7展示了重打包文件與原.apk文件的相似度得分(即Similarity),若作者簽名不同而相似度很高則可以判定其是重打包應(yīng)用。

圖7 計算兩個.apk文件的相似度

本實(shí)驗(yàn)?zāi)J(rèn)app-ori為合法應(yīng)用,將其作為基準(zhǔn)分別計算app-re1和app-re2與該應(yīng)用的相似度,從而對二者是否為重打包程序進(jìn)行判斷。通過對比針對同一app-ori[i]的兩個不同重打包版本app-re1[i]與app-re2[i]在檢測中表現(xiàn)出來的差異,以及進(jìn)一步統(tǒng)計檢測系統(tǒng)在不同情況下的漏報率,可以推測出本文在構(gòu)造特定重打包行為時所采取的混淆、自解密代碼轉(zhuǎn)換等技術(shù)對重打包檢測算法所造成的影響。

實(shí)驗(yàn)結(jié)果如表1所示,本文構(gòu)造數(shù)據(jù)樣本時混淆等處理降低了重打包應(yīng)用與原應(yīng)用的相似度,使其低于重打包攻擊行為的判定閾值,從而在一定程度上欺騙了檢測系統(tǒng)。本文所復(fù)現(xiàn)的檢測算法沒有針對代碼以外的信息進(jìn)行處理,將兩個包括作者簽名在內(nèi)完全相同的.apk文件(其相似度高達(dá)1.0)判定為重打包,而Wu Fan可以對.apk文件的簽名做出識別,將其正確判定為作者相同,即“非重打包”,如圖7所示。但現(xiàn)實(shí)中Android應(yīng)用市場在正式發(fā)布應(yīng)用前都至少會對其簽名進(jìn)行最基本的驗(yàn)證與校對,驗(yàn)證時即可獲知作者信息,因此對持有相同作者信息的App重打包判定可暫不作考慮。

表1 檢測性能對比

針對于僅完成了重打包的.apk文件,基于相似度的檢測算法均能以很高的準(zhǔn)確率檢測出其重打包行為(本實(shí)驗(yàn)在重打包過程中僅采取較為簡單的人工修改或添加,且判定閾值設(shè)置較低,真實(shí)情況不一定會達(dá)到如表1所示百分之百正確率和零漏報率)。針對本實(shí)驗(yàn)處理后的重打包測試樣本,其與原文件的相似度數(shù)值呈明顯降低。實(shí)驗(yàn)結(jié)果顯示混淆、自解密代碼轉(zhuǎn)換等方法使得多數(shù)重打包.apk與原.apk文件的相似度降至基于代碼相似度算法的判定閾值之下,從而存在很大概率可成功繞過此類型的重打包檢測。

3 Android重打包攻擊防御的改進(jìn)

3.1 系統(tǒng)框架

上文分析了軟件分析技術(shù)為目前被廣泛應(yīng)用的三種重打包檢測方法所帶來的影響,基于此,本文綜合了以SDC等技術(shù)為依據(jù)的檢測或防御算法,在此基礎(chǔ)上提出一種改進(jìn)的重打包防御框架,如圖8所示。

圖8 重打包攻擊防御系統(tǒng)框架

Android應(yīng)用開發(fā)者在編寫完程序代碼后:

1) 將源代碼進(jìn)行自動化程序分析,其環(huán)境與軟件測試保持一致即可,在這個過程中:① 對程序結(jié)構(gòu)進(jìn)行一定的轉(zhuǎn)換與優(yōu)化,使之便于后續(xù)的水印嵌入和SDC生成,同時也起到混淆的作用,從而降低程序的可讀性;② 對可利用的分支語句進(jìn)行標(biāo)記,如程序規(guī)模較小則利用不透明謂詞添加可利用的分支。

2) 構(gòu)造水印信息并進(jìn)行切分和壓縮等處理。

3) 結(jié)合自解密與自防御算法,將水印嵌入程序,同時對代碼進(jìn)行加密處理,生成自解密代碼。

4) 將代碼與資源等文件打包、簽名和上傳到應(yīng)用市場待審核。

隨后,權(quán)威Android應(yīng)用市場會對App進(jìn)行初步檢測,在模擬環(huán)境下進(jìn)行運(yùn)行測試。在測試過程中運(yùn)行到SDC時,正常情況下程序會自動進(jìn)行解密還原,若無法進(jìn)行解密則顯然會因?yàn)閬y碼從而導(dǎo)致程序運(yùn)行崩潰,此時權(quán)威應(yīng)用市場即可根據(jù)程序運(yùn)行錯誤的提示判定該App有缺陷或有被重打包的可能,拒絕發(fā)布該應(yīng)用。而通過了初步檢測以及模擬運(yùn)行測試的App會被發(fā)布到Android應(yīng)用商店供用戶下載。

用戶從應(yīng)用商店等多種渠道下載App到智能移動設(shè)備上,若該應(yīng)用為合法應(yīng)用,程序會逐步自動解密還原,用戶可以在沒有額外附加感受的前提下正常使用;若該應(yīng)用是被重打包過的,程序存在很大的概率會在運(yùn)行到某處時由于自解密失敗而崩潰。此時該程序便無法繼續(xù)運(yùn)行,在一定程度上阻止了該重打包應(yīng)用繼續(xù)危害用戶設(shè)備的可能,程序的崩潰也為移動設(shè)備使用者發(fā)出了該應(yīng)用可能存在問題的警示,用戶可以采取卸載程序以及舉報該程序等行為。Android應(yīng)用市場收到用戶的反饋后會對該可疑應(yīng)用進(jìn)行進(jìn)一步篩查和更細(xì)致的審計。若該App僅為運(yùn)行錯誤則提示更新修復(fù),若該App確實(shí)存在惡意行為則下架該應(yīng)用并對發(fā)布者進(jìn)行一系列懲罰。如果該應(yīng)用為惡意的且已經(jīng)對移動設(shè)備使用者造成了損失,則需要進(jìn)一步借助水印中所攜帶的信息來判定該應(yīng)用是否為重打包以及責(zé)任歸屬問題。

3.2 改進(jìn)分析

由于自防御代碼[2]意圖以程序崩潰作為重打包的代價從而阻止重打包攻擊,而自解密代碼則是借助SDC嵌入軟件水印[7],我們希望可以通過優(yōu)化水印的構(gòu)造方式來降低嵌入的成本,從而將二者結(jié)合,既可以實(shí)現(xiàn)讓重打包App自動暴露以達(dá)到防御效果,又可以在重打包攻擊發(fā)生后通過水印所攜帶的作者信息、發(fā)布信息等進(jìn)行版權(quán)保護(hù)或惡意行為的責(zé)任判定。同時在此基礎(chǔ)上結(jié)合其他重打包檢測與防御系統(tǒng)的優(yōu)勢設(shè)計出一個更為可靠的防御框架。

經(jīng)過處理后的SDC既可以在水印與載體代碼之間建立內(nèi)在依賴,將二者加密為一個SDC段,從而更好地將軟件水印融合到程序之中,并提升攻擊者移除或篡改水印的成本;又可以利用程序完整性校驗(yàn)碼等構(gòu)造密鑰以實(shí)現(xiàn)重打包應(yīng)用的自動化防御;在此基礎(chǔ)上引入的加密算法,作為一種重要的混淆技術(shù),也在一定程度上提升了程序的復(fù)雜性,使得攻擊者閱讀代碼和重構(gòu)代碼更加困難。

隨著軟件分析領(lǐng)域的發(fā)展,程序綜合等技術(shù)使得條件分支語句也就是初始SDC的各個“入口”是可以以自動化分析的形式找到并基于概率求解的,這使得攻擊者以低于重開發(fā)的成本重打包一個被SDC保護(hù)的Android應(yīng)用成為了可能。因此,我們的框架在SDC生成前加入一個步驟,先對源程序進(jìn)行程序分析以及類似于混淆技術(shù)的代碼轉(zhuǎn)換處理,以此來增加攻擊者自動化求解的難度。

本框架的優(yōu)勢之一是讓Android應(yīng)用程序開發(fā)者、移動設(shè)備使用者、Android應(yīng)用市場三方全都參與到重打包的防御中來。開發(fā)者可以以自身的操作對代碼加以保護(hù)從而從根本上阻礙他人的剽竊行為,而不是將版權(quán)保護(hù)寄托于檢測能力參差不齊的第三方應(yīng)用市場、在他人重打包攻擊行為發(fā)生后才進(jìn)行耗時耗力的追責(zé);用戶也可以通過程序的運(yùn)行崩潰感知重打包行為,從而阻止惡意應(yīng)用繼續(xù)存在于移動設(shè)備之上。

4 結(jié) 語

軟件分析技術(shù)的發(fā)展既使攻擊者繞過檢測、對抗防御、降低攻擊成本成為了可能,同時也為重打包防御提供了提升的空間。本文分析了目前常見的重打包檢測算法,構(gòu)造了特定數(shù)據(jù)樣本及繞過檢測的策略進(jìn)行測試,并基于此設(shè)計一個綜合的重打包防御框架。本文的不足之處在于,沒有對提出的方案進(jìn)行完整的實(shí)現(xiàn)與測試評估,僅通過第二節(jié)中實(shí)驗(yàn)所得出的結(jié)論來輔助驗(yàn)證改進(jìn)設(shè)計的合理性,且僅在代碼層面而非編譯器層面實(shí)現(xiàn)了SDC。