United States Patent [191
`Chambers
`
`US005398196A
`[11]
`Patent Number:
`[45] Date of Patent:
`
`5,398,196
`Mar. 14, 1995
`
`[54] METHOD AND APPARATUS FOR
`DETECHQN OF COMPUTER VIRUSES
`
`[76] Inventor: David A. Chambers, 3655 Eastwood
`C1r., Santa Clara, Calif. 95054
`[21] Appl' No‘: 99,368
`[22] Filed:
`JuL 29, 1993
`
`[51] Int. Cl.6 ............................................ .. G06F 15/20
`52 US. Cl. .................................. .. 364 580' 364 550-
`[
`1
`364/578_ 364/579’, 395//5O6
`[58] Field Of Search ............. .. 364/550 578 579 580
`364/286.4; 371/162, 19; 395/500
`References Cited
`
`[56]
`
`U'S' PATENT DOCUMENTS
`4,080,650 3/1978 Beckett ............................. .. 395/500
`4,773,023 9/1983 Tallman --
`5'086’5O2 2/1992 Malmm "
`128ml "
`
`371/19 X
`
`5’233’ 611 8/1993
`' """"" "
`’
`’
`FOREIGN PATENT DOCUMENTS
`9006430 4/1991 Brazil
`1057534 V1992 China
`304033 2/1939 European pat Off_ ‘
`510244 10/1992 European Pat Off, _
`514815 11/1992 European Pat. Off. .
`2629231 9/ 1989 France .
`2632747 12/1989 France .
`3736760 5/1989 Germany .
`461879 4/1990 Sweden .
`2231418 11/1990 United Kingdom .
`
`2246901 2/1992 United Kingdom .
`2253511 9/1992 United Kingdom .
`9113403 9/1991 WIPO .
`9221087 11/1992 WIPO .
`OTHER PUBLICATIONS
`Bowen, T., “Central Point Tool Unearths New Vi
`fuses,” P.C. Week, May 31, 1993, pp. 41-42.
`Excerpts From On-line Documentation for FProt Pro
`gram, 1994_
`.
`Primary Examiner-Edward R. Cos1mano
`A’wmey’ Agent’ 0’ Fi’m—T°wnsend and Townsend
`Khmme and crew
`Cr
`ABS
`[57]
`A behavior analyzing antivirus program detects viral
`infection of a target program by emulating the execu
`tion of the target program and analyzing the emulated
`execution to detect viral behavior. The antivirus moni
`tor program contains both variables corresponding to
`the CPU’s registers and emulation procedures corre
`sponding to the CPU’s instructions. The target program
`is loaded into memory and its execution is emulated by
`the antivirus monitor program. Intelligent procedures
`contained in the monitor program are given control
`between every instruction emulated so as to detect aber
`rant or dangerous behavior in the target program in
`which case the danger of a viral presence is flagged and
`emulation is terminated.
`
`27 Claims’ 9 Drawing Sheets
`_
`_
`Micro?che Appendix Included
`(2 Micro?che, 167 Pages)
`
`[500
`L0“! TARGET PROGRAI
`IIITO NEW
`1
`IIITMLIZE
`EIULATED REGISTERS
`
`4510
`
`'520
`
`u
`man 111
`POIITED T0 81 THE
`EIllATED IISTIWTIOI
`POIITER m ICREEIT
`EILATED INSTRUCTION
`POIITER BY SIZE OF
`
`/530
`CHECK ACCESS TO HENRY
`
`540
`
`550
`
`M01 ACCESS TO HOCE
`
`ONE“ UFEMTM
`SYSTEI Elm POIIUS)
`
`000001
`
`Symantec 1035
`IPR2015-01892
`Symantec v. Finjan
`
`

`
`Patent
`
`Mar. 14, 1995
`
`Sheet 1 of 9
`
`5,398,196
`
`[40
`
`[I0
`
`[50
`
`/L—__J\\,___.,/ "3&5"
`
`T
`
`T
`
`OPERATING svsrsu L20
`
`MEIuRY
`
`Q:> CPU
`
`,30
`
`msx STORAGE C:>
`
`FIG: IA.
`(PRIOR ART)
`
`000002
`
`

`
`US. Patent
`
`Mar. 14, 1995
`
`Sheet 2 of 9
`
`5,398,196
`
`IO
`
`OPERATING svsm CID
`
`,20
`
`MEMORY
`
`(
`
`>
`
`CPU
`
`MONITOR
`PROGRAM
`
`TARGET
`PROGRAM
`
`[so
`DISK STORAGE <I>
`
`FIG: l8.
`
`000003
`
`

`
`US. Patent
`
`Mar. 14, 1995
`
`Sheet 3 of 9
`
`5,398,196
`
`men usnonv
`
`non
`
`men nsnom
`
`non
`
`[/70
`
`/70
`
`FREE
`SPACE
`
`FREE
`smc:
`
`men
`PROGRAM
`
`omznmuc ,40
`svsrsn
`Low MEMORY
`
`F762 24.
`(PRIOR ART)
`
`PROGRAM
`
`MONITOR
`"5°
`PROGRAM
`orsamne ,40
`svsm
`Low uznomr
`
`F162 28
`
`000004
`
`

`
`US. Patent
`
`Mar. 14, 1995
`
`Sheet 4 0f 9
`
`5,398,196
`
`ISIO
`
`,320
`
`r330
`
`I340
`
`FLAGS
`
`up
`
`sP
`
`lP
`
`(DC/3M8
`cnrng
`
`FIG 3.
`(PRIOR ART)
`
`400
`
`BEGIN
`
`ARE
`NE ALREADY
`INSTALLED IN
`NENORY?
`
`GET CURRENT OPERATING
`SYSTEM sum POINT
`(INTERRUPT VECTOR am)
`AND SAVE n ron
`STEP 450A
`
`430
`’
`SET NEN OPERATING
`SYSTEM ENTRY POINT
`(SET IT TO STEP 400A)
`
`PASS CONTROL TO
`HOST PROSRAN
`
`F76. 4A.
`(PRIOR um
`
`000005
`
`

`
`US. Patent
`
`Mar. 14, 1995
`
`Sheet 5 of 9
`
`5,398,196
`
`,500
`LOAD TARGET PROGRAN
`INTO IIENDRY
`
`INITIALIZE
`EII ULATED REGISTERS
`
`52°
`
`rncn msmucnou
`POINTEO T0 BY ms
`mum msmucnou
`POINTER AND mcnsum
`EIIULATED INSTRUGTIOII
`POINTER BY SIZE OF
`INSTRUCTION
`/ 53D
`I
`GIIEGK ACCESS TO IIEIIORY
`ISEE FIG. 6)
`
`_
`
`,540
`IcuEcx AccEss TO moczomss
`(SEE FIG. 1)
`{550
`I
`GIIEGK OPERATING
`SYSTEII ENTRY POINTIS)
`(SEE FIG. 8)
`
`IIAS TARGET
`TERIIINATED ‘I
`
`TERMINATE
`summon
`
`FIG: 5.
`
`>- THE
`A FILE NANE
`ASSOCIATED WITH THIS
`DOS REOUEST
`
`,410
`WRITE TO THE FILE
`(INFEGT IT) IF IT IS NOT
`ALREADY INFECTED
`
`EXIT
`(PASS GOIITROL TO
`PREVIOUS INTERRUPT
`2| HANDLER)
`
`FIG 4B.
`(PRIOR ART)
`
`000006
`
`

`
`US. Patent
`
`Mar. 14, 1995
`
`Sheet 6 of 9
`
`5,398,196
`
`600
`
`(FROM STEP 52D)
`BECIN
`
`DOES THIS
`INSTRUCTION ACCESS
`MEMORY?
`
`IS THIS
`MEMORY ADDRESS
`SELECTED TO BE
`REMAPPED?
`
`CHANCE MEMORY ADDRESS
`TO REFLECT MEN ADDRESS
`(AND COPY CONTENTS OF
`ORIGINAL MEMORY TO NEYI
`MEMORY IF NECESSARY)
`
`/ 640
`I
`LOS ACCESS TO
`CRITICAL MEMORY
`AREA (FOR LATER
`ANALYSIS ETC.)
`
`650
`
`END
`(GO TO STEP 540
`
`FIG‘. 6.
`
`000007
`
`

`
`US. Patent
`
`Mar. 14, 1995
`
`Sheet 7 of9
`
`5,398,196
`
`INSTRUCTION POINTER
`POINT TO A CONTROLLED
`
`N0
`
`A
`
`NOTE ATTENPT T0
`ACCESS A CONTROLLED
`PROCEDURE
`
`ENULATED AS IS
`
`/T4O
`PERFORM SPECIAL '
`CASE ENULATION OF
`INSTRUCTION
`
`K750
`'
`PERFORN STANDARD
`ENULATION OF
`INSTRUCTION
`
`(‘TOO
`
`I
`END
`(GO TO STEP 550)
`
`FIG. 7.
`
`000008
`
`

`
`US. Patent
`
`Mar. 14, 1995
`
`Sheet 8 0f 9
`
`5,398,196
`
`BEGIN
`(SEE STEP 830)
`
`OPEN
`GUINEA PIG FILE
`
`CLOSE
`GUINEA PIG FILE
`
`920
`
`EX EGUTE
`GUINEA PIG FILE
`
`r960
`LOG umwmomzss
`Access T0 GUINEA m.
`(OPTIONALLY PASS
`CONTROL romunz I0)
`
`r970
`
`IRET
`
`FIG. .9.
`
`I LOG AND FLAG AN
`OPERATING SYSTEII
`ENTRY POINTHIIAS
`r830
`INSTRUETITITIUIPTILIT¥ER
`
`AND FLAGS (ON
`EIIULATED STACK)
`
`,840
`INITIALIZE ENULATEO
`INSTRUCTION POINTER
`NIT II ADDRESS OF
`INTERRUPT HANDLER
`TESTING ROUTINE
`(SEE FIG. 9)
`
`850
`m /
`
`(GO TO STEP 560)
`
`F761 8
`
`000009
`
`

`
`US. Patent
`
`Mar. 14, 1995
`
`Sheet 9 0f 9
`
`5,398,196
`
`r- IOIO
`
`/-I020
`
`I
`SAVE THE STATE OF THE
`GURRENT TARGET PROGRAN
`AND LOAD TIIE GUINEA PIG
`FILE FOR ENULATIOII AS
`THE NEW TARGET PROGRAN
`(GO TO STEP 500)
`I
`IFROII STEP 5T0)
`TARGET PROGRAN
`(GUINEA PIG FILE)
`IIAS TERNINATED
`
`/ I050
`LOG THAT (INITIAL)
`TARGET PROGRAM
`CONTAINS A VIRUS
`
`END
`(GO TO STEP 970)
`
`F161 [0.
`
`000010
`
`

`
`5,398,196
`2
`the computer virus. Such requests would generally be
`functions which the virus required to be performed in
`order to replicate or to destroy its host, i.e., “Write to a
`?le”, “Erase a ?le”, “Format a disk” etc. By intercept
`ing these requests, the computer operator/ user could be
`informed that a potentially dangerous function was
`about to be performed. Control could be halted or con
`tinued as necessary. Some antivirus programs actually
`modify the instructions of the discovered virus program
`and make them inoperable so as to “kill” them.
`The behavior interceptor method of virus detection
`has several drawbacks. The ?rst problem is that it relies
`entirely on user input and decision making-when poten
`tially dangerous behavior is detected. This places a
`great burden on the user, for it is often very dif?cult to
`determine whether the ?agged behavior is part of the
`normal operation of the program being executed. For
`example, disk optimizing programs routinely reformat
`hard disks to improve the interleave value. In response
`to a warning message, a user might suspect that their
`disk optimizer was infected with a virus (when in fact it
`was not) and halt program execution. Or, worse yet, if
`the user knows that such behavior is part of the normal
`operation of a disk optimizer program, they would
`likely allow the format to continue uninterrupted,
`which would be disastrous if the program were actually
`infected.
`A second problem with behavior interceptor antivi
`rus programs is that computer virus technology has
`advanced to such a state that some computer viruses are
`able to bypass the interception points used by the antivi
`rus. The virus can then make operating system function
`requests that are never intercepted by the antivirus, thus
`avoiding detection.
`A third problem with behavior interceptor antivirus
`programs is that by allowing the virus to execute, the
`virus has an opportunity to locate and identify the anti
`virus program in computer memory. Once the antivirus
`program is located, the virus can modify the antiviru
`s—-rendering it completely ineffective in exactly the
`same manner that antivirus programs locate and modify
`virus programs to render them ineffective.
`A fourth and very signi?cant problem with behavior
`interceptor antivirus programs is that there are no low
`level operating system function requests employed by
`computer viruses that are not also used by any of thou
`sands of nonvirus programs. At an instruction by in
`struction level, or at a function-call by function-call
`level, a computer virus performs the same operations as
`legitimate computer programs. In other words, the
`closer a computer virus is examined, the less distinguish
`able it becomes from any other computer program.
`
`35
`
`45
`
`1
`
`METHOD AND APPARATUS FOR DETECTION
`OF COMPUTER VIRUSES
`
`SOURCE CODE APPENDIX
`A micro?che appendix (consisting of 2 sheets and a
`total of 167 frames) of assembly language source code
`for a preferred embodiment (@1993 David Chambers)
`is ?led herewith. A portion of the disclosure of this
`patent document contains material which is subject to
`copyright protection. The copyright owner has no ob
`jection to the facsimile reproduction by anyone of the
`patent document or the patent disclosure, as it appears
`in the Patent and Trademark Office patent ?le or re
`cords, but otherwise reserves all copyright rights what
`soever.
`
`15
`
`BACKGROUND OF THE INVENTION
`The present invention relates generally to a method
`and apparatus for emulating the execution of a program
`on a computer system. In particular, the present inven
`tion relates to monitoring program behavior to detect
`and terminate harmful or dangerous behavior in a pro
`gram. More particularly, the present invention relates
`25
`to monitoring program behavior to detect computer
`viruses.
`In recent years, the proliferation of “computer vi
`ruses” (generally designed by rogue programmers ei
`ther maliciously or as “pranks”) has become an increas
`30
`ingly signi?cant problem for the owners and users of
`computer systems. True computer viruses vary, but
`they share the general characteristic that they comprise
`executable computer code capable of replicating itself
`by attachment to and modi?cation of standard com
`puter ?les. Such ?les are then considered “infected”.
`On most computer systems, viruses are limited to infect
`ing program applications. When the application is exe
`cuted, the virus can then replicate and attach copies to
`further application ?les. Typically, viruses also engage
`in other forms of behavior‘ that are considered undesir
`able, such as re-formatting a hard disk.
`Often grouped with true computer viruses are some
`other types of malevolent computer programs: worms
`and trojan horses. Worms do not infect other applica
`tions but merely replicate, either in memory or in other
`storage media. The harmful effect of worms is generally
`to reduce system performance. Worms are of concern
`for large multiuser computer systems, but are generally
`not of concern for personal computers. Trojan horses
`are programs that masquerade as useful programs or
`utilities; they generally run only once and have a harm
`ful effect (such as destroying or damaging the computer
`system data storage). Trojan horses do not replicate,
`and after being run once by a user, the user is usually
`alerted to the harmful behavior and will not run the
`trojan horse again.
`In response to the proliferation of computer viruses, a
`variety of “antivirus” methodologies and programs
`have been developed to detect the presence of infected
`?les. These antivirus programs can be generally catego
`rized into groups: behavior interceptors, signature scan
`ners, and checksum monitors.
`'
`
`55
`
`60
`
`BEHAVIOR INTERCEPTORS
`The earliest antivirus programs were generally of the
`behavior interceptor type: they would allow a virus
`program to execute in memory but would intercept
`strategic operating system function requests made by
`
`65
`
`SIGNATURE SCANNERS
`The next generation of antivirus technology, signa
`ture scanners, answered the problem of over-reliance on
`user interaction as well as the problem of allowing the
`virus to execute. A signature scanner operates by know
`ing exactly what a target virus program code looks like
`(“signature” code) and then scanning for these program
`codes in any programs requested to be executed or
`otherwise requested to be scanned. As long as the signa
`ture codes were suf?ciently long enough so as not to be
`confused with another program’s code, then positive
`identi?cation was virtually guaranteed and the request
`to execute could be stopped before execution ever be
`gan. The primary problem with this technique is that it
`
`000011
`
`

`
`5,398,196
`3
`requires the antivirus developer to have previously
`collected and analyzed the target viruses, and included
`the signature codes in the antivirus program. The antivi
`rus program thus relies on an extensive virus signature
`library, for there are currently several thousand known
`IBM PC viruses and several new viruses appear each
`day. Any new viruses appearing after the antivirus pro
`gram was developed are not included in the library of
`program codes for which the antivirus can scan. Signa
`ture scanning antivirus programs therefore require fre
`quent updates to keep them current with the increasing
`number of viruses. If the antivirus developer is lax in
`providing updates, or the user is lax in obtaining and
`employing available updates, a signature scanning anti
`virus program can rapidly lose its effectiveness.
`
`10
`
`4
`program. The monitor program also has means for emu
`lating the execution of the modi?ed dummy program
`after the emulation of the target program is complete. If
`the modi?ed dummy program is determined to have
`modi?ed functionality, the original target program is
`?agged as possessing viral behavior. In one particular
`embodiment according to this aspect of the invention, a
`?rst dummy program is known to not possess the ability
`to modify another ?le. If after modi?cation by the tar
`get program the ?rst dummy program is emulated and
`found to modify a second dummy program, then the
`original target program is ?agged as virus infected, for
`having “infected” the ?rst dummy ?le with aberrant
`behavior.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1B is a block diagram illustrating the primary
`components of a computer system executing a target
`program in a standard manner.
`FIG. 1B is a block diagram illustrating the primary
`components of a computer system executing a target
`program according to the present invention.
`FIGS. 2A and 2B are diagrams illustrating memory
`maps of the computer systems of FIGS. 1A and 1B,
`respectively.
`FIG. 3 is a block diagram illustrating the register set
`emulated by a particular embodiment of the present
`invention.
`FIGS. 4A and 4B are ?owcharts illustrating respec
`tively the installation and replication procedures typi
`cally employed by computer viruses.
`FIG. 5 is a flowchart illustrating the general emula
`tion process performed by a monitor program accord
`ing to 'a particular embodiment of the present invention.
`FIG. 6 is a ?owchart illustrating in further detail the
`memory access control step of the ?owchart of FIG. 5.
`FIG. 7 is a ?owchart illustrating in further detail the
`procedure access control step of the flowchart of FIG.
`5.
`FIG. 8 is a ?owchart illustrating in further detail the
`operating system entry point monitoring step of the
`?owchart of FIG. 5.
`FIG. 9 is a ?owchart illustrating the process per
`formed by a particular embodiment of the present in
`vention to check the behavior of an interrupt handler.
`FIG. 10 is a ?owchart illustrating the process per
`formed by a particular embodiment of the present in
`vention to identify viral replication behavior.
`
`CHECKSUM MONITORS
`The last standard technique of virus detection does
`not look for anything to do with viruses in particular,
`but concentrates on the host programs which the vi
`ruses attack. Every program on a system can be “check
`summed” at antivirus installation time. Then, when a
`virus attaches itself to the unsuspecting host program,
`the checksum value will (probably) be different and the
`?le infected with the virus can be isolated. The primary
`problem with this technique is that many programs
`store varying program information within themselves;
`this will change the checksum value and thus trigger a
`false alarm virus detection. Another problem is ensuring
`the integrity of the checksum information, which is
`typically attached to the program ?le itself or stored in
`a separate ?le. Both locations are vulnerable to covert
`virus modi?cation. Once a virus infects a host, it can
`then update the stored checksum value to correspond to
`the newly infected ?le and then execute undetected.
`
`25
`
`30
`
`45
`
`SUMMARY OF THE INVENTION
`An improved antivirus program according to a ?rst
`aspect of the present invention avoids the problems of
`the prior art and detects viral infection of a target pro
`40
`gram by emulating the execution of the target program
`and scanning for viral behavior. By emulating the exe
`cution of the target program, viruses are prevented
`from circumventing the monitor program’s protective
`mechanisms. A second aspect of the present invention
`recognizes that a key viral behavior is replication: vi
`ruses generally operate by passing replication/program
`modi?cation code onto uninfected programs. Unin
`fected programs, on the other hand, do not generally
`add program-modi?cation code to other programs.
`According to this aspect of the invention, the emulated
`target program is tested for replication behavior to
`determine whether the target program is virus~infected.
`A monitor program according to the ?rst aspect of
`the present invention contains both variables corre
`sponding to the CPU’s registers and emulation proce
`dures corresponding to the CPU’s instructions. The
`monitor program includes means for loading a target
`program into memory and emulating its execution. The
`monitor program also includes means for analyzing the
`60
`emulated behavior of the target program and for signal
`ling a warning if the emulated behavior is determined to
`be aberrant, dangerous or otherwise undesirable.
`In one embodiment according to the second aspect of
`the present invention, the monitor program further
`65
`includes means, responsive to a ?le access request by
`the target program, for providing a dummy program,
`having known behavior, for modi?cation by the target
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENT
`This description is sufficiently detailed for an under
`standing of the invention, but for those interested in
`more details of implementation, a micro?che appendix
`containing the source code for a particular embodiment
`is attached. This embodiment is intended for use on
`IBM PC (or compatible) type computer systems.
`In FIG. 1A a block diagram is shown illustrating the
`primary components of a computer system executing a
`target program in a standard manner. The computer
`system includes a CPU 10, a memory 20, and a disk
`storage device 30. This is simply an exemplary con?gu
`ration; the system could of course employ a tape storage
`device rather than disk storage, and many other varia
`tions are possible as well. Operating system 40 typically
`exists in Read Only Memory, but may also be partially
`loaded from the disk storage 30 into memory 20. At
`power up, the CPU begins executing the instructions of
`
`000012
`
`

`
`5,398,196
`6
`5
`operating system 40, which thereafter controls the load
`may be set or cleared during the execution of various
`ing and execution of application programs such as tar
`types of instructions. These bits can be examined by
`get program 50.
`other instructions to alter program flow or to perform
`other tasks. Registers 310 are general purpose and are
`In this standard con?guration, if a user selects target
`program 50 for execution, operating system 40 would
`used for a variety of tasks. Index registers 320 are typi
`cally used to indirectly reference memory. Stack
`load target program 50 from disk storage 30 into mem
`ory 20 and then transfer control to target program 50 by
`pointer 330 is used to maintain a data storage stack in
`memory. Instruction pointer (program counter) 340
`loading the start address of target program 50 into the
`program counter register, or instruction pointer regis
`points to the location in memory at which the next
`ter, of CPU 10. CPU 10 would then begin executing the
`instruction to be executed resides. Finally, segment
`instructions of target program 50, as pointed to by the
`registers 350 are used to prepend and additional 4 bits
`instruction pointer register. Target program 50 will
`onto other memory addressing registers (16 bits wide),
`typically include calls to operating system routines,
`allowing them to access a broader range of memory.
`Because these registers are intimately involved in the
`which are identi?ed by a table of pointers, commonly
`known as interrupt vectors. It is by remapping these
`execution of programs, they are all emulated by the
`interrupt vectors that standard behavior interceptor
`monitor program of the preferred embodiment, so as to
`fully control the execution of a target program.
`antivirus programs attempt to maintain control and
`supervision of target programs. As discussed above,
`however, many computer viruses are able to circum
`vent this remapping of the interrupt vectors and are able
`to use operating system routines without being moni
`tored by the antivirus program.
`In order to prevent this circumvention of monitoring
`code, a particular embodiment of the present invention
`is invoked by a user to request that an application pro
`gram be analyzed for viral behavior. This embodiment
`takes the form of a monitor program that emulates the
`execution of the application for a period of time, moni
`toring its behavior. By emulating the execution of the
`application program, the application program can be
`maintained in a controlled environment that cannot be
`circumvented by a virus.
`The con?guration of the monitor program and target
`application program is illustrated in FIG. 1B. Monitor
`program 60 loads target program 50 into memory and
`emulates the execution of the instructions of target pro
`gram 50, serving as a protective barrier between the
`application program and the remainder of the computer
`system. If the application program has not shown any
`viral behavior at the end of the monitor period, then it
`is loaded and executed in the standard manner, such as
`illustrated in FIG. 1A.
`In the secure environment created by the monitor
`program of FIG. 1B, every aspect of execution can be
`scrutinized and the operation of the virus can be con
`trolled completely. If the virus were to request a hard
`disk format operation, a successfully completed status
`would be returned to it making the virus “believe” that
`the operation was successful when in fact it was never
`executed in the ?rst place.
`FIGS. 2A and 2B respectively show the general lay
`out in memory 70 for an IBM PC type computer system
`with a target program loaded directly by PC DOS as in
`FIG. 1A, and for a target program loaded by an em
`bodiment of the present invention as in FIG. 1B. As
`55
`shown in FIG. 2A, ROM occupies the upper portion of
`the memory address space with the remainder of mem
`ory being ?lled up from the bottom: ?rst the operating
`system 40 in lower memory, followed by device drivers
`and memory resident programs, then user selected pro
`grams such as target program 50. FIG. 2B illustrates
`memory usage as in FIG. 2A, but additionally with
`monitor program 60 loaded.
`FIG. 3 illustrates the various CPU registers em
`ployed by an 8086 type CPU, the general type of CPU
`employed by many personal computers, and for which
`the presently described preferred embodiment is in
`tended. Flags register 300 is a set of bit-wise ?ags the
`
`Viral Code
`FIG. 4A illustrates the installation procedure typi
`cally employed by computer viruses. The virus execu
`tion begins at block 400 and proceeds to block 410, at
`which the virus determines if a copy of itself has already
`been installed in memory. If not, execution precedes to
`block 420, where the virus the current value of interrupt
`vector 21h (the operating system entry point on 8086
`type computers), and saves this value for later use.
`Next, at block 430, the virus sets the entry point to point
`to a procedure within the virus itself, after which at
`block 440 control is passed to the host program. If at
`block 410 the virus had determined that a copy had
`previously been installed, control would pass immedi
`ately to block 440.
`FIG. 4B illustrates a typical viral procedure for repli
`cation. The beginning of such a procedure would be the
`replacement entry point stored by the viral code at step
`430 of FIG. 4A. When a program later attempts to make
`an operating system call through int 21, the call would
`be directed to beginning block 450 of the viral proce
`dure of FIG. 4B. The viral .code would then execute,
`and at block 460 would determine if there was a ?le
`name associated with the operating system call. Such
`operating system calls are typically used by a normal
`program to open a ?le or execute another program. If
`there was a name associated with the operating system
`call, then at block 470 the viral code would replicate
`itself by writing its own executable code to the ?le that
`was the subject of the operating system call, in some
`instances after having checked to ensure that this ?le
`was not already infected by the virus. After block 470,
`the viral code would then exit at block 480, passing
`control to the original interrupt handler, a pointer to
`which had been saved at block 420 of FIG. 4A. If at
`block 460 the viral code had determined that there was
`no ?lename associated with the operating system call,
`then execution would have passed directly from block
`460 to block 480. In this manner the operating system
`continues to function normally except for a slight inter
`ruption while the viral code executes.
`
`Emulation to Detect Viral Code
`FIG. 5 illustrates the operation of monitor program
`60 according to a preferred embodiment of the inven
`tion. The monitor program can be executed explicitly
`by the user with a designated target program, or in
`alternative embodiments can be executed automatically
`whenever an operating system call is placed to execute
`a program. At block 500, the monitor program loads the
`
`20
`
`40
`
`50
`
`000013
`
`

`
`5
`
`15
`
`25
`
`30
`
`35
`
`45
`
`5,398,196
`8
`7
`target program into memory, in exactly the same man~
`target program to these areas of memory is simply de
`nied by the monitor program.
`ner as the operating system would have loaded the
`From the starting point at block 600, the procedure
`target program, but rather than passing execution to the
`target program immediately, the monitor program re
`passes to block 610, at which the monitor program
`tains control for a_ period of time, to evaluate the target
`determines if the current instruction is one whose func
`program.
`tion is to access memory. If so, then control passes to
`block 620, where the monitor program determines if the
`After the target program is loaded at block 500, at
`block 510 the monitor program initializes the emulated
`memory location to be accessed by the current instruc
`registers, which correspond to the registers used by
`tion is in an area selected for controlled access. If so,
`CPU 10. These register variables are used by a set of
`then control passes to block 630, which implements a
`remapping of the memory address. The monitor pro
`instruction emulation routines that are capable of emu
`lating the instructions of CPU 10. The emulated regis
`gram’s representation of the instruction is modi?ed to
`point to the mapping destination, so that the original
`ters are initialized with the same values that the real
`registers would have had if the target program had been
`memory location is protected from the target program.
`loaded by the operating system for execution.
`In the preferred embodiment, the contents of the
`original memory location are copied to the mapping
`After the emulation registers are initialized, the main
`emulation loop is entered. At block 520 the instruction
`destination the ?rst time the location is accessed by the
`pointed to by the emulated program counter register is
`target program. In other embodiments, the contents of
`fetched by the emulation software and the emulated
`the entire memory area selected for controlled access
`program counter register is incremented by the size of
`are copied into the mapping destination area when the
`20
`the fetched instruction, so that it points to the next
`monitor program ?rst starts. In yet other embodiments,
`instruction. Control then proceeds to a set of evaluation
`certain areas selected for controlled access can have
`procedures for the instruction. At block 530, the moni
`their mapping destination areas initialized with null or
`dummy values. For example, it may be desirable that
`tor program determines if the target program is at
`the content of the monitor program be protected and
`tempting to access memory selected for controlled ac
`cess. In the preferred embodiment, operating system
`hidden from the target program, so that a virus cannot
`detect the presence of the monitor program.
`procedures and data areas the address range of the mon
`After the remapping of block 630, at block 640 the
`itor program are selected for controlled access. Option
`ally, any memory not belonging to the target program
`attempted access to a controlled memory area is logged
`for later analysis and reporting to the user. After block
`can be selected for controlled access. The memory
`access process is explained in more detail below with
`640, the memory access control procedure ends at block
`reference to FIG. 6.
`650, which returns control to the main process of FIG.
`After block 530, at block 540 the monitor program
`5, at block 540. A negative determination at either of
`blocks 610 or 620 also results in control passing immedi
`evaluates the instruction for attempted access to a con
`trolled procedure, explained more fully below with
`ately to block 650.
`reference to FIG. 7, and then also emulates the execu
`tion of the instruction. Following block 540 is block
`550, at which the monitor program evaluates any possi
`ble modi?cations to the operating system entry points.
`The processes performed at block 550 are described in
`more detail below with reference to FIGS. 8-10.
`Following the emulation and evaluation blocks
`5305-50, at block 560 the monitor code determines if
`the target application has terminated. If so, emulation is
`terminated at block 570. The determination of step 560
`can be according to whether the target program termi
`nates of its own accord, or the determination can be set
`by a total number of instructions to be emulated or by a
`?xed period of time for emulation. If the target program
`has not terminated of its own accord at step 560, and if
`the monitor program has not forcibly terminated it,
`control returns to block 520, where the next cycle of the
`emulation loop is begun. The emulation termination at
`block 570 includes some “cleanup” on the part of the
`monitor program. This includes displaying to the user a
`status report of all operating system requests performed
`by the target program. This step may optionally also
`include reporting any memory accesses that have been
`performed outside of the area provided for the target
`program by the monitor program.
`Controlling Access to Memory
`The memory access monitoring process of block 530
`is illustrated in further detail in FIG. 6. The described
`process involves remapping selected parts of memory,
`which effectively virtualizes those memory areas, mak
`ing them inaccessible to the target program, and thus
`protected. In alternative embodiments, access by the
`
`Controlling Access to Procedures
`In some instances, it is desirable to control access to
`certain procedures. For instance, operating system pro
`cedures, ROM procedures, and interrupt handling pro
`cedures can have powerful effects and can be subject to
`misuse by a virus. For these reaso