朱洪軍 陳耀光 華保健 陳 灝

1(中國科學(xué)技術(shù)大學(xué)軟件學(xué)院 安徽 合肥 230051)2(中國科學(xué)技術(shù)大學(xué)蘇州研究院 江蘇 蘇州 215123)

?

一種Android應(yīng)用加固方案

朱洪軍1,2陳耀光1華保健1,2陳 灝1

1(中國科學(xué)技術(shù)大學(xué)軟件學(xué)院 安徽 合肥 230051)2(中國科學(xué)技術(shù)大學(xué)蘇州研究院 江蘇 蘇州 215123)

Android應(yīng)用安全問題日益突出，大量Android應(yīng)用遭受逆向、非法復(fù)制及惡意代碼注入等攻擊。對Android應(yīng)用安全機(jī)制進(jìn)行研究，在分析靜態(tài)逆向和動態(tài)逆向攻擊原理的基礎(chǔ)上，提出一種移動應(yīng)用加固保護(hù)方案。方案綜合運(yùn)用加殼、反調(diào)試、簽名校驗(yàn)及反編譯等應(yīng)用加固技術(shù)，對目標(biāo)應(yīng)用進(jìn)行加固；經(jīng)測試，該加固方案能夠很好地對抗常見的靜態(tài)分析和動態(tài)分析等逆向攻擊。

加固 反調(diào)試 Android安全 加殼

0 引 言

2014年5月，中國工業(yè)和信息化部電信研究院發(fā)布《移動互聯(lián)網(wǎng)白皮書》[1]。文獻(xiàn)[1]指出：Android(安卓)在中國市場的主導(dǎo)優(yōu)勢更為凸顯。2013年四季度 Android 以新增市場94.6%的絕對領(lǐng)先優(yōu)勢主導(dǎo)國內(nèi)市場。同時(shí)，Android安全問題也日益嚴(yán)重，另據(jù)手機(jī)安全公司統(tǒng)計(jì)，2013年受惡意吸費(fèi)代碼感染的終端數(shù)量高達(dá)1400萬，用戶直接經(jīng)濟(jì)損失超過7000萬元。

基于Android平臺的應(yīng)用程序代碼經(jīng)過編譯器編譯生成Android應(yīng)用壓縮包APK，APK極易被逆向工具，如Apktool(谷歌公司提供的一種用于APK反編譯的工具)等進(jìn)行反編譯，從而開展逆向攻擊。自2.3版本發(fā)布之后，Android平臺引入了代碼混淆機(jī)制；通過代碼混淆僅增加了逆向分析的難度和工作量，應(yīng)用程序核心邏輯仍然可以通過函數(shù)調(diào)用關(guān)系進(jìn)行逆向破解與攻擊[2,3]。因此，未經(jīng)加固的Android應(yīng)用程序無法很好地對抗惡意代碼注入、非法拷貝等攻擊。Android應(yīng)用一旦遭受攻擊，就可能被植入廣告、程序后門，甚至竊取用戶隱私數(shù)據(jù)，給用戶帶來嚴(yán)重?fù)p失。

文獻(xiàn)[2]提出了一種基于classes.dex(APK壓縮包中可執(zhí)行代碼包)文件動態(tài)加載的Android平臺加固方案，可以有效地隱藏關(guān)鍵代碼，生成目標(biāo)代碼保護(hù)殼，但其并未實(shí)現(xiàn)對殼文件的有效保護(hù)。文獻(xiàn)[4]提出的Android加固方案是在加殼的基礎(chǔ)上添加了對殼程序的保護(hù)措施，例如偽加密、代碼混淆、簽名校驗(yàn)等，但其提出的保護(hù)措施僅在Java層，通過簡單逆向攻擊手段，如直接修改smali代碼，就可以輕易破解。

在此基礎(chǔ)上，本文提出一種移動應(yīng)用加固方案：通過將目標(biāo)虛擬機(jī)可執(zhí)行文件dex(Dalvik VM Executes)加密之后隱藏在如圖片等資源文件中，使用非法屬性識別符ID(Identifier)、反調(diào)試及簽名校驗(yàn)等技術(shù)，對目標(biāo)應(yīng)用程序進(jìn)行加固。實(shí)驗(yàn)結(jié)果表明：本加固方案可以很好地對抗反編譯、逆向分析、非法復(fù)制及重打包等逆向攻擊。

1 Android應(yīng)用逆向分析概述

