Whisper Bully

Outil de recherche sur l'extraction BDADDR Bluetooth, le déni de service et le détournement

© 2026 @Ymsniper — Pour la recherche en sécurité autorisée uniquement.

Aperçu

Whisper Bully est un outil de recherche en sécurité Bluetooth en trois étapes qui cible les appareils annonçant Google Fast Pair (UUID de service fe2c). Il démontre deux primitives d'attaque non corrigées qui sont hors du périmètre du correctif firmware CVE-2025-36911 :

• Fuite BDADDR non corrigée — adresse d'identité permanente divulguée via une simple connexion BLE, sans interaction GATT requise, fonctionne sur les appareils entièrement corrigés
• Contournement de l'authentification SMP via la fenêtre de réinitialisation — liaison persistante établie via SMP Just Works standard pendant la récupération de la pile BT après un flood L2CAP, sans aucune poignée de main GATT Fast Pair

⚠️ Cet outil n'implémente PAS le protocole Whisper Pair (GATT Fast Pair). Il n'écrit jamais sur la caractéristique Key-Based Pairing (UUID 1236) ni sur la caractéristique Account Key (UUID 1238). La surface d'attaque décrite ici est distincte du correctif de vérification du mode d'appairage CVE-2025-36911 et n'est pas traitée par celui-ci.

https://github.com/user-attachments/assets/67f2bcb6-38ad-4ba0-80c5-36dbb54f3f11

Étapes d'attaque

