libfuzzer

libfuzzer 技能概觀

libfuzzer 是用來做什麼的

libfuzzer 是一個針對以 Clang 編譯的 C/C++ 程式所設計、以覆蓋率為導向且在程序內執行的 fuzzing 工具。當你想把「我手上有一個目標函式」快速變成一個可運作的 fuzzing harness，並且用最少的設定找出當機、卡死與輸入處理 bug 時，就很適合使用 libfuzzer 技能。

哪些人適合安裝

這個 libfuzzer 技能最適合做安全稽核的工程師、正在加強 parser 防護的維護者，以及已經用 LLVM/Clang 建置專案的團隊。當你需要比 AFL++ 或 LibAFL 更簡單的起步方式，且一開始不需要完整的 fuzzing farm 時，它特別實用。

它比一般通用提示詞更強的地方

它最大的優勢在於實務導向的設定指引：harness 要怎麼切、目標需要哪些輸入、以及要怎麼跑 fuzzing 才會產生有用的發現，而不是只有一堆雜訊測試。repo 也把取捨講得很清楚：libfuzzer 上手容易、支援廣泛，但它已進入維護模式，並不是每一種 fuzzing 專案的最佳選擇。

如何使用 libfuzzer 技能

先安裝，並找到正確的檔案

先依照你的環境走標準的技能安裝流程，接著第一個就讀 SKILL.md。這個 repo 刻意保持精簡，不另外附 helper scripts、參考資料或額外規則，所以大部分價值都集中在主指南本身。如果你需要安裝背景資訊，先看技能裡的 LLVM/Clang toolchain requirements，再開始編譯 harness。

把程式碼庫轉成 fuzz target

libfuzzer 技能最適合你提供具體目標，而不是模糊需求。比較好的起手式像是：「為這個 C++ XML parser 建立一個 libfuzzer harness，假設使用 Clang，保持 parser state 隔離，並讓 harness 盡量精簡。」請一併提供函式名稱、輸入型別、build system，以及像「必須避免檔案系統存取」或「必須在 sanitizers 下執行」這類限制。

依照技能預期的流程來用

先找出一個可呼叫的單元，它要能接收 bytes，並且可以在單一程序中反覆執行。接著把原始 fuzzer 輸入映射到那個單元，讓副作用保持隔離，並用指南中建議的 Clang 相關 flags 來編譯。若你想要一套 libfuzzer 的使用流程，可以請技能產出：

• LLVMFuzzerTestOneInput 的 harness
• 針對你專案結構的 build instructions
• 適合 sanitizer 的前提假設
• 如果你已經有 sample inputs，則提供 seed corpus 策略

按這個順序讀，效果最好

若想最快上手，請先從頭到尾讀完 SKILL.md，再回頭看何時使用、快速開始、安裝與前置需求等章節。這個順序能幫你先判斷 libfuzzer 是否適合你的 stack，再決定要不要花時間改寫 harness。若你在比較不同工具，請把技能裡的 fuzzer comparison table 當作決策輔助，而不是行銷摘要。

libfuzzer 技能 FAQ

libfuzzer 是不是適合當第一個 fuzzing 工具？

是的，前提是你的程式碼庫是 C/C++，而且本來就用 Clang 建置。這個 libfuzzer 技能是給那些想直接踏入 fuzzing，但不想一開始就導入更複雜分散式架構的團隊。

什麼情況下不該用 libfuzzer？

如果你的目標不是 C/C++、不能使用 Clang，或一開始就需要強大的多核心協調能力，就不適合從 libfuzzer 開始。這些情況下，libfuzzer 指南仍然可能幫你理解 harness 設計，但其他 fuzzer 可能更合適。

這跟直接請 ChatGPT 寫有什麼不同？

一般通用提示詞可以幫你草出 harness，但 libfuzzer 技能提供的是一個有工作流程感的起點：該怎麼提需求、哪些輸入重要、以及哪些環境假設要先講清楚。這能降低拿到一個「能編譯，但對安全稽核根本不好用」的 harness 的機率。

libfuzzer 到現在還適合做安全工作嗎？

適合。即使已是維護模式，libfuzzer 仍然是初期安全稽核很實用的選項，因為它安裝簡單、整合容易，而且如果之後規模變大，也能順利轉向 AFL++。

如何改進 libfuzzer 技能

提供正確的目標細節

品質提升最大的關鍵，在於明確指出實際函式或 parser 入口點、預期輸入格式，以及任何前置條件。例如，「fuzz ParseMessage(const uint8_t*, size_t)；bytes 是 UTF-8 text；不要使用磁碟或網路」會比「fuzz 我的 library」好得多。

說清楚你在意哪種失敗模式

如果你要找的是 crash、輸入驗證問題、特定 parser 路徑的覆蓋，或是回歸重現，請一開始就講明。這會影響 harness 的形狀，也會決定 libfuzzer 技能應該偏向最小包裝層、seed inputs，還是 corpus normalization。

檢查第一版 harness 是否有隱性耦合

常見的失敗模式包括共享全域狀態、持久快取，以及對合法長度或編碼的假設。如果第一版輸出不穩定，請要求更嚴格的 isolate-and-reset 版本 harness，並請它明確註記 sanitizer 注意事項；這在 libfuzzer 的 Security Audit 工作裡非常重要。

用真實輸入迭代，不要只做抽象修改

第一次產出後，請把崩潰樣本、代表性的 corpus 檔，或失敗的 build log 交給技能。這能讓 libfuzzer 技能把 harness 往真正有用的方向修正：更好的解析邊界、更安全的初始化，以及更貼近真實情境的 fuzzing 覆蓋。