ymsniper/whisper_bullyExtração de BDADDR Bluetooth em três etapas, DoS e sequestro em dispositivos Fast Pair; primitivas não corrigidas fora do escopo do CVE-2025-36911 (sem necessidade de Ubertooth)
Ferramenta de Pesquisa para Extração de BDADDR Bluetooth, Negação de Serviço e Sequestro
© 2026 @Ymsniper — Apenas para pesquisa de segurança autorizada.
Whisper Bully é uma ferramenta de pesquisa de segurança Bluetooth de três estágios que tem como alvo dispositivos que anunciam o Google Fast Pair (UUID de serviço fe2c). Ela demonstra duas primitivas de ataque sem patch que estão fora do escopo do patch de firmware CVE-2025-36911:
⚠️ Esta ferramenta NÃO implementa o protocolo Whisper Pair (Fast Pair GATT). Ela nunca escreve na característica de Pareamento Baseado em Chave (UUID 1236) ou na característica de Chave de Conta (UUID 1238). A superfície de ataque descrita aqui é separada e não é abordada pelo patch de verificação de modo de pareamento CVE-2025-36911.
https://github.com/user-attachments/assets/67f2bcb6-38ad-4ba0-80c5-36dbb54f3f11
Causa raiz: Quando uma conexão BLE é estabelecida, a pilha host Linux BlueZ processa o evento LL_CONNECTION_COMPLETE e resolve o Endereço Privado Resolvível (RPA) do dispositivo para seu Endereço de Identidade permanente, armazenando-o em cache na tabela de dispositivos BlueZ. Isso ocorre no nível da Camada de Enlace / HCI, antes de qualquer interação com o serviço GATT. Nenhum protocolo Fast Pair está envolvido.
O que o código realmente faz:
BleakScanner) em busca de dispositivos que anunciam o UUID de serviço Fast Pair fe2c — usado apenas para identificação do alvo, sem interação com o protocoloBleakClient.connect() — sem escritas GATT de qualquer tipoNoInputNoOutput em preparação para o Passo 4wb.py)bluetoothctl pair <rpa_addr> — tentativa de pareamento SMP Bluetooth padrão, não Fast Pairbluetoothctl em busca de saída Bonded: yes, que pode conter o endereço vinculadobluetoothctl devices e compara com o RPA inicial — qualquer entrada com o mesmo nome de dispositivo, mas endereço diferente, é o Endereço de Identidade permanente, vazado pelo BlueZ no passo 2Por que o patch não corrige isso:
A correção do firmware CVE-2025-36911 adiciona uma verificação de modo de pareamento ao manipulador da característica de Pareamento Baseado em Chave GATT Fast Pair no acessório. Esta ferramenta nunca escreve nessa característica. O vazamento do endereço de identidade ocorre no host Linux do atacante por meio do cache de dispositivos do próprio BlueZ — totalmente fora do firmware do acessório.
Notas importantes sobre o comportamento:
bluetoothctl pair falhar ou expirarNoInputNoOutput significa que não há interação do usuário em nenhum dos lados para Just WorksUma vez conhecido o endereço permanente, opcionalmente execute uma inundação L2CAP sustentada de negação de serviço usando uma versão modificada de l2flood.
Dois modos são usados na ferramenta:
Flag -R — Modo EMP (inundação do Estágio 2)
Dispara e esquece silencioso com reconexão em rajada. Todas as threads sincronizam seus ciclos de conectar → rajada → fechamento forçado para que o alvo receba desmontagens completas periódicas de ACL em vez de embaralhamento escalonado de canais L2CAP que ele pode absorver. Usa SO_LINGER {1,0} para desmontagem RST imediata em cada fechamento. Não produz saída stdout durante operação normal — erros de conexão são suprimidos para stderr e exibidos apenas periodicamente.
Modo normal (sonda de sequestro do Estágio 3)
Usado sem -R para sondar se o alvo ainda está respondendo. Este modo também foi melhorado — agora lida automaticamente com reconexões e gera no response from <addr>: id N quando o alvo para de responder, que é o que wb.py monitora para acionar o sequestro.
Resultado: O dispositivo alvo fica não responsivo a tentativas normais de conexão enquanto a inundação está ativa. O dispositivo se recupera totalmente quando o ataque para — sem danos permanentes.
Comportamento com múltiplas threads:
Causa raiz: A inundação L2CAP sustentada faz com que a pilha Bluetooth do dispositivo alvo falhe ou reinicie. Durante a janela de recuperação — antes que o serviço GATT Fast Pair seja re-registrado e antes que o Gerenciador de Segurança seja totalmente reinicializado — o dispositivo aceita um vínculo SMP Just Works padrão de NoInputNoOutput sem exigir o handshake Fast Pair GATT que normalmente bloquearia o vínculo. O vínculo resultante é persistente: sobrevive a reinicializações do adaptador BT e mostra Paired: yes / Bonded: yes em bluetoothctl info.
Por que esta é uma descoberta separada do CVE-2025-36911:
O patch CVE-2025-36911 impõe uma verificação de modo de pareamento no manipulador da característica de Pareamento Baseado em Chave GATT FP. O Estágio 3 nunca toca nessa característica. O vínculo é estabelecido na camada SMP durante uma janela onde o servidor GATT FP não foi reinicializado, então a porta de segurança Fast Pair nunca é sequer alcançada. Um dispositivo totalmente corrigido permanece vulnerável a isso porque o patch não tem visibilidade da camada SMP durante a recuperação da pilha.
O que o código realmente faz:
l2flood -c -1 -t 2) para confirmar que o dispositivo está não responsivo — procura por no response from <addr>: id N na saídabluetoothctl connect <permanent_addr> em um loop de repetiçãoNoInputNoOutput / NoInputNoOutput → modelo de associação Just Works → vínculo completobluetoothctl connect retorna código de saída 0 em caso de sucessoProbabilidade de sucesso por estado do dispositivo:
| Estado do Dispositivo | Resultado Esperado |
|---|---|
| Ativamente inundado / não responsivo | Maior sucesso — pilha em estado degradado durante recuperação |
| Recuperando-se da inundação | Alto sucesso — janela temporária de reinicialização do SM |
| Totalmente recuperado | Menor sucesso — segurança normal restaurada |
| Desligado | Falha |