張楨宇，朱東來，楊哲慜，楊 珉

(復(fù)旦大學(xué)軟件學(xué)院，上海201203)

E-mail:yangzhemin@fudan.edu.cn

1 引言

近年來，智能移動設(shè)備得到了飛速的推廣普及.隨著日新月異的移動應(yīng)用的出現(xiàn)，智能移動設(shè)備在生活的方方面面中正在起到越來越重要的作用.據(jù)IDC(International Data Corporation)報道［1］，2017年全球智能移動設(shè)備出貨量為14.6億部，而安卓設(shè)備自2014年起常年占據(jù)全球智能移動設(shè)備年出貨量的80%左右.安卓設(shè)備正是目前全球范圍內(nèi)使用最為廣泛的智能移動設(shè)備.在此環(huán)境下，安卓設(shè)備的安全性顯得尤為重要.

安卓系統(tǒng)的巨大市場吸引了大量的惡意攻擊者，據(jù)McAfee報道［2］，2017年新增移動惡意樣本逾700萬例，全球移動設(shè)備平均惡意軟件感染率逾10%.與此同時，眾多研究工作［6-8，11］提出各種利用自動化程序分析的方式進行惡意軟件檢測的方法.與之對應(yīng)的，惡意軟件作者開始采用對抗分析技術(shù)以應(yīng)對上述分析檢測工作.

對抗分析技術(shù)是指一系列不同種類的、能夠干擾程序分析的技術(shù)手段.在安卓生態(tài)系統(tǒng)中存在大量公開免費的商業(yè)化加固服務(wù).商業(yè)化加固服務(wù)為其用戶提供一站式的加固服務(wù)，將一系列對抗分析技術(shù)自動化地附加到用戶上傳的樣本之中.商業(yè)化加固服務(wù)的初衷是為了保護應(yīng)用開發(fā)者的知識產(chǎn)權(quán)，防止應(yīng)用遭到惡意的逆向修改及重打包.然而，商業(yè)化加固服務(wù)卻遭到了惡意軟件開發(fā)者的濫用.Duan等人［3］研究發(fā)現(xiàn)，在其獲取的2010年至2015年的惡意樣本中，13.89%的樣本使用了對抗分析技術(shù)，其中約30%使用了商業(yè)化加固服務(wù).由于安卓生態(tài)系統(tǒng)中商業(yè)化加固服務(wù)的存在，作為安卓生態(tài)系統(tǒng)中的下游環(huán)節(jié)的反病毒引擎正面臨著與傳統(tǒng)PC環(huán)境不同的挑戰(zhàn).與對抗分析技術(shù)對應(yīng)，DexHunter［4］，App-Spear［5］等研究提出了通用的自動化脫殼方案，旨在突破對抗分析技術(shù)的干擾，還原樣本中隱藏的行為.

然而，目前學(xué)術(shù)界缺乏對現(xiàn)有安卓生態(tài)系統(tǒng)中薄弱環(huán)節(jié)的系統(tǒng)性研究，無法明確目前安卓生態(tài)系統(tǒng)安全性受到不同對抗分析技術(shù)影響的差別.因此導(dǎo)致反對抗分析技術(shù)的相關(guān)研究缺乏方向性，難以進行更為有效的反對抗分析研究.

為了實現(xiàn)此研究，本文設(shè)計并實現(xiàn)了自動化的加固工具AATPacker(Anti-Analysis Techniques Packer).AATPacker根據(jù)用戶輸入的參數(shù)選擇不同的對抗分析技術(shù)，將不同的對抗分析技術(shù)代碼自動化地插入用戶指定的安卓應(yīng)用程序之中.在有了AATPacker這一可指定選擇附加不同對抗分析技術(shù)的自動化加固工具之后，方可對安卓生態(tài)系統(tǒng)的安全性受到不同種類的對抗分析技術(shù)的影響進行系統(tǒng)性的研究.

借助于AATPacker，本文對安卓生態(tài)系統(tǒng)安全性受到對抗分析技術(shù)的研究進行了深入的研究.目前，現(xiàn)有研究［3］僅對反病毒引擎受到商業(yè)化加固的影響進行了簡要研究.而利用AATPacker，本文不僅能夠?qū)Ψ床《疽媸艿礁黝悓狗治黾夹g(shù)的影響進行更為深入全面的研究，而且首次將商業(yè)化加固服務(wù)納入受對抗分析技術(shù)影響研究的范疇，對商業(yè)化加固服務(wù)本身受到不同種類的對抗分析技術(shù)的影響進行了系統(tǒng)化的實驗研究.通過分析對比了不同種類的對抗分析技術(shù)對商業(yè)化加固服務(wù)以及反病毒引擎的安全性檢測產(chǎn)生的影響，本文為將來的防御工作提供重點研究方向.

利用AATPacker，本文對來自F-droid1https://f-droid.org/的9個良性開源樣本及來自GitHub公開倉庫2https://github.com/ashishb/android-malware的22個已知惡意樣本附加不同種類的對抗分析技術(shù)，共生成239個施加了不同種類組合的對抗分析技術(shù)的應(yīng)用樣本，對商業(yè)化加固服務(wù)及反病毒引擎進行實驗，主要取得了如下發(fā)現(xiàn):

1)商業(yè)化加固對上傳樣本進行了一定程度的安全性檢測，但通過附加對抗分析技術(shù)將極大程度地降低其檢測的有效性，惡意樣本通過檢測率由27.27%提升至81.82%

