Как создать ключ продукта для моего приложения С#?

Ответ 1

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

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

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

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

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

edit: Я просто хочу добавить, не вкладывайте слишком много времени в это или думайте, что каким-то образом ваша запутанная схема будет отличаться и не поддаётся проверке. Это не будет, и не может быть до тех пор, пока люди будут контролировать оборудование и ОС, на которых работает ваша программа. Разработчики пытались придумать все более сложные схемы для этого, думая, что, если они разработают для себя свою собственную систему, то они будут известны только им и, следовательно, "более безопасны". Но это действительно эквивалент программирования, который пытается построить вечный двигатель.: -)

Ответ 2

Кому вы доверяете?

Я всегда считал эту область слишком критичной, чтобы доверять третьей стороне для управления безопасностью вашего приложения. Как только этот компонент взломан для одного приложения, он взломан для всех приложений. Это случилось с Discreet через пять минут после того, как они пошли с решением сторонней лицензии для 3ds Max лет назад... Хорошие времена!

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

• Название лицензии - имя клиента (если есть), которое вы лицензируете. Полезно для управления развертываниями компаний - заставить их чувствовать себя особенными, чтобы иметь "персонализированное" имя в информации о лицензии, которую вы им предоставляете.
• Срок действия лицензии
• Количество пользователей для запуска под одной лицензией. Это предполагает, что у вас есть способ отслеживания выполнения экземпляров на сайте, на сервере-ish way
• Коды функций - позволяют использовать одну и ту же систему лицензирования для нескольких функций и для нескольких продуктов. Конечно, если он треснул для одного продукта, он взломал для всех.

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

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

И так как это, вероятно, самый важный код в вашем приложении/компании, поверх/вместо обфускации, подумайте о том, чтобы поместить процедуры расшифровки в собственный DLL файл и просто P/Invoke.

Несколько компаний, с которыми я работал, с большим успехом приняли обобщенные подходы к этому. Или, может быть, продукты не стоили взломать;)

Ответ 3

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

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

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

Ответ 4

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

Простая логика ключа продукта может состоять в том, чтобы сказать, что ключ продукта состоит из четырех 5-значных групп, таких как abcde-fghij-kljmo-pqrst, а затем далее указывать внутренние отношения, такие как f + k + p, равный a, что означает первые цифры групп 2, 3 и 4 должны составлять a. Это означает, что 8xxxx-2xxxx-4xxxx-2xxxx действителен, поэтому 8xxxx-1xxxx-0xxxx-7xxxx. Конечно, были бы и другие отношения, в том числе сложные отношения типа, если вторая цифра первой группы нечетна, тогда последняя цифра последней группы также должна быть нечетной. Таким образом, были бы генераторы ключей продукта, а проверка ключей продукта просто проверяет, соответствует ли это всем правилам.

Шифрование обычно представляет собой строку информации о лицензии, зашифрованной с использованием закрытого ключа (== с цифровой подписью) и преобразованной в Base64, Открытый ключ распространяется вместе с приложением. Когда строка Base64 приходит, она проверяется (== расшифрована) открытым ключом и, если она будет найдена, продукт активируется.

Ответ 5

Существует опция Лицензирование и защита программного обеспечения Microsoft (SLP). Прочитав об этом, я действительно хотел бы использовать его.

Мне очень нравится идея блокировки частей кода на основе лицензии. Горячий материал и наиболее безопасный для .NET. Интересное чтение, даже если вы его не используете!

Лицензирование программного обеспечения Microsoft® и Служба защиты (SLP) - это услуга активации программного обеспечения, которая позволяет независимым поставщикам программного обеспечения (ISV) принять гибкое лицензирование условия для своих клиентов. Microsoft SLP Services использует уникальную метод защиты, который помогает защитить ваша заявка и лицензирование информацию, позволяющую вам добраться до быстрее рынка соблюдение требований клиентов.

Примечание. Это единственный способ опубликовать продукт с чувствительным кодом (например, ценный алгоритм).

Ответ 6

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

