Android重包裝應(yīng)用程序靜態(tài)分析系統(tǒng)的設(shè)計(jì)

孫翌博+邰淳亮+宮婧

摘 要：本文以Android重包裝應(yīng)用程序的檢測(cè)為研究?jī)?nèi)容，通過(guò)對(duì)當(dāng)前主流的靜態(tài)分析技術(shù)進(jìn)行對(duì)比與總結(jié)，提出了一種基于眾包的Android重包裝應(yīng)用程序靜態(tài)分析方法。該方法選取能表征Android應(yīng)用程序唯一性的信息作為特征字符串，利用眾包構(gòu)建Android應(yīng)用程序注冊(cè)與數(shù)據(jù)庫(kù)服務(wù)平臺(tái)，對(duì)比簽名鑒別重包裝應(yīng)用程序。最后為驗(yàn)證所提出方法的有效性，構(gòu)建原型系統(tǒng)進(jìn)行實(shí)驗(yàn)測(cè)試。實(shí)驗(yàn)結(jié)果表明，本方法能夠有效進(jìn)行Android重包裝應(yīng)用程序的靜態(tài)分析。

關(guān)鍵詞：Android應(yīng)用程序 重包裝 靜態(tài)分析 眾包

中圖分類號(hào)：TP399 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1672-3791（2017）10（b）-0119-03

1 相關(guān)技術(shù)研究

現(xiàn)在的Android惡意應(yīng)用程序分析方法主要是利用動(dòng)態(tài)分析技術(shù)或靜態(tài)分析技術(shù)進(jìn)行惡意應(yīng)用的檢測(cè)。Android惡意程序的各種攻擊方式中，應(yīng)用程序重新打包是極為常見的手段。文獻(xiàn)[1]研究發(fā)現(xiàn)，當(dāng)攻擊者通過(guò)反編譯手段獲得一個(gè)良性Android應(yīng)用程序的源碼后，可以實(shí)施的惡意操作通常有三類。

（1）注入廣告SDK。向原程序中加入廣告SDK，實(shí)現(xiàn)廣告收入。

（2）替換應(yīng)用內(nèi)廣告。替換掉原程序作者在其應(yīng)用中設(shè)置的廣告SDK的發(fā)布者ID，實(shí)現(xiàn)竊取程序開發(fā)者的廣告收入。

（3）添加惡意代碼。在大體了解代碼流程的基礎(chǔ)上，加入惡意代碼片段，使得用戶執(zhí)行過(guò)程中觸發(fā)惡意操作。

前兩種惡意操作方式主要是對(duì)知識(shí)產(chǎn)權(quán)的侵害，后一種的危害則是十分巨大的。攻擊者在實(shí)施惡意操作后只需要重新打包簽名形成新的安裝包APK文件就可以上傳至應(yīng)用商城。用戶看到的貌似是正常的一款應(yīng)用程序安裝包，安裝后也能使用程序功能，但Android終端實(shí)際上已經(jīng)遭到了惡意程序的入侵。文獻(xiàn)[1]研究顯示許多流行的Android應(yīng)用程序包括QQ、AngryBirds等都已經(jīng)出現(xiàn)了被重包裝的情況。

由于靜態(tài)分析不需要運(yùn)行程序，可以實(shí)現(xiàn)代碼的全覆蓋以及沒(méi)有運(yùn)行時(shí)開銷等優(yōu)勢(shì)，特別適合進(jìn)行Android重包裝應(yīng)用程序的分析。文獻(xiàn)[2]就設(shè)計(jì)了一種DroidMOSS檢測(cè)系統(tǒng)，對(duì)官方來(lái)源的應(yīng)用實(shí)現(xiàn)反編譯獲得源碼，然后采用模糊哈希技術(shù)對(duì)程序切片提取Android應(yīng)用行為模式作為特征形成指紋，構(gòu)建應(yīng)用數(shù)據(jù)庫(kù)進(jìn)行分析。該研究發(fā)現(xiàn)第三方應(yīng)用商城中至少有5%至13%的Android應(yīng)用存在重新包裝的情況，多數(shù)植入了惡意代碼和添加了廣告SDK，情況不容樂(lè)觀。但是該方法對(duì)于惡意攻擊者可以在代碼中加入無(wú)效冗余代碼以降低形成指紋的相似性來(lái)逃避分析和可以進(jìn)行高度的混淆加密進(jìn)而導(dǎo)致無(wú)法生成指紋的情況沒(méi)有考慮到。

