基于模糊測試的activex控件 漏洞挖掘研究——碩士論文

1、<p><b>　　碩士學位論文</b></p><p>　　基于模糊測試的ActiveX控件</p><p><b>　　漏洞挖掘研究 </b></p><p>　　專 業(yè) 名 稱： 軟 件 工 程 </p><p>　　研究生姓名： </p>

2、;<p>　　導 師 姓 名： </p><p>　　校外導師姓名： </p><p><b>　　摘要</b></p><p><b>　　關鍵字：</b></p><p><b>　　ABSTRACT</b>

3、;</p><p>　　Key Words: </p><p><b>　　目 錄</b></p><p><b>　　摘要I</b></p><p>　　ABSTRACT II</p><p><b>　　第一章 緒論1</b></p&g

4、t;<p>　　1.1 研究背景1</p><p>　　1.2 相關研究現(xiàn)狀1</p><p>　　1.2.1 ActiveX控件技術的發(fā)展1</p><p>　　1.2.2 模糊測試技術的研究現(xiàn)狀2</p><p>　　1.2.3 緩沖區(qū)溢出漏洞研究現(xiàn)狀2</p><p>　　1.3 研究目的

5、和意義3</p><p>　　1.4 主要工作與創(chuàng)新點3</p><p>　　1.5 本文的章節(jié)安排4</p><p>　　第二章ActiveX控件安全性分析與模糊測試技術5</p><p>　　2.1 ActiveX控件原理分析5</p><p>　　2.1.1 ActiveX控件加載原理5</p&

6、gt;<p>　　2.1.2 ActiveX控件的加載條件5</p><p>　　2.2 ActiveX控件漏洞形成分析6</p><p>　　2.2.1 軟件漏洞的定義6</p><p>　　2.2.2 軟件漏洞的原理與分類6</p><p>　　2.2.3 ActiveX控件的漏洞的特點與形成原因10</p&

7、gt;<p>　　2.3 模糊測試技術12</p><p>　　2.3.1 傳統(tǒng)的漏洞挖掘方法12</p><p>　　2.3.2 模糊測試的定義13</p><p>　　2.3.3 模糊測試技術的原理13</p><p>　　2.3.4 模糊測試的優(yōu)點和缺點14</p><p>　　2.3.5

8、 進化模糊測試思想15</p><p>　　2.4 本章小結16</p><p>　　第三章 漏洞分析相關技術17</p><p>　　3.1 調(diào)試器原理17</p><p>　　3.2關鍵調(diào)試技術分析18</p><p>　　3.2.1 調(diào)試技術基礎18</p><p>　　3.2

9、.2 調(diào)試相關的API20</p><p>　　3.3 自動化動態(tài)分析技術20</p><p>　　3.4 靜態(tài)分析技術22</p><p>　　3.4.1 IDA Pro及其插件開發(fā)22</p><p>　　3.4.2 利用IDA Pro實現(xiàn)靜態(tài)代碼分析22</p><p>　　3.5 本章小結23<

10、;/p><p>　　第四章 ActiveX控件漏洞挖掘分析系統(tǒng)24</p><p>　　4.1 系統(tǒng)總體設計24</p><p>　　4.2 漏洞挖掘模塊24</p><p>　　4.2.1 ActiveX控件分析子模塊25</p><p>　　4.2.2啟發(fā)式靜態(tài)分析子模塊28</p><p

11、>　　4.2.3二進制代碼覆蓋率分析子模塊29</p><p>　　4.2.4 測試數(shù)據(jù)生成子模塊31</p><p>　　4.2.5 模糊測試執(zhí)行子模塊32</p><p>　　4.3 漏洞分析模塊32</p><p>　　4.3.1 調(diào)試器子模塊33</p><p>　　4.3.2 反匯編子模塊3

12、5</p><p>　　4.3.3 溢出檢測與定位子模塊36</p><p>　　4.3.4 單步跟蹤子模塊41</p><p>　　4.3.5 漏洞代碼分析子模塊43</p><p>　　4.5 本章小結43</p><p>　　第五章 ActiveX控件漏洞挖掘分析系統(tǒng)44</p><

13、p>　　實驗驗證及結果分析44</p><p>　　5.1 實驗驗證44</p><p>　　5.1.1 實驗環(huán)境44</p><p>　　5.1.2 存在漏洞的控件44</p><p>　　5.2 漏洞分析44</p><p>　　5.2.1 SetList（棧溢出漏洞）44</p>

14、<p>　　5.2.2 SetLogInfo2（堆溢出漏洞）48</p><p>　　5.3 漏洞自動挖掘系統(tǒng)的優(yōu)缺點52</p><p>　　5.3.1 系統(tǒng)優(yōu)點52</p><p>　　5.3.2系統(tǒng)缺點52</p><p>　　5.4本章小結53</p><p>　　第六章 總結與展望54&

15、lt;/p><p>　　6.1 本文工作總結54</p><p>　　6.2未來研究展望54</p><p><b>　　致謝55</b></p><p><b>　　參考文獻56</b></p><p><b>　　第一章 緒論</b></p

16、><p><b>　　1.1 研究背景</b></p><p>　　自從萬維網(wǎng)誕生以來，針對瀏覽器的攻擊就愈演愈烈，一刻也不曾停歇過。瀏覽器作為廣大網(wǎng)民接觸網(wǎng)絡的主要工具，是網(wǎng)民踏入互聯(lián)網(wǎng)世界的主要入口之一。一旦這個入口受到惡意攻擊，將有大量電腦淪為黑客的“肉雞”，輕則電腦運行緩慢、不斷彈出廣告頁面，重則帳號、金錢被盜，重要資料失竊等等。</p><p

17、>　　隨著軟件工程理論和軟件工業(yè)的發(fā)展，愈來愈多的軟件漏洞被發(fā)現(xiàn)，軟件安全問題日益嚴重。由于利益的關系，越來越多的黑客將注意力轉移到了瀏覽器軟件領域，致使不斷出現(xiàn)瀏覽器的安全漏洞。作為Windows自帶的瀏覽器，IE到目前為止依然占有超過50%的市場份額。這一數(shù)字使得大量黑客在不斷尋找IE瀏覽器的漏洞，而隨著IE的諸多新版本推出，尋找并利用新漏洞的難度也越來越大。</p><p>　　作為IE瀏覽器唯一支持

18、的插件形式，ActiveX控件的安全性一直受到很大的關注。由于ActiveX控件一般會帶有自身的類型庫信息，而類型庫中包含了控件所能提供的所有方法和屬性，以及它們的參數(shù)信息，因此這些方法和屬性成為了優(yōu)良的模糊測試的對象。黑客借助于Comraider、Axman等工具可以輕易發(fā)現(xiàn)ActiveX控件中存在的漏洞，從而利用這些漏洞達到破壞、竊取信息以及非法牟利的目的。</p><p>　　經(jīng)歷了2007、2008年Ac

19、tiveX控件漏洞出現(xiàn)高峰之后，各個廠商都開始注重ActvieX控件的安全問題，由于沒有判斷輸入?yún)?shù)長度而導致的緩沖區(qū)溢出漏洞也大大減少。但是，如Comraider這種半自動化工具已越來越難以滿足漏洞挖掘的需要，而且，對于一些隱藏的漏洞也無能為力。</p><p>　　1.2 相關研究現(xiàn)狀</p><p>　　1.2.1 ActiveX控件技術的發(fā)展</p><p>