• Найдите узкое место процессора и извлеките его в файл P/Invokeable.
• Как действие post build, зашифруйте часть DLL файла с помощью XOR ключ шифрования.
• Выберите схему открытого/закрытого ключа, включите открытый ключ в DLL файл
• Упорядочить так, чтобы дешифровать ключ продукта и XORing два половина вместе приводит к ключу шифрования для DLL.
• В коде DLL DllMain отключите защиту (PAGE_EXECUTE_READWRITE) и расшифровать его с помощью ключа.
• Сделайте метод LicenseCheck(), который делает проверку работоспособности лицензионный ключ и параметры, затем проверяет весь файл DLL, бросая нарушение лицензии. О, и выполните другую инициализацию здесь.

Когда они находят и удаляют LicenseCheck, что за забавой будет когда DLL запускает segmentation faulting.

Ответ 7

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

Ответ 8

Другим полезным недорогим инструментом для ключей и активаций продукта является продукт под названием InstallKey. Взгляните на www.lomacons.com

Ответ 9

Фокус в том, чтобы иметь алгоритм, который вы только знаете (чтобы его можно было декодировать на другом конце).

Есть такие простые вещи, как "Выберите простое число и добавьте к нему магическое число"

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

Возможно также стоит прочитать ответы на этот вопрос, а также

Ответ 10

Для него есть некоторые инструменты и API. Однако, я не думаю, что вы найдете его бесплатно;)

Существует, например, набор OLicense: http://www.olicense.de/index.php?lang=en

Ответ 11

Вы можете проверить LicenseSpot. Он обеспечивает:

• Бесплатный компонент лицензирования
• Онлайн-активация
• API для интеграции вашего приложения и интернет-магазина
• Генерация серийного номера
• Отменить лицензии
• Управление подпиской

Ответ 12

Один простой метод использует глобально уникальный идентификатор (GUID). GUID обычно сохраняются как 128-битные значения и обычно отображаются как 32 шестнадцатеричных цифры с группами, разделенными дефисами, например {21EC2020-3AEA-4069-A2DD-08002B30309D}.

Используйте следующий код в С# с помощью System.Guid.NewGuid().

getKey = System.Guid.NewGuid().ToString().Substring(0, 8).ToUpper(); //Will generate a random 8 digit hexadecimal string.

_key = Convert.ToString(Regex.Replace(getKey, ".{4}", "$0/")); // And use this to separate every four digits with a "/".

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

Ответ 13

Пожалуйста, проверьте этот ответ: fooobar.com/questions/70209/...

Идея заключается в использовании SKM Platform в качестве сервера лицензий. Здесь шаг за шагом пример (в VB.NET)

Ответ 14

Я собираюсь немного контрейлеровать на @frankodwyer отличный ответ и немного углубиться в онлайн-лицензирование. Я являюсь основателем Keygen, лицензирования REST API, созданного для разработчиков.

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

Для начала мы могли бы создать 2 типа лицензии (называемые политиками в Keygen), и всякий раз, когда пользователь регистрирует учетную запись, вы можете создать для нее пробную лицензию ( "пробная версия" "лицензия реализует нашу" пробную "функциональную политику), которую вы можете использовать для различных проверок в приложении, например может пользователь использовать пробную функцию-A и пробную-функцию-B.

И основываясь на этом, всякий раз, когда пользователь покупает ваше приложение (независимо от того, используете ли вы PayPal, Stripe и т.д.), вы можете создать лицензию, реализующую "полную" политику функций и связать ее с учетной записью пользователя. Теперь в вашем приложении вы можете проверить, имеет ли пользователь полную лицензию, которая может выполнять Pro-Feature-X и Pro-Feature-Y (делая что-то вроде user.HasLicenseFor(FEATURE_POLICY_ID)).

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

• Учетные записи пользователей позволяют связывать несколько лицензий и несколько компьютеров с одним пользователем, давая вам представление о поведении вашего клиента и предлагая им "покупки в приложении", то есть приобретая вашу "полную" версию (вроде мобильных приложений).
• Мы не должны требовать от наших клиентов ввода длинных лицензионных ключей, которые являются утомительными для ввода и трудно отслеживать, то есть они легко теряются. (Попробуйте найти "потерянный лицензионный ключ" в Twitter!)
• Клиенты привыкли пользоваться электронной почтой/паролем; Я думаю, мы должны делать то, что люди привыкли делать, чтобы мы могли обеспечить хороший пользовательский интерфейс (UX).

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

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

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