Declaration of John Hawes of Virus Bulletin
`
`I, John Hawes, declare as follows:
`
`1.
`
`I am over the age of majority and make this declaration based on the
`
`business records of my employer, Virus Bulletin.
`
`2.
`
`I am the Chief of Operations at Virus Bulletin, running the business
`
`side of the company since 2014 and managing all aspects of product testing and
`
`reviews since 2006. Virus Bulletin is an online magazine about the prevention,
`
`detection and removal of mal ware and spam. It regularly features analyses of the
`
`latest virus threats, articles exploring new developments in the fight against
`
`viruses, interviews with anti-virus experts, and evaluations of current anti(cid:173)
`
`malware products. Virus Bulletin has run an annual international conference on
`
`malware, anti-malware and related subjects since 1991. Virus Bulletin is
`
`headquartered at The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP,
`
`United Kingdom.
`
`3.
`
`According to Virus Bulletin's business records, which are maintained
`
`in the ordinary course of business, the paper entitled "Dynamic Detection and
`
`Classification of Computer Viruses Using General Behaviour Patterns" by Morton
`
`Swimmer was published by Virus Bulletin to all 163 attendees of the Virus
`
`Bulletin International Conference at the Boston Park Plaza Hotel and Towers in
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 1
`
`

`
`September 1995. The conference proceedings book containing the Swimmer paper
`
`was subsequently made available for private sale to individuals by Virus Bulletin.
`
`4.
`
`Attached hereto as Exhibit A is a true and correct copy of the paper
`
`entitled "Dynamic Detection and Classification of Computer Viruses Using
`
`General Behaviour Patterns" that Virus Bulletin published in 1995.
`
`5.
`
`I hereby declare that all statements made herein of my own
`
`knowledge are true and that all statements made on information and belief are
`
`believed to be true, and further that these statements were made with the
`
`knowledge that willful false statements and the like are punishable by fine or
`
`imprisonment, or both, under 18 U.S.C. § 1001.
`
`Executed at Oxfordshire, United Kingdom on October 15, 2015.
`
`John Hawes
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 2
`
`

