Программа для сравнения бина прошивки

Обновлено: 21.11.2024

Я полный ноль в программировании встраиваемых систем. Предположим, я собираю прошивку с помощью компилятора. Результатом этой операции является файл, который будет прошит (я думаю) во флэш-память микроконтроллера, такого как ARM или AVR.

Мой вопрос: Какие общие структуры (если они есть) используются для таких сгенерированных файлов, содержащих прошивку?

Я пришел из разработки настольных компьютеров и понимаю, что, например, для Windows компилятор, скорее всего, сгенерирует PE или PE+, в то время как для Unix-подобных систем я могу получить ELF и COFF, но понятия не имею о встроенных системах.

Я также понимаю, что это сильно зависит от многих факторов (компилятор, ISA, поставщик микроконтроллера, ОС и т. д.), поэтому мне достаточно хотя бы одного примера.

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

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

4 ответа 4

Большинство инструментов выводят либо ELF, либо COFF, либо что-то подобное, что в конечном итоге может сводиться к файлу HEX/bin.

Однако это не обязательно то, что хочет видеть ваша цель. У каждого поставщика свой формат файлов "прошивки". Иногда они зашифрованы и подписаны, иногда — в виде простого текста. Иногда есть сжатие, иногда сырое. Это может быть простой файл или что-то более сложное, чем просто ваша программа.

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

Файл микропрограммы представляет собой исполняемый файл, который можно связать, обычно преобразуемый в двоичный (.bin) или текстовый двоичный (.hex) формат.

Этот двоичный файл представляет собой точную память, которая записывается во встроенную флэш-память. При первом включении платы внутренний загрузчик перенаправит выполнение на точку входа прошивки, обычно по адресу 0x0.

Оттуда запускается ваш код, поэтому у вас есть код запуска (обычно файл startup.s), который будет настраивать часы, регистры указателя стека, векторную таблицу, загружать раздел данных в ОЗУ (ваш инициализированный переменных), очистите секцию, инициализированную нулями, возможно, вы захотите скопировать свой код в ОЗУ и перейти к копии, чтобы избежать запуска кода из FLASH (может быть быстрее на некоторых платформах) и т. д.

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

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

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

Одним из основных отличий является адресация памяти в бинарном файле firwmare. Обычно адреса представляют собой адрес физической ОЗУ, поскольку на большинстве микроконтроллеров отсутствует функция отображения памяти. Это прозрачно для пользователя, компилятор абстрагирует его.

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

Несколько дней назад я решил перепроектировать образ прошивки моего маршрутизатора с помощью binwalk.

Я купил домашний роутер TP-Link Archer C7. Не один из лучших, но достаточно хороший для моих нужд.

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

При установке и настройке OpenWRT я также загрузил последнюю версию официального образа прошивки Archer C7, предоставленную TP-Link, и решил проанализировать ее. Просто для удовольствия и чтобы написать немного о binwalk, одном из лучших инструментов для этой работы!

Что такое binwalk?

Binwalk – это инструмент с открытым исходным кодом для анализа, обратного проектирования и извлечения образов встроенного ПО.

Программа binwalk, созданная в 2010 году Крейгом Хеффнером, способна сканировать образ микропрограммы и искать сигнатуры файлов, чтобы идентифицировать и извлекать образы файловой системы, исполняемый код, сжатые архивы, образы загрузчика и ядра, форматы файлов, такие как JPEG и PDF, и многие другие. больше!

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

Вы можете распаковать образы файловой системы для поиска определенных файлов паролей (passwd, shadow и т. д.) и попытаться взломать хэши паролей. Вы можете выполнить двоичный diff между двумя или более файлами. Вы можете выполнить энтропийный анализ данных для поиска сжатых данных или жестко запрограммированных криптографических ключей. И все это без необходимости доступа к исходному коду!

Как работает Binwalk?

Главной особенностью binwalk является сканирование сигнатур. Binwalk может сканировать образ встроенного ПО для поиска различных типов встроенных файлов и файловых систем.

