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

1) в NXP сказали, что "закрыто"
2) дизасм можно найти в нете
3) опасно, чревато тем, что этот интерфейс поменятеся в следующей партии

1. NXP в свое время закрывала загрузчик и на RD2...
2. Прикинь какой это "гемор" с DASM ковыряться...
3. NXP сама не разрабатывает. Или покупает лицензию или заказывает где-то. Поэтому маловероятно, что изменится механизм программирования.
От этого всего не легче... Мне надо отдавать закодированные hex. Видимо придется по-другому выкручиваться.

Это Вы о чем? NXP вольна изменить технологию и прочие нюансы своего собcтвенного Flash когда пожелает. Зачем лезть в прямое программирование Flash, если предоставляется высокоуровневый интерфейс гарантирующий независимость от последующих изменений. Горько жмут несколько килобайт Flash? - возьмите LPC2366/8

Заменить не получится - загрузчик защищен от записи в себя

Снимается. Раньше по образу и подобию официального обновления прошивки, а теперь и библиотечки выложили. Только вот смысла в этом нет практически никакого.

А что за библиотеки выложили, и где?

На NXP, естественно, где-то весной прошлого года. Библиотеки для установки снятия security с любого сектора. Пробовал - работает.

В ту же тему. Есть ли возможность защитить изделие на похожем проце (ARM NXP) от тиражирования у контрактного производителя. Железо делают они, они же прошивают и продают, а мне нужно знать сколько приборов было произведено (прошито). Используя стандартный загрузчик шифровать прошивку не получится.

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

Кто Вам это сказал? NXP вообще очень ленивая компания. Описание прямого программирования дают практически все производители.
Упомянутый Вами, высокоуровневый интерфейс жрет 8кБ флэш. Мало того, если я захотел написать загрузчик для USB, CAN и др. мне придется потратить еще примерно столько же.
Камень 128кБ. Теперь, если учесть некомпактность кода 16/32 битных процессоров, ЧТО ОСТАНЕТСЯ НА САМУ ПРОГРАММУ? Вы предлагаете поставить процессор побольше? А Вы знаете насколько повышается стоимость изделия? Следующий в серии камень стоит в 3 раза дороже. Удорожание составляет примерно 180-200 руб. 200 *1000шт/мес*12=2 400 000 руб в год. А если выпуск больше? Нифига себе решение, да? Мне -то вроде бы все равно, а вот заказчик на такое не пойдет.

Вы хотите сэкономить 8кб флэша? А если запятую через неделю придется дописать и не влезет?

8kB это не запятая. Это очень много. Кроме того, не только сэкономить , но и иметь возможность кодировать данные для загрузки.

Кто Вам это сказал ?

Вот ленивые, не собирающиеся менять Flash в своих контроллерах и дают...

8K на уровне 128K это совсем не много.

Теперь попробуйте вместо рассуждений просто писать программы. Узнаете про "некомпактрость" и про потребные размеры Flash.

И в этом Вы совершенно не ориентируетесь Мало того, что сам чип стоит чуть больше 100 рублей поштучно, так и +128K Flash у следующего стоят рублей 20, примерно...

А почему не *1000000000 ????
Короче, пока пустой треп.

У меня debug и release сборки отбличаются больше, чем на 8кб. Если 8кб это критично - Вы, со временем, не сможете нормально отлаживать.



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

Объясните подробнее.
Допустим у меня на плате есть уникальный серийник (DALLAS или что то подобное), как в этом случае защититься от тиражирования? Я заранее не знаю номера серийника, знаю только, что они не повторятся. Я не имею возможности осуществлять програмирование загрузчика, который бы раскодировал зашифрованый hex файл при загрузке. Но я могу сделать так, чтоб программа читала серийник и отдавала компьютеру (устройству производящему програмирование). Но протокол загрузки LPC открытый и если подслушать програмирование можно восстановить исходный файл.

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

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

1. 8 kB это для меня много. И это не обсуждаемо. Это условие вопроса по-умолчанию.

2. Насчет компактности кода Вы не правы. Одинаковый функционально код написанный на 51-м и на ARM имеет в ARM больший в 1,5 -- 2 раза размер. И если Вы такой крутой программер Вам это должно быть известно.
3. Это Вы совершенно не ориентируетесь в ценах.

А если сказать по-русски -- Вы болтун... :-))) К тому же хам...
Кто Вас пустил в модераторы этого форума мне непонятно. Жду извинений.... Я не злой.

Когда кто-то чем-то не владеет, то сразу начинает для обороны выстраивать догмы "не обсуждаемо" и точка.

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