20、;　　ActiveX是微軟公司1996年提出的基于COM組件和OLE技術的一種通用的開放程序接口，使用該技術開發(fā)的ActiveX控件可以直接集成到IE瀏覽器或其它第三方程序中[1]。</p><p>　　由于ActiveX控件可以方便地擴展瀏覽器功能，因此許多軟件廠商都喜歡開發(fā)自己的ActiveX控件。例如，各大網(wǎng)銀為了保證自己的登錄和交易安全，都會讓用戶安裝自己的ActiveX控件登錄；一些電子商務網(wǎng)站，如淘寶

21、，也會建議用戶安裝登錄安全控件。此外，網(wǎng)絡視頻軟件、在線殺毒軟件等也都會安裝自己的ActiveX控件。</p><p>　　這些控件一旦出現(xiàn)安全問題，黑客便可以構造惡意頁面，誘使用戶訪問，而用戶一旦訪問，黑客就可以輕易植入木馬和病毒，盜取用戶銀行賬戶，對企業(yè)和個人造成重大損失。</p><p>　　1.2.2 模糊測試技術的研究現(xiàn)狀</p><p>　　模糊測試的思

22、想最早產(chǎn)生于1989年美國威斯康星大學的一個研究計劃，Barton Miller教授（被成為模糊測試之父）最初是用來測試UNIX應用程序的健壯性[2]。</p><p>　　1999年，芬蘭Oulu大學開始研發(fā)基于Fuzzing的網(wǎng)絡協(xié)議測試工具PROTOS，并于2002年發(fā)布了用于SNMP測試的版本。PROTOS綜合了黑盒測試和白盒測試的特點，是模糊測試發(fā)展過程中的一個里程碑[3]。</p>&l

23、t;p>　　2002年，Dave Aitel發(fā)布了一個開放源代碼的模糊測試工具SPIKE5，它使用了基于塊的模糊處理器，用于測試基于網(wǎng)絡的應用程序。作為第一個可以實現(xiàn)自定制的模糊測試器框架，SPIKE的發(fā)布標志著模糊測試一個新的里程碑[4]。</p><p>　　2004年，F(xiàn)ile Fuzzing開始出現(xiàn)。Mu Dynamics(原Mu Security)公司開始開發(fā)一種硬件模糊裝置，其目的是讓網(wǎng)絡中傳輸

24、的協(xié)議數(shù)據(jù)發(fā)生變異。這個商業(yè)產(chǎn)品供應商的出現(xiàn)，恰好吻合當前人們關注Fuzzing的潮流[3]。</p><p>　　同年，兩個類似SPIKE的基于塊的Fuzzer工具發(fā)布：Peach和smudge。這兩個工具都是使用python開發(fā)，從而提供了易于使用的快速開發(fā)框架。Peach是近年來較受外界關注的模糊測試框架，適用于多個平臺。Peach要先對測試的協(xié)議或文件格式進行建模，并用XML語言描述出這種數(shù)據(jù)模型，然后數(shù)

25、據(jù)生成引擎通過解析XML文件來構造測試數(shù)據(jù)集[5]。</p><p>　　2006年，ActiveX控件的Fuzzing開始流行，David Zimmer發(fā)布了COMRaider，H.D.Morre發(fā)布了AxMan16。ActiveX控件由于其中接口、函數(shù)原型的公開性，是一種優(yōu)秀的模糊測試目標，允許對其實施自動化的智能測試。這使得ActiveX控件漏洞的挖掘一時間風靡整個黑客界，不斷會爆出某些軟件的0day漏洞。

26、比如2007年底迅雷5的PPLAYER.DLL控件中溢出漏洞；2008年初的聯(lián)眾GLChat.ocx 控件溢出漏洞；2009年的暴風影音mps.dll控件遠程棧溢出漏洞；2011年的QQ旋風中QQIEHelper.dll控件的遠程棧溢出漏洞；2011年的淘寶阿里旺旺中imageMan.dll控件的遠程棧溢出漏洞等等。</p><p>　　國外對模糊測試的研究較早也較深，有多款成熟的模糊測試框架推出，相對于此，國內(nèi)

27、對模糊測試的研究起步較晚，尚未出現(xiàn)成熟的測試框架。文獻[9]介紹了使用模糊測試挖掘MP3播放軟件中的漏洞，文獻[10]介紹了使用模糊測試挖掘Word軟件中的漏洞，文獻[11]介紹了使用模糊測試挖掘PNG格式解析軟件的漏洞，以上三種都屬于文件Fuzzing的范疇，而文獻[12]介紹了使用模糊測試挖掘TFTP中的漏洞，這是種網(wǎng)絡協(xié)議的模糊測試。</p><p>　　1.2.3 緩沖區(qū)溢出漏洞研究現(xiàn)狀</p>

28、;<p>　　緩沖區(qū)溢出攻擊起源于1996年的一篇文章 “Smashing The Stack For Fun And Profit”[14]，這篇文章清楚地闡述了緩沖區(qū)溢出攻擊的原理。這使得緩沖區(qū)溢出攻擊不斷被世人所了解。1998年來自“Cult of the Dead cow”的Dildog詳細介紹了如何利用Windows的溢出[15]，這篇文章的最大貢獻在于提出了利用棧指針的方法來完成跳轉，避免了因進程、線程的不同造

29、成的棧位置不固定。1999年，Dark Spyrit提出使用系統(tǒng)核心DLL中的Jmp ESP指令完成跳轉[16]。同年，w00w00安全小組的Matt Conover寫了基于堆的緩沖區(qū)溢出的專著[17]，從而使人們意識到堆溢出的危害性。</p><p>　　與此同時，緩沖區(qū)溢出保護技術也在不斷發(fā)展。</p><p>　　2000年，Arash Baratloo和Tzi-cker Chiue

30、h等實現(xiàn)的StackShield原型系統(tǒng)通過保留返回地址的副本來檢測溢出的發(fā)生[18]。同年，Hiroaki Etoh和Kunikazu Yoda提出Etoh和Yoda技術，使用隨機數(shù)保護和棧中的數(shù)組重定位技術來防止對局部變量的溢出[19]。2002年12月，Chew和Song對棧的基地址、系統(tǒng)調(diào)用表和庫函數(shù)入口指針進行了隨機化，并達到了破壞溢出利用可靠性的目的[20]。2003年5月，Xu,Kalbarczyk和lyer提出了透明實時

31、隨機化技術，對Linux的?；贰⒍鸦芬约癎OT進行了隨機化[21]。</p><p>　　Windows也從XP SP2開始引入隨機化PEB基址、SEH保護、堆棧Cookie保護等技術。這些技術的引進會增大緩沖區(qū)溢出攻擊利用的難度，但是并不能從本質上消除緩沖區(qū)溢出的出現(xiàn)。正如黑客技術與反黑客技術一樣，溢出研究與溢出保護研究也在對抗之中不斷發(fā)展與前進。</p><p>　　1.3 研究目

