Whisper Bully

Инструмент исследования Bluetooth: извлечение BDADDR, отказ в обслуживании и перехват

© 2026 @Ymsniper — Только для авторизованных исследований безопасности.

Обзор

Whisper Bully — это трёхэтапный инструмент для исследования безопасности Bluetooth, нацеленный на устройства, рекламирующие Google Fast Pair (сервисный UUID fe2c). Он демонстрирует два неисправленных примитива атаки, которые находятся за пределами области действия патча прошивки CVE-2025-36911:

Неисправленная утечка BDADDR — постоянный идентификационный адрес раскрывается через простое BLE-соединение, без необходимости взаимодействия с GATT, работает на полностью исправленных устройствах
Обход аутентификации SMP через окно сброса — постоянное связывание устанавливается через стандартный SMP Just Works во время восстановления стека BT после L2CAP-флуда, без какого-либо рукопожатия Fast Pair GATT

⚠️ Этот инструмент НЕ реализует протокол Whisper Pair (Fast Pair GATT). Он никогда не записывает в характеристику Key-Based Pairing (UUID 1236) или характеристику Account Key (UUID 1238). Описанная здесь поверхность атаки является отдельной и не учтена в патче проверки режима сопряжения CVE-2025-36911.

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

Этапы атаки

Этап 1 — Извлечение BDADDR (Неисправленное раскрытие информации)

Основная причина: При установке BLE-соединения хост-стек Linux BlueZ обрабатывает событие LL_CONNECTION_COMPLETE и преобразует разрешимый приватный адрес (RPA) устройства в его постоянный идентификационный адрес, кэшируя его в таблице устройств BlueZ. Это происходит на уровне Link Layer / HCI, до любого взаимодействия с GATT-сервисом. Протокол Fast Pair не задействован.

Что на самом деле делает код:

Выполняет активное BLE-сканирование (BleakScanner) для обнаружения устройств, рекламирующих сервисный UUID Fast Pair fe2c — используется только для идентификации цели, без взаимодействия с протоколом
Устанавливает простое BLE-соединение через BleakClient.connect() — никаких GATT-записей любого рода
Устанавливает агент BlueZ в режим NoInputNoOutput в качестве подготовки к шагу 4
Проверяет наличие сервиса Fast Pair GATT на целевом устройстве — эта проверка является только рекомендательной; инструмент продолжает работу независимо от результата (строка 452 в wb.py)
Выполняет bluetoothctl pair <rpa_addr> — стандартная попытка SMP-сопряжения, а не Fast Pair
Отслеживает вывод bluetoothctl на наличие строки Bonded: yes, которая может содержать связанный адрес
Основной запасной вариант: Вызывает bluetoothctl devices и сравнивает с исходным RPA — любая запись с тем же именем устройства, но другим адресом, является постоянным идентификационным адресом, раскрытым BlueZ на шаге 2

Почему патч это не исправляет:

Исправление CVE-2025-36911 добавляет в прошивку аксессуара проверку режима сопряжения в обработчике характеристики Key-Based Pairing GATT Fast Pair. Этот инструмент никогда не записывает в эту характеристику. Утечка идентификационного адреса происходит на хосте атакующего Linux через собственный кэш устройств BlueZ — полностью вне прошивки аксессуара.

Ключевые замечания по поведению:

Извлечение может быть успешным, даже если шаг bluetoothctl pair завершается неудачей или тайм-аутом
Проверка наличия GATT-сервиса FP на шаге 4 не блокирует атаку
Окно подтверждения PIN не появляется — NoInputNoOutput означает отсутствие взаимодействия с пользователем с обеих сторон для Just Works

Этап 2 — L2CAP-флуд (Режим EMP-всплеска и переподключения)

После получения постоянного адреса можно по желанию выполнить устойчивый L2CAP-флуд типа «отказ в обслуживании», используя модифицированную версию l2flood.

В инструменте используются два режима:

Флаг -R — режим EMP (флуд на этапе 2) Тихий режим «выстрелил и забыл» с всплесками и переподключением. Все потоки синхронизируют свои циклы «подключение → всплеск → принудительное закрытие», чтобы цель получала периодические полные разрывы ACL, а не перемежающуюся перестановку L2CAP-каналов, которую она может поглотить. Использует SO_LINGER {1,0} для немедленного разрыва RST при каждом закрытии. Не выводит stdout в нормальном режиме работы — ошибки подключения подавляются в stderr и выводятся только периодически.

