В своём предыдущем посте я рассказывал о реверс-инжиниринге прошивки моего нового Creative Sound Blaster Katana V2X.

То, что начиналось как попытка написать Linux-инструмент для общения с саундбаром, закончилось обнаружением уязвимостей, позволяющих любому нападающему в радиусе примерно 15 метров от Katana V2X превратить его в шпионское устройство и Rubber Ducky без необходимости сопряжения или физического контакта с оборудованием.

Введение в CTprotocol

Katana V2X — это подключаемый по USB саундбар для PC. Creative разработала приложение, позволяющее менять параметры устройства — DSP, конфигурацию светодиодов, источник вывода и так далее.

Для этого оно использует собственный протокол под названием CTP (подозреваю, что это расшифровывается как Creative Transport Protocol). По сути, он кажется довольно простым проприетарным протоколом для отправки различных команд и считывания ответов на них. Я не буду здесь вдаваться в подробности, но если вам любопытно, то описание его работы я привёл в предыдущем посте.

Однако важно отметить, что прежде чем выполнять любые действия с CTP через USB, необходимо сначала произвести с устройством аутентификацию «запрос-ответ». Ключ статический и его можно извлечь из двоичных файлов, поставляемых с Creative App; не знаю, зачем это вообще нужно, но саундбар не будет принимать никаких команд, пока не выполнена аутентификация. Ну да ладно.

Ещё один аспект, который станет важным позже, заключается в том, что обновления прошивок тоже происходят через CTP. Именно так я изначально и получил образ прошивки — прослушкой USB-трафика при помощи Wireshark и извлечением данных из перехваченной информации.

Анализ прошивки

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

Во-первых, в нём есть FBOOT, который я изначально посчитал загрузчиком (bootloader), но также он содержит своего рода режим восстановления для саундбара. В этот режим восстановления можно попасть, удерживая кнопку SOURCE при включении питания устройства. Он позволяет восстановиться из сбойного состояния и много раз спасал моё устройство от «окирпичивания», за что я ему крайне благодарен.

Вторая часть — это FMAIN, то есть основная прошивка устройства. Она запускается при «нормальном» запуске устройства. FBOOT во многом реализует ту же функциональность, что и FMAIN (например, оба могут обрабатывать команды CTP), однако FMAIN примерно в 6,5 раза больше, чем FBOOT.

И FBOOT, и FMAIN основаны на версии FreeRTOS (достаточно сильно модифицированной), что можно понять из присутствующей в двоичных файлах строки: /home/jieyi/mcuos2.5/kernel/freertos-8.2.3/.

Последняя важная часть — это CHK2: контрольная сумма SHA-256 для всего контейнера прошивки, добавляемая в самый конец.

Хоть это и не особо потрясло меня, учитывая объём усилий, потраченных на реализацию аутентификации CTP, но я был немного удивлён, что кроме контрольной суммы SHA-256 в CHK2, которую можно было тривиально пропатчить, больше не было никакой защиты от записи прошивок. Я ожидал увидеть здесь проверки подписей или хотя бы защиту вида hashsum(secret_value + container_contents), но воссоздав функциональность обновления прошивки в моём v2x-ctl, я обнаружил, что если CHK2 корректно, устройство спокойно принимает пропатченные прошивки.

Чтобы проверить это, я внёс достаточно простое изменение: заменил строку WELCOME, отображаемую на сегментном дисплее при запуске устройства, на строку PATCHED. Записав прошивку и перезапустив устройство, я с радостью увидел эту строку:

Моя хакерская сторона думала, что это замечательно — люди должны иметь возможность выполнять любые действия с устройствами, которые купили. Вторая моя сторона, профессионал в сфере безопасности, считает, что полное отсутствие защиты (например, необходимости разблокировки загрузчика на мобильных устройствах) — это довольно плохая практика. Но это не конец света, если для обновления устройства через USB требуется физический доступ.

Если.

Все любят Bluetooth

Как и «все уважающие себя» современные аудиоустройства, Katana V2X, разумеется, имеет Bluetooth, даже несмотря на то, что основную часть своей жизни будет подключено к PC или игровой консоли.

И разумеется, Creative должна была создать приложение, позволяющее управлять параметрами и светодиодной подсветкой через телефон по Bluetooth.

