CA2194215A1

CA2194215A1 - Personal computer security system

Info

Publication number: CA2194215A1
Application number: CA002194215A
Authority: CA
Inventors: Dmitry A. Luchuk; Oleg V. Kuznetsov
Original assignee: Individual
Current assignee: YBM Technologies Inc
Priority date: 1994-07-01
Filing date: 1995-06-30
Publication date: 1996-01-18
Also published as: AU2959495A; US5483649A; WO1996001446A1

Abstract

A personal computer subsystem (20), having a hardware module (20B) and protection software (20A), is designed to protect files on a personal computer from inadvertent or intentional distortion, and can be used to protect personal computers from programs known as computer viruses. The hardware module (20B) is connected to the personal computer system busses (50, 52, 54) and the software (20A) has a kernel which ensures the security of one access path (46A, 46B, 46C, 46D) to the hard disk controller (30) and utilizes the above-mentioned module (20B) to block other access paths (34, 36, 38, 40, 42, 44) to the hard disk controller (30). The only permitted access path (46A, 46B, 46C, 46D) to the hard disk controller (30) is a path which uses the computer's operating system (24), modular device driver (26) and basic input/output system (28). All other access paths (34, 36, 38, 40, 42, 44) to the hard disk controller (30) are interpreted by the personal computer subsystem (20) as forbidden.

Description

~ W096/01446 21 q42 1 5 P~

PERSONAL ~.~U~K SECURTTY SYSTEM
SPECIFI QTION
FTRTn OF THE lNv~-LluN
~The invention pertains to methods of protecting information on a hard disk, and can be used to protect files from ~inadvertent or intpnti~nAl distortion. In particular, this invention C~ a personal computer security system.
R~R~R~UND OF T~R l~V~ lUN
The most progressive approach to using personal computers for collective information processing is to combine personal computers into local area networks (LANs). The estAhlic1 --L of a LAN facilitates information gathering and permits the Pff;cipnt use of memory l~s~uL~es. However, LANs also provide favorable conditions for the rapid propagation of ~LVyL~~g known as computer viruses and the mass distortion of information stored on personal-computer disks. Computer viruses which distort information for purposes of causing Prnr i ~ 1068 to the information owner are particularly dangerous. The disastrous losses caused by computer viruses and the continually increasing number of viruses have brought about the need for information security subsystems designed to identify and eliminate viruses. ~owever; despite the many different security subsystems, computer crime statistics show that computer viruses present no less of a threat than before, and are still capable of causing serious losses to personal computer users. The risk for users of personal computers cnnnPctP~ to a LAN is cnncj~Prably higher than the risk for users of stand-alone personal computers. Therefore, protection from computer viruses is an urgent problem for stand-alone personal computers, and i6 PCpP~iAlly i ,~ rlL
for personal computers used in LANs.
A review of prior security subsystems for personal computers shows that these subsystems are usually based on the use of pLUyL~ which protect files from inadvertent or intentional distortion . DPpPn~ i ng on the hardware used to support the protection ~L~L~S~ these security subsystems are either software subsystems or software-hardware subsystems.

W096/0l~6 ~ "~

Software subsystems do not have any dedicated hardware, and all the L~s~uLces needed to support the protection P1OYLGm- are borrowed from the main personal ~ Gr. Software subsystems guickly became popular among pPr~nAl computer users and are now the main means for virus protection. However, experience with software subsystem8 showed that these subsystems are easily thwarted, and thus they are not very ~L~ iR1ng in the continuing war against viruses. Therefore, the main trend in the devPl ~ of security subsystems i5 toward software-hardware security subsystems.
Software-hardware sccurity subsystems include dedicated hardware and borrow some lesuuL~es from the main personal computer to support the protection ~L~L ~. A
typical example of this type of subsystem is the D.D.C.
subsystem (USA~, which provides virus diagnostics before the operating system is loaded into the main memory of the personal computer. (~ul~ 1 m i 11 i ~n~ i re Pickens finances antivirus firm, EDV-Aspekte, No. 9, p. 46, 1992.) The D.D.C.
subsystem is an ~YtPrn~l board which is inserted into one of the PyplnRi~n slots of the personal computer. The protection program, which is resident in the external board RO~, receives control after the personal Pr is reset and eliminates viruses on the hard disk before the operating system i8 loaded. A similar subsystem known as Thlln~rhyte was developed by the Dutch firm Esass. Both systems have the advantages of simple hardware supporting the protection program and relatively low cost. However, in these subsystems the protection program is not directly involved with hard disk access. As a result, these subsy8tems are not capable of preventing inadvertent or intentional distortion of hard disk files.
Subsystem8 which execute protection P~YLG~_ while the personal computer is in use provide protection against inadvertent or intentional distortion of files.
The following constitute various PY~mplpR of patents ~iccl~cin7 computer security systems.

wog6/01446 2l 942l 5 rc~

In British patent application 2248324A tData Security in a Computer Network), there is fl;cclncPd the use of a microcomputer in a ~ LPr network which permits shared access to stored data. The mi~L~ er comprises a security circuit which controls the operation of an address buffer according to a table of access conditions retrieved from non-volatile memory in response to an input F~ Ld (which can be one of five ~csignpd security levels), there being one of three access conditions ([l] read/write disable, [2] read enable/write disable and [3] read and write enable) for each block of memory addLesses. The relevant memory address block is ;flr~nt;~i~d by reading of a memory map that has been created and stored by the security circuit in the non-volatile memory.
Therefore, portions of a computer's memory are available to selected users and of those users only certain individuals have the ability to modify those portions of memory.
In European Patent Application 0268138A2 (Implementing Privilege on Ni~LuyLocessor Systems for Use in Software Asset Protection), there is disclosed a software protection system that uses two mi~-up~ucessoLD, an application p~ucesso~ and a supervisor plocessoI, to form a dual privilege (high or low) uu~Lucessor protection system.
To that end, the application processor only executes the application code and has no input/output capability. The supervisor processor, which controls the application processor, retrieves all of its instructions from a secure ROM
which cannot be modified by any external devices. Therefore, all input/output to the application ~LUCe550L is by way of the supervisor ~uceDDor. A high privilege read only memory ~nd a secure random access memory are enabled only in ~D~u..se to dedicated control signals from the supervisor p~U~USSUL. A
secure random access memory is provided for storage of sensitive information such as decryption keys. The coprocessor ; ~l c a low privilege level of operation for the purpose of executing protected software which is first decrypted under the control of the supervisor pLuceDDoL ~nd then stored in the application processor random access memory.

W096101446 r~
2l 9421 5 The c~y-~ce~soL i8 also capable of high privilege operation cither by the supervisor processor alone or with the supervisor p~oaes~L controlling the application y.~cess~l and its ~ssociated high privilege read only memory.
In Buropean Patent Application 0407060A2 (Method of Providing Mandatory Secrecy and Integrity File Security in a C to~ System) there is ~;c~lOc~ a method for ensuring access to filea of a computer system only to computer processes properly authorized for access. A separate security label is associated with each file and process of the system and defines authorized security classes pertaining to the associated file or process. Each security label contains information describing authorizations based on data secrecy and data integrity. A comparison is made on an attempted access of a file by a process of the security label associated with the process and the security label associated with the file. A verification is made based on the comparison that the process is authorized to access the file. The verification as to both secrecy and integrity aspects is accomplished in the single verification step.
In European Patent Application 04587l8A2 (Method for Controlling Public Access to a Plurality of Data Objects within a Data Proc~cc~ ing System), there i6 ~1 CCl 0~ a method for efficiently controlling public access to a plurality of data objects stored within a data processing system. An access control profile is associated with each data object.
Each access control profile preferably includes: an authorization parameter listing the identity of a particular user and ~he authorization level granted to that user; a shared authorization parameter listing the identities of a plurality of users and the authorization level granted to each listed user; and, a public authorization parameter listing the authorization level gr~nted to each user not specifically set forth within the access control profile. A single "public"
user identity i5 then defined for all users not specifically set forth within the access control profile, and that identity, as well as a public authorization level for an ~ WO96/01~6 2 1 9 4 2 1 ~ r~

entire group of data objects, i8 listed within a single shared authorization parameter. That shared authorization parameter is then placed within the access control profile of each data object within the group. Thereafter, a reference to the shared authorization parameter is placed within the public authorization parameter of each data object within the group so that public access to the entire group of data objects may be centrally controlled by means of a single shared authorization parameter.
In British patent application 2242295A (Access Control in a Data ProcQcR;ng System), there is disclosed a method of controlling access in a data processing system by way of a set of attributes defining targets that may be c~RRo~ and for acc~RRors that may access these targets. A
set of access security classes is then defined in terms of these attributes or other classes. Each class has a set of allowable operations associated with it. Each target is ARR;gn~ a classification comprising one of the classes and a set of allowed operations. Each entrant is assigned an authority consisting of one of the classes and a set of allowed operations. An entrant is allowed to access a target only if there is a common sub-class contained in both the entrant~s authority and in the target's classification and if the required operation is defined for that 51lhrl ~RR and appears in both the entrant's authority and in the target's classification.
In German P~lhl;RhPA Application No. 4034444Al (Data-.Ch i ~l ~ ; ng Workplace C t~r), there is disclosed a data-shielding workplace computer with working memory, mass storage, processor, peripherals, and a system bus connecting these system to each other. Data is stored in encrypted form in the mass storage devices. A security , t~r is provided, which has an additional pL~cessoI, additional working memory, and an additional system bus to connect these to each other and which is compatible with the workplace computer; a bus coupler is provided in order for the two system busses to be cnnn~rt~ and W096101446 2 1 9 4 2 1 5 ~ 9!1~

d;~çnnn~c~e~. Furthermore, requests for data from mass storage are yl~ce4~ed under the sole command of the security computer. Cryptologic proc~cin~ of these requests is ~ h~ exclusively by the security computer; monitoring units are provided in order for the system bus of the workplace computer to monitor access to ~1nAll~ ~_d addresses and to the security-relevant hardware ports of the mass storage units; an yenuy stop is implemented on the workrlAce computer whenever unallowed access i6 attempted.
In International Publication No. WO90/13084 tComputer File Protection System), there i8 fl; ~cln~ed a module comprising an auxiliary memory and a controller which are ~nnPcted to the system bus of a computer. The auxiliary memory is used to store supervisor-assigned criteria for secure access to the files. The controller is based on a digital ~r~coss~L, and thwarts access attempts which do not conform to the est~hl~ ~h~d security criteria. During the installation process, the controller creates a protected area on the disk for the storage of file signatures. If there is any deviation from the ese~hl;~h~fl criteria for secure access to files, the subsystem ~V~ further use of the computer.
~owever, such a functional-fl;agnns;~ subsystem tends to use expensive hardware and relatively high overall cost, making such a security system unavailable to many personal computer usera .
In addition, none of the above disclosures provides the uyeLatu~ with a personal computer having hidden storage of security yLuyl~a in conjunction with a hardware module that establish a single permitted path between the application program and the hard disk controller that can be monitored and/or obstructed when unauthorized access is attempted to, or a ~_ L~r virus attempts to write to, the hard disk.
03JECTS OF T~R INVRNTION
Accordingly, it is the general object of this invention to provide apparatus which address the aforementioned needs.

