基于Spark的大規(guī)模軟件完整性校驗(yàn)行為識(shí)別框架

邱景 李宜卓

摘 要：軟件完整性校驗(yàn)廣泛應(yīng)用于反篡改防御，保護(hù)軟件知識(shí)產(chǎn)權(quán)，防止盜版。因此，了解不同完整性校驗(yàn)方法的強(qiáng)度和弱點(diǎn)很重要。針對(duì)傳統(tǒng)檢測(cè)方法處理大規(guī)模數(shù)據(jù)時(shí)效率較低的問(wèn)題，描述了一個(gè)基于Spark的大規(guī)模軟件完整性校驗(yàn)行為識(shí)別框架。對(duì)于單個(gè)文件檢測(cè)，使用后向污點(diǎn)分析識(shí)別可執(zhí)行或者用來(lái)計(jì)算可執(zhí)行位置值的內(nèi)存位置，然后使用前向污點(diǎn)分析識(shí)別校驗(yàn)過(guò)程。該方法適用于多種不同完整性校驗(yàn)防御方案，提供的信息可以用來(lái)輔助繞過(guò)防御。實(shí)驗(yàn)表明，該方法可以有效識(shí)別常見(jiàn)軟件完整性校驗(yàn)行為。

關(guān)鍵詞：軟件安全;軟件反篡改;完整性校驗(yàn);污點(diǎn)分析

DOI：10. 11907/rjdk. 191219

中圖分類號(hào)：TP306文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1672-7800（2019）004-0046-04

0 引言

軟件完整性校驗(yàn)廣泛應(yīng)用于軟件防篡改保護(hù)技術(shù)中，其基本思想是對(duì)程序指令（或其它與指令相關(guān)的數(shù)據(jù)）計(jì)算一個(gè)哈希值，當(dāng)且僅當(dāng)這個(gè)哈希值與預(yù)期值相同時(shí)，程序才會(huì)正常執(zhí)行[1-7]。任何嘗試篡改代碼的行為，如關(guān)閉或移除一個(gè)許可證檢測(cè)，都會(huì)被完整性校驗(yàn)機(jī)制檢測(cè)到，因而可用來(lái)防止盜版。衡量不同完整性校驗(yàn)機(jī)制的強(qiáng)度和弱點(diǎn)也是安全領(lǐng)域研究熱點(diǎn)。

當(dāng)前已有不少軟件防篡改防御工作。Aucsmith[3]提出一種使用多重自修改和自解密代碼塊檢測(cè)運(yùn)行時(shí)代碼完整性的校驗(yàn)方法;Horne 等[4]、Chang 等[6]討論了一種使用校驗(yàn)過(guò)程網(wǎng)絡(luò)的完整性校驗(yàn)系統(tǒng)，校驗(yàn)過(guò)程之間相互保護(hù)，要繞過(guò)這種保護(hù)，需要同時(shí)繞過(guò)所有校驗(yàn)過(guò)程，無(wú)疑增加了破解難度;Tsang 等[8]提出使用大量隨機(jī)篡改響應(yīng)的校驗(yàn)過(guò)程，通過(guò)多個(gè)版本函數(shù)使得每次程序運(yùn)行不同代碼;Cappaert等[2]、Wang等[9]則利用校驗(yàn)值作為密鑰加解密程序，破壞程序完整性會(huì)導(dǎo)致解密過(guò)程生成錯(cuò)誤代碼。還有一些方法，如隱式設(shè)計(jì)篡改響應(yīng)，使得攻擊者難以從篡改響應(yīng)回溯到校驗(yàn)驗(yàn)證代碼[10]。也有通過(guò)隱式哈希方法檢測(cè)代碼執(zhí)行效果是否符合預(yù)期，以判斷軟件是否被篡改[11]。文獻(xiàn)[12]使用污點(diǎn)分析指令執(zhí)行軌跡檢測(cè)上述軟件完整性校驗(yàn)行為。以上方法無(wú)法應(yīng)付大規(guī)模軟件分析，且存在誤報(bào)率高的問(wèn)題。

還有一些反篡改防御工作，通過(guò)一個(gè)可信的遠(yuǎn)程服務(wù)器完成完整性校驗(yàn)[1，5]。湯戰(zhàn)勇等[13]提出一種進(jìn)程級(jí)虛擬機(jī)軟件防篡改方法，以虛擬指令方式融合校驗(yàn)、哨兵技術(shù)和反調(diào)試技術(shù)。這些方法超出了本文工作范圍。

