Начну с того, для чего это потребовалось и "откуда ноги растут".
Три года назад сделал по заказу девайсы на ATMega16, софт к ним. Девайсы имели интерфейс с компьютером по RS-232 и я заложил в схему возможность запуска boot-загрузчика (перемычку). Но тогда по запарке, а может из экономии денег (не помню точно), заказчик решил не делать boot-загрузчик и прошивать девайсы только программатором. За три года много девайсов разошлось по миру и никому не требовалось что-то менять в девайсах.
Но тут вдруг в Германии нашлись потребители, которые захотели-таки немного "заточить" девайсы под себя. И встал вопрос а как быть? Ну, софт доработать не проблема, а как его заменить в девайсах? И при этом не открыть прошивку, т.е. не отдать её в чужие руки в открытом виде. Ехать кому-то в Германию с программатором, софтом и т.п. накладно. Отдать прошивку (если они сами найдут программатор) нельзя, мало ли что. Девайсы то по железу простые, скопировать раз плюнуть. Просить чтобы прислали девайсы сюда тоже накладно, долго, проблемы таможни и т.д. Что делать?
И тут появилась идея автономного (т.е. без компьютера) микропрограмматора. Это маленькое устройство, которое подключается к разъёму ISP девайса (питается от него же) и программирует его после включения питания. Тогда мы им высылаем этот маленький программатор и они с его помощью "оприходуют" все свои девайсы. Для простоты было решено таки программировать AES-boot загрузчик, а потом уже с компьютера заливать в девайсы новую версию софта (а потом и следующие обновления, если будут). К тому же загрузчик мал по размеру (менее 2К), так что нет проблемы его "запихать" в память контроллера микропрограмматора. Конечно, возможность "перехвата" кода остаётся - если "снять" весь обмен по ISP в момент программирования. Но всё же это потребует некоторых "спец" средств, которых может не быть под рукой. Да и желание "связываться" может отпадёт. Для "надёжности" ещё решено применить счётчик программирований, - задать количество девайсов, которые можно будет прошить микропрограмматором. Счётчик будет в eeprom, декрементироваться после каждого удачного программирования. При обнулении счётчика - в отказ.

Теперь о железе микропрорамматора. Это 5-ть деталей: контроллер ATMega48V (в DIP-корпусе), светодиод, резистор 470 Ом (или около того), панелька 28 ног для контроллера и разъём ISP (в моём случае 6 пин) для втыкания в целевой девайс. Схему тут не привожу, т.к. её рисовать дольше чем написать текстом: выводы земли и питания с ISP разъёма подаются на ноги котроллера 8,22 и 7,20 соответственно; сигналы MOSI, MISO, SCK на одноимённые выводы контроллера - 17,18,19; сигнал RESET - на вывод 16; светодиод катодом на вывод 6 и анодом через резистор на плюс питания (нумерация ног для DIP-корпуса!). Тактирование делается внутренним RC-генератором, на который контроллер "настроен" с завода. Я только сбросил фуз-бит делителя на 8, чтобы контроллер начал работать на тактовой 8 МГц. Панелька нужна для того чтобы вынуть контроллер и зашить его в программаторе. Но можно доработать схему для того чтобы шить контроллер не вынимая, - для этого надо добавить переключатель, который переключает сигнал RESET с разъёма ISP между выводами 16 и 1 контроллера. Я так не делал, чтобы избежать каких-либо проблем с немцами или при пересылке, - вдруг перемычка сорвётся, будет переставлена и т.д., надо чтобы всё было "железно".

Как работает. Подключаем к ISP разъёму, включаем питание целевого девайса, начинается программирование. Поскольку оно очень быстрое, то индикация сделана только "по результатам". Если не удалось войти в режим программирования, то длинная вспышка светодиода и такая же пауза, попытки войти в режим программирования циклически повторяются. Если контроллер девайса не тот, который должен прошиваться (не тот ID кристалла), то короткая вспышка с длинной паузой. Если истёк счётчик прошиваний, то короткая вспышка и короткая пауза. Если всё в норме, то постоянное свечение. В последних трёх случаях микропрограмматор в итоге зацикливается на высветке.