32、的和意義</p><p>　　本文的研究目的主要有以下三點：</p><p>　　1、尋找到一種智能、高效的基于模糊測試的漏洞挖掘方法，能夠挖掘出ActiveX控件中的緩沖區(qū)溢出漏洞</p><p>　　2、研究出一種動態(tài)分析與靜態(tài)分析相結合的漏洞分析方法，對漏洞進行高效、準確的分析，獲取到漏洞形成的相關信息</p><p>　　3、實現(xiàn)一套

33、基于模糊測試的自動化ActiveX控件的漏洞挖掘分析系統(tǒng)，以完成從控件接口分析到漏洞挖掘到漏洞分析的自動化過程</p><p>　　本文的研究意義主要有：</p><p>　　1、通過對ActiveX控件進行自動化漏洞挖掘和分析，以幫助軟件開發(fā)者或安全人員盡早地發(fā)現(xiàn)、定位和分析漏洞，減少已發(fā)布軟件中漏洞的數(shù)量及生存期，從而避免漏洞對企業(yè)和個人造成重大的損失。</p><

34、p>　　2、通過對ActiveX控件的漏洞挖掘研究，掌握漏洞挖掘過程的技巧和方法，以應用到其它類型的軟件安全漏洞挖掘中去。</p><p>　　1.4 主要工作與創(chuàng)新點</p><p>　　本文的主要工作與創(chuàng)新點主要有以下三點：</p><p>　　1、使用本人獨立開發(fā)的調(diào)試器，研究并實現(xiàn)了一套高效的自動化單步跟蹤算法，大大減少了普通單步調(diào)式造成的性能影響，并

35、在此基礎上實現(xiàn)了計算二進制代碼覆蓋率的方法。</p><p>　　2、研究了基于遺傳算法的智能模糊測試技術，并使用二進制代碼覆蓋率作為適應度函數(shù)，來指導測試數(shù)據(jù)的生成。</p><p>　　3、研究并提出了一種基于逆向工程的，動態(tài)分析為主、靜態(tài)分析為輔的緩沖區(qū)溢出漏洞自動檢測、定位、分析技術。</p><p>　　1.5 本文的章節(jié)安排</p><

36、;p>　　本文的組織結構如下：</p><p>　　第1章緒論，概述了選題的背景和意義，選題相關內(nèi)容的研究現(xiàn)狀，概述了本文的研究內(nèi)容、研究意義以及主要工作，最后介紹了論文的章節(jié)安排。</p><p>　　第2章ActiveX控件安全性分析與模糊測試技術，介紹了ActiveX控件的原理技術，常見軟件漏洞的分類以及ActiveX控件漏洞自身的特點，然后介紹了傳統(tǒng)的漏洞挖掘方法和模糊測試技

37、術的定義、原理以及優(yōu)缺點，最后提出了使用進化算法改進模糊測試。</p><p>　　第3章漏洞分析相關技術，介紹了漏洞分析相關的技術，包括基于調(diào)試技術的動態(tài)分析方法，在此基礎上研究出一套高效、可控的動態(tài)分析方法用于計算二進制文件的代碼覆蓋率，最后介紹了基于IDA Pro的靜態(tài)分析方法。</p><p>　　第4章ActiveX控件漏洞挖掘分析系統(tǒng)實現(xiàn)，介紹了漏洞自動挖掘系統(tǒng)的模塊組成以及模

38、塊間的關系，還有系統(tǒng)運行的流程圖，最后分析了該系統(tǒng)現(xiàn)在的優(yōu)缺點。</p><p>　　第5章ActiveX控件漏洞挖掘分析系統(tǒng)實現(xiàn)驗證及結果分析，使用了一款用戶量很大的網(wǎng)絡電視軟件作為案例，使用漏洞自動挖掘系統(tǒng)對該軟件進行測試分析，最后發(fā)現(xiàn)了6個緩沖區(qū)溢出漏洞。</p><p>　　第6章總結與展望，總結了本文的工作，并分析了本文工作的不足和需要改進的地方。</p><

39、p>　　第二章ActiveX控件安全性分析與模糊測試技術</p><p>　　作為IE瀏覽器唯一支持的控件形式，ActiveX控件的安全性問題一直深受關注。本章將重點分析ActiveX控件的加載原理及其漏洞的類型和形成原因，并對模糊測試技術做相應的介紹。</p><p>　　2.1 ActiveX控件原理分析</p><p>　　2.1.1 ActiveX控件

40、加載原理</p><p>　　ActiveX是以微軟COM（組件對象模型Commponent Object Model）技術為基礎建立起來的，通過創(chuàng)建帶有接口的對象，使其能夠被腳本程序（如javascript）跨進程、甚至跨機器遠程調(diào)用，降低了軟件之間的耦合性，為二進制重用提供了一種途徑，代表著新的軟件開發(fā)技術。</p><p>　　常見的ActiveX控件會被編譯成exe、dll或ocx

41、格式的PE文件，在控件內(nèi)部需要實現(xiàn)一些必須實現(xiàn)的接口，其中實現(xiàn)控件主要功能的接口必須繼承自IDispatch接口（派發(fā)接口）。該接口共定義了GetTypeInfoCount（是否支持類型信息）、GetTypeInfo（獲取類型信息接口指針）、GetIDsOfNames（獲取接口函數(shù)的索引）、Invoke（根據(jù)索引調(diào)用相應函數(shù)）四個方法，其中最重要的是GetIDsOfNames和Invoke方法。這兩個方法使得程序可以使用函數(shù)名來調(diào)用函數(shù)

42、，從而實現(xiàn)“晚綁定”（運行期間實現(xiàn)函數(shù)綁定）。因此，IDispatch接口成為自動化（Automation，用編程語言控制軟件運行）的核心技術。</p><p>　　而創(chuàng)建為雙重接口類型的ActiveX控件可以同時支持“早綁定”（通過虛函數(shù)表實現(xiàn)）和晚綁定，這樣在編譯型程序中可以使用早綁定，而在腳本程序中使用晚綁定。</p><p>　　此外，ActiveX控件也跟普通COM組件一樣，擁有

43、一個類標識（CLSID）和多個接口標識（IID），CLSID與IID都是128位的標識符，每個類標識有一個相應的易于識別的字符串型的ProgID。</p><p>　　ActiveX控件由三個要素組成：屬性、方法、事件。</p><p>　　屬性：描述控件的特征信息</p><p>　　方法：控件暴露給外界的接口，使用者通過調(diào)用這些方法來完成特定的操作。</p

44、><p>　　事件：用戶執(zhí)行特定操作（如鼠標單擊、雙擊、按鍵等）后產(chǎn)生的消息通知，程序收到事件通知后可以執(zhí)行相應的操作。</p><p>　　ActiveX控件需要嵌入在容器中才可以正常工作，否則對象會創(chuàng)建失敗。IE瀏覽器就是一種很好的控件容器，通過編寫一定格式的html代碼（使用<object>標簽，并且指定clsid屬性），就可以在IE中加載指定的ActiveX控件[6]。&l

45、t;/p><p>　　2.1.2 ActiveX控件的加載條件</p><p>　　由于ActiveX控件一旦執(zhí)行后就擁有和瀏覽器等同的系統(tǒng)權限，因此需要一些機制來避免惡意控件的加載。主要有以下幾種機制：</p><p><b>　　1、數(shù)字簽名 </b></p><p>　　ActiveX控件在發(fā)布前需要打上公司的數(shù)字簽名