~096/01446 2 1 9 4 2 1 ~ r~ ~

It i8 a further object of this invention to provide hard disk protection of a p~r~n~Al computer without having to use encryption/de-cryption codes.
It is still a further object of this invention to provide security ~LU~mS that are loaded and operable within the personal computer before the basic input/output system is loaded and operable.
It is yet a further object of this invention to provide internal software protection for n~ ' JLked and non-n~L~J.ked computers for the procPc~ing of security-sensitive data.
It is still yet another object of this invention to provide a personal computer security system having a hardware portion that is not complex.
It is still yet a further object of this invention to provide a personal computer security system that provides a close rela~i~n~h; r between the hard disk access and the execution phase of the protection software.
sr~ ARY OF THE INV~NTION
These and other objects of the instant invention are achieved by providing a system of protecting data stored on the hard disk of a personal computer from inadvertent or intentional distortion. The personal computer has a central processing unit and memory, a hard disk controller having a command register, a hard disk, an address bus, a data bus, a control bus, and peripheral devices coupled thereto. The memory comprises a basic input/output system, a modular device driver, an operating system kernel, an application program and an interrupt vector table containing original interrupt handlers. The system of protecting data stored on the hard disk of a personal computer comprises a means for establishing a single access path to the hard disk controller from the application program. The means for establishing only one access path comprises a means for monitoring requests by the ~pplication program to the operating system kernel, the modular device driver and the basic input/output system. The means for establishing only one access path further comprises WO96101446 2 1 9 4 2 1 5 rc~

a PLUYL h7~ restriction module that permits the servicing of only those requests that utilize the opersting system kernel, the modular device driver and the basic input/output system, while precluding the servicing of any other ~u~ue~
The PLUYL h7e restriction module is coupled to the personal C , ~ ~r address, data and control busses and operates in a passive mode thereby allowing servicing of those requests util ;7;ng the operating system kernel, the modular device driver and the basic input/output system; or the PLU-, hle restriction module operates in an active mode thereby preventing the servicing of any other requests.
D~qCRTPTION OF THE DRAWINGS
Other objects and many of the att~n~nt advantages of this invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the ac ,-"ying drawings wherein:
Fig. l is an interface diagram of the invention with the personal computer system;
Fig. 2 i8 an interface diagram of the pLuyL~ ble restriction module and the computer hardware;
Fig. 3 is a functional diagram of the pLuuL~ ble restriction module;
Fig. 4 is a flow chart of the protection initialization program;
Figs. 5A-5B is a flow chart of the BIOS-level request check program;
Fig. 6A-6B is a flow chart of the modular device driver-level request check program; and Figs. 7A-7E is a flow chart of the OS kernel-level request check program.
Fig. 8 is an interface diagram of another ~
of this invention showing the configuration of its respective protection kernel;
Fig. 9 is a ~LL~UL~1 diagram of the protection-program support module;

~ WO96/01446 ~ ~ 9~215 r~

Fig. 10 i5 a flow chart of the protection initialization program;
Figs. llA-llB i8 a flow chart of the BIOS-level request check program;
Figs. 12A-12B i5 a flow chart of the modular device driver-level request check program;
Figs. 13A-13F i8 a flow chart of the OS kernel-level request check program;
Fig. 14 is a flow chart for a key program.
Fig. 15 is a functional block diagram of the program discriminator;
Fig. 16 is a functional block diagram of the pLUyL hle controller; and Fig. 17 is an ~ lAry protection control program.
DES~RTPTION OF T~F INV~TION
Referring now in detail to the various figures of the drawing wherein like reference characters refer to like parts, there is shown at 20 in Fig. 1, the file protection subsystem which comprises protection software 20A and a hardware module 20B, known as the pLVyL hle restriction module (PRM) 20B. The protection software 20A comprises a set of protection p~vy~ , the kernel of which uses the PRM
20B to restrict the set of possible access paths to the hard-disk controller, as ~i~cn~P~ below.
A convPntinnAl personal computer system basically comprises application program software 22, operating system (oS) software 24, modular device driver (MDD) software 26 and basic input/output system (BIOS) software 28 that have access to the computer's hard disk controller 30 (and, thereby, the hard disk 32 itself) via a set of access paths 34-48.
The file protection subsystem 20 is interfaced with the pPn~nAl computer system to monitor the security of requests involving one access path 46A-46D to the hard-disk controller 30, and prevents the servicing of requests involving other access paths 34-44 to the hard-disk controller 30. The only permitted access path 46A-46D to the hard-disk controller 30 is an access path using the BIOS 28. All other WO96~1446 2 1 9 ~ 2 1 5 ncces6 paths 34-44 to the hard-disk controller 30 are interpreted as f.~rh; ~Dn ~
The PRN 2OB is an external board cnnn~ct~d to the personal computer system address bus 50, data bus 52 and control bus 54 (Fig. 2). The PRN 20B has two operating modes.
In the first (passive) operating mode, the PRN 20B does not affect central processing unit 56 (CPU) access to the peripheral devices. In the second (active) operating mode, the yLuyL hle restriction module monitors the bus cycles involving CPU 56 access to the peripheral devices and ~Luduces a blorki ng signal in the bus cycle of data output to the data register of the hard-disk controller 30, thereby preventing the completion of the current bus cycle by removing availability from the CPU 56.
The protection software 20A consists of a protection initialization program, a protection kernel, and a protection control program. The hard disk 32 is used to store the protection software 20A. The protection control program is stored on the hard disk 32 as an ordinary file. The first eight sectors of the hard disk 32 are used to store the protection initialization program and the protection kernel.
The protection initialization program is stored in the first sector of the hard di6k 32, while the master boot record is transferred from the first sector and placed in the ninth sector of the hard disk 32. As A result, the first program which receives control when the OS 24 is loaded is the protection initialization program.
The protection kernel has a three-level configuration and consists of three ~ ~ntS: a program 58 which checks requests at the BIOS level (Figs. 5A-5B~, a program 60 which checks requests at the modular device driver level (NDD, Figs. 6A-6B), and a program 62 which checks requests at the OS kernel level (Figs. 7A-7F). Each -nt of the protection kernel uses a specific link with an individual c of the OS 24 or BIOS 28. The OS kernel-level request check program 62 is linked with the original handler of the 21h OS interrupt (MS-DOS System Fnnnti~An~) by ~ WO96/01446 7 1 9 ~ 2 1 5 r~

removing from the OS kernel the call of the 82h function tNetwork Redirect) of the 2Ah OS program interrupt (N~ JLk~
Interface) and inserting the call for the OS kernel-level request check program 62 into the OS kernel. The NDD-level request check program 60 uses a link estAhliched by r~plAc;ng the address of the original handler of the 13h interrupt of the modular device driver in the interrupt vector table (IVT) with the address of the modular device driver-level request check program 60. The BIOS-level request check program 58 uses a link esfAhl;ch~ by rpplAring the address of the original handler of the 13h BIOS interrupt used by the modular device driver to call the program with the address of the BIOS-level request check program 58. In addition, the BIOS-level request check program 58 uses a link estAhl; Ch~d by replacing the address of the original handler of the 13h BIOS
program interrupt in the interrupt vector table with the address of the BIOS-level request check program 58, thus providing an AllY; 1; Ary link which is used during loading of the OS 24.
The protection initialization program loads the protection kernel into the main memory and establishes a link between the BIOS-level request check program 58 and the original handler of the 13h BIOS interrupt. After this link is estAhl i Ch~d, the protection initialization program loads the master boot record into the main memory and transfers control to the master boot record.
During the OS 24 loading process, the BIOS-level request check program 58 monitors the procesg and es~hl i ch~c, after loading is completed, a link between the MDD-level request check program 60 and the original handler of the 13h modular device driver interrupt. The BIOS-level request check program 58 establishes a link between the modular device driver and the 8IOS-level request check program. Further fun~tioning of the protection kernel is initiated by information requests from the application program 22, and depends on the type of request. The protection kernel supplements the file protection measures performed by the OS

WO96101446 2 1 9 4 2 1 5 P~

kernel, and grants the protection control program the privilege of rh In~ing the status of files.
The purpose of the protection control program i8 to change file attributes. It i5 the only application program 22 that has the privilege of changing the status of files. An example of a protection control program i5 given in Fig. 17.
To use this privilege, the protection control program sets its own activity flag when requesting a change of file attribute.
The activity flag of the privileged program is checked by the OS kernel-level request check program 62 (Figs. 7A-7F).
The OS kernel-level request check program 62 checks for a match between the current request and the set of d~my~Luus requests at the OS 24 kernel level and prevents the servicing of dangerous requests by returning control to the application program and by setting an error flag in the CPU 56 (Fig. 7F). An example of setting an error flag is by setting the carry bit in the flags register of the CPU 56. The dany~l~us requests include requests to change file attributes in the absence of a protection control program activity flag and requests to write a track on a logic device. All other reque8ts are interpreted as safe. If the reque8t is a safe request, then the os kernel-level reguest check program 62 doe8 not prevent servicing of the request; in the event of requests to create files with the ext~nci~nC .EXE, .CON, .sYs, .OVL, .LIB, .DLL, or .BIN, the OS kernel-level request check program 62 ascribes the attribute "read only" (Figs. 7B and 7C).
The modular device driver-level request check program 60 checks for a match between the current request and the set of dangerous requests at the modular device driver 26 level. Among the dangerous requests are hard disk 32 formatting requests. Other dangerous requests are write requests which are not preceded by use of the OS 24, and write requests from sources other than the modular device driver 26.
All others requests are interpreted as safe. If the request i8 one of the dangerous requests, the MDD-level request check program 60 pl~v~11Ls servicing of the request by returning ~ WO96/01446 2 1 9 4 2 ~ 5 P~

control to the calling program and by setting an error flag in the CPU 56 ~Fig. 6B). Otherwi5e, the MDD-level request check program 60 does not prevent servicing of the request and calls the original handler of the 13h modular device driver interrupt (Fig. 6B).
The BIOS-level reguest check program 58 checks for a match between the current request and the set of dan~L~us requests at the BIOS 28 level. The dangerous requests include hard disk 32 formatting requests, write requests not preceded by use of the modular device driver 26, and write requests from sources other than the modular device driver 26. The BIOS-level request check program 58 prevents the servicing of dangerous requests by retnrn;ng control to the calling program and by setting an error flag in the CPU 56 (Fig. 5B). If the request is safe, the BIOS-level request check program 54 switches the PRM 20B to the passive operating mode and transfers control to the original handler of the 13h BIOS
interrupt; after this handler services the request, the BIOS-level request check program 54 switches the PRM 20B into the active operating mode. An attempt to use the hard disk controller 30 when the PRM 20B is in the active mode will result in the removal of CPU 56 availability. In that event, the personal computer will have to be reset before further use. As a result, the only permitted access path to the hard disk controller 30 is an access path 46D using the BIOS 28.
A detailed description of the configuration and functional organization of the file-protection subsystem is given below.
As shown in Fig. 3, the PRM 20B contains a peripheral device port decoder 64, two D-type flip-flops 66 and 68, a pulse g~,lel~to1 70, an inverter 72, and two buffers 74 and 76.
The peripheral device port decoder 64 monitors the bus cycles involving CPU 56 access to the peripheral devices and ~.oduces a system-bus blocking signal I/O CH RDY on the system bus availability line 78 in the event of access to the hard-disk controller 32 registers. In addition, the peripheral W096/01446 2 1 q ~ 2 1 5 rc1~

