周立博,梁 彬,游 偉,黃建軍,石文昌

中國人民大學信息學院 北京 中國 100872

1 引言

根據(jù)國際數(shù)據(jù)公司IDC 發(fā)布的統(tǒng)計資料,近五年來,安卓系統(tǒng)的市場份額穩(wěn)定在85%以上[1],安卓應用生態(tài)一片繁榮。但與此同時,安卓應用也面臨著嚴重的重打包威脅。Zhou 等人[2]的研究顯示,有85%以上的惡意應用是重打包應用。

為了有效降低惡意重打包應用所帶來的危害,如圖 1 安卓應用重打包威脅模型所示,研究人員從開發(fā)者、應用市場和應用安全服務商三個角度出發(fā),提出了不同的重打包攻擊對抗方式:①開發(fā)者實施重打包防御策略,對應用進行加固,提高攻擊者構建重打包應用的難度。常見的策略有防篡改檢查[3-4]、代碼混淆[5-7]、應用反調試和信息隱藏等。這種方式部署靈活,開發(fā)者可以根據(jù)需要配置不同的防御策略,保護通過不同渠道發(fā)布的應用。②應用市場對應用進行靜態(tài)重打包應用檢測,通過重打包應用與原應用的相似性[8-17]進行檢測,限制重打包應用通過應用市場傳播。③應用安全服務商在應用安裝和執(zhí)行時收集特征信息來進行重打包應用檢測。常見的檢測方式有安裝時簽名校驗,運行時UI 相似度檢測[18-20]等。

在上述對抗方式中,開發(fā)者利用安卓應用重打包工具的實現(xiàn)缺陷來加固應用,中斷圖 1 中的反編譯環(huán)節(jié),是一種有效的重打包防御策略。但目前僅有少數(shù)工作對其進行研究,Tim Strazzere[21]指出可以利用反編譯工具解析dex 文件的一個特定缺陷來中斷重打包工具對APK 的解析操作。盡管該缺陷目前已被修復,但證明了該思路的可行性。自然地,我們想要知道,如何系統(tǒng)化地發(fā)現(xiàn)更多重打包工具中的缺陷？

針對這一問題,我們提出了一種面向重打包對抗的重打包工具可利用缺陷檢測方法。如圖 2 所示,本方法能夠盡可能地檢出重打包工具中的可利用缺陷。開發(fā)者可以利用這些缺陷對應用進行加固,加固后的應用可以在目標安卓設備中正常運行而無法被重打包工具正常解析。與其它由開發(fā)者實施的重打包攻擊對抗技術(如防篡改檢查、代碼混淆、應用反調試和信息隱藏等)相比,本文提出的方法具有易于實施、運行時開銷小等優(yōu)勢。同時,該方法與其它加固方法互補,能夠與其他加固方法共同使用,進一步提高應用抗重打包的能力。

本方法利用重打包工具中缺陷與異常的聯(lián)系將對缺陷的檢測轉換到對重打包工具中潛在異常點的研究上來。這一轉換基于我們的以下觀察:①重打包工具中的文件解析缺陷能夠導致其對APK 的解析失敗,使得重打包工具不能輸出正確的反編譯結果。這一特性可用于對安卓應用進行加固。②重打包工具中的文件解析缺陷主要由程序執(zhí)行過程中未經處理的異常引起?，F(xiàn)有工作[21]中對重打包工具解析缺陷的利用證明了我們觀察的合理性。此外,我們在研究過程中發(fā)現(xiàn),一些知名的應用程序(如作業(yè)幫、Instagram)也基于類似觀察進行應用加固。

本工作的主要貢獻有以下兩點:

1) 提出了一種面向重打包對抗的重打包工具解析APK 文件的實現(xiàn)缺陷檢測方法,以發(fā)現(xiàn)可利用的缺陷來加固應用。該方法利用重打包工具文件解析缺陷與異常的聯(lián)系,把對缺陷的檢測轉換為對重打包工具中潛在異常點的定位、觸發(fā)和可利用性確認。

