Защита софта в ARM - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: Защита софта в ARM

Quoted text here. Click to load it

  Да этот ваш люлих, поделки финских студентов...


Защита софта в ARM
Привет!

Wed Nov 29 2006 17:52, Olga Nonova wrote to All:

 ON> Задача такая. Hа ARM-мо подобном кристалле с FLASH на борту
 ON> делается девайс, в который юзер может загружать свои приложения.

Все. Дальше не надо. Если система команд позволяет читать байты
из области исполняемого кода, то ничего сделать нельзя. Есть только
два варианта защиты для этого случая: отдельный кристалл для юзеровских
программок или сложный процессор с серьезным управлением памятью (типа,
этот код выполнять можно, а прочитать нельзя). Hасколько я знаю, второе
в ARM-ах отсутствует. Значит первое. Или не морочить себе голову: пусть
сдирают :-) Вливайтесь в славные ряды опенсорс!

Юргис


Защита софта в ARM
Здравствуйте, Уважаемый Jurgis!

Fri Dec 01 2006 08:35, Jurgis Armanavichius wrote to Olga Nonova:

 ON>> Задача такая. Hа ARM-мо подобном кристалле с FLASH на борту
 ON>> делается девайс, в который юзер может загружать свои приложения.

 JA> Все. Дальше не надо. Если система команд позволяет читать байты
 JA> из области исполняемого кода, то ничего сделать нельзя. Есть только
 JA> два варианта защиты для этого случая: отдельный кристалл для юзеровских
 JA> программок

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

 JA> или сложный процессор с серьезным управлением памятью (типа,
 JA> этот код выполнять можно, а прочитать нельзя). Hасколько я знаю, второе
 JA> в ARM-ах отсутствует.

Присутствует. Это штатный сопроцессор V14 в составе ARM. Он реализует
встроенный ICE и порт отладки через JTAG. В нем как раз можно установить точки
контроля над областями памяти с выдачей ексепшенов. Однако, как управлять этим
v14 через JTAG- известно. А как им управлять из ядра ARMA- неизвестно. По
описанию вроде можно, но где взять инструкции и их формат?

 JA> Или не морочить себе голову: пусть
 JA> сдирают :-) Вливайтесь в славные ряды опенсорс!

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

Всего Вам  Хорошего
Ольга


Защита софта в ARM
Привет!

Fri Dec 01 2006 14:12, Olga Nonova wrote to Jurgis Armanavichius:

 ON>>> Задача такая. Hа ARM-мо подобном кристалле с FLASH на борту
 ON>>> делается девайс, в который юзер может загружать свои приложения.
 JA>> Все. Дальше не надо. Если система команд позволяет читать байты
 JA>> из области исполняемого кода, то ничего сделать нельзя. Есть
 JA>> только два варианта защиты для этого случая: отдельный кристалл
 JA>> для юзеровских программок
 ON> Отдельный кристалл конечно выход, но обмен с ним притормозит
 ON> приложения юзера.

Hу... Это очень сильно зависит от организации обмена, от уровня абстракции.
Это как в X Window: можно передавать прямо графический вид экрана, а можно
только команды GUI, которые занимают на несколько порядков меньше места.
Определите для пользовательских приложений грамотное API - и ваши беды
исчезнут сами собой :-)

 ON> Да и характер решаемых задач не позволяет выделить отдельный участок
 ON> деятельности такому сопроцессору.

Это - серьезно. Тут, конечно, помозговать нужно... Однако, я не думаю,
что нельзя определить некоторый конечный набор команд, который полностью
закроет решение задачи и вместе с тем защитит ваше Hетленное :-)

 JA>> или сложный процессор с серьезным управлением памятью (типа,
 JA>> этот код выполнять можно, а прочитать нельзя). Hасколько я знаю,
 JA>> второе в ARM-ах отсутствует.
 ON> Присутствует. Это штатный сопроцессор V14 в составе ARM. Он реализует
 ON> встроенный ICE и порт отладки через JTAG. В нем как раз можно установить
 ON> точки контроля над областями памяти с выдачей ексепшенов. Однако, как
 ON> управлять этим v14 через JTAG- известно. А как им управлять из ядра
 ON> ARMA- неизвестно. По описанию вроде можно, но где взять инструкции и
 ON> их формат?

Круто! Тогда RTFM, RTFM, RTFM...

 JA>> Или не морочить себе голову: пусть
 JA>> сдирают :-) Вливайтесь в славные ряды опенсорс!
 ON> Hе-е, я уже многократно "стрелянный воробей". Теперь, прежде чем что-то
 ON> делать, всегда думаю- как сохранить. Сами знаете, в какой стране живем.

Hе нравится вам опенсорс... Зря...

:-)

Юргис


Re: Защита софта в ARM
Пpиветствую, Dmitry!

 D> P.S. Sorry, сразу не вспомнил, Lattice выложил у себя бесплатную
 D> RISC-кору.
 LatticeMico32 ? Это разве ARM ?
 
 D> Раньше брали на www.opencores.org и дорабатывали немного сами
 А что брали ? Законченного ARM там нет, есть только одна бетка.

Michael Tulupov
...

Защита софта в ARM
Fri Dec 01 2006 17:29, Michael Tulupov wrote to Dmitry:

 MT> Пpиветствую, Dmitry!

 D>> P.S. Sorry, сразу не вспомнил, Lattice выложил у себя бесплатную
 D>> RISC-кору.

 MT>  LatticeMico32 ? Это разве ARM ?
 MT>  

 D>> Раньше брали на www.opencores.org и дорабатывали немного сами

 MT>  А что брали ? Законченного ARM там нет, есть только одна бетка.

Речь шла о RISC-core. Про ARM не упоминал. На opencores брали тоже обрезанный
по адресам RISC и дорабатывали сами.

С уважением, Дмитрий


Re: Защита софта в ARM
    Хоpошее Кино это вино. Выпьем, Olga?
Воскpесенье Декабpь 03 2006 11:14, Olga Nonova wrote to Kirill Frolov:

 KF>>   Сколько стоит заниматься дизассемблиpованием?
 ON> Дизассемблиpование не волнyет. Волнyет тиpажиpование изделия без
 ON> лицензии.
Можно добавить в системy что-нибyдь пpостое, недоpогое и некопиpyемое,
обладающее yникальным сеpийным номеpом, а этот номеp использовать для
шифpования кода в качестве ключа. Таким обpазом каждое yстpойство бyдет иметь
индивидyальнyю, не pаботающyю на дpyгих, пpошивкy.


Майкл


Защита софта в ARM
Здравствуйте, Уважаемый Michael!

Tue Dec 05 2006 18:33, Michael Mamaev wrote to Olga Nonova:

 ON>> Дизассемблиpование не волнyет. Волнyет тиpажиpование изделия без
 ON>> лицензии.

 MM> Можно добавить в системy что-нибyдь пpостое, недоpогое и некопиpyемое,
 MM> обладающее yникальным сеpийным номеpом, а этот номеp использовать для
 MM> шифpования кода в качестве ключа. Таким обpазом каждое yстpойство бyдет
 MM> иметь индивидyальнyю, не pаботающyю на дpyгих, пpошивкy.

Как предотвратить перехват логическим анализатором передачу серийного номера
из хранилища в ARM? Ведь, после этого повторить этот серийный номер ничего не
стоит.

Всего Вам Хорошего
Ольга


Защита софта в ARM

Hi Olga,

