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

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

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

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

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

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

Например, есть пакет OLicense: http://www.olicense.de/index.php?lang=en

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тривиально это или сложно взломать, я не уверен, что это действительно имеет значение.

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

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

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

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

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

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

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

Microsoft® Software Licensing and Protection (SLP) Services is a software activation service that enables independent software vendors (ISVs) to adopt flexible licensing terms for their customers. Microsoft SLP Services employs a unique protection method that helps safeguard your application and licensing information allowing you to get to market faster while increasing customer compliance.

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

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

1. Найдите узкое место в ЦП и извлеките его в DLL-файл P / Invokeable.
2. В качестве действия после сборки зашифруйте часть файла DLL с помощью XOR ключ шифрования.
3. Выберите схему открытого / закрытого ключа, включите открытый ключ в файл DLL
4. Организуйте так, чтобы расшифровка ключа продукта и XOR для двух половинки вместе приводят к ключу шифрования для библиотеки DLL.
5. В коде DLL DllMain отключите защиту (PAGE_EXECUTE_READWRITE) и расшифровать его ключом.
6. Создайте метод LicenseCheck (), который проверяет работоспособность лицензионный ключ и параметры, затем контрольные суммы всего DLL файла, выкидывая нарушение лицензии ни на что. О, и сделайте другую инициализацию здесь.

Когда они найдут и удалят LicenseCheck, какое веселье последует когда DLL запускает нарушение сегментации.

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

Еще один хороший недорогой инструмент для ключей продукта и активаций - это продукт под названием InstallKey. Взгляните на www.lomacons.com

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

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

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

Используйте следующий код на C# от 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 "/".

Я надеюсь, что это помогает.

Пожалуйста, проверьте этот ответ: https://stackoverflow.com/a/38598174/1275924

Идея состоит в том, чтобы использовать Криптолинзы в качестве сервера лицензий. Вот пошаговый пример (в C# и VB.NET). Я также прикрепил фрагмент кода для проверки ключа ниже (на C#):

var licenseKey = "GEBNC-WZZJD-VJIHG-GCMVD";
var RSAPubKey = "{enter the RSA Public key here}";

var auth = "{access token with permission to access the activate method}";
var result = Key.Activate(token: auth, parameters: new ActivateModel()
{
    Key = licenseKey,
    ProductId = 3349,
    Sign = true,
    MachineCode = Helpers.GetMachineCode()
});

if (result == null || result.Result == ResultType.Error ||
    !result.LicenseKey.HasValidSignature(RSAPubKey).IsValid())
{
    // an error occurred or the key is invalid or it cannot be activated
    // (eg. the limit of activated devices was achieved)
    Console.WriteLine("The license does not work.");
}
else
{
    // everything went fine if we are here!
    Console.WriteLine("The license is valid!");
}

Console.ReadLine();

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

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

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

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

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

1. Учетные записи пользователей позволяют связать несколько лицензий и несколько машин с Один пользователь, давая вам представление о поведении вашего клиента и предлагать им совершать покупки в приложении., то есть о покупке вашей «полной» версии (вроде мобильных приложений).
2. Мы не должны требовать от наших клиентов ввода длинных лицензионных ключей, которые утомительны для ввода и трудно уследить, т.е. они легко теряются. (Попробуйте поискать "утерянный лицензионный ключ" в Твиттере!)
3. Заказчики - привык использовать электронную почту / пароль; Я думаю, мы должны делать то, что люди привыкли делать, чтобы мы могли обеспечить хороший пользовательский интерфейс (UX).

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

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

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