Question

I am working on creating fully functional trial version of a software. Now, because I don’t want a time limited (like 30 day trial) or functionality limited trial, it would be nice to go with the ‘number of times a user can execute the software’ trial.

Its a C# based .NET application and I am trying hard to figure out a way to implement this. Tried registry keys, file based tracking etc, but they don’t seem to be very reliable.

Would really appreciate help on this topic.

Thanks,
Rohan

Answer 1

The normal two ways a trial period is kept track of is with a registry key, and with a web service:

• Registry Key: Implement some method of persisting the number of program startups into a key in the Windows Registry, probably with some sort of obfuscation. A “salted” encryption scheme, where you encrypt a scheme containing your value plus some machine-dependent value like the NIC’s MAC address, would probably work best; make sure your code is made hard to decompile, using something like Dotfuscator. It would be best to put the key in places using the installer, so the program can simply treat absence of the key as an attempt to tamper.

  Then, on startup, retrieve the key, decrypt and inspect it. If it’s what you expect, add 1 to the value, write it back to the registry, and if the new value is greater than the number of allowed startups, lock the user out. If the registry key is ever a value you don’t expect (meaning they tampered with it), including not being present at all, just lock the user out.

  The advantage of this approach is that it provides very strong security without needing the Internet. The downside is that “machine-dependent” details can change for legitimate reasons, and when that happens your user is locked out before he’s used all of his starts, which can frustrate users. Also, your implementation for the salting and encryption is present on the user’s computer; a sophisticated hacker will have ways to examine your program even if you obfuscate the code, and can discover your implementation and mimic it to “reset” the counter. It only takes one guy that can do that, and there will be a simple Warez app to allow anyone else to do it.

• Web Service: Implement a WCF service on a server you control. Lock it down tight, so the only way in or out from outside your LAN is through the WCF port in exactly the way WCF expects. Now implement a client in your program and its installer. On installation, the installer will call a service method saying that the software is being installed on a machine with a particular MAC address or hardware ID. If you don’t have that unique machine listed in your database, add it; otherwise don’t do anything. Then, on program startup, call the web service from your program, pass in the same information, and the web service will update the number of starts, and return a value telling the client whether it is allowed to start.

  The upside of a web service is that it will be very hard to get around in a way that can be mass-marketed via Warez; the main way to attack such a system is to hack the license server, or else to put in a “man in the middle” who can redirect your program’s request for the web service to a computer he controls. The downside is that changes to a computer’s hardware ID can still cause early lockouts, or worse, allow a workaround by allowing the attacker to simply spoof a new MAC address or hardware ID you’ve never seen before, and reinstall your software which gives the user a new set of starts on the “new” machine. There are ways to prevent that, too, but each level of obfuscation and anti-hack checking you add is one more layer of complexity.

Whatever you do, remember the 80/20 rule; 80% of your users will be kept honest by the most basic measures to secure the trial process. 20% of your users will find a way around that. Of that 20%, 80% of them will be stymied by any additional measure you put in place. This process is recursive; the point is that someone, somewhere WILL get around any measures you put in place, but if the math holds, 96% of your users will just give in and pay you for full access when faced with a shift-ciphered registry key and obfuscated program code. You can get that to 99.2% of users by adding anything else, like salting the obfuscated key with something machine-specific.