В этом эксперименте мы с помощью дифференциальной микроскопии фотонной эмиссии засекли, в какой момент на чипе RP2350 (ревизии A4) активируется регистр отладки, и точно определили, куда целиться лазером. Затем, поймав нужный момент через интерфейс SWD, мы с помощью лазерного импульса точечно переписали два бита, восстановив доступ к режиму Secure Debug.

— С помощью микроскопиии фотонной эмиссии мы смогли найти на чипе регистр, отвечающий за включение отладочного режима в микроконтроллере Raspberry Pi.

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

— Для реализации такой атаки требуется физический доступ к устройству со вскрытием корпуса чипа и лабораторное оборудование стоимостью примерно $250 000.

Модель RP2350 — это двухъядерный микроконтроллер от Raspberry Pi, в котором при загрузке можно выбирать, какие именно ядра использовать — Arm Cortex-M33 или RISC-V Hazard3. Его система безопасности на аппаратном уровне включает:

• Механизм безопасной загрузки (Secure boot), который проверяет подлинность подписи прошивки по отпечаткам публичных ключей из OTP-памяти (One-Time Programmable).

• Механизм Armv8-M TrustZone, который разделяет состояние выполнения кода на защищённое (Secure) и незащищённое (Non-secure).

• Настройки перманентного отключения отладки.

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

Команда Raspberry Pi активно приглашала исследователей оценить эти механизмы защиты в рамках конкурса по взлому RP2350 Hacking Challenges. Первый такой челлендж проходил с августа по декабрь 2024 года, и тогда проверяли самую первую версию чипа. После того как разработчики исправили несколько найденных уязвимостей, была выпущена его обновлённая ревизия — A4. Именно эту версию мы и тестировали.

Неизменяемая конфигурация безопасности и отпечатки открытых ключей загрузки хранятся в OTP-памяти. Каждый бит в ней можно лишь один раз переключить из 0 в 1 — обратно переключить не получится. Так что все записанные настройки чипа сохраняются на нём навсегда.

OTP организована по 128-байтным страницам, защищённым двумя строками аппаратной (постоянной) блокировки. Для страницы n строка PAGEn_LOCK0 задаёт опциональные ключи чтения/записи и поведение чипа, если ключ не введён. При этом строка PAGEn_LOCK1 содержит аппаратно закреплённые права доступа LOCK_S и LOCK_NS. Эти права можно только ужесточать — например, изменить доступ «чтение-запись» на «только чтение» или полностью его закрыть. Более свободным его делать нельзя.

Согласно спецификации RP2350, в подсистеме OTP-памяти для полей, связанных с безопасностью, используется избыточное кодирование. Важнейшие флаги кодируются по мажоритарной схеме «три из восьми» по восьми последовательным строкам памяти, а для битов блокировки OTP применяется трёхкратное резервирование с проверкой по системе «два из трёх».

При сбросе подсистемы OTP постоянные значения LOCK_S и LOCK_NS инициализируют программную блокировку (soft lock) для каждой страницы. Прошивка может ужесточать эту блокировку вплоть до следующего сброса OTP, но не ослаблять. Любые её изменения после перезапуска подсистемы сбрасываются.

Внешний отладчик общается с RP2350 через отладочный интерфейс Arm SWD (Serial Wire Debug). Запросы сначала поступают в порт отладки (SW-DP), а затем перенаправляются в порты доступа (AP). В используемой здесь конфигурации с ядрами Cortex-M33 каждое ядро имеет собственный порт доступа к памяти (Mem-AP), подключённый к его системной шине. Если порт Mem-AP включён, отладчик может читать и записывать данные в разрешённые области памяти и периферийные устройства. Отдельный, всегда активный, порт доступа (RP-AP) предоставляет небольшой набор элементов управления сбросом и восстановлением системы.

Защищённая отладка (Secure debug) означает доступ через порт Mem-AP с правами защищённого режима. В этом случае отладчик может взаимодействовать с ресурсами в защищённой области памяти (если это разрешено логикой контроля доступа), а также останавливать или инспектировать ядро, работающее в защищённом состоянии.

