000001
`
`Symantec 1021
`IPR of U.S. Pat. No. 7,757,298
`
`

`
`U.S. Pateilt
`
`Oct. 25, 1994
`
`Sheet 1 of 8
`
`5,359,659
`
`MADIMEMORY
`(RAM)
`
`26
`
`24
`
`
`
`KEYBOARD
`L ____ _ _' __________________________ __ ._ J
`
`OOOOO2
`
`000002
`
`

`
`U.S. Pateilt
`
`Oct. 25, 1994
`
`Sheet 2 of 8
`
`5,359,659
`
`30
`
`_
`
`ORIGINAL PROGRAM
`
`32
`
`MAKE ARMOR
`
`MODULE
`
`
`PROTECTED PROGRAM
`
`RUN ARMOR MODULE
`
`6
`
`68385;
`
`-1
`
`I L
`
`><— —
`
`
`
`/_"'—'A"—_\
`/ RUN OR\
`
`<
`
`ea " _("§_'-__)_/
`
`
`
`
`
`I
`70}/-————\\
`< DATA TABLE >‘_ _ _J
`\
`(FIG. 4)
`/
`\______/
`
`
`
`
`000003
`
`000003
`
`

`
`U.S. Patent
`
`Oct. 25, 1994
`
`Sheet 3 of s
`
`‘
`
`5,359,659
`
`39 '
`
`40
`
`START
`MAKE ARMOR
`
`VERIFY USER
`PASSWORD AND
`SERIAL NWBER
`
`’
`
`4,
`
`'
`
`wnmz BLOCK
`EXE I-EADER
`
`
`
`44
`
`43
`
`COM FLE
`
`
`
`42
`
`
`CONVERT TO EXE
`EXAME FLE - COM
`
`EXE. OVERLAY. ETC?
`(ADD EXE HEADER)
`
`
`
`
`COWRESS AND ENCRYPT
`DENTFY USER op'noNs _
`ORIGINAL PROGRAM
`
`
` PER SET USER OPTIONS
`SUPRESSION OF ENCJCOM’-.
`(mg.EXCLUUNG
`EXCLUSION OF PORTIONS. ETC.
`
`SPECIFIED PORTIONS)
`
`
`
`
`ENCJCONP. SLPPRESSED
`
`ADD RLN ARMOR CODE (68)
`
`47
`
`43
`
`49
`
`5°
`
`5
`
`54
`
`56
`
`5?
`
`ADD BLANK
`DATA TABLE (70)
`
`WRITE FRST ENCRYPTION
`SEED AM) OPTION DATA TO
`DATA TABLE (70)
`
`ENCRYPT DATA TABLE (70)
`USNG SECOND ENCRYPTION
`SEED (73)
`
`STORE SECOND ENCRYPTION
`
`L%%EEn"3~”§FBE¥%“¥‘£‘§Es
`
`ADJUST EXE PEADER TO CAUSE
`RH‘! ARMOR TO EXECUTE ON
`START OF PROTECTED PROGRAM
`
`CALCULATE CRC 8 Cl'ECKSlM ON
`PROTECTED PROGRAM (38) USNG
`REFERENCE VALUES AND KEYS
`
`STORE CRC AND Cl-ECKSLM
`RESLLTS N PREDETERIDED
`LOCATIONS N DATA TABLE
`
`END MAKE ARMOR
`
`OOOOO4
`
`F'G- 3
`
`000004
`
`

`
`U.S. Patent
`
`Oct. 25, 1994
`
`Sheet 4 of 8
`
`5,359,659
`
`
`
`
`
`mmofizM43002o<O...mxmsmz
`
`.mmo<m_._mxm._<z_o_mo
`
`
`
`<53oz<M58_2<mwoE
`
`
`
`8m._.n_>mozmoz<ommmmmmzoov
`
`B..¢n_>mozmmoommmmxmzooSzv
`
`
`
`<mm<._mm<4.cmE5m<._<zo_Eo
`
`
`85oz<zamxomzo20E.omoadxu
`.BEEozmmoommmummzooSE$53.3m._m<..._ao_2
`._<zoFn_o
`
`zo_.EEozu
`
`ommm
`
`Nb.an
`umozamxomzo
`
`army.are.
`
`
`
`mozmmmmmmmozmmmumm
`
`
`
`am5._<>_am5._<>
`
`¢nssmxomzo
`
`
`
`
`
`<mm<<._.<ozo_.Eo
`
`,/|Iu||||J\|nI.I|||\
`
`
`
`_ons_<mooEom5m.6E
`
`.S&.:o
`
`5%.
`
`
`
`on_2<mooE._<z_o_mo
`
`
`
`
`
`mmofi:m.5oos_04.0..mxm
`
`
`
`<29oz<mooos_<mooE
`
`
`
`<mm<.m_m<._bm_Eom<._<zo_Eo
`
`
`
`
`
`000005
`
`¢.0_n_
`
`
`
`
`
`
`
`<mm<<._.<om._m<Eoos_._<zo_Eo
`
`000005
`
`
`
`