Софт микропрограмматора сделан путём кастрации софта из моей темы про программатор Dimoniprog (тут). Для упрощения все ожидания завершения программирования флеша или фузов с локами сделаны просто на задержках.
Для использования проекта в своих целях надо адаптировать под нужный целевой кристалл (код кристалла, задержки, значения фузов и локов). Это делается настройками определений в начале файла isp.c. У меня всё настроено для программирования целевого кристалла ATMega16. Возможно, для надёжности следует уточнить коды команд интерфейса сериального программирования по даташиту целевого кристалла (хотя это вроде у всех АВР Атмелов однохренственно). В файле main.c надо задать счётчик возможных программирований и вставить код своего boot-загрузчика. Внимание! В приводимом исходнике main.c код загрузчика по понятным причинам искажён (потому работать и не будет) и приводится для наглядности. Код загрузчика (для тех кто в танке) берётся из Application Note AVR231.
Для того чтобы легко получить код своего загрузчика в виде исходного текста, я наваял програмку Hex2Src, которая принимает через командную строку имя файла загрузчика, например, boot.hex (можно не только в intel-hex формате, но и в motorola и tektronix). После запуска будет создан файл с тем же именем, но расширением .c. Из него надо взять нужное и с небольшими правками перенести в файл main.c. Думаю, трудностей возникнуть не должно.
После внесения всех правок компилируем проект BootProg. Поскольку в проекте используется eeprom, то выходной файл компилятора задан в simple формате. Так что для получения из него файла кода в hex-формате надо применить POSTLINK команду. Для простоты я её добавляю в оболочку IAR через "Configure Tools...". Надо ввести следующее:

И поставить галку "Redirect to Output window". Сам файлик POSTLINK.BAT (оригинальный в директории BIN софта IAR) надо подменить на поправленный, который можно взять из темы тут.
После компиляции вызываем из меню "Tools" команду "Postlink". В результате получаем hex-файл прошивки ATMega48V. Зашиваем флеш, а зашивать eeprom нет необходимости - инициализация счётчика загрузок делается программно. Микропрограмматор готов!
---------------------------------------------------
Сделал я сей девайс и пришли другие идеи. Ведь такая штука может быть нужна не только для случая подобного моему. Например, вот ещё. Если увеличить память (другой контроллер взять), то можно шить не только загрузчик, но и вообще весь софт в целевой девайс. Тогда, допустим, это может быть востребовано на производстве - клепают девайсы и тут же шьют, ни компьютеров не надо, ни программаторов (надо только счётчик загрузок выкинуть). Один раз зашил где-то этот микропрограмматор, а потом только переливай.
Или вот ещё мысль. Можно сделать микропрограмматор (опять же если взять с большей памятью) на разные целевые кристаллы, - каждому своя "заливка". При этом, например, выбирать что заливать по коду кристалла, который считывается вначале. Или выбирать перемычками. Тогда будет "походный автономный заливатель" на несколько девайсов.

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

- тогда делаем так: берем как контроллер Tiny2313 (SPI и I2C - софтовые), то что будем шить (образ FLASH+EEPROM+FUSE+LOCK) храним в 24С512 (если 64кб не хватило то ставим еще n штук 24С512 или заменяем их на изделия из серии AT45 (они тоже в SO8 но интерфейс SPI)). Для обновления заливки вешаем FT232(у меня стояла старая, еще с внешнем 93С46) (ну или MAX232 - в зависимости от ваших потребностей).
Такой программатор реализовывал у меня двухступенчатую прошивку target'a - сначала загружал тестово-калибровочную прошивку, запускал ее на выполнение (отпускал reset) и после успешного завершения калибровки (ждали ответ) писал рабочую прошивку и лочил по LOCK-битам и RSTDISABLE кристалл.

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

Граждане! При желании можно скопировать всё и вся, я же это не отрицаю! То что для этого нужен ещё контроллер и т.д. - это я и назвал спецсредствами. Думаете, что у тех людей, которые ставят приборы на эксплуатацию, когда надо делать всё вовремя и к сроку, это всё есть и оно на мази, типа потирая руки ждут шанса скопировать код устройства? Да не смешите мои тапочки. Это у вас есть (или можете наваять), а у них врядли, да и некогда им этим заниматься. Я скорее обезопасился от случайного "уплывания" прошивки налево. И всё.