device port decoder 64 produces signals that permit the reading of information from the first flip-flop 66 or the writing of information into the second D-type flip-flop 68.
The peripheral device port decoder 64 is a pr~L hl e logic device with three outputs (D0, Dl and D2). The first output D0 of the peripheral device port decoder 64 i5 connected to the control input of the first buffer 74 and to the SET-input (S) of the first flip-flop 66; the second output Dl of the peripheral device port decoder 64 is connected to the control input Or the second buffer 76 and the C-input of the first D-type flip-flop 66; and the third output D2 of the peripheral device port decoder 64 is cnnnPct-p~ to the C-input of the second D-type flip-flop 68.
The first D-type flip-flop 66 records instances when the PRM 20B ~v~ an attempt to access the hard disk controller 30 registers.
The second D-type flip-flop 68 sets the operating mode of the PRM 20B.
The pulse generator 70 produces a reset ~ignal (a low level logic pulse) for the first D-type flip-flop 66 when the supply voltage is initially received. This signal is a ~hort negative pulse transmitted to the R-input of the first D-type flip-flop 66.
The inverter 72 changes the polarity of the RESET
signal transmitted from the system bus to the R-input of the second D-type flip-flop 68.
The first buffer 74 is connected to the system-bus availability line 70 and removes availability from the personal computer system bus when a blocking signal I/0 C~ RDY
is received from the first output D0 of the peripheral device port decoder 64.
The second buffer 76 is cnnnP~tp~ to the system data bus 52 via line 80 and is used to permit the reading of the state of the first D-type flip-flop 66.
The PRM 20B begins to operate after the personal _ , t~r is started. Upon startup, the output of the pulse generator 70 produces a signal to reset the first D-type flip-~ WO96101446 2 I q 4 2 1 ~ rc~

flop 66. At the same time, a system RESET signal i6 receivedby the inverter 72 which generates a reset signal to the R-input of the second D-type flip-flop 68 in order to reset the flip-flop. When these signals are present, a high-level logic signal i8 ~uduced at the inverted output Q of the first D-type flip-flop 66, indicating the absence of thwarted attempts to access the hard disk 32, and a low-level logic signal is uduced at the direct output Q of the second D-type flip-flop 68. The low-level logic signal from the direct output Q of the second D-type flip-flop 68 is transmitted to the first input (An) of the peripheral device port decoder 64 and sets the PRN 20B in the passive operating mode.
In order to switch the operating mode of the PRM
20B, the CPU 56 produces signals (a "l" or a "0") on the data bus 52, along with signals on the control 54 and address 50 busses (based on the input from the BIOS-level request check program, Fig. 5B, to be ~;~c1~c~ later) that is latched into the second D-type flip-flop 68 which specifi~s the required operating mode. In particular, a one ("l") value for this bit sr~c;f;~c the active operating mode and a zero ("0") value specifies the passive operating mode. When present, the rising edge of the signal from the D2 output of the peripheral device port decoder 64 latches the "l" or "0", that is present on line 80, into the D input of the second D-type flip-flop 68.
Once in the active operating mode, the peripheral device port decoder 64 checks the bus cycles involving CPU 56 access to the peripheral devices. If the system output line sends an active signal, IOW (input/output write), to the input of the peripheral device port decoder 64 and if the address of the hard-disk controller 30 command register is on the address lines of the system unibus, then a low-level logic signal is produced at the first output D0 of the peripheral device port decoder 64 and is transmitted to the control input of the first buffer 74 and to the S-input of the first D-type flip-flop 66. As a result, the inverted output Q of the first D-type flip-flop 66 will have a low logic level. A low-level WO96/01~6 l~ll~ _ 21942~5 logic signal is produced at the output of the first buffer 74 and is transmltted to the personal computer system unibus availability line 78. This signal ~L~V l-Ls the completion of the current bus cycle and any further use o~ the personal computer.
The personal computer must be reset before further use is pocc;hl~. In the event of a system RESET signal, the PR~ 20B switches to the passive operating mode, and the inverted output Q of the first D-type flip-flop 66 ~Luduces a low-level logic signal, which indicates that an attempt to access the hard disk has been denied. The CPU 56 checks the current state of the first D-type flip-flop 66 by reading the state of the SD0 signal generated by the first D-type flip-flop 66. The rising edge of the read signal on the line 82 from Dl writes into the first D-type flip-flop 66 the logic zero set at the D-input of the flip-flop 66. The first D-type flip-flop 66 then switches to the initial state.
The protection initialization program identifies the personal computer user, loads the OS 24 kernel into the main memory, and es~hliRh~R a link between the BIOS-level request check program 58 and the original handler of the 13h BIOS
program interrupt.
The protection initialization program resides in the first sector of the hard disk 32 and is loaded into the personal computer main memory before the master boot record (MBR) is loaded. The initialization-program stack is placed in the conventional memory. After the stack is installed, the initialization program decreases the amount of memory available to the OS 24 by the amount of memory occupied by the protection software 20A (Fig. 3). The initialization progr~m decreases the amount of memory available to the OS 24 by correcting the two-byte value of the memory size, which i5 stored in the address 0040:0013h. After the amount of memory available to the os 24 has been changed, the initialization program clears the last four Kbytes of the conventional memory.

~ WO96/01446 2 1 9 4 2 1 ~ ~l/U~

After the memory area needed for the protection kernel is cleared, the protection initialization program uses the 02h function (Read Disk Sectors) of the 13h BIOS program interrupt to load the protection kernel into the main memory.
After the protection kernel i5 loaded, the protection initialization program requests the personal computer user p~ ..d. After the E~- JLd is entered, the initialization program compares the signature of the p~ JLd entered by the user with the p~- d signature in the protection kernel. If the two s~yllaLuLes do not match, the protection initialization program outputs a message that use of the personal ~ or is prohibited and stops the CPU 56. If the signatures match, the protection initialization program undertakes to establish a link between the BIOS-level request check program 58 and the original handler of the 13h BIOS program interrupt.
The protection initialization program est~hl i ~h~ a link between the BIOS-level request check program 58 and the original handler of the 13h BIOS program interrupt. To do this, the protection initialization program extracts from the interrupt vector table the address of the original handler of the 13h BIOS interrupt and places in the interrupt vector table the address of the BIOS-level request check program 58.
The protection initialization program saves the address of the original handler of the 13h BIOS program interrupt, and the BIOS-level request check program 58 uses that address to transfer control to the original handler of the 13h BIOS
program interrupt. After that link is est~hl; ~hod, the initialization program reads the MBR from the ninth sector of the hard disk 32, loads the MBR into the main memory, and transfers control to the MBR.
The BIOS-level request check program 58 uses the PRM
20B to limit the poc~ihlo access paths to the hard-disk controller 30 and performs the following fllnrtinn~ (Figs. 5A-5B):
when the hard-disk partition table is read, the BIOS-level request check program 58 places in the sector WO96/01446 r~

number register the number of the ninth sector used to store the original hard-disk partition table;
when the OS 24 is being loaded, the BIOS-level request check program 58 monitors the OS 24 loading process, and after this process is completed, establishes a link between the MDD-level request check program 60 and the original handler of the 13h modular device driver interrupt;
when the personal _ ~r i~ being used, the BIOS-level request check program 58 establishes a link with the modular device driver 26 and yL~v~ S the servicing of d-ngelv~s requests.
when the OS 24 i5 being loaded, the BIOS-level request check program 58 identifies read requests using the 02h tRead Disk Sectors), OAh (Read Long Sectors), or OEh (Read Sector Buffer) functions (i.e., the standard input/output function of BIOS) of the 13h BIOS interrupt. The BIOS-level request check program 58 checks for the presence of two OS
loading completed flags. The first OS loading completed flag is the rl A~ t of the address of the original handler of the 21h interrupt in the interrupt vector table. The second OS
loading lete~ flag i8 the OS initialization ~ le~
flag, which is returned by the 1200h function (Get DOS
Installation Status) of the 2Fh OS program interrupt (Multiplex Service). In the abGence of these OS loading completed flags, the BIOS-level request check program 58 switches the PRM 20B into the passive operating mode and calls the original handler of the 13h BIOS interrupt. The BIOS-level request check program 58 then switches the PRM 20B back into the active operating mode.
If the OS loading completed flags are present, the BIOS-level request check program 58 places in the interrupt vector table the address of the MDD-level request check program 60 and stores the address of the original handler of the 13h modular device driver interrupt in the MDD-level request check program 60. Then the BIOS-level request check program 58 copies the data d~t~rm;ning the current state of the OS 24 into the conv~nt;nnA1 memory, and, using the 5D06h ~ WO96~1446 21 9421~

