nccgroup/sniffleSniffer Bluetooth 5 y 4.x LE para hardware TI CC1352/CC26x2 con soporte para publicidad extendida, todos los modos PHY, filtrado MAC/RSSI y exportación PCAP compatible con Wireshark.
Sniffle es un sniffer para Bluetooth 5 y 4.x (LE) que utiliza hardware TI CC1352/CC26x2.
Sniffle tiene varias características útiles, que incluyen:
Si no quieres pasar por el esfuerzo de configurar un entorno de compilación para el firmware, puedes simplemente flashear binarios de firmware precompilados usando UniFlash/DSLite. Los binarios de firmware precompilados están adjuntos a las versiones en la pestaña de versiones de GitHub de este proyecto. Al usar firmware precompilado, asegúrate de usar el código Python correspondiente a la etiqueta de la versión, no la rama master, para evitar problemas de compatibilidad con el firmware que está detrás de la rama master.
El arm-none-eabi-gcc proporcionado a través del gestor de paquetes de varias distribuciones de Linux a menudo carece de algunos archivos de cabecera o requiere algunos cambios en la configuración del enlazador. Para mínimas complicaciones, sugiero usar el ARM GCC enlazado arriba. Puedes simplemente descargar y extraer los ejecutables precompilados.
El SDK de TI se proporciona como un binario ejecutable que extrae un montón de código fuente una vez que aceptas el acuerdo de licencia. En Linux y Mac, el directorio de instalación predeterminado está dentro de ~/ti/. Esto funciona bien y mis makefiles esperan esta ruta, así que sugiero simplemente usar el valor predeterminado aquí. Lo mismo aplica para la herramienta TI SysConfig.
Una vez que el SDK ha sido extraído, necesitarás editar un makefile para que coincida con tu entorno de compilación. Dentro de ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 (o donde sea que se haya instalado el SDK) hay un makefile llamado imports.mak. Las únicas rutas que deben configurarse aquí para compilar Sniffle son para GCC, XDC, cmake y SysConfig. No necesitamos el compilador CCS. Mira el diff a continuación como ejemplo, y adáptalo para donde instalaste las cosas.```
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 partir de la versión 8.30.01.01 del SDK, para compilar con versiones recientes de GCC (y binutils),
es necesaria una pequeña modificación al SDK para evitar errores de enlace
"Unknown destination type (ARM/Thumb)" y "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
Después de realizar esta modificación, necesitarás recompilar el SDK.``` cd ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 make build-gcc -j5
### Obteniendo DSLite
DSLite es la herramienta de servidor de depuración y programación en línea de comandos de TI para depuradores XDS110. Las placas Launchpad CC26xx y CC13xx incluyen depuradores XDS110. Desafortunadamente, TI no proporciona una descarga independiente de DSLite para línea de comandos. La forma más sencilla de obtener DSLite es instalar [UniFlash](http://www.ti.com/tool/download/UNIFLASH) de TI. Está disponible para Linux, Mac y Windows. El ejecutable de DSLite se encontrará en `deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite` relativo al directorio de instalación de UniFlash. En Linux, el directorio de instalación predeterminado de UniFlash está dentro de `~/ti/`.
Debe colocar el directorio del ejecutable de DSLite dentro de su `$PATH`.
## Construcción del Firmware
Una vez que GCC, DSLite y el SDK estén instalados y operativos, construir Sniffle debería ser sencillo. Simplemente navegue al directorio `fw` y ejecute `make`. Si no instaló el SDK en el directorio predeterminado, es posible que necesite editar `SIMPLELINK_SDK_INSTALL_DIR` en el makefile.
Si está construyendo para o instalando en alguna variante de Launchpad que no sea CC26x2R, debe especificar `PLATFORM=xxx`, ya sea como argumento para make, o definiéndolo como una variable de entorno antes de invocar make. Los valores compatibles para `PLATFORM` se pueden encontrar en el makefile del firmware. Asegúrese de realizar un `make clean` antes de construir para una plataforma diferente.
## Instalación del Firmware (Placa TI Launchpad)
Para instalar Sniffle en una Launchpad CC26x2R (conectada) usando DSLite, ejecute `make load` dentro del directorio `fw`. Para cualquier otro modelo de Launchpad, debe especificar el argumento `PLATFORM` para make como se describió anteriormente. También puede flashear el binario compilado `sniffle.hex` usando la GUI de UniFlash.
## Instalación del Firmware (Dongle USB SONOFF)
Para instalar Sniffle en un dongle SONOFF CC2652P (equipado con un puente USB/UART CP2102N), use la utilidad [JelmerT/cc2538-bsl](https://github.com/JelmerT/cc2538-bsl) para flashear el firmware usando el cargador de arranque ROM incorporado con el siguiente comando:```
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv sniffle_cc1352p1_cc2652p1.hex
A partir del 10 de enero de 2025, hay un error en cc2538-bsl que impide reiniciar el chip CC2562P en el dongle Sonoff después de flashear. La solución está en el pull request 173, que aún no ha sido fusionada. Mientras tanto, mientras espera que se fusione el pull request, puede usar mi fork en https://github.com/sultanqasim/cc2538-bsl.
En 2022, debido a la escasez de chips durante la pandemia de COVID-19, algunos dongles Sonoff CC2652P se fabricaron con chips puente USB/UART CP2102 (no N) que están limitados a 921600 baudios. Si tiene uno de estos, necesitará flashear una imagen de firmware diferente que use una velocidad de baudios más lenta de 921600. Esta compilación especial de velocidad de baudios más lenta se llama sniffle_cc1352p1_cc2652p1_1M.hex (variante de compilación CC2652P1F_1M). También necesitará invocar las utilidades de Sniffle con la opción -b 921600 para anular la velocidad de baudios predeterminada de 2000000.
ADVERTENCIA: No flashee la variante de compilación incorrecta usando el cargador de arranque, o corre el riesgo de brickear el dispositivo y bloquearse fuera del cargador de arranque. Para dispositivos Sonoff CC2652P, use el archivo sniffle_cc1352p1_cc2652p1.hex (variante de compilación CC2652P1F) o el archivo sniffle_cc1352p1_cc2652p1_1M.hex (variante de compilación CC2652P1F_1M) para una velocidad de baudios de 921600. Si flashea la variante incorrecta y se bloquea fuera del cargador de arranque, puede ser posible recuperar el dispositivo usando JTAG/SWD.
Electronic Cats proporciona una herramienta Catnip Uploader para cargar firmware. Para obtener información detallada, consulte el repositorio. Descargue la herramienta y siga estos comandos:```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
Necesitas cambiar el *COMPORT* a la ruta adecuada para tu placa.
Usando el comando `python3 catnip_uploader.py load 2 COMPORT`, cargarás
el firmware `2: nccgroup_v1.10.0_sniffle_cc1352p7_1M.hex`.
**Para cargar el firmware, Catsniffer V3 requiere SerialPassthroughwithboot**.
**ADVERTENCIA:** No flashees la variante de compilación incorrecta usando el bootloader, o corres
el riesgo de brickear el dispositivo y bloquearte fuera del bootloader. Si
usas el script `catnip_uploader.py` para obtener e instalar el firmware, solo
te presentará firmware compatible. Sin embargo, si decides compilar e instalar
el firmware manualmente, asegúrate de usar la variante de compilación correcta. Para CatSniffer
v3, usa el archivo `sniffle_cc1352p7_1M.hex` (variante de compilación `CC1352P74_1M`).
Los dispositivos CatSniffer v1.x/v2.x usan una variante de chip diferente (CC1352P1) que necesita una
compilación de firmware distinta (variante `CC1352P1F3_1M`, imagen `sniffle_cc1352p1_cc2652p1_1M.hex`).
Sniffle no ha sido probado en dispositivos CatSniffer v1.x/v2.x pero probablemente
funcionarán siempre que flashees la variante de compilación adecuada. Si flasheas la
variante incorrecta y te bloqueas fuera del bootloader, puede ser posible recuperar
el dispositivo usando JTAG/SWD.
## Uso del 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
El depurador XDS110 en las placas Launchpad crea dos puertos serie. En
Linux, normalmente se denominan ttyACM0 y ttyACM1. El primero de los
dos puertos serie creados se utiliza para comunicarse con Sniffle. De forma predeterminada,
la CLI de Python se comunica usando el primer dispositivo CDC-ACM que encuentra que coincida
con la combinación USB VID:PID del TI XDS110, o el primer dongle Sonoff que encuentra. Es posible
que necesites anular esto con la opción de línea de comandos -s si estás usando
un adaptador serie USB diferente o tienes dispositivos USB CDC-ACM adicionales conectados.
Para la opción -r (filtro RSSI), un valor de -40 suele funcionar bien si el
sniffer está muy cerca o casi tocando el dispositivo transmisor. El filtro
RSSI es muy útil para ignorar anuncios irrelevantes en un entorno RF
ocupado. El filtro RSSI solo está activo cuando se capturan anuncios,
ya que siempre deseas capturar el tráfico del canal de datos de una conexión que se está
siguiendo. Probablemente no quieras usar un filtro RSSI cuando el filtrado MAC
está activo, ya que podrías perder anuncios de la dirección MAC de interés
cuando el RSSI es demasiado bajo.
Para saltar junto con los anuncios y tener un sniffing de conexión confiable, debes
configurar un filtro MAC con la opción -m. Debes especificar la
dirección MAC del dispositivo periférico, no del dispositivo central. Para determinar
qué dirección MAC esnifar, puedes ejecutar el sniffer con filtrado RSSI mientras
colocas el sniffer cerca del objetivo. Esto te mostrará los anuncios del
dispositivo objetivo, incluida su dirección MAC. Cabe señalar que muchos dispositivos BLE
anuncian con una dirección MAC aleatoria en lugar de su MAC fija "real"
escrita en una etiqueta.
La mayoría de los dispositivos BLE nuevos utilizan Direcciones Privadas Resolubles (RPA) en lugar de direcciones
fijas estáticas o públicas. Si bien puedes configurar un filtro MAC para una RPA
particular, los dispositivos cambian periódicamente su RPA. Las RPA se pueden resolver (asociar
con un dispositivo particular) si se conoce la Clave de Resolución de Identidad (IRK). Sniffle
admite la resolución automática de RPA cuando se proporciona la IRK. Esto evita la necesidad
de seguir actualizando el filtro MAC cada vez que la RPA cambia. Puedes especificar una
IRK para Sniffle con la opción -i; la IRK debe proporcionarse en formato
hexadecimal, con el byte más significativo (MSB) primero. Especificar una IRK permite
que Sniffle salte de canal con un anunciante de la misma manera que lo hace con un filtro MAC.
La función de filtrado MAC basada en IRK (-i) es mutuamente excluyente con la función
de filtrado MAC estático (-m).
También hay una función de conveniencia para identificar automáticamente la dirección MAC
del anunciante cuyo anuncio o respuesta de escaneo contiene una cadena
especificada (serie de bytes). Esto es útil para dispositivos con RPA donde se desconoce la IRK,
pero el anuncio contiene una cadena estática suficientemente única adecuada
para la identificación. Esta función utiliza la opción -S, con la cadena especificada
usando secuencias de escape estándar. Por ejemplo, para buscar un anunciante cuyo
anuncio contenga la secuencia de bytes hex DE AD BE EF, especifica
-S "\xDE\xAD\xBE\xEF". Para buscar un anunciante con la cadena "hello",
simplemente especifica -S "hello". Cuando se usa la función de búsqueda de cadenas, inicialmente
se aceptarán todas las direcciones MAC hasta que se encuentre un anuncio que contenga la cadena
de búsqueda. Después de eso, se configurará un filtro MAC con la dirección MAC del
anunciante correspondiente, y cualquier filtro RSSI se desactivaría automáticamente.
Para habilitar el seguimiento de punteros auxiliares en la publicidad extendida de Bluetooth 5,
activa la opción -e. Para mejorar el rendimiento y la confiabilidad en la captura
de publicidad extendida, esta opción deshabilita el salto en los canales de publicidad
primarios, incluso cuando se configura un filtro MAC. Si no estás seguro de si se
establecerá una conexión mediante publicidad heredada o extendida, puedes
activar el indicador -H junto con -e para realizar saltos de canal
primario con anuncios heredados y escucha programada de paquetes auxiliares
de anuncios extendidos. Al combinar -e y -H, la
confiabilidad de la detección de conexión puede reducirse en comparación con saltar solo en
canales de publicidad primarios (heredados) o secundarios (extendidos).
Para esnifar el PHY de largo alcance en los canales de publicidad primarios, especifica la opción -l.
Ten en cuenta que no se admite ningún salto entre canales de publicidad primarios
en el modo de largo alcance, ya que toda la publicidad de largo alcance utiliza el mecanismo
extendido BT5. Bajo el mecanismo extendido, los punteros auxiliares en los tres
canales primarios apuntan al mismo paquete auxiliar, por lo que saltar entre
canales primarios es innecesario.
Para no imprimir paquetes de datos vacíos en pantalla mientras se sigue una conexión, usa
el indicador -q. Esto facilita la observación de comunicaciones significativas en
tiempo real, pero puede ocultar cuándo el seguimiento de la conexión es inestable o se pierde.
Para conexiones cifradas, Sniffle admite la detección de actualizaciones de parámetros
de conexión incluso cuando se desconoce la clave de cifrado, e intenta medir
los nuevos parámetros. Sin embargo, si conoces el nuevo intervalo de conexión y el delta
Instant que esperar en las actualizaciones de parámetros de conexión cifrados, puedes especificarlos
con la opción --preload/-Q para mejorar el rendimiento/confiabilidad.
El par Intervalo:DeltaInstant esperado debe proporcionarse como enteros separados
por dos puntos. El Intervalo es un entero que representa múltiplos de 1,25 ms (según se define
en LL_CONNECTION_UPDATE_IND). DeltaInstant es el número de eventos de conexión
entre el momento en que se transmite el paquete de actualización de conexión y el momento en que se
aplican los nuevos parámetros. DeltaInstant debe ser mayor o igual a 6, según los
requisitos de la especificación Bluetooth para dispositivos centrales. Si se esperan múltiples
actualizaciones de parámetros cifrados, puedes proporcionar múltiples pares de parámetros,
separados por comas (ej. 6:7,39:8). Si tienes un dispositivo que emite
PDU de actualización PHY cifradas que no cambian el PHY, o emite PDU de control de potencia LE
cifradas sin ningún cambio de PHY, puedes usar la opción --nophychange/-n.
Para detener el sniffer, presiona Ctrl-C.
Si por alguna razón el firmware del sniffer se bloquea y se niega a capturar cualquier tráfico incluso con los filtros deshabilitados, debes restablecer el MCU del sniffer. En las placas Launchpad, el botón de restablecimiento está ubicado junto al puerto 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
Los argumentos de línea de comandos del scanner funcionan igual que los del sniffer. El propósito de la utilidad scanner es recopilar una lista de dispositivos cercanos que están anunciando y emitir activamente solicitudes de escaneo para los dispositivos observados, sin tener la avalancha de datos de desplazamiento rápido que se obtiene con la utilidad sniffer. El hardware/firmware entrará en un modo de escaneo activo donde reportará los anuncios recibidos, emitirá solicitudes de escaneo para aquellos que sean escaneables y reportará las respuestas de escaneo recibidas. La utilidad scanner registrará y reportará las direcciones MAC observadas solo una vez, sin saturar la pantalla. Una vez que hayas terminado de capturar anuncios, presiona Ctrl-C para detener el escaneo y reportar los resultados. El scanner mostrará el último anuncio y la última respuesta de escaneo de cada objetivo. Los resultados del escaneo se ordenarán por RSSI en orden descendente.
## Ejemplos de uso
Sniffear todos los anuncios en el canal 38, ignorar RSSI < -50, permanecer en el canal de anuncios incluso cuando se vean CONNECT_REQs.```
./sniff_receiver.py -c 38 -r -50 -a
Esnifa anuncios de la MAC 12:34:56:78:9A:BC, permanece en el canal de publicidad incluso cuando se vean CONNECT_REQs, guarda los anuncios en data1.pcap.```
./sniff_receiver.py -m 12:34:56:78:9A:BC -a -o data1.pcap
Escanea anuncios y conexiones para la primera dirección MAC vista con RSSI >= -40. El filtro RSSI se desactivará automáticamente una vez que se haya bloqueado una dirección MAC. Guarde los datos capturados en `data2.pcap`.```
./sniff_receiver.py -m top -r -40 -o data2.pcap
Sniffear anuncios y conexiones del periférico con IRK big endian 4E0BEA5355866BE38EF0AC2E3F0EBC22. Precargar dos actualizaciones esperadas de parámetros de conexión cifrada; la primera con un Intervalo de 6, que ocurre en un instante 6 eventos de conexión después de que se observe un LL_CONNECTION_UPDATE_IND cifrado por el sniffer. La segunda actualización esperada de conexión cifrada tiene un Intervalo de 39, y un DeltaInstant de 6 también.``` ./sniff_receiver.py -i 4E0BEA5355866BE38EF0AC2E3F0EBC22 -Q 6:6,39:6
Capturar anuncios extendidos de BT5 y conexiones de dispositivos cercanos (RSSI >= -55).```
./sniff_receiver.py -r -55 -e
Capturar anuncios heredados y extendidos y conexiones del dispositivo con la dirección MAC especificada. Guarda los datos capturados en data3.pcap.```
./sniff_receiver.py -eH -m 12:34:56:78:9A:BC -o data3.pcap
Esnifa anuncios extendidos y conexiones usando el PHY primario de largo alcance en el canal 38.```
./sniff_receiver.py -le -c 38
Escanear activamente en el canal 39 anuncios con RSSI mayor a -50.``` ./scanner.py -c 39 -r -50
## Obteniendo el IRK
Si tienes un teléfono Android rooteado, puedes encontrar los IRK (y LTK) en el archivo de configuración de Bluedroid. En Android 8.1, se encuentra en `/data/misc/bluedroid/bt_config.conf`. El `LE_LOCAL_KEY_IRK` especifica el IRK propio del dispositivo Android, y los primeros 16 bytes de `LE_KEY_PID` para cada dispositivo emparejado en el archivo indican el IRK del dispositivo emparejado. Ten en cuenta que las claves almacenadas en este archivo están en little endian, por lo que **el orden de bytes de las claves en este archivo deberá invertirse.** Por ejemplo, el IRK little endian 22BC0E3F2EACF08EE36B865553EA0B4E debe cambiarse a 4E0BEA5355866BE38EF0AC2E3F0EBC22 (big endian) al pasarlo a Sniffle con la opción `-i`.
También puedes encontrar el IRK y el LTK a través de registros HCI Snoop capturados en Android o iOS sin rootear el 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 de Wireshark
Sniffle incluye un plugin de Wireshark que permite lanzar Sniffle automáticamente desde la interfaz gráfica de Wireshark seleccionando la interfaz de captura 'Sniffle'.
Para instalar el plugin de Sniffle, primero encuentra la ubicación de tu carpeta Personal Extcap en el diálogo 'Acerca de Wireshark' (*Ayuda* > *Acerca de Wireshark* > *Carpetas* > *Ruta de Extcap personal*). En sistemas POSIX (Linux y Mac OS) que ejecuten versiones recientes de Wireshark (4.2.0+), esta carpeta se encuentra en `~/.local/lib/wireshark/extcap`. En Windows, se puede encontrar en `%USERPROFILE%\AppData\Roaming\Wireshark\extcap`.
En sistemas POSIX, puedes simplemente enlazar simbólicamente el plugin extcap de Sniffle en el directorio extcap personal de Wireshark:```
mkdir -p ~/.local/lib/wireshark/extcap
ln -s $(pwd)/python_cli/sniffle_extcap.py ~/.local/lib/wireshark/extcap
En Mac OS, Wireshark puede intentar usar el Python de Xcode en lugar del Python en tu PATH especificado
por el perfil de tu shell. Por lo tanto, el complemento Sniffle puede no aparecer en las interfaces extcap si PySerial
no está instalado para el Python de Xcode. Para solucionar esto, puedes editar la línea shebang de
sniffle_extcap.py para que apunte directamente al Python con PySerial instalado, por ejemplo el
Python de Homebrew en /opt/homebrew/bin/python3, en lugar de /usr/bin/env python3.
En Windows, puedes copiar los siguientes archivos y directorios desde el directorio python_cli a
tu carpeta Personal Extcap:```
sniffle/
sniffle_extcap.py
sniffle_extcap.bat
En Windows, puede ser necesario editar `sniffle_extcap.bat` para especificar la ubicación del intérprete de Python si el directorio de instalación no está incluido en el PATH, p. ej.:```
@echo off
C:\my_python_install\python.exe "%~dp0sniffle_extcap.py" %*
Una vez que se haya instalado el plugin, reinicie Wireshark o elija Captura > Actualizar interfaces para habilitar la interfaz Sniffle.
Mientras que el firmware original de Sniffle de 2019 era puramente un oyente pasivo, las versiones posteriores del firmware añadieron varias funciones para transmitir activamente paquetes de diversas maneras. El firmware actual de Sniffle admite actuar tanto como dispositivo central como periférico GAP, incluyendo escaneo activo, publicidad heredada y extendida, iniciación de conexiones, y estar conectado en un rol central o periférico. El script scanner.py realiza escaneo activo. El script initiator.py inicia una conexión a un periférico y luego actúa como un central conectado. El script advertiser.py realiza publicidad heredada y acepta solicitudes de conexión de otros dispositivos, transitando a un rol periférico conectado.
La funcionalidad de transmisión de Sniffle es un poco diferente de un controlador Bluetooth tradicional basado en HCI, porque te da un control de muy bajo nivel sobre las PDU exactas que se envían en la capa de enlace. Este control de bajo nivel permite que el código del lado del host implemente funcionalidades adicionales, como pruebas de fuzzing de la capa de enlace o ataques de retransmisión de la capa de enlace.
Aún no he tomado el tiempo para documentar formalmente la API del firmware de Sniffle, aunque es bastante autoexplicativa al observar su implementación del lado del host en sniffle_hw.py. El escaneo activo (que transmite solicitudes de escaneo) se activa mediante cmd_scan. La iniciación de conexión se desencadena con cmd_connect, aunque es más fácil usar el envoltorio initiate_conn. La publicidad (opcionalmente conectable) se activa mediante cmd_advertise para publicidad heredada, o cmd_advertise_ext para publicidad extendida.
Dado que la corrección del problema TI EXT_EP-11735 a mediados de 2024, el depurador XDS110 (incluido en las placas Launchpad de TI) maneja altas velocidades de transmisión como 2M (usado por Sniffle) de manera razonable sin latencia excesiva. Sin embargo, el firmware más reciente del XDS110 todavía utiliza operación UART basada en DMA con búfer a tales velocidades de transmisión, y como tal aún puede introducir latencia de hasta 30 ms. Esta latencia es insignificante para su uso como sniffer, pero puede ser perjudicial para operaciones más activas, como el código del lado del host que actúa como cliente o servidor GATT, o realizando ataques de retransmisión. La modificación del firmware XDS110 versión 3.0.0.28 descrita a continuación para operación basada en interrupciones aún puede reducir en gran medida la latencia para tales operaciones sensibles al tiempo. Debería ser posible hacer una modificación similar al firmware más reciente del XDS110, pero no he tomado el tiempo para hacer ingeniería inversa y encontrar los bits correctos que cambiar.
A mediados de 2024 y antes, el firmware del depurador TI XDS110 (incluido en las placas Launchpad) tenía un comportamiento indeseable en su puente USB a UART, donde a altas velocidades de transmisión, puede haber una latencia severa, especialmente con escrituras pequeñas frecuentes como las realizadas por el firmware de Sniffle. Este problema estuvo presente durante años, y aún estaba presente en abril de 2024 con el firmware XDS110 3.0.0.28 incluido con UniFlash 8.6.0. La causa raíz era que en la operación basada en DMA, el firmware del XDS110 acumulaba datos UART en un búfer cuyo tamaño era proporcional a la velocidad de transmisión, y esperaba a que este búfer se llenara antes de transferir los datos. Había lógica para vaciar este búfer si no llegaban nuevos datos en los últimos 15 milisegundos, pero esta lógica de vaciado nunca se activaba cuando Sniffle agregaba frecuentemente paquetes pequeños de eventos de conexión cada pocos milisegundos. Como resultado de este comportamiento subóptimo, los datos olfateados podían aparecer en ráfagas retrasadas en el host.
El firmware del XDS110 también tiene un modo alternativo para la operación UART, donde cada recepción UART desencadena una interrupción que resulta en que los datos se pasen inmediatamente al host. Este modo de operación basado en interrupciones tiene una latencia mucho menor. Sin embargo, el firmware solo lo usa para velocidades de transmisión por debajo de 230400. Como solución alternativa a la alta latencia del modo DMA con fragmentos de datos pequeños frecuentes, puede modificar el firmware para usar el puente USB-UART basado en interrupciones incluso a altas velocidades de transmisión (como 2M baudios usado por Sniffle). En el firmware 3.0.0.28 (incluido con Uniflash 8.6.0), puede editar en hexadecimal los bytes en el desplazamiento 0x0A14 de 61 3F a 00 1F. Esto cambiará la velocidad de transmisión para cambiar a operación UART basada en DMA de 230400 a 0x200000 (2097152).
Tenga en cuenta que los desplazamientos y las modificaciones de bytes descritos anteriormente son solo para el firmware 3.0.0.28, y serán diferentes para diferentes versiones del firmware. Flashear firmware no válido en su depurador puede dañarlo, y no asumimos ninguna responsabilidad por cualquier daño que pueda ocurrir.
Los siguientes comandos se pueden usar en Linux para modificar el firmware del XDS110 para UART de baja latencia a altas velocidades de transmisión:``` 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
Antes de flashear, verifique que la suma SHA256 del firmware modificado sea `c226f2e9cb2b9f0bc111ca11f2903d58d4065293468623428c0e8eeb22086dcf`. Después de verificar esto, ejecute los siguientes comandos para flashear el firmware del depurador XDS110 modificado:```
./xdsdfu -m
./xdsdfu -f firmware_3.0.0.28_fastuart.bin -r
Sniffle puede usarse para realizar retransmisión a nivel de capa de enlace del tráfico Bluetooth LE. Al realizar la retransmisión, un dispositivo Sniffle actúa como central BLE (usando relay_master.py) y un segundo dispositivo Sniffle actúa como periférico BLE (usando relay_slave.py). Maestro y esclavo son términos históricos para central y periférico BLE respectivamente. El maestro de retransmisión captura los datos de publicidad y respuesta a escaneo del periférico genuino, y luego los pasa al esclavo de retransmisión. El esclavo de retransmisión transmite anuncios y respuestas a escaneo imitando al periférico genuino y acepta conexiones. Al aceptar una conexión, el esclavo de retransmisión notifica al maestro de retransmisión, que entonces inicia una conexión con el periférico genuino. A partir de este punto, todos los paquetes de la capa de enlace se reenvían entre el maestro y el esclavo de retransmisión.
El script maestro de retransmisión proporciona funcionalidad para solicitar intervalos de conexión más rápidos en uno o en ambos lados de la retransmisión para reducir la latencia. Si se utiliza el XDS110 como puente USB/UART, tenga en cuenta que el firmware del XDS110 introduce latencia adicional a la retransmisión a menos que lo modifique como se describió anteriormente.
Tenga en cuenta que el script maestro de retransmisión crea un listener de red que se vincula a todas las interfaces (0.0.0.0), y el protocolo de red utilizado para comunicarse entre los dispositivos de retransmisión no proporciona seguridad. Utilice estos scripts únicamente en entornos de red de confianza.
El uso de los scripts maestro (central) y esclavo (periférico) de retransmisión se muestra a continuación. Actualmente, la publicidad extendida no es compatible con los scripts de retransmisión.``` 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
## <a id="usage"></a>⚙️ Uso```
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