Licensing: How to deal with tampering with a computer's local time / date?

  

If the user in question breaks the subscription (no longer pay) or no longer connects to the licensing server, you can use the product until a certain date (the expiration date of the last downloaded license).

Do not use certain dates. Use number of days . For example, each monthly payment entitles you to use for 28-31 days.

Every boot-up of your service:

• validate the time of the last update versus the current time.

  • If the date is different (past or future, whatever) remove a day .
  • If the system time is lower (the clock has been manipulated), remove a day .

• Store the current moment so that it can be validated at the next boot-up.

So, attempts to circumvent the counter will always count against the malicious user, but without prejudice to the honest user.

As @Bacco originally mentioned in your comment (the credit is yours, Bacco!), it is interesting that you validate this structure against some other source to avoid restarting the file containing the time of the last evaluation. The solution it presents (storing in the encrypted file the last ID of a table known and often used for database write operations, for example) is simple, robust and easy to deploy.

There are several ways to do it.

One that I recommend is that you check the date and time of your system's input and output. If it comes back more than two hours from the last exit time, you ask it to reconnect to re-validate the license and without that it blocks access.

The worst case of this method is that it is able to use for 30 continuous days (managing well the system date and time every time and having extra work).

Another option is to scan the system and look at the date and time of one or several files in the operating system and your program to take a look at any inconsistencies.

You can compare against the application's own database by checking to see if there are no records with date and time more recent than the date set on the local computer. For if the date was adulterated one hour the dates of the records of the base will begin to give divergences.

Example:

Let's assume that the tainted date was fixed on 2/29/2016. In a given table generated the following records:

02/29/2016 08:00:00, 02/02/2016 09:00:00, 02/02/2016 13:00:00 and 02/02/2016 18:37:00

Tomorrow when the application is used the date will remain 29/02/2016 (or some minor date). Let's suppose that new records were generated in this table:

2/29/2016 10:30:00 AM

Notice the inconsistency? Like I'm entering a record on 02/29/2016 at 10:30 if I already have records on this same day with higher schedules. In this case this is detected the inconsistency and you can crash the application because it is a sign that they are trying to circumvent the license system.

You can have a table in the application just to record the hours every hour and create a routine to detect the inconsistency, or you can even use some existing table that has date and time and generate records with some frequency. >

Another option can also be to compare with windows application event logs (Event Viewer) instead of using your base.