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

Концепт защиты

Flash Readout Protection (RDP) ключевой компонент в защите, включенный во все линейки микроконтроллеров. Он защищает системную прошивку, сохраненную во внутренней флэш памяти от вычитывания. В зависимости от линейки, могут быть включены дополнительные механизмы, такие как Memory Protection Unit (MPU) и привилегированные / непривилегированные режимы исполнения. Вместе, эти системы призваны повысить защищенность.

RDP имеет 3 уровня защиты, RDP level 0, 1, 2. Защищенность увеличивается с ростом числа.

RDP level 0 : установлен по умолчанию и не предполагает защиты. Используя интерфейс отладки, можно получить полный доступ к устройству.

PRD level 1: Интерфейс отладки остается активным, но доступ к флэшу ограничен. Как только подключается интерфейс отладки, флэш память блокируется. Она не может быть считана ни напрямую, ни через DMA, ни путем исполнения инструкций из нее. Уровень защиты может быть как повышен до 2, так и понижен до 0, с потерей содержимого всей флэш памяти.

PRD level 2: максимально ограничивает и предоставляет максимальный уровень защиты. Интерфейс отладки отключен. Уровень не может быть понижен. Однако, несмотря на самый высокий уровень защиты, уровень 1 широко используется. Многие компании предпочитают не блокировать устройства полностью, предполагая возможности для устранения багов и неисправностей, т. к. на уровне 2 отладка невозможна. К тому же, в серии STM32f1 нет поддержки RDP level 2.

Устройство защиты RDP

RDP level это часть конфигурации систем микроконтроллера, хранящаяся в выделенной option bytes секции как 16 бит non-volatile памяти в виде двух регистров, RDP и nRDP. nRDP побитно комплементарен к RDP. Избыточность необходима для защиты от смены уровня путем подмены одного бита.

Регистры конфигурации RDP
Регистры конфигурации RDP

Логика работы RDP

Согласно datasheet, на RDP level 1 существует два режим исполнения. Режим пользователя и режим отладки. Как только мк переходит в режим отладки, доступ к флэш блокируется. Чтение из флэша по заявлениям производителя должен вызвать ошибку шины, затем Hard Fault interrupt.

Атака Cold-Boot Stepping

В режиме RDP level 1 при подключении отладчика ограничивается доступ только к FLASH памяти, тогда как SRAM остается доступна. Мы можем попробовать вычитать данные в момент, когда она загружены в оперативную память. С такой уязвимостью борются разработчики криптографических библиотек. Ключи шифрования хранятся в SRAM только во время использования, что составляет несколько миллисекунд, что делают такую атаку практически не выполнимой, даже без того факта, что мы не знаем об организации памяти.

Для преодоления этого ограничения авторы статьи разработали Cold-Boot Stepping (CBS), метод с помощью которого можно делать точные снимки оперативной памяти. Идея метода в том, чтобы точно отсчитывать время от события, к примеру RESET, и циклично с шагом несколько тактов делать snapshot содержимого SRAM. Атака состоит из следующих шагов:

Схема установки для атаки CBS
Схема установки для атаки CBS

1. Установление системы в изначальное состояние

1. Отключение питания. Необходимо чтобы мк смог снова читать из flash памяти.
2. Установка RESET до подачи питания. Позволяет запустить систему без начала исполнения кода
3. Подача питания под установленным RESET

2. Запуск системы на N кол-во шагов.

1. Запускает исполнение кода путем снятия RESET
2. Ожидание пока исполнение прошивки дойдет до установленного места
3. Установка Reset. Останавливает выполнение, но данные в SRAM остаются нетронутыми.

3. Вычитывание содержимого SRAM в файл

1. Подключение отладчика к мк
2. Снятие сигнала reset. МК не начинает исполнение кода, т. к. находится в состоянии halt установленного отладчиком.
3. Вычитывание SRAM

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

Экстракция прошивки через CBS

