Whisper Bully

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.

Visão Geral

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:

• Vazamento de BDADDR sem patch — endereço de identidade permanente divulgado por meio de conexão BLE simples, sem necessidade de interação GATT, funciona em dispositivos totalmente corrigidos
• Bypass de autenticação SMP via janela de reinicialização — vínculo persistente estabelecido através do SMP Just Works padrão durante a recuperação da pilha BT após inundação L2CAP, sem qualquer handshake Fast Pair GATT

⚠️ 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

Estágios do Ataque

Estágio 1 — Extração de BDADDR (Divulgação de Informação sem Patch)

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:

1. Realiza uma varredura BLE ativa (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 protocolo
2. Estabelece uma conexão BLE simples via BleakClient.connect() — sem escritas GATT de qualquer tipo
3. Define o agente BlueZ como NoInputNoOutput em preparação para o Passo 4
4. Verifica se o serviço GATT Fast Pair está presente no alvo — esta verificação é apenas consultiva; a ferramenta continua independentemente do resultado (linha 452 de wb.py)
5. Executa bluetoothctl pair <rpa_addr> — tentativa de pareamento SMP Bluetooth padrão, não Fast Pair
6. Monitora a saída padrão de bluetoothctl em busca de saída Bonded: yes, que pode conter o endereço vinculado
7. Fallback principal: Chama bluetoothctl 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 2

Por 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:

• A extração pode ser bem-sucedida mesmo se a etapa bluetoothctl pair falhar ou expirar
• A verificação de presença do serviço GATT FP no passo 4 não impede o ataque
• Nenhuma janela de confirmação PIN aparece — NoInputNoOutput significa que não há interação do usuário em nenhum dos lados para Just Works

Estágio 2 — Inundação L2CAP (Modo EMP-Recuperação de Conexão)

Uma 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:

• As threads sincronizam após cada ciclo de rajada para que a pressão atinja o alvo simultaneamente
• Eficaz até ~16 threads em hardware típico; retornos decrescentes além disso
• Múltiplos adaptadores HCI podem ser usados simultaneamente para aumentar a pressão

Estágio 3 — Sequestro via SMP Just Works Durante Janela de Reinicialização (Bypass de Autenticação sem Patch)

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:

1. Envia uma sonda L2CAP (l2flood -c -1 -t 2) para confirmar que o dispositivo está não responsivo — procura por no response from <addr>: id N na saída
2. Uma vez confirmado o estado não responsivo, executa bluetoothctl connect <permanent_addr> em um loop de repetição
3. O SMP negocia NoInputNoOutput / NoInputNoOutput → modelo de associação Just Works → vínculo completo
4. bluetoothctl connect retorna código de saída 0 em caso de sucesso
5. O vínculo persiste após o ataque parar

Probabilidade de sucesso por estado do dispositivo:

Relação com CVE-2025-36911

⚠️ Aviso Legal

Esta é uma ferramenta de pesquisa de negação de serviço e acesso não autorizado.

Usar esta ferramenta em dispositivos que você não possui ou sem autorização explícita por escrito é um crime federal punível com prisão e multas sob o Computer Fraud and Abuse Act (18 U.S.C. § 1030) e estatutos equivalentes em outras jurisdições.

Você pode somente usar esta ferramenta em:

• Dispositivos que você possui pessoalmente
• Dispositivos para os quais você tem autorização explícita por escrito do proprietário para realizar testes de segurança

Requisitos

• Linux (testado no Ubuntu 20.04+)
• Privilégios de root (necessários para bluetoothctl e acesso BLE bruto)
• bluetoothctl / BlueZ instalado e funcional
• Python 3.7+
• Para Estágio 2/3: l2flood com suporte OpenMP — veja kovmir/l2flood

Instalação

Dependências do sistema

Ubuntu / Debian:

sudo apt update
sudo apt install -y python3 python3-pip libdbus-1-dev libglib2.0-dev bluez

Fedora / RHEL / CentOS:

sudo dnf install -y python3 python3-pip dbus-devel glib2-devel bluez

Arch Linux:

sudo pacman -S python python-pip dbus glib bluez

Alpine Linux:

apk add --no-cache python3 py3-pip dbus-dev glib-dev bluez bluez-openrc

openSUSE:

sudo zypper install -y python3 python3-pip dbus-1-devel glib2-devel bluez

Void Linux:

sudo xbps-install -S python3 python3-pip dbus-devel glib-devel bluez

Clonar e instalar

git clone https://github.com/Ymsniper/Whisper_Bully.git
cd Whisper_Bully
pip3 install -r requirements.txt
# Necessário apenas para Estágio 2/3:
make
sudo make install

Uso

Estágio 1: Extração de BDADDR

# Detecta e extrai automaticamente todos os dispositivos Fast Pair próximos
sudo python3 wb.py

# Varredura de 20 segundos, salva resultados
sudo python3 wb.py -s 20 -o targets.json

# Varredura de 30 segundos, arquivo de saída personalizado
sudo python3 wb.py -s 30 -o extracted.json

Nota: Se um dispositivo foi previamente conectado ou pareado por esta ferramenta ou manualmente, o BlueZ já conhece seu endereço de identidade. Remova-o primeiro para que a extração seja executada de forma limpa:

root@kitploit:~

sudo bluetoothctl remove <address>

Estágio 2: Inundação L2CAP (Opcional)

Método 1 — Interativo (solicitado após extração)

sudo python3 wb.py -s 20 -o targets.json
# Ao término: "Run aggressive L2CAP test... (yes/no)" → yes

Método 2 — Flags (pular prompts)

# Apenas Estágio 1 + Estágio 2
sudo python3 wb.py -s 20 -o targets.json --aggressive

# Estágio 1 + Estágio 2 + Estágio 3
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack

# Com duração e número de threads
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 8

Método 3 — Script de inundação autônomo

# Inunda a partir do arquivo de alvos extraídos por 120 segundos
sudo python3 aggressive_test.py -f targets.json -d 120 -t 4

# Inunda um único endereço conhecido por 60 segundos
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -d 60

# Inunda para sempre (Ctrl+C para parar)
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -f

Estágio 3: Sequestro (Opcional)

# Integrado — extrai, inunda e sequestra
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120

# Sequestro autônomo manual em endereço conhecido
sudo python3 wb.py -H AA:BB:CC:DD:EE:FF

Execução Completa de Três Estágios (Um Comando)

sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 4

Fluxo de execução:

1. Varre por 20 segundos em busca de dispositivos Fast Pair
2. Extrai o BDADDR permanente de cada alvo
3. Inunda todos os alvos por 120 segundos usando 4 threads
4. Monitora o estado não responsivo
5. Tenta sequestro em cada alvo durante a janela de recuperação
6. Salva resultados em targets.json

Ataque com Múltiplos Adaptadores

# Terminal 1
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -i hci0 -d 120 -t 4 &

# Terminal 2
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -i hci1 -d 120 -t 4

Dobra a pressão DoS e aumenta a probabilidade de sucesso do sequestro durante a janela de recuperação.

Flags da Linha de Comando

Detalhes Técnicos

Estágio 1 — Por que a Extração Funciona Sem Interação GATT

O UUID de serviço Fast Pair FE2C é usado apenas como filtro de varredura para identificar alvos candidatos. Uma vez estabelecida uma conexão BLE:

• A Camada de Enlace completa o handshake de conexão e dispara LL_CONNECTION_COMPLETE para o host
• O BlueZ processa este evento e, se o dispositivo usar um Endereço Privado Resolvível, resolve-o contra seu cache IRK ou simplesmente registra o endereço de identidade a partir dos parâmetros de conexão
• O endereço de identidade é armazenado em cache na tabela interna de dispositivos do BlueZ
• bluetoothctl devices mostra então tanto o RPA original quanto o endereço de identidade recém-registrado — mesmo nome de dispositivo, endereço diferente
• A ferramenta compara com o RPA original e retorna a nova entrada como o BDADDR permanente

A chamada bluetoothctl pair que é executada concorrentemente pode ou não ser bem-sucedida — o BDADDR normalmente já está na tabela quando o comando pair é concluído ou falha.

Estágio 2 — Modo EMP (l2flood -R)

Este l2flood modificado tem dois modos dependendo do estágio pretendido:

Flag -R — Modo EMP (apenas DoS, sem sequestro) Usado ao executar o Estágio 2 de forma autônoma sem prosseguir para o Estágio 3. Dispara e esquece silencioso com reconexão em rajada — todas as threads sincronizam seus ciclos de conectar → rajada → fechamento forçado para garantir desmontagens completas periódicas de ACL. Não produz saída stdout durante operação normal.

Modo normal (DoS + sonda de sequestro) Usado quando o Estágio 3 é pretendido. O modo normal foi melhorado para lidar automaticamente com reconexões e gera no response from <addr>: id N quando o alvo para de responder — este é o sinal que wb.py monitora para acionar a tentativa de sequestro.

Estágio 3 — Por que o Vínculo Persiste

O vínculo resultante não é uma conexão transitória — é um vínculo SMP completo armazenado pelo BlueZ:

• bluetoothctl info <addr> mostra Paired: yes, Bonded: yes, Trusted: no
• O vínculo sobrevive a ciclos bluetoothctl power off/on
• O vínculo sobrevive a reinicialização da máquina atacante (armazenado em /var/lib/bluetooth/)
• O dispositivo aceita conexões subsequentes do adaptador atacante sem novo pareamento

Limitações Conhecidas

Estágio 1

• Requer Linux com BlueZ / bluetoothctl
• O alvo não deve já estar na tabela de dispositivos BlueZ sob o RPA (remova primeiro se necessário)
• A rotação de endereço durante a janela de conexão pode causar problemas de temporização — reexecute se a extração falhar

Estágio 2

• Requer conhecimento do endereço permanente (do Estágio 1 ou outros meios)
• O alvo deve estar ligado e dentro do alcance
• O dispositivo se recupera totalmente quando a inundação para — sem efeito persistente

Estágio 3

• Requer que o dispositivo entre em estado não responsivo (dependência do Estágio 2)
• O sucesso depende da temporização — o sequestro deve ocorrer durante a janela de recuperação
• Não funciona se o dispositivo desligar durante a inundação

Solução de Problemas

Nenhum dispositivo encontrado

• Verifique se bluetoothctl está funcionando: sudo bluetoothctl list
• Aumente o tempo de varredura: -s 30

Falha na conexão BLE / extração falha

• Remova o dispositivo do BlueZ primeiro: sudo bluetoothctl remove <addr>
• Reexecute — a rotação do RPA pode causar problemas de temporização

Inundação não tem efeito

• Aumente o número de threads: -t 16
• Use múltiplos adaptadores simultaneamente
• Verifique se o endereço permanente (não o RPA) está sendo alvo

Permissão negada

• Execute com sudo
• Certifique-se de que o usuário está no grupo bluetooth ou execute como root

Erro de importação bleak

• Debian/Ubuntu: sudo apt install libdbus-1-dev libglib2.0-dev
• Fedora: sudo dnf install dbus-devel glib2-devel
• Arch: sudo pacman -S dbus glib

Erros de D-Bus

• sudo systemctl start dbus && sudo systemctl start bluetooth

Créditos

• @kovmir por l2flood
• KU Leuven COSIC pela pesquisa original WhisperPair / CVE-2025-36911

Licença

MIT. Consulte LICENSE para detalhes.

Aviso Legal

Esta ferramenta é apenas para testes de segurança autorizados e pesquisa defensiva. O acesso não autorizado a dispositivos Bluetooth é ilegal. Use apenas em dispositivos que você possui ou para os quais tem permissão explícita por escrito para testar. O autor não assume nenhuma responsabilidade pelo uso não autorizado ou ilegal.