Остапа понесло.. Любуйтесь:
http://mt-system.ru/index.php?store_search=lpc236&id=5
Если Вы хотите доказать, что сможете постараться и купить где-то LPC2366 дороже чем LPC2364 на 200 а на 20 рублей, то я опять Вам верю и даже отговаривать не буду.

А я от Вас не жду - по всему видно, что безнадежно

Когда кто-то чем-то не владеет, то сразу начинает для обороны выстраивать догмы "не обсуждаемо" и точка.

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

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

Просил же не хамить... :-)))

Остапа понесло.. Любуйтесь:
http://mt-system.ru/index.php?store_search=lpc236&id=5



Если Вы хотите доказать, что сможете постараться и купить где-то LPC2366 дороже чем LPC2364 на 200 а на 20 рублей, то я опять Вам верю и даже отговаривать не буду.

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

А я от Вас не жду - по всему видно, что безнадежно
Ну почему же? Извините если я Вас чем-то оскорбил...

Ладно... Что болтать -- работать надо. Все равно никто не ответит на мой вопрос. Зарекался же на форумы ходить...

Любимые мои LPC чипы с цифирью кончающейся на 8 причем "картинок" во Flash у них нет. Посему своими "большими" приложениями можете гордится перед другими .

Это констатация факта. Для ориентации в реалиях можете попробовать собрать чего-нибудь стандартное, например, попугаемер Dhrystone 2.1 под ARM и 51.

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

Уже ответил - овчинка, при сколь-нибудь нормальном комплексном подходе к делу (покупаем контоллеры по реальным ценам, аккуратно пишем программы) выделки не стоит .

Арифметика у Вас какая-то жестокая. Только что проверил по прайс-листу. LPC2366 дороже LPC2364 в 1.196 раза. А запись во флеш не раскрываем по двум причинам:
- совместимость.
- патентованный МАМ модуль.


Так было с 8-битными. Вернее не совсем так, но с привлечением 3-й компании. С АРМ NXP всё разрабатывает сам.

Спасибо, за наиболее полный ответ.
А насчет цен ошибочка вышла -- при производстве в Китае 2366 стоит около 160 руб.

Я так понял Вы имеете какое-то отношение к NXP. ("не раскрываем"). Всвязи с этим вопрос.
По даташиту в LPC boot располагается в верхних адресах флэш.
От одного человека слышал, что на последних сериях камней boot находится совсем в другом месте(???) и не занимает флэш пользователя. То есть , например, в 2364 практически все 128 кБ свободны для программ пользователя. Верно ли это?

--- zltigo, обрати внимание на человека умеющего общаться без хамства и гипертрофированного самомнения...

Угу.. Только просьба перечитать свои посты и дать оценку апломбу с которым Вы пытались рассказывать о ценах. Да и обовсем остальном тоже...

Для этого не надо слушать "человеков", нужно просто читать документацию - у всех, кроме 512K моделей вся Flash доступна пользователю. Только у 512K от 8 до 12K занимает загрузчик.

я Вам больше скажу, lpc2364/66/68 - это один и тот же кристалл.
NXP не заморачивается изготовлением трех процессоров. Реально выпускается один и только в последнем цикле часть функций блокируется.
Отсюда следует, что себестоимость у них одинаковая. Различия в цене - чисто маркетинговый ход.

Поэтому на больших количествах цена на 64 и на 68 будет практически одинаковой.

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

забыл сказать - 2366 в диджикее при количестве 5000 штук стоит 5,795 USD.

если в Китае есть хоть один проект с его использованием в нормальных объемах, т о там он стоит 3-4 доллара.

Вот тут и начинаются мелкие нюансы. Чтоб пересылать мне номера ключей, у производителя должна быть прошивка, которая могла бы их читать. А еще лучше, могла бы выполнять ограниченый набор функций (для проверки работоспособности изделия перед продажей). Если ограничения в работе на объекте зависят от выданых ключей, значит у производителя есть вся прошивка (без ключей работающая в ограниченном режиме и не шифрованная), которую он волен запустить в дизасемблере под отладчиком, обнаружить затычку (или несколько) и заблокировать ее (в простейшем случае заменой условного перехода на безусловный). Все будет зависеть от квалификации ломателя. Поэтому, выдавать нешифрованную прошивку смысла нет. Но чтоб можно было пользоваться шифрованной прошивкой в проц нужно загрузить бутлоадер с дешифрователем. А как это сделать? Снова речь идет о выдаче открытого hex-а с алгоритмом дешифровки (пусть даже он привязан к серийнику). А это просто еще одна ступенька в лестнице к взлому, не более того.
Не хотелось бы орентироваться на защиту через незнание, все тайное когдато станет явным (вспомните MIFARE), а хотелось бы придумать такой алгоритм, где суть алгоритма известна, но все же вскрыть его сложно.

