Защита устройства от взлома и копирования

Защита от копированияОбещал я недавно моему знакомому — хорошему электрику и чайнику в электронике — сделать небольшое устройство
1) Итак, сделали вы ваше устройство, продали заказчику c предоплатой. Проходит условленный месяц — а второй части оплаты все нет и нет… Вы ему звоните — а он куда-то пропал… Вы ему угрожаете — а он отмазывается. В результате железякой он пользуется, а деньги вам все не отдал. Г-гадина!!!
2) Итак, сделали вы ваше устройство, продали заказчику и радуетесь жизни. А потом с удивлением обнаруживаете на рынке до боли похожее устройство, но сделанное кем-то другим. Оказалось, что у заказчика взял посмотреть ваше устройство его друг, который ваш конкурент. Он его скопировал и теперь продает. Г-гадина!!!
3) Итак, сделали вы ваше устройство, продали заказчику и радуетесь жизни. Вы закрыли все fuse у контроллера — порядок, копировать не будут!.. Так как устройство у вас поддерживаемое, вы регулярно выкладываете обновления, которые заливаются bootloader-ом. А потом с удивлением узнаете, что дружбан заказчика чего-то там модернизирует в вашей программе, делает похожую плату и начинает тиражировать устройство. Оказывается, он проанализировал ваш код и теперь ваяет свое. Г-гадина!!!

У вас такое было/будет/волнует? Если да — то учимся не допускать этого!

I. S. Спасибо всем за дельные комментарии!


Содержание:


Изделие или разработка?


Прежде всего вопрос — что вы делаете? Вернее, что от вас ожидает заказчик? Конкретное изделие или разработку? Очень внятно и толково написал об этом Alfa , за что ему — спасибо! Цитирую полностью (по его же просьбе):

Заказ может быть в 2 вариантах:

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

Ещё раз: по сложившейся практике в таком случае заказчику передаётся вся документация. Вполне справедливо, вам не кажется?

2. Заказ на результат. Вам заказывают что-то. Как вы сделаете это «что-то» — заказчику по барабану. Потому что в таких случаях оговаривается цена конечного изделия и сколько вы потратите на разработку — ваши проблемы. Но и никаких претензий на документацию от заказчика быть не может. Все права принадлежат вам. Это сложившаяся мировая практика. Т.е. традиция. Насколько эта традиция будет иметь отношение к вам… да, вы угадали, :-) зависит от договора.
Этот вариант можно также назвать «заказ на товар». Т.е. вы продаёте не работу, а товар. Как вы понимаете, он используется в основном тогда, когда продаётся уже готовая разработка, или нужна небольшая доработка, вполне оценимая (и небольшая) по затратам, или стоимость готовых изделий превышает стоимость разработки, или разработка перспективная и позволит в дальнейшем получить большие деньги с других клиентов.

Но всегда возможны варианты. Как пример можно привести фирму MicroSoft, которая не покупает программные продукты (для своего использования; да-да, они не только пишут программы, но и, бывает, покупают — не всё можно сделать самим) других фирм, если те не соглашаются дать вместе с лицензией на программу исходные коды этой программы. Хорошо, суки, знают, что такое бэкдор. :-)
Существуют также всякие промежуточные варианты типа конкретному заказчику документацию без права распространения, продажи и производства на сторону, а у вас остаются все права и др.

Теперь о том, чего же хочется. А хочется, естественно, оплату получить как за первое, а права — по второму варианту :-). И насколько это у вас получится — написано в договоре.

Есть ещё такая штука, как авторское право.

Патент же — защита от посторонних. С которыми вы не связаны договорными отношениями.

Далее мы будем говорить о защите «изделия», а не разработки.

А нужно ли защищать?..


Трудная работа криптоаналитикаНо прежде чем переходить к конкретике, надо понять 3 вещи:
  1. нужно ли оно (устройство) кому-нибудь?
  2. насколько оно нужно?
  3. насколько вы готовы этому противостоять?
Если вы делаете комнатный термометр на светодиодиках и цена ему на рынке 10 долларов, то захочет ли кто-то тратить силы на анализ схемы, программы? Наверняка затраченные усилия на анализ того не стоят.
А вот если вы делаете железяку, способную вырубать всю цифровую технику в радиусе пару километров, то тут совсем другое дело! Там будут не просто железяку анализировать, а вас и всю вашу семью также!
Так что первый вопрос упирается в ценность вашего изделия. Может, и проблемы-то нет?..
Опять же — излишние меры защиты усложняют работу с устройством как разработчику, так и заказчику. И вообще, некоторые считают, что изложенная тут тема — это игра в шпионов. Может быть, и вправду?.. Не нужно маниакальной боязни преследований копирования, надо оценить нужду в защите.

В связи с этим предлагаю пару опросов от Alfa на тему реальной востребованности защиты:


Если же ваше изделие весьма ценно — стоит на рынке пару тысяч долларов — то наверняка кто-то готов потратить на копирование сколько-то денег.

Сколько? Второй вопрос — сколько сил, то есть денег готов потратить аналитик на анализ вашего изделия? Если оно стоит с десяток тысяч, то тысяча долларов в случае успеха себя наверняка окупит. Поэтому вам стоит затратить на это y денег…

Сколько? Третий вопрос — сколько сил, то есть денег вы готовы потратить на защиту своего изделия? В случае термометра со светодиодиками каждый лишний доллар на счету. Если же оно стоит те самые тысячи, то лишнюю сотню затратить имеет смысл.

Итак, когда заходят мысли о защите, надо сразу понять:
  1. ценность вашего изделия для аналитика,
  2. сколько денег аналитик готов потратить на анализ,
  3. сколько денег вы готовы потратить на защиту.
Если третий пункт дешевле второго и явно дешевле первого, то читаем дальше!

Постановка задачи


Давайте немного формализуем проблему, опишем ее. Возьмем наиболее общий случай.
Вы делаете ваше устройство. Оно состоит из:
  1. схемы, превращенной в плату,
  2. программы в контроллере,
  3. программы на компьютере, взаимодействующей с устройством,
  4. bootloader-ом для обновления прошивки.
Вы хотите:
  1. продать этот программно-аппаратный комплекс за оговоренные деньги,
  2. быть уверенным, что его не будут успешно расковыривать на части,
  3. или же знать о такой попытке,
  4. и спать спокойно, т. к. ваше устройство не будет скопировано и растиражировано.
Благая цель? А то! Да вот все это достичь трудновато… Вернее, трудновато задним числом. А вот если это все предусмотреть и обдумать заранее, то все реально! Именно этому — анализу и рассмотрению методов — посвящена эта статья. Я думаю, она будет полезна как новичкам, так и старичкам опытным разработчикам. Я надеюсь, что в комментариях мы рассмотрим различные методы/способы. Ну и самые внятные идеи я буду добавлять в статью. Договорились?

Прежде всего пару слов о терминах.

Взломщик vs криптоаналитикНам стоит отказаться от брутального образа взломщика в пользу утонченного образа аналитика. Первый взламывает системы молотком и кувалдой (метод грубой силы, на англ. brute force). Второй исследует природу объекта, анализирует взаимосвязи и находит заложенную в него информацию. Первый не оставляет сомнений в том, что была попытка доступа к объекту. Второй следов за собой не оставляет (как правило). В конце концов, первый почти не пользуется математическими и прочими методами. Второй же только ими и пользуется. Разумеется, деление условное и неоднозначное. Более того, иной раз один превращается в другого. Но все-таки мы будет ориентироваться на научный подход. Поэтому нашего вероятного противника я буду называть аналитиком — он будет анализировать нашу систему.

При этом аналитик несет угрозу нашей системе. Мера этой угрозы и слабое место, через которое осуществляется угроза, — уязвимость. Если уязвимость слабая, то и угроза слабая.

А теперь пошли изучать сию тему. Начнем с предисловия:

Уязвимости на этапе разработки


Проблемы начала работВозникла идея — где-то в кафе вы ее обсудили, в ночном клубе или по скайпу. Ну и радостно ныряете в работу. Попутно на форумах обсуждаете детали, народу рассказываете подробности. Да вот беда — идея-то оказалась хорошей и хлебной, и ваши сообщения читают, разговоры в кафе случайно подслушивают… Вы не боитесь, что кто-то ее может успеть реализовать раньше и дешевле? Выйти на потенциальных заказчиков, и на вашего в том числе? Не боитесь? Зря, т. к. мир тесный.
Так что совет для начала: не выкладывайте полную информацию о вашем устройстве в публичный доступ. На форумах можно указать часть проблемы, не сообщая о предметной области. Можно придумать похожий пример, и на нем выяснить все детали. Помните, что стены иной раз слушают…

Ладно, учли. Вам дали предоплату и вы помчались работать. Предоплата — это, вообще говоря, неплохо (а иной раз и необходимо), но за нее требовать начинают… И о сроках напоминают. А это иногда напрягает. Лично я, если возможно, предоплату стараюсь не брать. Ибо и требовать не могут, пока не заплачено ничего. Поэтому, если я ее беру, то к концу работы, когда сроки уже весьма предсказуемы. Но это так, к слову.

А вот что не к слову — то, что вы отдаете изделие людям в чужие руки. Заказчик устройство забыл — и все, о вас могут забыть. Вы ему будете звонить, а он не брать трубку. Вы к нему будете приезжать, он будет вас кормить «завтраками». Очень неприятное ощущение, я вам скажу! Дистанционно уже ничего не поделаешь — если об этом не задуматься заранее! У меня так «уплыл» сайт, делаемый через «Дезигн proekt» весьма серьезного человека. А в сайте я не предусмотрел дистанционной «стиралки»… Этот опыт мне «обошелся» в 300 долларов.

Как от этого защититься? Есть два способа:

1) я сплоховал в том, что сразу не подписал договор. Мы уже пару раз с заказчиком взаимовыгодно работали. И вот, договорились вначале сделать сайт, а потом уже и договор сделать. Сделали — все довольны. Я приношу договор — и начинаются странности. То ему то не нравится, то это. Начинается ругань. В итоге рассорились и разошлись. Мораль: любую работу начинайте с договора.

2) потом я уже подумал о том, что можно было оставить скрипт, позволяющий мне на сервере обработать «содержимое» страницы. В частности — стереть все и оставить надпись — «заплатите, и тогда верну сайт назад». Мигом бы расплатился! Но это сайт, там так можно. А в электронном устройстве всегда можно поставить счетчик включения/часов работы. В договоре же прописать — «оплата производится в течении месяца после сдачи работ». Ну или "… не позднее 100 часов непрерывной работы". Достаточно, чтобы убедиться в функционале. Как устройство отреагирует на несвоевременную оплату — дело уже ваше личное. Взрываться не стоит, выводить из строя подключенное оборудование тоже. А вот просто перестать работать, оставить моргающую лампочку какую-нибудь — самое то! Выбор методов большой. Подробно обсудим попозже (неплохой пример есть тут). Самое главное иметь возможность вернуть нормальную работоспособность потом! Мораль: предусматривайте способ ограничить функционал, а также дистанционное отключение этого ограничения. Почему «дистанционное» — а потому, что ваша железяка может быть на морской платформе, а вы на континенте; вызывать вертолет для вашего перелета туда чтобы залить новую прошивку будет очень круто и накладно.

В общем-то, все не так-то уж и трагично и сложно. Просто нужно иметь долю здорового цинизма и не забывать, что возможно кидалово на любом этапе. Не забываем о том, что 1) за редкими исключениями не нужно верить обещаниям без бумажки, 2) без бумажки ты договор дает определенные гарантии, 3) а с бумажкой ты все равно 100% гарантий договор также не дает.

Но это все ерунда по сравнению с тем, что вы отдаете ваше беззащитное устройство в чужие жадные лапы! Вот тут уже все серьезней.

Уязвимости и защита


Разбираем нашу систему на кусочки и смотрим ее уязвимости:

Надежность и уязвимость системы

Для начала рассмотрим все компоненты вкратце, в целом.

  • схема/плата. Уязвимость очень высокая, т. к. аналитик может исследовать вашу плату самыми разными способами. У него есть доступ ко всем контактам на плате (под «контактом» я подразумеваю переходную площадку между ножкой внешнего элемента и платы). Он плату видит визуально, что очень упрощает дело. У него есть мультиметры. Можете ли вы защитить плату от копирования? Очень тяжело, почти нереально.
  • программа в микроконтроллере (м/к-р). Тут гораздо лучше! Записанную программу наружу считать невозможно крайне тяжело (при условии грамотной конфигурации fuse-ов!). Насколько мне известно, есть возможность определить состояние памяти «механическим» путем (снимаются слои с чипа и считывается состояние памяти), но это очень дорогая процедура и отнюдь не 100% гарантия успеха. Так что тут защита максимальная. Впрочем, слабое место — взаимодействие с внешней периферией. Это взаимодействие отслеживается логическими анализаторами без труда.
  • программа в компьютере (PC). А вот тут опять кисло. Вашу программу можно трассировать как в режиме реального времени (например, SoftICE — отладчик режима ядра для Microsoft Windows), так и пошагово (например, IDA — интерактивный дизассемблер). Есть даже средства анализа ассемблерного кода и его превращения в нечто высокоуровневое (всевозможные декомпиляторы). Впрочем, средства защиты не дремлют (попробуйте запустить Skype на машине с работающим SoftICE).
  • взаимодействие м/к-ра и PC. Тут дело еще кислее. Если программу в PC можно хоть как-то защитить, то обмен весь как на ладони. Есть куча всевозможных анализаторов последовательного порта, USB, Wi-Fi и Bluetooth. И защита тут возможна только смысловая — криптографическая.
  • bootloader. Тут опять тоскливо. Вы даете код программы в открытый доступ! Просто таки подарок тому, кто хочет скопировать вашу железяку. Но! криптография не дремлет и тут — вы можете выкладывать зашифрованную прошивку. Причем защита может быть полностью реализована на стороне м/к-ра.


Какой итог можно подвести? Если мер к защите не принять, то можно скопировать все, кроме программы в м/к-ре (тоже возможно, но очень дорого). Но тут действует принцип самого слабого звена — достаточно не скопировать хоть один элемент, nj его придется воссоздавать по косвенным признакам, и тогда к задаче копирования добавляется задача воссоздания. А если защищены несколько элементов, то проще создать все заново. Так что, при надлежащей защите всех элементов системы вероятность успешного анализа стремится к 0.

На сей оптимистической ноте переходит к подробному анализу всех элементов и средств их защиты.

Защита платы


Самый первый элемент, который анализируют при копировании — это схема. А схему пытаются воссоздать по плате. Следовательно, защиту надо начинать с защиты платы.

У аналитика задача состоит в том, чтобы получить перечень элементов и схему соединения всех их ножек. Если говорить математически, то он строит квадратную матрицу, в которой столбик/ряд соответствует выводам всех микросхем. Есть соединение элемента — ставим крестик. И так до-о-олго-долго… Таким путем он получает схему в первом приближении. «В первом» — так как есть еще задача проанализировать экраны, индуктивности и емкости, образуемые нарисованными проводниками.

Наша задача ему помешать в этом. Как? Несложно, в общем-то!