function (Get Critical-Error Flag Address) of the 21h OS
interrupt, ~PtPrmin~c the address of the rwarp~hlP data area (SDA). After the address of that area is detPrminPd, the BIOS-level request check program 58 sets an OS loading _leted flag and LeDLoles the current OS state using the copy of the data ADtPrmin;ng the current OS state.
While the personal computer is in use, the 8IOS-level request check program 58 est~hlichPc a link with the modular device driver 26 and prevents the servicing of dangeLuuD requests. Nhen a formatting request i8 i~nti fip~, the check program ~L-._.I-S the servicing of the request by ret~rning control to the calling program and by setting an error flag in the CPU 56. When a write request is identified, the check program 58 checks the path used to access the hard-disk controller 30. If the flag of the MDD-level request checlc program 60 activity is not set or if the request source i5 not the modular device driver 26, the check program 58 prevents the servicing of the request and returns control to the calling program and by setting an error flag in the CPU
56.
For the servicing of requests, the BIOS-level request check program 58 switches the PRN 20B into the passive operating mode and calls the original handler of the 13h BIOS
program interrupt (Fig. 5B). After the request is serviced and control is L~uL..ed to the BIOS-level request check program 58, the program switches the PRM 20B to the active operating mode.
The ~DD-level request check program 60 (Figs. 6A-6B) identifies hard disk formatting requests and prevents servicing of the request by retl~rning control to the calling program and by setting an error flag in the CPU 56. When a write rec~est is identified, the check program 60 checks the path used to access the hard-disk controller 32. If the flag of OS kernel-level request check program 62 activity is not present, the check program 60 ~L~V~ 5 the servicing of the request and returns control to the calling program and by setting an error flag in the CPU 56. In addltion, the MDD-WO96101446 2 1 9 4 2 1 5 P~ s level request check program 60 ~Le~..L~ the servicing ofrequests from sources other than the modular device driver 26 or the NS-WINDOWS operating environment.
For the servicing of requests, the MDD-level request check program 60 sets a flag of its own activity and ca11s the original handler of the 13h modular device driver program interrupt. After the request is serviced and control is le~uL..ed to the NDD-level request check program 60, the program 60 removes the flag of its own activity.
The OS kernel-level request check program 62 checks the number of the requested function of the 21h OS interrupt and, if the OCh (Clear Buffer and Input~, 31h tTerminate and 8tay ~si~Pnt), 48h (Allocate Memory~, 49h (Release Memory), 4Ah (Modify Nemory Allocation), 4Bh (Execute Program), or 4Ch (Terminate with Return Code) function is ;~ntif;~i, returns control to the original handler of the 21h OS program interrupt. In the event of other requests, the OS kernel-level request check program 62 copies the values of the registers used by the original handler of the 21h OS interrupt into the memory area used by the protection software 20A.
Then the request check program 62 extracts from the swappable data area (SDA) the value of the application program stack indicator and copies the application program stack to the memory area used by the protection software 20A. After the stack copy is made, the OS kernel-level request check program 62 checks the number of the requested function and identifies the 16h (Create File with File Control Block), 3Ch (Create File with Handle), 6Ch (Extended Open/Create), 4301h (Set File Attributes), or 440Dh (Write Track on Logical Drive) function of the 21h OS interrupt, each of these flln~ti nnc involving a separate protection ~L ~dUL e .
For the 16h function (Create File with File Control Block) of the 21h OS interrupt, the OS kernel-level request check program 62 ~iPtPrminPC the format of the file control block (FCB, Fig. 7B). If the FCB has an extended format, the check program determines the extension of the file being created. For files with extPnc;nnc of .EXE, .COM, .SYS, .OVL, ~ W096/01446 21 9421 ~ r ~

.LIB, .DLL, or .BIN, the OS kernel-level request check program 62 ascribes the attribute "Read Only" by modifying the file attribute field in the FCB.
For the 3Ch (Create File with ~andle) and 6COOh (Extended Open/Create) functions (Fig. 7C), the OS kernel-level request check program 62 checks the format of the ASCIIZ
line (characters being represented in ASCII format and where the final character in the string is ASCII character "O") indicated in the call of said fllnr~innR If the ASCIIZ line format is not correct, i.e. , the ASCIIZ line does not contain a final zero, then the OS kernel-level request check program 62 returns control to the program creating the file (Fig. 7F).
The OS kernel-level request check program 62 also sets an error flag in the CPU 56 and installs the error code "Access Denied" (Fig. 7F). If the ASCIIZ line format is correct, the program 62 detQrm;n~R the extension of the file being created.
For files with ex~QnRionR of .EXE, .CO~, .SYS, .OVL, .LIB, .DLL, or .BIN, the OS kernel-level request check program 62 (Fig. 7C) places the attribute "Read Only" in the application program stack storing the value of the CX register (the Count register of the CPU 56). In addition, the OS kernel-level request check program 62 places the attribute in the copy of the value of the CX register used by the original handler of the 2lh OS interrupt.
For the 4301h (Set File Attributes, which permits a program to change a file's attributes) function (Fig. 7A), the OS kernel-level request check program 62 checks for the activity flag of the protection control program having the privilege of ~h~ng;ng file attributes. If the activity flag of the protection control program is absent, the OS kernel-level request check program 62 pl~v~ the servicing of the request by transferring control to the program requesting the change in file attributes and by setting an error flag in the CPU 56 and installing the error code "Access Denied" (Fig.
7F).
For the 440Dh (which includes Minor Code 41h: Write Track on Logical Drive) function (Fig.7A), the OS-kernel-level W096/01446 ~1;9 4 ~ 1 5 P~

request check program 62 identifies a request to write a track on a logic device that is a prototype of the hard disk 32, and prevents servicing of the request by tr~nsferring control to the program requesting to write a track and by setting an error flag in the CPU 56 and installing the error code "Access Denied" (Fig. 7F).
After a protection yLuueduLe involving one of the abuv~ i~n~d fnnrti~n~ is performed, the OS kernel-level request check program 62 changes the return address from the original handler of the 21h interrupt in the application program stack. The OS kernel-level request check program 62 saves the return address from the original handler to the application program and places the return address to the oS
kernel-level request check program 62 in the application program stack. Then the Os kernel-level reguest check program 62 places the address of the ~DD-level request check program 60 in the interrupt vector table and stores the current address of the handler of the 13h modular device driver interrupt in the memory area used by the protection software 2OA. After the current address of the 13h interrupt handler is changed in the interrupt vector table, the os kernel-level request check program 62 uses the 1600h function of the 2Ph program interrupt (Nultiplex Interrupt) to check for activity of the MS-Windows operating environment. If the value le~uL..ed to the AX register (the Arc~ tor register of the CPU 56) is not 1600h, the check program 62 sQts the MS-Windows activity flag. Then the OS kernel-level request check program 62 restores the register values based on the copy of the register values used by the original handler of the 21h OS
interrupt, sets its own activity flag, and rQturns control to the original handler of the 21h program interrupt. After the request is serviced and control is l~ul..ed to the OS kernel-level request check program 62, the request check program 62 removes its own activity flag and the activity flag of the Windows operating environment. Then the OS kernel-level request check program 62 restores the current address of the ~ WO96/01446 2194~15 13h modular device driver interrupt handler and transfers control to the application program 22.
As stated earlier, the purpose of the protection control program is to change file attributes. It is the only application program 22 which has the privilege of changing the status of files. In order to use this privilege, the protection control program sets its own activity flag before calling the 4301h function of the 21h OS interrupt and removes that flag after the request is serviced. The activity flag for the protection control program is set using the data byte declared in the OS kernel-level request check program 62. The protection control program det~rmin~c the memory address for the activity flag with the aid of the llllh function (Search for First Entry (FCB)) of the 21h OS program interrupt; the OS
kernel-level request check program 62 processes the above-- ion~d function and returns the value memory address for the activity flag to the protection control program.
Another ~ of this invention accomplishes the same type of access restriction a -ni~ with secure monitoring of the permitted path.
To that end, there is shown at 120 in Fig. 8 a protection-program subsystem that comprises hardware and protection ~L~L 120A on a single computer board, known as the protecti~.. p~U~L~m support module 1208 (PPSM). As shown in Fig. 9, the protection pL~yL~_ 120A and the PPSN 120B
restrict 11 paths 34-44 between the application software 22 and the hard drive controller 30 while monitoring the security of requests involving one access path 46A-46D and 48, as ~i~rllCC~d earlier with respect to the file protection subsystem 20.
However, the interfaces between the PPS~ 120B and the computer busses are different than the PP~ 20B. In particular, as shown in Fig. 9, the PPSM 120B comprises a first memory 122, an address decoder 124, a second memory 126, a program discriminator 128, a pL~yL hle controller 130, and an AND gate 132. Each of these (except for the AND gate 132) is connected to the computer's address bus 50, data bus W096/01446 2 ~ ~4~ i 5 PCI/I . ~

52 and control bus 54, accordingly. The interaction of these ' will be ~;Q~Anc~e~ later.
The PPSM 120B is an external board C~nnnPctP~l to the personal computer address bus 50, data bus 52 and control bus 54. The PPSM 120B provides hidden storage for the protection ~LU~L 120A and estAhli~hPQ a logical tlerPn~pn~Ae between the ~YP~-utinn phase of the protection ~lLV~Lloli 120A and the possibility of using the hard disk 32, as will be AiQC~ in detail later.
The PPSN 120B has two operating modes. In the first (passive or neutral) operating mode, the PPSM 120B does not affect CPU 56 access to the peripheral devices. In the second (active or working) operating mode, the PPSM 120B monitors the bus cycles involving CPU 56 access to the peripheral devices and ~L~duces a blocking signal in the bus cycle of data output to the command register of the hard disk controller 30, thereby preventing the completion of the current bus cycle by removing avAil~hility from the CPU 56.
The first memory 122 stores the protection ~JlU~L
120A, and this memory 122 can be ;nArcPQQihle to the cPU 56.
The second memory 126 is always AccPQsihle to the CPU 56 and is used to store the different versions (134, 136 and 138, Fig. 8) of the key program ~Fig. 14), which is capable of changing the state of the PPSM 120B. As shown in Fig. 9, the address decoder 126 has two outputs and divides the address space occupied by the PPSM 120B memories between the first memory 122 and the second memory 126. The first output of the address decoder 126 is cnnnPcfP~l via line 140 to the first input 142 of the AND gate 132. The output 144 of AND gate 132 is cnnnPr~Prl to the select input 146 of the first memory 122.
The second output of address decoder 124 is connected to the select input 148 of the second memory 126 and also to the control input 150 of the program discriminator 128 via line 152. The output of the program discriminator 128 is connected to the ~LUyL hle controller 130 via line 154.
The memory access control output 156 of the pluyLrA~a.ble controller 130 is connPcfe~ to the second input 158 of the AND