Для возможности перекрывать этот путь существует отдельный флаг CRIT1.DEBUG_DISABLE. Когда он установлен, сигналы включения для портов Mem-AP обоих ядер сбрасываются в ноль. Это «полностью блокирует выполнение любых запросов к шине со стороны портов доступа», а также отключает интерфейс заводского тестирования JTAG и порт доступа модуля отладки RISC-V. При этом модули SW-DP и RP-AP продолжают отвечать на запросы, но ни один из портов Mem-AP ядра уже не может получить доступ к системной шине.

Однако здесь существует лазейка. Регистр DEBUGEN, отображаемый в адресное пространство, позволяет программному обеспечению из защищённого режима заново включить порты Mem-AP каждого ядра и отдельно разрешить через них безопасный доступ. В спецификации указано, что блокировку DEBUG_DISABLE «можно полностью обойти, установив все биты этого регистра».

Как раз этот критически важный переключатель в цепочке защиты и сделал отладочный интерфейс нашей главной целью. Получение доступа к Secure Debug через порт Mem-AP даёт универсальный инструмент для чтения и записи защищённой памяти, остановки процессора, пошагового выполнения кода и анализа регистров ядра. И в оставшейся части статьи мы ответим на вопрос о том, можно ли активировать этот регистр с помощью инжекции сбоев.

Испытательный стенд

Объект исследования

В предложенном разработчиками Pi челлендже участников просили извлечь из OTP 128-битный секретный ключ.¹ При старте подписанная прошивка следит, чтобы на странице 48 присутствовала ожидаемая перманентная блокировка. После этого она применяет программную блокировку, которая закрывает и защищённый, и незащищённый доступ к этому секрету до следующего сброса OTP.

Мы воспроизвели эту конфигурацию на своём собственном устройстве ревизии А4:

• Записали отпечаток SHA-256 нашего публичного ключа в BOOTKEY0.

• Установили для BOOT_FLAGS1.KEY_VALID значение 0x1, а для BOOT_FLAGS1.KEY_INVALID — 0xe.

• Включили защищённую загрузку (CRIT1.SECURE_BOOT_ENABLE = 1).

• Перманентно отключили отладку (CRIT1.DEBUG_DISABLE = 1).

• Активировали детекторы сбоев на максимальной чувствительности (CRIT1.GLITCH_DETECTOR_ENABLE = 1, CRIT1.GLITCH_DETECTOR_SENS = 3).

• Настроили перманентные блокировки для страниц 1 и 2 в соответствии с конфигурацией из челленджа.

• Зашили в строку перманентной блокировки страницы 48 значение PAGE48_LOCK1 = 0x3c3c3c, запретив доступ из незащищённого режима (LOCK_NS = INACCESSIBLE) с сохранением возможности чтения-записи из защищённого (LOCK_S = READ_WRITE).

При включении защищённой загрузки разрешается использование только ядер Cortex-M33, поэтому для этих экспериментов в обоих процессорных узлах использовалась архитектура Arm.

Мы вскрыли корпус микросхемы с обратной стороны, чтобы инфракрасный свет мог спокойно доходить до транзисторов сквозь кремниевую подложку, а не блокировался металлическими слоями на лицевой стороне чипа. Затем мы припаяли чип к дочерней плате, подключённой к открытой платформе Scaffold, которую в Ledger Donjon разработали для управления тестируемыми устройствами и их мониторинга. Поскольку при удалении выводной рамки с обратной стороны чипа нарушается его заземление, для восстановления контакта GND пришлось припаять медный провод.²

Вскрытый с обратной стороны RP2350 припаян к дочерней плате для анализа

Экспериментальный стенд

DEBUGEN включает пять функциональных компонентов:

Для безопасной отладки ядра необходимо активировать оба управляющих бита: отвечающий за включение порта Mem-AP и разрешающий защищённый доступ через этот порт.

В отличие от избыточного кодирования, применяемого для полей безопасности в OTP-памяти, для DEBUGEN в спецификации не заявлено никакой избыточности битов, контроля чётности или мажоритарного голосования.

