Как создать файл лицензии для программы
поскольку использование лицензионного ключа, как это обычно, мне интересно:
- как это обычно решается?
- как может Я генерирую ключ и как он может быть проверен приложением?
- как я могу также избежать публикации ключа в интернете и использования другими, которые не заплатили лицензию (ключ, который в основном не является "их").
Я думаю, что я также должен связать ключ с версией приложения так или иначе, чтобы можно было взимать плату за новые ключи в версиях функций.
что-нибудь еще, о чем я должен думать в этом сценарии?
предостережение: вы не можете запретить пользователям пиратство, но только облегчить честным пользователям делать правильные вещи.
предполагая, что вы не хотите делать специальную сборку для каждого пользователя, а затем:
- создайте себе секретный ключ для продукта
- имя пользователя
- Concatentate имя пользователя и секретный ключ и хеш (например) и SHA1
- распакуйте хэш SHA1 в виде буквенно-цифровой строки. Это индивидуальность "ключ продукта" пользователя
- в программе выполните тот же хэш и сравните его с ключом продукта. Если равны, хорошо.
но, повторяю: это не помешает пиратству
недавно я прочитал, что этот подход не является криптографически очень здравым. Но это решение уже слабое (как само программное обеспечение должно включать секретный ключ где-то), поэтому я не думаю, что это открытие отменяет решение насколько она уходит.
просто подумал, что я действительно должен упомянуть об этом; если вы планируете извлечь из этого что-то еще, будьте осторожны.
существует много способов создания лицензионных ключей, но очень немногие из этих способов действительно безопасны. А жаль, ведь для компаний лицензионные ключи имеют почти такую же ценность, как и реальные деньги.
В идеале вы хотели бы, чтобы ваши лицензионные ключи имели следующие свойства:
только ваша компания должна иметь возможность генерировать лицензионные ключи для ваших продуктов, даже если кто-то полностью реверсирует ваши продукты (что произойдет, я говорю от опыт.) Запутывание алгоритма или скрытие ключа шифрования в вашем программном обеспечении действительно не может быть и речи, если вы серьезно относитесь к контролю лицензирования. Если ваш продукт будет успешным, кто-то сделает ключевой генератор в течение нескольких дней с момента выпуска.
лицензионный ключ должен использоваться только на одном компьютере (или, по крайней мере, вы должны иметь возможность контролировать это очень плотно)
лицензионный ключ должен быть коротким и простым для ввода или диктуйте по телефону. Вы не хотите, чтобы каждый клиент звонил в службу технической поддержки, потому что они не понимают, содержит ли ключ "l" или "1". Ваш отдел поддержки поблагодарил бы вас за это, и у вас будут более низкие расходы в этой области.
Итак, как вы решаете эти проблемы ?
ответ прост, но технически сложен: цифровые подписи с использованием криптографии с открытым ключом. Лицензионные ключи должны быть подписаны "документы", содержащие некоторые полезные данные, подписанные закрытым ключом вашей компании. Подписи должны быть частью лицензионного ключа. Продукт должен проверить лицензионные ключи с соответствующим открытым ключом. Таким образом, даже если кто-то имеет полный доступ к логике вашего продукта, он не может генерировать лицензионные ключи, потому что у него нет закрытого ключа. Лицензионный ключ будет выглядеть так: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA)))) Самая большая проблема здесь заключается в том, что классическая алгоритмы открытого ключа имеют большие размеры сигнатур. RSA512 имеет 1024-битную подпись. Вы не хотите, чтобы ваши лицензионные ключи до сотни символов. Одним из наиболее мощных подходов является использование криптографии эллиптических кривых (с осторожными реализациями, чтобы избежать существующих патентов). Ключи ECC как 6 времен более коротких чем ключи RSA, для такой же прочности. Вы можете дополнительно уменьшить размеры подписи, используя алгоритмы, такие как алгоритм цифровой подписи Шнорра (патент истек в 2008 году - хорошо :) )
ну, просто удалите избыточные символы, такие как" 1"," l"," 0"," o " из ваших ключей. Разделите строку лицензионного ключа на группы символов.
простой ответ-независимо от того, какую схему вы используете, ее можно взломать.
Не наказывайте честных клиентов системой, предназначенной для предотвращения хакеров, поскольку хакеры взломают ее независимо.
простой хэш-код, привязанный к их электронной почте или аналогичный, вероятно, достаточно хорош. Идентификаторы на основе оборудования всегда становятся проблемой, когда людям нужно переустановить или обновить оборудование.
при создании ключа не забудьте объединить версию и номер сборки в строку, в которой вы вычисляете хэш. Таким образом, не будет ни одного ключа, который открывает все, что вы когда-либо выпустили.
после того, как вы найдете некоторые ключи или патчи, плавающие в Асталависта.ящик.СК Вы будете знать, что вам удалось сделать что-то достаточно популярным, что кто-то потрудился взломать. Радуйтесь!
кроме того, что уже было сказано.
вы даже не можете использовать аппаратные значения для создания ключа больше. Виртуальные машины теперь позволяют кому-то создавать образ "лицензированной" машины и запускать ее на любой платформе выбирать.
Если это дорогое программное обеспечение, есть и другие решения. Если это не так, просто сделайте это достаточно сложным для случайного хакера. И принять тот факт, что в конечном итоге будут нелицензированные копии.
Если ваш продукт сложен, то своиственные вопросы поддержки будут создавать некоторую защиту для вас.
Он основан на системе" частичной проверки ключа", которая означает, что только подмножество ключа, которое вы используете для создания ключа, должно быть скомпилировано в ваш дистрибутив. Вы создаете ключи самостоятельно, поэтому реализация лицензии уникальна для вашего программного обеспечения.
Как указано выше, если ваш код можно декомпилировать, его относительно легко обойти большинство систем лицензирования.
Я не знаю, насколько подробно вы хотите получить
Они будут держать их от переключения машин после того, как у них есть ключ.
Я использовал Crypkey в прошлом. Это один из многих доступных.
вы можете защитить программное обеспечение только до точки с любой схемы лицензирования.
единственный способ сделать все, что вы просили, это требует доступа в интернет и верификация с сервером. Приложение должно войти на сервер с ключом, а затем вам нужно сохранить детали сеанса, такие как IP-адрес. Это предотвратит использование ключа на нескольких разных машинах. Обычно это не очень популярно у пользователей приложения, и если это не очень дорогое и сложное приложение, оно того не стоит.
вы может просто иметь лицензионный ключ для приложения, а затем проверить клиентскую сторону, если ключ хорош, но легко распространять этот ключ другим пользователям, и с помощью декомпилятора могут быть созданы новые ключи.
на мой взгляд, если вы не используете веб-лицензирование, нет никакого реального смысла защищать программное обеспечение вообще. С головной болью, которую может вызвать DRM, это несправедливо по отношению к пользователям, которые на самом деле заплатили за это.
Я твердо верю, что только система лицензирования на основе криптографии с открытым ключом является правильным подходом здесь, потому что вам не нужно включать в свой исходный код необходимую информацию, необходимую для генерации лицензии.
в прошлом, я использовал библиотека лицензирования Treek много раз, потому что он заполняет эти требования и предлагает действительно хорошую цену. Он использует ту же защиту лицензии для конечных пользователей и себя, и никто не взломал до сих пор. Вы также можете найти хорошие советы на сайте, чтобы избежать пиратства и взлома.
невозможно полностью предотвратить пиратство программного обеспечения. Вы можете предотвратить случайное пиратство, и это то, что делают все лицензионные решения.
заблокированное лицензирование узла (машины) лучше всего, если вы хотите предотвратить повторное использование лицензионных ключей. Я использую Cryptlex около года для моего программного обеспечения. У него есть свободный план также, Так что если вы не ожидаете слишком много клиентов, вы можете использовать его бесплатно.
Как и некоторые другие упомянутые, я огромный противник враждебности к клиентам по умолчанию-то, что индустрия лицензирования печально известна. Поэтому я расширю хорошее решение для вашей проблемы, что также предлагает хороший клиент UX.
для начала вы упомянули, что у вас есть "ограниченная" версия вашего программного обеспечения, которую вы используете, чтобы попытаться преобразовать клиентов в "обновление" для дополнительных функций. Так что вы ищете лицензии для вашего продукта, например, клиент может приобрести лицензию на функция-X или особенность-Y.
Я построил кейген С учетом этого типа лицензирования. Keygen-это лицензионный REST API, который позволяет управлять учетными записями пользователей, лицензиями, а также отслеживать использование/ассоциации машин.
что бы я сделал, это настроить 2 типы лицензий (a политика в пределах Keygen) где одно основание политика для ограниченной бесплатной версии, а другая-политика для платной версии.
Я не уверен, что вы используете для платежей, но предположим, что вы используете что-то вроде Stripe (довольно стандартное в настоящее время), которое предлагает веб-перехватчиков. Keygen также имеет webhooks (используете ли вы его или нет, все это по-прежнему применимо). Вы можете интегрировать Keygen, чтобы поговорить с вашим поставщиком платежей, используя веб-крючки с обеих сторон (подумайте: customer.created ->создать базовую лицензию для клиента, license.created - >поручите клиента для новой лицензии).
таким образом, используя webhooks, мы можем автоматизировать создание лицензий для новых клиентов. Итак, как насчет проверки лицензии в самом приложении? Это можно сделать различными способами, но самый популярный способ-потребовать от вашего клиента ввести длинный лицензионный ключ в поле ввода, которое вы можете проверить; я думаю, что это Грозный способ обработки проверки лицензии в вашем приложении.
почему Я так думаю? Ну во-первых, вы требуете, чтобы ваш клиент вводил утомительно длинный лицензионный ключ, предназначенный для потребления машины, и во-вторых вы требуете, чтобы вы и ваш клиент отслеживали указанный утомительно длинный лицензионный ключ.
хорошо, так какая альтернатива? Я думаю, что лучшая альтернатива делает то, что все ваши клиенты привыкли: позволяет им создать учетную запись для вашего продукта с помощью электронной почты / пароля. Тогда вы можете свяжите все их лицензии и машины С этой учетной записью. Поэтому теперь вместо ввода лицензионного ключа они могут просто войти в систему, используя свои учетные данные.
какое преимущество это дает? во-первых, он избавляется от необходимости для вас и ваших клиентов, чтобы отслеживать лицензионные ключи, поскольку все это обрабатывается за кулисами внутри их учетной записи пользователя и главное: Теперь вы можете предложить своим клиентам самообслуживание лицензия и активация машины! т. е. поскольку все их лицензии и машины связаны с их учетной записью пользователя, вы можете предложить им приобрести лицензию, когда они запускают ваше приложение на непризнанной машине.
теперь на проверку лицензии: всякий раз, когда ваш клиент входит в ваше приложение со своей электронной почтой/паролем, вы можете запросить их учетную запись пользователя для лицензий, которыми они владеют, чтобы определить, могут ли они использовать функция-X или особенность-Y. И так как ваше приложение теперь самообслуживание, вы можете позволить своим клиентам купить дополнительные функции прямо из вашего приложения!
Итак, мы ввели Т автоматизации нашей системы лицензирования, мы можем лицензировать отдельных особенности (т. е. ограниченная и полная версия), мы предложили высокий UX для наших клиентов и мы также разрешали одну из самых больших причин для запросы поддержки:восстановление лицензионного ключа.
в любом случае, это долго, но, надеюсь, это поможет кому-то!
Я один из разработчиков за Cryptolens платформа лицензирования программного обеспечения и работает над системами лицензирования с 14 лет. В этом ответе я включил несколько советов, основанных на опыте, приобретенном за эти годы.
лучший способ решить эту проблему-настроить сервер лицензионных ключей, который будет вызывать каждый экземпляр приложения для проверки лицензионного ключа.
преимущества сервера лицензионных ключей
в преимущества лицензионного сервера ключей в том, что:
- вы всегда можете обновить или заблокировать лицензионный ключ с немедленным эффектом.
- каждый лицензионный ключ может быть заблокирован на определенное количество машин (это помогает предотвратить публикацию лицензионного ключа в интернете для других пользователей).
соображения
хотя проверка лицензии онлайн дает вам больше контроля над каждым экземпляром приложения, подключение к интернету не всегда присутствует (особенно если вы нацелены на более крупные предприятия), поэтому нам нужен другой способ выполнения проверки лицензионного ключа.
решение заключается в том, чтобы всегда подписывать ответ лицензионного ключа с сервера, используя криптосистему с открытым ключом, такую как RSA или ECC (возможно, лучше, если вы планируете работать на встроенных системах). Ваше приложение должно иметь только публичный ключ для проверки ответа лицензионного ключа.
таким образом, если нет подключения к интернету, вы можете использовать вместо этого предыдущий ответ лицензионного ключа. Обязательно сохраните оба дата и машина идентификатором в ответе и проверьте, что он не слишком старый (например. вы разрешаете пользователям находиться в автономном режиме не более 30 дней и т. д.) И что ответ лицензионного ключа принадлежит правильному устройству.
защита секретных алгоритмов
I в большинстве случаев цель любого решения для лицензирования программного обеспечения-помочь честным людям быть честными (т. е. честные пользователи, которые готовы платить, не забывают платить после окончания пробной версии и т. д.).
тем не менее, у вас все еще может быть некоторый код, который вы никоим образом не хотите просочиться в общественность (например. алгоритм для прогнозирования цен на акции и т. д.). В этом случае единственный способ - создать конечная точка API что ваше приложение будет звонить каждый раз, когда метод должен быть выполненный. Для этого требуется подключение к интернету, но это гарантирует, что ваш секретный код никогда не выполняется клиентской машиной.
реализация
Если вы не хотите реализовать все самостоятельно, я бы рекомендовал взглянуть на в этом уроке (часть Cryptolens)
ваше программное обеспечение по-прежнему будет взломать, но для случайного взломщика вполне может быть достаточно, чтобы отложить их, и эти простые шаги также предотвратят извлечение кода и повторно используется.
Как создать установщик для своего приложения
давно хочу написать установкщик,но весь гугл перерыв не нашел.вот все совреемнные установщики.
Как заменить ключ от своего приложения в Google Play?
При попытке публикации обновления для приложения у меня возникает ошибка, говорит что использованы.
Как создать окно справки для своего приложения?
подскажите, пожалуйста, леплю интерфейс, как подключить при нажатии f1 справку, или вообще как.
Лицензионный ключ для Каспера
Я Касперским мало пользовался, поэтому не знаю. Сначала я его установил, всё нормально работало.
Khaker_tt, вам нужен один ключ или механизм проверки правильности введенного ключа? Соответственно нужен и генератор ключа?
Какого вида ключ вы хотите создать? Дайте больше информации.
Yury Komar, Мне нужен механизм проверки правильности введенного ключа.
Добавлено через 35 минут
Допустим такой ключ GYH-NDJ-JDH-hjd-fjd.
Добавлено через 13 минут
то есть регистрация для своей программы.
Khaker_tt, а как вы создаете этот ключ? или это просто строка текста?
ну тогда самый простой способ - это:
Yury Komar, Нет. Это очень простой способ я по моему неправильно сформулировал вопрос извиняюсь за неудобства. Мне нужно чтобы как то было динамично. Допустим кто та хочет использовать мою программу он должен взят у меня код активации. И этот код должен работать на один компьютер а на другой он уже не рабочий.
Решение
Khaker_tt, тогда вы должны попросить и данные о его копьютере, чтобы сформировать ключ именно для этого компьютера, либо завести сетевую базу данных, и хранить количество авторизаций с разных компьютеров с этим серийным номером. это муторно.
проще на основе имени компьютера (например) создавать ключ по определенным правилам, которые будут известны только вам конечно.
разделяете пароль на части, кодируете каждую часть определенным образом, чтобы ключ каждый раз содержал разные символы, но при проверке, удовлетворял условиям кодировки ключа..
Добавлено через 21 минуту
Скажем так, вот следующий алгоритм проверки пароля, не очень сложный, но и не такой простой как обычный текст:
Просто зашиваете слово, например YURIY (как в данном примере) в ваш пароль и прячете среди других символов, конечно сложность пароля может быть разной, на ваш вкус, я привел просто пример, чтобы натолкнуть на мысль.
Вот такие пароли успешно подойдут для авторизации по данной функции:
m Y S-4 U c-A R 5-Q I 1-q Y 7
S Y m-c U 4-5 R A-1 I Q-7 Y q
a Y URIY-L U M-P R O-S I LK-K Y ARIO
Добавлено через 2 минуты
разработайте алгоритм проверки ключа, которые выданы для 1,2 или Unlimited и проверяйте на совпадения какие-то конкретные части пароля.
XmlDocument doc = new XmlDocument ();
doc.LoadXml( @"
doc.ChildNodes[0].SelectSingleNode( @"/license/Name" , null ).InnerText = Name;
doc.ChildNodes[0].SelectSingleNode( @"/license/Date" , null ).InnerText = StartDate.ToShortDateString();
doc.ChildNodes[0].SelectSingleNode( @"/license/UpdateTo" , null ).InnerText = UpdateTo.ToShortDateString();
MD5 md5 = new MD5CryptoServiceProvider();
byte [] data = System.Text. Encoding .UTF8.GetBytes(Name + StartDate.ToShortDateString() + UpdateTo.ToShortDateString() + "SomePasswordKey" );
byte [] hash = md5.ComputeHash(data);
doc.ChildNodes[0].SelectSingleNode( @"/license/Signature" , null ).InnerText = Convert .ToBase64String(hash);
doc.Save(System.IO.Path.Combine(Path, "license.xml" ));
>
>
* This source code was highlighted with Source Code Highlighter .
На выходе получаем примерно такой вот файл license.xml
* This source code was highlighted with Source Code Highlighter .
Далее в защищаемом приложении нам нужно пройти проверку, делается это путем вызова метода Verify при каждом запуске приложения:
public class LicenseVerify
public LicenseVerify() < >
public string Name < get ; private set ; >
public DateTime StartDate < get ; private set ;>
public DateTime UpdateTo
public void Verify()
string File = "license.xml" ;
if (!System.IO. File .Exists( File ))
throw new ApplicationException ( "Ваша копия программы не лицензирована! Не найден файл лицензии License.xml.\n Обратитесь к автору." );
>
throw new ApplicationException( "Ваша копия программы не лицензирована!\nОшибка чтения файла лицензии!\nОбратитесь к автору." );
>
if (sig1 != Signature)
throw new ApplicationException( "Ваша копия программы не лицензирована!\nОшибка чтения файла лицензии!\nОбратитесь к автору." );
>
if ( DateTime .Now < this .StartDate)
throw new ApplicationException( string .Format( "Ваша копия программы не лицензирована!\nСрок действия лицензии еще не начался! Начало \nОбратитесь к автору." ,StartDate.ToShortDateString()));
if (App.Created > this .UpdateTo)
throw new ApplicationException( string .Format( "Ваша копия программы не лицензирована!\nВы не имеет право использовать это обновление.\nВы могли получать обновления до \nОбратитесь к автору." , UpdateTo.ToShortDateString()));
* This source code was highlighted with Source Code Highlighter .
Отрицательным может быть то, что разгадав SomePasswordKey, получив дизасемлированием код, злоумышленник может создать свой файл лицензии.
Положительным моментом может служить простота реализации, когда криптозащита не стоит на первом месте.
Disclaimer: всё ниженаписанное написано исключительно с просветительскими и исследовательскими целями, а также понимания механизмов защиты от взлома. Автор ни в коем случае не рекомендует использовать данную информацию для взлома программ.
Перейдём, собственно, к взлому.
0. Обнуление триала
Собственно, это даже не взлом, а полулегальный способ продлить срок использования неактивированной программы. Заключается он в том, что находится место, где хранится дата первого запуска и меняется/уничтожается. После этого всё можно пользоваться программой до следующего срока.
Посмотрим на нашего подопытного рефлектором. Немного погуляв по коду, находим интересную строчку в конструкторе MainForm:
Открываем редактор реестра, идём в HKEY_CURRENT_USER\Software\Ultrapico\Expresso и видим следующие ключи:
Удаляем их и получаем ещё 60 дней работы.
Данный вариант, конечно, прост и очевиден, но если он даже был бы сложнее — потребовалось бы чуть больше времени провести в рефлекторе, чтобы выяснить все места, куда пишется информация и зачистить их.
Совет разработчикам, которые будут пытаться записать данные в потаённое место: пишите аккуратнее, а то всё может обернуться проблемами обычным пользователям, у которых почему-то не окажется данного места, или не хватит на него прав.
1. Написание keygen'а
Самый ужасный для разработчика вариант, и самый приятный для конечного злобного пользователя. Программа считает себя лицензионной, никаких страшных телодвижений не нужно делать.
Открываем рефлектор и ищем код на предмет классов содержащих License или Registration, видим:
При вводе имени и кода по имени вычисляется некий хеш, который и сравнивается с кодом.
Данный хеш использует DES и всякие префиксы
Байты конвертятся в строку с помощью данного метода.
Теперь всё выяснилось, открываем IDE и копируем все необходимые куски кода (или сами реализовываем). Осталось только выяснить, какие значения у Prefix, Suffix и параметры реализации MyDES. Я их приводить не буду, это уже технические детали.
В результате генерируем ключ на любое имя и видим:
Защита от кейгенов проста и очевида: использовать в каком либо виде ассиметричное шифрование. Т.е. сделать так, чтобы без знания приватного ключа сгенерировать код было бы невозможно, а данный ключ находится только в одном месте — у автора программы.
2. Использование враппера
Проверка корректности лицензии, достаточно хлопотное дело, и небыстрое. Поэтому разработчики программ обычно проверяют лицензию один раз, и дальше используют полученный флажок — валидна/невалидна (как вариант насколько валидна, если допускается несколько типов лицензии, отличающихся возможностями). Тут можно на этом сыграть, использовав следующий алгоритм:
- Указать программе, что лицензия уже проверена
- Указать программе, что лицензия корректна
Воспользуемся этим. Сделаем новый проект, добавим Reference на Expresso.exe и запустим его через себя:
Смотрим, что получилось:
Ну кто бы сомневался.
В данном случае всё оказалось просто, но если бы автор программы заменил публичные свойства на приватные, то всего-лишь пришлось бы использовать Reflection для доступа и всё бы свелось к исходной задаче.
Думаю понятно, как можно пробовать защититься от этого — проверять лицензию периодически, смотреть окружение из которого запущена программа, сделать невозможным установку нужной переменной.
Но все эти защиты приведут к тому, что злоумышленник будет использовать
3. Физический взлом программы
Запускаем ildasm, открываем Expresso.exe и сохраняем дамп в .il файл. Находим уже рассмотренный метод IsRegistered и добавляем немножко своего кода (без меток):
Потом берём ilasm и собираем всё назад (не забыв подключить ресурсы).
Что делает данный код: устанавливает нужное имя для регистрации (не обязательно), и возвращает статус, что всё хорошо.
Т.е. вполне очевидно, что теперь всё будет хорошо:
Немного про код в MSIL: это стековая машина, у которой нет регистров, все операции имеют вид: засунуть в стек нужное количество параметров, выполнить функцию, которая заберёт нужное количество параметров и положит результат. Ну и обратно: установить значение переменной тем, что лежит в стеке. Чтобы лучше понять работу всего этого рекомендую простой приём: пишите маленькую программу на привычном языке, компилируете, смотрите что получилось в MSILe и разбираетесь в конструкциях языка.
Чем жертвует злоумышленник: подписью программы, теперь она уже не автора, а его. В некоторых случаях это проблема, если в программе используется множество библиотек. Тогда злобному хакеру придётся разбирать их все и собирать их заново, но если он с этим справится, то у него будет «своя» версия программы подписанная его ключом.
Защиты от всего этого безобразия собственно немного: проводить обфускацию или выносить часть логики/проверки защиты в нативный код.
Заключение
Создавая свое первое коммерческое приложение, я стал задумываться о системе, которая защитит его от несанкционированного копирования, и косвенно поможет мне контролировать его продажи. Сам я программист и не имею опыта в продажах, и на этапе распространения ПО, хотел привлекать для этого специально обученных людей. Для этого я разработал для своего ПО специальную систему лицензирования. Как выяснилось мне позже, Ваше ПО после создания никто продвигать не будет, пока оно не станет известным и без ошибок работающим. Так что надо учиться продавать так же хорошо, как и программировать. А система лицензирования – она осталась, и надеюсь, в будущем она еще сыграет свою роль в распространении ПО.
В общем, я и хочу поведать о системе лицензирования, которую я разработал для своего ПО. Вдруг какие-то идеи пригодятся кому-то для того чтобы получать больше денежек за свои приложения. Эта система не претендует за абсолютно защищенную, но это очень хорошая защита от дурака.
Давайте не будем делать из себя ангелочков и меценатов. Все программисты хотят получать достойный денежный эквивалент за свои программы.
Т.е. цели при создании системы лицензирования были такими:
1. Контроль установки ПО, бесплатного и не бесплатного
2. Возможность сделать ПО внезапно платным
3. Контроль функционала ПО
Тех. задание от самого себя самому себе ставилось такое:
4. ПО не должно работать не получив ключа активации
5. Ключ активации не должен храниться в дистрибутивах ПО и его нельзя просто вычислить (вычислить можно, но не просто)
6. ПО не должно запускаться, если его «пропатчить»
7. Ключ активации должен быть привязан только к одному работающему экземпляру ПО
8. Возможность менять ключи активации после обновления ПО
9. Возможность ограничивать действие ключа активации по времени
10. Ключ активации должен нести информацию об задействованных модулях в программе.
Сразу оговорюсь, что ПО, для которой разрабатывалась система лицензирования – программа для продаж. В ней используется СУБД MS SQL. Распространять это программное обеспечение планируется через интернет, как бесплатную версию и через продавцов за деньги. В бесплатной версии предполагается отключать некоторый функционал, и если клиент решает использовать полную версию, то он может ее приобрести.
Через некоторое время общая схема работы системы лицензирования стала такова:
Все начинается с того что пользователь получает ПО. ПО можно получить, загрузив его с сайта программы. Далее устанавливает его на своем сервере СУБД и рабочих станциях. После установки программа не запускается, а просит ввести ключ активации.
Вообще активация может выполняться двумя способами:
1. Активации ПО как бесплатного
2. Активация ПО, полученного через продавца
Прежде чем описать шаги по активации ПО, кратко опишу, как его сначала подготовить.
Перед тем как создать дистрибутив и начать распространять ПО, после компиляции в его бинарный файл и базу данных вносятся изменения и дополнительная информация. Это прежде всего версия ПО, и разрешения на запуск некоторых модулей. Так же шифруются критически важные для работы участки кода. Ключ шифрования известен только поставщику ПО, который создал релиз.
Ну а теперь сама активация. Механизм активации таков:
1. Клиент получает ПО
2. Установка ПО
3. Первый запуск ПО
4. Получение регистрационного кода программы
5. Получение кода активации
6. Перезапуск программы
Но для получения кода активации нужно регистрационный код программы сначала передать поставщику ПО. Код активации можно получить как с сервера активации, который расположен в интернете, так и вручную, связавшись с поставщиком ПО по почте или телефону.
По регистрационному коду программы создается код активации. Для этого исходными данными для получения кода активации служат переданные через регистрационный код: Релиз программы, номер жесткого диска или сетевой карты, ИД базы данных.
Так же для создания кода активации необходим ключ шифрования ПО. При активации как бесплатного ПО, через интернет, ключ шифрования «зашивается» в код активации через механизмы на сервере активации.
Если клиент получает код активации через продавца, то продавец потом запрашивает его у вас (т.е. поставщика ПО), чтобы потом передать его клиенту. Для одного приложения у меня процесс получения кода активации через продавца так же был автоматизирован. На каждого продавца в системе лицензирования заводился аккаунт, где он мог получать коды активации для ПО.
Здесь изображен интерфейс приложения, которое генерирует коды активации:
Интерфейс получения кода активации через интернет с ограничением функционала:
В полученном коде активации содержится ключ, по которому зашифрованы критически важные участки кода. Как только код активации попадает в базу данных программы, она начинает работать.
Вроде как идея проста, но реализовать это все оказалось немного сложнее, чем я рассчитывал. Особенно, наверное, потому что при реализации серверной части системы лицензирования мне пришлось познакомиться с особенностями создания расширений для PHP, «прокачаться» в программирование на Си, да и вообще узнать, что такое Unix платформа поближе (у хостинга, где размещается система лицензирования установлена FreeBSD). Это волшебный мир… Выбор в сторону Unix был сделан по экономическим соображениям. Хоститься на юниксе дешевле в 15 раз, чем на виндовс. Сервер стоит, и кушать не просит.
В системе лицензирования использовались библиотеки OpenSSL. Без шифрования никуда.
Это мой первый пост на хабре. Если у народа возникнут более конкретные технические вопросы по этой системе лицензирования, то я с удовольствием на них постараюсь ответить.
Всем побольше работающих приложений и побольше денюшек.
Спасибо за внимание.
Читайте также: