Троян в твоих ушах: как угнать WhatsApp и Amazon через беспроводные наушники

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

Речь о незащищённом сервисном интерфейсе, через который любой человек в радиусе действия Bluetooth может вытащить из чужих наушников криптографические ключи, клонировать устройство и получить контроль над звонками. И всё это без спаривания, вводов PIN‑кода и какой‑либо аутентификации. В итоге исследователи довели цепочку атаки до угона WhatsApp-аккаунтов. Уязвимость затронула устройства Sony, Marshall, JBL, Jabra, Beyerdynamic, Teufel и множество клонов AirPods.

Давайте разберемся, как реверс-инжиниринг утилиты обновления прошивки привёл к компрометации целой экосистемы Bluetooth-аудио, и почему ваша безопасность зависит от лени OEM-интеграторов.

Содержание статьи

• Искали медь, а нашли золото

  • Сюрпризы в прошивке

  • «Хирургическая операция» и сопоставление чипов

• Android как Розеттский камень

  • Попытки эксплуатации протокола RACE и Bumble

• Grand Theft Headphones

  • Кража Link Key и угон аккаунта

  • Прослушка: микрофон как оружие

• Угон WhatsApp

• Экосистема безответственности

• Заключение

  • Инструментарий: проверь себя сам

  • Как защититься

Искали медь, а нашли золото

Для справки: Auracast — фича стандарта Bluetooth LE Audio, реализующая широковещательную трансляцию звука, с ее помощью один передатчик может транслировать аудио на неограниченное число приёмников. Это что-то вроде радио для конференц-залов или аэропортов. Технология полезная, но что насчет безопасности?

Сюрпризы в прошивке

Для начала исследователи Фридер Штайнмец и Деннис Хайнц вдоль и поперёк изучили спецификацию Auracast и нашли лишь пару теоретических шероховатостей, однако их интересовали особенности реализации технологии в конкретном железе.

На рынке не так много устройств с поддержкой Auracast, но исследователям удалось приобрести трансмиттер MoerLab Auracast, умеющий бродкастить аудио, и пару совместимых наушников. Купили, распаковали и сразу решили реверсить: проанализировать прошивку через Ghidra и посмотреть, как она работает.

На сайте производителя трансмиттера лежал файл обновления прошивки. Наши герои скачали файл, открыли его в hex‑редакторе и увидели бинарный блоб. Структура в нём угадывалась, заголовки просматривались, но без ключа к формату двигаться дальше было невозможно.

Зато вендор предлагал Windows‑утилиту для настройки трансмиттера. Подключаете устройство по USB, запускаете софт, и он позволяет менять имя потока Auracast и частоту дискретизации, ставить пароли и обновлять прошивку. Соответственно, где‑то внутри этой утилиты должен быть ключ к расшифровке прошивки. Поэтому исследователи запустили Wireshark и начали сниффить USB‑трафик между утилитой и трансмиттером.

Весь обмен шёл через USB HID (Human Interface Device). Вообще HID придуман для клавиатур и мышек, но разработчики железа любят его по другой причине: для этого стандарта не нужно писать и подписывать драйверы. Поэтому через HID часто гоняют проприетарные протоколы.

Анализ дампов показал два момента.

• Во‑первых, пакеты с настройками содержали читаемый текст — протокол, скорее всего, не зашифрован.

  

• Во‑вторых, пакеты обновления прошивки включали куски того самого бинарного файла: утилита просто нарезала его на чанки и отправляла в HID‑репортах. Но как устройство понимает, куда писать эти куски?

  

В каждом пакете обновления исследователи заметили поле, значение которого монотонно возрастало. Сперва они подумали, что это счётчик пакетов. Только вот незадача — цифры не начинались с нуля, а шаг не равнялся единице. Тогда исследователи сопоставили значения с файлом прошивки, и разница между соседними значениями идеально совпала со смещением данных в бинарнике. Словом, это был не счётчик, а адрес памяти во флеше. Утилита диктовала контроллеру: «Возьми этот кусок данных и положи его по адресу 0xABC».