А потом главная мысль в теме ведь не эта, а мысль иметь простое устройство для автономного (без компьютера с кучей софта и подключённого к нему программатора) и быстрого (почти моментального)программирования девайсов, одной "серии" или разных на совместимых контроллерах.
Конечно, можно сделать и более навороченное устройство, нет сомнений, но это уже печатная плата и т.д. А у меня панелька под контроллер - это и есть плата. Спаял за 20 мин, из них половину времени потратил на разделку кабеля.

ИМХО очень правильно. Такая девайсина, залитая компаундом с разъёмом на конце . "Те люди, которые ставят приборы..." вскоре придумают наукообразное название ( например, "ключ на разлочку") и будут давать друг другу попользоваться "на 1 раз". Только нужно, чтобы всё работало как часы, и было очень эргономично, т.е. просто и понятно. Потому что эта штука не должна попасть в руки "умников", которым слить трафик - раз плюнуть. По крайней мере, живая. А закончился ресурс прошивок - и сотри флеш... Светодиод я, пожалуй, оставил бы - типа индикатор 5 вольт

У светодиода всё же более интеллектуальная задача - сигнализировать результат.
Врочем, если вдруг не горит, то это как раз означает, что питания нет

Вот зафотил девайс:

С другой стороны залил герметиком:

Хорошая идея , но главное, чтобы его не забыли в готовом приборе.

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

Ценно! Для себя. Поэтому AES тут не нужен. А в чужих руках AES не поможет - SPI же открыт.

Дык AES будет нужен потом, когда будет заливаться (или обновляться) прошивка с компьютера через этот AES-boot загрузчик.

Так SPI же на таргет все равно открытый - Вы сами об этом знаете.

Ну так ведь речь зашла о назначении AES, а он не связан со SPI загрузкой. Потому и нужность AES с ней тоже никак не связана. А вот потом при обновлении через AES-boot уже будет лучше не просто boot, а шифрованный AES-boot.

