United States Patent [19J
`Nachenberg
`
`[54] POLYMORPmC VIRUS DETECTION
`MODULE
`
`[75]
`
`Inventor: Carey Nachenberg, Northridge, Calif.
`
`[73] Assignee: Symantec Corporation, Cupertino,
`Calif.
`
`[21] Appl. No.: 535,340
`
`Sep. 28, 1995
`
`[22] Filed:
`Int. CI.6
`
`[51]
`
`•••••••••••••••••••••••••••••••• H04L 9/00; G06F 3/00;
`H04K3/00
`[52] U.S. CI •............................. 380/4; 364n09.05; 380/1;
`380/25; 395/183.01; 395/183.09; 395/183.14
`[58] Field of Search .................................... 380/49, 4, 25;
`395/183.01, 183.09, 183.14; 364/709.05
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,975,950
`5,121,345
`5,144,660
`5,319,776
`5,321,840
`5,349,655
`5,359,659
`5,398,196
`5,408,642
`5,421,006
`5,440,723
`5,442,699
`5,485,575
`
`12/1990 Lentz .......................................... 380/4
`6/1992 Lentz ...................................... 364/550
`9/1992 Rose ............................................ 380/4
`6/1994 Rile et al. ............................... 395/575
`6/1994 Ahlin et al .............................. 395noo
`9/1994 Mann ...................................... 395/575
`10/1994 Rosenthal .................................... 380/4
`3/1995 Chambers.
`4/1995 Mann ...................................... 395/575
`5/1995 Jablon et al ............................ 395/575
`8/1995 Arnold et al. .......................... 395/181
`8/1995 Arnold et al. .....•••••••••......•........• 380/4
`111996 Chess et al ...••••••...........••.. 395/183.14
`
`FOREIGN PATENT DOCUMENTS
`
`0636977 A2
`
`2/1995 European Pat. Off .••••.... G06F 11/00
`
`· 18 Claims, 4 Drawing Sheets
`
`111111111111 m 1111 111111111111111111111111111111111111
`US005696822A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,696,822
`Dec. 9, 1997
`
`OTHER PUBUCATIONS
`
`Digitext, "Dr. Solomon's Anti-VIrus Toolkit for Wmdows
`and DOS", S&S International PLC, Jan. 1995, pp. 1-15,
`47-65, 75-77, 91-95 113-115, and 123-142, United King(cid:173)
`dom.
`Veldman, Frans, "Virus Writing Is High-Tech Infosecurity
`Warfare", Security on the /-Way '95, 1995, pp. L-1-L-16,
`U.S.A.
`Symantec Corporation, ''Norton AntiVirus for Windows 95
`& Special Subscription Offer", 1995, U.S.A.
`
`(List continued on next page.)
`
`Primary Examiner-Stephen C. Buczinski
`Attorney, Agent, or Firm-Fenwick & West LLP
`[57]
`ABSTRACT
`
`A Polymoxphic Anti-Virus Module (PAM) (200) comprises
`a CPU emulator (210) for emulating the target program, a
`virus signature scanning module (250) for scanning
`decrypted virus code, and an emulation control module
`(220), including a static exclusion module (230), a dynamic
`exclusion module (240), instruction/interrupt usage profiles
`(224) for the mutation engines (162) of the known poly(cid:173)
`morphic viruses (150), size and target file types (226) for
`these viruses, and a table (228) having an entry for each
`known polymorphic virus (150). Prior to emulation, the
`static exclusion module (230) examines the gross charac(cid:173)
`teristics of the target file for attributes that are inconsistent
`with the size/type data (226), and excludes polymoxphic
`viruses (150) from the list (228) accordingly. During
`emulation, the dynamic exclusion module (240) compares
`fetched instructions with the instruction/interrupt usage pro(cid:173)
`files (224) to determine when emulation has proceeded to a
`point where at least some code from the decrypted static
`virus body (160) may be scanned for virus signatures.
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 1
`
`

`
`5,696,822
`Page2
`
`OTHER PUBLICATIONS
`
`ThunderBITE B.V., "User Manual", 1995, pp. i-191,
`Wijchen, The Netherlands.
`"Virus Infection Techniques: Part 3", Virus Bulletin, 1995,
`pp. 006--007, Oxfordshire, England.
`Cohen, Frederick B., "A Short Course on Computer Virus-
`2d Ed.", John Wiley & Sons, Inc., pp. 54-55, 199-209,
`1994, U.S.A.
`Veldman, Frans, "Heuristic Anti-Vlrus Technology", Pro(cid:173)
`ceedings of the International Virus Protection and Infonna(cid:173)
`tion Security Council, Apr. 1, 1994.
`Wells, Joseph, "Vrruses in the Wild", Proceedings of the
`International Virus Protection and Infonnation Security
`Counci~ Apr. 1, 1994.
`Gordon, Scott, "Vrruses & Netware", Proceedings of the
`International Virus Protection and Infonnation Security
`Coucil, Mar. 31, 1994.
`Solomon, Alan, "Viruses & Polymorphism", Proceedings of
`the International Virus Protection and Infonnation Security
`Council, Mar. 31, 1994.
`Case, Tori, "Viruses: An Executive Brief', Proceedings of
`the International Virus Protection and Infonnation Security
`Counci~ Mar. 31, 1994.
`
`Skulason, Fridrik, "For Programmers", Virus Bulletin, Jul.
`1990, pp. 10-11, Oxon, England.
`"Automated Program Analysis for Computer Virus Detec(cid:173)
`tion", IBM Technical Disclosure Bulletin, vol. 34, No.2, Jul.
`1991, pp. 415-416.
`"Artificial Immunity for Personal Computers", IBM Tech(cid:173)
`nical Disclosure Bulletin, vol. 34, No. 2, Jul. 1991, pp.
`150-154.
`Marshall, G., "Pest Control", LAN Magazine, Jun. 1995, pp.
`54-67.
`Gotlieb, L., "End Users and Responsible Computing",
`CMA-the Management Accounting Magazine, vol. 67, No.
`7, Sep. 1993, pp. 13.
`Karney, J., "Changing the Rules on Viruses", PC Magazine,
`vol. 13, No. 14, Aug. 1994, pp. NE36.
`Schnaidt, P., "Security", LAN Magazine, vol. 7, No. 3, Mar.
`1992, pp. 19.
`"UK-Sophos Intros Unix Vrrus Detection Software Jan. 26,
`1995", Newsbytes News Network, Jan. 26, 1995.
`"Anti-Vrrus Company Claims Polymorphic Breakthrough
`Jul. 10, 1992", Newsbytes News Network, Jul. 10, 1992.
`"LAN Buyers Guide: Network Management", LAN Maga(cid:173)
`zine, vol. 7, No. 8, Aug. 1992, pp. 188.
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 2
`
`

`
`U.S. Patent
`
`.ceD
`
`799199
`
`Sheet 1 of 4
`
`5,696,822
`
`0..6?‘we_
`
`mmmmn§mu
`
`..mm....mm9
`
`\.+mum.&o§N:>+3.6maofiN:EmmassM:
`..e.\:8E.8Qmu
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 3
`
`

`
`U.S. Patent
`
`Dec. 9, 1997
`
`Sheet 2 of 4
`
`5,696,822
`
`Emulation Module
`
`210
`
`228
`
`226
`
`224
`220
`..J
`
`Scanning Engine
`
`230
`
`240
`
`254
`
`252
`
`FIG. 2
`
`200
`
`011100110011001001001100101110000001010111000101011101010001101
`
`011001011101010100011010100101001010101111000001101010000010107
`
`011000110011001001010101111000001101010101070000110101000001010
`
`011100110011001001001100101110001001100110010000111100170111100
`
`FIG. 3
`
`\_224
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 4
`
`

`
`U.S. Patent
`
`Dec. 9, 1997
`
`Sheet 3 of 4
`
`5,696,822
`
`Entry Point
`From
`Scanning
`Phase
`
`Prepare Virtual
`Machine {Emulator)
`
`Load Next File
`
`Examine File for
`Static Exclusions
`
`410
`
`414
`
`418
`
`400
`
`440
`
`File is Infection
`Free
`
`YES
`
`424
`
`428
`
`430
`
`434
`
`Fetch Instruction
`
`Check Off Viruses
`That Do Not Use
`Instruction
`
`Emulate Instruction
`
`Tag Virtual Memory
`Page Accessed
`
`YES
`
`NO
`
`FIG. 4A
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 5
`
`

`
`U.S. Patent
`
`Dec. 9, 1997
`
`Sheet 4 of 4
`
`5,696,822
`
`454
`
`458
`First Byte of Next ..,.__ ____ __,
`Word
`
`464
`
`470
`
`490
`
`YES
`
`Indicate File
`Infected
`
`YES
`
`FIG. 48
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 6
`
`

`
`5,696,822
`
`1
`POLYMORPHIC VIRUS DETECTION
`MODULE
`
`BACKGROUND OF THE INVENITON
`
`1. Technical Field
`This invention relates to the field of computer viruses, and
`in particular to methods and systems for detecting polymor(cid:173)
`phic viruses.
`2. Background Art
`Polymorphic viruses are a type of computer virus
`designed to evade detection by infecting each new file with
`a mutated version of the virus. By providing each newly
`infected file with viral code having a different appearance,
`polymorphic viruses frustrate most standard virus-detection
`schemes, which rely on some type of string scanning to
`identify computer viruses in a file.
`Polymorphic viruses comprise a static virus body and a
`mutation engine. In the most common polymorphic viruses,
`the virus does not mutate. Rather, the mutation engine
`generates a virus decryption routine (polymorphic decryp(cid:173)
`tion loop) and uses the dual of this routine to encrypt the
`static virus body and the mutation engine. The new decryp(cid:173)
`tion routine and the newly encrypted virus body are then
`inserted into the host file. Common mutation strategies
`employed by the mutation engine include reordering of
`instructions, substituting equivalent instructions or equiva(cid:173)
`lent sequences of instructions, inserting random "garbage"
`instructions (which have no effect on the virus
`functionality), interchanging function calls, in-line code,
`JMP instructions, and the like, and using equivalent registers
`interchangeably.
`Thus far, the most successful technique for detecting
`polymorphic viruses has been cue-directed program emula(cid:173)
`tion (CDPE). CDPE methods assumes that the polymorphic
`code contains at least one section of machine code, the static
`viral body, that is consistent from generation to generation.
`CDPE methods also assume that when executed the decryp(cid:173)
`tion routine of the polymorphic virus deterministically 40
`decrypts the encrypted static virus body and transfers control
`to the static virus body when decryption is complete. The
`strategy employed by CDPE methods is to emulate the
`polymorphic virus until it has decrypted itself and then
`analyze the decrypted virus body using standard scanning
`techniques.
`CDPE virus detection systems comprise a scanner
`module, a CPU emulator (80x86), a set of virus signatures,
`and an emulation control module. The scanner module
`locates a file's entry point and the CPU emulator performs
`a limited emulation of the file's machine code under control
`of the emulation control module. Emulation proceeds until
`the emulation control module believes either that the virus is
`fully decrypted or that the file is not infected with a virus, at
`which point string scanning for virus signatures commences.
`The CDPE emulation control module examines each
`emulated instruction with the aid of certain heuristics to
`determine whether the instructions being emulated are likely
`to be part of a polymorphic decryption loop or a normal
`program. For example, certain sequences of instructions are
`frequently found in polymorphic decryption loops. These
`instruction sequences are referred to as ''boosters" since they
`indicate to the emulation control module that it is seeing a
`potential decryption loop and should continue emulating
`instructions. Other sequences of instructions are rarely
`found in decryption loops. These instruction sequences are
`referred to as "stoppers" since they indicate to the emulation
`
`2
`control module that the instructions are probably not from a
`virus decryption loop. Stoppers may be present if the host
`file is not infected or if the emulation has fully decrypted the
`static virus body. In the latter case, the static virus body, like
`5 any other program, may use any instructions supported by
`the processor architecture. In addition, stoppers may be
`present if a virus designer has included them in a decryption
`loop to foil CDPE detection methods.
`CDPE based methods employ additional heuristics to
`10 determine what the detection of various stoppers and boost(cid:173)
`ers indicates about the code being emulated. For example, if
`a number of stoppers have been found prior to the detection
`of any boosters, the emulation control module will likely
`decide that the host file is uninfected. On the other hand, if
`one or more stoppers are detected following detection of a
`15 number of boosters, the emulation control module will likely
`decide that the polymorphic loop has been fully decrypted to
`reveal the static virus body. In this case, virus scanning will
`proceed.
`The selection of boosters and stoppers included in the
`20 emulation control module can have a substantial impact on
`the speed and accuracy with which the CDPE system detects
`viruses. Ideally, stoppers and boosters are selected to work
`accurately for all known polymorphic viruses. However, it
`may not be possible to find a set of such heuristics that does
`25 not significantly slow virus scanning. Stoppers and boosters
`useful for detecting several polymorphic viruses may actu(cid:173)
`ally prevent the detection of other polymorphic viruses, as
`for example, where a virus writer includes a standard stopper
`in polymorphic loop code to confuse CDPE modules. In
`30 general, any change in the stoppers or boosters used must be
`accompanied by extensive regression testing to insure that
`previously detected viruses are not missed using the new
`heuristics. Since new polymorphic viruses are continually
`being developed, the time consuming and awkward selec-
`35 tion and regression testing of new combinations of stoppers
`and boosters can not be avoided.
`Thus, there is a need for polymorphic virus detection
`systems that can be readily expanded to cover newly dis(cid:173)
`covered viruses, without need for extensive regression test(cid:173)
`ing and modification of the heuristics of the emulation
`control module. In addition, the system should be able to
`provide accurate results without emulating unnecessarily
`large numbers of instructions.
`
`45
`
`SUMMARY OF THE INVENI10N
`The present invention is a polymorphic anti-virus module
`or PAM (200) for detecting polymorphic viruses (150) using
`mutation-engine specific information for each known poly(cid:173)
`morphic virus rather than heuristic stopper and booster code
`50 sequences. The PAM system (200) comprises a CPU emu(cid:173)
`lator (210) for emulating the target program, a virus signa(cid:173)
`ture scanning module (250) for scanning decrypted virus
`code, and an emulation control module (220), including a
`static exclusion module (230) and a dynamic exclusion
`55 module (240), for determining how long each target file is
`emulated before it is scanned. The emulation control module
`(220) also includes data (222) specific to each known
`polymorphic virus (150) and organized in a format that
`facilitates comparison with target files being tested for
`60 infection. This data (222) includes instruction/interrupt
`usage profiles (224) for the mutation engines (1li2) of the
`known polymorphic viruses (150), as well as size and target
`file types (22li) for these viruses. The emulation control
`module (220) also includes a table (228) having an entry for
`65 each known polymorphic virus (150) which can be flagged
`when characteristics inconsistent with the polymorphic virus
`are detected.
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 7
`
`

`
`5,696,822
`
`3
`In accordance with the present invention, the static exclu(cid:173)
`sion module (230) examines the gross characteristics of the
`target me for attributes that are inconsistent with the muta(cid:173)
`tion engine specific data for known polymorphic viruses
`(150). These characteristics are the type of target file, the 5
`size of the target file's load image, the presence of certain
`instructions at the file entry point, and the distance between
`the file entry point and the end of the load image. The last
`characteristic is useful because most viruses append them(cid:173)
`selves to the files they infect. In some cases, the static
`exclusion module (230) allows certain target files to be
`identified as infected without any emulation.
`The dynamic exclusion module (240) examines the
`instruction/interrupt usage promes (224) of each known
`polymorphic virus (150) as each instruction is fetched for
`emulation. The instruction/interrupt usage profiles (224) 15
`indicate which polymorphic viruses (150) employ mutation
`engines that do not use the fetched instruction in decryption
`loops they generate, and the emulation control module (220)
`flags these viruses. The emulation control module (220)
`continues until all mutation engines have been flagged or 20
`until a threshold number of instructions have been emulated.
`The flagging technique implemented by the dynamic exclu(cid:173)
`sion module (240) determines when emulation has pro(cid:173)
`ceeded to a point where at least some code from the
`decrypted static virus body (160) may be scanned and 25
`substantially reduces the number of instructions emulated
`prior to scanning the remaining target mes without resort to
`booster or stopper heuristics.
`It is not always necessary to fully decrypt the static virus
`body (160) to identify the underlying virus. In the preferred 30
`embodiment of the invention, the emulation control module
`(220) trackS those parts of virtual memory modified during
`emulation and periodically interrupts the emulation process
`to call the scanning module (250). The scanning module
`(250) tries to identify the virus type from the portion of
`decrypted static virus code (160). In order to speed up the 35
`process, the scanning module (250) implements a coarse
`scan of tagged memory locations to identify data bytes most
`likely to be associated with decrypted static virus code (virus
`signatures). It implements a more detailed binary search
`process only when selected bytes are encountered during the 40
`coarse scan. This approach greatly speeds up scanning
`without decreasing the accuracy of the scanning module
`(250). When code matching one of the viral signatures is
`identified, the PAM system (200) signals to the host com(cid:173)
`puter that an infected file has been located.
`
`10
`
`4
`have been used to infect three different types of executable
`files: COM files, SYS files, and EXE files. A common
`feature of these files is that at some point after loading,
`control of the computer is passed to the program code stored
`in the file. Computer viruses infect these executable files by
`attaching themselves to the me and modifying the machine
`language at the file entry point to transfer control to the virus
`rather than to the executable file. In order to camouflage
`their presence, computer viruses typically return control to
`the infected executable file once they have run.
`Referring to FIGS. lA and 1B, there are shown executable
`images 100, 100' of an EXE file before and after infection,
`respectively, by a virus 130. Infection modes for EXE,
`COM, and SYS files are discussed in greater detail in
`Nachenberg, A New Technique For Detecting Polymorphic
`Computer Viruses, Master Thesis, University of California
`at Los Angeles (1995), which is hereby incorporated by
`reference. Executable image 100 comprises a header 110 and
`program code 120. Header 110 includes a signature (MZ),
`size field, a code segment field CS, an instruction pointer
`field IP, a stack segment field SS, and a stack pointer field SP.
`MZ indicates the file type (EXE in this case) and the
`following field specifies the size of executable image 100.
`CS and IP specify an entry point 122 of program code 120,
`and SS and SP point to the end of program code 120, where
`a stack (not shown) may be generated.
`Upon infection by computer virus 130, header 110' of
`executable image 100' is modified so that size field equals
`the size of executable image 100 incremented by the size of
`computer virus 130. In addition, computer virus 130 has
`replaced CS, IP of image 100 with CS', IP' in image 100',
`CS', IP' point to an entry point 132 of virus 130 rather than
`entry point 122 of program code 120. Similarly, computer
`virus 130 has replaced SS, SP of image 100 with SS', SP' in
`image 100', which point to the end of virus 130. In order to
`return control of the computer to program code 120 follow-
`ing execution of virus 130, CS, IP, SS, and SP of uninfected
`image 100 are retained by virus 130.
`Computer viruses 130 which are added to EXE, COM, or
`SYS files in the manner of FIG. 1B are relatively easy to
`detect. A virus detection program need only scan executable
`image 100' for code segments associated with known viruses
`130. These code segments, known as virus signatures, are
`45 code segments unique to different viruses, and their presence
`in an executable image 100' is taken as a clear indication that
`the corresponding file has been infected. A number of
`methods are available for scanning executable images 100'
`for virus signatures. Different viruses 130 may implement a
`number of strategies to hide their presence in an executable
`image 100'.
`One of the most successful strategies is that implemented
`by polymorphic viruses, which include a mutation engine
`that encrypts a static virus body according to a different
`(mutated) encryption key with each new infection. The
`encrypted virus is appended to the image with a mutated
`decryption routine, which decrypts the encrypted virus to
`reveal the static virus body only when the file is executed.
`The new appearance presented by such polymorphic viruses
`on each infection frustrate those detection methods which
`would simply scan images 100' for vital signatures.
`Referring now to FIG. 1C, there is shown an executable
`image 100" infected by a polymorphic virus 150. Polymor(cid:173)
`phic virus 150 comprises a static virus body 160 including
`65 a mutation engine 162, both of which are shown hatched in
`the FIG. 1C to indicate their encrypted state. On infection,
`mutation engine 162 generates a variable encryption routine
`
`50
`
`BRIEF DESCRlPTION OF TilE DRAW1NGS
`FIGS. 1A-1C are schematic representations of the load
`images of an uninfected computer file, a file infected by a
`virus, and a file infected by a polymorphic virus, respec(cid:173)
`tively.
`FIG. 2 is a block diagram of a Polymorphic Anti-virus
`Module (PAM) in accordance with the present invention.
`FIG. 3 is an example of an instruction/interrupt usage
`profile employed in the emulation control module (220) of 55
`the present invention.
`FIG. 4A is a flowchart of the emulation process imple(cid:173)
`mented by an emulation control module (220) in accordance
`with the present invention.
`FIG. 4B is a flowchart of the scanning process imple- 60
`mented by a scanning module (250) in accordance with the
`present invention.
`
`DETAlLED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`Computer viruses infect a variety of files in a number of
`different ways. In the DOS environment, computer viruses
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 8
`
`

`
`5,696,822
`
`5
`(not s~own) ~at encrypts static virus body 160 (including
`mutation engme 162) to prevent detection of polymorphic
`virus 150 by conventional scanning techniques. A decryp(cid:173)
`~on routine 164, which is the dual of the encryption routine,
`IS prepended to encrypted static virus body 160. When 5
`image 100" is executed, a decryption routine 164 alecrypts
`and passes control to static virus body 160, which employs
`the CPU of the host computer to attach itself to other files
`and implement whatever mischief its designer intends.
`One anti-virus detection scheme designed specifically for 10
`polymorphic viruses 150 is Cue Directed Program Emula(cid:173)
`tion (CDPE). CDPE operates by emulating a target image
`100" or file for a sufficient number of instructions to allow
`a polymorphic virus 150 present in image 100" to decrypt
`itself and reveal its static virus body 160. Static virus body 15
`160 is then scanned to identify the type of virus present and
`steps are taken to deactivate it. As noted above, CDPE
`methods rely on the detection of prescribed stopper and
`booster code segments as a target file is emulated in order to
`determine whether an encrypted static virus body 160' is 20
`present, and if so, to determine whether it has been at least
`partially decrypted. The problem with this approach is that
`stopper and booster segments must be selected carefully and
`thoroughly tested in order to detect viruses accurately and
`completely. Stoppers and boosters added to detect new 25
`viruses require thorough regression testing to insure that
`they do not interfere with the detection of other polymorphic
`viruses. In short, stoppers and boosters that will work
`effectively with all polymorphic viruses must be identified,
`even as virus designers use these same stopper and booster 30
`heuristics to better camouflage their creations.
`In addition to the problems posed by any changes in the
`stopper, booster heuristics, CDPE emulation is done by
`virtual machines in order to isolate potentially infected files
`from the actual CPU and memory of the host computer. 35
`These virtual machines tend to operate slowly relative to the
`actual CPUs, and since each file must be checked, virus
`checking can be a very time consuming process. The speed
`of these programs is slowed further as more complicated
`heuristics are developed to detect polymorphic viruses.
`Referring now to FIG. 2, there is shown a block diagram
`of a polymorphic anti-virus module (PAM) 200 in accor(cid:173)
`dance with the present invention. PAM 200 comprises an
`emulation module 210, an emulation control module 220
`and a scanning module 250. As in CDPE systems, emulatio~ 45
`module 210 allows PAM 200 to emulate a target file without
`allowing the target file to interact with either the actual CPU
`or memory of the host computer. Scanning module 250
`includes virus signatures 252 for identifying polymorphic
`viruses 150 and a scanning engine 254 for efficiently search- 50
`ing decrypted virus code for these signatures. The scanning
`engine 254 is discussed in greater detail below in conjunc(cid:173)
`tion with FIG. 4B.
`Emulation control module 220 comprises virus profile
`data 222, a static exclusion module 230, and a dynamic 55
`exclusion module 240, which combine to substantially
`reduce the number of file instructions that must be emulated
`in order to detennine whether a target file is infected by a
`virus. Virus profile data 222 comprises an instruction/
`interrupt usage profile 224 for each known polymorphic
`virus 150 as well as data on the sizes of known polymorphic
`viruses 150 and type of target files infected by each (size/
`type data 226). Sizetrype data 226 is accessed by static
`exclusion module 230 prior to emulation to eliminate certain
`polymorphic viruses 150 from consideration, and 65
`instruction/interrupt usage profiles 224 are accessed by
`dynamic exclusion module 240 during emulation to deter-
`
`6
`mine whether the emulated code may be part of a virus
`decryption loop. Emulation control module 220 also
`includes a table 228 of all known polymorphic viruses 150
`which is initialized with all viruses 150 flagged. As each
`virus 150 is eliminated from consideration by static or
`dynamic exclusion modules 230, 240, respectively, the cor-
`responding flags are reset to preclude further consideration
`of the virus.
`For example, gross features of executable image 100 that
`are inconsistent with various polymorphic viruses 150 allow
`the static exclusion module 230 to rule out infection of a
`target file 100 by these polymorphic viruses before any
`emulation is done. H features inconsistent with a polymor-
`phic virus 150 are detected in target file 100, the associated
`flag in table 228 is reset and it is excluded from further
`consideration during the subsequent emulation phase. H the
`gross features of target file 100 are inconsistent with infec(cid:173)
`tion by all known polymorphic virus 150, no emulation is
`required to determine that target file 100 is uninfected, and
`the next target file may be considered. More often, analysis
`by static exclusion module 230 allows only some of poly(cid:173)
`morphic viruses 150 to be excluded from further consider(cid:173)
`ation.
`Data on polymorphic viruses 150 considered by static
`exclusion module 230 are: (1) the type of target file each
`known polymorphic virus 150 is designed to attack; (2) the
`minimum size of the load image of each polymorphic virus
`150; (3) whether a polymorphic virus 150 uses a JMP
`instruction as the first instruction of in target COM file; and
`( 4) the maximum size of the load image of each polymorphic
`virus 150. In order to take advantage of this data, static
`exclusion module 230 determines: the target file type and
`~oad image size for a target file being analyzed. In addition,
`if a COM target file is being analyzed, static exclusion
`module 230 determines its first instruction, and if an EXE
`target file is being analyzed, static exclusion module 230
`detennines the distance between the entry point and end of
`the load image. Theses gross characteristics and their rela(cid:173)
`tionship to features of known polymorphic viruses 150 are
`40 considered below.
`Type of Executable File Targeted
`Different viruses infect different executable file formats.
`Some infect only COM files, some infect only EXE files, and
`some infect both COM and EXE ·files. Very few viruses
`infect SYS files but some of these can infect EXE or COM
`files as well. Consequently, if target file is an EXE file, all
`polymorphic viruses 150 that attack only COM files or SYS
`files may be excluded from further consideration in the
`analysis of target file 100. In this case, flags are reset in table
`228 for each of polymorphic viruses 150 excluded by the
`type of target file 100, and subsequent analysis of target file
`100 considers only unexcluded polymorphic viruses 150.
`Minimum Size of Polymorphic VIrus
`Depending on the encryption routine employed, polymor-
`phic viruses 150 may generate executable images having a
`range of sizes. However, a minimum size for the executable
`image of each polymorphic virus 150 is provided by unen(cid:173)
`crypted static virus body 160, including mutation engine
`60 162. Consequently, each polymorphic virus 150 having an
`executable image that is larger than the executable image
`100 of the target file being analyzed may be excluded from
`further consideration in that analysis.
`JMP Instruction Usage
`Many polymorphic viruses 150 that infect COM files do
`so by appending themselves to the COM file and inserting a
`JMP instruction at the entry point of the COM file.
`
`BLUE COAT SYSTEMS - Exhibit 1065 Page 9
`
`

`
`5,696,822
`
`5
`
`10
`
`7
`8
`The instructions/intenupts used by the mutation engine of
`Consequently, when static exclusion module 230 examines
`a COM file and determines that the first instruction is not a
`a polymorphic virus may be determined by infecting a large
`JMP instruction, each polymorphic virus 150 that employs
`number of files with the polymorphic virus and analyzing
`such an instruction at the entry point of infected COM files
`the decryption loops generated in the infected files. VIrus
`may be excluded from further consideration.
`infection may be done automatically under software control,
`and the resulting polymorphic decryption loops may like(cid:173)
`Entry Point Distance in EXE Files
`wise be analyzed automatically to generate instruction/
`Polymorphic viruses 150 that infect EXE files have a
`intenupt usage profile 224 appropriate for the virus' muta(cid:173)
`maximum load image size. Since these viruses infect EXE
`tion engine. Further, since each polymorphic virus 150 is
`files by appending themselves to the EXE file load image,
`tested with data specific to its mutation engine 162, there is
`the distance between entry point 132 and the end of the load
`no need for regression testing when a new instruction/
`image must be less than this maximum value. Any poly(cid:173)
`intenupt usage profile is added to emulation control module
`morphic viruses 150 having maximum sizes less than the
`220.
`distance calculated for an EXE file under analysis may be
`Polymorphic viruses 150 typically have no reason to use
`excluded from further consideration.
`This list of features examined during the static exclusion 15 intenupts in their decryption loops, and consequently, these
`phase is not intended to be exhaustive. Additional features of
`were used as "stoppers" by CDPE anti-virus program devel-
`polymorphic viruses 150 may also be suitable for use by
`opers. Not surprisingly, virus developers began to include
`static exclusion module 230 to exclude various polymorphic
`intenupts in their decryption loops specifically because
`viruses 150 from further consideration.
`conventional CDPE programs would interpret their presence
`Typically, only a subset of known polymorphic viruses 20 as an indication that the associated code was not part of a
`will be ruled out by static exclusion module 230 and some
`decryption loop. In the present invention, emulation control
`emulation will be required. In these cases, dynamic exclu-
`module 220 treats detection of an interrupt in a manner
`similar to detection of any instruction, to eliminate from
`sion module 240 is implemented to initiate and control
`emulation module 210. During emulation, emulation control
`further consideration each polymorphic virus 150 that does
`module 220 instructs emulation module 210 to fetch an 25 not employ such an interrupt in its decryption loop.
`instruction from load image 100. As each instruction is
`Emulation cont