WO1993021582A1

WO1993021582A1 - System for protection of software

Info

Publication number: WO1993021582A1
Application number: PCT/US1993/003669
Authority: WO
Inventors: Mark Lieberman
Original assignee: Mark Lieberman
Priority date: 1992-04-20
Filing date: 1993-04-20
Publication date: 1993-10-28
Also published as: AU4107393A; CA2133960A1

Abstract

A system for protecting (10) computer software against unauthorized copying or use includes writing to and reading (47) from storage media such as diskettes (10) and determining whether the storage medium is authorized based upon the results of the write/read (47) operation (436-446, 464-466). In a preferred embodiment, a software medium (30) is prepared for distribution (10) of an application program by writing a scrambled version of the application program (40) and an install program (20) that determines whether the medium is authorized by evaluating bad spots (434) in the medium. A similar mechanism protects against unauthorized copying of an application form a hard disk (418) drive or a computer's memory. The system provides a simple software-based mechanism (46) for turning it on another computer. The system provides for emergency use (44) of the application program in the event that the authorized distribution medium (10) becomes unusable.

Description

SYSTEM FOR PROTECTION OF SOFTWARE

Field of the Invention

This invention relates to software protection, i.e. inhibition of unauthorized copying or use of computer software. More particularly, this invention relates to a software-based software protection system, which does not rely on specialized hardware to protect the software.

Background of the Invention

Unauthorized copying and use of software 10 ("software piracy") is a problem that has cost software publishers billions of dollars per year since it became common for users to purchase standard software products. Software is typically distributed on a removable storage medium such as a magnetic or optical disk or diskette, and 15 such terms may be used interchangeably herein. It is estimated that for every five units of software sold, four are pirated. The annual loss to software publishers from software piracy is estimated at over $3 billion per year.

Two approaches have been used to attempt to 20 protect software against piracy. Hardware-based software protection systems include an auxiliary piece of hardware which is distributed with the software and which must be installed in a computer, such as by being connected to an I/O port, to permit the computer to run the protected 25 software. Such systems can be highly effective, since the

**• hardware "keys" can be made difficult to copy. However, hardware-based software protection systems are typically expensive, and thus suitable for use only with expensive software packages. Such systems can permit use of the software on different computers while restricting the use to one machine at a given time. However, it is often inconvenient to remove the hardware "key" from one machine and install it on another.

Software-based software protection systems have also been developed. Such systems are relatively inexpensive, and therefore are more suitable for use with less expensive, mass-marketed software. However, such systems are generally ineffective, and may be defeated by software programs such as COPY II PC which are readily and inexpensively available. While mass copying of software for resale is unusual in the United States, small scale copying is not. A person may make a few copies for friends, or for use on other machines at work, or to permit use of the same software at home and at work. The cumulative effects of such small-scale copying represent a major loss to software publishers.

Much software that has been distributed with software-based software protection has run into criticism by users because it is time consuming to move the software from one computer to another. If a user uses the software at the office, it may require 30 or 40 minutes to uninstall it at the office and reinstall it at home. Summary of the Invention

It is therefore a general object of the invention to provide an improved software protection mechanism.

It is another object of the invention to provide a software protection mechanism which is highly effective.

It is another object of the invention to provide a software protection mechanism which is inexpensive, so that it may be advantageously used to protect a wide range of software.

It is another object of the invention to provide protection for software on its distribution media, while installed on a hard disk, and while in use in the computer's main memory.

It is another object of this invention, that in case the user's installed copy of the protected software becomes not usable, the application software may be reinstalled after the user calls the software publisher for data to allow the reinstallation.

It is another object of the invention to provide a software protection mechanism which does not interfere with other software protection mechanisms which may be used by a software publisher. It is another object of the invention to provide a software protection mechanism which is easily employed by a software publisher.

It is another object of the invention to provide a software protection mechanism which minimizes inconvenience in using protected software on different machines at different times.

It is another object of the invention to provide a software protection mechanism- which permits the user to run the protected software in the event that the original copy becomes unusable.

The present invention is based upon the recognition that the software distribution medium itself has or may be provided with physical attributes which are sufficiently distinctive and sufficiently difficult to copy as to be useful in a process for determining whether a particular distribution medium is an original or authorized copy or an unauthorized copy. The present invention provides software which operates in conjunction with such distribution medium attributes to provide a novel software protection system.

This invention - provides a mechanism that produces diskettes with a scrambled, thus not usable version of the software publisher's application program. This diskette is supplied to the user with an INSTALL program that verifies that the diskette is the original by the existence of bad spots (physically altered locations on the diskette that will not properly record data) on the diskette. -The INSTALL program verifies that the bad spots are real by reading and writing to these diskette sector locations. Accordingly products like COPY II PC which copy diskettes including bad spot indications in the File Allocation Table will copy the diskette, but the INSTALL program will not run because the indicated bad spots are not really bad.

In a preferred embodiment, the program for bad spot verification is made difficult to analyze and/or bypass. According, the program code that reads and writes to these bad spots is unpredictably scattered throughout the program to make it very time consuming for an expert to debug and fool the program. In addition, at random times during this write/read process, the write/read tests will be done by a separate spawned program that will have its own ability to stop the process if the results of the write/reads are not what is. expected by the spawned write/ read program. This makes it very difficult for a computer expert to block or alter the actions of this invention to protect the software application. The order of reads and writes is also not predictable. This makes it very difficult to guess what the program expects from the reads and writes. The locations of these bad spots are used in the formulas to scramble and unscramble the application program file. Thus, creating a diskette to look exactl like the original as far as formatting and bad spot locations would take much more time than it is worth. The main value of the above protection mechanism is that the location of the bad spots must be verified by the ^'INSTALL program as being in the same place as the original. This is very difficult since the sectoring and timing functions of the computer's formatting programs do not start the tracks in the same place. The probability of creating an exact copy of a bad spotted diskette is very, very low. If someone does spend the time to copy a diskette, he will not be able to mass distribute this copy mechanism because the bad spots of the next diskette will most probably not be in the same place.

In a preferred embodiment, there is a hidden scrambled USER RECORD on the diskette with other data that is used in the scramble and unscramble formulas. This means that this record, which cannot be seen by the computer's file system because the file system did not write it, must be located, read, and unscrambled. It must then be. used to unscramble the application program file. The software pirate must find and unscramble the hidden USER RECORD, which has values to unscramble the application program file. These values can be changed periodically. The order of the fields in this record may also be changed periodically. One additional step to foul the' efforts of the software pirate is to actually change the scramble and unscramble formulas. These things prevent a copy protection break mechanism that will work past a short time.

In another aspect of the invention, a "ONCE INSTALLED PROTECTION" capability is used to protect the software- from piracy from the hard disk or from the computer's main memory. During the install process, a set of data unique to this specific installation is stored in a ONCE INSTALLED PROTECTION program. When the protected application program is run it spawns this program which checks the current computer's file system information about the software applications program file. If the data returned by the computer's file system does not match the data stored in the ONCE INSTALLED PROTECTION program, the application program file will be erased and the program will not execute. In addition, the location of hard disk bad spots along with the status of these bad spots is used to verify that this copy of the application is valid for use. This protection prevents the pirating of the application from the installed hard disk or the computer's main memory. In both cases, the ONCE INSTALLED PROTECTION mechanism, which requires the presence of the original hard disk status to run, must be present with a matching original ONCE INSTALLED PROTECTION PROGRAM.

In another aspect of the invention, this bad spot verification mechanism may be used in a SOFTWARE KEY diskette. This is an option for the software publisher that allows the user to install a not usable copy of the application on more than one computer at a time. The SOFTWARE KEY program has the ability to turn the use of the application OFF on one computer and ON on another computer. The SOFTWARE KEY diskette insures that the application is usable on only one computer at a time. In another aspect of the invention, as an cption to the software publisher, an EMERGENCY USE copy of the application may be provided. This makes it unnecessary for the user to copy the diskettes prior to installation. This diskette is protected in the same manner as are the APPLICATION DISKETTE and SOFTWARE KEY DISKETTE. It also has the EMERGENCY RUN program on it that actually runs the real application. This diskette must be the original to run properly. It also has a limited number of uses that allows the user to contact the software publisher for a new copy of the application. This will allow the software publisher, who tracks the users for updates and warranties, to track excessive copies as well. Systems seldom crash and diskettes seldom become unreadable.

Other objects and features of the invention will be understood with reference to the following specification, claims, and drawings.

Brief Description of the Drawings

The flow charts and illustrations of the drawings describe the preferred embodiment of the invention. The step boxes in the flow charts are accompanied by numbers which refer to a place in the text in the detailed description of the invention that describes the step. Figures are as follows:

Figure 1 is a flow chart of the ten steps and programs that comprise the invention. Figure 2 is a flow chart of the steps used to create the APPLICATION distribution diskette.

Figure 3 is a flow chart of the program steps of the CREATE APPLICATION DISKETTE program.

Figure 4 is a flow chart of the scramble mechanism used in the CREATE APPLICATION DISKETTE program.

Figure 5 is a flow chart of the steps used by the CREATE APPLICATION DISKETTE program to scramble, hide and write the USER RECORD.

Figure 6a and 6b are a flow chart of program steps of the INSTALL program.

Figure 7 is a flow chart of the program steps used by the INSTALL, SOFTWARE KEY, and EMERGENCY USE programs that verify the bad spots on a diskette.

