jcxz

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

Почему "разъедется"? Куда? У меня на рабочем компе стоят несколько версия дров сеггера. Меняются между собой в отладчике они за пять секунд несколькими кликами. Впрочем - дело ваше. Всяк суслик сам себе агроном. И на каком основании сделан такой вывод?

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

Не знаю можно ли сделать такое в STM32, но в XMC4xxx я бы просто запустил второй таймер, не останавливаемый отладчиком. Который бы сбрасывался периодическими событиями от вашего останавливаемого таймера, а когда таких событий нет - его счётчик добегал бы до некоего конечного значения переполнения (или COMPARE-события). Дальше просто проверяем флаг наличия переполнения - есть значит останов скорее всего был. Ну или запустите любой таймер (хоть внутренний WDT, который только генерит не сброс, а прерывание). И периодически его сбрасывайте по COMPARE-событию (часто сбрасывайте). Если добежал до переполнения, значит -> не было сброса -> был останов. Это будет весьма сложно сделать с остановленным CPU. Ведь ТСу явно это нужно знать в программе.

Кодовый калькулятор, о котором писал выше - это видимо и есть такой аппаратный генератор лицензий. Их существует множество готовых. Только на странице Swedbank-а вижу несколько штук разных: https://www.swedbank.lv/business/d2d/ebanking/authentication?language=RUS (раздел "Калькулятор кодов"). И купить и использовать его может видимо кто угодно, не только банки. Стоят они как видно - сравнительно недорого = 6-12 евро. И разрабатывают и производят их не сами банки видимо, а сторонний производитель. Значит устройство его известно не только пользователю (банку).

Ну-ну.... Так почему тогда до сих пор не сломали кодовый калькулятор Swedbank-а? Ведь там, за этим взломом, такой жирный куш маячит! В виде миллионов евро на счетах юзеров. Ломай и греби бабки лопатой! Имха - все эти россказни про лёгкий взлом разных МК, по большей части - байки. Да, в каких-то МК видимо были баги, которые и позволяли их взламывать. Конкретно эти семейства МК. Но это скорее частные случаи, чем правило. Иначе такие устройства, как этот самый кодовый калькулятор, были бы просто невозможны. Так как легко ломались бы.

При том, что например в нашем Swedbank-е доступ к инет-банку может открываться генерацией кода кодовым калькулятором. Это такое небольшое устройства, формата брелока, в котором видимо стоит защищённый каким-то образом МК. Если ломать МК так легко, как вы рассказываете, то эти брелоки должны ломаться на раз. И кто угодно может легко получить доступ к любому чужому счёту. Но почему тогда не происходит массового взлома счетов??? PS: Кстати - этот кодовый калькулятор работает примерно так же (такой же порядок действий с ним), как хочет чтоб работал генератор кодов аренды ТС. Например для выполнения какой-то расходной операции по счёту: страничка инет-банка генерит код; этот код вводится юзером в калькулятор; калькулятор в ответ генерит код-ответ; который затем вводится на инет-странице для подтверждения операции. Примерно то же самое хочет ТС, только инет-страничку и девайс поменять местами.

Результат - мотор сдох, рельс остался недопиленным. Так как в пиле был PMSM-мотор. Который не поедет без участия контроллера. Пример со счётчиком - тоже мимо кассы (если конечно счётчик сделан толково). Никакой нормальный интеллектуальный счётчик не станет считать в обратку. Не надо слушать сказки для простаков. Чем умнее и сложнее техника, тем меньше с ней работает метод лома и кувалды. ну да, ну да... свежо предание, да верится с трудом... Если вас послушать, то диву даёшься - и как только всякие интернет-банки работают??? Ведь любой школопет должен одной левой их ломать. И все защиты в контроллерах - тоже конечно ничего не стоят.

....и в начале каждого дня ушлый юзер будет переводить часики на сутки назад. И разорит ТС-а.

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