1) уничтожение маркировки микросхем стиранием. Когда нет маркировки, то резистор еще можно худо-бедно обмерить мультиметром, емкость и индуктивность вообще головняк, а всякие элементы о 3-х и значительно более ножках иной раз невозможно! В принципе, нет ничего невозможного, но задача становится весьма нетривиальной и очень тяжелой в реализации. Так что запомните этот момент.
Уничтожить маркировку можно или наждачкой/напильником/болгаркой (правда-правда болгаркой! Только очень-очень осторожно и не спеша). Самый дешевый метод, при этом весьма эффективный.
Сами понимаете — в серийных изделиях этот подход не очень…

2) уничтожение маркировки микросхем краской. Можно микросхемы залить краской/лаком. Лак прилипает намертво, заодно обеспечивает вам защиту от случайного замыкания и коррозии. Правда, потом вы сами не сможете прозвонить что-то при ремонте. Перепаять тоже станет большой проблемой.
Для серии тоже не феншуйно.

3) многослойная плата. Если сделать 4-ре слоя — два внутренних питание/земля — то у вас появляется хорошая экранировка, защита от статических помех. А у аналитика исчезает возможность визуально проследить что-нибудь (особенно если переходы на внутренние слои выполнить под пузом плоских микросхем). А если сделать 6 слоев, то задача прозвона может стать практически невыполнимой!
К сожалению, добавление слоев сильно удорожает производство и трассировку платы, а в домашних условиях это сделать очень и очень сложно.
Также конкретно усложняет анализ платы использование BGA-микросхем — тут надо уже рентген или разрушение платы, чтобы все выводы соотнести (спасибо Vga , что напомнил!)

4) заливка платы маской. Кстати, любителям ЛУТа — вот ссылка о том, как это сделать в домашних условиях! Плюсы — та же защита от коррозии, случайных замыканий. Заливка, кстати, может быть не только зеленой, а и белой (рекомендуется для индикационных устройств), черной. Я как-то рассматривал плату, залитую черной краской. Там дорожки толком и рассмотреть невозможно! Ну ладно, тут фотка плохая, но в реальности ненамного легче там что-то понять!
Хотя к прозвону это отношения не имеет, все звонится также прекрасно…

5) заливка платы пластиком. Есть такие пистолеты, что расплавляют трубочку пластика, и этим пластиком можно залить. Та же защита от влаги, но уже в объеме. А также невозможность ткнуться куда-то тестером и что-то рассмотреть (то есть содрать-то можно, но тяжко и явно видно будет).
Тоже дешево и сердито.

6) защита патентом. На цивилизованных людей должно подействовать. В теории. На практике — … Я такого не делал, знаю, что это дорого. Зато, коли таки обнаружили факт копирования, можно пугать судом и прочим.

7) волосинка-детектор. Вы изготовили плату, запаяли, маской залили. Потом на пару соседних свободных ножек контроллера положили ма-аленькую такую волосинку и прихватили ее паяльником. Лежать она должна на дорожках. Что получим? Когда аналитик будет пытаться что-то прозвонить и содрать зеленку, он почти наверняка содрет эту волосинку. А программа должна проверять наличие этой связи. Связь пропала? Ага-а! Тогда через пару часов работы (или другое время, но не сразу) надо какой-то глюк делать — или просто выдавать сообщение об ошибке. Вас вызывают на ремонт, вы смотрите на плату. А микроконтроллер вам жалуется через USB, что столько-то часов назад (он сохранил информацию в EEPROM) волосинку содрали. Вы туда внимательно-внимательно смотрите и все видите…
Другой вариант — плату скопировали, все запаяли, а волосинку запаять-то и забыли…
Понятна мысль?
Сами понимаете, что это все-таки кустарщина и радиолюбительство… На серийных платах такой метод непригоден.

8) еще весьма сбивает с панталыку использование разных типов полигонов. Тут — диагональный, тут — сеточкой, а тут — сплошной. А можно еще их накладывать. В сочетании с черной маской убивает наповал при попытке что-то понять на глаз. Себестоимость решения мизерная.

9) саморазрушение при вскрытии. Показывали нам одну такую разработку для криптографии, очень секретную и не менее дорогую. Так вот, там при вскрытии происходит небольшой взрыв, повреждающий плату и микросхемы. Мне лично такое не нравится. Это слишком вульгарно и крайне не-ремонто-пригодно, а об это забывать нельзя! Да и глаза повредить можно, в суд еще подадут… А вот какое-то небольшое замыкание сделать, дабы контроллер знал, что корпус раскрывали,- вот это вариант! Об этом подумать можно.

10) демо-перемычка. Идея была высказана DIHALT . Это, скорее, аппаратный метод установить demo-режим. Пока данная дорожка существует (зашунтирована на землю, а в микроконтроллере стоит подтяжка к питанию), устройство работает в демонстрационном режиме. Как только проплатили все деньги, пользователю высылается инструкция как перерезать дорожку. И все, после этого устройство полностью функционально. Мне этот метод не нравится — мало ли что там пользователь перережет?.. Да и, собственно, от копирования он не спасает.

11) обманные маневры. Почему бы не использовать свободные выводы для всяких ненужных вещей? Скажем, на выводы АЦП повесить фото- и термо-резисторы, на остальные — какие-нибудь копеечные инверторы/регистры. Можно их не запаивать при разработке, но потом — обязательно! И в программе ими как-нибудь отфонарно управлять (если вы используете RTOS, то задействуйте самый низкий приоритет для такой функции). Можно даже несколько некорректно — как-то апериодически для фото/терморезистора АЦП настраивать то на вход, то на выход, а когда на вход — то подтягивать, то отключать подтяжку. Еще более гламурно будет залить непрозрачным лаком фоторезистор, с терморезистора стереть маркировку или поместить его вплотную к источнику питания. Ну и прочий бред. Главное — чтобы не было вреда от этого как в плане функциональности, так и по цене. Зато аналитик голову сломает, пытаясь понять суть происходящего на плате.

Господа комментирующие — есть еще идеи?

Все приведенные способы 100% гарантии от копирования не дают, да и некоторые дорогие/трудозатратные. Да и alex_avr напомнил в комментариях, что лак и волосинки для серии — это уже совсем ерунда.Так что какой метод применить — надо смотреть на практике под ваше конкретное устройство. Лично мои устройства схемотехнически весьма просты, и я на защиту на этом уровне не заморачиваюсь (но от зеленки не отказываюсь). Но вот коли буду делать заказ на несколько тысяч долларов, то обязательно удалю маркировку, сделаю многослойку и, возможно, заливку пластиком.

Защита программы в микроконтроллере



Если для защиты платы надо было применять нехилые усилия, то защита кода микроконтроллера гарантируется и неплохо реализована самими производителями. Правда, при условии грамотной конфигурации fuse-ов!

Взлом микроконтроллераБеглый анализ Интернета показал, что не все так безоблачно, как хотелось бы — тут человек смог снять fuse-ы и получить, соответственно, доступ к программе. Или вот эта организация. Правда, радуют цены на это дело (больше тысячи долларов), не 100% гарантия и повреждение внешнего вида (а часто и полностью) контроллера. Т. е. вас для гарантийного ремонта не вызовут. Но ведь и копию могут сделать! Поэтому защиту нужно делать для всех элементов системы (хотя если кто-то готов так полосовать ваш контроллер, то и снять лак с платы он тоже не постесняется).

Но не будем о грустном — если ваше устройство стоит до тысячи долларов, то вряд ли кто-то решится на такие траты. Так что методы — в студию!

1) защита fuse-ми. Самое основное наше оружие защиты. У каждого контроллера они свои, доступ разный. Но все они как минимум управляют возможностью записи/чтения всех видов памяти контроллера. Надо обязательно запрещать все виды считывания и записи! Лучше эти функции перенести на внешние интерфейсы (в частности, я всегда первым делом записываю bootloader, делаю программку для чтения и записи всех переменных из EEPROM).
Это правило стоило мне незаработанных нехилых денег, так как первую свою коммерческую разработку я не закрыл и потом мы обнаружили у наших клиентов из купленного одного устройства наличие таких же трех… Оправдывает меня то, что я тогда был еще студентом, а мой наставник как-то не подумал меня предупредить об этом.

2) обманные маневры. Они и тут могут иметь место! И вообще, этот метод может применяться во всех узлах системы. Главное — не впадать в манию. На уровне программного кода это может быть какое-то периодическое/апериодическое дрыгание свободными выводами (или занятыми, если это не влияет на функциональность).
Иногда вспоминайте, что ваша программа все-таки может быть дизассемблирована и проанализирована. Самое то добавить в код какие-то неиспользуемые участки с каким-то тщательно подобранным мусором. Или делать побольше проверок условий на нереальное значение и там что-то мусорить (кстати, это хороший метод для отлавливания каких-то багов!).

3) опасайтесь внешних EEPROM и памяти! Помните, что взаимодействие с ними проанализировать очень и очень просто! Поэтому пользуйтесь ими в крайнем случае. Ну а если уж пришлось — применяйте всевозможные средства защиты обмена (подробнее мы их обсудим в защите интерфейсов).

4) анализ странных внешних событий. Аналитик может пробовать подавать какие-то свои сигналы на входы вашего контроллера, изучая систему и ее поведение. Об этом стоит подумать и по возможности предусмотреть. Как минимум — используйте во внешнем EEPROM контрольные суммы по всему (или только по части) содержимому. Как максимум — дублируйте там же зашифрованную по-разному информацию и проверяйте несоответствия. Не стоит сразу клинить работу программы при обнаруженных странностях, но вот оповестить тем или иным образом своего разработчика (при сервисном обслуживании или ремонта) можно.

5) ограничение функциональности / срока работы. Скажем, вы делаете весьма дорогое изделие, за которое вам заплатят предоплату. И в договоре вы четко пишите, что окончательная оплата должна иметь место не позднее чем через 100 часов непрерывной работы. Прекрасно! А заказчик-то может забыть — как случайно, так и специально… А вы ставьте счетчик включений и работы устройства — дабы не забыл. Время прошло — все, работать устройство больше не хочет, пишет ошибку. Тут-то заказчик и засуетится… Или, скажем, вы обнаружили теми или иными средствами, что вашу железяку таки украли (в широком смысле этого слова). И тогда вы выводите ту же самую ошибку. Или посылаете сообщение себе, разработчику.

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

Этичность защиты методом ограничения функциональности



В комментариях бурные дискуссии вызвал именно этот, последний метод (почему-то у plcist он вызвал лютую ненависть). Вкратце аргументы противников сводятся к тому, что это нечестно. И что заказчик, узнав о такой бяке, больше у меня заказывать ничего не будет.

Тут проблема, как мне кажется, сводиться к взгляду на мир в излишне розовых очках. Вы уверены, что заказчик вас не киданет? На словах «да». А дайте ему тогда на хранение пару тысяч (или десятков тысяч) долларов с его честным словом вернуть. Или голову на отсечение положите, что он вас не киданет. Тут уже уверенности будет поменьше… Обратите внимание — я не утверждаю, что все люди плохие. Я знаю, что не уверен в моральных качествах нового заказчика. Собственно, один раз был уверен — и «Дезигн proekt» он меня таки обманул… Поэтому защититься от такой потенциальной неприятности стоит.

Другое возражение — вот, вы купили у заказчика кофемолку. Через некоторое время она вывела на экран сообщение, что… в общем, не хочет работать. Вы связываетесь с заказчиком, и он посылает вам дистанционную включалку — и все заработало. Будете ли вы ему доверять в будущем? Интересный вопрос.

Ответ: вы уверены, что у купленных сапог змейка не отколосится за пару лет нОски? Или же что увлажнитель воздуха проживет больше трех лет? (если такой найдете, обязательно сообщите мне!!!) На сегодняшний день многие производители смекнули, что лучше делать не очень качественно, чтобы покупатель должен был покупать почаще. Некоторые на Западе говорят, что это даже обязательно! Машина у вас не должна жить больше пяти лет — надо выбрасывать и покупать новую! И что мой ВАЗ-2108 1986-го года выпуска — это моральный урод, т. к. я из-за нее не покупаю себе новую машину. Так что вопрос оппонентам: вы уверены, что ваше устройство проработает значительно больше гарантийного срока?..

На самом деле есть проблема взаимодействия двух человек — заказчика и исполнителя. Если оба честные — все прекрасно. Если нечестный один — то другому надо защититься от его нечестности (случай нечестных двоих я рассматривать не буду). Вы честный исполнитель или нет? Я себя отношу к честным. Кто мой заказчик — я не знаю, поэтому защиту на всякий случай поставлю (защиту в договоре и защиту в программе/плате устройства). Как только его обязательства по отношению ко мне будут выполнены, я сниму все свои ограничители в его устройстве.

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

Защита компьютерной программы



Взлом компьютерной программыЭта тема настолько изъедена в Интернете, что даже вкратце тут мне сказать нечего.

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

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

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

По поводу настройки вашего устройства у заказчика — возите с собой свой компьютер для настройки оборудования. Сейчас есть всякие микро-мини-нет-ноутбуки, так что рюкзак тяжелее не станет. А вы будете уверены, что вашу программу заказчик и его друг-аналитик не сможет проанализировать! Если же настройку обязан проводить заказчик, то разделите настройку логически на две части — что-то предельно важное настраивайте лично вы перед продажей, а все остальное — заказчик.

Интересующимся подробней — гуглите/рамблерите/яндексите/….

Самый надежный способ шифрования



Защита информацииА теперь — небольшое лирическое отступление на тему методов кодирования информации, т. е. криптографии. Тема эта — характеристики видов шифрования — очень обширная и математизированная, рассматривать ее тут бессмысленно. Поэтому я изложу тут реализацию одного метода шифрования, которая очень простая в реализации. А метод этот, тем не менее, один из самых надежных. Речь идет о шифре Виженера. Самым надежным он становится при соблюдении следующих требований:
  1. ключ должен быть случайным числом,
  2. длина ключа должна быть не меньше длины сообщения,
  3. ключ этот должен использоваться один раз

Суть простая. У вас есть «сообщение» — байты данных (массив DATA). У вас есть «ключ» — другие байты случайных данных (массив KEY). Тогда кодирование информации выглядит следующим образом:


for (i = 0; i < size; ++i)
  CRYPT[i] = DATA[i] ^ KEY[i];


Дешифрование — обратная операция:


for (i = 0; i < size; ++i)
  DATA[i] = CRYPT[i] ^ KEY[i];


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

Скажем, вы хотите зашифровать прошивку длиной 32Кб, которую вы будете посылать через Интернет. Надо делать тогда ключ длиной те же 32Кб. И он должен быть еще случайным…

На практике, впрочем, проблему длины ключа можно решить таким хитрым маневром.

Взаимно простые числаВы берете сообщение длиной 9 байт и второе длиной 8 байт. Потом эти два сообщения побайтно складываете. В результате вы получаете третье сообщение, длина которого составит произведение длин этих двух сообщений. Красота? Было 8 + 9 = 17 байт, получили сообщение длиной 8 * 9 = 72 байта! Красота-то красота, но если длины исходных сообщений являются взаимно простыми числами.

Можно взять и три, четыре — сколько угодно ключевых сообщений, но обязательно все их длины должны быть взаимно простыми! Суммарная длина будет их произведением. Так, ключи длиной 8, 15, 49 байт (в памяти занимают 8 + 15 + 49 = 72 байта) дают результат 8 * 15 * 49 = 5880 байт.

