基于沙箱技術的惡意代碼行為檢測方法

童 瀛, 牛博威, 周 宇, 張 旗

(江蘇省公安廳, 江蘇 南京 210000)

惡意代碼具有互聯網中快速傳播的能力，任何連入互聯網的計算機都談不上絕對的安全。在頻繁發(fā)生的互聯網安全事件中，最常見的是因惡意代碼引起的，而且其造成的損失也是最為嚴重的。

目前安全廠商的沙箱產品主要包括以下3個類別，第一類是以對外提供在線服務為主的沙箱環(huán)境，包括騰訊哈勃分析系統(tǒng)、金山火眼在線分析系統(tǒng)、VirusTotal等；第二類以對內提供服務為主的沙箱環(huán)境，如賽門鐵克等很多公司內部的分析系統(tǒng)，主要用于云查殺技術支撐；第三類是包含在安全軟件中的沙箱環(huán)境，如卡巴斯基殺毒軟件的啟發(fā)式掃描。嚴格來講主動防御技術和沙箱技術也有很多重疊?？紤]到目前大多數的攻擊與防御主要集中在Windows操作系統(tǒng)，本文主要對Windows下的惡意代碼與沙箱技術進行研究。與常見的基于操作系統(tǒng)層面的檢測不同，本文對惡意代碼還開展了虛擬執(zhí)行研究，同時實現了針對Windows系統(tǒng)特性的模擬，以期可以實現不依賴操作系統(tǒng)而確定代碼的執(zhí)行行為。

1 惡意代碼攻擊與檢測技術

1.1 惡意代碼攻擊技術

在Windows平臺下，不同種類的惡意代碼使用的攻擊技術相互交叉融合。病毒為躲避殺毒軟件和反病毒分析，采取很多對抗分析技術，比較典型的包括：(1)使用多態(tài)變形或加殼技術對自身代碼做擾亂，如著名的SMEG變形引擎[1]；(2)使用反檢測技術規(guī)避殺毒軟件、虛擬機等檢測[2]；(3)惡意軟件體過大，導致難以全面分析，如著名的震網病毒；(4)使用解釋性編程語言增加分析難度等[3]。這些惡意代碼的對抗技術，極大地增加惡意代碼分析工作量。

目前，病毒的制作越來越流行使用ShellCode技術[4]，這種技術的應用使得病毒樣本體內極少含有傳統(tǒng)意義上的惡意代碼，因此，對ShellCode代碼的檢測也越來越成為惡意代碼檢測的關鍵。惡意ShellCode代碼的檢測難度主要在于：(1)體積小。這種代碼一般都是匯編語言編寫，體積很小，容易隱藏在正常文件中；(2)存放形式多樣。既可以存儲在正?？蓤?zhí)行文件中，也可以存放在帶有漏洞的文檔中，或者直接在運行時候通過網絡傳遞，并不在受害系統(tǒng)磁盤上存留；(3)容易加密變形。這種編碼的執(zhí)行不受文件格式的限制，因此可以任意加密、自加密，分析時候面臨解密問題；(4)傳統(tǒng)代碼檢測手段失效。這種惡意編碼被加密后，除非監(jiān)測動態(tài)執(zhí)行過程，否則基本不可能識別出其作用。

1.2 惡意代碼分析方法

在Windows系統(tǒng)中可執(zhí)行文件是二進制形式文件，惡意代碼主要也是以這種形式存在。有很多種惡意代碼的分析方法，常用的為靜態(tài)分析方法和動態(tài)分析方法[5]，分類依據是分析過程是否需要執(zhí)行惡意代碼。

靜態(tài)分析方法的優(yōu)點是針對惡意代碼本身進行分析，從代碼的具體內容中得到其行為特性，從而確定其實現的功能。因此，該方法不受具體的系統(tǒng)環(huán)境約束，也可以分析不能運行的二進制代碼，不會對操作系統(tǒng)造成任何影響。靜態(tài)分析方法可以對代碼進行細粒度分析，且具有高精度[6]。

目前，很多惡意代碼常用變形、多態(tài)、加殼[7]、模糊轉換等方法隱藏自己，使得靜態(tài)分析方法難以識別它們。此外，該方法不能檢測未知的惡意代碼及其變種，只能識別已知的惡意代碼。