Figure 8 is a flow chart of lower level steps of

Figure 7. These steps randomly pick which write/read routine to use.

Figure 9 is a flow chart of the program steps used by the INSTALL, SOFTWARE KEY, and EMERGENCY USE programs to find, verify, and unscramble the USER RECORD.

Figure 10 is a flow chart of the steps to unscramble and install the application program. Figure 11 is a flow chart of the steps used to create the SOFTWARE KEY DISKETTE.

Figure 12 is a flow chart of the CREATE SOFTWARE KEY DISKETTE PROGRAM.

Figures 13a and 13b are a flow chart of the

SOFTWARE KEY PROGRAM.

Figure 14 is a flow chart of the steps used to create the EMERGENCY USE DISKETTE.

Figure 15 is a flow chart of the CREATE EMERCENCY USE DISKETTE PROGRAM.

Figures 16a and 16b are a flow chart of the EMERGENCY USE PROGRAM.

Figure 17 is an illustration of the INSTALL PROGRAM DISKETTE.

Figure 18 is an illustration of the SOFTWARE KEY

DISKETTE.

Figure 19 is an illustration of the EMERGENCY USE DISKETTE.

Figure 20 is an illustration of a process for creating bad spots on a diskette. Figures 21a and 21b are a flow chart of the INSTALL PROGRAM steps .that create the ONCE INSTALLED PROTECTION.

Figures 22a and 22b are a flow chart of the ONCE INSTALLED PROTECTION PROGRAM.

Figure 23 is a flow chart of the program steps of the INSTALL PROGRAM to perform the UNINSTALL PROCESS.

Figure 24 is a flow chart of the spawned WRITE/ READ program.

Figure 25 is a flow chart of the BUILD SYSTEM

VERIFY DATA PROCESS.

Figure 26 is a flow chart of the BUILD HARD DISK VERIFY DATA PROCESS.

Figure 27 is a flow chart of the SYSTEM VERIFY PROCESS.

Figure 28 is a flow chart of the HARD DISK VERIFY PROCESS.

Figure 29 is a flow chart of the TURN ON PROCESS used by the SOFTWARE KEY program.

Figure 30 is a flow chart of the TURN OFF

PROCESS used by the SOFTWARE KEY program. Figure 31 is a flow chart of the APPLICATION EXECUTE PROCESS.

Figure 32 is a flow chart of the DOES NOT PASS PROCEDURE used to destroy the ability to run if the application is found not to be a valid copy.

Figure 33 is a -flow chart of the REINSTALL PROCESS optionally used in the INSTALL PROGRAM.

Detailed Description

Introduction

This invention comprises procedures and the use of from 2 to 9 computer programs that provide usage protection for a software publisher's application program.

The first program, called the CREATE APPLICATION DISKETTE PROGRAM, puts a scrambled copy of the software publisher's program, hereafter called the application, a scrambled copy of the ONCE INSTALLED PROTECTION PROGRAM, and a copy of a small write/read program onto a distribution medium, hereafter called the diskette. The application program is scrambled according to the location of bad spots randomly put onto the diskette and a modulus factor that may be changed periodically to make unscrambling the application more difficult. The same process is used to copy the ONCE INSTALLED PROTECTION PROGRAM to the diskette. This program also puts a scrambled copy of a 'USER RECORD' onto the diskette in a hidden area of the diskette containing the modulus factor, optional user informati-n, and flags, such as the SOFTWARE KEY flag, which indicates if the publisher is using the SOFTWARE KEY option. This record, located on the diskette by the locations of the bad spots, must be found and unscrambled prior to unscrambling the application. This record cannot be found using the standard file system callable routines.

The next program, called the INSTALL PROGRAM, is distributed with the APPLICATION diskette and unscrambles/ installs the application program on the user's computer.

It also checks the bad spots on the APPLICATION diskette to see if they are really bad. This prevents products such as COPY II PC from being used to successfully copy the APPLICATION diskette. This program finds and unscrambles the USER RECORD. It then unscrambles the application as it installs it on the user's computer. It also unscrambles and installs the ONCE INSTALLED

PROTECTION PROGRAM. The ONCE INSTALLED PROTECTION PROGRAM is copied to the hard disk and data used in the once installed protection process is copied directly into the

ONCE INSTALLED PROTECTION PROGRAM.

This program has the ability to uninstall the application if the SOFTWARE KEY OPTION is not used. This is done by verifying that the application is valid by spawning the ONCE INSTALLED PROTECTION PROGRAM. If the application is valid, it is destroyed and data in the user data record on the diskette is changed to show the uninstall. The next program, called the SOFTWARE KEY BUILD PROGRAM, builds the SOFTWARE KEY diskette for the optional SOFTWARE KEY facility provided to .the software publisher. If the software publisher has chosen to use the SOFTWARE KEY option, the INSTALL PROGRAM installs the application with the first part of the application replaced with a small program called the NOTON PROGRAM. If the application is executed, the NOTON PROGRAM is really executed. It will display a message telling the user that the application is turned off. The SOFTWARE KEY BUILD PROGRAM scrambles and hides the USER RECORD on the SOFTWARE KEY diskette the same way the CREATE APPLICATION DISKETTE PROGRAM does on the APPLICATION diskette. It then copies the NOTON program, the SOFTWARE KEY PROGRAM, and a scrambled copy of the first 512 bytes of the application program to the diskette.

The SOFTWARE KEY diskette contains the SOFTWARE KEY PROGRAM which is used to turn ON and OFF application that has been installed on a computer. One of the major problems with most past protection mechanisms is that it is inconvenient and time consuming to move the application to another computer. If the SOFTWARE KEY FLAG is set, the INSTALL- PROGRAM allows for the installation of the application on many computers. The SOFTWARE KEY PROGRAM restricts use of the application to one computer at a time. This program verifies that a diskette is an original or verifies authorized copy by making sure that the bad spots are reaily bad. If the user is turning the application ON on this computer, it makes sure that the last thing the SOFTWARE KEY was used for was to turn the application OFF.^' If this is true, it replaces a portion of the application, such as the first 512 bytes with the real program. If the user is turning the application OFF, the first 512 bytes of the application are replaced by the NOTON program.

This program spawns the ONCE INSTALLED PROTECTION PROGRAM to verify that the application program to be turned off is valid. If it is not valid it is made not- usable.

This program also gets a random number and stores it in the USER DATA record and the ONCE INSTALLED PROTECTION PROGRAM when the application is turned ON. This can be used at a later time if the SOFTWARE KEY DISKETTE is needed to verify that the installed application program is really valid.

The next program is the CREATE EMERGENCY USE DISKETTE PROGRAM, which builds the EMERGENCY USE DISKETTE that optionally is distributed with the application package to provide emergency use of the application capabilities. Should the installed version of the application become not usable, this diskette allows the user to run the application a fixed number of times. This program and the process that goes with it puts bad spots on a diskette and formats the diskette, copies a copy of the application program file to the diskette, copies the NOTON program to the diskette, copies the scrambled first block of ^• the application program to the diskette. scrambles and writes the USER RECORD to a hidden place on the diskette, and copies the EMERGENCY USE PROGRAM to the diskette. It then replaces the first block of the EMERGENCY USE PROGRAM file with the NOTON program, making the application not usable.

Should the installed copy of the application on the user-'s computer become unusable, the EMERGENCY USE DISKETTE with the EMERGENCY USE PROGRAM can be used to run the application. This program verifies its validity using the bad spots in the same way that the INSTALL PROGRAM did. It finds, reads and unscrambles the USER RECORD which keeps track of the number of uses left for the EMERGENCY USE PROGRAM. The number of uses are limited to a fixed number defined by the software publisher. It replaces the first block of the application program file with a scrambled file containing the real beginning of the file. It runs the EMERGENCY USE application program. It then replace the first block of- the application program file with the NOTON program, making the application file not usable.

The next program is the SPAWNED WRITE/READ PROGRAM. This program is manually put on the INSTALL PROGRAM DISKETTE, the SOFTWARE KEY DISKETTE, and the EMERGENCY USE PROGRAM DISKETTE. This program is spawned by the INSTALL PROGRAM, the SOFTWARE KEY PROGRAM, and the EMERGENCY USE PROGRAM as part of the diskette verification process. These programs do write/read tests of the bad spots on the diskette. At random times during this process they will spawn this program to perform the same tests. This being a separate program makes it very difficult for an expert to intercept this function and nullify it. In addition, this program will take its own action to terminate the current program that spawned it. This makes an effort by an expert to intercept a returned value from the WRITE/READ PROGRAM of no value.

The next program is the ONCE INSTALLED PROTECTION PROGRAM, which protects the application after it is installed on the computer's hard disk. This program is spawned from the INSTALL PROGRAM, the application program, and the SOFTWARE KEY PROGRAM to verify that the installed application is the file installed by the INSTALL PROGRAM. Data used in the verify process, such as the physical cluster addresses of the application program and the ONCE INSTALLED PROTECTION PROGRAM, the random number stored in the ONCE INSTALLED PROTECTION PROGRAM and the USER DATA record on the diskette, and other file names are physically stored in a scrambled manner in places in this program file rather than stored in a separate file. This makes it very difficult for someone to find this data and try to manipulate it without destroying other data or program code.