傳統(tǒng)單機(jī)分析滿足不了日益增長(zhǎng)的軟件發(fā)展趨勢(shì)，亟需多機(jī)并行處理提高速度。鑒于此，本文將Spark與完整性檢測(cè)算法結(jié)合，提出基于Spark的大規(guī)模軟件完整性檢驗(yàn)識(shí)別框。Spark作為當(dāng)前最流行的大數(shù)據(jù)處理平臺(tái)之一，一直受到各研究領(lǐng)域青睞[14]。如蘭云旭等[15]將傳統(tǒng)醫(yī)學(xué)圖像處理方法與Spark結(jié)合起來(lái)，提出基于Spark的并行醫(yī)學(xué)圖像處理方法;文獻(xiàn)[16]和文獻(xiàn)[17]利用Spark的機(jī)器學(xué)習(xí)庫(kù)從海量數(shù)據(jù)中檢測(cè)0day惡意軟件。

借助Spark的大數(shù)據(jù)處理平臺(tái)，本文框架可以較高效率地完成大規(guī)模軟件的完整性校驗(yàn)行為檢測(cè)。對(duì)于單個(gè)文件，檢測(cè)方法使用動(dòng)態(tài)信息流分析技術(shù)，識(shí)別軟件中多種完整性校驗(yàn)行為。污點(diǎn)分析是二進(jìn)制代碼信息流分析的主要技術(shù)，用來(lái)追蹤污點(diǎn)源與錨如何關(guān)聯(lián)[18]。

本文方法將檢測(cè)出完整性校驗(yàn)代碼的一些關(guān)鍵信息，如：是否有完整性校驗(yàn)發(fā)生及被校驗(yàn)代碼位置;發(fā)生創(chuàng)建的位置（如果校驗(yàn)代碼是動(dòng)態(tài)創(chuàng)建的）;計(jì)算出的校驗(yàn)值;比較校驗(yàn)值的代碼位置;篡改響應(yīng)機(jī)制（通過(guò)條件跳轉(zhuǎn)、間接跳轉(zhuǎn)，或者將校驗(yàn)值作為代碼解壓密鑰）等。這些信息包含完整性校驗(yàn)的大量細(xì)節(jié)，并給出如何繞過(guò)完整性校驗(yàn)提示，同時(shí)可以指出某個(gè)完整性校驗(yàn)機(jī)制的弱點(diǎn)以及可能的補(bǔ)救措施。

1 檢測(cè)框架

Spark操作對(duì)象稱作彈性分布式數(shù)據(jù)集（Resilient Distributed Dataset，RDD）。本文框架最主要操作是圍繞RDD進(jìn)行Map/Reduce。

整體檢測(cè)框架如圖1所示。流程如下：

（1）將待檢測(cè)可執(zhí)行文件復(fù)制到共享空間，路徑包裝成RDD。

（2）對(duì)于每個(gè)可執(zhí)行文件通過(guò)黑盒獲取執(zhí)行軌跡。執(zhí)行軌跡記錄程序運(yùn)行時(shí)的指令及地址，執(zhí)行軌跡可通過(guò)二進(jìn)制插樁工具如Intel Pin Tool，或者基于虛擬機(jī)的Ether得到[19，20]，這一步相當(dāng)于將可執(zhí)行文件映射成執(zhí)行軌跡。由于被檢測(cè)程序可能不會(huì)自動(dòng)關(guān)閉（如GUI程序），因此設(shè)置執(zhí)行時(shí)間限制及軌跡文件大小上限。

（3）對(duì)于一條執(zhí)行軌跡，搜集其中的已執(zhí)行代碼地址，然后均分成子任務(wù)，執(zhí)行后向污點(diǎn)分析，Map得到污點(diǎn)源后，Reduce各個(gè)計(jì)算節(jié)點(diǎn)結(jié)果得到不重復(fù)的污點(diǎn)源。

（4）均分上一步得到的污點(diǎn)源，使用前向污點(diǎn)分析Map得到子結(jié)果，Reduce匯總過(guò)濾得到最后報(bào)告。

2 完整性校驗(yàn)檢測(cè)

2.1 整體流程

一般來(lái)說(shuō)，一個(gè)完整性校驗(yàn)首先通過(guò)包含代碼或者用來(lái)創(chuàng)建代碼（即脫殼）的內(nèi)存計(jì)算一個(gè)值，然后用其影響后續(xù)要執(zhí)行的代碼。完整性校驗(yàn)檢測(cè)本質(zhì)就是搜索能夠控制代碼執(zhí)行的自校驗(yàn)行為。

