Конвенции следовать для создания программного обеспечения Commercial тяжелее для взламывания?

Книга: Написание безопасного кода 2

Существуют сторонние инструменты для запутывания вашего кода. Visual Studio поставляется с одним.

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

Дело в том, что с кодом .NET сравнительно легко перепроектировать с помощью таких инструментов, как .NET Reflector . Запутывание кода может помочь, но все еще возможно работать.

Если вы хотите быстрое решение (но, конечно, нет никаких обещаний, что вы не будете взломаны - это просто «защита»), вы можете искать некоторые инструменты, такие как Themida или Star Force . Это обе знаменитые защитные оболочки.

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

это почти как миссия невыполнима, если у вас очень мало клиентов.

просто подумайте - вы когда-нибудь видели версию Windows, которая не взломана?

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

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

После этого все зависит от того, чего вы пытаетесь избежать. Установка без лицензии? Взрыв на время? Увеличение использования программного обеспечения (например, на большем количестве процессоров) без дополнительной оплаты?

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

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

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

Here are some tips, not perfect but maybe could help:

• update your software frequently
• if your software connects to some server somewhere change the protocol now and then. you can even have a number of protocols and alternate between them depending on some algorithm
• store part of your software on a server which downloads every time you run the software
• when you start your program do a crc check of your dlls that you load i.e. have a list of crc's for approved dll's
• have a service that overlooks your main application doing crc checks once in a while and monitoring your other dependent dll's/assemblies.

unfortunately the more you spend on copy protecting your software the less you have to spend on functionality, all about balance.

another approach is to sell your software cheap but to do frequent, cheap upgrades/updates, that way it will not profitable to crack.