程序敏感的模糊測試樣本生成方法

許 樸，舒 輝，于穎超

(信息工程大學 數學工程與先進計算國家重點實驗室，河南 鄭州 450001)

0 引 言

隨著硬件性能的提高，人們對于軟件功能的需求也越來越高。這使得軟件程序更加復雜，公開發現的軟件漏洞也日趨增多[1]。雖然通過人工來檢測軟件漏洞有著不可替代的優勢。但是對于日益復雜的軟件，僅僅依靠人工來進行檢測已經遠遠不夠。其一，人的精力有限。要發現軟件缺陷，首先需要深入了解軟件框架，而目前軟件實現愈加趨于復雜，要理解消化軟件代碼耗時巨大。其二，軟件缺陷種類多樣[2]，人在檢查軟件缺陷時往往難以做到面面俱到。

因此利用自動化的方法檢測軟件漏洞十分必要。在工業界，對于挖掘軟件漏洞比較常見的方法是采用模糊測試，例如Google的OSS-Fuzz項目。模糊測試的英文稱作Fuz-zing，屬于動態執行灰盒測試框架，幾乎不需要對被測試的程序做深入分析，一部分的實現也可以無需程序源碼。這兩點使其應用范圍廣，任何接受輸入的程序都能被用來做測試。然而模糊測試由于缺乏對程序的感知能力，難以高效生成魔數等校驗字段，對初始樣本的依賴程度較高。目前關于模糊測試的研究主要集中在提高樣本生成質量以達到提高代碼覆蓋率的目的。

1 相關工作

傳統Fuzzing通過既定的策略(比特翻轉，數值運算，固定數值填充等)以及一些隨機化(隨機數值填充)的方式來修改輸入樣本，使生成的不同輸入樣本能夠觸發程序不同的執行流程，以提高代碼覆蓋率來觸發軟件漏洞。比較有代表性的Fuzzing工具有AFL[3]，honggfuzz，libFuz-zer[4]等。這些工具采用較為簡單的灰盒方式，僅依靠代碼覆蓋率信息作為反饋，以此進行種子選擇來輔助樣本生成。但是它們忽略程序代碼本身以及輸入的數據流信息，并不能有效產生高質量輸入，只能依賴于優秀的初始種子樣本以及不斷的嘗試次數。而且AFL為了運行效率，其搜集的覆蓋率信息犧牲了一定的精度[5]，這也導致其無法篩選出某些優質樣本。因此，目前對于模糊測試的研究主要在于采用一些輔助分析的手段，來提高生成樣本質量，從而提高代碼覆蓋率。

基于樣本生成而非樣本修改的方式，文獻[6]實現了以skyfire命名的工具。該工具通過爬蟲收集互聯網上目標格式的輸入樣本文件，然后通過基于ANTLR的開源語法解析器對這些文本進行解析，將這些文件解析成語法樹格式，從而獲得概率語法推導公式以及語法樹中每個詞法單元對應的具體值。獲得這些信息之后，其通過概率語法推導公式導出一棵新的語法樹，然后在相應詞法單元中選取收集到的不同數據填入，最終生成新的樣本。該方法能夠在保持生成樣本多樣性的同時，保證輸入的語法格式，使其通過程序的結構化校驗，從而能夠通過程序的語法校驗。但是該方法適用性較窄，首先其需要有巨大的樣本量，其次，需要針對程序所處理樣本的格式編寫語法解析器。