1.1 APK文件結(jié)構(gòu)

APK文件是Android平臺下的可執(zhí)行文件，它本質(zhì)上是一種zip壓縮文件格式，其文件結(jié)構(gòu)及作用大致如表1[5,6]所示。

表1 APK文件目錄

其中classes.dex文件是Dalvik虛擬機(jī)字節(jié)碼文件，是攻擊者進(jìn)行逆向分析與攻擊的目標(biāo)。dex文件主要結(jié)構(gòu)如圖1所示。

圖1 dex主要結(jié)構(gòu)

在dex header中checksum和signature分別是對dex文件的校驗(yàn)值和簽名值，系統(tǒng)在加載dex時(shí)會校對dex的簽名及檢驗(yàn)值，避免加載損壞的dex，在一定程度上增加應(yīng)用程序安全性。

1.2 靜態(tài)分析

靜態(tài)分析是指在不運(yùn)行代碼的情況下，采用詞法分析、語法分析等各種技術(shù)手段對程序文件進(jìn)行掃描從而生成程序的反匯編代碼，然后閱讀反匯編代碼來掌握程序的一種技術(shù)[7,8]。

靜態(tài)分析Android程序主要有兩種方法：一是閱讀反匯編生成的smali代碼，二是閱讀反匯編生成的Java代碼。靜態(tài)逆向分析的關(guān)鍵是要找到程序的關(guān)鍵代碼，常用的定位關(guān)鍵代碼的方法有以下幾種[7]：

(1) 特征函數(shù)法

通過查找系統(tǒng)關(guān)鍵API來定位關(guān)鍵代碼。

(2) 順序查看法

從軟件啟動代碼開始逐行分析代碼。

(3) 代碼注入法

通過smali注入代碼使得APK自動輸出關(guān)鍵數(shù)據(jù)。

(4) 棧跟蹤法

通過輸出運(yùn)行時(shí)棧上的函數(shù)調(diào)用序列來分析執(zhí)行流程。

(5) Method Profiling

分析程序性能，跟蹤函數(shù)調(diào)用關(guān)系等。

在對抗靜態(tài)分析時(shí)，常用的方法是找到某些靜態(tài)分析工具自身漏洞，針對漏洞做出一些特定的反制措施。常用的靜態(tài)分析工具有Apktool、Backsmali、smali、Dex2jar、AXMLPrinter2.jar等。

1.3 動態(tài)分析

動態(tài)分析是在沒有軟件源代碼的情況下，通過調(diào)試器跟蹤分析匯編代碼。對于Android應(yīng)用，動態(tài)跟蹤調(diào)試又可分為動態(tài)調(diào)試Android SDK程序和動態(tài)調(diào)試Android原生程序[7]；

動態(tài)逆向分析常用的工具有以下幾種[7]：

(1) AndBug

AndBug是一款腳本式Android程序動態(tài)調(diào)試器，通過AndBug可以完成Android程序的無源碼調(diào)試。

(2) IDA Pro

在IDA Pro6.6之后版本不僅能動態(tài)調(diào)試APK中的so動態(tài)鏈接庫，還可以直接動態(tài)調(diào)試APK。

(3) Gdb

Android以Linux內(nèi)核為基礎(chǔ)，所以可以使用gdb配合gdbserver進(jìn)行Android原生程序匯編級調(diào)試。

(4) NetBeans、Eclipse

通過apktool在APK中加入調(diào)試信息之后可以通過NetBeans或Eclipse完成smali代碼的動態(tài)調(diào)試。

在對抗動態(tài)逆向分析時(shí)，常用的方法是檢測APK是否被調(diào)試器附加，比如后文中提到的檢測/proc/pid/status文件中的TracePid來判斷是否被調(diào)試器附加。

2 加固方案設(shè)計(jì)

2.1 加固方案綜述

加固方案共分為兩個階段，主要流程及各階段完成的功能如圖2所示。

圖2 加固方案主要流程

加固階段一主要完成對目標(biāo)APK的加殼，對受保護(hù)的目標(biāo)代碼進(jìn)行隱藏；加固階段二通過加載libsecurity.so安全庫來完成殼的自我保護(hù)，采用的技術(shù)包括反調(diào)試、防止重打包(通過簽名校驗(yàn)保護(hù)方式)和防止反編譯等。

在加固階段一和二中主要涉及到5種對象：

(1) 目標(biāo)APK

