Reverse Engineering Bluetooth Protocols
1.0.0
このドキュメントでは、Cobra IRAD 900レーダー検出器のBluetoothプロトコルをリバースエンジニアリングするために行ったプロセスの概要を説明しています。私の最初の目標は、iOS/Androidアプリケーションを使用せずにアラートを処理するために、Bluetoothを介してデバイスとのRaspberry Pi 3インターフェイスを使用して、最終的にはRaspberry Pi "Carputer"の素晴らしいインターフェイスとして機能することでした。
Bluetoothプロトコルの最初の経験はなかったことに注意することが重要ですが、全体的にかなり楽しい学習体験でした。
私がこのプロジェクトを最初に始めたとき、私はどこから始めればいいのか分かりませんでした。私は通常のWebトラフィックを嗅ぐ方法を知っていましたが、Bluetoothは私にとって少しブラックボックスでした。いくつかの簡単な検索で、PybluezライブラリとRFCOMMを介した通信の例を見つけました。また、Travis Goodspeedによる興味深いブログ投稿など、いくつかの優れたリソースを見つけました。
しかし、このテーマに関するほとんどガイダンスは、このようなリソースにかなりの時間を費やしました。
私の古いジェイルブレイクされたiPhone 5と遊んで、私はbtserverを使用して、iPhoneが送信して受け取ったBluetoothトラフィックをログに記録することができました。複数のBluetoothデバイスに囲まれているため、ログファイルは急速に成長しましたが、それほど問題はありませんでした。ありがたいことに、ログは.pklgファイルとして出力されたため、Wiresharkの関連パケットを簡単にフィルタリングできます。
パケットフィルターbluetooth.src == B8:92:1D:00:3F:61使用して、iOSアプリがレーダー検出器に送信している生パケットを見ることができました。電話とレーダー検出器の間の通信のサンプル録音をいくつか撮影しましたが、一部はアラートが生成され、一部は生成されていません。
Bluetoothデータは、RFCOMMプロトコルを介して転送されます。デバイスが最初に接続するとき、彼らはいくつかの情報を行き来します。おそらく設定を同期するだけです（これについては後で詳しく説明します）。その後、2つのデバイスは互いの間の予測可能なパターンに従います。レーダー検出器は、通常の1/2秒間隔でBluetoothを介してRFCOMMパケットを送信します。しばらく時間と忍耐があれば、レーダー検出器からiPhoneに送信されるペイロード構造を解読することができました。
ペイロード構造：レーダー検出器→iPhone
| アイテム | 値（六角） | サイズ |
|---|---|---|
| 前文 | 55 | 1バイト |
| ペイロードサイズ | xx xx | 2バイト |
| アクション | xx | 1バイト |
| 予約済み | 00 | 1バイト |
| seq | xx | 1バイト |
| 予約済み | xx xx xx xx xx xx | 6バイト |
| アラート | xx | 1バイト |
| アラートタイプ | xx | 1バイト |
| ... | ... | ... |
レーダー検出器が実行されているため、上記の形式でパケットを送信します。コンピューターネットワーキングは私の専門分野ではありませんが、できる限り最善を尽くします。
送信されたプリアンブルバイトは、常に0x55で送信されます。これは、以前のパケットから継続するのではなく、デバイスからの新しいペイロードメッセージの始まりであることを指定します。その後、メッセージの残りのサイズ（最初の3バイトの後のすべて）を含む2バイトの値があります。アクション値は、パケットが送信している情報の種類を指定します。
配列番号は、物事が面白くなり始めるところです。ネットワーキングのクラスを受講したり、TCPについて少し知っている場合、おそらくそれが何のためにあるのかをすでに知っているでしょう。レーダー検出器はiPhoneに1バイトの値を送信し、iOSアプリケーションは同じ値のACK番号で応答する必要があります。それ以外の場合、レーダー検出器は何かが不幸であり、それ自体が切断されていることに気付きます。
Alertバイトは、アラートがトリガーされているかどうかを指定します。その場合、それは値0x41のセットであり、次のバイトを使用して、アラートのタイプが送信されています。私は実際のレーダー銃を所有していないので、私は価値についてあまり知ることができませんでした。しかし、Instructablesの男がArduinoを使用してLidar Gun Simulatorを作りました。それはパケットの分析に大いに役立ちました。
iOSアプリにデバイスへの接続を維持するには、正しい形式で応答を送信する必要があります。ありがたいことに、レーダー検出器への応答ははるかに単純で、わずか9バイトです。
応答： iPhone→レーダー検出器
| アイテム | 値（六角） | サイズ |
|---|---|---|
| 前文 | 55 | 1バイト |
| ペイロードサイズ | xx xx | 2バイト |
| アクション | 02 | 1バイト |
| 予約済み | 00 | 1バイト |
| Ack | xx | 1バイト |
| 予約済み | 00 42 | 2バイト |
| カウンタ | xx | 1バイト |
前述のように、ACK値は以前に受信した配列値と同じ値でなければなりません。そうしないと、接続が切断されます。それは十分に簡単でした。他の一部のプロトコルには、クライアントチェックの明白な方法がそれほど明白ではない場合があります。ありがたいことに、そうではありませんでした。興味深いことに、使用される別のcounter変数があります。私はバイトが何のために何であるかを実際に理解することはありませんでしたが、デバイスへの応答ごとに1倍減少します。これらの値は両方とも、Pythonスクリプトにコーディングするのに十分簡単であり、あまり多くの作業を必要としませんでした。
先に述べたように、iOSアプリが最初にレーダー検出器に接続するとき、一部の設定とデータは前後に同期されます。それらのパケットを理解して分解することは本当に私の優先事項ではなかったので、私はこれにあまり時間を費やしたくありませんでした。 wiresharkのパケットログ全体をxmlファイル（data.xml）としてエクスポートし、pythonスクリプト（parsedata.py）を使用して、後で使用するための情報を処理および保存しました。
ロードされると、Radar.pyはPacketData.datファイル内で前処理されたデータを開きます。次に、Bluetoothを介したレーダー検出器をスキャンし、それに接続しようとします。接続されると、レーダー検出器は、いくつかのデータのパケットを接続されたデバイスに送信します。ありがたいことに、それらは毎回まったく同じシーケンスにあるまったく同じパケットです。 Pythonスクリプトは、受信したパケットのPacketData.datファイルのデータを調べます。メインのPythonスクリプトがマシングパケットを見つけると、レーダー検出器に対応する以前に記録された応答を送信します。
驚くべきことに、それはうまくいきました。ただし、iOSアプリ内の設定を変更した場合、データファイルを更新する必要があると思います。デバイスを一度構成する必要があり、おそらくアプリを二度と使用する必要があるため、それほど問題ではありませんでした。
私が見つけたすべての情報を考えると、iPhoneの接続をエミュレートするPythonスクリプトを書くことができました。記録された応答のデータベース内にパケットが見つからない場合、以前に詳細に説明した構造で応答パケットを構築します。
振り返ってみると、それは私が本当に経験したことのない何かをする本当に楽しいプロジェクトでした。コンピューターサイエンスの専攻として、ハードウェアで何かをすることは面白かったです。
Brandon Asuncion // [email protected]
コメント/フィードバックは大歓迎です！
