dougives/wispスクリプトとハードウェアキットで、802.11クライアントを一斉に自動的にdeauthします。後での悪事のためにパケットをキャプチャします。
802.11クライアントを大量に自動deauthするスクリプト。後で悪用するためのパケットをキャプチャします。地元のコーヒーショップで会話のきっかけに最適です。
このスクリプトはRaspberry Pi 3以降で動作するように設計されています。もちろん、同等以上の能力を持つ類似のハードウェアでも動作します。
スクリプトを効果的に運用するには、かなりの追加キットが必要です。以下も必要です:
最大限の効果を得るには、以下のものも用意すべきです:
私は個人的に、SSH経由でこのようなキットを制御するために、ConnectBot を Hacker's Keyboard と一緒にスマートフォンで使用しています。最も目立たず、ポケットに収まります。
ルーティング/NATの問題を避けるために、デバイスが自分でホストするVPNに自動接続するように設定することをお勧めします。これを実現する最も簡単な方法は、クラウドホスト上に OpenVPN をセットアップすることです。OpenVPN のサーバー設定ディレクティブ client-to-client を使用するか、別途フォワーディングを設定してください。
当然ながら、デバイスをインターネットに接続するにはWi-Fi以外の方法が必要です。セルラーアクセスが最も簡単な候補です。リモートからデバイスのパケットキャプチャを取得する必要がない限り、必要な帯域幅は非常に少なく（<100Kib/s）です。一定量のデータ使用後に速度制限がある安価な「無制限」データプランでも十分です。
OpenVPNをセルラー経由で実行する際にMTUの問題が発生したことがあります。最も簡単な解決策は、ip link set dev tunX mtu 1200 でMTUを1200に設定することです（tunXはtunデバイスです）。ネットワークによっては別のMTUを使用する必要があるかもしれません。
特定の設定によっては、接続されたUSBデバイスがRaspberry Piの通常の方法で供給できる以上の電力を消費する可能性があります。前述のUSB給電ハブを使用すると、バッテリーの別のUSBポートから無線機に電力を供給できます。安価なUSBハブの中には、Raspberry Pi上のハブに「バックパワー」を供給するものがあります。良質なバッテリーを使用している限り、これは適切であり、むしろ有用です。
もう一つの解決策は、このような スプリッターを使用してUSBハブに追加電力を供給することです。動作はしますが、お勧めしません。誤って外れる可能性がもう一つ増え、整理するのも厄介です。
テザリングした携帯電話を介してリモートコントロールを提供する場合、可能であればキット起動時にバッテリーが完全に充電されていることを確認してください。安価なデバイスの中には、常時データ接続によって消費される電力に追いつくのに十分な電流を引き出せないものがあります。
複数の無線機、Raspberry Pi、セルラーモデムの組み合わせは非常に高温になります。Panda PAU06は特に熱くなります。熱を気にしないと、無線機が溶けたり、さらに悪いことになります。使用するバッグ/エンクロージャが適切な放熱を提供するかどうか、事前に室温でテスト運転を行ってください。暖かい日の車内など、高温環境でキットを使用しなければならない場合は、過熱を防ぐために追加の対策を講じてください。車の場合、エアコンの温度調節を設定し、断続的にリモートスタートすれば十分です。
安価な携帯電話の中には、追加の機器と定期的なデータ送信の必要性の組み合わせにより、過熱しやすいものがあります。これらの条件下ではシャットダウンし、リモートコントロールができなくなる可能性があります。電話機をキットの他の部分とは別のコンパートメントに置くと効果的ですが、別のデバイスを使用する方が良いでしょう。
キットを隠密に運用するつもりなら、熱が予期せぬ方法で注目を集める可能性があることに留意してください。雪の日に車のダッシュボードに置いておくと、雪や氷が溶けます。他のすべてが雪で覆われている中で、フロントガラスにきれいな円形の空いたスペースができ、キットが中央に見えるようになります！
Wispのインストール手順は rpi-install.md に詳細が記載されています。手順は非Raspbianシステムでも同様のはずです。Wispはdeauthフレームを送信するために aircrack-ng の aireplay-ng に依存しています。特に、デバイス用にPython-3.7.1をビルドする必要があります。これもrpi-install.mdファイルに記載されています。
Wispは dream という別の小さなCプログラムに依存しています。ソースは dream.c として含まれています。Dreamはlibpcapに依存しています。
以下のコマンドでデバイス用のdreamをコンパイルします: gcc -O3 dream.c -lpcap
Dreamは、grep可能な行出力を持つ802.11トラフィック監視ツールです。また、キャプチャしたトラフィックを標準的なpcap形式のファイルに保存します。Wispは各監視無線機に対してdreamを呼び出し、その出力をパースしてクライアントトラフィックを抽出します。以下がその引数です:
--a: 関連付けられたクライアントからのトラフィックのみを報告します。（--dが有効な場合、すべてのパケットはディスクに記録されます。）--d (file): パケットを指定されたファイルにダンプします。-[b][c][d][f][s][t]: 1行あたりに出力するフィールドを指定します。具体的には:
b: BSSc: チャンネル番号。d: パケットを受信したデバイスの名前。f: 周波数。s: ステーション（STA）。t: Pcapタイムスタンプ。これらのフィールドは、指定された順序に関係なく、常に同じ順序で出力されます。（つまり、-bcst は -sctb と同等です。）
Wispは設定のために wisp.json というjson形式のファイルを読み取ります。以下はキーの説明です:
monitors: モニターとして設定されるデバイスのリストを含みます。各デバイスは、その特定の設定を記述するサブキーを含みます:
channel: デバイスが監視するチャンネル。injector: deauthフレームを注入するように設定されるデバイス。timing: いくつかのタイミングパラメータをリストし、すべてミリ秒単位で指定します:
delay: クライアントごとに送信されるdeauthパケット間の遅延。jitter: 指定された範囲内でランダムな量だけ遅延時間を変調します。stale: クライアントが遅延リストから削除されるまでの未確認時間。遅延時間範囲に近くない限り、実質的な効果はほとんどありません。すべてのパラメータは wisp.json から読み込まれるため、wispは単に python3 ./wisp.py で呼び出されます。
Wispは wisp.json で記述されたとおりに自動的に無線機を設定します。また、airmon-ng の動作と同様に、rfkillを無効にし、干渉するプロセスを強制終了します。
Wispは指定されたデバイスを wispX という形式にリネームします（Xはphyに関連付けられた番号）。終了時に元の名前に戻します。
Wispは送信したdeauthごとに . を出力します。これは、期待通りに動作していることを確認するシンプルで効果的な方法です。
Wisp（dream経由）は、パケットをキャプチャした無線機（phy）の名前とランダムな16進文字列をプレフィックスとし、.cap で終わるpcapファイルを出力します。例えば、phy0-8cf9ec5ca146943f.cap のようなものです。その後、pcapファイル用の通常のツールを使って、これらのファイルを検査、パース、操作できます。