本文完整性校驗(yàn)檢測(cè)方法包含如下步驟：

（1）后向污點(diǎn)分析。首先遍歷軌跡，搜集已執(zhí)行的內(nèi)存地址，標(biāo)記為污點(diǎn)。后向傳播污點(diǎn)識(shí)別可能用來(lái)創(chuàng)建執(zhí)行代碼的內(nèi)存地址。

（2）前向污點(diǎn)分析。從后向污點(diǎn)分析得到的污染位置開(kāi)始，分析前向傳播污點(diǎn)狀態(tài)。

（3）識(shí)別完整性校驗(yàn)。這一步識(shí)別校驗(yàn)值驗(yàn)證指令，檢查執(zhí)行軌跡中的指令是否滿足如下條件之一：①它是一個(gè)有污染操作數(shù)的控制轉(zhuǎn)移指令;②它寫(xiě)入一個(gè)污染值到后續(xù)被執(zhí)行的代碼內(nèi)存位置;③它傳入一個(gè)污染值到系統(tǒng)輸出函數(shù)，如printf（）。

然后，進(jìn)一步分析這些驗(yàn)證指令，得到校驗(yàn)代碼的額外細(xì)節(jié)。

2.2 污點(diǎn)分析

根據(jù)問(wèn)題特點(diǎn)，本文用字節(jié)級(jí)別的污點(diǎn)分析。污點(diǎn)分析傳播方向有前向（與控制流同向）和后向（與控制流反向）。在前向污點(diǎn)分析中，如果指令的源操作數(shù)是污染的，則其目標(biāo)操作數(shù)也標(biāo)記為污染。在后向污點(diǎn)分析中，如果目標(biāo)操作數(shù)是污染的，則源操作數(shù)也標(biāo)記為污染。

后向污點(diǎn)分析識(shí)別執(zhí)行軌跡中已執(zhí)行代碼的源位置，也就是執(zhí)行代碼從這些源位置變化（或者不變化）而來(lái)。這個(gè)分析是保守的，即若指令目標(biāo)操作數(shù)是污染的，則污染該條指令的所有源操作數(shù)，即使實(shí)際源操作數(shù)中只有一個(gè)是污染的。然后，將目標(biāo)操作數(shù)標(biāo)記為未污染。

2.3 識(shí)別完整性校驗(yàn)

首先，使用后向污點(diǎn)分析得到已執(zhí)行代碼的源位置，排除沒(méi)有被任何指令讀寫(xiě)的源位置。

其次，污染第一步得到的源位置，識(shí)別操作數(shù)被污染指令，對(duì)于能夠影響程序行為的指令也污染。

第三，每一個(gè)能夠影響程序行為的指令對(duì)應(yīng)一些源位置，如果這些源位置數(shù)量超過(guò)（用戶定義的）閾值θmin，則該指令被識(shí)別為完整性校驗(yàn)驗(yàn)證指令。

在x86中，函數(shù)調(diào)用通常被轉(zhuǎn)換為push指令和call指令組合，這類call不讀寫(xiě)污染的內(nèi)存地址。為了處理校驗(yàn)值流向系統(tǒng)輸出函數(shù)，對(duì)于call指令，若有其參數(shù)是污染的，則此指令也被認(rèn)為是污染的。

如果被分析文件使用一些壓縮工具，如UPX，代碼是壓縮的，則上述算法會(huì)有誤報(bào)。閾值θmin用來(lái)減少誤報(bào)。在解壓縮中（即脫殼），被壓縮字節(jié)序列會(huì)被復(fù)制到可執(zhí)行位置或不可執(zhí)行位置。不可執(zhí)行的內(nèi)存地址有可能會(huì)在前向污點(diǎn)傳播中被檢測(cè)到，從而導(dǎo)致誤報(bào)，因此使用閾值θmin過(guò)濾掉這些誤報(bào)。此外，本文還增加全局閾值θmax，如果被忽略的檢測(cè)數(shù)量超過(guò)θmax，則會(huì)生成一個(gè)警告。

一個(gè)軟件可以使用多個(gè)脫殼軟件加密，而完整性校驗(yàn)可能發(fā)生在脫殼過(guò)程序列的任何一個(gè)點(diǎn)。但是，本文算法可以檢測(cè)任意點(diǎn)的完整性校驗(yàn)。分析如下：