Обычный режим (зондирование для перехвата на этапе 3) Используется без -R для проверки, отвечает ли цель ещё. Этот режим также был улучшен — теперь он автоматически выполняет переподключения и выводит no response from <addr>: id N, когда цель перестаёт отвечать, что wb.py отслеживает для запуска перехвата.

Результат: Целевое устройство становится недоступным для обычных попыток подключения, пока активен флуд. Устройство полностью восстанавливается, когда атака прекращается — никакого постоянного повреждения.

Поведение многопоточности:

Потоки синхронизируются после каждого цикла всплеска, чтобы давление на цель оказывалось одновременно
Эффективно до ~16 потоков на типичном оборудовании; дальнейшее увеличение даёт убывающую отдачу
Для увеличения давления можно одновременно использовать несколько HCI-адаптеров

Этап 3 — Перехват через SMP Just Works во время окна сброса (Неисправленный обход аутентификации)

Основная причина: Устойчивый L2CAP-флуд вызывает сбой или сброс стека Bluetooth целевого устройства. В окне восстановления — до того, как GATT-сервис Fast Pair будет перерегистрирован и Security Manager полностью переинициализируется — устройство принимает стандартную SMP-связку Just Works от NoInputNoOutput, не требуя рукопожатия Fast Pair GATT, которое обычно ограничивает связывание. Полученная связка является постоянной: она переживает сбросы BT-адаптера и показывает Paired: yes / Bonded: yes в bluetoothctl info.

Почему это отдельное открытие, а не часть CVE-2025-36911:

Патч CVE-2025-36911 внедряет проверку режима сопряжения в обработчик характеристики Key-Based Pairing GATT Fast Pair. Этап 3 никогда не обращается к этой характеристике. Связывание устанавливается на уровне SMP в окне, когда GATT-сервер FP ещё не переинициализировался, поэтому шлюз безопасности Fast Pair даже не достигается. Полностью исправленное устройство остаётся уязвимым, потому что патч не имеет видимости уровня SMP во время восстановления стека.

Что на самом деле делает код:

Отправляет L2CAP-зонд (l2flood -c -1 -t 2) для подтверждения, что устройство не отвечает — ищет в выводе no response from <addr>: id N
После подтверждения состояния без ответа запускает в цикле с повторными попытками bluetoothctl connect <permanent_addr>
SMP согласовывает NoInputNoOutput / NoInputNoOutput → модель ассоциации Just Works → связывание завершается
bluetoothctl connect возвращает код выхода 0 при успехе
Связка сохраняется после завершения атаки

Вероятность успеха в зависимости от состояния устройства:

Состояние устройства	Ожидаемый результат
Активно под флудом / не отвечает	Наивысший успех — стек в деградированном состоянии во время восстановления
Восстанавливается после флуда	Высокий успех — временное окно повторной инициализации SM
Полностью восстановилось	Более низкий успех — нормальная безопасность восстановлена

Отношение к CVE-2025-36911

⚠️ Правовое предупреждение

Это инструмент для исследования отказа в обслуживании и несанкционированного доступа.

Использование этого инструмента на устройствах, которые вам не принадлежат, или без явного письменного разрешения является федеральным преступлением, наказуемым тюремным заключением и штрафами в соответствии с Computer Fraud and Abuse Act (18 U.S.C. § 1030) и аналогичными законами в других юрисдикциях.

Вы можете только использовать этот инструмент на:

Устройствах, которые лично вам принадлежат
Устройствах, на которые у вас есть явное письменное разрешение от владельца на проведение тестирования безопасности

Требования

Linux (протестировано на Ubuntu 20.04+)
Права root (требуются для bluetoothctl и низкоуровневого доступа к BLE)
Установленный и работающий bluetoothctl / BlueZ
Python 3.7+
Для этапов 2/3: l2flood с поддержкой OpenMP — см. kovmir/l2flood

Установка

Системные зависимости

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

Клонирование и установка

