
TI CC1352/CC26x2ハードウェア向けのBluetooth 5および4.x LEスニファ。拡張アドバタイズ、全PHYモード、MAC/RSSIフィルタリング、Wireshark互換のPCAPエクスポートに対応。
Sniffle は、TI CC1352/CC26x2 ハードウェアを使用した Bluetooth 5 および 4.x (LE) 向けスニファです。
Sniffle には、次のような便利な機能があります。
ファームウェア用のビルド環境をセットアップする手間をかけたくない場合は、UniFlash/DSLite を使用して事前ビルド済みファームウェアバイナリをフラッシュするだけです。 事前ビルド済みファームウェアバイナリは、このプロジェクトの GitHub リリースタブのリリースに添付されています。事前ビルド済みファームウェアを使用する場合は、master ブランチより古いファームウェアとの互換性の問題を避けるため、master ではなくリリースタグに対応する Python コードを使用してください。
さまざまな Linux ディストリビューションのパッケージマネージャーで提供される arm-none-eabi-gcc は、ヘッダーファイルが不足していたり、リンカー設定の変更が必要だったりすることがよくあります。手間を最小限にするには、上記でリンクした ARM GCC を使用することをお勧めします。事前ビルド済み実行ファイルをダウンロードして展開するだけです。
TI SDK は、ライセンス契約に同意するとソースコードの束を展開する実行可能バイナリとして提供されます。Linux と Mac では、デフォルトのインストールディレクトリは ~/ti/ 内です。これは問題なく機能し、私の makefile はこのパスを期待しているので、ここではデフォルトのままにすることをお勧めします。TI SysConfig ツールについても同様です。
SDK を展開したら、ビルド環境に合わせて 1 つの makefile を編集する必要があります。~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 (または SDK がインストールされた場所) の中に、imports.mak という名前の makefile があります。Sniffle をビルドするためにここで設定する必要があるパスは、GCC、XDC、cmake、SysConfig のみです。CCS コンパイラは必要ありません。以下の diff を例として参照し、インストールした場所に合わせて調整してください。```
diff --git a/imports.mak b/imports.mak
index b2cf5bf59..389d1a7c3 100644
--- a/imports.mak
+++ b/imports.mak
@@ -18,14 +18,14 @@
-XDC_INSTALL_DIR ?= /home/username/ti/xdctools_3_62_01_15_core -SYSCONFIG_TOOL ?= /home/username/ti/ccs1270/ccs/utils/sysconfig_1.21.1/sysconfig_cli.sh +XDC_INSTALL_DIR ?= $(HOME)/ti/xdctools_3_62_01_15_core +SYSCONFIG_TOOL ?= $(HOME)/ti/sysconfig_1.21.1/sysconfig_cli.sh
-CMAKE ?= /home/username/cmake-3.21.3/bin/cmake +CMAKE ?= cmake PYTHON ?= python3
TICLANG_ARMCOMPILER ?= /home/username/ti/ccs1270/ccs/tools/compiler/ti-cgt-armllvm_3.2.2.LTS-0 -GCC_ARMCOMPILER ?= /home/username/arm-none-eabi-gcc/12.3.Rel1-0 +GCC_ARMCOMPILER ?= $(HOME)/arm_tools/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-eabi IAR_ARMCOMPILER ?= /home/username/iar9.50.2
SDKバージョン8.30.01.01以降、最近のバージョンのGCC(およびbinutils)でコンパイルするには、
リンクエラー「Unknown destination type (ARM/Thumb)」および「dangerous relocation: unsupported relocation」を回避するために、
SDKに小さな変更を加える必要があります。```
diff --git a/kernel/tirtos7/packages/ti/sysbios/family/arm/m3/Hwi_asm_gcc.s b/kernel/tirtos7/packages/ti/sysbios/family/arm/m3/Hwi_asm_gcc.s
index 187cfd744..4cbf0d384 100644
--- a/kernel/tirtos7/packages/ti/sysbios/family/arm/m3/Hwi_asm_gcc.s
+++ b/kernel/tirtos7/packages/ti/sysbios/family/arm/m3/Hwi_asm_gcc.s
@@ -236,6 +236,7 @@ lab$1:
@ user code has set the PRIMASK and not cleared it, or when single
@ stepping with interrupts disabled.
+.type ti_sysbios_family_arm_m3_Hwi_interruptsAreDisabledButShouldNotBe, %function
ti_sysbios_family_arm_m3_Hwi_interruptsAreDisabledButShouldNotBe:
b ti_sysbios_family_arm_m3_Hwi_interruptsAreDisabledButShouldNotBe
diff --git a/kernel/tirtos7/packages/ti/sysbios/family/arm/v8m/Hwi_asm_gcc.s b/kernel/tirtos7/packages/ti/sysbios/family/arm/v8m/Hwi_asm_gcc.s
index 717f49c9a..1c83ed725 100644
--- a/kernel/tirtos7/packages/ti/sysbios/family/arm/v8m/Hwi_asm_gcc.s
+++ b/kernel/tirtos7/packages/ti/sysbios/family/arm/v8m/Hwi_asm_gcc.s
@@ -226,6 +226,7 @@ lab$1:
@ user code has set the PRIMASK and not cleared it, or when single
@ stepping with interrupts disabled.
+.type ti_sysbios_family_arm_v8m_Hwi_interruptsAreDisabledButShouldNotBe, %function
ti_sysbios_family_arm_v8m_Hwi_interruptsAreDisabledButShouldNotBe:
b ti_sysbios_family_arm_v8m_Hwi_interruptsAreDisabledButShouldNotBe
この変更を行った後、SDKを再コンパイルする必要があります。``` cd ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 make build-gcc -j5
### DSLite の入手
DSLite は、XDS110 デバッガ用の TI 製コマンドラインプログラミング/デバッグサーバーツールです。CC26xx および CC13xx Launchpad ボードには、どちらも XDS110 デバッガが搭載されています。残念ながら、TI はスタンドアロンのコマンドライン DSLite のダウンロードを提供していません。DSLite を入手する最も簡単な方法は、TI から [UniFlash](http://www.ti.com/tool/download/UNIFLASH) をインストールすることです。Linux、Mac、Windows で利用できます。DSLite 実行ファイルは、UniFlash のインストールディレクトリからの相対パス `deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite` に配置されます。Linux では、UniFlash のデフォルトのインストールディレクトリは `~/ti/` 内です。
DSLite 実行ファイルのディレクトリを `$PATH` に含めるようにしてください。
## ファームウェアのビルド
GCC、DSLite、SDK がインストールされ動作していれば、Sniffle のビルドは簡単です。`fw` ディレクトリに移動して `make` を実行するだけです。SDK をデフォルトディレクトリにインストールしていない場合は、makefile 内の `SIMPLELINK_SDK_INSTALL_DIR` を編集する必要があるかもしれません。
CC26x2R 以外の Launchpad のバリアント向けにビルドまたはインストールする場合は、make の引数として、または make を呼び出す前に環境変数として `PLATFORM=xxx` を指定する必要があります。`PLATFORM` でサポートされている値は、ファームウェアの makefile に記載されています。別のプラットフォーム向けにビルドする前には、必ず `make clean` を実行してください。
## ファームウェアのインストール (TI Launchpad ボード)
DSLite を使って (接続済みの) CC26x2R Launchpad に Sniffle をインストールするには、`fw` ディレクトリ内で `make load` を実行します。他の Launchpad モデルの場合は、上記で説明したように make に `PLATFORM` 引数を指定する必要があります。また、UniFlash GUI を使用して、コンパイル済みの `sniffle.hex` バイナリをフラッシュすることもできます。
## ファームウェアのインストール (SONOFF USB ドングル)
SONOFF CC2652P ドングル (CP2102N USB/UART ブリッジを搭載) に Sniffle をインストールするには、[JelmerT/cc2538-bsl](https://github.com/JelmerT/cc2538-bsl) ユーティリティを使用して、内蔵 ROM ブートローダーでファームウェアをフラッシュします。次のコマンドを使用します:```
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv sniffle_cc1352p1_cc2652p1.hex
2025年1月10日時点で、cc2538-bsl には、フラッシュ後にSonoffドングルのCC2562Pチップをリセットできないバグがあります。この修正はプルリクエスト 173 にありますが、まだマージされていません。その間、プルリクエストがマージされるのを待つ間、私のフォーク https://github.com/sultanqasim/cc2538-bsl を使用できます。
2022年、COVID-19パンデミックによるチップ不足のため、一部のSonoff CC2652Pドングルは、921600ボーに制限されたCP2102(非N)USB/UARTブリッジチップを搭載して製造されました。お持ちのドングルがこれに該当する場合、より低速な921600ボーを使用する別のファームウェアイメージをフラッシュする必要があります。この低速ボー用の特別なビルドは、sniffle_cc1352p1_cc2652p1_1M.hex(ビルドバリアント CC2652P1F_1M)という名前です。また、Sniffleユーティリティを起動する際に、デフォルトの2000000ボーを上書きするためにオプション -b 921600 を指定する必要があります。
警告: ブートローダーを使用して誤ったビルドバリアントをフラッシュしないでください。デバイスが文鎮化し、ブートローダーにロックアウトされる恐れがあります。Sonoff CC2652Pデバイスの場合は、sniffle_cc1352p1_cc2652p1.hex ファイル(CC2652P1F ビルドバリアント)または sniffle_cc1352p1_cc2652p1_1M.hex ファイル(CC2652P1F_1M` ビルドバリアント)を921600ボー用に使用してください。誤ったバリアントをフラッシュしてブートローダーにロックアウトされた場合、JTAG/SWDを使用してデバイスを復旧できる可能性があります。
Electronic Catsは、ファームウェアをロードするためのCatnip Uploaderツールを提供しています。詳細については、リポジトリ を参照してください。 ツールをダウンロードし、以下のコマンドを実行してください:```bash
[ec@sniffle]$ git clone https://github.com/ElectronicCats/CatSniffer-Tools.git [ec@sniffle]$ cd CatSniffer-Tools/catnip_uploader [ec@sniffle]$ pip install -r requirements.txt
[ec@sniffle]$ python3 catnip_uploader.py releases [INFO] Fetching assets from https://api.github.com/repos/ElectronicCats/CatSniffer-Firmware/releases/latest [INFO] Release: board-v3.x-v1.1.0 [INFO] Fetching assets from https://api.github.com/repos/nccgroup/Sniffle/releases/latest [INFO] Release: v1.10.0 [INFO] Found local release: releases_board-v3.x-v1.1.0 [SUCCESS] Local release is up to date: board-v3.x-v1.1.0 [SUCCESS] Available releases: 0: sniffer_fw_CC1352P_7_v1.10.hex 1: airtag_scanner_CC1352P_7_v1.0.hex 2: nccgroup_v1.10.0_sniffle_cc1352p7_1M.hex 3: airtag_spoofer_CC1352P_7_v1.0.hex 4: sniffle_CC1352P_7_v1.7.hex
[ec@sniffle]$ python3 catnip_uploader.py load 2 COMPORT
You need to change the *COMPORT* to the appropriate path for your board.
Using the command `python3 catnip_uploader.py load 2 COMPORT`, you will load
the `2: nccgroup_v1.10.0_sniffle_cc1352p7_1M.hex` firmware.
**To load the firmware Catsniffer V3 requires SerialPassthroughwithboot**.
**警告:** ブートローダーを使用して誤ったビルドバリアントを書き込まないでください。デバイスが文鎮化し、ブートローダーにアクセスできなくなる恐れがあります。`catnip_uploader.py` スクリプトを使用してファームウェアを取得・インストールする場合は、互換性のあるファームウェアのみが表示されます。ただし、ファームウェアを手動でコンパイルしてインストールする場合は、正しいビルドバリアントを使用するようにしてください。CatSniffer v3 デバイスの場合は、`sniffle_cc1352p7_1M.hex` ファイル(`CC1352P74_1M` ビルドバリアント)を使用してください。CatSniffer v1.x/v2.x デバイスは異なるチップバリアント(CC1352P1)を使用しており、異なるファームウェアビルド(`CC1352P1F3_1M` バリアント、`sniffle_cc1352p1_cc2652p1_1M.hex` イメージ)が必要です。Sniffle は CatSniffer v1.x/v2.x デバイスではテストされていませんが、適切なビルドバリアントを書き込めばおそらく動作するでしょう。誤ったバリアントを書き込んでブートローダーにアクセスできなくなった場合でも、JTAG/SWD を使用してデバイスを回復できる可能性があります。
## Sniffer の使用方法```
[skhan@serpent python_cli]$ ./sniff_receiver.py --help
usage: sniff_receiver.py [-h] [-s SERPORT] [-b BAUDRATE] [-c {37,38,39}] [-p] [-r RSSI]
[-m MAC] [-i IRK] [-S STRING] [-a] [-A] [-e] [-H] [-l] [-q]
[-Q PRELOAD] [-n] [-C] [-d] [-o OUTPUT]
Host-side receiver for Sniffle BLE5 sniffer
options:
-h, --help show this help message and exit
-s SERPORT, --serport SERPORT
Sniffer serial port name
-b BAUDRATE, --baudrate BAUDRATE
Sniffer serial port baud rate
-c {37,38,39}, --advchan {37,38,39}
Advertising channel to listen on
-p, --pause Pause sniffer after disconnect
-r RSSI, --rssi RSSI Filter packets by minimum RSSI
-m MAC, --mac MAC Filter packets by advertiser MAC
-i IRK, --irk IRK Filter packets by advertiser IRK
-S STRING, --string STRING
Filter for advertisements containing the specified string
-a, --advonly Passive scanning, don't follow connections
-A, --scan Active scanning, don't follow connections
-e, --extadv Capture BT5 extended (auxiliary) advertising
-H, --hop Hop primary advertising channels in extended mode
-l, --longrange Use long range (coded) PHY for primary advertising
-q, --quiet Don't display empty packets
-Q PRELOAD, --preload PRELOAD
Preload expected encrypted connection parameter changes
-n, --nophychange Ignore encrypted PHY mode changes
-C, --crcerr Capture packets with CRC errors
-d, --decode Decode advertising data
-o OUTPUT, --output OUTPUT
PCAP output file name
Launchpadボード上のXDS110デバッガは、2つのシリアルポートを作成します。
Linuxでは、通常これらはttyACM0およびttyACM1と命名されます。
作成された2つのシリアルポートのうち最初のものがSniffleとの通信に使用されます。
デフォルトでは、Python CLIは、TI XDS110 USB VID:PIDの組み合わせに一致する最初の
CDC-ACMデバイス、または検出された最初のSonoffドングルと通信します。
別のUSBシリアルアダプタを使用している場合や、追加のUSB CDC-ACMデバイスが接続されている場合は、
-sコマンドラインオプションでこれを上書きする必要があるかもしれません。
-r(RSSIフィルタ)オプションについては、スニファが送信デバイスに非常に近いか、
ほぼ接触している場合、-40の値がうまく機能する傾向があります。RSSIフィルタは、
混雑したRF環境で無関係なアドバタイズメントを無視するのに非常に役立ちます。
RSSIフィルタは、アドバタイズメントのキャプチャ中にのみ有効です。
フォロー中の接続のデータチャネルトラフィックは常にキャプチャしたいからです。
MACフィルタリングが有効な場合はRSSIフィルタを使用したくないでしょう。
RSSIが低すぎると、対象のMACアドレスからのアドバタイズメントを
失う可能性があるためです。
アドバタイズメントに合わせてホッピングし、信頼性の高い接続スニッフィングを行うには、
-mオプションでMACフィルタを設定する必要があります。ペリフェラルデバイスの
MACアドレスを指定する必要があり、セントラルデバイスではありません。どの
MACアドレスをスニッフィングするかを把握するには、スニファをターゲットの近くに置き、
RSSIフィルタリングを有効にしてスニファを実行します。これにより、ターゲットデバイスの
MACアドレスを含むアドバタイズメントが表示されます。多くのBLEデバイスは、
ラベルに書かれた「実際の」固定MACではなく、ランダム化されたMACアドレスで
アドバタイズすることに注意してください。
最近のBLEデバイスのほとんどは、固定の静的アドレスやパブリックアドレスでは
なく、Resolvable Private Address(RPA)を使用します。特定のRPAにMACフィルタを
設定できますが、デバイスは定期的にRPAを変更します。RPAは、Identity Resolving Key(IRK)が
既知であれば解決(特定のデバイスとの関連付け)できます。
Sniffleは、IRKが提供されると自動RPA解決をサポートします。これにより、
RPAが変更されるたびにMACフィルタを更新し続ける必要がなくなります。
SniffleのIRKは-iオプションで指定できます。
IRKは16進数形式で、最上位バイト(MSB)を先頭にして指定する必要があります。
IRKを指定すると、SniffleはMACフィルタの場合と同じようにアドバタイザと
チャネルホッピングできます。IRKベースのMACフィルタリング機能
(-i)は、静的MACフィルタリング機能(-m)とは相互排他的です。
また、アドバタイズメントまたはスキャン応答に指定された文字列(バイト列)を含む
アドバタイザのMACアドレスを自動的に識別する便利な機能があります。
これは、IRKが不明なRPAデバイスに役立ちますが、
アドバタイズメントに識別に十分な一意の静的文字列が含まれている場合に有効です。
この機能は-Sオプションを使用し、文字列は標準のエスケープシーケンスで指定します。
たとえば、アドバタイズメントに16進バイト列DE AD BE EFを含む
アドバタイザを探すには、-S "\xDE\xAD\xBE\xEF"と指定します。
文字列「hello」を持つアドバタイザを探すには、単に-S "hello"と指定します。
文字列検索機能を使用すると、最初はすべてのMACアドレスが受け入れられ、
検索文字列を含むアドバタイズメントが見つかった後に、対応するアドバタイザの
MACアドレスでMACフィルタが設定され、RSSIフィルタは
自動的に無効になります。
Bluetooth 5の拡張アドバタイジングで補助ポインタを追跡するには、-eオプションを有効にします。
拡張アドバタイズメントキャプチャのパフォーマンスと信頼性を向上させるため、
このオプションはMACフィルタが設定されている場合でも、
プライマリアドバタイズチャネルでのホッピングを無効にします。
レガシーまたは拡張アドバタイジングのどちらで接続が確立されるかわからない場合は、
-eと併せて-Hフラグを有効にすると、レガシーアドバタイズメントでの
プライマリチャネルホッピングと、拡張アドバタイズメントの補助パケットへの
スケジュールされたリスニングを実行できます。-eと-Hを組み合わせると、
プライマリ(レガシー)またはセカンダリ(拡張)アドバタイズチャネルのみでの
ホッピングと比較して、接続検出の信頼性が低下する可能性があります。
プライマリアドバタイズチャネルでロングレンジPHYをスニッフィングするには、-lオプションを指定します。
ロングレンジモードでは、プライマリアドバタイズチャネル間のホッピングは
サポートされないことに注意してください。すべてのロングレンジアドバタイズメントは
BT5拡張メカニズムを使用するためです。拡張メカニズムでは、
3つのプライマリチャネルすべての補助ポインタが同じ補助パケットを指すため、
プライマリチャネル間のホッピングは不要です。
接続をフォロー中に空のデータパケットを画面に表示しないようにするには、-qフラグを使用します。
これにより、意味のある通信をリアルタイムで観察しやすくなりますが、
接続フォローが不安定または失われた場合に分かりにくくなる可能性があります。
暗号化された接続について、Sniffleは暗号化キーが不明な場合でも
接続パラメータの更新を検出し、新しいパラメータの測定を試みます。
ただし、暗号化された接続パラメータ更新で期待される新しい接続間隔と
Instantデルタがわかっている場合は、--preload/-Qオプションで
それらを指定して、パフォーマンス/信頼性を向上させることができます。
期待されるInterval:DeltaInstantのペアは、コロン区切りの整数として
指定する必要があります。Intervalは、1.25 msの倍数を表す整数です
(LL_CONNECTION_UPDATE_INDで定義されています)。
DeltaInstantは、接続更新パケットが送信されてから新しいパラメータが
適用されるまでの接続イベント数です。
DeltaInstantは、Bluetooth仕様のセントラルデバイスに対する要件に従って、
6以上でなければなりません。複数の暗号化されたパラメータ更新が予想される場合は、
カンマ区切りで複数のパラメータペアを指定できます(例: 6:7,39:8)。
PHYを変更しない暗号化PHY更新PDUを発行するデバイス、または
PHY変更なしで暗号化LE電力制御PDUを送信するデバイスがある場合は、
--nophychange/-nオプションを使用できます。
スニファを停止するには、Ctrl-Cを押します。
何らかの理由でスニファファームウェアがロックアップし、フィルタを無効にしても トラフィックをキャプチャしなくなった場合は、スニファMCUをリセットする必要があります。 Launchpadボードでは、リセットボタンはmicro USBポートの横にあります。
usage: scanner.py [-h] [-s SERPORT] [-b BAUDRATE] [-c {37,38,39}] [-r RSSI] [-l] [-d] [-o OUTPUT]
Scanner utility for Sniffle BLE5 sniffer
options: -h, --help show this help message and exit -s SERPORT, --serport SERPORT Sniffer serial port name -b BAUDRATE, --baudrate BAUDRATE Sniffer serial port baud rate -c {37,38,39}, --advchan {37,38,39} Advertising channel to listen on -r RSSI, --rssi RSSI Filter packets by minimum RSSI -l, --longrange Use long range (coded) PHY for primary advertising -d, --decode Decode advertising data -o OUTPUT, --output OUTPUT PCAP output file name
スキャナーコマンドライン引数はスニファーと同じです。スキャナーユーティリティの目的は、周辺でアドバタイズしているデバイスのリストを収集し、観測されたデバイスに積極的にスキャン要求を発行することです。スニファーユーティリティのように高速にスクロールするデータの奔流にさらされることはありません。ハードウェア/ファームウェアはアクティブスキャンモードに入り、受信したアドバタイズを報告し、スキャン可能なものにはスキャン要求を発行し、受信したスキャンレスポンスを報告します。スキャナーユーティリティは、観測されたMACアドレスを一度だけ記録・報告するため、表示がスパムされることはありません。アドバタイズのキャプチャが完了したら、Ctrl-Cを押してスキャンを停止し、結果を報告します。スキャナーは各ターゲットからの最後のアドバタイズとスキャンレスポンスを表示します。スキャン結果はRSSIの降順でソートされます。
## 使用例
チャネル38で全アドバタイズをスニッフィングし、RSSI < -50を無視し、CONNECT\_REQsが見られてもアドバタイズチャネルに留まる。```
./sniff_receiver.py -c 38 -r -50 -a
MAC 12:34:56:78:9A:BC からのアドバタイズメントをスニッフィングし、アドバタイジングチャネルに留まり、
CONNECT_REQs が見られても、アドバタイズメントを data1.pcap に保存します。```
./sniff_receiver.py -m 12:34:56:78:9A:BC -a -o data1.pcap
RSSI >= -40 で最初に見つかった MAC アドレスのアドバタイズと接続をスニッフィングします。
MAC アドレスがロックされると、RSSI フィルターは自動的に無効になります。
キャプチャしたデータを `data2.pcap` に保存します。```
./sniff_receiver.py -m top -r -40 -o data2.pcap
ビッグエンディアンのIRK 4E0BEA5355866BE38EF0AC2E3F0EBC22 を持つペリフェラルからのアドバタイズと接続をスニッフィングします。予想される暗号化接続パラメータ更新を2つプリロードします。1つ目はInterval 6で、スニファが暗号化されたLL_CONNECTION_UPDATE_INDを観測してから6接続イベント後のインスタントで発生します。2つ目の予想される暗号化接続更新はInterval 39、DeltaInstantも6です。``` ./sniff_receiver.py -i 4E0BEA5355866BE38EF0AC2E3F0EBC22 -Q 6:6,39:6
近く(RSSI >= -55)のデバイスからのBT5拡張アドバタイズメントと接続をスニッフィングします。```
./sniff_receiver.py -r -55 -e
指定されたMACアドレスを持つデバイスから、レガシーおよび拡張アドバタイズメントと接続を
スニッフィングします。キャプチャしたデータをdata3.pcapに保存します。```
./sniff_receiver.py -eH -m 12:34:56:78:9A:BC -o data3.pcap
チャンネル38でロングレンジプライマリPHYを使用して、拡張アドバタイズメントと接続をスニッフィングします。```
./sniff_receiver.py -le -c 38
チャネル39でRSSIが-50より大きいアドバタイズメントを能動的にスキャンします。``` ./scanner.py -c 39 -r -50
## IRK の取得
ルート化された Android 端末をお持ちの場合、Bluedroid 設定ファイルで IRK(および LTK)を見つけることができます。Android 8.1 では、これは `/data/misc/bluedroid/bt_config.conf` にあります。`LE_LOCAL_KEY_IRK` は Android 端末自身の IRK を指定し、ファイル内の各ペアリング済みデバイスについて `LE_KEY_PID` の最初の 16 バイトが、そのペアリング済みデバイスの IRK を示します。このファイルに保存されているキーはリトルエンディアンであることに注意してください。したがって、**このファイル内のキーのバイト順を逆にする必要があります。** 例えば、リトルエンディアンの IRK 22BC0E3F2EACF08EE36B865553EA0B4E は、Sniffle に `-i` オプションで渡す際に 4E0BEA5355866BE38EF0AC2E3F0EBC22(ビッグエンディアン)に変更する必要があります。
IRK と LTK は、デバイスをルート化せずに Android または iOS でキャプチャした HCI Snoop ログからも見つけることができます:
* Android: <https://novelbits.s3.us-east-2.amazonaws.com/Developer+Guides/Android+Bluetooth+Debugging+Guide.pdf>
* iOS: <https://novelbits.s3.us-east-2.amazonaws.com/Developer+Guides/iOS+Bluetooth+Debugging+Guide.pdf>
## Wireshark プラグイン
Sniffle には Wireshark プラグインが含まれており、Wireshark GUI で 'Sniffle' キャプチャインターフェースを選択することで、Sniffle を自動的に起動できます。
Sniffle プラグインをインストールするには、まず 'About Wireshark' ダイアログで Personal Extcap フォルダの場所を確認します(*Help* > *About Wireshark* > *Folders* > *Personal Extcap path*)。最近のバージョンの Wireshark(4.2.0+)を実行している POSIX(Linux および Mac OS)システムでは、このフォルダは `~/.local/lib/wireshark/extcap` にあります。Windows では、`%USERPROFILE%\AppData\Roaming\Wireshark\extcap` にあります。
POSIX システムでは、Sniffle extcap プラグインを Wireshark の個人用 extcap ディレクトリにシンボリックリンクするだけで済みます:```
mkdir -p ~/.local/lib/wireshark/extcap
ln -s $(pwd)/python_cli/sniffle_extcap.py ~/.local/lib/wireshark/extcap
Mac OS では、Wireshark がシェルプロファイルで指定した PATH の Python ではなく、Xcode Python を使用しようとする場合があります。そのため、Xcode Python に PySerial がインストールされていないと、Sniffle プラグインが extcap インターフェースに表示されないことがあります。これを修正するには、sniffle_extcap.py の shebang 行を編集して、PySerial がインストールされている Python を直接指すようにします。たとえば、/usr/bin/env python3 ではなく、Homebrew Python の /opt/homebrew/bin/python3 を指定します。
Windows では、python_cli ディレクトリから次のファイルとディレクトリを Personal Extcap フォルダにコピーできます。```
sniffle/
sniffle_extcap.py
sniffle_extcap.bat
Windowsでは、インストールディレクトリがPATHに含まれていない場合、`sniffle_extcap.bat` を編集して
pythonインタープリタの場所を指定する必要があるかもしれません。例:```
@echo off
C:\my_python_install\python.exe "%~dp0sniffle_extcap.py" %*
プラグインをインストールしたら、Wiresharkを再起動するか、Capture > Refresh Interfaces を選択して Sniffleインターフェースを有効にします。
2019年のオリジナルのSniffleファームウェアは純粋にパッシブなリスナーでしたが、その後のファームウェアバージョンでは、
さまざまな方法でパケットを能動的に送信する機能が追加されました。現在のSniffleファームウェアは、
GAPセントラルおよびペリフェラルデバイスの両方として動作し、アクティブスキャン、レガシー
および拡張アドバタイズ、接続の開始、セントラルまたは
ペリフェラルロールでの接続をサポートしています。scanner.py スクリプトはアクティブスキャンを実行します。initiator.py
スクリプトはペリフェラルへの接続を開始し、接続されたセントラルとして動作します。
advertiser.py スクリプトはレガシーアドバタイズを実行し、他のデバイスからの接続要求を受け入れて、
接続されたペリフェラルロールに移行します。
Sniffleの送信機能は、従来のHCIベースのBluetoothコントローラとは少し異なります。 リンク層で送信される正確なPDUを非常に低レベルで制御できるからです。 この低レベル制御により、ホスト側コードは追加機能を実装できます。 たとえば、リンク層ファズテストやリンク層リレー攻撃などです。
SniffleファームウェアのAPIを正式に文書化する時間はまだ取っていませんが、かなり
自明です。sniffle_hw.py のホスト側実装を見ればわかります。アクティブスキャン
(スキャン要求を送信する)は cmd_scan によって有効になります。接続開始は
cmd_connect によってトリガーされますが、initiate_conn ラッパーを使うのが最も簡単です。アドバタイズ(オプションで
接続可能)は、レガシーアドバタイズでは cmd_advertise、拡張アドバタイズでは cmd_advertise_ext によって
有効になります。
2024年半ばのTI問題 EXT_EP-11735 の修正以降、 XDS110デバッガ(TI Launchpadボードに同梱)は、次のような高ボーレートを 2M(Sniffleが使用)でも、過度なレイテンシなしで合理的に処理します。ただし、最新の XDS110ファームウェアは、このようなボーレートでもバッファリングされたDMA駆動のUART動作を使用しているため、 最大30 msのレイテンシが依然として発生する可能性があります。このレイテンシはスニファとしての使用には影響ありませんが、 GATTクライアントとして動作するホスト側コードや、 サーバー、またはリレー攻撃の実行など、よりアクティブな操作には悪影響を及ぼす可能性があります。XDS110ファームウェアバージョン3.0.0.28の変更(以下で説明する割り込みベースの動作のための変更)は、 このような時間に敏感な操作のレイテンシを大幅に削減できます。 最新のXDS110ファームウェアにも同様の変更を加えることは可能でしょうが、 リバースエンジニアリングして変更すべき正しいビットを 見つける時間はまだ取っていません。
2024年半ば以前、TI XDS110デバッガ(Launchpadボードに同梱)のファームウェアは、 USBからUARTへのブリッジで望ましくない動作をしていました。高ボーレートでは、特に Sniffleファームウェアが行うような頻繁な小さい書き込みがある場合、深刻なレイテンシが発生する可能性がありました。この問題は 何年も存在し、2024年4月時点でも、UniFlash 8.6.0にバンドルされているXDS110ファームウェア3.0.0.28で 依然として存在していました。根本的な原因は、DMAベースの動作では、XDS110ファームウェアが ボーレートに比例するサイズのバッファにUARTデータを蓄積し、データを転送する前にこの バッファが満たされるのを待っていたことでした。最後の15ミリ秒間に新しいデータが到着しなかった場合に このバッファをフラッシュするロジックがありましたが、Sniffleが 接続イベントからの小さなパケットを数ミリ秒ごとに頻繁に追加していたため、このフラッシュロジックは決してトリガーされませんでした。その結果、 この最適ではない動作により、スニッフィングされたデータがホスト上で遅延したバーストとして表示される可能性がありました。
XDS110ファームウェアには、UART動作の代替モードもあり、すべてのUART受信が 割り込みをトリガーし、その結果データがすぐにホストに渡されます。この 割り込みベースの動作モードは、レイテンシがはるかに低くなります。ただし、ファームウェアは230400未満のボーレートでのみ このモードを使用します。頻繁な小さなデータチャンクを伴うDMAモード動作の高レイテンシの回避策として、 ファームウェアを変更して、高ボーレート(Sniffleが使用する2Mボーなど)でも割り込みベースのUSB-UARTブリッジングを使用することができます。 ファームウェア3.0.0.28(Uniflash 8.6.0に同梱)では、オフセット 0x0A14 のバイトを 61 3F から 00 1F にhex編集できます。これにより、 DMAベースのUART動作に切り替えるボーレートが230400から0x200000(2097152)に 変更されます。
上記のオフセットとバイト変更はファームウェア3.0.0.28専用であり、 ファームウェアのバージョンが異なると異なることに注意してください。デバッガに無効なファームウェアを書き込むと デバッガが損傷する可能性があり、発生する可能性のある損傷について一切の責任を負いません。
以下のコマンドをLinuxで使用すると、低レイテンシUARTのために 高ボーレートでXDS110ファームウェアを変更できます:``` cd ~/ti/uniflash_8.6.0/deskdb/content/TICloudAgent/linux/ccs_base/common/uscif/xds110/ cp firmware_3.0.0.28.bin firmware_3.0.0.28_fastuart.bin printf '\x00\x1f' | dd of=firmware_3.0.0.28_fastuart.bin bs=1 seek=$((0x0A14)) conv=notrunc sha256sum firmware_3.0.0.28_fastuart.bin
フラッシュする前に、変更したファームウェアのSHA256チェックサムが
`c226f2e9cb2b9f0bc111ca11f2903d58d4065293468623428c0e8eeb22086dcf` であることを確認してください。これを確認したら、
以下のコマンドを実行して、変更したXDS110デバッガファームウェアをフラッシュしてください:```
./xdsdfu -m
./xdsdfu -f firmware_3.0.0.28_fastuart.bin -r
Sniffleを使用して、Bluetooth LEトラフィックのリンク層リレーを実行できます。リレーを実行する際は、1台のSniffleデバイスがBLEセントラルとして動作し(relay_master.pyを使用)、もう1台のSniffleデバイスがBLEペリフェラルとして動作します(relay_slave.pyを使用)。マスターとスレーブは、それぞれBLEセントラルとペリフェラルの旧称です。リレーマスターは、本物のペリフェラルからのアドバタイズおよびスキャンレスポンスデータをキャプチャし、それをリレースレーブに渡します。リレースレーブは、本物のペリフェラルを模倣したアドバタイズおよびスキャンレスポンスを送信し、接続を受け入れます。接続を受け入れると、リレースレーブはリレーマスターに通知し、リレーマスターは本物のペリフェラルへの接続を開始します。この時点以降、すべてのリンク層パケットはリレーマスターとリレースレーブの間で転送されます。
リレーマスタースクリプトには、リレーの両側で接続間隔を短縮するよう要求し、レイテンシを低減する機能があります。XDS110をUSB/UARTブリッジとして使用する場合、前述のようにXDS110ファームウェアを変更しない限り、XDS110ファームウェアによってリレーに追加のレイテンシが生じることに注意してください。
リレーマスタースクリプトは、すべてのインターフェース(0.0.0.0)にバインドするネットワークリスナーを作成し、リレーデバイス間の通信に使用されるネットワークプロトコルはセキュリティを提供しないことに注意してください。これらのスクリプトは信頼できるネットワーク環境でのみ使用してください。
リレーマスター(セントラル)およびスレーブ(ペリフェラル)スクリプトの使用法を以下に示します。現時点では、拡張アドバタイズはリレースクリプトではサポートされていません。``` usage: relay_master.py [-h] [-s SERPORT] [-c {37,38,39}] [-m MAC] [-i IRK] [-S STRING] [-P] [-q] [-Q PRELOAD] [-f] [-p] [-F] [-o OUTPUT]
Relay master script for Sniffle BLE5 sniffer
options: -h, --help show this help message and exit -s, --serport SERPORT Sniffer serial port name -c, --advchan {37,38,39} Advertising channel to listen on -m, --mac MAC Specify target MAC address -i, --irk IRK Specify target IRK -S, --string STRING Specify target by advertisement search string -P, --public Supplied MAC address is public -q, --quiet Don't show empty packets -Q, --preload PRELOAD Preload expected encrypted connection parameter changes -f, --fastslave Relay slave should request a fast connection interval -p, --pause Wait for key press on master before relaying -F, --fastmaster Relay master should specify a fast connection interval -o, --output OUTPUT PCAP output file name
# Ligolo-NG : VPNのようにトンネリング
**Ligolo-NG** は、リバーストンネルを使用する*シンプル*かつ*軽量*なツールで、**TCP**接続と**UDP**パケットを転送するためのソケットに対して透過的なトンネルを確立します。
*高度な*ピボットツールです。
## Ligolo-NGはLangwolfのForkです。Ligolo-NGの作者は[Nicocha30](https://github.com/nicocha30)によって作成されました: [https://github.com/nicocha30/ligolo-ng](https://github.com/nicocha30/ligolo-ng)。Ligolo-NGを使用する際には、彼の[貢献](https://github.com/nicocha30/ligolo-ng/graphs/contributors)を忘れないでください。
## お願い:
私のバージョンを使用する場合は、スターを付けてください。また、Nicocha30のバージョンも忘れずにスターを付けてください。彼は素晴らしい仕事をしました!
そして、改善や提案があれば、Issueを開いてください。
## 目次
<!-- vim-markdown-toc GFM -->
* [はじめに](#はじめに)
* [使い方](#使い方)
* [インストール](#インストール)
* [Ligolo-NGの構築方法](#Ligolo-NGの構築方法)
* [TLSオプションの使用方法](#TLSオプションの使用方法)
* [デモ](#デモ)
* [機能](#機能)
* [To-Do](#To-Do)
* [クレジット/ありがとう](#クレジット/ありがとう)
<!-- vim-markdown-toc -->
## はじめに
あなたのターゲットはWindowsマシンで、さらなる内部ネットワークに到達するためにピボットする必要がありますか?
**Ligolo-NG**が役に立ちます!
**サーバー** (アタッカーマシン) で*プロキシ*サーバーを起動し、**エージェント** (ターゲットマシン) から接続します。
接続が確立されると、**TUN**インターフェースが作成されます!
次に、アタッカーマシンでこのインターフェースを経由するルートを設定します。これにより、リバーストンネルを介してエージェントの内部ネットワークに到達できます。
## 使い方
### セットアップ
**Ligolo-NG**は**TUN**インターフェースで動作します。
*サーバー* (アタッカーマシン) に*プロキシ*サーバーを起動し、*エージェント* (侵害されたマシン) から接続します。
`--auto-cert`オプションを使用して自己署名証明書を生成できますが、手動で証明書を作成することも可能です。
エージェントがサーバーに接続する際、証明書のフィンガープリントが表示され、確認できます。
#### プロキシサーバーのセットアップ
`proxy`サブコマンドを使用して、アタッカー制御サーバーで*プロキシ*サーバーを起動します:
```bash
./ligolo-proxy -laddr 0.0.0.0:443 -auto-cert
注意: -laddrを省略すると、デフォルトで0.0.0.0:11601でリッスンします。```
usage: relay_slave.py [-h] [-s SERPORT] [-M MASTERADDR] [-q]
Relay slave script for Sniffle BLE5 sniffer
options: -h, --help show this help message and exit -s, --serport SERPORT Sniffer serial port name -M, --masteraddr MASTERADDR IP address of relay master -q, --quiet Don't show empty packets