Защищать .NET-код от обратного инжиниринга?

Question

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

Также возможно преобразовать приложение C # в собственный код, и Xenocode слишком дорогой.

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

Безопасные сертификаты можно легко удалить из подписанных сборок в .NET.

Answer 1

запутать код! Есть пример в Обфусцирующий код C # .

Answer 2

Имейте в виду, что 99% + ваших пользователей не будут заинтересованы в проверке вашего исполняемого файла, чтобы увидеть, как он работает.

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

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

Answer 3

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

Оба имеют один и тот же очень простой ответ: не передавайте объектный код ненадежным сторонам, таким как (очевидно) вашим клиентам. Возможно ли разместить приложение на ваших машинах, зависит только от того, что оно делает.

Если это не веб-приложение , возможно, вы можете разрешить SSH вход с X-переадресацией на сервер приложений (или Remote Desktop Connection , Я думаю, для Windows).

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

Если вы мне не верите, назовите громкое приложение, которое не было взломано и пиратским.

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

Существуют пакеты, которые будут шифровать ваш EXE-файл и расшифровывать его, когда пользователю разрешено его использовать

Конечно, можно обойти тест «can-I-use-it», чтобы он всегда возвращал true.

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

Answer 4

Просто создайте хорошее приложение и создайте простую систему защиты. Неважно, какую защиту вы выберете, она будет полностью изменена ... Так что не тратьте слишком много времени / денег.

Answer 5

Невозможно полностью защитить приложение, извините.

Answer 6

Я могу рекомендовать использовать Обфускатор .

Answer 7

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

Dotfuscator скрывает ваш код, а .NET Reflector показывает ошибку при попытке его декомпиляции.

Answer 8

Просто добавьте предупреждение: если вы собираетесь использовать запутывание, проверьте, что все еще работает! Запутывание может изменить такие вещи, как имена классов и методов. Поэтому, если вы используете рефлексию для вызова определенных методов и / или классов (как в плагин-архитектуре), ваше приложение может потерпеть неудачу после запутывания. Также трассировки стека могут быть бесполезны для отслеживания ошибок.

Answer 9

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

Answer 10

Когда речь идет о .NET, если вы выпускаете приложение Windows Forms (или любое приложение, в котором у клиента есть файл Portable Executable), оно может быть взломано.

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