Тем, что кроме батарейки нужно обеспечить ещё и синхронизацию часов с реальным временем (например SNTP). И предусмотреть действия в случае разрядки/порчи батарейки. И в случае разного рода переводов часов (как на зимнее/летнее время, так и злоумышленные переводы назад). И т.д. Что в сумме намного сложнее учёта моточасов. Хватает для чего? И как вы это посчитали, не зная потребления RTC у ТС-а?

Значит надо посмотреть - какая версия сеггеровских дров стоит дома, и такую же поставить на работе. Потом запустить её JLinkDLLUpdater.exe. Потому что в рабочем другой S/N, ещё не забаненный в новом JlinkARM.dll. А S/N вашего J-Link-а уже забанен. Нет. Перечитайте ещё раз что я писал выше. PS: Если вы ничего не хотите делать для решения проблемы (даже самые простые вещи), то на кой тогда создавали тему с вопросом???

Зачем это окошко здесь? Если это и есть ваша "проблема", то решается она элементарно - заменой JlinkARM.dll на более старый (тот, что у вас стоял раньше). И причина её - в том что поставили более новые дрова Segger-a, а не какая не прошивка. Достаточно поставить те, что стояли раньше (или найти их в папке C:\Program Files (x86)\SEGGER - скорей всего они там у вас и остались). Для этого запустить JLinkDLLUpdater.exe от старых дров и разрешить ему заменить .dll (закрыв предварительно Кейл) Буквально сегодня утром делал такой откат для IAR. Как видно по вашему же скриншоту - вы ничего не шили (так как версия FW - от 2014г), а просто поставили более новый JLink_Windows_Vxxx.exe с новой JlinkARM.dll. В которой забанен S/N вашего J-Link. Этот у вас работает. Ничего покупать не надо. Просто откатите JlinkARM.dll Мой J-Link-Ultra утром выдавал такое же окошко. Сейчас он работает. Ничего не перешивал.

О каком коде речь? Ничего не понятно..... Если речь про пароль, то кто вас заставляет использовать 16-байт? Можно пароль сделать какой угодно длины. А в качестве ключа AES использовать хеш от этого пароля, нужной длины. Так обычно и делают. Только вообще-то TLS (и асимметричное шифрование) - это вообще не про это. Не про длину AES. Если что. Тогда из этого и нужно исходить, придумывая алгоритм учёта времени аренды и генерации кода аренды.

Видимо - мало денех предлагали. Только и всего. PS: Вот вам другой сценарий (очень даже жизненный): Есть некий Производитель девайсов, работающих по ModbusRTU. Предположим это некие счётчики (э/энергии или воды или ещё чего). Допустим есть Заказчик, купивший и установивший на свои объекты кучу этих счётчиков. Счётчики имеют экран, на котором показывают накопленные показания. Но также имеют RS-485 для централизованного запроса данных. Изначально Заказчик (в целях экономии бюджета) решил не делать централизованный съём данных (так как надо прокладывать провода, покупать оборудования для опроса и т.п.). Решил, что ему дешевле нанять бабушек с блокнотиками для периодического обхода. И так работало несколько лет, без нареканий. Но потом обстоятельства меняются - появляются доп.требования по оперативности контроля или просто бабушки начинают бастовать и требовать повышения ЗП. Заказчик вспоминает, что у купленных им счётчиков есть функция опроса через RS-485 по Modbus. И он, Заказчик, даже её оплатил (в расчёте на будущее). Заказчик подсчитывает экономический эффект и решает уволить всех бабушек, а проложить провода и купить оборудования для опроса по ModbusRTU. Далее - находит ваш девайс, который умеет опрашивать по ModbusRTU сторонние девайсы, и заказывает у вас кучу таких девайсов для опроса своих счётчиков. Монтирует на свои объекты. И... вроде можно пить боржоми и курить бамбук. А вам - подсчитывать прибыли. Но вот беда - иногда счётчики по неизвестной причине начинают передавать неверные данные. Очень редко. Непредсказуемо. И без видимых причин. Заказчик вызывает Производителя счётчиков. Делает ему втык. Говорит - "или решай проблему или следующего крупного договоря на N лямов $$$ тебе не видать как своих ушей". Т.е. - мотивирует Производителя материально. А у того эти счётчики уже давно находятся в серийном производстве. И разработчики их уже сокращены или на пенсии. Т.е. - искать проблему в огромной куче быдлокода счётчиков - некому. Да и лень. А договор горит! И Производитель счётчиков *опой чует, что дело в этом самом RS-485 (ведь до этого бабушки несколько лет исправно снимали показания и бед не знали). И возможно он даже знает что проблема в его собственном коде. Только никому не признаётся. И тут этот Производитель счётчиков узнаёт, что Modbus-то ваш - вовсе и не Modbus! Далее он просто пишет простейший код, который кроме нормальных кадров, иногда передаёт и такие разорванные кадры (которые ваш девайс воспринимает как нормальные). Этот тестовый девайс передаёт в нормальных кадрах правильные показания (соответствующие тестовым), а в разорванных - неправильные. Вешает на этот RS-485 сторонний сертифицированный логгер (или даже 2). И показывает этот тестовый стенд Заказчику, убеждая его, что проблема вовсе не в его счётчиках (где она реально и есть), а в ваших девайсах. Ведь сертифицированный логгер видит только кадры с правильными показаниями, а ваш девайс принимает иногда неправильные. Доказывает что ваш девайс видит то, чего нет. Всё - ваш девайс дискредитирован. Договора о поставках с Заказчиком вы лишились. А если бы Modbus у вас был честный, то Производителю счётчиков пришлось бы оторвать пятую точку от стула и найти/исправить баг в своём коде. А не вешать всех собак на вас.

