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

潘家曄，莊 毅

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

1 引 言

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

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

2 方法概述

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

圖1 總體架構示意圖Fig.1 Overall architecture of the proposed method

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

3 分析代碼構建

3.1 分析狀態

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

3.2 分析代碼塊

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

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

3.3 代碼塊的鏈接和執行

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

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

圖2 條件跳轉和分析代碼Fig.2 Conditional jump and analysis code

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

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

4 信息記錄與線程同步

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

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

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

5 實驗與分析

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

5.1 性能評估

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

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

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

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

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

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

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

表1 資源占用情況統計Table 1 Statistics of other resource occupations

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

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

5.2 案例分析

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

表2 功能分析的數據統計Table 2 Statistics of the functionality analysis

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

6 討 論

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

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

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

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

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

7 結 論

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