How do I enforce an expiration date for a trial install of my software?
I need to offer a trial period for my custom software. I have a 64-bit C# app, which uses 64-bit, multi-processor support DLLs. Other utilities to be included are written in C++ (exes and dlls). I must be able to encrypt the C# code, key the software to run only on a particular machine, and enforce an expiration date that cannot be foiled by resetting the machine clock.
I've evaluated several open source and COTS solutions: Infralution Licensing System, Protector, and ExeShield just to name a few. None of them satisfy all of my constraints.
Is anyone aware of an all-ecompasing solution that I should consider? Or do I need to do some registry diving and enforce it through custom code?
Answer
I've discovered over the course of several years of trying out varying licensing systems that there's a strong inverse correlation between security, and alienation of your potential customers.
There are essentially two kinds of piracy you need to worry about. One is casual piracy - users using the software without paying simply because they haven't really thought to pay. The other is deliberate piracy - people who are determined not to pay, and are willing to put real effort into not doing so.
Casual piracy can be handled with what essentially comes down to gentle reminders - activation keys, time limits, etc. Deliberate piracy, on the other hand, essentially can't be prevented. As Sony, Apple, Microsoft, Nintendo, and a number of other companies will tell you, even when you have the benefit of control of the hardware as well as the software, your protection scheme will be broken. And the person breaking it is as likely to be doing it for the sake of a fun challenge as for the desire to get free software. So for a certain demographic, making the protection stronger doesn't discourage them, it does quite the opposite.
Meanwhile all the stuff you do to try and achieve strong protection is driving legitimate users up the wall. Maybe the trip for detecting gerrymandering with the system clock got set off because they changed time zones. Or maybe they had to replace a bad hard drive or CPU or something, and that set off the system cloning mechanism. Or maybe Microsoft changes Windows's default security settings in a way that causes Windows to pop a mess of UAC warnings while your app's in use thanks to it not being friendly to some trick you used to try and hide the file that stores the licensing data. At work we use a commercial solution, and we've discovered that their protection mechanism can trip in ways that, thanks to a bug in the software, can cause the license data to be corrupted, thus locking the user out of the program. Because of the way their system stores that data, its an unrecoverable situation - the customer literally has to choose between not using that software on that computer ever again, and wiping the hard drive. Yes, it's happened multiple times. Yes, we've lost a lot of potential revenue over it. Yes, I get queasy to think of the damage it's caused because we rely primarily on word of mouth and it's generated a whole lot of bad word of mouth. Long story short, the naive paranoia about piracy of earlier years has probably cost me quite a number of sailing vacations in the Caribbean.
And the worst of it is, it's only a problem for legitimate users. Crackers can easily - painfully easily - get around it with the aid of - if it comes to last resorts - a debugger and decompiler. If the software is on a device in the possession of the end user, you might as well start thinking as if your software's already been cracked. It's to the point that there's a cottage industry that has built up around the idea of people cracking software they legitimately own, just to avoid the annoyance of the software protection mechanisms. They'll give you the money, but they'll still crack the software because your copy protection is just that irritating, and just that easy to circumvent. The alternative - and this is the route I've gone - is to just go buy different software that's less annoying, or use free software instead.
So go with the minimum - watch the clock and time out the demo, because you do need to remind your users to send you a check. But don't do it in a way that makes them decide they don't want to give you a check. If your goal is to convert sales, consider this as the most elegant, cost-effective, and efficient system for keeping users from violating your demo period by mucking with the system clock: It's really, really irritating to work with a computer that's got the clock set to the wrong date. And that's just for home users. For (legitimate) businesses, it's not even a feasible option. And anyone who isn't deterred by that is probably a script kiddie who never really had the means to pay for your software in the first place.