46、證書，證明控件的合法身份。IE瀏覽器在加載控件前會檢查控件的數(shù)字簽名信息是否完整，檢查失敗則不會加載控件。</p><p><b>　　2、標記為安全</b></p><p>　　ActiveX控件需要在注冊表中標記為“腳本安全”和“初始化安全”。具體來說就是在注冊表項“HKEY_CLASSES_ROOT\CLSID\{控件的CLSID}\Implemented Ca

47、tegories”下面存在“{7DD95801-9882-11CF-9FA9-00AA006C42C4}”和“{7DD95802-9882-11CF-9FA9-00AA006C42C4}”這兩個子項。</p><p>　　除此之外，ActiveX控件還可以通過實現(xiàn)IObjectSafety接口來在IE瀏覽器中將自身標記為安全。</p><p>　　3、KillBit機制</p>

48、<p>　　微軟還提供了一種臨時禁止控件加載的機制，即KillBit機制。如果注冊表值“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{控件的CLSID}\Compatibility Flags”為32位長整型的0x400，IE就認為該控件已被禁用，從而拒絕加載該控件。該方法可以作為控件出現(xiàn)漏洞時的臨時補救措施[7

49、]。</p><p>　　2.2 ActiveX控件漏洞形成分析</p><p>　　2.2.1 軟件漏洞的定義</p><p>　　漏洞（Vulnerability）是指計算機系統(tǒng)在硬件、軟件、協(xié)議的具體實現(xiàn)或系統(tǒng)安全策略上存在的安全型缺陷，主要包括輸入驗證錯誤、設計錯誤、整數(shù)溢出、緩沖區(qū)溢出、格式化字符串錯誤、意外情況處理錯誤、環(huán)境錯誤等[8]。</p&g

50、t;<p>　　漏洞與功能性缺陷（bug）之間的區(qū)別是：漏洞會使攻擊者通過惡意的輸入獲得系統(tǒng)的一定權限，從而對系統(tǒng)造成破壞，或竊取機密信息。</p><p>　　2.2.2 軟件漏洞的原理與分類</p><p>　　從本質上講，漏洞的形成都是程序員的疏忽造成的。由于沒有對所有可能的輸入進行正確的處理，這使得程序在正常的輸入情況下沒有問題，而一旦用戶有意或無意輸入了錯誤甚至惡意

51、的數(shù)據(jù)，就會使程序執(zhí)行攻擊者指定的惡意代碼，獲得系統(tǒng)權限。</p><p>　　根據(jù)漏洞的類型主要可以分為以下幾種：</p><p><b>　　緩沖區(qū)溢出</b></p><p>　　這是迄今為止危害最大，也是覆蓋面最廣的漏洞類型。 </p><p>　　所謂緩沖區(qū)溢出，是指向一個緩沖區(qū)內(nèi)拷貝的字符數(shù)組的長度超過了緩沖

52、區(qū)的實際長度，從而致使其它合法數(shù)據(jù)被破壞，之后執(zhí)行的指令在讀取修改后的數(shù)據(jù)后通常會導致程序崩潰。而精心處理的數(shù)據(jù)可以使程序跳轉到攻擊者制造的指令上來，這也是該漏洞的危害所在。</p><p>　　緩沖區(qū)溢出分為棧溢出和堆溢出。</p><p><b>　?。?）棧溢出</b></p><p>　　棧（Stack）是程序存儲局部變量和調(diào)用函數(shù)所必

53、不可少的連續(xù)的內(nèi)存區(qū)域。在Windows中，程序默認的棧大小為1M到2M，如果要在棧中分配超過棧允許長度的內(nèi)存，就會發(fā)生棧溢出。可以在程序鏈接時通過開關修改默認的棧大小。</p><p>　　操作系統(tǒng)在創(chuàng)建線程時，會為每個線程分配單獨的?？臻g并初始化相關的數(shù)據(jù)結構和寄存器。例如，在x86系統(tǒng)中，會使用SS（Stack Segment）寄存器（堆棧段寄存器）來記錄堆棧段的段值，使用EBP寄存器作為棧幀基址寄存器，E

54、SP寄存器作為棧頂指針。程序在進行函數(shù)調(diào)用的時候，一般會通過“call xxx”（xxx為函數(shù)地址）指令去調(diào)用函數(shù)，實際上該指令做了以下兩個操作：</p><p><b>　　PUSHEIP</b></p><p><b>　　JMP xxx</b></p><p>　?。ㄗⅲ?匯編中是不可以直接操作EIP的，這里

55、只是為了便于理解，下同）</p><p>　　所以“call”指令在執(zhí)行時會自動保存函數(shù)的返回地址，以便函數(shù)在返回時可以回到“call”指令的下一條指令。這是通過“ret n”（n為參數(shù)所占的字節(jié)數(shù)）指令實現(xiàn)的，“ret n”指令做了以下兩個操作：</p><p><b>　　POPEIP</b></p><p><b>　　AD

56、Dn</b></p><p>　　因此，棧中保存的函數(shù)返回地址決定了程序的執(zhí)行路徑，改變了返回地址，也就改變了程序的執(zhí)行流程。</p><p>　　在函數(shù)的一開始一般會有以下創(chuàng)建標準棧幀的操作（優(yōu)化后的代碼會沒有）：</p><p><b>　　PUSHEBP</b></p><p>　　MOVE

57、BP, ESP</p><p>　　通過這種方式，就可以將上一次函數(shù)調(diào)用時的棧幀基址保存起來，并將EBP設為新的棧幀基址，因此通過EBP值可以在棧中找到一條函數(shù)調(diào)用鏈。如圖2-1所示，根據(jù)紅框中EBP的值可以依次得到每次函數(shù)調(diào)用的棧幀，再根據(jù)函數(shù)的返回地址就得到了函數(shù)的調(diào)用堆棧，這就是堆?；厮?，在程序調(diào)試的過程中會經(jīng)常用到它。</p><p>　　圖2-1 函數(shù)調(diào)用堆棧圖</p>

58、;<p>　　函數(shù)在棧中可以分配的內(nèi)存大小一般是在編譯時決定的，編譯器會在函數(shù)開始的地方生成類似“SUBESP, 100”這樣的指令。也就是說，該函數(shù)只有0x100個字節(jié)的?？臻g可以使用，如果函數(shù)中做了內(nèi)存拷貝的操作，而且拷貝的字節(jié)數(shù)超過了0x100，那么后面的?？臻g就會被非法修改。這就是棧溢出發(fā)生的原因。最常見的情況就是由于函數(shù)的返回地址被修改而出現(xiàn)訪問違規(guī)，如果是精心構造的數(shù)據(jù)，返回地址會指向攻擊者的代碼，從而使攻

59、擊者得到了遠程代碼執(zhí)行權限。</p><p><b>　?。?）堆溢出</b></p><p>　　堆（Heap）是組織內(nèi)存的另一種重要方法，是程序在運行期動態(tài)申請內(nèi)存空間的主要途徑。</p><p>　　堆和棧的區(qū)別主要有以下幾點：</p><p>　　?？臻g的分配是固定的，是編譯時決定的，而堆空間是動態(tài)分配的，是運行

