Hi and thank you for your help
We have an application that might be installed both in online and offline environments. The application is dockerized therefore we built up a pretty complex structure of scripts that manages the activation for both scenarios.
In some (but not all) installations, we want to provide a timed license, meaning that after a certain date the application must stop working.
I know limelm offers the timed trial option, but its introduction would require the refactoring of the complex structure of scripts and we prefer to examine the options we have with the standard activation procedure paramount.
We work with Ubuntu 18.04, the application is written in C and we are using TurboActivate 4.3.1.0 but we conducted tests also with 4.4.4.0. Given that, our questions are:
1) How can we detect that the user is changing the system date to gain more time? We added a custom field expire_date to the license that is filled only if required by the installation. We experimented the function TA_isDateValid() that should return TA_FAIL if the date expires (it works), or the system dates have been tampered. To test the latter we tried to change system time up to one year backward but the function returns TA_OK instead. The return of TA_FAIL due to tampering it is critical, especially in the offline scenario. We also experimented with TA_GenuineDays() that should set DaysRemaining to 0 if the system time has been tampered, but it is set to more than 300 if we bring the system time one year backward. In to online scenario we can rely on TA_isGenuine[Ex]() that returns TA_E_INET_TLS and deactivate the product in case of time tampering but, of course, it is of no use in case we are offline
2) Is there a simple and reliable, client-side, way to determine whether the application was activated online or offline using the TurboActivate interface? Up until now we are using a license's custom field of type checkbox, ticked if the activation was offline.
Thank you in advance
Always use the latest TA, we're continually fixing bugs, improving security, and adding new client-side fraud detection.
We use a variety of methods to detect client-side fraud. No, we don't document them. And simple roll-back / roll-forward “testing” of the functionality won't suss them out.
For trial functionality we recommend using the timed trial functionality. It's not a good idea to ad-hoc rebuild what we've already built and spent considerable resources perfecting.
Thank you for your reply.
It is perfectly reasonable to not document your methods. I got confused when I saw that the simplest approach someone might use to elude expiration date (rolling-back system time) worked.
If you assure me that sooner or later TA_isDateValid() will detect the fraud, both in the offline and in the online scenario, it would be the perfect solution for me.
If you assure me that sooner or later
TA_isDateValid()will detect the fraud […]
Most of the time it will detect client-side fraud. The best way to prevent fraud:
Is there a way to prove that TA_isDateValid() detects if system time has been tampered, especially in the offline scenario? It is a functional requirements of the application
Client-side fraud detecting cannot be 100% prevented. Hence the advice in the previous answer.
If you're looking for 100% prevention, the answer is that it does not exist. You will, however, find charlatans offering services that provide those type of guarantees.
Advice noted but, as I told you, in some environment we simply cannot rely on any kind of connection.
I am aware that 100% client-side prevention is impossible but something can be done. Is there a way I can show our client that TA_isDateValid() (or any other TurboActivate entry) can detect the basic rolling-back time tampering in the offline scenario?
Thank you for your help
Nope.
Artificial rollback/roll-forward are ignored.