2)附加對抗分析技術(shù)能夠顯著降低惡意軟件在反病毒引擎中的檢出率，首次上傳由AATPacker附加所有對抗分析技術(shù)的惡意樣本，其平均檢出率下降56.26%.而良性樣本在使用對抗分析技術(shù)后被部分反病毒引擎的誤報為PUP(Potentially unwanted program)，部分樣本甚至被誤報為惡意軟件.

3)使用商業(yè)化加固對反病毒引擎產(chǎn)生的干擾效果與使用AATPacker附加對抗分析技術(shù)相近.將AATPacker與商業(yè)化加固結(jié)合使用能進一步提升干擾效果，降低其檢測有效性.

4)在不同種類的對抗分析技術(shù)中，動態(tài)代碼加載技術(shù)能夠?qū)ι虡I(yè)化加固與反病毒引擎中的安全檢測環(huán)節(jié)均產(chǎn)生最為顯著的對抗干擾效果.

綜上所述，本文旨在對安卓生態(tài)系統(tǒng)的安全性受到對抗分析技術(shù)的影響進行研究，以找出目前安卓生態(tài)系統(tǒng)安全性的薄弱環(huán)節(jié)，為將來的研究提供方向性的指導(dǎo).為實現(xiàn)此研究目的，本文設(shè)計實現(xiàn)了自動化加固工具AATpacker，以對實驗樣本可控地插入不同種類的對抗分析技術(shù).基于上述發(fā)現(xiàn)，本文揭示了現(xiàn)有反對抗分析研究成果尚未在實際安卓生態(tài)系統(tǒng)中得到有效應(yīng)用，對抗分析技術(shù)仍然能夠?qū)Π沧可鷳B(tài)系統(tǒng)中的安全性分析產(chǎn)生顯著影響，不僅使惡意軟件能夠規(guī)避檢測，還會使良性軟件遭到誤報.商業(yè)化加固服務(wù)作為對抗分析技術(shù)的供應(yīng)者，其本身卻缺少對對抗分析技術(shù)的反對抗能力，從而易使其提供的服務(wù)遭到惡意軟件作者的濫用.上述安卓生態(tài)系統(tǒng)中的薄弱環(huán)節(jié)應(yīng)作為將來反對抗分析技術(shù)研究工作的重點方向.

2 背景與相關(guān)工作

2.1 對抗分析技術(shù)

對抗分析技術(shù)是指一系列以干擾程序分析為目的的技術(shù)手段.程序分析可分為人工分析和自動化分析，自動化分析可主要分為靜態(tài)程序分析和動態(tài)程序分析兩類.在實際的應(yīng)用中，可混合使用上述程序分析方法，相互結(jié)合形成如動靜結(jié)合的程序分析等更加靈活復(fù)雜的程序分析方法.對抗分析技術(shù)針對程序分析過程中的某些弱點進行對抗，使程序分析無法繼續(xù)進行或無法得到真實有效的分析結(jié)果.本文關(guān)注的對抗分析技術(shù)主要包含動態(tài)代碼加載，反模擬器，反調(diào)試，完整性檢查.動態(tài)代碼加載主要針對靜態(tài)程序分析，而后三者主要針對動態(tài)程序分析.

動態(tài)代碼加載主要指安卓應(yīng)用通過調(diào)用系統(tǒng)接口等方式，在運行過程中動態(tài)地加載Java層代碼并執(zhí)行的技術(shù)手段.被動態(tài)加載的代碼通常以加密形式存放在安卓安裝包(Android Package，在下文中簡稱為APK)文件中，在動態(tài)運行時進行解密并動態(tài)加載運行.被動態(tài)代碼加載的代碼在靜態(tài)時無法被有效分析，進而能夠規(guī)避靜態(tài)的程序分析檢測.在實際應(yīng)用中，惡意開發(fā)者使用動態(tài)代碼加載技術(shù)使其惡意行為免于被靜態(tài)分析工具發(fā)現(xiàn);而良性開發(fā)者使用動態(tài)代碼加載技術(shù)旨在使其核心代碼不直接暴露于攻擊者眼下，增加攻擊者對應(yīng)用進行篡改的難度.

反模擬器是指通過檢測運行環(huán)境是否處于安卓模擬器環(huán)境中，進而決定是否執(zhí)行關(guān)鍵代碼的技術(shù)手段.反模擬器技術(shù)通常通過檢測系統(tǒng)調(diào)用返回值、檢測模擬網(wǎng)絡(luò)環(huán)境、檢測底層模擬器、檢測計算性能等方式進行［9］.動態(tài)分析工具常部署在安卓模擬器環(huán)境中，以取得對設(shè)備更強的控制能力.惡意開發(fā)者正是利用這一特性，利用反模擬器技術(shù)使其惡意代碼免于動態(tài)分析工具的檢測;而良性開發(fā)者使用反模擬器技術(shù)以保護其真實用戶群體免受惡意批量注冊的虛假用戶的損害.

反調(diào)試技術(shù)是指在運行過程中防止應(yīng)用在處于被調(diào)試狀態(tài)下運行關(guān)鍵代碼的技術(shù)手段.反調(diào)試技術(shù)可通過檢查進程調(diào)試狀態(tài)和主動搶占調(diào)試等方式實現(xiàn).當應(yīng)用處于被調(diào)試狀態(tài)時，調(diào)試者對應(yīng)用有完全的掌控權(quán)，安全研究人員能夠完全掌握應(yīng)用所執(zhí)行的所有代碼，且能夠繞過如反模擬器，完整性檢查等其他針對動態(tài)分析的對抗分析技術(shù);而惡意攻擊者能夠達到隨意篡改和竊取應(yīng)用數(shù)據(jù)的目的.

