[meister 0]

Да со минимальным знанием конкретики (таблица векторов, их контрольная сумма в ней, известное содержимое 0x1FC) такое и просто в лоб (а если еще и hiew/qview подобную утилитку вместо клочка бумаги :) .... )ломается и без всяких правильных методик на 1-2-3.

 

Загрузчик-то нешифрованный :))) и, например, моя прога, которая шифрует обновление прошивки, загрузчик вообще откусывает, потому как он лишний в этом файле.

 

Я шифрую с помощью tiny encryption algorithm, читал, что он довольно стойкий для одного абзаца кода.

[zltigo 1]

Загрузчик-то нешифрованный :)))

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

 

 

читал, что он довольно стойкий...

Для того, что бы не заморачиваться чтением рассуждений на эту тему использую AES256 :)

[Step68 0]

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

Для того, что бы не заморачиваться чтением рассуждений на эту тему использую AES256 :)

Возможно ты и прав, zltigo... Но ведь подобные алгоритмы занимают довольно много flash и медленновато работают на контроллерах(в нашем случае, вроде, некритично). Ты говоришь, что XOR со сдвигом быстро ломается? Разговоры , типа "ломается на 1-2-3"--лишь разговоры.

Может попробуешь?

Вариант 1

Исходные 4 байта 61A0DE88

Конечные 4 байта C0302FD8

Вариант 2

Исходные 4 байта FF5BA8C6

Конечные 4 байта 1AE5DE55

 

Если еще надо спроси...

Даже если тебе дать алгоритм, то на вычисление маски и смещения уйдет уйма времени.

Если использовать кодирование по 8 байт еще дольше провозишься.

Если конечно ты не везунчик и при первом же случайном выборе не попадешь в точку:-)))

 

 

Ломается элементарно. Поверхностное описание методики взлома было, кажется, у Скляра в "Цифровой связи".

Все ломается. Только сколько времени и сил уйдет? См. ниже.

 

DES или AES в AVR реализовать ваще не проблема, так уже делали.

Здесь проблема в том, что загрузчик тоже шьет заказчик. Читайте весь топик.

Sorry... Это получается типа картриджа для сотовых телефонов?

 

 

Сложность программ как-то коррелирует с серийностью их выпуска?

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

 

Еще одна идея.

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

Програмируется устройство аппаратной железякой. Железяка кроме интерфейса с програмируемым процом имеет еще и свой интерфейс с серийником.

Железяка читает серийник платы. Сравнивае, не работала ли она ранее с этим серийником.

Вставляет его (или функцию от него) в нешифрованный загрузчик.

Грузит его в проц и закрывает флешь от чтения.

Загрузчик в проце запускается, читает серийник с платы и если он совпадает готова к прошивке целевой программы.

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

Целевая прога стартует, сравнивает серийник на плате и если он тот, то стартует.

Железяка инкрементирует счетчик.

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

Понимаю, дыра есть, но покритикуйте сложность взлома.

Есть тут одна сложность. Кто держатель этой железяки? Например, это дилер по месту продажи. Так вот, дилеры, обычно, далекие от техники люди и ни за что не хотят свзываться с перешивкой изделий.

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

Кстати не все фирмы закрывают свое ПО. Исходят из того, что массово повторить изделие довольно сложно.

 

Еще одна идея.

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

Програмируется устройство аппаратной железякой. Железяка кроме интерфейса с програмируемым процом имеет еще и свой интерфейс с серийником.

Железяка читает серийник платы. Сравнивае, не работала ли она ранее с этим серийником.

Вставляет его (или функцию от него) в нешифрованный загрузчик.

Грузит его в проц и закрывает флешь от чтения.

Загрузчик в проце запускается, читает серийник с платы и если он совпадает готова к прошивке целевой программы.

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

Целевая прога стартует, сравнивает серийник на плате и если он тот, то стартует.

Железяка инкрементирует счетчик.

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

Понимаю, дыра есть, но покритикуйте сложность взлома.

Есть тут одна сложность. Кто держатель этой железяки? Например, это дилер по месту продажи. Так вот, дилеры, обычно, далекие от техники люди и ни за что не хотят свзываться с перешивкой изделий.

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

Кстати не все фирмы закрывают свое ПО. Исходят из того, что массово повторить изделие довольно сложно.

[zltigo 1]

Но ведь подобные алгоритмы занимают довольно много flash...

