• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 282
  • Last Modified:

how to prevent user from changing system time ?

I'm implementing the 30 days trial scheme on program. but the problem is how can I prevent the user changing the system date ?
1 Solution
In my opinion, you shoudn't try to stop the user from changing the system time. You rather should check the system time when the software is installed and each time it is started. Crypt that somewhere in a file or in the registry, and make sure date and time don't change to earlier than the last check.
eugenengAuthor Commented:
that is what I've done, but user can simply hack that by changing the system date back, so my program will still assume it is not expire yet!! I've seen some programs, e.g Xing player, even I've changed the system date back to the date before it expire, the program will still refuse to run. how to do that ?
You really cannot prevent users from changing the clock on their own systems.

If however, you app were to keep a log of every time it runs and a run time comes up that is out of sequence, then you know that the time has been messed with.  So end up with a timeline like:


If the current time is ever before the install or the last run time, you do whatever it is you are planning.  Keep this data in a file or the registry (if Windows) and generate a HASH (MD-5 is a reasonable choice).  That way if the timeline data is modified you'll know that as well.
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

why not write the time and date to a file on the hard drive

called something not obvious


2 files

one when the software was installed

the other every day the software is run

then read the software installed data with the date out of the second file
and if the diff is >30 then dont load

thats how i did  it


Combine few methods and test few times during session.
May use (if Windows) RegEnumKeyEx( ) where is
PFILETIME lpftLastWriteTime. I not found how to change
this value.
I had this very same problem in a program I created, and I was able to solved it very successfully.

First of all, you don't want to stop the user from changing the system time.  What you need is a method to determine if the system time has been change, and if it has been changed, what is the correct time.

You program should first get the system time.
Then get the time stamp from several operating system key files.
These key files are files that get modified during boot up.
Even if the user does change the system time, these files will still reflect the correct date of boot up.
The only way the user can get around this is to change the time in the BIOS.
For windows NT you can check "c:\\pagefile.sys" and "c:\\winnt\*.tmp"

For NT/98/95 you can check the following:

In Win98/95 there are a few other files you can check, but I don't remember them of hand.  You can figure this out by looking at a Win98/95 directory, and look at what files have the current date stamp.
On Win98/95 the file that is used for virtual memory will have the most current date.

You should check all these files, and make sure that none of them has younger date then the system date.
If any of them do, then you know the system time has been changed, and you should time out the program.

Another step to take is have an extra time out key for your program.  That key should always have the latest date dectectable by your program.  You should always check the system time with this extra key.  The system time should never be younger then this key.  If so, you know that the system time has been changed, and you then can time out the program.

Program starts 01 March 2001.  
Extra key always has the latest date.
User starts program on 31 March 2001.
Your program saves the latest date "31 Mar 01" in the extra key.
When your program times out, and the user changes the date to 01 Mar or 29 Mar, your program will be able to see that the date is younger then the previously stored date "30 Mar" and can then time out.
Make sure when you save these keys, to save it in the registry in an inconspicuous location.  Make the key look like a system's variable. And make the date encrypted.  You can use any simple encryption.  Like change the numbers to letters.
15 Mar 2001 (15/03/2001)
Can be changed to
And you should take out the "/" dividers so it should look like the following:

Why go through this trouble?
If you don't change the date format, a user can just do a registry key search for keyword using the time out date as the key word.
You want to minimize the chance that a user can find your registry key.

An example of a inconspecuous key would be something like:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IE Setup\Options\subver

You want to pick a key that you know you the user will have access to, and that can not interfere with the system, but it looks like it's part of the system.

continue .....
You should also put some decoy registry keys in obvious locations.
Something like

When your program detects this key has been changed, make it update it to automatically.

You should do anything you can to add to confusion and add to the hacker's frustration in order to discourage the hacker.

In my program I had 5 backups for the Initialize date.
And my program would always used the oldest date of the five dates.  If any of the five locations had incorrect dates, my program would update it to the oldest date.

Here are four of the locations I used:
1. Registry Key
2. System.ini Variable key
3. win.ini Variable key
4. Custom file with a hidden Variable key
5. (???????)

All keys were encrypted.

Before my program initialized the key in the files, it first got the file dates, then added the initialized key, and then change the file stamp to the original date.
If you don't do this the user can just search directory for most recent file changed.

continue ....
I forgot to mention, that you should make the custom file have the same date as your executable.  So after you initialize the custom file, change the date stamp on the file, and make it match your main program.

None of these methods are fire proof.

The registry key can be found by a user using a registry tracker program.
The system.ini and win.ini key can be found by a user going to a different computer, and then saving the system.ini and win.ini files to a backup directory, before installing your program.
Then install your program.
After installing your program, they can use a File-Dif program to find the difference between the original win.ini file and the modified win.ini file.

The custom file can be found by installing the program into two different computers at different dates, and then doing a file-dif on all the files in the sub directory.

I'm sure there are other methods to finding these keys that I haven't even thought of yet.

So what you have to keep in mind is that your goal is to stop the average user from hacking your time out.
You will not be able to stop a really good hacker.

For more info, you can take a look at the following PAQ:

Above PAQ is a similar question I answered previously.
eugenengAuthor Commented:
Excellent!!! Axter, thanx alot..

for the other helpers, I think Axter deserves the reward points coz he gave me the most robust methods & ideas to solve my problem, anyhow, thousand of thanks for you guys

Featured Post

Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now