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?
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.
You could use a licensing component. You can make one yourself (see the LicenseManager class), or buy one from a vendor (for example CryptoLicensing).
I have one simple solution for you.
Take 2 variables for registry: 1. date 2. counter
steps:
Set a counter = 1
Copy system date to date
Check each time if the date is different than the current date, than copy that date to the registry date, also increment the counter by 1. If the date is same, don't do anything.
Now you can check you counter for trial days expiration
By using these trick, if user change the system date to previous date than also it works.
For registry you can encrypt the date & counter so that technical person would not recognize your logic!
cheers...
ADDED
This logic fails only when user doesn't change the date for each day! Again we have the solution for that!
I don't know whether it is possible or not but you can always have some solution:
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).
Hard to process 30 days without reference to the system date/clock. You could always keep a list of the dates on which the app was started and count 1 for every time it was different from the last time. This way your user would have to set the same date each time they fired up your app.
Other than that, you could, providing there were internet access, query a known good time server for the current date. This could be circumvented by disconnecting but you could always demand an internet connection before your app will start.
Lastly, an external, local time source via a hardware dongle or similar but I think you are getting into the extreme where you'd be better off directly managing the trials in person.
You can use free project Libprot. The site is https://github.com/libprot/trunk.
The idea is that it should be simple and easy to use. You can spend $$$ on protection but it may be hacked in one week. If someone wants to do reverse engineering of your code then no one can stop it. My advice to use simple methods that works.
Write a string like:
Company X|10.2.2014|1.12.2015
where 10.2.2014 is current date and if the system time is less then someone changed system clock => we should not run
1.12.2015 - until what time the key is valid
and name of company who bought/downloaded it.
that string should be obfuscated with asymmetric algorithm with private/public key and encoded into string that you may send by e-mail, for example.
you may also want to have some web service for validation. when internet connection is on you may validate the key, if it's hacked and available for public in internet you may ban it. Or if someone would write key generator you may validate that key is real.
you can add some PHP/java script in your site to automatically send trial codes.
IF you can guarantee an internet connection you could implement an online scheme (check a time server or your own authentication server). Of course that introduces another dependency - if the internet goes away, your users can't work.
Ultimately I'd say buy a third party licensing solution - it's still not unbreakable but it will probably be more robust than something you can do yourself without a lot of time and effort.
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.
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.
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).
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 !
© 2022 - 2024 — McMap. All rights reserved.