BLE (Bluetooth Low Energy) работает следующим образом: у каждого устройства есть различные регистры (называемые характеристиками GATT); при наличии подключения к устройству пользователь может выполнять их запись, чтение, подписываться на их уведомления и так далее. Важно то, что для подключения к устройству не обязательно выполнять с ним сопряжение. Часто достаточно просто подключиться к устройству и сразу начать читать и записывать данные в характеристики. Сопряжение обеспечивает шифрование, но соединение можно создать и без него.

В процессе исследования прошивки Katana я обнаружил, что внутренний обработчик CTP связан с USB и, очевидно, с Bluetooth:

Заинтригованный этим, я скачал мобильное приложение Creative и попробовал подключиться к устройству.

«Нажмите кнопку POWER для сопряжения».

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

Я подготовил среду прослушивания Bluetooth и увидел, что для инициации процесса сопряжения телефон записал полезную нагрузку вида 5a 0b... в характеристику 9e9daaec-3a10-4fe8-b69f-7397aff77886 и считал ответ из характеристики 9e9daaeb-3a10-4fe8-b69f-7397aff77886.

Значение 5a вызвало во мне крайне сильные подозрения, потому что это тот же байт, с которого начинаются все команды CTP. Предчувствуя что-то интересное, я подключился к устройству через Bluetooth с ноутбука и записал полезную нагрузку 5a 09 01 02, то есть команду CTP для считывания версии прошивки, которая при передаче через USB требует аутентификации.

К моему удивлению, считав характеристику 9e9daaeb-3a10-4fe8-b69f-7397aff77886, я увидел строку с полной версией. Из этого следовало, что кто угодно мог просто подключиться к любому Katana V2X через Bluetooth и начать отправлять на него команды CTP, считывая информацию, меняя параметры и так далее.

Беспроводные обновления (непрошенные)

Мне не понадобилось много времени, чтобы выяснить, что обновления прошивок тоже выполнялись через CTP. Учитывая то, что кто угодно может собрать валидную собственную прошивку, я задался вопросом, а сможет ли нападающий просто загрузить свою прошивку через Bluetooth без необходимости аутентификации или сопряжения.

Потратив какое-то время на борьбу со странностями BLE (которые я подробно опишу ниже), я написал относительно простой скрипт на Python, выполняющий именно то, что делает мой инструмент v2x-ctl для обновления прошивок, но только через Bluetooth. С его помощью я попытался загрузить в устройство заранее созданную модифицированную прошивку. Так как BLE довольно медленный, для завершения понадобилось примерно десять минут, но после этого включённое устройство снова приветствовало меня сообщением «PATCHED».

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

Ещё интереснее для меня было то, что в стандартной компоновке саундбар подключён к PC через USB, то есть во всех смыслах является USB-устройством, которому доверяет компьютер.

Что, если мы напишем свою прошивку, заставляющую устройство работать в качестве клавиатуры, отправляющей нажатия клавиш для открытия терминала и исполнения произвольных команд? Так мы превратим саундбар в Rubber Ducky, но удалённо, даже без подключения чего-то к самому устройству или PC.

Паразитируем на ядре

Поначалу я думал, что это будет сродни подвигу Геракла. У меня не было доступа к исходному коду прошивки, поэтому понадобилось бы вставить в неё целый раздел кода, настраивающий устройство в качестве HID (human interface device) (если это вообще возможно для данного SoC), а затем процедуру, использующую его для отправки нажатий клавиш на PC через USB; при этом остальной код прошивки должен был работать обычным образом, чтобы не вызывать подозрений.

Однако ещё немного поисследовав прошивку, я осознал, что это не так сложно, как казалось.

Во-первых, оказалось, что саундбар изначально настроен как HID-устройство. Да, не как полнофункциональная клавиатура, а как Consumer Control device, позволяющее менять громкость и управлять состоянием мультимедиа на PC (воспроизведение/пауза), но почти ничего сверх того.

Это можно увидеть из логов ядра:

В USB-устройствах это реализуется так: устройство сообщает компьютеру набор дескрипторов USB, то есть, по сути, даёт отчёт о своих возможностях и действиях, список интерфейсов и так далее.

Найти дескриптор отчёта в прошивке оказалось довольно легко и, на мою удачу, там было достаточно места для добавления второго дескриптора отчёта, который сообщал, что устройство является клавиатурой. Запустив после этого dmesg, мы увидим, что теперь устройство говорит, что оно клавиатура:

Вторая проблема заключалась в отправке самих данных HID и эмуляции нажатий клавиш. Здесь мне снова повезло: в прошивке уже имелась удобная подпрограмма для отправки данных HID и мне достаточно было передавать ей данные (нажимаемую или отпускаемую клавишу), после чего вызывать.

