fuzzing-dictionary
作成者 trailofbitsfuzzing-dictionary スキルは、パーサー、プロトコル、ファイル形式向けに、ドメイン固有のトークン、マジック値、プロトコル文字列を使った fuzzing dictionary の作成を支援します。盲目的なミューテーションでは行き詰まり、libFuzzer、AFL++、cargo-fuzz でより広いカバレッジが必要なときに役立ちます。
このスキルは 78/100 で、掲載候補として十分に有力です。どんな場面で使うべきかがすぐ分かり、一般的な fuzzing プロンプトよりも、ワークフローの情報があるため迷いにくくなっています。辞書駆動の fuzzing を再利用可能なガイドとして使いたい場合に向いていますが、ツール操作そのものよりは手法寄りです。
- パーサー、プロトコル、ファイル形式の fuzzing で使うべきタイミングが明確で、エージェントが適用判断しやすいです。
- 引用付きエントリ、16進エスケープ、トークン注入、libFuzzer・AFL++・cargo-fuzz 間のフォーマット差など、実務に直結する内容が充実しています。
- 本文に構造化された見出しとワークフローの संकेत があり、段階的に理解しやすく、エージェントの把握も速くなります。
- インストールコマンド、スクリプト、付属ファイルは用意されていないため、自動化やすぐ実行できるツールを期待しないほうがよいです。
- このスキルはエンドツーエンドの fuzzing 手順ではなく手法中心なので、対象ごとの辞書作成には外部コンテキストが必要になる場合があります。
fuzzing-dictionary skill の概要
fuzzing-dictionary skill は、fuzzing dictionary を作成・活用するための skill です。fuzzing dictionary とは、fuzzer をより深い parser、protocol、file-format のコードへ導くための、厳選された token、magic value、protocol string のことです。libFuzzer、AFL++、cargo-fuzz で fuzzing を行っていて、単純な mutation では行き詰まっているなら、fuzzing-dictionary skill は fuzz target を書き直さずに coverage を改善する現実的な方法を提供します。
この skill は、すでに動作する target はあるものの、validation が重いロジックまで十分に届かない人に特に向いています。reserved keyword、structured header、command verb、あるいは random fuzzing では見逃しやすい format 固有の constant を含む input では、特に効果的です。
fuzzing-dictionary が解決すること
主な役割は、「fuzzer が行き詰まっている」を、より誘導された input 戦略へ変えることです。適切な fuzzing dictionary があれば、早い段階での reject を回避し、stateful な parsing branch を開き、数個の見た目が妥当な token が揃って初めて現れる edge case を露出させやすくなります。
fuzzing-dictionary が最適な場面
fuzzing-dictionary は、認識しやすい token を持つ parser、protocol handler、file reader の fuzzing に使うのが最適です。input の構造が生の byte のカオスより重要なケースには強く、純粋な arithmetic、image transform、あるいは token 語彙を持たない logic-heavy なコードにはあまり向きません。
fuzzing-dictionary が他と違う理由
fuzzing-dictionary skill は、単に「文字列を増やす」ものではありません。対象の validation ルールと parse ルールに合う token を選び、それを fuzzer が実際に消費できる形に整えることに重点があります。そのため、見た目がそれらしく見えるだけの一般的な prompt よりも、実際に使える dictionary が必要なときに役立ちます。
fuzzing-dictionary skill の使い方
インストールして元ファイルを確認する
まずは directory install の流れを使います: npx skills add trailofbits/skills --skill fuzzing-dictionary。インストール後は SKILL.md から読み始め、同じ skill フォルダ内にリンクされている資料があれば続けて確認してください。この repo では skill が self-contained なので、主な source は skill file 自体です。
対象をそのまま使える prompt に変える
fuzzing-dictionary usage は、target の domain、input format、failure mode を具体的に渡したときに最も効果を発揮します。たとえば「自分の app 用の fuzzing dictionary を作って」と頼む代わりに、次のような情報を指定してください。
- parser または protocol の名前
- sample input や grammar のヒント
- 既知の keyword、header、magic byte、delimiter
- 使っている fuzzer と dictionary format の要件
- どの coverage が不足しているか、どこで validation が失敗するか
強い prompt の例は次のようになります: 「DNS 風 protocol parser 向けの fuzzing-dictionary を作成してください。一般的な record type、delimiter、control token を含め、AFL++ 用の形式で出力してください。」
skill は正しい順番で読む
この repository では、最も役立つ読み順は次のとおりです。
- ワークフローと適用条件のルールを確認するための
SKILL.md - dictionary entry と token category の inline example
- ターゲットに向いていない場合に skill を使わないための “When to Apply” ガイダンス
実用上の使い方のコツ
entry は短く、妥当そうで、domain-specific に保ってください。target が早い段階で input を reject することが分かっているなら、明らかな token に加えて境界値や不正な変種も少し混ぜます。最初の dictionary が一般的すぎる場合は、target が失敗する直前までに到達する正確な parse checkpoint に合わせて絞り込みます。
fuzzing-dictionary skill FAQ
fuzzing-dictionary は fuzzing 上級者だけのものですか?
いいえ。fuzzing-dictionary skill は、何を fuzzing するのかを把握していて、example input を用意できる初心者でも使えます。fuzzer の内部実装を深く知っている必要はありませんが、target の token vocabulary を説明できる程度の文脈は必要です。
どんなときにこの skill を使わないべきですか?
target に意味のある input token がない場合、guidance がなくても coverage が十分な場合、あるいは bottleneck が input の質ではなく harness の設計にある場合は、fuzzing-dictionary は使わないでください。dictionary は、壊れている fuzz target、crash 専用の bug、または corpus seed 不足が原因の問題は解決できません。
通常の prompt と何が違うのですか?
通常の prompt では、一般的な token list が返ってきがちです。fuzzing-dictionary skill のほうが有用なのは、install 可能なワークフロー、fuzzer 互換の formatting、そして dictionary が実際に coverage を改善する条件に沿っているからです。そのため、fuzzing-dictionary install の判断や、繰り返し使う用途に向いています。
すべての fuzzer に対応しますか?
libFuzzer、AFL++、cargo-fuzz を中心に、dictionary を扱いやすい主要な ecosystem に適しています。別の input mechanism を使う toolchain でも token 選定の考え方は流用できますが、使う前に必要な dictionary syntax を必ず確認してください。
fuzzing-dictionary skill を改善するには
対象の根拠をもっと具体的に出す
最良の fuzzing-dictionary guide 用 input は、target から取れた実際の token を含んでいます。たとえば protocol verb、enum name、field label、magic number、reserved keyword などです。小さな sample corpus や数個の失敗 input だけでも、曖昧な project 説明よりずっと token selection を改善できます。
用途ごとに token を分けて依頼する
fuzzing-dictionary for Code Generation を使うときは、token を役割別に分けてください。たとえば、必須 keyword、任意 modifier、boundary value、不正な変種です。そうすると、valid な parse path と、ほぼ正しい edge case の両方をカバーしやすくなり、単なる文字列の羅列で終わりません。
よくある失敗パターンに注意する
最大の失敗は、範囲が広すぎる dictionary、target の grammar に合わない entry、mutation に役立たないほど長い token です。最初の結果が一般的すぎると感じたら、1 つの parser、1 つの protocol command set、または 1 つの file format section に絞って再生成してください。
最初の実行後に反復する
最初の fuzzing では、どの token が実際に coverage を増やし、新しい state に到達させるかを確認します。そのあとで、不要な entry を削り、trace や log から見落とした keyword を追加し、むやみに拡大するのではなく、より小さく精密な fuzzing-dictionary を再生成してください。
