Информация низкоуровнего доступа к внутренней flash микроконтроллеров от NXP явлается секретом. А также является секретом как первоначально прошивается bootloader на предприятии изготавливающем эти чипы.
Поэтому я был бы весьма признателен, если конить поможет пролить свет на эти "секреты". Ведь производитель некоторых программ загрузчиов имеют представление как в LPC программить flash без IAP. Помогите кто может!

Зачем?

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

А почему хотите избавиться от IAP? Чем не устраивает?
Немного про устройство загрузчиков есть здесь
P.S. Я бы тоже не отказался узнать как ведет себя контроллер с полностью чистым флешем - срабатывает ли CRP и не блокируется ли доступ по JTAG.

Зачем - чтобы сделать хорошую защиту кода. Второе - если есть возможность с помощью загрузкика обновить версию bootload , то наверняка перед записью нового старый полностью затирается. Это предпологает, что загрузчик копирует или грузи в RAM те функции через которые потом программирует новую версию. Чтобы сделать хорошую защиту кода - надо сделать свой загрузчик(ни кому не известный) заместо штатного, или не дать возможность после резета отрабатывать штатному. Для этого мне и нужно либо знать как работать с flash на низком уровне или иметь проттотипы функций IAP, что вобщемто одно и тоже.




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

Разработчики от NXP хотели сделать плохую, или хорошую, но у них не хватило информации и квалификации

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

ИМХО, ирония здесь несколько неуместна. Разработчики кристаллов почти никогда (за исключением специальных случаев, когда разрабатывается защищенная система) не заморачиваются защитой кода клиентов, CRP - это просто "бесплатный бонус. Есть - и ладно, но никто ничего не гарантирует, даже "на словах".
Навскидку - два примера:
- еще 5 лет назад я изучал загрузчик MSP430F149, прошитый в ROM. Там была найдена дыра, сегодня известная как баг "BSL03", о чем Texas был поставлен в известность. F149-й до сих пор выпускается с этой "дырой" и успешно не применяется в моих изделиях.
- "дыра" в загрузчиках для тех же LPC21xx - в версиях до 1.64 включительно также хорошо известна (даже обсуждалась у нас на форуме) и отлично свидетельствует об избытке "квалификации и информации" у разработчиков NXP. И не факт, что там (и в других загрузчиках от NXP) больше не осталось таких проблемных мест.
Далее - загрузчик от NXP, с известным протоколом и с отсутствующей криптографией, легко обойти применяя несложные методы социальной инженерии и некоторое знание психологии. Не кражей, не подкупом, не шантажом и не другими некрасивыми методами, а просто основываяясь на невнимательности сервисников/ремонтников.
Поэтому разработка своего загрузчика достаточно актуальна, притом что, например, в моей компании cуществует более чем 10-летняя традиция использования своего протокола и методики криптозащиты, которые к тому же составляют заметную часть функциональности изделий. И замалчивание деталей программирования флеша со стороны NXP вызывает недоумение и некоторое раздражение, тем что вынуждает заниматься реверс-инжинирингом (со временем я стал находить дизассемблирование все более и более скучным занятием ).
Вот такие у меня 5 коп

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

Совершенно правильно, тоже использую свой ВТОРИЧНЫЙ криптозагрузчик для раздачи upgrade направо и налево. Только при этом не страдаю маниями по поводу наличия основного загрузчика и использования его составной части IAP.

А у меня нет - невозможно объять необъятное.

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

Угу. Приходит из поля прибор. Не рабочий. Вроде все OK, но не пашет. Что делает "авторизованный" сервисник/ремонтник? Запускает утилиту типа FlashMagic или Вашего isp200. Прибор "отзывается", но вот выясняется что, например, прошивка слетела - пусто в чипе, или мусор какой. Ну что ж, пытаемся прошить ВТОРИЧНЫЙ загрузчик - это ж лень проц перепаивать, а вдруг заработает. Прошили - все OK. Залили через вторичный загрузчик криптованную прошивку - все OK. Пашет! Отдаем прибор обратно в "поле", уф-ф, ставим галочку - "успешный ремонт" и берем с полки пирожок .
А контроллер-то был не простой, там "злобные конкуренты" слегка пропатчили первичный загрузчик от NXP. И, к примеру, CRP "иногда" не работает. И вся прошивочка, вторичный загрузчик, а также ключики из этого загрузчика - "того", попали к кому не надо. Хорошо еще, если изделие не особо тиражное, прошивка несертифицируемая и можно наделать уникальных ключей. Но это далеко не всегда так - у меня почти всегда ключ общий для большой серии, а иногда даже для страны производства. А заставить сервисника/ремонтника всегда проводить проверку аутентичности контроллера - это утопия.

