Preventing date rollback

[Flint Pellett]

rcosj at chudich.co.rmit.oz (John Simmons) writes:

>richard at dataspan.dataspan.UUCP (Richard "Tiger" Melville) writes:

>>Many of the software products our company sells rely on a licence file which
>>specifies the duration of time the software is licensed for.  The software
>>then refuses to run when the period has expired.  It is, however, possible
>>to roll back the date on a machine and fool the licence manager software.
>>This problem must be solved in order for us to distribute free demo versions
>>which work for a specified period only.

>>Is there a reliable way to test if the date on a machine has been rolled
>>back ?  (System files which have modified dates in the future might do the
>>trick.)  As portable a solution as possible is desirable, although we mainly
>>run SunOs 4.0.

>Couldn't you get your program to check the date fairly regularly when it is
>run and write it away somewhere, keeping track of the latest date reached so

That's the problem: where are you going to write it?  A reasonably clever
user, after rolling the clock back does not get things started again, is
first going to re-install from the original installation media.  If that
doesn't get it going again because you've written a date in some file other
than one of the ones originally installed, said user will go back to the
backup they made the end of the day they installed your stuff, and see what
files changed that day.  After they figure out which one you wrote into, they
restore it from the backup and they're going again.  You can do stuff to make
it hard for them to figure out what you've done, but if it is worth enough
to them they can always figure out what you did.

I've heard of schemes where the installation program on the installation
media alters the install media so that it can only be used to install with
once: and I've heard of people creating X copies of it before they first
install it to avoid that problem.

>far, then refuse to run at any time/date earlier than the latest one stored.
>The software may run after the desired date (if unscupulous people fiddle the
>machines date ) but it will slowly run out of usable time as the stored date 
>gets up to the final die-by date. You could even have a penalty setup such
>that it deducts time from the final die-by date if it detects an attempt to
>run it at a time before the latest stored time/date.

The software could even delete itself from the machine-- that won't help
because they can always restore it from a backup.
-- 
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL  61874     (217) 352-1165
uunet!gistdev!flint or flint at gistdev.gist.com