How can I make my product as a trial version for 3

Question

I have created my product and also generated license key for that but I want to ask that key after 30 days. I have do it with registry value storing the date with adding 30 days in that. But I found that if the user change the system date with 30 days before my logic not work.

So is there any solution for the trial version software without checking system date and allow only 30 days of trial?

Answer 1

You need to have a way of detecting if the user changes the date from when you first started the trial. In solutions I've used before, we have saved the "last executed" date and the "first executed" date and if the clock changes to anything more than two days of "last executed" we expire the trial. You also need a "days executed" counter so that they can't keep moving the date two days back (forgot to mention that part) - the counter gets incremented on each execution.

Of course, software licensing systems like this are always avoidable by uninstalling and reinstalling with appropriate refreshing of the registry - the trick is obfuscating and duplicating your license information enough to make this difficult, but eventually, it will get found (especially if you're using an unobfuscated .NET codebase).

Answer 2

Store the last run date, and whenever the system date is before that, expire the trial.

The only fail-safe method is to validate the app against a service that you host, assuming no one cracked your connection code ;)

As long as they can clear the registry value/isolated storage file/saved settings: they can just restart the trial. There's not much you can do about that. That's why people opt for reduced functionality in trial software, in addition to a time-based trial period.

Answer 3

If its acceptable to allow say 8 hours of trial usage (instead of a 30 day trial), then one way to remove the dependence on the System DateTime is by using a timer in your app which is fired say every minute. Count these and so every time the app gets run, it will accumulate a total usage minute count. You can then store this count value somewhere, such as in the registry.

Answer 4

It's simple store evaluation end date and check for it every day. To avoid extended usage by date manipulation, maintain an hour count in the application; keep incrementing and writing it to registry. Check should be done against both the evaluation end date and the hour count not to exceed 24 (may be 30 with some teolrence).

Answer 5

Think Also About :

Saving the DateTime of the closing of the application, next time it's lunched your application will be able to detect if the Datetime setting was changed or not (at least they can't change it before to something before the closing time). Example :

On Application Closing :

Saving The Time => 15:34 03/31/2014 (Saved)

Next Starting Of The Application :

Check Datime.Now > 15:34 03/31/2014. (so they can't go bellow that...)

ADDED :

Try somehow to integrate the datetime settings of the system into your application use : Generating Invoices, Tickets, Receipts... whatever !

Answer 6

You could have another registry key that you increment after every day's use. That way, even if they change the computer's date, this key would indicate to your program that it's been running for > 30 days.

Additionally, this value could be encrypted so that if the user tries to manually change it, the program can refuse to run because it was unable to decrypt the value and get a valid number out of it.

To get around reinstalls, you could add some information to any file saved with the trial version of your app which is unique to that specific version of the app (perhaps a timestamp from when it was installed). When a trial version of your app tries to open a file, it will check this signature and ensure that it was created with that same instance, otherwise refuse to open the file. This essentially neuters the ability to simply reinstall the app and continue using it.

At the end of the day though, the user has complete control over their machine and can probably find a way around whatever it is you want to do (short of accessing a web service where these details are kept before you let the user use the app). You probably shouldn't expend so much energy trying to stop the guys who are willing to go through this extra trouble, but instead spend that extra time/money/energy improving the app for those who are willing to pay.