Whisper Bully

Bluetooth-BDADDR-Extraktion, Denial-of-Service & Hijack-Forschungswerkzeug

© 2026 @Ymsniper — Nur für autorisierte Sicherheitsforschung.

Übersicht

Whisper Bully ist ein dreistufiges Bluetooth-Sicherheitsforschungswerkzeug, das Geräte anvisiert, die Google Fast Pair (Dienst-UUID fe2c) bewerben. Es demonstriert zwei ungepatchte Angriffsprimitive, die außerhalb des Anwendungsbereichs des CVE-2025-36911-Firmware-Patches liegen:

• Ungepatchter BDADDR-Leak — permanente Identitätsadresse wird über eine einfache BLE-Verbindung preisgegeben, keine GATT-Interaktion erforderlich, funktioniert auf vollständig gepatchten Geräten
• SMP-Authentifizierungsumgehung über Reset-Fenster — persistenter Bond wird während der BT-Stack-Wiederherstellung nach L2CAP-Flood mittels Standard-SMP Just Works aufgebaut, ohne Fast-Pair-GATT-Handshake

⚠️ Dieses Werkzeug implementiert NICHT das Whisper Pair (Fast Pair GATT)-Protokoll. Es schreibt nie auf die Key-Based Pairing-Charakteristik (UUID 1236) oder Account-Key-Charakteristik (UUID 1238). Die hier beschriebene Angriffsfläche ist getrennt von und nicht adressiert durch den CVE-2025-36911-Pairing-Mode-Check-Patch.

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

Angriffsstufen

Stufe 1 — BDADDR-Extraktion (Ungepatchte Informationspreisgabe)

Grundursache: Wenn eine BLE-Verbindung hergestellt wird, verarbeitet der Linux-BlueZ-Host-Stack das LL_CONNECTION_COMPLETE-Ereignis und löst die auflösbare private Adresse (RPA) des Geräts in seine permanente Identitätsadresse auf, die er in der BlueZ-Gerätetabelle zwischenspeichert. Dies geschieht auf der Link-Layer-/HCI-Ebene, bevor eine GATT-Dienstinteraktion stattfindet. Kein Fast-Pair-Protokoll ist beteiligt.

Was der Code tatsächlich tut:

1. Führt einen aktiven BLE-Scan (BleakScanner) nach Geräten durch, die die Fast-Pair-Dienst-UUID fe2c bewerben – wird nur zur Zielidentifikation verwendet, keine Protokollinteraktion
2. Stellt eine einfache BLE-Verbindung über BleakClient.connect() her – keine GATT-Schreibvorgänge jeglicher Art
3. Setzt den BlueZ-Agenten auf NoInputNoOutput als Vorbereitung für Schritt 4
4. Überprüft, ob der Fast-Pair-GATT-Dienst auf dem Ziel vorhanden ist – diese Prüfung ist nur empfehlend; das Werkzeug fährt unabhängig vom Ergebnis fort (Zeile 452 von wb.py)
5. Führt bluetoothctl pair <rpa_addr> aus – Standard-Bluetooth-SMP-Pairing-Versuch, nicht Fast Pair
6. Überwacht die Standardausgabe von bluetoothctl auf die Ausgabe Bonded: yes, die die gebondete Adresse enthalten kann
7. Primärer Rückfall: Ruft bluetoothctl devices auf und vergleicht mit der ursprünglichen RPA – jeder Eintrag mit demselben Gerätenamen, aber einer anderen Adresse, ist die permanente Identitätsadresse, die in Schritt 2 von BlueZ preisgegeben wurde

Warum der Patch dies nicht behebt:

Der CVE-2025-36911-Firmware-Fix fügt eine Pairing-Mode-Prüfung zum Fast-Pair-GATT-Key-Based-Pairing-Charakteristik-Handler auf dem Zubehör hinzu. Dieses Werkzeug schreibt nie auf diese Charakteristik. Der Identitätsadressen-Leak tritt auf dem Linux-Host des Angreifers über den eigenen BlueZ-Geräte-Cache auf – vollständig außerhalb der Firmware des Zubehörs.

Wichtige Verhaltenshinweise:

• Die Extraktion kann selbst dann erfolgreich sein, wenn der Schritt bluetoothctl pair fehlschlägt oder zeitlich ausläuft
• Die Prüfung auf das Vorhandensein des FP-GATT-Dienstes in Schritt 4 blockiert den Angriff nicht
• Es erscheint kein PIN-Bestätigungsfenster – NoInputNoOutput bedeutet keine Benutzerinteraktion auf beiden Seiten für Just Works