`
`VIRUS BUU£TIN CONFERENCE, SEPTEMBER /995 • 7 5
`
`DYNAMIC DETECTION AND CLASSIFICATION OF
`COMPUTER VIRUSES USING GENERAL BEHAVIOUR
`PATTERNS
`
`Morton Swimmer
`
`Virus Test Center, University of Hamburg, Odenwaldstr. 9, 20255 Hamburg, Germany
`Tel +49 404 910041 · Fax +49 405 471 5226 ·Email swimmer@acm.org
`
`Baudouin Le Charlier and Abdela:dz Mounji
`
`F.U.N. D.P., lnstitutd' Informatique, University ofNamur, Belgium
`Email ble@info.fundp.ac.be I amo@info.fundp.ac.be
`
`ABSTRACT
`
`The number of files which need processing by virus labs is growing exponentially. Even though only a small
`proportion of these ft les will contain a new virus, each file requires examination. The normal method for
`dealing with files is still brute force manual analysis. A virus expert runs several tests on a given file and
`delivers a verdict on whether it is virulent or not. If it is a new virus, it will be necessmy to detect it. Some
`tools have been developed to speed up this process, ranging from programs which identify previously(cid:173)
`classified .files to programs that generate detection data. Some anti-virus products have built-in mechanisms
`based on heuristics, which enable them to detect unknown viruses. Unfortunately all these tools have
`limitations.
`
`In this paper, we will demonstrate how an emulator is used to monitor the system activity of a virtual PC,
`and how the expert system ASAX is used to analyse the stream of data whicg the emulator produces. We use
`general rules to detect real vimses generical~v and reliably, and specific rules to extract details of their
`behaviour. The resulting system is called VIDES: it is a prototype for an automatic analysis system for
`computer viruses and possibly a prototype anti-virus product for the emerging 32 bit PC operating
`systems.
`
`1
`
`INTRODUCTION
`
`Virus researchers must cope with many thousands of suspected files each month, but the problem is not so
`much the number of new viruses (which number perhaps a few hundred and grows at a nearly exponential
`rate) as the number of files the researcher receives and must analyse- the glut. Out of perhaps one hundred
`files, only one may actually contain a new virus. Unfortunately, there are no short cuts. Every file has to be
`processed.
`
`ViRUS BULLETINCONFERENC£©1995 Virus Bulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire, OX143YS, En gland.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`without the prior written permission of the publishers.
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 3
`
`

`
`76 • SWIMMER: DYNAMIC DETEGION AND CLASSIFICATION OF COMPUTER VIRUSES ...
`
`The standard method of sorting out such files is still brute force manual analysis, requiring specialists.
`Some tools have been developed to help cope with the problem, ranging from programs which identify and
`remove previously-classified files and viruses to utilities which extract strings from infected files that aid in
`identifying the viruses. However, none of the solutions are satisfactory. Clearly, more advanced tools are
`needed.
`
`In this paper, the concept of dynamic analysis as applied to viruses is discussed. This is based on an idea
`called VIDES (Virus Intrusion Detection Expert System), coined at the Virus Test Center [BFHS91]. The
`system will comprise of a PC emulation and an IDES-like expert system. It should be capable of detecting
`viral behaviour using a set of a priori. rules, as shown in the preliminary work done with Dr. Fischer-
`H iibner. Furthermore, advanced rules will help in classifying the detected virus.
`
`The present version ofVID ES is only of interest to virus researchers; it is not designed to be a practical
`system for the end-user- its demands on processing power and hardware platform are too high. However, it
`can be used to identify unknown viruses rapidly and provide detection and classification information to the
`researcher. It also serves as a prototype for the future application of intrusion detection technology in
`detecting malicious software under future operating systems, such as OS/2, MS-Windows NT and 95,
`Linux, Solaris, etc.
`
`The rest of the paper is organized as follows: Section 2 presents the current state of the art in anti-virus
`technology; Section 3 describes a generic virus detection rule; Section 4 discusses the architecture of the PC
`auditing system; Section 5 shows how the expert system ASAX is used to analyse the activity data collected
`by the PC emulator; and finally, Section 6 contains some concluding remarks.
`
`2
`
`CURRENT STATE OF THE ART
`
`For the purpose of discussion it will be necessary to define the term computer virus.
`
`2.1 TERMS
`There is still no universally-agreed definition for a computer virus. What is missing is a description which
`is still general enough to account for all possible implementations of computer viruses. An attempt was
`made in [Swi95], which is the result of many years of experience with viruses in the Virus Test Center. The
`following definition for a computer virus is the result of discussion in comp.virus (Virus-L) derived from
`[Seb]:
`
`Def 1
`
`A Computer Virus is a routine or a program that can 'infect' other programs by modifying them
`or their environment such that a call to an infected program implies a call to a possibly evolved,
`fimctional~y similar, copy of the virus.
`
`A more formal, but less useful, definition of a computer virus can be found in [Coh85]. Using the formal
`definition, it was possible to prove the virus property undecidable.
`
`We talk of the infected file as the host program. System viruses infect system programs, such as the boot
`or Master Boot Sector, whereas file viruses infect executable files such as EXE or COM files. For an in(cid:173)
`depth discussion of the properties of viruses, please refer to literature such as: [Hru92], [SK94], [Coh94] or
`[Fer92].
`
`Today, anti-virus technology can be divided into two approaches: the virus specific and the generic
`approach. In principle, the former requires knowledge of the viruses before they can be detected. Due to
`advances in technology, this prerequisite is no longer entirely valid in many of the modern anti-virus
`products. This type of technology is known to us as a scanner. The latter attempts to detect a virus by
`observing attributes characteristic of all viruses. For instance, integrity checkers detect viruses by checking
`for modifications in executable files; a characteristic of many (although not all) viruses.
`
`VIRUS BULLETINCONFERENC£©1995 Virus Bulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire, OX143YS, England.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`without the prior written permission of the publishers.
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 4
`
`

