nccgroup/sniffleSniffer Bluetooth 5 e 4.x LE per hardware TI CC1352/CC26x2 con supporto per extended advertising, tutte le modalità PHY, filtraggio MAC/RSSI ed esportazione PCAP compatibile con Wireshark.
Sniffle è uno sniffer per Bluetooth 5 e 4.x (LE) che utilizza hardware TI CC1352/CC26x2.
Sniffle ha una serie di funzionalità utili, tra cui:
Se non vuoi affrontare la fatica di configurare un ambiente di build per il firmware, puoi semplicemente flashare i binari del firmware precompilati usando UniFlash/DSLite. I binari del firmware precompilati sono allegati alle release nella scheda release di GitHub di questo progetto. Quando usi il firmware precompilato, assicurati di usare il codice Python corrispondente al tag della release piuttosto che il ramo master per evitare problemi di compatibilità con un firmware che è indietro rispetto al ramo master.
L'arm-none-eabi-gcc fornito tramite i gestori di pacchetti delle varie distribuzioni
Linux spesso manca di alcuni file header o richiede alcune modifiche alla configurazione
del linker. Per evitare problemi, suggerisco di usare il GCC ARM collegato sopra.
Puoi semplicemente scaricare ed estrarre gli eseguibili precompilati.
Il TI SDK è fornito come binario eseguibile che estrae una serie di codice
sorgente una volta accettato il contratto di licenza. Su Linux e Mac, la directory
di installazione predefinita è ~/ti/. Questo funziona bene e i miei makefile
si aspettano questo percorso, quindi suggerisco di seguire l'impostazione predefinita. Lo stesso
vale per lo strumento TI SysConfig.
Una volta estratto l'SDK, dovrai modificare un makefile per adattarlo
al tuo ambiente di build. All'interno di ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01
(o ovunque sia stato installato l'SDK) c'è un makefile chiamato imports.mak.
Gli unici percorsi che devono essere impostati qui per compilare Sniffle sono quelli per GCC,
XDC, cmake e SysConfig. Non abbiamo bisogno del compilatore CCS. Vedi il diff qui sotto
come esempio e adattalo a dove hai installato le cose.```
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
A partire dalla versione SDK 8.30.01.01, per compilare con versioni recenti di GCC (e binutils),
è necessaria una piccola modifica all'SDK per evitare errori di linking
"Unknown destination type (ARM/Thumb)" e "dangerous relocation: unsupported relocation".```
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
Dopo aver apportato questa modifica, dovrai ricompilare l'SDK.``` cd ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 make build-gcc -j5
### Ottenere DSLite
DSLite è lo strumento da riga di comando di TI per la programmazione e il debug dei debugger XDS110. Le schede Launchpad CC26xx e CC13xx includono entrambe debugger XDS110. Purtroppo TI non fornisce un download standalone da riga di comando di DSLite. Il modo più semplice per ottenere DSLite è installare [UniFlash](http://www.ti.com/tool/download/UNIFLASH) da TI. È disponibile per Linux, Mac e Windows. L'eseguibile DSLite si troverà in `deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite` relativo alla directory di installazione di UniFlash. Su Linux, la directory di installazione predefinita di UniFlash è dentro `~/ti/`.
Dovresti inserire la directory dell'eseguibile DSLite nel tuo `$PATH`.
## Compilazione del Firmware
Una volta che GCC, DSLite e l'SDK sono installati e funzionanti, compilare Sniffle dovrebbe essere semplice. Basta navigare nella directory `fw` ed eseguire `make`. Se non hai installato l'SDK nella directory predefinita, potresti dover modificare `SIMPLELINK_SDK_INSTALL_DIR` nel makefile.
Se stai compilando per o installando su una variante di Launchpad diversa da CC26x2R, devi specificare `PLATFORM=xxx`, sia come argomento di make, sia definendolo come variabile d'ambiente prima di invocare make. I valori supportati per `PLATFORM` si trovano nel makefile del firmware. Assicurati di eseguire `make clean` prima di compilare per una piattaforma diversa.
## Installazione del Firmware (Scheda TI Launchpad)
Per installare Sniffle su una Launchpad CC26x2R (collegata) usando DSLite, esegui `make load` nella directory `fw`. Per qualsiasi altro modello di Launchpad, devi specificare l'argomento `PLATFORM` a make come descritto sopra. Puoi anche flashare il binario compilato `sniffle.hex` usando la GUI di UniFlash.
## Installazione del Firmware (Dongle USB SONOFF)
Per installare Sniffle su un dongle SONOFF CC2652P (dotato di bridge USB/UART CP2102N), usa l'utility [JelmerT/cc2538-bsl](https://github.com/JelmerT/cc2538-bsl) per flashare il firmware usando il bootloader ROM integrato con il seguente comando:```
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv sniffle_cc1352p1_cc2652p1.hex
A partire dal 10 gennaio 2025, c'è un bug in cc2538-bsl che impedisce di
resettare il chip CC2562P nel dongle Sonoff dopo il flashing. La correzione per
questo problema si trova nella pull request 173, che
non è ancora stata unita. Nel frattempo, in attesa che la pull request venga
unita, puoi usare il mio fork su https://github.com/sultanqasim/cc2538-bsl.
Nel 2022, a causa della carenza di chip dovuta alla pandemia di COVID-19, alcuni dongle Sonoff CC2652P sono stati
costruiti con bridge chip USB/UART CP2102 (non-N) che sono limitati a 921600 baud. Se
hai uno di questi, dovrai flashare un'immagine firmware diversa che usa
una velocità di baud più bassa, 921600. Questa build speciale a velocità di baud ridotta si chiama
sniffle_cc1352p1_cc2652p1_1M.hex (variante di build CC2652P1F_1M). Dovrai anche
richiamare le utilità Sniffle con l'opzione -b 921600 per sovrascrivere la
velocità di baud predefinita di 2000000.
ATTENZIONE: Non flashare la variante di build sbagliata usando il bootloader, o
rischi di brickare il dispositivo e di bloccarti fuori dal bootloader. Per i dispositivi Sonoff
CC2652P, usa il file sniffle_cc1352p1_cc2652p1.hex (variante di build CC2652P1F)
oppure il file sniffle_cc1352p1_cc2652p1_1M.hex(variante di buildCC2652P1F_1M`)
per una velocità di baud di 921600. Se flashi la variante sbagliata e rimani bloccato
fuori dal bootloader, potrebbe essere possibile recuperare il dispositivo usando JTAG/SWD.
Electronic Cats fornisce uno strumento Catnip Uploader per caricare il firmware. Per informazioni dettagliate, fare riferimento al repository. Scarica lo strumento e segui questi comandi:```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
Devi modificare *COMPORT* con il percorso appropriato per la tua board.
Usando il comando `python3 catnip_uploader.py load 2 COMPORT`, caricherai
il firmware `2: nccgroup_v1.10.0_sniffle_cc1352p7_1M.hex`.
**Per caricare il firmware, Catsniffer V3 richiede SerialPassthroughwithboot**.
**ATTENZIONE:** Non flashare la variante di build errata tramite il bootloader, o
rischi di brickkare il dispositivo e di rimanere bloccato fuori dal bootloader. Se
usi lo script `catnip_uploader.py` per scaricare e installare il firmware, ti
verranno presentati solo firmware compatibili. Tuttavia, se scegli di compilare e installare
il firmware manualmente, assicurati di usare la variante di build corretta. Per i dispositivi CatSniffer
v3, usa il file `sniffle_cc1352p7_1M.hex` (variante di build `CC1352P74_1M`).
I dispositivi CatSniffer v1.x/v2.x usano una variante di chip diversa (CC1352P1) che richiede una
build firmware differente (variante `CC1352P1F3_1M`, immagine `sniffle_cc1352p1_cc2652p1_1M.hex`).
Sniffle non è stato testato sui dispositivi CatSniffer v1.x/v2.x, ma probabilmente
funzioneranno purché tu flashi la variante di build appropriata. Se flashi la
variante sbagliata e rimani bloccato fuori dal bootloader, potrebbe essere possibile recuperare
il dispositivo tramite JTAG/SWD.
## Utilizzo dello 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
Il debugger XDS110 sulle schede Launchpad crea due porte seriali. Su Linux, di solito sono denominate ttyACM0 e ttyACM1. La prima delle due porte seriali create viene utilizzata per comunicare con Sniffle. Di default, la CLI Python comunica utilizzando il primo dispositivo CDC-ACM che rileva corrispondente alla combinazione USB VID:PID del TI XDS110, oppure il primo dongle Sonoff che vede. Potrebbe essere necessario sovrascrivere questo comportamento con l'opzione da riga di comando -s se si utilizza un adattatore seriale USB diverso o si hanno dispositivi USB CDC-ACM aggiuntivi collegati.
Per l'opzione -r (filtro RSSI), un valore di -40 tende a funzionare bene se lo sniffer è molto vicino o quasi a contatto con il dispositivo trasmittente. Il filtro RSSI è molto utile per ignorare annunci advertising irrilevanti in un ambiente RF affollato. Il filtro RSSI è attivo solo durante l'acquisizione di annunci advertising, poiché si desidera sempre catturare il traffico dei canali dati per una connessione seguita. Probabilmente non si vorrà usare un filtro RSSI quando il filtraggio MAC è attivo, poiché si potrebbero perdere annunci advertising dall'indirizzo MAC di interesse quando l'RSSI è troppo basso.
Per saltare di canale in canale seguendo gli annunci advertising e avere uno sniffing affidabile delle connessioni, è necessario impostare un filtro MAC con l'opzione -m. Si dovrebbe specificare l'indirizzo MAC del dispositivo periferico, non quello del dispositivo centrale. Per capire quale indirizzo MAC sniffare, si può eseguire lo sniffer con il filtraggio RSSI mentre lo si posiziona vicino al bersaglio. Questo mostrerà gli annunci advertising del dispositivo target, incluso il suo indirizzo MAC. Va notato che molti dispositivi BLE pubblicizzano con un indirizzo MAC casuale piuttosto che con il loro indirizzo MAC fisso "reale" stampato su un'etichetta.
La maggior parte dei nuovi dispositivi BLE utilizza indirizzi privati risolvibili (RPA) piuttosto che indirizzi statici fissi o pubblici. Sebbene sia possibile impostare un filtro MAC su una particolare RPA, i dispositivi cambiano periodicamente la propria RPA. Le RPA possono essere risolte (associate a un particolare dispositivo) se si conosce la chiave di risoluzione dell'identità (IRK). Sniffle supporta la risoluzione automatica delle RPA quando viene fornita la IRK. Questo evita la necessità di aggiornare continuamente il filtro MAC ogni volta che la RPA cambia. È possibile specificare una IRK per Sniffle con l'opzione -i; la IRK deve essere fornita in formato esadecimale, con il byte più significativo (MSB) per primo. Specificare una IRK consente a Sniffle di fare channel hopping con un advertiser allo stesso modo in cui fa con un filtro MAC. La funzione di filtraggio MAC basata su IRK (-i) è mutuamente esclusiva con la funzione di filtraggio MAC statico (-m).
Esiste anche una funzione pratica per identificare automaticamente l'indirizzo MAC dell'advertiser il cui annuncio pubblicitario o scan response contiene una stringa specificata (sequenza di byte). Ciò è utile per dispositivi con RPA in cui la IRK è sconosciuta, ma l'annuncio pubblicitario contiene una stringa statica sufficientemente univoca adatta all'identificazione. Questa funzione utilizza l'opzione -S, con la stringa specificata tramite sequenze di escape standard. Ad esempio, per cercare un advertiser il cui annuncio pubblicitario contiene la sequenza di byte esadecimali DE AD BE EF, specificare -S "\xDE\xAD\xBE\xEF". Per cercare un advertiser con la stringa "hello", basta specificare -S "hello". Quando viene utilizzata la funzione di ricerca per stringa, inizialmente tutti gli indirizzi MAC verranno accettati finché non viene trovato un annuncio pubblicitario contenente la stringa cercata. Dopodiché, verrà impostato un filtro MAC con l'indirizzo MAC dell'advertiser corrispondente e qualsiasi filtro RSSI verrà disabilitato automaticamente.
Per abilitare il seguimento dei puntatori ausiliari nell'advertising esteso Bluetooth 5, abilitare l'opzione -e. Per migliorare prestazioni e affidabilità nell'acquisizione dell'advertising esteso, questa opzione disabilita l'hopping sui canali advertising primari, anche quando è impostato un filtro MAC. Se non si è sicuri se una connessione verrà stabilita tramite advertising legacy o esteso, è possibile abilitare il flag -H insieme a -e per eseguire l'hopping sui canali primari con annunci legacy e l'ascolto pianificato dei pacchetti ausiliari dell'advertising esteso. Quando si combinano -e e -H, l'affidabilità del rilevamento della connessione potrebbe essere ridotta rispetto all'hopping sui soli canali advertising primari (legacy) o secondari (estesi).
Per sniffare la PHY a lungo raggio sui canali advertising primari, specificare l'opzione -l. Si noti che in modalità lungo raggio non è supportato l'hopping tra i canali advertising primari, poiché tutto l'advertising a lungo raggio utilizza il meccanismo esteso BT5. Con il meccanismo esteso, i puntatori ausiliari su tutti e tre i canali primari puntano allo stesso pacchetto ausiliario, quindi l'hopping tra i canali primari non è necessario.
Per non stampare a schermo i pacchetti dati vuoti durante il seguimento di una connessione, usare il flag -q. Questo rende più facile osservare comunicazioni significative in tempo reale, ma può nascondere quando il seguimento della connessione è instabile o perso.
Per le connessioni crittografate, Sniffle supporta il rilevamento degli aggiornamenti dei parametri di connessione anche quando la chiave di crittografia è sconosciuta, e tenta di misurare i nuovi parametri. Tuttavia, se si conoscono il nuovo intervallo di connessione e il delta Instant da aspettarsi negli aggiornamenti crittografati dei parametri di connessione, è possibile specificarli con l'opzione --preload/-Q per migliorare prestazioni/affidabilità. La coppia prevista Interval:DeltaInstant deve essere fornita come interi separati da due punti. Interval è un intero che rappresenta multipli di 1,25 ms (come definito in LL_CONNECTION_UPDATE_IND). DeltaInstant è il numero di eventi di connessione tra la trasmissione del pacchetto di aggiornamento della connessione e l'applicazione dei nuovi parametri. DeltaInstant deve essere maggiore o uguale a 6, come richiesto dalla specifica Bluetooth per i dispositivi centrali. Se sono attesi più aggiornamenti crittografati dei parametri, è possibile fornire più coppie di parametri, separate da virgole (es. 6:7,39:8). Se si dispone di un dispositivo che invia PDU di aggiornamento PHY crittografate senza cambiare la PHY, o emette PDU crittografate di controllo della potenza LE senza variazioni della PHY, si può usare l'opzione --nophychange/-n.
Per fermare lo sniffer, premere Ctrl-C.
Se per qualche motivo il firmware dello sniffer si blocca e rifiuta di catturare qualsiasi traffico anche con i filtri disabilitati, si dovrebbe ripristinare il MCU dello sniffer. Sulle schede Launchpad, il pulsante di reset si trova accanto alla porta 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
Gli argomenti della riga di comando dello scanner funzionano come quelli dello sniffer. Lo scopo
dell'utility scanner è raccogliere un elenco dei dispositivi vicini che stanno trasmettendo
advertisement, e inviare attivamente richieste di scan per i dispositivi osservati, senza il
torrente di dati che scorre rapidamente come con l'utility sniffer. L'hardware/firmware entrerà
in una modalità di scansione attiva in cui riporterà gli advertisement ricevuti, invierà richieste
di scan per quelli scansionabili e riporterà le scan response ricevute. L'utility scanner
registrerà e riporterà gli indirizzi MAC osservati solo una volta, senza inondare il display.
Una volta terminata la cattura degli advertisement, premi Ctrl-C per interrompere la scansione
e visualizzare i risultati. Lo scanner mostrerà l'ultimo advertisement e l'ultima scan response
per ciascun target. I risultati della scansione saranno ordinati per RSSI in ordine decrescente.
## Esempi di utilizzo
Sniffa tutti gli advertisement sul canale 38, ignora RSSI < -50, resta sul canale advertising
anche quando vengono visti CONNECT\_REQs.```
./sniff_receiver.py -c 38 -r -50 -a
Intercetta gli advertisement dal MAC 12:34:56:78:9A:BC, rimani sul canale advertising
anche quando vengono visti CONNECT_REQs, salva gli advertisement in data1.pcap.```
./sniff_receiver.py -m 12:34:56:78:9A:BC -a -o data1.pcap
Intercetta annunci e connessioni per il primo indirizzo MAC rilevato con
RSSI >= -40. Il filtro RSSI verrà disabilitato automaticamente una volta che
un indirizzo MAC è stato agganciato. Salva i dati catturati in `data2.pcap`.```
./sniff_receiver.py -m top -r -40 -o data2.pcap
Sniffa advertising e connessioni dalla periferica con IRK big endian 4E0BEA5355866BE38EF0AC2E3F0EBC22. Precarica due aggiornamenti previsti e cifrati dei parametri di connessione; il primo con un Interval di 6, che si verifica a un istante di 6 eventi di connessione dopo che un LL_CONNECTION_UPDATE_IND cifrato viene osservato dallo sniffer. Il secondo aggiornamento di connessione previsto e cifrato ha un Interval di 39 e DeltaInstant di 6 anch'esso.``` ./sniff_receiver.py -i 4E0BEA5355866BE38EF0AC2E3F0EBC22 -Q 6:6,39:6
Sniffa annunci estesi BT5 e connessioni da dispositivi vicini (RSSI >= -55).```
./sniff_receiver.py -r -55 -e
Intercetta gli annunci legacy ed estesi e le connessioni dal dispositivo con
l'indirizzo MAC specificato. Salva i dati catturati in data3.pcap.```
./sniff_receiver.py -eH -m 12:34:56:78:9A:BC -o data3.pcap
Intercetta annunci estesi e connessioni utilizzando la PHY primaria a lungo raggio sul
canale 38.```
./sniff_receiver.py -le -c 38
Esegui una scansione attiva sul canale 39 per advertisement con RSSI superiore a -50.``` ./scanner.py -c 39 -r -50
## Ottenere l'IRK
Se hai un telefono Android con root, puoi trovare gli IRK (e gli LTK) nel file di configurazione
Bluedroid. Su Android 8.1, questo si trova in `/data/misc/bluedroid/bt_config.conf`.
`LE_LOCAL_KEY_IRK` specifica l'IRK del dispositivo Android stesso, e i primi 16
byte di `LE_KEY_PID` per ogni dispositivo associato nel file indicano l'IRK
del dispositivo associato. Tieni presente che le chiavi memorizzate in questo file sono little endian, quindi
**l'ordine dei byte delle chiavi in questo file dovrà essere invertito.** Ad esempio,
l'IRK little endian 22BC0E3F2EACF08EE36B865553EA0B4E deve essere cambiato in
4E0BEA5355866BE38EF0AC2E3F0EBC22 (big endian) quando viene passato a Sniffle con
l'opzione `-i`.
Puoi anche trovare l'IRK e l'LTK attraverso i log HCI Snoop catturati su Android o iOS
senza effettuare il root del dispositivo:
* 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>
## Plugin per Wireshark
Sniffle include un plugin per Wireshark che rende possibile avviare Sniffle automaticamente
dalla GUI di Wireshark selezionando l'interfaccia di cattura 'Sniffle'.
Per installare il plugin di Sniffle, individua prima la posizione della tua cartella Personal Extcap nella
finestra di dialogo 'About Wireshark' (*Help* > *About Wireshark* > *Folders* > *Personal Extcap path*).
Su sistemi POSIX (Linux e Mac OS) con versioni recenti di Wireshark (4.2.0+), questa
cartella si trova in `~/.local/lib/wireshark/extcap`. Su Windows, si trova in
`%USERPROFILE%\AppData\Roaming\Wireshark\extcap`.
Su sistemi POSIX, puoi semplicemente creare un collegamento simbolico del plugin extcap di Sniffle nella directory
extcap personale di Wireshark:```
mkdir -p ~/.local/lib/wireshark/extcap
ln -s $(pwd)/python_cli/sniffle_extcap.py ~/.local/lib/wireshark/extcap
Su Mac OS, Wireshark potrebbe provare a usare il Python di Xcode invece del Python nel tuo PATH specificato
dal tuo profilo di shell. Pertanto, il plugin Sniffle potrebbe non comparire nelle interfacce extcap se PySerial
non è installato per il Python di Xcode. Per risolvere il problema, puoi modificare la riga shebang di
sniffle_extcap.py per puntare direttamente al Python con PySerial installato, ad esempio il
Python di Homebrew in /opt/homebrew/bin/python3, invece di /usr/bin/env python3.
Su Windows, puoi copiare i seguenti file e directory dalla directory python_cli nella
tua cartella Personal Extcap:```
sniffle/
sniffle_extcap.py
sniffle_extcap.bat
Su Windows, potrebbe essere necessario modificare `sniffle_extcap.bat` per specificare la posizione
dell'interprete Python se la directory di installazione non è inclusa nel PATH, ad esempio:```
@echo off
C:\my_python_install\python.exe "%~dp0sniffle_extcap.py" %*
Una volta installato il plugin, riavvia Wireshark o scegli Capture > Refresh Interfaces per abilitare l'interfaccia Sniffle.
Mentre il firmware originale Sniffle del 2019 era puramente un listener passivo, le versioni successive del firmware hanno aggiunto varie funzionalità per trasmettere attivamente pacchetti in diversi modi. Il firmware Sniffle attuale supporta il funzionamento sia come dispositivo centrale GAP che periferico, inclusa la scansione attiva, l'advertising legacy ed esteso, l'avvio di connessioni e l'essere connesso in un ruolo centrale o periferico. Lo script scanner.py esegue la scansione attiva. Lo script initiator.py avvia una connessione a un dispositivo periferico e poi agisce come centrale connesso. Lo script advertiser.py esegue l'advertising legacy e accetta richieste di connessione da altri dispositivi, passando a un ruolo periferico connesso.
La funzionalità di trasmissione di Sniffle è un po' diversa da un controller Bluetooth tradizionale basato su HCI, perché offre un controllo di bassissimo livello sugli esatti PDU inviati a livello di link. Questo controllo di basso livello consente al codice lato host di implementare funzionalità aggiuntive, come il fuzz testing del livello di link o gli attacchi di relay a livello di link.
Non ho ancora trovato il tempo di documentare formalmente l'API del firmware Sniffle, anche se è abbastanza autoesplicativa guardando l'implementazione lato host in sniffle_hw.py. La scansione attiva (che trasmette richieste di scansione) viene attivata da cmd_scan. L'avvio della connessione è innescato da cmd_connect, anche se è più semplice usare il wrapper initiate_conn. L'advertising (opzionalmente connettibile) viene attivato da cmd_advertise per l'advertising legacy, oppure cmd_advertise_ext per l'advertising esteso.
Dalla correzione del problema TI EXT_EP-11735 a metà 2024, il debugger XDS110 (incluso nelle schede TI Launchpad) gestisce baud rate elevati come 2M (quello usato da Sniffle) in modo ragionevole, senza eccessiva latenza. Tuttavia, l'ultimo firmware XDS110 usa ancora un funzionamento UART basato su DMA con buffer a tali baud rate e, di conseguenza, può ancora introdurre una latenza fino a 30 ms. Questa latenza è irrilevante per l'uso come sniffer, ma può essere dannosa per operazioni più attive come il codice lato host che agisce da client o server GATT, o che esegue attacchi di relay. La modifica del firmware XDS110 versione 3.0.0.28 descritta di seguito per il funzionamento basato su interrupt può ancora ridurre notevolmente la latenza per tali operazioni sensibili al tempo. Dovrebbe essere possibile apportare una modifica simile all'ultimo firmware XDS110, ma non ho trovato il tempo di farne il reverse engineering e individuare i bit giusti da cambiare.
A metà 2024 e prima, il firmware del debugger TI XDS110 (incluso nelle schede Launchpad) aveva un comportamento indesiderato nel suo bridge USB-UART, dove a baud rate elevati può esserci una latenza severa, specialmente con frequenti piccole scritture come quelle fatte dal firmware Sniffle. Questo problema era presente da anni ed era ancora presente ad aprile 2024 con il firmware XDS110 3.0.0.28 incluso in UniFlash 8.6.0. La causa principale era che, nel funzionamento basato su DMA, il firmware XDS110 accumulava i dati UART in un buffer la cui dimensione era proporzionale al baud rate e aspettava che questo buffer si riempisse prima di trasferire i dati. C'era una logica per svuotare questo buffer se non arrivavano nuovi dati negli ultimi 15 millisecondi, ma questa logica di svuotamento non veniva mai attivata quando Sniffle aggiungeva di frequente piccoli pacchetti dagli eventi di connessione ogni pochi millisecondi. A causa di questo comportamento non ottimale, i dati sniffati potevano apparire in burst ritardati sull'host.
Il firmware XDS110 ha anche una modalità alternativa per il funzionamento UART, in cui ogni ricezione UART attiva un interrupt che fa sì che i dati vengano immediatamente passati all'host. Questa modalità di funzionamento basata su interrupt ha una latenza molto più bassa. Tuttavia, il firmware la usa solo per baud rate inferiori a 230400. Come soluzione alternativa all'elevata latenza della modalità DMA con frequenti piccoli blocchi di dati, puoi modificare il firmware per usare il bridging USB-UART basato su interrupt anche a baud rate elevati (come 2M baud, quello usato da Sniffle). Nel firmware 3.0.0.28 (incluso con Uniflash 8.6.0), puoi modificare in hex i byte all'offset 0x0A14 da 61 3F a 00 1F. Questo cambierà il baud rate per il passaggio al funzionamento UART basato su DMA da 230400 a 0x200000 (2097152).
Tieni presente che gli offset e le modifiche ai byte descritti sopra sono validi solo per il firmware 3.0.0.28 e saranno diversi per versioni diverse del firmware. Flashare firmware non valido sul tuo debugger potrebbe danneggiarlo e non ci assumiamo alcuna responsabilità per eventuali danni che potrebbero verificarsi.
I seguenti comandi possono essere usati su Linux per modificare il firmware XDS110 per una UART a bassa latenza ad alti baud rate:``` 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
Prima di effettuare il flash, verifica che la somma SHA256 del firmware modificato sia `c226f2e9cb2b9f0bc111ca11f2903d58d4065293468623428c0e8eeb22086dcf`. Dopo aver verificato, esegui i seguenti comandi per eseguire il flash del firmware modificato del debugger XDS110:```
./xdsdfu -m
./xdsdfu -f firmware_3.0.0.28_fastuart.bin -r
Sniffle può essere utilizzato per eseguire l'inoltro a livello di collegamento del traffico Bluetooth LE. Quando si esegue l'inoltro, un dispositivo Sniffle agisce come centrale BLE (usando relay_master.py) e un secondo dispositivo Sniffle agisce come periferica BLE (usando relay_slave.py). Master e slave sono termini storici rispettivamente per centrale e periferica BLE. Il relay master cattura i dati di advertising e scan response dalla periferica genuina, poi li passa al relay slave. Il relay slave trasmette gli advertising e le scan response imitando la periferica genuina e accetta connessioni. Dopo aver accettato una connessione, il relay slave notifica il relay master, che avvia quindi una connessione alla periferica genuina. Da questo punto in poi, tutti i pacchetti a livello di collegamento vengono inoltrati tra relay master e relay slave.
Lo script relay master fornisce la funzionalità per richiedere intervalli di connessione più rapidi su entrambi i lati del relay per ridurre la latenza. Se si utilizza l'XDS110 come bridge USB/UART, tenere presente che il firmware dell'XDS110 introduce ulteriore latenza al relay a meno che non venga modificato come descritto in precedenza.
Si noti che lo script relay master crea un listener di rete che si collega a tutte le interfacce (0.0.0.0), e il protocollo di rete utilizzato per comunicare tra i dispositivi relay non fornisce alcuna sicurezza. Utilizzare questi script solo in ambienti di rete affidabili.
Di seguito viene mostrato l'utilizzo degli script relay master (centrale) e slave (periferica). Al momento, l'advertising esteso non è supportato dagli script relay.``` 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
The input content for chunk 43 is empty. There is no text provided to translate. Please supply the actual Markdown content for this chunk.```
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