Stufe 2 — L2CAP-Flooding (EMP-Burst-Reconnect-Modus)

Sobald die permanente Adresse bekannt ist, kann optional ein anhaltender L2CAP-Denial-of-Service unter Verwendung einer modifizierten Version von l2flood ausgeführt werden.

Zwei Modi werden im gesamten Werkzeug verwendet:

-R-Flag — EMP-Modus (Stufe 2 Flood) Stiller Fire-and-Forget-Burst-Reconnect. Alle Threads synchronisieren ihre Connect→Burst→Forced-Close-Zyklen, sodass das Ziel periodisch vollständige ACL-Takedowns erhält, anstatt gestaffeltes L2CAP-Kanal-Shuffling, das es absorbieren könnte. Verwendet SO_LINGER {1,0} für sofortigen RST-Takedown bei jedem Schließen. Erzeugt während des normalen Betriebs keine Ausgabe auf stdout – Verbindungsfehler werden nach stderr unterdrückt und nur periodisch ausgegeben.

Normalmodus (Stufe 3 Hijack-Probe) Wird ohne -R verwendet, um zu prüfen, ob das Ziel noch antwortet. Dieser Modus wurde ebenfalls verbessert – er behandelt jetzt automatisch Wiederverbindungen und gibt no response from <addr>: id N aus, wenn das Ziel nicht mehr antwortet, was wb.py überwacht, um den Hijack auszulösen.

Ergebnis: Das Zielgerät wird während des aktiven Floods unerreichbar für normale Verbindungsversuche. Das Gerät erholt sich vollständig, wenn der Angriff stoppt – kein dauerhafter Schaden.

Multithread-Verhalten:

• Threads synchronisieren sich nach jedem Burst-Zyklus, sodass der Druck gleichzeitig auf das Ziel trifft
• Effektiv bis zu ~16 Threads auf typischer Hardware; abnehmender Nutzen darüber hinaus
• Mehrere HCI-Adapter können gleichzeitig verwendet werden, um den Druck zu erhöhen

Stufe 3 — Hijack über SMP Just Works während des Reset-Fensters (Ungepatchter Auth-Bypass)

Grundursache: Der anhaltende L2CAP-Flood führt dazu, dass der Bluetooth-Stack des Zielgeräts abstürzt oder zurückgesetzt wird. Während des Wiederherstellungsfensters – bevor der Fast-Pair-GATT-Dienst erneut registriert wurde und bevor der Security Manager vollständig neu initialisiert wurde – akzeptiert das Gerät einen standardmäßigen SMP Just Works Bond von NoInputNoOutput, ohne den Fast-Pair-GATT-Handshake zu erfordern, der normalerweise den Bond blockieren würde. Der resultierende Bond ist persistent: Er überlebt BT-Adapter-Resets und zeigt Paired: yes / Bonded: yes in bluetoothctl info an.

Warum dies ein separater Befund von CVE-2025-36911 ist:

Der CVE-2025-36911-Patch erzwingt eine Pairing-Mode-Prüfung im FP-GATT-Key-Based-Pairing-Charakteristik-Handler. Stufe 3 greift nie auf diese Charakteristik zu. Der Bond wird auf der SMP-Ebene während eines Fensters hergestellt, in dem der FP-GATT-Server nicht neu initialisiert wurde, sodass das Fast-Pair-Sicherheitstor nie erreicht wird. Ein vollständig gepatchtes Gerät bleibt dafür anfällig, da der Patch während der Stack-Wiederherstellung keine Sichtbarkeit auf die SMP-Ebene hat.

Was der Code tatsächlich tut:

1. Sendet eine L2CAP-Probe (l2flood -c -1 -t 2), um zu bestätigen, dass das Gerät nicht reagiert – sucht nach no response from <addr>: id N in der Ausgabe
2. Sobald der nicht reagierende Zustand bestätigt ist, führt es bluetoothctl connect <permanent_addr> in einer Wiederholungsschleife aus
3. SMP verhandelt NoInputNoOutput / NoInputNoOutput → Just Works-Assoziationsmodell → Bond wird abgeschlossen
4. bluetoothctl connect gibt bei Erfolg den Exit-Code 0 zurück
5. Bond bleibt bestehen, nachdem der Angriff gestoppt wurde

Erfolgswahrscheinlichkeit nach Gerätezustand:

Beziehung zu CVE-2025-36911

⚠️ Rechtlicher Hinweis

Dies ist ein Forschungswerkzeug für Denial-of-Service und unbefugten Zugriff.

Die Verwendung dieses Werkzeugs auf Geräten, die Ihnen nicht gehören, oder ohne ausdrückliche schriftliche Genehmigung ist ein Bundesverbrechen, das mit Gefängnis und Geldstrafen gemäß dem Computer Fraud and Abuse Act (18 U.S.C. § 1030) und entsprechenden Gesetzen in anderen Rechtsordnungen bestraft wird.

Sie dürfen dieses Werkzeug nur verwenden auf:

• Geräten, die Ihnen persönlich gehören
• Geräten, für die Sie die ausdrückliche schriftliche Genehmigung des Eigentümers zur Durchführung von Sicherheitstests haben

Anforderungen

• Linux (getestet auf Ubuntu 20.04+)
• Root-Rechte (erforderlich für bluetoothctl und rohen BLE-Zugriff)
• bluetoothctl / BlueZ installiert und funktionsfähig
• Python 3.7+
• Für Stufe 2/3: l2flood mit OpenMP-Unterstützung – siehe kovmir/l2flood

Installation

Systemabhängigkeiten

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

Klonen und installieren

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

Verwendung

Stufe 1: BDADDR-Extraktion

# 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

Hinweis: Wenn ein Gerät zuvor von diesem Werkzeug oder manuell verbunden oder gepaart wurde, kennt BlueZ bereits seine Identitätsadresse. Entfernen Sie es zuerst, damit die Extraktion sauber läuft:

root@kitploit:~

sudo bluetoothctl remove <address>

Stufe 2: L2CAP-Flooding (Optional)

Methode 1 — Interaktiv (nach Extraktion abgefragt)

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

Methode 2 — Flags (Überspringe Abfragen)

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

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

# Mit Dauer und Thread-Anzahl
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 8

Methode 3 — Eigenständiges Flood-Skript

# Flood aus extrahierter Zieldatei für 120 Sekunden
sudo python3 aggressive_test.py -f targets.json -d 120 -t 4

# Flood einer einzelnen bekannten Adresse für 60 Sekunden
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -d 60

# Flood unendlich (Strg+C zum Stoppen)
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -f

Stufe 3: Hijack (Optional)

# Integriert — extrahieren, flooden, dann hijacken
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120

# Manueller eigenständiger Hijack auf bekannter Adresse
sudo python3 wb.py -H AA:BB:CC:DD:EE:FF

Vollständiger Dreistufen-Lauf (Ein Befehl)

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

Ausführungsablauf:

1. 20 Sekunden nach Fast-Pair-Geräten scannen
2. Permanente BDADDR von jedem Ziel extrahieren
3. Alle Ziele 120 Sekunden lang mit 4 Threads flooden
4. Auf nicht reagierenden Zustand überwachen
5. Hijack-Versuch an jedem Ziel während des Wiederherstellungsfensters
6. Ergebnisse in targets.json speichern

Multi-Adapter-Angriff

# 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

Verdoppelt den DoS-Druck und erhöht die Hijack-Erfolgswahrscheinlichkeit während des Wiederherstellungsfensters.

Befehlszeilen-Flags

Technische Details

Stufe 1 — Warum Extraktion ohne GATT-Interaktion funktioniert

Die Fast-Pair-FE2C-Dienst-UUID wird nur als Scan-Filter verwendet, um Kandidatenziele zu identifizieren. Sobald eine BLE-Verbindung hergestellt ist:

• Der Link Layer schließt den Verbindungs-Handshake ab und feuert LL_CONNECTION_COMPLETE an den Host
• BlueZ verarbeitet dieses Ereignis und löst, falls das Gerät eine auflösbare private Adresse verwendet, diese gegen seinen IRK-Cache auf oder registriert einfach die Identitätsadresse aus den Verbindungsparametern
• Die Identitätsadresse wird in der internen Gerätetabelle von BlueZ zwischengespeichert
• bluetoothctl devices zeigt dann sowohl die ursprüngliche RPA als auch die neu registrierte Identitätsadresse an – gleicher Gerätename, andere Adresse
• Das Werkzeug vergleicht mit der ursprünglichen RPA und gibt den neuen Eintrag als permanente BDADDR zurück