動態(tài)分析方法的優(yōu)點是基于惡意代碼的行為進行分析，而不是分析代碼本身，該方法需要實際執(zhí)行惡意代碼。因此，動態(tài)分析方法能夠較好地檢測未知的惡意代碼。同時，動態(tài)分析還有分析速度快，人工參與少的特點，可以批量自動化分析大量樣本。

動態(tài)分析的技術難點是如何確保惡意代碼的執(zhí)行不會對系統(tǒng)造成真實破壞，通常要在虛擬機中執(zhí)行惡意代碼，會造成系統(tǒng)資源的過度消耗。虛擬機的環(huán)境不能保證與真實的系統(tǒng)環(huán)境完全相同，這將使分析結果或多或少地具有不確定性，降低了準確性。此外，在虛擬機環(huán)境本身存在漏洞的情況下，被執(zhí)行的惡意代碼可能會感染到宿主機。

2 沙箱技術簡介

2.1 沙箱安全模型

沙箱是一個安全軟件，它為程序的執(zhí)行提供一個虛擬的環(huán)境[8]。在沙箱中有專門制定的安全策略，對程序行為進行監(jiān)控，當程序的執(zhí)行違反安全策略時，沙箱會限制其行為。為了確保系統(tǒng)環(huán)境不會遭到破壞，沙箱對文件、注冊表等進行虛擬化重定向，這樣惡意代碼只能操作虛擬的文件和注冊表，而系統(tǒng)真正的文件和注冊表不會受到影響[9]。沙箱技術的核心是創(chuàng)建一個對程序操作進行限制的執(zhí)行環(huán)境，在沙箱中運行不受信任和未知目的的程序，可以避免對系統(tǒng)可能造成的破壞。

沙箱的運行過程如下：在沙箱中運行不信任文件，并記錄其可疑行為，當確認程序有惡意目的時，沙箱將終止其操作，并且刪除惡意程序執(zhí)行痕跡，將系統(tǒng)恢復到原始狀態(tài)。

2.2 Windows API掛鉤技術

沙箱的具體實現非常復雜，需要接管很多系統(tǒng)操作，文件、注冊表的重定向接管只是最基本的，Windows下還有窗口、類名、消息、服務、rpc、Token、COM等等。對這些接口的接管和重定向既包括驅動層，也包括應用層API、消息協議等，本文介紹最常見的API掛鉤方法。

API是Windows系統(tǒng)對用戶開放的編程接口，可在用戶態(tài)下對操作系統(tǒng)進行控制。惡意代碼要實現其功能最終會調用API函數，通過API Hook技術可以監(jiān)控系統(tǒng)中的API函數調用，其原理是監(jiān)控進程通過dll注入方式，修改API函數的原入口地址到一個自定義的函數，然后在一個自定義的函數內調用原函數，并返回結果。在注入成功后對目標API進行掛鉤，根據掛鉤方式的不同可以分為兩種，在函數的調用點劫持和在函數體內劫持[5]。

2.3 虛擬化技術

虛擬化技術根據虛擬化程度的不同可以將該技術分為全虛擬化、半虛擬化、硬件輔助虛擬化等[10]。不同的虛擬化程度決定了在分析惡意軟件的時候，樣本是否能夠完全運行，以及虛擬環(huán)境是否被惡意軟件識別。

完全虛擬化，敏感指令在操作系統(tǒng)和硬件之間被捕捉處理，客戶操作系統(tǒng)無需修改，所有軟件都能在虛擬機中運行，例如IBM CP/CMS，VirtualBox，VMware Workstation。

半虛擬化，針對軟件運行時的一部分環(huán)境進行虛擬化。比如對文件系統(tǒng)、注冊表等進行虛擬化。

硬件輔助虛擬化，利用硬件(主要是CPU)輔助處理敏感指令以實現完全虛擬化的功能，客戶操作系統(tǒng)無需修改，例如VMware Workstation，Xen，KVM等。

3 基于應用層的沙箱監(jiān)控技術

前面分析了惡意代碼的攻擊技術和攻擊行為，這些行為主要體現在惡意代碼對于文件、注冊表、網絡端口、進程線程和內核加載的操作上，本部分將針對惡意代碼在這些方面的行為進行檢測，并分析通過監(jiān)控哪些API函數才能實現對惡意行為的有效監(jiān)控。