С третьей проблемой мне пришлось повозиться. Было сложно найти достаточно свободного места для записи (чтобы оно правильно отобразилось в памяти и не приводило к мгновенному вылету устройства при запуске), нужный участок кода («трамплин»), который правильно работал и не вылетал при возврате к обычному потоку команд, и так далее.

В конечном итоге я осознал, что всё это работает на FreeRTOS, поэтому, скорее всего, при запуске и так исполняется куча разных задач. Мне не нужно писать трамплин и жонглировать потоком исполнения; достаточно лишь переписать готовую задачу, а прошивка уже сама запустит её. Я нашёл задачу diagnostic, которая при обычной работе вроде бы ничего не делала: насколько я мог судить, она применялась для сбора диагностических данных от DSP-сопроцессора.

Я заменил эту задачу на задачу, которая:

1. Ждёт примерно 20 секунд запуска саундбара и загрузки USB-подсистемы

2. Вводит echo pwned и нажимает на Enter с паузами примерно в 20 мс между нажатиями на клавиши

3. Завершает задачу, не вмешиваясь в остальную функциональность устройства

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

Получившиеся патчи оказались довольно минимальными — всего 83 байта на отчёт USB и 102 байта написанных вручную ассемблерного кода ARM/Thumb для инъектора нажатий клавиш плюс 2 байта на каждое нажатие клавиши, которое я хотел передать.

Результат

Соединив всё это вместе, я смог полностью удалённо, беспроводным образом загрузить собственную прошивку в саундбар, с которым не выполнял сопряжение. Он перезагружался, записывал прошивку, а после перезагрузки вводил команду echo pwned и исполнял её.

В сценарии реальной атаки я бы выполнил нажатия клавиш для открытия powershell.exe или чего-то подобного и вставки настоящего зловредного однострочника, но в качестве proof of concept моего результата было вполне достаточно. Кроме того, настоящий нападающий, скорее всего, отключил бы процедуру обновления прошивки в обычном режиме и режиме восстановления, из-за чего зловредную прошивку невозможно было бы удалить с устройства или пропатчить в будущем.

Усугубило ситуацию то, что Bluetooth всегда включён в устройстве, даже в режиме сна, и очевидных способов его отключения нет.

Ликвидация последствий

Общение с представителями Creative было очень утомительным процессом.

У компании нет никаких контактных данных, связанных с безопасностью. На самом деле, я даже не смог найти обычных контактов, если не считать формы техподдержки на веб-сайте. Я дважды пытался связаться с ними через веб-форму, но потом сдался и обратился в SingCERT, чтобы она была посредником, надеясь, что им больше повезёт в общении с Creative.

Похоже, поначалу SingCERT тоже не удавалось связаться с Creative. Компания ответила SingCERT примерно через два месяца. К сожалению, она сообщила, что «не считает это уязвимостью, потому что это не представляет угроз кибербезопасности». Не знаю, как они пришли к этому выводу, но стало ясно, что Creative не заинтересована в ответе и реакции на эту проблему.

Из-за этого пока нет патчей от самой Creative. Её последняя прошивка уязвима.

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

Я создал инструмент, который скачивает официальную прошивку с серверов Creative, патчит её в памяти и загружает её в подключенный через USB Katana V2X. Его можно скачать со страницы Releases: https://git.dog/xx/v2x-patcher (или собрать самостоятельно при помощи cargo, если вы хотите предварительно исследовать патчи).

Подробности

Ниже приведены технические подробности о процессе реверс-инжиниринга и о патчах двоичных файлов.

Страдания по структуре памяти

Чтобы автоматический анализ Ghidra (или любого другого инструментария для реверс-инжиниринга) работал правильно, двоичный файл должен иметь корректный базовый адрес. В противном случае указатели, вычисляемые на основе базового адреса, будут указывать не на те данные, а полученный дизассемблированный код не будет иметь смысла.

С FMAIN.bin мне пришлось попотеть. Недостаточно было просто загрузить прошивку с тем, что я считал корректным базовым адресом (0x10000000). Когда я загружал двоичный файл с этим адресом, автоматический анализ как будто создавал валидные результаты, код запуска и ядро FreeRTOS казались корректными, но после небольшого раздела в начале автоматический анализ давал сбой и генерировал мусор.

Как оказалось, FMAIN.bin — это не монолитный образ, он загружается по частям и разные разделы прошивки загружаются по разным адресам.

Мне не удалось найти удобного способа определения правильной структуры памяти, но я смог получить следующую структуру (а позже и удостовериться в её правильности благодаря считыванию памяти из устройства, когда смог пропатчить и загрузить прошивку):

Использование этой структуры памяти в Ghidra позволило генерировать валидные результаты анализа.

Строковые x-ref для прошивки ARM

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

Отталкиваясь от того, что, как я предполагал, было методом log прошивки, я осознал, что указатели строк не загружались напрямую. Для этого использовалась пара команд movw и movt:

movw r0, #0x29A4   ; младшие 16 бит
movt r0, #0x400A   ; старшие 16 бит, r0 = 0x400A29A4

Я пробовал искать онлайн, но не нашёл практически никакой информации о том, почему анализ Ghidra, похоже, не распознаёт их, как указатели строк (возможно, из-за разбросанной загрузки?), но написал скрипт, который обходил все пары movw/movt, выполнявшие загрузку в один регистр, отфильтровывал те, которые указывают на валидную память, и задавал для них ссылки DATA. Это создало примерно 13 тысяч ссылок, что сильно упростило мне жизнь.

Патчи прошивок для чтения, записи и исполнения памяти

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

Я решил, что для подготовки этих обработчиков лучше всего будет переписать существующий обработчик CTP, который уже подключен, но не делает ничего важного. Достаточно хорошим кандидатом мне показался опкод CTP 0x54, он всего лишь возвращал обратно переданные данные, а занимал при этом около 106 байт. Казалось, что этого маловато для трёх команд, но оказалось, что они с трудом, но уместились — получившийся обработчик с тремя командами занимал 96 байт.

На стороне хоста я просто добавил в инструмент v2x-ctl поддержку этой новой команды CTP. Благодаря этому я смог исполнять произвольный код через USB без необходимости перезаписи всей прошивки; тестирование патчей и прочие действия стали гораздо более удобными.

Таймеры наблюдения делают свою работу

В процессе написания полезной нагрузки для отправки команд HID я постоянно сталкивался с проблемой: мой код, который казался правильным и справлялся с отправкой одиночных нажатий, перезапускал устройство каждый раз, когда я пытался реализовать отправку серии нажатий.

Это было до того, как я пришёл к решению с заменой уже существующей задачи, и просто выполнял свою полезную нагрузку при помощи mem-exec. Самое странное заключалось в том, что устройство вылетало, когда я вызывал казавшуюся безобидной функцию vTaskDelay, встроенную в FreeRTOS, чтобы добавить небольшую задержку между событиями нажатий.

Оказалось, Creative реализовала таймеры наблюдения для каждой задачи, и если исполнение критичной задачи занимало слишком много времени, операционная система уходила в панику и перезагружалась (по крайней мере, я так думаю). Когда я вызывал vTaskDelay через mem-exec, то делал это в контексте задачи обработки USB. Задержки для каждого символа накапливались, таймер наблюдения не срабатывал вовремя и система перезапускалась.

Проблема самоустранилась, когда я инъецировал свой код в задачу диагностического сервиса, перестав вызывать её напрямую из задачи USB.

Все тесты и реверс-инжиниринг были выполнены с прошивкой версии 1.3.230619.1820.

Хронология

• 01.04.2026 — Попытка номер 1 получения контакта производителя через форму поддержки (у производителя отсутствуют публичные контакты по безопасности)

• 07.04.2026 — Попытка номер 2 получения контакта производителя через форму поддержки

• 09.04.2026 — Отправка уязвимости в SingCERT

• 16.04.2026 — Ответ SingCERT с просьбой предоставления дополнительной информации

• 16.04.2026 — Отправка SingCERT дополнительных подробностей

• 20.04.2026 — Ответ SingCERT с просьбой предоставления дополнительной информации

• 20.04.2026 — Отправка SingCERT дополнительных подробностей

• 20.04.2026 — Ответ SingCERT с подтверждением отчёта и сообщением о попытке связаться с производителем

• 08.05.2026 — Электронное письмо от SingCERT о том, что ей не удалось связаться с производителем, и вопросом, следует ли продолжать пытаться получить ответ

• 08.05.2026 — SingCERT отправлено подтверждение

• 25.05.2026 — Электронное письмо от SingCERT о том, что производитель ответил и в курсе дела

• 03.06.2026 — Электронное письмо от SingCERT о том, что производитель «не считает это уязвимостью, потому что это не представляет угроз кибербезопасности».

• 03.06.2026 — Публикация статьи