Считать заблокированный микроконтроллер через ПДП

[>TEHb<]

Наткнулся на статью про "взлом" защиты Level1 в микроконтроллерах семейств GD32, STM32, APM32, CH32, ну и прочих клонах
Если вкратце, то там предлагается не вычитывать программатором код из флеша, а выполнить код в оперативной памяти, который сам всё вытянет. Просто так ядром читать не получится, а вот через ПДП запросто!
Попробовал. Написал функцию чтения в оперативную память и выполнял код из оперативной памяти же. Без защиты всё свободно вычитывается хоть ядром, хоть через модуль Прямого Доступа к Памяти. С защитой ПДП выкидывает ошибку, ядро тоже не может получить доступ. Проверял на STM32F334.

Что думаете по этому поводу? Кто-нибудь ещё проверял?

[jcxz]

Что думаете по этому поводу? Кто-нибудь ещё проверял?

Думаю, что в STM не дураки сидят, и при включённой защите:
1) или не дадут вообще загрузить и выполнить код в ОЗУ;
2) или загрузить/выполнить дадут, но встроенная флешь такому коду не будет доступна.

Проверять смысла нет. Это всё равно что проверять, что вода действительно мокрая.

[>TEHb<]

Там пишут иное.
Сам лично выполнял код из оперативы, но к флешу действительно не получил доступа. Это на СТМе модели 334. А другие "совместимые"?

[HardWareMan]

вода действительно мокрая

Однако, не каждая вода - мокрая. Так что всегда следует уточнять, какая именно вода имеется в виду.

[Mr.fury89]

Что думаете по этому поводу? Кто-нибудь ещё проверял?

Лично я пробовал вычитать залоченную флеш на STM32F205RET6, запустив код из оперативки, через режим DFU, но запускал из RAM, Удалось. На STM32F103C8T6 не прокатило, на STM32F401CCU6 тоже не прокатило, причём DFU загрузчик запускал на нём как из оперативки, так и встроенный. И ещё не прокатило на МК в моём JLink-е, STM32F205VET6. С чем связано, я так и не понял. Возможно это из-за разной организации памяти, или по-разному сконфигурирована защита от чтения, не знаю.

[Rapra]

Были попытки (в том числе и удачные) на основе создания сильных помех в питании при включении. Основаны на том, чтобы вызвать сбой в последовательности запуска и проскочить чтение битов защиты. Там же по сути в момент запуска скрыто читается Option-регистр, он то в том числе и включает эту самую защиту. Не везде это работает, потому что производители тоже не дураки, работают над своими ошибками, залатывают дыры..

А вот что касается чтения залоченного МК через DFU - тут чето сомневаюсь. При уровне Level 2 системный DFU отключается, просто потому, что выключаются все системные (прошитые изготовителем микроконтроллера) загрузчики. Единственная возможность подключаться по USB - это написанный автором прошивки DFU. Но такой способ поддерживает только заливку новой прошивки без сохранения старой. И если автор загрузчика явно не разрешил чтение старой прошивки, то невозможно к ней и подключиться.

[>TEHb<]

Так-так, можно подробнее? Про взлом через шины питания слышал, но все об этом говорят как о чём-то общеизвестном.

[Mr.fury89]

А вот что касается чтения залоченного МК через DFU - тут чето сомневаюсь. При уровне Level 2 системный DFU отключается, просто потому, что выключаются все системные (прошитые изготовителем микроконтроллера) загрузчики. Единственная возможность подключаться по USB - это написанный автором прошивки DFU. Но такой способ поддерживает только заливку новой прошивки без сохранения старой. И если автор загрузчика явно не разрешил чтение старой прошивки, то невозможно к ней и подключиться.

Да, согласен. Но чтение флеши через DFU можно организовать в своём DFU загрузчике, запущенном из RAM-памяти. И через какую-нибудь DfuSeDemo вычитать. Главное, чтобы правильно загрузчик был написан. Лично у меня пока не особо получаются загрузчики, но я научусь, вопрос времени.

[Rapra]