"Много" это сколько в байтах? Куда,например девать оставшиеся байты в секторе боотлоадера?

При этом поминаемый ранее TEA совершенно микроскопический, но имеет оцененный уровень криптостойкости. Да и тот-же AES256 занимает у меня в загрузчике порядка 900 байт (без особой опримизации под 32bit), при этом в bootsector-е еще почти 900 байт остаются для развития.

Разговоры , типа "ломается на 1-2-3"--лишь разговоры.

Отнюдь :( всякое приходилось лично вытворять в 80x-90x годах - в то время, когда считающие, что просто XOR c легкими наворотами это круто, еще не вымерли.

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

Ссылок не будет и исходников не будет. А моя область применения LPC это в основном телекомуникационое оборудование. Например, поддержка протоколов:

♦ SS7 MTP3: ITU-T Q.704, Q.707, ETSI 300

008, 300 008-1, ANSI T1.111, Bellcore

GR246, GR606, GR82

♦ SS7 MTP2: ITU-T Q.703, ETSI 300 008,

300 008-1, ANSI T1.111, TTC JT-Q.703,

ITU Q.703 Annex A 1996, China

SS7 YD/T 1125 - 2001

♦ SS7 MTP signaling performance ITU-T

Q.706

♦ M3UA: RFC 3332

♦ M2PA: IETF

♦ SCTP: RFC 2960, RFC 3309

♦ LAPB/D: Q.921, TR 41449, TR 62411

♦ LAPF:Q.922

♦ LAPV5

♦ X.25: CCITT

 

Гуглом найдете, что это такое

[Step68 0]

Отнюдь :( всякое приходилось лично вытворять в 80x-90x годах - в то время, когда считающие, что просто XOR c легкими наворотами это круто, еще не вымерли.

 

Ссылок не будет и исходников не будет. А моя область применения LPC это в основном телекомуникационое оборудование. Например, поддержка протоколов:

♦ SS7 MTP3: ITU-T Q.704, Q.707, ETSI 300

008, 300 008-1, ANSI T1.111, Bellcore

GR246, GR606, GR82

♦ SS7 MTP2: ITU-T Q.703, ETSI 300 008,

300 008-1, ANSI T1.111, TTC JT-Q.703,

ITU Q.703 Annex A 1996, China

SS7 YD/T 1125 - 2001

♦ SS7 MTP signaling performance ITU-T

Q.706

♦ M3UA: RFC 3332

♦ M2PA: IETF

♦ SCTP: RFC 2960, RFC 3309

♦ LAPB/D: Q.921, TR 41449, TR 62411

♦ LAPF:Q.922

♦ LAPV5

♦ X.25: CCITT

 

Гуглом найдете, что это такое

 

Я безумно напуган всеми этими названиями, zltigo. :-))) Ты еще не все протоколы назвал, zltigo(etc. Злой тиго).

 

А насчет XORов... Я же тебе послал байты для дешифровки.

 

Дело в том , что НЕТ смысла закрывать ПО сложными алгоритмами.

Предположим что ты взломал алгоритм декодировал ПО, у тебя есть схема и разводка... Но ведь чтобы сделать и ПРОДАТЬ изделие в количествах опасных для первого производителя надо потрудиться.

 

А то AES, DES... нафига?

[shahr 0]

Это я видел. Для меня было бы понятнее если бы написали конкретно -- в девайсах менее 512к флэш пользователя не занята 8к загрузчика. Спасибо.

 

эта мысль и изложена в даташите :)

[zltigo 1]

Moderator:

Часть ветки перенесена в оффтопик.

http://electronix.ru/forum/index.php?showtopic=50537&hl=

[HARMHARM 0]

...

При этом поминаемый ранее TEA совершенно микроскопический, но имеет оцененный уровень криптостойкости. Да и тот-же AES256 занимает у меня в загрузчике порядка 900 байт (без особой опримизации под 32bit), при этом в bootsector-е еще почти 900 байт остаются для развития.

...

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

[zltigo 1]

Задайте побольше и все, если вы настолько озабочены безопастностью.

Если-бы Вы прочитали мои посты в этой ветке, то поняли-бы, что я не являюсь озабоченным безопасностью человеком. AES используется в качестве обычно-стандартного алгоритма занимающего достаточно скромные для меня ресурсы. Изобретать "консервные банки" разваливающиеся от одного взгляда на них или в противоположность разыскивать параноидальные алгоритмы я не собираюсь.