3.1 文件操作行為監(jiān)控

惡意軟件在運行的時候。為了權限維持，安全軟件繞過等目的，通常都會有一系列的文件操作行為。惡意軟件在成功運行后，一般會在臨時文件夾或系統(tǒng)文件夾下，創(chuàng)建一個服務的備份用作后門，用以權限的維持。在該過程中需要CreateFile函數來創(chuàng)建文件，WriteFile函數對其寫入，結束后一般會調用CloseHandle來關閉文件句柄。

通過上述分析，不難發(fā)現，可以通過監(jiān)視表1中的API函數監(jiān)視涉及文件的操作。

表1 文件操作監(jiān)控的關鍵API函數表

3.2 網絡行為監(jiān)控

像間諜軟件和木馬這樣的惡意代碼還會對網絡造成影響，攻擊的一方利用它們主動連接網絡來獲得竊取到的重要信息。通常情況下，惡意代碼網絡行為主要表現在端口復用、開放本地監(jiān)聽端口、端口反向連接，可疑報文收發(fā)等4個方式。

1) 端口復用

端口重用技術意味著惡意代碼與操作系統(tǒng)已經打開的網絡端口通信。公共端口是39、135、80等等，其目的是在少開甚至不開新端口的情況下進行網絡通信，使得防病毒軟件更難發(fā)現惡意行為[11]。

端口復用并不影響端口的正常服務，因此，其行為十分隱蔽，具有很強的欺騙性。在程序中調用系統(tǒng)函數setsockopt和通過so_reuseaddr參數值的函數，從而實現端口復用。

2) 開設本地監(jiān)聽端口

惡意代碼為了將竊取的信息通過網絡傳輸，通常在被攻擊主機的系統(tǒng)中設立一個監(jiān)聽端口。通過監(jiān)聽80等常用端口，以避免被殺毒軟件發(fā)現。設立監(jiān)聽端口后，黑客就可以遠程操作請求網絡連接，專門用于傳輸數據。

當被監(jiān)控程序在執(zhí)行過程中，有上述行為可以作為判斷建立本地端口監(jiān)視器的嘗試的依據。

3) 端口反向連接

端口反向連接是指被控端(服務端)主動向控制端(客戶端)發(fā)起連接，是木馬攻擊常用的技術。大多數防火墻軟件都具有檢測開設本地監(jiān)聽端口的功能，然而，防火墻軟件有一個弱點，即當主機用戶通過Internet訪問網頁時，瀏覽器的每一頁都將與服務器建立多個網絡連接，這被認為是合法的，不會被防火墻軟件攔截。為了避免被檢測到，惡意代碼利用這一弱點主動向攻擊一方發(fā)起網絡連接，在這個過程中需要調用connect函數[12]。

4) 可疑報文收發(fā)

可疑報文主要包括惡意程序向控制端發(fā)送被感染者敏感信息、被感染者心跳包、控制端對惡意程序的控制指令等。這些報文一般都具有固定的特征，例如定時發(fā)送心跳包告知控制端被感染者存活、通信數據經過簡單的加密處理等。將可疑報文模型化后，可以通過對send、recv等函數進行監(jiān)控，一旦發(fā)現樣本報文符合可疑模型，立即終止該進程并警告用戶。

上述分析表明，可以通過監(jiān)控表2的API函數實現對網絡行為的監(jiān)控，同時也可以在網卡虛擬化的基礎上對通信行為與流量進行嗅探，也可以達到同樣的網絡行為監(jiān)控的目的。

表2 網絡操作監(jiān)控的關鍵API函數表

3.3 終止和創(chuàng)建進程監(jiān)控

惡意代碼執(zhí)行前期，經常會終止反病毒軟件，同時在病毒更新、或者調用第三方軟件時候會有進程創(chuàng)建操作。常見的可能被關閉的反病毒軟件進程有360tray.exe、kavstare.exe、Navapw32.exe、KAVsvc.exe、Rav.exe等等，基于辦公文檔漏洞的攻擊過程中，病毒一般會在代碼釋放后執(zhí)行Office進程或者pdf等辦公軟件進程。

