Ткните носом в каталоги, где можно накопать инфу и подобрать подходящую плату.

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

Необходимый функционал - USB (1-2 разъема), Ethernet
Нужно слобать что-то типа роутера

Спасибо!

Для роутера лучше ARM9. Из последнего, что я использовал и что подходит по теме - http://starterkit.ru/new/index.php?name=Pa...page&pid=15
Купить можно в терра-электроника за 2000 руб. Кстати и на терре хороший выбор отладочных плат.

Есть интересные платы от ЗАО ЗЭО к примеру ТионПро http://www.zao-zeo.ru/catalog/tionpro.html или ТионПро версии 2 http://www.zao-zeo.ru/catalog/tionprov2.html

http://telemetry.ru/docs/UTC920LXv1.pdf
Неплохой и очень компактный модуль, но нужна материнка с питанием и разъемами. Из минусов: есть пара косяков в софте, с которыми сейчас борюсь и цена - около 4к...

Всем спасибо, будем выбирать

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

Вот есть такой дивайс:


Все в одном, все очень модульно.
Интегрирована даже smart зарядка метал-гидридных аккумуляторов.
Совмещает два модема, Ethernet, USB slave и host, CAN, 1-Wire, RF, GPS, SD ...
Предусмотренно локальное управление с любого IR пульта, причем возможно одновременно с нескольких разных.
Делался именно как роутер причем реально защищенный. Даже SD карта защищается паролем.
Для взлома придется ломать аж 3-и процессора.
Внешних FLASH или RAM с программой не используется.

Как страшно жить... А в предлагаемом Вами устройстве какая ОС?
Ну а как насчет хранения образа ядра и файловой системы во внешней незащищенной флэш но в зашифрованном виде + свой загрузчик, который и будет считывать зашифрованую прошивку? А баги, которые надо вычищать всю жизнь, надо сообщить разработчикам чтобы эти баги исчезли и сделать хорошее дело!

Уже запарился искать куда засунуть тот загрузчик чтоб хотябы его спрятать в тех же SAM9 или iMX
И чтоб прога в RAM-е не сидела.
Может знаете ответ?
А то давно бы уже все на линуксе делал.

Ну а SAM9XE для чего сделали?

Сори, но что в SAM9XE особенного, позволяющего защищать прошивки?
Вот например AT91SAM9260 - пишут "8K bytes of SRAM and 32K bytes of ROM" - это не то что надо или недостаточно для маленького загрузчика? Сам загрузчик полностью сидит внутри и не обращается к внешней RAM. Есть чипы с уникальными идентификаторами, от них тоже можно завязываться. Правда несмотря на то что он (загрузчик) и прошивка защищены, кто-то может схватить образ ядра и ФС во время записи в SDRAM - там то оно открыто... Но я не верю что нет способов защитить разработку на базе Linux, должны быть методы, которые я хотел бы в скором времени изучить...
Ещё есть дополнительные механические способы защиты насколько я знаю - это, например, внешняя SDRAM в BGA с линиями данных во внутренних слоях чтоб не слили образ ядра и ФС по проводочкам во время запуска - поправьте если ошибаюсь? Или даже в этом случае можно как-то забрать? А ещё можно чем-нибудь залить, чтобы только уничтожив плату можно было бы добраться к контактам...
ЗЫ Сори за мои ламерские предположения...

Вы готовы заказать несколько десятков тысяч кристаллов?


При современном развитии печатного дела на западе...

В наличие внутренней флеше. Я еще подробно не изучал данный чип, т.к. он пока еще в development состоянии, но я думаю что там будет какая-никакая защита от несанкционированного чтения. В 512К можно записать загрузчик с функцией загрузки и дешифрования прошивки на лету.
А вот с SDRAM - имхо, действительно только механика спасет. По-моему BGA с разводкой во внутренние слои - неплохая идея. Но нужно без перемычек на нижние слои а поверх них необходимо провести важные дорожки так, чтобы нельзя было рассверлить до заветных пинов и подключиться к ним...

Это не серьезно. Как я уже писал, при современном развитии печатного дела на западе ничего не стоит изготовить переходник под SDRAM в BGA. А дальше берем исходную плату, отпаиваем память, ставим свой переходник и все. Даже совсем недорого получится.

Врядли даже это будут делать.
Сошлифуют плату послойно.
Эт даже в гараже сделать можно.

В SAM9XE FLASH будет скорее всего отдельным чипом как в предыдущих Atmel-овских чипах с большой памятью.
Умельцы оторвут, сделают ребондинг и прочитают как параллельную FLASH.
Всех делов на пару дней.

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

Тогда если считать, что единственное уязвимое место - внешняя SDRAM ( или SRAM ), тогда нужно подгружать в нее ядро каким-нибудь хитрым образом - по частям случайным образом. Хотя и это можно побороть при желании...
Получается вся та же проблема нападения и защиты - пока дешевле воровать прошивки чем разрабатывать с нуля будут воровать и это неизбежно как природа человека...

AlexandrY, aaarrr - спасибо
Дали пищу для размышлений... Я вот думал действительно если брать проц с большой флэшкой то туда можно запихнуть расшифровывающий загрузчик из внешней флэши + очень важную часть программы хранить только во внутренней флэшке... Оказывается, если она будет сделана внешней в самом корпусе чипа то её смогут отсоединить и считать... Жить действительно страшно

неисповедимы пути господни...
вот уже и топик про мост usb-ethernet перерос в прикладную хардварную криптографию

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

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

1. Необходим проц с MMU (т.е. видимо 9й арм)
2. Внутреннее ОЗУ (ну пусть оно будет 32К) разбиваем на минимальные страницы (по 4К, кажется), значит имеем всего 8 страниц.
3. Отображаем при помощи MMU 8 текущих наиболее часто используемых страниц, из которых выполняется код (данные пусть лежат во внешнем озу, фиг с ними). При обращении к неотображенной странице выбрасываем самую старую страницу и на ее место из флеша достаем необходимую страницу кода (пока тут классическая виртуальная память), но только во флеше храним все в зашифрованном виде. Посему, вместо копирования применяем расшифровку.

У Freescale i.MX есть интересная фишка - High-assurance boot. Почитайте, если кому надо супер защиту.

Да, это интересная мысль, что самый важный код _никогда_ не будет вылезать во внешнюю SDRAM... Но вот вопрос: и как же собственно реализовать такую схему при условии работы ОС Linux? Интересуют именно практические шаги и руководства по претворению мечты в суровую реальность...

Забудьте. Станет клином такая конструкция. Там слишком много кода исполняется при работе. Так что у Вас только один вариант - написать весь софт самому.

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

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

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



Какой либо код не должен выполняться из внешнего ОЗУ, иначе - это путь к подлому софта.

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

Кстати, эти теоретизирования не на пустом месте. WinCE умеет хранить во флеше пакованые странички и подкачивать их в озу на лету. Правда, там это сделано для уменьшения объемов требуемой флеши. Но в принципе, от замены zlib на des ничего особо не поменяется