Пишу внутрипрограммный загрузчик.

Как понимаю, в этих процессорах защита организована так.
По адресу 0x000001FC во флешь находится поле Code Read Protection (CRP).
Записав в это поле определенное в даташите значение, устанавливается степень защиты кода.
При загрузки внутренний загрузчик смотрит на это поле и решает, что делать ISP.

Так же есть возможность определить программно, закрыт процессор или нет.

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

Очередную проблему Вы выдумали - защита штатного загрузчика должна быть активирована ВСЕГДА. А из своего - пишите через ISP что хотите.

У меня в векторах прерываний стоят бранчи на сектор обновляемой части прошивки, а оттуда - куда надо.

В атмеловском арме можно выкрутиться без "бранчей" путём программирования контроллера прерываний и размещения минимального обработчика в бутлодыре (который call делает по вектору из контроллера). С FIQ аналогично, только jmp сместо call (вопрос возврата уже на совести обработчика FIQ). Для исключений вроде ABORT распечатка регистров и стека в RS232. У меня так.

Совершенно не нужны никакие "обработчики c call" в bootloader-e - вектор 32bit - загружается одной командой

в pc и все.
FIQ, если он один, действительно можно отправить, например, на 0 адрес основной прошивки.
Кроме, того вопрос-то был о другом.

Понял.

Загрузчик теперь немного модифицировался. Нужно сделать еще и так.
Часть функций зашиврована и лежит в некоторой странице флешь. Потом, когда
загрузчик определит, что защита включена, он распакует содержимое флешь в область RAM.
И сразу запустит от туда обработчик команд. (компилятор IAR)

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

Собственно думал заменить механизм инициализации __ramfunc, на собственный механизм распаковки.
Это вообще возможно?Или есть что-то лучше?




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

Остановился на полном закрытии загрузчика.

Нашел еще интересную ссылку про загрузчик.
http://caxapa.ru/105173.html?hilite=scmRTOS&todo=full

Только как в новом IAR 5.11 сделать копию векторов прерываний в область, раположенную не по адресу 0x00000000, а в 0x00003000?

Похоже не поняли - ЗАЩИТА ВКЛЮЧЕНА ВСЕГДА. И никаих танцев с бубнами, распаковок из FLASH в RAM просто не надо. Тем более, что это НЕ ЗАЩИТА, если есть моменты, когда сам загрузчик занимающийся расшифровкой можно считать



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

Понял, но не до конца изложил идею. Всегда теперь разрешаю защиту. Ни для кого не секрет, что китайцы пилят процессоры. Как-то находил, что спилить авр стоит около 200 долларов.
Для меня сейчас главное - это защитить часть функций загрузчика, такие как считывание некоторой области данных. Или вообще весь загрузчик распаковывать, если все ключи внутри верны.
Допустим, ключем является вся область страницы флешь памяти. Пусть человек получил после спила китайскую прошивку. После ее зашития в нормальный процессор, загрузчик либо закрывает доступ к процессору (если в прошивке также установлен CRP), и разрешает доступ к функциям (к которым можно достучаться по определенному мной и шифрованному протоколу), в этом случае нужно ломать протокол. Либо нужно модифицировать начало флешь, чтобы записать туда программу, которая вычитывает всю прошивку, но в этом случае она вычитает просто какой-то мусор(зашифрофанную прошивку), а правильно расшифровать уже будет не возможно. Думаю этот способ по-лучше, чем просто поставить CRP. , только проблеммный.

Собственно для запуска прикладной программы используется переотображение векторов, поэтому про загрузчик ей вообще знать не нужно (как в ScmRtos Сергея Борща).
Пока лучше не нашел способа, может подскажете, где еще можно посмотреть альтернативные варианты запуска прикладной программы?

п.с. защита прикладной области пока не рассматривается

Можно поподробней про "пилить"?

CRP запрещает ISP и JTAG. Если мой загрузчик умеет только стирать и писать, на вход принимает шифрованную прошивку и не запускает некорректную программу (у которой CRC не сошлась). МК с моей прошивкой можно "распилить"?