`
`U.S. Pateilt
`
`Oct. 25, 1994
`
`Sheet 5 of 8
`
`5,359,659
`
`
`
`ENCRYPTEDCODE82
`
`ENCRYPTIONXORKEYS50
`
`
`
`ORIGINALPROGRAM30
`
`FIG.5
`
`<XOR
`
`000006
`
`000006
`
`

`
`U.S. Patent
`
`Oct. 25, 1994
`
`Sheet 6 of 8
`
`5,359,659
`
`ATTEMPT TO INVOKE
`PROTECTED PROGRAM (38) --
`RUN ARMOR STARTS
`
`
`
`89
`
`
`
`SEARCH FOR LATEST VERSION
`OF ARMOR (36)
`
`ARMOR NOT. FOUND
`
`VERIFY ARMOR CHECKSUM AND
`FILE ATTRIBUTES
`
`NO VALID
`VERSION FOUND
`
`
`
`
`NVAUD _ TRY
`EARLIER VERSION(S)
`
`29
`
`EXEC ARMOR AS A
`CHILD PROCESS
`(FIG. 7. bIk.I30)
`
`
`
`
`
`
`
`PASS CONTROL TO ORIGINAL
`PROGRAM (30)
`
`PROGRAMS TERMINATE --
`RETURN TO DOS
`
`FIG. 6
`
`000007
`
`ARMOR RETURNS
`ERROR
`
`
`
`
`ARMOR RETURNS
`(FROM FIG. 7. blk.
`I40): EXAMINE
`RETURN cons
`
`
`
`
`
`NO ERROR
`
`
`
`ERROR - DISPLAY ERROR
`MESSAGE AND EXIT
`
`98
`
`97
`
`
`
`99
`
`000007
`
`

`
`U.S. Patent
`
`Oct. 25, 1994
`
`Sheet 7 of 8
`
`5,359,659
`
`START ARMOR (CALl.ED
`FROM FIG. 6. blk. 94)
`
`INITIALIZE AND DISPLAY
`"PROTECTED BY
`NESSAGE
`
`
`
`POSSBLE
`CORRUPTION
` SCAN ENVROMENT (MAIN
`DETECTED
`MEMORY. BOOT SECTORS.
`
`SYSTEM FLES) FOR VRUS
`
`SIGNATURES
`POSSBLE
`CORRLPTION
`
`
`
`VERFY ARMOR coo:-: wrru
`NTERNAL crecxsum AND cm
`
`ACCESS AND DECRYPT
`DATA TABLE (70)
`
`Cl-ECK FOR "COMPANION"
`VIRUS FLES
`
`POSSBTLIEON
`coanup
`
`
`
`
`
`'00
`
`'0'
`
`I02
`
`,0‘,
`
`'06
`
`'°3
`
`PERFORM CFECKSLM AND CRC ON
`PROTECTED PROGRAM CODE (66):
`Cl-ECK AGANST VALUES N
`DATA TABLE (70)
`
`
`
`
`
`
`V5 PROGRAM CODE
`COMPRESSED AND
`ENCRYPTED?
`
`
`
`
`GENERATE ERROR
`RETLRN CODE
`TO BE PASSED
`TO RIM ARMOR
`
`
`
`
`
`
`DECONPRESS AND DECRYPT
`TO RESTORE ORIGNAL PROGRAM
`(30) NTO ITEMORY.
`OVERWRITNG ARMOR
`
`
`
`
`
`
`
`COPY PROGRAM
`CODE N70 MEMORY.
`OVERWRITNG ARMOR
`
`
`RETURN TO R114 ARMOR.
`PASSNG BACK
`
`
`
`RETlRN CODE
`RETURN CODE = N0 ERROR
`RETURN CODE = ERROR
`(FIG. 6. BLOCK 98)
`
`
`FIG. 7
`
`000008
`
`000008
`
`

