Stm32 с чего начать изучение...

[Rapra]

как быстро у вас бы пропало желание ковыряться, если бы я сделал "проверку серийника" в десятке мест и, в случае его несовпадения, тупо бы затирал случайную страницу FLASH? Что скажете насчет классики: отслеживать наличие отладчика и портить прошивку при подозрениях?

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

Затирать флеш тоже бессмысленно - исходная прошивка ведь есть. И обращение к механизму стирания флеша тоже легко обнаруживаются.

[ARV]

Я не стараюсь построить неприступную стену для взломщика, я стараюсь заставить его лезть на стену, намазанноу то говном, то маслом, чтобы ему было то противно, то скользко... в надежде, что ему надоест.
Когда он раз обнаружит стертую FLASH между "пошаговым" прогоном (ну, если у него хватит терпения КАЖДУЮ команду пошагово выполнять, внимательно отслеживая контекст её выполнения, то это явно КРУТОЙ ХАКЕР, а не простой любитель), два обнаружит, а птом и три - я надеюсь, он скажет "да ну его нахрен".

Вы как собрались его обнаруживать?

Ну... опыта именно в stm32 у меня нет, но ИИ говорит, что есть особые регистры ядра, где это можно увидеть, что можно следить за уровнем пинов SWDIO/SWDCLK, что можно замерять аппаратным таймером длительность прогона некоторых функций... Если все это размазать по коду, если слегка обфусцировать проверки (написать многоэтажный if с кучей & и && вместо ==), и если любую неудачныю проверку сопровождать стиранием FLASH - вы считаете, это не может выбесить?

[ARV]

Обезвреживается сама попытка проверки серийника

это если я сделал if(IsValidKey()), а если я в десятке мест написал "развернутую" проверку (проинлайнил тело IsValidKey), и после каждой "непроверки" подтираю что-то непредсказуемое (после чего не факт, что программа упадет вообще) - вы так же будете считать, что это пустяк?
ну, снимаю шляпу, вы крутой хакер. а про крутых я писал сразу - бесполезно. но за 1000 рублей они не будут работать.

[linux_rulezz]

реверснуть прошивку и посмотреть

Кстати, да: наш любитель калокуба совсем забыл, что прошивка его железки обязана будет храниться без блокировки чтения: иначе невозможно будет сделать обновление (придется полностью стирать флеш → сотрется и бутлоадер).
Тут разве что такой вариант огораживания сгодится: во флеше хранить зашифрованную прошивку. Бутлоадер будет при старте ее считывать, дешифровывать и писать в ОЗУ. Далее произведет переход на исполнение прошивки из ОЗУ. Правда, опять же, для этого как минимум придется выкинуть калокуб: если это УГ даже для элементарной моргалки светодиодом аж больше килобайта прошивку лепит, что говорить об объеме более-менее приличных вещей (тот же каловский USB-CDC не меньше 10кБ флеша "пустой" занимает + не умеет даже в 6Мбод — т.е. "индусы", которые это дерьмо писали, даже не осилили документацию почитать!)?

[Rapra]

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

И еще. Прошивку можно запустить в программном эмуляторе.

[ARV]

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

[Rapra]

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

[ARV]

придется полностью стирать флеш → сотрется и бутлоадер

наш любитель линуха вообще не читает, на что отвечает - бутлоадера-то и нет вообще...

ИИ говорит вам ерунду

конкретно, в чем? всё, что он говорит, имеет место быть. а о том, насколько это эффективно, я не писал. и, кстати, ИИ говорит - малоэффективно. но 100 малоэффективных мер могут стать эффективным средством по сумме...

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

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

получаем сишный (не ассемблерный!) код

пожалуйста, покажите мне такой дизассемблер! они реально существуют?!

[linux_rulezz]