`
`VIRUS BUU£TIN CONFERENCE, SEPTEMBER /995 • 77
`
`2.2 VIRUS SPECIFIC DETECTION
`
`Virus specific detection is by far the most popular type of virus protection used on PCs. Information
`from the virus analysis is used in the so-called scanner to detect it. Usually, a scanner uses a database of
`virus identification information which enable it to detect all viruses previously analysed.
`
`The term scanner has become increasingly incorrect terminology. The term comes from lexical scanner, i.e.
`a pattern matching tool. Traditionally scanners have been just that. The information extracted from viruses
`were strings which were representative of that particular virus. This means that the string has to:
`
`• differ significantly from all other viruses, and
`
`• differ significantly from strings found in bonafide anti-virus programs.
`
`Finding such strings was the entire art of anti-virus program writing until polymorphic viruses appeared on
`the scene.
`
`Encrypted viruses were the first minor challenge to string searching methods. The body of the virus was
`encrypted in the host file, and could not be sought, due to its variable nature. However, the body was
`prepended by a decryptor-loader which must be in plain text (unencrypted code); otherwise it would not be
`executable. This decryptor can still be detected using strings, even if it becomes difficult to differentiate
`between viruses.
`
`Polymorphic viruses are the obvious next step in avoiding detection. Here, the decryptor is implemented
`in a variable manner, so that pattern matching becomes impossible or very difficult. Early polymorphic
`viruses '?'ere identified using a set of patterns (strings with variable elements). Moreover, simple virus
`detection techniques are made unreliable by the appearance of the so-called Mutation Engines such as
`M tE and TPE (Trident Polymorphic Engine). These are object library modules generating variable
`implementations of the virus decryptor. They can easily be linked with viruses to produce highly
`polymorphic infectors. Scanning techniques are further complicated by the fact that the resulting viruses
`do not have any scan strings in common even if their structure remains constant. When polymorphic
`technology improved, statistical analysis of the opcodes was used.
`
`Recently, the best of the scanners have shifted course from merely detecting viruses to attempting to
`identify the virus. This is often done with added strings, perhaps position dependent, or checksums, over the
`invariant part of the virus. To support this, many anti-virus products have implemented machine-code
`emulators so that the virus' own decryptor can be used to decrypt the virus. Using these enhancements, the
`positive identification of even polymorphic viruses poses no problem.
`
`The next shift many scanners are presently experiencing is away from known virus only detection to
`detection of unknown viruses. The method of choice is heuristics. Heuristics are built into an anti-virus
`product in an attempt to deduce whether a file is infected or not. This is most often done by looking for a
`pattern of certain code fragments that occur most often in viruses and hopefully not in bona fide programs.
`
`Heuristics analysis suffers from a moderate to high false-positive rate. Of course, a manufacturer of a
`heuristic scanner will improve the heuristics both to avoid false positives and still find all new viruses, but
`both cannot be achieved completely. Usually, a heuristic scanner will contain a 'traditional' pattern-matching
`component, so that viruses can be identified by name.
`
`2.3 GENERIC VIRUS DETECTION
`
`Computer viruses must replicate to be viruses. This means that a virus must be observable by its mechanism
`of replication.
`
`VIRUS BULLETLN CONFERENC£©1995 Virus Bulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire, OX14 3 YS, England.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`without the prior written permission of the publishers.
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 5
`
`

`
`78 ·SWIMMER: DYNAMIC DETEaiON AND CLASSIFICATION OF COMPUTER VIRUSES ...
`
`Unfortunately, it is not as easy to observe the replication as it may seem. DOS, in it various flavours,
`provides no process isolation, or even protection of the operating system from programs. This means that
`any monitoring program can be circumvented by a virus which has been programmed to do so. There used to
`be many anti-virus programs which would try to monitor system activity for viruses, but were not proof
`against all viruses. This problem led to the demise of many such programs. Later in the paper, we shall
`discuss how we avoided the problem when implementing VIDES.
`
`A more common approach is to detect symptoms of the infection such as file modifications. This type of
`program is usually called an integrity checker or checksummer.
`
`When programs are installed on the PC, checksums are calculated over the entire file, or over portions of the
`file. These checksums are then used to verify that the programs have not been modified. The shortcoming of
`this method is that the integrity checker can detect a modification in the file, but cannot determine whether
`the modification is due to a virus or not. A legitimate modification to, for instance, the data area of a
`program will cause the same alarm as a virus infection.
`
`Another problem is virus technology aimed specifically against anti-virus products. Advances in stealth and
`tunnelling technology have made updates necessary. There have also been direct attacks against
`particular integrity checkers, rendering them useless. Again, the lack of support from the operating
`system makes the prevention of such attacks very difficult. As a consequence, the acceptance of such
`p roducts is low.
`
`The non-specific nature of the detection has little appeal for many of the users. Even generic repair
`facilities in the anti-virus products do not help, despite these methods effectively rendering identification
`unnecessary. The problem is partly understandable. The user is concerned with his data. Merely
`disinfecting the programs is not enough if data has been manipulated. Only if the virus has been
`identified and analyzed can the user determine if his data was threatened.
`
`Generic virus detection technology should not be dismissed. It is just as valid as virus-specific technology.
`The problems so far have stemmed from the permissiveness of the underlying operating system, DOS, and
`from the limits in the programs. Both problems can be addressed.
`
`3
`
`DYNAMIC DETECTION RULES
`
`Before we can attempt to detect a virus using ASAX, we need to model the virus attack strategy. This is
`then translated into RUSSEL, the rule-based language which ASAX uses to identify the virus attack.
`
`3.1 REPRESENTING INFECTION PATTERNS USING STATE TRANSITION DIAGRAMS
`
`State transition diagrams are eminently suitable for representing virus infection scenarios. In this model of
`representation, we distinguish two basic components: a node in a state transition diagram represents some
`aspects of the computing system state. Arcs represents actions performed by a program in execution.
`Given a (current) state s;, the action a takes the system from the states; to the state s1 as shown in Figure
`1. The infection process played by a virus can be viewed as a sequence of actions which drives the system
`from an initial clean state to a final infectious state, where some files are infected. In order to get a complete
`description of the actual scenario, a state is adorned by a set of assertions, characterizing the objects as
`affected by actions.
`
`Figure 1: State transition diagram
`
`VIRUS BULLETINCONFERENC£©1995 Virus Bulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire, OX143YS, England.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`without the prior written permission of the publishers.
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 6
`
`

