November 199 1
`
`ISSN 0956-9979
`
`TTl \ T Tn
`
`BULLET IN
`
`T H E AUTHORITATIVE INTERNAT IONAL PUBLICATION
`ON COMPUTER VIRUS PREVENTION,
`RECOGNITION AND REMOVAL
`
`Editor: Edward W ilding
`
`Technical Editor: Ft·idl"ik S kulnson
`
`Editorial Advisors: Jim Bates, Oates Associates. UK, Phil Crt we, Fingerprint, UK, David Ferbr11che, Defence Research Agency, UK, Ray Glath, RG Software
`Inc., USA, Hans Gliss, Oatenschutz Bemter, West Gennany, Ross M. Green bug, Software Concepts Design, USA, Dr. Harold Jose ph Highland, Compulit
`Microcomptner Security Evaluation Laboratory, USA, Dr. Jan llr nska, Sophos, UK, Or. Keith Jackson, Walsham Contracts, UK, Owen Keane, Barrister,
`UK, J ohn Laws, Defence Research Agency, UK, David T . Lindsay, Digital F_quipment Corporation, UK, Yisrael Rndai, Hebrew University of Jerusalem,
`lsruel, Martin Sa mocivk, Network Security Management, UK, J ohn Sherwood, Sherwood Associates, UK, Prof. E ugene Spafford, Purdue University, USA,
`Dr. Peter Tippett, Certus International Corporation, USA, Dr. Ken Wong, PA Consultmg Group, UK, Ken van Wyk, CERT, USA.
`
`CONTENTS
`
`EDITORIAL
`
`TECHNICAL NOTES
`
`KNOWN IBM PC VIRUSES
`(UPDATE)
`
`TOOLS & TECHNIQUES
`
`Virus Verification and Removal
`
`VIRUS ANALYSES
`
`I . DJR 11 - The Much Hyped
`' Linking' Virus
`
`2. Music Bug
`
`3. Form
`
`2
`
`3
`
`5
`
`7
`
`11
`15
`
`16
`
`FIAT LUX
`
`A Pervading Myth: The ' CMOS
`Virus'
`
`17
`
`ON COMPUSERVE
`
`Troublesome Concubines in the
`Anti-Virus Harem
`
`18
`
`SCANNER TACTICS
`
`Living Together - Without
`False Alarms!
`
`PRODUCT REVIEW
`
`Virus Buster
`
`E ND-NOTES & NEWS
`
`19
`
`20
`
`24
`
`VIRUS DULLETIN ©1991 Virus Bulletin Lrd, 21 The Quad rani, Abingdon Scient< Park, Oxon, OX 14 3YS, Enghmd. Trl (+44) 235 555139.
`/90/$0.00+2.50 This bulletin tsavailable only to qualified subscribers No part of thi$ publication may be reproduced, stored in a retrieval system, or transmtrted
`by any fonn or by any means. electronic. rnagnetic. opt teal or photO<:opying, without the prior written JNrnHssion of the publishers
`
`PALO ALTO NETWORKS Exhibit 1031 Page 1
`
`

`
`Page2
`
`VJRUS BULLETIN
`
`November 1991
`
`EDITORIAL
`
`A Little Knowledge is a Dangerous Thing
`
`'Give a child a hammer and all of a sudden things around him
`will start looking like nails.' (Anon.)
`
`No MIS or DP manager in his right mind would hand out The
`Norton Ulililies to all PC users regardless of their need or
`ability to use such powerful and potentially destructive
`software. The misuse of Norton (or PC Tools or any other
`powerful disk editor) could cause untold damage if its
`distribution were not limited to technically competent staff.
`
`Neither would it be wise to instruct general users as to the
`existence or nature of certain of the more dangerous DOS
`commands - most PC users in business run a limited set of
`applications (text editors, spreadsheets, databases and DTP
`being prevalent) and can remain happily oblivious to such
`two-edged swords as FORMAT and FDJSK Even the humble
`delete command dons a perplexing mantle when combined
`with those cheeky wildcard characters '*.• '1 Obviously, all of
`the DOS commands are thoroughly outlined in the user
`manual- be it from Microsoft or IBM or Digital Research. It
`is fortuitous in this instance, therefore, that people rarely, if
`ever, refer to manuals while using software - this is one of the
`major reasons why software developers employ 'walk-thru'
`menus. The information and resources to cause untold
`accidental damage arc readily available wiU1in DOS itself but
`are not clearly signposted as such.
`
`The point here is tlmt handing out powerful security and audit
`tools to the masses, and providing superficial education about
`the operating system to people who don't need that informa(cid:173)
`tion, is a recipe for disaster. Instructions to use security tools
`and techniques should be on a ' need to know' basis- PC
`Support should know the exact locations of all such software
`and its distribution should be extremely limited.
`
`In the case of anti-virus software, many packages aim to
`provide comprehensive virus detection and removal facilities.
`'Toolkit' utilities of this sort provide programs to replace boot
`sectors, edit specific areas of disk and even write protect
`drives. Is it wise to place such power in the hands of users?
`Even a simple scanner becomes a complex beast when you
`examine the number of menu driven or command line options
`that many developers have provided. Can PC Support be sure
`that users will comply with their ex-calhedra statement to
`boot from a write-protected system Jloppy disk? Do users
`know what such a disk is, or why they should use it, or how to
`prepare it? Do they even know the difference between drive
`A: and drive C:?
`
`It is sometimes difficult for technicians to appreciate the
`relative ignllrance of non-technicians- many developers of
`security software still believe that mass populations can be
`
`trained to usc their products correctly and effectively. More
`seasoned and forward-thinking observers knew a long time
`ago thot this belief was nothing more than a pipe dream.
`Given that it takes a massive and concerted effort to educate
`users in the most basic aspects of corporate security, training
`a mass community in the use of relatively complex software
`security packages is a wholly untenable objective.
`
`Security managers in many organisations rightly conclude that
`they are simply not prepared to trust end-users with any
`degree of technical responsibility when it comes to combating
`computer viruses. As a result, the tools and techniques for this
`job are restricted to those capable of using them. This is an
`elitist rather than populist approach - conside1·ing the wealth
`of accumulated ignorance in any society it is entirely under(cid:173)
`standable and well conceived. This is not to belittle education;
`if a problem can be explained in simple, straightforward and
`readily understood terms then that is all to the good. However,
`there is an enormous divide between understanding the basic
`tenets of a problem and proficiency in dealing with it!
`
`The strategy which is most effective and which bas been
`widely adopted combines three elements: centra/ reporling;
`specialist response /eams (variously known as PC SWAT or
`CERT, or simply PC Support) and risk analysis. Central
`reporting effectively channels all enquiries and problems to
`the SWAT team - qualified technicians who have studied the
`virus problem and who are supplied with the requisite
`information and tools to deal with any outbreak both swiftly
`and correctly. Risk analysis is the process of identifYing the
`' mission criticnl' machines within the organisation. TI1ese arc
`the machines from which any loss of availability or integrity
`would have a serious impact on the overall performance of the
`organisation. A risk analysis of any organisation usually
`shows that 'mission critical' PCs comprise a relatively small
`percentage of overall IT resources. Jt is vital, however, that
`these PCs are adequately protected and this may necessitate
`the purchase of suitable defensive software.
`
`One questionable strategy is that of equipping every single PC
`with defensive software. This may be necessary in high
`security environments but imposes burdens in tenns of
`financial outlay, support costs and inconvenience. Memory(cid:173)
`resident software may well cause memory clashes (with
`Windows 3.0 or SHARE. COM tor example), lalse alanns and
`is critically dependent on user-compliance. Checksumming
`software needs careful implementation and management -
`particularly in an a shifting software enviromnenL Memory(cid:173)
`resident software is prone to subversion by stealth viruses as
`is checksumming software if it is mn in an infected DOS
`environment. Monitors and checksummers can be adminis(cid:173)
`tered - but not on 5,000 PCs in 60 or 70 locations!
`
`Ultimately. put the diagnostic tools in capable hands and
`purchase defensive software on the basis of considered risk
`cmalysis. Finally, make friends with Symantec and the
`Federation Against Software Theft ... locate all unauthorised
`copies of The Norton Ulilities and delete them!
`
`VIRUS BULLETIN C t991 Virus Bullelin Lid, 21 Tht Quadr•nl, Abingdon Sd t nre Park, Oxon, OXI4 3YS, England. Tel (+44) 235 555139.
`/90/S0.00+2.50 This bulletin is available only to qtk11ified subscnbers. No par t ofthos publication may be reproduced, stored in a retrieval system, or lransrnrtted
`by any form tlr by any means, electronic, magnetic, optical or photocopyrng, wothout the pro or wntten perm ission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1031 Page 2
`
`

`
`November 199 1
`
`VIRUS BULLETIN
`
`Page3
`
`TECHNICAL NOTES
`
`Norton and The Cascade Message
`
`In recent months VB and various anti-virus software manufac(cid:173)
`turers have received a number of calls concerning reports of
`'Cascade' by the System Information (SI) program supplied
`with Norton Utililie:; version 5.0. lltese spurious reports have
`nothing to do with the Cascade virus and do not imply
`infection by any virus.
`
`The confwing message is displayed by Sl in its list of
`hardware interrupts, as a description of IRQ2 and refers to the
`internal hardware of the PC.
`
`PC-ATs contain two 8259A hardware interrupt controller
`chips, each of which support eight system interrupts. The 8086
`family of microprocessors has a single line to communicate
`with the interrupt controllers, so TRQ2 on the {irst interrupt
`controller accepts interrupt requests from the second control(cid:173)
`ler. Thus the two controller chips are connected in a cascading
`manner - hence the 'Cascade' message.
`
`The actual Cascade virus has been the cause of various
`misinterpretations; the virus is also known as I 70 I which also
`happens to be a standard disk read error message! Perhaps
`Hailstonn, Fall, Autumn Leaves or one of the many other
`aliases for this virus should be adopted and standardised.
`
`FDISK /MBR
`
`Kevin Powis of Visionsoji has brought a little known and very
`useful feature of f/JJSK supplied with MS-DOS 5 to our
`attention. This feature will effectively remove many current
`viruses which infect the Master Boot Sector (Track 0, Head 0.
`Sector 1).
`
`If a PC running MS-DOS 5 is infected by such a vims, the
`user can boot !rom a clean write-protected system diskette
`upon which is stored a copy of FDJSK.
`
`The FD/SK program should then be run from the diskette
`drive. By typing FDISK /MBR at the A: prompt, clean Master
`Boot Sector code is written to the first physical sector on the
`hard disk. Moreover, when this FDISK option is invoked, all
`initialisation data in the 64 byte Partition Table stored in
`physical sector I is left completely intact.
`
`Note: this option should only be used if the Partition. Table
`in the first physical sector on the hard disk is present and
`correct after the Master Boot Sector has become infected.
`This may not necessarily be the case with future computer
`vimses. [Such viruses may already exist. Tech Ed.]
`
`Fortunately, most viruses which currently infect the Master
`Boot Sector do not tamper with the Partition Table.
`
`"lltis feature, combined with the ability of SYS to remove DOS
`Boot Sector viruses (those which inJect the boot sector of the
`active DOS partition), provides users of MS-OOS 5.00 with
`simple standard tools to remove most boot sector vimses
`without having to resort to formatting. This FDISK option is
`only available under MS-DOS version 5- it docs not apply to
`versions prior to 5.
`
`It is still recommended that a ll PC users store clean write(cid:173)
`protected backups of the boot sectors of their fixed disks
`on diskette.
`
`Non-Compliance
`
`Many resident scanners, monitors and standalone checksum(cid:173)
`ming programs provide the option for PC administrators to
`customise the screen message which appears when these
`programs detect virus activity. System administrators can thus
`instruct the user to contact the relevant PC Support desk and
`provide other information consistent with company policy.
`
`Unfortunately, a user of unauthorised or stolen software, upon
`seeing a virus alert reported on his screen may decide not to
`report the incident to PC Support, particularly so if company
`policy entails severe disciplinary actio.n for illicit software
`use. Subsequently such a user may attempt to disinfect his
`machine which may result in compounded damage.
`
`The problem of the non-compliant user is an extremely
`difficult one to solve. At the recent Sysguard 91 conference in
`London, Noel Bonczoscek of the Computer Crimes Unit
`suggested that developers of memory-resident software might
`consider incorporating a completely customised alert banner
`into their monitors - upon detecting a vi.rus the on-screen alert
`could thus be configured in such a way as not to arouse the
`suspicions of the ' untrustcd user'.
`
`This is an interesting suggestion which merits consideration.
`
`Using Virus Guard (from Dr. Solomon's Anti-Virus Toolkit)
`as a representative example, this resident monitor, upon
`detecting a virus, curremly flashes a message to screen which
`states prominently:
`
`Virus Alarm
`
`Or. Solomon's Anti-Virus Toolkit has Intercepted a
`virus:
`
`Cl ose everything down normally, then conslllt Too lkit.
`manual for remedy
`
`However, Bonc1:oscek said that PC administrators might
`prefer to configure 3 more subtle display along the lines of
`' lntemal Error: Do Not Proceed, Contact PC Support! Tel
`Extension 203 '.
`
`VIRUS BULLETIN ©1991 Virus Bulltl in Lid, 21 T he Quadrant, Abingdon Scitnct Park, Ox on, OX 14 3YS, Engt,.nd. Tel (+44) 235 555139.
`1901$0.00+2.50 This bulletin is avaolablc only 10 qualified subscnbers. No pan oflhis publica! ion may be reproduced, stored m a retrieval syslem, or trunsmmed
`by any form or by any mean!!, electronic, magnc1ic, optical or photocopying. withoul I he prior written permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1031 Page 3
`
`

`
`Page4
`
`VIRUS BULLETIN
`
`November 1991
`
`This banner would have no reference to a suspected virus
`attack or the anti-virus software that had detected such activity
`but would be sufficient to ensure that the more naive user
`contacted the appropriate support staff.
`
`This is only one suggested (and, to our knowledge, untested)
`proposal to encourage user-compliance. The potential pitfalls
`of such a tactic are readily apparent - not least the fact that a
`genuine operating system error would not direct the user to an
`' in house' telephone extension! Any user recognising this fact
`might well be capable of dealing with a virus attack in the first
`place!
`
`However, Bonczoszek's underlying point is that computer
`administrators should never assume that users will automati(cid:173)
`cally comply with company policy and report virus outbreaks
`or other incidents. (To quote Thomas Harris: 'Never assume
`anything- you'll make an ASS out of U and ME'). Compli(cid:173)
`ance auditing is one of the most complex tasks in computer
`security - making sure that people understand the rules and
`that they are following them is a formidable task and technical
`solutions do not lend themselves easily to it.
`
`Little wonder that the wisest and most experienced computer
`security managers don't allow users anywhere near detection
`and diagnostic software - they know that either it will not be
`used, or that it will be used incorrectly (often with dire
`results), or that alerts and warnings will simply be ignored!
`
`Rage Change
`
`An amended scan string to detect the Rage virus (VB, October
`1991, p. 2 1) has been supplied by Andrew Busey of Microcom
`Software Division Inc. The scan string contains no addresses
`and should be used in preference to either of the previously
`published patterns.
`
`Rage B9FD 01SA 2451 SACS D2C4 59SS 24FE C046
`
`Nobbled Nibble
`
`A one-nibble error in the search pattern published for the
`Liberty virus in last month's VB effectively invalidated the
`string. An amended and corrected pattern appears below.
`
`Liberty
`
`8931 2S33 D2CD 1306 BB5C 0653 CB2E
`803E BC06 OA74 4633 COSE
`
`Anti-virus software developers should take note that the
`original pattern for this virus (last published in July 1991)
`should be maintained as essential scan data. This pattern was
`extracted from an earlier version of the virus which is not
`consistently detected by the pattern above. The pattern is
`repeated here:
`
`Liberty
`
`0174 031F 5958 5053 5152 1E06 1EOE
`1FES
`
`VIRUS BULLETIN
`EDUCATION, TRAINING
`AND
`AWARENESS PRESENTATIONS
`
`Education, training and awareness are essential as
`part of an integrated campaign to minimise the
`threat of computer viruses and Trojan horses
`
`Virus Bulletin has prepared a presentation de(cid:173)
`signed to inform users and/or line management
`about this threat and the measures necessary to
`minimise it. The standard presentation consists of
`a ninety minute lecture supported by 35mm
`slides, fo llowed by a question and answer ses(cid:173)
`sion.
`
`Throughout the presentation, technical jargon is
`kept to a minimum and key concepts are ex(cid:173)
`plained in accurate but easily understood lan(cid:173)
`guage. However, a fami liarity with basic MS(cid:173)
`DOS functions is assumed. The presentation can
`be tailored to comply with individual company
`requirements and ranges from a basic introduc(cid:173)
`tion to the subject (suitable for relatively inexpe(cid:173)
`rienced users) to a more detailed examination of
`technical developments and available counter(cid:173)
`measures (suitable for MIS departments).
`
`The aim of the basic course is to increase user
`awareness about computer viruses and other
`malicious software without inducing counterpro(cid:173)
`ductive 'paranoia' . The threat is explained in
`comprehensible terms and straightforward,
`proven and easily-implemented countermeasures
`are demonstrated. An advanced course, aimed at
`li ne management and DP staff, outlines various
`procedural and software approaches to virus
`prevention, detection and recovery.
`
`The presentations, are offered fi·ee of charge
`except for reimbursement of travel and any
`accommodation expenses incurred. Information
`is available fi·om the editor, Virus Bulletin, UK.
`Tel 0235 555 I 39.
`
`VIRUS BULLETIN ©1991 Virus Bulletin Ltd, 21 The Quadrant, Abingdon Scie nce Park, Oxon, OX14 3YS, England. Tel (+44) 235 555139.
`/90/$0.00+2.50 This bulletin is ava ilable only to qualified subscribers. No part of this publication may be reproduced. stored in a retrieval system, or transmitted
`by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1031 Page 4
`
`

`
`November 199 I
`
`VIRUS BULLETIN
`
`Page 5
`
`KNOWN IBM PC VIRUSES (UPDATE)
`
`Updates and amendments to the Virus Bulletin Table of Known IBM PC Viruses as of 20th October 199 1. Hexadecimal patterns may
`be used to detect the presence of the virus with a disk utility program, or preferably a dedicated virus scanner.
`
`Type Codes
`
`E~ EXE [iJes
`C=COM files
`M o Infects Ma~tcr l3(lol Sector (Track Q. Head 0, Sector I)
`R = Memory-resident after infection
`P = Companion virus
`
`D - Infects DOS Boot Sector (logical sector 0 011 disk)
`N =Not memory-resident atlcr infection
`L - Link virus
`
`864 - CN: This virus adds 864 bytes in front of the files it infects. Awaiting analysis.
`864
`8040 8449 8742 473A 2575 153A 7D01 7510 3A45 0275 08C6 4502
`1876 - CER: This 1876-byte virus is probably of Polish origin. Awaiting analysis.
`1876
`8ECO 33FF 33CO 89FF 7FFC F2AE 26F6 05FF 75F8 83C7 0388 072E
`Best Wishes-970 - CER: This virus is detected by the search pattern for the Attention virus, but not by the pattern for the Best
`Wishes-1024 virus. This variant is not able to infect .EXE files properly.
`Black Wizard - EN: A variant of the ' Old Yankee' virus and detected by the pattern for that virus, 11Jis variant is 205 1 bytes long and
`plays a different tune than the original virus, but is othetwise similar.
`Bulg;~rian 123 - CN: A simple 123-byte virus from Bulgaria, which does nothing but rcplicatc.lt may infect the same file repeatedly.
`Bulgarian 123
`8103 8054 F484 40CD 2184 3ECD 2184 4FCD 2173 AF8B 0001 FFE3
`Copmpl - CER. This is a III I (COM) or 1114 (EX.E) byte Polish variant of the Akuku virus. The name is derived from the following
`text, which can be found inside the virus 'Sony, I'm copmpletly dead' (sic). The only effect of the virus is to play a tune.
`Copmpl
`80E6 OF8A D680 FAOO 7407 SOFA OB76 0682 0284 OECD 218C CSBE
`Copyright - CN: A 1193-byte virus from East Europe, which contains a t3ke Award BIOS copyright message. Awaiting analysis.
`Copyright
`AB4A 75F2 E2EA 33CO CDl6 8800 0687 0733 C9B6 1882 4FCO 10E9
`DIR-U - LCER: A 1024-byte 'link' virus from Bulgaria. ' Infects' all COM and EXE files in each directory on a single pass. If the
`virus is resident, 'infected' COM and EX.E files can be disinfected by renaming their extensions. (VB, Nov 1991).
`DIR II
`8COO 06FF 06E8 0431 C98E D9C5 06C1 0005 2100 1E50 8430 E824
`DM-400 - CR: This 400-byte virus does not seem to do anything but replicate. It contains the tex t '(C)1990 DM'.
`OM-400
`80FC 4874 3380 FC56 7419 FE04 80FC 3D74 12FE 0480 FC3E 751C
`Europe '92 - CR: This 421-byte virus activates if the year is set to 1992, when it displays the message: 'Europe/92 4EVERI'
`Europe '92
`8450 CD21 SC08 488E D8C6 0600 OOSA 891E 0100 8916 0300 53B8
`Fake-VirX- CN: A 233-byte virus from Finland which activates on any Friday the 13th, when it displays the message 'VirX 3190'.
`Filke- VirX
`4088 D589 0600 CD2l 6801 575A S9CD 2164 3ECD 2188 0001 FFEO
`Gcrgana- CN: Four variants of the Gergana virus, which are longer than the original with improved error handling.
`Oergana-222
`BFBO FFB9 3000 F3A4 E9C6 FDSE 81C6 0001 BFOO 0189 DEOO F3A4
`Gergana - 300
`8F80 FFB9 3000 F3A4 E985 FDSE BlC6 0001 BFOO 0189 2C01 F3A4
`Gergana - 450
`BPSO PF89 3000 F3A4 E97E FDSE 81C6 0001 8FOO 01B9 C201 F3A4
`Gergana - 512
`BAOO FAB4 3FCD 21C3 6900 0284 40CD 21C3 6801 572E 880E 5001
`Gosia - CR: A 466-byte virus from Poland. It contains the text ' I ' Gosia'. ' is the ASCII character (03))
`Gosia
`0275 10AC 268A 2547 3AC4 7405 80CC 203A C4E2 EE9F 03F9 8810
`Gotch a - CER: Two related viruses from East Europe, 879 and 881 bytes long. They contain the text string: 'GOTCHA!'.
`Gotcha
`9C30 DADA 7428 80FC 3074 OA30 006C 7405 80FC 4875 1306 lE50
`Hero-394 - ER: Related to the 506-bytc Hero vi rus. but does not damage the files it infects. Awaiting analysis.
`Hero-394
`898A 0133 C08F 0002 0305 83C7 02E2 F929 069C 0388 0042 33C9
`Hungarian-482 - CR: This 482-byte vints from Hungary activates on November 7th. If an infected program is run on that date it will
`display the string 'Fonnat .. .' and proceed to format the hard disk.
`Hungarian- 482
`5603 F7AC OACO 740A DOES 840E 8307 CD10 E8Fl 8901 008A 8000
`
`VIRUS BULLETIN ~!199 1 Virus Bulletin Ltd, 21 The Qu•drant, Abingdon Science Pork, Ox on, OXJ4 3YS, England. Ttl (+~4) 235 555139.
`/90/$0.00+2.50 This bulletin is available only tO qualified subscribers. No pan of this publicauon may be reproduced, stored in a retrieval system, or tral1smincd
`hy any limn or by any means, electroniC, magnetic, optical or photocopying, without the prior written permission of the publishers
`
`PALO ALTO NETWORKS Exhibit 1031 Page 5
`
`

`
`Page 6
`
`VIRUS BULLETIN
`
`November 1991
`
`Iron Maiden- CN: A 636-byte vims, which contains the text ' IRON MAIDEN' near the end. It has not been fully analysed, but
`contains destructive code (!NT 26H calls). The original sample of this virus was also infected with the Polish Wl3-A virus.
`Iron Maiden
`2425 CD21 SFOE 1F88 8557 02A3 0001 BAAS 5902 8826 0201 841A
`Leningrad - CN: Two viruses, 600 and 543 bytes long, first reported in Leningrad (now St. Petersburg}, and probably written by the
`same author. The 600 byte variant has not been analysed, but the other variant will activate on any Friday the 13th, and display the
`message 'That could be a crash, crash, crash!'. These vimses were described last month as Sov I and Sov2.
`
`Murphy-Brothers - CER: A 2045-byte Murphy variant. Contains the text: 'Brothers in arms'. Detected by the HIV pattern.
`
`Omega - CN: A 440-byte virus from Finland. It overwrites the beginning of the first two hard disks, trashing the Partition Table.
`Omega
`805C AA89 7E2E 83EC 1589 1500 88FC 88F5 A4E2 FOES 1000 8915
`Path - CN: A 547-byte virus from East Europe, which searches the path for files to infect.
`Path
`8900 0057 8A07 8805 4347 E2F8 C605 OOSF 8801 43CD 21B8 0230
`PC-Fiu - CR: This 802-byte vims from Poland was made available with the original commented source code from the author. It
`seems to be intended to bypass three specific anti-virus programs, Flushot, Vstop and Virblock, but this has not been tested.
`PC-Flu
`501F 8800 0180 3FE9 7537 4380 3F15 7531 4380 3F05 7528 8800
`PC-Flu-2 - CER: A 2112-byte variant of the previous virus using self-modifying encryption. No simple search pattern is possible.
`
`Plovdiv, New Bulgarian 800 - CR: This virus is 800 bytes long, but the increase is hidden while the virus is active. It contains the text
`'(c) Damage inc.Ver 1.1, Plovdiv,1991 ', but has not been fully analysed yet.
`Plovdiv
`80E2 1F80 FA1E 7506 2681 6F1D 2003 0790 SASB EB02 CD32 559C
`Polish Color- CN: A simple 376-byte Polish virus, which does nothing but replicate.
`Polish Color
`018F 0000 8900 01F3 A45E 88C6 8FOO 0089 0001 F3A4 5E88 C605
`Polish Minimal-45- CN: An attempt to create the world's smallest virus. It overwrites the files it infects which cannot be disinfected.
`Polish-45
`0230 CD21 8808 8440 8AOO 01B1 2DCD 2184 3ECD 2184 4FE8 DCC3
`Polish Pixel - CN: Two Pixel variants from Poland, which contain cmde self-modifying code. They are 457 and 550 bytes long, and
`·
`detected by ~he Pixel-277 pattern.
`
`Rybka- CER: This is a variant of one of the Vacsina (TP-series) vimses. It may infect the same file over and over, increasing its size
`by 1344 bytes each time. Detected by the Vacsina pattern.
`
`Something- CR: A 658-byte virus, which attaches itself in front of .COM files. It appears destmctive, containing code to delete files.
`Something
`8808 89FF FFlE 5233 D22E 8E1E 8303 843F CD21 725F 3000 E873
`SVC-1740- CER: This 1740-byte virus is closely related to the 1689-byte variant (SVC 4.0) and is detected by the same pattern.
`
`SVC 5.0- CER: An improved version of the earlier SVC viruses, and fully 'stealth'. Awaiting analysis.
`SVC 5.0
`5606 86EO 35FF FFSE CODE 1F33 FF89 9908 FCF3 A607 5E74 03E9
`Vienna-726- CN: A 726-byte variant, detected by the Vienna (4) pattern.
`
`Vienna-Polish 634- CN: This modified version is detected by the Vienna (I) pattern.
`
`Vienna-776- CN: A 776-byte variant. A similar 757-byte variant has also been found. Awaiting analysis.
`Vienna- 776
`844E 8ADD.0003 0689 0300 CD21 EB04 844F CD2 1 7302 E89F 8884
`Vienna - 757
`844E 8A58 0003 0689 0300 CD21 E804 844F CD21 7302 E89F 8884
`Voronezh-370- CR: This virus is related to the Voronezh and USSR-600 viruses, perhaps their common ancestor.
`Voronezh - 370
`0500 0188 F08F 0001 FCSA 0434 B888 0546 47E2 F688 0001 50C3
`W13-C- CN: A minor modification of the 507-byte Wl3-B variant. The only modification is that this variant sets the month field to
`12, not 13, which makes all files created in December immune to infection. Detected by the W 13 pattern.
`
`W13-361 - CN: A member of the W13 group of Vienna-related viruses. It is detected by the W 13 pattern, but does not function
`properly, as infected programs (second generation) will never run. A 377-byte variant also exists which replicates without problems.
`
`Words - CER: A series of 4 Polish viruses, I 069, I 085, 1387 and 1503 bytes long. The two longest variants use self-modifying
`encryption, and no simple search pattern is possible for them. The other variants can be detected with the following pattern:
`Words
`8066 OEFE 5958 88C1 SESD 9DCF 5288 D6B4 409C 2EFF 1EOD OOSA
`Yankee-1150 and Yankee-1205- CER: Two stripped-down versions of the Yankee virus which only replicate.
`Yankee - 1150
`C858 5383 E844 C32E 808F 0100 0074 0681 FCFO FF72 E58C 0848
`Yankee - 1 202
`C858 5383 EB45 C32E 808F 0100 0074 0681 FCFO FF7 2 E58C 0848
`
`VIRUS BULLETIN ©1991 Virus Bulletin Ltd, 21 The Quadrant, Abingdon Scie nce Park, Oxon, OX14 3YS, England. Tel (+44) 235 555139.
`/90/$0.00+2.50 This bulletin is available only to qua l i tied subscribers. No part ofthis pub I ication may be reproduced, stored in a retrieval system, or transmitted
`by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written pern1ission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1031 Page 6
`
`

`
`November 1991
`
`VIRUS BULLETIN
`
`Page 7
`
`TOOLS & TECHNIQUES
`
`David M. Chess
`
`High Integrity Computing Laboratory
`IBM Thomas J. Watson Research Center
`Yorktown Heights, NY, USA
`
`Virus Verification and Removal
`
`The first line of defense against computer viruses consists of
`programs that detect that something is probably wrong. These
`include modification detectors, integrity shells, known-virus
`scanners, access-control programs, and similar things. Their
`main function is to alert the user of a machine that a virus,
`some virus, is probably present. The important thing is the
`alert; since something is likely to be wrong, the user should
`stop what he is doing, and take action to correct the problem.
`It doesn't matter much at this stage what the alert says; a first(cid:173)
`line anti-virus system that always said simply 'Something
`virus-like may be going on! ' would be sufficient for most
`environments, if it were usually right.
`
`Once the alert has been given and the infected system taken
`out of immediate contact with other systems, other kinds of
`software become important. Before we can decide how to
`clean up an infected system, and even where else to look for
`infection, we need to know exactly what the infection consists
`of. This paper is a description of one part of the second-line
`toolbox, the virus verifier (and remover).
`
`Virus Verifiers
`
`A virus verifier is a program that, given a file or disk that is
`probably infected with a given virus, determines with a high
`degree of certainty whether the virus is a known strain, or a
`new variant. This is, of course, important to know: if the virus
`is different from any known strain, it will have to be analyzed
`for new effects before we can be confident that we know just
`what to do to clean up after it.
`
`On the other hand, if the virus is identical to a known strain,
`we already know what to do. It is pa11icularly important to
`perform verification in a program that attempts to remove the
`virus infection from an object automatically, restoring it to its
`original uninfected form .
`
`In abstract, a verifier is a program that, given another program
`as input, determines whether or not the given program is part
`ofthe set of possible 'offspring' of a particular virus. For
`many classes of viruses, including all the viruses actually
`widespread at the moment, this is easy to do. Almost all
`known viruses consist almost entirely of code that does not
`change from infection to infection, except perhaps for a
`
`simple XOR-type garbling, and data areas that are either
`constant, or change in si mple ways (or that can be ignored
`entirely for the purposes of verification).
`
`Given a suspect file F and a known virus V, it is therefore
`always relatively simple to answer the question ' is Fa file that
`could have been produced by infection with virus V?'. It is an
`open question of some theoretical interest whether or not
`some future virus might make this harder to do! Reliably
`determining whether a file is infected with any virus at all is
`of course known to be impossible, but we have no similar
`constraint on determining the presence of a specific virus.
`
`Trade-offs and Development Decisions
`
`There are various concrete decisions and trade-offs involved
`in writing a virus verifier; this section will list a few of them,
`while the next sections will describe the verifier currently
`being developed and used at the High Integrity Computing
`Laboratory at IBM's Watson Research Center.
`
`A verifier may be an independent tool, or it may be integrated
`into a virus detector. An integrated detector/verifier can be
`quicker and more convenient, since there's no need for a user
`to find and run a verifier once the detector goes off. On the
`other hand, since most copies of any virus detector will never
`in fact detect a virus (most of the world's computers are not
`infected, after all), integrating a verifier along with the
`detector is in some sense inefficient,