Платный grok вполне себе по дизасму может более-менее читаемый сишный код сгенерировать.
Но, опять же: дизассемблирование прошивки имеет смысл лишь в том случае, если написать аналогичную с нуля будет дороже. А если на это уйдет пара-тройка дней - то смысл? Скажем, когда я баловался с китайскими клонами "ПЛК" FX3U, то сразу же понял, что никакого смысла реверсить этот быдлокод нет (особенно учитывая то, что китайцы почти в 100% случаев пользуются калокубом, т.к. вообще программировать не умеют). Просто взял, да написал свой код (заодно добавив функционала: у меня работает CAN). Программировать новую логику стало просто элементарно: вместо убогой "мышкотыкательной" маздай-онли дичи можно просто взять код прошивки и под свои нужды переделать. А тем уродам, что придумали "языки программирования ПЛК", желаю в аду гореть!

[linux_rulezz]

если вместо сравнения с нулем выполнить CRC большого куска памяти и потом результат использовать в вычислениях без явного сравнения с нулем или иной константой, быстро вы поймете, что всего навсего это аналог ==0?

Это называется "Security through obscurity", и об этом любой программист знает: такой метод "защиты" на самом деле лишь дает видимость безопасности, а фактически - чушь.
А если еще и бутлоадера нет, то вообще никакой возможности защитить прошивку не будет, пусть она и залочена будет после программирования.
Хотя… Вот такой есть вариант: взять исходники пакета stlink и добавить туда возможность чтения зашифрованной прошивки. Тебе придется вести у себя базу данных соответствия серийника МК проданной железки с неким ключом. Пользователь тебе выдает ключ, ты ему высылаешь прошивку, зашифрованную с солью, равной серийнику. Далее твой модифицированный st-flash читает серийник и пытается им расшифровать прошивку. Если не выходит, пользователь шлется нафиг (значит, ключ - не от его железки). Иначе же МК стирается и записывается новая прошивка + лочится.
P.S. Правда, данный метод огораживания тоже ломается легко: достаточно почитать исходники модифицированного st-flash, чтобы понять, что там в качестве ключа используется серийник МК. Далее код st-flash меняется так, чтобы вместо считанного с МК серийника использовался "подсунутый" в аргументе командной строки.

[ARV]

А тем уродам, что придумали "языки программирования ПЛК", желаю в аду гореть!

Думаю, что если вам аналогичное пожелают те, кто на этом зарабатывает себе на жизнь - миллионы инженеров АСУТП - для вас в аду поставят отдельную персональную домну

и об этом любой программист знает

любой программист - возможно, но любой ли "тиражировщик"? мне почему-то кажется, что если бы все было так вот просто, не существовало бы индустрии защиты ПО. ведь ПО для ОС намного проще ломать, чем для Embedded-устройств!

[ARV]

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

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

[КРАМ]

можно замерять аппаратным таймером длительность прогона некоторых функций...?

Оч.смешно. Вам никто не рассказывал, что всю периферию индивидуально можно фризить при отладке? То есть таймер замрет вместе с остановом.
Это, к слову, основной режим отладчика, чтобы не развалить синхронизацию кода и периферии работающей синхронно с кодом (таймеры, например).

[КРАМ]

Когда он раз обнаружит стертую FLASH между "пошаговым" прогоном...

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

[ARV]

КРАМ, ну вроде у вас уровень мышления повыше многих, не ожидал такого... Расчет на то, что из 100500 CALL-ов какой-то все таки будет пройден в отладчике "без входа". Не думаю, что каждый взломщик готов КАЖДУЮ ассемблерную команду пройти, ведя попутно учет контекста её исполнения.

[Rapra]

В этом смысле есть более эффективный таймер Но пусть AVR сам почитает мануал на этот счет.

[Rapra]

А каждую ассемблерную команду проходить и не нужно. Достаточно лишь поймать первое обращение и расставить ловушки.

[КРАМ]

КРАМ, ну вроде у вас уровень мышления повыше многих, не ожидал такого... Расчет на то, что из 100500 CALL-ов ....

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

[Rapra]

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

[Rapra]

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