Теперь кодирование/декодирование выглядит так:


a = 0;
b = 0;
c = 0;

for (i = 0; i < size; ++i)
{
  DATA[i] = CRYPT[i] ^ KEYa[a++] ^ KEYb[b++] ^ KEYc[c++];

  if (a == SIZEa)    a = 0;
  if (b == SIZEb)    b = 0;
  if (c == SIZEc)    c = 0;
}


Думаю, понятно как этот код сделать элегантнее для более общего случая.

Что является «случайным» числом? Тема эта очень сложная и непростая — загляните для примера в Википедию. Для нас же это может быть какими-нибудь обрывками заархивированных файлов. В общем-то, неважно что. Главное, чтобы байты были максимально случайными (так, текстовый файл не прокатит, т. к. там высока вероятность символов-букв, и почти нулевая вероятность непечатаемых символов).
Vga подсказал мне в комментариях родственный алгоритм RC4 (англ. Rivest Cipher 4 или англ. Ron’s Code, также известен как ARCFOUR или ARC4 (англ. Alleged RC4)). Он тоже ксорит данные с генерируемой на основе ключа небольшой длины последовательностью псевдослучайных чисел.

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

Запомните этот (или RC4) метод. Он нам пригодится в дальнейшем. Его сила в том, что 1) алгоритм шифрования может быть легко получен анализом кода, но вся его сила в ключе, который аналитику по определению не известен; 2) он очень прост и быстр в реализации.

А также запомните еще одно — метод терморектального криптоанализа позволяет вскрыть любое, самое зашифрованное сообщение!

Защита обмена



Защита обменаМы подошли к самому кислому (с точки зрения защиты) элементу системы — обмен между компьютером и устройством. Кислый — потому что обмен очень легко отследить как на стороне компьютера, так и по проводам. На стороне компьютера есть всякие перехватчики потоков COM, USB. На стороне «железа» еще проще захватывать все эти потоки на стороннее устройство (либо прямо на компьютер). Поэтому ваше сообщение будет как за стеклом — подробно изучено и проанализировано. Как тут защититься?

1) обманные маневры. Как и везде, тут тоже можно подурачить аналитика. Можно передавать бессмысленные пакеты. Можно «осмысленным» пакетам придать пару видов (идентификаторов сообщений) и посылать то один, то другой. В периоды простоя программы на микроконтроллере можно посылать откровенный мусор (но так, чтобы компьютер не сошел с ума!). Вариаций на тему предостаточно.

2) кодирование обмена. Тоже весьма полезная вещь — передавать сообщения в зашифрованном виде. Тут, правда, подойдет не абы какой способ шифрования. Самая главная проблема — вычислительная сложность на стороне микроконтроллера. Так что тут сложновато… Впрочем, если система недорогая и пристальное внимание к ней не ожидается, то можно обойтись и вышерассмотренным шифром Виженера.
Но тут надо четко понимать — работа программы на стороне компьютера может быть легко проанализирована, и все ваши ключи будут как на ладони (алгоритмы — и подавно). Недостатком симметричной системы (а шифр Виженера оным и является) будет то, что ключ для шифровки и дешифровки совпадает. Следовательно, проанализировав программу на компьютере, аналитик получит ключ для 1) чтения передаваемых сообщений, 2) их эмуляции. Поэтому лучше использовать алгоритмы ассиметричного шифрования (системы с открытым ключом). Но тут уже начинается математика… Так что ассиметричное шифрование в данном случае — это все-таки для маньяков (ну или очень серьезных устройств!).

3) обнаружение попытки анализа. Когда аналитик сделал первичный анализ вашего обмена и получил какие-то примеры сообщений, он попытается их подать с помощью какого-нибудь эмулятора на ваше устройство и посмотреть на его реакцию. Микроконтроллеру это легко обнаружить. Есть пара характерных признаков: 1) появляется много «ложных» сообщений (неправильные или нереальные идентификаторы, значения полей) — аналитик пробует и иногда ошибается, 2) появляются большие паузы между пакетами — анализатор это делает частично вручную. Обнаружив такие события, ваша программа это может учесть…

4) режим чистого обмена. Но все-таки вы приезжаете на обслуживание, или же сами разрабатываете и отлаживаете устройство. И вам все вышеприведенные хитрости ни к чему — они только мешают. Тогда используется или другие сообщения, или вначале передайте некоторый пароль. Все это нужно для того, что микроконтроллер мог 1) работать чисто, без мусора и шифрований; 2) мог пожаловаться вам на попытки анализа.

Вроде бы и все на тему обмена.

Лично я тут не заморачиваюсь — обмен у меня всегда очень прост и незамысловат. Но в ответственных случаях я буду использовать асиметричные шифры и анализ попыток взлома обмена.

Защита bootloader-а



BootloaderМы подходим к последнему элементу нашей системы — передачи прошивки через публичные каналы данных прямиком в контроллер. Прошивка идет в открытом виде, может быть прочитана кем угодно, проэмулирована, проанализирована, про...-на. Это не фонтан, прошивку надо защищать.

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

Вторым пунктом будет какое-либо кодирование кода прошивки. Значит, надо делать программу для преобразование получившегося HEX-файла (или бинарника) в закодированный вид. Значит, в микроконтроллере должен быть декодер.

Соответственно, последовательность программирования микроконтроллера будет такая:
  1. в компиляторе вы получили файл прошивки в HEX-формате,
  2. программой на своем компьютере кодируете прошивку и выкладываете/высылаете заказчику,
  3. он запускает у себя программу-программатор и переводит микроконтроллер в загрузочный режим,
  4. запускает функцию «прошить». Понятное дело, программа на компьютере у заказчика просто и тупо передает закодированный файл в контроллер, вся дешифровка и прочее производится в нем.
Код bootloader-а разбухает — куда ж деваться? — зато информация зашифрована по высшему разряду.

Как вы закодируете прошивку? Тут есть варианты:

1) шифрование. Сюда идеально подойдет шифр Вижинера в комбинации двух и более ключей. Как подобрать длину ключей? Достаточно просто: выбираете простые числа. Берете их сумму — получаете длину ключа в памяти. Берете их произведение — получаете длину создаваемого ключа. Я взял для примера 23, 37, 47 — суммарная длина 107, создаваемый ключ 39 997. Неплохо, да? Потом берете несколько заархивированных файлов, и откуда-то из середки архива выбираете произвольно последовательности указанных длин. Для истинных фанатиков защиты информации — генерируете псевдослучайное число сертифицированным генератором псевдослучайных чисел. Все, ключ получен. Записываете его в bootloader и в программу кодирования прошивки.

2) обманные маневры. Как и ранее, интерпретируете информацию некоторым заранее заданным произвольным образом (скажем, байт 0x873E преобразуется в 0x4EF0). А еще добавляете к каждому 3-му байту откровенный мусор. А еще можно перемешивать части в файле. А еще… Фантазию, в общем, включайте. Главное, чтобы беглый (а потом уже и вдумчивый) анализ двоичной последовательности не дал никакой информации о структуре данных и назначении отдельных байтов.

Таким нехитрым методом вы очень и очень усложните жизнь аналитику. 100% гарантии опять же никто не дает, но цена (и время) анализа возрастает неимоверно. Лично я делаю только шифрование.

Впрочем, не забываем и о том, что враг не дремлет! Допустим, вы закрыли прошивку только вышеуказанным методом шифрования. В бинарном и тем более HEX-файле есть кусочки, чье содержимое и расположение с той или иной степенью точности можно предположить. Например, код из startup-а, инициализация секции инициализированных переменных и тому подобное. В результате для этих областей можно получить ключ шифрования и заменить код в них своим — допустим таким:


for (int i = 0; i < MAXFLASH; i++)
  PORTA = *((char *) i);


После чего скармливаем bootloader-у прошивку, где вместо этого блока вставлен вышеприведенный код чтения всей памяти программ и выдачи его любым доступным интерфейсом. В итоге получаем на этом интерфейсе дамп зашитой в МК программы (и bootloader-а заодно, если отсутствует защита от доступа на чтение секции с ним). Поэтому банальное шифрование может не помочь. Мораль: не забываем об обманных маневрах. Спасибо Vga за описание этой идеи!

Впрочем, e_mc2 мне напомнил о простом и очевидном способе защиты: косвенная аутентификация. В нашем случае достаточно посчитать контрольную сумму (хеш) по открытому тексту и сохранить это значение в файле прошивки. Bootloader после расшифровки текста должен проверить контрольную сумму по открытому тексту. Если она не совпала – программа была модифицирована, стираем все нафиг. Аналитик самостоятельно не может пересчитать эту контрольною сумму, так как у него нет доступа к полному открытому тексту.
Касательно хеш-функции — для простоты подойдет арифметическое суммирование всей прошивки и запись последнего байта. Более серьезный подход — использование циклической контрольной суммы (Cyclic redundancy code, CRC). Зайдите по этой ссылке — там есть пример табличной реализации, вполне доступной для микроконтроллера.

Самая главная защита



Ну а самая лучшая защита — это, пока враги чего-то взламывают и копируют (то есть тратят время на повторение), вы делаете новое и более качественное (то есть тратите время на усовершенствование).

Успехов!

P. S.Хочу поучаствовать в конкурсе, поэтому добавляю: Спонсоры
  • +19
  • 25 октября 2012, 14:46
  • PICC

Комментарии (227)

RSS свернуть / развернуть
Копирастия — это плохо :(
+4
Несколько забавных историй, связанных с PICC-маразмом и PICC-подставами
О рыжих PICC-козлах — в России таких называют Чубайсами
www.plc4good.org.ua/view_post.php?id=107
Станок прекрасно работал пару-тройку лет, и вдруг на дисплее системы ЧПУ появилось сообщение ”Emergency Stop” и станок всяческие действия производить отказался.

Фаза пятая — Победа!
Программа управления, собственно ничего хитрого собой не представляет. Обычное «релейное» управление всякой всячиной, типа гидравлики, насосами, клапанами и прочей дрянью, но… Присутствует код таймера на 360 рабочих смен по 8 часов. Таймер считает только тогда, когда включен какой-то выход, типа включения гидронасоса усилителя давления, то есть когда станок работает. Когда таймер досчитывает до конца, устанавливается флаг с адресом M13.0 :), типа, все ребята, платите денежки! Что это, как не вымогательство! Сбросить флаг невозможно никаким образом, кроме подключения отладчика, для чего нужен пароль!
Насколько это некрасиво и кто запрограммировал это, либо китайцы, либо наши посредники из Москвы мне, естественно, неведомо…
Но хочется сказать: Ну и козлы же вы, ребята!
И таких инновационно-мыслящих козлов Чубайсов-Михалковых с каждым днём становится всё больше.
О нагибании за мылом
iadt.siemens.ru/forum/viewtopic.php?t=15494&highlight=%F1%F3%E4
Вообще подобные PICC не отличается умом и сообразительностью и долгой счастливой жизнью — ходить по судам, нагибаться за мылом…
А мы не придуриваемся и не страдаем от недополученной прибыли.
Пишу именно как «криптоаналитик»-дилетант -
-1
Интересный отзыв! Предлагаю рассмотреть моя взгляд (и, типа, ответ) в новом разделе статьи «Этичность защиты методом ограничения функциональности» (в самом начале статьи я дал оглавление, т. к. уже реально много подразделов) — почитайте, выскажите ваше мнение.
Да, и откуда вы узнали, что у меня рыжая борода???
0
Причём здесь «Этичность защиты методом ограничения функциональности»?
Это называется и классифицируется (в т.ч. Уголовным кодексом) совсем по-другому — вымогательство.
Не путайте тёплое с мягким.
0
Да вы ресурсом ошиблись. Вам на «задоба.ли» надо. Поплакаться, пожаловаться, пооскорблять. Заодно привести пару случаев про каких-то неадекватов, которые явно не репрезентативны. А по сути — ничего.
0
И таких инновационно-мыслящих козлов Чубайсов-Михалковых с каждым днём становится всё больше:
iadt.siemens.ru/forum/viewtopic.php?t=20402
В симатике я так себе разбераюсь…
И так задача такая, требуется запуск вытяжки в определенное время ночи, привязка требуется к реальному времени. Вытяжка должна включатся в 22.00 и отключатся в 05.00.
Сама идея возникла в целях безопасности а после и вообще заинтересовала когда прочитал маленький пост.
В нем говорилось что некий самооучка которого не сильно увожали написал программу и пролил её, которая должна была остановить в заданное время какоето оборудование и он придет и за считанные сикунды все устранит.
Ну и как после этого обращаться к мелким жуликам с большим самомнением о своей гениальности?
У умного, порядочного инженера даже мыслей таких не бывает — он просто делает свою работу.
А вот подонки только и думают, что все вокруг такие же подонки как он сам и поэтому он имеет моральное право на подонство.
Вот и вся разница в моралях.
Как то в командировке делать было нечего и занялся я анализом одной защиты — и были там мусор и разные XORы по нескольку раз, замусоренные сотнями килобайтов мусора, на которых ИДА просто затыкалась, и MS криптование паролями.
Написал утилитку, которая мусор просто вычищала и оставался чистый код.
Пароль к MS Крипту?
Немного размышления о логике той стороны и принцип оказался логично наипростейшим.
Ежели на поломку первой версии ушло пару недель, то на последующие ещё более замусорено-заксоренно-закриптованные 4 варианта уходил день — так как логика той стороны мне известна «Запудрить мозги Заказчику супер-пупер алгоритмом, состоящем на 90% из мусорного кода»
Та сторона сдалась :)
Да вы ресурсом ошиблись. Вам на «задоба.ли» надо.
Неа — вы можете и дальше играться в мелких шулеров, а можете просто оставаться Человеками и не видеть во всём упущенную выгоду.
Вообще эта статья смотрится на этом сайте как Провокация — тут обычно люди делятся знаниями, схемами и прошивками для повторения,
а статья призывает жлобничать и не делиться знаниями, схемами и прошивками для повторения.
Так то из нас ресурсом ошибся?
Или реально Пинборды ДиХальта через месяц начинают мигать всеми светодиодами, намекая, что мол надо ещё денежку дослать?
А потом он сообщает, что дорожку на плате в таком то месте надо перерезать?
-2
А чем Вы профессионально занимаетесь, можно узнать? Не похоже, чтобы Вы делали какую-то электронику на заказ. И вообще не похоже, что Вы лично общаетесь с заказчиками.
0
Например разные подразделения РЖД просто заказывают изделия и не пытаются их клонировать своими силами.
Разбираются ли Заказчики-Руководители, принимающие решения, в электронике? Смеёщься?
Заказчику главное, чтобы всё надёжно работало.
Когда в 90-е приходилось браться за подработки, то от работ с кривыми личностями (заказчиками) просто на стадии разговора отбрехивался, говорил что это мне не по силам, а для нормальных людей делал, так как это было мне по силам, и не пытался обчистить их карманы, брал за работу столько сколько им было не жалко.
Как то шёл по улице и передо мной у мужика выпала связанная резинкой пачка денег — я просто на инстинкте окликнул мужика, не смотря на предложение случайного прохожего идущего рядом пойти поделить деньги…
Через месяц коллега по работе (с такими же взглядами как у тебя) появился с синякамм — оказывается он оказался в такой же ситуации и пошёл делить деньги… ну его и поделили в подворотне.
Завтра в 9 вечера ТНТ комедия «Ослеплённый желаниями» — очень поучительный фильм. Научитесь правильно формулировать свои хотелки.
На счёт защит — несколько лет назад началась эпопея противостояния Самсунга с пользователями теликов Самсунг серии В, желающих добавить свой расширенный функционал. Сначала прошивка не криптовалась и народ просто правил и заливал прошивку, типа добавить полноэкранный режим для AVI или вообще активировать видеопроигрыватель на более дешёвой модели. Потом добавили мышь, клаву, интернет обозреватель, дешёвые WiFi-свистки… Самсунг засолил прошивку. У кого то опустились руки, но кому то запуском эксплойтов в виджетах удалось разлочить дебажные входы и стали лазить в Линукс прямо через сервисные ножки разъёма VGA и добавлять новый функционал в рассоленную внутри прошивку. При появлении чёрных кирпичей из-за неправильных действий просто стирали епромку 24С замыканием контактов на ней. Ну да когда заинтересованных десятки тысяч то и дело спорится как например с продукцией Микрософта и прочих, в том числе, защищаемых аппаратными донглами.
Сейчас, добавленный тогда любителями функционал, имеется в состоянии поставки телика.
-1
Где Вы работаете — тайна, что Вы делаете — тайна, и все, в общем, тайна, кроме стиля общения и неумения понять то, что читаете. Дело Ваше.
0
Ваше мнение и точка зрения конечно имеют место быть, только вот стиль изложения совершенно неприемлем. Ситуации бывают разными. Иногда может возникнуть потребность в защите кода или всего устройства. Автор описал различные варианты, которыми можно это сделать. Так что эта статья вполне себе на месте.
А вот оскорблять кого-то только потому что Вам что-то не нравится, совершенно не нужно.
+1
Ещё раз повторю — разных ситуаций не бывает.
Иначе можно «разной ситуацией» оправдать все неморальные деяния — я как то 10 лет назад попал в больницу, так всё отделение было заполнено бабками с проломленными головами — ситуация с зарплатой была тяжёлая, а пенсии пенсионеркам выдавали регулярно…
Поэтому и призываю не пытаться искать моральные оправдания для мелкопакостного жульничиства.
Жёстко и неприятно для души?
Так наверное не многим нравится и правдивая надпись на пачке сигарет«Курение вас убивает».
0
Ещё раз повторю — разных ситуаций не бывает.
Да? А если в техзадании на устройство будет прописана защита устройства и прошивки? Это значит что заказчик этого устройства — аморальный тип? :)

