Здравствуйте,
У меня такая ситуация: есть прошивка(в CodeVisionAVR под AtMega16), нужно передать её другому человеку, но так, чтоб он смог использовать её только для одного устройства.

Думаю сделать это так: при первом запуске контроллер генерит случайный код, записывает его в EEPROM и выводит на LCD.Код передаётся мне, я составляю ответный код, передаю его, он вводится в устройство, контроллер записывает его в EEPROM.Далее при каждом включении контроллер сверяет на правильность коды из EEPROM, при несоответствии работа устройства блокируется.

Но для этого думаю нужно контролировать что стоит фьюз защиты от чтения EEPROM(иначе не генерить первый код) и генератор реально случайных чисел(не псевдослучайных).

Посоветуйте как это можно реализовать, или может есть способы попроще

Да есть.. Продавать прошитые чипы. (хотя бы с Вашим бутлоадером)

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

К сожалению передать прошитый чип нет возможности.
Может всёже есть другие варианты защитить прошивку?

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

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


Добавить в схему еще один чип, так чтобы оба чипа могли друг-друга программировать.
Добавить межпроцессорный протокол. И тогда Ваш вариант заработает. Например так:

Заказчик заливает прошивку в оба чипа.

Первый чип (1) подает второму (2) команду залочить себя
(2) лочит (1), после чего перезапускает и сообщает (1), что тот залочен.
(1) пишет в EEPROM статул лока, для того чтобы больше не просить (2) себя лочить, и генерит некий код который надо сообщить Вам по телефону.
Ну а дальше уже так как Вы описали в самом первом посте.
Только самое важное, чтобы программа без второго чипа была неработоспособной.

Можно попробовать прочитать заводскую инфу из самого чипа (к примеру - калибровочную константу CLC, она для разных экземпляров чипов будет наверняка разной, хотя совпадения и возможны), и использовать ее как идентификатор.
Ваш заказчик должен будет выслать Вам значение этой калибровочной константы, а дальше - Ваша задача написать загрузчик, который будет использовать при записи контроль содержимого чипа, с блокировкой записи при несовпадении данных.

Есть простой и надежный способ - работать на доверии.
А если не доверяешь - не работать.

А как можно считать константу CLC(ну кроме как через програматор), сам контроллер может считать свою константу?

Взламывается на раз, два, плюнуть - достаточно умного слэйва-напарника вместо (2) для вычисления лок-бит, ну и, естественно, программиста для всей этой раскалбасни...Хотя, тогда ни вижу смысла всей этой галиматьи...

Насколько я знаю, эту константу можно прочитать только через программатор (ИМХО).

Вы сами то пробовали дизассемблировать win32 приложение? Я не говорю, что это сложно для того, кто этим занимается часто, НО... Не такая уж тривиальная задача, если подойти к этому с умом.

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

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

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

сделай так что бы устройство 10 мин работало а дальше циклилось. такое устройство точно не будут в комерческих целях использовать. А дизасемблировать? ну извините по моему лучше свое написать чем в чужом разбираться.

"расциклить" такое устройство с помощью AVRStudio пара пустяков...

Тоесть код для контроллера?Можно пример, как вытащить эту константу.
А по поводу защиты от дизасемблирования, может можно программой проверять контрольную сумму флэша, если она не как у оригинальной прошивки, блокировать работу?Если можно, подскажите как(для CodeVision).

Команда LPM очень легко и непринужденно находиться в асме,так что подпрограмму проверки контрольной суммы найти и отключить несложно,а при желании "раскусить" подпрограмму проверки пин-кода тоже можно.
Если хотите 100% защиты-как уже советовали ,отсылайте прошитый камень
А если не 100% - подумайте над тем ,будет ли нуждаться в ваших услугах заказчик ,если он будет иметь хакера ,если программист способен разобратся в чужом коде,то сможет написать свой не хуже вас
Ну а если ломанут,это будет большая честь для Вас,так как ломают дорогие и популярные вещи,и программеры способные создавать такие вещи как правило без работы и денег не сидят.
Так что в любом случае Вы выигрываете.

А может, вместе с прошивкой, высылать клиенту SIM-карту от сотового? Далеко не все SIM-карты клонируются без проблем. Прошивка должна уметь с ней работать, обмениваться информацией, считывать серийный номер, да мало ли ещё что делать. Можно кусок кода в ней хранить и прошивать в процессор при начальной инициализации. А после прошивки, процессор стирает информацию в SIM. То-есть прошить можно будет только ОДНО устройство! Правда, тут без бутлоадера не обойтись.
P.S. А ещё можно применить 1-Wire от Dallas со встроенной RAM. Эта RAM умеет защищаться паролем от считывания, а в ней кусок кода. Но опять-же, нужен BootLoader.