如果要監(jiān)控對進程的創(chuàng)建和關閉，可以監(jiān)控表3中的API函數。

表3 終止和創(chuàng)建進程操作監(jiān)控的關鍵API函數表

3.4 線程操作監(jiān)控

在操作系統(tǒng)中，程序執(zhí)行是包含一個或多個線程的過程，多個線程共享進程占用的系統(tǒng)資源，如內存和CPU。

在Window操作系統(tǒng)中有很多DLL文件，其功能是擴展為一個功能模塊。惡意代碼往往被偽裝或替換為DLL文件的系統(tǒng)，從而隱藏自己的痕跡。這些惡意代碼經常會感染系統(tǒng)的關鍵進程，影響操作系統(tǒng)的正常運行。而這些進程往往不能人為終止，給惡意代碼的檢測和清除帶來了困難。

木馬通常以DLL形式，采用遠程線程注入[13]封裝主部件。窗口系統(tǒng)加載和調用Dll文件，而DLL文件作為函數模塊只包含函數形式，不能直接調用，因此，需要被其他進程加載才能運行，通過這種方式實現自身的隱藏。

通過分析可知，可以將線程注入操作和線程創(chuàng)建操作調用系統(tǒng)功能鏈接起來，實現線程運行監(jiān)控。遠程線程創(chuàng)建函數的CreateVirtualAllocEx是用戶態(tài)下的形式，內核態(tài)的API函數應該是NtCreateVirtualAllocEx，所以，通過掛鉤NtSetifyRoutine常規(guī)功能可以實現內核級線程注入操作監(jiān)控。同時，該NtSetifyRoutine功能也與實現線程的創(chuàng)建核心級監(jiān)控。表4中是監(jiān)視需要鉤子的線程操作的API函數。

表4 線程操作監(jiān)控的關鍵API函數表

4 基于虛擬化的沙箱監(jiān)控

基于API攔截的沙箱監(jiān)控方式是通過接管系統(tǒng)接口獲取惡意文件行為，阻斷對真實系統(tǒng)的破壞。這種技術的缺點是不能跨平臺、部署復雜，運行過程系統(tǒng)資源消耗大，而且對ShellCode惡意代碼檢測效果較差。基于虛擬化的沙箱監(jiān)控技術，能夠克服上述缺點。該技術是利用一種純解釋執(zhí)行的虛擬化檢測方式，通過完全模擬x86匯編指令和Windows系統(tǒng)環(huán)境，監(jiān)控惡意文件行為。

4.1 沙箱流程

虛擬化沙箱的設計思想，是模擬運行疑似為可執(zhí)行代碼的輸入的數據流，當模擬執(zhí)行過程中有嘗試調用敏感系統(tǒng)函數的行為，或者模擬執(zhí)行步數達到一定程度(如200步)時，則將該模擬執(zhí)行過程輸出報警。為此，純虛擬化沙箱技術通過對x86匯編指令、Windows系統(tǒng)特性、內存布局等進行全面模擬，以期達到預期效果。

4.2 x86寄存器模擬

模擬執(zhí)行x86匯編代碼，先要模擬CPU基礎架構，下面數據結構用于模擬x86框架下的寄存器。

32位寄存器模擬的關鍵數據結構如下。

SRegisterAddr_T RegisterAddr[MAX_REG_SYMBOL] =

{

{ "eax", &m_eax, 4 },

{ "ecx", &m_ecx, 4 },

{ "edx", &m_edx, 4 },

{ "ebx", &m_ebx, 4 },

{ "esp", &m_esp, 4 },

{ "bl", &m_bl, 1 },

{ "eip", &m_eip, 4 },

{ "eflags", &m_eflags, 4 },

{ "cs", &m_cs, 2 },

{ "ds", &m_ds, 2 },

{ "ss", &m_ss, 2 },

{ "es", &m_es, 2 },

{ "fs", &m_fs, 2 },

{ "gs", &m_gs, 2 },

};

完成了上述模擬寄存器結構后，涉及到對寄存器進行操作時，采用匯編語句執(zhí)行時將會比較方便，如對寄存器進行讀寫操作，則較方便操作如下。