Étape 1 — Extraction BDADDR (divulgation d'informations non corrigée)

Cause racine : Lorsqu'une connexion BLE est établie, la pile hôte BlueZ de Linux traite l'événement LL_CONNECTION_COMPLETE et résout l'adresse privée résoluble (RPA) de l'appareil vers son adresse d'identité permanente, en la mettant en cache dans la table des appareils BlueZ. Cela se produit au niveau de la couche liaison / HCI, avant toute interaction avec les services GATT. Aucun protocole Fast Pair n'est impliqué.

Ce que fait réellement le code :

1. Effectue un scan BLE actif (BleakScanner) pour les appareils annonçant l'UUID de service Fast Pair fe2c — utilisé uniquement pour l'identification des cibles, aucune interaction protocolaire
2. Établit une connexion BLE simple via BleakClient.connect() — aucune écriture GATT d'aucune sorte
3. Configure l'agent BlueZ sur NoInputNoOutput en préparation de l'étape 4
4. Vérifie si le service GATT Fast Pair est présent sur la cible — cette vérification est uniquement indicative ; l'outil continue quel que soit le résultat (ligne 452 de wb.py)
5. Exécute bluetoothctl pair <rpa_addr> — tentative d'appairage SMP Bluetooth standard, pas Fast Pair
6. Surveille la sortie standard de bluetoothctl pour la sortie Bonded: yes, qui peut contenir l'adresse liée
7. Repli principal : Appelle bluetoothctl devices et compare avec la RPA initiale — toute entrée avec le même nom d'appareil mais une adresse différente est l'adresse d'identité permanente, divulguée par BlueZ à l'étape 2

Pourquoi le correctif ne résout pas ce problème :

Le correctif firmware CVE-2025-36911 ajoute une vérification du mode d'appairage au gestionnaire de la caractéristique GATT Key-Based Pairing Fast Pair sur l'accessoire. Cet outil n'écrit jamais sur cette caractéristique. La fuite d'adresse d'identité se produit sur l'hôte Linux de l'attaquant via le cache d'appareils de BlueZ lui-même — entièrement en dehors du firmware de l'accessoire.

Points clés de comportement :

• L'extraction peut réussir même si l'étape bluetoothctl pair échoue ou expire
• La vérification de présence du service GATT FP à l'étape 4 ne conditionne pas l'attaque
• Aucune fenêtre de confirmation PIN n'apparaît — NoInputNoOutput signifie aucune interaction utilisateur des deux côtés pour Just Works

Étape 2 — Flood L2CAP (mode EMP burst-reconnect)

Une fois l'adresse permanente connue, exécutez facultativement un déni de service L2CAP soutenu à l'aide d'une version modifiée de l2flood.

Deux modes sont utilisés dans l'outil :

Option -R — mode EMP (flood de l'étape 2) Reconnexion en rafales silencieuse de type « fire-and-forget ». Tous les threads synchronisent leurs cycles connect → burst → fermeture forcée afin que la cible reçoive des démontages ACL complets périodiques plutôt que des réorganisations de canaux L2CAP échelonnées qu'elle peut absorber. Utilise SO_LINGER {1,0} pour un démontage RST immédiat à chaque fermeture. Ne produit aucune sortie stdout pendant le fonctionnement normal — les erreurs de connexion sont envoyées vers stderr et imprimées périodiquement uniquement.

Mode normal (sonde de détournement de l'étape 3) Utilisé sans -R pour vérifier si la cible répond encore. Ce mode a également été amélioré — il gère désormais les reconnexions automatiquement et émet no response from <addr>: id N lorsque la cible cesse de répondre, c'est ce que wb.py surveille pour déclencher le détournement.

Résultat : L'appareil cible devient non réactif aux tentatives de connexion normales pendant que le flood est actif. L'appareil récupère complètement lorsque l'attaque s'arrête — aucun dommage permanent.

Comportement multithread :

• Les threads se synchronisent après chaque cycle de rafale afin que la pression atteigne la cible simultanément
• Efficace jusqu'à ~16 threads sur du matériel typique ; rendements décroissants au-delà
• Plusieurs adaptateurs HCI peuvent être utilisés simultanément pour une pression accrue

Étape 3 — Détournement via SMP Just Works pendant la fenêtre de réinitialisation (contournement d'authentification non corrigé)

Cause racine : Le flood L2CAP soutenu provoque le crash ou la réinitialisation de la pile Bluetooth de l'appareil cible. Pendant la fenêtre de récupération — avant que le service GATT Fast Pair ne soit ré-enregistré et avant que le Security Manager ne soit complètement ré-initialisé — l'appareil accepte une liaison SMP Just Works standard de NoInputNoOutput sans exiger la poignée de main GATT Fast Pair qui conditionnerait normalement la liaison. La liaison résultante est persistante : elle survit aux réinitialisations de l'adaptateur BT et affiche Paired: yes / Bonded: yes dans bluetoothctl info.

Pourquoi cette découverte est distincte de CVE-2025-36911 :

Le correctif CVE-2025-36911 impose une vérification du mode d'appairage dans le gestionnaire de la caractéristique GATT Key-Based Pairing FP. L'étape 3 ne touche jamais à cette caractéristique. La liaison est établie au niveau de la couche SMP pendant une fenêtre où le serveur GATT FP ne s'est pas ré-initialisé, donc la barrière de sécurité Fast Pair n'est même jamais atteinte. Un appareil entièrement corrigé reste vulnérable à cette attaque car le correctif n'a aucune visibilité sur la couche SMP pendant la récupération de la pile.

Ce que fait réellement le code :

1. Envoie une sonde L2CAP (l2flood -c -1 -t 2) pour confirmer que l'appareil est non réactif — recherche no response from <addr>: id N dans la sortie
2. Une fois l'état non réactif confirmé, exécute bluetoothctl connect <permanent_addr> dans une boucle de tentatives
3. SMP négocie NoInputNoOutput / NoInputNoOutput → modèle d'association Just Works → la liaison aboutit
4. bluetoothctl connect renvoie le code de sortie 0 en cas de succès
5. La liaison persiste après l'arrêt de l'attaque

Probabilité de succès selon l'état de l'appareil :

Relation avec CVE-2025-36911

⚠️ Avertissement légal

Il s'agit d'un outil de recherche sur le déni de service et l'accès non autorisé.

Utiliser cet outil sur des appareils que vous ne possédez pas ou sans autorisation écrite explicite est un crime fédéral passible d'emprisonnement et d'amendes en vertu du Computer Fraud and Abuse Act (18 U.S.C. § 1030) et des lois équivalentes dans d'autres juridictions.

Vous pouvez utiliser cet outil uniquement sur :

• Les appareils que vous possédez personnellement
• Les appareils pour lesquels vous disposez d'une autorisation écrite explicite du propriétaire pour effectuer des tests de sécurité

Prérequis

• Linux (testé sur Ubuntu 20.04+)
• Privilèges root (requis pour bluetoothctl et l'accès BLE brut)
• bluetoothctl / BlueZ installé et fonctionnel
• Python 3.7+
• Pour les étapes 2/3 : l2flood avec support OpenMP — voir kovmir/l2flood

Installation

Dépendances système

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

Clonage et installation

git clone https://github.com/Ymsniper/Whisper_Bully.git
cd Whisper_Bully
pip3 install -r requirements.txt
# Required for Stage 2/3 only:
make
sudo make install

Utilisation

Étape 1 : Extraction BDADDR

# Auto-detect and extract all nearby Fast Pair devices
sudo python3 wb.py

# 20 second scan, save results
sudo python3 wb.py -s 20 -o targets.json

# 30 second scan, custom output file
sudo python3 wb.py -s 30 -o extracted.json

Remarque : Si un appareil a été précédemment connecté ou appairé par cet outil ou manuellement, BlueZ connaît déjà son adresse d'identité. Supprimez-le d'abord pour que l'extraction se déroule proprement :

root@kitploit:~

sudo bluetoothctl remove <address>

Étape 2 : Flood L2CAP (facultatif)

Méthode 1 — Interactive (invite après l'extraction)

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

Méthode 2 — Options (sans invites)

# Stage 1 + Stage 2 only
sudo python3 wb.py -s 20 -o targets.json --aggressive

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

# With duration and thread count
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 8

Méthode 3 — Script de flood autonome

# Flood from extracted targets file for 120 seconds
sudo python3 aggressive_test.py -f targets.json -d 120 -t 4

# Flood a single known address for 60 seconds
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -d 60

# Flood forever (Ctrl+C to stop)
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -f

Étape 3 : Détournement (facultatif)

# Integrated — extract, flood, then hijack
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120

# Manual standalone hijack on known address
sudo python3 wb.py -H AA:BB:CC:DD:EE:FF

Exécution complète en trois étapes (une seule commande)

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

Déroulement de l'exécution :

1. Scanner pendant 20 secondes les appareils Fast Pair
2. Extraire le BDADDR permanent de chaque cible
3. Flooder toutes les cibles pendant 120 secondes avec 4 threads
4. Surveiller l'état non réactif
5. Tenter le détournement sur chaque cible pendant la fenêtre de récupération
6. Enregistrer les résultats dans targets.json

Attaque multi-adaptateurs

# 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

Double la pression DoS et augmente la probabilité de succès du détournement pendant la fenêtre de récupération.

Options de ligne de commande

Détails techniques

Étape 1 — Pourquoi l'extraction fonctionne sans interaction GATT

L'UUID de service Fast Pair FE2C est utilisé uniquement comme filtre de scan pour identifier les cibles candidates. Une fois qu'une connexion BLE est établie :

• La couche liaison termine la poignée de main de connexion et déclenche LL_CONNECTION_COMPLETE vers l'hôte
• BlueZ traite cet événement et, si l'appareil utilise une adresse privée résoluble, la résout via son cache IRK ou enregistre simplement l'adresse d'identité à partir des paramètres de connexion
• L'adresse d'identité est mise en cache dans la table interne des appareils de BlueZ
• bluetoothctl devices affiche alors à la fois la RPA d'origine et l'adresse d'identité nouvellement enregistrée — même nom d'appareil, adresse différente
• L'outil compare avec la RPA d'origine et renvoie la nouvelle entrée comme BDADDR permanent

L'appel bluetoothctl pair exécuté en parallèle peut réussir ou non — le BDADDR est généralement déjà dans la table au moment où la commande pair aboutit ou échoue.

Étape 2 — Mode EMP (l2flood -R)

Ce l2flood modifié a deux modes selon l'étape visée :

Option -R — mode EMP (DoS uniquement, pas de détournement) Utilisé lors de l'exécution de l'étape 2 de manière autonome sans passer à l'étape 3. Reconnexion en rafales silencieuse de type « fire-and-forget » — tous les threads synchronisent leurs cycles connect → burst → fermeture forcée pour garantir des démontages ACL complets périodiques. Ne produit aucune sortie stdout pendant le fonctionnement normal.

Mode normal (DoS + sonde de détournement) Utilisé lorsque l'étape 3 est visée. Le mode normal a été amélioré pour gérer automatiquement les reconnexions et émet no response from <addr>: id N lorsque la cible cesse de répondre — c'est le signal que wb.py surveille pour déclencher la tentative de détournement.

Étape 3 — Pourquoi la liaison persiste

La liaison résultante n'est pas une connexion transitoire — c'est une liaison SMP complète stockée par BlueZ :

• bluetoothctl info <addr> affiche Paired: yes, Bonded: yes, Trusted: no
• La liaison survit aux cycles bluetoothctl power off/on
• La liaison survit au redémarrage de la machine de l'attaquant (stockée dans /var/lib/bluetooth/)
• L'appareil accepte les connexions ultérieures depuis l'adaptateur de l'attaquant sans ré-appairage

Limitations connues

Étape 1

• Nécessite Linux avec BlueZ / bluetoothctl
• La cible ne doit pas déjà être dans la table des appareils BlueZ sous la RPA (supprimez-la d'abord si nécessaire)
• La rotation d'adresse pendant la fenêtre de connexion peut provoquer des problèmes de synchronisation — relancez si l'extraction échoue

Étape 2

• Nécessite la connaissance de l'adresse permanente (issue de l'étape 1 ou d'autres moyens)
• La cible doit être allumée et à portée
• L'appareil récupère complètement lorsque le flood s'arrête — aucun effet persistant

Étape 3

• Nécessite que l'appareil entre dans un état non réactif (dépendance à l'étape 2)
• Le succès dépend du timing — le détournement doit se produire pendant la fenêtre de récupération
• Ne fonctionne pas si l'appareil s'éteint pendant le flood

Dépannage

Aucun appareil trouvé

• Vérifiez que bluetoothctl fonctionne : sudo bluetoothctl list
• Augmentez la durée du scan : -s 30

Échec de la connexion BLE / de l'extraction

• Supprimez d'abord l'appareil de BlueZ : sudo bluetoothctl remove <addr>
• Relancez — la rotation de la RPA peut provoquer des problèmes de synchronisation

Le flood n'a aucun effet

• Augmentez le nombre de threads : -t 16
• Utilisez plusieurs adaptateurs simultanément
• Vérifiez que l'adresse permanente (pas la RPA) est bien ciblée

Permission refusée

• Exécutez avec sudo
• Assurez-vous que l'utilisateur est dans le groupe bluetooth ou exécutez en root

Erreur d'import 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

Erreurs D-Bus

• sudo systemctl start dbus && sudo systemctl start bluetooth

Crédits

• @kovmir pour l2flood
• KU Leuven COSIC pour la recherche originale WhisperPair / CVE-2025-36911

Licence

MIT. Voir LICENSE pour plus de détails.

Avertissement

Cet outil est destiné aux tests de sécurité autorisés et à la recherche défensive uniquement. L'accès non autorisé aux appareils Bluetooth est illégal. Utilisez-le uniquement sur des appareils que vous possédez ou pour lesquels vous disposez d'une autorisation écrite explicite de test. L'auteur décline toute responsabilité en cas d'utilisation non autorisée ou illégale.