Защита программного обеспечения для мелких поставщиков

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

Но более интересный вопрос не «что», а «почему». Прежде чем поставщик программного обеспечения приступит к этому типу упражнений, действительно важно построить модель угроз. Например, угрозы для недорогой B2C-игры полностью отличаются от угроз для полноценного B2B-приложения.

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

Я не согласен xsl.

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

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

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

Вам не нужно несколько сотен пользователей, чтобы взломать ваше программное обеспечение. Меня раздражало, что моя условно-бесплатная программа взламывалась так много раз, поэтому в качестве эксперимента я создал программу под названием Magic Textbox (которая представляла собой просто форму с текстовым полем) и опубликовал ее для условно-бесплатных сайтов (у нее был собственный файл PAD и все остальное. ). Днем позже была доступна взломанная версия Magic Textbox.

Этот опыт заставил меня в значительной степени отказаться от попыток защитить свое программное обеспечение чем-либо, кроме элементарной защиты от копирования.

Раньше я использовал .NET Reactor с хорошими результатами - http://www.eziriz.com/

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

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

Мне очень-очень не нравится слово «защищать», которое здесь использовано. Единственное, что вы пытаетесь защитить, - это ваш контроль. Вы являетесь нет, защищающим программное обеспечение. Программное обеспечение в любом случае в порядке, как и ваши пользователи.

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

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

xsl, это очень узкая точка зрения с МНОГИМИ встроенными предположениями.

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

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

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

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

По некоторым ссылкам:

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

Где и когда проверять серийный номер: проверяю один раз при запуске. Многие люди говорят: «Проверяйте в самых разных местах», чтобы кому-то было труднее взломать чек, сняв чек. Если вы хотите быть особенно неприятным для взломщика, проверяйте всевозможные места, используя встроенный код (то есть НЕ выносите все это в SerialNumberVerifier.class) и, если это вообще возможно, сделайте его многопоточным и трудно распознать, когда он выходит из строя , тоже. Но это только усложняет взлом, а не делает невозможным, и помните, что ваша цель - не победить взломщика. Победа над взломщиком не принесет вам заметных денег. Вам просто нужно победить случайного пользователя в большинстве случаев, а случайный пользователь не имеет доступа к отладчику и не знает, как его использовать.

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

Не делайте «интересной» или «сложной» защиты. Многие взломщики взламывают одни только интеллектуальные вызовы. Сделайте вашу защиту трудной для взлома, но как можно более скучной.

Есть некоторые трещины, которые ищут байтовые шаблоны в поисках места для исправления. Обычно они не уничтожаются перекомпиляцией, но если ваш .EXE упакован (ASProtect, Armadillo и т. д.), Такие взломы должны сначала распаковать .EXE .. и если вы используете хороший упаковщик, такой как ASProtect, взломщик сможет распаковать EXE вручную с помощью отладчика уровня сборки, такого как SoftICE, но не сможет создать инструмент, который автоматически распаковывает .EXE (для последующего применения байтовых патчей).