Именно ситуации разными и бывают. То что кто-то использует данные методы для своих мелких пакостей или в попытке нахаляву подзаработать — это уже его собственные проблемы. Но не надо стричь всех под одну гребенку.
Потому и говорю, что Вы зря набросились на автора с оскорблениями.
0
Обсуждаем конкретную статью и не пытаемся облагородить благородные копирастные помыслы автора.
Все 3 ситуации описаны в шапке — во всех 3-х случаях Заказчик не заказывал Защиту от себя любимого — и все 3 ситуации, в которых оплативший изделие Заказчик оказывается Гадиной.
1) Итак, сделали вы ваше устройство, продали заказчику c предоплатой.
Г-гадина!!!
2)… Г-гадина!!!
3)… Г-гадина!!!
Это не проблема всех «фрилансеров», не имеющих постоянной работы и постоянного заработка — есть честные от воспитания, а есть воспитанные на майдане Индивидуальные Проходимцы.
0
Согласен с Вами, но все равно это не повод грубить и оскорблять человека.
0
ну и где ж тут «криптоаналез» указаный в тегах?
и к чему приплели софтайс — уже давно не актуальный?
обычный ксор называть «шифр Вижнера» — как минимум гениально
0
1) о криптоанализе сказано немало, как мне кажется
2) SoftICE по-прежнему рулит, т. к. у многих заказчиков по-прежнему стоит Win98 — сам видел
3) XOR — это неплохая реализация шифра Виженера
0
у вас как мне кажется немного нетрадиционное понятие термина «криптоанализ» ;)
тех заказчиков у которых стоит 98ая — нужно сразу слать лесом, в большинстве своем то нищеброды либо жадные до упора поцы.
0
1) как раз вполне жизненное его понимание
2) если такие заказчики мне платят по паре штук баксов за не очень-то и сложное устройство, то… я поступлюсь гордостью и сделаю железяку!
0
то нищеброды либо жадные до упора поцы
Кстати, я говорил о гос. заказчиках из области нефте и газа, как ни странно. На покупку железяки деньги-то им выделяют нехилые, а вот на оборудование условий труда (и, в частности, нормальных компьютеров) — почему-то нет…
0
обычный ксор называть «шифр Вижнера» — как минимум гениально
Алгоритм здесь не в XOR'е, а в генерации ключа. XOR просто удобный способ применения ключа к данным. Есть еще один похожий алгоритм — ArcFour. Он тоже ксорит данные с генерируемой на основе ключа небольшой длины последовательностью псевдослучайных чисел.
+1
Оно состоит из 1) схемы, превращенной в плату, 2) программы в контроллере
Для спискоты есть теги ul и ol. Не надо ее в одну строчку писать.

Шифр реализован неправильно — ты забыл инкреметировать индексы ключа. На самом деле надо a = (a < SIZE_A-1)? (a + 1): 0; (скобки для наглядности). Алсо, ключи обычно получаются хэшированием. Оно как раз обеспечивает рандом с требуемыми криптографии свойствами.
Поэтому лучше использовать алгоритмы ассиметричного шифрования (системы с открытым ключом). Но тут уже начинается математика…
Причем тяжелая. Так что это в большинстве случаев решение только для устройств с аппаратными криптомодулями.
0
  • avatar
  • Vga
  • 25 октября 2012, 15:55
шифр Вижинера – это очень плохая идея. Даже не углубляясь в криптоанализ, он легко ломается, если я знаю содержимое открытого текста. А в случае прошивки – я с больной вероятностью могу предположить содержимое фрагмента кода. Например, инициализация .data, .bss — часто используется «стандартная», библиотечная. Зная фрагмент открытого текста, я могу определить соответствующий фрагмент ключа. Зная фрагмент ключа, я могу написать эксплойт, зашифровать его, и подставить.

Если уж хотите шифровать — используйте современны алгоритмы шифрования.
0
Упс, промахнулся, комментарий должен быть в основной ветке
0
В принципе да, но для защиты от этого есть другие средства — вроде подсаливания, пред/постобработки, контроля целостности и так далее.
0
Ну, «соль» используется в хешировании, и там она однозначна нужна. Здесь, пли шифровании, мы можем только дополнительно усложнить алгоритм каким либо образом предварительно обработав открытый текст. Но такая защита «защита, основанная на незнании алгоритма» неэффективна. Поверьте, лучше взять простой в реализации и надежный алгоритм шифрования (типа RC4) и использовать его для шифрования и косвенной аутентификации.
0
RC4 тоже достаточно уязвим, так что добавить дополнительные элементы защиты никогда не помешает. К тому же, алгоритмы пред/постобработки и подсаливания скрыты в бутлоадере и кодировщике прошивки у автора, так что атакующему они недоступны.
0
Кстати, этот шифр как-то не очень похож на шифр виженера. Больше похоже на машины вроде энигмы, которые использовали кодовые диски с несколькими ключами взаимно простой длины, из которых получался длинный ключ.
0
Шифр виженера это полиалфавитная субституция одного символа сообщения одним символом ключа, а как получен ключ и повторяется ли, в принципе не важно.
0
Нам на лекциях по криптографии его преподнесли именно так. И вроде бы соответствует Википедии: «метод полиалфавитного шифрования буквенного текста с использованием ключевого слова».
Но, если общественность желает, я уберу из текста ссылку на французского дипломата :-)
0
Я не специалист в криптографии. Просто описанный шифр не похож на тот, что описывается в вики. Да и полиалфавитности как таковой тут нету, ИМХО. Это XOR данных с выхлопом PRNG.
0
он легко ломается, если я знаю содержимое открытого текста
Если бы использовался ключ единичной длины, то да. А тут каждый новый символ кодируется новым ключом. Поэтому и требуется полный перебор для получения ВСЕГО ключа.
HEX-структура регулярная, это да. Но у разных файлов будут общими только адреса и символ ":", а остальное будет разнится!
0
HEX-структура регулярная, это да. Но у разных файлов будут общими только адреса и символ ":", а остальное будет разнится!
HEX-то зачем шифровать? Шифровать надо бинарник.
А тут каждый новый символ кодируется новым ключом. Поэтому и требуется полный перебор для получения ВСЕГО ключа.
А весь не нужен. Достаточно найти ключ к сотне байт и заменить их на код вида
for(int i=0; i<MAXFLASH; i++)
  PORTA = *((char *) i);

И получить всю прошивку на порту А.
0
Тем более если шифровать бинарник, то фиг разберешься!
В пример по поводу PORTA не въехал…
0
В бинарном файле есть кусочки, чье содержимое и расположение с той или иной степенью точности можно предположить. Например, код из startup'а, инициализация секции инициализированных переменных и подобные. В результате для этих областей можно получить ключ шифрования и заменить код в них своим. После чего скармливаем буту прошивку, где вместо этого блока вставлен код чтения всей памяти программ и выдачи его любым доступным интерфейсом и получаем на этом интерфейсе дамп зашитой в МК программы (и бутлоадера заодно, если отсутствует защита от доступа на чтение секции с бутом).
+3
Шикарно! Взлом а-ля «переполнение стека».
Добавлю в статью, если Вы не против.
0
Осмелюсь пояснить заявление Vga. За частую таблица векторов прерываний представляет из себя известную структуру и расположена по известному адресу. Плюс к этому известен код инициализации из стандартной библиотеки (это даже лишнее). Наши действия:
1) Восстанавливаем ключ указанных блоков.
2) Шифруем свой код вывода содержимого flash памяти с помощью восстановленной части ключа, которая чудесным образом попадает и по смещению.
3) Подсовываем в тело шифрованной прошивки свой шифрованный код (одна проблема — CRC) и шьём ей МК.
4) Запускаем контроллер.
В итоге получаем на порте прошивку в чистом виде.

На словах легко, да деле для криптоаналитика ещё проще. Уж что-что, а ксор не вызывает проблем.
+1
Ну медленно я печатаю, что поделать :)
0
Да не, как раз неплохо и подробно расписано! Те, кто по ссылке со статьи спустятся сюда почитать — увидят подробный разбор метода. Спасибо!
0
В качестве замены ксора можно присмотреться в английскому табличному, либо Simple-DES (была мысля аналогичную статью накатать для стм8 с этим алгоритмом). Тоже не супер сложные шифры, но уже так просто взять не получится. Это вам не просто ксор, хотя и просто замена.
0
Существенно выше требования к памяти, да и выгоды по быстродействию не вижу (я про табличные методы). Хотя они прокатят для более сложных методов шифрования
0
Можно использовать CBC режим, т.е. XORить байт плейнтекста с шифратом предыдущего байта перед его перед шифрованием ключом.
+1
Фантазия тут безгранична. Чем более нестандартный подход, тем более тяжелая работа у аналитика. Это самая главная мысль статьи
0
Мне не нужно расшифровывать всю прошивку (знать весть ключ). Мне достаточно знать фрагмент, который я использую для внедрения эксплойта. А експлойт уже сдампит ваш бутлоадер, вместе с полным ключом.
0
Бут врядли, обычно он защищается от чтения из секции приложения. Например, на AVR есть биты защиты бута и отключения SPM.
0
А случае с AVR – согласен. Но бутлоадер не во всех МК имеет подобную защиту.
0
Для спискоты есть теги ul и ol. Не надо ее в одну строчку писать
UL и OL мне не нравится (в данном случае) тем, что раскидывает текст на различные строчки.

Шифр реализован неправильно
Позоррр мне! Спасибо, исправил!

Алсо, ключи обычно получаются хэшированием
Тоже математика. Достоинство XORа в его предельной простоте.
0
UL и OL мне не нравится (в данном случае) тем, что раскидывает текст на различные строчки.
И это правильно. А твои списки в одну строчку, да еще и два списка на один абзац, если внимательно не читать, а пробегать глазами, то даже не заментишь что их два…
Тоже математика. Достоинство XORа в его предельной простоте.
Я имею в виду исхожные ключи, которые ты предлагаешь дергать из архива.
0
Ладно-ладно, разделю списки на части.
По поводу генерации ключа — дам Ваш комментарий и ссылочку на RC4, ОК?
0
Почему RC4? Ключи обычно генерируются из паролей (впрочем, можно задействовать и случайные данные, чтобы брутфорсеру было веселей) при помощи алгоритмов вроде MD5, SHA1 etc.
0
В общем, я решил не вдаваться в детали и просто указать на родственный алгоритм :-)…
0
Ну, если уж насколько беспокоиться о надежности – то из паролей пропущенных через функцию хеширования тоже генерировать ключ не очень.

В серьезных системах для генерации используют аппаратные датчики (например, шумящие диоды) для накопления энтропии, потом накопленные данные нормализуют и (для некоторых алгоритмов) проверяю на «слабые ключи».
0
Ну, конкретно такой подход, AFAIK, используется в системах, шифрующих именно по паролю. А так да, лучше на вход хэшу скормить труЪ-рандом. Хэш ему добавит равномерности.
0
Гигантская работа.Уважаю! Вообще, очень полезная статья.
0
Тема хорошая, но подход очень уж кустарный/радиолюбительский. Лак, волоски между ножками, это все несерьезно, особенно для серийных устройств.
По шифрам лично я предпочитаю AES.
+1
Волоски — да, согласен. Это, пожалуй, защита для единичных изделий. Добавлю эту мысль в статью, спасибо!
А вот лак — это очень хорошо! Помимо защиты от копирования это защита от влаги и случайных закороток.
0
Я не говорю что лак плохо(а в некоторых устройствах просто необходимо), но как средство защиты от взлома — несерьезно.
0
Ну… Работу желающему прозвонить плату это очень усложняет
0
Не так уж и усложняет. BGA, внутренние слои и дорожки под микросхемами больше гемора доставляют — приедтся или разрушать плату, или прибегать к рентгену.
0
Хотел бы узнать личные мнения сообщества по поводу предоплаты. Меня научили ее недолюбливать :-). А вы как считаете — прав я или нет?
0
  • avatar
  • PICC
  • 25 октября 2012, 17:20
Договор. Всё в договоре.
Если в договоре указан срок — по фигу, платили ли вам предоплату. Всё равно скорее всего будут требовать.
0
Я тоже не люблю предоплату брать. Впрочем, я не так уж и часто делаю что-то на заказ, да и то не разработка железа, а софт/сайты/etc.
Но тут на форуме было интересное мнение. Заслуживает внимания, имхо.
0
Поэтому банальное шифрование может не помочь.
Вы неправильно поняли. «Банальное» шифрование помочь может, если использовать ширование для скрытия открытого текста и косвенной аутентификации отправителя.
Просто нужно использовать нормальные алгоритмы, которые не позволяют получить фрагмент ключа по известному фрагменту открытого текста.
0
  • avatar
  • e_mc2
  • 25 октября 2012, 18:24
