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?

  • 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. – ConditionRacer Feb 14 '13 at 15:01
  • Getting the CPU cycle count in a programmer-friendly way comes to mind. – Florian Margaine Feb 14 '13 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. – Dunk Feb 14 '13 at 19:49

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.

  • this does not prevent the attacker from reinstalling the program and reseting the trial window (cleaning registry, etc) – Dredok Jan 28 '16 at 9:40

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.

  • 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. – l46kok Feb 14 '13 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). – Gilbert Le Blanc Feb 4 '15 at 22:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.