Разобравшись с адресацией, исследователи стали искать идентификатор команды (OpCode). Сравнивая пакеты конфигурации с пакетами прошивки, они выделили двухбайтовое поле — неизменное в рамках одной операции, но отличавшееся от действия к действию. Для прошивки это было значение 02 04. Зная, что речь идёт об архитектуре ARM с порядком байтов Little Endian, они перевернули его и получили 0×0402.

Тут помог случай. Ресерч в интернете по сигнатурам прошивки привел к репозиторию airoha‑firmware‑parser на GitHub, где энтузиасты уже написали распаковщик для прошивок чипов Airoha. Исследователи скачали его, распаковали блоб, получили чистый бинарный код и загрузили в дизассемблер Ghidra.

switch(cmd_id) {
    case 0x400:
        pvVar3 = FUN_0838bad4(&inputMsg->hdr,length,transport_id);
        return pvVar3;
    case 0x402:
        pvVar3 = cmd_write_flash(&inputMsg->hdr,length,transport_id);
        return pvVar3;
    case 0x403:
        pvVar3 = FUN_0838b920(&inputMsg->hdr,length,transport_id);
        return pvVar3;
    case 0x404:
        pvVar3 = FUN_0838b994(&inputMsg->hdr,length,transport_id);
        return pvVar3;
}

Теперь можно было сопоставить наблюдения из Wireshark с реальным кодом. В прошивке нашлась таблица обработчиков команд — аккуратный switch‑case. Функция по коду 0×0402 принимала адрес, размер данных и сами данные, а затем вызывала драйвер флеш‑памяти для записи. Но самое интересное было прямо под ней в том же switch‑case: функция с похожей сигнатурой, которая делала ровно противоположное — читала данные из памяти и отправляла обратно.

Исследователи быстро набросали скрипт на Python, который эмулировал поведение Windows‑утилиты, но вместо команды записи отправлял команду чтения, и устройство послушно, байт за байтом, отдало всё содержимое своей флеш‑памяти. В этот момент Штайнмец и Хайнц окончательно забыли про Auracast.

«Хирургическая операция» и сопоставление чипов

Они вскрыли наушники с трансмиттером и изучили маркировку чипов. Это оказался SoC от компании Airoha, тайваньский вендор, чьи Bluetooth Audio SoC стоят в устройствах от премиальных Sony, Marshall, JBL и аудиофильских Beyerdynamic до множества реплик AirPods.

Оставалось понять, какие именно наушники построены на чипах Airoha. Исследователи занялись пассивной разведкой: изучали отчёты Федеральной комиссии по связи США (FCC), где публикуются фотографии плат устройств, и анализировали сайт 52audio.com, специализирующийся на разборах аудиотехники. По фотографиям чипов они составили список и бросились скупать наушники, чтобы оценить масштаб проблемы. И тут их ждало разочарование: ни одни из купленных наушников не определялись компьютером как USB‑устройство. USB‑порт в них использовался исключительно для зарядки. Скрипт для дампа флеша стал бесполезен, но идея была слишком заманчивой, чтобы махнуть на нее рукой. В конце концов эти наушники тоже обновляются — только через мобильные приложения‑компаньоны.

Android как Розеттский камень

Исследователи скачали приложения, декомпилировали их (благо Java‑байткод Android не славится обфускацией) и начали искать знакомые паттерны.

Вскоре выяснилось, что здесь для обновлений используется тот же протокол, работающий поверх Bluetooth. Нашлись имена для многих команд и имя самого протокола — RACE. Увы, исследователи таки и не выяснили, что стоит за этой аббревиатурой.

Протокол оказался транспортно‑агностическим. В трансмиттере байты RACE заворачивались в USB HID. Bluetooth‑наушники использовали RFCOMM (эмуляция последовательного порта) для Classic и GATT (система характеристик с сервисами и UUID) для BLE.

Попытки эксплуатации протокола RACE и Bumble