Ну, там много тонкостей. В криптозащите PS2, основывающейся, AFAIK, на RSA, находят пещеры для кода эксплоита.
0
Тонкости не в самом криптоалгоритме, а в окружении (среде исполнения). Сам криптоалгоритм, как правило, вполне надежен и я не знаю взломов именно через алгоритм (хотя, иногда случаются прорывы типа «радужных таблиц» в MD5). Если бы кто-то мог, за приемлемое время, взломать алгоритм уровня подписи RSA, он врядли разменивался на мелочи, типа взлом игровых консолей :)
0
Ну не такие уж оно и мелочи) Но да, ломают не алгоритм, а уязвимые места защиты (для NDS вон вообще просто RSA-ключи у нинтенды сперли). Но я собственно к тому веду, что на одном лишь надежном алгоритме далеко не уедешь, так что возможно на него и заморачиваться незачем. Подлатать основные дырки простого и вперед. Идеальная ж защита не всегда нужна, это для приставок ее взлом дорого обходится (единовременно ломается защита всех игр).
0
Ну не такие уж оно и мелочи)

Ну, даже быстрый взлом DES (несмотря на его неактуальность) потенциально может принести нехилый проффит. А уз взлом подписи RSA открывает просто неведомые перспективы :)

А по сути, я с вами, конечно, согласен — идеальной защиты нет. Криптоалгоритм – лишь часть защиты, которая (если она нужна) должна быть комплексной (есть такая штука КСЗИ – комплексная система защиты информации). И защита должна быть адекватна «ценности» защищаемой информации. Безопастность информации и удобство пользования системой – это две противоположенные вещи. Я могу привести много примеров систем, которые уязвимы именно из-за чрезмерной усложненности системы защиты.

«Если заставить пользователя придумать пароль он, скорее всего, придумает пароль не стойкий к перебору. Но если заставить пользователя придумать пароль длиной в 20 символов – он запишет его на бумажке и положит под клавиатуру».
0
Неа. Тру пользователь включит опцию запоминания паролей и при входе на сайт все будет вводится автоматически. При этом не важно кто вообще находится за компом.

А самые трушные включат защиту с помощью вебки. И как кто-то левый появится перед компом, то он тут же будет блокироваться. Правда есть маленький недостаток. Нужно все время пялится в объектив камеры… Меня это достало после первых десяти блокировок.
0
Неа. Тру пользователь включит опцию запоминания паролей.

:)

Серьезную систему с такой опцией не допустят к эксплуатации (если говорить о действительно «серьёзных» системах). Даже автоматическое запоминание логина недопустимо.
А вот бумажку под клавиатурой запретить/проконтролировать нельзя :)
0
Кто-нибудь реально защищает свои проекты от копирования? Если есть возможность обойти фьюзы, — содержимое контроллера можно размножать со всеми криптозащитами. Лаки смываются смываются ацетоном или сковыриваются ножом. Скорее заказчик незаинтересован, чтобы разработку, которую он финансировал и с которой хотел навариться разработчик начал тиражировать без него.
0
:-)
0
Скорее заказчик незаинтересован, чтобы разработку, которую он финансировал и с которой хотел навариться разработчик начал тиражировать без него
Разные заказчики бывают. Если это организация, где есть грамотные ремонтники и которые могут повторить схему и снять прошивку, то очень даже заинтересованы! Так у меня один проект и уплыл…
0
Прочитал я статью и стало мне интересно: а насколько это в реальности востребовано?
Поэтому я создал опросы

Приходилось ли вам использовать в своих разработках методы защиты устройства от взлома или копирования?
we.easyelectronics.ru/Soft/prihodilos-li-vam-ispolzovat-v-svoih-razrabotkah-metody-zaschity-ustroystva-ot-vzloma-ili-kopirovaniya.html

Какова стоимость изделия, которое вам пришлось защищать?
we.easyelectronics.ru/Soft/kakova-stoimost-izdeliya-kotoroe-vam-prishlos-zaschischat.html

Приглашаю.
Предлагаю разместить ссылки на них в теле статьи.
+2
  • avatar
  • Alfa
  • 25 октября 2012, 19:52
+1
Хм, а в чем смысл данного опроса? Какая польза от его результатов?
+1
См. начало ветки. :-) Мне просто стало интересно. :-)
Хотя если опрос покажет, что этим многие пользуются, то это сигнал к тому, чтобы более серьёзно отнестись к теме.
0
Тогда, более информативным, был бы опрос – как часто вас «кидал» заказчик? :)
+1
Тоже неплохая тема.
0
Просто согласно канонам защиты информации, перед тем как что-то защищать, нужно определить степень угрозы и оценить соответствующие риски :)
0
Да и для остальных ориентир.
0
Не против. Ща добавлю вначале
0
Автор, было интересно прочесть.

Как итог, пока ломают, движемся вперед, очень мудро.
0
Боязнь шпионов и «криптоаналитиков» — пережитки холодной войны и совка в общем. Если будете сидеть в дальнем углу и никому ничего не показывать — так и останетесь — умные и никому нафиг не нужные.

Я не скрываю свои знания и разработки, ни от коллег, ни от заказчиков. Мне приятно, когда люди видят мою работу и годами пользуются результатами моих трудов.
+3
  • avatar
  • Const
  • 25 октября 2012, 21:58
Не похоже что ты полностью прочёл название и текст статьи.
А комментарий вообще о том как ты примерил на себе-любимом опыт другого человека.
0
Мне приятно, когда люди видят мою работу и годами пользуются результатами моих трудов
Это не имеет отношения к теме статьи, по-моему. Пользуются и оценивают ваш труд — прекрасно. Пользуются чьей-то сворованной подделкой (которая к тому же может быть глючной) — неприятно.
0
Не все задумываются о подобных ситуациях заранее, вот некоторые исключительно по мере поступления проблемы.
0
Я не согласен с вашим подходом в целом. Мне непонятна идея «защитить себя от заказчика». Кого и от кого защитить? Все наоборот!

Это вы, как исполнитель, должны его обхаживать, чтобы он был уверен, что получит качественный продукт в указанные сроки. И благодарить его, что дал ВАМ работу, а не купил готовое изделие. А вы вместо этого предлагаете на выбор различные варианты диверсий, сомнительных как с этической, так и с юридической точки зрения.

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

Грамотные комментарии пишет e_mc2 . На этот обратите внимание. Особенно последние два абзаца.
+1
Я предлагаю защищать себя не от заказчика, а от копирования моего продукта — как заказчиком, так и кем угодно. И диверсий я ему делать не собираюсь. Не оплатил продукт — так и нечего им пользоваться, не так ли?
0
Const подразумевает, что при заказе на разработку продукт не твой, а заказчика. Впрочем, в этом случае заказчик требует не железяку, а сорцы и доки.
0
Все-же прокомментирую Вашу статью в общем (т. к. вопросы защиты информации мне очень близки)…

ИМХО, все то, что вы описали, называется «игра в шпионов» — явки, ставки, пароли, криптография. Вы слишком усложняете вопрос. От проф. реверс-инжиниринга абсолютной защиты просто нет. Заказчиков, которые будут заниматься криптоанализом очень мало :) И, с такого уровня заказчиками, Вы, скорее всего, будете работать по контракту а не на «честном слове». Излишнее увлечение защитой только усложняет взаимодействие с заказчиком и отнимает Ваше время, которое можно потратить с пользой.

На практике – есть простые методы от банального «кидка» рядовым заказчиком.

Вот DIHALT’овский метод перерезания дорожек – очень простой и эффективный способ. Один мой знакомый, обеспечил защиту тем, что выводили на дисплей устройства (при старте) пару матерных слов :) Для демонстрации работы оно не мешает, а вот в массы такая прошивка вряд ли пойдет.
+4
  • avatar
  • e_mc2
  • 25 октября 2012, 22:28
Почему-то у многих прочитавших статью сложилось мнение, что я призываю всех тотально шифроваться. Вовсе нет! Я попытался проанализировать угрозы и методы защиты. И также я призываю к АДЕКВАТНОЙ защите! По-моему, в самом начале я это написал. Хотя, возможно, стоит это подчеркнуть особенно.
Как по мне — если разработка и использование защиты большой проблемы не создает (как однажды разработанный и используемый bootloader с поддержкой легкой криптографии, заливка платы и лак), то почему бы не использовать защиту?
0
Понимаете, прочитав Вашу статью, у меня сложилось впечатление, что вы пишете о том, в чем сами плохо разбираетесь.

Начинается все с термина «криптоаналитик». Криптоаналитик – это специалист по криптанализу. Это математик, человек, который ищет (или использует известные) уязвимости в криптоалгоритмах. Один из представителей данной профессии сидит сейчас рядом со мной, поверьте такой человек вам мало поможет в «вскрытии» устройства, он очень далек от электроники и программирования, он оперирует исключительно математикой :)

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

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

По моему опыту – самый эффективный способ борьбы с «кидаловом» это не игра в шпионов, а просто грамотный выбор заказчика и грамотно построенные взаимоотношения. Во многих случаях, заказчик не хочет платить деньги просто потому, что ему не очень то и нудно разработанное Вами устройство (или он нашел, где купить готовое). И никакие средства защиты вам не помогут.

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

Хоть я учился на специальности «специализированные компьютерные системы», я прослушал курс лекций у Горбенко — одного из ведущих специалистов по защите информации в Украине. Прослушал лично для себя, поскольку люблю криптоанализ. В нашей группе я был самым лучшим в этой теме (естественно, сын Горбенко на голову лучше меня в этом разбирается, но так он же учился именно на той специальности!)

Да, криптоаналитик — это математик в первую очередь. А что же тогда есть попытка изучить поведение системы, как не математический анализ??? Изучить плату — это построить матрицу пересечений. Изучить закодированную прошивку — тем более. Изучить алгоритм обмена — это предположение о структуре пакетов, подбор, оценка влияний и т. п. Да, эллиптические кривые, НОД и прочее тут не используется, но это квалифицированный труд, для которого нужны серьезные знания! И поэтому я взломщика тут я назвал «аналитиком».

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

На эту тему я задумался из-за того, что у меня скопировал мой проект вполне серьезный заказчик с договором и всеми делами. Да, он поступил культурно — наделал себе копии жутко дорогой железяки, мы с ним договорились, что он не будет ее продавать другим. И я с ним дальше работаю, потому что заказчик денежный. Но… просто учитываю его специфику и, вот, защищаюсь. Больше кидалова не было :-) Да и «кидалово» тут — просто недополученная прибыль, убытка он мне не создал.

А про мои средства защиты я ему не говорю, сами понимаете ;-)…
0
Давайте все-же разберемся с криптографией.

Знание отдельных блоков ему не помогут узнать об остальных.

Знание отдельных блоков поможет внедрить есплойт. От этого есть довольно простой метод защиты – косвенная аутентификация. В вашем случае, достаточно посчитать контрольную сумму (хеш) по открытому тексту и сохранить это значение в файле прошивки. Бутлоаер, после расшифровки текста должен проверить контрольную сумму по открытому тексту. Если она не совпала – программа была модифицирована, стираем все нафиг. Злоумышленник (Man-in-the-middle) самостоятельно не может пересчитать эту контрольною сумму, т. к. у него нет доступа к полному открытому тексту.

Касательно кидалова и жадности отдельных заказчиков.

мы с ним договорились, что он не будет ее продавать другим

Но вы же пишете, что у Вас с ним был договор, почему Вы не предусмотрели этот момент в договоре?

А про мои средства защиты я ему не говорю, сами понимаете ;-)…

Зря. Ели Вы оставляете бектдор, который, например, позволяет удаленно «стереть сайт» (как Вы писали в статье) — это плохо. Еще раз повторюсь, если бы я обнаружил в коде такой бекдор, я бы больше не работал с таким исполнителем. Я не могу быть уверен, что обнаруженный бекдор единственный и я не знаю, с какой целью исполнитель будет его использовать.
0
В вашем случае, достаточно посчитать контрольную сумму (хеш) по открытому тексту и сохранить это значение в файле прошивки
Хорошо, добавлю этот момент в статью в разделе bootloader-а.

Но вы же пишете, что у Вас с ним был договор, почему Вы не предусмотрели этот момент в договоре?
ФОРМАЛЬНО вроде бы все ОК — я свое изделие не патентовал. Но ПРАКТИЧЕСКИ он все-таки мог поступить нехорошо — слава Богу, не поступил, и мы с ним по-прежнему нормально работаем.

Ели Вы оставляете бектдор, который, например, позволяет удаленно «стереть сайт» (как Вы писали в статье) — это плохо
Кстати, так реально делают разработчики веб-сайтов. И это хорошо даже для заказчика. Вот реальный пример.
Сделал мой знакомый сайт товарищам в Англии. Договор, деньги перечислили на счет — все пучком. И тут его с банка срочно дергают — вы сперли деньги с чужой кредитной карты, ваш счет заморожен. В чем дело? — вроде как он украл деньги с карточки своего заказчика. Он ему срочно звонит, пишет мыло (а дело было в субботу) — нифига, тот не отвечает. Тогда он дистанционно отрубает заказчику сайт — выводти текст, что надо срочно связаться. В течении часа заказчик отреагировал. Оказалось, что его банк воспринял платеж как кражу… Разобрались — счет разблокировали — сайт восстановили — все довольны. И далее сотрудничают
0
ФОРМАЛЬНО вроде бы все ОК — я свое изделие не патентовал.

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

Кстати, так реально делают разработчики веб-сайтов. И это хорошо даже для заказчика.

Плохо, что так делают. Это некорректно по отношению к заказчику, неважно с какой целью это было сделано.

Не все заказчики жалобы и сволочи. Большинство – вполне нормальные и адекватные. Поставьте себя на их место. Вы заказали сайт (заплатили деньги), он вам нужен, он вам приносит деньги, он – часть вашего бизнеса. А потом вы узнаете, что исполнитель оставил бекдор. Он (потенциально) имел доступ к информации (в т. ч. конфиденциальной), которая храниться на вашем ресурсе, мог модифицировать или уничтожить эту информацию. Вы не знаете, пользовался ли исполнитель этим бекдором или нет. Вопрос – будете ли вы и дальше с таким исполнителем сотрудничать?
0
Плохо, что так делают. Это некорректно по отношению к заказчику, неважно с какой целью это было сделано.

Не все заказчики жалобы и сволочи. Большинство – вполне нормальные и адекватные. Поставьте себя на их место. Вы заказали сайт (заплатили деньги), он вам нужен, он вам приносит деньги, он – часть вашего бизнеса. А потом вы узнаете, что исполнитель оставил бекдор. Он (потенциально) имел доступ к информации (в т. ч. конфиденциальной), которая храниться на вашем ресурсе, мог модифицировать или уничтожить эту информацию. Вы не знаете, пользовался ли исполнитель этим бекдором или нет. Вопрос – будете ли вы и дальше с таким исполнителем сотрудничать?
Будут, ещё как будут. Потому, что бороться с этим бесполезно.
Если такие монстры, как Филипс, в своих продуктах, которые потенциально обеспечивают доступ к деньгам и персональной конфиденциальной информации, делают закладки (я о чипах RFID), то что про остальных говорить?
Про MS, я думаю, упоминать вообще нет смысла.
0
Да, бороться с «закладками» достаточно тяжело и, практически, нереально. Как правило, о таких вещах узнают по факту их срабатывания, когда уже поздно.