`
`VIRUS BULLETIN CONFERENCE, SEPTEMBER 1995 • 79
`
`In practice, we only represent those actions relevant to the infection scenario. As a result, many possible
`actions may occur between adjacent states, but are not recorded because they do not entail a modification in
`the current state. In terms of auditing, irrelevant audit records may be present in the sequence of audit
`records representing the infection signature.
`
`For the sake of simplicity, discussion of the generic detection rules are based on the state transition
`diagrams described above.
`
`3.2 BUILDING THE RULES
`
`VI DES uses three types of detection rules: generic detection rules, virus specific rules, other rules. As its
`name implies, generic rules are used to detect all viruses which use a known attack pattern. For this, models
`of virus behaviour are needed for the target system (in our case MS-DOS). Virus-specific rules use
`information from a previous analysis to detect that specific virus, or direct variants. These rules are similar
`to virus-specific detection programs, except for the fact that they analyze the dynamic behaviour of the virus
`instead of its code. Finally, there are the 'other rules' for gleaning other information from the virus which
`can be used in its classification.
`
`We will not go into the virus-specific rules or the 'other' rules, concentrating instead on the generic rules.
`
`In developing a generic rule for detecting viruses, we need to have a model for the virus attack. No one
`model will do, because MS-DOS viruses can use choose from many effective strategies. This is
`compounded by the diversity of executable file types forMS-DOS. Fortunately for us, the majority of
`viruses have chosen one particular strategy, and infect only two types of executable files. This means that
`we can detect most viruses with very few rules. On the other hand, a virus which uses an unknown attack
`strategy will not be detected. For this reason, the prototype analysis system contains an auxiliary static
`analysis component to detect such problems.
`
`In the following, we will develop a generic rule which detects file infectors that modify the file directly to
`gain control over that file. We will concentrate on COM file infectors. EXE file infectors are detected in an
`analogous way.
`
`We must make two assumptions about the behaviour of DOS viruses to help us build the rule.
`
`Assumption 1:
`
`A file-infecting virus modifies the host file in such a way that it gains control over the
`host file when the host file is run.
`
`This is a specific version of the virus definition (Def 1 ). However, it doesn't specify when the virus gains
`control over the host file.
`
`Assumption 2:
`The virus in an infected file receives control over the file before the original host
`program.
`
`That is, when the infected file is run, the virus is run before the host program.
`
`Discussion: If the virus never gains control over the host file, it would not fulfil the definition of a virus.
`This observation leads to Assumption 1. However, there is no reason (in the defmition) why the virus must
`gain control before the host does.
`
`We make an additional assumption that the virus does gain control before the host program does. The reason
`we do this is to avoid very blatant false positives. However, it should be noted that Assumption 2 does not
`result from the virus definition, and will cause some viruses to be missed. For these cases, other rules are
`used.
`
`VIRUS B ULLETLN CONFERENCE ©1995 Virus Bulletin Ltd, 21 The Quadrant, Abingdon, Oxford shire, OX 14 3YS, England.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`without the prior written permission of the publishers.
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 7
`
`