~ WO96/01446 2 1 9 ~ 2 1 5 gate 132 via line 160. Finally, the blocking signal output 162 of the ~LU~L hlP controller 130 is connected to the _ ~ar control bus 54 via line 164.
The program discriminator 128 dPtPrminp~ the type of program acting on the ~LUyL hlP controller 130 and est~hli~hpc the logical relatinn~h1p between the type of abu~ ~ione~ program and the possibility of switching the PPSM 120B. The program discriminator 128 ~PtPrminP~ the type of program acting on the P10~L hle controller 130 by testing the COLL~ nre between the content of the bus cycles for the extraction and execution of this program and the content of the bus cycles for the extraction and PYpcut;on of the key program. The program-extraction cycles are the cycles for reading the codes of the key program from the second memory 126. The program F~u~llion cycles are the cycles for outputting information to the ~LUUL hl~
controller 130. If the cycle content corresponds to that of the key program, the program discriminator 128 generates a signal which confirms the activity of the key program. This signal is sent along line 154 to the pL~L h1e controller 130, and makes it possihlp to record information in the controller 130. If the cycle content does not cuLL~yu~d to the key program, the program discriminator 128 does not allow the entering of information into the yLuu,L hle controller 130.
The pLUyL h1e controller 130 blocks access to the hard-disk controller 30 and pL~vents access tc the first memory 122. The CPU 56 can program the mode of the controller 130 only when the signal indicating the activity of the key program i8 present. The ~LUyL h1~ controller 130 stores the given code and generates control signals COLL~ 1ng to the given operating mode.
If the ~LUyL hlP controller 130 contains the code allowing access to the memory 122, the controller 130 generates a signal allowing access to the first memory 122.
If the pLUUL hle controller 130 contains the code preventing access to the memory 122, the controller 130 W096/01446 p~"~ _ 2~94215 generates a signal preventing access to the first memory 122, by hlo~ing the AND gate 132. In particular, if a high level logic signal is present on line 160 the gate 132 does not permit the trAnF~;csi~n of select signals for the first memory 122 as requested by address decoder 124 on line 140. If a high level logic signal is not present on line 160, the AND
gate 132 does not prevent the trAnF~1Ccinn of select signals for the first memory 122 as requested by address decoder 124 on line 140.
If the neutral-state code is stored in the plOuL -hle controller 130, the latter does not affect access by the CPU 56 to the hard-disk controller 30. If the working-state code is stored in the plUyL -hle controller 130, the latter verifies the bus cycles for CPU 56 access to output devices. If a cycle for CPU 56 access to the hard-disk controller is found, the pLU~L hl P controller 130 generates a signal which blocks access to the hard-disk controller 30.
This signal is sent through line 164 to the system ready line and prevents the completion of the current bus cycle and any further use of the pprsnn~ r, The personal computer must be reset (and the PPSM 120B reset) before any further use is allowed.
The details of the hardware operation of the PPSM
120B will be ~iccllccp~ later following the ~icr~ ;nn of the protection pLuyLa~3 120A.
The initial state of the PPSM 120B is the neutral state (the passive mode), and the first memory 122 is read-accessible. In this regard, it should be noted that the reset signal causes the CPU 56 to detcrmine the personal-computer configuration and transfer control to pL~yL resident in the external-device ROM. Since the first memory 122 of the PPSM
120B occupies the region of address space reserved for the external-device ROM, the protection pLu~La~ 120A receive control before the OS 24 is loaded. As a result, the protection ~LU~L 120A, using versions (134, 136 and 138) of the key program (that coLLeapul-d to a respective level request check program ~ic~llcsed below), can switch the PPSM 120B into WO96/01446 ra~
~ 219~215 the required state before the p~rsAn~l computer is in the ready state. In particular, the key program can switch the PPSM 120B into the working state (the active mode) after the oS 24 i8 loaded. In addition, the protection pL~L 120A
can prevent access to the first memory 122 and can be hidden from the applications software 22 and the OS 24.
The protection ~L~L~ 120A include a protection initialization program (Fig. 10), a protection kernel, and a protection control program. The protection kernel has a three-level configuration and consists of three L~: a program 135 which checks requests at the BIOS level (Figs.
llA-llB), a program 137 which checks requests at the modular device driver level (Figs. 12A-12B), and a program 139 which checks requests at the OS kernel level (Figs. 13A-13F). Fach - ~nt of the protection kernel uses a specific link with an individual ~ of the OS 24, modular device driver 26, or BIOS 28. The OS kernel-level request check program 139 is linked with the original handler of the 21h OS interrupt by removing from the OS kernel the call of the 82h function of the 2Ah OS program interrupt and inserting into the OS 24 kernel the call code for the key program 138 in the memory 126 which coLLu-~ul-ds to the request check program 139 at the OS
24 level. The modular device driver-level request check program 137 uses a link estAhli~hed by replacing the address of the original handler o~ the 13h illLeL~ of the modular device driver 26 in the interrupt vector table with the call code for the key program 136 in the memory 126 which coLL~D~Ilds to the modular device driver-level request check program 137. The BIOS-level request cheak program 135 uses a link est~hl;~h~ by r~pl~i ng the address of the original handler of the 13h BIOS interrupt used by the modular device driver 26 with the call code for the key program 138 in the memory 126 which uuLL~unds to the BIOS-level request check program 135. In addition, the BIOS-level request check program 135 uses a link es~hli~h~d by replacing the address of the original handler of the 13h BIOS program interrupt in the interrupt vector table with the address of the key program Wo96/014J6 2 1 94~ 1 5 134 ~OL~ JIJ~;ng to the BIOS-level reguest check program 135, thus providing an auxiliary link which is used during loading of the OS 24.
Each L of the protection kernel uses its own version of the key program (Fig. 14). All the versions (134, 136 and 138) of the key program are stored in the second memory 126 of the PPSN 120s. Each version of the key program switches the PPSM 120B into the passive mode when control is transferred to the _ ~ of the protection kernel coLL-~p-ll;ng to the level of the request, and switches the PPSM 120B into the active mode when control is returned to the program which requested the service at the COLL~ ;ng level. An attempt to use the hard-disk controller 30 when the PPSM 120B is in the active mode results in the removal of availability from the CPU 56, and the personal ~ r must be reset before further use is possible. As a result of this, the only p~rm;c~ihle access path to the hard-disk controller 30 is the access path using ~ _ Ls of the protection kernel.
The first memory 122 stores the protection initialization program and the protection kernel. The protection control program is stored on the hard disk 32 as an ordinary file.
The protection initialization program (Fig. 10) is stored in the ROM of the personal-computer peripheral devices, and obtains control at the stage when the BIOS ROM-5can system procedure is performed. As a result, the protection initialization program receives control before the os 24 is loaded. The protection initialization program identifies the user based on the entered pA~ _Ld and establishes a link between the sIcs-level request check program 135 and the original handler of the 13h BIOS interrupt.
The BIOS-level request check program 135 monitors the process of loading the OS 24 kernel into the working memory of the personal computer, and estAhli~h~G, after loading is completed, a link between the modular device driver-level request check program 137 and the original ~ WO96/01446 2 1 ~ 4~ 1 ~ r .,~

handler of the 13h modular device driver interrupt. Further flln~tinn1ng of the protection kernel is initiated by information ~ue~L~ from the application program 22, and depends on the type of request. The protection kernel s~rpl - the file-protection measures performed by the OS
24 kernel, and grants the protection control program the privilege of changing the status of files.
The purpose of the protection control program is to change the user pAI ,,~ld and file attributes. It is the only application program that has the privilege of changing the status of files or the user pA~ .Ld. To use these privileges, the protection control program sets its own activity flag when requesting a change of file attribute or user p~ d. The nctivity flag of the privileged program is checked by the OS kernel-level request check program 139.
The OS kernel-level request check program 139 checks for a match between the current request and the set of dangerous requests at the OS 24 kernel level ~nd ~~ Ls the servicing of dangerous requests by ret~rn;ng control to its C~LL ~ ;ng key progr~m 138 and by setting an error flag in the CPU 5S (Fig. 13E). The dangerous requests include requests to change file attributes in the absence of a protection control program activity flag and requests to write a track on a logic device. All other requests are interpreted as safe. If the request is a safe request, then the OS kernel-level request check program 139 does not prevent servicing of the request and calls the original handler of the 21h OS
interrupt; in the event of requests to create files with the extensions .EXE, .COM, .SYS, .OVL, .LIB, .DLL, or .BIN, the check program ascribes the attribute "read only".
The modular device driver-level request check program 137 checks for a match between the current request and the set of dangerous requests at the modular device driver 26 level. Among the dangerous requests are hard disk 32 formatting requests. Other dangerous requests are write requests which are not preceded by use of the OS 24, and write requests from sources other than the modular device driver 26.

wos6/0l~6 2 ~ ~ 4 2 1 5 r~

All other requests are interpreted as safe. If the reguest is one of the dangerous requests, the modular device driver-level request check program 137 p~ ..Ls servicing of the request by returning control to lts ~urL ~ ng key program 136 and by setting an error flag in the CPU 56 (Fig. 12B). Otherwise, the modular device driver-level request check program 137 does not prevent servicing of the request and calls the original handler of the 13h modular device driver interrupt.
The BIOS-level request check program checks 135 for a match between the current request and the set of dangerous requests at the BIOS level. The da..y~L~us requests include hard disk 32 formatting requests, write requests not pL~ded by use of the modular device driver 26, and write requests from sources other than the modular device driver 26. The BIOS-level request check program 135 prevents the servicing of dang~Lvus requests by retllrn;nq control to its ~OLL~ 7;ng key program 134 and by setting an error flag in the CPU 56 (Fig. llB). If the request is safe, the BIOS-level request check program 135 oalls the original handler of the 13h BIOS
interrupt.
A detailed description of the configuration and the functional organization of the file protection subsystem is given below.
The protection initialization program is stored in the memory 124 and receives control from the BIOS ROM-Scan ~ceduL~ be~ore the oS kernel is loaded. The protection initialization program identifies the personal computer user and est~hl ~ Ch~c a link between the BIOS-level request check program 135 and the original handler of the 13h BIOS
interrupt. After control is transferred from the BIOS ROM-Scan p.~ceduL~, the protection initialization program requests the p~ .Ld of the personal-computer user. After the password has been entered, the initialization program compares the signature of the p~
entered by the user with the p~ Ld signature in the memory 124. If the signatures do not match, the protection initialization program outputs a message that the use of the ~ WO96/01446 2 l 9 4 2 l 5 I~l/~

personal computer is f~rhi~Pn and stops the CPU 56. If the siy..atu.es match, the protection initialization program undertakes to establish a link between the BIOS-level request check program 135 and the original handler of the 13h BIOS
interrupt.
The protection initialization program (Fig. 10) estAhl;~hP~ a link between the BIOS-level request check program and the original handler of the 13h BIOS interrupt.
To do this, the protection initialization progr_m e~LLaeL~
from the interrupt vector table the address of the original handler of the 13h BIOS interrupt and places in the interrupt vector table the address of the key program in the memory 126, which coIL~D~ol.ds to the BIOS-level request check program 135.
The protection initialization program saves the address of the original handler of the 13h BIOS program interrupt in the memory 122, and the BIOS-level request check program uses the address to access the original handler of the 13h BIOS program interrupt. After the link is esf~hll~hPd, the initialization program transfers control to BIOS version 134 of the key program in the memory 126, which then switches the PPSM 120B
into the active mode and returns control to the BIOS RON-Scan ~L~I~:ej1UL~: .
The BIOS-level request check program 135 is resident in the memory 122 and receives control from the COLL-~1J~ 1ng version 134 of the key program. The key program 134 is resident in the memory 126, and switches the PPSM 120B into the passive mode (Fig. 14), after which it transfers control to the BIOS-level request check program 135. The BIOS-level request check program 135 performs the following functions:
when there is a request to read the partition table of the hard disk 32, the BIOS-level request check program 135 sets the flag of successful completion of the operation and transfers to the reguesting program the contents of the original partition table of the hard disk 32. The original partition table of the hard disk 32 is stored in the memory 122;

WO96~1446 2 1 9 4 2 T ~ rc~

