А для распаковки?

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

2ТС: ознакомьтесь для начала с атмеловскими аппликациями

Да.

Нет.

Да

Ну а поскольку у меня в прошивках контроллера встречается, как правило, прошивка FPGA, то пред шифровкой использую простейшее RLE подобное сжатие.

Кода-то от него и отталкивался. Только там есть
- как минимум одна ошибка при обработке нештатых ситуаций(забыл какая конкретно, поскольку сразу все начал переписывать);
- все писано небрежно, а AES уж слишком в лоб . AES подлежит оптимизации (однажды на форуме была стихийно возникшая тема в которой выкладывал эти исходники хоть как-то оптимизипрванные под AVR).

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

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

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

На моих платформах всегда применяется сжатие для фирмваре, и даже несколько алгоритмов.
И как правило коэффициент сжатия больше 2-х даже на простых алгоритмах типа LZSS.
Поскольку часто апгрейд идет через GSM и другие медленные каналы то любые лишние 100K чувствуются.

Спасибо всем за каменты
То есть, я так понимаю,
1. не столько важно зашифровать исходник, чем запаковать и зашифровать чем-то исходник
2. Просто зашифрованная прошивка тем же AES, 3DES поддастся анализу? (текстовых блоков нет, передаваемых подряд констант по внешнему каналу максимум 128 бит уже в рабочем девайсе)
3. Сама прошивка ~64 KB
4. Перестановка блоков прошивки (например, отдельное шифрование+сжатие блоков по 512,1К.2К) для каждого конкретного девайса может дополнительно помочь?

Что важно, а что нет - решать вам, под задачу. Если надо экономить время при передаче массива, то сжимать важно, если нет - то нафиг надо, только время зря тратить на распаковку и на написание сложного бутлодера.


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


Нет.

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

Намёк понятен.
Передавать не зашифрованную прошивку, а зашифрованную "разницу".
Это реализовывалось и в основном работает.

Вообще самое правильное для удаленной прошивки - передавать скрипт для скриптового движка. При таком решении вся прошивка может байт 100 занимать.

Что-то не совсем понятно, поясните как будет работать обновление ?

можно посмотреть? полазил поиском AES* - пересмотрел несколько страниц, не нашел
хотя, конечно, более интересуют реализации, заточенные под 32-бит архитектуру

ChaCha выглядит привлекательно. Salsa20/12 тоже неплохо.


Прикладное ПО выполнено в виде скрипта. Новый скрипт загрузил - вот и обновился.

Ага-ага. Щас. Я глянул - LZ как LZ. Причем по древним боянным технологиям хранения ссылок назад. С поддержкой двухбайтовых ссылок назад. Я таких написался пятнадцать лет назад дофига.

Да, там действительно была какая-то стихийно возникшая тема по оптимизации загрузчика, где на этом атмеловском исходнике тренировались.
А этот атмеловский исходник живущий у меня под ARM, с оптимизацией, но помнится, без какой-то особой оптимизации конкретно под ARM - в приложении. Хотя, возможно, это не последний вариант - то, что сейчас нашлось на одном из компьютеров.
memcpy_z(). замените на memcpy(). bint для ARM это int. Для AVR bint это unsigned char. Все остальное без изменений.

то есть, вся адаптация под ARM того самого AVR231 сводится только к замене функции memcpy_z() ?

Разумеется нет . просто я правил это изрядно давно, когда memcpy() у IAR было чрезмерно тормозным. Посему использовалась самодельная. Сейчас это без надобности.

итого
берем атмелевский пример и не заморачиваемся? компилятор сам разберется с оптимизацией байтовых операций?