2) 我們以當下最流行的重打包工具Apktool[22]作為實驗對象,在Apktool 2.4.1 中找到了12 個未知的可利用的解析缺陷。并利用這些缺陷對真實應用進行了加固,加固后的應用不能被Apktool 重打包,證明了方法的實際價值。

2 背景知識

為了對應用進行重打包,攻擊者可能會使用多種重打包工具對APK(Android package)文件進行解析。常見的重打包工具有Apktool、Jadx、dex2Jar 等。在眾多重打包工具中,Apktool 使用最為廣泛,是本文的重點研究對象。為了便于讀者對本文檢測方法的理解,本節(jié)對Apktool 和重打包工具中的文件解析異常進行簡要介紹。

Apktool 是主要由Ryszard Wi?niewski 與Connor Tumbleson 開發(fā)和維護的開源安卓重打包工具。Apktool 功能完善,能夠反編譯resources.arsc、dex文件、png 格式的圖像文件和二進制的xml 文件(包括AndroidManifest.xml 文件與res 目錄下壓縮后的xml 資源文件等)并在之后對其進行回編譯。其使用Java 語言實現(xiàn)對APK 的反編譯,利用安卓官方提供的打包工具aapt 或aapt2 進行回編譯生成未簽名的重打包應用。

APK 文件本質上是ZIP 格式的壓縮文件,重打包功能提供對壓縮文件中部分或全部文件的解析功能。重打包工具對文件的解析通常是順序進行的,即一次解析壓縮文件中一個或一組文件。當重打包工具中存在文件解析缺陷時,重打包工具可能會因為某些文件解析失敗而終止運行導致APK 解析失敗。而重打包工具的文件解析過程通?；谔囟ǖ奈募袷?。當遇到不符合工具開發(fā)者設定格式的文件時,程序通常會產生異常,若開發(fā)者認為該異常無法被處理,則重打包工具則會因為該異常而終止執(zhí)行。但如果此時安卓操作系統(tǒng)能夠對該應用正常解析,我們就可以認為重打包工具在實現(xiàn)上具有缺陷。由這一思路出發(fā),本文提出了重打包工具解析缺陷的檢測方法,第三節(jié)是對這一方法的具體介紹。

3 方法設計

本方法的指導思想是通過檢測重打包工具解析APK 文件的實現(xiàn)缺陷,以發(fā)現(xiàn)能夠用于加固應用的可利用缺陷。我們設計了包含二次模糊測試的缺陷檢測方法,通過尋找可利用的異常點來檢測重打包工具中的缺陷。我們以當下最流行的重打包工具Apktool 為研究對象,對本方法的具體實現(xiàn)進行介紹。

圖3 是本方法的總體流程圖。如圖所示,本方法分可主要分為潛在異常點定位、基于模糊測試的異常觸發(fā)和包含二次模糊測試的異常點可利用性確認三個階段。首先,在異常定位階段,我們使用靜態(tài)分析的方法對應用代碼進行掃描,確定潛在的異常點;其次,在異常觸發(fā)階段,我們使用模糊測試的方式來生成測試應用,根據(jù)Apktool 解析測試應用的日志判斷異常是否被觸發(fā);最后,在異常點可利用性確認階段,確認潛在異常點能否用于應用加固,并對部分無法直接確認可利用性的異常點進行第二次模糊測試。

下面,我們對本方法的每個環(huán)節(jié)的具體實現(xiàn)進行詳細介紹。

3.1 潛在異常點定位

在進行異常定位前,我們首先要了解Apktool 中的異常。由前文我們對Apktool 的介紹可知,Apktool進行APK 解析部分的代碼由Java 語言編寫。Java 語言提供了良好的錯誤處理機制,其使用Throwable 類的眾多子類來描述各種不同的異常,為開發(fā)者提供了try,catch 語句捕獲和處理異常。