基于符號執行[7]手段，將程序運行中的數據進行符號化。這樣在執行到分支路徑中就能通過求解這些表達式得到不同的值，從而執行不同路徑。文獻[8]基于angr[9]，開發了一款名為Drill的工具，該工具基于具體符號執行，收集執行過程中的變量約束，利用符號求解器，求解出不同的執行路徑所需要的約束值，從而生成對應該執行路徑樣本。文獻[10]實現的Qsym，其通過直接作用于x86匯編指令進行具體符號執行，而非KLEE[11]和angr基于中間語言形式，提高符號執行速度；采用具體執行，只求解單個執行路徑中的分支，提高符號執行可用性。雖然符號執行概念很早就提出來，但是其面臨幾個重要的難題，約束其應用范圍。首先是與其它外部環境代碼交互的問題，雖然能夠通過模擬執行，將程序代碼本身進行符號化執行，但是程序的運行還會涉及到與其它庫，系統調用交互等問題，而符號執行無法對系統調用代碼進行模擬。其次，由于符號執行可以執行不同的分支，每個分支都需要維護執行時的相關符號表達式信息，同時分支狀態數隨著分支數量呈幾何級數增長，這些海量的分支不僅考驗計算能力，也考驗存儲能力。最后，為了確認是否能夠執行某條分支，需要求解符號表達式。然而表達式求解屬于NP問題，因此并不能確保能夠求解出需要的值。這些問題都限制了符號執行的應用。

通過對程序代碼本身的分析，獲得程序的受控輸入點以及關鍵脆弱點。文獻[12]通過先對程序進行詞法語法分析，以此搜集程序的受控點和脆弱點，在此基礎上再來進行有指導性的模糊測試，提高測試效率。文獻[13]設計了一種針對路由器程序的漏洞挖掘方法，其通過靜態語義分析出脆弱路徑，然后再利用動態污點分析獲取能夠影響這些路徑的關鍵輸入字段，在后續模糊測試過程中對這部分字段進行重點變異。然而這種方法需要對被測程序進行一定程度的建模，不同類型的程序模型存在差別，因此通用性不高。

本文提出的方法是基于細粒度污點分析，來獲取輸入中影響程序執行的部分來進行針對性樣本修改。相比于符號執行，其開銷較小，執行效率高，適用程序廣泛。文獻[14]實現的VUzzer，其包含的一個模塊也是基于污點分析的，但是其將污點分析所獲得的所有信息一次性針對樣本進行修改，如果其中某個修改破壞了前置校驗，則無法執行到后面的校驗，錯過部分執行路徑，并且也未考慮通過不斷反饋形成更加優質的樣本。本文則為污點分析中獲取的每個不同位置的不同比較各生成一個樣本，然后再將這些生成樣本作為反饋輸入，進行下一輪的樣本生成工作，減少不同字段校驗間的干擾。同時VUzzer使用的污點分析引擎dtracker是基于libdft的實現，通過分析其代碼，發現其同樣不支持浮點寄存器。然而在現實代碼中，memcpy、memmove等內存拷貝調用比較常見，而這些函數在glibc的實現中都使用浮點寄存器來加快執行速度，不支持浮點寄存器十分影響污點分析的精度。本文為了解決這個問題，實現了一款輕量級細粒度污點分析模塊，專注內存轉移類指令的污點傳播，支持浮點寄存器。雖然VUzzer也是基于細粒度污點的分析，但是其在考慮生成樣本時未考慮到大小端轉換問題，本文通過分析影子內存中污點的來源位置自動識別該字段是否存在字節轉序。另一方面VUzzer其通過識別error handling函數，來為路徑權重賦值，挑選執行路徑權重和高的種子來進行樣本修改。而本文通過利用污點分析時獲得輸入數據的使用頻度信息，同時考慮控制流信息和數據流信息來進行種子選擇。

2 基于細粒度污點分析的樣本生成

基于路徑覆蓋反饋的模糊測試工具，通過覆蓋率信息來指導樣本修改以及種子選擇。但是其面臨一個重要的問題，即目標樣本需要如何修改才能觸發不同路徑。傳統的模糊測試工具因此十分依賴于初始種子樣本集合，好的種子樣本集合能夠覆蓋被測程序中大多數處理輸入的正常路徑，在此基礎上，樣本生成只需依靠比特翻轉，數值運算等修改策略來觸及錯誤處理分支。

