[toweroff 0]

Добрый день!

Есть бут, который принимает прошивку и пишет во внутреннюю флеш

Соответственно, хочется ее зашифровать

Кто что использует для этого и насколько эффективны и сложны в реализации разные методы?

 

Спасибо

[ILYAUL 0]

Добрый день!

Есть бут, который принимает прошивку и пишет во внутреннюю флеш

Соответственно, хочется ее зашифровать

Кто что использует для этого и насколько эффективны и сложны в реализации разные методы?

 

Спасибо

А как сам проц будет выполнять зашифрованный код? :laughing: Как Вы это себе представляете на аппаратном уровне - он же сам расшифровывать вроде как не умеет , по причине полной тупизны?

[toweroff 0]

А как сам проц будет выполнять зашифрованный код? :laughing: Как Вы это себе представляете на аппаратном уровне - он же сам расшифровывать вроде как не умеет , по причине полной тупизны?

наверное, я не совсем ясно выразил мысль :)

конечно, "на лету" ничего расшифровываться не будет

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

[yashok 0]

Я шифрую по алгоритму Triple DES (3DES). При заливке на ходу расшифровывается и пишется во флэш. Процы из серии lpc 17xx с прошивкой ~500 kB прошиваются чуть меньше чем за 6 мин.

Вся эта защита необходимо если перепрошивкой занимается конечный пользователь.

[AlexandrY 3]

наверное, я не совсем ясно выразил мысль :)

конечно, "на лету" ничего расшифровываться не будет

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

 

Лучше сжать, а потом зашифровать. И зашифровать в режиме CBC по 3DES или AES. В начало вставить блок случайных данных. Потом все подписать хешем по SHA1.

На STM32F2 это все делается особо просто.

 

[toweroff 0]

у меня LPC2929

со сжатием интересно, спасибо за совет

единственное - памяти на борту только внутренняя контроллера, часть которой использутся под буферы

хватит оставшихся 16-20 кб на распаковку и дешифрацию?

[AlexandrY 3]

у меня LPC2929

со сжатием интересно, спасибо за совет

единственное - памяти на борту только внутренняя контроллера, часть которой использутся под буферы

хватит оставшихся 16-20 кб на распаковку и дешифрацию?

 

16 кБ это разве что на RLE алгоритм хватит.

Можно конечно в алгоритмах сжатия регулировать требуемый объем памяти.

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

 

 

[Tanya 4]

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

А кусками?

[=AK= 10]

хватит оставшихся 16-20 кб на распаковку и дешифрацию?

Используйте XTEA, ему совсем мало места надо.

 

А если хочется, чтобы и просто, и быстро, то сделайте простой потоковый шифр на 32-битном LFSR. Для практики этого будет более чем достаточно, имхо.

[AlexandrY 3]

А кусками?

 

Ну так уменьшение heap-а в LZ алгоритмах это и есть фрагментация процесса сжатия. Она и ухудшает показатель сжатия.

 

Есть алгоритм UCL который как утверждается не требует памяти на декомпрессию.

Но не пробовал.

 

А если хочется, чтобы и просто, и быстро, то сделайте простой потоковый шифр на 32-битном LFSR. Для практики этого будет более чем достаточно, имхо.

 

RC4 будет быстрее чем LFSR. А применяется в серьезных технологиях VPN.

[=AK= 10]

RC4 будет быстрее чем LFSR.

Мне это неочевидно. Всегда думал, что самый простой и эффективный цифровой генератор псевдобелого шума - это LFSR

 

А применяется в серьезных технологиях VPN.

Там оправдано, более того - необходимо применение более сложных алгоритмов, чем простейший LFSR.

[AlexandrY 3]

Мне это неочевидно. Всегда думал, что самый простой и эффективный цифровой генератор псевдобелого шума - это LFSR

 

Нелинейный LFSR применяют в автомобильных радиобрелках, как известно, и в донглах типа eToken, где предельно мало RAM-а.

Но прокручивать там этот регистр приходится сотни раз! для одного сэмпла.

[Tanya 4]

Ну так уменьшение heap-а в LZ алгоритмах это и есть фрагментация процесса сжатия. Она и ухудшает показатель сжатия.

Мне вот кажется, что прошивки мало отличаются одна от другой...

[AlexandrY 3]

Мне вот кажется, что прошивки мало отличаются одна от другой...

 

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

Отличаться есть чем, хотя не понял к чему это утверждение в данном контексте.

[Tanya 4]

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

Отличаться есть чем, хотя не понял к чему это утверждение в данном контексте.

Я имела в виду возможность использования одного и того же дерева. Кроме всего прочего, можно же менять (даже двигать) куски (фрагменты).