在本方法中,我們將Java 語言中的潛在異常點分為兩類:顯式異常點和隱式異常點。顯式異常點指使用throw 關鍵字拋出異常的語句,如圖 4 中第12行和第18 行所示。隱式異常點指的是,開發(fā)者沒有主動進行異常處理的可能導致運行時異常的代碼塊。圖 4 中的array函數(shù)包含了一個隱式異常點實例,在第23 行,參數(shù)x沒有經過檢查就被當作數(shù)組初始化的下標使用。當參數(shù)x為負值時,程序會在運行時拋出異常Java.lang.NegativeArraySizeException,同時沒有異常處理語句對此異常進行捕獲處理。在本工作中,我們僅關注那些可能導致重打包工具解析終止的異常點,過濾掉被已被捕獲處理的異常點。圖4 中test1函數(shù)僅在invoke函數(shù)中被調用(第3 行),其拋出的異常會在invoke函數(shù)中被捕獲處理(4～6 行),因此我們將忽略test1函數(shù)中的異常點。

為了進行潛在異常點的定位,我們實現(xiàn)了基于Soot[23]的代碼掃描工具。其工作流程如圖5 所示。首先,掃描器將輸入的Java 字節(jié)碼轉換為Jimple 中間代碼,生成程序的函數(shù)調用圖(Call Graph,CG)和控制流圖(Control Flow Graph,CFG)。在生成的CFG 中包含從throw 子句到catch 模塊的邊和從隱式異常點的前驅節(jié)點到異常處理語句的邊。我們可以在遍歷過程中獲得可能的異常點。然后,如算法1 所示,通過嘗試匹配異常點與其try 模塊來確認其是否被捕獲處理,過濾掉那些已經被捕獲處理的異常點。

算法1 異常過濾

3.2 基于模糊測試的異常觸發(fā)

由于不是所有異常點都能夠被觸發(fā),我們需要通過異常觸發(fā)測試篩選出可觸發(fā)的潛在異常點。如圖 6 所示,這一階段的主要步驟包括:①通過重打包工具插樁和測試獲得異?？赡鼙挥|發(fā)時所處的解析階段和對應的解析文件類型;②根據(jù)待檢測的異常和其對應解析文件類型生成變異應用;③使用Apktool 解析測試應用,確認異常觸發(fā)情況。

異常點對應觸發(fā)文件類型關系獲取

本階段的目的是獲得APK 中不同的文件類型可能觸發(fā)的異常點,以此加速后續(xù)的模糊測試。在整個方案中,該步驟只需進行一次。我們首先對Apktool正常解析APK 獲得的日志進行分析,發(fā)現(xiàn)Apktool對APK 中不同部分的解析相對獨立,每一段解析開始時均會輸出特定的日志?？梢愿鶕?jù)日志區(qū)分Apktool 開始解析不同類型文件的順序,在該日志輸出處插入相應的開關變量,標識相應的解析流程。Apktool 對不同類型文件的解析順序如表 1 所示。

表1 Apktool 對安卓應用中不同類型文件的解析順序Table 1 The order of parsing files of different types in Apks with Apktool

接下來我們依據(jù)Apktool 的解析流程和已獲得的異常點進行代碼插樁操作。圖 7 展示了我們的插樁結果:在Apktool中加入Phase類,使用靜態(tài)域now表明當前屬于哪個分析階段。在異常點所在控制流的第一個條件跳轉語句前添加日志輸出語句,記錄可能觸發(fā)的異常。

插樁工作完成后,我們使用插樁后的Apktool 對測試應用進行解析,獲得輸出日志之后就可以根據(jù)日志信息確定對應異常觸發(fā)與APK 中文件類型的對應關系。圖8 展示了插樁后的Apktool 解析多看閱讀應用的實例,根據(jù)日志片段,我們可以看到StringBlock 類中的getUtf8與getUtf16函數(shù)中存在的異?？赡軙贏ndroidManifest.xml 和res 目錄下資源文件解析的過程中被觸發(fā)。

·變異應用生成

由于APK 本質上是一個ZIP 格式的壓縮文檔,而ZIP 文件中存在大量文件有效性檢查。例如,ZIP文件的本地文件頭中的CRC-32 校驗值,核心目錄頭中存儲的其相對本地目錄頭的偏移量,對這些變量的修改會導致APK 無法通過ZIP 格式校驗。

為此,我們采用變異解壓后的文件,再重新壓縮,簽名的方式生成用于測試的變異應用。本質而言,我們的模糊測試是一種以字節(jié)為單位進行變異的針對特定目標文件和特定異常點的定向模糊測試。其中的關鍵環(huán)節(jié)包括變異文件選擇和具體的文件變異方式。

1) 變異文件選擇

首先根據(jù)需要探測的異常點和APK 中文件類型之間的對應關系,確定可能觸發(fā)異常點的文件類型。接著遍歷APK 內的文件,從滿足類型且在之前的測試中沒有被選中的文件中,找到體積最小的文件作為輸出結果。通過變異文件的選擇,我們可以減小每次測試過程中進行變異的選擇范圍,提高模糊測試效率。

2) 具體的文件變異方式如圖 9 所示,對于每一個文件,我們以單字節(jié)為基本單位對文件進行變異。這主要是因為重打包工具通常以字節(jié)作為單位進行讀取,因此以字節(jié)為基本單位進行變異是一個自然的選擇。從文件頭開始,逐字節(jié)將原始位置變異為0x00-0xFF 之間的一個隨機值。每變異一個字節(jié)生成一個新文件,用“源文件名_文件名_位置_變異值”的方式命名變異后的文件。在后續(xù)的測試過程中,Apktool 測試輸出的日志同樣按照此規(guī)律進行命名,根據(jù)日志文件名就可以確定對應測試應用變異的字節(jié),避免因存儲大量變異應用而帶來的存儲開銷。

·Apktool 異常觸發(fā)確認

生成變異應用以后,我們使用Apktool 對測試應用進行解析,生成對應的日志文件。此時,若日志文件中存在報錯信息且應用解析提前停止,我們就認為異常被觸發(fā),可以從日志文件中得到異常的相關信息。否則,我們認為這次變異沒有導致異常被觸發(fā)。

3.3 異常點可利用性確認

為了保證利用缺陷加固的應用在使Apktool 解析出錯的同時能夠在目標安卓設備上正常運行,我們對應用進行異常點可利用性確認。確認流程如圖 10所示,包含兩個主要流程:執(zhí)行監(jiān)測和第二次模糊測試。下面對這兩階段進行詳細介紹。

·執(zhí)行監(jiān)測

在應用執(zhí)行監(jiān)測環(huán)節(jié),我們需要判斷變異應用能否在目標安卓系統(tǒng)上正常運行。因此,我們需要對應用的正常運行狀態(tài)進行刻畫?？紤]到變異應用可能會影響原始應用的正常功能,而從市場下載的應用正常功能對于測試而言是未知的。同時可能存在其他反重打包措施導致變異應用無法直接運行。因此我們考慮直接開發(fā)一個測試應用作為兩次模糊測試的種子應用。為了使種子應用能夠觸發(fā)盡可能多的解析異常,我們根據(jù)合法APK 所可能包含的內容,在應用中添加對應資源,如在res/目錄下添加menu,assets 等非必須資源項,并在相應的Activity 進行加載和調用。同時為了便于測試,我們將對不同資源的訪問分布在不同的Activity 下,通過配置Activity 的屬性,使得應用更易于用adb 進行調試。我們對Activity的配置如圖 11所示,我們將所有的Activity都設置為可通過顯示意圖直接啟動,之后就可以使用腳本來啟動Activity,加載對應的資源文件,收集程序運行時的日志信息,來監(jiān)測應用的執(zhí)行狀況。

·進一步模糊測試

在執(zhí)行檢測過程中,我們發(fā)現(xiàn)一些異常能夠使Apktool 在解析APK時崩潰,同時對應變異應用無法在安卓手機上正常執(zhí)行。圖 12 展示了一個此類待確認異常。

在對測試應用中res/layout 目錄下一個布局文件進行變異后,該異常被觸發(fā)并導致Apktool 崩潰,但變異應用無法在安卓系統(tǒng)上正常運行。圖 13 展示了其在實際執(zhí)行中產生的崩潰日志。

我們認為對于此類異常已經體現(xiàn)了重打包工具與安卓系統(tǒng)在解析APK 上的差異,通過后續(xù)人工分析造成差異的原因可能將此類異常利用起來。接著我們將此變異測試應用作為模糊測試的種子,對該文件進行變異。根據(jù)日志分析判斷對應的測試應用所變異的字節(jié)與待確定異常是否相關。

4 實驗評估

在本章,我們將用實驗來評估我們的方案在Apktool 上的具體實現(xiàn)。首先,我們對實驗中的環(huán)境和使用的數(shù)據(jù)做簡要介紹(4.1 節(jié));接著,我們對通過實驗找到的可利用異常進行介紹,并對其中的部分實例進行解析(4.2 節(jié));然后,我們對本方法的性能開銷進行分析(4.3 節(jié));最后,我們以LinkedIn 為例,展示了兩個可利用異常對實際應用進行加固的過程和效果(4.4 節(jié))。

4.1 實驗環(huán)境及數(shù)據(jù)

我們在Java 環(huán)境中實現(xiàn)了對Apktool 字節(jié)碼的靜態(tài)分析和插樁工作,使用Python 語言編寫腳本進行模糊測試和應用在安卓設備上運行情況監(jiān)測。實驗用到的PC 配置為16GB 內存,6 個2.1GHz 內核和1TB 硬盤,安卓手機型號是小米6,安卓系統(tǒng)版本為9.0。

我們的實驗主要有以下兩個數(shù)據(jù)來源:

1) 測試應用:測試應用集合來自豌豆莢與Apkpure。其中包含豌豆莢應用分類排行榜14 個分類中,每類的前50 個應用,Apkpure 中分類排行榜32個分類中每類前10 個應用,總測試應用共計有1020個。在異常點對應觸發(fā)文件類型關系獲取階段,我們使用插樁后的Apktool 對測試應用進行解析,獲得異常和APK 壓縮包中文件類型之間的對應關系。

2) 種子應用:我們在進行模糊測試時使用自己開發(fā)的測試應用作為種子應用,以避免應用市場中包含重打包檢測,代碼混淆和資源混淆的應用對實驗結果造成影響。

4.2 實驗結果與實例分析

通過實驗與人工分析,在Apktool 2.4.1 上共發(fā)現(xiàn)343 個異常,總共確認了12 個未知的可利用的缺陷,與缺陷相關的可利用異常點的詳細信息如表2所示,下面我們對找到的異常及其拋出這些異常的解析缺陷進行分析。

表2 可利用異常點Table 2 Available exception points

·拋出顯式異常的解析缺陷

圖14 展示了ExtDataInput 類中被確認的顯式異常。在異常定位階段,我們能夠通過對代碼的解析,定位到該throw 語句,并逐級檢查該函數(shù)拋出的異常有沒有被調用者用catch 語句捕獲。最終我們能夠從找到從main函數(shù)到該函數(shù)的路徑,確認在main函數(shù)拋出的異常中可能包含此異常,因此將其作為可能的異常。之后在變異arsc 文件的過程中得到的變異應用觸發(fā)了該異常,且能夠在目標設備上正常運行。由此我們確認其是一個可利用異常。

·拋出隱式異常的解析缺陷

圖15 展示了ARSCDecoder 類中的一個隱式異常,該隱式異常同樣與數(shù)組操作相關。圖中packageCount變量從文件中獲取,后續(xù)作為數(shù)組的大小在初始化時被使用。與StringBlock 類中的例子類似,該值同樣可能為負值,導致拋出Java.lang.NegativeArraySizeException 異常。

但 Android 系統(tǒng)去解析 APK 時,并不關心packageCount對應的字節(jié)。該解析差異導致此異常被觸發(fā)的同時,應用能夠在手機上正常運行。

·需要進一步探測的解析缺陷

以3.3 節(jié)我們討論的異常為例,在使用種子應用進行模糊測試測試的過程中我們注意到,若在第一輪探測中當變換res/layout/activity_main.xml 中第64個字節(jié)為0xFF 時,會導致第318 行offset值為負值,觸發(fā)Java.lang.NegativeArraySizeException 異常。但該應用無法在手機上正常運行。于是我們將此變異測試應用作為模糊測試的種子進行第二輪fuzz操作。

通過這種方式,我們可以發(fā)現(xiàn)異常的關鍵輸入,如圖 16所示。確認了arsc文件中與其對應的關鍵字節(jié),通過觀察可以得知其儲存著值res/layout/activity_main.xml,即我們變異的文件。經過進一步分析,我們可以從中獲得一種加固應用的新方法:向res/layout 目錄下插入無意義的損壞布局文件,同時在對應的索引文件中添加相應的索引值。這樣由于Apktool 會依據(jù)索引值對APK 中的文件進行解析,重打包工具將會在解析到我們添加的損壞布局文件時出錯。而無意義的布局文件不會在系統(tǒng)中被解析,使得加固后的安卓應用能夠在目標安卓設備上正常執(zhí)行。

4.3 性能開銷

本文方案在實現(xiàn)上可以大致分為三個階段:潛在異常點定位、異常觸發(fā)和異?？衫眯源_認。在潛在異常點定位階段,我們主要對Apktool 進行靜態(tài)分析,這一步驟需要對重打包應用的CG 和CFG 進行遍歷。靜態(tài)分析階段在整個方案中僅需執(zhí)行一次,即使消耗時間較長也在可接受范圍內。在異常觸發(fā)階段,會進行大量變異操作并使用Apktool 進行解析,消耗時間較長。在異?？捎眯源_認階段,我們能夠利用異常觸發(fā)階段的結果,跳過部分可能導致異常的變異探測,從而加速關鍵字節(jié)的探測過程。每個階段的詳細耗時情況如表3 所示。

從表3 可以看出,異常查找花費時間最少,平均時間在1.05 s 左右,異常觸發(fā)花費時間最長,平均每個異常被觸發(fā)需要十分鐘以上。在異常利用階段因為已經獲得觸發(fā)階段的數(shù)據(jù),平均每個異常耗時600 s 要低于異常觸發(fā)階段,符合我們的預期。

表3 各階段耗時統(tǒng)計Table 3 Time consuming statistics of each stage

4.4 實例驗證

在實例驗證階段,我們從豌豆莢和Apkpure 中挑選了9 個真實應用,使用已檢測到的缺陷進行應用加固驗證。9 個應用可以按大小分為三組,1～3 號小型應用(1～20MB),4～6 號中型應用(20～100MB),7～9 號大型應用。每組應用從來自豌豆莢中的測試應用中隨機選出,為了體現(xiàn)Apkpure 商店與豌豆莢的差異,我們使用Apkpure 特有的應用替換部分測試應用。得到了最終的真實應用列表,如表 4 所示。

表4 真實應用列表Table 4 Real application list

接下來我們以常見的LinkedIn 應用為例,展示我們利用4.2 節(jié)已分析的部分異常點對實際應用的加固效果和加固細節(jié)。如圖 17 所示,在應用加固前后,應用功能和用戶界面沒有發(fā)生變化,加固后應用能夠在目標安卓設備上正常運行。

下面介紹應用的加固細節(jié)。skipCheckShort函數(shù)中異常對應的解析缺陷是Apktool 在解析arsc 文件時對Entry 資源項數(shù)值讀取的額外檢查。進行檢查的語句為 ARSCDecoder 類readValue方法中的mIn.skipCheckShort((short) 8),該語句檢查讀入的數(shù)值是否為0x08,當檢測到的值不是0x08 時,拋出顯式異常。由此,我們首先對LinkedIn 應用中arsc 文件的部分Entry 項進行修改,將對應的0x08 替換成0xFF,如圖 18 所示。

接著用修改后的arsc 文件替換原arsc 文件生成LinkedIn 的重打包應用com.linkedin.android_1.apk。重打包應用能夠在手機上正常運行,使用Apktool 無法正常進行解析,在解析過程中拋出異常:brut.androlib.AndrolibException:Could not decode arsc file。同樣的,我們也可以利用隱式異常使得Apktool 拋出運行時異常。圖 19 展示了對readTableHeader函數(shù)中隱式異常的利用。