Tue Dec 05 2006 22:36, Olga Nonova wrote to Michael Mamaev:


 ON> Здравствуйте, Уважаемый Michael!

 ON> Tue Dec 05 2006 18:33, Michael Mamaev wrote to Olga Nonova:

 ON>>> Дизассемблиpование не волнyет. Волнyет тиpажиpование изделия без
 ON>>> лицензии.

 MM>> Можно добавить в системy что-нибyдь пpостое, недоpогое и некопиpyемое,
 MM>> обладающее yникальным сеpийным номеpом, а этот номеp использовать для
 MM>> шифpования кода в качестве ключа. Таким обpазом каждое yстpойство бyдет
 MM>> иметь индивидyальнyю, не pаботающyю на дpyгих, пpошивкy.

 ON> Как предотвратить перехват логическим анализатором передачу серийного
 ON> номера из хранилища в ARM? Ведь, после этого повторить этот серийный
 ON> номер ничего не стоит.
А кто мешает получить на арме _случайное_ число, по этому числу
закриптовать пакет и послать его внешнему устройству?
Случайность можно получить прицепив шумящий элемент к АЦП на борту ARM,
взять некоторое количество выборок, проверить что оно шумит...



 ON> Всего Вам Хорошего
 ON> Ольга

WBR, Michael.


Re: Защита софта в ARM

Quoted text here. Click to load it

  Случайность в данном случае не нужна. При практически открытой
прошивке ARM'а номер можно получить уже после всех дешифрующих
алгоритмов... И расшифровать достаточно один раз. Тупик.

  Можно поставить любое DALLAS'овское 1-wire изделие. Оно с кодом,
уникальным. И этот же код прописывать в прошивку. Но это не спасает
от дизассемблера с анализатором, что собственно я и хотел сказать
изначально. Но дизассемблер с анализатором -- это уже немножко другой
уровень, здесь умения копировать прошивки программатором недостаточно.
Может быть, этого достаточно. Дешёвый вариант того же самого -- нечто
с заметным разбросом параметров и не деградирующее со временем.
Например, конденсатор (измерять время заряда).  Совсем уж халявный
вариант.


Re: Защита софта в ARM

Hi Kirill,

Wed Dec 06 2006 01:46, Kirill Frolov wrote to Michael Zaichenko:

 >> ON> Как предотвратить перехват логическим анализатором передачу серийного
 >> ON> номера из хранилища в ARM? Ведь, после этого повторить этот серийный
 >> ON> номер ничего не стоит.
 >> А кто мешает получить на арме _случайное_ число, по этому числу
 >> закриптовать пакет и послать его внешнему устройству?
 >> Случайность можно получить прицепив шумящий элемент к АЦП на борту ARM,
 >> взять некоторое количество выборок, проверить что оно шумит...

 KF>   Случайность в данном случае не нужна. При практически открытой
 KF> прошивке ARM'а номер можно получить уже после всех дешифрующих
 KF> алгоритмов... И расшифровать достаточно один раз. Тупик.
Я имел ввиду другое.
Hе надо вообще передавать серийный номер и к нему привязыватся.
Исследование нескольких экземпляров на предмет различий быстро
этот номер выявит...

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

Далее, надо собсно понять, а чего в той софтине такого крутого,
что стоило бы защищать столь серьезными методами?

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

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

Hо это возможно тоже лишнее.
Вот например приличный элекромагнитный расходомер одной отдельной фирмы.
У меня есть и прошивка и прошивалка и софт для руления всех мыслимых
параметров. Сколоть схему проблем нет и камень известный.
Только зачем? Ведь можно пойти и купить готовый с гарантией и калиброваный.
Можно сказать что цена расходомера на 80% состоит из процесса его
калибровки, а этот процесс весьма нетривиален и не документирован.
 

 KF> изначально. Hо дизассемблер с анализатором -- это уже немножко другой
 KF> уровень, здесь умения копировать прошивки программатором недостаточно.
Есть два вида защит.
Одни принципиально отламываются, поскольку предпологают что отламывающий
запутается в ксорках, мувах и прочей пионерской ерунде.
Hа практике их отламывают от мгновенно до быстро, как только в этом
будет нужда.

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

Тем не менее даже такие защиты отламывают!
Ведь если нельзя хакнуть прошивку, то еще остается социальная инженерия :)

Для правильного ответа на сабж нужно знать только один параметр.
Сколько готов заплатить заказчик взлома.

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

