UniSoft

Это зависит от наличия соответствующей лицензии: JFlash эти опции могу быть изначально активированы в BASE, либо соответственно купив дополнительные лицензии. Они вводятся кодом (если важна легальность), и для этого есть у них соответствующая утилита: J-Link License Manager Можно даже найти калькулятор (я как-то тоже его писал, возможно еще где-то гуляет по сети, правда не знаю, работает ли он еще)... Сейчас он особо не актуален, все можно добавить и через J-Link Commander (тут уже не раз это писали). Про него... Оно будет ежедневно выскакивать.

Серийный номер тут не причем... Это не из-за него... вот полный список забаненных серийных номеров: (из последней dll v6.64) к defective так-же приводит наличие фичи: "GDBFull" (она допустима лишь для некоторых старых jlink'ов, v9, v10... не в их числе) так-же к этому ведет несовпадение хэша серийника, это второй UINT32 идущий сразу за серийником... Он должен быть либо корректным, либо просто 0xFFFFFFFF, считается как-то так: Ну и собственно инвалидная сигнатура, т.е. сама dll не может корректно дешифровать сигнатуру... кстати сама dll не проверяет соответствие sn сигнатуре, это делается в самом jlink'е. Возможно в вашем случае в jlink'е просто в bootloader добавлен код, который перед запуском основной прошивки просто патчит проверку сигнатуры (а вместо реальной сигнатуры просто мусор, либо пусто) в плане прошивки, наличием строки (редакции) "SEGGER-EDU" в плане софта: меньшим кол-вом фитч (ну там например JFlash не будет работать, ...), ну и надоедливым наг скрином, который не даст забыть, то что это EDU и не может быть использован в коммерческих целях. А то вдруг забудете. Данная строка хранится в программно реализованной OTP памяти (допустимо только запись бита из 1 в 0). Таким образом из BASE можно легко сделать EDU, но не наоборот. Стереть строку просто так не получится там допустимо только строгое соответствие одной из строк: (пустая строка, т.е. первый байт 0xFF есть BASE) . Легального пути преобразовать EDU в BASE нету, и такая опция даже не заложена в прошивке. Следовательно любые манипуляции с прошивкой и патчами - противозаконны.

Она идет в комплекте с keil'ом... C:\Keil_v5\ARM\BIN\ElfDwT.exe

В общем удалось как-то победить данную проблему, правда через ж... зад.. 1. В постбилд'е переименовывается (копируется) firmware.out в firmware_orig.out 2. Своя утилита обрабатывает бинарник и запихивает его в elf файл firmware.out (одной секцией без дебаг инфы, если кому нужно, исходник функции во вложении) 3. Во вкладке Debugger включаем использование макроса execUserReset() { __var value; __message "---- execUserReset ----" ; // включаем возможность отладки в sleep (__WFI) value = __readMemory32(0xE0042004, "Memory"); value |= 0x00000027; __writeMemory32(value, 0xE0042004, "Memory"); } execUserPreload() { __message "---- execUserPreload ----" ; // тут грузим отладочную инфу из оригинального elf __loadImage("C:\\projects\\Test\\EWARM\\firmware\\Exe\\firmware_orig.out", 0, 1); } execUserSetup() { __message "---- execUserSetup ----" ; } elf.rar

В моем случае так проще... Постоянно перешивать устройство на debug/release муторно... это только основная прошивка, а там же еще есть и бутлоадер (точнее 2) которые не пропустят не подписанную прошивку. А это отдельные проекты. Это нужно открывать и пере-компилировать каждый проект отдельно, плюс еще внешнюю утилиту. А так подпись добавляется в автомате за миллисекунды, и не нужно никаких лишних движений. На массовое производство я итак написал для шефа свою одно-кнопочную утилиту, которая и прошивает и защищает контроллер как нужно, без всяких jflash'ей и прочей хрени, лишь JLinkARM.dll. У меня начальник китаец, хорошо знает как копировать девайсы, так как мы сами этим занимались неоднократно, отсюда и некоторые требования в плане защиты. А я по больше степени реверсер, так что хорошо знаю, как усложнить жизнь таким же реверсерам как я. --- P.S.: С IAR'ом я просто эксперементировал, просто интересно было попробовать. Не пользовался я им с 2014 года. С тем, чем пользуюсь сейчас, таких проблем у меня даже не возникало. У меня в email уже множество запросов на то, чтобы обновил свой кейген IARkg14_Unis (хотя последняя версия была IARkg15_Unis, но я ее никогда не выкладывал). Вы же знаете, что он более не справляется с последней версией EWARM, уверен данная тенденция продолжится и на остальные продукты. Вот и пробовал IAR, так бы может хоть стимул появился...

Так а в чем проблема? Вы же не меняете положение функций и переменных... просто добавляется подпись в конец файла подпись это RSA-2048... т.е. 256 байт... и нет, не проще скриптом, да и зачем, все же нормально работает, но не в IAR. VS2019 + visualGDB - лучшего редактора не видел.

Это Вы так троллите? Я знаю, что это elf, я же об этом написал в сообщении, зачем повторять? У меня 20-летний опыт в реверс-инженеринге! Читайте внимательнее! К тому же я писал про "Browse Information" а не про "debug information"... Это совершенно разные вещи.

Это вы про время компиляции? Вы в Keil в Options на вкладке Output снимите галочку с Browse Information... И увидите реальную скорость компиляции.

А в контроллер по вашему пишется что? ну ведь не .elf (он же .out)... Линкер выплевывает .elf файл, из которого получается бинарник, и в IAR есть опция. Далее этот бинарник подписывается, и его и нужно загрузить в контроллер, он ведь по прежнему соответствует .out, адреса функций, переменных все осталось на своих местах. Поэтому отладчик свободно берет инфу из elf, но в контроллер грузится бинарник. Тут нет никакой магии. Я же говорю, оно работает, просто контроллер прошивается дважды, сначала .out а потом hex... мне не проблема создать bin или hex. С elf'ом нет желания возится... так то можно и его создать, и там уже опцией --debugfile указать. Просто мне не верится, что подобной задачи (когда требуется некоторая постбилд обработка файла) ни у кого никогда не возникало. И что нет простого и очевидного решения. Во Flash...

Так там в настройках только одна опция для отключения прошивки "suppress download" ... установив ее, оно подавляет всю запись, даже из макроса. а *.out он итак подхватывает, даже с подавленной загрузкой.

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

Так и JLink.exe понимает, но это же не вариант в постбилде шить устройство. Прежде чем задать вопрос я это все прочитал, но не нашел ничего подходящего. __loadImage это то-же самое, что вы привели на скриншоте. В принципе как-то работает через ж..у, если указать hex файл, но и только двойная прошивка, сначала пишет *.out, а поверх этот hex... Не нравится мне такой поход. Ну да ладно, ну его на хрен этот IAR... не зашел он мне как-то... Во первых, это самый наихудший редактор (IDE), я уж думал с 2014 года (как написал кейген к нему) что-то улучшилось, но увы нет... Очень медленный компилятор! Но создает более оптимальный код (это единственный плюс).

Да это я видел, только толку мало... Не понимает оно bin файлы совсем. HEX файл принимает, но на вкладке Download нужно снять опцию Use Flash Loader(s), тогда загрузка производится средствами самого JLink... Но сначала грузится *.out, а потом уже поверх указанный hex... Как отменить загрузку *.out пока не нашел. Есть опция suppress download, но она подавляет все, включая эти extra image(s). Так что вопрос все еще в силе... Может кто уже делал что-то подобное.

Задача... Есть проект, компилится, на выходе включено создание bin файла... Далее в post-build этот бинарник подписывается, получаем новый бинарник, пусть будет project_signed.bin... Так вот как заставить IAR загружать в контроллер именно этот файл вместо *.out? (Естественно, чтобы отладочную инфу брал из *.out, но грузил в контроллер именно указанный бинарный файл) Пока что использую Visual Studio + VisualGDB + Keil compiler, там это легко реализуется, target remote :$$SYS:GDB_PORT$$ mon reset monitor halt #load monitor loadbin "$(TargetDir)\$(TargetFileNameWithoutExtension)_signed.bin", 0x08020000 monitor SWO EnableTarget 216000000 10000000 0x1 0 monitor reg sp = (0x08020000) monitor reg pc = (0x08020004) set *0xE0042004 = (*0xE0042004) | 0x00000007 А вот как подобное реализовать в IAR?

ULink это чисто KEIL'овский отладчик, поддерживается исключительно keil'ом. В целом он лучше при работе с keil, как-то более глубже интегрирован. Но он не продается отдельно, а дается в довесок при покупке кейла (ULINK PRO). А те клоны, что продаются, являются очень старой версией - ULINK 2.

Ну что сказать, плохо вычитали тему... Не банятся серийники (ну да, есть там несколько забаненых в dll серийников типа 11111111, ... ну и все)... Но тут нет никакой гарантии, что не добавят позже... мало ли что им на ум придет. Тем более, что функция уже реализована, достаточно просто добавить серийник в список. Клон можно выловить по нескольким факторам: другой контроллер + пропатчен бутлоадер, фэйковая связка (серийник + unique ID + RSA-signature). Я уже не раз тут писал, серийник + unique ID контроллера (знаете что это?) подписаны RSA подписью... Эти 3 составляющие мертво связанны! В клоне используется небольшой патч, который как раз таки и подменяет unique ID (как именно? ключевое слово FlashPatch...). А так как сеггеровцы однажды просекли эту фишку, то просто, в начале прошивки добавили отключение FlashPatch'а и обнуление всех его регистров. Отсюда и попадали все клоны. Итак, чтобы подменить серийник, вам нужно считать всю связку "серийник + unique ID + и саму подпись" с оригинального линка. найти способ подменить unique ID программно, пропатчить бутлоадер воткнув считанные данные и добавив функцию которая как раз и подменит unique ID, ну и все. Ну наверное в том, что исправляют косяки... Всю историю можно посмотреть на сайте. А насчет "постоянно получают проблемы", ну это вы преувеличиваете... Один раз это не постоянно... Нет, не сложно... только вот зачем? Чтобы потом это делать для каждой новой версии? Обновитесь новой версией и сразу кирпич будет. Вырезать ничего не нужно, можно просто обойтись небольшой функцией добавленной в бутлоадер, и все работает и обновляется.

Да есть она там, J-Link V11... контроллер тот-же... видел где-то на каком-то китайском форуме, что китайцы прошивали V10 этой версией V11 и работало...

Не знаю, но из всех клонов, что я видел, с этим было все в порядке (да я не рассматриваю всяческие usb-затычки, открывашки, брелки и прочую хрень со встроенным jlink'ом), на 19-ом пине +5 вольт, идет напрямую с usb-входа, как правило через fuse, низкоомный резистор и ключ. (хотя китайцы иногда экономят на fuse'ах, перемычки ставят) для управления состоянием существует команда: power <On/Off> [perm] (при наличии ключика "perm" запоминает состояние, и при включении будет сразу выставлять нужное). Что касается VTref (пин 1), то тоже ни разу не видел, чтобы он был подключен напрямую к питанию. даже наоборот, сам напаивал перемычку на 3.3v, чтобы лишний провод не тянуть с устройства при отладке. В v10, к счастью, появилась возможность программно выставить нужное фиксированное напряжение на VTref, и для этого есть соответствующая команда: vtref <value_mV> моя коллекция

Последнюю версию (4.3.5) можно скачать с сайта... таблетку под нее не делал, пока нет нужды ну и как следствие - стимула.

Что-то это какой-то совсем китайский колхоз, далекий от оригинала... не видно что за контроллер... это там voltage regulator, тот что около level converters?

Да они вроде как не планировали выпуск новых версий, но тем не менее V11 уже существует (по крайней мере прошивка под него есть в dll). @truevoxdei уже описал внешние отличия. немного добавлю, пункт 4, это совсем не обязательно что в клонах будет стоять LCP4337 (хотя из тех клонов, что я видел это так), но можно допустить, что могут быть клоны и на LPC4322, там в области бутлоадера достаточно места под патч. Китайцы же несколько заморочились, с попыткой скрыть метод патча (хотя они так всегда делают, т.к. прекрасно понимают, что другие китайцы могут склонировать их клон ). Разбавив код кучей мусорных инструкций и реализовав что-то типа простенькой ВМ, из за этого код получился довольно большой вот им и пришлось заюзать MCU с большим объемом памяти, а это как раз и есть LCP4337. Итак чтобы создать клон, нужно взять SN, UniqueID и RSA-сигнатуру (она же - цифровая подпись) с оригинального ж-линка... по сути просто считать полный дамп + считать UniqueID контроллера. Залив это в клон естественно получите труп, ведь UniqueID у нас будет другой... Так вот, в клоне, заюзав технологию Flash Patch, подменяли UniqueID на тот, что клонировали. Затем SEGGER'овцы это просекли и (в версии 6.32i) в начале кода добавили отключение и обнуление регистров Flash Patch. Как именно китайцы обошли это в более новых клонах, не имею понятия, не попадались. Это все относится к тем клонам, что я видел... можно допустить что есть и другие клоны с другими реализациями патча (ну например кастомный бутлоадер, и т.д. и т.п.). Ничего страшного нет, если ляжет, можно будет откатиться назад... без проблем... если есть оригинал, то зачем вам второй, берите клон и не заморачивайтесь. EDU и BASE отличаются лишь наличием строчки "EDU" в программной OTP (в контроллере реализована эмуляция eeprom (ну там где хранятся настройки и т.д.), а так-же эмуляция OTP (серийник, редакция (EDU, IAR, SAM7, ...)) таким образом BASE можно легко программно превратить в EDU (но не наоборот).

И получите труп... во первых обновление что лежит в dll не содержит бутлоадера (да и сигнатура лежит в области бутлоадера). во вторых кроме серийника и сигнатуры нужен еще и uniqueID контроллера (он тоже прописан в сигнатуре). в третьих сигнатура не читается dll'кой, проверка производится внутри прошивки, так что в логе ничего интересного не увидите. Это касается версии V10 Ну @truevoxdei вполне прав, они могут в любое время заблокировать клоны, это легче простого, также могут заблокировать по серийнику, все это конечно обходится, пока что. Ну заблокируют, можно будет просто откатиться на последнюю рабочую с блокировкой дальнейших обновлений.

Что вы подразумеваете под словом "баловаться"? в v10 им не побалуешься, от фонаря вбить что-либо не получится, можно только использовать реальную пару (серийник + сигнатура) от реального линка и да 2xxx. так что почти все клоны идут с одним и тем же серийником.

Там CRP1 стоит...

не надо ничего конфигурировать, единственное что надо P2_7 на землю посадить. Там стоит защита от чтения, так что не помню читается ли сигнатура. Надо стирать полностью. Но учтите, при стирании уничтожите сигнатуру, потом ее никак не восстановить... останется только искать дамп (сигнатуру и соответствующий ей uniqID) с рабочего девайса, и делать патч подменяющий uniqID.