`
`SCANNERS OF THE YEAR 2000: HEURISTICS
`
`Dmitry 0. G1J1azoov
`
`S&S International Pic, Alton House, Gatehouse Way, Aylesbury, Bucks, HP 19 3XU, UK
`Tel +441296 318700 ·Fax +44 12963 18777 ·Email grdo@sands.co.uk
`
`INTRODUCTION
`
`At the beginning of 1994, the number of known MS-DOS viruses was estimated at around 3,000. One year
`later, in January 1995, the number of viruses was estimated at about6,000. By the time this paper was
`written (July 1995), the number of known viruses exceeded 7,000. Several anti-virus experts expect this
`number to reach 10,000 by the end of the year I 995. This large number of viruses, which keeps growing
`fast, is known as the glut and it does cause problems to anti-virus software- especially to scanners.
`
`Today, scanners are the most frequently used type of anti-virus software. The fast-growing number of
`viruses means that scanners should be updated frequently enough to cover new viruses. Also, as the number
`of viruses grows, so does the size of the scanner or its database, and in some implementations the scanning
`speed suffers.
`
`lt was always very tempting to find a final solution to the problem; to create a generic scanner which can
`detect new viruses automatically without the need to update its code and/or database. Unfortunately, as
`proven by Fred Cohen, the problem of distinguishing a virus from a non-virus program is algorithmically
`unsolvable as a general rule.
`
`Nevertheless, some generic detection is still possible, based on analysing a program for features typical or
`not typical of viruses. The set of features, possibly together with a set of rules, is known as heuristics.
`Today, more and more anti-virus software developers are looking towards heuristica I analysis as at least a
`partial solution to the glut problem.
`
`Working at the Virus Lab, S&S lntemational Pic, the author is also carrying out a research project 'on
`heuristic analysis. The article explains what heuristics are. Positive and negative heuristics are introduced
`and some practical heuristics are represented. Different approaches to a heuristical program analysis are
`discussed and the problem of false alanns is explained and discussed. Several well-known scanners
`employing heuristics are compared (without naming the scanners) both virus detection and false alarms rate.
`
`1 WHY SCANNERS?
`
`If you are following computer virus-related publications, such as the proceedings of anti-virus conferences,
`magazine reviews, anti-virus software manufacturers' press releases, you read and hear mainly 'scanners,
`scanners, scanners'. The average user might even get the impression that there is no anti-virus software
`other than scanners. This is not true. There are other methods of fighting computer viruses -but they are not
`
`VIRUS BULLETlNCONFERENCEf:Jl 995 Virus Bulletin Ltd,21 The Quadrant, Abingdon, Oxford shire, OXJ4 JYS, England.
`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 wrinen pennission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1011 Page 1
`
`
`
`226 • GRYAZNOV: SCANNERS OF THE YEAR 2000: HEURISTICS
`
`as popular or as well known as scanners; and anti-virus packages based on non-scanner technology do not
`sell well. Sometimes people who are trying to promote non-scanner based anti-virus software even come to
`the conclusion that there must be some kind of an international plot of popular anti-virus scanner producers.
`Why is this? Let us briefly discuss existing types of anti-virus software. Those interested in more detailed
`discussion and comparison of different types of anti-virus software can find it in [Bontchev 1], for example.
`
`1.1
`
`SCANNERS
`So, what is a scanner? Simply put, a scanner is a program which searches files and disk sectors for byte
`sequences specific to this or that known virus. Those byte sequences are often caJled virus signatures. There
`are many different ways to implement a scanning technique; from the so-called 'dumb' or' grunt' scanning
`of the whole file, to sophisticated virus-specific methods of deciding which particular part of the file should
`be compared to a virus signature. Nevertheless, one thing is common to all scanners: they detect only known
`viruses. That is, viruses which were disassembled or analysed and from which virus signatures unique to a
`specific virus were selected. In most cases, a scanner cannot detect a brand new virus until the virus is
`passed to the scanner developer, who then extracts an appropriate virus signature and updates the scanner.
`This all takes time - and new viruses appear virtually every day. This means that scanners have to be
`updated frequently to provide adequate anti-virus protection. A version of a scanner which was very good
`six months ago might be no good today if you have been hit by just one of the several thousand new viruses
`which have appeared since that version was released.
`
`So, are there any other ways to detect viruses? Are there any other anti-virus programs which do not depend
`so heavily on certain virus signatures and thus might be able to detect even new viruses? The answer is yes,
`there are: integrity checkers and behaviour blockers (monitors). These types of anti-virus software are
`almost as old as scanners, and have been known to specialists for ages. Why then are they not used as
`widely as scanners?
`
`1.2 BEHAVIOUR BLOCKERS
`
`A behaviour blocker (or a monitor) is a memory-resident (TSR) program which monitors system activity
`and looks for virus-like behaviour. In order to replicate, a virus needs to create a copy of itself. Most often,
`viruses modify existing executable files to achieve this. So, in most cases, behaviour blockers try to
`intercept system requests which lead to modifying executable files. When such a suspicious request is
`intercepted, a behaviour blocker, typically, alerts a user and, based on the user' s d.ecision, can prohibit such
`a request from being executed. This way, a behaviour blocker does not depend on detailed analysis of a
`particular virus. Unlike a scanner, a behaviour blocker does not need to know what a new virus looks like to
`catch it.
`
`Unfortunately, it is not that easy to block all the virus activity. Some viruses use very effective and
`sophisticated techniques, such as tunnelling, to bypass behaviour blockers. Even worse, some legitimate
`programs use virus-like methods which could trigger a behaviour blocker. For example, an install or setup
`utility is often modifying executable files. So, when a behaviour blocker is triggered by such a utility, it's up
`to the user to decide whether it is a virus or not- and this is often a tough choice: you would not assume that
`all users are anti-virus experts, would you?
`
`But even an ideal behaviour blocker (there is no such thing in our real world, mind you!), which never
`triggers on a legitimate program and never misses a real virus, still has a major flaw. To enable a behaviour
`blocker to detect a virus, the virus must be run on a computer. Not to mention the fact that virtually any user
`would reject the very idea of running a virus on his/her computer, by the time a behaviour blocker catches
`the virus attempting to modify executable files, the virus could have triggered and destroyed some of your
`valuable data files, for example.
`
`VIRUS B ULLETINCONFERENC£©1995 Virus Bulletin Ltd,21 The Quadrant, Abingdon, Oxfordshire, OX143YS, England.
`Tel. +44 (0)1235 555139. No part of this pubHcation may be reproduced, stored in a retrieval system, or transmitted in any fonn
`without the prior written pennission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1011 Page 2
`
`
`
`VIRUS BUllETIN CONFERENCE, SEPTEMBER 1995 • 227
`
`INTEGRilY CHECKERS
`1.3
`An integrity checker is a program which should be run periodically (say, once a day) to detect all the
`changes made to your files and disks. This means that, when an integrity checker is first installed on your
`system, you need to run it to create a database of all the files on your system. During subsequent runs, the
`integrity checker compares files on your system to the data stored in the database, and detects any changes
`made to the files. Since all viruses modify either files or system areas of disks in order to replicate, a good
`integrity checker should be able to spot such changes and alert the user. Unlike a behaviour blocker, it is
`much more difficult for a virus to bypass an integrity checker, provided you run your integrity checker in a
`virus clean environment- e.g. having booted your PC from a known virus-free system diskette.
`
`But again, as in the case of behaviour blockers, there are many possible situations when the user's expertise
`is necessary to decide whether changes detected are the result of virus activity. Again, if you run an install
`or setup utility, this normally results in modifications to your files which can trigger an integrity checker.
`That is, every time you install new software on your system, you have to tell your integrity checker to
`register these new files in its database.
`
`Also, there is a special type of virus, aimed specifically at integrity checkers -so-called slow infectors. A
`slow infector only infects objects which are about to be modified anyway; e.g. as a new file being created by
`a compiler. An integrity checker will add this new file to its database to watch its further changes. But in the
`case of a slow infector, the file added to the database is infected already!
`
`Even if integrity checkers were free of the above drawbacks, there still would be a major flaw. That is, an
`integrity checker can alert you only after a virus has run and modified your files. As in the example given
`while discussing behaviour blockers, this might be well too late ...
`
`1.4 THAT'S WHY SCANNERS!
`So, the main drawbacks of both behaviour blockers and integrity checkers, which prevent them from being
`widely used by an average user, are:
`
`1. Both behaviour blockers and integrity checkers, by their very nature, can detect a virus only after you
`have run an infected program on your computer, and the virus has started its replication routine. By
`this time it might be too late - many viruses can trigger and switch to destructive mode before they
`make any attempts to replicate. It's somewhat like deciding to find out whether these beautiful yet
`unknown berries are poisonous by eating them and watching the results. Gosh! You would be lucky to
`get away with just dyspepsia!
`2. Often enough, the burden to decide whether it is a virus or not is transferred to the user. It's as if
`your doctor leaves you to decide whether your dyspepsia is simply because the berries were not ripe
`enough, or it is the frrst sign of deadly poisoning, and you'll be dead in few hours if you don' t take
`an antidote immediately. Tough choice!
`On the contrary, a scanner can and should be used to detect viruses before an infected program has a chance
`to be executed. That is, by scanning the incoming software prior to installing it on your system, a scanner
`tells you whether it is safe to proceed with the installation. Continuing our berries analogy, it's like having a
`portable automated poisonous plants detector, which quickly checks the berries against its database of known
`plants, and tells you whether or not it is safe to eat the berries.
`
`But what if the berries are not in the database of your portable detector? What if it is a brand new species?
`What if a software package you are about to install is infected with a new, very dangerous virus unknown to
`your scanner? Relying on your scanner only, you might frnd yourself in big trouble. This is where behaviour
`blockers and integrity checkers might be helpful. 1 t's still better to detect the virus while it's trying to infect
`
`V/RUSBUI..LETL¥CONFERENC£f:;1995\rll1lsBulJetinLtd,21 TheQuadrant,Abingdon,Oxfordshirc,OX143YS,England.
`Tel. +44 (0)1235 555139. No part of tills publication may be reproduced, stored in a retrieval sysrem, or transmitted in any fonn
`without the prior written pennission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1011 Page 3
`
`
`
`228 • GRYAZNOV: SCANNERS OF THE YEAR 2000: HEURISTICS
`
`your system, or even after it has infected but before it destroys your valuable data. So, the best anti-virus
`strategy would include all three types of anti-virus software:
`
`• a scanner to ensure the new software is free of at least known viruses before you run the software
`• a behaviour blocker to catch the virus while it is trying to infect your system
`
`• an integrity checker to detect infected files after the virus has propagated to your system but not yet
`triggered.
`
`As you can see, the scanners are the first and the most simply implemented line of anti-virus defence.
`Moreover, most people have scanners as the only line of defence.
`
`2 WHY HEURISTICS?
`
`2.1 GLUT PROBLEM
`As mentioned above, the main drawback of scanners is that they can detect only known computer viruses.
`Six or seven years ago, this was not a big deal. New viruses appeared rarely. Anti-virus researchers were
`literally hunting for new viruses, spending weeks and months tracking down rumours and random reports
`about a new virus to include its detection in their scanners. It was probably during these times that a most
`nasty computer virus-related myth was born that anti-virus people develop viruses themselves to force users
`to buy their products and profit this way. Some people believe this myth even today. Whenever I hear it, I
`can't help laughing hysterically. Nowadays with two to three hundred new viruses arriving monthly, it
`would be total waste of time and money for anti-virus manufacturers to develop viruses. Why should they
`bother if new viruses arrive in dozens virtually daily, completely free of charge? There were about 3,000
`known DOS viruses at the beginning of 1994. A year later, in January 1995, the number of viruses was
`estimated at least5,000. Another six months later, in July 1995, the number exceeded 7,000. Many anti(cid:173)
`virus experts expect the number of known DOS viruses to reach the I 0,000 mark by the end of 1995. With
`this tremendous and still fast-growing number of viruses to fight, traditional virus signature scanning
`software is pushed to its limits [Skulason, Bontchev2]. While several years ago a scanner was often
`developed, updated and supported by a single person, today a team of a dozen skilled employers is only
`barely sufficient. With the increasing number of viruses, R&D and Quality Control time and resource
`requirements grow. Even monthly scanner updates are often late, by one month at least! Many formerly
`successful anti-virus vendors are giving up and leaving the anti-virus battleground and market. The fast(cid:173)
`growing number of viruses heavily affects scanners themselves. They become bigger, and sometimes
`slower. Just few years ago a 360Kb floppy diskette would be enough to hold half a dozen popular scanners,
`leaving plenty of room for system files to make the diskette bootable. Today, an average good signature(cid:173)
`based scanner alone would occupy at least a 720Kb floppy, leaving virtually no room for anything else.
`
`So, are we losing the war? I would say: not yet- but if we get stuck with just virus signature scanning, we
`will lose it sooner or later. Having realise4 this some time ago, anti-virus researchers started to look for
`more generic scanning techniques, known as heuristics.
`
`2.1 WHAT ARE HEURISTICS?
`In the anti-virus area, heuristics are a set of rules which should be applied to a program to decide whether
`the program is likely to contain a virus or not. From the very beginning of the history of computer
`viruses different people started looking for an ultimate generic solution to the problem. Really, how does
`an anti-virus expert know that a program js a virus? It usually involves some kind of reverse engineering
`(most often disassembly) and reconstructing and understanding the virus' algorithm: what it does and how it
`does it. Having analysed hundreds and hundreds of computer viruses, it takes just few seconds for an
`experienced anti-virus researcher to recognise a virus, even it is a new one, and never seen before. It is
`
`VIRUS BUUETINCONFERENC£©1995 Virus BuUetinLtd,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 tile publishers.
`
`PALO ALTO NETWORKS Exhibit 1011 Page 4
`
`
`
`VIRUS BULLETIN CONFERENCE, SEPTEMBER 1995 • 229
`
`almost a subconscious, automated process. Automated? Wait a minute! If it is an automated process, let's
`make a program to do it!
`
`Unfortunately (or rather, fortunately) the analytic capabilities of the human brain are far beyond those of a
`computer. As was proven by Fred Cohen [Cohen], it is impossible to construct an algorithm (e.g. a
`program) to distinguish a virus from a non-virus with 100 per cent reliability. Fortunately, this does not
`rule out a possibility of90 or even 99 per cent reliability. The remaining one per cent, we hope to be able to
`solve using our traditional virus signatures scanning technique. Anyway, it's worth trying.
`
`SIMPLE HEURISTICS
`2.2
`So, how do they do it? How does an anti-virus expert recognise a virus? Let us consider the simplest case: a
`parasitic non-resident appending COM file infector. Something like Vienna, but even more primitive. Such a
`virus appends its code to the end of an infected program, stores a few (usually just three) first bytes of the
`victim ftle in the virus body and replaces those bytes with a code to pass control to the virus code. When the
`infected program is executed, the virus takes control. First, it restores the original victim's bytes in its
`memory image. It then starts looking for other COM files. When found, the file is opened in
`Read_and_ Write mode; then the virus reads the ftrst few bytes of the file and writes itself to the end ofthe
`file. So, a primitive set ofheuristical rules for a virus of this kind would be:
`
`I. The program immediately passes control close to the end of itself
`2. It modifies some bytes at the beginning of its copy in memory
`3. Then it starts looking for executable files on a disk
`4. When found, a file is opened
`5. Some data is read from the file
`6. Some data is written to the end of the file.
`
`Each of the above rules has a corresponding sequence in binary machine code or assembler language. In
`general, if you look at such a virus under DEBUG, the favourite tool of anti-virus researchers, it is usually
`represented in a code similar to this:
`
`START :
`
`JMP VIRUSCODE
`
`Start of the infected program
`Rule 1 :
`the control is passed
`to the virus body
`
`<victim's code>
`
`VIRUS :
`
`SAVED :
`
`Virus body starts here
`
`Saved original bytes of the
`victim's code
`
`MASK:
`
`DB
`
`'*. COM' ,0
`
`Search mask
`
`VIRUSCODE :
`
`MOV DI , OFFSET START
`MOV SI,OFFSET SAVED
`MOVSW
`MOVSB
`
`Start of the virus code
`Rule 2 : the v irus restores
`victim' s code
`in memory
`
`MOV DX , OFFSET MASK
`
`Rule 3: the virus
`
`ViRUS BULLETJNCONFERENCE01995 VIJ'Us Bulletin Ltd,21 TheQWidrant,Abingdon, Olfordsh.ire, OX143YS, England.
`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 wrinen permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1011 Page 5
`
`
`
`230 • GRYAZNOV: SCANNERS OF THE YEAR 2000: HEURISTICS
`
`MOV AH , 4EH
`I NT 21H
`
`MOV AX , 3D0 2H
`INT 21H ;
`
`l ooks f o r othe r
`p rog r ams to infect
`
`Rul e 4 :
`
`t h e viru s o p e n s a f ile
`
`MOV DX,OFFSET SAVED
`MOV AH, 3FH
`I NT 2 1H
`
`Rule 5: firs t b yte s of a file
`a r e read to the virus
`b o dy
`
`MOV DX , OFFS ET VIRUS
`MOV AH,4 0H
`I NT 2 1H
`
`t he v i rus write s
`Rule 6 :
`t o the fi l e
`
`i tsel f
`
`Figure 1. A sample virus code
`
`When an anti-virus expert sees such code, it is immediately obvious that this is a virus. So, our heuristical
`program should be able to disassemble a binary machine-language code in a similar manner to DEBUG, and
`to analyse it, looking for particular code patterns in a similar manner to an anti-virus expert. In the simplest
`cases, such as the one above, a set of simple wildcard signature string matching would do for the analysis.
`In this case, the analysis itself is simply checking whether the program in question satisfies rules J through
`6; in other words, whether the program contains pieces of code corresponding to each of the rules.
`
`In a more general case, there are many different ways to represent one and the same algorithm in machine
`code. Polymorphic viruses, for example, do this all the time. So, a heuristic scanner must use many clever
`methods, rather than simple pattern-matching techniques. Those methods may involve statistical code
`analysis, partial code interpretation, and even CPU emulation, especially to decrypt self-encrypted viruses:
`but you would be surprised to know how many real life viruses would be detected by the above six simple
`heuristics alone! Unfortunately, some non-virus programs would be ' detected' too.
`
`FALSE ALARMS PROBLEM
`2.3
`Strictly speaking, heuristics do not detect viruses. As behaviour blockers, heuristics are looking for virus(cid:173)
`like behaviour. Moreover, unlike the behaviour blockers, heuristics can detect not the behaviour itself, but
`just potential ability to perform this or that action. Indeed, the fact that a program contains a certain piece of
`code does not necessarily mean that this piece of code is ever executed. The prob !em of discovering whether
`this or that code in a program ever gets control is known in the theory of algorithms as the Halting Problem.
`and is in general unsolvable. This issue was the basis of Fred Cohen's proof of the impossibility of writing
`a perfect virus detector. For example, some scanners contain pieces of virus code as the signatures for which
`to scan. Those pieces might correspond to each and every one of the above six rules. But they are never
`executed- the scanner uses them just as its static data. Since, in general, there is no way for heuristics to
`decide whether these code pieces are ever executed or not, this can (and sometimes does) cause f alse alarms.
`
`A false alatm is when an anti-virus product reports a virus in a program, which in fact does not contain any
`viruses at all. Different types of false alarms, as well as most widespread causes of false alarms, are
`described in [Solomon] for example. A false alarm might be even more costly than an actual virus infection.
`We all keep saying to users: 'The main thing to remember when you think you've got a virus - do not
`panic! ' Unfortunately, this does not work well. The average user will panic. And the user panics even more
`if the anti-virus software is unsure itself whether it is a virus or not. In the case, say, where a scanner
`definitely detects a virus, the scanner is usually able to detect all infected programs, and to remove the virus.
`At this point, the panic is usually over; but if it is a false alarm, the scanner will not be able to remove the
`virus, and most likely will report something like: 'This file seems to have a virus', naming just a single file
`as infected. This is when the user really starts to panic. 'It must be a new virus!'- the user thinks. ' What do
`
`VIRUSBULLETJNCONFERENCE©l995VirusBuUetinLtd,2l TheQuadrant,Abingdon,Oxfordshirc,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.
`
`PALO ALTO NETWORKS Exhibit 1011 Page 6
`
`
`
`VIRUS BUllETIN CONFERENCE, SEPTEMBER 1995 • 23/
`
`I do?!' As a result, the user well might format his/her hard disk, causing himself a far worse disaster than a
`virus could. Formatting the hard disk is an unnecessary and un-justified act, by the way; even more so as
`there are many viruses which would survive this act, unlike legitimate software and data stored on the disk.
`
`Another problem a false alarm can (and did) cause is negative impact on a software manufacturing company.
`If an anti-virus software falsely detects a virus in a new software package, the users will stop buying the
`package and the software developer will suffer not only profit losses, but also a loss of reputation. Even if it
`was later made known that it was a false alarm, too many people would think: 'There is no smoke without
`fire', and would treat the software with suspicion. This affects the anti-virus vendor as well. There has
`already been a case where an anti-virus vendor was sued by a software company whose anti-virus protection
`mistakenly reported a virus.
`
`In a corporate environment, when a virus is reported by anti-virus software, whether it is a false alarm or
`not, the normal flow of operation is interrupted. It takes at best several hours to contact the anti-virus
`technical support and to ensure it was a false alarm before normal operation is resumed - and, as we all
`know, time is money. In the case of a big company, time is big money.
`
`So, it is not at all surprising that, when asked what level of false alarms is acceptable ( 10 per cent? 1 per
`cent? 0.1 percent?), corporate customers answer: 'Zero per cent! We do not want any false alarms!'
`
`As previously explained, by its very nature heuristic analysis is more prone to false alarms than traditional
`scanning methods. Indeed, not only viruses but many scanners as well would satisfy the six rules we used as
`an example: a scanner does look for executable files, opens them, reads some data and even writes
`something back when removing a virus from a file. Can anything be done to avoid triggering a false positive
`on a scanner? Let's again turn to the experience of a human anti-virus expert. How does one know that this
`is a scanner, and not a virus? Well, this is more complicated than the above example of a primitive virus.
`Still, there are some general rules too. For example, if a program relies heavily on its parameters or involves
`an extensive dialogue with a user, it is highly unlikely tbat the program is a virus. This Leads us to the idea
`of negative heuristics; that is, a set of rules which are true for a non-virus program. Then, while analysing a
`program, our heuristics should estimate the probability of the program to be a virus using both positive
`heuristics, such as the above six rules, and negative heuristics, typical for non-virus programs and rarely
`used by real viruses. If a program satisfies all our six positive rules, but also expects some command-line
`parameters and uses an extensive user dialogue as well, we would not call it a virus.
`
`So far so good. Looks like we found a solution to the virus glut problem, right? Not reaJly! Unfortunately,
`not all virus writers are stupid. Some are also well aware of heuristic analysis, and some of their viruses are
`written in a way which avoids the most obvious positive heuristics. On the other hand, these viruses include
`otherwise useless pieces of code, the only aim of which is to trigger the most obvious negative heuristics, so
`that such a virus does not draw tbe attention of a l1euristical analyser.
`
`2.4 VIRUS DETECTION VS. FALSE ALARMS mADE-OFF
`Each heuristic scanner developer sooner or later comes to the point when it is necessary to make a decision:
`' Do I detect more viruses, or do I cause less false alarms?' The best way to decide would be to ask users
`what do they prefer. Unfortunately, the users' answer is: 'I want it all! 100 percent detection rate and no
`false alarms!' As mentioned above, this cannot be achieved. So, a virus detection versus false alarms trade(cid:173)
`off problem must be decided by the developer. It is very tempting to build the heuristic analyser to detect
`almost aU viruses, despite false alarms. After all, reviewers and evaluators who publish their tests results in
`magazines read by thousands of users world-wide, are testing just the detection rate. It is much more
`difficult to run a good false alarms test: there are gigabytes and gigabytes of non-virus software in the
`world, far more than there are viruses; and it is more difficult to get hold of all this software and to keep it
`for your tests. 'Not enough disk space' is only one of the problems. So, let's forget false alarms and
`negative heuristics and call a virus each and every program which happens to satisfy just some of our
`
`ViRUS BULLETJNCONFERENCEf:Jl995 Virus BulletinLtd,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
`wilhout the prior written permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1011 Page 7
`
`
`
`232 • GRYAZNOV: SCANNERS OF THE YEAR 2000: HEURJSTICS
`
`positive heuristics. This way we shall score top most points in the reviews. But what about the users? They
`normally run scanners not on a virus collection but on a clean disks. Thus, they won't notice our almost
`perfect detection rate, but are very likely to notice our not-that-perfect false alarms rate. Tough choice.
`That's why some developers have at least two modes of operation for their heuristical scanners. The default
`is the so-called ' normal' or' low sensitivity' mode, when both positive and negative heuristics are used and
`a program needs to trigger enough positive heuristics to be reported as a virus. In this mode, a scanner is
`less prone to false alarms, but its detection rate might be far below what is claimed in its documentation or
`advertisement. The often-used (in advertising) figures of ' more than 90 per cent' virus detection rate by
`heuristic analyser refer to the second mode of operation, which is often called 'high sensitivity' or
`'paranoid' mode. It is really a paranoid mode: in this mode, negative heuristics are usually discarded, and
`the scanner reports as a possible virus any program which happens to trigger just one or two positive
`heuristics. In this mode, a scanner can indeed detect 90 per cent of viruses, but it also produces hundreds
`and hundreds of false alarms, making the "paranoid' mode useless and even harmful for real-life everyday
`use, but still very helpfu l when it comes to a comparative virus detection test. Some scanners have a special
`command-line option to switch the paranoid mode on; some others switch to it automatically whenever they
`detect a virus in the normal low sensitivity mode. Although the latter approach seems to be a smart one, it
`takes just a single false alarm out of many thousands of programs on a network file server to produce an
`avalanche offalse virus reports.
`
`2.5 HOW IT ALL WORKS IN PRACTICE: DIFFERENT SCANNERS COMPARED
`
`Being myself an anti-virus researcher and working for a leading anti-virus manufacturer, I have developed a
`heuristic analyser of my own. And of course, I could not resist comparing it to other existing heuristic
`scanners. We believe the results will be interesting to other people. They underscore what was said about
`both virus detection and false alarms rates. As the products tested are our competitors, we decided not to
`publish their names in the test results. So, only FindVirus of Dr Solomon's AntiVirus Toolkit is called by its
`real name. All the other scanners are referred to with letters: Scanner_A, Scanner_B, Scanner_C and
`Scanner_D. The latest versions of the scanners available at the time of the test were used. For Find Virus, it
`was version 7.50- the first version to employ a heuristic analyser.
`
`Each scanner tested was run in heuristics-only mode, with normal virus signature scanning disabled. This
`was achieved by either using a special command-line option, where available, or using a special empty virus
`signature database in other cases.
`
`The test consisted of two parts: virus detection rate and false alarms rate. For the virus detection rate S&S
`International Pte ONE OF EACH virus collection was used, containing more than 7,000 samples of about
`6,500 different known DOS viruses. For tile false alanns test the shareware and freeware software collection
`ofSIMIEL20 CD-ROM (fully unpacked), all utilities from different versions ofMS-DOS, IBM DOS,
`PC-DOS and other known files were used (current basic S&S false alarms test set).
`
`)
`
`When measuring false alarms and virus detection rate, all files reported were coun