Der bluetoothctl pair-Aufruf, der parallel läuft, kann erfolgreich sein oder fehlschlagen – die BDADDR befindet sich normalerweise bereits in der Tabelle, wenn der Pair-Befehl abgeschlossen ist oder fehlschlägt.

Stufe 2 — EMP-Modus (l2flood -R)

Dieses modifizierte l2flood hat zwei Modi, abhängig von der beabsichtigten Stufe:

-R-Flag — EMP-Modus (DoS nur, kein Hijack) Wird verwendet, wenn Stufe 2 eigenständig ohne Übergang zu Stufe 3 ausgeführt wird. Stiller Fire-and-Forget-Burst-Reconnect – alle Threads synchronisieren ihre Connect→Burst→Forced-Close-Zyklen, um periodisch vollständige ACL-Takedowns zu garantieren. Erzeugt während des normalen Betriebs keine Ausgabe auf stdout.

Normalmodus (DoS + Hijack-Probe) Wird verwendet, wenn Stufe 3 beabsichtigt ist. Der Normalmodus wurde verbessert, um automatisch Wiederverbindungen zu behandeln und gibt no response from <addr>: id N aus, wenn das Ziel nicht mehr antwortet – dies ist das Signal, das wb.py überwacht, um den Hijack-Versuch auszulösen.

Stufe 3 — Warum der Bond bestehen bleibt

Der resultierende Bond ist keine flüchtige Verbindung – es ist ein vollständiger SMP-Bond, der von BlueZ gespeichert wird:

• bluetoothctl info <addr> zeigt Paired: yes, Bonded: yes, Trusted: no
• Bond überlebt bluetoothctl power off/on-Zyklen
• Bond überlebt Neustart des Angreiferrechners (gespeichert in /var/lib/bluetooth/)
• Gerät akzeptiert nachfolgende Verbindungen vom Angreifer-Adapter ohne erneutes Pairing

Bekannte Einschränkungen

Stufe 1

• Erfordert Linux mit BlueZ / bluetoothctl
• Ziel darf sich nicht bereits unter der RPA in der BlueZ-Gerätetabelle befinden (falls nötig zuerst entfernen)
• Adress-Rolling während des Verbindungsfensters kann zu Timing-Problemen führen – bei fehlgeschlagener Extraktion erneut ausführen

Stufe 2

• Erfordert Kenntnis der permanenten Adresse (von Stufe 1 oder anderen Mitteln)
• Ziel muss eingeschaltet und in Reichweite sein
• Gerät erholt sich vollständig, wenn der Flood stoppt – kein dauerhafter Effekt

Stufe 3

• Erfordert, dass das Gerät in einen nicht reagierenden Zustand versetzt wird (Abhängigkeit von Stufe 2)
• Erfolg ist zeitabhängig – Hijack muss während des Wiederherstellungsfensters landen
• Funktioniert nicht, wenn das Gerät während des Floods ausgeschaltet wird

Fehlerbehebung

Keine Geräte gefunden

• Überprüfen, ob bluetoothctl funktioniert: sudo bluetoothctl list
• Scan-Zeit erhöhen: -s 30

BLE-Verbindung fehlgeschlagen / Extraktion fehlschlägt

• Gerät zuerst aus BlueZ entfernen: sudo bluetoothctl remove <addr>
• Erneut ausführen – RPA-Rolling kann Timing-Probleme verursachen

Flood hat keine Wirkung

• Thread-Anzahl erhöhen: -t 16
• Mehrere Adapter gleichzeitig verwenden
• Überprüfen, ob die permanente Adresse (nicht die RPA) als Ziel verwendet wird

Zugriff verweigert

• Mit sudo ausführen
• Sicherstellen, dass der Benutzer in der bluetooth-Gruppe ist, oder als root ausführen

bleak-Importfehler

• 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

D-Bus-Fehler

• sudo systemctl start dbus && sudo systemctl start bluetooth

Danksagungen

• @kovmir für l2flood
• KU Leuven COSIC für die ursprüngliche WhisperPair / CVE-2025-36911-Forschung

Lizenz

MIT. Siehe LICENSE für Details.

Haftungsausschluss

Dieses Werkzeug ist für autorisierte Sicherheitstests und defensive Forschung bestimmt. Unbefugter Zugriff auf Bluetooth-Geräte ist illegal. Verwenden Sie es nur auf Geräten, die Ihnen gehören oder für die Sie eine ausdrückliche schriftliche Erlaubnis zum Testen haben. Der Autor übernimmt keine Haftung für unbefugte oder illegale Nutzung.