Robert Fruit has 20 years experience using computers to solve business' problems. For the last ten years that work has been with PC computers. He frequently contributes articles to various computer magazines. He can be contacted at Simulation Rule, P.O. Box 295, Clarendon Hills, IL, 60514
Hardware locks, an alternative to copy protection schemes, are more reliable now than they were in the past. For this reason, I wrote this article to provide you with enough information to decide if hardware locks should be investigated. This is not a review of hardware locks, and no recommendations will be made about which ones work better than others. For a list of manufacturers, see Figure 1.
Hardware locks consist of two parts. The first part is the physical lock, a plastic piece about two-inches square with 25-pin connectors on each end. Physical locks usually attach to the computer's printer port, but are available for both the parallel and serial ports. Inside the physical lock is an EEPROM. The lock manufacturer puts special codes and algorithms on the EEPROM chip. The manufacturer will not tell you, nor is it necessary for you to know, what those codes and algorithms are. The physical lock communicates over the printer's signal lines, not the printer's data lines, to prevent any conflicts with the printer's normal operations. The physical lock receives those signals, modifies them based on its internal codes and algorithms, and returns an encrypted value.
The second part of a hardware lock is the lock program module, an object program that can be linked into the subject application. The lock program module handles the direct communications with the physical lock. Based on the signals received from the physical lock, the lock program module will return a value that confirms the presence or absence of the physical lock. The application then uses this value to decide whether or not to continue running.
It is the application's responsibility to learn the result of the lock test, interpret that result, and then provide an action if the lock is absent. Also, the application should test for the lock periodically to prevent the lock being moved to another computer to start an illegal copy. Exiting to the DOS prompt should be an adequate response if the program just started. However, if the lock test fails after the application has been running for a while the application should give the user the chance to save before returning to the DOS prompt. Important data may reside in the computer's memory, but not on a hard or floppy disk, so a direct exit to DOS would cause a loss of data.
To simulate using a hardware lock this article contains a header file, FAKELOCK.H (Listing 1) , and three program listings, FAKELOCK.C (Listing 2) , TESTLOCK.C (Listing 3) , and TESTPROG.C (Listing 4) . FAKELOCK simulates communication with a lock's program module. TESTLOCK feeds input parameter's (in this case, a string of characters) to the lock's program module to see what values are returned by the hardware lock. After choosing the lock-calling parameter and learning its encrypted value, the programmer can write the application that will use the lock. TESTPROG simulates a program that uses a lock.
FAKELOCK.C (see Listing 1 and Listing 2) would normally come from the hardware lock's manufacturer as a compiled object file. The calls to FAKELOCK would be added to the application, and FAKELOCK.OBJ would be included in the link step. It's unlikely that you have access to a physical lock and the lock's program module, so FAKELOCK is designed to simulate both the lock's program module and the physical lock.
FAKELOCK input parameters are a pointer to a string of characters and an integer. The string of characters becomes the input to the simulated physical lock. The simulated physical lock changes the input string of characters into an integer. That integer becomes the return value from FAKELOCK.
FAKELOCK takes a few steps that would not normally be part of a lock's program module. Primarily, FAKELOCK transforms the input string into a return value. This would normally be part of the physical lock's action. FAKELOCK simulates the physical lock encryption algorithm by doing a bit-wise AND between the input parameter's first four bytes and every block of four bytes after that. A hardware lock manufacturer uses a more sophisticated algorithm.
FAKELOCK simulates two locks. The test program can simulate what will happen if a lock cannot be found. Based on the second parameter, one of two bit-wise exclusive OR's can be used before returning a value.
The best way to learn how a hardware lock responds to input parameters is to build a test program and write the lock's return value to the screen. TESTLOCK is such a program. <RETURN> terminates the task cycle.
Figure 2 contains an example of a dialogue with TESTLOCK. Note that when you give the same input string, and request the same lock, TESTPROG returns the same value. The first and last loops of TESTLOCK in Figure 2 are for the same input parameters.
TESTPROG (Listing 4) is an application you can lock with FAKELOCK. TESTPROG has a main function and four subsidiary functions. Of the subsidiary functions, func2 and func3 are called frequently when TESTPROG is running and func1 and func4 are almost never called. Another function CALL_LOCK, calls FAKELOCK and terminates TESTPROG when the lock check fails.
The most obvious place to check for the hardware lock is at startup. But checking at the start of some key steps can be useful in preventing a user from moving the lock to another computer to start an illegal copy. Testing for the lock when calling frequently used functions makes the checks occur with some random time element, but not frequently enough to slow the operation of the computer noticeably. An application like TESTLOCK checks for the hardware lock when calling the most frequently-used functions (such as func2 and func3). func4 also tests for the hardware lock, so the user can enter the input string sent to FAKELOCK. Normally calls to func1 and func4 would not include lock checks. They are called infrequently and would contribute very little to controlling the use of TESTPROG.
CALL_LOCK makes the calls to FAKELOCK. CALL_LOCK asks the user to select a lock to use, 1 or 2. CALL_LOCK only knows the input parameter/return value pair of abcdefgh and 19334. This is the return value for lock 1. If lock 2 is chosen, CALL_LOCK finds a different return value, and thinks the hardware lock is missing. In this case, CALL_LOCK will not allow TESTPROG to continue. Including two lock calls for CALL_LOCK and letting the program user select which one to use, simulates the lock being removed and then reinstalled.
Figure 3 shows a typical run of TESTPROG. Every time it calls CALL_LOCK, the program asks Which lock is to be called (1 or 2):. The usual answer for this question is 1. The second time TESTPROG asks this question the answer 2 is given, to simulate the lock not being attached. CALL_LOCK reports the missing lock and asks Enter another lock to try (0 to exit to DOS, or 1 or 2):, giving the program user the opportunity to enter another value. This time 1 is entered as if the lock were reattached to the computer and TESTPROG continues. When the program reached func4 the user has the opportunity to enter the string passed to FAKELOCK. If abcdefgh was used and lock 1 selected, TESTPROG would continue to its logical end. In Figure 3, qwerty was given to func4. Now, no matter what lock is selected, CALL_LOCK will not find the lock. The only way out is to select the 0 option.
The programs and headers in this article were compiled using Borland C++ 2.0. But these are C programs, not C++ programs. They were not tested.
The lock-calling techniques used in a commercial application will be more complex then those in TESTPROG. The keys for the lock will often be encoded or broken into noncontiguous pieces so someone exploring the application with a debugger will not usually be able to find them. Frequently, an application will test for the lock at one location, but wait until it reaches a second location before deciding to stop the program. The material sent by the hardware lock manufacturer will include several suggestions for use. The application developer must decide how it is to work in the application.
Hardware lock manufacturers supply many lock program modules. They will usually have a lock program module for the major languages and the major compiler manufacturers. This means that hardware locks can be used in a variety of applications.
Real hardware locks can work as well and as problem-free as the FAKELOCK demo. In the past six months the firm I work with has delivered over 200 applications with hardware locks installed. None have had problems with the locks. Sometimes the people installing the programs do not understand how to use the locks, but a quick explanation of how to install the lock solves that problem.
Hardware locks are not nirvana for application developers. Though my experiences have been free of computer/printer problems, the literature reports that some locks do interfere with printers at times. Some locks require the attached printer be turned on or the lock will not operate. Hardware locks make preemptive use of certain computers interrupts, which may interfere with background printing. So, background printing will probably not work while a program that uses a hardware lock is running.
The space the locks take behind the computer can be a problem. I work with four different programs and each one uses a different lock. When all four locks are attached to the back of the computer the locks stick out more than eight inches. One lock will usually fit in the average space between the back of a computer and the wall. Four locks will not. You can solve this problem by getting an RS232 cable with all 25 pins wired. Plug the RS232 cable into the computer and put the locks onto the end of the cable.
Cost is another factor limiting the use of hardware locks. Copy-protection techniques use a physical device already sold with every program, the floppy disk. The only expenses are the cost of including the copy-protection software in the application, and sometimes a slightly more expensive disk-duplication process. Hardware locks on the other hand have an expensive, separate device that must be purchased also. When buying them in lots of 100 hardware locks cost about $30 apiece. Obviously, it is not cost effective to put a $30 lock on a $20 program. The only programs that make this cost effective are those that already have a high cost.
Hardware locks are a possible alternative to copy-protection techniques for developers of high cost applications. After some investigation the program developer can make that decision.