Исходная постановка вопроса неверная. Исходно вы почему-то полагаете, что в среде передачи всё идеально. А там может быть не так. В этой среде передачи (например - RS-485) могут присутствовать устройства, работающие криво. Например - выдающие иногда (очень редко и при определённых условиях) какой-то мусор в канал. Например - обрывки Modbus-кадров. Эти баги разработчики устройств не заметили. Да и фиг с ними. Ведь если в этой среде передачи все приёмники имеют корректные парсеры входящих кадров, то они отбросят такое как мусор. Теперь в этот RS-485 втыкают ваше устройство. И оно начинает иногда глючить. Ведь воспринимает тот мусор как корректные кадры. Дальше начинается разборка - кто виноват? Кому выписывать пи^&*лей? В этот RS-485 втыкают некий сторонний логгер ModbusRTU кадров, пишущий все кадры в течение нескольких суток непрерывно. Логгер - серьёзный, сертифицирован как "ModbusRTU-compliancy". Потом лог просматривают и... не обнаруживают в нём кадров, адресованных вашему устройству. В то время как ваш девайс действовал, как будто видел такие кадры (так как клеил их из какого-то мусора). Делается вывод о несоответствии вашего девайса ModbusRTU. Занавес. А ведь ваши манагеры уже заключили договор на продажу этому заказчику 1 миллиона штук ваших девайсов. Под это дело вы уже закупили вагон комплектации (в кредит). Но договор расторгается. Так как ваши девайсы "не соответствуют спецификации Modbus-RTU". А ваша контора влетает на бабки. Так никто же не против того, чтобы вы реализовали частное решение для данного частного случая, назвав это своим "vendor specific" протоколом. Почему так не сделать??? Но вы же называете его "ModbusRTU", которое им по факту не является. Назовите его своим проприетарным протоколом, в какой-то мере похожем на ModbusRTU. Никто и слова не скажет. Но вы же вместо этого зовёте его ModbusRTU, вводя всех в заблуждение. Намеренно или по глупости.

