murmur

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

Это если вы знаете в чем заключается защита. Хотя.... Можно ведь наугад пощерстить код на предмет того, а не обращается ли он к уникальному номеру процессора. А если обращается...

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

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

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

Не буду создавать отдельную тему. Похоже проблема с неким конфликтом памяти, ибо Такой вот мусор попадает в SDFatFS на этапе, когда инициализируется USB, еще ДО ТОГО, как к SDFatFS идет обращение. Естественно, когда я потом пишу if (f_mount(&SDFatFS, (TCHAR const*)SDPath, 0) == FR_OK), то обращение идет не к SD карте, а куда-то на Марс.... Отследить, где происходит эта поломка брейкпоинтами не удалось, библиотека USB в HAL живет своей жизнью. У меня такой вопрос - а можно ли как-то в отладчике KEIL перехватить обращение к конкретной переменной? Чтоб программа останавливалась при изменении данной переменной и можно было бы отследить, где это произошло? Я тупо поиском по тексту проекта прошлась - нигде нет обращения, кроме участка кода, который запскается значительно позднее. Пока что ради эксперимента я завела политически нейтральную переменную DISK_FatFS и обращаюсь к дискам только через нее. Но все же гложет тот факт, что в памяти какой-то барабашка завелся....

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

Все не надо. Последний мой пост почитайте.

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

P.S. При отключении DualFlash все записалось нормально на максимальной частоте. Варианта 3. 1. Плохой экземпляр одной из микросхем. 2. Плохая разводка этой микросхемы. 3. Косяк в самом режиме DualFlash. 1 вариант исключен. Значит вариант 2 или 3...

Зря смеетесь, было такое. Но... разъем SWD у меня в сантиметре от чипа. Кабель неэкранированный 15 см длиной. Есть необходимость поработать над этим? И насчет таргета - не забывайте - внутренняя флеш, как уже мной писалось, без ошибок пишется на максимально доступной частоте J-Link

С этого момента поподробнее. Если по вашему на сей процесс влияет качество JLink,то, как я уже спрашивала почему качество зависит от частоты J-Link? Насколько я понимаю, микросхеме дается команда на запись, а алгоритм и, тем более IDE, просто ждут отработки этой команды. В шею ведь микросхему никто не гонит? В задачу J-Link входит коммуникация. Будь проблема в J-link, то терялся бы коннект во время программирования. А так все на совести QSPI....

Добрый вечер, друзья. Не было заботы, да купила баба порося (пардон, не порося, а J-Link) Ранее я заливала прошивку посредством китайского свистка ST-Link, работал он на частоте 1.8 МГц и не более. Тот объем данных для QSPI, который накопился в процессе разработки, заливался минут 40. Был приобретен китайский же J-Link v11. На частоте 15 МГц он прекрасно заливает прошивку во внутреннюю флеш, без ошибок. QSPI он программирует за 6 минут - причем неважно 15 МГц, 10Мгц или 2 Мгц. Скорость не меняется. В процессе программирования ошибок нет, но они выявляются при проверке (и они действительно есть, если запустить устройство и посмотреть на залитые картинки). Если же поставить 1 МГц - то все без ошибок, программируется за 12-13 минут. По сравнению с ST-Link на меньшей частоте скорость получается больше. Но все же.... никак нельзя шить QSPI на большей частоте? Может саму QSPI надо как-то настраивать по другому? У кого какой опыт, расскажите, с какой скоростью, на какой частоте удавалось прошивать QSPI? Объясните мне, почему так получается - почему качество зависит от частоты J-Link? Насколько я понимаю, микросхеме дается команда на запись, а алгоритм и, тем более IDE, просто ждут отработки этой команды. В шею ведь микросхему никто не гонит? Настройки QSPI в алгоритме у меня такие.

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

В qspi только данные. Где в keil проверить адрес точки останова и как его установить? Почему раньше у меня такой проблемы не возникало с stlink и H743/F746?