Всем привет,

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

Не знаю как у Вас, у меня загрузчик обрабатывает данные из hex файла, там два поля АДРЕС и ДАННЫЕ (до 16 байт). Контроллер анализирует поле АДРЕС и выполняет запись во flash или eeprom. Можно, по аналогии, заставить линкер формировать еще область данных с физически несуществующим в микроконтроллере адресом. Когда прийдут данные для записи в это адресное пространство, то направлять из в блютуз. А вот данные запихнуть в прошивку прийдется "ручками".

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

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



Надеялся что есть какието открытые стандарты, где уже учтен опыт проб и ошибок, как пользуют например motorola или nokia или тотже apple.
Вот, например: http://droid-dev.mobi/wiki/SBF

Напишите все требования к протоколу сразу. Два уже есть.

Даже не пытался искать. За пару недель написал своё. Нижний уровень tag-length-value-crc пакеты. С их помощью сериализуется описание прошивки, ключи, интерфейс для прошивания, фильтры для аппаратных различий ну и собственно прошивки. Умеет прошивать несколько чипов разного типа по разным интерфейсам в одном файле-архиве. Обмен ключами - ecdh с подписью ecdsa в кач-ве симметричного - банальный aes. Тот же формат использую для начальных настроек бутлоадера.

Как делаю я.
1. IAR формирует hex файл.
2. На этапе postbuild в этот файл автоматически (давно написанной утилитой) добавляется заголовок (номер версии, тип процессора, название проекта, идентификатор клиента), затем всё это шифруется.
3. Конечный файл можно размещать на сайте или пересылать клиентам по открытым каналам.
4. Затем этот файл с помощью другой утилиты заливается в контроллер, где данные принимает загрузчик, налету расшифровывает и записывает во Flash.
5. Так как запись производится в процессе передачи данных, то скорость прошивки определяется скоростью записи в память. Скорость канала не является критичной, например скорости 115200 мне всегда хватало.
6. Проверено на STM8, STM32 и некоторых контроллерах других семейств. Утилиты являются универсальными, аппаратные различия на уровне загрузчика в контроллере.

Этих форматов очень много. Практически каждый производитель придумывает свой формат упаковки фирмваре.
Я встречал такое у Nordic, TI, Microchip-Atmel, Freescale-NXP и т.д.

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

Самое интересное это фреймворк на PC с поддержкой базы данных образов фирмваре, разными форматами хэширования, сжатия и подключением по разным физическим каналам.
У меня есть такой в исходниках в RAD Studio 10.1 , поддерживать может неограниченное количество загружаемых образов. Работает как с HEX так и с BIN.

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

Тогда задам вопрос иначе, мой бутлодер вырос из уровня передачи бин\хекс файла, до уровня сжатия данных, сейчас планируется добавление крипто механизмов, планирую использовать какой либо асимметричный алго. Тут встает воспрос генерации\храннения закрытых ключей, и мне интересно как принято это организовывать? Используют один закрытый ключ для одного устройспа зашиваемый на производстве и фирмваря для этих девайсов всегда шифруется одним ключем? используют ли для этих случаев резервные ключи? какие есть механизмы "сброса" ключа в случае утечки? Насколько надежно использовать генерацию ключа из серийника проца+серийника какой либо обвязки(флеш, BTили чтото еще), понятно в этом случае этап шифрования переноситься на сервер с которого скачивается ПО, повторюсь на сколько это надежно? Если ли опыт подобного использования? Как быть с дебажным ПО, всегда шифровать\подписывать?

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

Зачем резервный ключ? Принцип же - запрограммировал и забыл.
Сброс от утечки чего? Ключа? Или программиста?


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

Поэтому вам надо найти в этом форуме конкретно ветку по семейству которое применяете вы и там конкретно спрашивать.
Скажем для Kinetis введение в защищенный криптозагрузчик будет здесь - http://www.nxp.com/assets/documents/data/e...KBTLDR200RM.pdf
Мало не покажется.
Но это цветочки, на горизонте уже TrustZone
Поэтому коня в вакууме под названием "развитый защищенный универсальный загрузочный контейнер" вы не найдете.

Механизмы "сброса" ключа в случае утечки есть, как на аппаратном уровне, так и на программном. Например такое начал использовать лет пять назад после ряда случаев. А далее эти бэкдоры например для массовой продукции стали не нужны, из-за высоких темпов обновления лиенйки продуктов. Но в новых продуктах конечно использую свой загрузчик с криптованной прошивкой.
И не понятно, зачем бутлодер вырос из уровня передачи бин\хекс файла, до уровня сжатия данных?
Серийник проца не использую, было такое, но из-за длины отказался. Асимметричный думаю избыточен.
Не уверен, что описание форматов и функционала подобных рабочих контейнеров вы найдете, разве если ктото свой г..код выложит. А так у каждого свои слоны и муравьи. А так в общих чертах все чего то да напишут, что чего куды и как; ... rsa, dsa, aes и пт в помощь.