git clone https://github.com/Ymsniper/Whisper_Bully.git
cd Whisper_Bully
pip3 install -r requirements.txt
# Требуется только для этапов 2/3:
make
sudo make install

Использование

Этап 1: Извлечение BDADDR

# Автоматическое обнаружение и извлечение всех ближайших устройств Fast Pair
sudo python3 wb.py

# Сканирование 20 секунд, сохранение результатов
sudo python3 wb.py -s 20 -o targets.json

# Сканирование 30 секунд, пользовательский выходной файл
sudo python3 wb.py -s 30 -o extracted.json

Примечание: Если устройство ранее было подключено или сопряжено этим инструментом или вручную, BlueZ уже знает его идентификационный адрес. Сначала удалите его, чтобы извлечение прошло чисто:
sudo bluetoothctl remove <address>

Этап 2: L2CAP-флуд (опционально)

Способ 1 — Интерактивный (запрос после извлечения)

sudo python3 wb.py -s 20 -o targets.json
# По завершении: "Run aggressive L2CAP test... (yes/no)" → yes

Способ 2 — Флаги (пропуск запросов)

# Этап 1 + Этап 2 только
sudo python3 wb.py -s 20 -o targets.json --aggressive

# Этап 1 + Этап 2 + Этап 3
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack

# С указанием длительности и количества потоков
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 8

Способ 3 — Отдельный скрипт флуда

# Флуд из файла извлечённых целей в течение 120 секунд
sudo python3 aggressive_test.py -f targets.json -d 120 -t 4

# Флуд одного известного адреса в течение 60 секунд
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -d 60

# Бесконечный флуд (Ctrl+C для остановки)
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -f

Этап 3: Перехват (опционально)

# Интегрированный — извлечение, флуд, затем перехват
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120

# Ручной отдельный перехват по известному адресу
sudo python3 wb.py -H AA:BB:CC:DD:EE:FF

Полный трёхэтапный запуск (одной командой)

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

Порядок выполнения:

Сканирование 20 секунд для поиска устройств Fast Pair
Извлечение постоянного BDADDR для каждой цели
Флуд всех целей в течение 120 секунд с использованием 4 потоков
Мониторинг состояния без ответа
Попытка перехвата каждой цели в окне восстановления
Сохранение результатов в targets.json

Атака с несколькими адаптерами

# Терминал 1
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -i hci0 -d 120 -t 4 &

# Терминал 2
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -i hci1 -d 120 -t 4

Удваивает давление DoS и увеличивает вероятность успеха перехвата в окне восстановления.

Флаги командной строки

Технические детали

Этап 1 — Почему извлечение работает без взаимодействия с GATT

Сервисный UUID Fast Pair FE2C используется только как фильтр сканирования для идентификации потенциальных целей. После установки BLE-соединения:

Link Layer завершает рукопожатие соединения и отправляет хосту событие LL_CONNECTION_COMPLETE
BlueZ обрабатывает это событие и, если устройство использует разрешимый приватный адрес, преобразует его с помощью кэша IRK или просто регистрирует идентификационный адрес из параметров соединения
Идентификационный адрес кэшируется во внутренней таблице устройств BlueZ
bluetoothctl devices затем показывает как исходный RPA, так и только что зарегистрированный идентификационный адрес — одно и то же имя устройства, но другой адрес
Инструмент сравнивает с исходным RPA и возвращает новую запись как постоянный BDADDR

Вызов bluetoothctl pair, который выполняется параллельно, может завершиться успешно или нет — BDADDR обычно уже находится в таблице к моменту завершения или сбоя команды pair.

Этап 2 — Режим EMP (`l2flood -R`)

Эта модифицированная версия l2flood имеет два режима в зависимости от предполагаемого этапа:

Флаг -R — режим EMP (только DoS, без перехвата) Используется при запуске Этапа 2 отдельно без перехода к Этапу 3. Тихий режим «выстрелил и забыл» — все потоки синхронизируют свои циклы «подключение → всплеск → принудительное закрытие», чтобы гарантировать периодические полные разрывы ACL. Не выводит stdout в нормальном режиме работы.