Description of the Drawings

The procedures and programs of the invention provide a reliable copy protection mechanism for software publishers. It comprises up to 10 major steps, set forth in Figure 1. Not all steps are always used, as some are optional. Step 10 is the creation of the APPLICATION DISKETTE, a protected diskette for distribution of the application program. This diskette contains a scrambled version of the application program and a hidden scrambled copy of a USER RECORD. Step 20 is execution of the INSTALL PROGRAM which unscrambles the application and installs it on the user's computer. Step 30 creates the SOFTWARE KEY DISKETTE. Step 40 is execution of the SOFTWARE KEY program which allows the user to turn the application OFF and ON. on different computers. Step 42 creates the EMERGENCY USE DISKETTE. Step 44 is execution of the EMERGENCY USE PROGRAM. Step 46 is the execution of the ONCE INSTALLED PROTECTION PROGRAM. Step 47 is the SPAWNED WRITE/READ PROGRAM which is used by the INSTALL PROGRAM, the SOFTWARE KEY PROGRAM, and the EMERGENCY USE PROGRAM to do write/reads of diskette sectors. Having this separate program makes the testing of bad and good diskettes more secure.

CREATE APPLICATION DISKETTE

Step 10 that creates the APPLICATION DISKETTE consists of 7 lower level steps (see Figure 2). The first of the.se (step 50) is to put physical bad spots on the diskette. Such bad spots are sections of the medium, -_ in this case a magnetic diskette, that cannot be successfully written to or read from. A number of methods may be used to accomplish this result. For instance, a laser may be used to burn a small hole in or otherwise flaw the read/ write surface of the diskette. Creation of bad spots by laser is illustrated in Figure 20. Step 50 may also be accomplished mechanically by using a sharp edge to scrape the surface of the diskette. The laser method is believed preferable in a mass production environment. For reasons that become more evident later, the effects of putting bad spots on the diskettes in random locations is better than putting them in the same area on the diskette.

The next step (step 60) is to format the diskette. Most computers come with a software program to perform this function. The format function sets up the diskette sectors and tracks making it usable by the computer's file system. In addition to this the format function creates a FILE ALLOCATION TABLE (FAT) on the diskette. The FAT is used, by the computer's file system to keep track of disk sectors and how they are used. It indicates which sectors are free for use, which are in use, and which are bad . and cannot be used because the physical status of that section of the disk is damaged. This is very important in connection with the present invention because there are products on the market that will copy diskettes as they are with the FAT indicating bad spots that were on the original diskette. Protection mechanisms that would use the bad spots in the protection mechanism will still think the bad spots are valid on the copied version.

Step 62 copies the ONCE INSTALLED PROTECTION PROGRAM to the diskette.

Step 70 is to copy the application program to the diskette. This step may use the copy facility that is usually supplied with the computer. In a production environ ent this step may be omitted and the program can be copied dynamically in the scramble procedure of step 90.

Step 74 is to copy the SPAWNED WRITE/READ PROGRAM to the diskette. This program is used in the diskette verification process.

Step 80 is to . copy the NOTON program to the diskette. This program, which may be very small, is used to replace the first part of the application program if the SOFTWARE KEY option is desired by the software publisher.

The CREATE APPLICATION DISKETTE PROGRAM (step 90) is then run. This program consists of 10 lower level steps, which are shown in Figure 3 and described below.

CREATE APPLICATION DISKETTE PROGRAM

The first function of this program is to create or read an existing customer record (step 100). This record has information about the application program and the desired options of -the software publisher. This record can be created or modified when the program starts. It may contain a flag indicating that the software publisher does or does not wish to use the SOFTWARE KEY option.

Step 110 gets the diskette type information. This is followed by step 120 which reads the boot sector of the diskette. In this case, using an IBM PC environment, these two steps provide the information about the diskette. Such things as the number of tracks on the diskette, the number of sectors per track and the number of sectors per cluster are provided in these steps.

The FAT sectors are read in step 130. This tells the program which sectors are good and bad. In the embodiment shown, the first 20 bad spots are saved.

Step 140 asks for optional user information. This step is not part of the software protection aspect of the invention but is included as an additional feature for the software publisher. It contains such things as name and address information, product serial number, and the SOFTWARE KEY FLAG.

Step 142 uses a formula that uses the bad spot locations and the number of times the application has been reinstalled to produce a number. This is done for a number of reinstalls allowed by the software publisher. At this time this is just a list of these numbers as they would be generated by the reinstall process. This will allow the user to call the publisher and ask for reinstall capability should something happen to the user's installed application. This number could be given to the user over the phone, allowing the application to be reinstalled. If a user calls with such a request the publisher will record the call and be able to keep track of the reinstalls. The formula could be assigned a number and this number saved in the USER DATA RECORD. Step 150 takes a global modulus factor, file status, and use value that are in the customer record and puts them into the USER RECORD which gets scrambled and hidden on the diskette. Later, at install time, these variables must be correct in order for the installation to work properly.

The scramble and write function (step 160) uses the location of the bad spots together with the modulus factor in the USER RECORD to scramble the file. The formulas used for this scramble may vary greatly from what is described here. This function consists of a program loop that goes through the program file described below in steps 180 through 240 shown in Figure 4.

Step 180 reads 2 sector-sized blocks of the application program file. Step 190 creates a scramble variable. This is put after the reads in the loop to allow for using the block number as a variable in the scramble variable calculation, which however is not done in the embodiment described. The scramble variable is used in the scramble algorithm to make the file not usable.

Step 200 takes the scramble variable number of bits in a 16 bit word and swaps them with the remaining bits on the other side of the word. For example, the cluster number of the second bad spot on the diskette may be used as a base, which is divided by 16 and the remainder added to the modulus in the USER RECORD to get the scramble variable. If this number is greater than 16, 16 is subtracted from it.

Step 210 further scrambles the block by swapping bytes in the block according to the scramble variable. Step 220 writes the file by swapping the two blocks that are currently in memory. The program checks for the end of file at step 230. If it is not at the end of file, the routine returns to step 180. If it is at the end of the file, it continues to step 240 which returns to step 170.

There are a large number of other algorithms in addition to the one described here which would adequately perform the scramble and write file step 160.

The program proceeds to step 170 of Figure 3, which scrambles the USER RECORD and hides it on the diskette. This record is hidden by using the bad spots as the key. The record is written to a good sector on the diskette. The file system will not know it is there. This step consists of lower level steps 250 through 300 shown in Figure 5 and described below.

Step 250 creates a scramble variable just as was done in step 190 except that the modulus number in the USER RECORD is not used. This is because the INSTALL program will not be able to get this variable to unscramble itself at install time. The USER RECORD is scrambled in steps 260 and 270, such as in the same manner that the application program blocks were scrambled in Figure 4. The program finds the first 16 unused sectors on the diskette in step 280.

In step 290 the program writes junk data. This is done to confuse someone looking for the data record. The format procedure initializes the empty sectors, which means that anything that looks different may be the USER

RECORD.

Step 300 actually writes the scrambled USER

RECORD to the record corresponding to the scramble variable in the 16 good sectors. For instance, if the scramble variable is 7, the USER RECORD is written to the

7th good sector.

The program then returns to step 172 which scrambles and writes the INSTALLED PROTECTION PROGRAM to the diskette in the same manner that step 160 scrambled and wrote the application file to the diskette.

It is important to note that this record and its location is not known to the file system or operating system of the computer. Unlike other protection mechanisms using hidden files which may be located by software programs, this data cannot be found and identified by software without knowing the finding algorithm first. INSTALL PROGRAM

The INSTALL program, illustrated in Figures 6a and 6b, uses the diskette that was created by the CREATE APPLICATION DISKETTE PROGRAM and allows the user to install the application on his computer. If the SOFTWARE KEY option is being used, the user may install the application on many computers in an unusable state. It must be turned ON by the SOFTWARE KEY before it can be used.

In step 302 the install program checks to see if the user wishes to uninstall the already installed application program. If the user does wish to do an uninstall, control is passed to step 304 which is the uninstall process. This will be described later. If this is not the user's wish the program checks to see if the user wishes to do a reinstall in step 306. If this is the case the program performs step 308, which is the reinstall procedure. If this is not the case control is passed to step 310 which starts the install process. (Step 304, the UNINSTALL PROCESS (Figure 23 ) , and step 308, the REINSTALL PROCEDURE (Figure 33) are described later.)

The INSTALL program must get the disk type data and boot sector data in the same way that the CREATE APPLICATION DISKETTE PROGRAM did in steps 110 and 120, and read the FAT sectors as was done in step 130. It does this in steps 310 through 330. It then goes through the FAT to identify the bad spots (step 340). Step 322 may appear out of place, but has an important value. Steps 322 and 324 are used to protect against a user copying the installed software in a

--' sp^'ecific manner. Once the application is installed, a user could copy the application program file and the spawned ONCE INSTALLED PROTECTION PROGRAM file on a sector by sector basis, keeping track of each sector and its physical sector address. The user could then run the