monitors the process of loading the OS, and after it is completed establishes a link between the modular device driver-level request check program 137 and the original handler of the 13h modular device driver interrupt; and when the pPrsnn~l computer is in use, the BIOS-level request check program 135 monitors and ~r ~v~nLs the servicing of dangerous requests, then the OS 24 is being loaded, the BIOS-level request check program 135 i~nt;fi~q read requests using the 02h, OAh, or OEh fnnrti~nc of the 13h BIOS interrupt. The BIOS-level request check program checks 135 for the ~L~sence of two OS loading completed flags. The first OS 24 loading completed flag i5 the rl ~ , of the address of the original handler of the 21h interrupt in the interrupt vector table.
The second os 24 loading completed flag i8 the OS 24 initialization completed flag, which i5 returned by the 1200h function of the 2Fh OS program interrupt. In the absence of these OS 24 loading leted flags, the BIOS-level request check program 135 calls the original handler of the 13h BIOS
interrupt.
If the OS 24 loading completed flags are present, the BIOS-level request check program 135 places in the interrupt vector table the addres6 of the modular device driver-level request check program 137 and stores the address of the original handler of the 13h modular device driver interrupt in the memory 124. Then the BIOS-level request check program 135 copies the data ~t~rm;ning the current state of the OS 24 into a free area of the personal-computer memory, and, using the 5D06h function of the 21h OS interrupt, det~rm;n~q the address of the swappable data area (SDA).
After the address of said area is de~rmin~d, the BIOS-level reque6t check program 135 sets an OS 24 loading completed flag and restores the current oS 24 state using the copy of the data det~rmin;ng the current OS 24 state.
While the personal computer is in use, the BIOS-level request check program 135 establi6he6 a link with the modullr device driver 26 and prevents the servicing of W096~1446 l~
~ 21~4~1~

dangerous requests. When a hard disk 32 formatting request is identified, the check program 135 ~Lev~nL~ the servicing of the request by returning control to its ÇOLL--~UU~ ; ng key program 134 (which in turn returns control to the calling program, Fig. 14) and by setting an error flag in the CPU 56 (Fig. llB). When a write request i8 identified, the check program 135 checks the path used to access the hard disk controller 30. If the flag of modular device driver request check program 137 activity i8 not set and if the request source is not the modular device driver 26, the check program 135 pr ~v~llL~ the servicing of the requQst and returns control to the ~oLL~ ,rl;ng key program 134 (which in turn returns control to the calling program) and by setting an error flag in the CPU 56.
For the servicing of requests, the BIOS-level request check program 135 sets its own activity flag and calls the original handler of the 13h BIOS program interrupt. After the request is serviced and control is returned to the BIOS
level request check program 135, the program 135 removes its own activity flag and LLal.~reL~ control to its version 134 of the key program in the memory 126, which in turn switches the PPSN 120B into the active mode and returns control to the program requesting servicing at the UULL~ ; ng level.
The modular device driver-level request check program 137 is resident in the memory 122 and receives control from the cuLL~p~ ;ng version 136 of the key program. The key program 136 is resident in the memory 126 and switches the PPSM 120B into the passive mode, after which it transfers control to the modular device driver-level request check program 137. The modular device driver-level request check program 137 identifies hard disk 32 formatting requests and prevents servicing of the request by returning control to its CULL~ ;ng key program 136 (which in turn returns control to the calling program) and by setting an error flag in the CPU 56 (Fig. 12B). When a write request is i~nt;f;~, the check program 137 checks the path used to access the hard disk controller 30. If the flag of OS kernel-level request check WO96/01446 2 t 9 4 2 ~ 5 P~

3~
program 139 activity is not present, the check program 137 ~L~v~--Ls the servicing of the request and returns control to the CUL1-C~I ~ing key program 136 (which in turn returns control to the calling program) and sets an error flag in the CPU 56. In addition, the modular device driver level request check program 137 prevents the servicing of requests from sources other than the modular device driver 137 or the MS-WINDOWS operating environment.
For the servicing of requests, the modular device driver-level request check program 137 sets a flag of its own activity and calls the original handler of the 13h modular device driver program interrupt. After the request is serviced and control is returned to the modular device driver-level request check program 137, the program 137 removes the flag of its own activity and transfers control to its version 136 of the key program in the memory 126, which in turn 3witches the PPSN 120B into the active mode and returns control to the program reque6ting servicing at the COL ~ ; ng level.
m e ûS kernel-level request check program 139 is resident in the memory 122 and receives control from the CU11 ~L..,..~1;ng version 138 of the key program. The key program 138 is resident in the memory 126 and switches the PPSM 120B
into the passive mode, after which it transfers control to the os kernel-level reguest check program 139. The OS kernel-level request check program 139 checks the numher of the requested function of the 21h oS program interrupt and, if functions not related to ~CCDC~; ng the disk-storage suhsystem are identlfied, returns control to the original handler of the 21h OS program interrupt. For all other requests, the ûS
kernel-level request check program copies the values of the registers used by the original handler of the 21h 0S interrupt into the memory 122. Then the request check program 139 extracts from the ~warr~hl D data area (SDA) the value of the application program stack indicator and copies the application program stack to the memory area used by the protection P1O~L~ 120A. After the stack copy is made, the OS kernel--~ W0~6/01446 2 I q 4 2 1 5 P~11U---level request check program 139 checks the number of the requested function and identifies the 16h, 3Ch, 6Ch, 4301h, or 440Dh function of the 21h OS interrupt, each of these fllnrt;~nc involving a separate protection ~L~aeduL~. If the number of the requested function is not linked with any of the protection ploceduL~s, the OS kernel-level request check program 139 services the request immediately.
For the 16h function of the 21h OS interrupt, the OS
kernel-level request check program 139 dPtp~m;npc the format of the file control block (FCB). If the FCB has an extended format, the check program 139 d~tPrmlnpc the extension of the file being created. For files with extensions of .EXE, .COM, .SYS, .OVL, .LIB, .DLL, or BIN, the OS kernel-level request check program ascribes the attribute "Read only" by modifying the file attribute field in the FCB.
For the 3Ch and 6Ch functions, the OS kernel-level request check program 139 checks the format of the ASCIIZ line indicated in the call of said fllnrt;r,nc. If the ASCIIZ line format is not correct, i.e. , the ASCIIZ line does not contain a final zero, then the OS kernel-level request check program 139 returns control to the ~ulL-~L.~ ing key program 138 (which in turn returns control to the program creating the file) and set6 an error flag in the CPU 56 and installs the error code "Access Denied" (Fig. 13E). If the ASCIIZ line format i5 correct, the program 139 ~Ptprm;npc the extension of the file being created. For files with extPnci~nc of .EXE, .COM, .SYS, .OVL, .LIB, .DLL, or .BIN, the OS kernel-level request check program 139 places the attribute "Read Only" in the application protection stack storing the value of the CX
register. In addition, the OS kernel-level request check program 139 places said attribute in the copy of the value of the CX register used by the original handler of the 21h OS
interrupt.
For the 4301h function, the OS kernel-level request check program 139 checks for the activity flag of the protection control program having the privilege Of rh Inging file attributes. If the activity flag of the protection WO96/01446 2 1 942 ~ 5 P~

control program is absent, the OS kernel-level request check program 139 ~L.~ Ls the servicing of the request by transferring control to the COLL~ ; ng key program 138 (which in turn returns control to the program requesting the change in file attributes) and sets an error flag in the CPU
56 and installs the error code "Access Denied" (Fig 13E).
For the 440Dh function, the OS kernel-level request check program 139 i~nt;f;eR a request to write a track on a logic device that i5 a prototype of the hard disk 32, and prevents servicing of the request by transferring control to the COLL~ 1ng key program 138 (which in turn returns control to the program requesting to write a track) and sets an error flag in the CPU 56 and installs the error code "Access Denied" (Fig. 13E).
Requests from the OS kernel-level request check program 139 are serviced by changing the re turn address from the original handler of the 21h interrupt in the application program stack. The initial return address to the application program from the 21h interrupt is stored in the memory 122, and the return address to the oS kernel-level reguest check program 139 is installed in the application program stack.
Then the OS kernel-level request check program 139 stores the address of the current handler of the 13h modular device driver interrupt in the memory 122 used by the protection P1UYL~ 120A and installs the address of the modular device driver-level request check program 137 in the interrupt vector table. After the current address of the 13h interrupt handler is changed in the interrupt vector table, the OS kernel-level request check program 139 uses the 1600h function of the 2Fh program interrupt to check for activity of the MS-Windows operating environment. If the value returned to the AX
register i5 not 1600h, the check program 139 sets the MS-Windows activity flag. Then the oS kernel-level request check program 139 restores the register values ba6ed on the copy of the register values used by the original handler of the 21h oS
interrupt, sets its own activity flag, and returns control to the original handler of the 21h program interrupt. After the ~ WO96/01446 2 1 9 ~ 2 ~ 5 - ~

request is serviced by the original handler of the 21h OS
program interrupt and control is L~LuL..ed to the OS kernel-level request check program 139, the request check program 139 removes its own activity flag and the activity flag of the Windows operating environment and restores the current address Or the 13h modular device driver interrupt handler. Then the OS kernel-level request check program 139 transfers control to its version 136 Or the key program in the memory 126, which in turn switches the PPSM 120B into the active mode and transfers control to the application program 22.
The protection control program is stored on the hard disk 32 as an ordinary file. The purpose of the protection control program is to change file attributes and the personal-computer user p~c ..JLd. It is the only application program having the privilege of rh~nging the status of files or the u8er p~ Ld. An example of a protection control program is given in Fig. 17. In order to use the privilege of changing file status or the user pas_ JLd, the protection control program sets its own activity flag at the 4301h function of the 21h OS interrupt. A special interface known to the OS
kernel level request check program 139 is used to set the activity flag of the protection control program. The protection control program initi~li 7QC the registers with certain values, while the OS kernel-level request check program 139 handles the above-mentioned function and performs the nPcPcc~ry actions, ~PpPn~;ng on the specific request of the protection control program.
The operation of the hardware on the PPSM 120B will now be ~iiccllcced. As stated earlier, the PPSM 120B comprises a first memory 122, an address decoder 124, a second memory 126, a program discriminator 128, a p~UyL hle controller 130, and an AND gate 132. Each of these (except for the AND
gate 132) is connected to the computer's address bus 50, data bus 52 and control bus 54, accordingly.
The program discriminator 128 (Fig. 15) comprises an AND gate 166, a control-port decoder 168, an inverter 170, and two D-type flip-flops 172 and 174. The pLuyL hle controller 2~ 94215 130 (Fig. 16) comprises a port decoder 176, a mode reglster 178, and a buffer 180.
The PPSM 120B is reset by the RESET signal (Flgs. 15 and 16) from the system reset line. In particular, the RESET
signal is transmitted to the input of the inverter 170 (Fig.
15), the output of which is connected to the S-input of the D-type flip-flop 172 of the program discriminator 128; the RESET
signal is also transmitted to the R-input of the mode register 178 (Fig. 16) of the pL~yL hle controller 130. The RESET
signal to the inverter 170 sets the flip-flop 172, which in turn generatcs a low level logic signal from the inverted output Q of the flip-flop 172. This low level logic signal from the inverted output Q sets the S-input of the D-type flip-flop 174 which in turn generates a high level logic signal from direct output Q of the flip-flop 174. This high-level logic signal at the direct output Q of the flip-flop 154 of the program ~;crriminAtor 128 is transmitted through line 154 to the ~LUyL hle controller 130, thereby permitting installation of data input into the mode register 178 of the ~L~yL bl P controller 130.
As shown in Fig. 16, the system-RESET signal feeds into the R-input of the mode register 178 which resets the register 178, thereby causing the Q0 output of the mode register 178 to send a low-level logic signal to the A1 of the port decoder 176. At the Ql output (memory access control output 156 of the p.~- h1e controller 130) of the mode register 178 there is also a low-level logic signal, which is sent through line 160 to the second input 158 of the AND gate 132. The low-level logic signal on line 160 enables the second input 158 of the AND gate 132, thereby permitting the trAne~icQinn of select signals for the first memory 122 as requested by the address decoder 124 via line 140. The output 144 of AND gate 132 is thereby rnnnP~tpd to the select input 146 of the first memory 122; i.e., the first memory 122 becomes accessible to the CPU 56.
With the above-de5cribed combination of signals at the port-decoder 176 inputs, a high-level logic signal is ~ W096l01446 2 1 9 ~ 2 1 5 present at the second output (D1) of the decoder 176 and i8 sent to the input of the control input 182 of buffer 180.
This high-level signal at the control input 182 causes the output 162 of the bu~fer 180 to convert to a high ; -'~nre state which does not affect the state of the system ready line.
Thus, the initial state of the PPSM 120B is the neutral state, and the first memory 122 is read-~cQ~ihle.
In this regard, it should be noted that the RESET signal causes the CPU 56 to ~QtQrminP the personal-computer configuration and transfer control to ~LU~LU~S resident in the external-device ROM. Since the first memory 122 of the PPSM
120B occllpiQ~ the region of address space reserved for the external-device ROM, the protection pLUyLu~ 120A receive control before the OS 24 is loaded. As a result, the protection programs 120A can switch the PPSM 120B into the required state before the personal computer is in the ready state. In particular, the protection p~U~LU~ 120A can switch t_e PPSM 120B into the working state after the OS 24 is loaded. In addition, the protection p~ U~LU~ 120A can prevent access to the first memory 122 and can be hidden from the applications software 22 and the OS 24.
In order to change the state of the PPSM 120B, the CPU 56 must enter the code for the desired state into the mode register 178 of the p~UyL hle controller 130. The protection ~LU~LU~- 120A change the state of the PPSM 120B
using a coLL--p~ ;ng version of the key program stored in the second memory 126. During the extraction of key program codes, the second output of the address decoder 124 pLuduces a low-level logic signal, which is sent through line 152 to the select input 148 of the second memory 126. This signal also is transmitted to the control input 150 of the program discriminator 128. The other inputs of the program discriminator 128, which are r~nnQcted to the system control lines 54, receive signals specifying the type of bus cycle.
In particular, the MEMRD input (Fig. 15) of the AND
gate 166 receives pulsed signals which specify the read-memory WO96/01446 2 ~ 9 4 2 1 5 r~