Обычный режим (DoS + зондирование для перехвата) Используется, когда планируется Этап 3. Обычный режим был улучшен для автоматического выполнения переподключений и выводит no response from <addr>: id N, когда цель перестаёт отвечать — это сигнал, который wb.py отслеживает для запуска попытки перехвата.

Этап 3 — Почему связка сохраняется

Полученная связка — это не временное соединение, а полная SMP-связка, хранимая BlueZ:

bluetoothctl info <addr> показывает Paired: yes, Bonded: yes, Trusted: no
Связка переживает циклы bluetoothctl power off/on
Связка переживает перезагрузку машины атакующего (хранится в /var/lib/bluetooth/)
Устройство принимает последующие подключения от адаптера атакующего без повторного сопряжения

Известные ограничения

Этап 1

Требуется Linux с BlueZ / bluetoothctl
Цель не должна уже находиться в таблице устройств BlueZ под RPA (при необходимости удалите сначала)
Смена адреса в окне подключения может вызвать проблемы с синхронизацией — повторите попытку, если извлечение не удалось

Этап 2

Требуется знание постоянного адреса (с Этапа 1 или другим способом)
Цель должна быть включена и находиться в зоне действия
Устройство полностью восстанавливается после прекращения флуда — постоянного эффекта нет

Этап 3

Требуется, чтобы устройство вошло в состояние без ответа (зависимость от Этапа 2)
Успех зависит от времени — перехват должен произойти в окне восстановления
Не работает, если устройство выключается во время флуда

Устранение неполадок

Устройства не найдены

Проверьте, что bluetoothctl работает: sudo bluetoothctl list
Увеличьте время сканирования: -s 30

Ошибка подключения BLE / сбой извлечения

Сначала удалите устройство из BlueZ: sudo bluetoothctl remove <addr>
Повторите попытку — смена RPA может вызывать проблемы с синхронизацией

Флуд не оказывает эффекта

Увеличьте количество потоков: -t 16
Используйте несколько адаптеров одновременно
Убедитесь, что целью является постоянный адрес, а не RPA

Отказано в доступе

Запускайте с sudo
Убедитесь, что пользователь состоит в группе bluetooth, или запускайте от root

Ошибка импорта 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

Ошибки D-Bus

sudo systemctl start dbus && sudo systemctl start bluetooth

Благодарности

@kovmir за l2flood
KU Leuven COSIC за оригинальное исследование WhisperPair / CVE-2025-36911

Лицензия

MIT. Подробнее в LICENSE.

Отказ от ответственности

Этот инструмент предназначен только для авторизованного тестирования безопасности и оборонительных исследований. Несанкционированный доступ к Bluetooth-устройствам незаконен. Используйте только на устройствах, которые вам принадлежат или на которые у вас есть явное письменное разрешение на тестирование. Автор не несёт ответственности за несанкционированное или незаконное использование.

Используемый протокол	Fast Pair GATT KBP (запись UUID 1236)	Нет — только простое BLE-подключение
Путь утечки BDADDR	Зашифрованное уведомление KBP (BR/EDR адрес)	Преобразование RPA BlueZ при LL_CONNECTION_COMPLETE
Путь обхода аутентификации	Отсутствует проверка режима сопряжения FP	SMP Just Works во время окна восстановления стека BT
Исправлено патчем 36911?	Да	Нет
Работает на исправленных устройствах?	Нет	Да
CWE	CWE-287	CWE-200 (Stage 1) + CWE-362/CWE-287 (Stage 3)

`-s, --scan-time`	Длительность BLE-сканирования в секундах (по умолчанию: 10)
`-o, --output`	Сохранить извлечённые адреса в JSON-файл
`--aggressive`	Пропустить запросы, сразу запустить Этап 2 (требуется предварительное письменное разрешение)
`-H, --hijack`	Попытаться выполнить Этап 3 после Этапа 2 (требует `--aggressive` или интерактивного yes)
`-d, --duration`	Длительность флуда в секундах (по умолчанию: 60) или `f` для бесконечного
`-t, --threads`	Количество параллельных потоков L2CAP-флуда (по умолчанию: количество CPU)
`-i, --hci`	Используемый HCI-адаптер (например, `hci0`, `hci1`)

Whisper_Bully

Популярное