Secrets of Copy Protection

by root access  (blakvortex@juno.com)

Remember the time when you downloaded that program, but after a couple of days of using it, a message came up saying that your evaluation time is over and that you gotta pay now?  Then you realized that by changing a number in the program's INI file, or by simply setting back your system clock you could keep on using the program for free?

Well, you can kiss all that goodbye.

Thanks to headlines like "$11 Billion Of Developers' Income Lost to Piracy," a multitude of companies are working on different types of locks that prevent anyone from "illegally" copying or using software.  You probably won't see this stuff in your next version of Quake, but if you've downloaded fully working demos of programs off the Internet, or buy more than $1,000 programs designed by the NSA or NASA, chances are you've already seen these locks at work.

There are two types of software protection locks commonly used today - hardware locks and software locks.

These control everything from the number of days the program stays active, to the number of times the program can be run, to which functions can be executed, and then some.

Hardware Locks

Let's examine hardware locks first.

These tend to hook up to a port on your computer.  Most use either a USB port or a parallel port, although models that use ISA slots, PCMCIA Type II or other, weirder ports also exist.  Most of these are small enough to fit in the palm of your hand, and can have other peripherals connected to them (for example, if you take up a printer port, you can connect the printer to the back of the lock - the locks are made in such a way that they are totally invisible to the user, and other processes running on the system).

You may be thinking "How the hell can a piece of hardware prevent me from running a program?"  Well, it can.

When the program is started, it looks for the hardware lock on the designated port.  If it is not there, the program simply refuses to run.  No and, ifs, or butts.  If the lock is present, a query is then sent asking for an algorithm.  If the algorithm received can decrypt parts of the program, the program will run.  This is just one way it can be done - there are other ways, although they are mostly similar.

The hardware locks may be invoked multiple times during the run of the program, to check whether the user has a right to use this or that function.  Most locks also have the ability to store small amounts of information, such as the number of times a program has been run, or the number of days it's been on the system.

There is a plus side though - programs utilizing hardware locks may be copied as many times as you want (however the lock will be needed to run every copy), and the locks support many different types of networks and OSes.  Also, multiple locks may be daisy chained to the same port, saving hard-drive space, instead of using software locks, which sometimes significantly bloat the size of executables.

However, with these pluses come two big minuses.  First, most locks prevent you from debugging or reverse engineering the programs - i.e., the programs can't be opened into hex editors.

Second, in case you didn't already realize this, the algorithms used in the locks are different for each individual lock, so you can't just buy extra locks instead of buying extra programs and locks - i.e., if you crack one lock's algorithm, that's all you've done - you've cracked one lock's algorithm.

Ways Of Beating The System

All the ways described here are theoretical, as I don't have the time, nor the resources to try them out:

1.)  If you can somehow monitor the traffic between the port that the lock is on and your computer, you may catch the algorithm used.  From there you can probably make an emulator that emulates that hardware lock.

2.)  If your lock is the type that allows debugging, fire up your favorite hex editor and delete the calls to the hardware lock (this may not work on the systems where the algorithm is required to decrypt parts of the program).

3.)  If you are a real hardware person, and have a lot of time/resources on your hands, open up the damn lock, and see what you can find inside.

Software Locks

Software locks are used a lot more than their hardware counterparts (I mean, really, who the hell wants to carry around a bunch of adapters that are easily misplaced so that they can run a bunch of crappy, overpriced programs?).

The bad thing though, is that software locks are integrated into the application they are protecting, which makes it even more of a bitch than hardware locks to beat.

With most of the software locks I've researched, the programmer who creates the application that is to be protected has to himself make calls to the "lock libraries" supplied by the manufacturer of the lock.  The libraries supplied make up the Developer Kit.  Then the program is compiled, linked, and distributed.  This creates an application that is its own protector.  There are no external files that can be messed with (except for maybe DLLs), and since the libraries generally have the ability to keep track of time, you can't just set the system time back.

When the program is first run on its host system, it looks for individual variables that would always vary from computer to computer.  It then makes a checksum of those variables, and displays it to the user (this is the Site Code).  The user is then instructed to call/e-mail/fax the company that gave him the software, and give them the Site Code.  The Site Code is then entered into a Site Key generator, which generates its own checksum (the Site Key), based on the Site Code.  The Site Key is then given back to the user who enters it into the program.  The program then somehow checks the validity of the Site Key (different programs use different methods), and, if it is valid, runs itself.  This is required only once.

There can be different Site Keys for one Site Code.  The Site Key tells the program for how many days the program can run, what parts of the program may be used, etc.  This is also a plus over hardware locks, since the Site Key may be changed over time (from demo version to registered version), without requiring the user to get a new copy of the program.

However, the program may not be copied and/or used on different computers, because the Site Code will be different for each computer (well, actually you can copy it, but you have to pay every time you copy it for the Site Code to be processed and the Site Key to be given to you).

There are two new features that some companies are including with their software locks.  One is the ability to use one executable over a network.  This works on a first come, first served basis, eliminating the need to obtain a license for every user on the network.

The second is "instant protection."  This eliminates the need for a programmer to make calls to the libraries in the source code, but instead encapsulates the executable in a layer of protection (the protection is, however, more limited than it would be through the Developer Kit).

Ways Of Beating The System

Like the hardware lock "ways of beating the system," these are purely theoretical, and what works for one lock may not work for another:

1.)  If you have one of those "Spy" programs that come with compilers (Spy++), you can use them to keep track of the different function calls by programs, and, well, use your imagination from here.

2.)  Fire up the trusty hex editor, and see what you can find!

3.)  Get a copy of the Developer Kit, and decompile the libraries - see what you can find.

4.)  If you can find out what variables the program checks for when making the Site Code, you might be able to emulate them.

5.)  Easiest one - get a copy of the Site Key Generator.

Final Thoughts

Will greater and more expensive copy protection schemes kill off Warezd00dz?  Probably not.

There will always be enough holes so that someone with an IQ of just above average will be able to devise a way to get a working copy of a program.  What will happen is that probably most of the AOL warez kiddiez will not be able to get their copies of Microsoft Flight Simulator 2008 and Hexen IX (notice the time period) for free, and cease to exist.

From then on, software cracking might actually get to a new level of hackerdom, due to the new challenges, where the hunt will be more important than the kill.