Да ладно уж - необъятное . Месяц занудной работы максимум. В моем случае окупится - уже проверено .
К тому же сам IAP переделывать смысла и правда никакого нет. А вот изменить протокол и добавить в него сразу криптование - самое оно.

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

Загрузчик LPC2000 уже давно вскрыли дизассембированием. Юзайте google. Мы написали свой собственный загрузчик и с успехом его используем.

Ну загрузчика "LPC2000" не существует - разные семейства чипов, разные версии загрузчика даже для одного семейства. Но гуглу это конечно всеравно .

1) Значит 'Ander' знает как перепрограммировать первичный загрузчик, но не говорит.
2) Ссылки на Гугл характерны для болтунов - сам не в курсе.
3) Свои платы нужно маркировать разрушаемой гарантийной наклейкой. А чужие платы пусть отвечают по гарантии сами. Много ли здесь таких, которые копируют чужие платы и отвечают перед покупателем?

Для этого достаточно посмотреть/воспользоватся штатным upgrade бутовых загрузчиков от NXP.

Хм, а Вы сами лично шьете все загрузчики? Или таки кому-то делегируете полномочия?
Я, при всем желании, лично не смог бы - тиражи не позволят.
Понимаете, у всех разные условия. Например, у нас есть надежные и добропорядочные партнеры которые вообще встраивают наше изделие на свою PCB - сами трассируют, прошивают, запускают - у них есть вся документация, загрузчики, ключи, etc. Для них криптозащита сделана просто для общности подхода, никаких секретов нет вообще. Есть партнеры-конкуренты - с ними один способ "борьбы" - быть на шаг впереди, никакая криптозащита тут особо не поможет, но и "дарить" прошивки тоже не стоит. А есть партнеры с которыми можно работать только по принципу "утром деньги - вечером стулья". Утечка прошивок/ключей тут равнозначна банальной утечке денег.

"Надо Федя, надо" ©
Сейчас примерно так и сделано, как Вы написали. Но есть потенциально слабое звено, если его можно убрать (и в ряде случаев есть основания так сделать), то почему нет? Вообще, я считаю что в данном случае NXP решил свои проблемы за счет клиентов. У Атмела в SAM7 проблемы загрузчиков решены намного более элегантным способом.
P.S. А разве уже опубликован способ замены загрузчиков 3-ей версии (23xx/24xx)? Я что-то пропустил?

Значит правим таблицу векторов в основном загрузчике (вектор резета). В связи с етим вопрос : будут ли после этого вызываться и корректно отрабатывать функции IAP? Ктонибудь такое делал, и какой прогой заливать подправленный бутер?

Вообщето в своём изделии я предполагал следущее: набрал секретный код на клавиатуре - установил свой вектор(вырубил штатный загрузчик) и доступа к флешу контроллера нет до тех пор пока снова не набрал на клавиатуре секретный код. Но здаётся мне, что через IAP не исправить таблицу векторов штатного загрузчика - там запрет на определённые сектора.

Вообще не занимаюсь производством. Ну и причем тут КАКОЙ загрузчик отдан партрнеру первичный или вторичный? А? Как свой отданный первичный спасает от недобросовестного партнера? Никак!

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


На этом можете со своми размышлениями о "защитах" закончить.

Уровень защиты CRP3 отрубает основной загрузчик полностью, так что для начала сам загрузчик можно не патчить. А про заливку новых загрузчиков для 23xx/24xx я и сам бы с удовольствием послушал бы.



Недобросовестным партнерам никто НИКАКИХ загрузчиков не отдает. Речь шла о том, что все равно есть люди "в наших окопах", все "белые и пушистые", которые и шьют загрузчики с ключами и прочим. Выше я привел пример, как можно просто и изящно изъять у этих людей всю нужную информацию.

Так не было для 23xx/24xx пока обновлений. Вот и появился вопрос - "А вдруг было, а мужики-то и не знают?"

Почему? Клавиатура здесь для примера - вводить ключ можно по разному.

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

Чего его контролировать, если он и так может оказаться "дырявым"

1-е утверждение правильное. Я знаю как шить чипы LPC213x/01. Мы в нашей конторе написали свой загрузчик.
2-е утверждение неверно. Я нашел инфу в инете через Гугл. Просто надо уметь искать и принимать во внимание, что инет - не статическая во времени вещь. С 2006 года многое могло поменяться.

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

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