目標(biāo)APK是要被加固的apk，目標(biāo)APK中的dex文件稱為目標(biāo)dex文件。

(2) 加殼程序

加殼程序負(fù)責(zé)進(jìn)行具體的加殼操作，完成的功能主要有：提取目標(biāo)APK中的dex、lib、res等源數(shù)據(jù)；加密目標(biāo)dex并嵌入圖片；將加密密鑰寫入殼APK的dex末尾。

(3) 殼APK

在殼程序運(yùn)行時(shí)完成兩件事，首先加載安全庫libsecurity.so，然后解密出目標(biāo)dex并完成動態(tài)加載。主要的反調(diào)試功能放在安全庫libsecurity.so中用C++語言實(shí)現(xiàn)，同時(shí)加入反調(diào)試，簽名校驗(yàn)等安全措施。

(4) 防反編譯程序

負(fù)責(zé)在殼APK中的axml文件中插入非法id值，防止APK被apktool反編譯。

(5) 加固后的APK

經(jīng)過簽名之后生成最終加固好的APK，該APK可被正確安裝及運(yùn)行，且功能和目標(biāo)APK相同。

2.2 加殼方案設(shè)計(jì)

由于Dalvik字節(jié)碼容易被反編譯，攻擊者可以輕易地從反編譯出的指令代碼中找到程序的關(guān)鍵邏輯[9]。為了防止應(yīng)用程序被反編譯，同時(shí)對抗靜態(tài)分析，通過加殼來隱藏真正的dex文件，可以很好地防止攻擊者直接反編譯出目標(biāo)應(yīng)用指令代碼。

圖3 目標(biāo)dex加密流程

傳統(tǒng)加殼方案直接將加密后的目標(biāo)dex放在殼dex末尾[10,11]，使得殼dex本身攜帶可疑代碼，攻擊者可以輕松地識別并靜態(tài)剝離出加密后的目標(biāo)dex，通過解密密鑰解密出目標(biāo)dex。為了解決此問題，可以將加密后目標(biāo)dex隱藏在如圖片等資源文件中，可以減弱目標(biāo)可疑特征，從而對抗攻擊者的攻擊。目標(biāo)dex加密流程如圖3所示。

目標(biāo)dex加密時(shí)，首先生成隨機(jī)加密密鑰，再讀取目標(biāo)dex并且用AES算法對其進(jìn)行加密，將加密后的dex嵌入資源文件如png格式圖片中，最后再將隨機(jī)生成的密鑰寫入殼dex末尾。殼dex文件結(jié)構(gòu)大致如圖4所示。

圖4 殼dex文件結(jié)構(gòu)

由于殼dex嵌入了解密密鑰，結(jié)構(gòu)遭到破壞，需要重新計(jì)算殼dex頭部中的checksum、signature和filesize幾個屬性值。

解密目標(biāo)dex流程如圖5所示。

圖5 對目標(biāo)dex解密的主要流程

解密時(shí)，首先從殼dex的末尾讀取出加密密鑰，然后在從存放目標(biāo)dex的資源文件中讀加密dex，使用AES算法對其進(jìn)行解密，之后得到解密后的目標(biāo)dex。

殼程序運(yùn)行主要流程如圖6所示。

圖6 殼程序運(yùn)行流程圖

在殼程序運(yùn)行時(shí)首先加載安全庫libsecurity.so，libsecurity.so中首先通過fork創(chuàng)建子進(jìn)程，子進(jìn)程專門用做反調(diào)試和簽名校驗(yàn)。父進(jìn)程則負(fù)責(zé)動態(tài)加載dex，首先將原類加載器替換成DexClassLoader加載器，然后分別從殼dex末尾和圖片中讀出密鑰和加密后的目標(biāo)dex，用密鑰解密出目標(biāo)dex后，動態(tài)替換殼application中的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)，進(jìn)而完成目標(biāo)APK的動態(tài)加載。 在運(yùn)行期間，若子進(jìn)程檢測到反調(diào)試或重打包，則直接殺死父進(jìn)程退出程序。

2.3 殼自身保護(hù)方案設(shè)計(jì)

加殼可以隱藏目標(biāo)APK，但是不能防止APK被動態(tài)調(diào)試。本節(jié)在加殼的基礎(chǔ)上加入殼自身保護(hù)技術(shù)。通過ptrace檢測/proc/pid/status和inotify監(jiān)控關(guān)鍵文件來防止動態(tài)調(diào)試；通過簽名校驗(yàn)防止APK被重打包；通過在AXML中插入非法ID來防止反編譯；綜合多種保護(hù)措施共同保護(hù)殼APK的安全。

