劉天一 周延森 崔見(jiàn)泉

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

0 引 言

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

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

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

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

1.1 Android重打包原理

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

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

圖1 dex文件逆向

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

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

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

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

1.2 自解密代碼

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

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

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

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

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

1.3 軟件水印

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

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

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

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

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

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

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

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

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

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

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

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

以程序1為例,其在Java代碼層面經(jīng)過(guò)混淆、自解密代碼轉(zhuǎn)換等處理后得到的等價(jià)代碼如程序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)過(guò)混淆、自解密代碼轉(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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖6 相似度重打包檢測(cè)流程

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

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

圖7 計(jì)算兩個(gè).apk文件的相似度

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

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

表1 檢測(cè)性能對(duì)比

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

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

3.1 系統(tǒng)框架

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

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

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

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

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

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

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

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

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

3.2 改進(jìn)分析

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

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

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

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

4 結(jié) 語(yǔ)

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