Исследователи отреверсили множество обработчиков команд RACE и составили карту возможностей протокола: чтение флеш‑памяти, ограниченная запись, чтение и запись оперативной памяти, обновление прошивки, запрос адреса Bluetooth Classic. Дело в том, что команды RACE позволяют читать и писать по любому адресу во всём адресном пространстве (memory map) чипа ARM Cortex‑M4. Оно включает не только оперативную память, но и регистры ввода‑вывода (MMIO), через которые управляется периферия. 

Теоретически это открывает путь к исполнению произвольного кода — например, созданию самораспространяющегося червя, но на практике для этого есть несколько барьеров.

• Во‑первых, встроенные команды RACE и так дают злоумышленнику полный контроль над устройством, что делает инжекцию кода избыточной.

• Во‑вторых, команда записи во флеш‑память жёстко ограничена — писать можно только в раздел обновления прошивки. Чтобы внедрить червя перманентно, атакующему придётся добыть ключи шифрования прошивки, собрать валидный файл обновления и инициировать процесс апдейта, который занимает от 3 до 5 минут по Bluetooth Classic (и ещё дольше по BLE). В полевых условиях это крайне непрактично.

Затем исследователи написали транспортно‑агностический инструмент для дампа флеша на Python с использованием Bumble — Bluetooth‑библиотеки от Google. Инструмент поддерживал USB, RFCOMM и GATT.

COMMON_SPP_UUID = UUID("00001101-0000-1000-8000-00805F9B34FB")
AIROHA_SPP_UUID = UUID("00000000-0000-0000-0099-AABBCCDDEEFF")
SONY_SPP_UUID = UUID("8901DFA8-5C7E-4D8F-9F0C-C2B70683F5F0")
BOSE_SPP_UUID = UUID("2D064AA9-32B5-4970-865C-643742BD2862")
BEYER_SPP_UUID = UUID("7B46E8DE-5A7E-4512-BE0D-863AEAA3312B")

UUID стандартного SPP-сервиса и сервисов разных производителей, используемых для подключения через RFCOMM.

AIROHA_GATT_SERVICE_UUID = UUID("5052494D-2DAB-0341-6972-6F6861424C45")
AIROHA_GATT_TX_UUID = UUID("43484152-2DAB-3241-6972-6F6861424C45")
AIROHA_GATT_RX_UUID = UUID("43484152-2DAB-3141-6972-6F6861424C45")
SONY_GATT_SERVICE_UUID = UUID("dc405470-a351-4a59-97d8-2e2e3b207fbb")
SONY_GATT_TX_UUID = UUID("bfd869fa-a3f2-4c2f-bcff-3eb1ec80cead")
SONY_GATT_RX_UUID = UUID("2a6b6575-faf6-418c-923f-ccd63a56d955")

UUID сервисов и характеристик Airoha и Sony для обмена данными через GATT.

Для демонстрации атак через HFP (управление звонками) исследователи отдельно использовали BTstack — Bluetooth Host Stack на C, поскольку Python‑скрипты на базе Bumble не обеспечивали нужной стабильности аудиосоединений.

Оставался открытым вопрос аутентификации. Во время всех тестов исследователи ставили наушники в режим спаривания и подключали их к ноутбуку, но в какой‑то момент выяснилось, что для подключения по RACE спаривание не требуется. Они подключились к наушникам без спаривания, отправили команду Get Version, и наушники ответили. Далее отправили команду чтения RAM — наушники послушно вернули дамп памяти.

Здесь кроется ещё одна угроза — деанонимизация. В BLE используются постоянно меняющиеся MAC‑адреса (Resolvable Private Addresses), чтобы устройство нельзя было физически отслеживать, однако команда RACE Get BD_ADDR (0×0CD5) выдаёт статичный MAC‑адрес Bluetooth Classic. Злоумышленник может тихо подключаться к наушникам по BLE, запрашивать этот адрес и использовать его для отслеживания перемещений владельца или как отправную точку для основной атаки с кражей Link Key.

Grand Theft Headphones