文獻(xiàn)[3]則綜合選取了Android應(yīng)用程序的簽名、權(quán)限和可執(zhí)行文件作為對(duì)比的依據(jù)，指標(biāo)具有綜合性。但是該方案仍然存在文獻(xiàn)[2]中需要在源代碼中嵌入代碼的缺點(diǎn)，適用性比較受限。

綜上，如何快速、有效地分析Android平臺(tái)中重包裝應(yīng)用程序仍是亟待解決的問(wèn)題。主要難點(diǎn)就是如何快速判斷兩個(gè)安裝包APK文件是屬于同一個(gè)程序。事實(shí)上，只要能夠知道兩款軟件其實(shí)是一個(gè)程序，那么比較一下程序的開發(fā)者簽名，就能夠立即得知其中是否存在重包裝的情況。

2 基于眾包的Android重包裝應(yīng)用程序靜態(tài)分析方法

2.1 眾包機(jī)制

眾包（crowdsourcing）指的是一個(gè)公司或機(jī)構(gòu)把過(guò)去由員工執(zhí)行的工作任務(wù)，以自由自愿的形式外包給非特定的大眾網(wǎng)絡(luò)的做法。它本身描述了一種新的商業(yè)模式，現(xiàn)在也指從廣泛群體，特別是在線社區(qū)，獲取所需想法、服務(wù)或內(nèi)容貢獻(xiàn)的實(shí)踐。在軟件安全性分析領(lǐng)域，眾包多用來(lái)收集數(shù)據(jù)，需要社會(huì)成員廣泛的參與，可以取得很好的效果[4]。但與此同時(shí)，眾包也會(huì)帶來(lái)很大的隱私爭(zhēng)議[5]。

近年來(lái)，文獻(xiàn)[5]都提出使用眾包（crowdsourcing）機(jī)制來(lái)參與Android應(yīng)用程序的分析，希望通過(guò)監(jiān)測(cè)大量真實(shí)的用戶使用程序的數(shù)據(jù)，來(lái)獲取充足特征值判斷程序的性質(zhì)。本文即是基于此提出了一種基于眾包的Android重包裝應(yīng)用程序靜態(tài)分析方法，使用眾包機(jī)制搜集信息來(lái)判斷程序的一致性，以此來(lái)快速分析程序重新打包問(wèn)題，并設(shè)計(jì)了一種高效的重包裝分析原型系統(tǒng)。

2.2 特征獲取

分析Android重包裝應(yīng)用程序首要解決的問(wèn)題就是如何判斷兩個(gè)安裝包APK文件是屬于同一個(gè)程序。判斷安裝包APK文件是否屬于同一個(gè)程序，Android本身是提供現(xiàn)有機(jī)制的。Android應(yīng)用程序發(fā)布時(shí)會(huì)生成一個(gè)APK文件，即應(yīng)用程序的安裝文件，其本質(zhì)上是一個(gè)zip格式的壓縮包。除了源代碼及資源文件，它還包含名為AndroidManifest.xml的清單文件，以向Android系統(tǒng)聲明必要的信息，見圖1。

Android系統(tǒng)使用包名（Package Name）來(lái)唯一標(biāo)識(shí)一個(gè)應(yīng)用程序，包名在開發(fā)時(shí)由開發(fā)者指定，位于清單文件AndroidManifest.xml的“package”屬性。包名相同的程序可以升級(jí)覆蓋原先版本的程序。除了包名，AndroidManifest.xml清單文件Int類型的android：versionCode主要用于版本標(biāo)識(shí)，確定升級(jí)信息。String類型的android：versionName用于顯示給用戶版本號(hào)信息。

另外，Android系統(tǒng)使用簽名在用戶、程序和進(jìn)程之間建立信任關(guān)系，對(duì)應(yīng)用程序的完整性和發(fā)布機(jī)構(gòu)的唯一性進(jìn)行校驗(yàn)。一般使用JDK自帶的Keytool和Jarsigner給程序簽名。Keytool是個(gè)密鑰和證書管理工具。Jarsigner利用密鑰倉(cāng)庫(kù)中的信息來(lái)對(duì)APK文件進(jìn)行簽名。如果不同開發(fā)者使用了相同的包名，簽名不同的程序不會(huì)被升級(jí)替換，這樣可防止已安裝的應(yīng)用被相似的惡意軟件通過(guò)升級(jí)替換掉。開發(fā)者持有簽名的私鑰，APK文件內(nèi)META-INF＼CERT.RSA存放公鑰，通過(guò)比較公鑰可以判斷私鑰是否一致。因此可以提取以上信息，組拼成字符串來(lái)唯一標(biāo)識(shí)一個(gè)Android應(yīng)用程序。endprint

