Protecting Your Application

Protecting Your Application - The Overview

by Tom Hebenstreit, Review Editor

Published 1998-08-01 Printer-friendly version

Program protection - what is it and why do you need it?

To answer the second question first: Money, i.e., getting paid for your work. The answer to the first question is what the rest of this overview is all about.

By the way, when you are done with this, be sure to read "Protecting Your Applications - The Tools". It will examine in-depth four tools which make it a snap to implement very powerful copy protection into your applications.

I thought copy protection went out years ago…

For the large commercial software houses, that's pretty much true. But, then again, you and I aren't Microsoft with an army of lawyers in our pockets, are we?

As software gets easier and easier to distribute via the Internet, it also increases our reach as small developers - we can now reach a fairly large audience that would have been virtually impossible to get to even a few years ago (when's the last time your programs had shelf space at the local computer megastore?). Unfortunately, we also find ourselves in the same position that the big commercial house were in way back when, and so feel the same need to protect our products from unauthorized (read "unpaid") use. For us, it becomes ever more important since, as small developers, we can't afford to write off any income due to software piracy.

So how can we protect our precious applications, then? Glad you asked…

First, about Locks and keys

Throughout this article, I will be referring to 'registering' or 'unlocking' programs or features. Think of these terms as the equivalent of sets of keys (the house or car kind, not the file kind). Protection tools put 'locks' of one type or another in your software that restrict access (just like the lock on your front door), and, just like your house, these locks require a unique key to unlock them. One trick thing about these software keys, though - most of them can be time locked so that they only work for limited periods or after a certain date.

What form can those locks and keys take? Well…

Loads of modes

Protection can be active, passive or both. Passive types rely on either simply trying to convince the user to be honest using nag screens, or in many cases, displaying something like "Unregistered Copy" all over itself. Active modes will modify the program's behavior in ways ranging from disabling a few features to outright refusal to run.

To actually implement these, every version of protection which we will look at relies two things:

The program "knows" its state at all times. By this, I mean that it knows what mode it is in, e.g., demo versus unlocked, about to expire or already expired. Each of the products we will look at uses an encrypted file of some type to store its protection information and state. This information can range from a simple number to information such as their name and a unique serial number, concurrent user information and more. Each of the tools also protects those files ferociously - any attempt to tamper with them or replace them will usually result in the user being completely locked out of their program.
Some type of mechanism is in place for the user to change the program state at their location. For example, from unregistered to registered or expired to active again.

For item 1, you determine the program's initial state when you compile it. The options you set in your protection tool templates are stored in a file which you ship, and the first time the program runs it will trigger them. This could be anything from simply displaying a nag screen to demanding that the program be registered right then and there. (Note that some tools can create the file on the fly using your defaults – in either case, the effect is the same.)

Item 2 provides the way for the user to tell the program that, yes, it is ok to unlock or activate. It usually follows a sequence of events like this:

Something happens to trigger the program to request an unlock code. This can be the first time it is run, or maybe that it is about to (or has) expired. The customer must now obtain the unlock code or be locked out of the program.
They call you up. You fire up the trusty program that came with your protection tool which creates unlock codes.
You ask them for certain information, such as company name, etc., and most importantly, for a unique serial or ID number which the user's copy of your program will create. This is the magic piece of information which ties the unlock you are about to create to that one machine.
You take that information, feed it to the unlock program and it will then generate a code (or codes) which you give to the customer.
They enter the unlock code into their copy of the software, and 'voila', everything works.

For many products, you get the unlock code right along with the software (of course, you only get the software after payment has been made). The first time you run it, you enter the code and you are done. The delayed methods are generally used for trials, demos and licensed software (software that must be paid for annually or it will expire).

So what kind of options do you have? Quite a few, as you will see. Let's start at the top (or bottom, if you prefer) and take a look at the basic way these tools work.

Copy Protection versus Installation Protection

Although these two functions are usually lumped together under the term of "copy protection", they actually serve two very distinct purposes in my mind. (Actually, the term "copy protection" is a bit of a misnomer nowadays -- a holdover from the old days when software houses would actually use various schemes to try and prevent the physical copying of the contents of a floppy disk.)

Installation Protection

Installation protection is what most people commonly refer to as copy protection. It basically concerns itself with preventing the user from buying a single copy of your program and then running around and installing it on every machine in sight. Oh, yeah, and then giving a copy to his friend at the next company to do the same thing.

Using this type of protection, you program will basically refuse to run until the person trying to install it contacts you and gets a code to unlock the program. Alternatively, it could always install itself in a limited trial or demo mode. The desired result is always that they must contact you (money in hand) in order to get the thing to actually work on a permanent basis.

Copy Protection

Ok, let's say a fictional user contacted you and paid up – great, right? Sure, but then he copies the unlocked program he now has out to the network and lets everyone copy it down to their machines. This is what I now refer to as real copy protection: simply preventing the user from duplicating an unlocked installation on other machines. How do we deal with this? We've given them the unlock already, it's out of our hands, right? "Hah!" we say.

The keys to the kingdom

It doesn't matter how many copies of the floppy they make, how many they time they install it or even if a particular copy has been registered and unlocked. The essential point to grasp is that your protection tool will use one of two methods (discussed below) to uniquely link each installation of your software to either the user (or company) that purchased it or the physical location where it was installed.

What this means is means that the key used to unlock the same program will be different for -every- installation.

The key for user A will not work for user B, so even though they can copy the program all they want, user B -must- register the software with you in order to use it. This is done using one (or both) of the following methods:

Software based Protection

Using this method, the software will use some scheme that usually involves file sizes, locations, contents, or whatever to uniquely identify the machine it is being installed on or the customer who is installing it (in this case, it just asks them). It then saves that information, and checks it every time your program is started. If it finds anything wrong, it will trigger whatever you told it to do when it detects tampering. Generally, this means calling you to get a new unlock code.

On the plus side, this method allows the user to pretty much change hardware with impunity (updating a BIOS for Year 2000 compliance, for example). On the down side, a really determined user could probably figure out which files would need to go where.

Hardware based Protection

Under this scheme, the software will actually store information about the hardware it is being installed on. Generally, it will use either BIOS (Basic Input Output System) information from the motherboard or the serial number from the hard drive. Just like software copy protection, it checks every time the program starts to be sure that the hardware matches the configuration which was first stored when the program was installed.

The up side of this method is that it is very hard to fake, and thus is more secure. The downside is that your protection can be triggered by common hardware upgrades (remember that Y2K BIOS update). Once again, they would need to contact you and have you issue a new unlock code for the new or upgraded machine.

In either case, this user or machine specific information is used when creating an unlock key, and that provides the variable factor that allows the same program to come up with a different key every time.

Ok, so that's how the tools do their magic. Now let's take a look at the many options they can offer us to use upon this foundation. Use the following list as a reference when you get to looking at the lists of options which each particular tool supports.

Protection Tool Options

Note: Quite often, many of the following items can require their own unlock, since they can be used in combination with other options. For example, a user may register to switch from demo to normal mode, but still need another unlock to get access to optional or special cost features.

The Ever Popular Nag Screen

Nag screens are simply screens which pop up every time a program is run to tell the user something they probably already know, such as "This is an unlicensed copy". They are also used to inform the user of pending expirations and so forth. Normally, you should be able to control how often and where these screens are seen.

Branding

Branding is done with a red hot metal poker, so you have to be careful not to damage your monitor (…no, wait! Let's start again …).

In software terms, branding means placing some identifying piece of information all over the program (on every window and report, for example). Usually, the company or user's name is used. The basic theory here is to embarrass people into registering, since it isn't terribly businesslike to have some other company or person's name on everything you create with the program (unless, of course, your name happens to be "Unregistered User").

This is probably the most common do-it-yourself method of program protection, and one of the simplest to defeat unless you are careful (or use one of the tools we will look at later). For most tools, you only allow the user to change the name when they register. If you are sneaky, you let them change the name and that triggers the tamper protection which forces them to contact you. Note that this can also be triggered by a legitimate company name change.

Program Expiration

This is used for a multitude of purposes, the most common of which is creating what are commonly referred to as "unlimited trial versions" - programs which expire after a certain date. All of the program's functionality is available, nothing is limited or locked out (well, except the user after the specified number of days).

The best tools offer you the ability to specify either a fixed date (the program dies on September 1, 1998) or a set number of days (the program dies 30 days after it is first installed and run).

Fixed expiration dates would normally be used for things like Beta test versions, where you don't want the user to simply use the beta forever, or for licensed software, where it may simply expire on the first day of every month, or at the beginning of each year.

A set number of days is usually used to limit demos, etc., since you never know when a prospective customer will download and install a program. You don't need to worry about it, the program will keep track of it all.

Nag screens are used to inform the user of pending expirations, and the better tools let you specify when they start popping up. For example, to have them start appearing on the day 25 of a 30 day trial.

Tamper notes: By far the most common trick tried by users is to simply set their PC clock back to a time before the program expired. Uh-uh. Good tools keep track of when they are run, and will still be locked out regardless of the current date. The best tools also prevent the user from simply reinstalling the demo to try and get another free 30 days or whatever.

Program Mode Restrictions

This is most often used in what it known as a "limited demo" version of your software. They have the standard package, but certain things will be unavailable until they actually register the program. It doesn't expire (unless you want it to), it just doesn't let them do everything.

You can restrict menu items, entire procedures, or just certain actions within a procedure. Once they register, the system will automatically make those options available.

Examples: No access to the reports menu, no access to the update form for a browse or maybe just hiding the OK button on the update form so that they can't actually save.

Run Counters

These allow you to specify that something should only occur a certain number of times. Most often, they are used to create a demo or trial version which can only be run, say, 25 times before it must be registered.

In some cases, they can also be used for licensing, such as a case where a particular function costs X dollars every time the user uses it. In this case, they would pay you in advance for a certain number of uses, then you would give them an unlock. Every time they use the function, the counter will decrement. When it gets below a certain level (set by you), you can have the program start to nag them about buying some more. Note that each time they will need a new unlock - old ones don't work.

Revert To Demo

This option is used when a program running in a particular mode expires (could be date, run counter, whatever). Instead of locking out the user, it will revert to a more limited 'demo' mode where, for example, no new items can be added or reports can't be printed. The user would still need to contact you for another unlock code.

Multiple Modules and/or Program Levels

A variant of the previous item, this allows you to ship a full program, but only let the user have access to particular portions of it even after registering. For example, you ship a full accounting system, but they didn't buy the payroll module. With this option, they can pay you for that module at a later date, you give them an unlock and 'presto!', the module is now available. Until they do that, though, any attempt to run payroll will just result in a message (where you naturally encourage them to buy this fabulous module).

Program levels accomplish the same task, only let you do it based on a mode basis (Lite, Standard, Enterprise, etc.) rather than a module by module basis. As the mode goes up, so do the features - all from the same program. No more multiple app version hassles.

Record Limiters

This option lets you specify limits as to the number of records a given files can contain. For example, maybe no more than 5 contacts can be added while your contact management system is in trial mode. As usual, registering automatically removes the restrictions.

Network Concurrency

This is a great option (and a great way to make more money off of your programs). The theory behind it is that you are not selling multiple copies of the program itself, you are selling licenses for using the program. They can install it on hundreds of machines, but only X number of people can use it at the same time.

If they need more people, they pay more money to get another unlock which adds a specified number of users. To offer a 'site license' for unlimited users, you simply give them an unlock for a huge number of users (a million or so, maybe?)

Tamper Note: An unlock is tied to a specific number of users, so they can't ask you for an unlock for 5 users and then try to surreptitiously use that unlock to enter 500 users. In the same manner, using the 5 user unlock 5 times will still result in 5 licenses, not 25.

Serial Number or ID's

Tools with this feature will create unique serial numbers or ID's for your programs on the fly as part of the registration process. The users give you the serial number, etc., when they register the program and that number is also used when creating unlocks. These can be handy for tracking installations, etc.

Developer Keys/Application ID's

These are intended to prevent someone with the same protection tool as you from generating unauthorized unlock codes. Basically, you embed certain unique information into your application which is then stored in the protection files. The magic unique numbers generated by your programs to identify themselves are tied to this embedded information, so unlock codes from anyone but yourself simply will not work. (They contain the other developer's unique information.)

Time Sensitive Unlock Codes

You can use this type of option to limit the lifespan of the codes you issue. In other words, you can not only make your programs expire, you can make the unlock codes themselves expire. For example, a code may be good for only seven days from the date of issue. If the user doesn't use it by then, it will no longer work.

A few general tips…

Since all protection schemes rely on manipulating information in exact ways, it is imperative that both you and your users always enter the same exact information when creating and entering unlock codes. If, for example, the user types "Big Company, Inc." and you create an unlock based on "Big Company ,Inc" (note the missing period), the unlock will not work. By the same token, when you identify your application in a protection tools template, you must use exactly the same information everywhere else. It all starts in your app, so be sure you like what you put there!
When testing various options, you should try them on a machine other than your development one. It is entirely possible to lock yourself out of your own applications by mucking around too much on that machine. (Word to the wise and all that…)
Think about the various ways these tools might be used to increase revenue from your existing programs by using, for example, network licensing or optional modules.
If you have ever tried to create a separate demo of one of your programs, give yourself a break and just use one of these tools. You program becomes your demo, and hence is always up to date. Indeed, your "demo" then becomes a great sales tool as well because it has all the features!

As we have seen, Protection tools can give you many options as to how your programs will go about protecting themselves. The most important thing to understand about their use, though, is that you need to have a thorough knowledge of who your prospective customers are and to tailor your protection system to their needs as well as your own.

For example, let's say your program aimed at a larger clients, ones with fairly sophisticated network resources. Let's further assume that they are running what are known as "mirrored" servers, where everything written to one serve is automatically duplicated on the second, backup machine. In situations like this, if the primary server fails, the network will automatically switch over to the second server – allowing those essential business processes to just keep on humming along while the first server is restarted, repaired or replaced.

Now, you have sold them your top-of-the-line, conquer-the-world-in-five-minutes masterpiece, and just happened to include one of the copy protection schemes which tied the installation to the hardware upon which the program was installed. Everything works, everybody is happy. Then one day, the primary server dies and the system rolls over to the backup. Everything is fine, except that your program now calls them criminals (so to speak) and refuses to run because it is no longer on the hardware where it was originally installed. Can you say unhappy customer (a dead server AND this problem)?

Another case: Perhaps you have designed the best wedding invitation designer program in the world. Would you want to distribute it with as a 30 day unlimited trial? Not really, I'd think, since they could be done with it before it ever expires. A crippled demo would be better in this case (maybe do everything but print).

The point is to really give a bit of thought as to how and where your program will be used, and how it will be distributed, before implementing any program protection scheme. In the worst scenarios, it is entirely possible to do this in a way that loses you customers rather than gaining them.

So our goal, then, is to strike that perfect balance between protecting our interests and not annoying the heck out of customers. To this end, our ideal protection system will ensure that a) we can actually encourage users to pass around our install disks and try it out, and b) that we get paid for every copy that is actually being used.

Is this possible? To quote a famous philosopher, "You bet your bippy it is!". Even better, we Clarion users have a nice selection of tools and options to choose from to easily accomplish that goal.

Just the facts, Jack

This concludes part one of our two part look at Clarion protection tools. Now that you have a good grasp (I hope) of all those protection tool concepts, terms and methods, it's time to move on to our in-depth look at the four leading products in (drumroll, please…) "Protecting Your Applications - The Tools".

See ya there!

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942