Как защитить мою .net winforms сборку от клиентов заказчика - PullRequest
4 голосов
/ 17 сентября 2010

Этот вопрос, похоже, умер, поэтому я решил предложить щедрость.

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

Лучший ответ был бы: да, он жизнеспособен, это делают все, и покупателям это нравится!

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


Упрощенный сценарий: -
У меня есть класс, который каким-то образом расширяет контроль, и я хочу продать свой класс под двумя лицензиями;

(1) Стандарт - клиент получает x количество элементов управления, которые используют мой класс, но не могут создать экземпляр класса (его внутреннего).
(2) Разработчик - аналогично стандартному, за исключением того, что они могут создавать свои собственные элементы управления, использующие мой класс.

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

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

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

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

Ответы [ 4 ]

2 голосов
/ 27 сентября 2010

Я полагаю, что вы будете хранить информацию о лицензировании (то есть Standard and Developer) где-нибудь в реестре.В таком случае, я полагаю, более простым решением было бы реализовать LicenseManager.Это то, что использует большинство поставщиков компонентов .NET.

http://msdn.microsoft.com/en-us/library/fe8b1eh9.aspx

Надеюсь, это поможет!

1 голос
/ 01 октября 2010

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

Лицензионный ключ может быть определен в файле конфигурации.

1 голос
/ 18 сентября 2010

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

Интересно, а могут ли потребители вообще обойти это ограничение, интегрировав поставленную сборку в свою собственную?

0 голосов
/ 26 сентября 2010

Это сложный вопрос, просто из-за природы .NET.Это выстрел в темноте, но вы можете посмотреть на такие продукты, как CodeVeil , который обеспечивает шифрование сборки на уровне IL.Ваша сборка будет отправлена ​​в зашифрованном виде, а ключ будет передан вашему клиенту.В этом случае заказчик будет единственным лицом, способным расшифровать ваши инструкции по сборке.Теперь CodeVeil заявляет следующее о своих ключах дешифрования:

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

Это, конечно, хорошо, но это та часть, которая у вас естьисследовать, потому что я не знаком с другими методами, которые они используют как часть их алгоритма расшифровки.Крутая вещь в том, что если это работает, ваши клиенты будут счастливы, и ОНИ могут сделать своих клиентов счастливыми, раскрывая части вашей сборки через их собственный API.В то же время ваш код остается защищенным от таких инструментов, как ILDASM и Reflector.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...