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

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

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

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

1 惡意代碼攻擊與檢測(cè)技術(shù)

1.1 惡意代碼攻擊技術(shù)

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

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

1.2 惡意代碼分析方法

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

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

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

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

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

2 沙箱技術(shù)簡(jiǎn)介

2.1 沙箱安全模型

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

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

2.2 Windows API掛鉤技術(shù)

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

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

2.3 虛擬化技術(shù)

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

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

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

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

3 基于應(yīng)用層的沙箱監(jiān)控技術(shù)

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

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

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

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

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

3.2 網(wǎng)絡(luò)行為監(jiān)控

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

1) 端口復(fù)用

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

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

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

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

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

3) 端口反向連接

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

4) 可疑報(bào)文收發(fā)

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

上述分析表明，可以通過監(jiān)控表2的API函數(shù)實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)行為的監(jiān)控，同時(shí)也可以在網(wǎng)卡虛擬化的基礎(chǔ)上對(duì)通信行為與流量進(jìn)行嗅探，也可以達(dá)到同樣的網(wǎng)絡(luò)行為監(jiān)控的目的。

表2 網(wǎng)絡(luò)操作監(jiān)控的關(guān)鍵API函數(shù)表

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

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

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

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

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

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

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

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

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

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

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

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

4.1 沙箱流程

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

4.2 x86寄存器模擬

模擬執(zhí)行x86匯編代碼，先要模擬CPU基礎(chǔ)架構(gòu)，下面數(shù)據(jù)結(jié)構(gòu)用于模擬x86框架下的寄存器。

32位寄存器模擬的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)如下。

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 },

};

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

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位寄存器模擬后，再配合反匯編引擎的解析，就可以實(shí)現(xiàn)對(duì)基本的匯編指令進(jìn)行解釋模擬運(yùn)行。

4.3 內(nèi)存地址映射關(guān)鍵代碼

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

為目標(biāo)指令提供虛擬的內(nèi)存環(huán)境，供尋址指令調(diào)用，采用代碼模擬虛擬地址映射的方式，其內(nèi)存地址映射關(guā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 反匯編獲取指令

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

獲取指令分類關(guān)鍵代碼如下。

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];

然后，根據(jù)指令類型，獲取該條匯編指令的詳細(xì)內(nèi)容。對(duì)整個(gè)數(shù)據(jù)流進(jìn)行反匯編是個(gè)不斷前進(jìn)持續(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);

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

4.5 匯編指令模擬

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

__asm{

push edx

mov ecx, this

lea ebx, [ecx]this.m_pCodes

mov ecx, pCpu

call dword ptr [ebx]

pop edx

}

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

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

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

// 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);

}

確定了上述內(nèi)存映射方式以后，就可以為虛擬環(huán)境開辟單獨(dú)的內(nèi)存空間。當(dāng)目標(biāo)代碼嘗試操作虛擬內(nèi)存時(shí)，通過上述映射方式對(duì)虛擬內(nèi)存進(jìn)行操作。

4.7 內(nèi)存結(jié)構(gòu)

為了使沙箱虛擬機(jī)的沙箱環(huán)境區(qū)全面支持Windows環(huán)境，即能實(shí)現(xiàn)對(duì)x86匯編指令環(huán)境的模擬，還應(yīng)實(shí)現(xiàn)對(duì)Windows系統(tǒng)特性如內(nèi)存結(jié)構(gòu)的支持?？紤]到ShellCode編碼的特點(diǎn)，運(yùn)行時(shí)會(huì)預(yù)先查找當(dāng)前所在進(jìn)程內(nèi)存空間，從中搜索到自己所需要的系統(tǒng)函數(shù)地址，因此，沙箱虛擬機(jī)需要模擬Windows進(jìn)程內(nèi)存，以便ShellCode可以在該虛擬環(huán)境中正常運(yùn)行。對(duì)虛擬內(nèi)存的模擬設(shè)置如下。

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

g_pMainCpu->CreateSegment(g_pMainCpu->

m_fs, 0xFFDF0000, 0x0FFF);

//從正常進(jìn)程中Dump出一份FS段內(nèi)容，填充到虛擬空間中

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

LoadData_1(IMAGE_BASE_ADDR, "Image.dat",

0, 0x1f80);

其中LoadData_1實(shí)現(xiàn)過程，先讀入預(yù)先Dump出的正常進(jìn)程數(shù)據(jù)，然后覆蓋到設(shè)定的虛擬空間內(nèi)，即

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

LoadData_1(IMAGE_BASE_ADDR, "Image.dat",

0, 0x1f80);

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

4.8 代碼執(zhí)行

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

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

CreateImage(g_EntryPoint, nCodeSize);

//創(chuàng)建虛擬內(nèi)存，供模擬執(zhí)行時(shí)候調(diào)用

PutMemAt(g_EntryPoint, pCodeBuf, nCodeSize);

//將輸入數(shù)據(jù)填充到設(shè)定的虛擬內(nèi)存中

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

//模擬其他進(jìn)程區(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í)行輸入數(shù)據(jù)

unsigned long nProcessCount = 0;

int nRet = CallNear(g_EntryPoint,

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

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

4.9 其他Windows性能模擬

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

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 },

};

在對(duì)上述API的模擬過程中，對(duì)于較簡(jiǎn)單情況，可以調(diào)用真實(shí)的API函數(shù)，將結(jié)果返回；對(duì)于較為復(fù)雜的情況，需要利用Windows系統(tǒng)特性，如對(duì)用于設(shè)置當(dāng)前進(jìn)程異常處理SetUnhandledExceptionFilter函數(shù)的支持，該函數(shù)的模擬需要采用Windows系統(tǒng)異常處理機(jī)制的實(shí)現(xiàn)，其中SHE鏈處理關(guān)鍵代碼如下。

// 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));

}

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

5 虛擬沙盒測(cè)試

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

圖1 檢測(cè)結(jié)果

圖2 文件16進(jìn)制顯示

6 結(jié)語

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