Вы знаете утилиту командной строки file, верно?

Команда file просматривает заголовок файла и ищет подпись (магическое число), чтобы определить тип файла. Например, если файл начинается с последовательности байтов 0x89 0x50 0x4E 0x47 0x0D 0x0A 0x1A 0x0A, он знает, что это файл PNG. Проверьте эту страницу Википедии для получения списка распространенных сигнатур файлов.

Binwalk работает так же. Но вместо того, чтобы искать сигнатуры только в начале файла, binwalk просканирует весь файл. Кроме того, binwalk может извлекать файлы, найденные в образе.

Оба инструмента file и binwalk используют библиотеку libmagic для идентификации подписей файлов. Но binwalk дополнительно поддерживает список пользовательских магических сигнатур для поиска сжатых/архивных файлов, заголовков микропрограмм, ядер Linux, загрузчиков, файловых систем и т. д.!

А теперь повеселимся?

Установка Binwalk

Binwalk поддерживается на нескольких платформах, включая Linux, OSX, FreeBSD и Windows.

Чтобы установить последнюю версию binwalk, вы можете загрузить исходный код и следовать процедурам установки или руководству по быстрому запуску, доступному на веб-сайте проекта.

У Binwalk есть много вариантов:

Теперь мы готовы сканировать образы прошивки.

Сканирование образа прошивки с помощью binwalk

Давайте начнем с поиска сигнатур файлов внутри изображения (я скачал это изображение с веб-сайта TP-Link).

Запуск binwalk с параметром --signature сделает эту работу:

Теперь у нас есть много информации об изображении!

В образе используется U-Boot в качестве загрузчика (заголовок образа по адресу 0x5AC0 и сжатый образ загрузчика по адресу 0x5B00). Основываясь на заголовке uImage по адресу 0x13270, мы знаем, что архитектура процессора — MIPS, а ядро ​​Linux — версии 3.3.8. И на основании образа, найденного по адресу 0x11CEA5, мы видим, что rootfs — это файловая система squashfs.

Теперь давайте извлечем загрузчик (U-Boot) с помощью команды dd:

Поскольку изображение сжато с помощью LZMA, нам нужно его распаковать:

Теперь у нас есть образ U-Boot:

Как насчет поиска значения по умолчанию для переменной среды bootargs?

Переменная среды U-Boot bootargs используется для передачи параметров ядру Linux. Из приведенных выше выходных данных мы лучше понимаем структуру флэш-памяти устройства.

Как насчет извлечения образа ядра Linux?

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

Формат файла uImage в основном представляет собой образ ядра Linux с дополнительным заголовком. Итак, давайте удалим этот заголовок, чтобы получить окончательный образ ядра Linux:

Изображение сжато, поэтому распаковываем его:

Теперь у нас есть окончательный образ ядра Linux:

Что мы можем сделать с образом ядра? Например, мы могли бы искать строки в образе, чтобы найти строку версии ядра Linux и узнать о среде, используемой для сборки ядра:

Хотя прошивка была выпущена в прошлом году (август 2019 г.), когда я пишу эту статью, в ней используется старая версия ядра Linux (3.3.8), выпущенная в 2012 г., скомпилированная с очень старой версией GCC (4.6), также выпущенной в 2012 г.!< /p>

С опцией --opcodes мы также можем использовать binwalk для поиска машинных инструкций и определения архитектуры ЦП образа:

А как насчет корневой файловой системы? Вместо того, чтобы вручную извлекать изображение, давайте воспользуемся опцией --extract binwalk:

Полная корневая файловая система будет извлечена в подкаталог:

Теперь мы можем многое!

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

С помощью qemu и chroot мы даже можем запускать (эмулировать) исполняемый файл из образа!

Круто! Но обратите внимание, что версия BusyBox — 1.19.4. Это очень старая версия BusyBox, выпущенная в апреле 2012 года.

Итак, TP-Link выпускает образ прошивки в 2019 году с использованием программного обеспечения (инструментарий GCC, ядро, BusyBox и т. д.) из 2012 года!

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