Я сам не пробовал, не было в том необходимости. Пишу лишь на основе того, что писали в инете. Но это было достаточно давно. Насколько правда - не знаю, "за что купил, за то и продаю". Но логика в этом есть. Производитель СТ признавал такую проблему. Опять же, сейчас пруфов нет, это обсуждалось лет 10 назад, а то и больше.
Суть заключалась с создании глитч-эффекта (сбоя, ложных импульсов) тактирования на начальном этапе запуска. Нужно было обмануть внутреннюю логику подтверждения начала работы осциллятора. И потом, когда тактирование начинало поступать на внутренние узлы, нужно было создавать глитчи, то есть срывы фронтов, ложные импульсы, затянутые фронты. И таким образом можно было проскочить скрытое чтение регистра опций.
По крайней мере, в то время именно так объяснялся механизм.
Позднее производитель СТ учел эту дыру безопасности и что-то поправил.
Повторюсь, лично я не проверял на деле.

[Rapra]

Да, согласен. Но чтение флеши через DFU можно организовать в своём DFU загрузчике, запущенном из RAM-памяти.

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

Главное, чтобы правильно загрузчик был написан. Лично у меня пока не особо получаются загрузчики,

Так вы чтож, сами себе подлянку хотите сделать, разрешив чтение прошивки в вашем загрузчике?
Ведь для чего делается программный загрузчик то - дак чтоб сторонний пользователь устройства мог обновлять прошивку через USB. Сам микроконтроллер при этом заблокирован от чтения прошивки на уровне Level 2. Более того, если делать по уму, то обновление прошивки должно поставляться и загружаться в зашифрованном виде. Микроконтроллер при загрузке расшифровывает её ключом, находящимся в защищенной части загрузчика, верифицирует (проверяет подлинность загруженной прошивки) и записывает её во флеш, а после перезапуска передает ей управление. То есть, управление загруженной прошивке передается только после её верификации, и передается управление только во флеш, а не в ОЗУ. В тех МК, где есть модуль MPU, можно вообще запретить исполнение из SRAM на аппаратном уровне.
В противном случае, при ошибке верификации загружаемой прошивки - закрытие USB-сеанса и стирание загруженного из SRAM. Повторюсь, сами по себе принятые байты перехватить на себя исполнение не могут. Передача исполнения - инициатива загрузчика, записанного во флеше.

[Mr.fury89]

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

Ха, вообще да, но на моменте постоянного допиливания и т.д. прошивки целевого устройства, этот вариант очень удобен, при этом чтение мне ни к чему. Однако, для вычитывания прошивки для клонирования устройства - вещь нужная.

[Rapra]

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

На всякий случай (вдруг есть недопонимание) поясню, что пользовательский (не системный) загрузчик разрабатывается отдельно и отдельно зашивается в микроконтроллер в отдельные сектора флеша. После этого при первом запуске микроконтроллера запускается этот загрузчик и выставляет защиту от записи/стирания своих секторов флеша (в которых он лежит) и включает защиту Level 2 и инициализует программный рестарт микроконтроллера. После перезапуска микроконтроллера загрузчик проверяет включение Level2, инициализует USB или иной вид связи (UART, SD-карта) и ожидает загрузки рабочей программы. Если рабочая прошивка поставляется в зашифрованном виде, загрузчик дешифрует её, проверяет валидность и записывает во флеш. И только после всех этих процедур загрузчик может передать управление в рабочую прошивку.

[Mr.fury89]

Всё это понятно, и логика понятна как работает всё это.

[Zikon]

вот некоторые моменты по вскрытию RDP на GD32
без DMA через SWD

https://habr.com/ru/companies/pt/articl ... 1757644955

[Rapra]

Ну это, что я и рассказывал. Глитч (сбой) при запуске, создание затянутых фронтов и ложных импульсов тактирования с помощью дергания питания. И если у кого есть инструменты, то вскрытие корпуса и попытка добраться до внутренней электроники. Понятно, что "против лома нет приема".
Но и производители тоже не стоят на месте, совершенствуют защиты. Ведь STM32F1xx - это самые старые 32-битные МК у ST. Сейчас у них уже закончился срок лицензии, поэтому понаделали кучу их клонов. В том числе и со всеми проблемами