What actually tends to happen is that real customers get hassled with complicated password and key-checking schemes that do not work, and that people who would not buy the software anyway simply download a patch, crack or key.
I am sure most of us have encountered annoying copy protections. A couple of years ago, I purchased a copy of Norton Internet Security in order to protect my Windows-based PC with a decent firewall. After several retries, reboots, and typing of lengthy keys, I gave up in disgust: the software would only intermittently admit to the fact that this was a legal copy; most of the time it would not start, or claimed to be in evaluation mode. In the end, I installed a pirated copy that gave me no hassle at all – but has since given way to a free alternative.
Let’s face it: almost any protection system, no matter how primitive, can prevent the average user from copying the software. On the other hand, there is no system that is 100% secure, and it takes just one dedicated hacker to publish a patch somewhere on the net – everybody else just need to be able to google for it.
Given this sorry state of affairs, why do software publishers continue to spend money on complicated but still simplistic schemes that do nothing but annoy their legitimate customers?
To answer the question and give some unsolicited advice to people publishing software, I will look at 3 separate categories of software: Shareware, Commercial software and Enterprise software. Free software is already Free, so it doesn’t warrant discussion here 🙂
For customers of this category of software, software licence compliance is a big deal, and they rarely seek to avoid paying the fees for the software that they need. Instead, any protection scheme in this class of software should be geared towards licence compliance, i.e. ensuring that the customer is made aware when the number of licences purchased is insufficient or when a module that he or she has not paid for is required.
As a result, the system applied does not need to be particularly secure against hackers (since hackers most likely don’t want or need this the software, and certainly would not pay for it if they do), but should be of high quality and provide good messages to the user when a licence violation has occurred or is about to occur. Fortunately, this type of system is relatively easy to design and implement so it’s all good news for these people.
This label is possibly a bit misleading, since any software that is charged for could belong in this category. What I mean is software that is mass-marketed, shrinkwrapped and in the $75-1500 category, i.e. products from publishers like Adobe, Microsoft and Symantec.
Software in this category is what most of us use on a daily basis, yet it’s not so cheap that the cost is insignificant. As a result, it is naturally the most attractive market for hackers (they want the software, and so do all their friends) – and unfortunately, it is also the market where it is most difficult to set up good hacker countermeasures.
Because software in this market is mass-produced and not tailored to a particular customer, the software has to run in the form that comes on the CD or DVD. This is the crux of the problem.
The most common form of “copy protection” used for this class of software is a CD key of some sort. The CD key is relatively short and a unique key is printed on the CD or in the manual; during installation or when the software is first run, the customer needs to type in the key. Some of the more sophisticated (or annoying, depending on your perspective) ones attempt to contact a server on the net to determine if the supplied key is valid, invalid, or a known “pirated” key that has been found on the net.
Unfortunately, this type of protection is inherently not secure enough to avoid being broken, and it’s normally circumvented in one of 3 ways:
- Someone buys the software and places his key on the internet
- Someone figures out how to change the software so it will accept any key you might enter
- Someone figures out how valid keys are created and makes a “key generator”
The first one is annoying, and can only be prevented by requiring the user to register his key on a central server and then check for duplicates. Of course, this can be circumvented as well (using the same techniques as desribed below for the second item), and all this really does is annoy legitimate users who now cannot use their software without being connected to the net.
The second one sounds hard (i.e. change the software), but isn’t really: let’s spend a moment to look at why that is. In pseudo programming, the code internally may look something like the following:
Get-Key-From-User; if Check-If-Key-Is-Valid = True then Everything is fine else Ask user to enter another key
Check-If-Key-Is-Valid routine is almost certainly very complicated and very difficult to decipher. But to a hacker, this doesn’t matter! All he has to do is find the place where the routine would return
False (the code is not valid) and change it to always return
True instead – and now every key you might enter is valid!
To a hacker, this is unfortunately very simple to do. And since hackers don’t like to do things that are easy (there not much of a reputation to gain by doing something easy, I guess), they tend to go even further and implement option 3: the Key Generator.
Now, this is something that could be prevented: technology exists that should make it very hard to impossible to create a key generator. For some reason, most publishers do not realize this and use algorithms that are easy to reverse engineer instead – where all they had to do is use a public/private-style infrastructure where the public key is embedded in the code, and the private key is required to generate a valid CD key. With this approach, the CD keys would be longer than they are today in most cases, but not so long as to be impossible to type in. And while it would still be possible to change the code to accept any key, it would be close to impossible to write a Key Generator.
Most shareware is protected with abysmal protection systems that in their implementation resemble the pseudo code shown above – and thus can be circumvented in a few minutes in various ways.
From a licensing point of view, the author has several advantages over publishers of commercial software:
- The Trial version does not have to do everything the Full version does
- The author knows the name, or at least email of every user of the Full version
- The key does not have to be so short it can be typed in. A cut/paste from an email can be very long without annoying the user
This means that if the Trial version does not include all of the code or data necessary to run all of the registered functionality, then no amount of hacking can make it work like the Full version. So, by simply limiting funcitonality in one or more ways, the simple “hack the Free version” option is eliminated.
Since it is not important that the “key” be very short, since it will be sent to the user via emeil, the code or data required to turn the Trial version into the Full version after registration can conveniently be distributed as part of the key. And since each key is assigned to a particular user, the temptation to publish the key on the net might be a little smaller – particularly if the user name is displayed when the application is run.
To illustrate the principle, take a look at this piece of code from some hypothetical shareware application:
if IsRegistered then RegisteredFunctionality( GetKeyValue(3) ) else AskUserToRegister;
IsRegistered call is similar to the code shown above, and a hacker can easily change the program to “pretend” the application is always registered. However, we assume that the
RegisteredFunctionality call needs a vital parameter, and the value of this parameter is not included in the application. Instead, it is retrieved by calling
GetKeyValue, which retrieves the value from the user’s key – and this obviously will not work if no such key is available.
Finally, if a public/private key mechanism is used to generate the key for each user, it also should be very hard indeed to make a new valid key (say, to create a key with a nonsensical user name), even for someone already in possession of an authorized key.
There are several more subtleties involved in making it really secure, but the basic outline provided is a good starting point. I even implemented something like it in a shareware application of my own (SecureIt) many, many years ago. I am currently working on a modernized Windows version of it – if I find the spare time, it may even eventually be released 🙂
I also have to mention CD checking, which is a commonly used protection mechanism, particularly for computer games. The principle behind it is that the original CD or DVD has to be in the drive, or the application will not run.
The downfall of this mechanism, like for many of the others mentioned, is that it does not add any information to the application – it is just another check that can be removed by a skilled hacker. Witness the number of hits if you google for nocd hack. I have yet to buy a game protected in this way where I have to use the CD – NoCD hacks are normally out very quickly…
Protecting software against illegal copying ranges from hard to impossible when faced with a skilled hacker. The only way to protect against a simple hack is to ensure that registering the software or typing in a key of some sort adds information to the program. If it is just a check against a complicated “is-this-a-valid-key” routine, it can and will be broken, removed or circumvented.
If only more companies would realize this, and stop investing in virtually-useless copy protection schemes that annoy users that buy their software, I would be happier. If publishers of commercial software want to have a decent level of protection against piracy, they have to adopt a more shareware-like distribution approach.
This doesn’t strike me as a likely outcome, so we will probably continue to work with annoying but mostly useless protection systems in the future.