Что ж, в теории можно было подслушать, какой трек сейчас играет в наушниках. Любопытно, но годится разве что для составления психологического портрета слушателя по музыкальным предпочтениям. Для серьезной атаки требовался доступ к постоянной Flash‑памяти, где хранится кое‑что по‑настоящему ценное.

Кража Link Key и угон аккаунта 

В начале флеш‑памяти лежит таблица разделов. Один из них — NVDM (Non‑Volatile Data Management), конфигурационное хранилище устройства. По сути это key‑value store, оптимизированный для флеш‑памяти (с wear‑leveling и прочими механизмами защиты от износа). Здесь хранится всё, что должно пережить перезагрузку: имя устройства, громкость, эквалайзер и данные о сопряжении.

В Bluetooth Classic сопряжение (Pairing) завершается генерацией общего секрета — Link Key, который создаётся протоколом управления соединениями (LMP) и лежит в основе аутентификации и шифрования. В BLE за сопряжение отвечает другой механизм (Security Manager Protocol) с собственным набором ключей, но в контексте этой атаки речь идёт именно о Classic. Атакующий может притвориться одним из устройств при наличии его Bluetooth‑адреса и Link Key. (Spoofing). Второе устройство примет соединение без вопросов.

Исследователи начали разбирать структуру NVDM. Внутри обнаружилась таблица соединений (connection table): для каждого сопряжённого устройства там хранились Bluetooth‑адрес, Link Key и связанные метаданные в открытом виде. Бинго! Оставалось их только извлечь.

Для этого Штайнмец и Хайнц написали ещё один Python‑скрипт, который сканирует BLE‑эфир, фильтрует устройства по характерным признакам (чтобы не цеплять телефоны и другие гаджеты поблизости) и подключается через GATT. Подключение не прерывает аудиопоток — жертва продолжает слушать музыку и ничего не замечает.

Скрипт читает таблицу разделов из начала флеша, находит раздел NVDM (обычно Partition 6), выкачивает его блок за блоком, парсит бинарную структуру на лету и извлекает Link Key. На выходе атакующий получает Bluetooth‑адрес телефона жертвы и соответствующий криптографический ключ.

Link Key — не пароль, который можно сбросить. Это общий криптографический секрет двух устройств. Пока владелец не удалит сопряжение (Forget Device) на телефоне, ключ остаётся валидным.

Имея Link Key, атакующий может клонировать наушники. Для этого нужно взять Bluetooth‑адаптер с возможностью смены адреса (например, на чипе CSR), подменить его на адрес наушников жертвы и передать украденный Link Key в Bluetooth‑стек. Теперь телефон жертвы принимает соединение, считая, что к нему подключились родные наушники. Никаких всплывающих окон или вводов PIN‑кодов.

После подключения атакующий получает доступ к профилю HFP (Hands‑Free Profile). Это не просто способ говорить по телефону за рулём, как думают некоторые. Спецификация Bluetooth SIG закладывает в этот профиль куда больше: HFP‑устройство может принимать и отклонять звонки, набирать номера, получать информацию о звонящем, узнавать имя оператора и запускать голосовых ассистентов. Таким образом, атакующий получает все эти возможности. Телефонная книга тоже доступна, но в ограниченном виде: контакты подтягиваются через нестандартные AT‑команды и требуют отдельных разрешений.

Но самая интересная опция — запрос номера абонента (Subscriber Number). Гарнитура может запросить у телефона номер владельца, и большинство смартфонов отдают эту информацию без дополнительной авторизации.

HFP не даёт доступа к SMS, поэтому обойти SMS‑based 2FA этим путём не получится. Зато атакующие могут принимать входящие звонки — а значит, сервисы с верификацией по звонку уязвимы.

Прослушка

Кража Link Key и угон аккаунтов — не единственный вектор атаки. Исследователи отдельно выделяют прослушку, которая не требует сложных цепочек и работает напрямую.

Прослушка через микрофон наушников. Злоумышленник подключается к наушникам по Bluetooth Classic и через профиль HFP активирует микрофон. После этого он слышит всё, что происходит вокруг жертвы, — разговоры, совещания, звонки.