`
`80 • SWIMMER: DYNAMIC DETEG/ON AND CLASS/FICA TION OF COMPUTER VIRUSES ...
`
`33 FINDING COM FILE INFECTIONS
`With respect to assumptions 1 and 2, we are looking for two possible infection strategies:
`
`found Virus
`
`·~ ~
`
`other
`read or writes !
`
`found Virus
`
`\ -- ~
`
`other
`I read or writes
`
`Figure 2: Generic rule for identifying COM file infectors
`
`The virus is overwriting. Therefore, we are looking for a write to the beginning of the file (BOF),
`without a previous read to the same location. Other reads and writes are permitted.
`2 The virus is non-ove1writing. We expect to see a read to BOF, then a write to BOF. Before, in
`between, and after these two events, other reads and writes are permitted.
`The assumption in both cases is that the write to BOF causes the virus to gain control on execution.
`
`In the case of a non-overwriting virus, we assume that the virus first reads the original code at BOF and
`then replaces it with its own code, usually a jump to the virus body. In most cases, the number ofbytes read
`will be the same as the number of bytes written, but we cannot assume this. In the case of an overwTiting
`virus, the code is not read (and saved somewhere), but overwritten.
`
`Other reads and writes are not actually relevant to the detection of the virus. They can be logged and used in
`generating virus- specific rules.
`
`The rule is initiated by the opening of a file (in this case a COM file). The rule is terminated by a close of
`the file, where this does not have to be done by the virus itself In between these two events, we expect the
`actual infection to occur. We look for the read BOF followed by the write BOF or the -.,vrite BOFwithout
`the read. Other administrative operations, like tracking the file position, are also done by the rule. This is
`shown in the state transition diagram offigure 2.
`
`Some viruses cause problems for the rule by closing the file after a first set of operations. This is handled
`by a reopen mechanism which waits for a possible open event on the same file from the virus. In order that
`this rule does not stay active indefinitely and clog up the rule memory, there are a number ofterminating
`
`VIR USB ULLETIN CONFERENCE ©1995 Virus Bulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire, OX 14 3 YS, England.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`withou1 the prior written permission of !he publishers.
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 8
`
`