Тогда "враги" поставят "симулятор серийника"

Я тебе не очень верю,а в документации я не нашел. Возможно я что-то пропустил? Может быть приведешь название документа и номер страницы?
Ты меня уж совсем загрыз... Тебе это зачем надо? Чтобы почувствовать себя что-то из себя представляющим разработчиком? А треп насчет камней с восьмерками в конце -- возможно просто треп. Назови свое изделие которое выпускается партией более 500 шт. в месяц. Хотелось бы глянуть.

Кстати-да! кто мешает поставить эмулятор датчика с зашитым в него "уникальным" серийником?

UM10211 (user.manual.lpc23xx.pdf)
Chapter 29: LPC2300 Flash memory
страница 591 of 600

Because of the boot block, the amount of flash available for user code and data is 504 K bytes in "512K" devices.

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



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

Обычно стараюсь более широко смотреть на имеющиеся проблемы и не проходить мимо явной дезинфрмации.

Сложность программ как-то коррелирует с серийностью их выпуска?


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

Это я видел. Для меня было бы понятнее если бы написали конкретно -- в девайсах менее 512к флэш пользователя не занята 8к загрузчика. Спасибо.

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

А насколько открыт протокол програмирования встроенной флешь через JTAG интерфейс?
Есть такая мысль, собрать аппаратную приблуду на стороннем проце (с закрытой прошивкой) которая при коннекте к разъему JTAG и последующем включении прошивает загрузчик в целевой LPC. А потом грузим его через бут лоадер шифрованным hex-ом.
Эта аппаратная приблуда и считает сколько раз она прошила прибор.
Покритикуйте идею. Насколько сложно подслушать и воспроизвести процесс програмирования через JTAG? И нужна ли в данном случае привязка к серийнику?

Легко. Тем более, что воспоизводить-то и не надо. Только содрать прошивку.

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

Может так?
Эта некая аппаратная приблуда читает серийник, зашивает в проц алгоритм расшифровки, проц запускается из ОЗУ, затем в него льется зашифрованный загрузчик (серийником) который расшифровывается процом и пишется во флешь, после этого флешь закрывается.
То есть нужно будет перехватывать алгоритм расшифровки и отделять его от загрузчика. А весь файл будет всегда разным.

Ответ простой - надежно - никак.

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

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

Ага, в отличие от банкомата, имеются и все прочие коды, посему выдать "шиш" не получится - придется давать "бабки".

Еще одна идея.
Исходим из того, что серийники в целевых платах менять не могут.
Програмируется устройство аппаратной железякой. Железяка кроме интерфейса с програмируемым процом имеет еще и свой интерфейс с серийником.
Железяка читает серийник платы. Сравнивае, не работала ли она ранее с этим серийником.
Вставляет его (или функцию от него) в нешифрованный загрузчик.
Грузит его в проц и закрывает флешь от чтения.
Загрузчик в проце запускается, читает серийник с платы и если он совпадает готова к прошивке целевой программы.
Железяка шифрует программу и загружает ее в проц. загрузчик расшифровывает ее серийником (или функцией от серийника) и прошивает его во флешь, сам стирается и закрывает флешь от чтения.
Целевая прога стартует, сравнивает серийник на плате и если он тот, то стартует.
Железяка инкрементирует счетчик.
Когда счетчик вышел, отправляйте железяку разработчикам или покупайте новую.
Понимаю, дыра есть, но покритикуйте сложность взлома.

Скоро надо будет запретить прием к рассмотрению проектов "вечных двигателей". Лично я престаю их рассматривать

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

Я всегда делал проще. Программой кодером кодировал часть файла через XOR со сдвигом. В загрузчике на камне декодировал и записывал. Об это зубы обломать можно запросто. Хотя и ломается я думаю. Но времени уйму убъешь. В интернет выкладывал кодированную прошивку и все. Новая версия вышла или какой баг обнаружился пользователь перешивает. А у AVR вон код AES выложен -- посложнее будет сломать, только вот ни к чему так заморачиваться.

DES или AES в AVR реализовать ваще не проблема, так уже делали.
Здесь проблема в том, что загрузчик тоже шьет заказчик. Читайте весь топик.

Ломается элементарно. Поверхностное описание методики взлома было, кажется, у Скляра в "Цифровой связи".

Да со минимальным знанием конкретики (таблица векторов, их контрольная сумма в ней, известное содержимое 0x1FC) такое и просто в лоб (а если еще и hiew/qview подобную утилитку вместо клочка бумаги .... )ломается и без всяких правильных методик на 1-2-3.

