|
Нужна готовая плата, функционал - USB, Ethernet |
|
|
2 страниц
1 2 >
|
 |
Ответов
(1 - 22)
|
Jun 23 2008, 17:48
|
Частый гость
 
Группа: Свой
Сообщений: 75
Регистрация: 31-07-06
Из: Москва
Пользователь №: 19 223

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

Участник

Группа: Участник
Сообщений: 65
Регистрация: 15-01-08
Из: Санкт-Петербург
Пользователь №: 34 101

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

Ally
     
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050

|
Не промахнитесь только. Все линуксовые решения страдают отсутствием защиты. Т.е. ваш дивайс и весь его софт всем будет как на ладони. Только ленивый не возьмется его клонировать. Вторая проблема в том, что баги в линуксовом софте можно вычищать всю жизнь. Вот есть такой дивайс:  Все в одном, все очень модульно. Интегрирована даже smart зарядка метал-гидридных аккумуляторов. Совмещает два модема, Ethernet, USB slave и host, CAN, 1-Wire, RF, GPS, SD ... Предусмотренно локальное управление с любого IR пульта, причем возможно одновременно с нескольких разных. Делался именно как роутер причем реально защищенный. Даже SD карта защищается паролем. Для взлома придется ломать аж 3-и процессора. Внешних FLASH или RAM с программой не используется. Цитата(toweroff @ Jun 24 2008, 21:18)  Всем спасибо, будем выбирать 
|
|
|
|
|
Jun 25 2008, 13:50
|

Ally
     
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050

|
Уже запарился искать куда засунуть тот загрузчик чтоб хотябы его спрятать в тех же SAM9 или iMX И чтоб прога в RAM-е не сидела. Может знаете ответ? А то давно бы уже все на линуксе делал. Цитата(AVR @ Jun 25 2008, 16:53)  Как страшно жить... А в предлагаемом Вами устройстве какая ОС? Ну а как насчет хранения образа ядра и файловой системы во внешней незащищенной флэш но в зашифрованном виде + свой загрузчик, который и будет считывать зашифрованую прошивку? А баги, которые надо вычищать всю жизнь, надо сообщить разработчикам чтобы эти баги исчезли и сделать хорошее дело!
|
|
|
|
|
Jun 25 2008, 16:05
|

фанат Linux'а
    
Группа: Свой
Сообщений: 1 353
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008

|
Цитата(vmp @ Jun 25 2008, 17:59)  Ну а SAM9XE для чего сделали? Сори, но что в SAM9XE особенного, позволяющего защищать прошивки? Цитата(AlexandrY @ Jun 25 2008, 17:50)  Уже запарился искать куда засунуть тот загрузчик чтоб хотябы его спрятать в тех же SAM9 или iMX И чтоб прога в RAM-е не сидела. Вот например AT91SAM9260 - пишут "8K bytes of SRAM and 32K bytes of ROM" - это не то что надо или недостаточно для маленького загрузчика? Сам загрузчик полностью сидит внутри и не обращается к внешней RAM. Есть чипы с уникальными идентификаторами, от них тоже можно завязываться. Правда несмотря на то что он (загрузчик) и прошивка защищены, кто-то может схватить образ ядра и ФС во время записи в SDRAM - там то оно открыто... Но я не верю что нет способов защитить разработку на базе Linux, должны быть методы, которые я хотел бы в скором времени изучить... Ещё есть дополнительные механические способы защиты насколько я знаю - это, например, внешняя SDRAM в BGA с линиями данных во внутренних слоях чтоб не слили образ ядра и ФС по проводочкам во время запуска - поправьте если ошибаюсь? Или даже в этом случае можно как-то забрать? А ещё можно чем-нибудь залить, чтобы только уничтожив плату можно было бы добраться к контактам... ЗЫ Сори за мои ламерские предположения...
--------------------
|
|
|
|
|
Jun 25 2008, 17:55
|
Частый гость
 
Группа: Свой
Сообщений: 75
Регистрация: 31-07-06
Из: Москва
Пользователь №: 19 223