Еще интересные вещи

Binwalk также может выполнять анализ энтропии, распечатывая необработанные данные об энтропии и создавая графики энтропии. Энтропия будет высокой, когда байты в изображении выглядят случайными, и это может означать, что изображение содержит зашифрованный, сжатый или запутанный файл или даже жестко запрограммированный криптографический ключ!

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

Пользовательские подписи можно добавить в binwalk либо через файл настраиваемых подписей, указанный в командной строке с помощью параметра --magic, либо добавив их в свой $HOME/.config/binwalk каталог /magic.

Дополнительную информацию о binwalk можно найти на странице использования официальной документации.

Расширение binwalk

Существует API-интерфейс binwalk, реализованный в виде модуля Python, который может использоваться любым скриптом Python для программного сканирования binwalk, а утилита командной строки binwalk может быть почти полностью продублирована всего двумя строками Python. код!

С помощью API Python вы также можете создавать подключаемые модули Python для настройки и расширения binwalk.

Также доступен подключаемый модуль IDA и облачная версия Binwalk Pro.

Так почему бы вам не скачать какой-нибудь образ прошивки из Интернета и не попробовать самостоятельно? Обещаю, вам будет очень весело!

Об авторе: Серджио Прадо работает со встроенными системами более 20 лет. Если вы хотите узнать больше о его работе, посетите страницу «О нас» или веб-сайт Embedded Labworks.

Инструмент анализа и сравнения встроенного ПО (FACT) – это набор инструментов для автоматизации анализа двоичных файлов устройств Интернета вещей, сетевых устройств, дронов, UEFI и т. д.). Этот инструмент поставляется с красивым веб-интерфейсом, и вам просто нужно загрузить на него тестовый двоичный файл. Этот инструмент автоматизирует весь процесс с помощью различных инструментов, таких как binwalk, QEMU и т. д.

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

< td>Используя такие инструменты, как binwalk, Firmadyne и т. д.
Извлечение двоичного файлаИзвлечение двоичного файла — это первая задача, выполняемая специалистом по безопасности. Двоичный файл может быть извлечен с использованием различных методов, таких как использование флэш-памяти SPI, JTAG, использование уязвимости в механизме обновления, с официального веб-сайта и т. д.
Сбор информации
Сбор уязвимостейВыявление секретов, таких как ключи API, пароли и т. д.
Обратный инжинирингС помощью Ghidra, IDA Pro и т. д.

Преимущество использования FACT

  • Объединяйте разные результаты с помощью инструмента.
  • Быстро и быстро начать работу
  • Простота в использовании, так как нужно просто загрузить двоичный файл в инструмент.
  • Графический веб-интерфейс
  • Сравните две версии прошивки
  • Автоматизировать такие задачи, как распаковка, сбор информации и т. д.
  • различные плагины для распаковки, анализа и сравнения доступны для анализа эльфов, анализа исходного кода, известных уязвимостей и т. д.

Установка

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

Использование

После успешной установки выполните следующую команду:

Для начала просто загрузите двоичный файл в инструмент FACT и запустите его. Инструменту обычно требуется 10–15 минут, чтобы проанализировать двоичный файл и предоставить результаты.

Связанные

Подпишитесь на нас, чтобы получать больше таких обновлений статей по электронной почте.

Если у вас есть какие-либо вопросы, не стесняйтесь задавать их в разделе комментариев ниже. Ничто не доставляет мне большей радости, чем помощь моим читателям!

Отказ от ответственности: это руководство предназначено только для образовательных целей. Лицо несет единоличную ответственность за любые незаконные действия.

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

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

  • Адрес загрузки: binbloom может анализировать необработанную двоичную прошивку и определять ее адрес загрузки.
  • Окончание байтов: binbloom может использовать эвристику для определения порядка байтов встроенного ПО.
  • База данных UDS: binbloom может анализировать необработанную двоичную прошивку и проверять, содержит ли она массив, содержащий идентификаторы команд UDS.

Сначала клонируйте репозиторий git:

Чтобы собрать последнюю версию:

Чтобы установить последнюю версию (только для Linux):

Определить порядок следования байтов

Эта команда должна выдать следующий вывод:

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

Определить адрес загрузки

Во-первых, вы должны предоставить файл, содержащий список возможных адресов функций в шестнадцатеричном формате (по одному в строке), например:

Этот файл должен называться в честь самой прошивки, а затем иметь расширение ".fun".

Этот файл можно сгенерировать с помощью функции tag_code() предоставленного скрипта Python tag_code.py с помощью IDA Pro:

  • Загрузите прошивку в IDA Pro по адресу 0 (выберите правильную архитектуру/порядок байтов)
  • В меню "Файл" выберите "Файл сценария" и выберите tag_code.py.
  • В консоли в нижней части IDA Pro используйте tag_code() . Файл функций создается автоматически.

Если вы предпочитаете использовать другой инструмент для создания файла функций, вы можете сделать это, если загружаете прошивку по адресу 0 (т. е. шестнадцатеричные значения в файле функций соответствуют смещениям в прошивке).

Эта команда должна выдать следующий вывод:

В этом выводе мы видим, что на 14903 предоставленных потенциальных функциях 1545 были найдены в массивах указателей функций, когда программа принимает предположение, что адрес загрузки равен 0x80010000.

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

Здесь у нас есть участок кода по адресу 0x00000000 и еще один по адресу 0x00040000.

Binbloom создает 2 выходных файла:

  • firmware.fad: этот файл содержит адреса идентифицированных функций
  • firmware.fpt: этот файл содержит адреса указателей на идентифицированные функции

Теперь вы можете снова запустить IDA Pro (или любую программу обратного проектирования), загрузить прошивку по указанному адресу и импортировать адреса 1545 идентифицированных функций:

  • Загрузить прошивку в IDA Pro по указанному адресу (в данном примере 0x80010000)
  • В меню "Файл" выберите "Файл сценария" и выберите import_entry_points.py.
  • Выберите файл .fad.
  • Выберите файл .fpt.

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

-E b : включить режим с прямым порядком байтов

-E l : включить режим с прямым порядком байтов

Найти базу данных UDS (для прошивки ЭБУ)

binbloom может попытаться выполнить поиск в массиве, содержащем идентификаторы UDS/KWP2000, с параметром -u:

Эта команда должна выдать следующий вывод:

Эти выходные данные показывают, что по адресу 0x1234 потенциальная база данных UDS была найдена с шагом 12 (это означает, что идентификаторы UDS присутствуют в массиве, в котором каждый элемент имеет длину 12 байт). В этом примере идентификаторы UDS находятся в первом столбце (10, 11, 22, 27, 28, 2e, 31, 34, 36, 37, 3e и 85).

Список поддерживаемых идентификаторов UDS жестко задан в binbloom.c, при необходимости его можно изменить.

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

В этом примере мы видим, что в каждой строке есть указатель с прямым порядком байтов (26 27 00 80 для первой строки, которая соответствует адресу 0x80002726). Вероятно, по этому адресу есть функция для управления UDS-командой 10. Вам нужно разобрать код, чтобы убедиться в этом, и поискать перекрестные ссылки на эту базу данных UDS.

Ранее мы писали о внедрении обновления прошивки для наших устройств. Одна важная деталь, которую мы не рассмотрели, — это безопасность обновлений встроенного ПО.

Многое можно сделать и написать о безопасности обновлений встроенного ПО, но, возможно, самым важным моментом является подписание встроенного ПО.Другие меры безопасности бесполезны, если мы не можем проверить подлинность обновления прошивки!

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

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

Нравится прерывание? Подпишитесь, чтобы получать наши последние публикации прямо в ваш почтовый ящик.

Содержание

Подписание прошивки

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

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

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

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

Когда подпись создается для двоичного файла микропрограммы, она однозначно привязывается к этой конкретной микропрограмме. Изменение двоичного файла хотя бы на 1 бит приведет к другой подписи.

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