Ага, "не нужно" может она у Вас и работать сможет в пороизвольном месте Flash? Нет? Тогда она уже обязана знать, что работает в области не занятой загрузчиком и соответственно знать о существовании загрузчика. В остальном тоже сполшные заморочки без всякой надобности. Почитайте пост meister
для просветления.

Спилить, это значит получить полый дамп вашей прошики не смотря на установленные биты защиты.
Есть много различных способов. Как от недокументированных багов загрузчика, так и получение прошивки электронным микроскопом. Здесь уже старенькая информация о коллекции "спиленных" процессоров:http://www.mcucrack.com/, но попадалась и новая информация.
Пока про взлом ARM не слышал, AVR ломают направо и налево. А ARM - это просто дело времени.


Все это хорошо, но что будет, если получить полный дамп вышей прошивки вместе с загрузчиком и залить в новый процессор?



Написать скрипт для компановщика для прикладной области, располагать таблицу векторов в строго фиксированном месте в прикладной области прошивки, а загрузчик эту область знает, просто переносит ее в ОЗУ и делает Remap. В данном случае прикладную программу можно отлаживать без загрузчика. А она может находиться в любой области Flash.

Стандартные загрузчики выключены (совсем).



Это, наверное, слишком дорого.



Будет клон.

Так вот именно, а как вы его отличите от вашего устройства и что сможете сделать, чтобы предотвратить клонирование?

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

К сожалению в вашем случае "против лома нет приема".

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

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

Так то оно так. Пока главной задачей ставится ухудшение дизасемблирования прошивки. Прикладная пограмма запускается и тоже распаковывается, если загрузчик в нормальном состоянии, CRC его и распакованной части известны заранее. Поэтому в реальном процессоре побегать J-tag ом не получится.
Так как нельзя снять бит защиты. в дизасемблере понять смысл этой прошивки очень сложно и чтобы определить что где надо почистить нужно хорошо постараться.
Это просто пока одно из решений для создания проблем дисасемблированию. Самое ценное в такой защите, это уметь отличать разницу между процессорами (например по уникальному серийнику, который нельзя было бы зачитать внешними средствами, которого нет у филипса). Тогда можно было делать распаковщик с ключем-серийником (подобным образом сделано у BlackFin серий ADSP - BF52x).

Если возможно перешить сам ISP загрузчик в филипсе, то все эти заморочки не имеют смысл.

Не смею более надоедать с разъяснениями.

Далеко не всё. Кто будет подтверждение давать AIC'у, кто будет стек переключать, либо иметь большой отдельный стек для прерываний, кто будет возврат из прерывания делать и функции со специальным прологом/эпилогом? Да, gcc вроде как что-то из этой области умеет... А как я говорю используются обычные функции.



Для FIQ у арма вектор предусмотрен, как раз ^^^ для такой вот команды. Но вопросы обработки и возврата на совести обработчика. Как и стека. Для FAST прерываний это оправдано.

Нет ни малейшей необходимости использовать "обычные" функции вместо обработчиков прерываний. И писать руками ТУПУЮ обертку сохраняющую все регистры, вместо того, что-бы позволить оптимизировать это дело компилятору. Нет ни малейшей необходимости делать ЛИШНИЙ вызов "обычной" функции из этой обертки.

Проблема века - естественно вызванный обработчик прерывания. Причем в тот момент КОГДА надо, например для организации вложенных прерываний, а не по выходу из функции. Нафиг такой "сервис".

Да вызываемый обработчик ЕСЛИ КОНКРЕТНО ЕМУ НУЖЕН отдельный огромный стек и будет его преустанаваливать со штатного аппаратно переключенного. А вот если обертка будет всем и вся НЕ РАЗЛИЧАЯ и зачем-то СОФТОВО переустанавливать стек, вместо того, что-бы пользоватся родным IRQ стеком, то это чистой воды глупость.

Это оправдано всегда.