これはAFL++が完全に処理できる単純なローカルターゲットであり、単なる例として簡単に示したものです。Litefuzzは、ネットワークやGUIファジングにおいてはるかに多くのことを行うように設計されており、詳しく見ていくとそれがわかるでしょう。

## なぜ

そう、また別のファザーです。しかも現在のトレンドや慣習にあまり沿っていないものです。特定の要件に対応するためにトレードオフが行われました。その要件とは、複数のプラットフォームでデフォルトで動作し、ローカルターゲットとネットワークターゲットの両方をファズでき、非常に使いやすいファザーであることです。何かを誰かに納得させようとしているわけではありませんが、背景を説明しましょう。一部のターゲットでは、AFLのようなファザーをビルドチェーンに統合するのに多大な労力が必要です。このファザーは計装を必要としないため、そのような問題はありません。計装による正確なカバレッジを犠牲にして、使いやすさと移植性を優先しています。また、AFLはそのままでネットワークファジングをサポートしておらず、それをサポートするAFLベースのプロジェクトも存在しますが、それらは決して簡単に使えるものではなく、動作させるためにより多くのコード修正やハーネスが必要になることがほとんどです（[Libfuzzer](https://llvm.org/docs/LibFuzzer.html)も同様の状況です）。

並列ファジングは行わず、[パーシステントモード](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html)が提供するような驚異的な速度向上もサポートしていないため、そのような機能を持つファザーに近いスケーラビリティはありません。繰り返しますが、これは最先端のファザーではありません。しかし、ソースコードやビルドの適切なセットアップ、特定のOS機能を必要としません。ネットワーククライアントのGUIやインタラクティブアプリケーションをファズすることもできます。多くの点で「Live off the Land」的であり、ミューテーターやミニマイゼーションなどの多くの機能はゼロから書かれています。

「そのまま動く」ように設計されており、必要なわずかな依存関係のセットアップとインストールを自動化するために努力が払われています。このファザーは目的を果たすために書かれており、さまざまなターゲットシナリオや環境で価値を提供し、最も重要なのは、すべてのファザーが最終的に評価されるべき点、つまりバグを見つける能力です。そして**実際に** [バグ](https://github.com/sec-tools/beta/blob/main/README.md#trophies) を見つけています。ターゲットのソースコードがあることを前提としていないため、クローズドソースソフトウェアでもかなりうまくカバーできます。自動化の一部としてほとんど修正なしで実行できますが、脆弱性研究者にとって楽しく使えるように作られています。ただし、完成品というよりも研究開発プロジェクトと考えるほうが有用です。また、複雑なセットアップは不要で、そのままで少し壊れていたり、最新のOSで動作させるためにさらに作業が必要ということはありません。

Ubuntu Linux、Mac、Windowsで動作確認済みで、ファジング準備完了の環境をセットアップするためのほぼすべてを自動化する完全なスクリプトが付属しています。

**セットアップスクリプトが完了すれば、さまざまなターゲットのファジングを開始するのにほんの数分しかかかりません。**

## 仕組み

**Litefuzzは、ローカル、クライアント、サーバーの3つの異なるモードをサポートしています。**

ローカルモードは、ローカルバイナリをターゲットにすることを意味します。Linux/Macでは、サブプロセス経由で起動され、クラッシュ時にそれぞれGDBとLLDBによる自動トリアージがサポートされ、Windowsでは[WinAppDbg](https://github.com/MarioVilas/winappdbg)を介して行われます。クラッシュはローカルのクラッシュディレクトリに書き込まれ、読み取り/書き込みAVやSIGABRT/SIGSEGVなどの障害タイプとファイルハッシュでソートされます。ファジング中にすべてのユニークなクラッシュがトリアージされ、このデータはターゲットの出力（利用可能な場合）とともにキャプチャされ、同じディレクトリにアーティファクトとして配置されます。また、`--replay`とクラッシュファイルを指定してクラッシュを再現することも可能です。`local`クライアントモードでは、入力ディレクトリにサーバーのグリーティング、レスポンス、またはクライアントがサーバーに接続する際に期待するデータを含める必要があります。

現時点では、ネットワークファジングのために複雑なセッションサポートなしで1回の「ショット」のみ実装されています。クライアントはコマンドラインから起動され、ファイルファジングと同じ方法でデバッグされます。このシナリオをサポートするためにリスナーがセットアップされます。はい、遅くてほぼ手動に近いですが、動作します。クラッシュが検出されると、gdbで再現されてトリアージの詳細が取得されます。`remote`クライアントモードでは、ローカルデバッグ/クラッシュトリアージがないことを除いて同じように動作します。*local*サーバーモードでは、ローカルクライアントモードと似ており、`remote`サーバーモードでは、指定されたターゲットに接続し、ユーザーが入力として指定した変異したサンプルクライアントデータを送信しますが、「まだ接続できるか、できなければ最後のデータでクラッシュした可能性が高い」という単純なトリアージのみ提供されます。

いくつかのミューテーション関数がゼロから書かれており、主に`-i`フラグで指定された入力のランダムな選択に対してランダムなミューテーションを行います。ファイルファジングの場合は、ローカルモードを選択し、アプリが解析するファイル名を期待する場所にFUZZを指定したターゲットコマンドライン（例：`tcpdump -r FUZZ`）と、ミューテーションする「良質なファイル」の入力ディレクトリを渡すだけです。ネットワーククライアントファジングの場合は、ローカルファジングと似ていますが、`-a`で接続詳細も指定します。サーバーをファズしたい場合は、サーバーモードにして、クライアントと同様に`protocol://address:port`を指定します。

ほとんどのCLIアプリケーションのように、ターゲットがデータを消費して終了する速度、またはローカル実行やネットワーク接続のタイムアウト前に必要と判断した時間だけ高速にファズします。これにより、かなり遅くなる可能性があります。派手なexecやカーネルトリックはありません。もちろん、入力を解析してすぐに終了するようなハーネスを書けば、ターゲットの特定の部分をカバーするのに役立ちます。しかし、その場合、ターゲットにそこまで近づけるのであれば、他のファザーが提供する[パーシステントモード](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html)や類似の機能を使ったほうがよいでしょう。

つまり...

### できること
- linux、windows、macで動作し、py2/py3をサポート
- ファイル/標準入力から読み取るCLI/GUIバイナリをファズ
- ネットワーククライアントとサーバー（オープンソースまたはプロプライエタリ）をファズし、ローカルまたはリモートでデバッグ可能
- クラッシュの差分、ミニマイゼーション、リプレイ、ソート、自動トリアージ
- TLSサポート、golangバイナリファジング、Mac用の追加機能などのその他
- さまざまな内蔵ミューテーターとpyradamsa（Linux）で入力を変異

### できないこと
- ネイティブ計装
- 並行ジョブでのスケーリング
- 複雑なセッションファジング
- リモートクライアントとサーバーの監視（接続などの基本的なチェックのみ）

## サポート

主に**Ubuntu Linux 20.04**（22.04と21.04は軽くテスト）、**Windows 10**、**Mac OS 11**（12は軽くテスト）でテストされています。ファザーとセットアップスクリプトは、これらのOSの少し古いバージョンや新しいバージョンでも動作する可能性がありますが、研究、テスト、開発の大部分はこれらの環境で行われました。Python3がサポートされており、[WinAppDbg](https://github.com/MarioVilas/winappdbg)を介してWindows上でファジングするために必要なPython2との互換性も確保するよう努められています。

プラットフォームのテストは主にIntelベースのハードウェアで行われましたが、AppleのM1プラットフォームでもほぼ動作するようです（顕著な例外として、LinuxではGDBのexploitableプラグインがサポートされていないと思われ、Pyradamsaも同様です）。また、setup/にはほとんどのタスクと依存関係のインストールを自動化するセットアップスクリプトがあります。一般的に各プラットフォームのネイティブバイナリ（多くの場合C/C++でコンパイル）をファズできますが、Golangバイナリのクラッシュもキャッチできます（実験的）。

### Pythonバージョン

Python3はLinuxとMacでサポートされ、WindowsではPython2が必要です。

なぜLinuxとMacでPy3なのか？ Pyautogui、Pyradamsa（Linuxのみ）、Macでのソケットサポートの向上。

なぜWindowsでPy2なのか？ WinappdbgがPy2を必要とするため。

### Linux

デバッグにはGDB、クラッシュトリアージには[exploitable](https://github.com/jfoote/exploitable)を使用します。OSSの場合は、[サニタイザ](https://fuzzing-project.org/tutorial2.html)などを使ってターゲットをビルドおよび計装できます。そうでない場合は、実行時にロードできる[メモリデバッガ](https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Heap_corruption)もあります。

このインストールは、Pythonの依存関係やその他の便利なものとともに、[setup/linux.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/linux.sh)で自動化されています。推奨OSはUbuntu 20.04です。これは、ほとんどのテストが行われた環境だからです。

### Mac

gdbの代わりに、OS Xではlldbを使用します。これはXCodeコマンドラインツールに含まれています。管理者またはdeveloperグループに属していればlldbを使用できるはずですが、この動作は環境やバージョンによって異なる可能性があり、どうしてもうまくいかない場合はsudo権限で実行する必要があるかもしれません。

手動で行う必要があるのは、SIPを無効にすることだけです（リカバリモードでcmd+R、またはVMware Fusionのハックを使用）。そうしないと、Tim AppleのOSでファジングするときに自動トリアージが失敗します。

セットアップのほぼすべては[setup/mac.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/mac.sh)スクリプトで自動化されているので、それを使ってすぐに開始できます。

### Windows

[WinAppDbg](https://github.com/MarioVilas/winappdbg)はWindowsでのデバッグに使用されますが、標準入力ファジングがサポートされていないという小さな注意点があります。

他のOSの自動セットアップと同様に、ChocolateyがWindowsでのパッケージインストールを自動化するのに役立ちます。litefuzzのルートディレクトリで[setup/windows.bat](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/windows.bat)を管理者として実行して、インストールを自動化してください。デバッグツールやその他の依存関係がインストールされ、スムーズに動作するようになります。

### ターゲット

以下は、テストされ、一般的にサポートされているターゲットのタイプのリストです。

* ファイル形式や標準入力を解析するローカルCLI/GUIアプリ
  - デバッグサポート

* サーバーレスポンスを解析するローカルCLI/GUIネットワーククライアント
  - CLIのデバッグサポート
  - GUIの限定的なデバッグサポート

* クライアントリクエストを解析するローカルCLIネットワークサーバー
  - デバッグサポート（注意：スタンドアロン実行可能ファイルとして実行できる必要があります。そうでない場合は*リモート*として扱うことができます）

* クライアントリクエストを解析するローカルGUIネットワークサーバー
  - 理論的にはサポート、未テスト

* サーバーレスポンスを解析するリモートCLI/GUIネットワーククライアント
  - デバッグサポートなし

* クライアントリクエストを解析するリモートCLI/GUIネットワークサーバー
  - デバッグサポートなし
  - ただしMacでは`attach`または`reportcrash`機能を使用する場合例外

繰り返しますが、このファザーはLinux、Mac、Windows上のローカルアプリ、クライアント、サーバーで動作・サポートし、もちろんターゲットプラットフォームに依存せずにリモートのものをファズすることもできます。

### トリアージ

* ファイル形式や標準入力を解析するローカルCLI/GUIアプリ
  - アプリを実行し、シグナルをキャッチ、クラッシュ入力を使用してデバッガ内で再実行し再現

* サーバーレスポンスを解析するローカルCLI/GUIネットワーククライアント
  - アプリを実行し、シグナルをキャッチ、クラッシュ入力を使用してデバッガ内で再実行し再現

* クライアントリクエストを解析するローカルGUI/CLIネットワークサーバー
  - デバッガ内でアプリを実行し、シグナルをキャッチ、クラッシュ入力を使用してデバッガ内で再実行し再現

* サーバーレスポンスを解析するリモートCLI/GUIネットワーククライアント
  - 可視性なし、リモート側からクラッシュを収集
  - トリアージを支援するスクリプトを手動で作成可能

* クライアントリクエストを解析するリモートCLI/GUIネットワークサーバー
  - 可視性なし、リモート側からクラッシュを収集
  - トリアージを支援するスクリプトを手動で作成可能
  - Macの例外として、`attach`および`reportcrash`オプションを使用してトリアージ機能の一部を有効にできる

## はじめに

プラットフォーム間のセットアップのほとんどは、[setup](https://github.com/sec-tools/litefuzz/blob/main/README.md#setup)ディレクトリのスクリプトで自動化されています。

litefuzzルートからそれらを実行するだけで、多くの時間を節約でき、自動化されたデプロイに必要なものの一部を有効にするのに役立ちます。クリーンなOSとファジング環境をセットアップするためにVMを使用すると便利です。特にスナップショット機能が役立ちます。

詳細は[INSTALL.md](https://github.com/sec-tools/litefuzz/blob/main/INSTALL.md)を参照してください。

**インストール後、最初のセクションにあるlatex2rtfのファジング例を参照して素早く試すか、このREADMEで詳しく説明されているすべてのコマンドラインオプションとその他の例を参照してください。**

### Docker

Dockerを使用して、`Dockerfile`を使ってローカルに依存関係をインストールせずにlitefuzzを実行できます。これは、簡単なテストやシステムに依存関係をインストールしたくない場合に特に便利です。

Dockerfileは次の両方で動作します：
- **リポジトリ内から** - ローカルファイルを使用（高速、ローカルの変更を含む）
- **スタンドアロン** - 任意のディレクトリからビルド可能（GitHubからクローン）```bash
# Build the Docker image (from any directory with Dockerfile)
docker build -t litefuzz:latest .

# Run litefuzz
docker run --rm litefuzz:latest python3 litefuzz.py --help

これは次のことを行います：
- latex2rtfを1000回のイテレーションでファズする
- ヒープデバッグを使用する（`-z`フラグ）
- クラッシュをホスト上の`./crashes`ディレクトリに保存する
- リポジトリの`/litefuzz/input/tex`にある組み込みの入力ファイルを使用する

ホストから独自の入力ファイルを使用したい場合：```bash
# Create input directory with your test files
mkdir -p input/tex crashes
# Add your test files to input/tex/
cp your-test.tex input/tex/

# Run fuzzing with your input files
docker run --rm \
  -v $(pwd)/input:/litefuzz/input \
  -v $(pwd)/crashes:/tmp/crashes \
  litefuzz:latest \
  python3 litefuzz.py -l -c "latex2rtf FUZZ" -i /litefuzz/input/tex -o /tmp/crashes -n 1000 -z

これにより、メインディレクトリ内で `test_litefuzz.py` のpytestが実行され、テスト実行終了時にPASS/FAIL結果が表示されます。

#### crashing app tests
異なるプラットフォームでのクラッシュおよびトリアージ機能をテストするための、バグのあるアプリの例が `test` フォルダにいくつかあります。

- (a) null pointer dereference (ヌルポインタ参照)
- (b) divide-by-zero (ゼロ除算)
- (c) heap overflow (ヒープオーバーフロー)
- (d-gui) format string bug in a GUI (GUIのフォーマット文字列バグ)
- (e) buffer overflow in client (クライアントのバッファオーバーフロー)
- (f) buffer overflow in server (サーバのバッファオーバーフロー)

これらはセットアップ中に自動的にビルドされ、コマンドライン、デバッガ内で実行したり、ファジングターゲットとしてテストに使用できます。

**Windowsのコマンドラインで実行する場合は、`イベントビューアー -> Windows ログ -> アプリケーション` でクラッシュを確認してください。**

## options
さまざまなターゲットシナリオを活用するための、多種多様なオプションと機能があります。以下に簡単な説明と、それらを使用する方法を理解するための例を示します。

### crash directory
`-o` を使用すると、デフォルトのローカルパスの crashes/ 以外のクラッシュディレクトリを指定できます。これを使用すると、異なるアプリに対する複数の同時ファジング実行のクラッシュフォルダを管理できます。

### insulate mode
`-u` は、通常のファジングプロセスからターゲットアプリケーションを隔離します（例：実行やパケットの反復送信とクラッシュのチェックを行わない）。代わりに、このモードはインタラクティブなクライアントアプリケーション（例：Postman）向けに作られており、アプリケーション内でスクリプトを実行してクライアントファジングの接続を繰り返すことができます。ターゲットはデバッガ内で実行され、ファザーは一時停止してユーザーがいくつかのボタンをクリックするか、ターゲットの設定を自動実行に変更する時間を確保します。ユーザーが再開すると、インタラクティブなネットワーククライアントのファジングが行われます。

`litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -z`

Insulate mode + refresh はインタラクティブクライアントに使用できます。例えば、FileZillaをデバッガで実行し、新しいイテレーションごとにF5を押してサーバに再接続させることができます。また、ローカルCLI/GUIサーバのファジングは、デバッガ内で一度だけ起動・実行され、処理をより効率的にします。

`--key` を使用すると、インタラクティブターゲットのファジング中にキーを送信することもできます。例えば、F5で「接続の更新」を送信して、FileZillaのFTPサーバ応答の解析をファジングできます。

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp/filezilla -u -pp --key "F5" -n 100 -z glibc`

注意：insulate mode は Linux でのみテストされており、Windows ではサポートされていません。

### timeout
`-x secs` を使用するとタイムアウトを指定できます。実際には、これはCLIターゲットの場合は「イテレーション間のおおよその時間」に近く、GUIの場合は実際のタイムアウトとして機能します。

### mutators
`--mutator N` はファジングに使用するミューテータを指定します。このオプションが指定されない場合、利用可能なミューテータのリストからランダムに選択され、各ファジングイテレーションで使用されます。

これらのミューテータは（もちろんRadamsaを除いて）スクラッチから書かれました。そして、何百万回ものイテレーションで広範囲にテストされ、良好に動作していますが、時折微妙なバグが存在する可能性があります。ただし、通常は機能に影響を与えることはありません。```
FLIP_MUTATOR = 1
HIGHLOW_MUTATOR = 2
INSERT_MUTATOR = 3
REMOVE_MUTATOR = 4
CARVE_MUTATOR = 5
OVERWRITE_MUTATOR = 6
RADAMSA_MUTATOR = 7

### 一時停止
Ctrl+c を押してファジングプロセスを一時停止します。再開する場合は `y` を、停止する場合は `n` を選択します。この機能はプラットフォーム間で正常に動作しますが、GUI アプリケーションのファジングでは信頼性が低くなる可能性があります。

### クラッシュの再利用による亜種発見

`-e` は再利用モードを有効にします。つまり、ファジング実行中にクラッシュが見つかった場合、それらを入力として使用して 2 回目のファジングラウンドを実行し、さらに多くのバグを発見するのに役立ちます。`-z` と組み合わせて `-ez` バグを！ ダダン。

次の例は、antiword を 100000 回の反復でファジングし、その後、同じ反復回数とオプションでもう一度実行を開始して、クラッシュを入力として再利用し、さらに多くのバグを見つけようとします。

`litefuzz -l -c "antiword FUZZ" -i docs -n 100000 -ez`

（または、クラッシュを手動で入力ディレクトリにコピーして、再利用実行の反復回数を直接制御することもできます）

`litefuzz -l -c "antiword FUZZ" -i docs-crashes -n 500000 -z`

注: このモードはローカルアプリケーションでのみサポートされています。

### メモリデバッグヘルパー
`-z` は、Linux では Electric Fence（フォールバックとして glib malloc デバッグ）、Mac では Guard Malloc、Windows では PageHeap を有効にします。また、`-zz` を使用すると、アプリケーションに対して PageHeap を有効にした後、無効にすることができます。ファジッカーを起動せずにオン/オフを切り替えたい場合は、`-i` フラグを省略するだけです。Windows のセットアップ中には、[gsudo](https://github.com/gerardog/gsudo) がインストールされ、コマンドラインで昇格したコマンドを実行するために使用できます。例：ターゲットに対して PageHeap を有効にするなど。

`sudo litefuzz -l -c "notepad FUZZ" -i texts/files -z`

`sudo litefuzz -l -c "notepad FUZZ" -zz`

Linux では、特定のヘルパーを選択できます。たとえば、フォールバックとして glib malloc を使用する代わりに、それを選択することもできます。

`litefuzz -l -c "geany FUZZ" -i texts/codes -z glibc`

デフォルトの Electric Fence malloc デバッガは優れていますが、すべてのターゲットで動作するわけではありません。ターゲットを EF でテストし、クラッシュする場合は代わりに glibc ヘルパーを選択してください。

### ライブターゲット出力の確認
Linux または Mac でローカルアプリをファジングする場合、`cat /tmp/litefuzz/RUN_ID/fuzz.out` でターゲットの最新の標準出力を確認できます。`RUN_ID` はファジング開始時に STATS 情報領域に表示されます。クラッシュが発生した場合、標準出力はクラッシュディレクトリに `.out` ファイルとしてキャプチャされます。グローバルな標準出力／標準エラー出力も `/tmp/litefuzz/out` に保存され、デバッグ目的で使用されます（インシュレートモードまたはローカルサーバーモードを除く。これらのモードではデバッガ出力は `/tmp/litefuzz/RUN_ID/out` に送られます）。

Winappdbg はターゲットの標準出力のキャプチャをネイティブでサポートしていないため（AFAIK）、この成果物は Windows では利用できません。

### クライアントモードとサーバーモード
サーバーをローカルで実行し、単にバイナリを実行するだけで（フラグや設定の有無を問わず）起動できる場合、そのコマンドラインを `-c` で渡すと、各反復ごとに新しい実行でサーバーが起動、ファジング、強制終了されます。この考え方は、速度を犠牲にする代わりに、ターゲットのメモリが「特定の状態」にある場合にのみトリガーされる厄介なバグを回避できるというものです。これにより誤検出が減少します。ネットワーククライアントをローカルでファジングする場合も同様です。TLS 接続もサポートしており、その場で証明書を生成します（サーバーをファジングする際にクライアント証明書が必要で、その証明書自体のファジングも別のアイデアです）。

Litefuzz はリモートクライアントおよびサーバーをファジングする際のデバッグサポートを提供しないため、そのリモート側での設定はユーザーに任されます。サーバーの場合、サーバーが応答を停止したかどうかを確認し、最後のペイロードをクラッシュ原因として記録します。これは TCP 接続ではうまく機能しますが、UDP サービスではこの余裕はありません。そのため、リモートサーバーの監視は、ReportCrash 機能（Mac で利用可）、デバッガ内でのターゲット実行（ローカルサーバーモードまたは手動）、またはカスタムサポートスクリプトの作成に任されています。また、一部のサーバーはクラッシュ後に自動再起動または回復する場合がありますが、ログやファイルシステム上の他の成果物にその兆候が見られることがあり、特定のターゲット用に作成されたサポートスクリプトで解析できます。

### ローカルネットワークの例

`litefuzz -lk -c "wget http://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -o crashes/curl --tls -n 100000 -z`

（Wireshark を開き、ダンプから応答をキャプチャし、Simple Network Management Protocol を右クリック -> Export Packet Bytes -> resp.bin）

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a localhost:8000 -i input/shouts -z`

`litefuzz -ls -c "snmpd" -i input/snmp -a udp://localhost:161 -z`

**クイックノート**
- UDP ソケットは Mac + Py2 では少し動作がおかしい場合があるため、Mac + Py3 のみテストおよびサポートされています。
- Windows でのローカルネットワーククライアントファジングは不安定な場合があり、現時点では実験的と見なすべきです。

### リモートネットワークの例

リモートクライアントとサーバーのファジングはもう少し難しいです。ローカルデバッグはなく、ネットワークを介した両者間のやり取りの停止を捉えてクラッシュを検出します。また、相手側で何が起こっているかはおそらく見えないため、クライアントまたはサーバーが応答を停止するとファジングは終了し、ユーザーがリモート側でスクリプトを設定してこのプロセスを管理しない限り、クライアントまたはサーバーが通常の（クラッシュしていない）状態に復元された後に手動で再起動する必要があります。

UDP はこれをさらに複雑にします。UDP ポートにリッスンサービスがあるかどうかをテストパケットを送信しても、応答が保証されるわけではありません。そのため、リモートでネットワーククライアントとサーバーをファジングすることは可能ですが、可視性にはトレードオフがあります。

#### クライアント

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -pp -n 100`

クライアントモードはここではさらに扱いにくいです。なぜなら、クライアントが実際にクラッシュして再接続していないのか、それとも send/recv のやり取りが単にずれているのかを判断するのが難しいからです。クライアントはそれぞれ異なる方法で接続を処理できるためです。また、これは単なる例であり、リモートクライアントファジングは性質上厄介で、ある程度実験的と見なすべきであることに注意してください。

#### サーバー

サーバーをローカルでファジングするかリモートでファジングするかのメリットとデメリットは、両方のオプションが利用可能な場合にターゲットにどのようにアプローチするかの決定に役立ちます。

基本的に、デバッガ内でサーバーをファジングする方が遅くなりますが、自動トリアージでクラッシュログを取得できます。一方、サーバーをリモートモードでファジングする（ローカルホストを指定しても）と平均してはるかに高速になりますが、高い可視性やデバッガベースのトリアージ機能は失われますが、クラッシュごとに手動でサーバーを再起動して終了する前に続行する時間が得られます（TCP サーバーのみ。この機能は UDP ベースのサーバーをサポートしません）。

**Shoutcast**

`./sc_serv ...`

`litefuzz -s -a localhost:8000 -i input/shouts -n 10000`

**SSHesame**

`sshesame`

`litefuzz -s -a tcp://target:2022 -i input/ssh-server -p -n 1000000 -x 0.05`

**FTP**

`litefuzz -s -a tcp://target:21 -i input/ftp/req.txt -pp -n 1000`

**DNS**

`coredns -dns.port 10000`

`litefuzz -ls -c "coredns -dns.port 10000" -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

または

`litefuzz -s -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

##### TLS

`litefuzz -s -a tcp://hostname:8080 -i input/http --tls -n 10000````
...
@ 48/10000 (1 crashes, 0 duplicates, ~7:13:18 remaining)

[!] check target, sleeping for 60 seconds before attempting to continue fuzzing...

各パケットは配列に取り込まれ、ランダムなインデックスが変異され、ターゲットをファズするために再生されます。

`litefuzz -lk -c "ssh -T test@localhost -p 2222" -a tcp://localhost:2222 -i input/ssh -o crashes/ssh -p -n 250000 -z glibc`

そして、最新のイテレーションにおけるターゲットの出力を確認できます。```
cat /tmp/litefuzz/out
kex_input_kexinit: discard proposal: string is too large
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: string is too large

... and others like

ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: unknown or unsupported key type

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Host key verification failed.

Bad packet length 1869636974.
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: message authentication code incorrect

ファザーは各行を独自のFTP応答に分割し、クライアントのセッション処理をファズします。ただし、クライアントが「適切に動作」したり、セッションが正常に完了するような振る舞いをする保証はないため、Wiresharkを実行しながらセッションテストケースを試行錯誤し微調整することで、ターゲット間の相互作用の違いを理解するのに役立ちます。

`litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z`

これは、FileZillaのようなGUIネットワークターゲットを隔離するために *-u* と組み合わせることもできます。

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc`

### プロセスへのアタッチ
ターゲットが接続時に新しいプロセスを生成する場合、サーバーへの接続が確立された後にアタッチするプロセス名（またはPID）を指定できます。これは、例えばlaunchdがポートで待ち受け、クライアントが接続したときにのみ処理プロセスを起動する場合に便利です。これは、ローカルファジングとリモートファジングの境界を曖昧にする機能の一つで、技術的にはファザーはリモートモードですが、ターゲットアドレスをlocalhostとして指定し、プロセスにアタッチするよう要求します。

`./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000`

注：現在この機能はMac（LLDB）とネットワークファジングでのみサポートされていますが、実装されればLinux（GDB）でも問題なく動作するはずです。

### クラッシュアーティファクト
ファジング中にクラッシュが発生すると、デバッガでリプレイされ、デバッグアーティファクトとバケット情報が生成されます。情報はプラットフォームによって異なりますが、一般的にはバックトレース、レジスタ情報、`!exploitable` タイプの情報（利用可能な場合）、その他の基本情報を含むテキストファイルが生成されます。

**メモリダンプ**は、Windowsでは `--memdump` を渡すことで有効に、`--nomemdump` で無効にできます。これは、mallocデバッガがそれぞれ `-z` と `-zz` で制御されるのと同様です。有効にすると、ダンプはコンソールデバッガ (cdbg) にも読み込まれ、`!analyze -v` クラッシュ分析出力が追加のメモリダンプクラッシュ分析ログにキャプチャされます。Winappdbgには既に初期クラッシュ分析で得られる !exploitable タイプの分析があるため、ここでは !analyze のみを行います。

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump`

または、アプリケーションのメモリダンプを無効にするには

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump`

自動クラッシュトリアージに加えて、バイナリ/文字列の差分（適切に）とターゲットのstdout（プラットフォーム/ターゲット依存）も生成され、もちろん再現ファイルも生成されます。

ローカルファジングでは、アーティファクトには通常、差分、stdout（Linux/Macのみ）、再現ファイル、クラッシュログおよび情報ファイルが含まれます。```
$ ls crashes/latex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.out
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.tex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.txt

リモートファジングの場合、選択されたオプションによって成果物は異なりますが、多くの場合、差分、再現ファイルや再現ファイルディレクトリ（入力が複数のパケットを含むセッションの場合）、以前のファジング反復の再現（リモートファジングには課題があるため、実際にクラッシャーである場合にバグを失うことを防ぐ）、クラッシュログや簡単な情報ファイルが含まれます。```
ls crashes/serverd
REMOTE_SERVER_testbox.1_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_PREV_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diff
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diffs
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.txt
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.zz

ls crashes/serverd/REMOTE_SERVER_localhost_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_1.zz	REMOTE_SERVER_localhost_NNNN_2.zz
REMOTE_SERVER_testbox.1_NNNN_3.zz	REMOTE_SERVER_localhost_NNNN_4.zz

最小化されたバージョンをご覧ください。```
GET /admin.cgi?mode=debug&option=a
Authorization:s YWRtaW46Y2hhbmdlbWU
Referer:admin.cgi

**最小化の例**

`litefuzz -l -c "latex2rtf FUZZ" -m test.tex -z`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a "tcp://localhost:8000" -m repro.http`

**supermin の例**```
litefuzz -l -c "latex2rtf FUZZ" -mm crashes/latex2rtf/test.tex -z
...
[+] starting minimization

@ 582/582 (1 new crashes, 1145 -> 582 bytes, ~0:00:00 remaining)  

[+] reduced crash @ pc=55555556c141 -> pc=55555557c57d to 582 bytes

[+] supermin activated, continuing...

@ 299/299 (1 new crashes, 582 -> 300 bytes, ~0:00:00 remaining)

[+] reduced crash @ pc=55555557c57d to 300 bytes
...
[+] reduced crash @ pc=555555562170 to 17 bytes

@ 17/17 (2 new crashes, 17 -> 17 bytes, ~0:00:00 remaining)

[+] achieved maximum minimization @ 17 bytes (test.min.tex)

[RESULTS]
completed (17) iterations with 2 new crashes found

#### Ubuntu でのファイルハンドラの列挙```
$ cat /usr/share/applications/defaults.list
[Default Applications]
application/csv=libreoffice-calc.desktop
application/excel=libreoffice-calc.desktop
application/msexcel=libreoffice-calc.desktop
application/msword=libreoffice-writer.desktop
application/ogg=rhythmbox.desktop
application/oxps=org.gnome.Evince.desktop
application/postscript=org.gnome.Evince.desktop
....

**stdin経由のgpg復号をヒープエラーチェックでファズ** (Mac)

`litefuzz -l -c "gpg --decrypt" -i test-gpg -o crashes-gpg -z`

**Booksアプリのファズ** (Mac GUI)

`litefuzz -l -c "/System/Applications/Books.app/Contents/MacOS/Books FUZZ" -i test-epub -t "/Users/test/Library/Containers/com.apple.iBooksX/Data" -x 8 -n 100000 -z`

注: `-z`は[Guard Malloc](https://www.manpagez.com/man/3/libgmalloc/)のヒープエラーチェックを有効にし、微妙なヒープ破損バグを検出します。

**macの注意**

一部のGUIターゲットは、各イテレーションのタイムアウト後に強制終了できず、応答しなくなる場合があります。これを軽減するには、別のターミナルで以下のようなスクリプトを実行し、定期的にそれらを一括で強制終了することで手動の手間と監視を減らせます。そうしないと、ファジングプロセスに影響が出る可能性があります。```
#!/bin/bash
ps -Af | grep -ie "$1" | awk '{print $2}' | xargs kill -9

*/Users/test*（一時ファイルがローカルGUIアプリに渡されるパスの最初の部分の例です。実行中にFUZZがパスになります。）は、プロセスを強制終了するためにユニークな文字列が必要であり、プロセス名のみを使用すると、ファジングプロセスにもその名前が含まれるため停止してしまうからです。

**Windows上でのファイルハンドラの列挙**

[AssocQueryString](https://github.com/sec-tools/WindowsFileHandlerEnumeration/) スクリプトと *assoc* コマンドを使用すると、ファイル拡張子をデフォルトアプリケーションにマッピングできます。```
C:\> .\AssocQueryString.ps1
...
.hlp :: C:\Windows\winhlp32.exe
.hta :: C:\Windows\SysWOW64\mshta.exe
.htm :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.html :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.icc :: C:\Windows\system32\colorcpl.exe
.icm :: C:\Windows\system32\colorcpl.exe
.imesx :: C:\Windows\system32\IME\SHARED\imesearch.exe
.img :: C:\Windows\Explorer.exe
.inf :: C:\Windows\system32\NOTEPAD.EXE
.ini :: C:\Windows\system32\NOTEPAD.EXE
.iso :: C:\Windows\Explorer.exe

#### local client

**ローカルホスト上のSNMPクライアントをファズする（Linux）**

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

#### remote client

**リモートFTPクライアントをファズする（Linux）**

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -n 100`

注：ターゲットによっては、クライアントファジングには特権ポート（1-1024）でのリッスンが必要になる場合があります。この場合、LinuxではPythonインタプリタに `setcap cap_net_bind_service=+ep` を設定するか、ファザー実行時にsudoを使用してください。Macではsudoを使用し、Windowsでは管理者としてファザーを実行して、Permission Deniedエラーを回避してください。

### server

#### クイックルック```
litefuzz -ls -c "./sc_serv shoutcast.conf" -a tcp://localhost:8000 -i input/shoutcast -o crashes/shoutcast -n 1000 -z
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id:     4001
cmdline:    ./sc_serv shoutcast.conf
address:    tcp://localhost:8000
crash dir:  crashes/shoutcast
input dir:  input/shoutcast
inputs:     3
iterations: 1000
mutator:    random(mutators)

@ 1000/1000 (1 crashes, 7 duplicates, ~0:00:00 remaining)

[RESULTS]
> completed (1000) iterations with (1) unique crashes and 7 dups
>> check crashes/shoutcast for more details

# trophies

Litefuzz は以下のような様々なソフトウェアパッケージからクラッシュをファジングしてきました。

* antiword
* AppleScript (OS X)
* ArangoDB VelocyPack
* Avast authenticode-parser
* Avast RetDec
* BBC Audio Waveform
* ColorSync (OS X)
* Dynamsoft BarcodeReader
* eot2ttf
* evernote2md
* faad2
* Facebook's Origami Studio
* FontForge
* ForestDB
* Gifsicle
* GPUJPEG
* GPAC Multimedia Framework
* Google Draco
* Google Quipper
* GoPro GPR
* GtkRadiant
* IIPImage Server
* John The Ripper
* Kyoto Cabinet
* latex2rtf
* libMeshb
* libembroidery
* libsndfile
* Lion Vector Graphics (lvg)
* L-SMASH
* mp3-decoder
* MindNode
* minimp4
* MiniWeb Server
* MLpack
* Nvidia Data Center GPU Manager
* Numbers (OS X)
* OpenJPEG
* OpenOrienteering Mapper
* OSM Express
* Pages (OS X)
* PBRT-Parser
* Pixar USD
* Remote Apple Events (OS X)
* Samsung rlottie
* Samsung ThorVG
* Shoutcast Server
* Silo
* syslog (OS X)
* Tencent NCNN
* TinyXML2
* UEFITool
* Ulfius Web Framework
* zlib

# FAQ

## このプロジェクトはどのようにして生まれたのですか？
ファジングは楽しいです！また、ファジラーがバグを見つけるという最終目標を達成するために、常に現代的なアプローチや人気のある方法に従う必要はないという逆張りの視点を取るプロジェクトをやるのも良いものです。ベアメタルに近いところで動くか、すべてのパスでコードカバレッジを取得するか、あるいは高速で柔軟な方法に最適化するか、根本的な「前提を無効にする」というやり方など、どのように現れるにせよ、楽しんでください。

## このプロジェクトは積極的にメンテナンスされていますか？
プロジェクトに対する積極的なサポートやメンテナンスは期待しないでください。新しい機能を追加したりバグを修正したりするために、自由にフォークしてください。小さなことについてはプルリクエストを送っても構いませんが、返信やトラブルシューティングの期待はしないでください。このリポジトリでの開発が活発に行われることは意図されていません。

## ファジラーがうまく動作しているかどうか、また他のファジラーと比較して測定しましたか？
Litefuzz の目的は、プラットフォーム間でバグを見つけることです。そして実際にそうしています。正直なところ、ファジラーXやファジラーYと比較する能力は重要視しませんでした。最初から特定のトレードオフが行われ、認識されていました。詳細は [#intro](https://github.com/sec-tools/litefuzz/blob/HEAD/README.md#intro) を参照してください。

## もし今日書き直すとしたら、何を変更しますか？
現在のままでも十分に動作し、さまざまなターゲットやシナリオでテストされています。とはいえ、よりモジュールベースでプラグインシステムに標準化することで、ターゲットやプラットフォームを切り替える際にコードの操作面で追加のチェックをあまり必要としないように改善できるでしょう。もちろん、より正式なテストや、サポートするオペレーティングシステム全体でテストするためのデプロイシステムがあれば、コア機能に変更を加える際により作業しやすい環境が作られるでしょう。このプロジェクトは、小規模ながら野心的なものから、すぐに少し大きなものへと成長しました。

## litefuzz の安定性はどの程度ですか？
コマンドライン、GUI、ネットワークファジング（主にLinuxとMac）、最小化などはかなり徹底的にテストされており、全体的にかなり安定しているはずです。隔離されたネットワークGUIファジング、Mac向けのReportCrashサポート、その他いくつかのニッチな機能など、よりエキゾチックな機能は実験的と見なすべきです。

## litefuzz でサポートされていないシナリオはありますか？
いくつかあります。しかし、そのほとんどはバグのある一般的でないシナリオか、正しく動作させるためにより多くの時間と研究を必要とするもの、あるいはプラットフォームに関連する理由でうまく動作しないものです。その多くは、そのようなオプションで実行しようとすると明示的に「サポートされていません」というメッセージとともに終了し、さまざまな機能を説明する際に上記のセクションでいくつかの注意事項が述べられています。より微妙なものとしては、隔離されたアプリでのリプレイモードはサポートされておらず、また隔離機能を使用したMacアプリでのテストは限られています。PyautoguiはLinuxとWindowsでは問題なく動作するようですが、Macではあまり信頼性が高くなかったため、機能的にサポートされていないと考えてください。Windowsでのクライアントファジングは、他のプラットフォームの他のモードよりも信頼性が低い場合があります。

あちこちにエッジケースがあるかもしれませんが、最も一般的なローカルおよびネットワークファジングのシナリオはテスト済みで動作しています。ああ、これらはクロスプラットフォームツールを作成する喜びです：やりがいはありますが、すべてを常に完璧に動作させるのは難しいです。全体的に、Linux/Macでのファジングはより安定しており、より多くの機能をサポートしているように見えます。特にネットワークファジングのテストがWindowsプラットフォームよりもはるかに多く行われているためですが、少なくとも基本はWin32でも利用できるように努力し、いくつかの追加機能もあります。

このファジラーをフォークして、そのような改善を行ったり、現在サポートされていない機能をサポートしたり、あるいはより小さな便利なものについてプルリクエストを送ることも自由にどうぞ。

## このプロジェクトまたはそのコードに対してどのような保証がありますか？
まったくありません。しかし、ファジングしてバグを手に入れるのを見るのはとても楽しいです。

## 著者 / 参考
- [Jeremy Brown](https://github.com/sec-tools/litefuzz/blob/HEAD/jbrown3264%5BNOSPAM%5Dgmail)
- [macOS Fuzzing のスライドデッキ](https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)