Зачем подписывать наши прошивки

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

Поскольку все больше и больше устройств подключаются к Интернету, безопасность становится все более актуальной темой при разработке встроенного ПО. Устройство, которое принимает обновления встроенного ПО по беспроводной сети или через Интернет, но не проверяет их, открывает себя для взлома. Скармливая ему вредоносный образ микропрограммы, злоумышленник может:

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

Это крайне нежелательные результаты, которые могут быть достигнуты в больших масштабах благодаря Интернету вещей. В 2020 году будет безрассудно обновлять встроенное ПО для наших систем без какой-либо формы аутентификации.

Чем не является подпись: подпись кода является важным компонентом безопасности прошивки, ее самой по себе недостаточно для создания безопасных систем. Также должны быть реализованы безопасное кодирование, статический анализ, обнаружение несанкционированного доступа к оборудованию, блокировка JTAG и многие другие методы. Подписание кода также не защищает от обратного проектирования. Это метод, отличный от шифрования прошивки.

ECDSA

Для подписи прошивки можно использовать несколько алгоритмов, включая RSA, DSA и ECDSA. В этом посте мы сосредоточимся на ECDSA по нескольким причинам:

  1. Безопасность. ECDSA — это новейший и лучший алгоритм подписи. Хотя большинство считает, что стандартный DSA нарушен, ожидается, что ECDSA останется безопасным до тех пор, пока квантовые вычисления не станут широко доступными.
  2. Популярность. ECDSA широко используется в различных приложениях, от криптовалют (биткойн) до безопасного обмена сообщениями. С популярностью приходят проверенные на практике реализации и надежность.
  3. Доступность. Для микроконтроллеров доступны реализации ECDSA с открытым исходным кодом, включая mbedtls 1 , wolfssl 2 и micro-ecc.
  4. Небольшой размер. Реализации ECDSA очень малы (одна цифра в килобайтах) и требуют ключей меньшего размера, чем RSA или DSA, для аналогичного уровня безопасности. Это экономит место для кода и оперативную память, а также делает ECDSA подходящим для встроенных сред.

Понимание математики ECDSA выходит за рамки этой статьи, но вот общий обзор того, как работает этот процесс:

  1. Создается криптографический хэш двоичного файла микропрограммы. Должен работать любой алгоритм криптографического хеширования, хотя рекомендуются хэши семейства SHA-2. В случае SHA-256 это дает 32-байтовое число.
  2. Подпись создается с использованием закрытого ключа и криптографического хэша.Эта подпись распространяется вместе с прошивкой и открытым ключом. Подпись может быть недетерминированной, поэтому не беспокойтесь, если несколько вызовов вашего кода ECDSA дадут разные подписи. Эта подпись представляет собой пару целых чисел, каждое из которых имеет длину 32 байта.
  3. Чтобы проверить двоичный файл, для двоичного файла микропрограммы еще раз вычисляется хэш SHA-256.
  4. Открытый ключ и хэш можно использовать для проверки того, что подпись была сгенерирована с использованием совпадающих входных данных.

Реализация подписи встроенного ПО

Наша реализация основана на коде, который мы написали для публикации об архитектуре обновления микропрограммы. Вы можете найти этот код на Github по адресу interrupt@20ec4ba.

Настройка

Как и в предыдущем посте «Пособие по обновлению прошивки», мы используем Renode для запуска примеров из этого поста. В предыдущем посте есть подробная инструкция, но вкратце:

Одно изменение, которое мы сделали по сравнению с предыдущими публикациями, — это запуск в автономном режиме. Это делается путем вызова Renode со следующими флагами:

Затем мы можем использовать telnet для подключения к консоли Renode:

Аналогичным образом мы направляем UART устройства к порту telnet, а не к графическому окну, добавляя две строки в наш renode-config.resc :

Затем мы можем получить доступ к UART нашего эмулируемого устройства через telnet:

Архитектура

Напоминаем, вот как выглядит архитектура обновления встроенного ПО нашего устройства:

Читайте также: