nccgroup/sniffleSniffer Bluetooth 5 e 4.x LE para hardware TI CC1352/CC26x2 com suporte para advertising estendido, todos os modos PHY, filtragem MAC/RSSI e exportação PCAP compatível com Wireshark.
O Sniffle é um sniffer para Bluetooth 5 e 4.x (LE) usando hardware TI CC1352/CC26x2.
O Sniffle tem uma série de recursos úteis, incluindo:
Se você não quiser passar pelo trabalho de configurar um ambiente de compilação para o firmware, você pode simplesmente gravar os binários de firmware pré-compilados usando UniFlash/DSLite. Os binários de firmware pré-compilados estão anexados aos lançamentos na aba de releases do GitHub deste projeto. Ao usar firmware pré-compilado, certifique-se de usar o código Python correspondente à tag de release, em vez do master, para evitar problemas de compatibilidade com firmware que está atrás do branch master.
O arm-none-eabi-gcc fornecido pelos gerenciadores de pacotes de várias distribuições Linux frequentemente não possui alguns arquivos de cabeçalho ou exige algumas alterações na configuração do linker. Para menos complicação, sugiro usar o ARM GCC linkado acima. Você pode simplesmente baixar e extrair os executáveis pré-compilados.
O SDK da TI é fornecido como um binário executável que extrai uma porção de código-fonte assim que você aceita o contrato de licença. No Linux e no Mac, o diretório de instalação padrão fica em ~/ti/. Isso funciona bem e meus makefiles esperam esse caminho, então sugiro apenas manter o padrão aqui. O mesmo se aplica à ferramenta TI SysConfig.
Depois que o SDK for extraído, você precisará editar um makefile para adequá-lo ao seu ambiente de compilação. Dentro de ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 (ou onde quer que o SDK tenha sido instalado) há um makefile chamado imports.mak. Os únicos caminhos que precisam ser definidos aqui para compilar o Sniffle são para GCC, XDC, cmake e SysConfig. Não precisamos do compilador CCS. Veja o diff abaixo como exemplo e adapte para onde você instalou as coisas.```
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 da versão 8.30.01.01 do SDK, para compilar com versões recentes do GCC (e do binutils),
é necessária uma pequena modificação no SDK para evitar erros de vinculação
"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
Após fazer esta modificação, você precisará recompilar o SDK.``` cd ~/ti/simplelink_cc13xx_cc26xx_sdk_8_30_01_01 make build-gcc -j5
### Obtendo o DSLite
O DSLite é a ferramenta de servidor de programação e depuração por linha de comando da TI para
depuradores XDS110. As placas Launchpad CC26xx e CC13xx incluem depuradores XDS110.
Infelizmente, a TI não fornece um download autônomo do DSLite para linha de comando.
A maneira mais fácil de obter o DSLite é instalar o [UniFlash](http://www.ti.com/tool/download/UNIFLASH)
da TI. Ele está disponível para Linux, Mac e Windows. O executável do DSLite estará
localizado em `deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite`
em relação ao diretório de instalação do UniFlash. No Linux, o diretório de instalação
padrão do UniFlash fica em `~/ti/`.
Você deve colocar o diretório do executável do DSLite no seu `$PATH`.
## Compilação do Firmware
Assim que o GCC, o DSLite e o SDK estiverem instalados e operacionais, compilar
o Sniffle deve ser simples. Basta navegar até o diretório `fw` e
executar `make`. Se você não instalou o SDK no diretório padrão, talvez seja necessário
editar `SIMPLELINK_SDK_INSTALL_DIR` no makefile.
Se estiver compilando para ou instalando em alguma variante de Launchpad diferente da CC26x2R,
você deve especificar `PLATFORM=xxx`, seja como argumento para o make, ou definindo-o
como uma variável de ambiente antes de invocar o make. Os valores suportados para `PLATFORM`
podem ser encontrados no makefile do firmware. Certifique-se de executar um `make clean` antes de
compilar para uma plataforma diferente.
## Instalação do Firmware (Placa Launchpad da TI)
Para instalar o Sniffle em um Launchpad CC26x2R (conectado) usando o DSLite, execute
`make load` dentro do diretório `fw`. Para quaisquer outros modelos de Launchpad, você deve
especificar o argumento `PLATFORM` para o make conforme descrito acima. Você também pode gravar
o binário `sniffle.hex` compilado usando a interface gráfica do UniFlash.
## Instalação do Firmware (Dongle USB SONOFF)
Para instalar o Sniffle em um dongle SONOFF CC2652P (equipado com uma ponte USB/UART
CP2102N), use o utilitário [JelmerT/cc2538-bsl](https://github.com/JelmerT/cc2538-bsl)
para gravar o firmware usando o bootloader de ROM integrado com o seguinte comando:```
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv sniffle_cc1352p1_cc2652p1.hex
As of January 10, 2025, there is a bug in cc2538-bsl that prevents it from
resetting the CC2562P chip in the Sonoff dongle after flashing. The fix for this
is in pull request 173, which
has yet to be merged. In the interim, while waiting for the pull request to be
merged, you can use my fork at https://github.com/sultanqasim/cc2538-bsl.
In 2022, due to COVID-19 pandemic chip shortages, some Sonoff CC2652P dongles were
built with CP2102 (non-N) USB/UART bridge chips that are capped at 921600 baud. If
you have one of these, you will need to flash a different firmware image that uses
a slower baud rate of 921600. This special slower baud rate build is named
sniffle_cc1352p1_cc2652p1_1M.hex (build variant CC2652P1F_1M). You will also
need to invoke Sniffle utilities with the option -b 921600 to override the
default baud rate of 2000000.
WARNING: Do not flash the wrong build variant using the bootloader, or you
risk bricking the device and locking yourself out of the bootloader. For Sonoff
CC2652P devices, use the sniffle_cc1352p1_cc2652p1.hex file (CC2652P1F build
variant) or the sniffle_cc1352p1_cc2652p1_1M.hex file (CC2652P1F_1M` build
variant) for a 921600 baud rate. If you flash the wrong variant and lock yourself
out of the bootloader, it may be possible to recover the device using JTAG/SWD.
A Electronic Cats fornece uma ferramenta Catnip Uploader para carregar firmware. Para informações detalhadas, consulte o repositório. Baixe a ferramenta e siga estes 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
Você precisa alterar o *COMPORT* para o caminho apropriado da sua placa.
Usando o comando `python3 catnip_uploader.py load 2 COMPORT`, você carregará
o firmware `2: nccgroup_v1.10.0_sniffle_cc1352p7_1M.hex`.
**Para carregar o firmware, o Catsniffer V3 requer SerialPassthroughwithboot**.
**AVISO:** Não grave a variante de build errada usando o bootloader, ou você
corre o risco de brickar o dispositivo e ficar bloqueado para fora do bootloader. Se você
usar o script `catnip_uploader.py` para buscar e instalar o firmware, ele
apresentará apenas firmware compatível. No entanto, se você optar por compilar e instalar
o firmware manualmente, certifique-se de usar a variante de build correta. Para dispositivos CatSniffer
v3, use o arquivo `sniffle_cc1352p7_1M.hex` (variante de build `CC1352P74_1M`).
Os dispositivos CatSniffer v1.x/v2.x usam uma variante de chip diferente (CC1352P1) que precisa de um
build de firmware diferente (variante `CC1352P1F3_1M`, imagem `sniffle_cc1352p1_cc2652p1_1M.hex`).
O Sniffle não foi testado em dispositivos CatSniffer v1.x/v2.x, mas eles
provavelmente funcionarão desde que você grave a variante de build apropriada. Se você gravar a
variante errada e ficar bloqueado para fora do bootloader, pode ser possível recuperar
o dispositivo usando JTAG/SWD.
## Uso do 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
O debugger XDS110 nas placas Launchpad cria duas portas seriais. No
Linux, elas são normalmente nomeadas ttyACM0 e ttyACM1. A primeira das
duas portas seriais criadas é usada para comunicar com o Sniffle. Por padrão,
a CLI Python comunica usando o primeiro dispositivo CDC-ACM que encontra
correspondendo à combinação VID:PID USB do TI XDS110, ou o primeiro dongle Sonoff que encontrar. Pode
ser necessário substituir isso com a opção de linha de comando -s se estiver a usar
um adaptador de série USB diferente ou tiver dispositivos USB CDC-ACM adicionais ligados.
Para a opção -r (filtro de RSSI), um valor de -40 tende a funcionar bem se o
sniffer estiver muito próximo ou quase a tocar no dispositivo transmissor. O filtro
de RSSI é muito útil para ignorar anúncios irrelevantes num ambiente de RF
movimentado. O filtro de RSSI só está ativo ao capturar anúncios,
pois quer sempre capturar tráfego de canais de dados para uma ligação a ser
seguida. Provavelmente não quer usar um filtro de RSSI quando a filtragem por MAC
estiver ativa, pois pode perder anúncios do endereço MAC de interesse
quando o RSSI for demasiado baixo.
Para saltar junto com os anúncios e ter uma captura de ligação fiável, é
necessário configurar um filtro MAC com a opção -m. Deve especificar o
endereço MAC do dispositivo periférico, não o do dispositivo central. Para descobrir
qual endereço MAC deve capturar, pode executar o sniffer com filtragem por RSSI enquanto
coloca o sniffer perto do alvo. Isto mostrar-lhe-á os anúncios do
dispositivo alvo, incluindo o seu endereço MAC. Deve notar-se que muitos dispositivos BLE
anunciam com um endereço MAC aleatório em vez do seu MAC fixo "real"
impresso numa etiqueta.
A maioria dos novos dispositivos BLE usa Endereços Privados Resolvíveis (RPAs) em vez de endereços fixos
estáticos ou públicos. Embora possa configurar um filtro MAC para um RPA
específico, os dispositivos mudam periodicamente o seu RPA. Os RPAs podem ser resolvidos (associados
a um dispositivo específico) se a Chave de Resolução de Identidade (IRK) for conhecida. O Sniffle
suporta resolução automática de RPA quando a IRK é fornecida. Isto evita a necessidade
de continuar a atualizar o filtro MAC sempre que o RPA muda. Pode especificar uma
IRK para o Sniffle com a opção -i; a IRK deve ser fornecida em formato
hexadecimal, com o byte mais significativo (MSB) primeiro. Especificar uma IRK permite
ao Sniffle saltar canais com um anunciante da mesma forma que faz com um filtro MAC.
A funcionalidade de filtragem MAC baseada em IRK (-i) é mutuamente exclusiva com a
funcionalidade de filtragem MAC estática (-m).
Existe também uma funcionalidade de conveniência para identificar automaticamente o endereço MAC
do anunciante cujo anúncio ou resposta de scan contém uma string (série de bytes) especificada.
Isto é útil para dispositivos com RPAs onde a IRK é desconhecida, mas o anúncio contém uma string estática suficientemente única adequada
para identificação. Esta funcionalidade usa a opção -S, com a string especificada
usando sequências de escape padrão. Por exemplo, para procurar um anunciante cujo
anúncio contém a sequência de bytes hexadecimais DE AD BE EF, especifique
-S "\xDE\xAD\xBE\xEF". Para procurar um anunciante com a string "hello",
simplesmente especifique -S "hello". Quando a funcionalidade de pesquisa de string é usada, inicialmente
todos os endereços MAC serão aceites até que um anúncio contendo a string de pesquisa
seja encontrado. Depois disso, um filtro MAC será configurado com o
endereço MAC do anunciante correspondente, e qualquer filtro de RSSI seria automaticamente desativado.
Para ativar o seguimento de ponteiros auxiliares em publicidade estendida Bluetooth 5,
ative a opção -e. Para melhorar o desempenho e a fiabilidade na captura de publicidade
estendida, esta opção desativa o salto nos canais de publicidade primários,
mesmo quando um filtro MAC está configurado. Se não tiver a certeza se uma
ligação será estabelecida via publicidade legada ou estendida, pode
ativar a flag -H em conjunto com -e para realizar saltos nos canais primários
com anúncios legados, e escuta agendada de pacotes auxiliares de publicidade
estendida. Ao combinar -e e -H, a
fiabilidade da deteção de ligação pode ser reduzida em comparação com o salto em
canais de publicidade primários (legados) ou secundários (estendidos) apenas.
Para capturar o PHY de longo alcance nos canais de publicidade primários, especifique a opção
-l. Note que não é suportado salto entre canais de publicidade primários
no modo de longo alcance, pois toda a publicidade de longo alcance usa o mecanismo estendido
BT5. Sob o mecanismo estendido, os ponteiros auxiliares em todos os três
canais primários apontam para o mesmo pacote auxiliar, portanto o salto entre
canais primários é desnecessário.
Para não imprimir pacotes de dados vazios no ecrã ao seguir uma ligação, use
a flag -q. Isto torna mais fácil observar comunicações significativas em
tempo real, mas pode obscurecer quando o seguimento da ligação está instável ou perdido.
Para ligações encriptadas, o Sniffle suporta detetar atualizações de parâmetros de
ligação mesmo quando a chave de encriptação é desconhecida, e tenta medir
os novos parâmetros. No entanto, se souber o novo intervalo de ligação e o delta
de Instant esperados em atualizações de parâmetros de ligação encriptadas, pode especificá-los
com a opção --preload/-Q para melhorar o desempenho/fiabilidade.
O par esperado Intervalo:DeltaInstant deve ser fornecido como inteiros separados por
dois pontos. Intervalo é um inteiro que representa múltiplos de 1,25 ms (conforme definido
em LL_CONNECTION_UPDATE_IND). DeltaInstant é o número de eventos de ligação
entre quando o pacote de atualização de ligação é transmitido e quando os novos
parâmetros são aplicados. DeltaInstant deve ser maior ou igual a 6, conforme
os requisitos da especificação Bluetooth para dispositivos centrais. Se forem esperadas múltiplas
atualizações de parâmetros encriptadas, pode fornecer múltiplos pares de parâmetros,
separados por vírgulas (ex. 6:7,39:8). Se tiver um dispositivo que emite
PDUs de atualização de PHY encriptadas que não alteram o PHY, ou emite PDUs de controlo
de potência LE encriptadas sem quaisquer alterações de PHY, pode usar a opção --nophychange/-n.
Para parar o sniffer, pressione Ctrl-C.
Se por algum motivo o firmware do sniffer bloquear e se recusar a capturar qualquer tráfego mesmo com os filtros desativados, deve reiniciar o MCU do sniffer. Nas placas Launchpad, o botão de reinício está localizado ao lado da 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
Os argumentos de linha de comando do scanner funcionam da mesma forma que os do sniffer. O objetivo do utilitário scanner é reunir uma lista de dispositivos próximos que estão fazendo advertising e emitir ativamente solicitações de scan para os dispositivos observados, sem o dilúvio de dados de rolagem rápida que você obtém com o utilitário sniffer. O hardware/firmware entrará em um modo de escaneamento ativo no qual relatará os advertisements recebidos, emitirá solicitações de scan para aqueles que são scannable e relatará as respostas de scan recebidas. O utilitário scanner registrará e reportará endereços MAC observados apenas uma vez, sem inundar a tela. Quando terminar de capturar advertisements, pressione Ctrl-C para interromper o escaneamento e reportar os resultados. O scanner mostrará a última advertisement e a resposta de scan de cada alvo. Os resultados do scan serão ordenados por RSSI em ordem decrescente.
## Exemplos de Uso
Sniffe todos os advertisements no canal 38, ignore RSSI < -50, permaneça no canal de advertising mesmo quando CONNECT\_REQs forem vistos.```
./sniff_receiver.py -c 38 -r -50 -a
Sniffar anúncios do MAC 12:34:56:78:9A:BC, permanecer no canal de publicidade mesmo quando CONNECT_REQs forem vistos, salvar anúncios em data1.pcap.```
./sniff_receiver.py -m 12:34:56:78:9A:BC -a -o data1.pcap
Capture anúncios e conexões para o primeiro endereço MAC visto com
RSSI >= -40. O filtro de RSSI será desativado automaticamente assim que um endereço MAC
for fixado. Salve os dados capturados em `data2.pcap`.```
./sniff_receiver.py -m top -r -40 -o data2.pcap
Sniffe anúncios e conexões do periférico com IRK big endian 4E0BEA5355866BE38EF0AC2E3F0EBC22. Pré-carregue duas atualizações de parâmetros de conexão criptografadas esperadas; a primeira com um Interval de 6, ocorrendo em um instante de 6 eventos de conexão após um LL_CONNECTION_UPDATE_IND criptografado ser observado pelo sniffer. A segunda atualização de conexão criptografada esperada tem um Interval de 39, e DeltaInstant de 6 também.``` ./sniff_receiver.py -i 4E0BEA5355866BE38EF0AC2E3F0EBC22 -Q 6:6,39:6
Sniffar anúncios estendidos BT5 e conexões de dispositivos próximos (RSSI >= -55).```
./sniff_receiver.py -r -55 -e
Capture anúncios legados e estendidos e conexões do dispositivo com o endereço MAC especificado. Salve os dados capturados em data3.pcap.```
./sniff_receiver.py -eH -m 12:34:56:78:9A:BC -o data3.pcap
Farejar anúncios estendidos e conexões usando o PHY primário de longo alcance no
canal 38.```
./sniff_receiver.py -le -c 38
Escaneie ativamente no canal 39 por anúncios com RSSI maior que -50.``` ./scanner.py -c 39 -r -50
## Obtendo o IRK
Se você tiver um telefone Android com root, você pode encontrar IRKs (e LTKs) no arquivo de configuração do Bluedroid. No Android 8.1, ele está localizado em `/data/misc/bluedroid/bt_config.conf`. O `LE_LOCAL_KEY_IRK` especifica o IRK do próprio dispositivo Android, e os primeiros 16 bytes de `LE_KEY_PID` para cada dispositivo vinculado no arquivo indicam o IRK do dispositivo vinculado. Esteja ciente de que as chaves armazenadas neste arquivo são little endian, portanto **a ordem dos bytes das chaves neste arquivo precisará ser invertida.** Por exemplo, o IRK little endian 22BC0E3F2EACF08EE36B865553EA0B4E precisa ser alterado para 4E0BEA5355866BE38EF0AC2E3F0EBC22 (big endian) ao ser passado para o Sniffle com a opção `-i`.
Você também pode encontrar o IRK e o LTK por meio de logs HCI Snoop capturados no Android ou no iOS sem fazer root no 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 do Wireshark
O Sniffle inclui um plugin do Wireshark que possibilita iniciar o Sniffle automaticamente a partir da interface gráfica do Wireshark selecionando a interface de captura 'Sniffle'.
Para instalar o plugin do Sniffle, primeiro encontre a localização da sua pasta Personal Extcap no diálogo 'Sobre o Wireshark' (*Ajuda* > *Sobre o Wireshark* > *Pastas* > *Caminho da Extcap pessoal*). Em sistemas POSIX (Linux e Mac OS) executando versões recentes do Wireshark (4.2.0+), esta pasta está localizada em `~/.local/lib/wireshark/extcap`. No Windows, ela pode ser encontrada em `%USERPROFILE%\AppData\Roaming\Wireshark\extcap`.
Em sistemas POSIX, você pode simplesmente criar um symlink do plugin extcap do Sniffle para o diretório pessoal de extcap do Wireshark:```
mkdir -p ~/.local/lib/wireshark/extcap
ln -s $(pwd)/python_cli/sniffle_extcap.py ~/.local/lib/wireshark/extcap
No Mac OS, o Wireshark pode tentar usar o Python do Xcode em vez do Python no seu PATH especificado
pelo seu perfil de shell. Assim, o plugin Sniffle pode não aparecer nas interfaces extcap se o PySerial
não estiver instalado para o Python do Xcode. Para corrigir isso, você pode editar a linha shebang de
sniffle_extcap.py para apontar diretamente para o Python com PySerial instalado, por exemplo, o
Homebrew Python em /opt/homebrew/bin/python3, em vez de /usr/bin/env python3.
No Windows, você pode copiar os seguintes arquivos e diretórios do diretório python_cli para a
sua pasta Personal Extcap:```
sniffle/
sniffle_extcap.py
sniffle_extcap.bat
No Windows, pode ser necessário editar `sniffle_extcap.bat` para especificar a localização do interpretador Python se o diretório de instalação não estiver incluído no PATH, por exemplo:```
@echo off
C:\my_python_install\python.exe "%~dp0sniffle_extcap.py" %*
Depois que o plugin for instalado, reinicie o Wireshark ou escolha Captura > Atualizar Interfaces para habilitar a interface Sniffle.
Embora o firmware Sniffle original de 2019 fosse puramente um ouvinte passivo, versões posteriores do firmware adicionaram vários recursos para transmitir pacotes ativamente de várias formas. O firmware Sniffle atual suporta atuar tanto como dispositivo central GAP quanto periférico, incluindo varredura ativa, publicidade legada e estendida, iniciar conexões e estar conectado em um papel central ou periférico. O script scanner.py realiza varredura ativa. O script initiator.py inicia uma conexão com um periférico e então atua como um central conectado. O script advertiser.py realiza publicidade legada e aceita solicitações de conexão de outros dispositivos, transitando para um papel periférico conectado.
A funcionalidade de transmissão do Sniffle é um pouco diferente de um controlador Bluetooth tradicional baseado em HCI, porque oferece controle de nível muito baixo sobre os PDUs exatos enviados na camada de enlace. Esse controle de baixo nível permite que o código do lado do host implemente funcionalidades adicionais, como testes de fuzz da camada de enlace ou ataques de relay na camada de enlace.
Ainda não reservei um tempo para documentar formalmente a API do firmware do Sniffle, embora seja bastante autoexplicativa ao observar sua implementação no lado do host em sniffle_hw.py. A varredura ativa (que transmite solicitações de varredura) é ativada por cmd_scan. O início de conexão é acionado por cmd_connect, embora seja mais fácil usar o wrapper initiate_conn. A publicidade (opcionalmente conectável) é ativada por cmd_advertise para publicidade legada, ou cmd_advertise_ext para publicidade estendida.
Desde a correção do problema EXT_EP-11735 da TI em meados de 2024, o depurador XDS110 (incluído nas placas TI Launchpad) lida com altas taxas de transmissão, como 2M (usado pelo Sniffle), de maneira razoável, sem latência excessiva. No entanto, o firmware mais recente do XDS110 ainda usa operação de UART orientada a DMA com buffer em tais taxas de transmissão e, portanto, ainda pode introduzir latência de até 30 ms. Essa latência é irrelevante para uso como sniffer, mas pode ser prejudicial para operações mais ativas, como código do lado do host atuando como cliente ou servidor GATT, ou realizando ataques de relay. A modificação do firmware XDS110 versão 3.0.0.28 descrita abaixo para operação baseada em interrupção ainda pode reduzir bastante a latência para tais operações sensíveis ao tempo. Deve ser possível fazer uma modificação semelhante no firmware mais recente do XDS110, mas não reservei um tempo para fazer engenharia reversa e encontrar os bits certos para alterar.
Em meados de 2024 e anteriormente, o firmware do depurador TI XDS110 (incluído nas placas Launchpad) tinha um comportamento indesejável em sua ponte USB para UART, onde, em altas taxas de transmissão, pode haver latência severa, especialmente com pequenas escritas frequentes, como as feitas pelo firmware do Sniffle. Esse problema esteve presente por anos e ainda estava presente em abril de 2024 com o firmware XDS110 3.0.0.28 incluído no UniFlash 8.6.0. A causa raiz era que, na operação baseada em DMA, o firmware do XDS110 acumulava dados UART em um buffer cujo tamanho era proporcional à taxa de transmissão e aguardava esse buffer encher antes de transferir os dados. Havia uma lógica para liberar esse buffer se nenhum dado novo chegasse nos últimos 15 milissegundos, mas essa lógica de liberação nunca era acionada quando o Sniffle adicionava frequentemente pequenos pacotes de eventos de conexão a cada poucos milissegundos. Como resultado desse comportamento subótimo, os dados capturados podiam aparecer em rajadas atrasadas no host.
O firmware do XDS110 também possui um modo alternativo para operação UART, em que cada recepção UART aciona uma interrupção que resulta na passagem imediata dos dados para o host. Esse modo de operação baseado em interrupção tem latência muito menor. No entanto, o firmware só o usa para taxas de transmissão abaixo de 230400. Como alternativa para a alta latência do modo DMA com pequenos blocos de dados frequentes, você pode modificar o firmware para usar a ponte USB-UART baseada em interrupção mesmo em altas taxas de transmissão (como 2M baud, usado pelo Sniffle). No firmware 3.0.0.28 (incluído com o Uniflash 8.6.0), você pode editar em hexadecimal os bytes no offset 0x0A14 de 61 3F para 00 1F. Isso alterará a taxa de transmissão para alternar para a operação UART baseada em DMA de 230400 para 0x200000 (2097152).
Esteja ciente de que os offsets e as modificações de bytes descritos acima são apenas para o firmware 3.0.0.28 e serão diferentes para outras versões de firmware. Gravar firmware inválido no seu depurador pode danificá-lo, e não assumimos responsabilidade por qualquer dano que possa ocorrer.
Os seguintes comandos podem ser usados no Linux para modificar o firmware do XDS110 para UART de baixa latência em altas taxas de transmissão:``` 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 gravar, verifique se o hash SHA256 do firmware modificado é
`c226f2e9cb2b9f0bc111ca11f2903d58d4065293468623428c0e8eeb22086dcf`. Após verificar isso,
execute os seguintes comandos para gravar o firmware modificado do depurador XDS110:```
./xdsdfu -m
./xdsdfu -f firmware_3.0.0.28_fastuart.bin -r
O Sniffle pode ser usado para realizar relay na camada de enlace
de tráfego Bluetooth LE. Ao realizar o relay, um dispositivo Sniffle atua como
central BLE (usando relay_master.py) e um segundo dispositivo Sniffle atua como
periférico BLE (usando relay_slave.py). Mestre e escravo são termos históricos para
central e periférico BLE, respectivamente. O mestre do relay captura dados de advertising e
scan response do periférico genuíno e os passa ao escravo do relay.
O escravo do relay transmite anúncios e scan responses imitando o periférico
genuíno e aceita conexões. Ao aceitar uma conexão, o escravo do relay
notifica o mestre do relay, que então inicia uma conexão com o periférico
genuíno. A partir desse ponto, todos os pacotes da camada de enlace são encaminhados
entre o mestre e o escravo do relay.
O script do mestre do relay oferece funcionalidade para solicitar intervalos de conexão mais rápidos em um ou em ambos os lados do relay para reduzir a latência. Se estiver usando o XDS110 como ponte USB/UART, esteja ciente de que o firmware do XDS110 adiciona latência extra ao relay, a menos que você o modifique conforme descrito acima.
Observe que o script do mestre do relay cria um listener de rede que se vincula a todas as interfaces (0.0.0.0), e o protocolo de rede usado para se comunicar entre os dispositivos de relay não oferece segurança. Use estes scripts somente em ambientes de rede confiáveis.
O uso dos scripts do mestre do relay (central) e do escravo do relay (periférico) é mostrado abaixo. Atualmente, o advertising estendido não é suportado pelos scripts de 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
No content provided for translation.```
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