一種改進的基于在線解耦的輕量級動態(tài)污點分析方法

潘家曄，莊 毅

(南京航空航天大學 計算機科學與技術(shù)學院，南京 211106)

1 引 言

當前，惡意代碼仍然不斷以新的形式來感染和攻陷各類終端系統(tǒng)，如：勒索軟件，挖礦代碼以及隱私竊取等[1,2].由于缺少源代碼，改進和提高二進制程序的逆向調(diào)試和自動化分析方法仍然是一項重要研究內(nèi)容[3,4].在過去十年內(nèi)，動態(tài)污點分析方法作為一種有效的細粒度分析方法，盡管面臨性能及可應(yīng)用性等問題，但仍有許多研究工作對其進行改進[5-7]，例如：在更廣闊的系統(tǒng)范圍內(nèi)對目標程序進行分析[8,9]；引入靜態(tài)分析并對動態(tài)分析過程進行優(yōu)化[10]；將程序執(zhí)行和分析過程進行解耦分離[11,12]；采用在線與離線方式結(jié)合完成分析[13].一些代表性的研究工作如：A.Davanian等人提出改進的全系統(tǒng)動態(tài)污點分析系統(tǒng)DECAF++[14].Banerjee等人提出新的動態(tài)分析優(yōu)化方法Iodine[15]，避免在樂觀分析下引起的頻繁回滾.Kemerlis等人提出并實現(xiàn)更加通用的分析方法libdft[16]，基于此方法可快速的構(gòu)建分析工具對商業(yè)軟件進行分析.Jee等人將靜態(tài)與動態(tài)進行結(jié)合，通過靜態(tài)分析提取數(shù)據(jù)流跟蹤邏輯并消除冗余部分，減小動態(tài)分析時對目標程序的影響[10],而后又提出了加速數(shù)據(jù)流分析的方法ShadowReplica[11]，將程序執(zhí)行和分析過程進行解耦，利用多核CPU并行化完成分析.Ming等人提出了并行化的符號污點分析方法TaintPipe[17]，同樣分離程序執(zhí)行過程與數(shù)據(jù)流分析，能夠降低目標程序負載，提高分析速度.盡管存在針對動態(tài)污點分析的各類研究，但是在實際應(yīng)用時仍然存在很多因素，使得動態(tài)污點分析難以在真實場景中得到更快捷及廣泛的應(yīng)用，例如：依賴一定程度的靜態(tài)分析，限制于特定的分析場景，分析過程的構(gòu)建比較復雜，對處理器資源消耗較大，或者難以面向現(xiàn)代大型應(yīng)用程序，缺乏通用性.

因此，在已有研究基礎(chǔ)上，本文提出一種改進的輕量級在線解耦的動態(tài)污點方法，稱之為DOTA，其以解耦分析為主要思想，并具有較好的可應(yīng)用性，能夠支持對各類復雜應(yīng)用程序進行分析.該方法首先對目標程序進行攔截，記錄動態(tài)污點分析所需的運行時信息，與此同時構(gòu)建用于分析的代碼和執(zhí)行環(huán)境.與其它方法相比，本文所提的方法靈活高效，分析的構(gòu)建過程更加快捷和簡單；不依賴于靜態(tài)分析而進行優(yōu)化，能構(gòu)建相對獨立、能進行遷移的分析環(huán)境，降低對目標程序的影響，并且支持對各類多線程程序進行分析.

2 方法概述