|
Цитата(AVR @ Jun 25 2008, 20:05)  Сори, но что в SAM9XE особенного, позволяющего защищать прошивки? В наличие внутренней флеше. Я еще подробно не изучал данный чип, т.к. он пока еще в development состоянии, но я думаю что там будет какая-никакая защита от несанкционированного чтения. В 512К можно записать загрузчик с функцией загрузки и дешифрования прошивки на лету. А вот с SDRAM - имхо, действительно только механика спасет. По-моему BGA с разводкой во внутренние слои - неплохая идея. Но нужно без перемычек на нижние слои а поверх них необходимо провести важные дорожки так, чтобы нельзя было рассверлить до заветных пинов и подключиться к ним...
|
|
|
|
|
Jun 25 2008, 18:31
|

Ally
     
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050

|
Врядли даже это будут делать. Сошлифуют плату послойно. Эт даже в гараже сделать можно. В SAM9XE FLASH будет скорее всего отдельным чипом как в предыдущих Atmel-овских чипах с большой памятью. Умельцы оторвут, сделают ребондинг и прочитают как параллельную FLASH. Всех делов на пару дней. Этож как же надо не уважать своих конкурентов (или свои дивайсы) чтобы думать, что у них не хватит денег прикупить пару ваших дивайсов для ломки. Цитата(aaarrr @ Jun 25 2008, 21:33)  Это не серьезно. Как я уже писал, при современном развитии печатного дела на западе ничего не стоит изготовить переходник под SDRAM в BGA. А дальше берем исходную плату, отпаиваем память, ставим свой переходник и все. Даже совсем недорого получится.
|
|
|
|
|
Jun 26 2008, 10:01
|

Йа моск ;)
     
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610

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

Участник

Группа: Участник
Сообщений: 65
Регистрация: 15-01-08
Из: Санкт-Петербург
Пользователь №: 34 101

|
У Freescale i.MX есть интересная фишка - High-assurance boot. Почитайте, если кому надо супер защиту.
--------------------
Debian Fan
|
|
|
|
|
Jun 28 2008, 06:33
|

Йа моск ;)
     
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610

|
Цитата Но вот вопрос: и как же собственно реализовать такую схему при условии работы ОС Linux? Забудьте. Станет клином такая конструкция. Там слишком много кода исполняется при работе. Так что у Вас только один вариант - написать весь софт самому. Кстати, о безопасности - стек тоже надо иметь во внутреннем озу, иначе легко подламывается патчем на ходу содержимого адресов возврата во внешнем озу и переход на процедуру эксгумации кода из внутреннего флеша, ну а дальше - дизассемблер и все радуются... Вообщем, создать достаточно защищенную конструкцию с большим внешним флешем программ можно, но это сопряжено с изрядными трудностями. Ну и конечно, во внешнем озу не должно быть никаких указателей на функции, все данные должны проверяться на валидность и т.д., потому как хацкер может попробовать подломать софт заменой исходных данных в озу (куда доступ наиболее прост). Вообщем, надо аккуратно подходить к вопросу. И, главное, за 5 минут это не пишется (долгая разработка) и нужен грамотный кодер (и следовательно, высокооплачиваемый). Вы уверены что произведение зарплаты кодера на время разработки будет ниже, чем возможный убыток от взлома девайса? Цитата что самый важный код _никогда_ не будет вылезать во внешнюю SDRAM Какой либо код не должен выполняться из внешнего ОЗУ, иначе - это путь к подлому софта.
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
Jun 28 2008, 15:12
|

Йа моск ;)
     
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610

|
Кстати, если вдруг надумаете реализовывать такую схему, не забудьте, что обязательно надо иметь контрольную сумму страниц во флеше, причем шифровать ее вместе со страницей, иначе возможен взлом банальным методом научного тыка - подбором последнего блока шифрования в странице флеша для получения управления в озу - и тогда капец  Кстати, эти теоретизирования не на пустом месте. WinCE умеет хранить во флеше пакованые странички и подкачивать их в озу на лету. Правда, там это сделано для уменьшения объемов требуемой флеши. Но в принципе, от замены zlib на des ничего особо не поменяется
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|