Прослушка через микрофон телефона. Если злоумышленник уже клонировал наушники, он может пойти дальше: инициировать звонок на подконтрольный ему номер, а затем разорвать Bluetooth‑аудиосоединение. На телефоне жертвы останется активный звонок, который транслирует звук через встроенный микрофон телефона напрямую злоумышленнику.

Оба сценария не оставляют видимых следов на экране, если телефон заблокирован.

Угон WhatsApp

Цепочка атаки выглядит так:

• скрипт запрашивает у телефона номер абонента — мобильное устройство отвечает номером жертвы;

• атакующий вводит этот номер в WhatsApp на своём устройстве;

• мессенджер просит код подтверждения — атакующий дожидается тайм‑аута и выбирает опцию «Позвонить мне» (Call Me);

• когда звонок от робота WhatsApp поступает на телефон жертвы, скрипт непрерывно шлёт команду принятия вызова через HFP;

• вызов принимается быстрее, чем телефон успевает завибрировать;

• робот диктует атакующему код — остается ввести его и получить контроль над миром аккаунтом.

Исследователи планировали провести этот этап вживую на 39C3, но демо сорвалось: кто‑то из зрителей позвонил на телефон жертвы в самый ответственный момент. Спикерам пришлось переключиться на предзаписанное видео.

На экране телефона жертвы остаются уведомления от WhatsApp: запрос кода и сообщение о перерегистрации аккаунта на другом устройстве. Атака заметна, но работает, если жертва не смотрит на телефон.

На демо исследователи показали и следующий шаг: они вошли в Amazon‑аккаунт Денниса, используя украденный номер телефона и получив код подтверждения через WhatsApp. И тут полная цепочка сложилась: наушники → Link Key → клонирование → HFP → номер телефона → WhatsApp → Amazon.

Экосистема безответственности

По итогам описанного тестирования исследователи подтвердили уязвимость на устройствах Sony, Marshall, Jabra, JBL, Beyerdynamic и Teufel, а также на многочисленных репликах AirPods. Всего исследователи выделили три CVE: 

• CVE-2025-20700 (отсутствие аутентификации в GATT/BLE); 

• CVE-2025-20701 (отсутствие аутентификации в Bluetooth Classic); 

• CVE-2025-20702 (критические возможности протокола RACE) 

Не все проверенные устройства были подвержены сразу трём уязвимостям, например, Jabra Elite 8 Active оказались частично защищены: BLE‑сервис GATT был отключён, а для Bluetooth Classic принудительно требовалось спаривание. Однако протокол RACE оставался доступен, и Jabra выпустила патчи с упоминанием всех трёх CVE.

Кому же жаловаться?

Проблема экосистемы Airoha (как и ODM‑производства в целом) — размытая ответственность. Airoha производит чип и SDK. OEM‑фабрики берут SDK и адаптируют прошивку под конкретное железо. Бренды клеят логотип и продают конечный продукт. До некоторых брендов можно достучаться, но охватить всех OEM нереально.

Самое очевидное решение — идти наверх, к Airoha напрямую. Их политика раскрытия уязвимостей выглядела образцово: ответ в течение 3–5 рабочих дней, коммуникация с OEM и downstream‑вендорами, патч за 90 дней. Был PGP‑ключ и выделенный email. Исследователи отправили технический отчёт и список затронутых устройств... и получили месяц полного игнора. Отправка писем на разные адреса и попытки найти контактные формы не принесли никаких результатов.

Тогда исследователи предупредили Airoha, что начнут связываться с вендорами напрямую, и написали в Sony, Marshall и Beyerdynamic. Sony и Marshall также проигнорировали обращения. Beyerdynamic, напротив, ответила оперативно — компания готовилась к вступлению в силу EU Cyber Resilience Act (CRA) и была заинтересована в коммуникации с исследователями. Sony же отреагировала, только узнав о планах исследователей выступить на конференции Troopers. и предложила провести CVE через программу HackerOne. Ее условия включали NDA и передачу прав на уязвимость, так что исследователи отказались.