`
`U.S. Pateilt
`
`Oct. 25, 1994
`
`Sheet 8 of 8
`
`5,359,659
`
`_t.ezm._A_V.o_m
`
`LOm>._.m_
`
`...om>E_
`
`A_V.o_.....
`
`mm.E_omno...
`
`
`
`fimwtovmmmE<zo_m
`
`mm:.z_on.no3.
`
`
`
`fimmtovmmmE<zo_m
`
`om.¢n_
`
`
`
`
`
`.._o3.c.m_m..:ovmumE<zo_mEmmc.z_o¢
`
`000009
`
`m.9...
`
`
`
`mm.mm.mm.
`
`Cmm.._.._9
`mm.E_on_no3.
`
`mmmE.<zo_mum
`
`000009
`
`
`
`
`
`

`
`1
`
`5,359,659
`
`2
`Calif.), and Turbo Debugger from Borland Interna-
`tional, Inc. (Scotts Valley, Ca1if.). Such an approach,
`however, requires that additional costly effort be ex-
`pended in the original design of the application program
`source code to incorporate these functions; further,
`software programs protected according to this ap-
`proach will not be able to detect later-created viruses
`without replacing the entire application program with’ a
`new version. Unlike the present invention, the prior art
`has never been able to secure existing executable appli-
`cation programs by directly coupling security routines
`to such program.
`SUMMARY OF THE INVENTION
`
`It is therefore an object of the present invention to
`provide a method to enhance the security of computer
`software, and reduce the software’s susceptibility to
`corruption and an apparatus capable of carrying out
`that method. Another object of this invention is to ver-
`ify the integrity of a computer program at the time it is
`executed. Yet another object is to allow producers of
`software to protect the integrity of their customers’
`computer systems by insuring that the products they
`distribute remain free of malicious contamination.
`These and other objects of the present invention are
`realized in the method described that enhances the secu-
`
`rity of an existing program by hardening the program
`such that the hardened version of the program automat-
`ically will detect infection by software viruses or any
`other unauthorized modification,
`tampering or alter-
`ation (collectively “corruption”).
`No modification to the original source code of the
`program to be protected, nor any recompilation or
`relinking,
`is required. Instead, the invention takes an
`existing, executable (object code) version of the pro-
`gram to be protected, and modifies that executable pro-
`gram code to produce a protected version of the pro-
`gram that is functionally equivalent to the original exe-
`cutable version, but that incorporates added security
`routines and protection. A preferred embodiment of the
`present invention also adds a formidable defense against
`unauthorized tampering, by compressing and encrypt-
`ing the protected program, rendering the program
`much more difficult to disassemble or infect.
`When a program that has been protected by the
`method of the present invention is executed, the incor-
`porated security routines execute first and automati-
`cally check for any corruption of the protected pro-
`gram. If no corruption is detected, the protected pro-
`gram is decompressed and decrypted, loaded into mem-
`ory in its original form, and executed as normal. These
`security precautions are entirely automatic and take
`only a few seconds.
`Thus, the protection provided by this invention is
`completely transparent to the end user, except that a
`program protected by this method will display a warn-
`ing when executed if any corruption is detected, and
`optionally may, whenever executed, display an an-
`nouncement of the fact that it has been protected by the
`method of the present invention, thus helping prevent
`the further contamination of any other software.
`This enhanced protection adds very little to a pro-
`gram’s normal loading time, and has no effect on run
`time performance, as the original executable program
`code is restored in memory. Disk storage space for the
`protected program often will be less than for the origi-
`nal program (particularly for larger programs), because
`
`METHOD FOR SECURING SOFTWARE AGAINST
`CORRUPTION BY COMPUTER VIRUSES
`
`FIELD on THE INVENTION
`
`This invention relates to computer system security,
`and more specifically a method and apparatus to en-
`hance the security and integrity of computer programs
`against corruption by software viruses or other means.
`BACKGROUND OF THE INVENTION
`
`A software or computer “virus” (sometimes also
`known as a worm or trojan) is a special piece of pro-
`gram code, usually created by a malicious programmer,
`that exists within (“infects”) an otherwise normal com-
`puter program. When an infected program is run, the
`viral code seeks out other programs within the com-
`puter and replicates itself. Infected programs can be
`anywhere in the system or even the operating system
`itself, and if undetected can have devastating effects,
`such as interfering with system operations or destruc-
`tion of data.
`It is difficult for producers of computer software to
`design and produce products that are adequately secure
`against infection by such software viruses. The inven-
`tion disclosed herein provides a method to “harden” or
`treat existing computer software programs such that the
`programs protect themselves against possible corrup-
`tion, including corruption through infection or other
`modification by software viruses.
`A number of methods have been devised that address
`the detection and prevention of infection by viruses.
`One approach is to use a separate program, external to
`the application programs being examined,
`to search
`through (“scan”) a computer’s memory and disk storage
`for the characteristic pattern (“signature”) of a known
`virus. Examples of products implementing this tech-
`nique include Virex from MicroCom, Inc. (Durham,
`N.C.) and Viruscan from MacAfee Associates (Santa
`Clara, Calif.). The effectiveness of this approach is lim-
`ited, however, by the fact that it depends on the com-
`puter user manually invoking the scanning software
`from time to time to scan the system. Computer users
`often fail to run such scans with sufficient frequency to
`prevent a virus from spreading during the “incubation”
`period between scans. Moreover, such scans often re-
`quire users to wait an unacceptable period of time while
`the entire system is scarmed.
`Another method to detect alteration of a program
`involves calculating a checksum value for the program
`being examined, and comparing it to the known check-
`sum value of the original, pristine version of the pro-
`gram. If the program being examined has been infected
`by a computer virus or otherwise altered, the checksum
`value of the program will have changed as well. Exam-
`ples of products implementing this method include Nor-
`ton AntiVirus from Symantec Corp. (Cupertino, Calif.),
`and System Monitor from Rosenthal Engineering (San
`Luis Obispo, Calif.). This approach suffers from similar
`limitations, in that it requires that the user remember to
`invoke the checksum software each time before running
`any of the user’s programs, and that the user remember
`to have a checksum calculated and stored for any new
`program when it is installed.
`Finally, some prior art application programs embody
`one or more of the foregoing methods as a built-in func-
`tion. Examples of such products include Virus Simula-
`tor from Rosenthal Engineering (San Luis Obispo,
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`000010
`
`000010
`
`

