Бреши в устройствах не всегда можно закрыть, в отличие от уязвимостей в софте. Однако это не повод для фрустрации! Исследовать безопасность IoT, телефонов, планшетов, блоков управления и т. д. все равно нужно. По крайней мере, можно предупредить пользователей об уязвимостях, а также устранить недостатки в новых версиях продуктов.

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

Немного о J-Link — исследуемом устройстве

J-Link — один из самых популярных отладчиков для микроконтроллеров среди разработчиков, любителей, энтузиастов и специалистов по кибербезопасности.

Вот его преимущества:

  • огромный перечень поддерживаемых микроконтроллеров и процессорных ядер,

  • поддержка всех распространенных протоколов отладки,

  • высокая скорость работы,

  • отличный бесплатный софт.

Производитель J-Link — компания SEGGER, которая выпускает свой флагманский продукт уже более 15 лет и за это время в полной мере столкнулась с проблемой контрафакта. Разные торговые площадки наполнены предложениями о продаже клонов по невысокой в сравнении с оригиналом цене. Но большинство подделок копируют старые версии J-Link — v8, v9 и старше.

Вероятно, разработчики SEGGER использовали накопленный опыт борьбы с контрафактом и в новых версиях, v10 и v11, реализовали более надежные методы защиты от копирования. Именно их мы и решили изучить.

Модели J-Link

J-Link — это не один программатор, а целая линейка продуктов, которые различаются по техническим характеристикам и доступным функциям. Набор функций определяется лицензиями, которые могут быть встроены либо приобретены на сайте производителя.

J-Link BASE

Набор встроенных лицензий в этой модели ограничен лишь основными функциями.

J-Link PLUS 

Эта модель имеет расширенный набор встроенных лицензий, который открывает доступ ко всем функциям ПО и технологиям вендора. 

J-Link PRO

У этой модели, как и у PLUS, есть полный набор встроенных лицензий.

J-Link PRO:

  • способна работать на более высоких скоростях;

  • имеет Ethernet-порт;

  • функционирует на основе другого микроконтроллера и имеет встроенную программируемую логическую интегральную схему (ПЛИС).

J-Link EDU

Самая младшая модель, предназначенная для некоммерческого использования. Продается без технической поддержки. Доступные в ней функции совпадают с функциями J-Link BASE. Перед каждым использованием нужно соглашаться с Terms of Use (рис. 1).

Рис 1. Соглашение об использовании J-Link EDU
Рис 1. Соглашение об использовании J-Link EDU

На самом деле J-Link EDU, J-Link BASE и J-Link PLUS — это одно и то же устройство: схемотехника, компонентная база и прошивка ничем не отличаются. В каждой из моделей меняется только набор встроенных лицензий.

В этой статье рассмотрим J-Link EDU v10, хотя все найденные недостатки распространяются на EDU, BASE, PLUS v10 и v11. 

Наше исследование. Как это было

Собрали вводные 

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

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

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

Покопались в J-Link EDU v10 

Разобрав устройство (рис. 2), мы обнаружили микроконтроллер NXP LPC4322, который реализует всю низкоуровневую логику, хранит встроенные лицензии и управляется с ПК по USB-интерфейсу.

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

Рис 2. J-Link EDU v10 и v11 в разобранном виде
Рис 2. J-Link EDU v10 и v11 в разобранном виде

Итак, мы выяснили, что просто считать прошивку с устройства через отладочный разъем не получится. После изучения софта вендора для ПК стало ясно, что можно получить дамп прошивки через процедуру обновления J-Link по USB — обычно после установки новой версии софта и подключения устройства появляется диалоговое окно с предложением обновить его.

Также можно принудительно перезаписать прошивку с помощью команды InvalidateFW. Если провести одну из этих процедур и параллельно записать USB-трафик, то можно увидеть, что новая прошивка передается в незашифрованном виде. Однако обнаружить эти данные в том же виде в директории с софтом не удастся: прошивки хранятся в зашифрованных файлах, а в более ранних версиях софта прошивки хранились в сжатом виде в JLinkARM.dll. Полученный дамп открывает возможности для обратной разработки и исследования.

После поверхностного анализа стало понятно, что разработчики разделили флеш-память MK LPC4322 на три части:

Номер

Область

Тип

Описание

1

0x1A000000 — 
0x1A005E00

Загрузчик

