Игровая консоль Playdate, разработанная компанией Panic, стала своеобразным возвращением к ретро-геймплею с уникальным дизайном и ограниченными техническими возможностями по сравнению с современными игровыми устройствами. Ее небольшой черно-белый экран без подсветки и процессор Cortex M7 создают атмосферу ностальгии по временам простых игр, при этом устройство обладает встроенным Wi-Fi, что открывает новые возможности для игровых проектов. Однако, несмотря на эти инновации, консоль столкнулась с серьезными проблемами безопасности, связанными с эскалацией привилегий, которые ставят под угрозу как личные данные пользователей, так и целостность системы. В середине 2024 года во время разработки игры для Playdate был обнаружен способ получить полный контроль над Wi-Fi модулем устройства, что ранее было невозможно из-за ограничений в API. В отличие от традиционных игровых платформ, Playdate предоставлял доступ к сети только через высокоуровневый API для таблиц лидеров, который фильтровал и ограничивал функции.
Это сделано для защиты пользователей и стабильности системы. Однако анализ этого механизма показал, что он не был идеальным и содержал уязвимости. Основополагающий элемент SDK для Playdate представлен в виде указателя на структуру PlaydateAPI, который ссылается на код, расположенный в специальном участке памяти устройства. Такая архитектура представляет собой нестандартное динамическое связывание, позволяющее разработчикам обновлять SDK вне зависимости от игры. При попытках провести реверс-инжиниринг с помощью инструментов вроде Ghidra выяснилось, что хотя часть памяти была защищена аппаратно и недоступна для чтения, SDK и некоторые смежные области имели открытый доступ, что позволило изучить ее структуру и некоторые внутренние методы работы с сетью.
Первоначальный анализ фокуса был сосредоточен на механизме работы с HTTP-запросами внутри SDK. В частности, было замечено использование команд ESP AT для управления встроенным Wi-Fi чипом Espressif ESP32. Попытка отправить произвольную AT-команду сразу приводила к ошибке и перезагрузке устройства с сообщением о недостатке прав. При этом попытки модифицировать защищенную область памяти с SDK не принесли результатов, поскольку она была доступна только для чтения. В ходе дальнейшего понимания устройства системы безопасности и модели прав Playdate в Cortex M7 был установлен интересный факт, что процессор работает в двух режимах: handler и thread.
Все пользовательские приложения работают в thread mode с неполными привилегиями, в то время как handler mode, используемый для обработки прерываний, функционирует с максимальными полномочиями. Для повышения прав процессор допускает вызов так называемого SuperVisor Call (SVC) с кодом 2. Этот вызов обрабатывается специальным обработчиком, который решает, можно ли разрешить временное повышение привилегий. SDK использует этот механизм, чтобы коротко повысить права для выполнения сетевых операций, а затем возвращать их обратно. Несмотря на очевидную градацию прав и механизм проверки вызова SVC, опытным путем было обнаружено, что вызов SVC напрямую из пользовательского кода постоянно отклоняется.
Система способна определить, откуда возник вызов и не допускает эскалацию с неподписанного или неподтвержденного сегмента памяти, соответственно права доступа не повышаются. Это могло свидетельствовать о наличии аппаратно-программной защиты в системе или же глубоко встроенной логике проверки. Однако случайная особенность асинхронной работы API таблиц лидеров дала новый шанс. Поскольку сетевые запросы выполнялись асинхронно, результаты возвращались в виде колбеков, вызываемых после завершения операции. Именно в этих колбэках была найдена уязвимость: в момент вызова callback система все еще функционировала под повышенными привилегиями, что позволяло любому коду, размещенному в колбэке, работать с максимальными правами.
Проверка гипотезы дала положительный результат — код мог получить полные привилегии в callback-функции, что означало, что пользовательские приложения, задействуя асинхронные механизмы API подсистемы, могли получить полный контроль над устройством. Для профессионала информационной безопасности это был классический пример ошибки в архитектуре управления привилегиями, которая допускает так называемую «privilige escalation» — актуальную угрозу с серьезными последствиями. Благодаря этому, теоретически, злоумышленник мог получить доступ к Wi-Fi сети пользователя, перехватывать данные или даже удаленно контролировать игровую консоль. Интересным дополнением к данной проблеме стал проект IndexOS — альтернативный лаунчер для Playdate, устанавливаемый пользователями, желающими расширить функциональность устройства. Анализ его работы показал, что инсталлятор этих альтернативных сред обладал собственной уязвимостью привилегий, позволяющей обходить системные ограничения.
Особая сборка на языке Lua сопровождалась маленьким бинарным модулем, который содержал несколько особенных инструкций, имитирующих разрешенный вызов SVC, тем самым обманывая систему безопасности и позволяя повысить права. Этот метод был сопоставлен с уязвимостью CVE-2021-43997, известной для FreeRTOS — ядра, на котором построена Playdate OS. Использование манипуляций с регистрами процессора и обходом проверки адресации позволило запускать код с повышенными привилегиями, что подтверждало угрожающую совместимость известных уязвимостей FreeRTOS на игровом устройстве. Это означало, что производитель, используя устаревшую или неподдерживаемую версию ядра, мог предоставить нападающим доступ к самым глубоким слоям системы. Комбинация этих двух различных, но родственных подходов к эскалации прав — обхода проверки через асинхронные колбэки и подделка адреса вызова SVC — создавала широкое поле для потенциальных атак.
Первый способ — своего рода «заход в дверь вслед за другим», а второй — «использование универсального ключа». При этом устранение одной уязвимости не отменяло опасность другой, что требовало комплексных мер для защиты устройства. После обнаружения этих проблем, была оперативная реакция компании Panic. Уже в октябре 2024 года вместе с выпуском версии 2.6.
0 Playdate OS большая часть уязвимостей была закрыта, включая обновление FreeRTOS до более безопасной редакции, что устранило CVE-2021-43997. Эти изменения привели к временным сбоям в работе альтернативных лаунчеров, которые смогли перестроить свои методы интеграции без привлечения уязвимых путей. Компания также анонсировала планы на добавление полноценного официального сетевого API в более поздних обновлениях, что сделало разработку сетевых игр проще и безопаснее. В целом увлекательное расследование основывается не только на технических аспектах и реверс-инжиниринге, но и демонстрирует важность обеспечения комплексной безопасности даже в таких, казалось бы, простых устройствах, как портативные игровые консоли. Она показывает как ошибки в управлении правами доступа, неудачная архитектура асинхронных вызовов и использование устаревшего ядра могут привести к серьезным уязвимостям.
Кроме того, пример с Playdate подчеркивает необходимость постоянного аудита и обновлений программного обеспечения, а также важность открытого диалога между разработчиками и сообществом для быстрого выявления и исправления проблем. Безопасность — это не разовое действие, а процесс, требующий внимания к мелочам и детальному пониманию систем. Для пользователей Playdate выявленная уязвимость означала потенциальные риски, связанные с возможностью несанкционированного доступа к личным данным и управлению устройством. Однако своевременное реагирование производителя и активность сообщества позволили устранить основные угрозы и повысить безопасность платформы. Эта история сломала многие стереотипы о том, что маленькие или нишевые устройства не требуют серьезного внимания к безопасности.
Разработчики игр и приложений для Playdate получили ценный опыт, а сама платформа стала примером того, как управление доступом и привилегиями является краеугольным камнем любой современной системы.