Спустя еще месяц отозвалась и Airoha. Выяснилось, что у компании была «маленькая техническая неувязка» с email‑инфраструктурой: сначала они не получали писем, потом их ответы не доходили обратно.  

Как только связь наладилась, работа пошла гладко. За две недели Airoha выпустила патч и разослала обновлённый SDK всем клиентам. Но спустя четыре недели после этого ни один downstream‑вендор не выпустил обновление для конечных пользователей.

Первичный репорт в Airoha был отправлен 25 марта 2025 года. Через 93 дня — 26 июня 2025 года — исследователи провели частичное раскрытие на конференции Troopers, без технических деталей, чтобы не подставлять пользователей. Полное раскрытие со всеми подробностями состоялось только 27 декабря 2025 года на 39C3 — то есть индустрия знала о проблеме минимум девять месяцев.

Вот что произошло за полгода, прошедших с момента частичного раскрытия до доклада на 39C3:

• Jabra — исправила все три CVE и сама распространила патч (затронуто более пяти моделей).

• Beyerdynamic и Marshall — выпустили обновления с явным упоминанием найденных проблем.

• Teufel — сделал несколько «тихих исправлений» без упоминания CVE. Исследователи предполагают, что они связаны с их находками, но официальных подтверждений не получили.

• По Sony ситуация неоднозначная: компания вышла на связь только после анонса публичного раскрытия и предложила работать через HackerOne с NDA, от чего, как уже упоминалось, исследователи отказались. Известно, что некоторые устройства получили частичные исправления, но подтвердить полноту патчей невозможно.

Типичная ситуация для IoT‑безопасности: производитель чипа кивает на вендора, OEM‑фабрика — на бренд, а последний — на сложность процесса. Пользователь остаётся один на один с уязвимым устройством.

Заключение

Что мы имеем в сухом остатке? Исследование началось с рядового аудита Auracast, а привело к обнаружению открытого сервисного интерфейса в чипах Airoha, через который можно дистанционно извлечь криптографические ключи из наушников и получить контроль над голосовым каналом телефона жертвы.

Инструментарий: проверь себя сам

Исследователи придерживаются принципов ответственного раскрытия (Responsible Disclosure) и не публикуют готовые эксплойты. Вместо этого на GitHub выложен RACE Toolkit — набор инструментов на Python для взаимодействия с устройствами по протоколу RACE через BLE GATT, Bluetooth Classic RFCOMM и USB HID:

• Сканер уязвимостей — находит устройства Airoha в эфире и отправляет безобидную команду через интерфейс RACE. Если наушники ответили — они уязвимы. Проверка покрывает все три CVE: CVE-2025-20700, CVE-2025-20701 и CVE-2025-20702. Если сканер сообщает об уязвимости устройства, то это достоверный результат. Но отрицательный ответ не гарантирует безопасность: исследователи отмечают, что автоматизировать проверку сложно из‑за множества технических нюансов, и на некоторых устройствах уязвимость проявляется не при каждой попытке.

• Инструмент обновления прошивки (FOTA) — для устройств Sony можно скачать прошивки и установить обновление.

• Распаковщик и модификатор прошивок — на стадии эксперимента (в процессе разработки исследователи «окирпичили» два устройства).

• Дамп памяти — чтение и запись RAM, дамп флеш‑памяти и отдельных разделов.

• Документация для дальнейших исследований.

В блог‑посте и White Paper также описан простой метод проверки через мобильное приложение — можно проверить BLE‑часть без специального оборудования.

Как защититься

• Обновите прошивку наушников. Jabra, Beyerdynamic и Marshall уже давно выпустили полноценные патчи, Sony — частичные. Проверьте приложение‑компаньон вашего устройства.

• Удалите неиспользуемые сопряжения. Каждое из них хранит Link Key и является потенциальным вектором атаки на ваш смартфон.

• Если вы высокоприоритетная цель (журналист, дипломат, политик) — используйте проводные наушники.

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

Ваши наушники знают ключи от вашего телефона. Вопрос в том, кто ещё их узнает?