Проверяет подпись основной прошивки и отвечает за ее обновление. Сам загрузчик прошивается на заводе и никогда не обновляется

2

0x1A005E00 — 
0x1A008000 

Область конфигурации

Содержит серийный номер, OEM-строку, встроенные лицензии, цифровую подпись и настройки устройства

3

0x1A008000 — 
0x1A080000

Основная прошивка

Реализует основную функциональность устройства, может обновляться из управляющего софта с ПК. Имеет цифровую подпись, которая должна защищать прошивку от внесения изменений

Область конфигурации можно увидеть на скрине (рис. 3).

Рис 3. Область конфигурации J-Link
Рис 3. Область конфигурации J-Link

Вот как основная прошивка и софт на ПК проверяют, что работают с лицензионным устройством:

  1. После старта прошивка считывает серийный номер устройства, уникальный ID микроконтроллера и проверяет цифровую подпись RSASSA-PSS(SHA1(serial_number + uniq_chip_ID)). Если серийный номер устройства и сама подпись хранятся во флеш-памяти, то уникальный ID записывается производителем микроконтроллера (NXP) при их производстве и не может быть изменен. Все MK LPC4322 имеют собственные уникальные ID, перезаписать их нельзя. То есть не получится взять серийный номер и подпись одного лицензионного устройства J-Link и наделать его клонов.

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

Мы разобрались, что защита от копирования занимается лишь вопросом отделения лицензионных устройств от клонов. Осталось выяснить, как лицензионные устройства на базе одной и той же платформы различаются между собой со стороны управляющего софта на ПК. Оказалось, что для этого используются OEM-строка и набор встроенных лицензий. Например, для J-Link EDU используются OEM-строка SEGGER-EDU и лицензии FlashBP и GDB, а у J-Link PLUS OEM-строка пустая и следующий набор лицензий: RDIFlashBPFlashDLJFlash и GDB. После подключения J-Link к ПК софт запрашивает цифровую подпись устройства. Если она валидна, то OEM-строка и список лицензий, которые устройство отдает, считаются доверенными.

Нашли ошибки и рассказали о них вендору

Ошибка 1. OEM-строка и список встроенных лицензий не имеют криптографической подписи и не привязаны каким-либо образом к серийному номеру устройства. Если перезаписать эти данные, то можно легко переделать J-Link EDU в J-Link PLUS.

OEM-строка и список лицензий хранятся во флеш-памяти в области конфигурации. В отличие от уникального ID микроконтроллера, эту память можно изменить.

Один из способов перезаписи, который приходит в голову: каким-либо образом получить дамп флеш-памяти, внести свои изменения, а затем, используя встроенные команды ISP в BootROM LPC4322 и интерфейс UART, стереть флеш-память и записать новый дамп. Но для этого потребуется как минимум разобрать устройство.

Можно пойти и другим путем. После нескольких экспериментов с процедурой обновления и попытками внести в нее изменения стало ясно, что прошивка имеет цифровую подпись, которая проверяется на стороне устройства его загрузчиком. Для проверки используется открытый ключ производителя, который должен защищать от внесения изменений. Но существует команда принудительного обновления прошивки InvalidateFW, которая работает довольно интересным образом. В процессе ее выполнения на устройство загружается прошивка, где изменяется ASCII-строка с датой компиляции. Например, строка compiled Mar 21 2019 меняется на compiled MAR 21 2019. При повторном подключении к ПК и запросе версии прошивки такая строка считается некорректной датой, и прошивка обновляется до версии, которая идет в комплекте с софтом вендора. Это сделано для возможности отката на старую версию прошивки при проблемах после обновления.

Интересно здесь то, что такой дамп с некорректной датой успешно проходит проверку подписи загрузчика и запускается на выполнение. Оказалось, первые 0x1A0 байт прошивки не подписываются и не проверяются загрузчиком. Но ведь именно эта область — наиболее важная часть прошивки, поскольку в ней лежат векторы прерываний, в том числе reset-вектор, указывающий, с какой инструкции начинать выполнение кода (рис. 4).

Рис. 4. Начало области основной прошивки
Рис. 4. Начало области основной прошивки

Ошибка 2. Частичное покрытие прошивки цифровой подписью дает возможность выполнять произвольный код на устройстве. Используя эту брешь, можно легко запустить собственный код, который изменит OEM-строку и набор лицензий. В качестве демонстрации мы подготовили скрипт, который за несколько секунд превращает J-Link EDU в J-Link PLUS. Публиковать его не будем, чтобы не поддерживать пиратство.

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