Поэтому мы решили проверить, получится ли с помощью лазерных импульсов установить биты DEBUGEN на защищённом устройстве, описанном выше.

Для проведения теста необходимо знать, куда конкретно целиться. Установка отдельного бита DEBUGEN означает, что нам нужно попасть в физическую ячейку одного бита регистра — считай найти иголку в стоге сена. С точки зрения прицеливания это более сложная задача, нежели классический пропуск инструкций при LFI. При лазерной инжекции сбой в любом из множества триггеров в исполнительном конвейере процессора может привести к одному и тому же результату, поскольку чувствительная область оказывается достаточно широкой для её обнаружения произвольным сканированием. В случае же поиска одного бита DEBUGEN слепое сканирование непрактично.

При переключении транзисторы испускают слабое инфракрасное свечение, отражающее их активность. Поэтому улавливание фотонов, излучаемых ими при многократном выполнении операции, помогает определить, где именно меняет состояние выбранный элемент управления. Это делает микроскопию фотонной эмиссии (PEM) идеальным решением для поиска DEBUGEN. Поскольку этот регистр отображён в память, ПО из защищённого режима может циклически переключать конкретные биты, создавая те самые повторяющиеся изменения состояния, необходимые для измерений. Мы использовали этот метод в качестве первого этапа локализации и получили карту, которая сузила последующее лазерное сканирование до области размером всего в несколько микрометров.

Мы сравнивали циклы, которые многократно включали и выключали выбранные биты DEBUGEN. Причём отличались эти циклы только тем, на какие именно биты они были направлены. Собственное фотонное излучение регистра слишком слабое на фоне шумов камеры и сильно зависит от медленно меняющихся внешних условий вроде температуры, поэтому на одном кадре увидеть что-либо невозможно. Усреднив множество кадров при выполнении каждого цикла, мы смогли подавить случайный шум сенсора. А вычитание двух полученных усреднённых снимков друг из друга полностью убрало всё общее для этих циклов: статический фон, смещение сенсора, тепловое излучение и переключение транзисторов, не связанных с выбранными битами. В этом случае чередование двух наблюдаемых циклов непосредственно во время съёмки помогло избежать влияния медленного изменения температуры на результат вычитания. В итоге осталось только излучение, соответствующее конкретно выбранным битам.

Усреднённые пакеты кадров для всех 200 сессий захвата с масками 0x3 и 0xc, а также результат их вычитания с сохранением знака. Красный цвет указывает на положительные значения (более сильная эмиссия для 0x3), синий — на отрицательные (более сильная эмиссия для 0xc). На приведённых ниже картах локализации дополнительно сбалансирован порядок захвата данных перед объединением соответствующих друг другу разностных кадров.

Многократные сравнения с использованием различных битовых масок позволили выявить компактные области, связанные с битами 0–3 регистра DEBUGEN в трёх зонах поля зрения камеры.

Поле зрения камеры в ИК-спектре с тремя маркированными областями. Цветными пикселями отмечены области, связанные с битами 0-3 регистра DEBUGEN

Эти зоны отражают активность переключения, связанную с каждым битом DEBUGEN, но точное расположение ячеек памяти они не указывают. Несколько зон свечения, обнаруженных для каждого бита, могут относиться как к самому элементу хранилища, так и к связанной с ним логике. Отличить одно от другого без топологии кристалла невозможно. Тем не менее эти зоны всё равно значительно сужают область поиска.

Для инжекции сбоев мы использовали импульсный лазер с длиной волны 980 нм и оптической мощностью до 2,97 Вт, работавший примерно на 40% от максимума (около 1,2 Вт). Длительность импульса составляла 100 нс, а сам луч фокусировался через объектив с 50-кратным увеличением. После каждого импульса мы проверяли состояние портов доступа через интерфейс SWD.

В рамках области, обнаруженной при помощи PEM, мы выполнили LFI-сканирование и на основе обратной связи по SWD точно определили координаты двух реагирующих точек, расположенных в нескольких микрометрах друг от друга. В одной точке импульсы активировали доступ к шине через порт Mem-AP ядра 1, что указывало на установку бита PROC1. В другой же регистр CSW (Control/Status Word) содержал SDeviceEn = 1 — управляемый состоянием системы сигнал, указывающий на то, что бит PROC1_SECURE наверняка установлен. После каждого импульса мы проверяли оба этих признака.

Слева: участки PEM, связанные с битами DEBUGEN. Справа: точки лазерной инжекции сбоев на инфракрасном снимке лазерной установки

Импульс, который выставлял в единицу один бит, мог сбросить в нуль другой, поэтому для установки обоих потребовалось действовать итеративно. Наш скрипт бил лазером по точке PROC1 до тех пор, пока не появлялся доступ к шине. После этого он начинал стрелять по PROC1_SECURE, пока флаг SDeviceEn не принимал значение 1. При этом в случае потери доступа к шине, скрипт возвращался к стартовой точке. Как только координаты и параметры импульсов были откалиброваны, эта последовательность действий позволила включать режим Secure Debug за считаные секунды. Интересно, что воспроизвести её при использовании объектива 20х нам не удалось. Поскольку две интересующие нас позиции находятся всего в нескольких микрометрах друг от друга, более широкое лазерное пятно, похоже, попадало и в область установки бита, и в область его сброса, из-за чего получить нужное значение было невозможно.

Как только оба бита включались, они оставались в этом состоянии без дальнейших лазерных импульсов или программных операций записи. При чтении регистра DEBUGEN через порт Mem-AP первого ядра возвращалось значение 0xc. Поскольку DEBUGEN доступен только из защищённого режима, это успешное считывание подтверждает выполнение транзакции с соответствующими правами.

Включение защищённого доступа через порт Mem-AP первого ядра позволяет отладчику считывать и производить запись в ресурсы, отображённые в адресное пространство, если их логика ACCESSCTRL разрешает ему управлять шиной, и если контроллеры целевого модуля допускают защищённые транзакции по шине AHB. Независимо от таких прямых запросов на чтение, отладчик может останавливать работу ядра, включать пошаговый режим выполнения, а также изучать или изменять его регистры. Это полностью нарушает изоляцию TrustZone в процессе работы, так как секреты можно извлекать напрямую через защищённый режим процессора. Но это не заставит встроенный Boot ROM принимать неподписанную прошивку: при обычном старте механизм безопасной загрузки всё так же проверяет её подлинность, но уже не может защитить дальнейшее рабочее состояние системы, которое остаётся доступным для отладчика после проверки.

Описанный выше доступ через порт Mem-AP раскрывает защищённое рабочее состояние системы. Однако программная блокировка страницы 48, которую устанавливает прошивка в конфигурации челленджа, всё ещё препятствует доступу к секретному ключу. В то же время перманентная блокировка этой страницы (PAGE48_LOCK1 = 0x3c3c3c) запрещает чтение из незащищённого режима, но оставляет параметр LOCK_S в состоянии READ_WRITE. Это означает, что страница остаётся доступной для чтения через защищённые запросы до момента активации прошивкой программной блокировки.

В процессе каждой загрузки прошивка записывает в регистр программной блокировки otp_hw->sw_lock[48] максимально строгое ограничивающее значение, 0b1111. В результате эта страница становится недоступной как для защищённого, так и для незащищённого доступа, включая защищённый режим отладки. Это, в свою очередь, не позволяет защищённым транзакциям через порт Mem-AP прочитать секрет.

Согласно документации, программные блокировки «при сбросе инициализируются на основе OTP-страниц блокировки», а запись значения изменяет состояние системы лишь «до следующего сброса». Таким образом, сброс подсистемы OTP аннулирует значение 0b1111 и восстанавливает состояние, заданное параметром PAGE48_LOCK1, для которого LOCK_S = READ_WRITE.

Оставалось лишь понять, как сбросить заблокированный чип, не дав встроенному ПО заново активировать программную блокировку? Порт RP-AP по-прежнему «доступен всегда, даже если внешняя отладка отключена». Установка бита CTRL.RESCUE_RESTART запускает аварийный сброс — полный перезапуск системы, при котором для модуля Boot ROM также устанавливается флаг, заставляющий его приостановить загрузку до того, как начнёт выполняться какое-либо пользовательское ПО.

Перед инициализацией сторожевого таймера, загрузкой из flash-памяти или по USB модуль Boot ROM проверяет флаг POWMAN_CHIP_RESET.RESCUE_FLAG, сбрасывает его, а затем удерживает ядро 0 в цикле ожидания с отключенными прерываниями, а ядро 1 — в режиме ожидания вектора.³ В спецификации отсутствуют какие-либо упоминания об ограничениях на использование бита CTRL.RESCUE_RESTART.

Порядок наших действий был таким:

• Аварийный сброс. Установка бита CTRL.RESCUE_RESTART в 1 с его последующим сбросом в 0 через порт RP-AP. Микросхема выполняет сброс и остаётся на путях ожидания Boot ROM. Подписанная прошивка так и не запускается, поэтому sw_lock[48] не срабатывает и остаётся с разрешающим значением, полученным из PAGE48_LOCK1, где LOCK_S = READ_WRITE.

• Перевод регистра DEBUGEN в значение 0xc через инжекцию сбоя. Когда оба ядра окажутся на путях ожидания Boot ROM, устанавливаем PROC1 и PROC1_SECURE, как описывалось выше; эти два бита дадут значение 0xc.

• Приостановка ядра 1 через его регистр DHCSR (Debug Halting Control and Status Register), используя теперь уже защищённый порт Mem-AP.

• Считывание секрета из OTP-строк с 0xc08 по 0xc0f через защищённый интерфейс чтения.

Выполнив эту последовательность действий на тестируемом устройстве, мы добыли заложенный разработчиками секрет.

DEBUGEN_LOCK блокирует программную запись в соответствующие биты регистра DEBUGEN: каждый бит блокировки работает по принципу «Запишите 1, чтобы заблокировать бит […] DEBUGEN. После установки обнулить его будет нельзя». В спецификации это преподносится как способ «избежать случайной записи».

В ходе испытаний, когда целевой бит DEBUGEN был 0, а соответствующий ему бит блокировки — 1, лазерный импульс всё равно мог установить DEBUGEN в 1, пока блокировка оставалась активной. Импульсы также принудительно устанавливали биты блокировки с сопутствующим изменением бита DEBUGEN или без него. В случае успеха к моменту установки обоих битов PROC1 и PROC1_SECURE все пять функциональных битов блокировки оказывались переключены в 1. Мы не зафиксировали ни одного перехода бита блокировки из 1 в 0, поэтому последующая запись DEBUGEN = 0 не может восстановить отключенное состояние после того, как внедрением сбоя была установлена соответствующая блокировка.

Как только защищённый доступ через порт Mem-AP оказывается включён, одного лишь разграничения прав становится недостаточно, чтобы изолировать отладчик от защищённой прошивки. Данный тип доступа не позволяет обойти жёсткие аппаратные блокировки OTP-памяти или элементы управления конкретных периферийных устройств. Система ACCESSCTRL способна заблокировать прямые транзакции мастера отладки к определённым адресатам, но сама по себе она не может помешать отладчику, контролирующему защищённое ядро, инициировать обращения от имени самого ядра или извлекать загруженные значения через его внутренние регистры. После аварийного сброса ACCESSCTRL возвращается к своим исходным настройкам ещё до того, как прошивка успеет переконфигурировать её. Таким образом, ACCESSCTRL лишь снижает риски прямого воздействия через Mem-AP, но не формирует независимый рубеж конфиденциальности.

Тем не менее прошивка может снизить риски для безопасности после загрузки, запретив отладчику доступ к чувствительным объектам в ACCESSCTRL с последующей установкой его бита в ACCESSCTRL.LOCK, чтобы через его транзакции нельзя было восстановить эти разрешения. Защищённая прошивка также может периодически проверять состояние регистра DEBUGEN и при обнаружении непредусмотренного значения инициировать отказоустойчивый сброс, очищая область холодного сброса процессора. Эти меры являются лишь временными защитными механизмами периода выполнения, работающими по принципу «наилучших усилий». Активированный отладчик может приостановить работу ядра ещё до проведения следующей проверки, а аварийный сброс останавливает выполнение до того, как прошивка успеет настроить ACCESSCTRL или запустить мониторинг. Таким образом, они не предотвращают чтение секрета до момента запуска прошивки, продемонстрированное в нашей работе.

После аварийного сброса Boot ROM приостанавливает работу ядра ещё до начала дешифровки. В этот момент ещё не существует незашифрованной полезной нагрузки, однако ключ дешифровки может быть доступен для прямого чтения, если постоянные привилегии OTP-страницы разрешают доступ в защищённом режиме и никакой другой элемент управления адресатами эту транзакцию не блокирует.

После обычной зашифрованной загрузки открытый текст уже находится в SRAM: прямые операции чтения через Mem-AP зависят от разрешений мастера отладки в системе ACCESSCTRL. При этом контроль над защищённым ядром может позволить извлечь данные опосредованно через само это ядро, даже если прямые операции чтения запрещены. Данные выводы представляют собой архитектурный анализ, а не результаты практического тестирования зашифрованной загрузки. В то же время зашифрованная загрузка по-прежнему защищает внешнюю флэш-память от автономного (offline) анализа.

Продемонстрированная последовательность действий обеспечивает доступ к памяти с правами Secure-уровня, контроль над выполнением кода в Secure-среде, а также доступ к секретному ключу после сброса программной блокировки его страницы памяти. Для реализации атаки требуются следующие ресурсы:

• Физическое вскрытие. После декапсуляции со стороны подложки корпус микросхемы остаётся необратимо повреждён, а кристалл оголён.

• Специальное лабораторное оборудование. Стоимость описанной конфигурации оборудования составляет примерно $250 000.

• Опыт работы с аппаратной защитой. Для операции потребуется подготовить сам опытный образец, уметь ориентироваться в кристалле, подбирать правильные параметры лазера и управлять им, а также позиционировать предметный столик и проводить измерения через SWD.

В микроконтроллере RP2350 критически важные флаги отключения отладки закодированы в OTP-памяти с использованием механизма большинства голосов. Однако регистр DEBUGEN может переопределять их действие и при этом, согласно спецификации, не имеет другой равноценной защиты. В наших экспериментах импульсы лазера изменяли состояние DEBUGEN в обход блокировки DEBUGEN_LOCK и могли устанавливать бит блокировки, не давая прошивке восстановить его исходное значение.

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

Дифференциальный анализ фотонной эмиссии помог выделить активность регистра DEBUGEN на уровне отдельных битов, после чего посредством LFI на основе этого пространственного ориентира удалось получить устойчивый доступ к защищённой отладке. На системном уровне главный урок заключается в том, что анализ безопасности должен охватывать весь путь обеспечения защиты — от постоянной конфигурации в OTP-памяти до изменяемых регистров управления и логики сброса, поскольку безопасность системы зависит от всей этой цепочки, а не отдельных механизмов.

О найденной уязвимости мы сообщили разработчикам Raspberry Pi 28 июля 2026 года. Благодарим команду проекта за вовлечённость в её обсуждение и за их прозрачный подход к исследованиям безопасности.

• https://github.com/raspberrypi/rp2350_hacking_challenge Репозиторий RP2350 Hacking Challenge, содержащий эталонную конфигурацию блокировки и прошивку, которые мы воспроизвели. ↩

• Courk, Laser Fault Injection on a Budget: RP2350 Edition. ↩

• Проверка аварийного режима является первым шагом на пути загрузки ядра 0 в файле src/main/arm/varm_boot_path.c; в файле src/main/arm/arm8_bootrom_rt0.S функция varm_wait_rescue входит в WFI-цикл varm_dead_quiet с отключенными прерываниями в то время, как ядро 1 остаётся на пути ожидания вектора в Boot ROM. ↩