Шифрование прошивки, кто что использует Опции

[toweroff]

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

Спасибо

[toweroff]

у меня LPC2929
со сжатием интересно, спасибо за совет
единственное - памяти на борту только внутренняя контроллера, часть которой использутся под буферы
хватит оставшихся 16-20 кб на распаковку и дешифрацию?

[AlexandrY]

у меня LPC2929
со сжатием интересно, спасибо за совет
единственное - памяти на борту только внутренняя контроллера, часть которой использутся под буферы
хватит оставшихся 16-20 кб на распаковку и дешифрацию?

16 кБ это разве что на RLE алгоритм хватит.
Можно конечно в алгоритмах сжатия регулировать требуемый объем памяти.
Но для сжатия хотя бы в два раза бинарной прошивки объемом в пару сотен килобайт LZ подобным алгоритмом нужно минимум 64 Кб RAM.

[MrYuran]

Но для сжатия хотя бы в два раза бинарной прошивки объемом в пару сотен килобайт LZ подобным алгоритмом нужно минимум 64 Кб RAM.

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

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

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

[zltigo]

Естественно, мелкоконтроллерам до этого как до луны.

Да.

Ну и стоит ли геморрой свеч?

Нет.

Разве что как дополнительная степень защиты. Так для этого можно и попроще алгоритм применить.

Да

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

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

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

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

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

[toweroff]

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

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

[zltigo]

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

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

Прикрепленные файлы

 aes_atmel.rar ( 2.26 килобайт ) Кол-во скачиваний: 68

 

[toweroff]

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

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

[zltigo]

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

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

[toweroff]

Разумеется нет

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