通過變異arsc 文件起始的第9～12 個字節(jié),使預期對應的packageCount值為–1,最終導致Apktool在解析過程中拋出異常:Exception in thread "main"Java.lang.NegativeArraySizeException。

類似地,我們可以利用其他缺陷對應用進行加固。加固后的應用在目標設備上正常運行地同時能夠使Apktool 解析異常。限于文章篇幅,其他異常點的利用情況不再一一贅述。

5 討論

文件變異方式:在本文中,我們以單字節(jié)為基本單位對文件進行變異。這主要是因為重打包工具通常以字節(jié)作為單位進行讀取,因此以字節(jié)為基本單位進行變異是一個自然的選擇。另一個可能的選擇是以比特為單位進行變異,這種變異方式可能會提高觸發(fā)異常的可能性,但是在模糊測試階段會帶來較大的性能開銷。在未來工作中,我們將深入探索不同變異策略的異常觸發(fā)效果及性能開銷。

方法自動化程度提升:本方法在執(zhí)行檢測環(huán)節(jié),根據(jù)日志判斷應用是否在目標系統(tǒng)上正常運行。目前,應用不能正常運行的具體原因需要人工對日志內容進行分析確認。在實驗過程中,我們發(fā)現(xiàn)從日志中提取出的關鍵字能夠反映出應用不能正常運行的原因。在未來工作中,我們擬設計啟發(fā)式規(guī)則,根據(jù)日志內容提取出的關鍵字,確定應用崩潰原因。

方法有效性:本工作提出了一種新的應用自我保護策略來對抗安卓應用重打包技術——利用安卓應用重打包工具解析APK 的實現(xiàn)缺陷對應用進行加固。盡管目前在本方案中發(fā)現(xiàn)的Apktool 解析缺陷可能在后續(xù)版本中被修復,但這一思路能夠被應用加固廠商借鑒,將其擴展到其他重打包工具如jadx,dex2jar 等,并發(fā)現(xiàn)新版本中可能存在的缺陷。對于攻擊者來說,通過本方案加固的應用能夠增加其重打包應用的難度。即使攻擊者已經獲得了可能會導致重打包工具出錯的異常點,也要對重打包工具或加固后的應用進行修改。提高了其進行攻擊的時間成本,在一定程度上能夠起到提高重打包攻擊技術門檻的效果。

6 相關工作

對于如何抵抗安卓重打包攻擊,目前主要有三種防御方法:一是開發(fā)者對應用進行加固,在應用中實施自我保護策略;二是在應用市場方面進行的靜態(tài)重打包應用檢測;三是在應用安裝或執(zhí)行時由可靠的應用安全服務提供商進行動態(tài)重打包應用檢測。

應用重打包對抗的一種主流方式是開發(fā)者進行應用加固,既在應用中實施應用自我保護策略,常見的策略有防篡改檢查、代碼混淆、應用反調試和信息隱藏等。防篡改檢查是指在應用中添加代碼檢測應用自身是否被篡改。為了加強防篡改檢查代碼的安全性,Luo 等人[3]在應用中分散插入大量檢測代碼來使得攻擊者難以定位所有檢測代碼,Zeng等人[4]在方案BombDroid 中創(chuàng)造性地利用經常在惡意軟件中使用的邏輯炸彈來檢測攻擊者對應用的修改。代碼混淆技術通過對應用的控制流[5]、程序中涉及到的標識符和字符串進行混淆[6-7],通過提高攻擊者分析混淆代碼難度來對應用進行保護。應用反調試則通過在應用中添加調試檢測代碼來進行判斷應用執(zhí)行狀態(tài),阻礙攻擊者通過調試進行動態(tài)分析。提高攻擊者重打包應用的難度。信息隱藏技術是指通過加密等方式隱藏部分關鍵代碼,提高攻擊者對代碼進行分析的難度。本質而言,本文提出的方法屬于由開發(fā)者實施的重打包攻擊對抗技術。相比于已有的防篡改檢查、代碼混淆、應用反調試等策略,本文提出的方法具有易于實施、運行時開銷小等優(yōu)勢。同時,該方法與其它加固方法互補,能夠與其他加固方法共同使用,進一步提高應用抗重打包的能力。