А что за инцидент был с Филипс?
0
Да в их чипах, которые они позиционировали то ли для паспортизации, то ли чего-то подобного, обнаружили недокументированные команды, которые фактически ставили крест на требуемом уровне надёжности. Но поскольку весь этот вопрос с беспроводным доступом на тот момент завис, история практически не вышла за рамки профессионального сектора. Т.е. массовой истерии :-) не было. Но след в И-нете остался.
0
Но след в И-нете остался.
Если не трудно, не могли бы Вы привести ссылки или хотя бы ключевые слова для поиска? Я работаю в смежной области, было бы очень интересно почитать про случившееся.
0
Увы, информации не осталось, т.к. мне было это интересно только для сведения.
Попробуйте что-нибудь типа «недокументированные команды RFID чипах Philips». Я по такому запросу сразу наткнулся на
www.t-generation.ru/015_rfid.html (ищите в тексте «Philips»)
www.habarok.info/chips.shtm (ищите в тексте «недокументированные», но здесь совсем краем упоминается)
0
Спасибо!
0
Будут, ещё как будут. Потому, что бороться с этим бесполезно.
И поэтому разработку реально надежных систем серьезные структуры все-таки делают своими руками. Я думаю, что в NASA компьютеры, которые задействованы в управлении полетами, стоит явно не Windows и не Linux, а что-то свое. И доступа в Интернет у них однозначно нет. Или я неправ?
0
Не знаю как на десктопах, но ели говорить о встраиваемых ОС реального времени, то NASA использует множество сторонних ОС в разных проектах (RTEMS, vxWorks, QNX).

И поэтому разработку реально надежных систем серьезные структуры все-таки делают своими руками

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

«Реально надежные системы», в большинстве, создаются коммерческими компаниями (иногда для такой деятельности нужна специальная лицензия). В процессе разработки используются специальные методики управления проектом. После этого софт (подаваемый в виде исходных кодов) проходит несколько проверок (заказчик для этого, обычно, привлекает независимую государственную или коммерческую организацию).

Но, естественно, все эти меры не дают 100% гарантии отсутствия «закладок».
0
После этого софт (подаваемый в виде исходных кодов) проходит несколько проверок (заказчик для этого, обычно, привлекает независимую государственную или коммерческую организацию)
О, вот оно! Все равно потом оно обязательно проверяется!
Но даже и это не спасает! Где-то в И-нете читал про такой доклад. Допустим, вы компилируете десятки раз перепроверенный код Linux-а. И сердце защиты — функцию «login». Компилятор же, видя эту функцию, добавляет свой код ее реализации… Все — ни отследить, ни даже заподозрить нереально!
Так что 100% защиты все равно нету.
0
Да, эллиптические кривые, НОД и прочее тут не используется, но это квалифицированный труд, для которого нужны серьезные знания!
Только ни разу не математические. Взломщик — это специалист по созданию и обходу систем защиты. Криптоаналитику (на уровне применения уже существующих наработок) он применить может, но вероятней — пойдет другим путем.
0
Начинается все с термина «криптоаналитик»...
Я понял что именно Вас смущает. Давайте я уберу этот термин, заменю просто на аналитика. Идет?
0
А почему, собственно, копировать будет именно заказчик разработки (производитель)? При нормальных отношениях такого быть не может.
Другое дело — конкуренты.
0
Ну… у меня было именно так.
Хорошо, согласен, подправлю по тексту
0
По всякому может быть.
Заказчик разработки имеет интерес копировать, когда он платит не за разработку, за конечное изделие. Т.е. когда он получает не документацию, а «железяку». (и платит, соответственно, за каждую единицу)
0
Если бы, например я, узнал что в сделанном по моему заказу сайте заложена функциональность по удаленному контролю за сайтом (со стороны разработчика) – я бы в жизни больше с таким разработчиком не работал.
Ну вообще, по хорошему, после полной оплаты заказчику следует отдать ключи от защиты (скажем, в виде удаляющего ее патча).
0
Ели такая процедура «передачи ключей» заранее оговорена – это нормально. Практика демоверсий и триалов достаточно распространена.

А если, в тайне от меня, создается бекдор –это другое дело. Обнаружение такой скрытой функциональности компрометирует разработчика. Да, возможно это единственный бекдор, и разработчик честно удалит его после релиза. А возможно не единственный, возможно не удалит… Я бы, лично, не стал играть с в такую «лотерею» с исполнителем.
0
после полной оплаты заказчику следует отдать ключи от защиты (скажем, в виде удаляющего ее патча)
А Вы уверены, что Вам дали ключ от всей защиты? Или от самой-самой последней защиты? Тема проблематичная и философская…
0
Нет. Но в полном отсутствии закладок без полной проверки все равно уверенным быть нельзя. Так что это скорее к разработчику относится, получил оплату — убей защиту.
0
В связи с Вашим комментарием первым разделом в статье поместил размышления на тему полезности защиты и опрос от Alfa
Вот DIHALT’овский метод перерезания дорожек – очень простой и эффективный способ
Ну-ну, и Вы после этого будете гарантировать работоспособность устройства? А если по дороге заказчик деранул пару соседних дорожек? Или полез туда с включенным питанием? Или резал болгаркой7 Или… Или… Слишком много «или». И слишком много возможных последствий. Недаром уже одно вскрытие корпуса многими считается как повод отказа от гарантийного обслуживания. Я бы такой метод доверил только тому, в чьей квалификации я уверен.
+1
Ну-ну, и Вы после этого будете гарантировать работоспособность устройства?

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

Касательно «гарантировать работоспособность» — это отдельная тема. Очень редко производитель берет на себя риски связанные с гарантией работоспособности, наоборот, большинство производителей явно прописывает в договоре/лицензии отказ от ответственности. В любом случае, этот момент регулируется договором.
0
Предпочитаю предпрошитый бутлоадер с блочным алгоритмом шифрования типа XTEA/RTEA. Из преимуществ — можно использовать обычный hex-формат и, соответственно, стандартные программаторы (как пример, испольование бутлоадером открытого протокола программирования — для AVR это STK500v2, в общем случае — тупо передача hex). Конечно шифровалки-дешифровалки на компе нужны, но в таком случае только разработчику. Более сложные/ресурсоемкие алгоритмы не вижу смысла применять — во-вторых особисты могут найти «криптографическое оборудование» и обеспечить кучку неприятностей, а во-первых достаточно отпугнуть возможных ломателей наличием правильной защиты. Ломать далее — опять же вопрос времени и денег.
0
>>Предпочитаю предпрошитый бутлоадер с блочным алгоритмом шифрования типа XTEA/RTEA.
Интересно насколько трудно взломать TEA?
0
0
Такое впечатление, что и вправду хороший метод! Особенно если в сочетании. Допустим, первый раз закрываем этим методом сообщение, второй раз — Виженером с коротким, повторяющимся ключом (но не кратным 32 битам!). Оба метода простые в реализации (что важно для bootloader), требования к длине ключа тоже не очень большие.
0
>>второй раз — Виженером с коротким
Не нужен никакой Виженер, имхо.
TEA+CBC+что-нибудь наподобие перепутывания страниц flash-а или добавления random-а в bin-прошивку уже будет достаточно.
0
А Вы могли бы привести пример кода для CBC? Или достаточно подробного описания? В Википедии очень хорошо описан TEA, а вот CBC слабее…
0
Вот пример кодировщика

using System;


namespace RTEA_256bit {
	class RTEACodingException: Exception {

		public RTEACodingException (string s) : base(s) {
		}
	}
	class RTEACoder {
		static void InputDataOk(byte[] in_data, uint[] key, bool crypt) {
			if ((in_data.Length%8)!=0)
				throw new RTEACodingException("Длина массива данных не кратна 8.");
			if (in_data.Length==0)
				throw new RTEACodingException("Длина массива данных равна 0.");
			if (key.Length!=8)
				throw new RTEACodingException("Длина ключа не равна 8.");
			int not_zero=0;
			int i;
			for (i=0;i<8;i++)
				if (key[i]!=0)
					not_zero++;
			if (crypt  && not_zero!=8)
				throw new RTEACodingException("Ключ c нулевыми значениями.");
			int max_equal=0, max_equal_tmp;
			int k;
			for (i=0; i<8; i++) {
				max_equal_tmp=0;
				for (k=0; k<8; k++) {
					if (k!=i && key[k]==key[i])
						max_equal_tmp++;
				}
				if (max_equal_tmp>max_equal)
					max_equal=max_equal_tmp;
			}
			if (crypt && max_equal>0)
				throw new RTEACodingException("Ключ c повторяющимися значениями.");
		}
		static uint FromByteToUInt(byte [] inpbt, int index) {
			uint result;
			result=(uint)(inpbt[index]+
				(inpbt[index+1]<<8)+
				(inpbt[index+2]<<16)+
				(inpbt[index+3]<<24));
			return result;
		}
		static uint [] ConvertFromByteTOUInt(byte [] inpbt) {
			uint[] tmp=new uint[inpbt.Length/4];
			int i;
			for (i=0; i<tmp.Length; i++) {
				tmp[i]=FromByteToUInt(inpbt, i*4);
			}


			return tmp;
		}
		static public byte [] Crypt(byte[] in_data, uint [] key, bool cbc_mode) {
			byte []output;

			InputDataOk(in_data, key, true);

			int i;
			

			uint[] temp=ConvertFromByteTOUInt(in_data);
			
			uint[] prev=new uint[2];
			prev[0]=0;
			prev[1]=0;
			for (i=0; i<temp.Length; i+=2) {
				uint a, b, r;
				a=temp[i];
				b=temp[i+1];
				if (i>0 && cbc_mode) {
					a^=prev[0];
					b^=prev[1];
				}
				for (r=0;r<64;r++) {
					b+=a+((a<<6)^(a>>8))+ (key[r%8]+r);
					r++;
					a+=b+((b<<6)^(b>>8))+ (key[r%8]+r);
				}
				temp[i]=a;
				temp[i+1]=b;
				prev[0]=a;
				prev[1]=b;
			}

			output=ConvertFromUIntToByte(temp);
			return output;
		}

		private static byte [] ConvertFromUIntToByte(uint[] temp) {
			byte [] output=new byte[temp.Length*4];
			uint i;
			for (i=0;i<temp.Length;i++) {
				output[i*4+0]=(byte)((temp[i]&0xFF)>>0);
				output[i*4+1]=(byte)((temp[i]&0xFF00)>>8);
				output[i*4+2]=(byte)((temp[i]&0xFF0000)>>16);
				output[i*4+3]=(byte)((temp[i]&0xFF000000)>>24);
			}
			return output;
		}
		static public byte [] Encrypt(byte[] in_data, uint [] key, bool cbc_mode) {
			byte []output;

			InputDataOk(in_data, key, true);

			int i;
			

			uint[] temp=ConvertFromByteTOUInt(in_data);
			
			uint[] prev=new uint[2];
			prev[0]=0;
			prev[1]=0;
			for (i=0; i<temp.Length; i+=2) {
				uint a, b, r;
				a=temp[i];
				b=temp[i+1];
				for (r=63;r>=0 && r<100;r--) {
					a-=b+((b<<6)^(b>>8))+ (key[r%8]+r);
					r--;
					b-=a+((a<<6)^(a>>8))+ (key[r%8]+r);

				}
				if (cbc_mode && i>0) {
					a^=prev[0];
					b^=prev[1];
				}
				prev[0]=temp[i];
				prev[1]=temp[i+1];
				temp[i]=a;
				temp[i+1]=b;
			}
			output=ConvertFromUIntToByte(temp);
			return output;

		}
	}
}

0
Э-э… Спасибо за TEA.
А интересует именно CBC :-)…
0
CBC — это не отдельный алгоритм, это cipher-block chaining – режим шифрования со сцеплением блоков.
0
Вы можете использовать этот режим с любым блочным шифром (в т. ч. и с TEA)
0
Смотрите функцию
public byte [] Crypt(byte[] in_data, uint [] key, bool cbc_mode)
Взависимости от cbc_mode работает либо с CBC либо без.
0
Alfa предложил пару опросов, я еще свой опрос добавил. Проголосуйте, думаю, будет интересно узнать результаты!
-1
  • avatar
  • PICC
  • 26 октября 2012, 15:11
Там ссылочки вначале статьи
-1
Э-э-э. Я смотрю, тут у многих наличествует путаница в самом понятии «заказ на разработку».

Заказ может быть в 2 вариантах:
1. Заказ на работу. Т.е. вам заказывают провести некоторые работы, в результате чего что-то получится. В нашем случае какое-то устройство. Иными словами, вам заказывают НИОКР. И вам платят именно за них. За работу. По сложившейся мировой практике результаты такой работы (оплаченной вам работы) принадлежат заказчику. Вы просто исполнитель работы, как наёмный работник на фирме. Так что ещё раз — договор, договор и ещё раз договор, как практически так же говорил дедушка Ленин. :-)
Ещё раз: по сложившейся практике в таком случае заказчику передаётся вся документация. Вполне справедливо, вам не кажется?
2. Заказ на результат. Вам заказывают что-то. Как вы сделаете это что-то — заказчику по барабану. Потому что в таких случаях оговаривается цена конечного изделия и сколько вы потратите на разработку — ваши проблемы. Но и никаких претензий на документацию от заказчика быть не может. Все права принадлежат вам. Это сложившаяся мировая практика. Т.е. традиция. Насколько эта традиция будет иметь отношение к вам… да, вы угадали, :-) зависит от договора.
Этот вариант можно также назвать «заказ на товар». Т.е. вы продаёте не работу, а товар. Как вы понимаете, он используется в основном тогда, когда продаётся уже готовая разработка, или нужна небольшая доработка, вполне оценимая (и небольшая) по затратам, или стоимость готовых изделий превышает стоимость разработки, или разработка перспективная и позволит в дальнейшем получить большие деньги с других клиентов.
Но всегда возможны варианты. Как пример можно привести фирму MicroSoft, которая не покупает программные продукты (для своего использования; да-да, они не только пишут программы, но и, бывает, покупают — не всё можно сделать самим) других фирм, если те не соглашаются дать вместе с лицензией на программу исходные коды этой программы. Хорошо, суки, знают, что такое бэкдор. :-)
Существуют также всякие промежуточные варианты типа конкретному заказчику документацию без права распространения, продажи и производства на сторону, а у вас остаются все права и др.

Теперь о том, чего же хочется. А хочется, естественно, оплату получить как за первое, а права — по второму варианту. :-) И насколько это у вас получится… браво! вторая угаданная буква! :-) написано в договоре.

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

Мне кажется, стоит об этом сказать в начале статьи, а то, я чуствую, народ о разном иногда спорит.
+2
  • avatar
  • Alfa
  • 26 октября 2012, 18:50