SOFTWARE KEY PROGRAM to^' turn the application OFF. The user could copy the sectors back to the disk, which leaves it in an ON condition. The user could then use the SOFTWARE KEY DISKETTE to turn the application ON on another computer, leaving 2 running copies. To prevent this, the TURN OFF function of the SOFTWARE KEY PROGRAM changes the name of the ONCE INSTALLED PROTECTION PROGRAM and truncates it. The new name of the new file is stored in the USER DATA RECORD on all of the diskettes, but is one of many, making the predictability difficult. This process also exists if the SOFTWARE KEY OPTION is not used. The uninstall, install process will produce the same results for the user. Checking to see if this file exists in step 322 and writing to it in step 324 means that, if a user writes the files back to the disk sector by sector, the ONCE INSTALLED PROTECTION PROGRAM file will not be in the file directory and the user may have destroyed his file directory structure by writing over a smaller file. The process that creates this smaller truncated file also writes many small files to the disk to increase the probability of destroying the directory structure of the file system. It should be noted that this process performs no actions outside of those normally allowed by the computer's file system. It would be the user's illegal action that is destructive.

In step 350 the program verifies the bad spots. It translates the bad spot cluster number that is stored in the FAT table into Head, Track, and Sector values. These values are used to do a physical write and read of these sectors. This is done without going through the file system which is usually used to read and write to the diskette. If the writes or the reads are not successful, the diskette has a very high probability of being an original application distribution diskette and not a copy. Some of the sectors will return successfully from the writes and reads, but if they are all good, the diskette is a copy. There are computer experts capable, with a lot of time and work, of using DEBUG mechanisms to find places in programs where input/output functions are going on. They may examine what is happening here and change the program to branch around this write/read code, return the expected return code and continue. In this case, however, the program gets a random number and either performs the write/read routine on a known good sector or a bad sector. The returns from a good sector must always be good. If they are not the program is terminated. The return from the bad sector write/reads can be good or bad, but some must be bad. This makes it very difficult for a person to determine what is expected by the program. To further make it difficult for a computer expert to avoid the copy protection, the program gets another random number. It uses this number to determine which of several, duplicate write/read routines that are distributed throughout the program is used. This means that after an expert spends time finding the location of the code he .wants to monitor, he cannot predict if or when it will be used again, or for what reason (good sector test or bad sector test) it will be used again.

One additional scheme adding to the problems of the expert out to break the protection is that at random times throughout the write/read test process the install process will spawn a separate program to do the write/read test. (See Figure 8). Step 470 gets a random number. Step 472 reduces this random number to a number used to make a determination. Step 474 makes the determination of which write/read routine to use in the program, or to spawn a separate write/read program.

The SPAWNED WRITE/READ PROGRAM is shown in

Figure 24. Step 1710 does the write/read of the sector passed as an argument. This program can look at the FAT and determine if a good write/read or bad write/read is expected. If the write/read results are as expected step 1730 returns a good value. If they are not, step 1740 erases the application program. Then step 1750 returns a bad value. This makes it very difficult for the expert because most debuggers will not work on two programs at the same time. This SPAWNED WRITE/READ PROGRAM can also take action,on its own if the results from the write/reads are not what was expected. This means that the expert's actions to intercept the returns from the spawned program will not allow the expert to bypass the application's protection. Step 360 tests the return from the routine that verifies the bad spots. If the return indicates that all of the bad spots are not really bad, the program stops and will not continue with the installation. The verify bad spots step consists of lower level steps 420 through 466 shown in Figure 7.

Steps 420 through 466 perform the actual tests of the bad sectors to insure that some of the bad sectors are really bad. While this is happening some write/reads of good sectors be done to confuse any attempt to fool the program by using a DEBUG mechanism to return an expected return code from the write/read routines. There are several of these routines to make it more difficult for someone trying to break the protection.

Step 420 gets a random number. This can be done with a random number generation routine or simply by getting the current system time if it includes a millisecond value. If the value is even, a write/read test will be performed on a good sector rather than a bad one. If this mechanism is intercepted by a DEBUG mechanism, and a bad return is injected into the process by using the DEBUGGER, the program will terminate. Step 430 passes control to_. step 460 which picks a write/read routine or spawns the WRITE/READ PROGRAM to execute for the good sector. There are several of these write/read sector routines in the program in different places to make it difficult for anyone to predict which routine will be used. Step 460 is comprised of lower level steps 470 through 480 shown in Figure 8. Step 470 gets another random number. Step 472 divides this number by the number of write/read routines in- the program + 1. If the remainder is 0, step 474 passes control to step 476, which spawns the WRITE/READ PROGRAM. The remainder is used in step 480 to pick the write/read routine to use.

Step 462 actually calls the picked write/read routine to test the good sector. Step 464 tests to see if the return was a good write/read. If it was, control is passed back to step 420 to continue and try again, else step 466 returns an "invalid diskette" code and the program will terminate.

If the number generated in step 420 was odd, control passes to step 432 which performs the pick write/ read sector routine (steps 470 through 480). Step 434 calls the write/read of the possibly bad sector. Step 436 tests the return to see if .the sector was bad. If it was bad, step 438 adds 1 to a bad flag variable. Steps 436, if the return was good, and step 438 both go to step 440 to check if it has gone through enough bad spots (e.g. 20 in the routine shown). If enough bad spots have not been tested, 1 is added to the number of tries in step 450 and the routine goes back to step 420 to get a new random number. If enough bad spots have been tested, a check is performed in step 442 to see if any of the bad sectors were really bad. If the answer is yes, a "valid diskette" value is returned in step 444, else an "invalid diskette" value is returned in step 446. If the bad spots indicated in the FAT are all good, the program stops the installation in step 370. If some of the bad spots are really bad the program continues to step 380, which finds and unscrambles the USER RECORD. Step 380 has lower level steps 490 through 530 shown in Figure 9.

The unscramble formulas must be the reverse of the scramble formulas used in the CREATE APPLICATION program. If they are not, the application file will not be usable after the install. In addition, the location of the bad spots on the installation diskette must be in the same places as they were during the CREATE APPLICATION program. Also, the bad spots indicated in the FAT must contain some sectors that are really bad. In addition, the USER RECORD must unscramble to a valid record. In addition, the modulus factor in the USER RECORD must be the same as the USER RECORD modulus factor when the CREATE APPLICATION program was run. If any of these are not as they should be, the unscramble will not work or will not work properly.

Step 490 of the unscramble USER RECORD procedure gets a scramble variable value based on the location of the bad spots. This step is the same as step 250 in the CREATE APPLICATION program. Step 500 is the same as step 280 in the CREATE APPLICATION program and finds the first 20 good unused sectors on the diskette. Step 510 reads the good sector corresponding to the scramble variable. Step 520 unscrambles each 16 bit word in the reverse manner that step 260 scrambled each 16 bit word did in the CREATE APPLICATION program. Step 520 reverses the effects of step 270. At this point the USER RECORD is in memory and the modulus factor may be accessed.

Step 390 (Figure 62) checks to see if the USER RECORD is valid by checking the modulus for a valid value between 3 and 14. It can also be checked by using a check digited serial number if the software publisher desires an additional level of validation. Other validity checks may also be used. If the USER RECORD is not valid, the installation is stopped at step 400. If the USER RECORD is valid the program proceeds to step 410. Step 410 unscrambles and installs the application program file on the user's computer. Steps 540 through 630 shown in Figure 10 are lower level steps of step 410.

Step 540 asks the user what the name of the program to install is and the path to install it to on the user's computer. In a production mode the first question would not be asked as it would be built into the INSTALL program.

Steps 550 through 600 are built to unscramble the scrambling done in steps 180 through 230 of the CREATE APPLICATION program (see Figure 10). Step 550 reads two, 512 byte blocks of the application program file. Step 560 creates the scramble variable from the location of the bad spots and the USER RECORD modulus factor. Step 570 reverses the scramble number of bits in each word in the opposite manner than was done in step 200 of the CREATE APPLICATION program. Step 580 unscrambles the words within the block in the reverse manner of step 210 of the

CREATE APPLICATION program. Step 590 writes the blocks, reversing the order of the two blocks it is working on, to the file of the path the user specified in step 540. The program checks for end of file in step 600. If end of file has not been reached, the program returns to step 550.

When end of the file has been reached, the program then checks the USER RECORD to see if the SOFTWARE KEY option is on for this software publisher's program. If it is not, the program returns to step 410. If the use of the SOFTWARE KEY option is on, the program replaces the first 512 bytes of the installed program file with the NOTON program. This renders the program not usable and requires the use of the SOFTWARE KEY to turn it ON.