`
`VIRUS BULLETIN CONFERENCE, SEPTEMBER 1995 • 81
`
`events. In fig. 2, reopen is abstracted as a transition element, whereas its implementation is as a separate
`rule.
`
`MS-DOS provides two methods of accessing files. The most common method uses file handles. Access
`using_file control blocks (FCB) was provided for compatibility to CP/M, and is rarely used, even by
`viruses. However, because it is used, we need a separate rule to handle this method. The basic rule stays the
`same, but internal handling of the data is different.
`
`We could avoid this problem by abstracting the audit data to give us a generic view of the system events.
`This way, we could reduce the number of audit records to only relevant higher-level records by using a
`filter. After that, processing becomes simpler as the problems of reopens and handle/FCB use disappear.
`This method also allows us to apply the rules on non-MS-DOS systems which provide similar file handling.
`
`As a matter of fact, ASAX itself is the logical choice to act as the filter. The first ASAX system reads the
`raw audit trail, converts it into generic data, and pipes its output as a NADF file for further processing (see
`Section 5). Using ASAX as a filter allows us to reduce the complexity of maintaining such a system while
`not sacrificing any power.
`
`4
`
`PC AUDITING
`
`The prerequisite for using an Intrusion Detection (ID) system like ASAX is an audit system which securely
`collects system activity data. In addition, integrity of the ID system itself must not be compromised: this
`means that the audit data retrieval, analysis and archiving must be secured against corruption by viruses.
`Moreov.er, the ID system must not be prevented from reporting (raising alarms, updating virus information
`databases) the results of such analysis. DOS neither provides such a service, nor makes the implementation
`of such a service easy. Its total lack of security mechanisms means that the collection of data can be
`subverted. Even if the collection can be secured, the data is open to manipulation if stored on the same
`machine.
`
`For the prototype ofVIDES, we were not bound to a real world implementation, so we explored various
`alternative possibilities. The experience gained by the use of such a system will not benefit DOS users, but
`should be applicable to users of various emerging 32-bitoperating systems which offer DOS support.
`
`We have made several attempts to build a satisfactory audit system: these are described hereafter.
`
`4.1 DOS INTERRUPTS
`
`All DOS services are provided to application programs via interrupts, which can be described as indexed
`inter-segment calls. Primarily, interrupt Ox21 is used. The requested service is entered into the AH
`register and its parameters are entered into the other registers. When the service is finished, it returns
`control to the calling program and provides its results in registers or in buffers.
`
`The very first implementation of an auditing system was a filter which was placed before DOS Services and
`registered all calls to DOS functions. This was done very early on, together with Dr. Fischer-Hi.ibner, to
`prove the feasibility of the VIDES concept. It also demonstrated the limits which DOS imposes on the
`implementation of such an auditing system: it did not run reliably, and could be subverted by tunnelling
`viruses.
`
`This implementation was soon scrapped, but it did prove that the premise was correct: viruses could be
`found using ID technology. This was perhaps the first such a trial that had been done [BFHS91].
`
`VIRUSBULLETINCONFERENCE©l995VirusBulletinLtd,2l TheQuadrant, Abingdon, Oxfordshire, OX143YS,England.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`without the prior written permission of the publishers.
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 9
`
`