Как вариант в защищаемую фузами область FLASH (максимальная бутовая) укладывается часть функций и работа с ними по фиксированным адресам. Т.е. для специально спрятанных функций заводим сегменты в xcl, замапливаем обычные, но нужные функции туда pragma location, ну и вроде должно помочь...

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

С SIM-карты защита точно не получится.Там два кода, IMSI-ничем незащищён(его даже через мобильный можно посмотреть),KI-защищён, но у тех карт которые не клонируются, его вычислить невозможно.

Ладно, я так понял нормальной защиты всё равно неполучится, ну мне хотябы защититу от простого копирования прошивки в другой МК. Вот мне идея понравилась проверять заводскую константу CLC.
Может кто-нибудь дать пример кода, как считать эту константу?

Как вариант ,
1 зашивать скриптованную программу с "внутренним" бутлоадером,
2 писать программку для ПК ,которая проверяет проверяет установку фузов.
3 при установленных фузах ,разрешает прием ключа (случайное число от МК) и возвращает дескриптор ключа и прошивки.
4 После этого "внутренний" бутлоадер распаковывает прошивку.
5 Можно добавить ,ложные байты,дескрипторы,подать "1" на порт закороченный на землю при неправильных ключах ,короче усложнить жизнь хакеру.

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

Вау,что я вычитал,
оказывается в мегах48\88\168 программа МК может прочитать фузы защиты,так что задача значительно прощается ,дерзайте.

А высылать как будете в HEX или в исходниках???

Если в HEX, то самый лучший способ - это какой-нибудь DALAS (как писали). Например часы или термометр. Убедите, что они нужны на плате для работы схемы. Дальше пусть пропишут Вам код (64бит). Его сверяйте при первом запуске, но не сначала. И код должен быть разбросан а не лежать в одном месте (чтоб не нашли).

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

C константой калибровочного бита CLC разобрался, беру в регистре OSCCAL.
Буду попробовать, может и фьюзы защиты найду где брать...

Странно что на это никто не обратил внимание? я очень извиняюсь но как вы собираетесь это сделать? - генерить случайный код? генератором случайных чисел? можно поподробнее :-)
зы: может я в танке? :-)

Это можно сделать очень просто - при первом включении прибор ждёт нажатия кнопки (или замыкания перемычки), в общем реакции заказчика, и при этом работает тот-же TCNT1 от максимальной тактовой частоты, ну а далее, использовать это значение для инициализации генератора случайных чисел. Можно сделать несколько нажатий кнопки, если хочется совсем уж случайно.

Да, согласен. Спасибо.

Это дело не сработает...
Во-первых там всего 256 возможных значений из которых реально используется отсилы 20.
Во-вторых бывает, что у всех МК одной партии значения калибровочных констант равны.

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

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

Ну если есть хотя-бы минимум доверия, то можно поступить следующим образом: разделить задачу на две части, на 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'а, можно все процессы в системе контролировать.

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

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

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

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

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

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

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

Так если поставить защиту кодом + защиту по калибровочной константе + проверку контрольной суммы(чтоб прошивку труднее править было) +ещё чё нибудь придумать, это сколько головной боли будет у того кто захочет такую программу ломать.
Думаю будет проще написать собственную программу, чем с такою разбиратся.
Только надо ещё чтоб реализация всего этого была достаточно простой, ато защита программы получится сложнее самой программы.

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


Мдя,или в старых даташитах ничего не сказано или я опять прохлопал.

Могу обрадовать ,можно не только прочитать но и записать.

Порядок насколько понял такой.
Заносим в R0 следующее значение
7 6 5 4 3 2 1 0
1 1 BLB12 BLB11 BLB02 BLB01 1 1

Записываем в SPMCR “X0001001”
После чего в течении 4 тактов нужно подать команду SPM ,желательно при этом шаманстве отключить все прерывания.
Проверка конца записи идет чтением фузов.
Далее идут рекомендации для совместимости кода с другими камнями,но это не актуально.

Теперь чтение

Загружаем вектор в регистр Z=$0001 ,
потом устанавливаем биты BLBSET и SPMEN регистра SPMCR,
далее в течение трех тактов подать LPM
Проверка конца чтения по сбросу битов BLBSET и SPMEN

Это не правильно, я ведь ранее писал что загрузчик вполне может закрыть прошивку от чтения запрограмировав биты LB1 LB2

если загрузщик (код) доступен потребителю, то всё.... Защита не поможет. надо именно поставлять мк с закрузщиком и залочеными битами

Почему, недавно видел проект, операционная система бинарно совместимая с Win, в исходных текстах. Драйвера от производителей железа там свободно пускаются. Причем 10 лет ей и разработчики вроде русские. Вопрос цены. Некоторые ничего вообще не умеют делать