nccgroup/sniffleSniffer Bluetooth 5 et 4.x LE pour le matériel TI CC1352/CC26x2 avec prise en charge de la publicité étendue, de tous les modes PHY, du filtrage MAC/RSSI et de l'export PCAP compatible avec Wireshark.
Sniffle est un sniffer pour Bluetooth 5 et 4.x (LE) utilisant le matériel TI CC1352/CC26x2.
Sniffle possède un certain nombre de fonctionnalités utiles, notamment :
Si vous ne souhaitez pas faire l'effort de mettre en place un environnement de construction pour le firmware, vous pouvez simplement flasher les binaires de firmware précompilés à l'aide d'UniFlash/DSLite. Les binaires de firmware précompilés sont joints aux versions de la page des versions (releases) GitHub de ce projet. Lorsque vous utilisez un firmware précompilé, assurez-vous d'utiliser le code Python correspondant à l'étiquette de version plutôt qu'à la branche master afin d'éviter les problèmes de compatibilité avec un firmware en retard sur la branche master.
Le arm-none-eabi-gcc fourni par les gestionnaires de paquets des différentes
distributions Linux manque souvent de certains fichiers d'en-tête ou nécessite des
modifications de la configuration du linker. Pour un minimum de tracas, je suggère
d'utiliser le GCC ARM lié ci-dessus. Vous pouvez simplement télécharger et extraire
les exécutables précompilés.
Le SDK TI est fourni sous forme d'un binaire exécutable qui extrait un ensemble de
code source une fois que vous acceptez le contrat de licence. Sous Linux et Mac, le
répertoire d'installation par défaut se trouve dans ~/ti/. Cela fonctionne très bien
et mes makefiles s'attendent à ce chemin, je suggère donc de simplement conserver la
valeur par défaut ici. Il en va de même pour l'outil TI SysConfig.
Une fois le SDK extrait, vous devrez modifier un makefile pour l'adapter à votre
environnement de construction. Dans ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01
(ou là où le SDK a été installé), il y a un makefile nommé imports.mak.
Les seuls chemins à définir ici pour construire Sniffle sont ceux de GCC, XDC,
cmake et SysConfig. Nous n'avons pas besoin du compilateur CCS. Voir le diff ci-dessous
comme exemple, et adaptez-le à l'endroit où vous avez installé les choses.```
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
À partir de la version SDK 8.30.01.01, pour compiler avec les versions récentes de GCC (et binutils), une petite modification du SDK est nécessaire pour éviter les erreurs de liaison "Unknown destination type (ARM/Thumb)" et "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
Après avoir effectué cette modification, vous devrez recompiler le SDK.``` cd ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 make build-gcc -j5
### Obtenir DSLite
DSLite est l'outil serveur de programmation et de débogage en ligne de commande de TI pour les débogueurs XDS110. Les cartes Launchpad CC26xx et CC13xx intègrent toutes deux des débogueurs XDS110. Malheureusement, TI ne fournit pas de téléchargement autonome de DSLite en ligne de commande. Le moyen le plus simple d'obtenir DSLite est d'installer [UniFlash](http://www.ti.com/tool/download/UNIFLASH) depuis TI. Il est disponible pour Linux, Mac et Windows. L'exécutable DSLite se trouvera dans `deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite` par rapport au répertoire d'installation d'UniFlash. Sous Linux, le répertoire d'installation par défaut d'UniFlash se trouve dans `~/ti/`.
Vous devez placer le répertoire de l'exécutable DSLite dans votre `$PATH`.
## Compilation du firmware
Une fois GCC, DSLite et le SDK installés et opérationnels, la compilation de Sniffle devrait être simple. Il suffit de naviguer vers le répertoire `fw` et d'exécuter `make`. Si vous n'avez pas installé le SDK dans le répertoire par défaut, vous devrez peut-être modifier `SIMPLELINK_SDK_INSTALL_DIR` dans le makefile.
Si vous compilez pour ou installez sur une variante de Launchpad autre que CC26x2R, vous devez spécifier `PLATFORM=xxx`, soit comme argument à make, soit en le définissant comme variable d'environnement avant d'invoquer make. Les valeurs prises en charge pour `PLATFORM` se trouvent dans le makefile du firmware. Assurez-vous d'effectuer un `make clean` avant de compiler pour une autre plateforme.
## Installation du firmware (carte TI Launchpad)
Pour installer Sniffle sur une Launchpad CC26x2R (branchée) à l'aide de DSLite, exécutez `make load` dans le répertoire `fw`. Pour tout autre modèle de Launchpad, vous devez spécifier l'argument `PLATFORM` à make comme décrit ci-dessus. Vous pouvez également flasher le binaire `sniffle.hex` compilé à l'aide de l'interface graphique UniFlash.
## Installation du firmware (dongle USB SONOFF)
Pour installer Sniffle sur un dongle SONOFF CC2652P (équipé d'un pont USB/UART CP2102N), utilisez l'utilitaire [JelmerT/cc2538-bsl](https://github.com/JelmerT/cc2538-bsl) pour flasher le firmware à l'aide du bootloader ROM intégré avec la commande suivante :```
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv sniffle_cc1352p1_cc2652p1.hex
Au 10 janvier 2025, il existe un bug dans cc2538-bsl qui l'empêche de réinitialiser la puce CC2562P du dongle Sonoff après le flashage. Le correctif se trouve dans la pull request 173, qui n'a pas encore été fusionnée. En attendant que la pull request soit fusionnée, vous pouvez utiliser mon fork à l'adresse https://github.com/sultanqasim/cc2538-bsl.
En 2022, en raison des pénuries de puces liées à la pandémie de COVID-19, certains dongles Sonoff CC2652P ont été fabriqués avec des ponts USB/UART CP2102 (non-N) plafonnés à 921600 bauds. Si vous en possédez un, vous devrez flasher une image de firmware différente qui utilise un débit plus lent de 921600 bauds. Cette version spéciale à débit plus lent est nommée sniffle_cc1352p1_cc2652p1_1M.hex (variante de compilation CC2652P1F_1M). Vous devrez également invoquer les utilitaires Sniffle avec l'option -b 921600 pour remplacer le débit en bauds par défaut de 2000000.
AVERTISSEMENT : Ne flashez pas la mauvaise variante de compilation via le bootloader, sinon vous risquez de briquer l'appareil et de vous retrouver sans accès au bootloader. Pour les appareils Sonoff CC2652P, utilisez le fichier sniffle_cc1352p1_cc2652p1.hex (variante de compilation CC2652P1F) ou le fichier sniffle_cc1352p1_cc2652p1_1M.hex(variante de compilationCC2652P1F_1M`) pour un débit de 921600 bauds. Si vous flashez la mauvaise variante et vous retrouvez sans accès au bootloader, il peut être possible de récupérer l'appareil via JTAG/SWD.
Electronic Cats fournit un outil Catnip Uploader pour charger le firmware. Pour plus d'informations, consultez le dépôt. Téléchargez l'outil et suivez ces commandes :```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
Vous devez modifier le *COMPORT* pour le chemin approprié à votre carte.
En utilisant la commande `python3 catnip_uploader.py load 2 COMPORT`, vous chargerez
le firmware `2: nccgroup_v1.10.0_sniffle_cc1352p7_1M.hex`.
**Pour charger le firmware, le Catsniffer V3 nécessite SerialPassthroughwithboot**.
**AVERTISSEMENT :** Ne flashez pas la mauvaise variante de build à l'aide du bootloader, ou vous
risquez de briquer l'appareil et de vous verrouiller hors du bootloader. Si vous
utilisez le script `catnip_uploader.py` pour récupérer et installer le firmware, il
ne présentera que des firmware compatibles. Cependant, si vous choisissez de compiler et d'installer
le firmware manuellement, assurez-vous d'utiliser la bonne variante de build. Pour les appareils CatSniffer
v3, utilisez le fichier `sniffle_cc1352p7_1M.hex` (variante de build `CC1352P74_1M`).
Les appareils CatSniffer v1.x/v2.x utilisent une variante de puce différente (CC1352P1) qui nécessite un
build de firmware différent (variante `CC1352P1F3_1M`, image `sniffle_cc1352p1_cc2652p1_1M.hex`).
Sniffle n'a pas été testé sur les appareils CatSniffer v1.x/v2.x, mais ils fonctionneront
probablement tant que vous flashez la variante de build appropriée. Si vous flashez la
mauvaise variante et que vous vous verrouillez hors du bootloader, il est peut-être possible de récupérer
l'appareil à l'aide de JTAG/SWD.
## Utilisation du 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
Le débogueur XDS110 des cartes Launchpad crée deux ports série. Sous Linux, ils sont généralement nommés ttyACM0 et ttyACM1. Le premier des deux ports série créés est utilisé pour communiquer avec Sniffle. Par défaut, l'interface en ligne de commande Python communique via le premier périphérique CDC-ACM qu'elle voit correspondant au couple VID:PID USB TI XDS110, ou le premier dongle Sonoff qu'elle voit. Vous devrez peut-être remplacer cela par l'option de ligne de commande -s si vous utilisez un adaptateur série USB différent ou si des périphériques USB CDC-ACM supplémentaires sont connectés.
Pour l'option -r (filtre RSSI), une valeur de -40 a tendance à bien fonctionner si le renifleur est très proche ou presque en contact avec le dispositif émetteur. Le filtre RSSI est très utile pour ignorer les publicités non pertinentes dans un environnement RF chargé. Le filtre RSSI n'est actif que lors de la capture des publicités, car vous voulez toujours capturer le trafic des canaux de données pour une connexion suivie. Vous ne voulez probablement pas utiliser un filtre RSSI lorsque le filtrage MAC est actif, car vous risquez de perdre des publicités provenant de l'adresse MAC d'intérêt lorsque le RSSI est trop faible.
Pour suivre les publicités et obtenir un reniflage de connexion fiable, vous devez configurer un filtre MAC avec l'option -m. Vous devez spécifier l'adresse MAC du dispositif périphérique, et non celle du dispositif central. Pour déterminer quelle adresse MAC renifler, vous pouvez exécuter le renifleur avec le filtrage RSSI tout en plaçant le renifleur près de la cible. Cela affichera les publicités du dispositif cible, y compris son adresse MAC. Il convient de noter que de nombreux dispositifs BLE diffusent avec une adresse MAC aléatoire plutôt qu'avec leur adresse MAC fixe « réelle » inscrite sur une étiquette.
La plupart des nouveaux dispositifs BLE utilisent des adresses privées résolubles (RPA) plutôt que des adresses statiques fixes ou publiques. Bien que vous puissiez configurer un filtre MAC pour une RPA particulière, les dispositifs changent périodiquement leur RPA. Les RPA peuvent être résolues (associées à un dispositif particulier) si la clé de résolution d'identité (IRK) est connue. Sniffle prend en charge la résolution automatisée des RPA lorsque l'IRK est fournie. Cela évite d'avoir à mettre à jour constamment le filtre MAC à chaque changement de RPA. Vous pouvez spécifier une IRK pour Sniffle avec l'option -i; l'IRK doit être fournie au format hexadécimal, avec l'octet le plus significatif (MSB) en premier. Spécifier une IRK permet à Sniffle de sauter de canal avec un annonceur de la même manière qu'avec un filtre MAC. La fonctionnalité de filtrage MAC basée sur l'IRK (-i) est mutuellement exclusive avec la fonctionnalité de filtrage MAC statique (-m).
Il existe également une fonctionnalité pratique pour identifier automatiquement l'adresse MAC de l'annonceur dont la publicité ou la réponse d'analyse contient une chaîne spécifiée (série d'octets). C'est utile pour les dispositifs avec RPA dont l'IRK est inconnue, mais dont la publicité contient une chaîne statique suffisamment unique pour l'identification. Cette fonctionnalité utilise l'option -S, avec la chaîne spécifiée à l'aide de séquences d'échappement standard. Par exemple, pour rechercher un annonceur dont la publicité contient la séquence d'octets hexadécimaux DE AD BE EF, spécifiez -S "\xDE\xAD\xBE\xEF". Pour rechercher un annonceur avec la chaîne « hello », spécifiez simplement -S "hello". Lorsque la fonctionnalité de recherche de chaîne est utilisée, toutes les adresses MAC sont initialement acceptées jusqu'à ce qu'une publicité contenant la chaîne recherchée soit trouvée. Ensuite, un filtre MAC sera configuré avec l'adresse MAC de l'annonceur correspondant, et tout filtre RSSI serait automatiquement désactivé.
Pour activer le suivi des pointeurs auxiliaires dans la publicité étendue Bluetooth 5, activez l'option -e. Pour améliorer les performances et la fiabilité de la capture de la publicité étendue, cette option désactive le saut sur les canaux publicitaires primaires, même lorsqu'un filtre MAC est configuré. Si vous n'êtes pas sûr qu'une connexion sera établie via la publicité héritée ou étendue, vous pouvez activer le drapeau -H en conjonction avec -e pour effectuer le saut de canal primaire avec les publicités héritées, et l'écoute planifiée des paquets auxiliaires de publicité étendue. Lors de la combinaison de -e et -H, la fiabilité de la détection de connexion peut être réduite par rapport au saut sur les canaux publicitaires primaires (hérités) ou secondaires (étendus) seuls.
Pour renifler la PHY longue portée sur les canaux publicitaires primaires, spécifiez l'option -l. Notez qu'aucun saut entre les canaux publicitaires primaires n'est pris en charge en mode longue portée, car toute la publicité longue portée utilise le mécanisme étendu BT5. Sous le mécanisme étendu, les pointeurs auxiliaires sur les trois canaux primaires pointent vers le même paquet auxiliaire, donc le saut entre les canaux primaires est inutile.
Pour ne pas afficher les paquets de données vides à l'écran lors du suivi d'une connexion, utilisez le drapeau -q. Cela facilite l'observation des communications significatives en temps réel, mais peut masquer les moments où le suivi de connexion est instable ou perdu.
Pour les connexions chiffrées, Sniffle prend en charge la détection des mises à jour des paramètres de connexion même lorsque la clé de chiffrement est inconnue, et tente de mesurer les nouveaux paramètres. Cependant, si vous connaissez le nouvel intervalle de connexion et le delta Instant à attendre lors des mises à jour chiffrées des paramètres de connexion, vous pouvez les spécifier avec l'option --preload/-Q pour améliorer les performances/la fiabilité. La paire Intervalle:DeltaInstant attendue doit être fournie sous forme d'entiers séparés par deux-points. L'Intervalle est un entier représentant des multiples de 1,25 ms (comme défini dans LL_CONNECTION_UPDATE_IND). DeltaInstant est le nombre d'événements de connexion entre le moment où le paquet de mise à jour de connexion est transmis et celui où les nouveaux paramètres sont appliqués. DeltaInstant doit être supérieur ou égal à 6, conformément aux exigences de la spécification Bluetooth pour les dispositifs centraux. Si plusieurs mises à jour chiffrées des paramètres sont attendues, vous pouvez fournir plusieurs paires de paramètres, séparées par des virgules (par ex. 6:7,39:8). Si vous avez un dispositif qui émet des PDU de mise à jour PHY chiffrées qui ne changent pas la PHY, ou qui émet des PDU chiffrées de contrôle de puissance LE sans aucun changement de PHY, vous pouvez utiliser l'option --nophychange/-n.
Pour arrêter le renifleur, appuyez sur Ctrl-C.
Si pour une raison quelconque le micrologiciel du renifleur se bloque et refuse de capturer tout trafic même avec les filtres désactivés, vous devez réinitialiser le MCU du renifleur. Sur les cartes Launchpad, le bouton de réinitialisation se trouve à côté du port 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
Les arguments de la ligne de commande du scanner fonctionnent de la même manière que ceux du sniffer. L'objectif de l'utilitaire scanner est de collecter une liste des périphériques à proximité qui diffusent des publicités, et d'émettre activement des demandes de scan pour les périphériques observés, sans avoir le déluge de données défilant à toute vitesse que l'on obtient avec l'utilitaire sniffer. Le matériel/firmware passera en mode de scan actif où il signalera les publicités reçues, émettra des demandes de scan pour celles qui sont scannables, et signalera les réponses de scan reçues. L'utilitaire scanner n'enregistrera et ne signalera les adresses MAC observées qu'une seule fois, sans inonder l'affichage. Une fois que vous avez terminé de capturer les publicités, appuyez sur Ctrl-C pour arrêter le scan et afficher les résultats. Le scanner affichera la dernière publicité et la dernière réponse de scan de chaque cible. Les résultats du scan seront triés par RSSI en ordre décroissant.
## Exemples d'utilisation
Sniffez toutes les publicités sur le canal 38, ignorez les RSSI < -50, restez sur le canal de publicité même lorsque des CONNECT\_REQs sont vus.```
./sniff_receiver.py -c 38 -r -50 -a
Sniffez les publicités de la MAC 12:34:56:78:9A:BC, restez sur le canal de publicité même lorsque des CONNECT_REQ sont observés, enregistrez les publicités dans data1.pcap.```
./sniff_receiver.py -m 12:34:56:78:9A:BC -a -o data1.pcap
Sniffez les publicités et les connexions pour la première adresse MAC vue avec
RSSI >= -40. Le filtre RSSI sera désactivé automatiquement une fois qu'une adresse MAC
a été verrouillée. Enregistrez les données capturées dans `data2.pcap`.```
./sniff_receiver.py -m top -r -40 -o data2.pcap
Reniflez les publicités et connexions du périphérique avec IRK big endian 4E0BEA5355866BE38EF0AC2E3F0EBC22. Préchargez deux mises à jour de paramètres de connexion chiffrées attendues ; la première avec un Interval de 6, survenant à un instant 6 événements de connexion après qu'un LL_CONNECTION_UPDATE_IND chiffré soit observé par le sniffer. La seconde mise à jour de connexion chiffrée attendue a un Interval de 39, et un DeltaInstant de 6 également.``` ./sniff_receiver.py -i 4E0BEA5355866BE38EF0AC2E3F0EBC22 -Q 6:6,39:6
Sniffez les publicités étendues BT5 et les connexions des appareils à proximité (RSSI >= -55).```
./sniff_receiver.py -r -55 -e
Capturez les annonces et connexions legacy et étendues provenant de l'appareil
avec l'adresse MAC spécifiée. Enregistrez les données capturées dans data3.pcap.```
./sniff_receiver.py -eH -m 12:34:56:78:9A:BC -o data3.pcap
Sniffez les publicités étendues et les connexions en utilisant la PHY primaire à longue portée sur
le canal 38.```
./sniff_receiver.py -le -c 38
Scannez activement le canal 39 pour les publicités avec un RSSI supérieur à -50.``` ./scanner.py -c 39 -r -50
## Obtention de l'IRK
Si vous disposez d'un téléphone Android rooté, vous pouvez trouver les IRK (et les LTK) dans le fichier de configuration Bluedroid. Sur Android 8.1, celui-ci se trouve à `/data/misc/bluedroid/bt_config.conf`. Le `LE_LOCAL_KEY_IRK` spécifie l'IRK propre à l'appareil Android, et les 16 premiers octets de `LE_KEY_PID` pour chaque appareil apparié dans le fichier indiquent l'IRK de l'appareil apparié. Notez que les clés stockées dans ce fichier sont en little endian, donc **l'ordre des octets des clés dans ce fichier devra être inversé.** Par exemple, l'IRK little endian 22BC0E3F2EACF08EE36B865553EA0B4E doit être transformé en 4E0BEA5355866BE38EF0AC2E3F0EBC22 (big endian) lorsqu'il est passé à Sniffle avec l'option `-i`.
Vous pouvez également trouver l'IRK et la LTK à partir des journaux HCI Snoop capturés sur Android ou iOS sans rooter l'appareil :
* 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>
## Extension Wireshark
Sniffle inclut une extension Wireshark qui permet de lancer Sniffle automatiquement depuis l'interface graphique de Wireshark en sélectionnant l'interface de capture « Sniffle ».
Pour installer l'extension Sniffle, commencez par localiser le dossier personnel Extcap dans la boîte de dialogue « À propos de Wireshark » (*Aide* > *À propos de Wireshark* > *Dossiers* > *Chemin Extcap personnel*). Sur les systèmes POSIX (Linux et Mac OS) exécutant des versions récentes de Wireshark (4.2.0+), ce dossier se trouve à `~/.local/lib/wireshark/extcap`. Sous Windows, il se trouve à `%USERPROFILE%\AppData\Roaming\Wireshark\extcap`.
Sur les systèmes POSIX, vous pouvez simplement créer un lien symbolique de l'extension extcap de Sniffle vers le répertoire extcap personnel de Wireshark :```
mkdir -p ~/.local/lib/wireshark/extcap
ln -s $(pwd)/python_cli/sniffle_extcap.py ~/.local/lib/wireshark/extcap
Sur Mac OS, Wireshark peut essayer d'utiliser le Python de Xcode plutôt que celui de votre PATH défini par votre profil shell. Ainsi, le plugin Sniffle peut ne pas apparaître dans les interfaces extcap si PySerial n'est pas installé pour le Python de Xcode. Pour corriger cela, vous pouvez modifier la ligne shebang de sniffle_extcap.py pour qu'elle pointe directement vers le Python avec PySerial installé, par exemple le Python Homebrew à /opt/homebrew/bin/python3, plutôt que /usr/bin/env python3.
Sous Windows, vous pouvez copier les fichiers et répertoires suivants depuis le répertoire python_cli dans votre dossier Personnel Extcap :```
sniffle/
sniffle_extcap.py
sniffle_extcap.bat
Sous Windows, il peut être nécessaire de modifier `sniffle_extcap.bat` pour spécifier l'emplacement de
l'interpréteur python si le répertoire d'installation n'est pas inclus dans le PATH, par exemple :```
@echo off
C:\my_python_install\python.exe "%~dp0sniffle_extcap.py" %*
Une fois le plugin installé, redémarrez Wireshark ou choisissez Capture > Refresh Interfaces pour activer l'interface Sniffle.
Alors que le firmware Sniffle original de 2019 était purement un récepteur passif, les versions ultérieures
du firmware ont ajouté diverses fonctionnalités pour transmettre activement des paquets de différentes manières. Le firmware Sniffle actuel
prend en charge le fait d'agir à la fois comme un appareil central et un appareil périphérique GAP, notamment le scan actif, l'advertising
legacy et étendu, l'initiation de connexions, et le fait d'être connecté en tant que central ou
périphérique. Le script scanner.py effectue le scan actif. Le script initiator.py
initie une connexion vers un périphérique puis agit en tant que central connecté. Le
script advertiser.py effectue l'advertising legacy et accepte les demandes de connexion d'autres
appareils, passant à un rôle de périphérique connecté.
La fonctionnalité de transmission de Sniffle est un peu différente de celle d'un contrôleur Bluetooth traditionnel basé sur HCI, car elle vous donne un contrôle de très bas niveau sur les PDU exactes envoyées au niveau de la couche de liaison. Ce contrôle de bas niveau permet au code côté hôte d'implémenter des fonctionnalités supplémentaires, comme le fuzzing de la couche de liaison ou les attaques par relais sur la couche de liaison.
Je n'ai pas encore pris le temps de documenter formellement l'API du firmware Sniffle, même si elle est assez
explicite quand on regarde son implémentation côté hôte dans sniffle_hw.py. Le scan actif
(qui transmet des requêtes de scan) est activé par cmd_scan. L'initiation de connexion est déclenchée par
cmd_connect, même s'il est plus simple d'utiliser le wrapper initiate_conn. L'advertising (optionnellement
connectable) est activé par cmd_advertise pour l'advertising legacy, ou par cmd_advertise_ext pour
l'advertising étendu.
Depuis la correction du problème TI EXT_EP-11735 à la mi-2024, le débogueur XDS110 (inclus sur les cartes TI Launchpad) gère les débits en bauds élevés tels que 2M (comme utilisé par Sniffle) de manière raisonnable sans latence excessive. Cependant, le dernier firmware XDS110 utilise toujours un fonctionnement UART piloté par DMA avec tampon à de tels débits, et il peut donc encore introduire une latence allant jusqu'à 30 ms. Cette latence est sans conséquence pour une utilisation comme sniffer, mais peut être préjudiciable pour des opérations plus actives, comme du code côté hôte agissant en tant que client ou serveur GATT, ou effectuant des attaques par relais. La modification du firmware XDS110 version 3.0.0.28 décrite ci-dessous pour un fonctionnement par interruptions peut encore considérablement réduire la latence pour de telles opérations sensibles au temps. Il devrait être possible d'apporter une modification similaire au dernier firmware XDS110, mais je n'ai pas pris le temps d'en faire la rétro-ingénierie et de trouver les bons bits à modifier.
À la mi-2024 et avant, le firmware du débogueur TI XDS110 (inclus sur les cartes Launchpad) présentait un comportement indésirable dans son pont USB vers UART : à des débits en bauds élevés, une latence sévère pouvait survenir, surtout avec de petites écritures fréquentes comme celles effectuées par le firmware Sniffle. Ce problème a existé pendant des années, et était toujours présent en avril 2024 avec le firmware XDS110 3.0.0.28 fourni avec UniFlash 8.6.0. La cause racine était que, dans le fonctionnement basé sur DMA, le firmware XDS110 accumulait les données UART dans un tampon dont la taille était proportionnelle au débit en bauds, et attendait que ce tampon se remplisse avant de transférer les données. Une logique permettait de vider ce tampon si aucune nouvelle donnée n'arrivait au cours des 15 dernières millisecondes, mais cette logique de vidage n'était jamais déclenchée lorsque Sniffle ajoutait fréquemment de petits paquets provenant d'événements de connexion toutes les quelques millisecondes. En raison de ce comportement sous-optimal, les données sniffées pouvaient apparaître en rafales retardées sur l'hôte.
Le firmware XDS110 dispose également d'un mode alternatif pour le fonctionnement UART, où chaque réception UART déclenche une interruption qui aboutit à ce que les données soient immédiatement transmises à l'hôte. Ce mode de fonctionnement par interruptions a une latence bien plus faible. Cependant, le firmware ne l'utilise que pour les débits en bauds inférieurs à 230400. Pour contourner la latence élevée du fonctionnement en mode DMA avec de fréquents petits morceaux de données, vous pouvez modifier le firmware pour utiliser un pont USB-UART par interruptions même à des débits en bauds élevés (comme le 2M baud utilisé par Sniffle). Dans le firmware 3.0.0.28 (inclus avec Uniflash 8.6.0), vous pouvez modifier en hexadécimal les octets à l'offset 0x0A14 de 61 3F à 00 1F. Cela changera le débit en bauds pour le passage au fonctionnement UART basé sur DMA de 230400 à 0x200000 (2097152).
Sachez que les offsets et les modifications d'octets décrits ci-dessus ne concernent que le firmware 3.0.0.28, et seront différents pour d'autres versions de firmware. Flasher un firmware invalide sur votre débogueur peut l'endommager, et nous déclinons toute responsabilité en cas de dommage.
Les commandes suivantes peuvent être utilisées sous Linux pour modifier le firmware XDS110 afin d'obtenir une UART à faible latence à des débits en bauds élevés :``` 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
Avant de flasher, vérifiez que la somme SHA256 du firmware modifié est
`c226f2e9cb2b9f0bc111ca11f2903d58d4065293468623428c0e8eeb22086dcf`. Après avoir vérifié cela,
exécutez les commandes suivantes pour flasher le firmware modifié du debugger XDS110 :```
./xdsdfu -m
./xdsdfu -f firmware_3.0.0.28_fastuart.bin -r
Sniffle peut être utilisé pour effectuer du relais de couche liaison
du trafic Bluetooth LE. Lors du relais, un périphérique Sniffle agit en tant que
central BLE (avec relay_master.py) et un second périphérique Sniffle agit en
tant que périphérique BLE (avec relay_slave.py). Maître et esclave sont des termes
historiques pour central et périphérique BLE respectivement. Le maître de relais
capture les données d'advertising et de scan response du périphérique authentique,
puis les transmet à l'esclave de relais. L'esclave de relais transmet des publicités
et des réponses de scan imitant le périphérique authentique et accepte les connexions.
Après avoir accepté une connexion, l'esclave de relais notifie le maître de relais,
qui initie ensuite une connexion vers le périphérique authentique. À partir de ce
point, tous les paquets de la couche liaison sont transmis entre le maître et
l'esclave de relais.
Le script du maître de relais offre la possibilité de demander des intervalles de connexion plus courts des deux côtés du relais afin de réduire la latence. Si vous utilisez le XDS110 comme pont USB/UART, sachez que le firmware du XDS110 introduit une latence supplémentaire au relais, sauf si vous le modifiez comme décrit ci-dessus.
Veuillez noter que le script du maître de relais crée un listener réseau qui se lie à toutes les interfaces (0.0.0.0), et que le protocole réseau utilisé pour communiquer entre les dispositifs de relais n'offre aucune sécurité. N'utilisez ces scripts que dans des environnements réseau de confiance.
L'utilisation des scripts du maître de relais (central) et de l'esclave de relais (périphérique) est présentée ci-dessous. Actuellement, l'advertising étendu n'est pas pris en charge par les scripts de relais.``` 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
I don't see any content to translate. The input chunk appears to be empty. Please provide the chunk text.```
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