After the application file has been installed, the INSTALL program performs the set up procedure, step 412, for the ONCE INSTALLED SOFTWARE PROTECTION. This consists of a spawned ONCE INSTALLED PROTECTION PROGRAM that will be used to ensure that the installed application program file is the one originally installed and not a copy. This program is written with some memory constants set to specific values allowing the INSTALL program to find them and change them. . These constants will be replaced with system values that identify the hard disk and the installed application program file as those originally installed. This is done in step 412 which consists of lower level steps 1280 through step 1400 as shown in Figures 21a and 21b. Step 1280 unscrambles and copies the ONCE INSTALLED.PROTECTION PROGRAM to the installation disk from the diskette. Step 1290 looks for the first constant -of a predetermined pattern in the file. The constants are set at program compile time. The constant is replaced with the ASCII character value of the physical cluster address of the beginning of the application file in step 1300. Step 1310 finds the next constant. Step 1320 replaces this with the ASCII character value of the first cluster address of the ONCE INSTALLED PROTECTION PROGRAM file. This ensures that the program files are valid at execution time because when the once installed protection check is done these values must be equal to the current actual cluster addresses. Functions in the UNINSTALL process and SOFTWARE KEY process (changing the name of the ONCE INSTALLED PROTECTION PROGRAM file and shortening it) make it nearly impossible to copy these files off and replace them. Steps 1330 through 1350 loop, putting the names of dummy files into the ONCE INSTALLED PROTECTION PROGRAM. One of these files will late.r have needed data in it. These files also will create problems for someone trying to copy off the application file and ONCE INSTALLED PROTECTIO PROGRAM file and replace them after uninstalling or turning the application OFF. Step 1360 creates and writes these files. Step 1370 does the BUILD SYSTEM VERIFY DATA process. Most computers will tell you the version of the operating system now in use. This can be used as one step in system verification. If the application is moved to a computer with a different version of the operating system, this check will return a bad value. There are 3 lower level steps to step 1370. They .are shown in Figure 25. Step 1760 gets the operating system version. Step 1770 gets the -hardware configuration. This may be in the form of a set of words stored in the operating system or may be gathered by looking for registered peripherals. Step 1780 stores this information in the USER DATA RECORD structure in memory.

Figure 26 shows the 7 lower level steps that make up step 1380. The function of this set of steps is to record a set of traits of the hard disk that may be tested at a later time to determine that this hard disk is the one that the application was installed on. This step collects data used to identify the hard disk that the application is installed on. If the application is copied to a disk on another computer, it will not pass this test and will not run. Step 1790 gets the location of a predetermined number of bad spots or as many as may exist up to this number. Step 1800 reads each bad spot a number of times. Many hard disks are supplied by the manufacturer with a list of bad spots. The file system of almost all computers will never have reason to write to these locations. A trait of magnetic disks is that a sector that is marginal may read bad some times and good at other times. The manufacturer usually tests these spots to a finer margin than can the disk drive itself. When the disk is formatted, the format function will write a recognizable pattern to the disk sectors. By reading the bad spot a number of times, the amount of the sector that is currently not stable may be determined. Sectors with small bad spots may often be able to be written to and often successfully. In their current state, these bad spots will not read properly because they were left with a bad block check character. A block check character is a piece of data that is calculated from data in the data block written to the sector. This block check character, often called the CCR, does not agree with the data in the sector for these sectors. By determining if the bad section of this sector is small, we can guess that there is a good probability that if this sector is written to, it will write and read correctly. (Tests have verified that this happens much of the time). If in the future this sector is read, and the read is good (the data agrees with the CCR), it means that this sector has been written to indicating that an individual sector by sector copy of the disk has taken place. If the bad section of the bad sector is small, control is passed to step 1830, which marks the sector as a "maybe good" bad spot in a data structure. If the bad section of the sector is large, the sector is marked as a "should be bad" bad spot in the data structure. Both steps 1830 and 1820 pass to step 1840 which saves the bit patent of a section of bits close to the good sector pattern. This may later be tested to determine the possibility that this sector was written to. Step 1850- stores this data as a data structure. Control is then passed to step 1390 which scrambles this data. Step 1400 then writes it to a dummy file.

It can also be of value to put real data into the good section of some of these sectors. This will serve to require that a sector by sector copy be required to read/write the bad spots as well as the good sectors. CREATE SOFTWARE KEY DISKETTE

This program, shown in Figures 11 and 12, creates a diskette called the SOFTWARE KEY DISKETTE. It is used to turn the application that may be installed on many computers, ON and OFF while insuring that it will be

ON on no more than one computer at a time.

Step 640 consists of making physical bad spots on the diskette in the same manner done in step 50 for the CREATE APPLICATION DISKETTE procedure. This diskette is then formatted (step 650) as in step 60. Step 660 copies the SOFTWARE KEY program to this diskette. Step 664 copies the SPAWNED WRITE/READ PROGRAM to this diskette. Step 670 runs the CREATE SOFTWARE KEY PROGRAM. This step consists of lower level steps 680 through 750 shown in Figure 12.

CREATE SOFTWARE KEY DISKETTE PROGRAM

This program copies the NOTON program and the first 512 bytes of the application program (file FSTBLK.ABC) to the SOFTWARE KEY DISKETTE. Step 680 reads the customer record. Step 690 gets the disk type data. Step 700 reads the boot sector. Step 710 reads the FAT sectors a d gets the first 20 bad spots. Step 720 puts the modulus factor and file status into the user record in memory. This data is copied from the customer record. Step 730 copies the NOTON program file to this diskette. Step 740 copies the first block of the application program to the diskette. It is put in a file called FSTBLK.ABC, in the present example. Step 750 scrambles and writes the rtSER RECORD to a hidden location on the diskette and may use the method shown in Figure 5.

Many of the above step function descriptions are the same as steps in the CREATE APPLICATION DISKETTE functions.

SOFTWARE KEY PROGRAM

This program, shown in Figure 13a and 13b, is on the SOFTWARE KEY DISKETTE and is used to turn the installed application ON.or OFF on a computer.

Turning the application OFF involves replacing the first 512 byte block of the application program with a small program that tells the user that the application is turned OFF. The program also updates the hidden USER RECORD on this diskette setting the status to a value indicating that the last thing it did was turn the application OFF. The status must be that the last action was to turn the application OFF before it can turn the application ON on any computer. Turning the application ON involves reading and unscrambling the file FSTBLK.ABC, which is the first 512 bytes of the application program. If the status is correct, the SOFTWARE KEY PROGRAM replaces the NOTON program in the first 512 bytes of the application program file with the real first 512 bytes of the application program file. Turning the application on also gets a random number that is stored in the ONCE INSTALLED PROTECTION PROGRAM and the USER DATA record which is used for validity tests in other places. This program also spawns the ONCE INSTALLED PROTECTION PROGRAM to verify that the installed application program is valid and not a copy. It also performs functions that will create problems for the user if other illegal copy schemes are tried. The SOFTWARE KEY PROGRAM description follows.

Step 760 gets disk type information, as was done in step 110 of the CREATE APPLICATION DISKETTE program. Step 770 reads disk set up information as was done in step 120. Step 780 reads the FAT sectors and step 790 identifies the first 20 bad spots and the first 20 good spots.

Step 800 verifies the bad spots as was done in step 350 of the INSTALL program and may use the method shown in Figure 7. Step 810 passes control to step 820 if the bad spots are not really bad. Step 820 stops the program and does not change.the status of the application. If some of the bad spots are really bad, control goes to step 830. Step 830 gets and unscrambles the USER RECORD in the same manner that the INSTALL program did in step 380. At this point step 840 (Figure 13b) checks the validity of the USER RECORD. The modulus value must be between 3 and 14 and the status code must be 23332 or 32223. If this test is not passed step 850 stops the program and leaves the status of the application on this computer unchanged.

If the test is passed, the program proceeds to step 852 which spawns the ONCE INSTALLED PROTECTION PROGRAM. This step consists of the lower level steps 1410 through 1620 shown in Figures 22a and 22b.

This spawned program tests data that was stored in it during the install process with data retrieved from the computer's file system. Step 1420 gets the physical disk location of the ONCE INSTALLED PROTECTION PROGRAM. Step 1430 checks to see that this location is equal to the value stored in the ONCE INSTALLED PROTECTION PROGRAM. If they are not, control is passed to step 1490 which can erase the application program file and will return a bad value to the SOFTWARE KEY PROGRAM which will not continue. If the test is good, step 1440 will get the actual disk cluster of the application program file. This must match with the data stored in the ONCE INSTALLED PROTECTION PROGRAM or step 1450 passes control to step 1490, terminating the process. The disk location is used as a validity test because only one file can have this disk address, thus a copy of the application program file cannot be turned off. If this test is passed, step 1450 passes control to step 1460, which will get the first X bad spots on the hard disk. Almost all hard disks have bad spots. The bad spots provide a way of uniquely identifying the installed hard disk. Thus, copying the installed application program file to another hard disk will make the SOFTWARE KEY PROGRAM not function. Step

1470 makes sure that the bad spots put into the ONCE INSTALLED PROTECTION PROGRAM at installation time are on the current hard disk. If they are not, control is passed to step 1490 to erase the application and return a bad value. If they are, control continues to step 1500 which checks fror the dummy file that should have the built system verification data and hard disk verification data in a scrambled form. Step 1510 reads the dummy file and unscrambles the data. Step 1520 does the SYSTEM VERIFY procedure. This step has 5 lower level steps shown in Figure 27.

Step 1860 gets the current operating system version. Step 1870 checks this against the version that was stored in the dummy record. If they are not equal, a "not valid" value is returned. If they are equal, control is passed to step 1880 which checks the hardware list with the list stored in the dummy record. If they are not equal, a "not valid" value is returned; otherwise step 1890 returns a "good value".

If the returned value is good, step 1540 does the Hard Disk Verify procedure. This procedure is made up of lower level steps 1910 through 2060 shown in Figure 28.