在現實測試中樣本集合的選擇主要考慮目標程序接受的輸入格式，根據格式選擇初始樣本集。然而這種測試方式卻忽視了程序本身的實現代碼。實際代碼中可能會支持處理其它格式輸入樣本，也可能實現一些自定義的格式解析方式。單純的根據經驗選擇的方法會錯過一些測試點。而且某些冷門的數據格式也并不容易收集全面。如果能夠通過對程序進行分析，依據程序處理輸入的方式來針對性進行樣本生成，實現對被程序的敏感，既能減少人工的干預，也能夠生成更符合程序需要的輸入。

基于以上思路，本文實現的方案是通過污點分析取得的輸入的數據流信息，分析出輸入中能夠直接影響程序執行路徑的關鍵數據。對樣本中這些數據進行針對性修改，生成觸發新路徑的樣本。同時，在生成樣本中按照對輸入使用的頻度，挑選出頻度更高的輸入樣本。通過多次反饋執行，使得生成的樣本通過程序的部分校驗，觸及測試程序深層次邏輯，達到對程序敏感的目的。以圖1為例，說明程序對輸入文件進行的常見校驗。

圖1 格式解析型程序示例

首先，程序對文件進行魔數校驗(magic check)，該校驗是檢驗輸入文件固定位置是否是某個固定值，初步判斷輸入文件所屬的文件格式類型。然后，通過對輸入文件中的數據部分使用哈希算法算出一個哈希值，與文件中存儲的原始哈希值進行比較，來判斷輸入是否受損。當這些校驗通過后，程序就判定輸入文件符合目標格式要求，開始處理目標文件，根據文件當中的元數據進行相應數據處理。在示例代碼中，由于沒有對長度字段進行正確的校驗，由此觸發了內存越界操作。傳統的模糊測試方法為了通過這些校驗，需要在正確的校驗位置進行修改，即使湊巧找到了需要修改的位置，根據比較字節的長度，最壞需要28*bytes嘗試次數。對于圖1中5個字節的魔數，即使每秒能嘗試1000次，最壞情況下需要約12 726天(28*5/24*60*60*1000)。而像示例中對數據長度大小的比較，雖然傳統模糊測試采用比特翻轉的方法能夠很容易觸發不同分支，但是漏洞的觸發依賴于取得的最值，通過覆蓋率反饋的方式，無法將取得最值的情況單獨區分出來。而針對文件格式解析型的程序，對魔數和元數據使用時，幾乎不會進行數值運算，因此，對于這部分的數據分析完全可以依賴于污點分析而非借助開銷極大的符號執行。

2.1 字節粒度污點的引入以及使用

2.1.1 通過監控系統調用引入source點

算法1：系統調用監控的偽代碼

輸入：二進制程序，程序的輸入文件

輸出：插樁后二進制程序

(1)inspectfds=?//被監視文件的打開句柄列表

(2)proceduresys_open_hook(path, flag, ret)//打開文件監控

(3)ifpath == inspect_paththen

(4) inspectfds ∪= ret

(5) off[fd] = 0

(6)proceduresys_read_hook(fd, buf, count, ret)//讀取文件監控

(7)iffd in inspectfdsthen

(8)fori = 1→ |ret|do

(9) shadow_mem[buf+i]=mktag(fd, off[fd]+i)

(10) off[fd] += ret

(11)proceduresys_lseek_hook(fd, offset, whence, ret)//文件句柄偏移的監控

(12)iffd in inspectfdsthen

(13) off[fd] = ret

(14)proceduresys_close_hook(fd, ret)//關閉監控

(15)iffd in inspectfdsthen

(16) inspectfds = fd

(17)apply_hooks(program)

程序讀取輸入文件前，需要調用sys_open系統調用進行打開操作。因此，對sys_open進行hook，然后通過pathname參數來判斷是否為程序讀入的輸入文件，如果是的話，則記錄返回句柄fd。

