Блог

Как защитить библиотеки DLL моего проекта таким образом, чтобы на них не могли ссылаться и использовать другие люди?

Спасибо

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

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

• Статическая ссылка, поэтому нет библиотеки DLL для атаки.
• Удалите все символы.
• Используйте файл .DEF и библиотеку импорта, чтобы иметь только анонимные экспортные данные, известные только по их идентификаторам экспорта.
• Храните библиотеку DLL в ресурсе и предоставляйте ее в файловой системе (под подходящим неясным именем, возможно, даже созданным во время выполнения) только при запуске.
• Скройте все реальные функции за фабричным методом, который обменивает секрет (лучше, доказательство знания секрета) на таблицу указателей функций на реальные методы.
• Используйте методы защиты от отладки, заимствованные из мира вредоносных программ, чтобы предотвратить обратное проектирование. (Обратите внимание, что это, скорее всего, приведет к ложным срабатываниям AV-инструментов.)

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

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

РЕДАКТИРОВАТЬ: Поскольку вы изменили метку, чтобы подразумевать, что C# и .NET-это среда, а не чистая DLL Win32, написанная на C, тогда мне действительно следует пересмотреть вышесказанное до «Вы не можете, но…»

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

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

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

Вы сталкиваетесь с той же проблемой, что и сторонники DRM.

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

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

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

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

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

Ты уже пробовал .Сетевой реактор? Я недавно наткнулся на это. Некоторые люди говорят, что это здорово, но я все еще тестирую его.

Ну, вы можете пометить все свои «общедоступные» классы как «внутренние» или «защищенные внутренние», а затем пометить сборки атрибутом [assembly:InternalsVisibleTo («»)], и никто, кроме отмеченных сборок, не сможет увидеть содержимое.

Вас может заинтересовать следующая информация о сборках друзей: http://msdn.microsoft.com/en-us/library/0tke9fxk(ПРОТИВ 80).aspx