bus cycles. If the REFR (refresh) input and AEN (address enable) input to the AND gate 166 do not comprise signals used for memory restoration and direct access to memory, then the output of the AND gate 166 will produce pul8ed signals which travel to the C-input of the flip-flop 172 and which latch the state of line 152. If there is a low-level logic signal at the D-input (i.e., at control input 150 of program discriminator 128) of the flip-flop 172, then each signal arriving at the C-input of the flip-flop 172 will produce at the inverse output Q of the flip-flop 172 a high-level signal which enables the operation of the flip-flop 174. If in that case, an active signal (IOW~ arrives at the control port decoder 168 from the system output line and i~ t_e address at the other inputs of the decoder 162 is the address of the control port, then the output of the control-port decoder 162 will be a pulsed signal indicating key program activity. This signal causes the direct output Q of the flip-flop 174 to have a low-level signal which is sent through line 154 to the first control input (pin V of the mode register 178 (Pig. 16) of the p~U~L hle controller 130, and this input ncts as the permit mode register 178 setup input.
If an active signal (i.e., a low-level signal is present on line 154) is present at the first control input of the uL~yr -hle controller 1~0, the state of the mode register 178 can be changed if another active signal (i.e., low-level slgnal IOW~ is present at the port decoder 176 from the system output line and if the other inputs to the decoder 176 have the address which is the address of the control port.
If this combination of signals is present at the permit mode register 178 setup input and at the port decoder 176 inputs, then the first output D0 of the port decoder 176 will produce a pulsed signal which sets the given information code at the outputs of the mode regi5ter 178.
If the code preventing access to the first memory 122 is entered into the mode register 178 then the Ql output (i.e., memory access control output 156) of the mode register 178 will produce a high-level signal, which is sent through ~ WO96/01446 2 ~ 9421 ~ Tcl/~

line 160 to the second input 158 of the AND gate 132. When that high-level signal is present, the AND gate 132 blocks the trAnF~;Cc~ion of the select signals for the first memory 122 from the address decoder 124, as ~;ccl~csed earlier. As a result, the first memory 122 becomes ;nACcD~q;hl~ to the CPU
56.
If the working-state code is entered into the mode register 178, then the first output Q0 (Fig. 15) of the mode register 178 will produce a high-level signal, which is sent to the first input A1 of the port decoder 176. The signal causes the port decoder 176 to verify the bus cycles for CPU
56 access to output devices. If the port decoder 176 receives an active signal from the system output line (i.e., IOW) and the address of the control register of the hard disk controller (not shown~ is at the other inputs of the decoder 176, then the Dl output of the port decoder 176 p~uduces a low-level signal which is sent to the control input 182 of the buffer 180. The low-level signal causes the output 162 of the buffer 180 to produce a low-level signal which is sent through line 164 to the system ready line. The low-level signal on the system ready line prevents the let;on of the current bus cycle and any further use of the personal computer.
The PPSM 120B should be an external card to be inserted into an PYrAncinn slot of the personal computer, and the porsnnAl computer should have an ISA (Industrial Standard Architecture) bus. The module memories 122 and 126 should occupy the address space for the external-device ROM. The ~10~L hl~ controller 130 should be set for the addres-c of the control register of the hard disk controller 30. With regard to hard disk controllers 30 which have an IDE
(Integrated Drive Electronics) interface, the PLUU,L h1e controller 130 should be set to the h~Y~c;r-l address 177 or lF7.
The protection P1UYL~ 120A are written in macroassembler language and are resident in the ROM of the computer's peripheral devices; fur~h~ ~, the P1UYL~O 120A

W096~1446 2 1 9~2 ~ 5 I_v~

is installed using the installation diskette supplied with the protection-program subsystem 120.
The protection y~vyLo~a 120A are d~a~gn~d to limit access to the personal _ ~r and to prevent the unintentional distortion of information in the computer's disk storage. In addition, the protection yLu~L~a 120A prevent the intrusion of y~O~L~n known as computer viruses and yL~ve~Ls the intentional distortion of information in the disk storage of the personal computer. A personal ~- ~r equipped with the protection p~vyLo~ 120A become resistant to the effects of known and unknown viruses. ~owever, a p~rsnn computer equipped with the protection yLv~L~s 120A do not support appl;c~At~nna which use direct access to the BIOS 28 or direct access to the hard disk controller 30.
Without further elaboration, the foregoing will so fully illustrate my invention that others may, by applying current or future knowledge, readily adopt the same for use under various conditions of service.

Claims

43 We claim:

1. A system (20) of protecting data stored on the hard disk (32) of a personal computer from inadvertent or intentional distortion, the personal computer having a central processing unit (56) and memory, a hard disk controller (30) having a command register, a hard disk (32) having sectors and a master boot record, an address bus (50), a data bus (52), a control bus (54), and peripheral devices coupled thereto, the memory comprising a basic input/output system (28), a modular device driver (26), an operating system kernel (24), an application program (22) and an interrupt vector table containing original interrupt handlers, characterized in that said system (20) comprises:
means for establishing a single access path to the hard disk controller (30) from the application program (22);
said means for establishing only one access path comprises means for monitoring requests (20A) by the application program (22) to the operating system kernel (24), the modular device driver (26) and the basic input/output system (28);
said means for establishing only one access path further comprises a programmable restriction module (20B) that permits the servicing of only those requests that utilize the operating system kernel (24), the modular device driver (26) and the basic input/output system (28) while precluding the servicing of any other requests; and said programmable restriction module (20B) being coupled to the personal computer address (50), data (52) and control (54) busses and being operable in a passive mode thereby allowing servicing of those requests utilizing the operating system kernel (24), the modular device driver (26) and the basic input/output system (28) or being operable in an active mode thereby preventing the servicing of any other requests.

2. The system of Claim 1 characterized in that said programmable restriction module (20B) comprises means for monitoring the bus cycles involving access by the central processing unit (56) to peripheral devices whenever said module (20B) is in said active mode.

3. The system of Claim 2 characterized in that said programmable restriction module (20B) comprises means for producing a blocking signal (64) in the bus cycle of data output to the command register of the hard disk controller (30) whenever said module (20B) is operating in said active mode and an attempt is made to access the hard disk controller(30).

4. The system of Claim 1 characterized in that said means for monitoring requests (20A) by the application program (22) controls said passive or active mode of said programmable restriction module (20B).

5. The system of Claim 4 characterized in that said means for monitoring requests (20A) by the application program (22) comprises means for switching said module (20B) into said passive mode before computer control is transferred to the basic input/output system (28) and for switching said module (20B) into said active mode after control is received from the basic input/output system (28).

6. The system of Claim 5 characterized in that said means for monitoring requests (20A) by the application program (22) further comprises means for requiring that both the basic input/output system (28) and the operating system kernel (24) must be used for access to the hard disk controller (30) in order to write information onto the hard disk (32).

7. The system of Claim 1 characterized in that said means for establishing only one access path further comprises means for initialization, said means for initialization being stored in the first sector of the hard disk (32) while the master boot record is transferred from the first sector to the ninth sector, said means for initialization being the first program to receive control once the operating system (24) is loaded.

8. The system of Claim 1 characterized in that said means for monitoring requests (20A) by the application program (22) further comprises a basic input/output system level request check program (58) having an address in the memory on the hard disk (32), said basic input/output system level request check program (58) comprises means for linking to the basic input/output system (28) by replacing the address of the original handler of the 13h basic input/output interrupt used by the modular device driver (26) with said address.

9. The system of Claim 8 characterized in that said basic input/output system level request check program (58) further comprises means for preventing the use of the basic input/output system (28) to format the hard disk (32), said means for preventing the use of the basic input/output system (28) to format the hard disk (32) identifying formatting requests and preventing the servicing of the formatting requests by returning control with an error flag.

10. The system of Claim 8 characterized in that said means for monitoring requests (20A) by the application program (22) further comprises a modular device driver-level request check program (60) having an address in the memory on the hard disk (32), said modular device driver-level request check program (60) comprises means for linking to the modular device driver by replacing the address of the original handler of the 13h interrupt in the interrupt vector table with said address of said modular device driver-level request check program (60), said modular device driver-level request check program (60) further comprises means for monitoring the use of the 13h modular device driver interrupt and for setting a modular device driver activity flag.

11. The system of Claim 10 characterized in that said basic input/output system-level request check program (58) comprises means for requiring the use of both the modular device driver and the basic input/output system to write information on the hard disk (32), said means for requiring the use of both the modular device driver (26) and the basic input/output system (28) verifies the presence of said modular device driver activity flag and prevents servicing of write requests in the absence of said flag by returning control with an error flag.

12. The system of Claim 10 characterized in that said modular device driver-level request check program (60) further comprises means for preventing the use of the modular device driver (26) to format the hard disk (32), said means for preventing the use of the modular device driver (26) to format the hard disk (32) identifying formatting requests and preventing the servicing of formatting requests by returning control with an error flag.

13. The system of Claim 8 characterized in that said means for monitoring requests (20A) by the application program (22) further comprises an operating system kernel-level request check program (62) having an address in the memory on the hard disk (32), said operating system kernel-level request check program (62) comprises means for linking to the operating system kernel (24) by removing from the operating system kernel the call of the 82h function of the 2Ah program interrupt and placing in the operating system kernel (24) the call of said operating system kernel-level request check program (62), said operating system kernel-level request check program (62) further comprises means for monitoring the use of the 21h operating system program interrupt and setting an operating system kernel activity flag.

14. The system of Claim 13 characterized in that said modular device driver-level request check program (60) further comprises means for requiring the use of both the operating system kernel (24) and the modular device driver (26) to write information on the hard disk (32), said means for requiring the use of both the operating system kernel (24) and the modular device driver (26) verifying the presence of said operating system kernel activity flag and preventing servicing of write requests in the absence of said flag by returning control with an error flag.

15. The system of Claim 13 characterized in that said operating system kernel-level request check program (62) further comprises means for preventing the use of the operating system kernel (24) to write a track on a logic device that is a prototype of the hard disk (32) and for preventing the servicing of requests to write a track on the logic device by returning control with an error flag.

16. The system of Claim 13 characterized in that said operating system kernel-level request check program (62) further comprises a means for changing the status of files created using the 16h function of the 21h operating system program interrupt and wherein the files have the extension ~BIN, ~COM, ~DLL, ~EXE, ~LIB, ~OVL or ~SYS, said means for changing the status of files created using the 16h function determining the extensions of such files and placing the attribute "READ ONLY" in the file control block.

17. The system of Claim 13 characterized in that said operating system kernel-level request check program (62) further comprises means for changing the status of files created using the 3Ch or 6Ch function of the 21h operating system program interrupt and wherein the files have the extension ~BIN, ~COM, ~DLL, ~EXE, ~LIB, ~OVL, or ~SYS, said means for changing the status of files created using the 3Ch or 6Ch function determining the extension of such files and placing the attribute "READ ONLY" in the stack of the program creating such files.

18. The system of Claim 13 characterized in that said operating system kernel-level request check program (62) further comprises means for monitoring the use of a protection control program having the privilege of using the operating system kernel (24) to change the status of files, the protection control program being privileged to use the 4301h function of the 21h operating system program (24) interrupt to change the attributes of a file and wherein the protection control program sets its own activity flag whenever there is a request to change the status of a file, the protection control program being enabled to use the 4301h function of the 21h operating system program interrupt by said operating system kernel-level request check program (62), said means for monitoring the use of the protection control program verifying the presence of the activity flag of the protection control program and for preventing the servicing of requests to change the status of files in the absence of the activity flag by returning control with an error flag.

19. A system (120) of protecting data stored on the hard disk (32) of a personal computer from inadvertent or intentional distortion, the personal computer having a central processing unit (56) and memory, a hard disk controller (30) having a command register, a hard disk (32), an address bus (50), a data bus (52), a control bus (54), and peripheral devices coupled thereto, the memory comprising a basic input/output system (28), a modular device driver (26), an operating system kernel(24), an application program (22) and an interrupt vector table containing original interrupt handlers, said system (120) comprising:
means for establishing a single access path to the hard disk controller (30) from the application program (22);
said means for establishing only one access path comprises means for monitoring requests (120A) by the application program (22) to the operating system kernel (24), the modular device driver (26) and the basic input/output system (28);
said means for establishing only one access path further comprises a protection-program support module (120B) that permits the servicing of only those requests that utilize the operating system kernel (24), the modular device driver (26) and the basic input/output system (28) while precluding the servicing of any other requests and wherein said means for monitoring requests (120A) by the application program (22) resides in a memory in said protection program support module (120B); and said protection program support module (120B) being coupled to the personal computer address (50), data (52) and control (54) busses and being operable in a neutral mode thereby allowing servicing of those requests utilizing the operating system kernel (24), the modular device driver (26) and the basic input/output system or being operable in a working mode thereby preventing the servicing of any other requests; and said protection-program support module (120B) comprising a first memory (122) and a second memory (126), said first memory (122) being inaccessible to the central processing unit (56) and said second memory (126) being accessible to the central processing unit (56).

20. The system of Claim 19 characterized in that said protection program support module (120B) comprises means for monitoring (128) the bus cycles involving access by the central processing unit to peripheral devices whenever said module is in said working mode.

21. The system of Claim 20 characterized in that said protection program support module comprises means for producing a blocking signal (130) in the bus cycle of data output to the command register of the hard disk controller (30) whenever said module is operating in said working mode and an attempt is made to access the hard disk controller (30).

22. The system of Claim 21 characterized in that said means for monitoring requests (120A) by the application (22) program comprises a basic input/output system level request check program (135), a modular device driver level request check program (137) and an operating system kernel-level request check program (139), said basic input/output system level request check program (135), said modular device driver level request check program (137) and said operating system kernel-level request check program (139) residing in said first memory (122).

23. The system of Claim 22 characterized in that means for monitoring requests (120A) by the application program (22) further comprises key programs (134, 136, 138) that reside in said second memory (126), said key programs (134, 136, 138) comprise means for switching said protection program support module (120B) into said neutral or working mode.

24. The system of Claim 23 characterized in that said basic input/output system level request check program (135) comprises means for transferring control to or receiving control from a first key program (134) having a first address in said second memory (126), said modular device driver level request check program (136) comprises means for transferring control to or receiving control from a second key program (136) having a second address in said second memory (126) and said operating system kernel-level request check program (138) comprises means for transferring control to or receiving control from a third key (138) program having a third address in said second memory (126).

25. The system of Claim 24 characterized in that said means for switching in said first key program (134) switches said module (120B) into said neutral mode before computer control is transferred to the basic input/output system (28) and for switching said module (120B) into said working mode after control is received from the basic input/output system (28).

26. The system of Claim 25 characterized in that said means for monitoring requests (120A) by the application (22) program further comprises means for requiring that both the basic input/output system (28) and the operating system kernel (24) must be used for access to the hard disk controller (30) in order to write information on the hard disk (32).

27. The system of Claim 26 characterized in that said basic input/output system level request check program (135) further comprises means for linking to the basic input/output system (28) by replacing the address of the original handler of the 13h basic input/output interrupt in the interrupt vector table with said first address of said first key program (134).

28. The system of Claim 27 characterized in that said modular device driver-level request check program (137) further comprises means for linking to the modular device driver (26) by replacing the address of the original handler of the 13h basic input/output interrupt of the modular device driver (26) with said second address of said second key program (136), said modular device driver-level request check program (137) further comprises means for monitoring the use of the 13h modular device driver interrupt and setting a modular device driver activity flag.

29. The system of Claim 28 characterized in that said operating system kernel-level request check program (139) further comprises means for linking to the operating system kernel (24) by removing from the operating system kernel (24) the call of the 82h function of the 2Ah program interrupt and placing in the operating system kernel (24) the call code for said third key program (138), said operating system kernel-level request check program (139) further comprises means for monitoring the use of the 21h operating system program interrupt and setting an operating system kernel activity flag.

30. The system of Claim 29 characterized in that said basic input/output system level request check program (139) further comprises means for monitoring queries at the 13h interrupt of the basic input/output system (28), and queries including hard disk formatting requests and attempts at recording on the hard disk (32) without the use of the basic input/output system (28).

31. The system of Claim 30 characterized in that said basic input/output system level request check program (135) further comprises means for preventing the use of the basic input/output system (28) to format the hard disk (32), said means for preventing use of the basic input/output system (28) to format the hard disk (32) identifying formatting requests and preventing the servicing of the formatting requests by returning control with an error flag via said first key program (134).

32. The system of Claim 31 characterized in that said basic input/output system-level request check program (135) further comprises means for requiring the use of both the modular device driver (26) and the basic input/output system (28) to write information on the hard disk (32), said means for requiring the use of both the modular device driver (26) and the basic input/output system (28) verifying the presence of said modular device driver activity flag and preventing servicing of write requests in the absence of said flag by returning control with an error flag via said first key program (134).

33. The system of Claim 32 characterized in that said modular device driver-level request check program (137) further comprises means for preventing the use of the modular device driver (26) to format the hard disk (32), said means for preventing the use of the modular device driver (26) to format the hard disk (32) identifying formatting requests and preventing the servicing of formatting requests by returning control with an error flag via said second key program (136).

34. The system of Claim 33 characterized in that said modular device driver-level request check program (137) further comprises means for requiring the use of both the operating system kernel (24) and the modular device driver (26) to write information on the hard disk (32), said means for requiring the use of both the operating system kernel (24) and the modular device driver (26) verifying the presence of said operating-system kernel-level activity flag and preventing servicing of write requests in the absence of said flag by returning control with an error flag via said second key program (136).

35. The system of claim 29 characterized in that said operating system kernel-level request check program (139) further comprises means for preventing the use of the operating system kernel (24) to write a track on a logic device that is a prototype of the hard disk (32) wherein said means for preventing denies servicing of requests to write a track on the logic device by returning control with an error flag via said third key program (138).

36. The system of Claim 35 characterized in that said operating system kernel-level request check program (139) further comprises means for changing the status of files created using the 16h function of the 21h operating system program interrupt and wherein the files have the extension ~BIN, ~COM, .DLL, ~EXE, ~LIB, ~OVL or ~SYS, said means for changing the status of files created using the 16h function determining the extensions of such files and placing the attribute "READ ONLY" in the file control block.

37. The system of Claim 36 characterized in that said operating system kernel-level request check program (139) further comprises means for changing the status of files created using the 3Ch or 6Ch function of the 21h operating system program interrupt and wherein the files have the extension ~BIN, ~COM, ~DLL, ~EXE, ~LIB, ~OVL, or ~SYS, said means for changing the status of files created using the 3Ch or 6Ch function determining the extension of such files and placing the attribute "READ ONLY" in the stack of the program creating such files.

38. The system of Claim 37 characterized in that said operating system kernel-level request check program (139) further comprises means for monitoring the use of a protection control program having the privilege of using the operating system kernel to change the status of files, the protection control program being privileged to use the 4301h function of the 21h operating system program interrupt to change the attributes of a file and wherein the protection control program sets its own activity flag whenever there is a request to change the status of a file, the protection control program being enabled to use the 4301h function of the 21h OS program interrupt by said operating system kernel-level request check program (139), said means for monitoring the use of a protection control program verifying the presence of the activity flag of the protection control program and preventing the servicing of requests to change the status of files in the absence of the activity flag by returning control with an error flag via said third key program (138).