重打包應用檢測技術以重打包應用與原應用之間的相似性為基礎,通過特征選取,相似性比較來判斷待檢測應用是否為重打包應用。根據(jù)選取特征的方式,重打包應用檢測技術可以進一步分為兩種類型:靜態(tài)重打包應用檢測和動態(tài)重打包應用檢測。靜態(tài)重打包應用檢測對APK 進行靜態(tài)分析,選取不同的應用特征如應用代碼、API 調用序列、代碼中包含的控制流信息、應用功能、資源文件等作為相似性度量的基礎。Zhou 等人[8]在安卓發(fā)展的早期就實現(xiàn)了一款名為DroidMoss 的相似性度量系統(tǒng)。該系統(tǒng)從dex 文件中抽取指令序列作為待測應用的初步特征,接著計算指令序列的模糊哈希(Fuzzy Hashing)值作為該應用的指紋信息,最后通過兩兩計算應用指紋之間的編輯距離來確定第三方市場中是否存在重打包應用。文獻[9-10]發(fā)現(xiàn)大量第三方庫的使用會導致基于dex文件的相似性檢測系統(tǒng)產生誤報,提出了兩階段的檢測方案:在進行特征提取前首先對應用使用的庫進行檢測,移除第三方庫代碼后再進行特征提取操作。Chen 等[11]的團隊與 Marastoni 等[12]團隊對代碼做進一步處理,將代碼之間的控制流信息作為相似性比較的基礎。Marastoni 等人為了獲得更好的檢測效果,還額外提取了API 的調用情況作為第二特征來刻畫應用。Abdurrahman 等人[13]與Fan等人[14]利用機器學習技術,從程序的API 調用情況出發(fā)訓練分類器進行重打包應用的檢測。文獻[15-17]基于重打包應用與原應用UI 的高度相似性,提出不同的檢測方法,對重打包應用進行檢測。

應用安全服務提供商常用動態(tài)重打包檢測來進行重打包應用檢測。他們可以在應用執(zhí)行時收集應用特征來進行重打包應用檢測。文獻[18-20]收集應用運行時產生的UI 信息來進行相似性檢測,文獻[24]提出了一種收集程序運行時API 調用信息作為檢測依據(jù)的方法,文獻[25]提出了一種向應用中添加水印信息并在運行過程中進行檢查的重打包應用檢測方式。

7 總結與展望

本文提出了一種面向重打包對抗的重打包工具可利用缺陷檢測方法,能夠發(fā)現(xiàn)可用于加固應用的重打包工具文件解析缺陷。首先,我們使用靜態(tài)代碼分析的方式對重打包應用進行代碼掃描,定位可能的異常點;其次,使用模糊測試技術觸發(fā)異常,獲得異常對應的關鍵輸入;然后,監(jiān)測觸發(fā)異常的變異應用在目標安卓設備上的運行情況,對異常的可用性進行確認,并進行進一步的模糊測試來輔助研究者構建能被用于對抗重打包攻擊的異常觸發(fā)向量。在以重打包工具Apktool 2.4.1 為實驗對象的測試中,我們總共發(fā)現(xiàn)了12 個未知的可利用的缺陷。所有這些缺陷都已被證明可用于實際應用中,能夠有效對抗重打包攻擊,證明了本工作的可用性。

盡管已經可以利用本方法檢測出Apktool 中未知的可利用缺陷,但本工作仍存在一定不足和需要改進的地方。

一是在其他重打包工具上進行推廣驗證。當前我們針對Apktool 進行實驗驗證,未來我們將在后續(xù)工作中將本方法推廣應用到其他重打包工具上。

二是增加對其他重打包階段的考慮。應用的重打包過程通常需要經歷反編譯與回編譯兩個階段。在本文的工作中,我們主要考慮Apktool 在反編譯方面可能引起的異常,缺少對回編譯階段的分析。為此,我們要在將來的后續(xù)工作中加入對回編譯階段異常的利用,實現(xiàn)對重打包工具的全流程覆蓋。