60、時決定的。</p><p>　　?？臻g是有限的，一般用于存儲局部變量，而堆空間相對來說是比較大的，允許分配大塊的內(nèi)存，而且可以顯式地控制對象的生存期，在其不需要時將其釋放。</p><p>　　在Windows中，棧是由高地址往低地址分配，堆由低地址往高地址分配；堆空間的管理要遠遠比?？臻g復雜。</p><p>　　由于Windows保護模式機制的存在，每個進程空間

61、是一個線性的平面結構。在32位系統(tǒng)上，進程可見的內(nèi)存空間范圍均為0~0xFFFFFFFF，即虛擬地址空間。這其中高2G空間為內(nèi)核空間，低2G為用戶空間，而且用戶空間前后的64K大小均為隔離帶，不能夠訪問。因此，用戶態(tài)程序真正能訪問的地址空間范圍是0x00010000 – 0x7FFEFFFF。Windows通過VirtualAlloc（分配虛擬內(nèi)存）、VirtualFree（釋放虛擬內(nèi)存）等API直接操作虛擬內(nèi)存，但是Win32子系統(tǒng)為

62、了提高內(nèi)存分配的效率，實現(xiàn)了一套堆管理機制來滿足應用程序對內(nèi)存的需求。即用戶應當通過HeapCreate（創(chuàng)建堆）、HeapAlloc（從堆中分配內(nèi)存）、HeapFree（釋放內(nèi)存）、HeapDestroy（銷毀堆）等API來創(chuàng)建和銷毀堆，這幾個API實際上調(diào)用的是ntdll.dll中的RtlCreateHeap（創(chuàng)建堆）、RtlAllocateHeap（從堆中分配內(nèi)存）、RtlFreeHeap（釋放內(nèi)存）和RtlDestroyHeap

63、（銷毀堆）。</p><p>　　事實上，實際編程中人們很少直接去調(diào)用這些堆管理函數(shù)，而是使用crt庫封裝的new（分配內(nèi)存）、delete（釋放內(nèi)存）或malloc（分配內(nèi)存）、free（釋放內(nèi)存）。 在Debug版本下，它們會包含一些調(diào)試代碼，可以方便編程人員發(fā)現(xiàn)存在的內(nèi)存問題。</p><p>　　如前所述，堆的內(nèi)部結構是非常復雜的，系統(tǒng)需要多個數(shù)據(jù)結構來維護堆的管理。每個堆由一到多

64、個內(nèi)存段（Segment）組成，第一個段（0號段）的開始處存放著一個HEAP結構的堆頭信息；每個段會有一個HEAP_SEGMENT結構來描述自身；一個段由若干個堆塊組成，每個堆塊會以一個8字節(jié)的HEAP_ENTRY結構開始。這些只是維護堆結構的最基本信息。</p><p>　　堆溢出與棧溢出類似，也是由于內(nèi)存拷貝操作超出了堆分配的長度，不同的是堆溢出會修改堆管理結構中的數(shù)據(jù)，造成堆管理器無法正常工作。較常見的情況

65、是堆被破壞后，在下一次分配堆（HeapAlloc）的時候發(fā)生訪問違規(guī)。但有時堆溢出很久之后才出現(xiàn)異常，這時再來尋找原因就已經(jīng)錯過了“第一現(xiàn)場”，難度會加大很多。因此，對堆的操作要格外小心。</p><p>　　一般來說，棧溢出會覆蓋函數(shù)返回地址或異常處理鏈，攻擊者使用堆噴射（Heap Spray）技術便可以執(zhí)行Shellcode，因此利用的難度會低一些。</p><p>　　相對于棧溢出，

66、堆溢出的利用會麻煩一些，因為無法直接改變指令的執(zhí)行流程。通常的思路是利用對指針的操作間接改變關鍵數(shù)據(jù)從而獲得代碼執(zhí)行權限。</p><p>　　隨著Windows加大對緩沖區(qū)溢出攻擊的防范力度，例如從XP SP2開始引入隨機化PEB機制、SHE保護、堆棧Cookie保護等技術，這些技術的引進增加了對緩沖區(qū)溢出利用的難度，但是并沒有從根本上消除緩沖區(qū)溢出的發(fā)生。因此只有在軟件開發(fā)的過程中杜絕危險的代碼，才能從本質上

67、消除緩沖區(qū)溢出的出現(xiàn)。</p><p><b>　　整數(shù)溢出</b></p><p>　　整型變量在申明時一般會確定好類型，包括占用的字節(jié)數(shù)和是否是unsigned類型。因此，整型變量在申明時其可以表示的整數(shù)范圍就已經(jīng)確定了。如果對其賦予一個不在其表示范圍內(nèi)的整數(shù)就會發(fā)生整數(shù)溢出。整數(shù)溢出可以分為以下幾種：</p><p>　?。?）算數(shù)運算產(chǎn)

68、生的進位</p><p>　　例如兩個大正數(shù)相加或相乘，產(chǎn)生進位的時候就會出現(xiàn)溢出，導致結果不正確。</p><p>　?。?）無符號類型的上溢與下溢</p><p>　　無符號數(shù)是沒有負數(shù)的，因此對一個接近于零的正數(shù)做減法操作時，不小心就會下溢變成一個超大的正數(shù)。</p><p>　?。?）有符號類型與無符號類型的轉換或比較</p&g

69、t;<p>　　由于這兩種類型表示的范圍不同，強制轉換或比較就容易出現(xiàn)問題。例如：</p><p>　　int i = -1;</p><p>　　unsinged int j = 0xFFFFFFF0;</p><p>　　bool b = i > j;</p><p>　　雖然i為負數(shù)，但結果卻會大于j。</p&

70、gt;<p>　　整數(shù)溢出本身并沒有太大的危害，一般情況只會影響計算的結果。但有時整數(shù)溢出會間接導致緩沖區(qū)溢出，因此也不容小視。</p><p><b>　　格式化字符串</b></p><p>　　成因一般是在使用包含格式化字符串操作的C語言函數(shù)時，如fprintf、sprintf、snprintf、vprintf、vfprintf、vsprintf和

71、vsnprintf等，允許用戶輸入格式化字符串導致的。因此，使用這些函數(shù)時必須正確地指定格式。</p><p><b>　　4、意外條件錯誤</b></p><p>　　對意外情況沒有做容錯處理，致使程序直接拋出異常而崩潰。</p><p>　　2.2.3 ActiveX控件的漏洞的特點與形成原因</p><p>　　1

72、、ActiveX控件常見的輸入?yún)?shù)類型</p><p>　　ActiveX控件是基于IDispatch接口實現(xiàn)的，使用的數(shù)據(jù)類型是VARIANT類型。具體使用的數(shù)據(jù)類型與javascript語言中的數(shù)據(jù)類型的對應關系如表2-1所示。</p><p>　　表2-1 ActiveX控件中使用的數(shù)據(jù)類型</p><p>　　2、ActiveX控件的漏洞的特點</p&

73、gt;<p>　　ActiveX控件除了會存在上述一般軟件存在的漏洞外，還具有以下一些特點。</p><p>　?。?）控件實現(xiàn)的接口主要通過腳本來調(diào)用，比如Javascript、VBScript等，因此傳入的參數(shù)需要符合相應腳本語言的語法規(guī)則。</p><p>　?。?）控件中有可能會存在一些邏輯漏洞，主要是設計時沒有對控件安全足夠重視造成的。例如控件中存在操作注冊表、操作

