nccgroup/sniffleBluetooth 5 und 4.x LE Sniffer für TI CC1352/CC26x2 Hardware mit Unterstützung für erweiterte Werbung, alle PHY-Modi, MAC/RSSI-Filterung und PCAP-Export, kompatibel mit Wireshark.
Sniffle ist ein Sniffer für Bluetooth 5 und 4.x (LE) mit TI CC1352/CC26x2 Hardware.
Sniffle hat eine Reihe nützlicher Funktionen, darunter:
Wenn Sie sich nicht die Mühe machen möchten, eine Build-Umgebung für die Firmware einzurichten, können Sie einfach vorgefertigte Firmware-Binärdateien mit UniFlash/DSLite flashen. Vorgefertigte Firmware-Binärdateien sind den Releases auf dem GitHub-Releases-Tab dieses Projekts beigefügt. Wenn Sie vorgefertigte Firmware verwenden, stellen Sie sicher, dass Sie den Python-Code des entsprechenden Release-Tags und nicht von master verwenden, um Kompatibilitätsprobleme mit der Firmware zu vermeiden, die hinter dem master-Branch liegt.
Das arm-none-eabi-gcc, das von verschiedenen Linux-Distributionen über deren
Paketmanager bereitgestellt wird, enthält oft einige Header-Dateien nicht oder erfordert
Änderungen an der Linker-Konfiguration. Für minimale Kopfschmerzen empfehle ich die
Verwendung des oben verlinkten ARM GCC. Sie können die vorgebauten ausführbaren Dateien
einfach herunterladen und entpacken.
Das TI SDK wird als ausführbare Binärdatei bereitgestellt, die nach der Annahme des
Lizenzvertrags eine Reihe von Quellcode extrahiert. Unter Linux und Mac befindet sich das
Standardinstallationsverzeichnis in ~/ti/. Das funktioniert gut und meine Makefiles
erwarten diesen Pfad, daher empfehle ich, hier einfach die Standardeinstellung zu
verwenden. Gleiches gilt für das TI SysConfig-Tool.
Sobald das SDK extrahiert wurde, müssen Sie eine Makefile bearbeiten, um es an Ihre
Build-Umgebung anzupassen. Innerhalb von ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01
(oder wo auch immer das SDK installiert wurde) gibt es eine Makefile namens imports.mak.
Die einzigen Pfade, die hier zum Bau von Sniffle gesetzt werden müssen, sind für GCC, XDC,
cmake und SysConfig. Wir brauchen den CCS-Compiler nicht. Siehe das folgende Diff als
Beispiel und passen Sie es an den Ort an, an dem Sie die Dinge installiert haben.```
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
Ab SDK-Version 8.30.01.01 ist eine kleine Änderung am SDK erforderlich, um mit aktuellen Versionen von GCC (und binutils) zu kompilieren, um Linker-Fehler wie "Unknown destination type (ARM/Thumb)" und "dangerous relocation: unsupported relocation" zu vermeiden.```
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
Nachdem Sie diese Änderung vorgenommen haben, müssen Sie das SDK neu kompilieren.``` cd ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 make build-gcc -j5
### DSLite beziehen
DSLite ist TIs Befehlszeilen-Programmier- und Debug-Server-Tool für XDS110-Debugger.
Die CC26xx- und CC13xx-Launchpad-Boards enthalten beide XDS110-Debugger.
Leider stellt TI keinen eigenständigen Befehlszeilen-Download für DSLite bereit.
Der einfachste Weg, DSLite zu erhalten, ist die Installation von [UniFlash](http://www.ti.com/tool/download/UNIFLASH) von TI.
Es ist für Linux, Mac und Windows verfügbar.
Die ausführbare DSLite-Datei befindet sich unter `deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite` relativ zum UniFlash-Installationsverzeichnis.
Unter Linux befindet sich das Standard-Installationsverzeichnis von UniFlash in `~/ti/`.
Sie sollten das Verzeichnis der ausführbaren DSLite-Datei in Ihrem `$PATH` platzieren.
## Firmware-Erstellung
Sobald GCC, DSLite und das SDK installiert und betriebsbereit sind, sollte das Erstellen von Sniffle unkompliziert sein.
Navigieren Sie einfach in das Verzeichnis `fw` und führen Sie `make` aus.
Wenn Sie das SDK nicht im Standardverzeichnis installiert haben, müssen Sie möglicherweise `SIMPLELINK_SDK_INSTALL_DIR` in der Makefile bearbeiten.
Wenn Sie für eine andere Variante des Launchpads als CC26x2R bauen oder installieren, müssen Sie `PLATFORM=xxx` angeben, entweder als Argument für make oder durch Definition als Umgebungsvariable vor dem Aufruf von make.
Unterstützte Werte für `PLATFORM` finden Sie in der Firmware-Makefile.
Führen Sie unbedingt `make clean` aus, bevor Sie für eine andere Plattform bauen.
## Firmware-Installation (TI Launchpad-Board)
Um Sniffle auf einem (eingesteckten) CC26x2R-Launchpad mit DSLite zu installieren, führen Sie `make load` im Verzeichnis `fw` aus.
Für alle anderen Launchpad-Modelle müssen Sie das `PLATFORM`-Argument für make wie oben beschrieben angeben.
Sie können auch die kompilierte `sniffle.hex`-Binärdatei mit der UniFlash-GUI flashen.
## Firmware-Installation (SONOFF USB-Dongle)
Um Sniffle auf einem SONOFF CC2652P-Dongle (ausgestattet mit einer CP2102N USB/UART-Brücke) zu installieren, verwenden Sie das Dienstprogramm [JelmerT/cc2538-bsl](https://github.com/JelmerT/cc2538-bsl), um die Firmware mit dem integrierten ROM-Bootloader mit dem folgenden Befehl zu flashen:```
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv sniffle_cc1352p1_cc2652p1.hex
Stand 10. Januar 2025 gibt es einen Fehler in cc2538-bsl, der das Zurücksetzen des CC2562P-Chips im Sonoff-Dongle nach dem Flashen verhindert. Die Behebung dafür befindet sich im Pull-Request 173, der noch nicht gemergt wurde. In der Zwischenzeit, während Sie auf die Zusammenführung des Pull-Requests warten, können Sie meinen Fork unter https://github.com/sultanqasim/cc2538-bsl verwenden.
Im Jahr 2022 wurden aufgrund der durch die COVID-19-Pandemie verursachten Chipknappheit einige Sonoff CC2652P-Dongles mit CP2102 (non-N) USB/UART-Brücken-Chips gebaut, die auf 921600 Baud begrenzt sind. Wenn Sie ein solches Modell besitzen, müssen Sie ein anderes Firmware-Image flashen, das eine langsamere Baudrate von 921600 verwendet. Dieser spezielle Build mit langsamerer Baudrate heißt sniffle_cc1352p1_cc2652p1_1M.hex (Build-Variante CC2652P1F_1M). Sie müssen auch die Sniffle-Utilities mit der Option -b 921600 aufrufen, um die Standard-Baudrate von 2000000 zu überschreiben.
WARNUNG: Flashen Sie nicht die falsche Build-Variante mit dem Bootloader, da Sie sonst Gefahr laufen, das Gerät zu brickieren und sich selbst aus dem Bootloader auszusperren. Verwenden Sie für Sonoff CC2652P-Geräte die Datei sniffle_cc1352p1_cc2652p1.hex (Build-Variante CC2652P1F) oder die Datei sniffle_cc1352p1_cc2652p1_1M.hex(Build-VarianteCC2652P1F_1M`) für eine Baudrate von 921600. Wenn Sie die falsche Variante flashen und sich aus dem Bootloader aussperren, ist es möglicherweise möglich, das Gerät über JTAG/SWD wiederherzustellen.
Electronic Cats stellt ein Catnip-Uploader-Tool zum Laden der Firmware zur Verfügung. Ausführliche Informationen finden Sie im Repository. Laden Sie das Tool herunter und befolgen Sie diese Befehle:```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
Sie müssen den *COMPORT* durch den passenden Pfad für Ihr Board ersetzen. Mit dem Befehl `python3 catnip_uploader.py load 2 COMPORT` laden Sie die Firmware `2: nccgroup_v1.10.0_sniffle_cc1352p7_1M.hex`. **Zum Laden der Firmware benötigt Catsniffer V3 SerialPassthroughwithboot**.
**WARNUNG:** Flashen Sie nicht die falsche Build-Variante über den Bootloader, sonst riskieren Sie, das Gerät zu brickieren und sich selbst aus dem Bootloader auszusperren. Wenn Sie das Skript `catnip_uploader.py` verwenden, um die Firmware zu laden und zu installieren, werden nur kompatible Firmware-Versionen angezeigt. Wenn Sie sich jedoch entscheiden, die Firmware manuell zu kompilieren und zu installieren, stellen Sie sicher, dass Sie die richtige Build-Variante verwenden. Verwenden Sie für CatSniffer v3-Geräte die Datei `sniffle_cc1352p7_1M.hex` (Build-Variante `CC1352P74_1M`). CatSniffer v1.x/v2.x-Geräte verwenden einen anderen Chip (CC1352P1), der eine andere Firmware-Build benötigt (Variante `CC1352P1F3_1M`, Image `sniffle_cc1352p1_cc2652p1_1M.hex`). Sniffle wurde auf CatSniffer v1.x/v2.x nicht getestet, wird aber wahrscheinlich funktionieren, solange Sie die entsprechende Build-Variante flashen. Wenn Sie die falsche Variante flashen und sich aus dem Bootloader aussperren, könnte es möglich sein, das Gerät über JTAG/SWD wiederherzustellen.
## Sniffer-Verwendung```
[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
Der XDS110-Debugger auf den Launchpad-Boards erstellt zwei serielle Ports. Unter Linux heißen sie typischerweise ttyACM0 und ttyACM1. Der erste der beiden erstellten seriellen Ports wird zur Kommunikation mit Sniffle verwendet. Standardmäßig kommuniziert die Python-CLI mit dem ersten CDC-ACM-Gerät, das der TI XDS110 USB VID:PID-Kombination entspricht, oder dem ersten Sonoff-Dongle, das sie findet. Möglicherweise müssen Sie dies mit der Befehlszeilenoption -s überschreiben, wenn Sie einen anderen USB-Seriell-Adapter verwenden oder zusätzliche USB-CDC-ACM-Geräte angeschlossen haben.
Für die Option -r (RSSI-Filter) funktioniert ein Wert von -40 in der Regel gut, wenn der Sniffer sehr nah am sendenden Gerät ist oder es fast berührt. Der RSSI-Filter ist sehr nützlich, um irrelevante Werbung in einer belebten HF-Umgebung zu ignorieren. Der RSSI-Filter ist nur aktiv, wenn Werbung erfasst wird, da Sie immer den Datenkanalverkehr für eine verfolgte Verbindung erfassen möchten. Sie sollten wahrscheinlich keinen RSSI-Filter verwenden, wenn die MAC-Filterung aktiv ist, da Sie möglicherweise Werbung von der interessierenden MAC-Adresse verlieren, wenn der RSSI zu niedrig ist.
Um mit Werbung mitzuspringen und zuverlässiges Verbindungs-Sniffing zu haben, müssen Sie einen MAC-Filter mit der Option -m einrichten. Sie sollten die MAC-Adresse des Peripheriegeräts angeben, nicht des Zentralgeräts. Um herauszufinden, welche MAC-Adresse gesnifft werden soll, können Sie den Sniffer mit RSSI-Filterung ausführen, während Sie den Sniffer in der Nähe des Ziels platzieren. Dies zeigt Ihnen Werbung vom Zielgerät einschließlich seiner MAC-Adresse. Es ist zu beachten, dass viele BLE-Geräte mit einer randomisierten MAC-Adresse werben, anstatt ihrer "echten" festen MAC, die auf einem Etikett steht.
Die meisten neuen BLE-Geräte verwenden auflösbare private Adressen (RPAs) anstelle von festen statischen oder öffentlichen Adressen. Während Sie einen MAC-Filter auf eine bestimmte RPA einrichten können, ändern Geräte periodisch ihre RPA. RPAs können aufgelöst (mit einem bestimmten Gerät verknüpft) werden, wenn der Identity Resolving Key (IRK) bekannt ist. Sniffle unterstützt automatische RPA-Auflösung, wenn der IRK bereitgestellt wird. Dies vermeidet die Notwendigkeit, den MAC-Filter jedes Mal zu aktualisieren, wenn sich die RPA ändert. Sie können einen IRK für Sniffle mit der Option -i angeben; der IRK sollte im Hexadezimalformat bereitgestellt werden, mit dem höchstwertigen Byte (MSB) zuerst. Die Angabe eines IRK ermöglicht es Sniffle, mit einem Werbetreibenden genauso mitzuspringen wie mit einem MAC-Filter. Die IRK-basierte MAC-Filterfunktion (-i) schließt sich gegenseitig mit der statischen MAC-Filterfunktion (-m) aus.
Es gibt auch eine Komfortfunktion, um automatisch die MAC-Adresse des Werbetreibenden zu identifizieren, dessen Werbe- oder Scanantwort einen bestimmten String (eine Reihe von Bytes) enthält. Dies ist nützlich für Geräte mit RPAs, bei denen der IRK unbekannt ist, aber die Werbung einen ausreichend eindeutigen statischen String zur Identifikation enthält. Diese Funktion verwendet die Option -S, wobei der String mit standardmäßigen Escape-Sequenzen angegeben wird. Um beispielsweise nach einem Werbetreibenden zu suchen, dessen Werbung die Hex-Byte-Sequenz DE AD BE EF enthält, geben Sie -S "\xDE\xAD\xBE\xEF" an. Um nach einem Werbetreibenden mit dem String "hello" zu suchen, geben Sie einfach -S "hello" an. Wenn die String-Suchfunktion verwendet wird, werden zunächst alle MAC-Adressen akzeptiert, bis eine Werbung gefunden wird, die den Suchstring enthält. Danach wird ein MAC-Filter mit der entsprechenden MAC-Adresse des Werbetreibenden eingerichtet, und ein eventueller RSSI-Filter wird automatisch deaktiviert.
Um das Verfolgen von Hilfszeigern (Auxiliary Pointers) in Bluetooth 5 Extended Advertising zu aktivieren, aktivieren Sie die Option -e. Um die Leistung und Zuverlässigkeit bei der Erfassung von Extended Advertising zu verbessern, deaktiviert diese Option das Springen auf den primären Werbekanälen, selbst wenn ein MAC-Filter eingerichtet ist. Wenn Sie sich nicht sicher sind, ob eine Verbindung über Legacy- oder Extended Advertising hergestellt wird, können Sie das Flag -H in Verbindung mit -e aktivieren, um das Springen auf primären Kanälen mit Legacy-Werbung und geplantes Abhören von Extended-Werbung-Hilfspaketen durchzuführen. Bei der Kombination von -e und -H kann die Zuverlässigkeit der Verbindungserkennung im Vergleich zum Springen nur auf primären (Legacy) oder sekundären (Extended) Werbekanälen reduziert sein.
Um die Long-Range-PHY auf primären Werbekanälen zu sniffern, geben Sie die Option -l an. Beachten Sie, dass im Long-Range-Modus kein Springen zwischen den primären Werbekanälen unterstützt wird, da alle Long-Range-Werbung den BT5 Extended Mechanism verwendet. Unter dem Extended Mechanism zeigen Hilfszeiger auf allen drei primären Kanälen auf dasselbe Hilfspaket, sodass ein Springen zwischen primären Kanälen unnötig ist.
Um beim Verfolgen einer Verbindung keine leeren Datenpakete auf dem Bildschirm auszugeben, verwenden Sie das Flag -q. Dies erleichtert die Beobachtung sinnvoller Kommunikation in Echtzeit, kann aber verdecken, wann die Verbindungsverfolgung fehlerhaft oder verloren ist.
Für verschlüsselte Verbindungen unterstützt Sniffle die Erkennung von Verbindungsparameteraktualisierungen, selbst wenn der Verschlüsselungsschlüssel unbekannt ist, und es versucht, die neuen Parameter zu messen. Wenn Sie jedoch das neue Verbindungsintervall und das Instant-Delta kennen, das bei verschlüsselten Verbindungsparameteraktualisierungen zu erwarten ist, können Sie diese mit der Option --preload/-Q angeben, um die Leistung/Zuverlässigkeit zu verbessern. Das erwartete Paar Interval:DeltaInstant sollte als durch Doppelpunkte getrennte Ganzzahlen angegeben werden. Interval ist eine Ganzzahl, die Vielfache von 1,25 ms darstellt (wie in LL_CONNECTION_UPDATE_IND definiert). DeltaInstant ist die Anzahl der Verbindungsereignisse zwischen dem Senden des Verbindungsaktualisierungspakets und dem Zeitpunkt, an dem die neuen Parameter angewendet werden. DeltaInstant muss gemäß den Anforderungen der Bluetooth-Spezifikation für zentrale Geräte größer oder gleich 6 sein. Wenn mehrere verschlüsselte Parameteraktualisierungen erwartet werden, können Sie mehrere Parameterpaare durch Kommas getrennt angeben (z. B. 6:7,39:8). Wenn Sie ein Gerät haben, das verschlüsselte PHY-Update-PDUs ausgibt, die die PHY nicht ändern, oder verschlüsselte LE Power Control PDUs ohne PHY-Änderungen aussendet, können Sie die Option --nophychange/-n verwenden.
Um den Sniffer zu stoppen, drücken Sie Strg-C.
Wenn die Sniffer-Firmware aus irgendeinem Grund hängt und sich weigert, Datenverkehr zu erfassen, selbst wenn Filter deaktiviert sind, sollten Sie den Sniffer-MCU zurücksetzen. Auf Launchpad-Boards befindet sich der Reset-Taste neben dem Mikro-USB-Anschluss.
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
Der Scanner-Befehlszeilenargumente funktionieren genauso wie die des Sniffers. Der Zweck des Scanner-Dienstprogramms besteht darin, eine Liste von nahegelegenen Geräten zu sammeln, die Werbung senden, und aktiv Scan-Anfragen für beobachtete Geräte auszugeben, ohne die Flut von schnell scrollenden Daten, die man mit dem Sniffer-Dienstprogramm erhält. Die Hardware/Firmware wechselt in einen aktiven Scan-Modus, in dem sie empfangene Werbepakete meldet, Scan-Anfragen für scannbare Pakete ausgibt und empfangene Scan-Antworten meldet. Das Scanner-Dienstprogramm zeichnet beobachtete MAC-Adressen nur einmal auf und meldet sie, ohne die Anzeige zu überfluten. Sobald Sie die Erfassung von Werbepaketen abgeschlossen haben, drücken Sie Ctrl-C, um das Scannen zu beenden und die Ergebnisse zu melden. Der Scanner zeigt die letzte Werbung und Scan-Antwort von jedem Ziel an. Die Scan-Ergebnisse werden nach RSSI in absteigender Reihenfolge sortiert.
## Verwendungsbeispiele
Schnüffle alle Werbepakete auf Kanal 38, ignoriere RSSI < -50, bleibe auf dem Werbekanal, auch wenn CONNECT_REQs gesehen werden.```
./sniff_receiver.py -c 38 -r -50 -a
Advertisements von MAC 12:34:56:78:9A:BC mitschneiden, auf dem Advertising-Kanal bleiben, auch wenn CONNECT_REQs gesehen werden, Advertisements in data1.pcap speichern.```
./sniff_receiver.py -m 12:34:56:78:9A:BC -a -o data1.pcap
Sniff advertisements and connections for the first MAC address seen with
RSSI >= -40. The RSSI filter will be disabled automatically once a MAC address
has been locked onto. Save captured data to `data2.pcap`.```
./sniff_receiver.py -m top -r -40 -o data2.pcap
Schnüffelt Werbeanzeigen und Verbindungen vom Peripheriegerät mit Big-Endian-IRK 4E0BEA5355866BE38EF0AC2E3F0EBC22. Laden Sie zwei erwartete verschlüsselte Verbindungsparameter-Updates vor; das erste mit einem Intervall von 6, das 6 Verbindungsereignisse nach dem Beobachten einer verschlüsselten LL_CONNECTION_UPDATE_IND durch den Sniffer auftritt. Das zweite erwartete verschlüsselte Verbindungs-Update hat ein Intervall von 39 und ebenfalls DeltaInstant von 6.``` ./sniff_receiver.py -i 4E0BEA5355866BE38EF0AC2E3F0EBC22 -Q 6:6,39:6
Sniffen Sie BT5 Extended Advertisements und Verbindungen von nahegelegenen Geräten (RSSI >= -55).```
./sniff_receiver.py -r -55 -e
Erfassen Sie Legacy- und erweiterte Advertisements und Verbindungen von dem Gerät mit der angegebenen MAC-Adresse. Speichern Sie die erfassten Daten in data3.pcap.```
./sniff_receiver.py -eH -m 12:34:56:78:9A:BC -o data3.pcap
Sniffen Sie erweiterte Werbungen und Verbindungen mit dem Long-Range-Primär-PHY auf Kanal 38.```
./sniff_receiver.py -le -c 38
Aktiv scannen auf Kanal 39 nach Werbepaketen mit einem RSSI größer als -50.``` ./scanner.py -c 39 -r -50
## IRK ermitteln
Wenn Sie ein gerootetes Android-Telefon besitzen, finden Sie IRKs (und LTKs) in der Bluedroid-Konfigurationsdatei. Unter Android 8.1 befindet sich diese unter `/data/misc/bluedroid/bt_config.conf`.
Die `LE_LOCAL_KEY_IRK` gibt die eigene IRK des Android-Geräts an, und die ersten 16 Byte von `LE_KEY_PID` für jedes verbundene Gerät in der Datei kennzeichnen die IRK des verbundenen Geräts. Beachten Sie, dass in dieser Datei gespeicherte Schlüssel im Little-Endian-Format vorliegen, sodass **die Bytereihenfolge der Schlüssel in dieser Datei umgekehrt werden muss.** Beispielsweise muss die Little-Endian-IRK 22BC0E3F2EACF08EE36B865553EA0B4E in 4E0BEA5355866BE38EF0AC2E3F0EBC22 (Big Endian) geändert werden, wenn sie mit der Option `-i` an Sniffle übergeben wird.
Sie können die IRK und den LTK auch über HCI-Snoop-Protokolle ermitteln, die auf Android oder iOS erfasst wurden, ohne das Gerät zu rooten:
* 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-Plugin
Sniffle enthält ein Wireshark-Plugin, mit dem sich Sniffle automatisch aus der Wireshark-GUI starten lässt, indem die Schnittstelle 'Sniffle' ausgewählt wird.
Um das Sniffle-Plugin zu installieren, ermitteln Sie zunächst den Speicherort Ihres persönlichen Extcap-Ordners im Dialog 'Über Wireshark' (*Hilfe* > *Über Wireshark* > *Ordner* > *Persönlicher Extcap-Pfad*). Auf POSIX-Systemen (Linux und Mac OS) mit aktuellen Wireshark-Versionen (4.2.0+) befindet sich dieser Ordner unter `~/.local/lib/wireshark/extcap`. Unter Windows finden Sie ihn unter `%USERPROFILE%\AppData\Roaming\Wireshark\extcap`.
Auf POSIX-Systemen können Sie das Sniffle-Extcap-Plugin einfach in das persönliche Wireshark-Extcap-Verzeichnis verlinken:```
mkdir -p ~/.local/lib/wireshark/extcap
ln -s $(pwd)/python_cli/sniffle_extcap.py ~/.local/lib/wireshark/extcap
Unter macOS versucht Wireshark möglicherweise, das Xcode-Python anstelle des in Ihrem PATH angegebenen Python aus Ihrem Shell-Profil zu verwenden. Daher kann das Sniffle-Plugin in den Extcap-Schnittstellen fehlen, wenn PySerial nicht für das Xcode-Python installiert ist. Um dies zu beheben, können Sie die Shebang-Zeile von sniffle_extcap.py bearbeiten, um direkt auf das Python mit installiertem PySerial zu verweisen, z. B. das Homebrew-Python unter /opt/homebrew/bin/python3, anstatt auf /usr/bin/env python3.
Unter Windows können Sie die folgenden Dateien und Verzeichnisse aus dem python_cli-Verzeichnis in Ihren persönlichen Extcap-Ordner kopieren:```
sniffle/
sniffle_extcap.py
sniffle_extcap.bat
Unter Windows kann es notwendig sein, `sniffle_extcap.bat` zu bearbeiten, um den Speicherort des Python-Interpreters anzugeben,
falls das Installationsverzeichnis nicht im PATH enthalten ist, z.B.:```
@echo off
C:\my_python_install\python.exe "%~dp0sniffle_extcap.py" %*
Sobald das Plugin installiert wurde, starten Sie Wireshark neu oder wählen Sie Erfassung > Schnittstellen aktualisieren, um die Sniffle-Schnittstelle zu aktivieren.
Während die ursprüngliche Sniffle-Firmware von 2019 ein rein passiver Lauscher war, fügten spätere Firmware-Versionen verschiedene Funktionen hinzu, um Pakete auf unterschiedliche Weise aktiv zu senden. Die aktuelle Sniffle-Firmware unterstützt sowohl die Rolle eines GAP-Zentral- als auch eines Peripheriegeräts, einschließlich aktivem Scannen, Legacy- und Extended Advertising, dem Initiieren von Verbindungen sowie dem Verbundensein in einer zentralen oder peripheren Rolle. Das Skript scanner.py führt aktives Scannen durch. Das Skript initiator.py initiiert eine Verbindung zu einem Peripheriegerät und fungiert dann als verbundener Zentralrechner. Das Skript advertiser.py führt Legacy-Advertising durch und akzeptiert Verbindungsanfragen von anderen Geräten, wodurch es in die Rolle eines verbundenen Peripheriegeräts wechselt.
Die Übertragungsfunktionalität von Sniffle unterscheidet sich etwas von einem herkömmlichen HCI-basierten Bluetooth-Controller, da sie eine sehr niedrige Kontrolle über die genauen PDUs ermöglicht, die auf der Link-Layer-Ebene gesendet werden. Diese niedrige Kontrolle ermöglicht es dem Host-seitigen Code, zusätzliche Funktionalitäten zu implementieren, wie z. B. Link-Layer-Fuzz-Tests oder Link-Layer-Relay-Angriffe.
Ich habe noch nicht die Zeit gefunden, die API der Sniffle-Firmware formell zu dokumentieren, obwohl sie bei Betrachtung der Host-seitigen Implementierung in sniffle_hw.py weitgehend selbsterklärend ist. Aktives Scannen (das Scan-Anfragen sendet) wird durch cmd_scan aktiviert. Die Initiierung einer Verbindung wird durch cmd_connect ausgelöst, wobei es am einfachsten ist, den Wrapper initiate_conn zu verwenden. Advertising (optional verbindbar) wird für Legacy-Advertising durch cmd_advertise oder für Extended Advertising durch cmd_advertise_ext aktiviert.
Seit der Behebung des TI-Problems EXT_EP-11735 Mitte 2024 behandelt der XDS110-Debugger (auf TI Launchpad-Boards enthalten) hohe Baudraten wie 2M (wie von Sniffle verwendet) auf angemessene Weise ohne übermäßige Latenz. Allerdings verwendet die neueste XDS110-Firmware immer noch einen gepufferten DMA-gesteuerten UART-Betrieb bei solchen Baudraten und kann daher immer noch Latenzen von bis zu 30 ms verursachen. Diese Latenz ist für die Verwendung als Sniffer unerheblich, kann jedoch für aktivere Vorgänge wie Host-seitigen Code, der als GATT-Client oder -Server fungiert, oder für Relay-Angriffe nachteilig sein. Die unten beschriebene Modifikation der XDS110-Firmware Version 3.0.0.28 für den interruptbasierten Betrieb kann die Latenz für solche zeitkritischen Vorgänge dennoch erheblich reduzieren. Es sollte möglich sein, eine ähnliche Modifikation an der neuesten XDS110-Firmware vorzunehmen, aber ich habe mir nicht die Zeit genommen, sie zu reverse-engineeren und die richtigen Bits zum Ändern zu finden.
Mitte 2024 und früher hatte die Firmware des TI XDS110-Debuggers (auf Launchpad-Boards enthalten) ein unerwünschtes Verhalten in seiner USB-zu-UART-Brücke, bei dem bei hohen Baudraten starke Latenzen auftreten konnten, insbesondere bei häufigen kleinen Schreibvorgängen, wie sie von der Sniffle-Firmware durchgeführt werden. Dieses Problem bestand seit Jahren und war im April 2024 mit der XDS110-Firmware 3.0.0.28, die mit UniFlash 8.6.0 gebündelt war, immer noch vorhanden. Die Ursache war, dass die XDS110-Firmware im DMA-basierten Betrieb UART-Daten in einem Puffer ansammelte, dessen Größe proportional zur Baudrate war, und darauf wartete, dass dieser Puffer gefüllt wurde, bevor die Daten übertragen wurden. Es gab eine Logik, um diesen Puffer zu leeren, wenn in den letzten 15 Millisekunden keine neuen Daten eintrafen, aber diese Leerungslogik wurde nie ausgelöst, wenn Sniffle häufig kleine Pakete von Verbindungsereignissen alle paar Millisekunden hinzufügte. Infolge dieses suboptimalen Verhaltens konnten gesniffte Daten in verzögerten Schüben auf dem Host erscheinen.
Die XDS110-Firmware hat auch einen alternativen Modus für den UART-Betrieb, bei dem jeder UART-Empfang einen Interrupt auslöst, der dazu führt, dass die Daten sofort an den Host weitergegeben werden. Dieser interruptbasierte Modus hat eine viel geringere Latenz. Die Firmware verwendet ihn jedoch nur für Baudraten unter 230400. Als Workaround für die hohe Latenz des DMA-Modus bei häufigen kleinen Datenblöcken können Sie die Firmware so modifizieren, dass sie den interruptbasierten USB-UART-Bridge auch bei hohen Baudraten (wie 2M Baud, wie von Sniffle verwendet) verwendet. In Firmware 3.0.0.28 (mit Uniflash 8.6.0 enthalten) können Sie die Bytes an Offset 0x0A14 von 61 3F auf 00 1F hex-editieren. Dadurch wird die Baudrate für den Umschaltpunkt zum DMA-basierten UART-Betrieb von 230400 auf 0x200000 (2097152) geändert.
Beachten Sie, dass die oben beschriebenen Offsets und Byte-Modifikationen nur für Firmware 3.0.0.28 gelten und für andere Firmware-Versionen unterschiedlich sind. Das Flashen ungültiger Firmware auf Ihren Debugger kann diesen beschädigen, und wir übernehmen keine Verantwortung für eventuelle Schäden.
Die folgenden Befehle können unter Linux verwendet werden, um die XDS110-Firmware für niedrige Latenz bei hohen Baudraten zu modifizieren:``` 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
Vor dem Flashen überprüfen Sie, dass die SHA256-Prüfsumme der modifizierten Firmware `c226f2e9cb2b9f0bc111ca11f2903d58d4065293468623428c0e8eeb22086dcf` ist. Nach dieser Überprüfung führen Sie die folgenden Befehle aus, um die modifizierte XDS110-Debugger-Firmware zu flashen:```
./xdsdfu -m
./xdsdfu -f firmware_3.0.0.28_fastuart.bin -r
Sniffle kann verwendet werden, um Link-Layer-Relaying von Bluetooth LE Datenverkehr durchzuführen. Bei der Durchführung des Relayings fungiert ein Sniffle-Gerät als BLE Central (mit relay_master.py) und ein zweites Sniffle-Gerät als BLE Peripheral (mit relay_slave.py). Master und Slave sind historische Begriffe für BLE Central bzw. Peripheral. Der Relay-Master erfasst Werbe- und Scan-Response-Daten vom echten Peripheral und übergibt sie an den Relay-Slave. Der Relay-Slave sendet Werbesendungen und Scan-Responses, die den echten Peripheral nachahmen, und akzeptiert Verbindungen. Nach dem Akzeptieren einer Verbindung benachrichtigt der Relay-Slave den Relay-Master, der dann eine Verbindung zum echten Peripheral initiiert. Von diesem Zeitpunkt an werden alle Link-Layer-Pakete zwischen Relay-Master und -Slave weitergeleitet.
Das Relay-Master-Skript bietet die Funktion, schnellere Verbindungsintervalle auf einer oder beiden Seiten des Relays anzufordern, um die Latenz zu reduzieren. Bei Verwendung des XDS110 als USB/UART-Brücke beachten Sie, dass die XDS110-Firmware zusätzliche Latenz für das Relay verursacht, sofern Sie sie nicht wie oben beschrieben modifizieren.
Bitte beachten Sie, dass das Relay-Master-Skript einen Netzwerk-Listener erstellt, der an alle Schnittstellen (0.0.0.0) gebunden ist, und dass das zur Kommunikation zwischen den relayenden Geräten verwendete Netzwerkprotokoll keine Sicherheit bietet. Verwenden Sie diese Skripte nur in vertrauenswürdigen Netzwerkumgebungen.
Die Verwendung der Relay-Master- (Central) und Slave- (Peripheral) Skripte wird unten gezeigt. Derzeit wird Extended Advertising von den Relay-Skripten nicht unterstützt.``` 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
EINGABE:```
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