基于以上信息，可以利用眾包機(jī)制，構(gòu)建出一個(gè)數(shù)據(jù)庫(kù)服務(wù)作為Android應(yīng)用程序的注冊(cè)平臺(tái)，要求開發(fā)者向平臺(tái)提供程序唯一性標(biāo)識(shí)信息。平臺(tái)采用先到先注冊(cè)的機(jī)制，并檢查保持包名的唯一性。當(dāng)用戶需要安裝一款應(yīng)用程序時(shí)，只要查尋一下Android應(yīng)用程序的注冊(cè)平臺(tái)就可以知道Android應(yīng)用程序是否存在重新包裝情況。

2.3 分析流程

從APK類型文件中提取唯一性信息需要以下工具：

（1）keytool.exe：JDK（Java Development Kit）自帶的密鑰和證書管理工具，主要用于密鑰和證書的創(chuàng)建、修改、刪除等。keytool工具利用以下命令查詢APK文件中的簽名信息：

keytool.exe -printcert -file apk＼CERT.RSA

（2）aapt.exe：Android Asset Packaging Tool是Android SDK（Software Development Kit）自帶的資源打包工具，具備查看APK文件內(nèi)資源的功能。aapt工具利用以下命令查詢APK文件中的唯一標(biāo)識(shí)信息：

aapt.exe dump badging [.apk文件路徑]

使用腳本程序調(diào)用keytool和aapt工具，并對(duì)結(jié)果字符串信息提取，獲得所需的查詢信息（Package Name，versionCode，versionName，Application signing），生成字符串，進(jìn)行數(shù)據(jù)庫(kù)查詢。

具體重包裝分析流程如下。

Step1：輸入APK文件OR應(yīng)用程序安裝文件URL地址。

Step2：預(yù)處理。

If（輸入為URL地址）啟動(dòng)網(wǎng)絡(luò)爬蟲工具下載APK類型文件。

Step3：信息提取。

提取APK文件信息構(gòu)造成字符串信息。

（Package Name，versionCode，versionName，Application signing）

Step4：查詢。

提交查詢信息至Android應(yīng)用程序注冊(cè)平臺(tái)；

利用Package Name、versionCode、versionName查詢唯一相同的應(yīng)用；

比較Application signing字段。

Step5：輸出結(jié)果。

If（兩相同應(yīng)用的Application signing相同）輸出非重包裝程序；

If（兩相同應(yīng)用的Application signing不同）輸出重包裝程序；

If（未查詢到相同應(yīng)用）輸出應(yīng)用未曾注冊(cè)，不能判別。

Android應(yīng)用程序的注冊(cè)平臺(tái)利用眾包機(jī)制要求非特定群體提供出Android應(yīng)用程序的唯一性標(biāo)識(shí)信息。Android應(yīng)用程序的注冊(cè)平臺(tái)不提供應(yīng)用程序下載推廣工作，僅為維護(hù)Android平臺(tái)安全，不會(huì)對(duì)其他應(yīng)用商城構(gòu)成競(jìng)爭(zhēng)，還會(huì)有促進(jìn)與規(guī)范作用。因此，利用眾包機(jī)制構(gòu)建一個(gè)應(yīng)用程序的注冊(cè)平臺(tái)并實(shí)施重包裝分析具備可行性。

3 Android重包裝應(yīng)用程序靜態(tài)分析原型系統(tǒng)設(shè)計(jì)

3.1 系統(tǒng)流程框架設(shè)計(jì)

Android重包裝應(yīng)用程序靜態(tài)分析原型系統(tǒng)需要對(duì)進(jìn)行過(guò)重包裝的Android惡意軟件進(jìn)行快速分析識(shí)別，同時(shí)功能模塊也要考慮到服務(wù)器運(yùn)算能力、網(wǎng)絡(luò)等資源緊張的現(xiàn)實(shí)，主要分析步驟如下。

（1）用戶通過(guò)手機(jī)客戶端提交需要檢測(cè)的APK文件，或者選擇提交APK文件下載路徑的URL地址到服務(wù)器端。

（2）服務(wù)器對(duì)接收到的信息進(jìn)行校驗(yàn)。如果接收到的是URL地址，啟動(dòng)網(wǎng)絡(luò)爬蟲工具下載地址對(duì)應(yīng)的APK文件，對(duì)獲得的APK文件進(jìn)行解壓等預(yù)處理。

（3）服務(wù)器對(duì)被預(yù)處理的APK文件進(jìn)行信息提取，組拼成特征字符串。