程序成功獲取句柄后，可以采用兩種方式將輸入文件中的數據載入內存當中。一種是通過sys_read調用直接讀取數據，另一種則是通過sys_map調用創建一塊對文件映射的內存。通過監控這兩個系統調用，如果句柄參數是sys_open所返回的，則表明讀入的數據來源于輸入文件當中，此時則創建的污點數據，并且將其存放于對應影子內存當中。

由于本文實現字節粒度的污點傳播，污點信息將會存儲污點在文件中的偏移，這就需要維護文件當前指針，才能獲取調用sys_read時讀取的污點數據在輸入文件中的起始位置。而維護文件起始指針，則需要對sys_seek進行監控。當讀入污點時，會對每個污點數據創建一個數據結構，主要包括存儲污點的來源文件，污點在文件當中的位置。然后將該污點結構的指針存入讀入位置的影子內存中。最后，當調用sys_close時，則需要刪除對應的監控句柄，避免引入錯誤的污點數據。

2.1.2 基于數據比較的sink點定位

算法2：sink點操作的偽代碼

輸入：污點信息

輸出：影響程序執行的關鍵污點輸入

(1)procedurecmp_hook(rip, dst_addr, src_addr, size)

(2)if!eflag_used_by_jmp(rip)then//判斷比較指令影響的eflags寄存器是否被條件跳轉指令使用

(3) return

(4)ifshadow_mem[dst_addr]then//判斷源操作數是否涉及污點

(5) fileoff = shadow_mem[dst_addr].off

(6) cmp_info ∪= {rip, fileoff, mem[src_addr], size}

(7)ifshadow_mem[src_addr]then//判斷目的操作數是否涉及污點

(8) fileoff = shadow_mem[src_addr].off

(9) cmp_info ∪= {rip, fileoff, mem[dst_addr], size}

本文實現工具的目的就是為了減少傳統模糊測試對初始數據集的依賴，利用程序執行時的信息進行指導如何對樣本進行修改。傳統模糊測試專注于提高程序覆蓋率，因此sink點的位置是能夠影響程序執行的指令，同時該指令也使用污點數據。在x86指令集中能夠影響程序執行分支跳轉的為eflags寄存器，雖然能夠影響eflags寄存器的指令并不唯一，但是程序執行過程中，多數是使用比較指令cmp來改變eflags寄存器的值。基于以上思路，本文通過監控cmp指令，來識別sink點。如果此時cmp當中的某一操作數包含污點數據，則表明該位置為有效sink點。

當執行到sink點時會做進一步檢驗，首先是對存儲污點中字節序的判斷，部分格式采用大端進行數據存儲，而x86處理器則是小端處理器，通過對參與比較的每個字節污點來源位置來判斷數據的大小端，如果順序反序，則識別其大小端轉序。其次，對污點實際存儲的數據和文件中來源數據進行比較，確保污點數據在傳播過程中沒有經過運算使得與輸入值不符，同時避免污點傳播中過污染的問題。

當順利通過校驗后，將sink點相關信息進行記錄，主要包括<指令地址，污點在文件中的偏移，與污點數據進行比較的數值，操作數大小>。這些記錄的信息指導樣本生成，同時整個執行流中記錄的這些信息則作為種子優先級排序時的依據。具體將在2.3節中敘述。

2.2 字節粒度污點的傳播

算法3：污點傳播的偽代碼

輸入：二進制程序，樣本文件

輸出：被污染的影子內存及影子寄存器

(1)proceduremov_rr_hook(dst_reg, src_reg, size)//寄存器到寄存器類型的污點傳播

(2)fori = 1→ |size|do

(3) shadow_reg[dst_reg][i]=shadow_reg[src_reg][i]

(4)proceduremov_mr_hook(dst_addr, src_reg, size)//寄存器到內存類型的污點傳播