完整性檢查是指在動態(tài)運行時，對應(yīng)用是否被靜態(tài)修改進行檢查，進而決定是否執(zhí)行關(guān)鍵代碼.安卓應(yīng)用需要經(jīng)過對APK文件的簽名后方可安裝，此簽名僅需使用自簽名的證書即可.惡意攻擊者可在反編譯應(yīng)用并篡改其內(nèi)容后使用完全不同的自簽名證書重新簽名，被篡改的應(yīng)用可以被正常的安裝執(zhí)行.此問題源于對安卓應(yīng)用的簽名只能保證在簽名之后的APK并未被改動，而無法保證對應(yīng)用進行簽名者正是原應(yīng)用開發(fā)者.完整性檢查可通過在附加對抗分析技術(shù)時記錄原DEX文件校驗值或原簽名證書信息，并在動態(tài)運行時進行相應(yīng)的檢查校驗來判斷應(yīng)用是否在上次打包后被重新打包.惡意開發(fā)者使用完整性檢查以規(guī)避基于靜態(tài)插樁的動態(tài)程序分析;良性開發(fā)者使用完整性檢查以避免應(yīng)用被重打包.

綜上所述，惡意開發(fā)者與良性開發(fā)者出于不同目的，均存在對對抗分析技術(shù)的需求.惡意開發(fā)者使用對抗分析技術(shù)對抗程序分析，延長其惡意軟件的存活時間;良性開發(fā)者使用對抗分析技術(shù)保護其知識產(chǎn)權(quán)，使其應(yīng)用不被破解盜版.在安卓生態(tài)系統(tǒng)中，存在大量的個人應(yīng)用開發(fā)者.個人開發(fā)者并不都具有對對抗分析技術(shù)的了解，大量的商業(yè)化加固應(yīng)運而生.商業(yè)化加固的本質(zhì)是集合了一系列對抗分析技術(shù)，將其附加至應(yīng)用開發(fā)者上傳的應(yīng)用中，使應(yīng)用開發(fā)者在不需要關(guān)注相應(yīng)技術(shù)細節(jié)的情況下，實現(xiàn)保護自身應(yīng)用不被非法破解盜版的目標.商業(yè)化加固為了避免為惡意軟件所用，通常都會進行對上傳應(yīng)用的安全性檢測，拒絕為惡意軟件提供相應(yīng)的服務(wù).

2.2 安卓生態(tài)系統(tǒng)

安卓生態(tài)系統(tǒng)是指由安卓應(yīng)用從應(yīng)用開發(fā)者到最終被用戶使用的整個過程.安卓生態(tài)系統(tǒng)的一大特點是其中存在大量商業(yè)化加固服務(wù)，其直接為安卓應(yīng)用開發(fā)者提供服務(wù)，位于安卓生態(tài)系統(tǒng)的上游.而反病毒引擎則位于安卓生態(tài)系統(tǒng)的下游環(huán)節(jié)，反病毒引擎以安全軟件的形式存在于用戶的終端設(shè)備中，作為保護用戶不受惡意軟件侵害的最后一道屏障.

安卓生態(tài)系統(tǒng)的安全性由商業(yè)化加固的安全性檢查與反病毒引擎進行的安全性檢測共同保障，任一環(huán)節(jié)如受到對抗分析技術(shù)的干擾，使惡意軟件成功通過該環(huán)節(jié)的安全性檢測，都將大大提升惡意軟件最終損害用戶的可能性.作為一個完整的生態(tài)系統(tǒng)，上下游環(huán)節(jié)中的安全性檢測息息相關(guān).商業(yè)化加固服務(wù)如為惡意軟件所用，將極大地提升作為下游環(huán)節(jié)的反病毒引擎發(fā)現(xiàn)和識別惡意軟件的難度.而如反病毒引擎為對抗分析技術(shù)所干擾，用戶將直接暴露在惡意軟件面前，極有可能受到惡意軟件帶來的損害.在研究對抗分析技術(shù)對安卓生態(tài)系統(tǒng)的安全性產(chǎn)生的影響時，應(yīng)將安卓生態(tài)系統(tǒng)中的各個環(huán)節(jié)本身受到的影響及前后環(huán)節(jié)之間可能產(chǎn)生的影響都考慮在內(nèi).

2.3 相關(guān)工作

目前，已有多項研究提出面向安卓應(yīng)用的通用自動化脫殼方案.DexHunter［4］認為安卓應(yīng)用在進行動態(tài)代碼加載時存在某些關(guān)鍵函數(shù)，為所有動態(tài)代碼加載技術(shù)所必經(jīng)，因此DexHunter在該函數(shù)中插入代碼，在進行主動的類初始化調(diào)用之后，對動態(tài)加載的代碼進行轉(zhuǎn)儲.

AppSpear［5］認為殼代碼與原始應(yīng)用代碼的執(zhí)行存在明顯分界，殼代碼將原始應(yīng)用代碼全部恢復(fù)后將執(zhí)行流轉(zhuǎn)交給原始應(yīng)用代碼.因此AppSpear選擇應(yīng)用的主活動(main activity)開始執(zhí)行時作為收集原始代碼的時間節(jié)點.AppSpear通過Dalvik虛擬機在內(nèi)存中維護的關(guān)于應(yīng)用代碼的內(nèi)存結(jié)構(gòu)收集相應(yīng)的數(shù)據(jù)結(jié)構(gòu)信息，并重新由此重新構(gòu)建DEX(Dalvik Executable)文件.