Следующие особенности делают эти недостатки удобными для пиратства со стороны пользователей:

  • для эксплуатации не требуется разбирать или паять устройство — достаточно ПК с USB-интерфейсом;

  • устройство продолжает работать с оригинальными загрузчиком и прошивкой;

  • устройство продолжает получать обновления прошивки и распознаваться как оригинальное (исправлено с версии софта v7.58);

  • подмену лицензий необходимо провести лишь один раз;

  • устройство можно вернуть в исходное состояние в любой момент и без следов модификации.

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

Таймлайн:

  • 25 октября 2021 г. — сообщили о найденных недостатках в SEGGER через форму технической поддержки. После запроса передали технические детали и PoC для демонстрации ошибок.

  • 28 октября 2021 г. — представители SEGGER подтвердили наличие ошибок.

  • 1 ноября 2021 г. — представители SEGGER сообщили, что идет подготовка новой версии софта, которая будет включать частичные исправления.

  • 5 ноября 2021 г. — вышел релиз софта v7.58 с частичными исправлениями.

Дальше началась жизнь после ошибок. Вот как мы резюмировали внесенные изменения после поверхностного анализа нового релиза v7.58 и общения с вендором. 

Ошибка 1, отсутствие подписи лицензий, частично устранена. В новых версиях софта проверяется список встроенных лицензий на основе модели устройства: EDU, BASE и т. д. Модель устройства определяется по серийному номеру. Например, если серийный номер начинается с цифр 26 (J-Link EDU) и среди встроенных лицензий обнаружена JFlash, то устройство считается контрафактным. Версии софта до v7.58 по-прежнему будут воспринимать устройство как лицензионное.

Ошибка 2, произвольное выполнение кода, не исправлена, причем исправление не планируется в обновлениях для v10 и v11. Чтобы устранить ее, потребуется перезаписать загрузчик в уже выпущенных устройствах, которые находятся у пользователей. Такое себе удовольствие: много рисков, к тому же это сломает обратную совместимость с предыдущими версиями софта. Загрузчик с исправлениями, по информации SEGGER, будет реализован только в новых версиях отладчика.

Возможные последствия ошибок. Что же будет?

Вот что может случиться из-за проблем в механизмах безопасности пользовательских устройств. 

Пиратство со стороны пользователей

Это сильно бьет по карману производителя. Простой способ обойти систему лицензирования, который не требует разбора устройства, понравится многим пользователям. Ведь J-Link PLUS примерно в 10 раз дороже J-Link EDU.

Атаки на цепочки поставок

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

Выводы

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

Благодаря анализу архитектуры и исходного кода устройства получится найти уязвимости еще на стадии проектирования, когда ошибки исправить проще и дешевле. В отличие от софта, далеко не все уязвимости встраиваемых систем можно исправить, выпустив обновление. Некоторые из них останутся жить в устройстве на протяжении всего срока его эксплуатации. Семь раз проверь — один раз выкати на прод????

Бонус! Отладчик отлаживает сам себя. Смотреть без СМС и регистрации

