Как сделать лицензионный ключ
Как создать лицензионный ключ для своего приложения?
Как создать установщик для своего приложения
давно хочу написать установкщик,но весь гугл перерыв не нашел.вот все совреемнные установщики.
Как заменить ключ от своего приложения в Google Play?
При попытке публикации обновления для приложения у меня возникает ошибка, говорит что использованы.
Как создать окно справки для своего приложения?
подскажите, пожалуйста, леплю интерфейс, как подключить при нажатии f1 справку, или вообще как.
Лицензионный ключ для Каспера
Я Касперским мало пользовался, поэтому не знаю. Сначала я его установил, всё нормально работало.
Khaker_tt, вам нужен один ключ или механизм проверки правильности введенного ключа? Соответственно нужен и генератор ключа?
Какого вида ключ вы хотите создать? Дайте больше информации.
Yury Komar, Мне нужен механизм проверки правильности введенного ключа.
Добавлено через 35 минут
Допустим такой ключ GYH-NDJ-JDH-hjd-fjd.
Добавлено через 13 минут
то есть регистрация для своей программы.
Khaker_tt, а как вы создаете этот ключ? или это просто строка текста?
Решение
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 и проверяйте на совпадения какие-то конкретные части пароля.
Чтобы больше заработать сделай свое ПО лицензионным
Добрый день!
Создавая свое первое коммерческое приложение, я стал задумываться о системе, которая защитит его от несанкционированного копирования, и косвенно поможет мне контролировать его продажи. Сам я программист и не имею опыта в продажах, и на этапе распространения ПО, хотел привлекать для этого специально обученных людей. Для этого я разработал для своего ПО специальную систему лицензирования. Как выяснилось мне позже, Ваше ПО после создания никто продвигать не будет, пока оно не станет известным и без ошибок работающим. Так что надо учиться продавать так же хорошо, как и программировать. А система лицензирования – она осталась, и надеюсь, в будущем она еще сыграет свою роль в распространении ПО.
В общем, я и хочу поведать о системе лицензирования, которую я разработал для своего ПО. Вдруг какие-то идеи пригодятся кому-то для того чтобы получать больше денежек за свои приложения. Эта система не претендует за абсолютно защищенную, но это очень хорошая защита от дурака.
Давайте не будем делать из себя ангелочков и меценатов. Все программисты хотят получать достойный денежный эквивалент за свои программы.
Т.е. цели при создании системы лицензирования были такими:
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. Без шифрования никуда.
Это мой первый пост на хабре. Если у народа возникнут более конкретные технические вопросы по этой системе лицензирования, то я с удовольствием на них постараюсь ответить.
Всем побольше работающих приложений и побольше денюшек.
Спасибо за внимание.
Как создать и проверить лицензионный ключ программного обеспечения?
В настоящее время я занимаюсь разработкой продукта (разработанного на C #), который будет доступен для загрузки и установки бесплатно, но в очень ограниченной версии. Чтобы получить доступ ко всем функциям, пользователь должен оплатить лицензионный сбор и получить ключ. Затем этот ключ будет введен в приложение, чтобы «разблокировать» полную версию.
Так как использование лицензионного ключа вроде обычного, мне интересно:
Думаю, мне следует как-то привязать ключ к версии приложения, чтобы можно было взимать плату за новые ключи в версиях функций.
Что-нибудь еще, о чем я должен думать в этом сценарии?
Предостережение: вы не можете запретить пользователям пиратство, а только упрощают честным пользователям правильные действия.
Предполагая, что вы не хотите делать специальную сборку для каждого пользователя, тогда:
Но, повторюсь: это не предотвратит пиратство
Недавно я прочитал, что этот подход не очень криптографически обоснован. Но это решение уже слабое ( поскольку само программное обеспечение должно где-то включать секретный ключ ), поэтому я не думаю, что это открытие делает решение недействительным настолько, насколько оно возможно.
Просто подумал, что я действительно должен упомянуть об этом, хотя; если вы планируете извлечь что-то еще из этого, будьте осторожны.
Существует много способов создания лицензионных ключей, но очень немногие из них действительно безопасны. И очень жаль, потому что для компаний лицензионные ключи имеют почти такую же ценность, как реальные деньги.
В идеале вы хотели бы, чтобы ваши лицензионные ключи имели следующие свойства:
Только ваша компания должна иметь возможность генерировать лицензионные ключи для ваших продуктов, даже если кто-то полностью обратный инжиниринг ваших продуктов (что произойдет, я говорю из опыта). Запутывание алгоритма или скрытие ключа шифрования в вашем программном обеспечении действительно исключено, если вы серьезно относитесь к контролю лицензирования. Если ваш продукт успешен, кто-то сделает генератор ключей в течение нескольких дней с момента выпуска.
Лицензионный ключ должен использоваться только на одном компьютере (или, по крайней мере, вы должны быть в состоянии контролировать это очень жестко)
Лицензионный ключ должен быть коротким, его легко набирать или диктовать по телефону. Вы не хотите, чтобы каждый клиент звонил в службу технической поддержки, потому что он не понимает, содержит ли ключ «l» или «1». Ваш отдел поддержки поблагодарит вас за это, и у вас будет меньше затрат в этой области.
Итак, как вы решаете эти проблемы?
Ну, просто удалите лишние символы, такие как «1», «l», «0», «o» из ваших ключей. Разбейте строку лицензионного ключа на группы символов.
Не наказывайте честных клиентов с помощью системы, предназначенной для предотвращения хакеров, так как хакеры взломают ее независимо от этого.
Простой хешированный код, связанный с их электронной почтой или подобным, вероятно, достаточно хорош. Аппаратные идентификаторы всегда становятся проблемой, когда людям нужно переустанавливать или обновлять оборудование.
При генерации ключа не забудьте объединить версию и номер сборки со строкой, по которой вы вычисляете хеш. Таким образом, не будет ни одного ключа, который разблокирует все, что вы когда-либо выпускали.
После того, как вы обнаружите, что некоторые ключи или патчи плавают в astalavista.box.sk, вы узнаете, что вам удалось сделать что-то достаточно популярное, чтобы кто-то потрудился взломать. Радуйтесь!
Вы даже не можете использовать аппаратные значения для создания ключа больше. Виртуальные машины теперь позволяют кому-то создавать образ «лицензированной» машины и запускать его на любой платформе, которую они выберут.
Если это дорогое программное обеспечение, есть другие решения. Если это не так, просто сделайте это достаточно сложным для случайного хакера. И принять тот факт, что в конечном итоге будут нелицензионные копии.
Если ваш продукт сложный, проблемы, связанные с поддержкой, создадут вам некоторую защиту.
Он основан на системе «Partial Key Verification», которая означает, что в ваш дистрибутив должен быть скомпилирован только поднабор ключей, которые вы используете для генерации ключа. Вы сами создаете ключи, поэтому реализация лицензии уникальна для вашего программного обеспечения.
Как указано выше, если ваш код можно декомпилировать, то относительно легко обойти большинство систем лицензирования.
Преимущества сервера лицензионных ключей
Преимущества использования сервера лицензионных ключей:
Соображения
Хотя проверка лицензий в режиме онлайн дает вам больший контроль над каждым экземпляром приложения, подключение к Интернету не всегда присутствует (особенно если вы нацелены на крупные предприятия), поэтому нам необходим другой способ проверки лицензионного ключа.
Решение состоит в том, чтобы всегда подписывать ответ лицензионного ключа от сервера, используя криптосистему с открытым ключом, такую как RSA или ECC (возможно, лучше, если вы планируете работать на встроенных системах). Ваше приложение должно иметь только открытый ключ для проверки ответа лицензионного ключа.
Таким образом, в случае отсутствия подключения к Интернету, вы можете использовать предыдущий ответ лицензионного ключа. Убедитесь, что в ответе хранятся и дата, и идентификатор компьютера, и убедитесь, что он не слишком старый (например, вы разрешаете пользователям оставаться в автономном режиме не более 30 дней и т. Д.) И что ответ лицензионного ключа принадлежит правильному устройству.
Обратите внимание, что вы всегда должны проверять сертификат ответа лицензионного ключа, даже если вы подключены к Интернету, чтобы убедиться, что он не был изменен после того, как он покинул сервер (это все равно необходимо сделать, даже если ваш API к сервер лицензионных ключей использует https)
Защита секретных алгоритмов
В большинстве случаев цель любого решения по лицензированию программного обеспечения состоит в том, чтобы помочь честным людям быть честными (т. Е. Честные пользователи, которые готовы платить, не забывают платить по истечении пробного периода и т. Д.).
Реализация
Если вы не хотите реализовывать все самостоятельно, я бы порекомендовал взглянуть на этот учебник (часть Cryptolens )
Я использовал Crypkey в прошлом. Это один из многих доступных.
Вы можете защищать программное обеспечение только до определенной степени с любой схемой лицензирования.
Я не знаю, насколько тщательно вы хотите получить
Вы могли бы заставить программу прислать вам это и что-то еще (например, имя пользователя и MAC-адрес ник)
Вы вычисляете код на основе этого и отправляете им по электронной почте ключ обратно.
они не дадут им переключаться между машинами после того, как у них будет ключ.
Единственный способ сделать все, что вы просили, это потребовать доступ в Интернет и проверку с помощью сервера. Прикладная программа должна войти на сервер с ключом, а затем вам необходимо сохранить детали сеанса, такие как IP-адрес. Это предотвратит использование ключа на нескольких разных машинах. Это обычно не очень популярно среди пользователей приложения, и если это не очень дорогое и сложное приложение, оно того не стоит.
Вы можете просто получить лицензионный ключ для приложения, а затем проверить клиентскую сторону на предмет его пригодности, но его легко распространить среди других пользователей, и с помощью декомпилятора можно генерировать новые ключи.
По моему мнению, если вы не используете веб-лицензирование, нет никакой реальной причины для защиты программного обеспечения вообще. Из-за головной боли, которую может вызвать DRM, несправедливо по отношению к пользователям, которые фактически заплатили за это.
Я твердо верю, что только система лицензирования на основе криптографии с открытым ключом является правильным подходом, потому что вам не нужно включать в ваш исходный код важную информацию, необходимую для генерации лицензии.
Таким образом, используя webhooks, мы можем автоматизировать создание лицензий для новых клиентов. Так как насчет проверки лицензии в самом приложении? Это может быть сделано различными способами, но наиболее популярным является требование, чтобы ваш клиент ввел длинный лицензионный ключ в поле ввода, которое затем можно проверить; Я думаю, что это ужасный способ проверки лицензии в вашем приложении.
Какое преимущество это дает вам? Во-первых, это избавляет вас и ваших клиентов от необходимости отслеживать лицензионные ключи, поскольку все они обрабатываются за кулисами внутри их учетной записи пользователя, и самое главное: теперь вы можете предложить своим клиентам лицензию и машину для самообслуживания. активация! т. е. поскольку все их лицензии и машины связаны с их учетной записью пользователя, вы можете предложить им приобрести лицензию, когда они запустят ваше приложение на неизвестной машине.
Итак, мы внедрили тонну автоматизации в нашу систему лицензирования, мы можем лицензировать отдельные функции (то есть ограниченную или полную версию), мы предложили удивительный UX для наших клиентов, и мы также решили одну из главных причин для запросов поддержки: восстановление лицензионного ключа.
В любом случае, это долго, но, надеюсь, кому-то поможет!
Как создать ключ продукта для приложения C#?
Как создать ключ продукта для приложения C#?
Мне нужно создать ключ продукта (или лицензии), который я обновляю ежегодно. Кроме того, мне нужно создать один для пробных версий.
14 ответов
учитывайте также расходы на поддержку имея дело с пользователями, которые забыли свой ключ, и т. д.
edit: я просто хочу добавить, не вкладывайте слишком много времени в это или не думайте, что каким-то образом ваша запутанная схема будет другой и неразрушимой. Это не будет и не может быть до тех пор, пока люди контролируют оборудование и ОС, на которых работает ваша программа. Разработчики пытались придумать для этого все более сложные схемы, думая, что если они разработают для этого собственную систему, то она будет известна только им и поэтому «более безопасный». Но это действительно программный эквивалент попытки построить вечный двигатель. 🙂
Я всегда считал эту область слишком важной, чтобы доверять третьей стороне для управления безопасностью выполнения вашего приложения. Как только этот компонент треснул для одного приложения, он треснул для всех приложений. Это случилось с тактичные через пять минут после того, как они пошли с третьей стороной решения для 3ds Max лет назад. Хорошие времена!
серьезно, подумайте о том, чтобы прокатить свой собственный для полного контроля над твоим алгоритмом. Если вы это сделаете, рассмотрите возможность использования компонентов в вашем ключе по строкам:
затем контрольная сумма, черт возьми, из них и добавьте любое (обратимое) шифрование, которое вы хотите, чтобы сделать его сложнее взломать.
сделать пробный лицензионный ключ, просто установите значения для указанных выше значений, которые переводятся как «пробный режим.»
и поскольку теперь это, вероятно, самый важный код в вашем приложении / компании, поверх/вместо обфускации рассмотрите возможность размещения процедур дешифрования в собственном DLL-файле и просто P / Invoke к нему.
несколько компаний, в которых я работал, приняли обобщенные подходы к этому с большим успехом. Или, может быть, продукты не стоили взлома;)
Если вы спрашиваете о ключах, которые вы можете ввести, как ключи продукта Windows, то они основаны на некоторых проверках. Если вы говорите о ключах, которые вы должны скопировать вставить, то они основаны на цифровой подписи (шифрование закрытого ключа).
шифрование обычно строка информации о лицензии зашифрована с помощью закрытого ключа (== с цифровой подписью) и преобразована в в base64. Открытый ключ распространяется вместе с приложением. Когда строка Base64 поступает, она проверяется (==расшифровывается) открытым ключом, и если она найдена допустимой, продукт активируется.
является ли это тривиальным или трудно взломать, я не уверен, что это действительно имеет большое значение.
вероятность взлома вашего приложения намного больше пропорциональна его полезности, а не силе обработки ключа продукта.
лично я думаю, что есть два класса пользователей. Те, кто платит. Те, кто не знает. Те, которые это делают, скорее всего, сделают это даже с самой тривиальной защитой. Те, кто не будет ждать трещины или искать в другом месте. В любом случае, это не принесет тебе больше денег.
есть вариант лицензирование и защита программного обеспечения Microsoft (SLP) услуги, а также. Прочитав об этом, я действительно хотел бы использовать его.
Примечание: это единственный способ, которым я бы выпустил продукт с чувствительным кодом (например, ценным алгоритмом).
Я должен признать, что сделал бы что-то довольно безумное.
когда они находят и удаляют LicenseCheck, какое удовольствие будет следовать когда DLL запускается сегментация ошибка.
Если вы хотите простое решение только для создания и проверки серийных номеров, попробуйте Ellipter. Он использует криптографию эллиптических кривых и имеет функцию» дата истечения срока действия», поэтому вы можете создавать пробные версии или регистрационные ключи с ограниченным временем.
еще один хороший недорогой инструмент для ключей продукта и активации-это продукт под названием InstallKey. Взгляните на www.lomacons.com
фокус в том, чтобы иметь алгоритм, который знаете только вы (такой, что его можно декодировать на другом конце).
есть такие простые вещи, как»Выберите простое число и добавьте к нему магическое число»
более запутанные параметры, такие как использование асимметричного шифрования набора двоичных данных (которые могут включать уникальный идентификатор, номера версий и т. д.) и распространение зашифрованных данных в качестве ключа.
возможно, также стоит прочитать ответы на этот вопрос а также
для него доступны некоторые инструменты и API. Однако я не думаю, что вы найдете его бесплатно;)
один простой метод использует Глобальный Уникальный Идентификатор (GUID). GUID обычно хранятся в виде 128-битных значений и обычно отображаются в виде 32 шестнадцатеричных цифр с группами, разделенными дефисами, такими как <21EC2020-3AEA-4069-A2DD-08002B30309D>.
надеюсь, это поможет.
вы можете проверить LicenseSpot. Он обеспечивает:
Я собираюсь немного откинуться на отличный ответ @frankodwyer и копнуть немного глубже в онлайн-лицензировании. Я основатель кейген, лицензионный REST API, построенный для разработчиков.
поскольку вы упомянули, что хотите 2″ типа «лицензий для вашего приложения, то есть» полная версия «и» пробная версия», мы можем упростить это и использовать модель лицензии функции где вы лицензируете специфические особенности вашего приложения (в этом случае «полный» набор функций и» пробный » набор функций).
для начала, мы могли бы создать 2 типы лицензий (под названием политика в Keygen) и всякий раз, когда пользователь регистрирует учетную запись, вы можете создать «пробную» лицензию для них, чтобы начать («пробная» лицензия осуществляет наша «пробная» политика функций), которую вы можете использовать для различных проверок в приложении, например, может ли пользователь использовать Trial-Feature-A и Trial-Feature-B.
и основываясь на этом, всякий раз, когда пользователь покупки приложения (используете ли вы PayPal, Stripe и т. д.), вы можете создать лицензию, реализующую» полную » политику функций, и связать ее с счета. Теперь в вашем приложении вы можете проверить, есть ли у пользователя» полная » лицензия, которая может сделать Pro-Feature-X и Pro-Feature-Y (делая что-то вроде user.HasLicenseFor(FEATURE_POLICY_ID) ).
I упомянуто, позволяя пользователям создавать учетные записи пользователей-что я хочу этим сказать? Я пошел в эту деталь в пара других ответов, но краткое изложение того, почему я думаю, что это превосходный способ аутентификации и идентификации ваших пользователей:
конечно, если вы не хочу для обработки учетных записей пользователей и вы хочу пользователи для ввода лицензионных ключей, это совершенно нормально (и keygen поддерживает это также). Я просто предлагаю другой способ справиться с этим аспектом лицензирования и, надеюсь, предоставить хороший UX для ваших клиентов.
наконец, поскольку вы также упомянули, что хотите обновить эти лицензии ежегодно, вы можете установить продолжительность в ваших политиках, так что» полные «лицензии истекают через год, а» пробные » лицензии длятся, скажем, 2 недели, требуя, чтобы ваши пользователи покупали новую лицензию после истечения срока действия.
Я мог бы покопаться в большем, связывая машины с пользователями и тому подобное, но я думал, что попытаюсь сохранить этот ответ коротким и сосредоточиться на просто лицензировании функций для ваших пользователей.