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

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

0 引 言

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

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

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

1 相關(guān)工作

逆向分析技術(shù)，是通過反匯編、反編譯、調(diào)試模擬程序運行等手段，分析現(xiàn)有的二進(jìn)制可執(zhí)行文件，得到程序的執(zhí)行流程、數(shù)據(jù)結(jié)構(gòu)等文件信息的一項重要技術(shù)。在逆向分析技術(shù)的研究領(lǐng)域方面，A.M.H.Al-Hakimi等[2]提出一種新的混合混淆加密技術(shù)來阻止逆向分析，經(jīng)過此類混淆加密的代碼幾乎不會被逆向工具讀取。Umair S等[3]在模型驅(qū)動逆向工程(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è)計，實現(xiàn)了對APP文件的逆向分析技術(shù)，介紹了逆向分析技術(shù)在操作系統(tǒng)中的重要價值。Sija BD等[6]介紹了協(xié)議自動化逆向工程的目標(biāo)、方法、工具及其研究成果，闡述了協(xié)議自動化逆向工程的目標(biāo)和障礙。

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

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

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)指針來檢測BeingDebugged字段的值。如果有調(diào)試器附加，則返回值為1，否則為0。

2.1.2 NtQueryInformationProcess

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

2.1.3 CheckRemoteDebuggerPresent

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.2 堆上信息檢測

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

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

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

2.2.4 父進(jìn)程檢測

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

2.2.5 時鐘檢測

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

2.2.6 TLS回調(diào)檢測

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

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

2.3.1 異常處理

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

2.3.2 調(diào)試器漏洞

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

2.3.3 步過(step over)失效

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

2.3.4 輸入設(shè)備封鎖

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

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

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

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

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

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

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

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

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

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

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

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

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

Pin是Intel提出的動態(tài)二進(jìn)制插樁工具，它可以動態(tài)地監(jiān)控程序的每一步運行。在程序正常運行時，call指令將改變IP寄存器的位置，進(jìn)而完成函數(shù)調(diào)用。ret指令在程序調(diào)用結(jié)束時，將改變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)試檢測是通過Pin插樁技術(shù)，動態(tài)檢測主函數(shù)的call指令數(shù)量與ret指令數(shù)量是否相同，初步篩選出含有反調(diào)試技術(shù)的程序?；赑in插樁的反調(diào)試檢測流程如圖3所示。

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

檢測框架如下：

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

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

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

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

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

基于IDC的反調(diào)試檢測是一種特征值檢測技術(shù)，其原理為檢測導(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)行遍歷掃描待檢測程序的IDC文件，將主函數(shù)中出現(xiàn)過的函數(shù)名與反調(diào)試函數(shù)檢測庫進(jìn)行對比。如果主函數(shù)的函數(shù)名和反調(diào)試函數(shù)檢測庫中的函數(shù)名一致，則標(biāo)記其函數(shù)名和函數(shù)在程序中的地址。第(7)～第(10)行對標(biāo)記的地址與函數(shù)名存入特征庫，并將上述符合要求的函數(shù)名與地址以鍵值對的形式作為輸出。

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

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

在大多數(shù)反調(diào)試使用時，其機(jī)器碼是固定且唯一的?；诖朔N情況，機(jī)器碼特征值反調(diào)試檢測方法將用戶態(tài)程序的機(jī)器碼匹配有關(guān)反調(diào)試技術(shù)的機(jī)器碼，進(jìn)而確定是否使用此種反調(diào)試技術(shù)。由于其機(jī)器碼的固定性與唯一性，幾乎無需手動檢查便可以確定該惡意程序是否使用了某種反調(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)行，遍歷掃描待檢測程序的二進(jìn)制，并將主程序的每個字節(jié)依次與反調(diào)試機(jī)器碼庫進(jìn)行對比。第(4)～第(11)行，如果程序某位置的首字節(jié)與反調(diào)試技術(shù)機(jī)器碼庫中某段的首字節(jié)相同，繼續(xù)對比反調(diào)試技術(shù)機(jī)器碼庫中此段后幾位字節(jié)是否也同樣依次出現(xiàn)在程序此位置中。如果同樣出現(xiàn)，則將此函數(shù)及其位置存入特征庫中，否則繼續(xù)遍歷主程序。

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

4 實驗與分析

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

4.1 實驗數(shù)據(jù)

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

表2 實驗數(shù)據(jù)分布

4.2 實驗環(huán)境

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

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

表3 實驗平臺參數(shù)

4.3 評價標(biāo)準(zhǔn)

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

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

(1)

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

(2)

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

(3)

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

(4)

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

4.4 實驗結(jié)果與分析

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

表4 code.exe實驗結(jié)果

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

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

表5 WeChat.exe實驗結(jié)果

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

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

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

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

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

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

表7 使用分布情況

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

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

5 結(jié)束語

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

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