How do I enforce an expiration date for a trial install of my software?

Question

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 1

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.

Answer 2

Use http://xheo.com/ products for this. They offer a code obfiscator that is great at protecting code, and a licensing platform that can do everything you would ever imagine. they offer a version that can be compiled into your code.

Encrypt - http://xheo.com/products/code-protection License - http://xheo.com/products/copy-protection

Answer 3

Why not just use the time from an internet source, like www.time.gov? You could fold in a C++ Qt app and use their QtWebKit library, http://doc.qt.nokia.com/4.7/qtwebkit.html, to download the time. (I've never in fact done anything like this, but looking at the documentation it looks promising.) The first time the program runs, you create a little file with a timestamp, or, for even more security, write the timestamp into a program-essential dll and recompile it. This gets checked every time the program is run. If you they're not connected to the internet you warn them a few times but eventually abort the load.

Another variation on this, used by a lot of software packages I think, is that you store the date the user starts using your software on your server. Recompile the program for each user (you might be able to script this) with a user-specific code, and the program checks itself against the date stored on the server every time it is loaded.

Answer 4

How can it be stored in a way as to be unrecoverable? Registry entries and files can be deleted. Alternate data streams don't get coppied into a zip file, so if you know the file that contains the ADS that contains the install data of the software (which is being used to reference the the current time to calculate days since install), you can just compress it in a zip file then extract it again and byebye to the install date reference. Store it as raw data on the harddrive (not referenced in the File Allocation Table as a file) and it will be overwritten when a file is saved to that location on the harddrive.

So I literally can't see a way to make an impossible to remove trial install date for copyprotection. It just can't be done.

Answer 5

Perhaps a better idea is to give away, for free, a smaller application that has only minimal features. Customers then pay for extra features or add-ons.

In my application, people have suggest that I offer more data for a fee. The application would be free with minimal data. Another idea is to go the subscription fee route for the advanced data access.