DexHunter和AppSpear都是通過修改安卓系統(tǒng)的方式進行相應(yīng)的實現(xiàn)，可部署在真實的安卓設(shè)備中，從而避免受到反模擬器及反調(diào)試等對抗分析技術(shù)的影響.但隨著商業(yè)化加固和其使用的對抗分析技術(shù)的發(fā)展，上述兩篇工作的前提假設(shè)都已無法保證，已無法達成對現(xiàn)有商業(yè)化加固應(yīng)用的有效脫殼.

DroidUnpack［3］基于全系統(tǒng)模擬，能夠獲取并重建操作系統(tǒng)級別和ART(Android Runtime)級別的語義信息，捕獲實際執(zhí)行的方法的代碼.此外，基于捕獲的操作系統(tǒng)級別的語義信息，通過對同一內(nèi)存區(qū)域的寫入和執(zhí)行順序的先后關(guān)系，判斷是否存在脫殼，代碼自修改，多層脫殼等技術(shù).但由于DroidUnpack僅能覆蓋實際執(zhí)行的代碼，存在代碼覆蓋率問題，且其基于模擬器的特性，會受到反模擬器技術(shù)的干擾，因此并不能在實際環(huán)境中用作解決商業(yè)化加固及對抗分析技術(shù)的終極方案.

此外，DroidUnpack中提到商業(yè)化加固會對反病毒引擎產(chǎn)生影響，降低反病毒引擎的有效性.但在DroidUnpack僅嘗試對少量惡意軟件進行商業(yè)化加固，并比較其加固前后的檢出率.其僅考慮了反病毒引擎受到商業(yè)化加固的直接影響.與之相比，本文實現(xiàn)了自動化加固工具 AATPacker.借助于AATPacker，本文能夠:

1)對商業(yè)化加固本身的安全性檢測受到對抗分析技術(shù)的影響進行研究.

2)通過選擇附加不同類型的對抗分析技術(shù)，比較不同類型的對抗分析技術(shù)之間產(chǎn)生影響的差異.

3)比較商業(yè)化加固及客制化加固(AATPacker)對反病毒引擎的影響差異.

4)對反病毒引擎進行了長時間的觀察，探究對抗分析技術(shù)對反病毒引擎產(chǎn)生的影響隨時間的變化.

3 AATPacker系統(tǒng)設(shè)計

本章將對AATPacker的系統(tǒng)設(shè)計進行闡述.AATPacker接受APK文件及用于指定不同對抗分析技術(shù)的程序參數(shù)作為輸入，輸出為自動化插入了根據(jù)參數(shù)選擇的對抗分析技術(shù)的APK文件.與商業(yè)化加固一樣，AATPacker的輸出文件需要經(jīng)過重新簽名后方可安裝至安卓設(shè)備中.AATPacker的系統(tǒng)結(jié)構(gòu)如圖1所示.

對于輸入的APK文件，AATPacker首先使用Apktool3https://ibotpeaches.github.io/Apktool/對原應(yīng)用進行反編譯，得到表示應(yīng)用程序代碼的smali文件及包含應(yīng)用基礎(chǔ)信息的應(yīng)用清單文件(AndroidManifest.xml).其次，AATPacker對應(yīng)用清單文件進行解析，獲取原應(yīng)用的有關(guān)信息.

隨后由控制模塊對輸入的參數(shù)進行解析，自對抗分析技術(shù)池中選取相應(yīng)的技術(shù)，根據(jù)所選擇的不同對抗分析技術(shù)，AATPacker將進行插入殼Application文件、插入對抗分析技術(shù)代碼文件、加密由APK中單獨抽取的原DEX文件、修改應(yīng)用清單文件和寫入AATPacker配置文件等操作，以將對抗分析技術(shù)附加至應(yīng)用之中.對抗分析技術(shù)池包含多種類型的對抗分析技術(shù)，主要由對現(xiàn)有加固的樣本的逆向分析及相關(guān)論文中提出的對抗分析技術(shù)綜合提取生成.殼smali文件作為AATPacker在應(yīng)用中所附加代碼的起始點和控制中心，負責(zé)在應(yīng)用動態(tài)運行時根據(jù)配置文件執(zhí)行相應(yīng)的對抗分析技術(shù).

圖1 AATPacker系統(tǒng)結(jié)構(gòu)Fig.1 System architecture of AATPacker

最后，AATPacker再次使用Apktool將所有修改后的資源文件，會同所有未被修改的其他原有資源文件重新組裝成APK文件.組裝后的APK文件將失去原有的簽名信息，需要經(jīng)過重新簽名后方可安裝至安卓設(shè)備之中.

4 AATPacker實現(xiàn)

AATPacker主要由對抗分析技術(shù)控制模塊和對抗分析技術(shù)池了兩部分組成，本章將詳細闡述其具體實現(xiàn)原理.

4.1 對抗分析技術(shù)控制模塊

對抗分析技術(shù)控制模塊主要負責(zé)AATPacker的整體執(zhí)行控制，其主要負責(zé)對參數(shù)進行解析以選擇對應(yīng)的對抗分析技術(shù)、調(diào)用Apktool完成對APK文件的反編譯及重新組合構(gòu)建、對應(yīng)用清單文件進行解析等操作.應(yīng)用清單文件以xml格式存放，通過對其進行的解析，控制模塊從中獲取了應(yīng)用的包名(package)以及原有的Application類名等信息.

Application類用于維護應(yīng)用的全局屬性，通常而言應(yīng)用并不需要使用自定義的Application子類.部分應(yīng)用可能為了維護某些特殊的全局變量因而需要使用自定義的Application類，在其提供了具體實現(xiàn)后，需要在應(yīng)用文件清單中＜application＞標簽下的“android:name”屬性中提供其實現(xiàn)的Application子類名.