The dummy file which contains a data structure with bad spot data has been read. Step 1910 goes through this structure to see if there are any bad spots with small bad sections. If any "maybe good" bad spots exist, they are read in step 1930. If they read as "good" it means that they were never bad and we are not on the original install hard disk or that someone has written to them, which means that someone has tried to break the protection. In either case a "no good" value is returned. This "no good" value will require that the original INSTALL DISKETTE or SOFTWARE KEY DISKETTE be used to verify the installed application program. If the "maybe good" bad spots read as "bad", control passes to step 1920, which checks the bad spot data structure for "should be bad" bad spots. If there are none of these, control passes to step 1930 which, returns a "good value". If there are some "should be bad" bad spots. Step 1960 starts a loop to verify these bad spots. The reason for this set of steps is to ensure that someone does not copy the entire hard disk, sector by sector, turn the application OFF or uninstall it so that it can be TURNED ON or reinstalled on another computer, and restore the hard disk sector by sector. When data is written to disk bad sectors, data around the bad part of the sector changes to a noticeable degree. That is, it is possible to detect when data is written to a bad sector, even if it is the same data that was read from the sector.

Step 1960 reads the bad spot. Step 1970 does a bit pattern test. This tests the bits closest to the good part of the bad sector. This is determined by picking bits close to the correct pattern written by formatting program. If the difference between these bits and those stored in the data structure is small, the test is passed and control is passed to step 2020 which gets the next bad spot and continues the loop. If the test is not passed, control goes to step 1980, which determines if the bit pattern is close and most likely good. (Bad spots do get worse with time. This step notes the slow change in a bad spot.) If the test is questionable, not passing the test in step 1970, but not bad enough to go to step 2000, control is passed to step 1990. This step takes the current bit pattern of the special section of the sector and writes it into the bad spot data structure. There is then a new test bit pattern for this sector. If the test in step 1980 does not pass as questionable, control passes to step 2000 which will verify that the sector is really bad and most likely has been written to. If the sector tests as "no good", 1 is added to bad totals in step 2010. If this is not the case, control is passed to step 2020 to continue the loop. When the loop is an end as determined by step 2030, control passes to step 2040. This step calculates the percentage of sectors determined to have been altered versus those that have passed the tests in steps 1970, 1980, and 2000 as not altered. This percentage is not tested against 0. It is possible, but not expected, that the expectations be tested within predetermined bounds. They may not exactly match the expectations because bad spots will not always act in a predicted manner. If the "bad totals" are not within bounds, step 2050 returns a "no good" value. If the "bad totals" are within bounds, step 2060 returns a "good" value.

Control is returned to step 1550. If the return value is "good", control is passed to step 1560, which returns a "good" value to step 854. If the test is not passed, control passes to step 1570. The next set of steps is performed if the system verify test or hard disk verify test are not passed. The system test and hard disk test may fail on very rare occasions even though the user has not tried to steal the application software. If is possible for the system verify test to fail if the user installs a new operating system or adds new hardware to the computer. The hard disk verify may fail if the bad spots take an unexpected turn for the worse. (Bad spots do grow, but the system will, in most cases, keep track of and adjust to the changes of the bad spots.) Step 1570 checks to see if the SOFTWARE KEY option is on. If it is, control is passed to step 1580, which requests the SOFTWARE KEY DISKETTE. If not, step 1590 requests the INSTALL DISKETTE. Both of these steps lead to step 1600, which does an absolute verify that the installed software application is the valid current version or the original program. This is done by comparing the stored random number stored, in the USER DATA RECORD on the diskette and in the ONCE INSTALLED PROTECTION PROGRAM during the CREATE ONCE INSTALLED PROTECTION procedure. If this test is passed, step 1610 re-creates the ONCE INSTALLED PROTECTION mechanism. If the test is not passed, step 1620 performs the "DOES NOT PASS" procedure, which makes the application not usable.

Requiring the use of the SOFTWARE KEY DISKETTE or the INSTALL DISKETTE for absolute verification of this copy of the application ensures that the failure of the system verification or hard disk verification will not kill the application when they should not. This, however, should seldom happen.

Control returns to step 854. If a "no good" value is returned, control passes to step 850, which stops the program. If the return is "good" control passes to step 860. If the test is passed, step 854 proceeds to step 860 which asks the user if he wishes to turn the application ON or OFF. Step 870 checks the user's intent. If the user wants to turn the application ON step 880 checks to see if the status in the USER RECORD, indicates us that the last action taken by the SOFTWARE KEY program was to turn the application OFF. If not, control is passed to step 860. If yes, control passes to step 890 which checks to see if the program is already on. This should not be possible. The check consists of searching the first 512 bytes of the application program file for the string value, "THE PROGRAM IS TURNED OFF". If this is found the NOTON program is the first block of the application file, indicating us that the program is turned OFF. Control is passed to step 900 which performs the TURN ON procedure. This step is made up of the 9 lower level steps from 2070 to 2150 shown in Figure 29. Step 2070 checks to see the ON flag in the USER DATA record is on. If it is not, control passes to step 2100 and the process can continue. If it is ON, control passes to step 2090, which checks to see if the random number stored in the USER DATA record is equal to the number stored in the ONCE INSTALLED PROTECTION PROGRAM. This number was created and stored during the last TURN ON process. If the ON flag is set and the numbers match, this program is already ON and valid. An error message is produced in step 2092 and step 2094 returns to step 860. If the ON flag is set and the numbers dc not natch, this appliction is on and not valid. In this case control passes to step 2080 which performs the DOES NOT PASS procedure. This procedure makes this copy of the application not usable. The DOES NOT PASS procedure is shown insteps 2310 through 2360. Step 2310 changes the name of the ONCE INSTALLED PROTECTION PROGRAM. Step 2320 makes this file shorter than it is. Step 2330 writes to this new file. The reason for these steps is to leave the file system in a questionable state if a special program tries to copy the program files off of the disk in a sector mode and later replace them in the same place. If this is done, the file system will not find the ONCE INSTALLED PROGRAM in the same place. Other checking functions will check for this file and write to it, destroying the overlayed copy of the ONCE INSTALLED PROTECTION PROGRAM. Step 2340 deletes any dummy files that may exist. Step 2350 creates new dummy files while step 2360 writes to them in volumes greater than 1 cluster. These steps raise the possibility that files will be written in places where the old ONCE INSTALLED PROTECTION PROGRAM was. If these file areas are overwritten by a program restoring the ONCE INSTALLED PROTECTION PROGRAM, the application program will not run. The ONCE INSTALLED PROGRAM must be complete, in the same place as before, accessible by the file system. The dummy files must exist also for the application to run as the ONCE INSTALLED PROTECTION PROGRAM will look for them.

Step 2100 writes over the file that replaced the ONCE INSTALLED PROTECTION PROGRAM. This will make a not valid copy of the ONCE INSTALLED PROTECTION PROGRAM not usable. Step 2110 writes over the dummy files and deletes them. This also can create problems if a user has done abnormal things to the disk in an effort to copy the application program. Step 2120 does the BUILD SYSTEM VERIFY. Step 2130 does the BUILD HARD DISK VERIFY. These functions must be done because the previous step destroyed this data in the dummy files. Step 2140 copies the first block of the application back to the first block of the application program file. Step 2150 performs the ONCE INSTALLED PROTECTION process.

If the user wants to turn the application OFF in step 870, control goes .to step 910 which checks the current status to make sure the last action taken by this program was to turn the application ON. If this is not the case, an error message is returned to the user and control is passed to step 860. If this is the case, control is passed to step 920 to see if the application program file on this computer is already OFF. If it is an error message is returned to the user and control is passed to step 860. If it is not, control passes to step 930 which performs the TURN OFF procedure shown in Figure 30. This step consists of 12 lower level steps that turn the application OFF if all validity checks are passed.

Step 2160 checks the on/off flag in the USER

DATA record. If it is OFF, control is passed to step 2162 which gives the user an error message telling him that the application is already off. Step 2164 then passes control back to step 860. If the flag was ON, step 2180 checks the random number that was stored in the USER DATA record and the ONCE INSTALLED PROTECTION PROGRAM. If these numbers are not the same, there is a problem that should not exist unless someone has tried to put together a not valid copy of the application. In this case control passes to step 2170 which performs the DOES NOT PASS procedure. This makes this copy of the application not usable. This was described earlier. If the numbers are equal control passes to step 2190 which changes the name of the ONCE INSTALLED PROTECTION PROGRAM. Step 2200 then shortens the file. As described earlier, this step prevents someone from copying the application and ONCE INSTALLED PROTECTION PROGRAM on a sector by sector basis and copying the files back after the turn OFF function. Step 2210 does a SYSTEM VERIFY while step 2220 does a HARD DISK VERIFY. If either of these steps are not passed, the DOES NOT PASS function is performed in step 2240 making the application unusable.. If they are both passed, the NOTON program is copied to the first block of the application program file, making the application program unusable. After the successful execution of steps 900 or 930, control passes to step 940 which updates the USER RECORD. Step 950 scrambles, writes and hides the USER RECORD on the diskette. Step 960 terminates the program.

CREATE EMERGENCY USE DISKETTE

This program, shown in Figures 14 and 15, creates a diskette called the EMERGENCY USE DISKETTE. It is used to run the application in the event that the installed copy of the application cannot be run. The number of times that the EMERGENCY USE copy of the application can be run is limited.

Step 970 consists of making physical bad spots on the diskette in the same manner done in step 50 for the CREATE APPLICATION DISKETTE procedure. This diskette is then formatted (step 980) as in step 60. Step 990 copies the.APPLICATION PROGRAM to this diskette. Step 994 copies the SPAWNED WRITE/READ PROGRAM to the diskette. Step 1000 runs the CREATE EMERGENCY USE DISKETTE PROGRAM. This step consists of lower level steps 1010 through 1090 shown in Figure 15.

