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

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

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

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

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

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

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

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

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

Этот подход позволяет объединять небольшие разделы кода с запутыванием и тем самым защищать проверку безопасности и т.д.

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

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

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

Так как все статические строки хорошо видны в файле .exe, я стараюсь быть общим с сообщениями об ошибках и т.д. Вы нигде не найдете строку "Ошибка авторизации".

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

От некоторых ссылок:

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

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

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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