Добрый день!
Тестируем Demo-версию VMProtect Ultimate v.3.2.0 с целью выяснить подходит он нам или нет.
Нам необходимо выписывать ограниченные по времени лицензии на наш продукт. У в VMProtect такая функциональность кончено есть и все хорошо работает: до Expiration Date программа запускается, после Expiration Date говорит, что лицензия истекла и не запускается. Но как показали тесты под Windows 10, достаточно перевести системное время на компьютере назад и защита снова думает, что лицензия валидна и запускает программу. Вопрос: я что-то не так сделал, выставил не все опции, не сказал секретные слова? Или же это поведение by design? Если так, то как все-таки защититься от "отмотки" системного времени?
Date tampering
Re: Date tampering
Вам необходимо это для реализации триала?
Re: Date tampering
Триал подразумевает наличие некой скрытой метки при первом запуске проги (метка в реестре или файле). Естественно её можно элементарно отследить (filemon, regmon). Поэтому защита триалом не очень эффективна.
Если уж и нужен триал, то метку надо не просто выставлять (запись в ветку реестра или файл даты первого запуска проги), а встраивать её в обрабатываемые данные (например базу данных) и при этом её (базу данных) полностью перешифровывать, чтобы не было явных следов этой метки (она будет как-бы размазана в зашифрованных данных).
При этом, естественно, функцию работы с базой данных и функцию шифрования надо виртуализировать на максимальных настройках (режим ULTRA http://vmpsoft.com/products/matrix/#ultra)
Если уж и нужен триал, то метку надо не просто выставлять (запись в ветку реестра или файл даты первого запуска проги), а встраивать её в обрабатываемые данные (например базу данных) и при этом её (базу данных) полностью перешифровывать, чтобы не было явных следов этой метки (она будет как-бы размазана в зашифрованных данных).
При этом, естественно, функцию работы с базой данных и функцию шифрования надо виртуализировать на максимальных настройках (режим ULTRA http://vmpsoft.com/products/matrix/#ultra)
Re: Date tampering
Да, нам это нужно для реализации полнофункционального триала.Admin wrote:Вам необходимо это для реализации триала?
Требование такие: триал должен быть привязан к конкретному компьютеру (Hardware ID), ограничен по времени (Expiration Date), и не должен запускаться на виртуальных машинах.
Причем нестрашно, если какой-нибудь продвинутый пользователь отломает себе ограничение по времени. Главное чтобы такой сломанный триал запускался только у него на машине. Но хотелось бы, чтобы для снятия ограничения по времени, нужно было бы поработать чуть больше, чем перевести системное время. Вместе с тем требование не запускаться на виртуалках становится ещё более серьёзным, т.к. отломанная expiration date на виртуалке – это уже очень неприятно.
Можно ли реализовать что-то подобное с помощью VMProtect?
Re: Date tampering
Метки в файле или реестре с датой первого запуска, подозреваю, будет недостаточно. Нужно как-то отслеживать, что пользователь не перевел дату назад. Я, конечно, могу что-нибудь навелосипедить на эту тему и прикрыть виртуализацией. Но, может быть, есть какие-нибудь общепринятые методики?horek wrote:Триал подразумевает наличие некой скрытой метки при первом запуске проги (метка в реестре или файле). Естественно её можно элементарно отследить (filemon, regmon). Поэтому защита триалом не очень эффективна.
Если уж и нужен триал, то метку надо не просто выставлять (запись в ветку реестра или файл даты первого запуска проги), а встраивать её в обрабатываемые данные (например базу данных) и при этом её (базу данных) полностью перешифровывать, чтобы не было явных следов этой метки (она будет как-бы размазана в зашифрованных данных).
При этом, естественно, функцию работы с базой данных и функцию шифрования надо виртуализировать на максимальных настройках (режим ULTRA http://vmpsoft.com/products/matrix/#ultra)
Re: Date tampering
Да, это все можно реализовать с помощью VMProtect. Для генерации триальных серийников мы рекомендуем использовать систему активации. Т.е. у вас в программе уже будет зашит триальный код активации, по которому пользователь получит серийный номер, ограниченный по времени использования с привязкой к HWID. Для этого в WebLM нужно будет добавить продукт, затем добавить к нему мод, у которого установить "ID компьютера = из URL", "Дата окончания = XX дней с даты активации", затем добавить код активации для этого мода. По поводу перевода времени - здесь тоже возможен вариант, при котором программа на старте лезет в инет за "правильной" датой и эту дату использует для проверки ограничений серийного номера (для этого достаточно вызывать VMProtectActivateLicense + VMProtectSetSerialNumber).mike wrote:Можно ли реализовать что-то подобное с помощью VMProtect?
Re: Date tampering
вполне достаточно. Но... (см. ниже жирным шрифтом).mike wrote:Метки в файле или реестре с датой первого запуска, подозреваю, будет недостаточно.
Нужно фиксировать 2 отметки на компьютере юзера (дату первого запуска и текущую дату), при этом обе шифровать вместе с данными. Далее проверять разность между ними и если она превысила порог - выдать сообщение или прекратить работу. Но это уже код программиста. Такой способ сгодится для локального отслеживания.mike wrote:Нужно как-то отслеживать, что пользователь не перевел дату назад.
Есть другой способ, который указал Admin (использовать API VMProtect). Но в этом случае нужен доступ в сеть.
Вариантов предостаточно.
Re: Date tampering
Спасибо за ответ. Я протестировал описанный Вами сценарий в WebLM. Всё работает примерно так, как нам хочется, за исключением одного момента. VMProtectActivateLicense действительно проверяет дату на стороне сервера. Но для ранее активированного кода активации этой проверки не производится.Admin wrote:Да, это все можно реализовать с помощью VMProtect. Для генерации триальных серийников мы рекомендуем использовать систему активации. Т.е. у вас в программе уже будет зашит триальный код активации, по которому пользователь получит серийный номер, ограниченный по времени использования с привязкой к HWID. Для этого в WebLM нужно будет добавить продукт, затем добавить к нему мод, у которого установить "ID компьютера = из URL", "Дата окончания = XX дней с даты активации", затем добавить код активации для этого мода. По поводу перевода времени - здесь тоже возможен вариант, при котором программа на старте лезет в инет за "правильной" датой и эту дату использует для проверки ограничений серийного номера (для этого достаточно вызывать VMProtectActivateLicense + VMProtectSetSerialNumber).mike wrote:Можно ли реализовать что-то подобное с помощью VMProtect?
Поясню. Выписали мы код активации с "датой окончания", например, 12 февраля. Если клиент, до 12 февраля не активирует этот код, то он его не активирует никогда. Откручивай он у себя дату, не откручивай - WebLM при активации сверяет "дату окончания" активационного кода с текущей датой на своей стороне и серийный номер не выдает, возвращая ACTIVATION_EXPIRED. Все хорошо, все логично. Но если клиент активировал код на конкретном компьютере 11 февраля, то последующий вызов VMProtectActivateLicense с этого компьютера завершается успешно в любую дату, хоть 12 февраля, хоть 5-го марта. Я так понимаю, что WebLM сверяет переданный HWID с уже выписанными серийниками для этого кода, и если находит серийник выписанный для этого HWID, возвращает его, не проверяя "дату окончания" активационного кода. Нам как раз хотелось бы, чтобы проверка производилась и в этом случае тоже.
Вопрос: это поведение "by design" или же вы сможете поправить это в следующих версиях?
Re: Date tampering
На мой взгляд вариантов совсем немного.horek wrote:вполне достаточно. Но... (см. ниже жирным шрифтом).mike wrote:Метки в файле или реестре с датой первого запуска, подозреваю, будет недостаточно.Нужно фиксировать 2 отметки на компьютере юзера (дату первого запуска и текущую дату), при этом обе шифровать вместе с данными. Далее проверять разность между ними и если она превысила порог - выдать сообщение или прекратить работу. Но это уже код программиста. Такой способ сгодится для локального отслеживания.mike wrote:Нужно как-то отслеживать, что пользователь не перевел дату назад.
Есть другой способ, который указал Admin (использовать API VMProtect). Но в этом случае нужен доступ в сеть.
Вариантов предостаточно.
Способ с использованием сети годный, но не совсем гуманный для пользователей.
А описанный Вами метод, к сожалению, в применении к ограничению по "expiration date" нерабочий.
Допустим выписал я лицензию на месяц. Пользователь установил её, запустил программу. В этот момент я зафиксировал эту дату и сохранил в суперзашифрованном виде, перемешав с некими "данными". Каждую неделю пользователь отматавает часы на неделю назад. Разность между текущей датой и "датой первого запуска" : 0 - 7 дней. Порога в 30 дней эта разность никогда не достигнет.
Этот подход мог бы сработать для ограничения по количеству запусков. Но этот счетчик тогда, действительно, пришлось бы прятать внутри "данных" программы, что реализуемо далеко не для любой программы.
Re: Date tampering
Мы говорим про разные даты окончания. Прочитайте мое сообщение еще раз:
Дата окончания в коде активации и в моде - это разные вещи. Дата окончания в моде пропишется в серийный номер при активации (мод - это что-то типа шаблона для генерации конечного серийника).Для этого в WebLM нужно будет добавить продукт, затем добавить к нему мод, у которого установить "ID компьютера = из URL", "Дата окончания = XX дней с даты активации",
Re: Date tampering
Я в курсе про две разные даты окончания.Admin wrote:Мы говорим про разные даты окончания. Прочитайте мое сообщение еще раз:Дата окончания в коде активации и в моде - это разные вещи. Дата окончания в моде пропишется в серийный номер при активации (мод - это что-то типа шаблона для генерации конечного серийника).Для этого в WebLM нужно будет добавить продукт, затем добавить к нему мод, у которого установить "ID компьютера = из URL", "Дата окончания = XX дней с даты активации",
Я конечно выставил 'expiration date' в моде тоже (1 день с даты активации в моем случае). Это первое с чего я начал.
Идея была чтобы VMProtectActivateLicense сверялся с датой на своей стороне и не выдавал лицензии вообще если "время уже вышло" в некотором смысле:
Но VMProtectActivateLicense эту дату никак не проверяет, просто выписывает лицензию ограниченную по времени на 1 день от момента активации. Да и не может он её проверить, ведь я задал дату окончания лицензии, относительно даты активации.Admin wrote: По поводу перевода времени - здесь тоже возможен вариант, при котором программа на старте лезет в инет за "правильной" датой и эту дату использует для проверки ограничений серийного номера (для этого достаточно вызывать VMProtectActivateLicense + VMProtectSetSerialNumber).
Кстати я не попробовал задать ограничение по дате в явном виде - например 13 февраля. Было бы классно, если бы VMProtectActivateLicense отказался выдавать лицензию, если эта дата уже в прошлом. Это решило бы проблему.
Потом я обнаружил что у ActivationCode тоже есть 'дата окончания'. Её то уж VMProtectActivateLicense точно должен проверять. И проверяет, за исключением того момента, о котором я писал в предыдущем сообщении.