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

91

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

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

Связанный:

c#  .net  license-key 
— J3r3myK
источник
— stukelly
@stukelly, который был опубликован после того, как J3r3myK опубликовал свой вопрос ...
— Dozer789

Ответы:

83

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

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

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

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

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

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

— Frankodwyer
источник
1
Хорошее резюме. Если кто-то не верит, что это просто обойти поиск CheatEngine, он делает это настолько легким, что непрограммисты могут это сделать. Лучше всего сделать этот слой простым.
— Келли
У меня та же проблема, я сделал лицензионный ключ для своего приложения с датой истечения срока действия и последней записанной датой для проверки, но проблема в том, что мне нужно добавить закрытый ключ для редактирования файла, чтобы обновить последнюю зарегистрированную дату, которая не умный способ вставить ключ в код. любой совет ?
— Doicare 08
16

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

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

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

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

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

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

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

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

— Spiffeah
источник
3
К вашему сведению, шифрование всегда обратимо, было бы бесполезно не читать то, что было зашифровано. Хеширование - это единственный способ «шифрования», о котором вы, возможно, думаете.
— Samuel
«Не применяйте свою собственную криптографическую схему», которая, я думаю, принадлежит Брюсу Шайеру (не уверен), - это правильный путь. Вы можете взглянуть на этот ответ: security.stackexchange.com/questions/2202/…
— Shadok
Не могли бы вы подробнее рассказать о "..P / Invoke to it". Я посмотрел на связанную страницу, но это не сделало меня мудрее: - /
— MrCalvin 01
11

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

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

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

— Кинджал Диксит
источник
9

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

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

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

— расточитель
источник
6

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

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

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

— Джошуа
источник
Разве тогда не нужно было бы отключать DEP?
— Роуленд Шоу,
Нет. Установка PAGE_EXECUTE_READWRITE - это задокументированный правильный способ написания самомодифицирующегося кода, который очищает бит NX только на этой странице.
— Джошуа
8
Эта общая техника была очень популярна в конце 80-х годов. Его слабость заключалась в том, что «секретный» код дешифровался в ОЗУ, что позволяло легко украсть любую работающую копию программного обеспечения.
— Ray Burns
5

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

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

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

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

— готовить
источник
Для тех, кто помнит, что он отменен: SLP снова запускается
— Майкл Олесен
5

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

— Роланд
источник
2

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

— Че
источник
2

Один из простых способов - использовать глобальный уникальный идентификатор (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 "/".

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

— Айшвар Си Нигам
источник
1

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

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

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

Может быть стоит прочитать ответы на этот вопрос , а также

— Роуленд Шоу
источник
6
«Уловка состоит в том, чтобы иметь алгоритм, который знаете только вы» - это в значительной степени определение безопасности через неясность, и это действительно плохая идея.
— Ник Джонсон
3
Однако все лицензирование осуществляется по алгоритму с использованием секретов. К лицензированию часто лучше всего подходят инвестиции в юристов, а не гонку вооружений по придумыванию «нерушимых» ключей
— Роуленд Шоу
+1 за комментарий относительно обеспечения соблюдения лицензии законными средствами
— Роб
Да, все лицензирование слабое, как и DRM. Однако использование секретного алгоритма явно слабее .
— Ник Джонсон
1
Я дал вам +1 за хороший ответ, и хотел бы дать вам еще один, против голосования против. К сожалению, в мире есть несколько очень незрелых младенцев.
— ProfK
0

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

  • Компонент бесплатного лицензирования
  • Онлайн-активация
  • API для интеграции вашего приложения и интернет-магазина
  • Генерация серийного номера
  • Отзыв лицензий
  • Управление подпиской
— Хосе
источник
1
«Бесплатно» не совсем бесплатно. Встраивать лицензионный компонент в ваше приложение можно бесплатно; Приложение не может использовать лицензионный компонент бесплатно. После 10 активаций вам нужно будет платить ежемесячную плату. Это не процент активации. Для небольших объемов недорогих .NET-приложений такая модель ценообразования будет недостатком. Это не похоже на Apple AppStore для приложений .NET.
— Cheeso
0

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

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

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

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

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

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

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

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

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

— Ezekg
источник
0

Проверьте этот ответ: https://stackoverflow.com/a/38598174/1275924

Идея состоит в том, чтобы использовать Cryptolens в качестве сервера лицензий. Вот пошаговый пример (на 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();
— Артем
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.