(5)fori = 1→ |size|do

(6) shadow_mem[dst_addr+i]=shadow_reg[src_reg][i]

(7)proceduremov_rm_hook(dst_reg, src_addr, size)//內存到寄存器類型的污點傳播

(8)fori = 1→ |size|do

(9) shadow_ reg[dst_reg][i]=shaow_mem[src_addr+i]

(10)proceduremov_ri_hook(dst_reg, size)//立即數到寄存器數據轉移，清除污點

(11)fori = 1→ |size|do

(12) shadow_reg[dst_reg][i]=NULL

(13)proceduremov_mi_hook(dst_addr, size)//立即數到內存數據轉移，清除污點

(14)fori = 1→ |size|do

(15) shadow_mem[dst_addr+i]=NULL

本文主要監控對象為直接使用的污點數據，并不關心執行過程中參與運算的那部分污點。因此，污點傳播的分析主要對涉及內存存取的相關指令進行監控，在x86的體系架構中，主要是mov類型指令，以及push、pop類型指令。mov指令主要是參與一般意義上的內存和寄存器以及寄存器和寄存器間的數據傳輸，而push、pop則是棧變量和寄存器間的傳輸。通過判斷原操作數中是否存在污點，如果存在的話，則將污點指針考入到目的操作數對應的影子內存中，否則清除污點。這樣的設計能夠有效減少污點傳播的復雜度，提高單次污點分析的執行效率。還有余下的一小部分在寄存器內變換字節位置的指令(例如bswap、shl、ror等)也需要模擬，以保證污點來源位置的準確性。

由于模糊測試盡可能要求程序單次執行速度，因此輸入樣本大小較小，最終污點傳播的范圍也有限。本文采用哈希數組的方式實現影子內存而非libdft中類似頁目錄頁表的實現方式以減少實現復雜度。同時，為每個寄存器分配寄存器長度大小的指針數組作為影子寄存器。目前的實現并不支持多線程程序，需要支持的話則需要為每個線程分配一套影子寄存器。

2.3 樣本生成及優先級排序

算法4：污點傳播的偽代碼

輸入：sink點輸出信息

輸出：新生成樣本，排序完成待測試樣本隊列

(1)proceduregen_new_input(input, cmp_info)

(2) fd = fopen(input, ‘rb’)

(3) inbuf = fd.read()

(4) fd.close()

(5)for{rip, fileoff, value, size} in cmp_infodo//遍歷記錄的污點信息

(6)ifvalue in values[rip]then//做過同樣內容的修改，不生成新樣本

(7) continue

(8) values[rip] ∪= value

(9) outbuf = inbuf

(10) outbuf[fileoff] = value

(11) is_new_addr = 0

(12)ifnot{rip, value} in changesthen//判斷是否全新的校驗信息

(13) changes ∪= {rip, value}

(14) is_new_addr = 1

(15) output = ‘output’ + str(rip) + str(value)

(16) fd = fopen(output, ‘wb’)

(17) fd.write(outbuf)

(18) fd.close()

(19) priority=is_new_addr*(2**10)+len(cmp_info)//計算優先級

(20) queued_input ∪= {output, priority}//加入新樣本隊列

樣本生成則依據sink點時獲取的<指令地址，污點在文件中的偏移，與污點數據進行比較的數值，操作數大小>四元組信息，來對污點分析的輸入樣本進行修改。首先<指令地址，與污點數據進行比較的數值>作為唯一性標簽，即如果此前修改過相同的二元組，則表示已經使用過該種類型的修改，放棄此次修改。采取這種策略的原因是，在程序相同位置做了相同的檢驗操作，再次做相同的修改很大程度上也會得到相同的執行路徑。

如果不存在，則根據<污點在文件中的偏移，與污點數據進行比較的數值，操作數大小>三元組信息對文件進行修改。具體實現就是將輸入文件中相應的偏移修改為與污點數據進行比較的數值。生成新的樣本文件。同時將<指令地址，與污點數據進行比較的數值>記錄下來，避免生成重復文件。

