`
`I, John Hawes, declare as follows:
`
`1.
`
`I am over the age of maj ority 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 malware 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-
`
`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
`
`Symantec 1044
`
`Symantec v. Finjan
`
`|PR2015-01892
`
`PALO ALTO NETWORKS Exhibit 1088 Page 1
`000001
`
`Symantec 1044
`Symantec v. Finjan
`IPR2015-01892
`
`000001
`
`
`
`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
`
`PALO ALTO NETWORKS Exhibit 1088 Page 2
`000002
`
`000002
`
`
`
`VIRUS BULLETIN CONFERENCE, SEPTEMBER I995 - 75
`
`
`DYNAMIC DETECTION AND CLASSIFICATION OF
`
`COMPUTER VIRUSES USING GENERAL BEHAVIOUR
`
`PATTERNS
`
`Morton Swimmer
`
`I Virus Test Center, University of Hamburg, Odenwaldstr. 9, 20255 Hamburg, Germany
`
`Tel +49 404 910041 ‘ Fax +49 405 471 5226 ‘ Email swimmer@.acm.org
`
`Baudoztin Le Charlier and Abdelaziz Mourtji
`
`F~.U.N.D.P., l1istitutd’Informatique, University of Namur, Belgium
`Email ble@info.flmdp.ac.be/ amo@info.i‘undp.ac.be
`
`'
`
`ABSTRACT
`
`The num ber offiles which needprocessing by virus labs is growing exponentially. Even though only a small
`proportion ofthesefiles will contain anew virus. eaclzfile requires examination. The normal methodfor
`dealing withfiles is still brutefizrce manual analysis. A virus. expert rims several tests on a givenfile and
`delivers a verdict on whether it is virulent ornot. Ifit is a new virus, it will be necessary to detect it. Some
`tools have been developed to speed up thisprocess, rangingfrom programs which iden tzfvpreviousIy—
`clczsstjiedfiles t_oprograms that generate detection data. Some anti- virusproducts have built- in mechanisms
`based on lzeurt;9t‘ias, which enable them to detect unknown viruses. Unfortunately all these tools have
`limitations.
`
`In th is paper, we will demonstrate how an emulator is used to monitor the system activiifv ofa virtual PC,
`and how the expert system ASAXis used to analyse the stream ofdata whicg the emulator produces. We use
`general rules to detect real viruses generically and reliably, andspecific rules to extract details oftheir
`behaviour. The resulting systenz is called VIDES: it is a prototypefor an automatic analysis systemfor
`computer viruses andpossibly a prototype an ttlvimsproduct for the emerging 32 bit PC operating
`svstems.
`
`1
`
`INTRODUCTION
`
`Virus researchers must cope with many thousands ofsuspected files each month, but the problem is not so
`much the number ofnew viruses (which number perhaps a few hundred and grows at a nearly exponential
`rate) as the number offiles the researcher receives and must analyse - the glut. Out ofperhaps one hundred
`files, only one may actually contain anew virus. Unfortunately, there are no short cuts. Every file has to be
`processed.
`
`
`PYRUS BULLETINCOzVFERE.I\lCE ©1995 VirusBulletin Ltd, 21 TheQuadrant, Abingdon, Oxfordshire, OXI43YS, England.
`Tel. +44 (0)1235 555139. No part of this publiczition may be‘ reproduced, stoned in a retrieval system, or transmitted in any fonn
`without
`the prior written permission of the publishers.
`»
`PALO ALTO NETWORKS Exhibit 1088 Page 3
`000003
`
`000003
`
`
`
`76 - SWIMMER‘ DYNAMIC DETECTION 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 ofdynamic 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 [BFHS9 1]. 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-
`Hiibner. Furtherrnore, advanced rulestwill helpin classifying the detected virus.
`
`The present version of VIDES 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 ofintrusion detection technology in
`detecting malicious software under future operating systems, such as OS/2, MS~Windows NT and 95,
`Linux, Solaris, etc.
`
`The rest ofthe paper is organized as follows: Section 2 presents the current state ofthe 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 on THE ART
`
`For the purpose of discussion itwill 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 ofcomputer viruses. An attempt was
`made in [Swi95], which is the result of many years ofexperience 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 ’ otherprograms by modifizing them
`or their erziaronmenz such that a call to an infectedprogram implies a call to a possibly evolved,
`fiutctionally similar, copy ofthe virus.
`-
`
`A more formal, butless usefiil, 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-
`depth discussion of the properties ofviruses, please refer to literature such as: [I-Iru92], [SK94], [Coh94] or
`[Fer92].
`
`Today, anti-virus technology can be divided into two approaches: the ViI‘1tS specific and the generic
`approach. In principle, the former requires knowledge ofthe viruses before they can be detected, Due to
`advances in technology, this prerequisite is no longer entirely valid in man y of the modern anti-virus
`produC—ts..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 BULLETINCONFERENCE@1995 Virus Bulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire. 0X14 SYS, 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.
`
`PALO ALTO NETWORKS Exhibit 1088 Page 4
`000004
`
`000004
`
`
`
`VIRUS‘ BULLETIN CONFERENCE, SEPTEMBER I993 - 77
`
`2.2 VIRUS SPECIFIC DETECTION
`
`Virus specific detectionis 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 itto detect all viruses previously analysed.
`
`The term scamzer 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 ofthat particular virus. This means that the string has to:
`
`a
`
`‘differ significantly from all other viruses, and
`
`o differ significantly from strings found in bonafide anti-virus programs.
`
`Finding such strings was the entire art ofanti-virusprogram writing until polymorphic viruses appeared on
`the scene.
`
`“Encrypted viruses were the first minor challenge to string searching methods. The body ofthe virus was
`encrypted in the hostfile, and could not be sought, dueto its variable nature. However, the body was
`prepefnded by a decryptor-loader which must be in plain text (unencrypted code); otherwise it would not be
`executab1e.T_his decryptor canstill be detected using strings, even if it becomes difficult to differentiate
`between viruses.
`
`Polymorphicviruses 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 were identified using a set ofpatterns (strings with variable elements). Moreover, simple virus
`detection techniques are made unreliable by the appearance of the so-called Mutation Engines such as
`MtE and TPE (Trident Polymorphic Engine). These are object library modules generating variable
`implernentations 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 ofthe 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 ofthe 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 ofeven polymorphic viruses poses no problem.
`
`The next shift many scanners are presently experiencing is away from known virus onlydetection .to
`detection of unknown viruses. The method ofchoice is heuristics. Heuristics are built into an anti~virus
`
`product in an attempt to deduce whethera fileis infected or not. This is most often done by looking‘ for a
`pattern ofcertain code fragments that occur most often in viruses and hopefully not in bozzafide programs.
`
`Heuristics analysis-suffers from a moderate to high false-positiverate. Ofcourse, a manufacturer of a
`heuristicrscanner will improve the heuristicsaboth to avoid false positives and still find all new viruses, but
`both cannotbe achieved completely. Usually, a heuristic scanner will contain a ‘traditional’ pattem-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
`ofreplication.
`‘
`'
`
`V1RUS‘B,ULZ.ETlN' CONFERENCE©1995 \’i.rusBulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire, OXHSYS, England.
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`
`wit.ho'ut
`
`the prior written pennission of the publishers.
`
`NETWORKS Exhibit 1088 Page 5
`
`000005
`
`
`
`78 ' 5VVIMMER' DYNAMIC DETECTION AND CLASSIFICATION OF COMPUTER VIRUSES...
`
`
`Unfortunately, itis notas easy to observe the replication as it may seem. DOS, in it various flavours,
`providesno 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 ofmany such programs. Later in the paper, We shall
`discuss how we avoidedthe problem when implementing VIDES.
`
`A more common approach isto detect symptoms of the infection such as file modifications. This type of
`program is usually called an integrity checker or clzecksummer.
`
`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 thatthe programs have not been modified. The shortcoming of
`thismethod 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 instealth 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 ofsuch attacks very difficult. As a consequence, the acceptance of such
`products is low.
`
`The non-specific -nature of the detection has little appeal for many of the users. Even generic repair
`facilities in the anti-virusproducts do notrhelp, 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 ifthe virus has been
`identified and analyzed can the user determine if his data was threatened.
`
`Generic virus detection technology should notbe dismissed. It is just as valid as virus-specific technology.
`Theproblems so far have stemmed from the permissiveness ofthe 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 twobasic components: a node in a state transition diagram represents some
`aspects ofthe 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 state s, to the state sfas 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 ofthe actual scenario, a state is adorned‘ by a set of assertions, characterizing the objects as
`affected by actions.
`
`
`
`Figure 1: State transition diagram
`
`VIRUSBULLETINCONFEREIVCE (6)1 995 Vims Bulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire, OX 14 3Y5, 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.
`PALO ALTO NETWORKS Exhibit 1088 Page 6
`000006
`
`000006
`
`
`
`VIRUS BULLETIN CONFERENCE, SEPTEMBER 1995 i 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 auditrecords may be present in the sequence ofaudit
`records representing the infection signature.
`
`For the sake of simplicity, discussion‘ ofthe generic detection rules are based on the state transition
`diagrams described above.
`-
`
`3.2 BUILDING THE RULES
`
`Vl DES usesthree 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 ofthe virus
`instead ofits code. Finally, there are the ‘other rules’ for gleaning other information from the virus which.
`canvbe used inits 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‘wi11.d'o, because MS-DOS viruses can use choose from many effective strategies. This is
`,_comp’ound_ed by the diversity of executable file types for MS-DOS; Fortunately for us, the majority of
`viruses have chosen one particular strategy, and infect only two types ofexecutable files. This means that
`we can detect most viruses withvery 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 therfollowing, we will develop a genericrule whichdetects 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 ofDOS viruses to help us build the rule.
`
`Assumption 1 :
`
`I Afile-infecting virus modifies the hostfile in such a way that 1'2‘ gains control over the
`ehostfile when the /zostfile 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.
`
`The virus in an infectedfile receives control over thefile before the original host
`Assumption 2:
`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 definition) why the virus must
`gain control before the host does.
`
`We make an additional assumption that the virus does gain control before the host programtdoes. The reason
`we do this is to avoid very blatant false positives. However, it should be noted thatAssumption 2 does not
`result from the virus definition, and will cause some viruses to be missed. For these cases, other rules are
`used.
`
`
`
`VIRUS ULLETAVCONFERENCE©l 995 Virus BI.tlletinLtd, 21 The Quadrant, Abingdon, Oxfordshire, OXI4 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 wfitten pennission of the publishers,
`PALO ALTO NETWORKS Exhibit 1088 Page 7
`000007
`
`000007
`
`
`
`80 * SWIMMER‘ DYNAMIC DETECTION AND CIASSIFICATION OF COMPUTER VIRUSES...
`
`
`3.3
`
`FINDING COM FILE INFECTIONS
`
`With respect to assumptions 1 and 2, we are looking for two possible infection strategies:
`
`close PX’
`
`
`found Virus E)— —>
`t,_ z
`
`i
`
`other
`E
`
`
`read or writes E
`»
`
`\\'i
`
`)2-=\
`
`\
`
`/
`
`\
`
`r
`
`read or writes i
`v \ _____j
`
`I
`
`i
`
`other
`
`read or writes
`
`(
`.
`
`I
`’
`
`'
`
`l
`
`
`
` write BOF
`I
`LX‘ 311
`
` 5_>(l‘;°\‘\_J H other
`
`lT¥_~l
`Ali
`at °Pen_ W
`
`,~?jT‘\
`und Virus L. _,~,
`
`st
`
`\ L
`
`‘
`
`l
`
`reopen
`
`/A‘ N T,
`i write BOF Sm}
`' close
`\,
`/
`i...
`/\’\
`
`=
`
`\ «
`
`other
`XE:
`2‘ read or writes
`
`Figure 2: Generic rulefor identifizing COMfile infectors
`
`1 The virus is overwriting, Therefore, we are looking for a write to the beginning of the file (BOF),
`without aprevious read to the same location. Other reads and writes are permitted.
`
`2 The virus is non-overwn'tz'ng. We expect to see a read to BOP, then a write to BOF. Before, in
`between, and alter 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 thatthe virus first reads the original code at BOF and
`then replaces it with its own code, usually ajump 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 ofan overwriting
`virus, the code is not read (and saved somewhere), but overwritten.
`
`Other reads and writes are not actually relevant to the detection ofthe virus. They can be logged and used in
`generating virus- specific rules.
`
`The ruleis 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 nothave 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 write BOF without
`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 virusescause problems for the rule by closing the file afiera 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 notestay active indefinitely and clog up the rule memory, there are a number of terminating
`
`VIRUS BULLE713/CONFERENCE©1 995 Ylms Bulletin Ltd, 21 The Quadrant, Abingdon, Oxfordshire. OX I431/S, Eng)andr
`Tel. +44 (0)1235 555139. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any fonn
`
`without the prior written permission of the publishers.
`
`NETWORKS Exhibit 1088 Page 8
`
`000008
`
`
`
`VIRUS BULLETIN CONFERENCE, SEPTEMBER I995 - 8!
`
`events. In fig. 2, reopen is abstracted as a transition element, whereas its implementation is as a separate
`rule;
`
`MS.-DOS provides two methodsofaccessing files. The most common method uses file handles. Access
`usingfile corztr-pl bloc/CS (PCB) 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 ofthe 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 toonly relevanthigher—Ievel records by using a
`“filter. After‘that, processing becomesvsimpler as the problems ofreopens and handle/FCB use disappear.
`This method also allows us to apply the rules on non—MS-DOS systems which provide similar file handling.
`
`Asa matter offact, 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 ofmaintaining 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 additiomintegrity of the ID system itselfmust not be compromised: this
`means that the audit data retrieval, analysis andarchiving must be secured against corruption by viruses.
`Moreover, the ID system must notbe prevented from reporting (raising alarms, updating virus information
`databases) the results ofsuch 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
`subvferfted. Even if the collection can be see ured, the data is open to manipulation ifstored 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 ofsuch a system will not benefit DOS users, but
`should be applicable to users ofvarious emerging 32~bit operating systems which offer DOS support.
`
`We have made several attempts to build a satisfactory audit system: these are described hereafier.
`
`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 0x21 is used. The requested service is entered into the AH
`register and itsparameters are. entered into the other registers. When the service is finished, it returns
`control to the callingprogram and provides its results in registers orin buffers.
`
`The very first implementation of an auditing system was a filter which was placed before DOS Services and
`registered all calls to DOS fimctions. This was done very early on, together with Dr. Fischer-Hiibner, to
`prove the feasibility ofthe VlDESconcept. It also demonstrated the limits which DOS imposes on the
`implementation ofsuch 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 [BFHS9 I].
`
`
`
`VIRUS BULLETINCONFERENCE@1995 Virus Bulletin Ltd,2 1 The Quadrant, Abtngdon, Oxfordshlre, 0X14 3YS, England.
`Tel. +44 (0)1235 555139. No pan of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
`without the prior written pcnnission of the publishers.
`PALO ALTO NETWORKS Exhibit 1088 Page 9
`00009
`'
`
`000009
`
`
`
`82 ° SWIMMEPc' DYNAMIC DETECTION AND CLASSIFICATION OF COMPUTER VIRUSES...
`
`
`4.2 VIRTUAL 8086 MACHINE
`
`The Intel iAPX 3 86 introduced the so-called virtual 8086 machine mode. A protected ‘mode operating system
`can create many virtual 8086 machines inwhich 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 portaccess) and DOS are redirected toithe host operating system (OS/2 in this case) for
`processing.
`
`This rnechanism,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 ofthe virtual 8086 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 ofthe-viruses running under a DOS window managed toharm vital
`parts ofthe system. One problem was that OS/2 files could be manipulated directly from within the DOS
`session. However, this did not explain the corruption ofthe running operating system.
`
`Even though using ‘a virtual 8086 machine was the original method ofchoice, such experimentsshowed 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 PeriSc0peIV, 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 istused to control the debugging session.
`
`Monitoring system behaviour on a DOS machine can be accomplished by capturing the Interrupt 0x21
`directly. or by setting a break point in the resident DOS kernel. Special memory areas can be monitoredby
`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. Ifthe 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 ofviruses on different operating systems. When such a solution is
`_
`implemented, itwill 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 ofthe 8086 processor. An emulation is a
`programwhich accepts the entire instruction set ofa 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
`interfacebetween the operatingsystem 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.
`
`V1RUSBULLE7'1NCONF£‘RENCE ©1 995 Virus Bu.IletinLtd, 21 The Quadrant, Abingdon, Oxfordshire, OX1-1 JYS, England.
`Tel. +44 (0)1235 555139. No pan of this publication may be reproduced, stored in a retnfeval system, or transmitted in any form
`without
`the prior written pemrission of the publishers.
`P&+6I_° NETWORKS Exhibit 1088 Page 10
`
`000010
`
`
`
`VIRUS BUlJ_ETlN CONFERENCE, SEPTEMBER I995 ' 83
`
`
`Using emulation gives us all the advantages ofthe hardware solution plus the possibility of handling
`everything in pseudo real-time with respect to the program running in the emulation. Because even the
`time—giving functions ofthe 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’ asrthe 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 majorproblem with using an emulation is its lack of speed. Even on -fastplatforms, the running speed
`is only marginally faster than an original PC/XT.
`
`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 of intrusion Detection [Den87] (<Subject, Action.
`Object, Exceptiom Condition, Resaurce—Usage, Time-Stamp>). H