（4）服務(wù)器將提取的特征字符串通過(guò)網(wǎng)絡(luò)通信模塊，送至注冊(cè)平臺(tái)查詢數(shù)據(jù)庫(kù)記錄，對(duì)比簽名信息，生成報(bào)告返回到客戶端展示。

3.2 系統(tǒng)功能模塊

根據(jù)圖2可以看出該系統(tǒng)設(shè)計(jì)為客戶端和服務(wù)器兩部分，五大功能模塊。其中客戶端含有“文件提交模塊”，負(fù)責(zé)用來(lái)提交需要分析的APK文件。繁重的分析工作由服務(wù)器端進(jìn)行，主要有“提交接收模塊”“網(wǎng)頁(yè)抓取模塊”“信息提取處理模塊”和“網(wǎng)絡(luò)通信模塊”4個(gè)部分?！疤峤唤邮漳K”首先需要接收用戶提交的應(yīng)用安裝包信息，校驗(yàn)提交的文件格式是否正確。若用戶上傳的是應(yīng)用程序安裝文件URL地址，則啟動(dòng)“網(wǎng)頁(yè)抓取模塊”，利用網(wǎng)絡(luò)爬蟲工具下載APK類型文件。服務(wù)器順利獲取APK文件后，“信息提取處理模塊”開始解析APK類型文件，獲取應(yīng)用獨(dú)特的包名、簽名和版本號(hào)等信息，生成特征字符串唯一標(biāo)識(shí)該程序。然后通過(guò)“網(wǎng)絡(luò)通信模塊”與Android應(yīng)用程序注冊(cè)平臺(tái)的數(shù)據(jù)庫(kù)記錄對(duì)比，查看同樣包名的應(yīng)用程序是否存在一致的簽名信息，如果發(fā)現(xiàn)同樣的程序出現(xiàn)不同簽名，則判定為重新打包生成的惡意程序，直接反饋結(jié)果給客戶端。無(wú)論出于什么目的，重新打包原作者的應(yīng)用程序后再發(fā)布，就判斷為惡意軟件。若簽名一致，則排除為重新打包的情況。

3.3 推薦系統(tǒng)的實(shí)現(xiàn)

該系統(tǒng)采用Client/Server架構(gòu)進(jìn)行開發(fā)，客戶端運(yùn)行環(huán)境是Android 6.0系統(tǒng)，服務(wù)器運(yùn)行環(huán)境是Ubuntu 14.10系統(tǒng)。在“重包裝分析工具”中點(diǎn)擊輸入框，選取需要分析的APK文件，使用“應(yīng)用上傳”按鈕，啟動(dòng)文件提交模塊向服務(wù)器提交數(shù)據(jù)。待上傳成功后，啟動(dòng)“開啟分析”按鈕，通知服務(wù)器端開啟分析過(guò)程，依次啟動(dòng)提交接收模塊、信息提取處理模塊和網(wǎng)絡(luò)通信模塊。分析結(jié)束后，服務(wù)器端將分析結(jié)果反饋給客戶端進(jìn)行展示。

4 結(jié)語(yǔ)

準(zhǔn)確、高效地分析和鑒別Android重包裝應(yīng)用程序，對(duì)于只能訪問(wèn)第三方應(yīng)用商店的中國(guó)Android系統(tǒng)用戶具有重要意義。本文提出的基于眾包的Android重包裝應(yīng)用程序靜態(tài)分析方法，利用現(xiàn)有的Android安全機(jī)制，提出構(gòu)建Android應(yīng)用程序注冊(cè)平臺(tái)，實(shí)現(xiàn)對(duì)Android惡意程序的綜合、高效分析，可以大大加快Android重包裝應(yīng)用程序靜態(tài)分析的速度和提高準(zhǔn)確性。

參考文獻(xiàn)

[1] Zhou W，Zhou Y，Jiang X，et al.Detecting repackaged smartphone applications in third-party android marketplaces[A].Proceedings of the second ACM conference on Data and Application Security and Privacy[C].ACM，2012：317-326.

[2] 余小秋.基于行為分析的Android應(yīng)用程序安全評(píng)估技術(shù)研究與系統(tǒng)設(shè)計(jì)[D].北京郵電大學(xué)，2015.

[3] 李少輝.基于靜態(tài)分析的安卓重新打包程序檢測(cè)方法研究[D].北京交通大學(xué)，2014.

[4] Brabham D C.Crowdsourcing as a model for problem solving：An introduction and cases[J]. Convergence，2008，14（1）：75-90.

[5] Amos B，Turner H，White J.Applying machine learning classifiers to dynamic android malware detection at scale[A].2013 9th international wireless communications and mobile computing conference（IWCMC）[C].IEEE，2013：1666-1671.endprint