`
`3
`the program is compressed. Memory requirements for
`execution of a protected program are virtually the same
`as without protection, because after the security rou-
`tines are run, virtually all memory space used for the
`security routines is released for reuse.
`This invention offers a number of advantages over
`currently employed anti-virus methods. The protection
`offered by this invention is relatively transparent to the
`user, and is extremely fast because it only needs to ex-
`amine those programs in use as opposed to everything
`on a system or network. Moreover, unlike current anti-
`virus methods, protection is active each time a pro-
`tected program is run, without any need for operator or
`user intervention. The invention thus eliminates the
`“incubation” period between the time an infected pro-
`gram is run (and begins infecting other programs) and
`the time a user or ‘system administrator gets around (if
`ever) to running the next security check. Thus, when an
`infection is discovered using the method of this inven-
`tion, it will usually be early enough to prevent further
`contamination, and even to reveal the first generation
`source of the infection.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1—A schematic representation of a computer
`system for implementation of the preferred embodi-
`ment.
`
`FIG. 2-—A depiction of the overall structure of the
`preferred embodiment.
`FIG. 3—A diagram of the major logical steps carried
`out by the Make Armor module.
`FIG. 4—A diagram showing certain internal struc-
`tures of a target program, and a protected version of
`that program.
`FIG. 5—An illustration of the encryption process
`according to the preferred embodiment.
`FIG. 6—A diagram of the major logical steps carried
`out by the Run Armor module.
`FIG. 7-A diagram of the major logical steps carried
`out by the Armor module.
`FIG. 8—A diagram of tables for storing virus signa-
`tures.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`The present invention utilizes a computer system 10
`of conventional design, shown in schematic form in
`FIG. 1, having a CPU unit 20, random access main
`memory 22 (RAM), one or more input devices, prefera-
`bly including a keyboard 24, one or more output de-
`vices, preferably including a video display monitor 26,
`and one or more mass storage devices, preferably in-
`cluding a fixed hard disk drive 28. Included within main
`memory 22 is a buffer area 29, which is discussed fur-
`ther below.
`
`The preferred embodiment of the present invention
`herein described is implemented on a computer compat-
`ible with the “IBM-PC ®” (a trademark of Interna-
`tional Business Machines) family of computers running
`the “PC-DOS” or “MS-DOS” operating systems
`(trademarks of IBM and Microsoft Corporation, respec-
`tively). However, it will be apparent to those skilled in
`the art that the present invention is equally applicable to
`other types of computers (e.g., the Apple Macintosh ®)
`and operating systems (e.g., Microsoft Windows ®,
`UNIX ® or IBM OS/2 ®). Accordingly, the following
`illustrative description, insofar as it relates to specific
`
`10
`
`l5
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`5,359,659
`
`4
`requirements of the PC-DOS/MS-DOS systems, is not
`intended to limit applicant’s invention.
`Referring to FIG. 2, original program 30 is an other-
`wise normal application or systems program, stored on
`hard disk drive 28 (FIG. 1), that the user desires to
`secure. The preferred embodiment of this invention
`utilizes three principal modules for security enhance-
`ment: Make Armor 32, Run Armor 34 (comprised of
`Run Armor code 68 and data table 70), and Armor 36,
`all of which also may be stored on hard disk drive 28.
`Basically, to secure a program, the user first copies the
`original program 30 into a work area of disk drive 28.
`The user then invokes the Make Armor module 32,
`which operates as a stand-alone utility program. Make
`Armor processes original program 30 in various ways
`and outputs as a result protected program 38. Protected
`program 38 is functionally equivalent to original pro-
`gram 30, except that program 38 is coupled to security
`routines in Run Armor 34 and Armor 36, such that
`when program 38 is executed, Run Armor 34 will be
`automatically invoked and will in turn invoke Armor
`36.
`’
`The three modules Make Armor 32, Run Armor 34,
`and Armor 36, will now be described in detail.
`
`Make Armor
`
`We refer now to FIG. 3, which outlines the specific
`steps performed by Make Armor. We shall also refer to
`FIG. 4 in the following discussion, which depicts the
`internal structures of original program 30 and protected
`program 38.
`Make Armor 32 is stored on hard disk 28 as an ordi-
`
`nary program on the system 10 depicted in FIG. 1. In
`block 39, Make Armor 32 is invoked by the user in the
`ordinary fashion for his or her system (e.g., by entering
`its name on the command line, by clicking on the appro-
`priate choice with a mouse), and preferably begins by
`prompting the user to enter a unique serial number and
`a password, as indicated in block 40. In addition to
`providing authorization security,
`the serial number
`unique to this user also will be imprinted on every pro-
`gram processed by the user’s copy of Make Armor
`along with the date and BIOS identification of the com-
`puter being used to produce the hardened program.
`This creates a permanent record in subsequent copies of
`protected program 38 that allows the origins of such
`copies to be traced, and thus may discourage unautho-
`rized tampering with Make Armor 32 or programs
`protected by Make Armor.
`Referring to block 41 (FIG. 3), Make Armor 32 then
`writes a new EXE load module header 64 (FIG. 4), in
`standard form, to the output file which will constitute
`protected program 38 upon completion of Make Armor
`32. The layout and data included in a typical EXE file
`load module header 60 is shown in Table 1 below, and
`is described more fully in Duncan, Ray, Advanced MS-
`DOS Programming,
`ISBN 1-55615-157-8, pp. 22-36
`(1988), which is incorporated herein by this reference,
`and in other similar references readily available and
`familiar to those skilled in the art.
`
`TABLE 1
`
`Contents of a Typical .EXE
`Load Module Header
`CONTENTS
`4DH, SAI-I — This is the Link
`program’s signature to mark the
`file as a valid .EXE file.
`
`HEX OFFSET
`00-01
`
`00001 1
`
`000011
`
`

`
`5
`
`TABLE 1-continued
`
`5,359,659
`
`6
`gram 30 in accordance with user selected options.
`These user options are identified in block 45 by such
`means as reading command line switches provided by
`the user when Make Armor was invoked, prompting
`the user, or, in the preferred embodiment, by a combina-
`tion of these methods. The compressed and encrypted
`code 66 (FIG. 4) is stored in the new file created to
`contain the protected program 38. Compression re-
`duces the amount of disk space required by the pro-
`tected program; it also makes the original code gener-
`ally unrecognizable, and thus less vulnerable to reverse
`engineering and infection by viruses.
`Several well known compression techniques are suit-
`able for the preferred embodiment of this invention, as
`discussed in references such as.S_torer, J. A., Data Com-
`pression: Methods and Theory (Computer Science Press,
`1988). Detailed algorithm comparisons have been pub-
`lished in the computer science literature, and, as is ap-
`parent to those skilled in the art, the choice of a particu-
`lar technique involves tradeoffs among speed, compact-
`ness, and security. A Ziv-Lempel compression algo-
`rithm, as described (for example) in Williams, R., An
`Extremely Fast Ziv-Lempel Data Compression Algorithm,
`IEEE Data Compression Conference (1991), IEEE
`Catalog Number 91THO373-1, pp. 362-371, which is
`incorporated herein by this reference, is recommended
`for its optimum speed; however, the selection of alter-
`nate methods remains within the scope of the disclosed
`invention.
`
`As illustrated in FIG. 5, encryption is performed by
`exclusive-ORing (XORing) each word of the original
`program 30 with numeric keys 80 to produce encrypted
`words 82. Preferably, multiple keys are used, such that
`each word of the program is encrypted with a different
`key. This process is well known.
`A pseudo-random number generator preferably is
`employed to create the multiple keys 80 used to encrypt
`the original program. In the preferred embodiment, the
`pseudo-random number generator is seeded using a
`random clock count internal to the computer, and pro-
`duces a series of numbers, used as keys 80. The pseudo-
`random number generator further must have the prop-
`erty that use of the same seed always results in genera-
`tion of the same series of keys. Thus, the seed serves as
`the primary key for encryption and decryption, from
`which the multiple keys 80 are generated. Preferably, a
`new seed is used for each original program to be pro-
`tected, thereby further discouraging unauthorized dis-
`assembly and tampering. In addition, the pseudo-ran-
`dom number generator will preferably produce an ef-
`fectively non-repeating series of keys, i.e. a series in
`which repetition occurs only after a fairly large number
`of keys (e.g., on the order of the number of words in
`original program 30) have been generated from the
`same seed. Pseudo-random number generators having
`the forgoing properties are well known in the art. One
`representative example, suitable for use with the pre-
`ferred embodiment,
`is the algorithm referred to as
`URN13 and described in Dudewicz and Ralley, The
`Handbook of Random Number Generation and Testing,
`pp. 620-21 (1981), which is incorporated herein by this
`reference. Said reference provides model Assembler
`source code for implementing URN13, as shown in
`Table 2 below:
`
`Contents of a Typical .EXE
`Load Module Header
`CONTENTS
`HEX OFFSET
`
`02-03
`
`04-05
`
`06-07
`08-09
`
`0A-OB
`
`0C—0D
`
`OE-OF
`
`10-11
`
`12-13
`
`14-15
`
`16-17
`
`Length of image mod 512
`(remainder after dividing the
`load module image size by 512).
`Size of the file in 512-bye
`increments (pages), including the
`header.
`Number of relocation table items.
`Size of the header in 16-byte
`increments (paragraphs). This is
`used to locate the beginning of
`the load module in the file.
`Minimum number of 16-byte
`paragraphs required above the end
`of the loaded program.
`Maximum number of 16-byte
`paragraphs required above the end
`of the loaded program.
`Displacement in paragraphs of
`stack segment within load module.
`Offset to be in the SP register
`when the module is given control.
`Word checksum - negative sum of
`all the words in the file,
`ignoring overflow.
`Offset to be in the IP register
`when the module is given control.
`Displacement in paragraphs of
`code segment within load module.
`Displacement in bytes of the
`first relocation items within the
`file.
`lA—lB
`Overlay number (0 for resident
`
`part of the program)
`
`As discussed below, new EXE load module header 64
`later will be adjusted to cause the Run Armor code 68
`(FIG. 4) to be executed upon any attempt to execute
`protected program 38.
`In the case of the PC-DOS/MS-DOS operating sys-
`tem, executable original program 30 may be either in
`the form of a COM or an EXE file. A COM file is in the
`form of a memory image, while an EXE program file
`has an EXE load module header containing the EXE
`signature (i.e., the first two bytes are 4 Dh and 5 Ah or
`“MZ” in ASCII), and information regarding relocation,
`memory requirements, and other execution details. In
`block 42, Make Armor 32 examines original program 30
`to determine whether it is a COM memory image type
`file or an EXE file, by looking for the presence of the
`standard EXE file signature which would identify the
`file as an EXE file. If original program 30 is determined
`to be a COM file, Make Armor converts it to an EXE
`file in block 43 by the addition of an EXE load module
`header 60 (FIG. 4) in a conventional manner. It should
`be noted that this is in addition to the new EXE load
`module header 64, which previously was written to the
`file comprising protected program 38. Conversion to
`EXE format removes the 64K-byte file size limitation of
`COM files that might be exceeded upon the addition of
`Run Armor code 68 and data table 70 discussed below,
`and further eliminates the threat from a large number of
`viruses that will only attack COM program files and not
`the more complicated EXE files.
`Next, as indicated in block 44, Make Armor com-
`presses and encrypts original program 30. As discussed
`below, such compression or encryption optionally may
`be suppressed for all or some portions of original pro-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`60
`
`65
`
`000012
`
`000012
`
`

`
`5,359,659
`
`LOOP
`
`TABLE 2
`Random Number Generator Code
`URN 13
`START 0
`URN 13 (IX,X,NBATCH)
`USING t, 15
`USE REGISTER 15 As BASE REGISTER
`STM 14, 12, 12(13)
`STORE SAVE AREA
`L 14,0(1)
`LOAD ADDRESS OF IX INTO REG. 14
`L 6,4(l)
`‘LOAD ADDRESS OF x INTO REG. 6
`L 7,s(1)
`.LoAD ADDRESS OF NDIMX INTO REG. 7
`L 2,o(6)
`LOAD CONTENTS OF x INTO REG. 2
`L 3,o(7)
`LOAD CONTENTS OF NDIMX INTO REG. 3
`L 1,o(14)
`LOAD CONTENTS OF Ix INTO REG. 1
`M O,FACTOR
`X(I + 1) = A - X(I)MOD(2“32) IN REG. 1
`ST 1,o(14)
`IX = X(I + 1)
`SLDL 0,24
`SHII=T DBL. REG. 0-1 LEFT BY 24 BITS
`STM o,1,HOLD
`STORE DOUBLE PRECISION MANTISSA IN HOLD
`MVI HOLD, x'40'
`INSERT BIASED EXPONENT (TRUE EXPONENT ZERO)
`LD o,HOLD
`LOAD FLT PT REG. 0 WITH HOLD
`AD, o,zERo
`NORMALIZE REG. 0. IT Now CONTAINS X(I + 1)3
`STE 0,0(6)
`STORE INTO x(1)
`LA 6,-1(6)
`INCREMENT INDEX REGISTER
`BCT 3,LOOP
`BRANCH To TOP OF LOOP
`LM 14, 12, 12(13)
`RESTORE SAVE AREA
`BR 14
`BRANCH To RETURN ADDRESS
`DS 1D
`HOLD = ONE DOUBLE woRD
`HOLD
`DC D’0.0'
`zERo = DOUBLE PRECISION ZERO
`zERo
`FACTOR DC X’278DDE6D’
`THIS HEX FACTOR = 663608941 IN DECIMAL
`END
`
`Turning again to the Steps of compression and en-
`cryption referred to in block 44 (FIG. 3), these steps
`logically can be considered separate, i.e., all of the data
`from original program 30 can first be compressed in one
`pass and then encrypted in a second pass. However, this
`technique is inefficient, especially where, as is often the
`case, the size of original program 30 is sufficiently large
`that there is not sufficient room in main memory 22 to
`contain the entire Original program 30 and the code
`operating on it, thus necessitating multiple disk reads
`and writes of the same data. Thus, in the preferred
`embodiment both compression and encryption are per-
`formed on the data from original program 30 in a single
`pass to maximize the speed of the process. To accom-
`plish this, a block of data from original program 30 is
`read into a buffer (4,096 bytes long in the preferred
`embodiment) contained in buffer area 29 of main mem-
`ory 22 (FIG. 1). The data from that buffer is then
`treated according to the Ziv-Lempel compression algo-
`rithm discussed above. Each of the resulting series of
`compressed words is XORed against a numeric key 80
`generated by the pseudo-random number generator
`described above, thus encrypting the word, and then is
`written to the file constituting protected program 38.
`When the buffer is emptied, additional uncompressed
`and unencrypted data is read from original program 30
`and the process is repeated until all data from original
`program 30 has been compressed and encrypted (other
`than those portions specifically excluded by user re-
`quest as identified in block 45 of FIG. 3).
`Referring once again to FIGS. 3 and 4, Make Armor
`next adds the Run Armor code 68 (FIG. 4) to protected
`program 38, as shown in block 46 (FIG. 3). In the pre-
`ferred embodiment this is accomplished by appending a
`copy of the Run Armor code 68 to the end of the file
`constituting protected program 38, which already con-
`tains a new EXE load module header 64, compressed
`and encrypted program code 66, and possible optional
`ASCII text label 65 and modifiable data area 67. It is
`apparent to those skilled in the art, however, that the
`physical location of the Run Armor code 68 within
`protected program 38 (or even elsewhere within com-
`puter system 10) is immaterial so long as the new EXE
`load module header 64 is adjusted properly and any
`
`3
`
`30
`
`35
`
`45
`
`50
`
`55
`
`60
`
`65
`
`necessary instructions are supplied so as to cause the
`Run Armor code to execute upon any attempt to exe-
`cute protected program 38.
`In block 47 a blank copy of data table 70 (FIG. 4) is
`appended to protected program 38 following the Run
`Armor code 68. In the preferred embodiment, the loca-
`tion of the data table immediately following Run Armor
`code 68 allows Armor 36 (which is later invoked by
`Run Armor code 68, as discussed below) to locate the
`data table 70 within a protected program 38 file. This is
`possible because the Run Armor code 68 has a fixed
`signature and is not compressed or encrypted,
`thus
`enabling Armor 36 to Search protected program 38 to
`locate the end of Run Armor code 68, which marks the
`beginning of data table 70. Other physical locations for
`data table 70 within protected program 30 (or elsewhere
`within computer system 10) are possible, so long as an
`appropriate marker or other mechanism is provided to
`enable Armor 36 to locate data table 70.
`Referring now to block 48 of FIG. 3, in the preferred
`embodiment, the random number generator seed used
`to encrypt the original program code 66 (as described
`above) is stored in the data table 70 (FIG. 4) at a prede-
`termined first encryption seed location 72, so that the
`multiple encryption keys 80 may be reproduced later by
`Armor 36 in order to decrypt the encrypted original
`program. User option data and other information neces-
`sary for Armor 36 to properly verify and reconstruct
`protected program 38, such as the location of any op-
`tional modifiable data area 67, whether compression or
`encryption has been Suppressed, etc., also are written to
`data table 70 in option data area 78.
`AS shown in block 49 (FIG. 3), preferably the data
`table 70 then is itself encrypted, using a second random
`seed based on the internal clock of the computer system
`10 and using the encryption method described earlier.
`In block 50 this second encryption seed is the stored
`within the data table 70 (FIG. 4) at a predetermined
`location 73 that is excluded from the encryption/de-
`cryption process. In this way, the Armor module 36 can
`later access and use the non-encrypted second encryp-
`tion seed 73 to decrypt the data table 70, and thereby
`
`000013
`
`000013
`
`

`
`9
`obtain the first encryption seed 72 in order to decrypt
`the original program code 66.
`In block 52 of FIG.‘ 3, the necessary adjustments (as
`apparent to one skilled in the art) are made to the new
`EXE load module header 64 so as to cause the Run
`Armor code 68 to execute upon any attempt to execute
`protected program 38. Run Armor should preferably be
`compiled as a COM file, so that it contains no relocation
`items and so that all of its data code and stack are within
`the same segment. The EXE header entries described
`earlier (see Table 1) are set for Run Armor as if the
`program were a COM file: the number of relocation
`items (bytes 6 & 7) are set to zero; displacement of the
`stack segment (bytes OE & OF) point to the end of the
`segment; and the IP segment and offset (bytes 14, 15 &
`16, 17) are set to the starting point of Run Armor so that
`execution of protected program 38 will begin there.
`Finally, after all adjustments have been made to pro-
`tected program 38, Make Armor calculates a reference
`checksum value and a reference cyclic redundancy
`check (“CRC”) value for the protected program in
`block 54, and stores them to the data table 70 (FIG. 4)
`in predetermined locations 74, 75, as shown in block 56
`(FIG. 3). A reference checksum value is calculated by
`summing all of the bytes in the original program. A
`reference CRC value is calculated by XORing the bytes
`of the original program with each other, in sequential
`order. As described further below, the point of comput-
`ing and saving these reference values is so that the
`Armor module 36 can verify the integrity of a protected
`program at execution time by performing the same
`checksum and CRC calculations on the file containing
`the program to be executed. If the values computed at
`execution time differ from the stored reference values,
`that indicates to Armor that the protected program file
`has been somehow modified, indicating possible corrup-
`tion. As is obvious to one skilled in the art, the check-
`sum and CRC results should not themselves be part of
`the checksum and CRC calculations. Thus, locations 74
`and 75 where the reference values are stored must be
`excluded from the checksum or CRC calculations per-
`formed by either Make Armor or Armor.
`In the preferred embodiment, a number of variant
`methods are used to calculate the checksum and CRC
`reference values. For example, one or more keys (cre-
`ated using random number generation means as de-
`scribed earlier) may be added to the reference check-
`sum value; one or more such keys may be inserted at the
`beginning of the XOR sequence; and one or more such
`keys may be used to determine the number of positions
`that each byte from the original program should be
`rotated before it is used in the checksum or CRC calcu-
`lation. The specific choice of variants utilized is immate-
`rial; the important point is that by employing a plurality
`of different checksum and CRC calculation methods,
`the possibility of undetected tampering is minimized. In
`any case, during the steps shown in block 56 (FIG. 3),
`any such additional keys also are stored in the data table
`70 at predetermined locations 76 and 77 so that they
`may be recovered and used later by Armor module 36.
`Because the CRC and checksum references values
`and keys, 74, 75, 76 and 77, are written after the encryp-
`tion of data table 70 has been completed in block 49,
`these elements are not stored in encrypted form and
`thus should be exempted from the decryption of the
`data table by Armor 36.
`_
`Not every original program 30 is suitable for the
`compression and encryption st