動態(tài)污點分析屬于指令級別的細粒度分析方法，傳統(tǒng)方法在分析時需要對目標程序進行大范圍的插樁，同時消耗大量的內(nèi)存空間，因此本文所提方法的重要目標是盡量降低對目標程序執(zhí)行環(huán)境的影響.方法的總體架構(gòu)示意圖如圖1所示，當前主要針對用戶模式下的程序進行分析，我們在獨立的進程空間或內(nèi)核空間中構(gòu)建分析環(huán)境.針對目標程序涉及的進程環(huán)境中的每個線程，創(chuàng)建一個相對應(yīng)的分析線程，并且處理兩者之間的數(shù)據(jù)讀寫與分析同步問題.分析環(huán)境由一系列分析線程和輔助緩沖區(qū)構(gòu)成，可構(gòu)建于一個最基本的進程執(zhí)行環(huán)境中，該進程可由攔截模塊創(chuàng)建，其生存周期基本與目標程序相同，也可直接構(gòu)建于內(nèi)核空間中.當目標程序執(zhí)行完成時，其對應(yīng)的分析過程也將同步完成.對于污點分析時所需的額外輔助內(nèi)存，如構(gòu)建指令分析代碼，存儲分析狀態(tài)等，則直接在分析進程空間中分配和創(chuàng)建.根據(jù)攔截方式的不同，攔截模塊可位于目標進程空間內(nèi)或者內(nèi)核中，當其獲取到線程創(chuàng)建、內(nèi)存分配以及新程序塊執(zhí)行等事件時，同時在分析環(huán)境中創(chuàng)建分析線程和所需的輔助空間.圖中攔截模塊出現(xiàn)在目標進程內(nèi)，可采用動態(tài)插樁方法來實現(xiàn)[18]，實際上也可以采用其它方法.

圖1 總體架構(gòu)示意圖Fig.1 Overall architecture of the proposed method

在進行具體分析時，事實上主要需對兩大類指令進行處理，一是對于涉及內(nèi)存訪問的指令，在執(zhí)行過程中，指令訪問的內(nèi)存地址會發(fā)生變化，另外可能會受到多個線程以及系統(tǒng)內(nèi)核的影響.因此，在分析過程中，較好的方法是實時獲取這些信息以保證準確性.二是對于僅涉及寄存器運算的指令，在多數(shù)情況下，只會受到當前線程的上下文影響，因此可以直接對其進行分析，而無需獲知其它信息.因此，與傳統(tǒng)分析類似，首先需對目標程序進行攔截并記錄一些運行時信息，并通過共享內(nèi)存方式來進行進程，傳輸記錄的運行時信息到分析環(huán)境，而后在構(gòu)建分析環(huán)境時，需要對這兩種情況進行不同的處理.需要注意的是，如果分析環(huán)境構(gòu)建于內(nèi)核中，則可直接映射并讀取目標進程空間的相關(guān)內(nèi)存數(shù)據(jù).

3 分析代碼構(gòu)建

3.1 分析狀態(tài)

線程上下文信息主要涉及寄存器狀態(tài)，我們采用相同大小的內(nèi)存空間來存儲其分析狀態(tài).即32位平臺下共有8個寄存器，對此采用32個字節(jié)存儲狀態(tài)，這里針對的是字節(jié)級別的污染狀態(tài)傳遞情形.對于進程內(nèi)存空間對應(yīng)的分析狀態(tài)，基于虛擬地址采用相應(yīng)大小的映射空間來存儲，即當目標程序分配可訪問的內(nèi)存頁面時，同時在分析進程中分配相應(yīng)的內(nèi)存頁面用于存儲其分析狀態(tài)，并且構(gòu)建映射表項，在32位平臺中整個映射表占用2MB空間.因此，在分析過程中內(nèi)存分析狀態(tài)的更新過程將得到簡化，而存儲分析狀態(tài)所需的內(nèi)存空間跟目標程序在運行時分配的內(nèi)存大小相關(guān)，更具體地是跟提交分配的物理頁面數(shù)量相關(guān)，這在實際應(yīng)用中是相對有限的.另外需要注意的是，如果分析線程執(zhí)行時，讀取的分析狀態(tài)存儲頁面還未分配時將會產(chǎn)生訪問異常，此時在異常處理程序中重新分配和構(gòu)建狀態(tài)存儲頁面即可.當在分析過程中實際物理頁面還未分配時，會導致上述情形出現(xiàn).