Развивая описанный метод, можно создать метод полной экстракции прошивки. Во многих продуктах производители используют загрузчик, алгоритм верификации прошивки которого базируется на подсчете чек суммы, например CRC32, реализованной в некоторых линейках мк. Применяя CBS (Cold-Boot stepping) на этапе работы загрузчика, можно полностью восстановить прошивку путем анализа регистров аппаратной чек суммы или программной ее реализации, ведь на определенном шаге в ней хранится байты интересующей нас части прошивки.  

Установка для атаки CBS
Установка для атаки CBS

На фотографии представлена автономная установка для извлечения прошивки. Ноутбук динамически подстраивает шаг, основываясь на успешности работы на предыдущем шаге. Для мк с малым объемом памяти, например STM32F051R8T6 на 64кб, экстракция займет несколько дней.

Получается, что несмотря на то, что RDP level 1 предоставляет защиту от чтения SRAM, она может быть взломана.

Использование RDP level 2 позволить обезопасить устройство от подобных атак, одна зачастую производители используют RDP level 1. Например, в популярном программном обеспечении для отладки, OpenOCD, предоставляет только команду “Lock” для защиты flash памяти устройство. При этом команда поддерживает только RDP level 1.

Понижения уровня защиты

Рассмотрим теперь методы понижения уровня RDP. Производитель заявляет, необратимость установки уровня RDP level 2. В идеале нам нужно понизить уровень 2 до 0, однако избыточность регистров RDP требует замены 8 битов. Чтобы понизить 2->1, требует изменить всего 1 бит.

Таблица соответсвия состояний RDP
Таблица соответсвия состояний RDP

Методом UV-C оптической экспозиции можно добиться изменения бит с состояния “0” на “1”. Когда излучение в 254нм попадет на затвор, происходит внедрение электронов и состояние логической ячейки переходит с 0 (заряженное) на 1 (незаряженное). Предварительно требуется очистить кристалл с помощью химического травления.

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

Защита от понижения уровня защиты

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

Взлом интерфейса отладки

Микроконтроллеры производителя ST предполагают отладку по интерфейсу SWD [2]. Когда отладчик подключается к мк с RDP level 1 защита флэш памяти ограничивает доступ. Плохо задокументированный механизм отладки вызывает много вопросов и подстегивает к его изучению.

Авторы статьи создали свою реализацию интерфейса SWD для изучения работы защиты. Оказывается, что защита активируется только если отладчик взаимодействует с шиной AHB-Lite [1]. Получая доступ только к регистрам SWD, защита не активируется, но как только запрашивается доступ к периферии, SRAM или Flash мк переходит в режим отладки и flash память блокируется.

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

Согласно документации на Cortex-M0 [3] инструкции процессора имеют приоритет по отношению к интерфейсу отладки.  Получается отладчику нужно дожидаться свободного цикла на шине чтобы исполнить свой запрос. Если отладчик получит доступ к шине раньше защиты flash памяти, то сможет считать данные из не заблокированной памяти.
Авторы статьи изучили работу защиты с прошивкой, эмулирующей нагрузку на шину, состоящий из интенсивного чтения и операций NOP. Если в прошивке нет таких операций, то чтения памяти отладчиком занимает 2 цикла: разрешения адреса и непосредственно чтение. Если добавить одну операцию NOP, то один из трех запросов на чтение не выполнится. Зависимость вероятности успешного чтения от кол-ва операций NOP может быть выражена в виде формулы

P_s = 1 -\frac{w}{2 + w} = \frac{2}{2 + 2}

Использование операций STR в качестве нагрузки позволят показать, что flash память сама контролирует доступ. Прошивка также очень быстро мигает светодиодом, а момент, когда он перестает мигать, говорит о том, что память заблокировалась и исполнение кода прекратилось.

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

Авторы представили действующую реализацию экстракции кода с помощью двух STM32F0 Discovery. Данные отправляются на ПК через интерфейс UART, а SWD реализован на одной из STM.