2.3.1 反調(diào)試方案設(shè)計(jì)(1) 通過檢查/proc目錄反調(diào)試

本加固方案通過定期檢測/proc/pid/status中的TracerPid來防止被調(diào)試，若檢測到調(diào)試器則殺死主進(jìn)程。該反調(diào)試流程如圖7所示。

圖7 檢測/proc目錄反調(diào)試流程圖

在Linux系統(tǒng)下一個進(jìn)程可以通過ptrace系統(tǒng)調(diào)用來監(jiān)控另一個進(jìn)程的執(zhí)行流程，gdb等調(diào)試軟件的核心原理即是通過ptrace系統(tǒng)調(diào)用。ptrace系統(tǒng)調(diào)用的第一個參數(shù)可以指定執(zhí)行行為，比如當(dāng)?shù)谝粋€參數(shù)為 PTRACE_TRACEME時(shí)表示本進(jìn)程被其父進(jìn)程跟蹤，在父進(jìn)程中可以使用PTRACE_ATTACH附加至子進(jìn)程完成調(diào)試。ptrace系統(tǒng)調(diào)用可以用于進(jìn)程調(diào)試，但是它有一個限制：一個進(jìn)程不能被ptrace多次。根據(jù)這個原理可知，只要在進(jìn)程中主動調(diào)用ptrace就可以實(shí)現(xiàn)基本的反調(diào)試。

Android使用Linux內(nèi)核，而Linux內(nèi)核提供了一種名為/proc的文件系統(tǒng)，通過/proc可以在運(yùn)行時(shí)訪問和改變某些內(nèi)核內(nèi)部數(shù)據(jù)結(jié)構(gòu)。 由于proc文件系統(tǒng)只存在于內(nèi)存中，所以其本質(zhì)上是一個偽文件系統(tǒng)。在進(jìn)程運(yùn)行過程中一些內(nèi)核狀態(tài)是在不斷變化的，所以通過proc文件系統(tǒng)讀取的進(jìn)程狀態(tài)也可能是不斷變化的。其中的/proc/pid/status文件就存儲了進(jìn)程號為pid的進(jìn)程狀態(tài)，通過定時(shí)檢測/proc/pid/status中的TracerPid，若該字段不為0時(shí)表示調(diào)試進(jìn)程的pid，若檢測到TracerPid不為0則直接殺死主進(jìn)程。

(2) 通過inotify反調(diào)試

在Linux操作系統(tǒng)下可以通過inotify來通知用戶應(yīng)用程序文件系統(tǒng)的某些變化，可以利用inotify來實(shí)現(xiàn)監(jiān)控某些文件系統(tǒng)事件，比如文件的打開、讀寫和刪除等。而/proc偽文件系統(tǒng)目錄下有一些十分關(guān)鍵的的文件可能被破解者利用，比如破解者可以通過/proc/pid/maps查看進(jìn)程地址空間分布情況，進(jìn)而通過dd命令直接dump出關(guān)鍵內(nèi)存區(qū)域，所以可以通過inotify來監(jiān)控這些敏感文件的讀取和打開，從而完成反調(diào)試。

通過inotify監(jiān)控/proc/pid/maps文件的關(guān)鍵代碼大致如下：

?

fd = inotify_init();

sprintf(buf, ″/proc/%d/maps″,ppid);

wd = inotify_add_watch(fd, buf, IN_ALL_EVENTS);

?

len = read(fd,readbuf,MAXLEN);

while(i < len){

struct inotify_event *event = (struct inotify_event*)&readbuf[i];

if((event->mask&IN_ACCESS) || (event->mask&IN_OPEN)){

int ret = kill(ppid,SIGKILL);

return;

}

i+=sizeof (struct inotify_event) + event->len;

}

?

2.3.2 防止重打包

早期的完整性校驗(yàn)直接放在Java層進(jìn)行，這時(shí)通過直接修改smali代碼可以很輕易的繞過校驗(yàn)，示例如下：

const-string v1, ″com/example/checksignature″

invoke-virtual{p0,v1}, Lcom/example/checksignature/MainActivity;->getSignature(Ljava/lang/String;)I

move-result v0

const v1, 0x7b7c6261