在算法第一步，Cn 中的指令地址以及Φi的代碼地址都將被搜集并污染。因?yàn)棣祅讀取了Cn-1，Cn-1的地址也將會(huì)被污染。以此類推，所有Ci以及Φi都會(huì)被后向污點(diǎn)傳播標(biāo)記。假設(shè)校驗(yàn)發(fā)生在第k個(gè)脫殼步驟之前（1≤k≤n），被校驗(yàn)地址集合為C'k-1[？]Ck-1。

假設(shè)C'k-1=C'0，后向污點(diǎn)分析將污染C'0，因此C'0前向傳播污點(diǎn)、CHECK（Ck-1）讀取的C'k-1以及參與校驗(yàn)計(jì)算本身的值，都將被標(biāo)記為污染。這使得參與完整性校驗(yàn)過(guò)程的值都將被污染，完整性校驗(yàn)也就會(huì)被識(shí)別。

本文方法需要處理大軌跡文件，在時(shí)空消耗上都會(huì)存在挑戰(zhàn)。一方面，可以使用軌跡壓縮技術(shù)減輕存儲(chǔ)和I/O消耗[21]。另一方面，可以使用兩個(gè)優(yōu)化技術(shù)加速污點(diǎn)分析：消除非相關(guān)指令、使用并行處理技術(shù)。

可以通過(guò)預(yù)污點(diǎn)分析，減少前向污點(diǎn)分析中指令的數(shù)量，得到一個(gè)子軌跡，包含前向污點(diǎn)分析所有相關(guān)指令。這個(gè)子執(zhí)行軌跡與原始執(zhí)行軌跡進(jìn)行前向污點(diǎn)分析效果是等價(jià)的。子軌跡通常遠(yuǎn)小于原始軌跡，因此可以顯著提高性能。前向污點(diǎn)分析中，只讀取指令軌跡文件，因此可以并行前向污點(diǎn)分析，可以通過(guò)均分污染源完成。

3 實(shí)驗(yàn)

3.1 實(shí)驗(yàn)配置

使用Intel Pin Tool記錄執(zhí)行軌跡[19]。實(shí)驗(yàn)使用5臺(tái)機(jī)器搭建Spark集群，機(jī)器配置為：3.70 GHz Intel Core i7-8700K 處理器，32 GB 主存，Ubuntu 18.04;Spark版本為2.0.2;算法θmin、θmax分別設(shè)置為16和512。

測(cè)試集使用自行編寫(xiě)的各種完整性校驗(yàn)方案程序。在每一個(gè)程序中，修改MD5計(jì)算程序包含完整性校驗(yàn)。測(cè)試包含4種完整性校驗(yàn)。

（1）Horne等[4]、Chang等[6]所描述的多個(gè)完整性校驗(yàn)過(guò)程校驗(yàn)方案。其用于檢測(cè)本文方法是否能夠正確識(shí)別多個(gè)重疊的完整性校驗(yàn)過(guò)程。本組測(cè)試程序中分別有1個(gè)（1-guards）、4個(gè)（4-guards）、10個(gè)（10-guards）、50個(gè)（50-guards）完整性校驗(yàn)過(guò)程。

（2）Cappaert等[2]、Wang等[9]所描述的校驗(yàn)值作為代碼解密密鑰校驗(yàn)方案。其用于測(cè)試是否能夠檢測(cè)校驗(yàn)值驗(yàn)證和篡改響應(yīng)使用動(dòng)態(tài)代碼修改影響程序執(zhí)行，而不是使用一個(gè)顯式的控制流轉(zhuǎn)換到篡改響應(yīng)。該程序稱為decrypt-key。

（3）運(yùn)行時(shí)在代碼解壓縮過(guò)程中進(jìn)行完整性校驗(yàn)。測(cè)試能否檢測(cè)被校驗(yàn)地址自身是不執(zhí)行的，而是用來(lái)創(chuàng)建執(zhí)行代碼。測(cè)試程序中有100層解壓縮，在偶數(shù)解壓層有完整性校驗(yàn)。該程序稱為100-layers。

（4）使用完整性校驗(yàn)值生成MD5初始化常數(shù)。計(jì)算出的MD5值通過(guò)函數(shù)printf（）輸出到屏幕，MD5代碼參見(jiàn)http：//people.csail.mit.edu/rivest/Md5.c，程序輸入為中華人民共和國(guó)國(guó)歌歌詞。該程序稱為chksum-md5。