CREATE EMERGENCY USE DISKETTE PROGRAM

This program copies the APPLICATION PROGRAM, in a TURNED OFF mode, the NOTON program, and the first 512 bytes of the application program (FSTBLK.ABC) to the EMERGENCY USE DISKETTE.

Step 1010 reads the customer record. Step 1020 gets the disk type data. Step 1030 reads the boot sector. Step 1040 reads the FAT sectors and gets the first 20 bad spots. Step 1050 puts the modulus factor, file status, and uses value, which is the number of times the application on the EMERGENCY USE DISKETTE will run, into the user record in memory. This data is copied from the customer record. Step 1060 copies the APPLICATION PROGRAM file to this diskette. Step 1070 copies the NOTON PROGRAM and the first block of the application program to the diskette. It is put in a file called FSTBLK.ABC. Step 1080 replaces the first 512 bytes of the application program with the NOTON program. Step 1090 scrambles and writes the USER RECORD to a hidden location on the diskette. Many of the above step function descriptions are the same as steps in the CREATE APPLICATION DISKETTE functions.

EMERGENCY USE PROGRAM

This program, shown in Figures 16a and 16b, is on the EMERGENCY USE DISKETTE and is used run the application in emergency situations. It verifies that this diskette is an original and not a copy. It then executes the APPLICATION PROGRAM, lowers the number of USES left by one, and terminates.

Step 1100 gets disk type information, as was done in step 110 of the CREATE APPLICATION DISKETTE program. Step 1110 reads disk set up information as was done in step 120. Step 1120 reads the FAT sectors and step 1130 identifies the first 20 bad spots.

Step 1140 verifies the bad spots as was done in step 350 of the INSTALL program. Step 1150 passes control to step 1160 if the bad spots are not really bad. Step 1160 stops the program and does not change the status of the application. If some of the bad spots are really bad, control goes to step 1170. Step 1170 gets and unscrambles the USER RECORD in the same manner that the INSTALL program did in step 380. At this point step 1180 (Figure 16b) checks the validity of the USER RECORD. The modulus value must be between 3 and 14 and the status code must be 23332 or 32223. If this test is not passed step 1190 stops the program and leaves the status of the application on this computer unchanged.

If the test is passed, the program proceeds to step 1200 which checks to see if there are uses left. If there are no uses left, control passes to step 1210 which stops the program. If there are uses left, control is passed to step 1220 which reads the FSTBLK.ABC file. This is the first 512 bytes of the application program file. Step 1220 unscrambles this data. Step 1230 replaces the first block of the application program file on the diskette to provide a runable copy of the application program file. Step 1240 runs the application as a child process.

When the application completes, control is returned to the EMERGENCY USE program along with a return code indicating is the run was successful. Step 1250 subtracts 1 from the USES^' value in the USER RECORD. The USER RECORD is then scrambled and hidden on the diskette in step 1260.

Step 1270 replaces the first 512 bytes of the

EMERGENCY USE APPLICATION PROGRAM file with the NOTON program making it not usable without going through the EMERGENCY USE PROGRAM

Figure 23 shows the flow of the UNINSTALL PROCESS. This process is needed for publishers who choose not to use the SOFTWARE KEY option. It allows the user to move the application software from one computer to another. Step 1630 spawns the ONCE INSTALLED PROTECTION PROGRAM, which performs all of the validity checks described earlier. If the installed application is not valid, control passes to step 1650, which performs the DOES NOT PASS procedure, making the application not usable. If the application is valid, step 1660 deletes the application program. Step 1670 then performs the DOES NOT PASS procedure making the application not usable on this computer. Step 1680 marks the application as uninstalled in the USER DATA record. Step 1690 unscrambles the first block of the application program on the INSTALL DISKETTE. This is done because the block was rescrambled, scrambled twice, during the install process. Step 1700 scrambles and writes the USER DATA RECORD to the diskette. The INSTALL DISKETTE is now ready to be reinstalled.

Figure 33 shows a flow of the REINSTALL PROCEDURE. This process provides an option for publishers to be able to allow users to reinstall the application should the current installed application program get destroyed. The USER DATA record will have a field for the number of reinstalls done and a number representing a specific formula. The procedure starts by having the user mount the INSTALL DISKETTE in the floppy drive in step 2370. Step 2380 gets and unscrambles the USER DATA record. Step 2390 calculates a number from the number of reinstalls already done. This ensures that the user cannot reinstall the application on several computers because the calculated number will change in an unpredictable fashion depending on the number of the reinstall and the location of the bad spots on the diskette. These numbers have been recorded by the publisher when the INSTALL DISKETTE was created. The user had to call the publisher to get this magic number. The REINSTALL PROCEDURE asks the user to enter this number in step 2400. Step 2410 checks to see if the entered number is the expected number. If it is not, the reinstall stops. If the numbers are equal, 1 gets added to the number of times the reinstall has been used in step 2430. If another reinstall is needed in the future, the number used in this one will not work in the next one. Step 2440 scrambles and writes the USER DATA record to the diskette. The reinstall then continues.

Figure 31 shows the flow of the installed application program to start the ONCE INSTALLED PROTECTION

PROCESS. The application spawns the ONCE INSTALLED

PROTECTION PROGRAM. This program then tests to see if it is on the hard disk. This combined with other steps taken during the ONCE INSTALLED PROTECTION PROGRAM ensures that the correct versions of the programs are being used. If the ONCE INSTALLED PROTECTION PROGRAM determines that these are not as they should be, the installed application will become not usable. In addition, a "bad" value will be returned to the application program and it will terminate itself. If the return value is "good", the application will continue.

Figures 17, 18, and 19 illustrate the contents of diskettes which may be produced in accordance with the invention. Figure 17 shows an INSTALL PROGRAM DISKETTE which contains physical bad spots, hidden user ID information, the SPAWNED WRITE/READ program, the ONCE INSTALLED PROTECTION program, a scrambled application file program, and the INSTALL program. The INSTALL program verifies the diskette as valid by writing to and reading from bad spots, finds and unscrambles the used information, unscrambles the application program file, and installs the application in a usable form on a user's hard disk or diskette.

Figure 18 shows a SOFTWARE KEY DISKETTE which contains physical bad spots, hidden user ID information, the SOFTWARE KEY PROGRAM, the SPAWNED WRITE/READ PROGRAM, and the files NOTON.COM and FSTBLK.ABC. This diskette is used to turn an installed application on or off. The SOFTWARE KEY PROGRAM verifies the diskette as valid by writing to and reading from bad spots, finds and unscrambles the user information, copies the N0T0N.COM file over the first block of the installed application to turn it off, and unscrambles and copies the FSTBLK.ABC file over the first block of the installed application to turn it on.

Figure 19 shows an EMERGENCY USE DISKETTE which may be used to run an application if the installed copy of the application is not usable. The diskette contains physical bad spots, hidden user ID information, a copy of the application in a turned off mode, the EMERGENCY USE program, the SPAWNED WRITE/READ program, and the N0T0N.COM and FSTBLK.ABC files. The EMERGENCY USE program verifies the diskette as valid by writing to and reading from bad spots, finds and unscrambles the user information, unscrambles and copies the FSTBLK.ABC file over the first block of emergency use program to make it usable, runs the emergency use application program, and copies the NOTON.COM file over the first block of the EMERGENCY USE PROGRAM to make it not usable.

FILES AND PROGRAMS

Files and programs as listed in the appendix and described above are as follows.

EXAMINE.EXE - is a program file used as the application program for this invention. Functionally the program dumps disk files to the screen.

FSTBLK.ABC - is a scrambled copy of the real first 512 bytes of the application program.

MKAPPDSK.EXE - is the program file for the CREATE APPLICATION DISKETTE program. This program creates the diskette that is distributed to the user

MKEMRAPP.EXE - is the EMERGENCY USE program that runs a copy of the application program a limited number of times. The application program run will not run without the EMERGENCY USE program running it.

MKEMRGCY.EXE - is the program file for the CREATE EMERGENCY USE DISKETTE program. It creates a diskette allowing the user to run the application if something destroys the installed application.

MKINSTAL.EXE - is the program file for the INSTALL program. This program is distributed on or with the APPLICATION DISKETTE and is used to install the application on the user's computer's storage media. MKONCE.EXE - is the program file of the program spawned by the INSTALL and SOFTWARE KEY programs to ensure that the installed application program file is the original and not a copy.

MKONOFF.EXE - is the program file for the SOFTWARE KEY program. This program file is on the SOFTWARE KEY diskette and turns an application ON or OFF after it is installed on a computer.

MKSFTKEY.EXE - is the program file for the CREATE SOFTWARE KEY DISKETTE program. ^• This program creates the SOFTWARE KEY diskette that is used to turn installed application programs OFF on one computer and ON on another.

NOTON.COM - is the program file for the NOT ON program. This is a small program that is used to replace the first part of the application program when the application is turned OFF. This program tells the user that the application is not usable and then terminates.

WRITREAD.EXE - is the program file for the WRITE/READ program. This program is spawned by the INSTALL, SOFTWARE KEY, and EMERGENCY USE programs.

CUSTOMER RECORD

