Плюсы / минусы использования сборки в качестве файла лицензии?

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

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

инструмент генерации лицензий может скомпилировать сборку с соответствующими свойствами и ресурсами и подписать ее.

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

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

13
.net assemblies c# reflection

6 ответов

подписанный файл лицензии xml имеет несколько преимуществ, но они не могут быть applicaple к вашей ситуации:

  1. вы можете проверить его содержимое с помощью простого инструмента, такого как блокнот или веб-браузер. Если вам нужно управлять множеством лицензий и проходит много времени, вы можете легко проверить область лицензии, просто просмотрев файл. Даже клиент может прочитать Вам наиболее важные моменты своей лицензии по телефону.
  2. Если установка одного приложения может быть назначено много лицензий (на пользователя, на функцию и т. д.), проще управлять списком xml-файлов, чем динамически загружать сборки.
  3. проще создать инструмент для создания лицензии на стороне клиента - > приложение отправит неподписанный xml-файл для подписания.
  4. Это проще для управления версиями. Если новая версия программного обеспечения имеет новые параметры лицензирования, а старая лицензия должна работать с обновленной версией, в зависимости от реализации паленый лицензионная сборка, вы можете сломать старое программное обеспечение.

Если у вас нет каких-либо из этих конкретных потребностей, перейдите к опции assembly-as-a-license, поскольку ее проще реализовать.

обновление

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

идти с подписанием лицензии в dll или внешнем xml-файле достаточно хорошо.

6

вы можете использовать сборку вместо файла лицензии, но вы не должны. Всегда можно было удалить цифровую подпись из сборки; теперь это тривиально с помощью инструмента Reflexil.

см. статью нарушена защита от взлома CAS: последствия для лицензирования программного обеспечения для получения более подробной информации.

4

хорошим решением, которое всегда работало для меня, является создание класса лицензии со всеми необходимыми свойствами, такими как имя, срок действия, логотипы и т. д. Сериализуйте класс в двоичные данные в памяти, затем зашифруйте их и сохраните в файл. Выполнение этого способа не требует подписи, и файл устойчив к взлому. Чтобы прочитать лицензию, просто сделайте обратное, прочитайте файл, расшифруйте, unencrypt, unserialize. Одно предостережение заключается в том, что если несколько сборок собираются прочитать этот файл лицензии, то функции encrypt / unencrypt должны находиться в отдельной общей сборке.

3

Я бы не стал использовать сборку в качестве файла лицензии - как указывали другие, это относительно тривиально сломать.
Я бы использовал файл (xml или что-то еще), а затем заблокировать его на компьютере пользователей. Это может быть достигнуто несколькими способами :
1) Использовать система.Криптография.ProtectedData - это просто обертывает DPAPI Windows и использует хранилище ключей windows ( на пользователя или на локальную машину ). Это простой(иш) подход, но вам придется использовать Кодирование.В utf8.GetString (или любая ваша кодировка) для преобразования обратно из массива байтов. Это простая, но не промышленная сила, поскольку кто-то все еще может выкопать ключевой магазин и т. д.
2) Используйте уникальный идентификатор машины, такой как SID с симметричным алгоритмом, таким как Rijndael или Blowfish, и предоставьте хэш SHA-256 незашифрованного файла лицензии как IV. Это немного сложнее реализовать, так как вам нужно будет использовать WMI для поиска SID, а затем использовать Система.Безопасность.Криптография.RijndaelManaged и т. д. Для шифрования/дешифрования.

1

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

0

Я бы предпочел версию сборки, потому что:

  • вместо .net sign вы можете использовать authenticode (для этого вам нужен сертификат, но это не так дорого), или вы можете использовать оба. Чем в вашем заявлении, вы можете проверить подпись. Это удаляет отверстие безопасности для измененного знака .net.
  • Он более гибкий. Вы можете определить интерфейс для сборки лицензии, который впоследствии может быть расширен.
  • вы можете иметь какую-то логику в лицензионной сборке.

но помните. Это просто защита программного обеспечения. Следующим шагом будет использование крипто ключа ( hasp, Маркс...)

0