7

I was always under the assumption that trial softwares write a registry value of the installation date and then the software makes a comparison of the current date of the system with the remaining days + installation date to verify whether the trial period is still valid or not. If this assumption is to be true, winding your system clock further up ahead than the remaining days should end the trial period of the software (or keep winding the clock backwards to use the trial software as long as you wanted to). From experience, This was the case for some softwares, not so for others.

For the latter case, I noticed that the trial period expires only after the days have passed in real time. I confirmed that the software wasn't connecting to the outer network for validation mechanism, so it is definitely something being done locally on the computer. How does the trial period validation work in this case?

3
  • 1
    This is just a guess because I've never implemented anything like this. I would save the clock at installation time and calculate an offset of the system clock before doing any timespan operations. EDIT: On second thought, this doesn't work. Now I'm curious as well. Commented Feb 14, 2013 at 15:01
  • Getting the CPU cycle count in a programmer-friendly way comes to mind. Commented Feb 14, 2013 at 15:14
  • I would think the easiest way would simply be to have a tick timer that triggers periodically while the program is running and increments a count variable. It would also periodically write its count to non-volatile memory. That way the system's actual date/time is never involved. Commented Feb 14, 2013 at 19:49

2 Answers 2

9

The way my trial versions handle it is to track a trial period 'window'. The program won't run if the date is set back or forward. Every time the program is run, the window gets smaller, and the updated 'start' time in the trial window is changed.

1
  • this does not prevent the attacker from reinstalling the program and reseting the trial window (cleaning registry, etc) Commented Jan 28, 2016 at 9:40
2

I don't know how it's correctly done, there are problably others that can tell you.

However off the top of my head, to prevent someone from rolling back time you could store and update the current time, but only update it if the time is larger than the old stored time. That way you wouldn't have a future time unless someone had rolled their clock back.

2
  • 1
    Sounds like a solid guess for me. The only potential problem I can see with this is if the user has had their clock set incorrectly and then installed the software, then the user readjusted the clock correctly later on. Not a very likely situation, but just something that I thought of. Commented Feb 14, 2013 at 16:22
  • @l46kok: I guess you can check the clock change and ignore small changes (on the order of a few minutes) and process large changes (on the order of multiple days). Commented Feb 4, 2015 at 22:50

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.