Этот вам так кажется. Пока не пришёл умный человек, знающий что такое Modbus, и не завалил ваш девайс, посылкой ему корректных Modbus-кадров, которые ваш девайс не в состоянии правильно распознать. Или отправкой мусора, который ваш девайс распознает как корректные кадры. И при желании такой человек всегда найдётся. Всё зависит от суммы гонорара. Скажем придёт ко мне завтра заказчик, принесёт ваш прибор, и скажет: "Вот тебе 10тыс.евро, напиши такой код на любом устройстве, который будет посылать кадры, корректные с точки зрения Modbus-протокола, но которые этот прибор будет неверно распознавать". И я напишу. Зная баги вашей реализации - запросто. И где же ваш девайс "правильно распознаёт кадры", если сами же выше писали, что распознаёт неправильно: Т.е. - по стандарту вы должны отбросить такое как мусор. Вы же воспринимаете это как корректный кадр. Вот сюда тот умный человек и вдарит ваш девайс. Превратив его в тыкву. Со всеми вытекающими. В TCP нет фреймов. Советую почитать учебник "что такое TCP". TCP-это потоковый протокол (поток байт). Если кто-то пишет работы с TCP с опорой на некие "фреймы", то это уже изначально некорретная реализация. И чья-то кривая реализация - это не оправдание другим делать так же.

Интересно - а зачем шили? Для чего?

Что можно обсуждать "созидательно" для сферического коня в вакууме? Вы даже не описали: 1. Примерный функционал прибора? 2. Доступ к какой функции требуется предоставлять с помощью данного сервиса? Ко времени работы прибора? Ко времени работы какого-то режима (мотора) прибора? Или к чему? 3. Как именно прибор осуществляет учёт расхода времени аренды? По часам реального времени? Путём периодического декремента некоего счётчика секунд/минут в памяти? или ...? 4. Если учёт по счётчику, то зачем тогда пишете о некоей дате? Если по часам реального времени - то как именно синхронизируются часы в приборе с реальным временем? Как будет достигаться соответствие времени в приборе со временем, по которому сгенерирована аренда внешним сервисом? И что мешает пользователю не продлять никакую аренду, а просто перевести часы прибора назад? Или что будет, если батарейка на часах прибора сядет, при ещё не истекшем сроке аренды? 5. Имеет ли прибор подключение к интернет? Если имеет (и часы реального времени синхронизируются через этот же канал), то что мешает и продление аренды сделать прям на приборе, без всяких сторонних вебов? PS: И да - прежде чем придумывать свой велосипед с деревянными колёсами, нужно хотя бы изучить имеющиеся (TLS например). И по возможности использовать их.

Лучше не барьеры, а операции обратного чтения после каждой записи в регистры конфигурации таймера. Т.е. - после записи каждого регистра таймера - сделать чтение из него. Впрочем - выше я уже предлагал это, но не знаю - делалось ли это или нет? На XMC4xxx во многих случаях, необходимо такое обратное чтение после записи в какой-либо регистр периферии, если сразу после этого идёт другая запись, в другой регистр, зависящая от эффекта предыдущей записи. Например: запись значения X1 в регистр конфигурации периферии R1, а потом - следующая запись (в регистр R2), включающая эту периферию, режим включения которой зависит от записи X1. Если между записью R1 и R2 не вставить чтение R1, то может работать некорректно. Инструкции барьеров в этом случае не помогают. Только обратное чтение. На STM32F429 тоже сталкивался с таким в какой-то периферии (при работе на макс. частоте). В документации XMC4xxx упоминается необходимость таких обратных чтений между зависимыми записями в регистры конфигурации. В коде операция: LPTIM1->DIER = ... не факт что успевает выполниться до последующего разрешения таймера. Обратное чтение LPTIM1->DIER после записи, до разрешения таймера, должно дать гарантию.

А сами значения в регистрах таймера (после инита) проверили? Сравнили с мануальными? А то кто его знает - не накосячено ли с определениями всех этих множества define-ов, там где вы их взяли?

Можно попробовать: При запрещённых всех прочих источниках прерываний сделать полную очистку всех pending (все ICPRx = ~0) (до инита таймера); потом запустить таймер и посмотреть - может где-то запрос появляется в другом регистре/бите? По идее - PRIMASK не должен никак влиять на появление флагов-запросов в NVIC.

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

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

Да. Это иногда недостаток наверное. Но также - не встречал в практике прям насущной необходимости в равноприоритетных задачах. Зато очень быстрое и простое управление задачами.