Ander, я потратил несколько дней, но за два года инфы в интернете, видать, накопилось столько, что никак не могу отыскать нужные мне сведения по методу записи без IAP. Ничего более конкретного, чем объявленная выше VslavX-ом ссылка не находил. Не подскажите ли чего-нибудь на config_n@hotmail.com

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

а то jtag такая хорошая штука и так ее обломать - ну пусть скан(sc0) не сделали но все остальное так прятать просто руки опускаются

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

Обсуждайте.... Проблема, правда, надуманная, но форум и не такое стерпит.

мдее... как бы это ответить -пожалуй не буду
перечитайте свои посты сами

Вчера "приговорил" LPC2368.
Отладил свой вторичный загрузчик, проверил работу команды "тотальной аннигиляции" (стирает всю доступную флеш включая поле @0x1FC). Наконец, установил CRP3 - ессно, JTAG отрубился. И тут я обнаружил, что залил отладочную версию моего загрузчика - она при старте в DCC сообщение кидает, типа "Secondary bootloader started". И все - JTAG залочен, а мой загрузчик стартануть не может - на выводе отладки виснет.
Понятно, что я как бы сам дурак, но NXP тоже хорош. В-общем, загрузчик и работа с флешью в LPC сделаны через "универсальный интерфейс" . С Атмелом я за три года на такое не попадал - ножка ERASE рулит.
Еще момент - у меня во флеши есть небольшой блок - <100 байт, в котором храниться всякая уникальная и номерная информация, которая иногда может и должна изменяться загрузчиком по командам со внешнего интерфейса. Пришлось для этих 100 байт целый сектор на 4K отвести . А в SAM7 была красота - там страничками по 128/256 байт стирать/модифицировать можно было. Ото ж - не кругом в LPC шоколадом намазано
Начал потихоньку загрузчик v3.3 ковырять - вылезло еще неизвестных 2 сектора памяти - память по адресам 0x7E000 не совпадает с памятью 0x7FFFE000. Причем отличия 2368 и 2378 именно в этих недокументированных секторах - по адресам 0x7E000.

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

Просто Atmel не сделал у себя отключение ножки "Erase" и Вы не смогли ее отключить . Это есть достоинство? Естати, тот-же Аtmel у AVR позволяет напахать и дополнив это отключием ножки "Reset" получить аналогичный результат. А вообще на самый крайний случай никто не мешает в своем загрузчике или проиложении завести люк для аварийного стирания/включения/перехода в штатный загрузчик по своему усмотрению.

Не удобно (в том смысле, что 256 байт лучше, чем 4K, а 1 байт еще лучше, чем 256 ), но не смертельно. Никто не мешает, тем более на этапе загрузки, когда RAM без вариантов завались, воспользоваться ей в качестве буфера для сохранения этих 4K.

Атмел сделал "печку" от которой можно "плясать" - в любой ситуации. BTW, этой "печки" не было еще в SAM7A3, в следующих чипах она появилась - ножка ERASE. В итоге, SAM7 можно достать из любой мыслимой дупы, в которую его можно загнать программно, а вот LPC - нет, так как есть некоторое метастабильное состояние. Разница ощущается?

Да оно все не смертельно. За исключением ситуации в предыдущем посте

Нет.
Никакого принципиального достоинства в ограничении свободы не вижу. У Вас либо есть свобода отключить все совсем, либо есть возможность оставить эквивалент той самой "Erase" ввиде полностью урезанного штатного загрузчика. Хотите еще и свой "Erase"? Берете любую удобную для себя ножку и назначаете ее в своем загрузчике/приложении "Erase". У меня это, например, один из пинов на JTAG.

Интересно, а как на этапе производства этот-самый bootloader попадает во-флеш?

А наверное через JTAG.

Сомневаюсь, эти чипы без bootloader-а пользователю прошить нельзя (через JTAG вызываются функции IAP, сам JTAG ничего о порядке работы с FLASH незнает)

А кто мешает залить в RAM функции которые "шьют" флеш без IAP? У производителя такие явно должны быть, это ведь только клиенты не удостоены чести знать алгоритмы.
Основной вопрос в том, разлочится ли JTAG если в "секретный" регистр не будет прописано нужное значение CRPx - при пустом флеше такого явно не происходит - некому прописать. Изначально сразу после аппаратного сброса JTAG залочен и, возможно, есть какой-то счетчик, который спустя некоторое время должен JTAG разлочить, если "секретный" регистр не прописан.

