0×0 此文目的
Fuzz即模糊測試，是一種使用大量的隨機數據測試系統安全的方法，Peach就是一種這樣的工具。網上零零星星有些介紹Peach的文章，也有少部分使用Peach測試某種文件的教程（其實就是直接翻譯官方文檔），並沒有針對實際協議的真正測試。初學者，往往無從下手，本文從實戰出發，穿插講解Peach套件的一些語法和原理，讓你真正從0開始一段奇妙的模糊測試之旅！
0×1 Peach簡介
Peach是一個遵守MIT開源許可證的模糊測試框架，首個版本發佈於2004年，使用python編寫，第二版於2007年發佈，被收購後，最新的第三版使用C#重寫了整個框架，而且分爲社區版和付費版。付費版本擁有更好的擴展功能，便於管理的Web界面，更加智能的建模機制，上手更容易。但是，鑑於廣大同胞囊中羞澀，本次當然重點講解社區版（免費版）。
Peach Fuzz其實是一種黑盒測試方法，通過發送大量的隨機數據到被測試系統，再結合監視器，檢測系統的運行狀態，來發現被測試系統或進程中，可能存在的安全問題。英文好的同學，可自行點擊Peach官網傳送門。
0×2 Peach安裝
安裝其實很簡單，對於本次的測試來說，不需要一些花裏胡哨的操作（比如，.NET，debug tools），對於Win10來說，更是如此。官方安裝指南——看看就好，不必當真。
所以，只需要一步，在官網上下載peach-3.1.124-win-x86-release或者x64社區版本即可；任性的同學也可以下載Linux/Mac的版本。下載之後，解壓。爲了方便後續的測試，最好將peach的目錄，加入到系統的環境變量。
0×3 結合Burpsuite對Web API進行fuzz測試
終於到了實戰環節，這也是本文的另一個重點內容。這部分從0開始，一步步帶你領略Peach的神奇魅力，更高級的功能，需要我們以後共同探索。
0×31 使用Burpsuite抓取需要fuzz的Web接口數據
設置代理，對目標接口進行抓包，這一步我相信大夥都會，不會的同學請自行移步Burpsuite抓包教程，我在這裏就不重複造輪子了。
需要fuzz的API接口
抓取數據包
我們的目的是要將抓取的數據包，轉換成數據模型，在此之前，需要先保存該數據包爲.bin文件。
全選：Ctrl + A
複製：Ctrl + C
創建文件login.bin，並將數據包拷貝過來並保存：Ctrl + V
將文件保存在E:\MyPeachPit\這裏只是指定一個文件夾，方便後面把所有的配置文件都放在一個目錄中。你們可隨意創建一個目錄。
0×32 創建數據模型
創建一個文件，命名爲 1-my_data.xml（命名請隨意），同樣放在E:\MyPeachPit\。首先是根標籤，也就是描述文件，你也可以在屬性中加入文件的整體註釋信息。
<?xml version="1.0" encoding="utf-8"?>
<Peach xmlns="http://peachfuzzer.com/2012/Peach" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://peachfuzzer.com/2012/Peach ../peach.xsd">
<DataModel name="my_data_model">
</DataModel>
</Peach>
在<Peach>標籤中，創建數據模型<DataModel>，屬性name可以隨便起個名字，但是後面會用到。數據模型其實就是我們需要的fuzz對象。按照上一節抓取的數據包，一步步來編寫這個數據模型，這是定製化fuzz的核心步驟。
數據包的第一行：POST /formLogin.htm HTTP/1.1。請注意這裏的空格，編寫數據模型一定要一一對應。
第一行對應的數據模型如下
每個標籤都可以起一個名字，爲空也是可以的。value是實際的值，token字段用於分隔，表明這是一段用於分隔其他字符的標籤。mutable，顧名思義，就是這段標籤能否用來變異，也就是說，你到底想不想改變這段數據。HTTP報文頭部後面幾行數據以此類推，相信大家都會編寫了。
溫馨提示1：HTTP頭部報文和請求體報文之間，存在一個空行，在數據模型的編寫中，也是要注意的。
接下來是比較重要的HTTP請求體的內容，對應的數據模型了。常見的請求體主要有兩種：XML和JSON。比如說，如果請求體是這樣
{"key1":"admin", "key2":"pw123"}
那麼對應的數據模型應該是
這裏有幾點注意下：雙引號的轉移字符是 " 剩下的內容以此內推。同樣的，標籤可以起名字，也可以爲空，但是不能全爲 name=“”但是像上圖那樣會有問題，會提示鍵重複。請刪除 name=“”。
溫馨提示2：普通字符和特殊字符最好分開寫，不然很容易出錯。比如
最好編寫成
溫馨提示3：編寫數據模型文件很容易出錯，最好寫一段就配合0×33節的步驟，對數據模型文件進行校驗。
0×33 驗證數據模型與抓取的數據包bin文件
數據模型文件編寫的過程本身就是一項比較繁瑣的工作，編寫好的文件，也極有可能出錯，PeachValidator.exe 應運而生。在編寫好數據模型之後，我們需要使用Peach解壓後，自帶的該工具，驗證編寫好的數據模型，與抓取的數據包bin文件內容是否一致。
如上圖所示，點擊完刷新按鈕之後，如果沒有報錯，說明數據模型文件編寫正確，否則，需要根據錯誤提示，進行修改。
本節所示的兩幅圖，即PeachValidator.exe 與 notepad++ 配合工作，使得調試數據模型較爲方便。
經歷過數據模型的定製後，有沒有覺得很麻煩？沒辦法，Peach後期的自動化依賴於前期的定製，所以數據模型的編寫正確與否，至關重要。根據不同的API，數據模型一旦編寫好之後，後續的步驟大同小異，可以套用。
0×34 創建配置模型
配置模型，顧名思義，是一些全局的配置信息，例如IP地址、端口之類的。你定義好了數據包，總得定義發送目標把。文件命名爲2-my.xml.config（命名依然請隨意）。
<?xml version="1.0" encoding="utf-8"?>
<PitDefines>
<All>
<IPv4 key="TargetAddress"
value="192.168.10.1" />
<Range key="TargetPort"
value="80"
min="0"
max="65535" />
<Range key="Timeout"
value="5000"
min="0"
max="999999" />
<!--
還可以定義一些配置信息，具體可參考官方手冊
!-->
</All>
</PitDefines>
</Peach>
0×35 創建狀態模型
狀態文件，主要包括input和output兩個動作。編寫狀態模型文件如下，並命名爲3-my_state.xml
input：從Publisher即發包器中接收或者讀取輸入
output：通過Publisher發送或寫output操作
未知數據保持在一個“Blob”元素（二進制大對象或者字節數組）中
0×36 創建綜合測試模型
綜合測試模型文件，定義了一些關鍵要素，例如發包器、監控器以及測試策略等。相當於把所有文件綜合成一個文件。實際上，針對一些簡單的API，也可以把所有文件直接寫在一個文件中。
Publishers是Peach的I/O連接，它是實現輸出、輸入和調用等操作之間的管道。對於文件fuzzer來說，將使用一個稱之爲文件的Publisher，它允許我們對一個文件進行寫操作。編寫綜合測試模型文件如下，命名爲4-my_integrate.xml
Test元素被用於配置一個指定的fuzzing測試，這個配置通過一個Publisher和其他選項（比如including/excluding等被變異的元素、Agents、fuzzing策略）組合成一個StateModel。多個test元素是支持的，在Peach命令行使用中，只需簡單提供test元素的名字即可。
至此，所有的xml文件編寫告一段落，那麼怎麼測試這些xml文件是否編寫正確呢？請看下節。
0×37 驗證測試套
輸入以下命令，即可驗證編寫的所有文件是否符合Peach的標準。請注意參數 -1 是數字1，而不是字母l。
peach E:\MyPeachPit\4-my_integrate.xml -l --debug
第一次運行時，肯定會報錯，需要根據錯誤提示，不斷修正我們剛剛編寫的測試套xml文件。
如果打印出上面的信息，那麼恭喜你，終於完成了測試套的編寫！也就是完成了Peach的數據建模，基本上，你已經完成了99%的前期準備工作！
0×38 結合Burp進行正式測試與結果分析
爲了實時監控數據流的變化狀況，我們需要監控Peach發送給測試目標的數據。Burpsuite給我們提供了一個便捷的“監控器”。
第一步綁定代理
請注意，上述的 127.0.0.1:8080，與編寫的測試套 4-my_integrate.xml 中的信息要一致。所以，需要將下面的紅框中的數據，也改爲127.0.0.1:8080
第二步peach發送的流量重定向到webserver
終於到了最後一步，也就是愉快的fuzz啦！
peach E:\MyPeachPit\4-my_integrate.xml –range 1,150000
–range 指變異的報文數量，官方推薦15W。
等fuzz完之後，篩選一下Burpsuite抓到的所有報文，就可以看到哪些畸形報文，對目標產生了影響。
0×4 總結
Peach最繁重的工作，都在協議的建模上，也就是編寫測試套件，中途可能會出現很多錯誤，需要耐心排查。關於一些更高級的用法，讀者可自行查閱官方手冊（中文翻譯版）。本文中用到的所有代碼，都是筆者親自編寫，並且進行了驗證。祝大家都能用行之有效的方法，挖意想不到的大洞！