Комментарии (27)


  1. rstepanov
    22.02.2022 16:35
    +3

    Предупреждение в J-Link EDU вроде как должно выскакивать раз в сутки, по факту оно вылезает перед каждой операцией, бесит ужасно. Так поневоле начнешь использовать китайские клоны, благо v9 для моих хобби вполне достаточно.


    1. UniSoft
      25.02.2022 10:38
      -1

      Оно выскакивает раз в сутки! Галочку нужно ставить "Don't show this message for today"


      1. rstepanov
        25.02.2022 10:39

        У меня эта галочка не работает правильно. macOS Monterey.


  1. HEXFFFFFFFF
    22.02.2022 17:28
    +3

    Они дирут непомерные деньги за свои копеечные железки. Не буду же я, работая инжинером, тратить свою месячную ЗП на такую железку. Работодатели тоже не психи и оплачивать несколько штук $ за платку себестоимостью в пару баксов не будут. Так что если не хотят что бы их ломали пусть назначают адекватную цену.


    1. count_enable
      22.02.2022 18:49
      +3

      J-Link не является жизненно необходимым, они вправе ставить любую цену на свои устройства. Дорогие? Так вы ещё Lauterbach не покупали.

      J-Link это рудимент начала нулевых, когда JTAG-отладчики были роскошью, и даже программаторы стоили ощутимых денег. Помню когда Atmel выпустила свой ломучий и глючный Dragon за 90$ - народ раскупал моментально и радовался, ибо это было в 5 раз дешевле чем профессиональный отладочный набор. А через пару лет ST начала раздавать STM32 платы с бесплатным STLink, и ICE стало чем-то само собой разумеющимся.

      Нужен ли J-Link в 2022? Сейчас есть куча открытых отладчиков на FT2232, включая фирменные (Digilent), которые и быстрые (20-30 МГц), и поддерживают кучу МК, и прекрасно скриптуются. Возможно для каких-то продвинутых возможностей отладки встроенных ОСРВ, или лютой экзотики J-Link и нужен. Но на популярных семействах МК вполне реально вести полноценную коммерческую разработку используя только открытые софт и железо.


      1. HEXFFFFFFFF
        22.02.2022 19:02
        +1

        Ну вот я сейчас работаю с последними чипами от nordic. Они там тестно работают с сигером. Их ide ни че кроме J-link не поддерживает.


        1. count_enable
          23.02.2022 00:35
          +3

          Мы перешли от IDE до VScode/vim + Make + gdb. И вижу всё больше инженеров, отказывающихся от фирменных ide в пользу подобной связки.

          Мейнстримные IDE это в большинстве случаев ухудшенный эклипс. Вещи типа Code Composer Studio или STMCubeMX вообще за гранью мыслимого и немыслимого, пользоваться ими невозможно.

          Платные Iar или Keil очень отсталые по меркам современных программистов, негибкие, управление репозиторием или системы сборки очень слабые. (Признаю, не следил за ними лет 6 - может что-то и поменялось).

          Из осей доступны Windows, реже Debian и почти никогда MacOS - а Макбуки вполне популярны среди программистов.

          Связка из текстового редактора, системы сборки и отладчика универсальна. Программист может её настроить согласно своим вкусам и потребностям. Она легко скриптуется и встраивается в CI/CD (пробовали может встроить проект на Кейле в CI?).

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


          1. HEXFFFFFFFF
            23.02.2022 00:51

            А как вы считаете сколько времени займет разобраться с их компилятором, набором библиотек, sdk , структурой проекта? И написать удобные рабочие скрипты и конфиги для работы в VS-code. Что бы работало автоматическое создание проекта, конфигурирование zephyr, дебаг итд итп (мне самому VS-code нравится, пишу на нем под stm, esp)

            По моей оценке на это можно убить не один месяц. И это само по себе приличных оьбемов проект. И работодатель/заказчик/клиент/начальник платить за это не готовы. Они хотят быстрый видимый результат. Поэтому приходится брать и работать с тем что есть.


            1. MinimumLaw
              23.02.2022 10:43
              +1

              Это вопрос, ответ на который знаете только вы. Только у вас есть требования и сроки для ваших проектов.

              По факту у меня только один вопрос - вам реально надо создавать несколько новых проектов в день? По мне Unix-way вполне живой. У нас (как правило) нет безумного количества файлов и возможностей банального gmake вполне достаточно для сборки скелета проекта. А дальше "мясо" нарастает по мере реализации. GCC (а местами CLang, и даже так любимый "не embedded разработчиками" Rust) вполне вписываются в такую схему. В любом случае время на создание проекта сильно меньше, чем время на его реализацию.

              А вопрос IDE при наличии возможности сказать "gmake firmware" уже вторичен. Любой вариант - от vim до "взрослой" Visual Studio или XCode.

              Единственная проблема - это когда часть кода идет в объектниках. Да не просто в объектниках, а в объектниках под какой-то конкретный компилятор. Но опять же - это личная ответственность разработчика. Я с таким стараюсь не связываться (и пока получается).

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


              1. HEXFFFFFFFF
                23.02.2022 11:42

                Хм. Подход который вы предлагаете конечно возможен для hello world или помигать светодиодом. Но вот в случае с nordic подобный подход мало реален. Дело в том что там используеться их sdk и zephyr. Внутри это, я так понимаю это выглядит так: есть два больших конфигурационных файла , 1й это настройки zephyr , в нем описывается какие возможности и библиотеки вам нужны, 2й файл описывает переферию конроллера ( чем то напоминает подход STMcube, где вы в графическом редакторе настраиваете нужную вам переферию, привязываете к нужным ножкам, дальше нажимаете кнопку и куб генерит вам кучу кода для инициализации всего этого. Но у нордика все это сложнее и запутаннее, вместо графического редактора текстовый конфиг, и с ходу даже не совсем понятно куда идет результат и где в итоге код инициализации)

                На основе этих конфигов ide создает/пересоздает даже не проект а "решение" состоящее из нескольких десятков проектов, каждый проект компелиться в отдельный обектник и потом все это собирается в прошивку. Причем часть кода может быть С а часть С++ , в зависимости от конфига и компиляторы для разных кусков могут быть похоже разные.

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

                И того получается что с вашим подходом можно убить месяцы на то что в их ide уйдет пять минут.

                Конечно классно было бы написать все это для VS-code но это отдельный большой проект. Чем то похожим занимается PlatformIO, не знаю сколько народу его делает, но делают они это годами, и у них там до сих пор тьма диких вопиющих ошибок. Эти ошибки они не успевают, я так понимаю исправлять. Год назад нашел у них критическую ошибку (из за нее работать с проф программатором, дебажить с ESP32 не возможно, прошивка в контроллер попадает битая) . При чем я полностью понял причину ошибки и исправил ее у себя. Об этом написал им на форуме, но спустя год ошибка так и не исправлена)))


                1. MinimumLaw
                  23.02.2022 13:56

                  Я вас уверяю - мои проекты сильно шире, чем помигать светодиодом. Впрочем... закон качалки гласит - всегда есть тот, кто твоим весом только разминается. В моих итоговый Makefile'ах несколько сотен файлов, но 99% когда в них написаны мной, а не сгенерированы кодегенераторами. И уверяю вас - при условии что в проекте код написан автором это вполне рабочий вариант независимо от размера проекта.

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


                  1. HEXFFFFFFFF
                    23.02.2022 14:47

                    Чип nrf9160 это gsm модем ( для iot сети), gps приемник и неплохой микроконтроллер на одном кристалле. Кроме того заявлено супернизкое энергопотребление. Но я так понял что конкретный чип не важен , фишка нордика это чип какой-то связи+ мк в одной микросхеме.

                    Для реализации многопоточности они используют не rtos а zephyr ( если вы не в курсе то zephyr это то же что rtos но кроме многопоточности там в составе еще куча библиотек для работы с сетью , железом, итд. Т.е. по сути можно сказать полноценная операционка для мк) Там есть куча тяжеловесных вещей типа реализации http/https протоколов. Как вы понимаете писать с нуля все это можно годами поэтому не вижу алтернативы кроме как использовать предложенные ими решения.

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

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


                    1. count_enable
                      23.02.2022 15:48

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

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

                      В больших проектах конфигурация собственно железа, ОСРВ и периферии это проценты от общего времени разработки. Куда больше времени тратится на собственно "бизнес-логику" прибора или приложения. Поэтому есть смысл оптимизировать разработку именно бизнес-логики.


                      1. MinimumLaw
                        23.02.2022 17:17

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

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


                    1. MinimumLaw
                      23.02.2022 17:03

                      Чип nrf9160 это gsm модем ( для iot сети), gps приемник и неплохой микроконтроллер на одном кристалле.

                      Понял. Да, эта одна из тех штук, для программирования который системщик не нужен. Это в том или ином виде заменяют генераторы. Последнее время довольно часто встречается. Наверное, это даже правильно. Если, конечно, вынести за скобки вопрос о том, будет ли IoT считаться критической инфраструктурой и, в связи с этим вопрос о качестве кода от Nordic. Что, к слову производитель говорит? Как всегда as-is без любых явных или неявных гарантий?

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

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


                      1. HEXFFFFFFFF
                        23.02.2022 19:04
                        +1

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

                        Я за свою жизнь практически 50 на 50 занимался чистым программированием ( не связаным с железками) и embedded. Почему то среди embedded инжинеров этот подход с нуля очень распространен, но в среде обычных прогеров с таким подходом долго не продержаться)))

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

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


                      1. MinimumLaw
                        23.02.2022 20:33

                        Вам повезло если вашему работодателью важен процесс а не результат, но это большая редкость.

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

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

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


                      1. HEXFFFFFFFF
                        23.02.2022 20:52

                        Последнее что хочу, наверное добавить.

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


                      1. MinimumLaw
                        24.02.2022 07:16
                        +1

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

                        Это именно та причина, по которой я и говорю что системное программирование потихоньку вымирает (ну, может не вымирает - но сильно перерождается). Те вещи, которые воспринимались как сами собой разумеющиеся и требующие крайне ответственного подхода ранее вдруг становятся второстепенными. Дошло до того, что люди умеющие напрямую открыть файл устройства и сделать IOCTL в UNIX уже называют себя системщиками. Люди, горда именуемы себя системными программистами, не пишут ни к один регистр периферии и вообще никак напрямую не контактируют с железом, а крайне серьезные инфраструктурные проекты содержат код качество которого под большим вопросом (но его очень много, и за его переработку страшно даже браться).

                        При этом в соседних темах всячески гнобят схемотехников за "одноразовые вещи". А там происходит примерно то же самое. "С нуля можно делать только несложные проекты. Какую ни будь простенькую пищалку...". Или "нет ничего сложного в источнике постоянного тока - берем типовую схему из мануала, ставим на плату как наши габариты требуют и всего делов-то". Там, правда пока все не так страшно, но уже похоже.

                        Ну что тут скажешь. Живем с этим. Эволюция. Только время покажет будет ли это новым витком или очередным "эволюционным тупиком". Я принимаю то, что вы пишите. Но продолжаю считать что это не единственный путь. Он совершенно точно хорош для прототипа. Быстро и наглядно. Для остального... Боюсь это за гранью моего понимания. История знает некоторое количество примеров, когда прототипы оказавшись первыми на рынке его завоевывали. Но есть и обратные - когда слишком рано выведенный на рынок прототип породил индустрию, но сам умер.


          1. rstepanov
            25.02.2022 10:49

            Макбук + CLion + J-Link - очень удобная связка, IDE от SEGGER пробовал поставить - выглядит ппц и как ей вооще пользоваться - не понятно, что-то из 90-х годов, кривой и стремный блокнот-переросток. Iar или Keil - туда же.


      1. Indemsys
        22.02.2022 19:44
        +3

        J-Link по настоящему даёт хорошую отдачу когда его используют в конфигурации Pro или Ultra и совместно с коммерческими средами типа IAR Embedded Workbench или SystemView.



    1. nixtonixto
      23.02.2022 11:09
      +2

      Они дирут непомерные деньги за свои копеечные железки

      Нет, это вы разрабатываете копеечные железки, для которых жылинк избыточен. Для компаний, производящих десятки тысяч плат в год, эти пару тысяч — капля в море, и если раработчики могут аргументированно пояснить, почему им нужен ИМЕННО ЭТОТ инструмент — у них будет и жылинк, и альтиум, и лицензии на их ИДЕ.

      Я тоже, когда покупал смд-установщик за 5к — думал, что сильно оверпрайс — себестоимость не больше 200...300, но деваться было некуда, надо было собирать платы. Но он мне за 5 лет вчистую окупился минимум 3...4 раза. Заработал и я, заработали и его изготовители. Так же и с этим жылинком. Он не для того, чтобы вам осенними вечерами кодить ёлочную моргалку на F030P4 — пользуйтесь семихостингом…


    1. Dark_Purple
      23.02.2022 19:54

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

      Софт ничего не стоит? Причем это хороший софт, а не типичное для нынешнего времени индусское говно.


    1. rstepanov
      25.02.2022 10:44

      Вообще это должен работодатель оплачивать, а не "инжинер". Для хобби можно брать J-Link EDU, он существенно дешевле стоит и вполне подходит для любительских задач. Если денег совсем нет, а что-то поделать хочется - есть другие отладчики, сильно дешевле.

      У J-Link BASE/PLUS/PRO главная фишка это коммерческая поддержка, если она вам не нужна - зачем за нее платить?


  1. predator86
    22.02.2022 21:58

    Так у J-Link EDU есть какие-нибудь ограничения кроме лицензионных? Какой смысл его переводить на PLUS и т.д.?


    1. dec123
      22.02.2022 23:36

      например EDU не видит Ti TMS570, а PLUS его и читает и пишет по JTAG


      1. predator86
        23.02.2022 00:10

        У меня официальный «J-Link EDU mini» с SWD, значит не стоит переживать за функциональность?