用戶態(tài)反調(diào)試檢測(cè)模型

顏瑞彬，高 見，2+，李天洋

(1.中國(guó)人民公安大學(xué) 信息網(wǎng)絡(luò)安全學(xué)院，北京 100038；2.中國(guó)人民公安大學(xué) 安全防范與風(fēng)險(xiǎn)評(píng)估公安部重點(diǎn)實(shí)驗(yàn)室，北京 102623)

0 引 言

近年來，隨著軟件保護(hù)技術(shù)不斷發(fā)展，對(duì)于用戶態(tài)程序的逆向分析越來越困難。逆向分析人員在調(diào)試用戶態(tài)程序時(shí)，受到反調(diào)試技術(shù)、代碼混淆、程序加殼等各類軟件保護(hù)技術(shù)的阻礙。在Windows環(huán)境下，由于反調(diào)試技術(shù)種類眾多，實(shí)現(xiàn)簡(jiǎn)單，因此，大量用戶態(tài)程序均通過反調(diào)試技術(shù)進(jìn)行加固保護(hù)。

在各個(gè)領(lǐng)域中，反調(diào)試技術(shù)雖然保護(hù)了用戶態(tài)程序，但也造成了很多的問題。例如，在網(wǎng)絡(luò)安全領(lǐng)域中，根據(jù)CNCERT互聯(lián)網(wǎng)安全威脅報(bào)告[1]，境內(nèi)大量終端遭到木馬的感染或僵尸網(wǎng)絡(luò)惡意程序的攻擊。由于反調(diào)試技術(shù)存在于木馬或惡意程序中，安全人員無法順利地分析此類用戶態(tài)程序關(guān)鍵信息。在軟件工程領(lǐng)域中，無論是在使用競(jìng)品分析技術(shù)開發(fā)軟件時(shí)，還是在使用凈室技術(shù)避免侵犯著作權(quán)時(shí)，反調(diào)試技術(shù)的應(yīng)用均會(huì)阻礙逆向分析人員正常分析。因此，如何對(duì)抗反調(diào)試技術(shù)逐漸成為一個(gè)亟需解決的問題?，F(xiàn)階段，檢測(cè)反調(diào)試技術(shù)的方法并不完善，大量研究均針對(duì)幾種簡(jiǎn)單API反調(diào)試技術(shù)，無法檢測(cè)其它種類反調(diào)試技術(shù)。同時(shí)，現(xiàn)存的檢測(cè)反調(diào)試技術(shù)的框架存在著僅能識(shí)別部分反調(diào)試技術(shù)的問題或經(jīng)常容易出現(xiàn)誤報(bào)的情況。

為解決相關(guān)問題，本文提出了一種針對(duì)Windows操作系統(tǒng)的用戶態(tài)反調(diào)試檢測(cè)模型。此模型可以檢測(cè)用戶態(tài)程序使用的反調(diào)試技術(shù)的類型和具體位置。用戶態(tài)反調(diào)試檢測(cè)模型包含4個(gè)階段：插樁篩選、粗過濾、細(xì)過濾和插樁驗(yàn)證，主要應(yīng)用3種技術(shù)：①基于Pin插樁的反調(diào)試技術(shù)檢測(cè)方法；②基于IDC的反調(diào)試檢測(cè)算法；③基于機(jī)器碼特征值的反調(diào)試檢測(cè)算法。其中，基于Pin插樁的反調(diào)試技術(shù)檢測(cè)方法主要使用Pin插樁技術(shù)，基于IDC的反調(diào)試檢測(cè)算法和基于機(jī)器碼特征值的反調(diào)試檢測(cè)算法主要利用特征值匹配的技術(shù)。

1 相關(guān)工作

逆向分析技術(shù)，是通過反匯編、反編譯、調(diào)試模擬程序運(yùn)行等手段，分析現(xiàn)有的二進(jìn)制可執(zhí)行文件，得到程序的執(zhí)行流程、數(shù)據(jù)結(jié)構(gòu)等文件信息的一項(xiàng)重要技術(shù)。在逆向分析技術(shù)的研究領(lǐng)域方面，A.M.H.Al-Hakimi等[2]提出一種新的混合混淆加密技術(shù)來阻止逆向分析，經(jīng)過此類混淆加密的代碼幾乎不會(huì)被逆向工具讀取。Umair S等[3]在模型驅(qū)動(dòng)逆向工程(model-driven reverse engineering，MDRE)的基礎(chǔ)之上提出了一種新型MDRE框架。此框架通過Java語言生成了統(tǒng)一建模語言(unified modeling language，UML)的結(jié)構(gòu)和行為圖。Henry WC等[4]介紹了逆向分析人員在逆向分析過程中的困難和挑戰(zhàn)，強(qiáng)調(diào)了有關(guān)逆向工程工具的重要性。Zhang ZY等[5]結(jié)合Android系統(tǒng)的安全檢查設(shè)計(jì)，實(shí)現(xiàn)了對(duì)APP文件的逆向分析技術(shù)，介紹了逆向分析技術(shù)在操作系統(tǒng)中的重要價(jià)值。Sija BD等[6]介紹了協(xié)議自動(dòng)化逆向工程的目標(biāo)、方法、工具及其研究成果，闡述了協(xié)議自動(dòng)化逆向工程的目標(biāo)和障礙。

反調(diào)試技術(shù)是阻止逆向分析者正確定位主函數(shù)位置的一項(xiàng)技術(shù)，它會(huì)引導(dǎo)程序進(jìn)入錯(cuò)誤的執(zhí)行流中。反調(diào)試技術(shù)的出現(xiàn)增大了逆向分析者對(duì)用戶態(tài)程序逆向分析的難度。在反調(diào)試的研究中，Choi S等[7]介紹了一種混合仿真方案x64Unpack，此方案可以分析和打包可執(zhí)行文件，并在64位Windows環(huán)境中自動(dòng)解析它們，降低了逆向分析解析難度。Ping C等[8]介紹了惡意軟件中使用的反調(diào)試技術(shù)和虛擬機(jī)檢測(cè)技術(shù)，對(duì)比分析了普通惡意軟件和具有目標(biāo)的惡意軟件所使用的反調(diào)試技術(shù)和虛擬機(jī)檢測(cè)技術(shù)的區(qū)別。Shi H等[9]提出了用于對(duì)抗反調(diào)試的Apate框架，此框架隱藏了WinDbg的調(diào)試信息，有效地繞過了大部分的調(diào)試技術(shù)。Kim JW等[10]介紹了惡意軟件在使用反調(diào)試技術(shù)時(shí)常用的5個(gè)函數(shù)和一個(gè)數(shù)據(jù)結(jié)構(gòu)，并提出了繞過此類反調(diào)試技術(shù)的方式。Zhang F等[11]提出了MALT的調(diào)試框架，MALT框架不依賴于虛擬化或仿真，因此不會(huì)受到部分反調(diào)試技術(shù)的干擾。吳極等[12]分析并匯總了現(xiàn)有的反調(diào)試技術(shù)及其對(duì)應(yīng)的繞過方法。

Pin插樁作為最流行的動(dòng)態(tài)二進(jìn)制插樁平臺(tái)，被廣泛應(yīng)用于逆向分析、程序調(diào)試、惡意軟件分析等多個(gè)領(lǐng)域。Lee YB等[13]首次提出了繞過軟件中反VM技術(shù)和反DBI技術(shù)的算法，通過針對(duì)5種最常用的商業(yè)保護(hù)軟件的實(shí)驗(yàn)，證明了算法的有效性。在Pin插樁的應(yīng)用方面，Singh A等[14]開發(fā)了一種基于Pin插樁的Mutexis動(dòng)態(tài)檢測(cè)工具，此工具在較低的內(nèi)存開銷下可以實(shí)現(xiàn)動(dòng)態(tài)跟蹤。Zeng J等[15]在Pin的基礎(chǔ)上，提出了一種PEMU框架。PEMU框架不僅支持用戶態(tài)程序的二進(jìn)制追蹤，也支持操作系統(tǒng)級(jí)別的程序追蹤。Zheng B等[16]提出了CBA-Detector精確檢測(cè)器，它可以實(shí)現(xiàn)實(shí)時(shí)檢測(cè)基于緩存的側(cè)通道攻擊。CBA-Detector精確檢測(cè)器結(jié)合Pintools的指令級(jí)監(jiān)控，可以準(zhǔn)確地識(shí)別攻擊。梁曉兵等[17]提出了一個(gè)輕量級(jí)的動(dòng)態(tài)插樁解決方案，此方案不再使用動(dòng)態(tài)二進(jìn)制翻譯的方法，并且可以在無源碼的條件下完成對(duì)信息的動(dòng)態(tài)獲取。

2 反調(diào)試技術(shù)

本文介紹了3類反調(diào)試技術(shù)，分別是基于WindowsAPI的反調(diào)試技術(shù)，基于調(diào)試器信息的反調(diào)試技術(shù)與干擾調(diào)試器工作的反調(diào)試技術(shù)。本文解釋了上述反調(diào)試技術(shù)的原理并分析了它們的特征，其結(jié)果見表1。

表1 3類反調(diào)試技術(shù)對(duì)比分析

2.1 基于Windows API的反調(diào)試技術(shù)

2.1.1 IsDebuggerPresent

IsDebuggerPresent是Windows下已公開的API，也是在用戶態(tài)程序中最常用的API。它通過讀取FS段中偏移量為0x30的進(jìn)程環(huán)境塊(process environment block，PEB)指針來檢測(cè)BeingDebugged字段的值。如果有調(diào)試器附加，則返回值為1，否則為0。

2.1.2 NtQueryInformationProcess

作為微軟未公開的API，它通過提取給定進(jìn)程的信息檢測(cè)進(jìn)程是否被調(diào)試。NtQueryInformationProcess的第一個(gè)參數(shù)是進(jìn)程句柄，第二個(gè)參數(shù)是指定特定值并調(diào)用該函數(shù)，相關(guān)信息將會(huì)被設(shè)置到第三個(gè)參數(shù)中。

2.1.3 CheckRemoteDebuggerPresent

CheckRemoteDebuggerPresent與IsDebuggerPresent類似，都是Windows公開的API，都會(huì)在反調(diào)試技術(shù)中檢測(cè)BeingDebugged字段。但是，CheckRemoteDebuggerPresent主要是調(diào)用ntdll中的ZwQueryInformationProcess來檢測(cè)進(jìn)程是否被另一個(gè)獨(dú)立的同步進(jìn)程調(diào)試。

2.1.4 基于程序狀態(tài)的APIs

基于程序狀態(tài)的APIs利用調(diào)試時(shí)的進(jìn)程狀態(tài)，對(duì)程序是否有調(diào)試器附加進(jìn)行檢測(cè)。常用的基于程序狀態(tài)的APIs主要如下：

(1)反調(diào)試技術(shù)通過調(diào)用OpenProcess，檢測(cè)是否有權(quán)限打開csrss.exe進(jìn)程，進(jìn)而檢測(cè)是否有調(diào)試器的附加。

(2)在獲取進(jìn)程信息的相關(guān)API中，反調(diào)試技術(shù)通過調(diào)用CreateToolhelp32Snapshot和Process32 Next，獲取進(jìn)程的相關(guān)信息，檢測(cè)是否有調(diào)試器附加。

(3)反調(diào)試技術(shù)通過調(diào)用CloseHandle，造成程序拋出異常Invalid Handle(0xC0000008)。

(4)反調(diào)試技術(shù)也可以調(diào)用LoadLibrary、LoadLibraryEx或LdrLoadDll打開任意文件后，再次通過其它API打開此文件，以檢測(cè)是否有調(diào)試器附加。

2.1.5 基于調(diào)試行為的APIs

基于調(diào)試行為的APIs是利用調(diào)試時(shí)調(diào)試器的行為，檢測(cè)程序是否有調(diào)試器附加。常用的基于調(diào)試行為的APIs主要如下：

(1)反調(diào)試技術(shù)通過修改DbgBreakPoint中的匯編指令，阻止DbgBreakPoint在程序中加入斷點(diǎn)，使調(diào)試器無法程序斷下。

(2)DbgPrint等相關(guān)異常處理API與UEF異常處理類似，可以檢測(cè)是否有調(diào)試器附加。

(3)反調(diào)試技術(shù)通過調(diào)用ReadFile可以修改返回地址，導(dǎo)致進(jìn)程崩潰，實(shí)現(xiàn)反調(diào)試的效果。

2.2 基于調(diào)試器信息的反調(diào)試技術(shù)

2.2.1 進(jìn)程信息檢測(cè)

反調(diào)試技術(shù)常通過檢測(cè)BeingDebugged標(biāo)志，確定該進(jìn)程是否被調(diào)試。反調(diào)試技術(shù)可以通過fs：[30]找到PEB的基地址，進(jìn)而確定BeingDebugged標(biāo)志。IsDebuggerPresent函數(shù)的本質(zhì)就是通過這種方式實(shí)現(xiàn)反調(diào)試技術(shù)的。同樣，可以通過匯編語言直接對(duì)BeingDebugged標(biāo)志進(jìn)行檢測(cè)。

2.2.2 堆上信息檢測(cè)

反調(diào)試技術(shù)可以檢測(cè)堆上的ProcessHeap和NtGlobalFlag屬性。ProcessHeap位于PEB結(jié)構(gòu)體中偏移量0x18處，屬性字段主要包括HeapForceFlags和HeapFlags，它們均可用來檢測(cè)調(diào)試信息。NtGlobalFlag位于PEB結(jié)構(gòu)體中偏移量0x68處，該字段的默認(rèn)值為0，在調(diào)試器附加時(shí)，該字段會(huì)被設(shè)置為一個(gè)特定的值。

2.2.3 系統(tǒng)痕跡檢測(cè)

在逆向分析者調(diào)試程序時(shí)，調(diào)試器的附加可能會(huì)留下痕跡。最常用的系統(tǒng)痕跡檢測(cè)包括檢測(cè)注冊(cè)表項(xiàng)和檢測(cè)窗口信息。

2.2.4 父進(jìn)程檢測(cè)

Windows系統(tǒng)程序的父進(jìn)程一般都是explorer.exe。但在調(diào)試器附加時(shí)，程序的父進(jìn)程則是調(diào)試器進(jìn)程。因此，可以直接檢測(cè)程序的父進(jìn)程以確定是否有調(diào)試器附加。同時(shí)，在父進(jìn)程的影響下，也可以通過STARTUPINFO信息或SeDebugPrivilege權(quán)限檢測(cè)程序是否被調(diào)試。

2.2.5 時(shí)鐘檢測(cè)

調(diào)試時(shí)代碼運(yùn)行速率要遠(yuǎn)小于沒有調(diào)試時(shí)的代碼運(yùn)行速率。反調(diào)試技術(shù)通過兩次rdtsc指令比較時(shí)間戳的差值，進(jìn)而判斷是否被調(diào)試。QueryPerformanceCounter和GetTickCount也可以用來進(jìn)行時(shí)鐘檢測(cè)。

2.2.6 TLS回調(diào)檢測(cè)

TLS回調(diào)函數(shù)在線程建立或銷毀時(shí)被調(diào)用，而在調(diào)試器附加時(shí)，調(diào)試線程的起點(diǎn)位于kernel32.dll中，這與普通線程不同?；诖?，反調(diào)試技術(shù)可以檢測(cè)線程的起點(diǎn)，進(jìn)而確定是否存在調(diào)試器的附加。TLS回調(diào)函數(shù)也會(huì)在用戶定義的主函數(shù)之前被調(diào)用，因此，也可以在TLS回調(diào)函數(shù)中調(diào)用其它反調(diào)試技術(shù)檢測(cè)程序是否有調(diào)試器附加。

2.3 干擾調(diào)試器工作的反調(diào)試技術(shù)

2.3.1 異常處理

反調(diào)試技術(shù)中，常用RaiseException函數(shù)、UEF以及interrupt 3斷點(diǎn)等方式干擾調(diào)試器工作。其中，在UEF異常處理中，如果程序通過SetUnhandledExceptionFilter函數(shù)設(shè)置了UEF，在調(diào)試器附加時(shí)，UEF不會(huì)被調(diào)用。另外，調(diào)用GenerateConsoleCtrlEvent時(shí)，查看程序是否會(huì)拋出EXCEPTION_CTL_C異常，進(jìn)而檢測(cè)程序是否被調(diào)試器附加。

2.3.2 調(diào)試器漏洞

用戶態(tài)程序編寫者有時(shí)通過調(diào)試器漏洞阻止分析人員進(jìn)行調(diào)試，這類反調(diào)試手段通常針對(duì)Ollydbg。例如，如果設(shè)置的DataDirectory數(shù)組元素個(gè)數(shù)超過0x10，Ollydbg會(huì)自動(dòng)退出。其它有關(guān)通過調(diào)試器漏洞實(shí)現(xiàn)反調(diào)試技術(shù)的方法與之類似。

2.3.3 步過(step over)失效