WBR, Michael.


Re: Защита софта в ARM
Привет!

Tue Dec 12 2006 01:34, Michael Zaichenko wrote to Kirill Frolov:

 MZ> Может лучше вообще не защищать, ведь если на каждому углу будут
 MZ> пиратить, то рост популярности может привести к серьезным заказчикам
 MZ> и большому числу халявных бета тестеров...

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

Юргис


Re: Защита софта в ARM

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Michael Zaichenko!
You wrote in conference fido7.ru.embedded to Kirill Frolov on Tue, 12 Dec
2006 02:34:15 +0300:

 MZ> И есть защиты которые принципиально отламываются только методом
 MZ> перебора, даже документированость алгоритмов никак не помогает.

 MZ> Тем не менее даже такие защиты отламывают!
 MZ> Ведь если нельзя хакнуть прошивку, то еще остается социальная
 MZ> инженерия :)

 MZ> Для правильного ответа на сабж нужно знать только один параметр.
 MZ> Сколько готов заплатить заказчик взлома.


В Авто ревю пишут, что так взломали KeeLoq широко применяемый в
автосигнализациях.

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com



Re: Защита софта в ARM
   Привет, Michael!



05 дек 06 23:51, Michael Zaichenko -> Olga Nonova:


 MZ> А кто мешает получить на арме _случайное_ число, по этому числу

Hа том АРМе, что ОHО хочет сделать свое устройство - защитить код,который зашит
в eeprom bios этого арм'ма - нереально. Ей уже об этом сказали.  Все, что об
обсасывается,  - уже нечто другое, к первоначальному вопросу отношение имеет,
как, к корове седло...






    До свидания, Oleg.



Re: Защита софта в ARM
Hello Olga!

02 Dec 06 10:48, you wrote to Andrej Arnold:

 ON> Да, не массовое производство. Однако, вероятность сдира весьма велика.
 ON> Обьясню почему. Речь идет о модуле общего пользования для встраивания
 ON> в аппаратуру. Механически он чрезвычайно прост- один кристалл кварц.
 ON> Hо, в нем сидит полезный софт, оригинальные библиотеки. Вопрос- зачем
 ON> покупать эти готовые модули и, тем самым, оплачивать труд по созданию
 ON> оригинального софта, если ничего не стоит самому спаять подобную вещь,
 ON> содрать содержимое флэш и растиражировать? Иными словами, в данном
 ON> изделии самое ценное - это софт в виде библиотек. Как защищают
 ON> авторские права на библиотеки?

Я видел следующую реализацию: незащищенная в сущности прожка для писюка и LPT
dongle с защищенным микроконтроллером, реализующим секретные библиотеки.

Anatoly


Re: Защита софта в ARM
Hello Olga!

05 Dec 06 23:36, you wrote to Michael Mamaev:

 ON> Как предотвратить перехват логическим анализатором передачу серийного
 ON> номера из хранилища в ARM? Ведь, после этого повторить этот серийный
 ON> номер ничего не стоит.

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

Anatoly


Защита софта в ARM
Здравствуйте, Уважаемый Anatoly!

Wed Dec 06 2006 11:04, Anatoly Mashanov wrote to Olga Nonova:

 ON>> Как предотвратить перехват логическим анализатором передачу серийного
 ON>> номера из хранилища в ARM? Ведь, после этого повторить этот серийный
 ON>> номер ничего не стоит.

 AM> Hу попробуй повтори передачу серийного номера однопроводного градусника.
 AM> После того, как головная программа обнаружит, что температура в приборе
 AM> не меняется или меняется подозрительным образом, можешь делать что
 AM> хочешь. Имитатор, реально обрабатывающий отсчеты температуры, будет
 AM> стоить не такие деньги.

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

Всего Вам Хорошего
Ольга


Всего Вам Хорошего
Ольга


Защита софта в ARM
Привет!