Не, это ж банально - стоимость взлома защиты должна быть больше стоимости защищаемого. С одной стороны хорошо, закрыли AES`ом, а с другой - дыра-SPI и работы на день-два. Неужели Ваша прога стоит меньше ? Имхо, хорошее решение - заменить у клиентов железо полностью или частично (лучше за их счет, т.к. это новая фича). И вот тогда таки да, AES. А в топике - девайс для "внутреннего" использования.

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

Немного доработал програмку преобразования кода в исходник Hex2Src.
В прежней версии я забыл снять ограничение на количество напрерывных "кусков" кода (в адресном пространстве памяти). Поэтому если в коде (в hex-файле) были "дырки", т.е. данные шли с разрывом, то программа отказывалась от действий.
В этой версии возможно любое количество "кусков": просто будет создан исходник с несколькими непрерывными массивами данных, имеющими свои начальные адреса и размер.
Плюс к этому я сделал вид исходника, который можно удобно "вставлять" не внося исправлений (ну, если только мало ли что не по нраву).
Это всё я сделал к тому, что мало ли вдруг захочется программировать не только boot, но и вообще весь код полностью. При этом надо только взять контроллер с подходящим объёмом памяти и перекомпилить под него проект. Меня как раз попросили сделать именно такой прошивальщик, так что пришлось перейти на ATMega168.
Поскольку код самого прошивальщика занимает что-то около 1КВ, то во многих случаях контроллер прошивальщика может быть такого же объёма флеша как и целевой контроллер (когда у целевого софта есть запас по памяти в эти 1КВ).

Новости по результатам реализации нового варианта прошивальщика. Это когда шьётся не только загрузчик, но и сразу весь остальной код целевого девайса (либо весь код без загрузчика).
Отличие возникает в следующем (помимо того, что контроллер взял с большей памятью - ATMega168):
1. Прошиваемый код может иметь (и скорее всего) несколько кусков кода, которые никак не стыкуются своим началом и/или концом друг с другом в адресном пространстве флеш памяти, а могут и отстоять друг от друга всего на несколько байт, в т.ч. в пределах одной страницы флеш-памяти.
2. В основном коде может оказаться нечётное количество байтов. В загрузчике такого быть не могло, т.к. там только коды команд, а здесь могут быть, например, строковые константы.
3. Надо (скорее всего) прошивать ещё и EEPROM.
4. Шьётся boot-загрузчик + код, так что для загрузчика с контролем CRC надо, чтобы в итоге получилось правильное содержимое флеша, чтобы CRC при проверке была равна 0, иначе загрузчик не стартует основное приложение.

Сразу скажу, что последнюю проблему я решил просто - переделал boot-загрузчик, чтобы он не проверял CRC (в AES-загрузчике от Атмела такая возможность есть).
Для исправления отл.3, я добавил процедуру прошивки EEPROM в код прошивальщика.
Из-за отл.1 и 2, при засовывании в проект загрузчика вместе с основным кодом, прошивальщик работал неправильно. Первый кусок шился кроме последнего байта (из-за нечётности), а второй неправильно (из-за малого "отступа" от первого при наличии страничности).
Для исправления отл.2 я вставил в ispProgramFlash() загрузку байта 0xFF в последнее слово в случае, если оказывалось нечётное количество байт в массиве (любом) для прошивки флеша. Кстати, эта "ошибка" по-моему есть в коде всех доморощенных программаторов. Но их спасает, видимо, то, что Студия формирует массивы для прошивки нужным образом - с чётным количеством байт (при прошивке флеша).
А вот с отл.1 оказалось всё сложнее. Поскольку флеш прошивается странично, то пришлось учесть то, как разные непрерывные куски кода прошивки ложатся в память: начальные адреса, конец куска добить до целой страницы, но при этом учесть, чтобы он не залез на следующий кусок (у меня, например, получалось два куска, между которыми был всего один байт "пустоты") и т.д. Опять же Студия, по всей видимости, всё это учитывает сама и выдаёт по протоколу STK500 блоки данных с нужным выравниванием и размером (потому и моя реализация STK500 для программатора Dimoniprog работает). Но в этом случае ведь никакой Студии нет, шьётся всё автономно! Проблему пришлось решать. Я не стал исправлять код прошивальщика, а сделал так, чтобы массивы для прошивания уже были "как надо". Для этого модифицировал программу Hex2Src. Теперь она формирует массивы в исходниках выровненные на границу страницы и размером с целое количество страниц. "Лишние" байты вставлены кодом 0xFF. Взаимное положение кусков кода тоже учтено. Если при выравнивании куски "состыкуются", то они в итоге станут одним целым куском. При запуске программы Hex2Src теперь надо в командной строке перед именем файла (.hex) задать цифрами размер страницы флеш памяти целевого кристалла (не контроллера прошивальщика!), например:

После такой подготовки массивов кодов для прошивки, решение проблемы с нечётным количеством байт стало неактуальным. Но я его оставил на всякий пожарный.
Поскольку теперь программа Hex2Src формирует выходные файлы сразу в "пригодном" виде, то я их стал добавлять в main.c директивой include. Только надо всё же поправить имена констант и массивов - я правил для boot-а (в boot.c) и eeprom-а (в eeprom.c), т.к. они скорее всего в процессе разработки не поменяются, а вот имена флеш массивов оставил как есть, так что при изменении прошиваемого кода просто перекидываю в проект загрузчика обновлённый файл code.c (название, понятно, условное) с новым кодом.
При наличии двух и более кусков, зашиваемых во флеш, надо добавить соответственно строчки (в main.c) с вызовами ispAddress() и ispProgramFlash() для этих кусков. Думаю это понятно.
Добавил зажигание светодиода на четверть секунды в начале при старте. Теперь ведь шьётся дольше, так что надо было как-то проинформировать, что "началось".
Ещё немного задержки увеличил на всякий пожарный. Лучше подольше, но наверняка.

Исходники нового "расширенного" BootProg и новой версии программы Hex2Src прилагаются. В исходняках, понятное дело, содержимое файлов boot.c, code.c удалено, оставлены начало и конец для наглядности. Файл eeprom.c секретности не несёт, так что его оставил как есть.

Обижаешь... Нет у меня такой ошибки
И байты - а пусть фрагменты (любое количество на странице) не только заканчиваются на нечётных байтах, а и начинаются на них, даже пусть хоть только одни нечётные байты в HEX-е прописаны.

Имелась в виду embedded составляющая, которой у вас нет. Так что прошу не обижаться
Я уже писал где-то, что лучше AvReal софта не видел. Но теперь хочется от него поддержки STK500.

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

По этой теме есть следующие соображения:


1. Загружаем с компа и храним зашифрованную прошивку на борту в отдельной флеш-микросхеме.
На целевой кристалл шьем AES бутлодер и затем уже через него - основную программу.

ДЫРА: 2. Для того чтобы расшифровать прошивку, бутлодер должен знать ключ. Бутлодер должен
зашиваться незашифрованным в чистый контроллер. Его можно перехватить по SPI во время программирования.
Как тогда сохранить в секрете ключ?

Временное решение. Сделать бутлодер трудно-поддающимся дизассемблированию (КАК?) и прошивать
в чистый микроконтроллер незащищенным. Но никому об этом не сказать. )))

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

4. Список и счетчики прошивок храним внутри контроллера-программатора.

ДЫРА: Если у программатора
снесет крышу и придется его перепрограммировать - потеряется таблица прошивок, тогда можно будет повторно
использвать прошивки, которые до этого могли быть уже прошиты максимальное число раз.

РЕШЕНИЕ: Программа-обновлялка для ПК, которая загружает новую прошивку на борт программатора - работает только
при наличии связи через сеть интернет. Сначала отсылает программисту (мне) таблицу прошивок из контроллера.
А потом только передает программатору новую прошивку. Тогда при новых компиляциях программы загрузчика
можно сразу туда включать эту таблицу.

5. В клиентских программах, также как и в программаторе, выставляем фьюзы на запрет чтения и записи
и внутри программы периодически их проверяем!
Хацкеры обычно разными способами сбивают эти фьюзы и читают прошивку. Если прога будет
их контролировать - можно попытаться стереть саму себя в случае обнаружения попытки взлома.

ДЫРА: Если сбить
фьюзы и сразу войти в режим программирования (подтянут ресет), т.е. не дать проге запуститься - то она не
успеет сама себя удалить и может быть считана!

НЕ РЕШЕНА! Остается надеяться, что в последних версиях контроллеров фьюзы нормально переносят фокусы
с питанием, а также надежно спрятаны от лазеров/ножыков во внутренних слоях кристалла.

ДЫРА: 6. Можно прошивать одновременно несколько контроллеров, включив их параллельно!

РЕШЕНИЕ: Можно перед прошивкой проверять серийный номер контроллера (а у AVR он есть?) Бутлодеры, у которых
серийник не совпал - просто перестанут принимать данные. Если серийника нет - по тихому загружать его в составе
бутлодера, каждый раз инкрементируя. Опять-же надо контролировать чтобы не шили параллельно несколько кристаллов.

Какие еще тут есть дыры (уязвимости, а не технологические отверстия) и способы их решения?

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

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

Ну или почитайте про системы с открытыми ключами



Здесь Боб - это программатор, Алиса - ваш девайс с прошитым загрузчиком и случайно сгенерированным сеансовым ключом.

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

Лично Вы это можете сделать? Нет? Так откуда уверенность, что уровень спеца который это сможет сделать будет ниже Вашего? А если так, то как думаете - кто меньше потребует ?

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


Результат биений двух таймеров с разными источниками тактирования. Например таймер от основного RC плюс прерывание от WDT...

И от блин температуры будет блин зависеть блин непонятно как. У основного RC и у WDT-шного могут быть разные знаки температурного коэффициента, могут буть одинаковые, у каких-то при определённх напряжениях пиатния у WDT вообще немонотонная характеристика частот от температуры. В любом случае с температурой это дело плыть будет атмел знает как.

Дык для генератора случайных чисел это хорошо. Чем больше "непонятно как" - тем лучше генератор... В простейшем виде это 8 битный таймер который крутится(многократно) до срабатывания прерывания WDT или програмный счетчик инкрементирующий ячейку памяти до сброса по WDT(если не хочется использовать прерывание вачдога).

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

В сети есть несколько сообщений о том что достаточно на короткое время сделать переполюсовку и фьюзы слетают. Для этого спецом достаточно быть ващще никаким. Ну а с подрезкой фузов лазером или напильником - это конечно редкостное извращение. ))) Это меня не беспокоит.

Спасибо! Все советы полезные!

Не спутали! Серийник AVR-кам тоже бы очень пригодился! Но поскольку его нет, я думаю придется самому генерить его и прошивать вместе с бутлодером.

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