由于AATPacker需要插入殼Application類作為AATPacker在動態(tài)運行時的入口，為保證應(yīng)用能夠正常運行，控制模塊需要保存原有的Application類信息，并在殼Application完成其任務(wù)后恢復(fù)原有Application類.為了達成此目的，控制模塊記錄了原有Application的類名.

4.2 對抗分析技術(shù)池

對抗分析技術(shù)技術(shù)池包含殼Application以及所有對抗分析技術(shù)的smali實現(xiàn)，以及附加相應(yīng)代碼需要進行的準備工作及收尾工作.以下將詳細闡述殼Application及每項對抗分析技術(shù)的具體實現(xiàn)方式.

4.2.1 殼 Application

AATPaker插入的對抗分析技術(shù)以應(yīng)用的Application類作為入口點.我們通過插入由我們實現(xiàn)的殼Application來控制對抗分析技術(shù)在應(yīng)用運行時的執(zhí)行.為了保證應(yīng)用能夠正常運行，我們需要在我們實現(xiàn)的殼Application完成相應(yīng)工作后，恢復(fù)應(yīng)用原有的Application類的運行.殼Application通過繼承android.app.Application類的方式實現(xiàn).對抗分析技術(shù)應(yīng)在應(yīng)用運行過程中盡可能早的時間段執(zhí)行，以盡可能地產(chǎn)生有效的對抗分析效果，且保持原應(yīng)用正常運行.出于此目的，AATPacker選擇覆蓋attachBaseContext方法，在其中插入執(zhí)行對抗分析技術(shù).attachBaseContext將在應(yīng)用啟動的較早階段被執(zhí)行，其執(zhí)行時機早于Application類的onCreate方法及應(yīng)用中其他組件的任意方法.

恢復(fù)執(zhí)行原Application的算法將在殼Application中被覆蓋的onCreate方法中被調(diào)用，其主要實現(xiàn)邏輯如下.

總體而言，我們需要將殼Application相對應(yīng)的對象從應(yīng)用的運行環(huán)境中移除，初始化生成原有Application對象(android.app.Application類)，并將生成的原有 Application對象加入應(yīng)用的運行環(huán)境.

我們通過反射的方式，由當前ActivityThread.mInitialApplication對象獲取殼Application對象，將其從ActivityThread.mAllApplications列表中刪除.通過LoadedApk.makeApplication方法完成原有Application對象的初始化，將mInitialApplication賦值為原Application對象并將其加入mAllApplications列表.此外，我們還需遍歷ActivityThread.mProviderMap的值域，將完成了初始化的原Application對象賦值給ActivityThreadMYMProviderClientRecord.mLocalProvider.mContext變量，以將原Application對象作為應(yīng)用的content provider的上下文使用.

4.2.2 動態(tài)代碼加載

動態(tài)代碼加載需要對原DEX文件進行加密存放，并在動態(tài)運行時將其解密存放于私有目錄中，并通過替換Class-Loader的方式對原DEX進行加載.具體而言，需要初始化一個DexClassLoader對象，其dexPath參數(shù)為解密后的DEX文件路徑，其parent ClassLoader參數(shù)為當前的ClassLoader.并將此新生成的DexClassLoader對象替換當前應(yīng)用的默認ClassLoader.當前應(yīng)用的ClassLoader信息存放于LoadedApk類中的mClassLoader對象中，而LoadedApk對象可以通過當前ActivityThread對象的mPackages對象利用當前應(yīng)用的包名獲得.

4.2.3 反模擬器

反模擬器技術(shù)可通過檢測系統(tǒng)調(diào)用返回值、檢測模擬網(wǎng)絡(luò)環(huán)境、檢測底層模擬器、檢測計算性能、檢測軟硬件組件等方式檢測運行環(huán)境是否處于安卓模擬器環(huán)境中，AATPacker式判斷運行環(huán)境是否為模擬器.Morpheus［10］中提供了10個能夠判斷運行環(huán)境是否為虛擬機的特征文件.經(jīng)過實驗，AATPacker對其進行了改進，選擇了1個來自Morpheus的和4個全新的特征文件作為判斷運行環(huán)境是否為模擬器的標準.具體文件請見表1.

表1 特征文件列表Table 1 List of feature files

為了驗證特征文件的有效性，本文構(gòu)建了用于收集相關(guān)數(shù)據(jù)的安卓應(yīng)用，對71款真機與7款模擬器進行了測試.其中真機測試利用騰訊云4http://wetest.qq.com/product/basic-compatibility-testing及阿里云5https://www.aliyun.com提供的兼容性測試服務(wù)完成，能夠較好的覆蓋目前較為主流的機型.在模擬器方面，本文選取了7款較為流行的安卓模擬器，詳情見表2.

表2 模擬器列表Table 2 List of Android emulators

這些模擬器覆蓋了arm架構(gòu)和x86架構(gòu)，及qemu和vbox底層模擬器.本文對上述共78款安卓設(shè)備進行特征文件總數(shù)量的統(tǒng)計.通過實驗，本文發(fā)現(xiàn)所有真機至少存在其中3個特征文件，而所有模擬器至多僅存在其中1個特征文件.因此，這些特征文件能夠有效檢測運行環(huán)境是否為安卓模擬器.

4.2.4 反調(diào)試

AATPacker采用檢測進程是否處于調(diào)試狀態(tài)的方法以實現(xiàn)反調(diào)試對抗分析技術(shù).由于安卓應(yīng)用主要由Java代碼構(gòu)成，但同時可以通過JNI(Java Native Interface)的方式調(diào)用本地代碼，因此需要同時檢測是否存在Java調(diào)試器和本地調(diào)試器.對于Java調(diào)試器的檢測，可以通過調(diào)用android.os.Debug類的isDebuggerConnected方法進行判斷.對于本地調(diào)試器的檢測，AATPacker采用了對于/proc/self/task目錄下所有的pid，檢查對應(yīng)/proc/［pid］/status文件中 TracerPid屬性是否為0的方式進行判斷.

此外，調(diào)試工具可能并非在應(yīng)用啟動時已存在，對此選用基于特征文件的對底層模擬器及軟件組件進行檢測的方AATPacker創(chuàng)建了新的線程，定期執(zhí)行調(diào)試狀態(tài)檢查.

4.2.5 完整性檢查

AATPacker采用判斷應(yīng)用簽名信息是否與加固時一致以判斷應(yīng)用完整性是否得以保障.AATPacker在加固時利用keytool工具提取原簽名證書的公鑰信息并加以保存;在動態(tài)運行時，通過調(diào)用PackageManager類的getPackageInfo方法獲取當前應(yīng)用的簽名證書信息.將動態(tài)獲取得到的當前應(yīng)用簽名證書信息與加固時保存的原簽名證書信息進行對比，以判斷應(yīng)用完整性是否被破壞.

5 實驗設(shè)計

為了回答對抗分析技術(shù)會對安卓生態(tài)系統(tǒng)的安全性檢測產(chǎn)生如何的影響，以及不同類型的對抗分析技術(shù)的效果是否存在差異的問題，本文利用AATPacker，設(shè)計對安卓生態(tài)系統(tǒng)不同環(huán)節(jié)的安全性檢測進行實驗.

對抗分析技術(shù)對安卓生態(tài)系統(tǒng)的影響可能并不僅僅發(fā)生在惡意樣本上，良性樣本在使用對抗分析技術(shù)后可能同樣會受到影響.為了有效分析對抗分析技術(shù)對安卓生態(tài)系統(tǒng)產(chǎn)生影響，本文將分別對良性樣本和惡意樣本利用AATPacker附加對抗分析技術(shù)，并分別對商業(yè)化加固和反病毒引擎進行實驗.在本章的后續(xù)小節(jié)中，將對本文采用的實驗原始樣本集，面向商業(yè)化加固服務(wù)的實驗及面向反病毒引擎的實驗設(shè)計進行詳細的闡述.

5.1 原始樣本集

本文進行實驗的原始樣本集分為良性樣本和惡意樣本兩部分，其中良性樣本為隨機選自F-Droid6https://f-droid.org/的9個開源樣本，本文在獲取其源碼后編譯生成相應(yīng)的APK文件.惡意樣本為來自GitHub公開倉庫7https://github.com/ashishb/android-malware的22個惡意軟件家族，對于每個惡意軟件家族，本文從倉庫中隨機選取其中的一個APK樣本作為其代表.此外，由于完整性檢查技術(shù)要求應(yīng)用加固前后使用相同的證書進行簽名，本文對所有樣本一一對應(yīng)地隨機生成了證書，并對其進行簽名.在對惡意樣本簽名之前，需要移除其原有簽名，并對其重簽名.在之后的所有實驗中，對抗分析技術(shù)的附加對象為經(jīng)過簽名的良性樣本和重新簽名的對抗分析技術(shù).

5.2 商業(yè)化加固服務(wù)實驗

商業(yè)化加固或出于企業(yè)責(zé)任，或出于維持自身于相關(guān)行業(yè)的聲譽，或出于為用戶提供對外包的第三方代碼檢測等目的，隨著商業(yè)化加固的不斷發(fā)展，主流商業(yè)化加固都會對用戶上傳的樣本進行安全性分析，拒絕為惡意軟件所用［3］.

據(jù)Duan等人［3］研究發(fā)現(xiàn)，在其獲取的2010年至2015年的惡意樣本中，使用了對抗分析技術(shù)的樣本中約30%的惡意軟件使用了商業(yè)化加固服務(wù).其中，超過50%的樣本使用的是梆梆加固.因此，本文選取了使用率最高的梆梆加固作為商業(yè)化加固服務(wù)的代表，為本文實驗的目標商業(yè)化加固服務(wù).

商業(yè)化加固實驗旨在探究作為對抗分析技術(shù)提供者的商業(yè)化加固，其本身的安全性檢測本身是否會受到對抗分析技樣本中任意一個通過商業(yè)化加固服務(wù)的安全性檢查，則視為對于該樣本，附加對抗分析技術(shù)能夠通過商業(yè)化加固的安全性分析.通過數(shù)量及通過率見表3.術(shù)的影響，使惡意軟件能夠通過其檢測，并得以進行商業(yè)化加固.如果存在影響，進一步探究不同種類的對抗分析技術(shù)的影響分別如何.得益于本文實現(xiàn)的自動化加固工具AATPacker，本文能夠?qū)颖驹诓皇苋魏伟踩詸z測制約的前提下，按照需求附加不同種類的對抗分析技術(shù)組合，這是文獻［3］中無法做到的.

本文首先對惡意樣本進行重新簽名，對每一個經(jīng)過重新簽名的樣本，對其在五種不同參數(shù)配置下生成帶有對抗分析技術(shù)的樣本.五種配置分別為:單獨附加動態(tài)代碼加載，單獨附加反模擬器，單獨附加反調(diào)試，單獨附加完整性檢查，同時附加上述四種對抗分析技術(shù).因此，對每一份惡意樣本，本文生成了原始惡意樣本、重簽名惡意樣本及上述五種附帶對抗分析技術(shù)的樣本共7份樣本.并將所有樣本上傳至梆梆加固，觀察其是否被拒絕加固.

5.3 反病毒引擎實驗

反病毒引擎作為保護用戶的最后一道屏障，其對樣本給出的斷言將直接影響應(yīng)用和用戶，漏報將使用戶受到惡意軟件的損害，誤報使良性應(yīng)用被誤殺，對應(yīng)用開發(fā)者造成損失.

本文利用VirusTotal8https://www.virustotal.com/平臺對樣本進行持續(xù)的觀察分析.VirusTotal平臺提供60余種反病毒引擎對上傳樣本的檢測結(jié)果，并保持反病毒引擎病毒庫的持續(xù)更新.

在反病毒引擎實驗中，本文選取良性樣本及惡意樣本共同作為原始樣本集.對于良性樣本，本文意圖考察其經(jīng)過商業(yè)化加固后是否會被反病毒引擎誤報.對于惡意樣本，本文意圖考察其在附加對抗分析技術(shù)后是否會被反病毒引擎漏報.對于每個良性樣本，本文選取其原始樣本及經(jīng)過梆梆加固的樣本作為樣本集.對于每個惡意樣本，本文選取在商業(yè)化加固服務(wù)實驗中所描述的7種樣本組合，以及其所有通過商業(yè)化加固能夠得到的樣本.由于并非所有上傳商業(yè)化加固服務(wù)的樣本均通過了商業(yè)化加固的安全性檢測，因此對于不同樣本其通過商業(yè)化加固得到的樣本數(shù)不等.

本文利用VirusTotal平臺提供的接口，實現(xiàn)了Python腳本，每日對上述所有樣本進行重新掃描，并獲取其最新的檢測報告.隨后，將其每日的檢測報告詳情儲存于MySQL數(shù)據(jù)庫中.本文對其檢測結(jié)果進行分析，以回答關(guān)于對抗分析技術(shù)對反病毒引擎影響情況的問題.

表3 商業(yè)化加固通過率Table 3 Success rate of commercial packing

可以看到，商業(yè)化加固具有一定的安全性檢測，僅約27%的原始惡意樣本和重簽名樣本能夠通過其安全性檢測.但在附加對抗分析技術(shù)后，通過商業(yè)化加固的安全性檢測的比例大幅提升至約82%.對抗分析技術(shù)對商業(yè)化加固的安全性檢測產(chǎn)生了極大的干擾，使惡意軟件能夠利用商業(yè)化加固，更有效地隱蔽自身的惡意代碼.

其次，本文進一步對不同種類的對抗分析技術(shù)通過商業(yè)化加固的安全性檢測的比例進行比較，不同種類的對抗分析技術(shù)組合，與原始樣本及重簽名樣本的通過率如圖2所示.

圖2 不同種類對抗分析技術(shù)通過率對比Fig.2 Comparison between different techniques

6 實驗結(jié)果

基于上一章所述的實驗設(shè)計，本章將闡述取得的實驗結(jié)果，并對其進行進一步分析，探討安卓生態(tài)系統(tǒng)各環(huán)節(jié)中需要對對抗分析技術(shù)著重關(guān)注的重點.

6.1 商業(yè)化加固服務(wù)實驗

對于商業(yè)化加固服務(wù)實驗，本文上傳了來自22個家族的，附加了不同對抗分析技術(shù)組合的共154個樣本，其中有67個樣本通過了商業(yè)化加固的安全性檢測，總體通過率為45.3%.首先，本文進行原始樣本、重簽名樣本及附加對抗分析技術(shù)后的樣本通過商業(yè)化加固的數(shù)量及比例的對比.其中對于每個樣本，若其五個按照不同配置附加對抗分析技術(shù)的

在原始樣本通過率僅有27.27%的情況下，不同種類的對抗分析技術(shù)均能夠顯著提高樣本通過商業(yè)化加固服務(wù)安全性檢查的成功率.其中附加動態(tài)代碼加載技術(shù)與附加所有對抗分析技術(shù)取得的效果相同，均能夠?qū)⑼ㄟ^率提升至63.64%.其作為對商業(yè)化加固影響最大的對抗分析技術(shù)，應(yīng)該進一步引起商業(yè)化加固服務(wù)的關(guān)注.

綜上所述，對抗分析技術(shù)能夠?qū)⒁阎獝阂廛浖ㄟ^商業(yè)化加固的比例由27%提升至82%，其中對抗分析技術(shù)的提升效果最為顯著.對抗分析技術(shù)能夠嚴重干擾商業(yè)化加固的安全性檢測，使其為惡意軟件所用，進一步加大惡意軟件對安卓生態(tài)系統(tǒng)的危害.商業(yè)化加固作為對抗分析技術(shù)的提供者，更應(yīng)保護其本身的安全性檢測免于對抗分析技術(shù)的干擾.

6.2 反病毒引擎實驗

對于反病毒引擎實驗，本文基于9個良性樣本和22個惡意樣本，生成了商業(yè)化加固后的良性樣本及經(jīng)過AATPacker或商業(yè)化加固的惡意樣本總計239個.持續(xù)觀察在首次上傳后20天內(nèi)的檢測報告，結(jié)果如下.

6.2.1 良性樣本實驗

此部分實驗包含對9個良性樣本和與之對應(yīng)的9個經(jīng)過梆梆加固的樣本的持續(xù)觀察.檢出結(jié)果如表4所示，其中若樣本在觀察周期內(nèi)存在反病毒引擎對其給出陽性結(jié)果(檢出惡意軟件)，則計入陽性樣本數(shù)統(tǒng)計.同理，如其被檢測為PUP或其他惡意軟件，則計入相應(yīng)統(tǒng)計.

9個原始良性樣本在整個觀察周期內(nèi)均無任何檢出，符合其做為良性樣本的屬性.但對于所有9個加固樣本，某一反病毒引擎自首次上傳起，始終將其標注為“PUP.HighConfidence”.對于其中一個加固樣本(sha256:ff30aa48 a2d3491 a5a02 ecea4307693257 d514b8fb7 ecd9bb616279512 a5d922)，在其原始樣本無任何檢出的情況下，自第12個觀察日起出現(xiàn)反病毒引擎將其標注為惡意軟件.在第20個觀察日，共有13家反病毒引擎對其給出陽性結(jié)果，其中3家反病毒引擎將其識別為“SmsSpy”惡意軟件.

表4 良性樣本檢出數(shù)Table 4 Detection of benign samples

存在反病毒引擎將進行商業(yè)化加固的樣本標注為PUP，說明部分反病毒引擎已對商業(yè)化加固產(chǎn)生關(guān)注，但由于無法分析樣本內(nèi)容，僅能給出存在潛在威脅的結(jié)果.更有甚者，由于反病毒引擎無法有效分析經(jīng)過商業(yè)化加固的樣本，可能導(dǎo)致樣本受到其他惡意樣本的影響，被識別標注為與其本身毫無相關(guān)的惡意樣本，遭到誤報，嚴重影響良性應(yīng)用的正常運行.

6.2.2 惡意樣本實驗

此部分實驗包含對22個原始惡意樣本，其重簽名樣本，經(jīng)過AATPacker附加對抗分析技術(shù)的樣本以及通過商業(yè)化加的樣本共221個.本文將樣本分文經(jīng)過AATPacker加固的樣本和經(jīng)過商業(yè)化加固的樣本兩部分比較對抗分析技術(shù)對反病毒引擎的影響.首先對惡意樣本本身，其重簽名樣本，5組AATPacker加固樣本等共7組154個樣本按照上述分組統(tǒng)計平均日檢出率，結(jié)果如圖3所示.

圖3 AATPacker加固惡意樣本檢出率Fig.3 Detection rate of AATPacker packed malware

總體而言，附加所有對抗分析技術(shù)的樣本和附加動態(tài)代碼加載的樣本檢出率相近;附加反模擬器，完整性檢查和反調(diào)試的樣本檢出率相近.在上傳首日，附加對抗分析技術(shù)能夠明顯降低樣本檢出率，其中附加所有對抗分析技術(shù)和附加動態(tài)代碼加載技術(shù)的樣本，相對于重簽名樣本，檢出率分別下降56.26%和55.15%，對反病毒引擎具有明顯的對抗效果.隨后，所有帶有對抗分析技術(shù)的樣本的檢出率均不斷提升.在首次上傳后第10日起，各樣本檢出率趨于穩(wěn)定，附加不同對抗分析技術(shù)相對于重簽名樣本檢出率降低約6%和20%.

對于經(jīng)過商業(yè)化加固的樣本，由于并非所有樣本都能夠通過商業(yè)化加固的安全性檢測，平均檢出率受不同樣本本身檢出率影響，直接展現(xiàn)平均檢出率并不能客觀反映對抗分析技術(shù)產(chǎn)生的干擾.本文以不同對抗分析技術(shù)為組，統(tǒng)計同一組內(nèi)每一樣本相對于其重簽名樣本的檢出率降低率，根據(jù)各組樣本數(shù)不同對其計算平均降低率，以此體現(xiàn)不同對抗分析技術(shù)與商業(yè)化加固結(jié)合后產(chǎn)生的影響，降低率越大說明對反病毒引擎的影響越大，見圖4.

圖4 商業(yè)化加固惡意樣本檢出率的降低率Fig.4 Reduction rate of the detection rate of commercial packed malware

與使用AATPacker加固類似，使用商業(yè)化加固也存在對抗分析效果不斷減弱的現(xiàn)象.最終單獨使用商業(yè)化加固能夠使惡意樣本檢出率降低約20%，其效果與AATPacker相似.在使用AATPacker進行加固后再次進行商業(yè)化加固能夠進一步提高檢出率的降低率.在附加商業(yè)化加固后，依然存在附加所有對抗分析技術(shù)的樣本和附加動態(tài)代碼加載的樣本檢出率相近;附加反模擬器，完整性檢查和反調(diào)試的樣本檢出率相近的現(xiàn)象.與單獨使用AATPacker類似，使用動態(tài)代碼加載技術(shù)與商業(yè)化加固結(jié)合能夠最大程度地降低檢出率，最終檢出率降低約30%.

7 總結(jié)

本文對安卓生態(tài)系統(tǒng)安全性受到對抗分析技術(shù)的影響進行了系統(tǒng)性的研究.為實現(xiàn)此研究，本文設(shè)計并實現(xiàn)了自動化加固工具AATPacker，能夠?qū)Π沧繎?yīng)用有選擇地附加不同種類對抗分析技術(shù).基于AATPacker，本文揭示了現(xiàn)有研究工作尚未在實際安卓生態(tài)系統(tǒng)中得到足夠應(yīng)用，對抗分析技術(shù)仍能起到對抗分析效果.在各類對抗分析技術(shù)中，動態(tài)代碼加載產(chǎn)生的影響最為顯著.而作為對抗分析技術(shù)提供者的商業(yè)化加固服務(wù)，其本身缺乏對對抗分析技術(shù)的反對抗，使其服務(wù)易于被惡意軟件作者濫用，進一步加大檢測分析惡意軟件的難度.上述安卓生態(tài)系統(tǒng)中的薄弱環(huán)節(jié)應(yīng)作為將來反對抗分析技術(shù)研究工作的重點方向.