switch (m_RegAddr[i].nLen){

case sizeof(u32):

*(u32 *) m_RegAddr[i].pAddr = nValue;

break;

case sizeof(u16):

*(u16 *) m_RegAddr[i].pAddr = (u16) nValue;

break;

default:

*(u8 *) m_RegAddr[i].pAddr = (u8) nValue;

break;

}

完成上述32位寄存器模擬后，再配合反匯編引擎的解析，就可以實現對基本的匯編指令進行解釋模擬運行。

4.3 內存地址映射關鍵代碼

Windows對每個進程都開辟了單獨的虛擬內存供該進程使用，為保證目標代碼可以正常虛擬執(zhí)行下去，解釋器必須建立自己的虛擬內存空間。

為目標指令提供虛擬的內存環(huán)境，供尋址指令調用，采用代碼模擬虛擬地址映射的方式，其內存地址映射關鍵代碼如下。

void *SMemSpace::GetAddressAt(SCpuCore *pCpuCore,

u32 nSegment, u32 nOffset, int nExpectedLen)

{

__asm

{

// Convert nSegment::nOffset to liner address

// fetch segment information

// eax = (nSegment[15..2]) * 16 ==

SELECTOR * 4

// pCpuCore->m_Segments + eax +

4 (offset of liner address field)

mov eax, nSegment

and eax, (SELECTOR_FLAG | LDT_FLAG)

mov esi, pCpuCore

lea eax, [esi]pCpuCore.

m_Segments.m_Table[eax * 4 + 4]

// esi = liner address + offset

mov esi, [eax]

add esi, nOffset

// Check segment length

mov eax, [eax + 4] // nLen

sub eax, nOffset

jb exception

// Compare offset + nExpectedLen with nLen + 1,

inc eax

// so inc eax.

// Don’t inc eax before sub eax, nOffset since...

jz maxsize

// eax == 0xFFFFFFFF,

don’t compare with nExpectedLen

sub eax, nExpectedLen

jb exception

maxsize:;

// p = m_pImage

mov ecx, [ecx]this.m_pImage

// if p == null, raise exception

jcxz exception

// eax = esi = liner address

mov eax, esi

while_p_not_null:

// if nOffset < p->m_nVirtualAddress, skip

cmp esi, [ecx]SImageList.m_nVirtualAddress

jb next

// if nOffset > p->m_nVirtualEnd, skip

cmp esi, [ecx]SImageList.m_nVirtualEnd

ja next

// Found

// if nOffset + nExpectedLen - 1 > p->

m_nVirtualEnd, raise exception

add esi, nExpectedLen

dec esi

cmp esi, [ecx]SImageList.m_nVirtualEnd

ja exception

// return (u8 *) p->m_pImage +

nOffset - p->m_nVirtualAddress

add eax, [ecx]SImageList.m_pImage

sub eax, [ecx]SImageList.m_nVirtualAddress

jmp quit

next:

// p = p->m_pNext

mov ecx, [ecx]SImageList.m_pNext

or ecx, ecx

jnz while_p_not_null

}

}

4.4 反匯編獲取指令

考慮到設計原理是將未知數據傳入虛擬機，由虛擬機嘗試將其視為惡意代碼開展模擬執(zhí)行，所以，在嘗試執(zhí)行這些未知輸入數據時，首先利用反匯編技術，獲取當前數據的匯編指令，然后才能對解析到的匯編指令，開展模擬執(zhí)行。對輸入數據流開展反匯編過程是先根據當前讀取的字節(jié)判定可能的匯編指令歸類，然后，再根據不同的指令類型獲取該指令的操作數等細節(jié)。

獲取指令分類關鍵代碼如下。

m_nCode1 = GetCodeU8();

if (m_nCode1 == 0x0F)

{

// Get from two bytes opcode map

m_nCode2 = GetCodeU8();

pOper = &gOperMapB20F[m_nCode2];

} else

// Get from one byte opcode map

pOper = &gOperMapB1[m_nCode1];

然后，根據指令類型，獲取該條匯編指令的詳細內容。對整個數據流進行反匯編是個不斷前進持續(xù)的過程，所以其循環(huán)執(zhí)行的代碼流程如下。

do

{

// Get code & opermap

pOper = GetCodeOper();

// Prepare operand for this instruction

PrepareOperandDesc(pOper);

// Get instruction

szDesc = pOper->pInstruction->

Deassemble(this, pOper);

} while (szDesc == NULL);