逆向分析人員在動(dòng)態(tài)分析遇到匯編指令call或rep時(shí)，常常使用F8步過該匯編指令。在這種情況下，調(diào)試器會(huì)將0xCC斷點(diǎn)設(shè)置在call或rep匯編指令的下一個(gè)匯編指令的位置。反調(diào)試技術(shù)可以檢測(cè)下一條指令是否為0xCC，判斷是否有調(diào)試器附加。

2.3.4 輸入設(shè)備封鎖

有關(guān)鍵盤封鎖的反調(diào)試經(jīng)常通過BlockInput實(shí)現(xiàn)。BlockInput會(huì)阻止鍵盤、鼠標(biāo)等輸入設(shè)備對(duì)該進(jìn)程的輸入，因此，調(diào)試器將無法使用F7、F8等調(diào)試命令進(jìn)行動(dòng)態(tài)調(diào)試。此外，SwitchDesktop也可以阻止鍵盤、鼠標(biāo)事件傳遞給調(diào)試器，阻止分析人員的正常調(diào)試。

3 反調(diào)試檢測(cè)算法與模型

傳統(tǒng)的反調(diào)試檢測(cè)大多是通過IDA pro的導(dǎo)入表，手動(dòng)分析程序中使用的反調(diào)試技術(shù)。在使用大量反調(diào)試技術(shù)的用戶態(tài)程序中，確定此程序使用的反調(diào)試技術(shù)比較困難。因此，本文提出了一種基于Pin插樁的反調(diào)試檢測(cè)技術(shù)，以判斷用戶態(tài)程序是否使用反調(diào)試技術(shù)。同時(shí)，提出了兩種特征值檢測(cè)技術(shù)，分析并確定用戶態(tài)程序使用反調(diào)試技術(shù)的種類和具體位置。

基于Pin插樁的反調(diào)試檢測(cè)技術(shù)是通過檢測(cè)主函數(shù)中call指令數(shù)量與ret指令數(shù)量是否相同，進(jìn)而確定程序是否使用了反調(diào)試技術(shù)?；贗DC的反調(diào)試檢測(cè)技術(shù)是通過IDA導(dǎo)出IDC-Database，在IDC-Database中遍歷程序所調(diào)用的API以及相關(guān)函數(shù)，并依次與特征庫進(jìn)行對(duì)比，進(jìn)而判斷反調(diào)試技術(shù)的種類，定位調(diào)用反調(diào)試技術(shù)的位置?；跈C(jī)器碼特征值的反調(diào)試檢測(cè)技術(shù)是對(duì)于可執(zhí)行程序的機(jī)器碼進(jìn)行檢測(cè)。可執(zhí)行程序中，同樣的反調(diào)試技術(shù)在對(duì)應(yīng)位置具有相同或類似的機(jī)器碼?；诖耍瑱z測(cè)算法將程序中的機(jī)器碼依次與機(jī)器碼庫中的反調(diào)試特征機(jī)器碼進(jìn)行對(duì)比，進(jìn)而確定反調(diào)試技術(shù)種類和位置。

同時(shí)，本文基于3種反調(diào)試檢測(cè)技術(shù)提出了反調(diào)試檢測(cè)模型。該模型分為插樁篩選、粗過濾、細(xì)過濾、插樁驗(yàn)證4部分，可以批量自動(dòng)化檢測(cè)用戶態(tài)程序是否存在反調(diào)試技術(shù)，判斷使用的反調(diào)試技術(shù)種類，并定位反調(diào)試技術(shù)的具體位置。

3.1 反調(diào)試檢測(cè)模型

反調(diào)試檢測(cè)模型以3種反調(diào)試檢測(cè)技術(shù)為基礎(chǔ)，由插樁篩選、粗過濾、細(xì)過濾、插樁驗(yàn)證4部分構(gòu)成。上述3種反調(diào)試檢測(cè)技術(shù)在單獨(dú)使用時(shí)，存在著準(zhǔn)確率不高、輸出結(jié)果不理想等問題，無法獲得逆向分析人員希望得到的結(jié)果。因此，反調(diào)試檢測(cè)模型結(jié)合并改進(jìn)了上述3種反調(diào)試檢測(cè)技術(shù)，通過動(dòng)態(tài)和靜態(tài)的兩個(gè)角度，檢測(cè)程序是否含有反調(diào)試技術(shù)。反調(diào)試檢測(cè)模型的框架如圖1所示。

圖1 反調(diào)試檢測(cè)模型框架

反調(diào)試檢測(cè)模型的插樁篩選模塊主要使用基于Pin插樁的反調(diào)試檢測(cè)技術(shù)(詳見3.2節(jié))。它將程序集合中含有反調(diào)試技術(shù)的程序篩選出來，作為第二部分的輸入。此模塊以待檢測(cè)程序作為輸入，通過Pin插樁程序動(dòng)態(tài)監(jiān)控，檢測(cè)call指令數(shù)量與ret指令數(shù)量是否一致，進(jìn)而確定程序中是否含有反調(diào)試技術(shù)。如果call指令數(shù)量與ret指令數(shù)量相同，則將此程序認(rèn)定為不含有反調(diào)試技術(shù)的程序，并將其篩除；否則，將此程序認(rèn)定為含有反調(diào)試技術(shù)的程序，并將其輸入到粗過濾階段。由于插樁篩選運(yùn)行速度較快，可以快速排除掉不含有反調(diào)試技術(shù)的程序，減少了反調(diào)試檢測(cè)模型中后續(xù)過濾過程的運(yùn)行時(shí)間，降低了整體的時(shí)間復(fù)雜度。

粗過濾作為模型的第二部分，它是以基于IDC的反調(diào)試檢測(cè)(算法1)為基礎(chǔ)。其輸入為篩選后含有反調(diào)試技術(shù)的程序。粗過濾主要通過IDC檢測(cè)程序中是否含有反調(diào)試相關(guān)函數(shù)，并定位反調(diào)試函數(shù)在函數(shù)表中的具體位置。粗過濾中，主要以靜態(tài)的方式定位反調(diào)試函數(shù)，獲取與反調(diào)試技術(shù)相關(guān)的API名稱和其在函數(shù)表中的具體位置，為反調(diào)試檢測(cè)模型中的細(xì)過濾提供基礎(chǔ)。

細(xì)過濾是此模型檢測(cè)的核心。它結(jié)合了基于機(jī)器碼特征的反調(diào)試檢測(cè)(算法2)。原始機(jī)器碼庫以機(jī)器碼形式存儲(chǔ)了二進(jìn)制層面上的反調(diào)試技術(shù)。在細(xì)過濾時(shí)，將粗過濾中獲取到的與反調(diào)試技術(shù)相關(guān)的API的位置和名稱作為機(jī)器碼庫的一部分，通過機(jī)器碼庫與原程序機(jī)器碼進(jìn)行逐一對(duì)比，確定此程序是否使用了反調(diào)試技術(shù)。機(jī)器碼庫不僅包含了相關(guān)API的位置和名稱，還存儲(chǔ)了與反調(diào)試技術(shù)相關(guān)的機(jī)器碼。例如，反調(diào)試技術(shù)檢測(cè)BeingDebugged標(biāo)志時(shí)，機(jī)器碼通常是固定的，此段機(jī)器碼將存儲(chǔ)在機(jī)器碼庫中。對(duì)于反調(diào)試技術(shù)相關(guān)API，32位程序可以直接使用函數(shù)表中的反調(diào)試函數(shù)位置。而64位程序需要時(shí)刻計(jì)算當(dāng)前機(jī)器碼位置與函數(shù)表中的反調(diào)試函數(shù)位置的差值，進(jìn)而將差值作為機(jī)器碼庫的一部分。由于機(jī)器碼特征的唯一性，細(xì)過濾可以較為準(zhǔn)確地過濾掉不含有反調(diào)試技術(shù)的程序，并在存在反調(diào)試技術(shù)的程序中，判斷和定位反調(diào)試技術(shù)的類型和位置。

插樁驗(yàn)證是此模型的最后一部分，其目的為自動(dòng)化動(dòng)態(tài)驗(yàn)證程序是否在特定位置使用了反調(diào)試技術(shù)。它同樣以Pin插樁工具為基礎(chǔ)，動(dòng)態(tài)監(jiān)控程序的運(yùn)行。插樁位置選擇在過濾階段獲取到的反調(diào)試技術(shù)具體位置，將動(dòng)態(tài)檢測(cè)過程中獲取到的機(jī)器碼或函數(shù)特征，與細(xì)過濾階段靜態(tài)檢測(cè)得到的反調(diào)試技術(shù)特征進(jìn)行對(duì)比，確定反調(diào)試技術(shù)檢測(cè)是否正確。由于用戶態(tài)程序很難在動(dòng)態(tài)監(jiān)控下隱藏反調(diào)試技術(shù)，因此，插樁驗(yàn)證為反調(diào)試技術(shù)檢測(cè)模型在準(zhǔn)確性上提供了可靠的保障。

3.2 基于Pin插樁的反調(diào)試檢測(cè)

Pin是Intel提出的動(dòng)態(tài)二進(jìn)制插樁工具，它可以動(dòng)態(tài)地監(jiān)控程序的每一步運(yùn)行。在程序正常運(yùn)行時(shí)，call指令將改變IP寄存器的位置，進(jìn)而完成函數(shù)調(diào)用。ret指令在程序調(diào)用結(jié)束時(shí)，將改變IP寄存器，程序?qū)⒎祷氐絚all指令調(diào)用前IP寄存器的位置，相關(guān)示例如圖2(a)所示。因此，主函數(shù)中的call指令數(shù)量與ret指令數(shù)量是一樣的。然而，反調(diào)試技術(shù)通常使程序直接退出。在圖2(b)所示的示例中，如果用戶態(tài)程序?qū)儆谡{(diào)試狀態(tài)，那么將進(jìn)入函數(shù)function1中。程序在函數(shù)function1中調(diào)用了exit()函數(shù)，進(jìn)而直接退出主程序，使得主函數(shù)中的call指令數(shù)量與ret指令數(shù)量不同。

基于Pin插樁的反調(diào)試檢測(cè)是通過Pin插樁技術(shù)，動(dòng)態(tài)檢測(cè)主函數(shù)的call指令數(shù)量與ret指令數(shù)量是否相同，初步篩選出含有反調(diào)試技術(shù)的程序?；赑in插樁的反調(diào)試檢測(cè)流程如圖3所示。

圖3 基于Pin插樁的反調(diào)試檢測(cè)流程

檢測(cè)框架如下：

(1)輸入：存在調(diào)試狀態(tài)的待檢測(cè)程序、Pin插樁程序、call指令計(jì)數(shù)器、ret指令計(jì)數(shù)器。

(2)檢測(cè)：通過Pin插樁程序找到待檢測(cè)程序主函數(shù)位置，動(dòng)態(tài)監(jiān)控待檢測(cè)程序，即只檢測(cè)主函數(shù)的執(zhí)行流。在遇到call指令時(shí)，call指令計(jì)數(shù)器自增；在遇到ret指令時(shí)，ret指令計(jì)數(shù)器自增。最后，將call指令計(jì)數(shù)器的值與ret指令計(jì)數(shù)器的值進(jìn)行對(duì)比。

(3)輸出：如果call指令計(jì)數(shù)器的值與ret指令計(jì)數(shù)器的值相同，將程序標(biāo)記為不含有反調(diào)試技術(shù)程序；否則，將程序標(biāo)記為含有反調(diào)試技術(shù)程序。

基于Pin插樁的反調(diào)試檢測(cè)可以初步確定程序中是否含有反調(diào)試技術(shù)，其檢測(cè)速度快，效率高。

3.3 基于IDC的反調(diào)試檢測(cè)

基于IDC的反調(diào)試檢測(cè)是一種特征值檢測(cè)技術(shù)，其原理為檢測(cè)導(dǎo)出的IDC-Database文件中，是否存在與反調(diào)試API或調(diào)用函數(shù)相關(guān)的字符串信息，進(jìn)而確定程序調(diào)用的反調(diào)試技術(shù)并定位到具體位置，算法如下所示：

算法1：IDC-based Anti-debugging Detection

Input: Programme Function In IDC-Database: X={x1,x2,…,xn}

Output: Anti-debugging Feature: F={f1,f2,…,fn}

(1)FunctionIDC_add(X, Feature_db):

(2)fori ← 1 to Xdo

(3)ifstr_name → Feature_dbdo

(4) name ←GetFunctionName(str_name)

(5) func_addr ←Funcaddr(str_name)

(6)endfor

(7)forj ← 1 tolen(name, func_addr)do

(8) Ad_feature[j].key ← name[j]

(9) Ad_feature[j].value ← func.addr[j]

(10)endfor

(11)returnAd_feature

第(2)～第(6)行遍歷掃描待檢測(cè)程序的IDC文件，將主函數(shù)中出現(xiàn)過的函數(shù)名與反調(diào)試函數(shù)檢測(cè)庫進(jìn)行對(duì)比。如果主函數(shù)的函數(shù)名和反調(diào)試函數(shù)檢測(cè)庫中的函數(shù)名一致，則標(biāo)記其函數(shù)名和函數(shù)在程序中的地址。第(7)～第(10)行對(duì)標(biāo)記的地址與函數(shù)名存入特征庫，并將上述符合要求的函數(shù)名與地址以鍵值對(duì)的形式作為輸出。

在單獨(dú)使用此算法時(shí)，為了更準(zhǔn)確地確定用戶態(tài)程序使用了哪些反調(diào)試技術(shù)，可以通過函數(shù)地址找到對(duì)應(yīng)API并檢測(cè)其是否起到了反調(diào)試的作用。此類反調(diào)試檢測(cè)方法計(jì)算效率高，可以準(zhǔn)確定位到與反調(diào)試相關(guān)的API或調(diào)用函數(shù)的具體位置。

3.4 基于機(jī)器碼特征值的反調(diào)試檢測(cè)

在大多數(shù)反調(diào)試使用時(shí)，其機(jī)器碼是固定且唯一的?；诖朔N情況，機(jī)器碼特征值反調(diào)試檢測(cè)方法將用戶態(tài)程序的機(jī)器碼匹配有關(guān)反調(diào)試技術(shù)的機(jī)器碼，進(jìn)而確定是否使用此種反調(diào)試技術(shù)。由于其機(jī)器碼的固定性與唯一性，幾乎無需手動(dòng)檢查便可以確定該惡意程序是否使用了某種反調(diào)試技術(shù)。其算法如下所示：

算法2：Machine Code Feature Anti-debugging Detection

Input: Programme Sample: X={x1,x2,…,xn}

Output: Anti-debugging Feature: F={f1,f2,…,fn}

(1)FunctionBinary_add(X, Feature_binary):

(2)fori ← 1 to Xdo

(3)ifprogram_bytes → Feature_binarydo

(4)forj ← 1 tolen(Feature_binary)do

(5)ifprogramme_bytes → Feature_binarydo

(6) programme_bytes = program_bytes + 1

(7)elsebreak

(8)ifj ==len(Feature_binary)do

(9) Ad_addr ←Findaddr(programme_bytes-len(Feature_binary))

(10) Ad_function ←Findfunc(Ad_addr)

(11)endfor

(12) programme_bytes = 0

(13)endfor

(14)returnAd_function

第(2)～第(3)行，遍歷掃描待檢測(cè)程序的二進(jìn)制，并將主程序的每個(gè)字節(jié)依次與反調(diào)試機(jī)器碼庫進(jìn)行對(duì)比。第(4)～第(11)行，如果程序某位置的首字節(jié)與反調(diào)試技術(shù)機(jī)器碼庫中某段的首字節(jié)相同，繼續(xù)對(duì)比反調(diào)試技術(shù)機(jī)器碼庫中此段后幾位字節(jié)是否也同樣依次出現(xiàn)在程序此位置中。如果同樣出現(xiàn)，則將此函數(shù)及其位置存入特征庫中，否則繼續(xù)遍歷主程序。

因?yàn)楹茈y出現(xiàn)機(jī)器碼序列一致但程序行為不同的情況，所以此類反調(diào)試檢測(cè)技術(shù)具有較高的準(zhǔn)確性。另外，在檢測(cè)用戶態(tài)程序時(shí)，我們常通過結(jié)合算法1與算法2的方式提高檢測(cè)的準(zhǔn)確率與效率。

4 實(shí)驗(yàn)與分析

本文實(shí)驗(yàn)分為兩部分。其一，本文通過算法1與算法2展開了初步實(shí)驗(yàn)。初步實(shí)驗(yàn)可以確定兩種算法的有效性，并為主體實(shí)驗(yàn)提供基礎(chǔ)。其二，本文基于用戶態(tài)反調(diào)試檢測(cè)模型展開了主體實(shí)驗(yàn)。主體實(shí)驗(yàn)通過用戶態(tài)反調(diào)試檢測(cè)模型對(duì)3類真實(shí)程序進(jìn)行檢測(cè)，得到的檢測(cè)結(jié)果可以驗(yàn)證用戶態(tài)反調(diào)試檢測(cè)模型的準(zhǔn)確率與檢測(cè)效率。另外，本文主體實(shí)驗(yàn)得到了真實(shí)代碼中反調(diào)試技術(shù)使用分布情況，可以有效地預(yù)測(cè)其它種類的用戶態(tài)程序中反調(diào)試技術(shù)使用分布情況。

4.1 實(shí)驗(yàn)數(shù)據(jù)

本文主體實(shí)驗(yàn)所用的程序和源代碼來自3部分。分別是Github中Anti-debugging相關(guān)源代碼、bazaar.abuse.ch真實(shí)惡意代碼[18]以及Windows系統(tǒng)內(nèi)程序樣例。在Github中Anti-debugging相關(guān)源代碼包含多種反調(diào)試技術(shù)。實(shí)驗(yàn)中，對(duì)源代碼編譯后形成的PE文件進(jìn)行檢測(cè)。Bazaar.abuse.ch收錄了實(shí)時(shí)的惡意代碼樣本，本文樣本選取的時(shí)間范圍以2021年7月與8月為主。實(shí)驗(yàn)數(shù)據(jù)的分布情況見表2。

表2 實(shí)驗(yàn)數(shù)據(jù)分布

4.2 實(shí)驗(yàn)環(huán)境

本文實(shí)驗(yàn)的環(huán)境為Windows10 64位操作系統(tǒng)、IDA pro 7.5，初步實(shí)驗(yàn)的待檢測(cè)程序?yàn)閏ode.exe 64位、WeChat.exe 32位。

主體實(shí)驗(yàn)中部分代碼由32位的Microsoft Visual C/C++(MSVC)編譯器或64位Minimalist GNU for Windows(MINGW)編譯器編譯。實(shí)驗(yàn)平臺(tái)具體參數(shù)見表3。

表3 實(shí)驗(yàn)平臺(tái)參數(shù)

4.3 評(píng)價(jià)標(biāo)準(zhǔn)

本文通過實(shí)驗(yàn)程序的正檢測(cè)率(true detection rate，TDR)、負(fù)檢測(cè)率(false detection rate，F(xiàn)DR)、誤報(bào)率(false alarm rate，F(xiàn)AR)以及各項(xiàng)反調(diào)試技術(shù)使用率(antidebug usage rate，AUR)進(jìn)行分析。具體公式如下所示

TDR=含有并檢測(cè)出反調(diào)試的樣本數(shù)樣本總數(shù)×100%

(1)

FDR=含有但未檢測(cè)出反調(diào)試的樣本數(shù)樣本總數(shù)×100%

(2)

FAR=不含有但檢測(cè)出反調(diào)試的樣本數(shù)樣本總數(shù)×100%

(3)

AUR=程序中含有并檢測(cè)出反調(diào)試總數(shù)樣本總數(shù)×1007

(4)

TDR、FDR和FAR可以衡量上述反調(diào)試技術(shù)的可實(shí)現(xiàn)性與準(zhǔn)確性。AUR可以衡量部分用戶態(tài)程序中的反調(diào)試技術(shù)比例且在一定程度上可以預(yù)測(cè)用戶態(tài)程序中常用的反調(diào)試種類。另外，如果程序不含有反調(diào)試技術(shù)，模型也未檢測(cè)到反調(diào)試技術(shù)，則在計(jì)算時(shí)忽略此程序。因?yàn)榇祟惓绦蛟趯?shí)驗(yàn)中沒有現(xiàn)實(shí)意義。

4.4 實(shí)驗(yàn)結(jié)果與分析

首先，通過算法1對(duì)code.exe中進(jìn)行檢測(cè)。在建立由反調(diào)試API函數(shù)構(gòu)成的檢測(cè)庫后，通過算法1將code.exe導(dǎo)出的IDC文件中的API與檢測(cè)庫的API進(jìn)行比對(duì)，得到code.exe中反調(diào)試技術(shù)相關(guān)API的種類和具體位置。但是，算法1得到的結(jié)果僅代表了code.exe存在使用此反調(diào)試技術(shù)的可能。算法1對(duì)code.exe的部分檢測(cè)結(jié)果見表4。

表4 code.exe實(shí)驗(yàn)結(jié)果

在此實(shí)驗(yàn)中，檢測(cè)了code.exe中一部分與反調(diào)試相關(guān)API，確定并定位了API的種類和具體位置。為了更準(zhǔn)確地確定用戶態(tài)程序中使用的反調(diào)試技術(shù)的種類，可以在IDA中通過函數(shù)地址找到對(duì)應(yīng)API并檢測(cè)其是否起到了反調(diào)試的作用。

另外，本文通過算法2對(duì)WeChat.exe中部分反調(diào)試技術(shù)進(jìn)行檢測(cè)。首先，通過反調(diào)試技術(shù)的機(jī)器碼特征建立機(jī)器碼庫。在檢測(cè)反調(diào)試技術(shù)相關(guān)API時(shí)，API函數(shù)在程序中的位置也需要導(dǎo)入機(jī)器碼庫中。然后，通過算法2將WeChat.exe的主函數(shù)中的二進(jìn)制流與機(jī)器碼庫的機(jī)器碼特征值進(jìn)行比對(duì)，得到最終的檢測(cè)結(jié)果。其部分結(jié)果見表5。

表5 WeChat.exe實(shí)驗(yàn)結(jié)果

此實(shí)驗(yàn)檢測(cè)了WeChat.exe中部分反調(diào)試技術(shù)，通過算法2可以快速確定并定位反調(diào)試技術(shù)的種類和位置，且無需進(jìn)行手動(dòng)驗(yàn)證。在批量使用反調(diào)試技術(shù)時(shí)，通過算法2進(jìn)行檢測(cè)具有更高的效率和準(zhǔn)確率。

本文主體實(shí)驗(yàn)通過用戶態(tài)反調(diào)試檢測(cè)模型對(duì)3類程序的反調(diào)試使用情況進(jìn)行檢測(cè)。首先，通過基于Pin插樁的反調(diào)試檢測(cè)方法快速篩選出含有反調(diào)試技術(shù)的程序。其次，構(gòu)建由反調(diào)試技術(shù)API構(gòu)成的檢測(cè)庫，并通過算法1對(duì)這3類程序進(jìn)行粗過濾，初步得到反調(diào)試技術(shù)相關(guān)API的種類和具體位置。然后，構(gòu)建機(jī)器碼庫，并將得到的反調(diào)試技術(shù)相關(guān)API的信息導(dǎo)入機(jī)器碼庫中。通過算法2對(duì)這3類程序進(jìn)行細(xì)過濾，得到準(zhǔn)確的反調(diào)試技術(shù)相關(guān)API的種類和具體位置。最后，對(duì)用戶態(tài)程序進(jìn)行插樁驗(yàn)證，判斷程序是否在獲取到的位置中使用了對(duì)應(yīng)的反調(diào)試技術(shù)。其結(jié)果見表6。

表6 反調(diào)試使用情況

由于現(xiàn)階段暫時(shí)沒有開源的反調(diào)試技術(shù)檢測(cè)方法與本文結(jié)果進(jìn)行對(duì)比。因此，為驗(yàn)證本文提出的檢測(cè)方法，將多名逆向分析人員手動(dòng)調(diào)試結(jié)果與實(shí)驗(yàn)結(jié)果進(jìn)行對(duì)比，得到最終結(jié)果。檢測(cè)結(jié)果與手動(dòng)調(diào)試分析結(jié)果部分不一致的可能的原因包括：①用戶態(tài)反調(diào)試檢測(cè)模型檢測(cè)到的反調(diào)試技術(shù)被使用，但是并沒有阻礙逆向分析人員的正常分析過程，也就是沒有起到反調(diào)試的作用；②用戶態(tài)反調(diào)試檢測(cè)模型在構(gòu)建檢測(cè)庫和機(jī)器碼庫時(shí)遺漏了部分反調(diào)試技術(shù)的特征。

實(shí)驗(yàn)結(jié)果表明，用戶態(tài)反調(diào)試檢測(cè)模型在檢測(cè)反調(diào)試技術(shù)時(shí)效果較好，具有較高的準(zhǔn)確率。另外，該模型在不同類型的程序中表現(xiàn)情況不完全一致。Windows系統(tǒng)內(nèi)程序樣例的反調(diào)試技術(shù)使用較少，其檢測(cè)結(jié)果不如較多使用反調(diào)試技術(shù)的真實(shí)惡意代碼。

最后，本文實(shí)驗(yàn)通過上述相同的方法檢測(cè)了部分反調(diào)試技術(shù)的使用分布情況，其結(jié)果見表7。

表7 使用分布情況

從實(shí)驗(yàn)結(jié)果中可以看出IsdebuggerPresent經(jīng)常被應(yīng)用在反調(diào)試技術(shù)中。這是由于此種反調(diào)試技術(shù)的實(shí)現(xiàn)最為容易，且阻礙逆向分析人員正常逆向分析的效果好，很多情況下，程序編寫者會(huì)在主程序中加入此種反調(diào)試技術(shù)。

從整體上看，本文提出的算法和用戶態(tài)反調(diào)試檢測(cè)模型可以有效并準(zhǔn)確地檢測(cè)出反調(diào)試的使用情況。另外，通過反調(diào)試技術(shù)分布情況，可以初步得出部分用戶態(tài)程序中各類反調(diào)試技術(shù)的應(yīng)用情況。逆向分析人員可以使用本文提出的用戶態(tài)反調(diào)試檢測(cè)模型，對(duì)Golden Eye、Petya等主流惡意程序展開有關(guān)反調(diào)試技術(shù)使用情況、反調(diào)試技術(shù)分布情況等相關(guān)實(shí)驗(yàn)檢測(cè)。

5 結(jié)束語

本文提出了一種用戶態(tài)反調(diào)試檢測(cè)模型，此模型通過插樁篩選、粗過濾、細(xì)過濾以及插樁驗(yàn)證，可以有效地檢測(cè)出用戶態(tài)程序中使用的反調(diào)試技術(shù)的類型和位置。用戶態(tài)反調(diào)試檢測(cè)模型使用了Pin插樁技術(shù)以及基于特征值匹配的反調(diào)試檢測(cè)算法。實(shí)驗(yàn)結(jié)果表明，用戶態(tài)反調(diào)試檢測(cè)模型具有較高的準(zhǔn)確性。另外，在使用大量反調(diào)試技術(shù)的程序中，此模型表現(xiàn)出更高的準(zhǔn)確性。

總的來講，用戶態(tài)反調(diào)試檢測(cè)模型可以系統(tǒng)化分析并定位用戶態(tài)程序所使用的反調(diào)試技術(shù)，降低了逆向分析人員對(duì)用戶態(tài)程序逆向分析的困難。下一步工作將在較小的時(shí)間復(fù)雜度和較高的準(zhǔn)確率下，實(shí)現(xiàn)對(duì)用戶態(tài)程序反調(diào)試技術(shù)檢測(cè)的完全自動(dòng)化。另外，在網(wǎng)絡(luò)安全領(lǐng)域中，越來越多的惡意軟件由GAN等機(jī)器學(xué)習(xí)模型生成[19]，如何對(duì)抗此類惡意軟件中反調(diào)試、代碼混淆等技術(shù)同樣是亟需解決的問題。