How can I make a evaluation timer?

[koSmiQ]

Hi!

I'm making a program for a company and wonder how I can add a timer to count down from 14 days and then make the progam stop working if there is no registration code or similar entered.

I don't think that the program should read from the Windows time down in the corner and instead read from some internal file or something that can't be so easily modified.

Is there any special file in windows that I can read that information from?

And if you like to know, I am making the program Win32 with the use of Visual Studio .NET 2003 Enterprise Architect.
The interface is made with MFC.

Please help me if you can.

Thanks in advance
//koSmiQ n' Raven

[bithub]

Well you can always connect to one of the many time servers out there to get the correct time. This would of course require some sort of internet connection though.

[AdamLAN]

If you find out how, tell me, cause' I'm just as confused about it as you, but it would be a big help if you could tell me how.

[VirtualAce]

Your kidding right??

When the user installs the program write the time and date in the registry. Check the registry entry on every startup of the program. When the time has elapsed - disable access to the program.

In order to account for days that stretch over 2 months base your time on hours, not days. Subtract the time in the registry from the current time on the user's computer. If the time in hours is greater than 14*24 then you know the program is 14 days old.

It doesn't matter how exact it is - but this method will shut down at exactly 14 days. There are 14*24 hours in 14 days no matter where you are. The start time is relative to the user's clock, so the end time should be to. You will also need to track the date the program was installed. You may have to write a small program that will know how long each month is...but no biggie there either. Each day is worth 24 hours...you should be able to do the rest from here.


No internet connection needed.

[Hunter2]

>>No internet connection needed.

I don't think that the program should read from the Windows time down in the corner and instead read from some internal file or something that can't be so easily modified.

Another thing you could do is manually track the amount of time the program has been running. Call GetTickCount() at program start and at program end to find the amount of time it has been running (in milliseconds), and log it to a file. Next time, count the time again and add it to the logged time... repeat until the time has accumulated to 14 days. You could also add time checks every once in a while, maybe set a timer.. and if the time has elapsed, quit the program on the person

[Vicious]

Ofcourse using bubba's idea you would want to "encrypt" the value and the key name. It wouldnt be to smart to have an entry that says "Install Date 100104" .

Just out of curiosity, what kind of project is it? And for what company?

[Hunter2]

>>Ofcourse using bubba's idea you would want to "encrypt" the value and the key name.
I think the main problem is the "go back in time" exploit, where you just keep adjusting the system clock backward, and thus never run out of trial time.

[misplaced]

well, is bios clock and the windows clock exactly the same thing? or is the windows clock relative to the bios clock? if so, i doubt many people would go through the trouble of setting their bios clock back to use a program

[vasanth]

well the install data is recorded and every time the user uses the program the time is recorded.. if the program starts in a time in the past it means that the use has fiddled with the time nad the program can exit... but it is impossible to make this fool proof.....

[Hunter2]

Well, assuming you hide the install time well enough, the internet time server idea seems pretty good - unless you're counting on the person trying to hack into the server and modify the date there

[misplaced]

using a combination of my idea and someone elses
you could store the install date/time and update 'last use time' every minute or so while the program is running, and then if the cpu time < last use time you know the clock has been set back... if last use time - install time == 14 days, end evalutaion....still not 100% but getting closer.

[Hunter2]

>>you could store the install date/time and update 'last use time' every minute or so while the program is running
Yes, that would at least prevent unlimited access (although with some incredible timing skills the user could get pretty close ). You could spawn a thread at startup that handles this and runs in the background so as not to disturb the rest of the program; in fact, if you do use a thread, then the entire 'trial' function could run almost independently of the rest of the program and become a detachable module even, for later reuse.

In fact, this could be merged with the internet time server idea: The first time an internet connection becomes available, find out how far different the computer clock is from real time, and then whenever an internet connection is available, use that to track the time - and if the computer clock suddenly falls really far behind real time, then the person is 'cheating' and you can (a) readjust the offset and (b) check if the time has actually expired already. Whenever an internet connection is unavailable, you can revert to the original plan of just using the computer's clock.

[Lithorien]

Use an atomic time server (time-a.nist.gov) to pull the exact time down, and store that an in MD5-encrypted file set +s +h +r, while storing the difference between that clock and the Windows clock. If there is no internet connection, refuse to run until there is. Then when your program runs, either pull the time from the Atomic Clock server, or if there is no internet connection, pull the Windows time in, adjust it due to the offset, and compare it to the Atomic Time value. Add checks such as storing the last access time in another MD5-encrypted +s +h +r file, and if the Windows time in that file is greater than the pulled Windows time, activate the time bomb in your program.

I can't readily think of a way to defeat that except by making sure I set my date/time to be +1s from the last time I opened the program. And you can also add checks for that - if the difference between opening time 1 and 2 is less than <somevalue>, then activate the time bomb.

Just 2cp.



P.S. What type of program will this be?

[Hunter2]

>>If there is no internet connection, refuse to run until there is.
That would kill your sales horribly

Then when your program runs, either pull the time from the Atomic Clock server, or if there is no internet connection, pull the Windows time in, adjust it due to the offset, and compare it to the Atomic Time value.

That's what I said.. err, I mean implied

>>if the difference between opening time 1 and 2 is less than <somevalue>, then activate the time bomb.
That isn't foolproof; if you make it too large, then the timebomb may false trigger; and as long as the user sets the time to just after <somevalue>, it won't trigger at all. You'd still need the time re-check to ensure that the user isn't screwing with the clock.

[Lithorien]

That would kill your sales horribly

That's one way to defeat any attempts to bypass your security -- require that all steps must be completed in initializing it.

That's what I said.. err, I mean implied

Ok.

That isn't foolproof; if you make it too large, then the timebomb may false trigger; and as long as the user sets the time to just after <somevalue>, it won't trigger at all. You'd still need the time re-check to ensure that the user isn't screwing with the clock.

Yes, I didn't say to *not* have the re-check. I'm just suggesting that you have some value like 10-30 seconds to blow up on. It's not foolproof, but it does severely cut down on the number of times you can use the "set clock back" trick to use the program. Plus you have to remember exactly when you used it last, no errors.