3.2 分析代碼塊

當攔截模塊捕捉到新的程序基本塊出現(xiàn)時，同時在分析進程中為其構(gòu)建相應(yīng)的分析代碼塊，同時構(gòu)建描述分析代碼信息的結(jié)構(gòu)體來記錄分析代碼的相關(guān)信息并添加到映射表項，便于獲取分析代碼信息及鏈接不同的分析代碼塊，并判斷當前程序基本塊對應(yīng)的分析代碼是否已經(jīng)構(gòu)建過，并檢查原程序代碼是否被修改.目標程序執(zhí)行的指令地址到分析代碼信息塊的映射結(jié)構(gòu)與進程頁表結(jié)構(gòu)類似，這里可采用三級索引結(jié)構(gòu).對于32位地址，與上節(jié)類似，一級索引表采用目標地址的高20位作為索引進行查詢，而末級索引表則使用指令地址的最低2位比特.因此，一級索引表總共需要占用2MB的空間，而后兩級結(jié)構(gòu)的空間消耗取決于目標程序?qū)嶋H加載的代碼大小.此外，為便于分析代碼獲取描述結(jié)構(gòu)體信息，同時將描述結(jié)構(gòu)地址保存在實際執(zhí)行的分析代碼之前.

污點分析過程中主要進行的任務(wù)是傳遞污染狀態(tài)，該功能實際上相對較容易實現(xiàn).因此，可以在分析代碼中利用固定的寄存器來表示分析上下文以外的信息，例如：用ebx表示當前讀取的運行時信息緩沖區(qū)地址，將edx指向存儲寄存器分析狀態(tài)的內(nèi)存空間.而后針對上文所述兩種類型的指令，我們分別構(gòu)建相應(yīng)的分析代碼.對于涉及內(nèi)存訪問的指令，先從記錄緩沖區(qū)中讀取相應(yīng)的內(nèi)存地址并獲取對應(yīng)的狀態(tài)存儲地址，同時保證數(shù)據(jù)的同步，更具體的情況將在下文作進一步討論.對于僅涉及寄存器運算的指令，則直接通過簡單的傳送指令完成分析狀態(tài)的傳遞操作，并不依賴于其它線程和運行時信息.例如：對于原指令“mov eax，ecx”，則在分析代碼中使用“mov eax，[edx+24]；mov [edx+28]，eax”兩條指令來完成狀態(tài)傳遞.

3.3 代碼塊的鏈接和執(zhí)行

由于分析代碼塊與原程序產(chǎn)生的基本塊保持對應(yīng)關(guān)系，因此當原程序出現(xiàn)分支指令時，分析代碼也需要能夠正確的跳轉(zhuǎn)到下一分析代碼塊繼續(xù)執(zhí)行.我們分別處理兩種分支情況，一是間接跳轉(zhuǎn)，如jmp eax、call [ecx]、 ret等.其中，對于涉及內(nèi)存訪問的指令，由于我們已經(jīng)對其進行攔截并記錄相關(guān)信息，因此可以從記錄緩存區(qū)中附帶取得下一個要執(zhí)行的分析代碼的指令地址.對于其它的間接跳轉(zhuǎn)，同樣可通過額外插樁記錄來獲取目標地址.二是直接跳轉(zhuǎn)，即可直接從代碼中獲取跳轉(zhuǎn)目標地址，但是對于其中的條件跳轉(zhuǎn)，仍然需要根據(jù)實際執(zhí)行情況來進行判斷.與原程序不同，分析代碼在分配時并不是連續(xù)的，因此需要重新建立不同分析代碼塊之間的依賴關(guān)系.如圖2所示，我們在分析代碼中結(jié)合無條件跳轉(zhuǎn)指令來重建構(gòu)建條件跳轉(zhuǎn)指令，從而將不同的分析代碼塊關(guān)聯(lián)在一起，保證其能連續(xù)正確的執(zhí)行，并使用直接地址跳轉(zhuǎn)來提高代碼執(zhí)行速度.