`
`82 • SWIMMER: DYNAMIC DETEa/ON AND CLASS/FICA TION OF COMPUTER VIRUSES ...
`
`4.2 VIRTIJAL 8086 MACHINE
`The Intel iAPX 3 86 introduced the so-called virtual 8086 machine mode. A protected mode operating system
`can create many virtual8086 machines in which tasks can run completely isolated from each other and from
`the operating system. Each task 'sees' only its own environment Operating systems such OS/2 use these
`constructs to provide a full DOS environment for DOS programs. All calls to the machine (via the BIOS
`interface or direct port access) and DOS are redirected to the host operating system (OS/2 in this case) for
`processmg.
`
`This mechanism can also be used to monitor the activity in DOS session. Because all interrupts are being
`redirected to the native operating system, the native operating system can record the activity securely and
`unobtrusively.
`
`Care has to be taken in the implementation of the virtual8086 machine. The DOS windows in OS/2 have
`been shown in tests at the VTC to be too permissive. In the course of a comprehensive test including the
`entire collection of file viruses, many of the viruses running under a DOS window managed to harm vital
`parts of the system. One problem was that OS/2 files could be manipulated directly from within the DOS
`session. However, this did not explain the corruption of the running operating system.
`
`Even though using a virtual8086 machine was the original method of choice, such experiments showed that
`the complexity of building a safe implementation would be difficult. A more secure method was sought for
`the prototype.
`
`4.3 HARDWARE SUPPORT
`Hardware debugging systems, such as the Periscope IV, may be used to monitor system events closely in
`real time. This is achieved by a card fitted between the CPU and the motherboard and which can set break
`points on various types of events on the PC' s bus. The card is connected to a receiving card in a second PC
`which is used to control the debugging session.
`
`Monitoring system behaviour on a DOS machine can be accomplished by capturing the Interrupt Ox21
`directly, or by setting a break point in the resident DOS kernel. Special memory areas can be monitored by
`setting a break condition on access to those areas.
`
`The monitoring is completely unobtrusive, i.e. the program will not notice a difference between running
`with or without the debugger. When an event is triggered, the PC is stopped while the controlling PC is
`processing the data. If the controlling PC is fast enough, the time delay should be nearly negligible.
`
`A hardware solution using the Periscope IV is complicated by the problem of automating the processes
`necessary to test large numbers of viruses on different operating systems. When such a solution is
`implemented, it will offer the possibility oftesting viruses on other PC operating systems which require full
`iAPX 386 compatibility.
`
`4.4
`
`8086 EMULATION
`
`The solution which was finally chosen was the software emulation of the 8086 processor. An emulation is a
`program which accepts the entire instruction set of a processor as input, and interprets the binary code as the
`original processor would. All other elements of the machine must be implemented or emulated, e.g. the
`various ports. To simplify and quicken the emulation, the BIOS Code (Basic Input Output System- the
`interface between the operating system and the hardware) can be replaced with special emulation hooks, so
`that the complicated machine access can be skipped as long as all access to those services are routed via the
`BIOS. In the case of a graphics adapter, the entire hardware must be emulated, whereas disk access can be
`handled with hooks in the BIOS.
`
`VIRUS BULLETIN CONFERENC£©1995 Vrrus Bulletin Ltd, 21 The Quadrant, Abingdon, Oxford shire, OX14 3YS, England.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system. or transmitted in any form
`without the prior written permission of the publishers.
`
`BLUE COAT SYSTEMS - Exhibit 1088 Page 10
`
`

`
`VIRUS BUUETIN CONFERENCE, SEPTEMBER /995 • 83
`
`Using emulation gives us all the advantages of the hardware solution plus the possibility ofhandl ing
`everything in pseudo real-time with respect to the program running in the emulation. Because even the
`time-giving functions of the emulation are being steered by the emulation, when interruptable to process an
`event, the time in the emulation can also be stopped.
`
`The emulation is ' safe' as the running virus has no access to the host machine at all. This is because the
`target machine's memory is being controlled entirely by the emulation, and file accesses are directed to a
`virtual disk, stored as a disk image file.
`
`The major problem with using an emulation is its lack of speed. Even on fast platforms, the running speed
`is only marginally faster than an original PCIXT.
`
`4.5 ACTIVITY DATA FORMAT
`Audit records representing the program behaviour in general, and virus activity in particular, have a pattern
`which is borrowed from the Dorothy Denning's model oflntrusion Detection [Den87] (<Subject, Action.
`Object, Exception-Condition, Resource-Usage, Time-Stamp>). However, due to the way processes are
`handled in DOS, this pattern is sl