The following is the record layout of the customer record as it may be used in this invention. It is expressed in the -C* language. In a production environment there would be one such record for every product of a software publisher.

struct cur_cust /*current customer data*/

(int modulos; /*changable value used in the scramble/ unscramble calculations*/ char exex[32]; /*path of application program file*/ char cust_name[30] ; /*software publisher name*/ char cust_addl[30] ; /*software publisher address*/ char cust_add2[30] char cust_city[20] char cust__state[3] char cust_zip[10] ; char cust_soft_key[2]; /*are we doing a software key Y or N*/ char cust_mem_protect[2]; /*are we doing memory protect Y or N not used*/ char user_flag[2]; /**/ int uses;^* /*number of uses allowed for emergency use application*/ long disk_ nade; /*number of diskettes produced*/} cur cust; USER RECORD

The following is the record layout of the customer record as it may be used in this invention. This record is on the various diskettes and is required to get the modulos factor to unscramble various files. It may also be accessed by the application at the option of the software publisher.

struct user_id /*user data*/

{int modulos; /*value used in unscramble calculations*/ char serial[16] ;/*optional serial number for use by the application*/ char name[30]; /*user name and address for optional use by the application*/ char addl[30] char add2(30] char city[20] char state[3] char zip[10]; int num_reinstalls; /*used to generate and verify code numbers that allow for reinstallation*/ int reinstall_formula; /*used to allow for variable formulas to generate a reinstall code*/ int uninstall_flag; /*coded flag to indicate that the application was last uninstalled*/ char cust__soft_key[2]; /*are we doing a software key*/ char cust_mem_protect[2]; /*are we doing memory protect*/ char exex(32]; /*application path*/ unsigned status; /*status of the installed application program file*/ int filler[200];} user id; GLOSSARY

Following is a glossary of terms used in this patent application.

application - is a program created for sale by a software publisher.

bad spots - are sectors on- a magnetic or optical media that cannot be successfully written to and read from. When the media goes through a formatting procedure required to make it usable on the computer the file system of the computer often put a file allocation table on the media that points to free space on the media and de ines sectors on the media that are bad spots.

block - for this invention is defined as 512 bytes of data.

check digited - a number whose digits used in a formula result in one digit of the number.

cluster - sequential disk sectors accessed by the computer's file system as a unit.

customer record - is a data record that contains information about the software publisher, the application, and protection options the software publisher has chosen for this application. diskette - is a magnetic or optical information media used by many computers. Diskettes are usually removable and are. used to distribute data and programs for computers.

file - a set of data stored on a media such as a disk.

file allocation table (FAT) - is a table maintained by the file system of most computers that specify which disk sectors on a disk are used., free for use, or bad spots.

file system - the parts of a computers operating system that deal with managing data on a storage media.

formatting - is a process, usually a program provided with the computer, that makes diskettes usable to the computer's file system. It consists of putting timing marks on the diskette, finding and marking bad spots, and defining the track and sectors on the diskette.

path - is an ascii string describing the location and name of a file to a computer's file system.

protected software - is a software program, stored as a file on a magnetic or optical storage media, that is protected from unauthorized copying and use.

software publisher - produces software for sale. This is often distributed on magnetic diskettes.

software producer - is the same as s'oftware publisher. user - The person using the protected software.

USER RECORD - is a data record that is hidden on the INSTALLATION diskette and the SOFTWARE KEY diskette that contains information about the purchasing user. Included in this record is the scramble modulus used to unscramble data and the options chosen by the software publisher.

use value - is a value in the USER RECORD that is used by the EMERGENCY USE program to keep track of how many times the EMERGENCY USE can be used.

While preferred embodiments of the invention have been described, variations will no doubt occur to those skilled in the art without departing from the spirit and scope of the invention.

Claims

What is claimed is:

1. A software protection method, for use with software embodied in a distribution medium having a file allocation table indicating bad spots in said medium, comprising the steps of:

writing data to said medium in locations said file allocation table indicates are bad spots;

reading data from said indicated bad spot locations;

comparing the data read from said locations with the data written to said locations to determine whether said locations are in fact bad spots; and

determining whether said medium is a copy based on the results of said comparing step.

2. The method of claim 1, wherein said medium is determined to be a copy if all locations indicated in said file allocation table to be bad spots are in fact good.

3. The method of claim 1, further comprising the step of inhibiting further use of said software upon determination that said medium is a copy.

4. The method of claim 1, further comprising the step of unscrambling said software.

5. The method of claim 4, wherein said unscrambling step includes unscrambling said software in accordance with data relating to said bad spots.

6. The method of claim 5, wherein said unscrambling step includes unscrambling a user record.

7. The method of claim 5, wherein said unscrambling step includes unscrambling an application program.

8. The method of claim 1, wherein said writing and reading steps are controlled by software which is written to two or more non-adjacent locations in said distribution medium.

9. Amethod of making a medium for software including application software comprising the steps of:

formatting the medium, including creating a file allocation table identifying bad spots on the medium;

scrambling at least some of said software in accordance with the bad spot identification in said file allocation table; and

writing said software to said medium.

10. The method of claim 9, further comprising the step of making bad spots on said medium.

11. The method of claim 9, wherein said scrambling step includes scrambling said software in accordance with a user record.

12. The method of claim 9, wherein said scrambled software includes said application software.

13. The method of claim 9, further comprising the step of writing an install program to said medium.

14. The method of claim 13, wherein said install program includes means for writing to and reading from portions of said medium identified as bad spots in said file allocation table.

15. The method of claim 14, wherein said install program includes means for unscrambling scrambled software in accordance with the location of bad spots in said medium.

16. The method of claim 13, wherein said install program includes means for installing said application software on a storage device in a computer and for altering said medium to prevent said application software from being installed on another computer from said medium.

17. The method of claim 16, wherein said install program includes means for rendering said installed application software unusable and altering said medium to permit said application software to be installed on a computer from said medium.

18. The method of claim 16, wherein said install program includes means for receiving predetermined user-supplied data and for enabling installation of the application software on a storage device in a computer upon receipt of said predetermined data.

19. The method of claim 18, wherein upon receipt of said predetermined data, said installation is enabled for a predetermined number of times.

20. The method of claim 9, further comprising the step of writing a software key program to said medium.

21. The method of claim 20, wherein said software key program includes means for writing to and reading from portions of said medium identified as bad spots in said file allocation table.

22. The method of claim 20, wherein said software key program includes means for interchanging a portion of an installed application program with another program in order to turn the installed application on or off.

23. The method of claim 22, wherein said software key program includes means for controlling said interchanging means in accordance with whether the last action of said interchange means was to turn the installed application on or off.

24. The method of claim 9, further comprising the step of writing an emergency use program to said medium.

25. The method of claim 24, wherein said emergency use program includes means for controlling the number of times an application program contained in said medium may be used.

26. The method of claim 9, wherein said software includes means for installing said software on a storage medium in a computer, and means for determining during installation one or more parameters of said computer and means for storing said parameters in installed software.

27. The method of claim 26, wherein said software includes means for comparing said stored parameters with corresponding parameters of the computer on which the software is installed, and for rendering installed application software unusable if said corresponding parameters differ.

28. The method of claim 27, wherein said comparing means includes a program spawned during execution of said application software.

29. The method of claim 26, wherein said parameters include parameters determined by the location of said software in said storage medium.

30. The method of claim 26, wherein said parameters include parameters determined by the location of bad spots in said storage medium.

31. The method of claim 30, wherein said parameters include bit patterns stored in and/or near bad spots in said storage medium.

32. The method of claim 31, wherein said software includes means for comparing said stored bit patterns with corresponding bit patterns of the storage medium of the computer which said software is installed, and for controlling execution of application software in response to said comparison.

33. A computer readable medium for use in a software protection system,

said medium having bad spots at locations identified in a file allocation table thereon, and said medium having written thereon programming code that has been scrambled according to the location of bad spots identified in the file allocation table.

34. A computer readable software distribution medium for installing an application program on a computer,

said medium having bad spots at locations identified in a file allocation table thereon, and

said medium having written thereon: hidden user identification information, a spawned write/read program, a once installed protection program, an install program, and an applicationprogramcomprisingprogramming code that has been scrambled according to the location of bad spots identified in the file allocation table.

35. A computer readable medium for turning ON and OFF an application program that has been installed on a computer,

said medium having written thereon: hidden user identification information, a spawned write/read program, a once installed protection program, a software key program, a program to-be substituted for a portion of the installed application program rendering the application program unuseable, and a scrambled portion of the application program that is capable of being unscrambled by the software key program to make the application program useable.

36. A computer readable medium for running an application program from the medium if the application program that has been installed on a computer has become unuseable,

said medium having written thereon: hidden user identification information, an unuseable copy of the application program, a spawned write/read program, an emergency use program, a program to be substituted for a portion of the installed application program rendering the application program on said medium unuseable, and a scrambled portion of the application program that is capable of being unscrambled by the emergency use program to make the application program on said medium useable.

37. A software distribution medium produced in accordance with any of claims 9 to 19 or 26 to 32.

38. A computer readable medium for turning ON and OFF an application program that has been installed on a computer, produced in accordance with any of claims 20 to 23.

39. A computer readable medium for running an application program from the medium if the application program that has been installed on a computer has become unuseable, produced in accordance with either of claims 24 or 25.