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

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

Низкоуровневые API, наоборот, дают доступ к более глубоким слоям Bluetooth-стека, но их реализация зависит от операционной системы. В Linux — BlueZ, в macOS — CoreBluetooth, а в Windows — проприетарный стек. И все они несовместимы друг с другом, и вдобавок модифицируют входные данные под спецификации стандарта. Это значит, что нестандартные пакеты или недокументированные функции часто блокируются на уровне API. Да и вообще, одни и те же операции (сканирование устройств, анализ трафика) могут давать разные результаты на разных платформах.

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

Исследователи искали платформу с прямым доступом к 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 с адресами функций. Благодаря этому плагину удалось автоматически присвоить имена множеству функций, вместо того чтобы тратить время на ручную идентификацию.

Фрагмент Python-кода, который демонстрирует использование библиотеки Scapy для взаимодействия с Bluetooth через USB-интерфейс

Другой плагин работал с 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 для событий.

0X01	Команда
0X04	Событие

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

Opcode	Length
2 bytes	1 byte

Код операции делится на две части: 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. Каждая запись таблицы содержит группу команд, служебную информацию и указатель на подтаблицу с конкретными командами.

Таблица hci_cmd_desc_root_tab, которая содержит ссылки на подтаблицы различных групп команд HCI

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

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

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

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

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

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

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

Команда	OCF	Параметры команды	Ответ
HCI_ESP32_CMD_SET_MAC	0x32	Bd_Addr	Status

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

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

Команда

OCF

Параметры команды

Ответ

HCI_ESP32_CMD_READ_MEM

0x01

Start_Address

Access_Size

Length

Status

Length

Data

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

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

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

Команда

OCF

Параметры команды

Ответ

HCI_ESP32_CMD_WRITE_MEM

0x02

Start_Address

Access_Size

Length

Data

Status

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

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

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

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

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

Неужели бэкдор мог получить такой низкий score?

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

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

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

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

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

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

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

PURP — телеграм-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона

Frontender`s Spectre

[Yandex for Frontend] Интерфейсы будущего / Полукруглый стол

Как найти и потерять бэкдор в ESP32