本部分反匯編技術的輸出結果，是后續(xù)指令模擬執(zhí)行的基礎，為后續(xù)模擬執(zhí)行提供匯編指令支撐。

4.5 匯編指令模擬

當進行匯編指令模擬時，對于常見的匯編指令，可以通過簡單方法進行模擬，其方法可參考4.2部分寄存器操作模擬；對于不常見指令，或者較難模擬的指令，將其交給真實的CPU去執(zhí)行，再獲取返回到的結果，其相關代碼如下。

__asm{

push edx

mov ecx, this

lea ebx, [ecx]this.m_pCodes

mov ecx, pCpu

call dword ptr [ebx]

pop edx

}

上述處理方法的優(yōu)勢是既充分發(fā)揮真實環(huán)境的優(yōu)點，又降低沙盒環(huán)境的開發(fā)難度。

4.6 反匯編執(zhí)行流程

反匯編執(zhí)行流程是對輸入數據流進行解釋執(zhí)行的主流程。通過解釋分析獲取當前匯編指令，然后，模擬正常匯編指令解析過程進行不斷前行解釋，其相關代碼為

// Initialize before execute this instruction

PreExecute();

try

{

// Execute this instruction

do

{

// Get opcode & its opermap

pOper = GetCodeOper();

// Prepare operand for this instruction

PrepareOperandAddr(pOper);

// Get instruction

bDone = pOper->pInstruction->Execute(this);

// If to be continued, got NULL in szDesc

} while (! bDone);

}

確定了上述內存映射方式以后，就可以為虛擬環(huán)境開辟單獨的內存空間。當目標代碼嘗試操作虛擬內存時，通過上述映射方式對虛擬內存進行操作。

4.7 內存結構

為了使沙箱虛擬機的沙箱環(huán)境區(qū)全面支持Windows環(huán)境，即能實現對x86匯編指令環(huán)境的模擬，還應實現對Windows系統(tǒng)特性如內存結構的支持。考慮到ShellCode編碼的特點，運行時會預先查找當前所在進程內存空間，從中搜索到自己所需要的系統(tǒng)函數地址，因此，沙箱虛擬機需要模擬Windows進程內存，以便ShellCode可以在該虛擬環(huán)境中正常運行。對虛擬內存的模擬設置如下。

//用于設置32位系統(tǒng)下的4G內存空間

g_pMainCpu->CreateSegment(g_pMainCpu->

m_fs, 0xFFDF0000, 0x0FFF);

//從正常進程中Dump出一份FS段內容，填充到虛擬空間中

LoadData_1(0x38, "FSImage.dat",0,1024 * 4);

LoadData_1(IMAGE_BASE_ADDR, "Image.dat",

0, 0x1f80);

其中LoadData_1實現過程，先讀入預先Dump出的正常進程數據，然后覆蓋到設定的虛擬空間內，即

LoadData_1(0x38, "FSImage.dat",0,1024 * 4);

LoadData_1(IMAGE_BASE_ADDR, "Image.dat",

0, 0x1f80);

建立上述虛擬內存空間后，當目標代碼虛擬執(zhí)行時，就可以模仿正常運行時的內存讀取和寫入操作。如果需要解釋器，也可以隨時將內存狀況進行保存或者監(jiān)控。

4.8 代碼執(zhí)行

完成上述工作后，便可以對用戶輸入的數據流進行模擬執(zhí)行檢測。主要檢測代碼如下。

InitCpu();//CPU環(huán)境初始化

CreateImage(g_EntryPoint, nCodeSize);

//創(chuàng)建虛擬內存，供模擬執(zhí)行時候調用

PutMemAt(g_EntryPoint, pCodeBuf, nCodeSize);

//將輸入數據填充到設定的虛擬內存中

SetFSImage();//模擬Windows系統(tǒng)特性，初始化FS區(qū)段

//模擬其他進程區(qū)段，供ShellCode

Cpu.PutU32At(Cpu.m_fs, 0x30, 0x7FFDF000);

LoadData_(0x08, "Image.dat", IMAGE_BASE_ADDR,

IMAGE_BUF_SIZE);

LoadData_(0x08, "Kernel32IAT.dat",

KERNEL32IAT_BASE_ADDR,

KERNEL32IAT_BUF_SIZE);

