Windows: reliable way to know if a certain date passed?

Question

For a simple product key library I need to reliably check if a certain date passed.
I'd like to do something slightly less trivial than checking the system clock since that can be changed easily by the user.

What are standard ways of doing this?

One way someone suggested is to check if there are files which were modified after the checked date. this sounds good but which files should I check? Obviously I don't want to start sweeping over the user's disk at random.

Edit - I'd like to avoid network based solution.

Answer 1

You could query your company's ntp server. Of course, users may firewall your ntp server out of existence, so you'll have to decide how much work you want to go to support users with either draconian security policies or users trying to bypass your licensing techniques.

Answer 2

You can check the clock, but also store the latest date you even got on any other checks in the registry. That way at least once the user has deactivated the program once, it can't be reactivated again. The only alternative I can see is to query some kind of internet service to get the time, but that's no good.

Answer 3

You can request any publicly available web server (say www.com) and grab date from response header.

Answer 4

You can allow the user to use the application only a certain number of times if it is a trail version scenario.

Answer 5

Relying on the OS for checking a date that can be altered --> you have already lost the game

Any method can and will be broken, to add insult to injury your starting off from a lost position. An external network based would be the sensible choice, but even that can be thwarted.

The key words to your question is

Reliable

and the simple answer is NO, there is no point in hammering a square peg into a round hole..

Edit 1: Weak solution

OK, understanding that this is pretty much a lost battle, if you still insist on having some very weak solution here is one possibility:

We know that time should only increment upwards, thus based on this assumption, this can be our 'test'. Violation of this rule we can assume someone is tampering with time and therefore block this case.

(1) On the first ever run of the application create an encrypted file with the current date (time-stamp).

(2) Every-time the application is run, first check for this file and check the current time from the OS.

(3) from our base assumption, we should expect that the current time should always be greater the stored time time. If it is we can WEAKLY assume that the OS time is 'Reliable'.

(3) If the current time is less than the stored time, then some one has been tampering the OS time -> bad guy.

(5) Upon closing encrypt the current time.

(6) If the encrypted file is missing assume also bad guy.

Answer 6

I'm not sure what shoosh means by no network based solutions. There's a web service available to get the date and time of any location.

EarthTools

An application can get the date and time at the creator's location when the application is installed, and when it is started.

EarthTools asks that you not submit more than one request a second, which should be adequate for most purposes.

Here's the example query for New York: http://www.earthtools.org/timezone/40.71417/-74.00639

Here's the example response:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<timezone xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="http://www.earthtools.org/timezone.xsd"&gt;
    <version>1.1</version>
    <location>
        <latitude>40.71417</latitude>
        <longitude>-74.00639</longitude>
    </location>
    <offset>-5</offset>
    <suffix>R</suffix>
    <localtime>4 Dec 2005 12:06:56</localtime>
    <isotime>2005-12-04 12:06:56 -0500</isotime>
    <utctime>2005-12-04 17:06:56</utctime>
    <dst>False</dst>
</timezone>

Answer 7

I'm reading between the lines. I think you want to make a "Trial software" version. Especially since you mention "cracking".

The best non-network solution I can imagine for "trial period" dates is to not worry about an absolute date going by, and instead, implement a day countdown. Even if you are defeated for a number of days by a user changing the CMOS/BIOS date-time, you can still store the date and time and system tick count of the last time you were booted up, and the next time you are booted up, if it appears that the date has done anything other than go forward by a small amount of time that is less than a day, then decrement your "days remaining in your trial" counter. You could also count hours that the application has been active, and count that down too. It is possible for someone to extend the lifetime of a trial version indefinitely by keeping your app away from the network, and by rolling back the clock, but if you run a service that is always running in the background, you might be able to catch the clock-rollbacks, and deactivate after some number (let's say three) clock rollbacks are detected by your background service.

I could probably come up with a way to pretty accurately lock down the active hours used in an application much more accurately than the date.

In fact, if you are contemplating a "trial version" of the software, why not consider just giving the user "xx hours of trial time", instead of "30 days". If 30 days goes by and your user doesn't fiddle with the date/time to extend it, he may be so annoyed that your trial expired before he spent any time with your software, that you may lose a sale.

Google's sketch-up pro uses the "hours countdown" technique, and I found evaluating it much easier.

I think this answer to another question is the best one I have seen: http://stackoverflow.com/questions/2481320/what-is-the-best-way-to-create-a-trial-program

The real answer is "anything you can do, there are lots of people who will try to defeat and crack it". Seriously. How much time do you want to spend on encryption and obfuscation? You won't make any money that way.