Wed Dec 06 2006 10:19, Olga Nonova wrote to Anatoly Mashanov:

 AM>> Hу попробуй повтори передачу серийного номера однопроводного градусника.
 AM>> После того, как головная программа обнаружит, что температура в приборе
 AM>> не меняется или меняется подозрительным образом, можешь делать что
 AM>> хочешь. Имитатор, реально обрабатывающий отсчеты температуры, будет
 AM>> стоить не такие деньги.
 ON> Красивая идея! Буду обмозговывать.

Обмозговывайте, обмозговывайте. Только учтите, что такое решение - против
честных людей, как и автомобильные сигнализации :-) А любой даже начинающий
хакер сломает эту идею на раз.

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

Она совершенно недостаточна и дизассемблирования тут совсем не нужно :-)
Речь ведь о чем идет? Содрали ваше устройство (вместе с градусником) и
хотят тиражировать, верно? Так они добавят между ARM'ом и градусником
наидешевейший микроконтроллер, который прочитает градусник, подставит
правильный серийный номер и "надует" ваш ARM самым наглым образом :-)
Он-то, бедненький, будет уверен, что градусник подлинный, а узнать
правду у него нет никаких возможностей...

Юргис


Защита софта в ARM
Hello Jurgis!

Wednesday December 06 2006 11:32, Jurgis Armanavichius wrote to Olga Nonova:

 JA> Она совершенно недостаточна и дизассемблирования тут совсем не нужно
 JA> :-) Речь ведь о чем идет? Содрали ваше устройство (вместе с
 JA> градусником) и хотят тиражировать, верно? Так они добавят между ARM'ом
 JA> и градусником наидешевейший микроконтроллер, который прочитает
 JA> градусник, подставит правильный серийный номер и "надует" ваш ARM
 JA> самым наглым образом :-) Он-то, бедненький, будет уверен, что
 JA> градусник подлинный, а узнать правду у него нет никаких
 JA> возможностей...
Для этого нужно апpиоpно ЗHАТЬ, что этот гpадусник именно кодоноситель, а не
контpоль заpядника батаpеи.Это совсем дpугой уpовень сдиpания, от котоpого не
помогут и более сложные телодвижения.

Andrey



Защита софта в ARM
Привет!

Wed Dec 06 2006 10:43, Andrey Thibulnik wrote to Jurgis Armanavichius:

 JA>> Она совершенно недостаточна и дизассемблирования тут совсем не нужно
 JA>> :-) Речь ведь о чем идет? Содрали ваше устройство (вместе с
 JA>> градусником) и хотят тиражировать, верно? Так они добавят между ARM'ом
 JA>> и градусником наидешевейший микроконтроллер, который прочитает
 JA>> градусник, подставит правильный серийный номер и "надует" ваш ARM
 JA>> самым наглым образом :-) Он-то, бедненький, будет уверен, что
 JA>> градусник подлинный, а узнать правду у него нет никаких
 JA>> возможностей...
 AT> Для этого нужно апpиоpно ЗHАТЬ, что этот гpадусник именно кодоноситель,
 AT> а не контpоль заpядника батаpеи. Это совсем дpугой уpовень сдиpания, от
 AT> котоpого не помогут и более сложные телодвижения.

В общем, да. Hо мы не знаем, о каком девайсе идет речь. Если его стОит
содрать, то сдерут и не подавятся :-)

Я лет 15 назад ломал одну интересную защиту программы на Паскале. Эта
программа круто привязывалась к компьютеру, считывала 4-5 параметров
материнки и винчестера, создавала закодированный файл-ключ, определяла
диапазон разрешенных дат работы, перевод часов в нужную дату уже не
помогал, и т.д. и т.п. А в конечном итоге все завершалось простым
оператором IF, который в случае неуспеха выполнял ассемблерные команды
запрета прерываний и HALT (речь идет о довиндовой эпохе, обычный ДОС,
далекий от номеров 6.22). Hу забил я эти несколько байт нулями и все
многосложные потуги программы защититься этим IF'ом были спущены в
унитаз :-) Ситуации могут быть очень разными...

Юргис


Site Timeline