Прошу помощи у коллег кто сталкивался с подобным противоречием..

Если ставить бит защиты от считывания- то он автоматически блокирует запись в память. ( Например чтобы не закатали через бутлоадер утилитку по считыванию памяти, такова идея защиты разработчиков ST)
Блокирует из любого источника или только со стороны бутлоадера?
Кажется на первый взгляд из любого, т.к через SWD также нельзя записать ничего.
При этом также ничего нельзя писать в память из приложения, те эмуляция eeprom для хранения настроек не возможна.. Или это не так?


Если мы хотим сделать собственный бутлоадер, то как нам закрыть доступ из встроенного?
и если мы отключили в программе swd то к swd нельзя ли подключиться до инициализации портов, и делать через него что-то ? (например читать память..)

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

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

Что такое "софтовый механизм защиты, живущий во флеше"?

Именно. Я стёр чип ещё до разлочки.

Так у вас у каждой железки белый IP? WEB и HTTP помогут только в локальной сети, если нет белого IP.


Такое ощущение, что вы робот и человеческие ошибки вам чужды. Допустить баг можно всегда и даже будучи опытным программистом. В некоторых ситуациях даже тестовые устройства могут не спасти, потому что они именно тестовые, а не находятся на реальном объекте. Вы читали про то, как NASA управляет марсоходом Coriosity? Несколько человек проверяют программный код очередного задания для марсохода, затем проверяют выполнение задания на Земле в услових приближенных к марсианским и все равно допускают ошибки! Везде есть человеческий фактор!

Так и что это даёт?
Своим загрузчиком под протектом я тоже это делаю, как мне нужно, при абдейте.


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

Может и так. Но иногда тестовый софт получается более навороченный, ёмкий, избыточный, дорогой, чем рабочая прога; но без него никак не обеспечить определённую надежность.

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

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

Я где-то писал, что все время занимаюсь обновлением прошивок?

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

Апдейты контролируются основной программой и, если появилась новая версия, контроллер перезагружается в bootloader и тянет прошивку. Поддержка DHCP есть и в bootloader'e, и в основной прошивке, так же в сети, к которой подключены контроллеры, присутствует DHCP. Порт сервера указывается в загрузчике и в основной программе. Проброс портов в таком случае не нужен.

Значит основная прога куда то лезет по сети? И если прошла ошибка через контрольную сумму, то после перезагрузки висяк обеспечен? Поскольку пишется сразу в память без доп анализа достоверности. А кто тогда в большой кучи фаерволов, роутеров, и тп обеспечивает не закрытость портов. Кто-то ручками должен прописать, так получается. И если сервер смениться и порты, то во всей кучи устройств надо менять. Неушто в uip, в 17K поддержан DHCP, потры?

Да, на этот же сервер по своим делам и попутно проверяет версию прошивки.

Что значит прошла ошибка через контрольную сумму? Прошивка скачивается блоками, у каждого блока проверяется CRC, а затем после записи всей прошивки, проверяется еще и общий CRC. Конечно теоретически можно принять мусор у которого CRC совпадает с правильным, но вероятность такого события ничтожно мала!
Как тогда вы обходите данную проблему?

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

И что в этом сложного? Делаем прошивку с новыми портами, обновляем на всех устройствах и переводим сервер на новые порты.

Я же выше писал. В 17к реализована поддержка DHCP, DNS, обработка UDP пакетов, перепрошивка по TCP в локальной сети, CRC.

облом. в stm32f407 нет криптопроца
придется что то свое колхозить

не такой уж и облом, на авр не было криптомодуля и ниче, все криптовали программно (у атмела и соурсы есть) и не возмущались, не думаю, что для такой редкой и сравнительно медленной операции, как обновление прошивки, обязательно иметь криптомодуль

Сообщение отредактировал aoreh - Apr 25 2013, 09:57

может есть где нибудь пример софтовой реализации AES декрипта под stm32 ?
буду признателен