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

Question

Это проблема, которую мы все должны рассмотреть в какой-то момент.

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

Далее, каждый раз, когда я пишу на эту тему, кто-то мне напоминает; «Прежде всего, независимо от того, какую защиту вы будете использовать, действительно преданный взломщик, в конце концов, преодолеет все защитные барьеры». Какое соотношение цены и качества c # защита кода для одного разработчика

Итак, не выдерживая этих двух общих истинных заявлений об отказе, давайте поговорим о «защите»!

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

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

Итак, мой подход состоял в том, чтобы запутать код виртуализацией с использованием таких продуктов, как: http://www.oreans.com/codevirtualizer.php Я был очень счастлив с этим продуктом. Насколько мне известно, он никогда не был побежден. Я даже могу сжать исполняемый файл с PEcompact У кого-нибудь еще есть опыт?

Не было ничего, кроме проблем с EXEcryptor http://www.strongbit.com/news.asp Даже сайт является головной болью для использования. Скомпилированные приложения будут зависать при выполнении любых вызовов WMI.

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

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

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

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

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

Для защиты от дампов памяти я использую простую технику обфускации текста (например, XOR для каждого символа). Это затрудняет различие между текстовыми данными в памяти и их изменением и т.

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

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

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

Другая идея - кодировать указатели с добавленной переменной. Переменная является результатом авторизации (обычно ноль). Это неизбежно приведет к GPF в какой-то момент. Я использую это в качестве крайней меры только после неудачной авторизации на более низком уровне, иначе реальные пользователи могут столкнуться с ней. Тогда репутация вашего программного обеспечения снижается.

Какие техники вы используете?

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

Из некоторых ссылок:

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

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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