if-eq v0, v1, :cond_0

//相等則驗(yàn)證成功，否則驗(yàn)證失敗

?

在破解時(shí)只需將if-eq改成if-ne即可繞過簽名驗(yàn)證[12]。本文實(shí)現(xiàn)的加固方案中的完整性校驗(yàn)并不放在Java層，而是通過JNI編程放在動態(tài)鏈接安全庫(libsecurity.so)中，主要原理是通過反射調(diào)用PackageManager類中的getPackageInfo()方法來獲取應(yīng)用程序簽名。由于在加載安全庫libsecurity.so時(shí)做了動態(tài)反調(diào)試，所以除非破解了反調(diào)試，否則無法通過簡單的改寫代碼來繞過簽名驗(yàn)證，這樣大大增加了應(yīng)用的安全性。

2.3.3 防止反編譯

在Android的manifest.xml文件是Android應(yīng)用中最重要的文件之一，它存儲了一個應(yīng)用程序運(yùn)行所需的權(quán)限、應(yīng)用程序的各個組件(activity，service等)、應(yīng)用程序的入口點(diǎn)等重要信息。但是早期的加固方案沒有對manifest做任何處理，這就導(dǎo)致破解者可以很輕易從manifest文件中找到一些關(guān)鍵信息。本文實(shí)現(xiàn)的加固方案對manifest文件做了一定的保護(hù)，可以有效地增加APK被破解的難度。

axml是AndroidManifest.xml對應(yīng)的二進(jìn)制文件，直接解壓apk包獲得的AndroidManifest文件即是amxl格式。apktool在解析axml文件時(shí)有一個漏洞，它會解析amxl中的所有屬性id，當(dāng)遇到非法屬性id時(shí)就會解析失敗。所以可以通過這個漏洞在axml文件中插入擁有非法id的屬性，使得apktool等逆向工具解析失敗，無法正常反編譯。由于android系統(tǒng)不解析非法id，所以apk包還是能夠正常安裝。

當(dāng)插入非法屬性id時(shí)apktool解析失敗，防止反編譯效果如圖8所示(插入非法ID值atest)。

圖8 防反編譯效果圖

在axml文件中插入非法id值之后需要對apk包進(jìn)行重簽名，通過這種方法可以在一定程度上防止反編譯，但是又不影響apk包的正常安裝。

3 實(shí)現(xiàn)與評價(jià)

在Android應(yīng)用市場(http://www.appchina.com/，截至2015年4月)隨機(jī)選取游戲類、資訊閱讀類、系統(tǒng)工具類、生活實(shí)用類等5款類型不同且大小也不同的apk(目標(biāo)APK未加殼)進(jìn)行加固方案測試，加固前后的應(yīng)用大小變化如表2所示。

表2 加固后應(yīng)用包大小變化(單位：字節(jié))

測試結(jié)果表明：經(jīng)過加固后應(yīng)用程序大致增加了400～500 KB的容量。加殼后APK變大的主要增量是libsecurity.so動態(tài)庫和解殼工程。

通過對常見的逆向工具測試，加固方案效果如表3所示。

表3 加固方案對抗逆向工具評測

注：√表示加固方法對某逆向工具有效，Χ表示加固方法對該逆向工具無效

測試結(jié)果表明：不同的加固方法對不同的逆向工具有效。通過apktool漏洞可以使得apktool反編譯失?。患託た梢允沟胊pktool、dex2jar或JEB無法反編譯出真正的dex；通過ptrace檢測/proc文件夾等反調(diào)試措施可以防止IDA Pro、NetBeans的動態(tài)調(diào)試；簽名校驗(yàn)可以防止NetBeans動態(tài)調(diào)試。綜合上述，所有加固方法可以對目標(biāo)APK起到有效全面的保護(hù)。

4 結(jié) 語

通過對Android安全機(jī)制的研究，分析常見逆向攻擊機(jī)制，設(shè)計(jì)了一種移動應(yīng)用加固方案。該方案將加密后的目標(biāo)dex嵌入圖片可以有效隱藏目標(biāo)dex，實(shí)驗(yàn)表明，加殼保護(hù)技術(shù)可以有效防止目標(biāo)APK被靜態(tài)分析。使用ptrace和檢測/proc/pid/status和inotify監(jiān)控關(guān)鍵文件，可以有效完成反調(diào)試保護(hù)。此外，加固方案還加入了JNI層的簽名校驗(yàn)，能有效防止重打包。加固方案的最后一個階段還利用apktool解析漏洞添加非法id值，使得殼APK無法被反編譯。通過測試，加固后的APK文件會大致增加400～500 KB的容量，對APK運(yùn)行或加載效率造成較小影響。本加固方案沒有實(shí)現(xiàn)對抗dump內(nèi)存的逆向攻擊方法，攻擊者仍然可以通過內(nèi)存拷貝等方式，找到目標(biāo)dex代碼。

本加固方案仍然有需要改進(jìn)和完善的地方，在接下來工作中將會著重研究：1) so加殼保護(hù)。dex加殼無法防止內(nèi)存dump，但通過so加殼保護(hù)則能大大增加內(nèi)存dump的難度。2) AndroidManifest.xml配置保護(hù)。AndroidManifest.xml配置文件作為應(yīng)用程序的“說明書”，當(dāng)前加固方案對其的保護(hù)不足，這是另一個研究重點(diǎn)。

