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

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

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

0 引 言

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

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

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

1 相關工作

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

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

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

2 反調(diào)試技術

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

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

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

2.1.1 IsDebuggerPresent

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

2.1.2 NtQueryInformationProcess

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

2.1.3 CheckRemoteDebuggerPresent

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

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

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

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

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

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

(4)反調(diào)試技術也可以調(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)試技術通過修改DbgBreakPoint中的匯編指令，阻止DbgBreakPoint在程序中加入斷點，使調(diào)試器無法程序斷下。

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

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

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

2.2.1 進程信息檢測

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

2.2.2 堆上信息檢測

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

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

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

2.2.4 父進程檢測

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

2.2.5 時鐘檢測

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

2.2.6 TLS回調(diào)檢測

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

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

2.3.1 異常處理

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

2.3.2 調(diào)試器漏洞

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

2.3.3 步過(step over)失效

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

2.3.4 輸入設備封鎖

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

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

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

基于Pin插樁的反調(diào)試檢測技術是通過檢測主函數(shù)中call指令數(shù)量與ret指令數(shù)量是否相同，進而確定程序是否使用了反調(diào)試技術。基于IDC的反調(diào)試檢測技術是通過IDA導出IDC-Database，在IDC-Database中遍歷程序所調(diào)用的API以及相關函數(shù)，并依次與特征庫進行對比，進而判斷反調(diào)試技術的種類，定位調(diào)用反調(diào)試技術的位置。基于機器碼特征值的反調(diào)試檢測技術是對于可執(zhí)行程序的機器碼進行檢測。可執(zhí)行程序中，同樣的反調(diào)試技術在對應位置具有相同或類似的機器碼。基于此，檢測算法將程序中的機器碼依次與機器碼庫中的反調(diào)試特征機器碼進行對比，進而確定反調(diào)試技術種類和位置。

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

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

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

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

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

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

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

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

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

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

基于Pin插樁的反調(diào)試檢測是通過Pin插樁技術，動態(tài)檢測主函數(shù)的call指令數(shù)量與ret指令數(shù)量是否相同，初步篩選出含有反調(diào)試技術的程序。基于Pin插樁的反調(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ù)器的值進行對比。

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

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

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

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

算法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ù)檢測庫進行對比。如果主函數(shù)的函數(shù)名和反調(diào)試函數(shù)檢測庫中的函數(shù)名一致，則標記其函數(shù)名和函數(shù)在程序中的地址。第(7)～第(10)行對標記的地址與函數(shù)名存入特征庫，并將上述符合要求的函數(shù)名與地址以鍵值對的形式作為輸出。

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

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

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

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

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

4 實驗與分析

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

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

本文主體實驗所用的程序和源代碼來自3部分。分別是Github中Anti-debugging相關源代碼、bazaar.abuse.ch真實惡意代碼[18]以及Windows系統(tǒng)內(nèi)程序樣例。在Github中Anti-debugging相關源代碼包含多種反調(diào)試技術。實驗中，對源代碼編譯后形成的PE文件進行檢測。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 評價標準

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

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)試技術的可實現(xiàn)性與準確性。AUR可以衡量部分用戶態(tài)程序中的反調(diào)試技術比例且在一定程度上可以預測用戶態(tài)程序中常用的反調(diào)試種類。另外，如果程序不含有反調(diào)試技術，模型也未檢測到反調(diào)試技術，則在計算時忽略此程序。因為此類程序在實驗中沒有現(xiàn)實意義。

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

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

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

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

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

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

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

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

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

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

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

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

表7 使用分布情況

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

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

5 結(jié)束語

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

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