В марте маленькая платка внезапно оказалась в центре технологического скандала. Заголовки пестрили страшилками про «бэкдор» в «миллиардах устройств», и по новостям казалось, что хакеры вот-вот захватят все умные лампочки, термостаты и прочий IoT.

А потом... все как-то поутихло. Что же на самом деле нашли испанские исследователи в популярном микроконтроллере? Почему новость о «бэкдоре» разлетелась со скоростью лесного пожара? И главное — насколько реальна была угроза?

Давайте разберемся в этой запутанной истории, где переплелись технические исследования, PR-ходы, погоня за кликами и, конечно же, всеми любимые низкоуровневые протоколы. Поехали!

С чего все началось?

6 марта 2025 года специалисты по кибербезу — Мигель Тараско Акунья (Miguel Tarascó Acuña) и Антонио Васкес Бланко (Antonio Vázquez Blanco) — выступили на конференции RootedCON в Мадриде. Их доклад с безобидным названием «Attacking Bluetooth the Easy Way» был посвящен упрощению тестирования безопасности Bluetooth-устройств при помощи вездесущих микроконтроллеров ESP32.

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

Ситуация разгоняется как снежный ком. История попадает в десятки технических медиа, заголовки становятся все громче и мрачнее. Пока СМИ монетизируют новость, Мигель и Антонио выкладывают детали своего исследования в открытый доступ. Коллеги по цеху недоумевают и пишут, что никакого бэкдора в ESP32 нет и в помине. Только их никто не слышит.

8 марта уязвимость получает формальное подтверждение. В базе CVE появляется запись под номером CVE-2025-27840.

К 9 марта информационная волна докатывается до рунета, приобретая поистине апокалиптические масштабы: «Миллионы умных замков и других гаджетов под угрозой взлома», «Миллиард устройств под угрозой».

10 марта выходит официальный комментарий от Espressif. Компания старательно объясняет: никакой сенсации нет, это стандартный набор инженерных команд. К этому времени интерес журналистов угасает, и медиа переключаются на новые сенсации.

Волна схлынула, но осадочек остался. Потому что до конца так и не ясно, — что это, черт побери, вообще было?

Зачем исследовать ESP32?

Испанцы не просто так ковырялись в ESP32 — у них была проблема, которая тянулась с 2021 года. Тогда исследователи разрабатывали методологии для тестирования безопасности Bluetooth. Они быстро поняли, что большинство утилит устарели, другие требовали редкого и дорогостоящего оборудования, а третьи были привязаны к конкретной операционной системе. Тогда Мигель и Антонио решили: если готовых решений нет — создадим свое.

Исследователи искали платформу с прямым доступом к Bluetooth-контроллеру. Их выбор пал на ESP32 — микроконтроллер с поддержкой Bluetooth Classic и Low Energy, Wi-Fi (а иногда и ZigBee). Его доступность, поддержка open source (например, Espressif IDF) и возможность работы с HCI решали все их проблемы.

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

Архитектура Bluetooth

Стандарт Bluetooth имеет двухкомпонентную архитектуру. Хост и контроллер обмениваются данными через Host Controller Interface (HCI). Такое разделение обеспечивает гибкость и стандартизацию разработки.

Хост — это программная часть, которая отвечает за высокоуровневую логику: обработку профилей (например, передачу аудио по A2DP), обеспечение безопасности (аутентификация, шифрование). А контроллер напрямую взаимодействует с радиочастотной частью. Это отдельный чип в составе Bluetooth-модуля, который реализует физический уровень связи и базовые протоколы: устанавливает соединение и обрабатывает пакеты. Благодаря HCI-интерфейсу хост и контроллер могут взаимодействовать, даже если их выпустили разные производители.

Микроконтроллер ESP32 поддерживает две конфигурации работы с Bluetooth. В первой хост-приложение работает прямо на ESP32 и общается с контроллером через виртуальный HCI-интерфейс. Во второй — ESP32 используется только как контроллер, а хост работает на внешнем устройстве, например, на ПК, и управляет Bluetooth через UART. Испанцы хотели реализовать управление по второй схеме, чтобы делать с контроллером все, что придет им в голову.