Атака состоит из следующих шагов:

  1. Перезагрузка системы с помощью отключения и подачи питания, чтобы сбросить защиту флэш памяти.

  2. Инициализация интерфейса отладки.

  3. Установка длины слова отладки в 32 бита

  4. Установка адреса чтения из флэша

  5. Попытка чтения из памяти

  6. Вычитывание считанных данных через SWD

  7. Повторить пока не прочтем всю память инкрементируя адрес

Средняя скорость вычитывания получается около 45 байт в секунду, что позволяет прочесть самый емкий «камень» в 256кб за 2 часа. Однако эксперименты проводились только на серии STM32F0 и предполагается, что из-за схожего внутреннего состояния, все мк линейки подвержены подобным атакам. Другие серии могут быть не затронуты.
Данную атаку можно избежать, используя второй уровень RDP, но как показано ранее уровень защиты может быть изменен. В то время как метод CBS требует работоспособность программного кода, уязвимость в отладчике может работать и в случае поврежденной при понижении уровня RDP прошивки.

Выводы

Серия мк STM32F0 содержит ряд уязвимостей позволяющих в лаборатории с базовым оборудованием создать установку для вычитывания прошивки. Методы могут комбинироваться для достижения наилучшего результата или позволить работать в RDP level 2.

Все необходимы материалы, исходный код и примеры представлены авторами статьи публично под лицензией MIT https://science.obermaier-johannes.de/.

Оригинал статьи: Shedding too much Light on a Microcontroller's Firmware Protection | USENIX

[1] ARM LIMITED. AMBA 3 AHB-Lite Protocol Specification v1.0, 2006.

[2] ARM LIMITED. CoreSight Components Technical Reference Manual, 2009.

[3] ARM LIMITED. Cortex-M0 Technical Reference Manual, 2009.