實際上分析代碼在執(zhí)行時，其下一個執(zhí)行的目標地址將會出現(xiàn)在記錄緩沖區(qū)中，為此在構(gòu)建條件跳轉(zhuǎn)指令時，可通過與下一個要讀取的緩沖區(qū)內(nèi)容進行比較來決定所要執(zhí)行的跳轉(zhuǎn)目標，如圖2中“cmp [eax-4]，241200”所示.需注意的是，這里比較的對象是分析代碼所對應(yīng)的描述結(jié)構(gòu)信息，其目的是當原程序代碼在執(zhí)行過程中被修改時，實際的分析代碼仍然能夠被正確執(zhí)行，即對于起始地址相同的原程序基本塊，可能會有多個分析代碼共享同一個分析代碼描述結(jié)構(gòu).在這種情況下，我們將直接從記錄緩沖區(qū)中獲取下一個分析代碼塊并執(zhí)行，如圖2所示，100A6DE2處的代碼修改，將導致其對應(yīng)的分析代碼重建，同時將其原來已鏈接的分析代碼的開頭處修改為間接跳轉(zhuǎn).

圖2 條件跳轉(zhuǎn)和分析代碼Fig.2 Conditional jump and analysis code

針對上述條件跳轉(zhuǎn)的情況，當攔截到目標程序執(zhí)行新的程序基本塊時，由于對已經(jīng)執(zhí)行的基本塊進行了記錄，因此我們可以獲取到跳轉(zhuǎn)至當前基本塊的上一個基本塊，并更新其對應(yīng)的分析代碼中的無條件跳轉(zhuǎn)地址.如圖2所示，從起始地址為100A6DD2的基本塊可以執(zhí)行到地址100A6E97，這樣當攔截到100A6E97處的基本塊時，同時更新上一個基本塊對應(yīng)的分析代碼.如圖2所示，無條件跳轉(zhuǎn)目標地址202A10為更新后的指向?qū)嶋H分配的分析代碼.

另外，由于用戶回調(diào)和異步執(zhí)行調(diào)用等機制的存在，當用戶模式下的程序從系統(tǒng)內(nèi)核返回后未必會繼續(xù)執(zhí)行后面相鄰的指令.所以對于會導致處理器特權(quán)級別切換的指令，如：sysenter，int等，也需在程序執(zhí)行時記錄下其返回后的指令執(zhí)行地址，在分析代碼中按照間接跳轉(zhuǎn)的方式來處理.

4 信息記錄與線程同步

目標程序在執(zhí)行時同步記錄進行污點分析所需的運行時信息，主要為涉及的內(nèi)存地址與值，以及必要的分支信息，通常采用代碼插樁的方式來完成.主要原因是這些信息容易發(fā)生變化，我們需保證整個分析過程的準確性.針對分支信息的記錄，包括兩種情況，一是如果當前程序基本塊中包含有內(nèi)存操作指令，則在第一個訪存指令處同時記錄當前基本塊地址；另一種是當前基本塊不包含訪存指令，則在基本塊開頭處作額外插樁并記錄其起始地址.在大多數(shù)情況下，基本塊內(nèi)都會有指令涉及內(nèi)存訪問操作.另外，對于不含訪存指令的基本塊，事實上可以從當前線程的上一次記錄處開始，通過寄存器運算來得到跳轉(zhuǎn)目標地址，但可能會增加上下文切換的額外開銷和出錯的可能性.

在進行信息記錄時，為減小內(nèi)存開銷，可以采用單個環(huán)形隊列或者多個緩沖區(qū)輪流記錄的方式[17]，同樣可減少因線程同步所帶來的額外開銷.目標程序線程與分析線程并行同步執(zhí)行，即當原線程被創(chuàng)建時，同步創(chuàng)建并執(zhí)行對應(yīng)的分析線程.多數(shù)情況下，由于分析線程完成的工作量要比原線程少，因此在每次從記錄緩沖區(qū)中讀取數(shù)據(jù)時，需要判斷取值是否為空，以保證分析執(zhí)行的一致性.如圖3所示，當分析線程從緩沖區(qū)中讀取到的值為空時，則繼續(xù)讀取直到其值不為空.在此情況下，各個分析線程間的同步基本能夠得到保證.另外，為控制分析線程對處理器資源的占用，當目標程序進出系統(tǒng)內(nèi)核執(zhí)行時，在保存記錄時設(shè)置特殊標記，這樣分析線程可根據(jù)該標記來進行等待和被喚醒.同樣，若采用多個緩沖區(qū)時，在單個寫滿時也應(yīng)添加標記.如圖3中的數(shù)字順序所示，中間當目標線程遇到系統(tǒng)調(diào)用時，則向緩沖區(qū)中寫入e，而對應(yīng)的分析線程如果讀取到該值，則進一步讀取緩沖區(qū)中的下一個值，如果下一個值為空，則表明目標線程還未從內(nèi)核返回，此時分析線程則可進入睡眠狀態(tài)，直到目標線程返回時被喚醒.

圖3 線程同步示意圖Fig.3 Synchronization between the native thread and analysis thread

5 實驗與分析

本文在Windows平臺上實現(xiàn)了該方法的原型，采用Intel Pin對目標程序進行插樁和攔截，并利用其提供的INS_InsertFillBuffer接口來記錄目標程序的運行時信息[18]，在記錄緩存區(qū)滿時使用系統(tǒng)函數(shù)WaitOnAddress來進行等待同步，具體的污點分析代碼基于libdft的核心部分進行構(gòu)建，并在實驗中與之進行性能比較.實驗環(huán)境為安裝Intel Core i7-7700 CPU @ 3.60GHz、16GB內(nèi)存的普通桌面終端，其中安裝的操作系統(tǒng)為Windows 10 64-bit，當前測試目標為32位應(yīng)用程序.

5.1 性能評估

采用Windows平臺下多種常見應(yīng)用程序來測試分析性能以及資源占用情況，具體列表如圖4所示.具體的實驗場景為，分別使用程序makecab、winzip(v21)及openssl(v1.0.2n)對大小為10MB的文本文件進行壓縮或加密，其中openssl首

圖4 針對多種應(yīng)用程序的分析性能比較Fig.4 Comparisons of analysis performance for different programs

先要基于源碼進行編譯并使用aes-256-cbc加密模式.使用pscp(1)城鎮(zhèn)化之前川渝地區(qū)鄉(xiāng)下人居的正屋(又稱“堂屋”)用作逢年過節(jié)祭祀點香用。從本地服務(wù)器下載大小為10MB的文件.而后使用7zip(v18.05)將大小為5MB的文本壓縮為默認7z格式，使用ffmpeg(v4.0.2)將大小為1MB的wmv文件轉(zhuǎn)換為mp4格式.最后使用系統(tǒng)內(nèi)置程序xcopy復制系統(tǒng)分區(qū)中的WindowsINF文件夾到其它分區(qū).選擇不同的文件大小主要是基于執(zhí)行時間和對比展示的綜合考慮.在實驗時，各場景重復多次并對相關(guān)結(jié)果計算平均值，并將結(jié)果與經(jīng)典分析方法進行比較，主要結(jié)果如圖4和圖5所示.

圖5 對不同程序進行分析時的CPU占用率Fig.5 CPU usage in the analysis of different programs

