Time limited software 3

[jmnagi]

hi.. assuming my software will be installed on a customer's machine on a 1-month trial basis, how do i enfore it ?

i mean, when the 1st month is over, unless the customer buys my software, s/he is not allowed use of the software. i know how to stop the software/driver internally.

the problem i have is "how can i make sure the customer has not played with the system time ?" {moving forward or backward} ? please reply. thanks

br:

--
br: nagi

 

[lionelhill]

I don't think you can. A stand-alone computer has no way to "measure" global time independantly of user actions. You can, however, limit the number of minutes the program will work before it demands that the user buy it. The sales-trick is to make sure that the number of minutes is sufficient that the user becomes hooked.

From a user perspective I suspect, however, that illegally copying of disks is probably going to lose you more income.

 

[AllenV]

It also depends on the type of program it is. If it's a game or something that's generally "fun" - then yes, system time changing may indeed play a role. However if it's a business or utility app, there's very little chance that someone is going to bother, as de-syncing a computers time in a network environment has strange side-effects on file-sharing.

A relatively easy thing to do is to store the "start and end" time of your program in a "hard to modify" file. If ever your "new" start or "new" end time is less than either time you've already stored (by more than 25 hours or so) them someone is probably trying to snow you. Mark the file with some sort of "invalid" note if the time is fudged to far.

The &quot;up to a day&quot; of fudge time is important to let slide because of time zone switching (which can be done for valid reasons) as well as network time synced computers that have a bad habit of drifting. ->Windows XP systems that are set to sync from Microsoft are VERY bad when it comes to time drift - I've had one XP system on my network slip 17 hours in a week between time syncs<- ->Some older UNIX boxes are time synced infrequently through dial-up, or even manually causing similar time jump issues<-

Otherwise, there is the way Microsoft keeps trying to get away with - have your Proggie call home every so many hours of use during the trial period. That way, your server can supply the time for your program.

 

[jmnagi]

hi allenv

that was my line of thought. but there is still this problem.

say
start date: 20-05-2003
end date: 20-07-2003

i can scrable this and store it in the registry. this is not a worry.

but what if {customer aware of the fact that s/he has a 2 month trial period} every two weeks the customer changes the system date to 30-05-2003 ?

i was thinking, i can run a &quot;timer&quot; internal to the driver ? what do you think ? is that a good idea ? is there any method that i can use to prevent &quot;theft&quot; from one computer to another ?



--
br: nagi

 

[tbshmkr]

Try this: A dongle. It has a clock in it to limit lifetime (you set). Without the dongle the software will not run.

It's calld the HASP 4 Time

http://www.ealaddin.com/hasp/time.asp?cf=tl

 

[lionelhill]

I really feel, though, that there is a danger of decreasing your profit by getting too worried about this.
(1) In properly networked business places people simply don't reset their system time. It's too messy.

(2) If it's not a properly networked business situation, you can't rely on the person having internet access (unless your programme is actually directly internet related and not useable without internet), so you probably can't dial home to check the time.

(3) You also have to be careful about stopping people from changing their system time. People do sometimes do it for legitimate reasons. The biggest example is the great millenium bug fiasco. Most people probably reset the system time somewhere to test the survival chances of critical software. Many people then found that their printer cartridges had suddenly &quot;expired&quot; and there was no way to correct it...
This may sound an unlikely situation, but look at it this way: If someone tomorrow discovers a system clock somewhere that is likely to hit its turnover point in the next year or two, and we have another millenium scare, people are going to start changing system clocks again. And every time they do so during the one month test period of your software, your software is suddenly not going to deliver what it promised. The user won't know why: they'll assume it's just that your program is bad, which means you'll lose a sale.

Of course the dongle will work. If you care to add that expense.

 

[AllenV]

Wait a minute. All good points really - so I look to my original solution. You have a one month trial, right. So every time your program starts - you check that it's within a day or after the last time you wrote your last start and last end dates.

Timestamp says
install: 20-May-2003 09:14:40 (never updates after install)
start: 20-May-2003 10:00:15
end: 20-May-2003 10:50:34

Your program starts, and asks the system's time:
20-May-2003 10:40:12

So we let the assumption go that there was a time drift that was &quot;auto-corrected&quot; (you know from your control file that 10:40 already happened), don't put up a fuss, it's no big deal. So you put the start time into your control anyway as the most recent time the software started. At exit, you ask the time again, and now it's: 21-May-2003 16:49. Write this as your exit timestamp.

O.K. - you start again...

Timestamp says:
INSTALL: 20-May-2003 09:14:40
START: 20-May-2003 10:40:12
END: 21-May-2003 16:49

Ask the system the time:
19-May-2003 08:42

Compare this against the higher of the two changing dates (dates you assume already happened). Woa, 2 days and 8 hours. Here is where you leave good customer service.

Pop a message box. &quot;The time on this system has changed backwards beyond reasonable expectations. The <program name> has been disabled. \n\n Contact <company> at <contact info> if you believe this message is in error.&quot;

Another good hint is a counter of how many times the timestamps are after the current time at start. This will be a decent check to see if someone is trying to spoof you on a daily basis. Pop the same message after 30 general time-stamp failures of more than 1 second.

Finally, I use three timestamps here in case of system hard failure (where you can't capture your end time). You can always capture your start time - but this time alone may not cut it.

Variations of other suggestions are also acceptable, update a timestamp every so many operations, loops or actions - test that.

Of course, what I've mentioned so far will already add several hundred lines (if not more) to your program.

Finally, There is very little you can do about a program being shuttled from one computer to another without using extreme measures. Twice in my carreer, I have run into programs that would check system parameters, and base the product installation key off of these. This is dangerous, and becomes a management nightmare when people do computer upgrades and start calling you for support. Basically it leaves a bad taste in people's mouths - leaving your software on the junk pile, replaced by a competitors product.

If you are concerned both about longevity of demo AND about PC to PC movement - see previous post about dongles. In mass production, they are quite reasonable, and they are relatively easy for a user to understand.

 

[icici]

you may also try this

when the software is installed, change the dates of all the files associated to the date of installation and then check with the date of your main file. if its > 1 month (30 days) inform that the software license is required to be purchased for further use. otherwise disable some of the options while giving for trial runs.

also you may think of accepting a license key (use your own formulae), which would be valid for one year and would also be maintaining the installation date, expiry date lathough in encrypted form.



thanks


icici