Как я могу сделать свой продукт в качестве пробной версии на 30 дней?

Question

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

Так есть ли какое-либо решение для пробной версии программного обеспечения без проверки системной даты и разрешения только на 30 дней пробного использования?

Answer 1

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

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

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

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

Answer 2

У меня есть одно простое решение для вас.

Взять 2 переменные для реестра: 1. дата 2. счетчик

шаги:

1. Установить счетчик = 1

2. Копирование системной даты на дату

3. Проверяйте каждый раз, если дата отличается от текущей даты, чем копируйте эту дату в дату реестра, также увеличивайте счетчик на 1. Если дата такая же, ничего не делайте.

4. Теперь вы можете проверить счетчик на истечение пробных дней

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

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

веселит ...

ДОБАВЛЕНО

Эта логика не работает, только если пользователь не меняет дату для каждого дня! Опять же, у нас есть решение для этого!

Я не знаю, возможно ли это или нет, но у вас всегда может быть какое-то решение:

1. подсчитайте общее время пробного периода и сохраните его в реестре.
2. Теперь посчитайте общее время каждого прогона и добавьте его в другую переменную. (Надеюсь, что это можно сделать по таймеру)
3. Сравните два значения для принятия решения об истечении срока действия.

Answer 3

Вы можете использовать компонент лицензирования. Вы можете сделать его самостоятельно (см. LicenseManager class ) или купить его у поставщика (например, CryptoLicensing ).

Answer 4

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

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

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

Answer 5

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

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

Answer 6

Вы можете использовать бесплатный проект Libprot. Сайт https://github.com/libprot/trunk.

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

Напишите строку вроде:

Компания X | 10.2.2014 | 1.12.2015

где 10.2.2014 - текущая дата, и если системное время меньше, тогда кто-то изменил системные часы => мы не должны запускать

1.12.2015 - до какого времени ключ действителен

и название компании, которая купила / загрузила его.

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

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

Вы можете добавить на свой сайт скрипт PHP / java для автоматической отправки пробных кодов.

Answer 7

Думайте также о:

Сохраняя DateTime закрытия приложения, в следующий раз, когда оно будет запущено, ваше приложение сможет определить, был ли параметр Datetime изменен или нет (по крайней мере, они не могут изменить его до чего-то до времени закрытия). Пример:

При закрытии заявки:

Экономия времени => 15:34 31.03.2014 (Сохранено)

Следующий запуск приложения:

Проверьте Datime.Now> 15:34 31.03.2014. (поэтому они не могут пойти ниже этого ...)

ДОБАВЛЕНО:

Попробуйте как-то интегрировать настройки системы datetime в ваше приложение: Генерация счетов, билетов, квитанций ... что угодно!

Answer 8

Это простая дата окончания оценки магазина и проверяйте ее каждый день. Чтобы избежать длительного использования манипуляций с датами, ведите счет часов в приложении продолжайте увеличивать и записывать его в реестр. Проверку следует проводить как по дате окончания оценки, так и по количеству часов, которое не должно превышать 24 (может быть 30 с некоторой вероятностью).

Answer 9

Если допустимо разрешить, например, 8 часов пробного использования (вместо 30-дневного пробного периода), то одним из способов устранения зависимости от System DateTime является использование в приложении таймера, который срабатывает, например, каждую минуту. Подсчитайте их, и поэтому каждый раз, когда приложение запускается, оно накапливает общее количество минут использования. Затем вы можете сохранить это значение где-нибудь, например, в реестре.

Answer 10

Сохраните дату последнего запуска, и всякий раз, когда системная дата предшествует этому, истекает пробная версия.

Единственный отказоустойчивый метод - проверка приложения по службе, которую вы размещаете, при условии, что никто не взломал ваш код подключения;)

Пока они могут очистить значение реестра / файл изолированного хранилища / сохраненные настройки: они могут просто перезапустить пробную версию. С этим мало что можно сделать. Вот почему люди выбирают ограниченную функциональность в пробном программном обеспечении в дополнение к основанному на времени испытательному периоду.