Загрузчик-то нешифрованный )) и, например, моя прога, которая шифрует обновление прошивки, загрузчик вообще откусывает, потому как он лишний в этом файле.

Я шифрую с помощью tiny encryption algorithm, читал, что он довольно стойкий для одного абзаца кода.

Не принциапиально, приводился просто пример достаточно известных данных. Годятся и многие другие известные данные.



Для того, что бы не заморачиваться чтением рассуждений на эту тему использую AES256

Возможно ты и прав, zltigo... Но ведь подобные алгоритмы занимают довольно много flash и медленновато работают на контроллерах(в нашем случае, вроде, некритично). Ты говоришь, что XOR со сдвигом быстро ломается? Разговоры , типа "ломается на 1-2-3"--лишь разговоры.
Может попробуешь?
Вариант 1
Исходные 4 байта 61A0DE88
Конечные 4 байта C0302FD8
Вариант 2
Исходные 4 байта FF5BA8C6
Конечные 4 байта 1AE5DE55

Если еще надо спроси...
Даже если тебе дать алгоритм, то на вычисление маски и смещения уйдет уйма времени.
Если использовать кодирование по 8 байт еще дольше провозишься.
Если конечно ты не везунчик и при первом же случайном выборе не попадешь в точку:-)))



Все ломается. Только сколько времени и сил уйдет? См. ниже.


Sorry... Это получается типа картриджа для сотовых телефонов?



Смотря какой коэффициент корреляции... Но ведь я пока не вижу ссылку ни на, хотя бы , одно?


Есть тут одна сложность. Кто держатель этой железяки? Например, это дилер по месту продажи. Так вот, дилеры, обычно, далекие от техники люди и ни за что не хотят свзываться с перешивкой изделий.
Если обнаружился глюк , не выявленный в результате испытаний изделия, то его просто отправляют назад. В случае, если загрузчик уже зашит, любой пользователь может взять кодированный файл в инете и записать.
Кстати не все фирмы закрывают свое ПО. Исходят из того, что массово повторить изделие довольно сложно.


Есть тут одна сложность. Кто держатель этой железяки? Например, это дилер по месту продажи. Так вот, дилеры, обычно, далекие от техники люди и ни за что не хотят свзываться с перешивкой изделий.
Если обнаружился глюк , не выявленный в результате испытаний изделия, то его просто отправляют назад. В случае, если загрузчик уже зашит, любой пользователь может взять кодированный файл в инете и записать.
Кстати не все фирмы закрывают свое ПО. Исходят из того, что массово повторить изделие довольно сложно.

"Много" это сколько в байтах? Куда,например девать оставшиеся байты в секторе боотлоадера?
При этом поминаемый ранее TEA совершенно микроскопический, но имеет оцененный уровень криптостойкости. Да и тот-же AES256 занимает у меня в загрузчике порядка 900 байт (без особой опримизации под 32bit), при этом в bootsector-е еще почти 900 байт остаются для развития.

Отнюдь всякое приходилось лично вытворять в 80x-90x годах - в то время, когда считающие, что просто XOR c легкими наворотами это круто, еще не вымерли.

Ссылок не будет и исходников не будет. А моя область применения LPC это в основном телекомуникационое оборудование. Например, поддержка протоколов:
♦ SS7 MTP3: ITU-T Q.704, Q.707, ETSI 300
008, 300 008-1, ANSI T1.111, Bellcore
GR246, GR606, GR82
♦ SS7 MTP2: ITU-T Q.703, ETSI 300 008,
300 008-1, ANSI T1.111, TTC JT-Q.703,
ITU Q.703 Annex A 1996, China
SS7 YD/T 1125 - 2001
♦ SS7 MTP signaling performance ITU-T
Q.706
♦ M3UA: RFC 3332
♦ M2PA: IETF
♦ SCTP: RFC 2960, RFC 3309
♦ LAPB/D: Q.921, TR 41449, TR 62411
♦ LAPF:Q.922
♦ LAPV5
♦ X.25: CCITT

Гуглом найдете, что это такое

Я безумно напуган всеми этими названиями, zltigo. :-))) Ты еще не все протоколы назвал, zltigo(etc. Злой тиго).

А насчет XORов... Я же тебе послал байты для дешифровки.

Дело в том , что НЕТ смысла закрывать ПО сложными алгоритмами.
Предположим что ты взломал алгоритм декодировал ПО, у тебя есть схема и разводка... Но ведь чтобы сделать и ПРОДАТЬ изделие в количествах опасных для первого производителя надо потрудиться.

А то AES, DES... нафига?