esaulenka

Точно было с F0 (но вроде бы исправлено в последних ревизиях) https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf и тут есть несколько вариантов для клонов, возможно, что-то работает и на F2/F4/... https://www.usenix.org/system/files/woot20-paper-obermaier.pdf вот тут ещё интересные вещи описаны https://www.eevblog.com/forum/microcontrollers/stm-32f4xx-what-hacks-are-known-around-level-2-security/ но я ленивый, я ни один из этих способов не проверял...

Если походить по ссылкам, Espressif пишет о выпуске новой ревизии, с некоей защитой (без подробностей, конечно). В 2019 году ещё. Подвержены ли этой (или подобной) атаке остальные ESP32 - никто не разбирался (или на публику это не выносил). С учётом того, что всеми любимый STM32 и его многочисленные китайские клоны читаются вообще на коленке, без всяких power glitch, проблема не то чтоб прям вот очень большая. Но статья интересная, спасибо.

TXFRQ: Transmit data flush request Writing 1 to this bit sets the TXE flag. This allows to discard the transmit data. This bit must be used only in Smartcard mode, when data has not been sent due to errors (NACK) and the FE flag is active in the USART_ISR register (это первый попавшийся под руку RefManual for STM32Lxxx, что там у автора - я не знаю) Ну а вопрос "нафига это надо делать" вы не задавали :-)) Тем более, у меня нет на него ответа. https://2cyr.com/ читает ЭТО с настройками "кодировка 1251 отображается как 1252". Ничего особенного, но чуть-чуть подумать надо.

Странно это. В стандартном STM-овском UART прерывание по FrameError включается флажком ErrorInterruptEnable и только в режиме DMA. Ну то есть лишнее было-таки включено

Вот ещё раз: не делайте так. Я не понимаю, почему у вас txSize портится, но если бы вы написали if (txCnt >= txSize) всего этого топика не было бы. По-хорошему - да. Но (только что освежил в памяти соотв. картинку из RefManual) FrameError / ParityError / NoiseError дёрнут прерывание, только если они явно разрешены. А OverrunError без ReceiveNotEmpty не бывает, как я понимаю - его и имеющийся код сбросит. Ну и в любом случае, это приведёт к зависанию в прерывании, а здесь и сейчас у нас bus fault.

Так он говорил уже - сразу за концом памяти. 99% вероятности, что это переполнение массива. Я внимательно посмотрел на ваш отладчик (gdb) backtrace #0 HardFault_Handler () at ./src/main.c:116 #1 <signal handler called> #2 0x08001682 in exchTXEHandler () at ./src/libs/exchange/exchange.c:341 #3 <signal handler called> #4 dbgout (level=level@entry=7, format=0x80017c7 <EXCH_process+266> "H\377\367\004\370\262#+\200\252\347\201N") at ./src/libs/dbg/dbg.c:19 #5 0x080017c6 in waitForRequest (exchRes=0x20000f20 <exchRes.7247>, pt=0x20000f2c <ptChild.7246>) at ./src/libs/exchange/exchange.c:175 #6 EXCH_process (pt=0x20001fec) at ./src/libs/exchange/exchange.c:461 давайте читать с конца: - exchange.c, 175 - это какая строчка в приведённом вами waitForRequest() ? - dbgout() как устроен? С exchXXXX() никак не связан (другой уарт, полностью независимый набор флажков и т.д.) ? - exchTXEHandler() что из себя представляет? Что у него в переменных в момент хардфолта?

Если вы так в консоли и работаете, то вам сюда: https://openocd.org/doc/html/General-Commands.html раздел "15.5 Breakpoint and Watchpoint commands". Но вроде б сейчас все IDE оборудованы соответствующими кнопками?.. Но, по сути, причину ошибки вам уже подсказали - переполнение приёмного буфера. Простейшее (и необходимое!) решение - условие (принято == длина_пакета) меняем на (принято >= длина пакета). И, кстати, банальный вопрос: поле "длина пакета" в заголовке - это длина данных или длина всего пакета вместе с заголовком? Также, как верно заметил jcxz, при таймаутах весь приём напрочь ломается. Если в линии по какой-то причине пропал один байт, вы попадёте в условие проверки таймаута по заголовку следующего пакета, и сразу же пропускаете первый байт заголовка. Хорошо ещё, если пропустите пакет целиком, а не найдёте магические два байта в середине данных...

А что будет, если "необходимое количество байт" в переменной packetLenght будет меньше пяти? И вообще, было б крайне полезно отладчиком посмотреть на содержимое приемного буфера (и следующих за ним байт) после того, как всё грохнулось.

Неживы. А реверсят и дорабатывают всё подряд. Управление двигателем (увеличение мощности или её имитация, снижение экологических норм), добавление всяких плюшек, которые в штатной комплектации не предусмотрены, допиливание всякой мультимедии (включение ютубов/нештатных карт / чёрт-знает-чего-ещё). Но да, рынок сильно больше, чем десяток супер-приборов. Но и специалисты там получше встречаются, уж извините. Если гарантирован возврат и прочие долговременные отношения при аренде, вся эта ерунда с кодами защиты решается юристами в договоре: "нарушите условия использования, перестанем дружить и возьмём неустойку".

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

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

Ну так код же есть, там всё стандартно-библиотечное. Я не настолько самоуверен, чтобы свои крипто-алгоритмы изобретать 🙂 https://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine https://ru.wikipedia.org/wiki/Вихрь_Мерсенна#Параметры_32-битного_генератора_MT И да, период обозначает количество итераций, когда алгоритм начнёт в точности повторять выданную последовательность. И он ДОСТАТОЧНО большой, чтобы никогда не увидеть подобного в реальной жизни, это авторы алгоритма гарантируют.

Вы почитайте, что-ли, что это за алгоритм такой. Никто не обещал, что генератор случайных чисел не выдаст подряд десяток одинаковых значений. Да, вероятность ОЧЕНЬ маленькая, но ненулевая. Вероятность "два одинаковых значения в произвольных местах" - очевидно выше, и тоже далеко ненулевая. Я не математик ни разу, но это легко доказывается на практике.

Это вероятность получить некое наперёд заданное значение. А вероятность получить пару одинаковых хэшей гораздо выше. Подробности в википедии, "парадокс дней рождения".

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