74、文件、下載文件之類的接口，攻擊者可以直接使用這些接口獲得一定的權限。</p><p>　　MS06-014漏洞就是一個典型的邏輯漏洞，由于系統(tǒng)對使用者的權限控制不足，導致它允許網(wǎng)頁腳本使用控件Microsoft.XMLHTTP、Adodb.Stream和Shell.Application去下載并運行一個遠程文件。</p><p>　?。?）程序缺陷（bug）導致拒絕服務攻擊</p&g

75、t;<p>　　普通的bug最多導致程序崩潰（Crash），但是ActiveX控件由于其遠程執(zhí)行性，攻擊者只需要將惡意代碼上傳到web服務器上，用戶訪問后瀏覽器就會發(fā)生異常而退出。這種漏洞雖然不會對系統(tǒng)造成大的危害，卻會影響用戶正常使用瀏覽器的功能。</p><p>　?。?）環(huán)境錯誤導致問題</p><p>　　操作系統(tǒng)或瀏覽器版本不兼容，從而致使控件無法正常工作或者程序崩

76、潰。</p><p>　　3、ActiveX控件的漏洞的形成原因</p><p>　　ActiveX控件的漏洞形成原因主要有以下幾種：</p><p><b>　　（1）設計錯誤</b></p><p>　　大部分的邏輯漏洞都是軟件在設計時沒有充分考慮到安全性，從而給攻擊者留下了“后門”。</p><

77、p>　?。?）沒有判斷輸入?yún)?shù)的長度</p><p>　　某些場景下，有些開發(fā)人員認為傳入的參數(shù)（比如一個文件名）長度不會超過某個上限，因此使用棧來分配空間，又沒有判斷參數(shù)的長度，結果就導致了棧溢出。</p><p>　?。?）處理邏輯未考慮特殊情況</p><p>　　這里主要是對輸入字符串的處理上，例如，要對一個url做分析，取出其中的參數(shù)，但是輸入的ur

78、l是這樣的“http://www.qq.com/index?a=1&?b&=&=?”，程序如果沒有正確地判斷，就容易出現(xiàn)漏洞了。</p><p>　　目前還有一種利用某些控件去讀取網(wǎng)絡文件的內(nèi)容，因此通過構造惡意的文件來挖掘漏洞。不過這已經(jīng)是屬于文件Fuzzing的范疇，本文不考慮這種情況。</p><p>　　（4）字符串處理函數(shù)的不正確使用</p>

79、<p>　　程序員在編寫代碼的時候由于粗心或對函數(shù)理解錯誤導致傳入了不正確的參數(shù)，從而產(chǎn)生漏洞。</p><p>　?。?）特殊字符編碼轉換</p><p>　　在實際中用到的編碼方式通常有Unicode、UTF-8、GBK等。如果沒有仔細考慮對編碼的處理，也會產(chǎn)生問題。例如，UTF-8編碼的“\xff\xfe\xde”就沒有對應的Unicode編碼。</p>&

80、lt;p>　　2.3 模糊測試技術</p><p>　　2.3.1 傳統(tǒng)的漏洞挖掘方法</p><p>　　傳統(tǒng)的漏洞挖掘方法有以下幾種：</p><p><b>　　1、手工測試</b></p><p>　　手工向目標程序發(fā)送特殊數(shù)據(jù)，觀察并分析程序的反應。這種方法完全依賴測試人員的專業(yè)水平，因此效率低下，但是準

81、確性較高。</p><p><b>　　2、二進制比對</b></p><p>　　又稱補丁對比技術，攻擊者一般會在軟件公司發(fā)布軟件漏洞補丁后的第一時間，通過比對補丁包做的修改來分析漏洞的原因，并利用用戶尚未來得及打補丁的時間差發(fā)動攻擊。這種方法能夠快速定位漏洞，但是如果軟件廠商做了較大改動，會使分析難度加大；而且有時源碼的微小改動或是編譯選項的改變也會造成二進制代碼

82、較大的變化。</p><p><b>　　3、靜態(tài)源碼掃描</b></p><p>　　這種方法適用于擁有源代碼的軟件。許多公司都有商業(yè)化的源碼掃描軟件，這些軟件通過掃描源代碼，進行詞法和語法分析，并利用模式匹配的方式發(fā)現(xiàn)源代碼中對strcpy、strcat、wcscpy、wcscat、strncpy、strncat、wcsncpy、wcsncat、sprintf等危

83、險函數(shù)的調(diào)用，以及其它一些安全風險。該方法可以自動化運行，但是會產(chǎn)生誤報，需要人工對結果進行甄別。常用的靜態(tài)源碼掃描工具有Cpp Check、VS Code Analysis等。</p><p><b>　　4、逆向工程方法</b></p><p>　　第一、二種方法屬于黑盒測試方法，第三種方法屬于白盒測試方法，逆向工程方法屬于灰盒測試范疇。</p>&

84、lt;p>　　逆向工程最早起源于硬件領域，有些人為了商業(yè)或軍事利益而對硬件進行逆向的分析。后來該方法運用到軟件領域，意為通過反匯編、動態(tài)跟蹤等方法來分析目標軟件的工作原理、邏輯結構、類關系和執(zhí)行流程等。</p><p>　　逆向工程技術主要分為靜態(tài)分析方法和動態(tài)分析方法。</p><p><b>　?。?）靜態(tài)分析方法</b></p><p&

85、gt;　　一般通過反匯編工具（如IDA Pro）得到目標程序的反匯編代碼，再對代碼進行掃描，分析出匯編指令中的函數(shù)、變量等，試圖建立函數(shù)間的調(diào)用關系圖，進而識別出代碼中的可疑匯編指令序列。常見的靜態(tài)分析技術包括：有向圖分析、污點數(shù)據(jù)傳播分析、IDC腳本分析和整數(shù)限制分析等。</p><p>　　這種方法快速高效、易于自動化實現(xiàn)，但缺點是難以識別程序中的復雜邏輯，也容易產(chǎn)生誤報。特別是面向對象技術的出現(xiàn)，使函數(shù)調(diào)用

86、動態(tài)化，即只有在運行時才能決定要調(diào)用函數(shù)的地址，對于這種情況靜態(tài)分析的方法已經(jīng)無能為力。</p><p><b>　?。?）動態(tài)分析方法</b></p><p>　　在運行時跟蹤、分析程序的執(zhí)行流程，以得到程序在當前輸入的情況下的運行狀態(tài)，具體可以使用動態(tài)調(diào)試、代碼插樁等方法。基于調(diào)試的方法是一種較為成熟、簡單的方法，既可以使用現(xiàn)有的調(diào)試器（例如：WinDbg、Oll

87、yDbg等），也可以自己編程實現(xiàn)一個定制化的調(diào)試器，通過觀察寄存器、內(nèi)存以及程序的狀態(tài)來發(fā)現(xiàn)程序的異常。</p><p>　　代碼插樁是一種常見的統(tǒng)計程序代碼覆蓋率的方法，不過一般是基于源碼的插樁；對于二進制程序可以使用動態(tài)插樁技術。這種方法可以獲得較為準確的程序動態(tài)執(zhí)行信息，但缺點是每次運行都不可能獲得所有的執(zhí)行路徑，因此無法發(fā)現(xiàn)所有的潛在漏洞。改進的方法是使用大量的不同輸入試圖覆蓋到所有分支路徑。</p