Согласен полностью.

После подачи питания JTAG не залочен - TAP контроллер захватывает работу ядра, время ему на это надо, вот и создаётся впечатление что JTAG залочен. А CRP - наоборот запрещает работу JTAG если записаны "магические слова" по фикс. адресу во флеш (расположенные рядом с загрузчиком - не путать с 0х1FC)

Что значит "захватывает работу ядра"?
TAP - отдельно, ядро - отдельно. Через TAP можно рулить ICE, а уже ICE в некотором роде рулит ядром.
Просто пока успеешь проинициализировать TAP+ICE и выставить Debug Request в DCSR - JTAG уже отваливается - ядро работает и пишет "Magic Number". Действительно, может сам JTAG и не залочен , но сделать ничего полезного до включения блокировки ядром не получается.
Были мысли притормозить ядро, но LPC23 стартует на внутреннем генераторе - тактовую не остановишь, игры с RESET-ом тоже ни к чему полезному не привели - ICE при сбросе блокируется.

"Магические слова" проверяются по адресу 0x1FC кодом в загрузчике почти сразу при старте. Если слово в 0x1FC "магическое", то загрузчик блокирует JTAG прописывая 0x87654321 в "секретный" регистрик @0xE01FC184 - Вы это подразумевали?

Уважаемые эксперты, позвольте вмешаться с вопросиком. Собственно вопрос: Возможно программно ввести LPC2378 в режим программирования ISP? Чтобы в терминалке знак вопроса, Synchronized и прочее. Пробовал коверкать данные по адресу 14, виснет на раз, но в режим программирования не становиться.

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

не, где-то инфа пробегала о возможности защиты от считывания/записи отдельных секторов стандартными ф-ми bootloader-а

Команда IAP "reinvoke ISP" чем-то не устраивает?

Да,
- привести контроллер в максимально исходное состояние (контроллер прерывний, PLL, ....);
- запрограммировать пин по которому при старте загрузчик сваливается в консоль на выход, записать туда 0;
- перейти по вектору сброса;
- прочитав на желаемом пине 0 загрузчик свалится в консоль.

Примерно так:
PLLCON &= ~(1 << 1); // Disconnect the PLL
PLLCON &= ~(1 << 0); /* Disable the PLL */
VICIntEnClear |=0xFFFFFFFF;

Что-то вроде:
PINSEL4 &= ~(0x03 << 20); /* Clear P2.10 function bits, enabling GPIO function */
FIO40DIR &= ~(1 << 10); /* Configure P2.10 as an input bit */
FIO4PIN &= ~(1<<10);

А вот здесь не знаю что делать. Ассемлерную вставку по идее надо типа "переход по адресу" Комада вроде "В". Или не прав? Как записать грамотно? Может ещё в чём-то не прав?

Ну вот Вы сами ответили на вопрос.
Нет загрузчика, никто и не прописывает никакие кодовые слова - значит JTAG в голом чипе доступен всегда.

Чуть что, так сразу ASM .
name - это собственно адрес чего-либо;
name() - это вызов по адресу....
теперь вместо name берем константу 0, говорим, что это указатель на функцию без параметров и вызываем:
((void(*)(void))0)();

Уважаемый, zltigo, переход на нулевой адрес работает отлично... но в режим AUTO-BAUD не становиться. PLL отключил, ноль сформировал на P2.10 (у меня LPC2378). Перезапускается и привет. Пробовал отключать стожевик, уарт (находил примеры для 2100) - бесполезно. CRPх не разрешал. Смотрел по алгоритму в мануале на LPC2378 больше ничего криминального нет. Что не учел?

Переход нужен с возвратом в режим SVC.

На внутренний RC переключились?

переключаюсь, с помощью регистра CLKSRCSEL=0;
принципиальной разницы, когда это делать, до или после отключения PLL, как я понимаю, нет.




можно поподробнее, пожалуйста

Пардон, заработало. Всем большое спасибо.

А ведь интересная была тема. Пока, по данным NXP, текущие версии загрузчиков не взломаны. Также не взломан и интерфейс "заводской" прошивки микроконтроллеров. Так что господа могут защищать свои программы штатными средствами МК, сильно о сохранности не беспокоясь. За исключением случаев физического проникновения в структуру МК.
Но для таких случаев существует EAL5+ сертификация. Если устройство прошло такую сертификацию, то во внутренней флеш можно смело зашивать номер своей кредитки с пинкодом.