LoadData_(0x30, "FSImage.dat", 0, 200);

LoadData_(0x38, "FSImage.dat", 0, 1024 * 4);

LoadData_(0x08, "SearchKern.dat",

DEFAULT_SEH_HANDLE_ADDR,1024 * 20);

//模擬執(zhí)行輸入數據

unsigned long nProcessCount = 0;

int nRet = CallNear(g_EntryPoint,

0, 0, 0, &nProcessCount, 1);

上述代碼是目標代碼虛擬執(zhí)行的主要流程，具體包括創(chuàng)建虛擬CPU環(huán)境；為目標代碼創(chuàng)建虛擬內存環(huán)境；模擬Windows特性，在虛擬內存里初始化內核表等數據，以便后續(xù)目標代碼可能使用。

4.9 其他Windows性能模擬

通常情況下，欲獲取較全的病毒運行流程，除了模擬32位匯編指令運行環(huán)境是遠遠不夠的，還需要模擬其他病毒可能會使用的系統(tǒng)性能，以便支撐惡意文件的運行。為此，設計除對Windows內存分布，還對惡意代碼技術涉及的API函數和異常處理進行了深入研究，并實現對常見API函數的運行結果模擬，其實現代碼如下。

static WINAPI_TABLE_T Kernel32Table[] =

{

{ "CreateThread", PROC_CREATETHREAD,

(SubFunc_T) Kernel32_CreateThread, 6 },

{ "CreateEventA", PROC_CREATEEVENT,

(SubFunc_T) Kernel32_CreateEvent, 4 },

{ "LoadLibrary", PROC_LOADLIBRARY,

(SubFunc_T) Kernel32_LoadLibrary, 1 },

{ "LoadLibraryA", PROC_LOADLIBRARY,

(SubFunc_T) Kernel32_LoadLibrary, 1 },

{ "GetLocalTime", PROC_GETLOCALTIME,

(SubFunc_T) Kernel32_GetLocalTime, 1 },

{ "GetModuleHandle", PROC_GETMODULEHANDLE,

(SubFunc_T) Kernel32_GetModuleHandle, 1 },

{ "GetModuleHandleA", PROC_GETMODULEHANDLE,

(SubFunc_T) Kernel32_GetModuleHandle, 1 },

{ "GetProcAddress", PROC_GETPROCADDRESS,

(SubFunc_T) Kernel32_GetProcAddress, 2 },

{ "GetTickCount", PROC_GETTICKCOUNT,

(SubFunc_T) Kernel32_GetTickCount, 0 },

{ "GlobalFree", PROC_GLOBALFREE,

(SubFunc_T) Kernel32_GlobalFree, 1 },

{ "GlobalAlloc", PROC_GLOBALALLOC,

(SubFunc_T) Kernel32_GlobalAlloc, 2 },

{ "SetEvent", PROC_SETEVENT,

(SubFunc_T) Kernel32_SetEvent, 1 },

{ "SetUnhandledExceptionFilter",

PROC_SETUNHANDLEDEXCEPTOINFILTER,

(SubFunc_T)

Kernel32_SetUnhandledExceptionFilter, 1 },

{ "WaitForSingleObject",

PROC_WAITFORSINGLEOBJECT, (SubFunc_T)

Kernel32_WaitForSingleObject, 2 },

// { "Sleep", PROC_SLEEP,

(SubFunc_T) Kernel32_Sleep, 1 },

// { "CreateToolhelp32Snapshot",

PROC_CREATETOOLHELP32SNAPSHOT,

(SubFunc_T)

Kernel32_CreateToolhelp32Snapshot, 2 },

};

static WINAPI_TABLE_T User32Table[] =

{

{ "FindWindowA", PROC_FINDWINDOW,

(SubFunc_T) User32_FindWindow, 2 },

{ "FindWindow", PROC_FINDWINDOW,

(SubFunc_T) User32_FindWindow, 2 },

{ "MessageBoxA", PROC_MESSAGEBOX,

(SubFunc_T) User32_MessageBox, 4 },

{ "MessageBox", PROC_MESSAGEBOX,

(SubFunc_T) User32_MessageBox, 4 },

};