在采用本文DOTA方法對不同程序進行分析時，其分析性能均會有提高，提高程度取決于具體的應(yīng)用程序.如圖4所示，對7zip和ffmpeg這類內(nèi)存讀寫密集型程序，其分析效率提升效果會更加明顯.另外圖中DOTA_R表示僅對目標程序進行插樁并記錄信息，但不進行分析的結(jié)果，與之相比，整個分析過程的效率降低并不明顯.該情況表明線程同步和具體污點分析實際未對性能造成明顯影響.多數(shù)情況下應(yīng)用程序涉及內(nèi)存訪問的指令執(zhí)行數(shù)量會占有較大的比例，由于實驗中采用Pin來獲取運行時信息，因此實際分析性能仍會受制于在線記錄過程，盡管其可能不是速度最優(yōu)的選擇，但是較容易應(yīng)用和部署的工具.從圖5來看，分析線程導致的CPU占用率升高程度在可接受范圍內(nèi)，因為普通終端的總共可用CPU核心數(shù)量并不會太多，我們需要考慮其影響.另外，進行上述實驗時，每個線程的記錄緩沖區(qū)大小為256KB，記錄時采用雙緩沖來進行.

事實上，為控制CPU使用率，分析線程和原線程之間的同步仍然存在一定的開銷，也會受到緩沖區(qū)大小的影響，其影響程度還依賴于目標程序的特點.我們選擇上面的7zip程序進行同樣的實驗，但是改變記錄緩沖區(qū)的數(shù)量來分析其帶來的影響.從實驗結(jié)果得知，當緩沖區(qū)數(shù)量為單個時，當其滿時會因同步問題，導致分析效率明顯下降.在其它情況下，完成分析所需時間和CPU占用率均隨著緩沖區(qū)數(shù)量緩慢增長.其中一個主要原因是內(nèi)存分配以及緩沖隊列維護帶來的開銷.另外，若在實驗中將緩沖區(qū)的數(shù)量固定為2個，則在此情況下，當單個緩沖區(qū)大小增加時，其分析性能并未一直隨著提高.其原因是Pin會對已滿的緩沖區(qū)進行清零處理，當其大小增加時，其對目標程序執(zhí)行的影響程度會累積.總的來看，緩沖區(qū)的不同設(shè)置并不會對分析造成嚴重影響.

針對各程序進行分析時的內(nèi)存資源占用情況如表1所示，分析代碼的內(nèi)存消耗情況跟實際執(zhí)行的基本塊數(shù)量相關(guān)，多數(shù)情況下處于較小的范圍內(nèi).分析代碼映射表中的二級索引大小與加載代碼保持一致，而末級索引的內(nèi)存開銷可以忽略不計.依賴目標程序?qū)嶋H加載代碼大小的還有污染狀態(tài)存儲空間，并且其還與程序執(zhí)行時實際分配的內(nèi)存相關(guān).注意的是，實驗中是根據(jù)目標程序分配的虛擬地址來分配狀態(tài)存儲空間的，而實際已分配物理頁面并使用的虛擬地址數(shù)量會更少，但當前總體內(nèi)存消耗在可接受范圍.

表1 資源占用情況統(tǒng)計Table 1 Statistics of other resource occupations

在采用真實環(huán)境程序進行實驗的基礎(chǔ)上，我們基于基準測試工具SPEC CPU 2006中的部分程序做進一步的性能測試，采用ref工作負載進行，并以程序原始執(zhí)行所消耗的時間為基線值來計算其它兩種分析環(huán)境下的執(zhí)行速度的降低比率.如圖6所示，從實驗結(jié)果來看，在長時間的運行過程中，DOTA分析與傳統(tǒng)分析相比仍然取得一定的分析性能的提升.由于基準測試程序運行時采用單線程，所以總體的CPU的開銷為原來兩倍左右.

圖6 采用基準程序進行測試的性能開銷對比Fig.6 Performance comparisons for the tests on benchmark programs

5.2 案例分析