[1] 工信部.移動互聯(lián)網(wǎng)白皮書[R].北京,2014.

[2] 巫志文,李煒.基于Android平臺的軟件加固方案的設(shè)計(jì)與實(shí)現(xiàn)[J].電信工程技術(shù)與標(biāo)準(zhǔn)化,2015(1):33-37.

[3] 吳善崇,張權(quán).Android平臺安全機(jī)制淺析[J].實(shí)驗(yàn)科學(xué)與技術(shù),2014,12(2):43-45.

[4] 徐劍,武爽,孫琦,等.面向Android應(yīng)用程序的代碼保護(hù)方法研究[J].信息網(wǎng)絡(luò)安全,2014(10):11-17.

[5] 梅瑞,武學(xué)禮,文偉平.基于Android平臺的代碼保護(hù)技術(shù)研究[J].信息網(wǎng)絡(luò)安全,2013(7):10-15.

[6] 伍景珠.基于Android平臺的軟件保護(hù)方案的研究與實(shí)現(xiàn)[D].北京郵電大學(xué),2013.

[7] 豐生強(qiáng).Android軟件安全與逆向分析[M].北京:人民郵電出版社,2013.

[8] 張志遠(yuǎn),萬月亮,翁越龍,等.Android應(yīng)用逆向分析方法研究[J].信息網(wǎng)絡(luò)安全,2013(6):65-68.

[9] 劉劼.Java反編譯技術(shù)和代碼安全[J].現(xiàn)代電子技術(shù),2004,27(10):22-24.

[10] 姚為光.軟件加殼技術(shù)的研究[D].電子科技大學(xué),2011.

[11] 李文.基于殼技術(shù)的軟件保護(hù)研究[D].電子科技大學(xué),2012.

[12] 李宇翔,林柏鋼.基于Android重打包的應(yīng)用程序安全策略加固系統(tǒng)設(shè)計(jì)[J].信息網(wǎng)絡(luò)安全,2014(1):43-47.

AN ANDROID APPLICATION REINFORCEMENT SCHEME

Zhu Hongjun1,2Chen Yaoguang1Hua Baojian1,2Chen Hao1

1(School of Software Engineering,University of Science and Technology of China,Hefei 230051,Anhui,China)2(Suzhou Institute for Advanced Study,University of Science and Technology of China,Suzhou 215123,Jiangsu,China)

Nowadays, the problem of Android application security is increasingly prominent. A large number of Android applications encounter the attacks such as reverse, illegal copy and malicious code injection, etc. We studied the security mechanism of Android applications, based on analysing static reverse and dynamic reverse attacks principle, we put forward a reinforcement protection scheme for mobile applications. The scheme comprehensively uses the application reinforcement technologies of shelling, anti-debugging, signature verification and anti-decompiling, etc., to reinforce target applications. Through a series of tests, it is proved that this scheme can well resist common reverse attacks of static analysis and dynamic analysis.

Reinforcement Anti-debugging Android security Shelling

2015-06-25。教育部-谷歌校企合作專業(yè)綜合改革項(xiàng)目([2014]14)；蘇州市科技計(jì)劃應(yīng)用基礎(chǔ)研究項(xiàng)目(SYG201406)。朱洪軍，講師，主研領(lǐng)域：軟件測試，移動應(yīng)用安全。陳耀光，碩士生。華保健，講師。陳灝，碩士生。

TP309

A

10.3969/j.issn.1000-386x.2016.11.067