По поводу патентования.
Патент — защита от посторонних. С которыми вы не связаны договорными отношениями.
С заказчиком же, как выше говорил коллега e_mc2 , ваши отношения регулируются договором и всё можно прописать там.
+2
Вы бы написали развернутую статью по данному вопросу (юридическому оформлению отношений). ИМХО, такая статья (на уровне ликбеза) была бы очень полезна для членов сообщества. В свою очередь, готов оказать посильную помощь (некие теоретический знания/практический опыт у меня есть, но я не юрист).
+1
Поддерживаю! Тоже очень полезно будет начинающему! Туда можно типовой договор поместить с подробным описанием.
0
Увы, я тоже не юрист. Но в планы такую статью поставлю. Но это будет очень не скоро.
0
Мне кажется, стоит об этом сказать в начале статьи, а то, я чуствую, народ о разном иногда спорит.
Добавил, спасибо! Только изменил подчеркивания на курсив — оно более соответствует дизайну статьи.
Да-а, в данной статье лично моего становится все меньше :-)…
0
Это не страшно. Коллективное написание обычно даёт ещё лучший результат.
0
Просто прикольно :-). Я сравниваю 1) написание статьи в научный журнал в аспирантуре и 2) свободный полет мысли тут. В 1) нужно все самому вылизывать, отшлифовывать — и, хоть ты тресни, что-нибудь забудется. А в 2) тебе укажут и подправят. Красота!
0
Ну, дык, надо пользоваться этим. :-)
Сначала сюда… затем оформляем и в научный журнал. :-) И указываем в качестве соавторов посетителей сайта we.easyelectronics.ru
:-)
+1
Процитирую Ваш отзыв моему научному руководителю :-)… Боюсь, правда, список соавторов будет уж слишком большим
0
В бутлоадер записываем миниядро forth. Размер ядра вряд ли будет больше 1 кб. Саму программу пишем на forth. А теперь нехай дизассемблируют :). Forth сам по себе тяжело дается отладке, а учитывая, что основная часть словаря в бутлоадере, задача восстановления логики работы программы становится сильно затруднена.
0
  • avatar
  • aen
  • 27 октября 2012, 00:06
задача восстановления логики работы программы становится сильно затруднена
Задача ее написания — тоже. Ну и медленно.
0
Не думаю, что сильно медленно. forth имеет не такие уж большие накладные расходы.
Тем более, что критические части можно на ассемблере написать или на тех же сях.
0
Любой интерпретатор — это минус порядок к производительности. Хотя да, если критичные части представить в виде нативных функций, а на форте делать только верхний уровень и прочие некритичные части — то пойдет. Но неудобство разработки никуда не денется, да и как только формат кода этой форт-машины станет известен реверсеру, его жизнь только упростится.
0
Любой интерпретатор — это минус порядок к производительности.
В лучшем случае, разумеется.
0
Тогда уж лучше на PICBASIC
0
А что это даст? Он вроде не интерпретатор.
0
Не, это скорее была ирония, чем реальный совет :-)…
0
Усложнение ксорки можно сделать если в полученных МК байтах будут содержатся новые ключи. Т.е. ключи для ксорки содержатся в самом файле, но об этом знает только бутлоадер. Алгоритм примерно такой:
1. Зашифровано ключом «123» первые 50 байт.
2. Через 50 байт будет новый ключ, который содержится прям в коде и бутлоадер считывает его из файла
3. Через еще 134 байта опять будет новый ключ, который также содержится в файле. И т.д.
Можно, чтобы не иметь фиксированную длину отрезков кода, придумать какую-нибудь последовательность байт для идентификации ключа ;) Тогда ваш бутлоадер будет универсальным ;)
0
Хранить ключ вместе с зашифрованными данными?! Не лучшая идея.
+1
почему? это бредовая идея если сделать стандарт. Но об этот будете знать только вы и ваш бутлоадер.
0
Потому что это типичный образец security through obscurity.
0
Не делать один ключ — и все. Тогда провести аналогию даже между несколькими вариантами прошивки будет невозможно. спи снифер тоже не даст результатов, т.к. все будет происходить внутри МК.
0
Ну, в общем, нестандартный (и оригинальный) подход рулит! Правда, иногда потом нужно проверять уровень «бредовости» своей идеи — может, есть простой обходной маневр для вашей супер идеи?..
0
Чем бредовее идея — тем лучше ;)
0
Так-то оно та-ак, но иногда бывает, что идея выглядит супер-пупер-непробиваемо, а на практике упускается какая-то мелочь в самом начале, основании — и все здание рушится. Я об этом
0
Уж ели Вам так хочется придумать «Собственный Секретный Алгоритм Шифрования» — это ваше право. Современная криптография защиту, основанную на незнании алгоритма, всерьёз не рассматривает.
Придумать новый, стойкий к современным методам крптоанализа алгоритм, поверьте, очень непросто.

Предложенный вами алгоритм можно отнести к маскированию информации. Можно поступить проще, например, проксорить прошивку саму с собой, сдвинутой на определенное кол-во бит. Это тоже маскирование.

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

Если играть в «рыцарей плаща и кинжала» — и предположить, что все вокруг враги, а международные секретные организации всячески хотят получить нашу прошивку, и готовы тратить на это кучу усилий – в таком случае нужна «научная» криптография. Стандартные криптоалгоритмы используются не просто так – они изучены множеством криптоаналитиков, даже потенциальные уязвимости известны. Можно сказать, что современный известный криптоалгоритм «гарантирует» некий уровень безопасности (который можно выразить в денежных и временных затратах на взлом).

Ну, это, конечно если Вы не верите во всемирный заговор между «тайным правительством» (которое стандартизировало уязвимый алгоритм) и независимыми экспертами (которые находятся в сговоре и молчат об уязвимости) :)

Но, так как по затраты реализации «маскирования» и «нормального алгоритма шифрования» сопоставимы – я бы рекомендовал Вам, все же, использовать стандартные алгоритмы, ели Вам действительно нужна криптозащита информации.
+1
У многих в комментариях возникло бурное несогласие с темой защиты средствами «эксплоита» — встроенного ограничителя функциональности. Я эту тему описал в новом разделе статьи «Этичность защиты методом ограничения функциональности» (в самом начале статьи я дал оглавление, т. к. уже реально много подразделов) — почитайте, выскажите ваше мнение.
0
  • avatar
  • PICC
  • 28 октября 2012, 15:31
Вот прямая ссылка на новый раздел
0
Ну, у товарища plcist , похоже, какие-то личные обиды, видать накипело :)

По сути, повторюсь, ИМХО, наиболее эффективная защита от «кидалова» — грамотный выбор заказчика и грамотно построенные (в т. ч. официально оформленные) взаимоотношения.

Касательно этичности – я считаю, что этично применять любую защиту (в разумных приделах) ели это заранее оговорено с заказчиком.

Другое дело, что Вы можете отпугнуть заказчика излишне переусердствовав со «страховкой» себя любимого :). Заказчик (нормальный) так-же не уверен в новом исполнителе, как и Вы в новом заказчике. А его риски, зачастую больше чем риски исполнителя.
0
Вы можете отпугнуть заказчика излишне переусердствовав со «страховкой» себя любимого :)
Если у нас взаимоотношения нормальные — он вообще не узнает о факте защиты! Она будет снята тихо и незаметно для него, без последствий.
0
Защиту «втихаря» я этичной не считаю. И это опасно (вдруг вы не сможете удаленно снять защиту) и она сработает? Вы выслали «обезвреженную» прошивку, а заказчик решит не спешить обновляться, он же не знает, что в старой версии есть «закладка».

Но это всего лишь мое мнение.
0
Хорошо, тогда, наверное, этично будет сделать так: залить «обрезанную» прошивку, о чем честно и предупредить заказчика. По факту оплаты залить «полноценную». Но а если тех. отдел заказчика скопирует мою плату и везде будет заливать полноценную прошивку? (само собой, в договоре оговаривается момент, что заказчик не имеет права повторять мою плату и мою прошивку самостоятельно)
0
Но а если тех. отдел заказчика скопирует мою плату и везде будет заливать полноценную прошивку? (само собой, в договоре оговаривается момент, что заказчик не имеет права повторять мою плату и мою прошивку самостоятельно)

ИМХО – договор это достаточно надежная и обоюдная зашита от «подставы» в отношениях с заказчиком.

Если заказчик насколько невменяем, что ради копирования устройств пойдёт на нарушение договора (по сути, на нарушение закона), то можно развить идею и дальше, придут к вам «представитель службы безопасности заказчика» и «убедят» Вас отдать прошивку вместе с исходниками. От этого тоже будем защищаться, сделаем «педаль мертвеца»? Если Вы настолько не уверенны в конкретном заказчике, может есть смысл отказаться от сотрудничества?

З.Ы. Если не секрет, каково рода устройства Вы разрабатываете, что вопрос копирования стоит настолько остро?
0
Если не секрет, каково рода устройства Вы разрабатываете, что вопрос копирования стоит настолько остро?
Смотри Профиль — устройства для знакомых чайников :(,
у которых есть непорядочные хитроковарные друзья не чайники :), способные растиражировать поделку.
we.easyelectronics.ru/my/PICC/
Обещал я недавно моему знакомому — хорошему электрику и чайнику в электронике — сделать небольшое устройство с парочкой АЦП и счетчиком импульсов…
Обещал я недавно моему знакомому — хорошему электрику и чайнику в электронике — сделать небольшое устройство в автомобиль...
Только не надо интересоваться где конкретно я работаю и что конкретно я сделал — я не использую Тырнет для саморекламы и не надеюсь найти Работодателя таким образом.
Каждый ведь может написать про себя
«
Я артист больших и малых театров.
А фамилия моя слишком известная, чтобы я вам её называл
отчего имеет воровское прозвище «Солист».
Из профессиональных качеств можно отметить мастерство при работе с отмычкой и взломе замков различной сложности.
Несмотря на то что живёт он со средств полученных преступным путём,
и государственный закон для него не указ,
тем не менее в фильме он настоящий патриот, и твёрдо стоит за территориальную целостность своей Родины
(в противоположность оригинальной пьесе, где Кемскую волость именно он всё-таки отдал шведам).
-2
И за что меня так невзлюбили — не пойму. То ли на больную мозоль кому-то наступил, то ли совесть их обидел…
Ну а «чайнику» — да, оптимизируем мы его автомобиль сообща, интересно ж ведь :-). Жить не только ради денег надо — вот и делаем всякие красивые светодиодные табло и регуляторы.
0
А чего Вы ваш логин plcist поменяли на новый, зарегистрированный только сегодня, freeon ?.. Ваши комментарии и рейтинг минусуют — это обидно, поэтому хочется сменить логин и начать по-новому. Но ведь и минусуют-то оправданно… Можно ж без ругани отвечать, нормальным русским языком. И честно признаться в какой сфере Вы работаете, а то Ваши комментарии соответствуют уровню базарной ругани…
В общем, предлагаю прекратить троллинг и в личной переписке (зачем это видеть посторонним?) высказать мне все претензии и послать меня куда Вам хочется :-).
Извините, послал бы это сообщение почтой, но Вы ее (в личине plcist ) не смотрите.
Ну и — да, особых навыков для отслеживания создаваемых с определенной целью логинов не требуется — достаточно публичной информации тут (где отзывы, дата создания, последнего посещения и т. п.). Так что плодить логины смысла нет.
0
PICC: Для крупных гос. заказчиков (трёхголовая Г-гадина!!!) делал (и делаю) промышленное оборудование.
Стоимость изделий в данной области промышленности (не могу назвать конкретно, уж извините) весьма высока.
Закладывал, закладываю и буду закладывать закладки-вымогатели...
Раньше этим отличались макаронники и китайцы — теперь и псевдославане стали друг другу грабли подкладывать — хорошо, когда быстро находятся умные Специалисты, которые быстро могут распознать подвох, а когда таких рядом нет, то работяги вместо зарплаты могут и деревянный макинтош получить…
Что таких как ты публично нагибают?
Надоели — то тут, то там подстава и за вами потом разргребай и устраняй.
Сами ни чего не знают, а делают криптоанальный анализ
Реально не веришь, что рыжие пройдохи Чубайсы вызывают у разных людей одинаковую реакцию?
forum.easyelectronics.ru/viewtopic.php?f=8&p=223149#p223149
Я верблюд, виноват и оправдываюсь :)
Зарегистрирован: 26 дек 2011, 18:08
-3
Дальнейшего смысла продолжения диалога с Вами не вижу.
0
Да уж не о чем говорить — почти 50 лет пацану, а он всё в закладочки играет с солидными клиентами.
А потом народ удивляется чего это шахты на воздух взлетают, наверное наркоманы на датчик ветошь повесили — а вот и нет = там жлобские закладочки сработали :(
Разработка модуля, предназначенного для измерения и автоматического непрерывного контроля довзрывоопасных концентраций горючих газов и паров в воздухе с использованием последовательного интерфейса.
Если бы это касалось поделок для хобби, то никто бы и не выступал против — но когда речь заходит о промышленности, то хотелось бы не подпускать близко таких пройдох.
-1
Для крупных гос. заказчиков делал (и делаю) промышленное оборудование. Стоимость изделий в данной области промышленности (не могу назвать конкретно, уж извините) весьма высока. А у заказчиков есть отделы ремонта, которые и сами чего-то пытаются делать. До недавних пор для них SMD это было ужас. Сейчас ситуация меняется.

Да, в договоре как-то не указывали мы тему, что нельзя копировать — даже и в мыслях не было… Будем указывать, значит
0
Для крупных гос. заказчиков

Тем более — договор рулит. Я не думаю, что крупный гос. заказчик пойдет на нарушение договора.

Да, в договоре как-то не указывали мы тему, что нельзя копировать — даже и в мыслях не было… Будем указывать, значит

Обязательно указывайте, на каких условиях вы переедете заказчику результаты работ и порядок сдачи/приема работ.
+1
Да, спасибо! Очень ценная мысль, которую я вынес отсюда :-)
0
А что если обновления выпускать в виде «патчей» в виде XOR поверх предыдущей версии… Можно даже автоматом детектить версию на контроллере и автоматом собирать патч именно для той, что установлена (переXORиванием всех промежуточных патчей). Неиспользуемое пространство флеша должно быть заранее заполнено рандомом. Разумеется CRC/Hash обязательны (в идеале считать их при каждом запуске)
Эдакая разновидность «лёгкой криптографии»… полагаю аналитик возможно будет способен восстановить лишь отдельные фрагменты (ещё можно поиграться с компилятором, дабы прошивки побайтно отличались друг от друга посильнее)
из минусов видится:
— невозможность оживить девайс при каком либо повреждении прошивки (хотя кому-то может это и плюс)
— первоначальная прошивка должна быть проведена разработчиком в безопасном окружении (хотя бутлоадер всё равно так нужно заливать)
0
В общем вариант похож на описанный в статье. Только ключ, в данном случае, равен длине всей прошивки.взломан может быть так же, как было описано в ветке комментариев. Посложнее чутка, но всё же.
0
из плюсов — крайняя простота реализации и нетребовательность к ресурсам
0
Слишком как-то оно сложно в реализации… Месяц делаю схему-железяку-программу и еще месяц отрабатываю вопросы прошивки?
0
Ну тут несложный бутлоадер и апдейты в виде патчей, а не бинарников. Всяко проще криптографии…
0
У stm32 есть уникальный код кристалла. Можно проверять что прошивка работает именно на том кристалле, для которого создавалась.
+1
  • avatar
  • OlegG
  • 30 октября 2012, 12:28