對(duì)于各組實(shí)驗(yàn)、插樁程序，在運(yùn)行時(shí)報(bào)告被校驗(yàn)的內(nèi)存地址范圍與檢測(cè)結(jié)果進(jìn)行比較。為了測(cè)試集群性能，將上述測(cè)試分為若干份輸入集群與單機(jī)器進(jìn)行比較。

3.2 實(shí)驗(yàn)結(jié)果

測(cè)試集單份實(shí)驗(yàn)結(jié)果如表1所示，沒(méi)有發(fā)現(xiàn)任何誤報(bào)。圖2 給出了集群性能測(cè)試結(jié)果，報(bào)告結(jié)果與單份相同。從圖2可以看出，處理時(shí)間大致與份數(shù)成線性關(guān)系，符合預(yù)期。

3.3 精度分析

有重疊完整性校驗(yàn)程序，成功識(shí)別了所有完整性校驗(yàn)。不過(guò)，檢測(cè)出的完整性校驗(yàn)代碼范圍小于實(shí)際。原因有兩點(diǎn)：首先，本文分析的是指令執(zhí)行軌跡，屬于動(dòng)態(tài)分析方法，而動(dòng)態(tài)分析代碼覆蓋率低，不是所有被校驗(yàn)代碼都會(huì)在運(yùn)行時(shí)執(zhí)行。其次，從已執(zhí)行的內(nèi)存地址開(kāi)始分析，本身就會(huì)漏掉一些沒(méi)有執(zhí)行的內(nèi)存地址（其可能會(huì)被完整性校驗(yàn)）。

在100-layers中，所有校驗(yàn)過(guò)程被識(shí)別出，檢測(cè)出的完整性校驗(yàn)都有相同校驗(yàn)范圍。原因是在源代碼中，被校驗(yàn)數(shù)據(jù)在某一層被變形和校驗(yàn)，然后立即傳遞到下一層脫殼。

對(duì)于decrypt-key，也是同樣結(jié)果，完整性校驗(yàn)的關(guān)鍵指令和被校驗(yàn)范圍被準(zhǔn)確識(shí)別。

4 結(jié)語(yǔ)

本文描述了一種基于Spark的軟件完整性校驗(yàn)檢測(cè)框架。對(duì)于單文件檢測(cè)，基于動(dòng)態(tài)分析，使用后向污點(diǎn)分析識(shí)別可執(zhí)行或者用來(lái)計(jì)算可執(zhí)行位置值的內(nèi)存位置，然后使用前向污點(diǎn)分析識(shí)別校驗(yàn)過(guò)程。實(shí)驗(yàn)表明，本文框架可以有效識(shí)別多種完整性校驗(yàn)行為。

本文方法的輸入是指令執(zhí)行軌跡，是一種動(dòng)態(tài)分析方法。動(dòng)態(tài)分析方法優(yōu)勢(shì)在于能夠透明地處理反分析防御，如運(yùn)行時(shí)代碼自修改，但存在代碼覆蓋率低的問(wèn)題，可以通過(guò)多路徑探索技術(shù)解決[21]。第二個(gè)問(wèn)題來(lái)自離線動(dòng)態(tài)分析，大軌跡文件會(huì)帶來(lái)顯著的存儲(chǔ)和處理消耗，可通過(guò)使用軌跡壓縮技術(shù)解決[22]。本文方法雖然可以識(shí)別完整性校驗(yàn)，但不能自動(dòng)轉(zhuǎn)化為一個(gè)直接屏蔽完整性校驗(yàn)的方法。在對(duì)原型工具的測(cè)試中，手工驗(yàn)證了檢測(cè)結(jié)果的正確性。但是，若校驗(yàn)代碼是在不可預(yù)料的內(nèi)存位置動(dòng)態(tài)創(chuàng)建的，則驗(yàn)證識(shí)別會(huì)比較棘手。

本文關(guān)注動(dòng)態(tài)完整性校驗(yàn)，卻沒(méi)有考慮靜態(tài)完整性校驗(yàn)。原則上調(diào)整本文方法處理靜態(tài)完整性校驗(yàn)并不困難，需跟蹤庫(kù)或系統(tǒng)函數(shù)調(diào)用，識(shí)別任何程序訪問(wèn)的文件，然后解析文件結(jié)構(gòu)，識(shí)別讀取文件操作。整合上述邏輯到原型工具將是下一步工作。

參考文獻(xiàn)：