Подготовка к исследованию

Хотя разработчик ESP не раскрывает полный исходный код контроллера, компания Espressif предоставляет достаточно материалов для анализа. В официальном репозитории Мигель и Антонио нашли ROM-файлы в ELF-формате — скомпилированные образы базовых функций загрузчика и драйверов. Также в их распоряжении были библиотеки Bluetooth-стека из репозитория esp32-bt-lib и драйверы физического уровня из esp-phy-lib.

Чтобы не заниматься анализом каждой библиотеки по отдельности, инженеры объединили все компоненты в единый файл, назвав его «золотым бинарником». Такой подход позволил смотреть на код как на единое целое, и заметно упростил анализ.

Команда не ограничилась простым объединением файлов. Они разработали специальные плагины для Ghidra. Один импортировал информацию из скриптов компоновщика Espressif с адресами функций. Благодаря этому плагину удалось автоматически присвоить имена множеству функций, вместо того чтобы тратить время на ручную идентификацию.

Другой плагин работал с SVD-файлами (System View Description) — стандартизированными XML-описаниями периферийных устройств. С их помощью исследователи определили назначение регистров управления.

Разработка BluetoothUSB

Чтобы напрямую управлять контроллером Bluetooth, исследователи начали разработку собственного ПО. Получился комплект из специальной прошивки для ESP32 и управляющей программы, который разработчики назвали BluetoothUSB.

Эта штука одинаково хорошо работает под Windows, Linux и macOS, поскольку вся логика контроллера находится на ESP32, однако в процессе отладки BluetoothUSB обнаружилось нечто странное.

Открытие: подозрительное ядро

Исследователи наткнулись на функцию RWIP_INIT — первый признак нестандартной архитектуры ESP32. Префикс RW в этой и других функциях намекал на связь с кодом RivieraWaves — создателя IP-библиотек для Bluetooth, которую впоследствии купила компания CEVA. Копнув глубже, специалисты выяснили, что ESP32 построен на двухкомпонентной архитектуре: основное ядро с FreeRTOS и дополнительное проприетарное ядро для Bluetooth.

Исследуя содержимое функции RWIP_INIT, испанцы обнаружили вызов инициализации транспортного слоя H4 — раннего варианта протокола HCI из спецификации Bluetooth. При детальном анализе функции r_h4tl_init они нашли код, отвечающий за регистрацию обработчиков HCI-пакетов.

Путь к обнаружению скрытых команд

Анализ выявил: протокол HCI на ESP32 следует стандартному формату. Пакеты всегда начинаются с однобайтового заголовка, который указывает тип данных — 0x01 для команд и 0x04 для событий. 

За заголовком идет код операции (2 байта) и поле длины (1 байт).

Код операции делится на две части: OGF (Opcode Group Field) классифицирует команду, а OCF (Opcode Command Field) определяет конкретную функцию внутри группы.

Мигель и Антонио обратили внимание на функцию r_ke_evt_h4_rx_hdr_cb, которая активируется при получении заголовка HCI-пакета:

(*r_modules_funcs_p->r_ke_event_callback_set)(KE_EVT_H4_RX_HDR, r_ke_evt_h4_rx_hdr_cb);

Эта функция обращается к таблице команд HCI, структурированной по полю OGF. Каждая запись таблицы содержит группу команд, служебную информацию и указатель на подтаблицу с конкретными командами.

Последняя запись здесь относится к группе OGF 0x3F. По стандарту Bluetooth этот диапазон зарезервирован для проприетарных команд производителя.

В этой группе исследователи обнаружили 29 недокументированных команд, предоставляющих широкие возможности для манипуляции чипом.

Команды, которые могут все

Найденные команды открывают широкие возможности: чтение и запись данных в память устройства, изменение MAC-адреса, управление флеш-памятью и, что особенно ценно, прямой обмен низкоуровневыми пакетами протоколов LMP и LLCP.

Исследователи пошли дальше теоретического анализа. Они детально изучили каждую команду: определили форматы входных параметров, разобрали выполняемые действия и структуру выходных данных и подтвердили их работоспособность на реальном оборудовании. Например:

Подмена MAC-адреса

HCI_ESP32_CMD_SET_MAC позволяет изменять значение MAC-адреса. Это открывает несколько потенциальных векторов атаки: скрытие от систем отслеживания, маскировка действий злоумышленника под легитимную активность другого устройства и проведение MITM-атак для перехвата или подмены данных.

Отправка команды на чтение памяти

На Хабре уже есть хорошая статья об алгоритме обработки команды Read Memory для STM32F. Механизм работы аналогичной команды в ESP32 оказался похожим — HCI_ESP32_CMD_READ_MEM (0x01) предоставляет прямой доступ к памяти контроллера.

Потенциальный вектор атак включает извлечение учетных данных WiFi, ключей шифрования и Bluetooth-ключей сопряжения. Стандартная защита — необходимость прав администратора для таких операций. Но злоумышленник может обойти это ограничение, отправив HCI-команды напрямую Bluetooth-контроллеру. Например, инициировав подключение к целевому устройству (скажем, наушникам), он может перехватить чувствительные данные из памяти.

Отправка команды на запись в память

С помощью команды HCI_ESP32_CMD_WRITE_MEM у злоумышленника появляется возможность записывать значения в произвольные области памяти. 

Эксплуатация этой команды открывает целый арсенал возможностей. Злоумышленник может отправить произвольный код на выполнение через r_hci_cmd_received и захватить полный контроль над устройством.

Уязвимость также позволяет читать зашифрованные участки flash-памяти — как напрямую через esp_flash_read() для получения сырых данных, так и через esp_flash_read_encrypted() — для доступа к расшифрованному содержимому.

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

Особенно опасно то, что вредоносный код может сохраняться в памяти даже после перезагрузки. Например, через esp_flash_write() злоумышленник может модифицировать функцию app_main, которая выполняется при включении устройства.

Эти и другие недокументированные HCI-команды в ESP32 были официально зарегистрированы под номером CVE-2025-27840. Казалось бы, вот он — настоящий бэкдор! Но не так все просто.

Уязвимости затрагивают только оригинальную ESP32, работающую во втором режиме, как контроллер под управлением внешнего хоста. Причем, чтобы воспользоваться этими командами, их нужно как-то отправить на ESP32. А это можно сделать, только если у вас есть физический доступ к USB/UART интерфейсам платы или root-доступ к ее операционной системе.

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

Espressif в итоге признала наличие недокументированных команд и все же обещает убрать их в будущих прошивках. Хотя, если честно, в этой практике нет ничего необычного. Спойлер: так делают практически все вендоры от Broadcom до Texas Instruments.

Одно слово, которое всколыхнуло индустрию

Важный момент: на слайдах из презентации исследователей не упоминается «бэкдор». Скорее всего, не было этого слова и в самом докладе. Этот термин всплыл только в пресс-релизе на сайте Tarlogic — компании, на которую они работают. Испанцы быстро это заметили и поправили формулировку, заменив громкое «backdoor» на более аккуратное «hidden feature» (скрытая функция). Но было уже поздно — новость разлетелась по интернету, и понеслась…

Из-за одного неудачно выбранного слова исследователи прославились как первооткрыватели бэкдора, которого на самом деле не было. Они просто хотели хакнуть ESP32, а в итоге протестировали медиасферу на доверчивость. Журналисты наделали ошибок, но наверняка неплохо заработали на трафике от сенсационных новостей. А настоящими проигравшими оказались обычные читатели — те, кто привык доверять громким заголовкам.

Так что в следующий раз, когда увидите новость о «критической уязвимости», которая «угрожает миллиардам» — глубоко вдохните, прочитайте первоисточник и разберитесь. Либо дождитесь, пока шум уляжется. Технические проблемы редко бывают такими страшными, какими их рисуют СМИ в первые дни после обнаружения. А вендоры... они продолжат делать то, что делали всегда — хранить инженерные секреты подальше от документации. Ведь так поступает вся индустрия, и ESP32 не исключение.