Вот это класс, не знал! Но не у всех кристаллов такое есть…
0
У стм нет только в дешёвых версиях 0xx. версии 0xx при этом имеют мало циклов перезаписи, не пообновляешься особо. Так что можно смело пользовать.
0
Не знаю, предлагали или нет…
— Предварительная прошивка (перед основной). Настраивает периферию, записывает константы и т.п., без которого основная работать не будет.
0
Вкатываем в качестве основной прошивки дампер флеша, получаем на руки полную прошивку. Чтобы это пофиксить — придем в итоге к бутлоадеру с шифрованием и подписью прошивки.
0
Вообще-то далеко не для всякого контроллера дампер флеша можно сделать. Тут неявно речь идёт об AVR, но не ими же едиными. :) Есть контроллеры с посекторной защитой от считывания — команды, аналогичные LPM, в защищённых секторах просто не работают, возвращают 0 или 0xFF. А стирание/запись работает. Минус, конечно — невозможность верификации обновлённой прощивки.
0
Такая защита добавляет проблем — затрудняет подтягивание констант из флеша, например. Хотя да, там где такое есть — с подсадными утками сложнее. На том же AVR можно защитить секцию бутлоадера от считывания, что тоже осложняет жизнь в плане реверсинга.
0
То есть к SecureBoot, ага :)
Только реализованной немного по-другому и для немного других целей, а на ПК MS SecureBoot — злейшее зло.
0
Да оно и тут зло…
0
Кстати, есть еще один момент, о котором я хотел бы напомнить – во многих странах (на пост-советском пространстве) разработка криптографических систем является лицензируемым видом деятельности. ИМХО – это бред и пережитки «холодной войны».
Но, например, в РФ
разработка, производство шифровальных (криптографических) средств, защищенных с использованием шифровальных (криптографических) средств информационных систем, телекоммуникационных систем;
является лицензируемым видом деятельности.
+1
  • avatar
  • e_mc2
  • 30 октября 2012, 22:24
Угу, есть такое дело. Точно не помню, при применение алгоритма типа XOR/цезарь допустимо отсутствие лицензии. При ключе до ~64 байт (или бит, не помню) доступно отсутствие лицензии на пользование.
Последний момент особенно доставляет. Вы не имеете права пользоваться средствами шифрования в личных целях, если шифрование устойчиво к влому (или что то такое).
P.S.: точно не помню, давно это было. Где-то я уже это писал.
0
Еще надо доказать, что данный алгоритм использует криптографию. Вот если вы в договоре явно прописываете использование криптографических алгоритмов — тогда да, случай как раз по закону. А в противном случае…
Тем более, что вы нигде и не афишируете используемые алгоритмы.
Длина ключа — тоже понятие крайне растяжимое. Ключ может быть реализован не как линейный массив в памяти. А если ключом будет ВСЯ прошивка (как кто-то тут предлагал)? Уже и не понять тогда — то ли это сообщение, то ли ключ.
Но в целом идея о том, что государству не нужны невзламываемые системы — это да, не только в Союзе, но и в Америке есть такой прикол.
0
>>если ключом будет ВСЯ прошивка
Это новое слово в науке и технике…
В AES используется до 256 бит — хватает, но нет кулибиным подавай ключ на всю прошивку — ключ на десятки кБит. Бредовая идея…
0
Этот «бред» вполне себе работает много лет… Несмотря на уязвимость — имея хоть одну прошивку, поддающуюся такому апдейту, можно раскрутить все остальные. Но ничто ж не мешает устроить «разрыв». Не опубликовать апдейт т.е.
0
Мало ли какой бред работает… вот его и не трогают.
Но зачем его дальше закладывать в новые устройства? Когда шифрование вполне по силам МК, начиная с килобайт 8 флеша.
0
Я просто хотел напомнить, что в некоторых странах такая норма есть. Хотя, я не понимаю, как ее можно всерьёз воспринимать в современном мире (когда криптография используется повсеместно).

Но в целом идея о том, что государству не нужны невзламываемые системы

Не взламываемые системы существуют, хочет того государство или нет. Например, «одноразовый блокнот шифрования» — абсолютный, не взламываемый алгоритм шифрования. И он настолько прост в использовании, что ним может пользоваться любой школьник. Именно по этому, я не понимаю, почему государство пытается контролировать данную сферу, ограничивать импорт/экспорт средств шифрования и т. д.
0
В том-то и дело, что пользоваться может… Но за это дело теоретически его могут посадить. :-)
0
Нет, использование не лицензируемо. Пользуйтесь, сколько хотите.
Лицензированию подлежит «разработка, производство».
0
«Борьба с террористами» очевидно же. Что бы не могли обмениваться сообщениями, которое правительство не может прочитать.
0
Слов много, информации о заците очень мало. Защищаясь из С прогаммы компилятор порождает одни и теже блоки програмного кода на ассемблере. Легко найти и вырезать, в упертом случае переназначить на требуемую константу.Автору надо подучиться.
-1
А Вы статью читали? Там есть идея шифровки «одних и тех же блоков программного кода на ассемблере». И, изменяя их, Вы потом не зальете код назад, т. к. не пропустит CRC по всему коду программы.
0
Спасибо за статью, подняли интересную тему! Хотелось бы найти еще больше информации по хардварной защите от реинженеринга — все то, что не относится к шифровке кода микросхемы и не касается интерфейсов обмена данными (может кто меня ткнет носом?)
0
Настоящая, работающая защита от взлома может быть реализована только на ассемблере. И то не стандартными средсвами. В качестве такой защиты применяют или неописанные команды (Z80) или косвенные переходы по вычисленным адресам. Главное написание защиты должно быть не стандартным. Применяя же С вы всегда порождаете стандартные блоки кода на ассемблере.
0
Ну-ну.
0
ну ну
Вы то хоть статью читали. причем тут асемблер или С. В статье идеология описана, а уж чем Вы ее реализуете это уже другой вопрос.
Какая разница что С порождает стандартные блоки кода? Вам то не дано это прочесть в бутлоадере.
0
ответ был адресован для anakost

Кстати по поводу защиты. а есть же к примеру у атмела кристалы где плм+авр в одном чипе. Вот еще инструмент для повышения надежности от взлома.
0
Статья вызывает радикулит=)
Главное, остался не затронутым один важный вопрос, а насколько сильно стоит защищать собственное устройство.
Я пришел к выводу, что лучше всего защищать так, чтобы реверсинг обошелся дороже, чем создание аналогичного устройства с нуля. И чем раньше аналитик поймет, что овчинка выделки не стоит, тем лучше. Удачи.
0
все верно, реверс должен быть дороже, но один момент. намного дороже… И только в комплексе с другими способами, как мне кажется в последнее время, самый лучший вариант с риском вывода устройства из рабочего состояния в случае неуплаты. Я раньше был противником такого, щас наоборот приветствую. Только при одном условии — заказчик должен быть оповещён, что если на заплатит через к примеру 300 часов работы устройства — сдохнет устройство. И без разговора о дальнейшем его восстановлении, не заплатит пусть пинает на свою жабу. Если заплатит, тут же получает инструкции к разлочиванию. Мараль проста, если я сделал девайс и за него не заплатили, то девайс ещё мой(в любом колличестве), просто ктото его взял поиграться(можно еще набраться наглости и обвинить в воровстве. но то уже от морали людей зависит), а с своим девайсом что хочу то и делаю, хотят купить пусть дают деньги, когда станет их ни че не сгорит и будут наслаждаться. Ведь нужно помнить, что мы разработчики, а не благотворительная компания.
0
можно иначе сказать. пока не оплатили девайс полностью — это макет, прототип, опытный образец, называйте как хотите. а раз так, в нем могут быть ошибки, не до конца вычищенная отладка, всякие счетчики профилирования и производительности…
0
А разве шпиён не догадаесться склонировать и еепромку? Или вопрос только в спирании файла прошивки, без обладания девайсом?
0
а как шпиён получит прошивку? если чип закрытый и чип из новых?
0
При наличии бинарной прошивки такие хитрости ловятся в дебаггере, а то и дизассемблере за полчаса. Чтобы хоть как-то защитить таким способом — приходится очень сильно извращаться и прятать код защиты.
0
  • avatar
  • Vga
  • 19 февраля 2013, 20:27
Спасибо за статью :)
Кстати, а как STM8 залочить, чтобы невозоможно было по SWIM получить FLASH/EEPROM?
0
доки почитать пробовали? говорят, помогает.
PM0047 так и называется «STM8 Flash programming»
st.com опять дурит, потому линк из гугла.
+1
А, спасибо большое)Я просто в Refernce Manual'е искал. Никак не привыкну, что инфа по STM8 по разным докам раскидана)
0
было б сказка если только на них. на 32е также… так что, привыкайте, пригодится :)
0
открою большой секрет: я даже в доках не рылся, а просто спросил у гугла «stm8 protect»
+1
Ну, в любом случае, еще раз спасибо)
0
на здоровье. :)
0
Да вроде привыкаю :)
Вообще, в этом даже свои плюсы есть — одна и та же информация не дублируется в доке на каждый камень, но это больше для печати актуально, как мне кажется)

До АРМов не дорос пока)Из применений в моих реалиях-только звуковуха внешняя. По идее, нужен какой-нибудь камень с аппаратным USB и внешний АЦП, типа такого:
www.ti.com/lit/ds/symlink/ads1271.pdf
0
> Вообще, в этом даже свои плюсы есть — одна и та же информация не дублируется в доке
> на каждый камень, но это больше для печати актуально, как мне кажется)

А ещё более актуально это когда надо перенести проект с одного МК на другой в пределах одного семейства/серии. Когда для каждого МК своя простыня текста, надо вычитывать всю эту повторяющуюся информацию, что б удостовериться, что не добавили/убавили критичный функционал или изменили поведение. И вот если текст совпадает на 90%, то очень сложно увидеть изменения.
0
Ну, и это тоже конечно)

Я вообще люблю весь «завязаный» на конкретный камень код в отдельную либо выносить, своего рода HAL. Родная либа от ST не нравиццо, сижу, пилю потихоньку свой велосипед :)
0
Опечатка)
*в отдельную либу
0
Немного критики.
Если вам заплатили за разработку КД (как за НИОКР) то вы просто обязаны сдать исходный код как часть КД. всё. точка.

Насчёт отключаемого функционала — был у нас (ВПК кстати) один пидорас, который закладывал счётчик, а потом катался на объекты в коммандировки доблестно исправлять. Так что, подумайте, как будет выглядеть ваше предприятие, когда это говно всплывёт наружу. И что может быть за это лично вам (в договоре обычно чётко написано про соблюдение репутации компании).
0
Тут я не рассматриваю моральную сторону — только техническую. Хотя и это тоже правильно
0
Не знал в какую ветку обсуждения воткнуть, ибо подходит к нескольким сразу, а посему пусть будет здесь. Это и к вопросу о том, чтобы делиться бесплатно с человечеством своими трудами, и также о взаимоотношениях «производитель-заказчик», и онужности сего действа в целом.
В приснопамятные времена посткоммунистической юности, наша контора продавала изделия с неустановлеными битами защит. Покупатель ничего не делал с изделиями, не пытался скопировать, стибрить идеи и т.п. Ну просто душка, а не хитрая акула империализма. Но! Вышло так, что одно изделие попало в руки наших бывших братьев, тех, которые с хитрым восточным прищуром. Ушлые дядюшки Ляо, верные заветам не только дедушки Мао, но и Дэн Сяньшэна, быстро поняли где же тот таинственный цимес, что позволяет поиметь в кармане не только горстку риса, но и вполне себе бутерброд с маслом. Плата в изделиях было двухслойная, компоненты штыревые, руки у вкуривших капитализма на коммунистической основе в меру прямые, а биты защиты, как было упомянуто, мифические.
Не прошло и полсказки, а — как говорится — чёрное дело было сделано. В итоге: добрым молодцам вход в ту горенку, то бишь на тот сектор рынка в краях загорских, был заказан навсегда, а хитрые братья обрели богатство земное, да славу людскую. Даже не откланялись вежливо, а при встрече и вовсе сторонятся, неча, мол, всякой рвани тут шляться.
Да, рассказывали мне про те поделки чудные, да чудеса, которые они миру явят, но ведь работала шайтан-арба, да дело своё кое-как делала. Ну и не златом за неё берут, а медью, что вполне по желанию толпы, да по её надобностям.
Вот вам и весь сказ, а кто понял — молодец.
0
ИМХО, сейчас уже такое время, что можно и не защищать свои устр-ва, поскольку цикл жизни(от разработки и до полного окончания пр-ва) некой модели — 1, максимум 2 года, а каждые полгода/год надо выпускать новую версию, соответственно, весь цикл разработки аппаратной части и ПО должен составлять максимум 3 мес. Все, кто не укладываются в эти современные стандарты — вымрут — это по законам neo-дарвинизма.

И вообще: Работайте и конкурируйте лучше, сукины сыны!
0
Хм, вы не путайте яичницу со сковородкой. Я работаю в конторе, не MP3-плееры, и даже не телевизоры, выпускающей. Ладно, для молодцев, урок не усвоивших прилежно, да ещё и к тому же хулящих сказителя, почём зря.
Первое: потерян некислый кусок рынка. Второе: наши изделия только гарантию намного поболе года имеют, а служат и того дольше. Отрасль же данная крайне консервативна и не меняет девайсы, аки глупый потребитель телефоны.
Ну а насчёт совета работать… Дык, мил человек, работаем, а вот о конкуренции я вам рассказал, дабы другие учились не ходить по граблям, аки бусурмане-йоги какие. Мы-то сами виноваты, да добрым людям наукой послужит сей сказ.
0
Очень сильное заблуждение по поводу надежности шифрования ключом, полученным из трех ключей с простыми числами длин. Этот результирший ключ (гамма) будет уязвим к атаке с частично известным открытым кодом.
Лет 10 назад успешно сломал такой в «коммерческой фрактальной системе шифрования». Просто из известных структур заголовков exe, word файлов восстанавливался весь текст. А ключи были под 2-3 кб каждый и было их 5 штук.
Да и какой смысл использовать непроверенные и опасные самодельные алгоритмы, когда des/aes вполне переваривают даже avr-ки?
0
  • avatar
  • Kosha
  • 23 августа 2013, 00:46
когда работал в рекламе — напоролся на недобросовестного заказчика, который не оплатил 60% стоимости табло после того, как работы были полностью закончены. Этот опыт был учтен и с тех пор в программу табло был добавлен код, позволяющий блокировать табло при вводе специального пароля через ИК пульт. Немного позже ситуация повторилась. И вот, у них табло просто перестало работать… вдруг… А гарантийный ремонт по договору только после полной оплаты… Подействовало. Естественно заказчик думал, что ему не повезло — не удалось сэкономить…
0
Миллион комментариев :)

Прошу прощения, если кто-то уже вспоминал этот вид «демо-перемычки», я его почерпнул из уже не помню какой книжки:
Ставим RC-цепочку, и меряем напругу на конденсаторе. Если она нарастает, да ещё и с нужной скоростью, то всё нормально, работаем. А если не нарастает, или нарастает, но не так, то демо режим. Ну и в прототипе переданном заказчику убираем или R или C. В принципе, не надо быть семи пядей во лбу, чтобы попытаться впаять на место отсутствующей детали пофигистор или резистор. Очень многие приборы конфигурируются таким образом. Проблема в том, что это не поможет. Нужна правильная деталь правильного номинала, а это уже куда веселее.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.