Как я могу сделать свой продукт в качестве пробной версии на 30 дней?
Я создал свой продукт, а также сгенерировал лицензионный ключ для этого, но я хочу спросить этот ключ через 30 дней. Я сделал это со значением реестра, сохраняя дату с добавлением 30 дней в этом. Но я обнаружил, что если пользователь изменит системную дату за 30 дней до того, моя логика не сработает.
Так есть ли какое-либо решение для пробной версии программного обеспечения без проверки системной даты и разрешения только на 30 дней пробной версии?
11 ответов
У вас может быть другой ключ реестра, который вы увеличиваете после каждодневного использования. Таким образом, даже если они изменят дату компьютера, этот ключ будет указывать вашей программе, что она работает> 30 дней.
Кроме того, это значение может быть зашифровано, так что если пользователь попытается изменить его вручную, программа может отказать в запуске, поскольку она не смогла расшифровать значение и получить из него действительное число.
Чтобы обойти переустановки, вы можете добавить некоторую информацию в любой файл, сохраненный с пробной версией вашего приложения, который является уникальным для этой конкретной версии приложения (возможно, отметка времени с момента его установки). Когда пробная версия вашего приложения пытается открыть файл, он проверит эту подпись и убедится, что она была создана с тем же экземпляром, в противном случае откажется открывать файл. Это, по сути, лишает возможности просто переустанавливать приложение и продолжать его использовать.
В конце концов, однако, пользователь имеет полный контроль над своим компьютером и, вероятно, может найти способ обойти то, что вы хотите сделать (если не получить доступ к веб-службе, где эти данные хранятся, прежде чем позволить пользователю использовать приложение). Вы, вероятно, не должны тратить столько энергии, пытаясь остановить парней, которые хотят пройти через эту дополнительную проблему, а вместо этого тратить это дополнительное время / деньги / энергия на улучшение приложения для тех, кто готов платить.
Вы можете использовать компонент лицензирования. Вы можете сделать его самостоятельно (см. Класс LicenseManager) или купить его у поставщика (например, CryptoLicensing).
У меня есть одно простое решение для вас.
Возьмите 2 переменные для реестра: 1. дата 2. счетчик
шаги:
Установить счетчик = 1
Скопировать системную дату в дату
Проверяйте каждый раз, если дата отличается от текущей даты, чем копируйте эту дату в дату реестра, также увеличивайте счетчик на 1. Если дата такая же, ничего не делайте.
Теперь вы можете проверить счетчик на истечение пробных дней
Используя этот трюк, если пользователь меняет системную дату на предыдущую, то это также работает.
Для реестра вы можете зашифровать дату и счетчик, чтобы технический специалист не распознал вашу логику!
ура...
ADDED
Эта логика не работает, только если пользователь не меняет дату для каждого дня! Опять же, у нас есть решение для этого!
Я не знаю, возможно ли это или нет, но у вас всегда может быть какое-то решение:
- Подсчитайте общее время пробного периода и сохраните его в реестре.
- Теперь посчитайте общее время каждого прогона и добавьте его в другую переменную. (Надеюсь, что это можно сделать по таймеру)
- Сравните выше два значения для принятия решения об истечении срока.
У вас должен быть способ определить, меняет ли пользователь дату, когда вы впервые запустили пробную версию. В решениях, которые я использовал ранее, мы сохранили дату "последнего исполнения" и дату "первого исполнения", и если часы меняются на более чем два дня "последнего исполнения", мы прекращаем пробную версию. Вам также нужен счетчик дней исполнения, чтобы они не могли перемещать дату на два дня назад (забыл упомянуть эту часть) - счетчик увеличивается при каждом выполнении.
Конечно, таких систем лицензирования программного обеспечения всегда можно избежать, удаляя и переустанавливая с соответствующим обновлением реестра - хитрость заключается в запутывании и дублировании информации о лицензии, чтобы сделать это затруднительным, но в конечном итоге это будет найдено (особенно если вы используя необоснованную кодовую базу.NET).
Трудно обрабатывать 30 дней без привязки к системной дате / часам. Вы всегда можете сохранить список дат, в которые приложение было запущено, и считать 1 для каждого раза, когда оно отличалось от прошлого раза. Таким образом, ваш пользователь должен будет устанавливать одну и ту же дату каждый раз, когда он запускает ваше приложение.
Помимо этого, вы могли бы, при наличии доступа в Интернет, запросить известный сервер времени для текущей даты. Это можно обойти, отключив, но вы всегда можете потребовать подключения к Интернету, прежде чем ваше приложение запустится.
Наконец, внешний локальный источник времени с помощью аппаратного ключа или аналогичного устройства, но я думаю, что вы попадаете в крайность, когда вам будет лучше напрямую управлять испытаниями лично.
Вы можете использовать бесплатный проект Libprot. Сайт https://github.com/libprot/trunk.
Идея заключается в том, что он должен быть простым и легким в использовании. Вы можете потратить $$$ на защиту, но она может быть взломана за одну неделю. Если кто-то хочет сделать реверс-инжиниринг вашего кода, никто не сможет его остановить. Мой совет использовать простые методы, которые работают.
Напишите строку как:
Компания X|10.2.2014|1.12.2015
где 10.2.2014 - текущая дата, и если системное время меньше, то кто-то изменил системные часы => мы не должны запускаться
1.12.2015 - до какого времени ключ действителен
и название компании, которая купила / загрузила его.
эта строка должна быть запутана асимметричным алгоритмом с закрытым / открытым ключом и закодирована в строку, которую вы можете отправить, например, по электронной почте.
Вы также можете иметь какой-то веб-сервис для проверки. при подключении к Интернету вы можете подтвердить ключ, если он взломан и доступен для общественности в Интернете, вы можете запретить его. Или, если кто-то напишет генератор ключей, вы можете проверить, что ключ реален.
Вы можете добавить на свой сайт скрипт PHP/java для автоматической отправки пробных кодов.
Это простая дата окончания оценки магазина и проверяйте ее каждый день. Чтобы избежать длительного использования манипуляций с датами, ведите счетчик часов в приложении; продолжайте увеличивать и записывать его в реестр. Следует проверить как дату окончания оценки, так и количество часов, которое не должно превышать 24 (может быть 30 с некоторой вероятностью).
Подумайте также о:
Сохраняя DateTime закрытия приложения, в следующий раз, когда оно будет запущено, ваше приложение сможет определить, был ли параметр Datetime изменен или нет (по крайней мере, они не могут изменить его до чего-то до времени закрытия). Пример:
При закрытии приложения:
Экономия времени => 15:34 31.03.2014 (сохранено)
Следующий запуск приложения:
Проверьте Datime.Now > 15:34 31.03.2014. (поэтому они не могут пойти ниже этого...)
ДОБАВЛЕНО:
Попробуйте как-то интегрировать настройки системы datetime в ваше приложение: Генерация счетов, билетов, квитанций... что угодно!
Если допустимо разрешить, например, 8 часов пробного использования (вместо 30-дневного пробного периода), то одним из способов устранить зависимость от System DateTime является использование в вашем приложении таймера, который срабатывает, скажем, каждую минуту. Подсчитайте их, и поэтому каждый раз, когда приложение запускается, оно накапливает общее количество минут использования. Затем вы можете сохранить это значение где-нибудь, например, в реестре.
ЕСЛИ вы можете гарантировать подключение к Интернету, вы можете реализовать онлайн-схему (проверьте сервер времени или свой собственный сервер аутентификации). Конечно, это вводит другую зависимость - если интернет исчезнет, ваши пользователи не смогут работать.
В конечном счете, я бы сказал, что купите стороннее решение по лицензированию - оно все еще не сломано, но, вероятно, оно будет более надежным, чем то, что вы можете сделать самостоятельно, не тратя много времени и сил.
Сохраните дату последнего запуска, и всякий раз, когда системная дата предшествует этому, истекает пробная версия.
Единственный отказоустойчивый метод - это проверка приложения по службе, которую вы размещаете, при условии, что никто не взломал ваш код подключения;)
Пока они могут очистить значение реестра / файл изолированного хранилища / сохраненные настройки: они могут просто перезапустить пробную версию. С этим мало что можно сделать. Вот почему люди выбирают ограниченную функциональность в пробном программном обеспечении в дополнение к основанному на времени испытательному периоду.