88、><p>　　2.3.2 模糊測試的定義</p><p>　　模糊測試，即Fuzzing Test，是一種自動化或半自動化的軟件測試技術。通過向程序輸入無效的、非預期的或是隨機的數(shù)據(jù)，會監(jiān)測到程序發(fā)生異常，比如崩潰（Crash）或是代碼中斷言（Assertion）的失敗。模糊測試通常被用于測試軟件或電腦系統(tǒng)的安全問題[3]。</p><p>　　Miller等人認為模糊

89、測試是軟件測試中的隨機測試技術；Sutton等人認為模糊測試的重要組成部分是暴力測試；Andrea等人認為模糊測試是一種簡單的黑盒測試技術；Oehlert認為模糊測試是黑盒測試中的邊界測試技術；Vuagnoux認為模糊測試是黑盒測試、錯誤注入、壓力測試的融合（Fuzzing技術綜述）。因此，傳統(tǒng)的模糊測試技術可以認為是一種簡單的使用錯誤注入的黑盒暴力測試技術。</p><p>　　2.3.3 模糊測試技術的原理&

90、lt;/p><p>　　模糊測試技術的原理是通過向測試對象傳入一些畸形的、非預期的輸入，致使程序產(chǎn)生異常，并記錄下此時的寄存器狀態(tài)信息、內(nèi)存、堆棧等數(shù)數(shù)據(jù)，來探究軟件中潛在的漏洞。</p><p>　　模糊測試的核心是模糊器（Fuzzer），也稱為模糊引擎。模糊器一般可以分為兩類：基于變異的模糊器（Mutation-based Fuzzer）和基于生成的模糊器（Generation-based

91、 Fuzzer）。前者先按照文件格式或協(xié)議格式創(chuàng)建一個有效的測試數(shù)據(jù)模版，然后不斷對其中的部分數(shù)據(jù)變異生成新的測試數(shù)據(jù)，傳入目標程序；而后者通過分析文件或協(xié)議的格式，根據(jù)格式生成測試數(shù)據(jù)。</p><p>　　這兩種方法都需要對文件或協(xié)議格式有一定的了解，因此需要一定的人工參與，但是這樣可以提高模糊測試的效率。</p><p>　　模糊測試的流程通?？梢苑譃橐韵聨讉€階段：</p>

92、;<p><b>　　目標分析</b></p><p>　　對軟件信息的了解將有助于模糊測試，這些信息包括軟件的安裝目錄、使用的開發(fā)語言、編譯器類型、導出和導入的API等等。對于ActiveX控件，比較重要的信息有控件注冊的接口、接口提供的方法以及參數(shù)、參數(shù)類型等。</p><p><b>　　分析輸入域</b></p>

93、<p>　　分析軟件可以利用的所有輸入類型和范圍，包括文件、網(wǎng)絡數(shù)據(jù)、環(huán)境變量等。對于ActiveX控件，主要的輸入域就是通過js調(diào)用控件提供的接口方法時傳入的參數(shù)，每個參數(shù)的輸入域會被限制在特定的參數(shù)類型。</p><p><b>　　生成測試數(shù)據(jù)</b></p><p>　　根據(jù)輸入域和選擇的模糊測試的類型和算法生成測試數(shù)據(jù)。對于ActiveX控件，

94、最常見的模糊測試的數(shù)據(jù)類型就是整型和字符串型，為了方便執(zhí)行測試，可以將生成的測試數(shù)據(jù)以完整的js函數(shù)調(diào)用的形式保存在一個HTML文件中。</p><p><b>　　執(zhí)行模糊測試</b></p><p>　　使用目標程序打開測試數(shù)據(jù)，為了測試大量的測試數(shù)據(jù)，需要目標程序能夠自動化地重復執(zhí)行。對于ActiveX控件，目標程序就是IE瀏覽器，一種簡單地自動化打開測試數(shù)據(jù)的

95、方法是在網(wǎng)頁中設置幾秒后自動跳轉到下一個網(wǎng)頁，但是這種方法有時會污染測試環(huán)境，也就是之前的測試數(shù)據(jù)對后面的測試數(shù)據(jù)產(chǎn)生影響，使得測試結果不準。</p><p><b>　　異常監(jiān)視</b></p><p>　　模糊測試的目的主要是用于發(fā)現(xiàn)程序在特定輸入時產(chǎn)生的異常，因此需要有異常監(jiān)測手段，最常見的方法就是使用調(diào)試器。調(diào)試進程以調(diào)試方式創(chuàng)建IE進程后，一旦ActiveX

96、控件發(fā)生異常，就會被調(diào)試進程捕獲到。</p><p><b>　　異常記錄與分析</b></p><p>　　將產(chǎn)生異常的測試數(shù)據(jù)保存到指定的目錄，并打開分析程序，進一步深入地分析異常產(chǎn)生的原因，并確定是否是漏洞以及漏洞的類型。</p><p>　　2.3.4 模糊測試的優(yōu)點和缺點</p><p>　　相對于傳統(tǒng)的漏洞挖

97、掘技術，模糊測試技術更適合于自動化實現(xiàn)，具有準確性高的優(yōu)點，但是它也具有一些缺點，如測試時間長、屬于黑盒測試、不能保證發(fā)現(xiàn)所有的漏洞等。</p><p>　　傳統(tǒng)的模糊測試方法具有以下一些缺點。</p><p><b>　　1、測試效率低下</b></p><p>　　由于測試數(shù)據(jù)輸入域空間很大（即便是32位長的整型數(shù)也會有232個取值，字符串

98、取值就更多了），而被測對象是一個黑盒，要對這些測試數(shù)據(jù)做等價類劃分是不可能的。因此，要在如此巨大的輸入域中找到會導致異常的測試數(shù)據(jù)所花的時間也是較多的。</p><p>　　2、缺乏對測試質量的評估和度量</p><p>　　模糊測試并不是一種一定會發(fā)現(xiàn)漏洞，或是能夠證明一定沒有漏洞的方法，而且測試結果沒有很好的量化指標，難以評定測試質量。目前只能通過發(fā)現(xiàn)漏洞的數(shù)量來大致評定模糊測試的有效

99、性。</p><p><b>　　3、測試數(shù)據(jù)冗余</b></p><p>　　模糊測試的測試數(shù)據(jù)是隨機生成的，因此會有很多冗余數(shù)據(jù)。這些冗余數(shù)據(jù)進行的都是無效測試，如果減少了冗余數(shù)據(jù)的數(shù)量，就會提高模糊測試的效率。</p><p>　　2.3.5 進化模糊測試思想</p><p>　　針對傳統(tǒng)模糊測試的這些缺陷，后來引

100、入了進化測試（Evolution Testing）的思想。</p><p>　　進化測試是近年來興起的一種自動生成有效測試數(shù)據(jù)的方法。它的基本思想是在一定的準則下將測試數(shù)據(jù)生成問題轉化為求解全局最優(yōu)問題。進化測試技術主要的理論依據(jù)是進化算法，目前進化算法包括遺傳算法、模擬退火算法和爬山法，模擬退火算法和爬山法一般應用于局部優(yōu)化策略中，而遺傳算法則具有較好的全局尋優(yōu)能力[29][31]。</p>&l

101、t;p>　　進化測試具有以下優(yōu)點：</p><p>　　1、自動化程度高，不需要人工的參與</p><p>　　2、能夠自學習、自適應，自動指導測試數(shù)據(jù)的生成</p><p>　　3、縮小了測試數(shù)據(jù)的輸入域，減少了生成的測試數(shù)據(jù)數(shù)量，提高了測試效率</p><p>　　遺傳算法（Genetic Algorithm, GA）是基于生物進化

102、理論和遺傳學機制演化而來的隨機化搜索方法，借用了生物學中達爾文提出的“適者生存、弱者淘汰”的進化論思想，通過模擬自然進化過程以得到最優(yōu)解。遺傳算法最初是由美國密西根大學的J.Holland教授于1975年首次提出，并出版了頗有影響力的專著《自然與人工系統(tǒng)中的自適應（Adaptation in Natural and Artificial Systems）》。至今，遺傳算法已廣泛應用于生物、運籌學、工程技術、計算機科學、圖像處理、模式識別

103、、社會科學等領域[28]。</p><p>　　遺傳算法具有以下特點：</p><p>　　自組織、自適應以及自學習性</p><p>　　并行性 能夠以并行的方式同時搜索解空間的多個區(qū)域</p><p>　　獨立性 不需要求導或其它輔助知識，只需影響搜索方向的適應度函數(shù)</p><p>　　多解性 對于給對的問

104、題，遺傳算法可以產(chǎn)生多個最優(yōu)解</p><p>　　遺傳算法首先對測試數(shù)據(jù)進行編碼形成個體，個體中每一位表示基因，使用隨機方法產(chǎn)生初始化種群，在之后的每次迭代中，對當前種群應用選擇、交叉、變異等進化算子，并使用一定的適應度評價機制使得每次迭代產(chǎn)生更優(yōu)的種群，最后通過對個體的解碼得到實際問題的解。</p><p>　　遺傳算法的一般流程如下：</p><p>　　根據(jù)

105、問題規(guī)模，確定參數(shù)范圍，并堆積產(chǎn)生一定規(guī)模的初始種群。個體由染色體的基因編碼表示</p><p>　　評價種群，計算個體的適應度，判斷是否滿足停止條件，若符合，輸出最佳個體機器代表的最優(yōu)解，并結束計算，否則轉向第3步</p><p>　　依據(jù)適應度選擇再生個體，適應度高的個體被選中的概率高，適應度低的個體被淘汰</p><p>　　按照一定的交叉概率和交叉方法，生成

106、新個體</p><p>　　按照一定給的變異概率和變異方法，生成新個體</p><p>　　由交叉和變異產(chǎn)生新一代的種群，并返回到第2步</p><p>　　程序的停止條件主要有以下三種：</p><p>　　出現(xiàn)達到預定目標的測試數(shù)據(jù)；</p><p>　　完成預先指定的進化代數(shù)；</p><p&

107、gt;　　種群中的最優(yōu)個體連續(xù)若干代沒有改進或平均適應度在連續(xù)若干代基本沒有改進。</p><p>　　因此，通過將進化測試的思想引入模糊測試中，可以有效地提高模糊測試的效率。進化測試的關鍵在于適應度評價機制，測試數(shù)據(jù)根據(jù)適應度函數(shù)計算出適應度，然后依據(jù)適應度的高低決定保留還是放棄該測試數(shù)據(jù)。在軟件測試中，計算適應度的方法一般是對控制流的覆蓋分析。因此，完全黑盒的模糊測試是不能使用進化算法的，而加入反匯編產(chǎn)生的灰

108、盒模糊測試卻是可以使用的。</p><p><b>　　2.4 本章小結</b></p><p>　　本章首先介紹了ActvieX控件的加載原理和加載條件，它是基于COM技術和自動化接口實現(xiàn)的一種IE擴展組件，IE為了保證控件的安全性，會在加載前通過數(shù)字簽名、腳本安全、初始化安全、KillBit等機制來驗證控件的安全性。接著，本章介紹了常見的漏洞原理和分類，如緩沖區(qū)溢

109、出、整數(shù)溢出、格式化字符串等；ActiveX控件漏洞獨有的一些特點以及形成原因；常見的漏洞挖掘方法，如手工測試、二進制對比、靜態(tài)源碼掃描、逆向工程等。最后，介紹了模糊測試技術的定義、原理以及優(yōu)缺點，并針對模糊測試的缺點引入了進化測試的思想。</p><p>　　第三章 漏洞分析相關技術</p><p>　　調(diào)試器技術是動態(tài)分析方法的關鍵技術之一，因此，本章介紹了調(diào)試器原理、調(diào)試過程中用到的

110、關鍵技術、重要的調(diào)試API等，并介紹了自動化動態(tài)調(diào)試的原理，以及在此基礎上用于計算二進制代碼覆蓋率的方法。最后，本章介紹了基于IDA插件的靜態(tài)分析方法。</p><p><b>　　3.1 調(diào)試器原理</b></p><p>　　調(diào)試技術是軟件開發(fā)過程中非常重要的一種技術，它可以幫助開發(fā)人員快速發(fā)現(xiàn)軟件中存在的缺陷（bug），從而有效地提高軟件開發(fā)的質量。</p

111、><p>　　雖然像VS、WinDbg這樣的調(diào)試器可以方便地進行源碼級調(diào)試，但事實上它們在底層上都是使用了CPU提供的指令級調(diào)試。這些調(diào)試器通過符號文件（PDB）獲取程序中包含的所有符號，然后建立每條指令與源碼的映射關系，并在上層屏蔽了指令的細節(jié)，使用戶以為調(diào)試器是基于源碼語句的調(diào)試。</p><p>　　調(diào)試器為了可以調(diào)試所有的應用程序，做到盡量的通用性，對于下斷點、單步調(diào)試這些操作都是由用

112、戶自己決定的。因此，整個調(diào)試工作難以實現(xiàn)自動化。</p><p>　　為此，實現(xiàn)一個定制化的自動調(diào)試工具，將非常有助于漏洞的自動化分析工作。事實上，Windows提供了一系列的調(diào)試API，使用這些API是可以實現(xiàn)一個定制化的調(diào)試工具的。</p><p>　　通常，要讓調(diào)試進程具有調(diào)試被調(diào)試進程的權限，有兩種方法：一種是使用CreateProcess（創(chuàng)建進程）以DEBUG_ONLY_THI

113、S_PROCESS或DEBUG_PROCESS作為參數(shù)創(chuàng)建被調(diào)試進程，這兩個選項的差別是前者只會調(diào)試創(chuàng)建的這個被調(diào)試進程，而后者可以調(diào)試創(chuàng)建的所有子進程；第二種方法是使用DebugActiveProcess將調(diào)試進程附加到被調(diào)試進程上。</p><p>　　調(diào)試進程獲取到對被調(diào)試進程的調(diào)試權限后，使用 WaitForDebugEvent等待調(diào)試事件的發(fā)生。被調(diào)試進程只要發(fā)生下列任一種事件，都會通知調(diào)試進程，并使自