在對上述API的模擬過程中，對于較簡單情況，可以調用真實的API函數，將結果返回；對于較為復雜的情況，需要利用Windows系統(tǒng)特性，如對用于設置當前進程異常處理SetUnhandledExceptionFilter函數的支持，該函數的模擬需要采用Windows系統(tǒng)異常處理機制的實現，其中SHE鏈處理關鍵代碼如下。

// Try SEH first

// Get first seh pointer @ fs:[0]

u32 nEip;

u32 nSEH, nProcAddress;

nEip = pCpu->m_eip;

nSEH = *(u32 *) pCpu->GetAddressAt(pCpu->

m_fs, 0, sizeof(u32));

while (nSEH != 0xFFFFFFFF &&

nSEH != DEFAULT_SEH_HANDLE_ADDR)

{

// Get handler

nProcAddress = *(u32 *) pCpu->

GetAddressAt(pCpu->m_ss, nSEH + 4,

sizeof(u32));

if (nProcAddress == KERNEL_SEH_PROC_ADDR)

{

// Enter kernal exception process, do nothing

nSEH = 0xFFFFFFFF;

break;

}

// Invoke process

// arguments:

// lpExceptionRecord

// lpSEH

// lpContext

// lpDispatcherContext

args[0] = (u32) s.ExceptionInfo.ExceptionRecord;

args[1] = nSEH;

args[2] = (u32) s.ExceptionInfo.ContextRecord;

args[3] = (u32) s.ExceptionInfo.ContextRecord;

if (! pCpu->CallNear(pCpu, nProcAddress,

0x7C9037BF, /* Copied from WinXP */ &args, 4,

&nRet, STOP_WHEN_EXCEPTION))

{

// Failed to execution, exception occurred

// Stop simulation

// Restore stack

pCpu->m_esp = nEsp;

return 0;

}

if (pCpu->m_esp >= nEsp)

{

// Stack is restored by exception handler,

return immediately

// return 1 means continue excution

return 1;

}

// Drop arguments

pCpu->m_esp += 0x10;

// Restore EIP (since it has been changed by CallNear

pCpu->m_eip = nEip;

if (nRet == 0)

{

// Return 0 means continue excution

nRet = EXCEPTION_CONTINUE_EXECUTION;

break;

}

switch (nRet)

{

case 1:

// Don’t care this exception

break;

case 2:

// Nexsed excpetion

break;

case 3:

// Collided unwind

break;

}

// Try next seh pointer

nSEH = *(u32 *) pCpu->GetAddressAt(pCpu->

m_ds, nSEH, sizeof(u32));

}

通過對這些Windows系統(tǒng)的API、異常處理等關鍵特性的模擬，使該檢測系統(tǒng)具備了掌握目標代碼執(zhí)行流程的能力，這是區(qū)別于傳統(tǒng)檢測手段的主要部分。

5 虛擬沙盒測試

為了測試所提出虛擬化的沙箱對惡意代碼行為監(jiān)控效果，為此，采用了使用編號為CVE-2012-0158的Microsoft Office安全漏洞文件進行檢測，檢測結果如圖1和圖2所示。從圖1可見，所提出的虛擬沙盒技術方案成功地檢測到該文件低12291處存在疑似ShellCode惡意代碼，圖2顯示了該疑似ShellCode惡意代碼實際位置為0x3005。因此，所提出的虛擬沙盒技術方案能夠檢測相關的惡意代碼。

圖1 檢測結果

圖2 文件16進制顯示

6 結語

在破壞與反破壞的過程中，惡意代碼為了躲避各類安全軟件的查殺，使用越來越復雜的技術來隱藏自己，這給惡意代碼的檢測和防治帶來了很多困難，計算機系統(tǒng)和網絡安全面臨的威脅和破壞日漸復雜。本文探討了惡意代碼的攻擊技術和惡意行為分析方法，并針對現有沙箱技術不能跨平臺，系統(tǒng)部署復雜的問題，提出了使用純虛擬化解釋執(zhí)行的手段檢測惡意代碼的一種方法。從實驗結果可以看出，沙箱能夠有效地檢測惡意代碼對文件操作和網絡行為，并對其進行限制。但是，沙箱技術對樣本實例的檢測結果還不夠全面，需要更進一步地研究。