Генерировать случайные числа буду через АЦП, например так: провёл 1000 замеров, три младших разряда суммы результатов -трёхзначное случайное число. Защёт погрешности АЦП результат будет абсолютно непредсказуемый и случайный.
Ну больше подходящих вариантов я невижу, а так хоть какаято защита.
И ещё очень легко организуема, вызовет зависание:
...
while (OSCCAL!=0x6A)
{
};
...

Кстати, я надеюсь калибровочную константу МК изменить нельзя?

Сообщение отредактировал Alex@ndr - Dec 26 2006, 00:52

Ну если есть хотя-бы минимум доверия, то можно поступить следующим образом: разделить задачу на две части, на bootloader который вы отдаете свободно, который, так сказать готовит камень заказчика (вот здесь то и нужно доверие, если вы конечно хотите знать на какое конкретно устройство все это будет установлено) который генерирует пару не симметричных ключей (DES, SHA или еще что…) и сохраняет их, открытый ключ bootloader сообщает пользователю, он вам, вы шифруете этим ключом firmware и передаете заказчику, при установке bootloader с помощью закрытого ключа его расшифровывает и программирует в камень по пути устанавливая все флаги, вот собственно и все.

Кстати, за основу можно взять Application Notes AVR231, там не так много надо переделовать

делайте случайное число от таймера, проттос дело говорит.

А вот и не угадали

Перед 'все', заказчику нужно не полениться считать установившийся bootloader и затем копировать его в нужных количествах . И зачем тогда все эти пляски?

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

В идеале, лучше переделать на SHA и это не так уж и сложно
mega640/1280/1281/2560/2561(возможно и mega88/168 и некоторые другие, надо проверять, по крайней мере для 640/1280/1281/2560/2561 - это даже описанно в документации) позволяет програмировать биты LB2, LB1, так что ничто не мешает bootloader-у их запрограммировать перед генерацией ключей

А чем неустраивает поставки мк с зашитыми загрузщиками и золочеными битами? Другого варианта не вижу.

Вот еще такой бредовый вариант.
Вы сами шьете дистанционно.

При большом желании ловится сниффером...

Вот это Вы напрасно. SSH, sftp...
Другое дело, что есть "подсматривающие" программы, но получив права root'а, можно все процессы в системе контролировать.

Сообщение отредактировал Tanya - Dec 26 2006, 11:02

А такой вариант: прошивка совмещается с простеньким программатором (напр. byte-blaster) и передается в виде одного exe-файла. При первом удачном программировании создает ключи в реестре, скрытые файлы и т.п. ... и дальше отказывается работать.
Можно попытаться хотя бы имитировать защиту покруче, что может отбить охоту заниматься взломом или запускать на другом комрьютере... понти - велика сила

Так, если bootloader может иметь доступ к защите, то это действительно какая-никакая Идея!
требующая уже некоторого копания в коде загрузчика для обхода.

Вон чё в даташите на AtMega16 нарыл:

Насколько я ничего не понимаю в английском, это значит что всётаки можно прочитать фьюзы и локи самим контроллером!!!Только как, для меня пока остаётся загадкой...

Например, как в app.note avr109 (flash.h).
Но как шифрование прошивки может помочь, если и загрузчик, и прошивку будет зашивать заказчик?

Спасибо, щас буду смотреть.

См. первое сообщение. Прошивка будет неработоспособна без моего кода, единственный вариант -считать ЕЕРRОМ с уже разблокированного МК(с обеими кодами) и шить его в остальные.

Но ведь прошивка открыта и посмотреть в ней таблицу соответствий или формулу вычисления ответного числа особого труда не составит. ?