Комментарии (25)


  1. IvUyr
    19.12.2021 06:13
    +1

    То есть, как я понял, кроме как засветив участок кристалла до сих пор не возможно понизить уровень RDP.


    1. AlanDrakes
      19.12.2021 09:23
      +3

      В некоторых случаях срабатывают Glitch-атаки. Но их нужно проводить в строго определённое время между снятием сигнала сброса, иногда отсчёт идёт с момента подачи питания.

      Например, была статья https://habr.com/ru/post/500246/ хотя здесь используют глитч на пине сброса.

      https://habr.com/ru/company/ntc-vulkan/blog/480500/ - Здесь RaccoonSecurity описывает уже vcc-glitch, когда ядро МК пропускает инструкцию, либо неверно её интерпретирует при просадке питания.

      Была ещё интересная история про взлом ключей приставки кабельного ТВ во франции, но я не могу вспомнить, было ли это на Хабре, или где-то в другом месте. Разве что там использовали дополнительное питание процессора, чтобы он не потерял содержимое памяти между успешным запуском и переносом (физическим) его в программатор для считывания этой самой памяти.


      1. IvUyr
        20.12.2021 03:03

        Ну, грубо говоря, здесь и используется вариация глитча.


  1. sim2q
    19.12.2021 11:23
    +2

    Но зачем там механическое реле?
    Почему не p-channel mosfet ?


    1. alextrof94
      20.12.2021 06:27

      Вряд ли он специально его покупал для опытов. Что первое попалось под руку то и использовал.


  1. angrysioux
    19.12.2021 11:44
    -2

    Честно говоря, все эти доблестные взломщики настолько достали, что хочется собственноручно свернуть голову паре-тройке этих благородных джентльменов.
    Защита становится настолько сложной, что приходится тратить дополнительно месяцы для разработки. Я занимался разработкой для NXP'шных LPC и rt1176, где защита на 10 порядков сложнее, чем описанная выше для stm Весь кошмар заключается в том, что описана она крайне непонятно, люди, отвечающие на форуме сами не знают ничего толком и приходится связываться напрямую с NXP "через завсклад и директор магазин" и только там находятся люди, способные ответить на вопросы. Кроме того все шаги одноразовые(OTP). Вы начитались документации, нужно пробовать, прожгли фьюз, потом оказывается, что в документации ошибка, это скопипасчено из предыдущих документаций и уже улучшено. Вам остается только отковырять мк и прилеплять новый.
    Особенно понравилась мольба одного чела на NXP'шном форуме. Он пишет: "пожалуйста, люди, помогите, мне не нужны все ваши 100 уровней защиты во время работы, защита после утилизации и перед всходом луны. Может кто-нибудь сказать, как мне защитить ее от чтения!!! Просто и без выкрутасов!!! Help!!!". Ан нет, брат, - отвечают ему,- вот документация на 1067 листов, читай.


    1. ilyawg
      19.12.2021 22:37
      +3

      А нефиг устанавливать все эти защиты, и усложнять жизнь людям, которые потом будут это ремонтировать.

      хочется собственноручно свернуть голову паре-тройке этих благородных джентльменов

      из-за которых приходится отправлять в помойку изделия с копеечной поломкой только потому, что его нечем прошить


      1. angrysioux
        19.12.2021 22:56

        Я утратил способность ясно излагать свои мысли.

        Все эти защиты приходится устанавливать чтобы предотвратить воровство и утечку информации. А выступаю с вилами я не против защиты как таковой, а долбоклюев, котрые посвящают свою скучную жизнь, чтобы взломать, сделанное другими и из-за которых вся эта свистопляска с защитами. В некоторых устройствах эта защита избыточна. Эта вторая нехитрая мысль, которую я пытался донести.
        Что касается ремонта, то есть ключи и можно отлаживаться с ними. Или можно, как в случае с стм, стереть, сбросив защиту и залить заново. Тоже способ.


        1. flx0
          19.12.2021 23:37
          +2

          Какой-такой информации? Пользовательской? Ну так зашифруйте на хеш от пользовательского пароля и спрашивайте этот пароль каждый раз. Ах, вы свой исполняемый код "защитить" хотите? А нахрена? Чего там такого у вас "украдут"? Секретные протоколы общения по шине которые нужны чтобы обеспечить вендор-лок и непригодность к ремонту, да? Так и хорошо что украдут.


          1. angrysioux
            20.12.2021 00:01
            +1

            Чего там такого у вас "украдут"?

            "Чо там у вас красть. У вас красть-то нечего". (прячет за спину). Смешно.


          1. daggert
            21.12.2021 00:10

            Вы уж совсем категоричны. Вы извините но я делаю девайс, это мое ноухау. Я вложил в R&D кучу денег и продаю. Почему я не имею право защитится от слива прошивок? Потому что лично вы хотите чинить? Чините. Причем тут прошивка? Вендор лок? Ну да, в разумных пределах он вполне возможен - особенно в автономных МК.

            Вот у меня есть устройства на стандартных элементах - sx1276, STM, MCP23017, DS3231. Первые версии создавал на макетке с али. Сейчас я эти решения произвожу через один известный китайский сайт и продаю людям тут, в РФ. Я честно пишу - я вам продаю устройство для таких-то целей, выполняющих определенную функцию, да, я хочу на этом заработать, я нифига не альтруист, я на эти деньги провожу R&D, даю гарантию и улучшаю свои устройства. Если какой-то уася залезет в устройство, срисует схему, что мне собственно-то ||, могу и сам ее отдать и сможет повторять из говна и палок - пускай, мне не жалко, могу еще ссылки дать на Али на компоненты.

            Но вот простите программу написанную, с мною не любимой математикой, курением десятка форумов и сайтов, общением со специалистами, заказанные за деньги алгоритмы на АСМ, клиентское приложение - нет. Это то что я хочу запретить копировать. Пусть пишет сам, пусть ломает голову, пусть думает как впихнуть в эти ограничения то что запихал я. Пусть сам думает над тем как от одной батареи работать весь сезон в 4 месяца. Пусть сам откладывает со своей зарплаты большую часть на заказы дев-версий и обкатки на макете в течении трех лет, с откладыванием похода к врачу с гнилыми зубами. И это не преувеличение - я заказывал новые ревизии плат, корпуса и дев-бордов новых компонентов, вместо того чтоб себе сделать зубы в течении двух лет! Но теперь лично я хочу получать деньги за свой труд. И если будет слив - я-то просто заброшу этот проект, разорюсь и пойду на обычную работу, а вот условный Уася - врядли сможет поддерживать и разивать ту штуку которую я придумал, иначе он-бы уже давно сделал свое.

            Если вы считаете что воровство это хорошо - ну чтож, желаю чтоб результат вашего интеллектуального труда тоже украли и продавали. Тогда и будете писать что вы рады что это произошло.


        1. ilyawg
          20.12.2021 00:49
          +1

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

          есть ключи

          нет ключей

          стереть, сбросив защиту и залить заново

          Да. Но сначала надо откуда-то скачать. Например у тех,

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

          ну или самому осваивать это мастерство.

          В некоторых устройствах эта защита избыточна

          И чтобы такое происходило как можно реже, те, кто ее включает должны страдать, читая 1067 листов документации, чтобы мысль "а может ну ее нафиг" посещала чаще.


  1. predator86
    19.12.2021 23:16

    В режиме RDP level 1 при подключении отладчика ограничивается доступ только к FLASH памяти, тогда как SRAM остается доступна.
    А можно ли зашить в SRAM временную прошивку, которая и передаст нам содержимое flash? Или мы можем только читать SRAM?


    1. AleksandrVi Автор
      20.12.2021 01:06

      Мы можем писать в SRAM, но теоретически сможем выполнить толькой 1-2 операции, а потом будем получать hard fault, т.к шина будет заблокирована


  1. anonymous
    00.00.0000 00:00


  1. wAgo
    20.12.2021 00:59
    +1

    Сбросить биты можно и в домашних условиях самодельным рентгеном: вполне доступно, страшные дозы рентгена не требуются, с напряжением 60..80кв на аноде кенотрона, удавалось получить первые битые биты во флеш памяти уже через 10минут экспозиции ;)


    1. AleksandrVi Автор
      20.12.2021 01:02

      В описанном методе тоже используется вполне обычная лампа для экспозиции, однако даже не думал что можно рентгеном и ведь не придется снимать крышку!


    1. IvUyr
      20.12.2021 03:06
      +2

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


  1. K40
    20.12.2021 00:59

    А есть подобная информация для МК ATmega?


    1. AleksandrVi Автор
      20.12.2021 01:00

      Не узучал вопрос, но вероятно есть


    1. IvUyr
      20.12.2021 03:07
      +1

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


      1. ColdSUN
        20.12.2021 15:45

        Могу попросить о ссылке на какую-нибудь статью об этих МК?


        1. IvUyr
          20.12.2021 18:15

          Ох, давно я про это читал... Если вспомню где и/или найду в заметках - обязательно поделюсь!


  1. svpcom
    20.12.2021 17:16
    +1

    Ну кто ставит только Level 1 - сам виноват. С установленным Level 2 ИМХО достаточно проверять при старте не понизился ли уровень защиты и если да, то повысить ее обратно (процесс довольно быстрый). Еще можно при старте переопределить ножки SWDIO и SWDCK. Также можно в OTP память при первом старте записывать случайную последовательность, которой потом можно шифровать критические данные (если важны именно они, а не сам код прошивки). OTP расположена рядом с fuse битами и при засветки там гарантированно что-нибудь поменяется и расшифровать дамп уже не получится никак.


    1. svpcom
      20.12.2021 17:17
      +1

      Ну и для защиты от glitch аттак можно на этапе проверки контролной суммы и/или level'а добавить случайные задержки от встроенного генератора случайных чисел (все старшие stm32 его имеют)