我們通過多個實際數(shù)據(jù)流分析的場景來驗證本文所提方法的有效性.首先使用openssl對大小為1K的文件進行加密并將其內(nèi)容保存至另一個文件；而后分別使用系統(tǒng)內(nèi)置程序certutil，以及第三方應(yīng)用程序aria2(v1.34)、curl for Windows(v7.61)、wget2所提供的下載功能從本地服務(wù)器上下載大小為1K的文件；最后對Trickbot惡意代碼樣本的數(shù)據(jù)發(fā)送功能進行分析，其在被感染的終端上啟動運行后會創(chuàng)建文件client_id，讀取內(nèi)容后通過https協(xié)議發(fā)送到服務(wù)器端.而后在分析時,我們同時攔截NtReadFile、NtWriteFile和NtDeviceIoControlFile等系統(tǒng)函數(shù)，在其中標記相關(guān)內(nèi)存地址為污染狀態(tài),并且及時檢測數(shù)據(jù)污染情況.實驗結(jié)果表明，本文方法均能夠檢測到污點數(shù)據(jù)的寫入或者發(fā)送操作，并且通過多次重復實驗得知其污點狀態(tài)的傳播情況基本上與傳統(tǒng)分析時保持一致，而且不同的應(yīng)用程序用于存儲污點狀態(tài)的內(nèi)存開銷在20MB至45MB之間，占用相對較低的內(nèi)存資源，其它的統(tǒng)計信息如表2所示.

表2 功能分析的數(shù)據(jù)統(tǒng)計Table 2 Statistics of the functionality analysis

另外，certutil和trickbot程序在運行時由不同的線程來完成網(wǎng)絡(luò)通信和文件讀寫過程，并且使用本文所提方法能夠正確的進行污點分析，跨線程來傳遞污染狀態(tài)，能檢測到網(wǎng)絡(luò)數(shù)據(jù)到目標文件的映射關(guān)系.此外,從表2中可以看出，盡管目標程序為多線程應(yīng)用，但是與分析場景相關(guān)的往往只是部分線程以及部分執(zhí)行代碼.因此在實際分析中，我們可以只對相關(guān)線程涉及的代碼進行攔截和分析，這將有利于對現(xiàn)代大型應(yīng)用程序的分析.

6 討 論

本文提供了一種針對多線程程序，快速構(gòu)建在線解耦分析的思路，旨在充分利用現(xiàn)有插樁工具并進一步提高分析效率，通過實際程序驗證了其可行性.與其它解耦分析相比，進一步提高了易用性和適用范圍，并合理控制目標環(huán)境的資源開銷.

該方法在線獲取的運行時信息較為充分，盡管也會帶來一定的性能開銷，但是能夠簡化分析過程并保證準確性.當前分析效率仍受限于信息記錄過程，而目標程序運行時的信息記錄也可以采用其它更高效的插樁和記錄方法來進行.在分析中該方法也可以采用其它污點分析引擎.

當前分析代碼采用匯編語言編寫構(gòu)建，會導致分析缺乏一些靈活性.在實際中，如果有其它分析需求，可以先使用高級語言編寫，再通過編譯器優(yōu)化功能來提取字節(jié)代碼.

分析線程也可以在目標進程內(nèi)執(zhí)行，但這樣會占用更多的目標進程的虛擬地址空間，也可以將其放入內(nèi)核層.而其它的輔助緩沖區(qū)等內(nèi)存也可以通過共享內(nèi)存來進行.

在極端情況下，當不同目標線程間采用原子方式在極短時間內(nèi)完成同步時，由于操作系統(tǒng)的線程調(diào)度機制，相對應(yīng)的分析線程可能會未能及時處理該情況，此時需要加入額外的檢查代碼.

7 結(jié) 論

本文提出一種改進的輕量級在線解耦的動態(tài)污點分析方法，相比于傳統(tǒng)分析方法能更高效的對目標程序進行細粒度分析，通過分離出部分可獨立于原程序執(zhí)行的分析任務(wù)，并構(gòu)建相對應(yīng)的分析代碼，可降低對目標程序執(zhí)行環(huán)境的影響并提高分析效率.本文通過采用多種真實程序及案例研究來驗證了該方法的有效性和易用性.后續(xù)將針對任務(wù)分割、多線程同步以及64位平臺開展進一步研究，以提高分析效率和部署靈活性.