шифрование .Net приложения и сборок

Question

У меня есть вопрос о шифровании / защите от копирования.

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

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

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

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

Спасибо!

Answer 1

Сборка строгих имен никогда не предназначалась для защиты от злоумышленника, который контролирует машину. Из записи msdn о задержке подписания :

В следующем примере отключается проверка сборки myAssembly.dll.

sn –Vr myAssembly.dll

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

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

Как уже упоминалось другими авторами, вы ищете обфускацию . У вас, вероятно, уже есть такой инструмент: Visual Studio (по крайней мере, 2005 и 2008) поставляется с общедоступной версией PreEmptive Solutions ' Dotfuscator. Microsoft также имеет свою собственную " Службу лицензирования и защиты программного обеспечения"товар.

Запутывание имеет некоторые технические недостатки, однако:

• это может усложнить процесс сборки. Вам нужен необъяснимый и запутанный строй, потому что последний не отлаживается.
• Мне нравится иметь диалоговое окно с сообщениями об ошибках для непредвиденных исключений, где пользователь может нажать «Копировать детали» и отправить мне письмо с некоторой технической информацией, включая трассировку стека. Однако с запутыванием, вы можете забыть о получении чего-либо полезного от Exception.StackTrace .
• если ваш код использует отражение , то есть большая вероятность, что все будет перерыв в запутанной сборке, потому что внутренний тип и имена членов не сохраняются.

Answer 2

Подписание вашей сборки сделает невозможным ее изменение без изменения подписи и, следовательно, ее ссылки. Следствием этого является то, что (строго именованная) ссылка на сборку не сможет быть сопоставлена ​​с измененной версией. И это гарантировано от нелепых шансов.

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

Другое доступное вам средство - это запутывание. Существует бесплатная версия обфускатора, поставляемая с Visual Studio, которую можно обновить до промышленного уровня. Запутывание делает код непонятным, не изменяя его поведения, и, следовательно, представляет собой реальный барьер для обратного проектирования.

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

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

Answer 3

Если они исправляют ваш исполняемый файл, строгое имя не поможет. Это, однако, поможет вам убедиться, что указанная вами dll является верной версией и не была подделана.
вы можете проверить Саламандра или Упреждающий для запутывания.
Шифрование вы можете посмотреть на Сборка Lockbox , CodeVeil , или ThinApp

Answer 4

Если вы хотите использовать ключ и зашифровать свою программу, эта статья может быть вам полезна: http://www.gironsec.com/blog/2012/02/dongles-how-do-they-work/

Вот соответствующая цитата из этой статьи:

There are 2 ways to implement a dongle. The right way and the wrong way. The right way would be to encrypt your programs and store the encryption key on the dongle and decrypt at run time depending on whether the device is connected or not.

Answer 5

В некоторой степени, Запутывание может быть полезно для вас. Но это не 100% безопасный способ. На самом деле, нет никакого 100% безопасного способа защиты любого программного модуля. В лучшем случае, запутывание просто отнимает много времени для обратного проектирования программы. .NET Reflector - это инструмент обратного проектирования, который восстанавливает исходный код из любых сборок .NET. Использование Dotfuscator затруднит понимание злоумышленником оригинального исходного кода, но можно попытаться получить хорошую оценку этого исходного кода, если награда большая.