生成的文件將按照優先級排序加入下一輪污點分析的待測樣本中。傳統的模糊測試工具僅僅考慮是否產生新的覆蓋率來作為樣本隊列的參考，該方案僅僅考慮了程序控制流信息對樣本進行篩選，忽略了數據流相關信息，也無法對樣本的優先級進行排序。本文依靠污點分析獲取的信息來對樣本優先級進行考量。首先，觀察指導生成樣本修改的指令地址是否首次出現，如果是則說明新生成的樣本很有可能觸碰到新的路徑，將其初始優先級設置為1024，否則初始為0。其次統計樣本參與的不同位置比較的總次數，使用輸入中元數據次數越多，說明對輸入處理的越深入，由于無法預先知道生成后樣本的這部分信息，因此使用其父樣本中污點分析的信息來進行代替。最終優先級公式為priority=is_new_addr<<10+compare_counts，按照優先級大小插入待測試隊列。這樣在有新路徑可能性的情況下就會優先探索新路徑，同時考慮到經過比較次數較多的樣本，說明其數據經過了更多的校驗，其觸及程序深層次處理邏輯的概率越大，優先對這部分樣本進行下一輪測試。

3 系統實現及實驗分析

3.1 系統實現

基于上述研究，本文設計并實現了taint_fuzz混合模糊測試工具，其框架如圖2所示。

圖2 混合模糊測試工具taint_fuzz框架

污點分析模塊基于intel pin開發，樣本生成和調度模塊通過編寫python腳本完成，混合執行中可選的基于路徑反饋的模糊測試工具采用AFL。系統運行過程中，taint_fuzz通過污點分析取得的信息進行樣本生成，AFL則根據路徑反饋進行樣本生成，因此需要編譯生成兩個可執行被測程序。一個是原始程序，被taint_fuzz使用進行污點分析，另外一個是基于源碼插樁以獲取路徑覆蓋的程序。通過共享taint_fuzz和AFL生成的樣本以達到混合執行的目的，taint_fuzz通過污點分析生成符合元數據校驗的樣本，AFL則通過比特翻轉等手段探測分支處理路徑、觸發漏洞。樣本調度模塊僅服務于taint_fuzz，這是考慮到基于覆蓋率反饋的模糊測試工具有其自身的樣本挑選規則。最后需要說明的是，本文實現的混合執行框架無需程序源代碼也能進行測試，taint_fuzz通過pin進行插樁，直接作用于二進制程序；而AFL也有基于qemu以及intel PT技術的擴展，可以實現無需源碼的二進制插樁。

如圖3所示，taint_fuzz通過python編寫的腳本taint-fuzz.py進行統一調度，首先，調用pin以及相應編寫的taint-fuzz.so動態插樁庫，進行污點分析，再根據污點分析獲得的結果來進行樣本生成，生成文件名中id代表樣本編號，origid代表父樣本id，off代表修改的位置，str則代表修改的值，該值是字符串化的十六進制數。然后從樣本池中再挑選樣本進行下一輪污點分析。

圖3 taint_fuzz運行展示

3.2 實 驗

實驗環境采用處理器為i7-8550U，運行內存為8 GB，系統為ubuntu18 64位的虛擬機。為了驗證本方法的有效性，通過與VUzzer64，AFL進行比較，對audiofile、exiv2、libav這3個現實世界中的應用程序以及應用庫進行模糊測試，用來對比生成樣本的代碼覆蓋率，以及挖掘到的有效漏洞數。其中VUzzer64是VUzzer的升級版本，主要提供64位程序的支持。實驗中的代碼通過gcc 7.4.0編譯，代碼覆蓋率獲取通過編譯時添加-fprofile-arcs-ftest-co-verage參數，使用gcov，lcov工具獲取。

圖4～圖6是taint_fuzz，VUzzer64，AFL分別對audiofile、exiv2、libav經過10小時的模糊測試所得到的覆蓋率結果，每30分獲取一次覆蓋率信息。需要說明的是taint_fuzz的初始樣本為1000字節的a字符串，僅用來使被測程序能夠正常執行，以獲得污點分析結果，即taint_fuzz的初始樣本完全沒有任何樣本格式預置信息。而為了避免AFL在魔數檢測部分空轉，測試中另外為AFL和VUzzer64提供了一個符合程序解析要求的初始樣本。因此可以看到，在測試的初始的階段，即AFL和VUzzer64的初始樣本池中的樣本代碼覆蓋率要優于taint_fuzz，這體現在了覆蓋行數的起始點。而且VUzzer64在執行之前還需要通過其編寫的ida腳本對被測程序進行一定的靜態分析。但是經過一段時間過后，AFL難以嘗試出其它魔數以及元數據的值；VUzzer64的污點分析結果沒有taint_fuzz的充分，也無法有效利用所獲得的污點數據，最終代碼覆蓋率被taint_fuzz超越。雖然VUzzer64同時通過靜態和動態手段獲取了更多關于程序信息，但在初始樣本比較簡單的情況下，其樣本生成效果甚至不如AFL。

圖4 audiofile測試的覆蓋率

圖5 exiv2測試的覆蓋率

圖6 libav測試的覆蓋率

在libav的測試中，VUzzer64主程序沒有獲得污點分析信息，認為執行出現錯誤，拒絕繼續執行。因此測試信息不包含VUzzer64。經過人工分析發現，由于VUzzer64的污點分析模塊沒有支持浮點指令集，而libav中自身實現了一套文件緩存機制，其通過事先讀取完整輸入樣本，再次讀取時無需系統調用，直接調用memcpy讀取緩存中內容即可，造成了VUzzer64無法獲取到污點信息。這也直接印證了前文所述，在memcpy、memmove等調用頻繁的程序中，缺少對浮點寄存器的支持會對污點分析結果造成巨大影響。

在表1中列舉了挖掘到的漏洞以及漏洞的類型。其中heap overflow說明堆訪問越界、null reference說明引用了空指針、infinite loop說明程序執行了死循環。可以看到，即使沒有初始樣本，taint_fuzz也能夠生成有效樣本觸發漏洞，其挖掘到的漏洞數明顯超過了AFL和VUzzer64。taint_fuzz專注污點分析構造有效樣本，然后利用混合模糊測試框架中的傳統模糊測試工具觸發漏洞；而VUzzer64僅關注樣本路徑的挖掘，卻沒有采取其它手段進行漏洞的觸發，最終也沒有觸發出任何漏洞。

同時在本次測試中，挖掘到了多個首次發現的漏洞，對此申請了CVE編號，獲得了CVE-2019-13147、CVE-2019-14368、CVE-2019-14369、CVE-2019-14371、CVE-2019-14372。

4 結束語

本文提出了一種自適應程序的模糊測試樣本生成方法。與傳統模糊測試相比，taint_fuzz能夠針對性的對樣本進行修改生成而非各種嘗試修改。與同樣采用字節粒度污點分析手段的工具相比，其污點分析結果更為精確，能夠識別大小端轉換，污點信息的利用效果也更好。同時本文提出了一種基于污點信息使用頻度的樣本優先級排序方法，挑選出更有可能觸發新路徑以及輸入樣本數據使用次數多的樣本，同時兼顧了控制流和數據流信息。目前本方法只能針對沒有經過數值運算的數據直接修改，后面可以考慮對挖掘到的這些關鍵字段位置進行嘗試性修改。同時通過污點分析挖掘觸發漏洞可能性大的字段，例如關鍵調用參數，針對這些字段進行導向性漏洞挖掘。