[1] AHMADVAND M，PRETSCHNER A，KELBERT F. A taxonomy of software integrity protection techniques[J]. Advances in Computers， 2019， 112： 413-486.

[2] CAPPAERT J，PRENEEL B，ANCKAERT B，et al. Towards tamper resistant code encryption： practice and experience[C]. Information Security Practice and Experience， 2008： 86-100.

[3] AUCSMITH D. Tamper resistant software： an implementation[C].? Information Hiding， 1996： 317-333.

[4] HORNE B，MATHESON L，SHEEHAN C，et al. Dynamic self-checking techniques for improved tamper resistance[C]. Security and Privacy in Digital Rights Management， 2002： 141-159.

[5] MARTIGNONI L，PALEARI R，BRUSCHI D. Conqueror：tamper- proof code execution on legacy systems[C]. Detection of Intrusions and Malware， and Vulnerability Assessment， 2010： 21-40.

[6] CHANG H，ATALLAH M J. Protecting software code by guards[C]. Security and Privacy in Digital Rights Management，2002：160-175.

[7] GIFFIN J T，CHRISTODORESCU M，KRUGER L. Strengthening software self-checksumming via self-modifying code[C]. Computer Security Applications Conference， 21st Annual， 2005：10-32.

[8] TSANG H C，LEE M C，PUN C M. A robust anti-tamper protection scheme[C]. Availability，Reliability and Security（ARES），2011 Sixth International Conference， 2011： 109-118.

[9] WANG P，KANG S，KIM K. Tamper resistant software through dynamic integrity checking[C]. Proceedings of the 2005 Symposium on Cryptography and Information Security，2005： 25-28.

[10] TAN G，CHEN Y，JAKUBOWSKI M H. Delayed and controlled failures in tamper-resistant software[C]. Information Hiding，2007： 216-231.

[11] AHMADVAND M，HAYRAPETYAN A，BANESCU S，et al. Practical integrity protection with oblivious hashing[C]. Proceedings of the 34th Annual Computer Security Applications Conference，2018： 40-52.

[12] QIU J，YADEGARI B，JOHANNESMEYER B，et al. Identifying and understanding self-checksumming defenses in software[C]. Proceedings of the 5th ACM Conference on Data and Application Security and Privacy，2015： 207-218.

[13] 湯戰(zhàn)勇，郝朝輝，房鼎益，等. 基于進(jìn)程級(jí)虛擬機(jī)的軟件防篡改方法[J]. 華中科技大學(xué)學(xué)報(bào)：自然科學(xué)版，2016 （3）： 13.

[14] 張?zhí)裉?，孫紹華. 基于Spark的云計(jì)算平臺(tái)在實(shí)驗(yàn)室的應(yīng)用與實(shí)現(xiàn)[J]. 軟件導(dǎo)刊，2018，17（4）：191-193.

[15] 蘭云旭，王俊峰，唐鵬. 基于Spark的并行醫(yī)學(xué)圖像處理研究[J].? 四川大學(xué)學(xué)報(bào)：自然科學(xué)版，2017，54（1）：65-70.

[16] GUPTA D，RANI R. Big data framework for zero-day malware detection[J].? Cybernetics and Systems， 2018， 49（2）： 103-121.

[17] CHUPRAT S，ARIFFIN A，SAHIBUDDIN S，et al. Malware forensic analytics framework using big data platform[C]. Proceedings of the Future Technologies Conference， 2018： 261-274.

[18] 王蕾，李豐，李煉，等. 污點(diǎn)分析技術(shù)的原理和實(shí)踐應(yīng)用[J]. 軟件學(xué)報(bào)，2017，28（4）：860-882.

[19] LUK C K，COHN R， MUTH R， et al. Pin： building customized program analysis tools with dynamic instrumentation[J]. ACM Sigplan Notices， 2005， 40（6）： 190-200.

[20] DINABURG A， ROYAL P， SHARIF M， et al. Ether： malware analysis via hardware virtualization extensions[C]. Proceedings of the 15th ACM Conference on Computer and Communications Security， 2008： 51-62.

[21] MOSER A，KRUEGEL C，KIRDA E. Exploring multiple execution paths for malware analysis[C]. Security and Privacy，2007： 231-245.

[22] BHANSALI S，CHEN W K，DE JONG S， et al. Framework for instruction-level tracing and analysis of program executions[C]. Proceedings of the 2nd International Conference on Virtual Execution Environments， 2006： 154-163.

（責(zé)任編輯：何 麗）