Biz & IT —

How to implement a self-destruct feature into free trial software?

A 14-day free trial is a nice idea but it has some practical problems.

How to implement a self-destruct feature into free trial software?
Stack Exchange
This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 100+ Q&A sites.

theGreenCabbage asks:

I am interested in implementing a free trial version to my existing software. I plan on having the trial last 14 days. Upon the 14th day, my software would prompt the user to either pay for the paid version, or have the consequence of not being able to use it. The free trial version is entirely unlocked, meaning all paid features are there.

However, my dilemma is about the "best" way to implement an end-of-trial solution. Do I delete vital DLLs? Have a user authentication system upon installation or use? Encrypt the initial time and date of use with a salt, and if it's an invalid date (AKA they try to change their initial date), disable the software?

See the full, original question here.

Pie in the sky

Mason Wheeler answers (42 votes):

You're looking for something that's essentially impossible. Some of the biggest, best-funded companies in the software industry have spent years, and millions upon millions of dollars, looking for a way to accomplish what you're trying to do, and it's never once actually produced successful results.

First off, you can forget all about screwing up a local install. As long as the original installer still exists, (or can be backed up, or re-downloaded,) that's nothing more than a speed bump. Even placing something somewhere in system settings means very little when the user can install to a VM and then back up and restore the entire VM image.

The next obvious step is online authentication: set up a server and have the program "call home" each time it's started to check credentials. This doesn't work either. First, you run into the obvious (and highly frustrating) problem of false negatives when the server is down or unreachable for any reason, or has some glitch in its software. And you can't make the software just validate the user automatically if it can't reach the server, or it's trivial to work around the authentication with a few networking tricks, or just by using it on a machine with the Wi-Fi turned off. (And of course, this means that people trying to legitimately use it with a good reason for not having a Wi-Fi connection, such as bringing their laptop along with them on the bus, will be locked out. That won't make anyone like your program.)

The other problem with online authentication is that in the end, it boils down to a boolean somewhere in your code. Somewhere it calls AuthenticateUser() and if it returns True, the user is in, and if it returns False, they're locked out. And no matter what you do to encrypt, obfuscate, or hide the code, if a computer can read it at some point, so can a programmer. Someone, somewhere, is going to produce a crack where AuthenticateUser always returns True, and they'll put it up on the Web.

The fundamental problem of cryptography can be described as "Alice wants to send a letter to Bob, without Charlie being able to read it even if it were to fall into his hands." The problem with what you want is that Bob and Charlie are the same person, which makes your goal impossible.

If you want to make money from your software, twisting your users' arms is not the answer. What will work, the only thing that does consistently work these days, is basic market theory: offer a product that the user perceives as having a greater value to him than the price you're asking for it, and he will be willing to pay. Anything else will just be a waste of time and effort on your part.

Related: "How to prevent users from creating multiple free trial accounts?"

Two clocks

GrandmasterB answers (4 votes):

It's not difficult to do. It really depends on how much effort you want to put into it.

Remember, the purpose of a trial version is to increase sales. All trial version schemes for installable software can theoretically be gotten around by some means, even if it involves tremendous effort, since the code is executed locally and can thus be edited with a hex editor. This answer is working from the assumption that the original poster is asking about practical solutions to this business problem, not theoretical.

As one of the other posters mentioned, the point is to make sure the effort involved in getting around the trial version scheme exceeds the cost in terms of time and effort than the cost of buying the software. Dedicated 'pirates' will simply download pre-cracked versions of your software using BitTorrent. Don't worry about them, as they wouldn't be customers anyway. The approaches below have been taken by countless software companies for decades, and as long as you are not crippled by the notion that such systems must be theoretically perfect, you will find they work quite well out in the real world.

At the simplest level, you could simply keep a start date/end date time "window" in the registry (encrypted). Each time the program runs, you check that the system time is between those two dates, and update the "start" component of that date. That prevents the casual user from simply setting the clock back to allow access to the trial version.

You can extend this by keeping track of that time window in several locations (both in the registry and in your application's data folder), and making sure they match on each start up. That prevents people from monkeying around with the entries—they have to know exactly where they are and how to unencrypt/encrypt the data.

There's a number of other ways to tighten things down as well, which I'm sure you'd encounter as you start developing the trial functionality.

If you don't want to do all this yourself, there are quite a few third-party libraries that provide this sort of functionality.

Note regarding actually deleting files: If your application tries to delete files, it may get flagged as malware by the user's anti-virus software. Anti-virus software is very aggressive these days. And many end users will be convinced there is a virus in your software if their anti-virus program pops up an alert.

Find more answers or leave your own answer at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, log in to Programmers and **ask** a question (it's free).

Channel Ars Technica