VMProtect Software » Forum

Добрый день!
Тестируем Demo-версию VMProtect Ultimate v.3.2.0 с целью выяснить подходит он нам или нет.
Нам необходимо выписывать ограниченные по времени лицензии на наш продукт. У в VMProtect такая функциональность кончено есть и все хорошо работает: до Expiration Date программа запускается, после Expiration Date говорит, что лицензия истекла и не запускается. Но как показали тесты под Windows 10, достаточно перевести системное время на компьютере назад и защита снова думает, что лицензия валидна и запускает программу. Вопрос: я что-то не так сделал, выставил не все опции, не сказал секретные слова? Или же это поведение by design? Если так, то как все-таки защититься от "отмотки" системного времени?

Вам необходимо это для реализации триала?

Триал подразумевает наличие некой скрытой метки при первом запуске проги (метка в реестре или файле). Естественно её можно элементарно отследить (filemon, regmon). Поэтому защита триалом не очень эффективна.
Если уж и нужен триал, то метку надо не просто выставлять (запись в ветку реестра или файл даты первого запуска проги), а встраивать её в обрабатываемые данные (например базу данных) и при этом её (базу данных) полностью перешифровывать, чтобы не было явных следов этой метки (она будет как-бы размазана в зашифрованных данных).
При этом, естественно, функцию работы с базой данных и функцию шифрования надо виртуализировать на максимальных настройках (режим ULTRA http://vmpsoftware.com/products/matrix/#ultra)

Admin wrote:Вам необходимо это для реализации триала?

Да, нам это нужно для реализации полнофункционального триала.
Требование такие: триал должен быть привязан к конкретному компьютеру (Hardware ID), ограничен по времени (Expiration Date), и не должен запускаться на виртуальных машинах.
Причем нестрашно, если какой-нибудь продвинутый пользователь отломает себе ограничение по времени. Главное чтобы такой сломанный триал запускался только у него на машине. Но хотелось бы, чтобы для снятия ограничения по времени, нужно было бы поработать чуть больше, чем перевести системное время. Вместе с тем требование не запускаться на виртуалках становится ещё более серьёзным, т.к. отломанная expiration date на виртуалке – это уже очень неприятно.
Можно ли реализовать что-то подобное с помощью VMProtect?

horek wrote:Триал подразумевает наличие некой скрытой метки при первом запуске проги (метка в реестре или файле). Естественно её можно элементарно отследить (filemon, regmon). Поэтому защита триалом не очень эффективна.
Если уж и нужен триал, то метку надо не просто выставлять (запись в ветку реестра или файл даты первого запуска проги), а встраивать её в обрабатываемые данные (например базу данных) и при этом её (базу данных) полностью перешифровывать, чтобы не было явных следов этой метки (она будет как-бы размазана в зашифрованных данных).
При этом, естественно, функцию работы с базой данных и функцию шифрования надо виртуализировать на максимальных настройках (режим ULTRA http://vmpsoftware.com/products/matrix/#ultra)

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

mike wrote:Можно ли реализовать что-то подобное с помощью VMProtect?

Да, это все можно реализовать с помощью VMProtect. Для генерации триальных серийников мы рекомендуем использовать систему активации. Т.е. у вас в программе уже будет зашит триальный код активации, по которому пользователь получит серийный номер, ограниченный по времени использования с привязкой к HWID. Для этого в WebLM нужно будет добавить продукт, затем добавить к нему мод, у которого установить "ID компьютера = из URL", "Дата окончания = XX дней с даты активации", затем добавить код активации для этого мода. По поводу перевода времени - здесь тоже возможен вариант, при котором программа на старте лезет в инет за "правильной" датой и эту дату использует для проверки ограничений серийного номера (для этого достаточно вызывать VMProtectActivateLicense + VMProtectSetSerialNumber).

mike wrote:Метки в файле или реестре с датой первого запуска, подозреваю, будет недостаточно.

вполне достаточно. Но... (см. ниже жирным шрифтом).

mike wrote:Нужно как-то отслеживать, что пользователь не перевел дату назад.

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

Есть другой способ, который указал Admin (использовать API VMProtect). Но в этом случае нужен доступ в сеть.

Вариантов предостаточно.

Admin wrote:

mike wrote:Можно ли реализовать что-то подобное с помощью VMProtect?

Да, это все можно реализовать с помощью VMProtect. Для генерации триальных серийников мы рекомендуем использовать систему активации. Т.е. у вас в программе уже будет зашит триальный код активации, по которому пользователь получит серийный номер, ограниченный по времени использования с привязкой к HWID. Для этого в WebLM нужно будет добавить продукт, затем добавить к нему мод, у которого установить "ID компьютера = из URL", "Дата окончания = XX дней с даты активации", затем добавить код активации для этого мода. По поводу перевода времени - здесь тоже возможен вариант, при котором программа на старте лезет в инет за "правильной" датой и эту дату использует для проверки ограничений серийного номера (для этого достаточно вызывать VMProtectActivateLicense + VMProtectSetSerialNumber).

Спасибо за ответ. Я протестировал описанный Вами сценарий в WebLM. Всё работает примерно так, как нам хочется, за исключением одного момента. VMProtectActivateLicense действительно проверяет дату на стороне сервера. Но для ранее активированного кода активации этой проверки не производится.
Поясню. Выписали мы код активации с "датой окончания", например, 12 февраля. Если клиент, до 12 февраля не активирует этот код, то он его не активирует никогда. Откручивай он у себя дату, не откручивай - WebLM при активации сверяет "дату окончания" активационного кода с текущей датой на своей стороне и серийный номер не выдает, возвращая ACTIVATION_EXPIRED. Все хорошо, все логично. Но если клиент активировал код на конкретном компьютере 11 февраля, то последующий вызов VMProtectActivateLicense с этого компьютера завершается успешно в любую дату, хоть 12 февраля, хоть 5-го марта. Я так понимаю, что WebLM сверяет переданный HWID с уже выписанными серийниками для этого кода, и если находит серийник выписанный для этого HWID, возвращает его, не проверяя "дату окончания" активационного кода. Нам как раз хотелось бы, чтобы проверка производилась и в этом случае тоже.
Вопрос: это поведение "by design" или же вы сможете поправить это в следующих версиях?

horek wrote:

mike wrote:Метки в файле или реестре с датой первого запуска, подозреваю, будет недостаточно.

вполне достаточно. Но... (см. ниже жирным шрифтом).

mike wrote:Нужно как-то отслеживать, что пользователь не перевел дату назад.

Нужно фиксировать 2 отметки на компьютере юзера (дату первого запуска и текущую дату), при этом обе шифровать вместе с данными. Далее проверять разность между ними и если она превысила порог - выдать сообщение или прекратить работу. Но это уже код программиста. Такой способ сгодится для локального отслеживания.
Есть другой способ, который указал Admin (использовать API VMProtect). Но в этом случае нужен доступ в сеть.

Вариантов предостаточно.

На мой взгляд вариантов совсем немного.
Способ с использованием сети годный, но не совсем гуманный для пользователей.
А описанный Вами метод, к сожалению, в применении к ограничению по "expiration date" нерабочий.
Допустим выписал я лицензию на месяц. Пользователь установил её, запустил программу. В этот момент я зафиксировал эту дату и сохранил в суперзашифрованном виде, перемешав с некими "данными". Каждую неделю пользователь отматавает часы на неделю назад. Разность между текущей датой и "датой первого запуска" : 0 - 7 дней. Порога в 30 дней эта разность никогда не достигнет.

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

Мы говорим про разные даты окончания. Прочитайте мое сообщение еще раз:

Для этого в WebLM нужно будет добавить продукт, затем добавить к нему мод, у которого установить "ID компьютера = из URL", "Дата окончания = XX дней с даты активации",

Дата окончания в коде активации и в моде - это разные вещи. Дата окончания в моде пропишется в серийный номер при активации (мод - это что-то типа шаблона для генерации конечного серийника).

Admin wrote:Мы говорим про разные даты окончания. Прочитайте мое сообщение еще раз:

Для этого в WebLM нужно будет добавить продукт, затем добавить к нему мод, у которого установить "ID компьютера = из URL", "Дата окончания = XX дней с даты активации",

Дата окончания в коде активации и в моде - это разные вещи. Дата окончания в моде пропишется в серийный номер при активации (мод - это что-то типа шаблона для генерации конечного серийника).

Я в курсе про две разные даты окончания.
Я конечно выставил 'expiration date' в моде тоже (1 день с даты активации в моем случае). Это первое с чего я начал.
Идея была чтобы VMProtectActivateLicense сверялся с датой на своей стороне и не выдавал лицензии вообще если "время уже вышло" в некотором смысле:

Admin wrote: По поводу перевода времени - здесь тоже возможен вариант, при котором программа на старте лезет в инет за "правильной" датой и эту дату использует для проверки ограничений серийного номера (для этого достаточно вызывать VMProtectActivateLicense + VMProtectSetSerialNumber).

Но VMProtectActivateLicense эту дату никак не проверяет, просто выписывает лицензию ограниченную по времени на 1 день от момента активации. Да и не может он её проверить, ведь я задал дату окончания лицензии, относительно даты активации.
Кстати я не попробовал задать ограничение по дате в явном виде - например 13 февраля. Было бы классно, если бы VMProtectActivateLicense отказался выдавать лицензию, если эта дата уже в прошлом. Это решило бы проблему.

Потом я обнаружил что у ActivationCode тоже есть 'дата окончания'. Её то уж VMProtectActivateLicense точно должен проверять. И проверяет, за исключением того момента, о котором я писал в предыдущем сообщении.