home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / computer-virus / faq next >
Encoding:
Internet Message Format  |  2001-07-18  |  159.3 KB

  1. Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
  2. Message-ID: <computer-virus/faq_995366276@rtfm.mit.edu>
  3. Supersedes: <computer-virus/faq_992768608@rtfm.mit.edu>
  4. Expires: 30 Aug 2001 10:37:56 GMT
  5. From: "Nick FitzGerald" <n.fitzgerald@csc.canterbury.ac.nz>
  6. Newsgroups: comp.virus,comp.answers,news.answers
  7. Subject: VIRUS-L/comp.virus Frequently Asked Questions (FAQ) v2.00
  8. Followup-To: comp.virus
  9. Organization: Virus-L/comp.virus moderator
  10. Approved: news-answers-request@MIT.Edu
  11. Reply-To: <VIRUS-L@Lehigh.edu>
  12. Summary: This posting contains a list of Frequently Asked Questions,
  13.          and their answers, about computer viruses.  It should be read
  14.          by anyone who wishes to post to VIRUS-L/comp.virus.
  15. X-Last-Updated: 1995/09/10
  16. Originator: faqserv@penguin-lust.MIT.EDU
  17. Date: 17 Jul 2001 10:39:49 GMT
  18. Lines: 3162
  19. NNTP-Posting-Host: penguin-lust.mit.edu
  20. X-Trace: 995366389 senator-bedfellow.mit.edu 1910 18.181.0.29
  21. Xref: senator-bedfellow.mit.edu comp.virus:31034 comp.answers:46271 news.answers:211552
  22.  
  23. Archive-name: computer-virus/faq
  24. Last-modified:  9 October 1995, 11:00 AM NZD
  25.  
  26. -----BEGIN PGP SIGNED MESSAGE-----
  27.  
  28.  
  29.             Frequently Asked Questions on Virus-L/comp.virus
  30.  
  31.                               Release 2.00
  32.  
  33.                Last Updated:  9 October 1995, 11:00 AM NZD
  34.  
  35.  
  36.  
  37. =========================
  38. = Using this FAQ sheet: =
  39. =========================
  40.  
  41.  
  42. This document is intended to answer some Frequently Asked Questions
  43. (FAQs) about computer viruses.  This FAQ sheet has been compiled by some
  44. of the main contributors to the Virus-L mailing list and its USENET news
  45. fan-out, comp.virus.  The Preface Section (below) explains the multi-
  46. part nature of the FAQ sheet and how to ensure you have "the genuine
  47. article", and gives details on version numbers and contacting the
  48. authors with questions and suggestions.  If you are seeking help after
  49. discovering what you suspect is a virus on your computer, read the
  50. Preface Section, skim through Sections A and B for the essential jargon,
  51. then concentrate on Section C.
  52.  
  53. If you feel that you may have found a new virus, or are not quite sure
  54. if some file or boot sector is infected, please refer to Section F
  55. Question #4 (F4) before posting a request for assistance.  The answer to
  56. this question has been developed to ensure new readers of Virus-L/
  57. comp.virus understand the protocol for raising such questions and to
  58. help them avoid asking questions that can be answered in this document.
  59. If you are looking for help in designing and implementing an antivirus
  60. policy or system, read all of Sections B through F inclusive, paying
  61. particular attention to Section D.
  62.  
  63. Please read the full list of questions carefully--as with most complex
  64. topics, dozens of different virus-related questions turn out to be about
  65. similar phenomena.  If you don't find your exact question here, look
  66. closely at the ones that seem vaguely similar.
  67.  
  68. Above all, remember that the time to really worry about viruses is
  69. *before* your computer gets one!
  70.  
  71.  
  72. ====================
  73. = Preface Section: =
  74. ====================
  75.  
  76. The Virus-L/comp.virus FAQ sheet is normally posted to on-line services
  77. and sent via e-mail in one of two forms:  As a single, large (>160KB)
  78. file, or in four separate pieces.  Either or both of these forms may be
  79. available for download from FTP sites and BBSes.
  80.  
  81. The one-piece FAQ sheet should be available in a file called
  82. vlfaqxyy.txt, where "xyy" is the current version number (starting from
  83. 200 in mid-1995 for version 2.00).  The multi-part version is created by
  84. splitting the main FAQ sheet into four pieces as follows:
  85.  
  86.     Filename          Contains
  87.                     FAQ Sections
  88.    ==============================
  89.     vlfxyy-1.txt       A & B
  90.     vlfxyy-2.txt       C & D
  91.     vlfxyy-3.txt       E & F
  92.     vlfxyy-4.txt       G
  93.  
  94. (with "xyy" again representing the current version number).  Please do
  95. not make your own multi-part FAQ, as each of the parts in the "official"
  96. multi-part version include additional preface information.
  97.  
  98. Either or both versions may also be available in some form of compressed
  99. archive--in this case the "name part" of the filename should be the same
  100. as the original file with the extension being replaced (or appended) as
  101. appropriate for the archiving method used.  Please *do not* repackage
  102. the multi-part FAQ into one large archive file, as this defeats the sole
  103. purpose for creating it--to ensure that the FAQ sheet is "officially"
  104. available in a readable form that will pass unmolested through most
  105. e-mail gateways.
  106.  
  107. All the files in either version of the FAQ sheet are signed with Nick
  108. FitzGerald's PGP key.  Nick's public key can be retrieved from the main
  109. PGP key servers.  If you do not know what PGP is, but wish to validate
  110. your copy of the FAQ sheet, you should read the USENET newsgroup
  111. alt.security.pgp [please do *not* e-mail me, as I am not a PGP expert--
  112. FAQ maintainer].
  113.  
  114. The FAQ sheet is a dynamic document, changing as people's questions
  115. change.  The version number also changes as *any* changes are made.
  116. Version numbers containing a "d" are drafts and should *not* be made
  117. publicly available, nor distributed.  We ask for your cooperation in
  118. deleting and not further distributing "d" versions of the FAQ sheet.  If
  119. you have any questions or contributions, please e-mail them to the FAQ
  120. sheet maintainer, Nick FitzGerald, at:
  121.  
  122.    n.fitzgerald@csc.canterbury.ac.nz
  123.  
  124. The most recent copy of the FAQ sheet will always be available on the
  125. Virus-L/comp.virus archives, including by anonymous FTP on corsa.ucr.edu
  126. (IP = 138.23.166.133) in the directory pub/virus-l.
  127.  
  128. A WWW version of the FAQ sheet, with cross-references and file links is
  129. currently under development, as is a WinHelp version with cross-
  130. references (if you would like to assist with these efforts, or to port
  131. one of these formats to another popular hypertext help format, please
  132. contact the FAQ sheet maintainer so we can better coordinate this work).
  133.  
  134. In various places the FAQ sheet mentions products by name.  This is
  135. usually only for illustrative purposes.  Such references should *not* be
  136. taken to imply that all, some, or any of the contributors to this FAQ
  137. sheet endorse any such product for any purpose or that such products are
  138. the *best* examples of what is being discussed.  Such refernces are
  139. usually because the products named were the first to implement a
  140. particular feature or function.  Further, that a given product is *not*
  141. mentioned in the FAQ should not be taken as an indication of its quality
  142. or suitability for any task.
  143.  
  144. Various brand and product names are used throughout the FAQ sheet--these
  145. remain trademarks or registered trademarks of their respective holders.
  146.  
  147. Unless indicated otherwise, prices are given in US dollars and should be
  148. taken as guides only.  Telephone numbers include an indication of the
  149. time-zone relative to GMT--some of these are very approximate, but
  150. should be close enough to save you ringing in the middle of the
  151. receiver's night!
  152.  
  153.  
  154.  
  155. Nick FitzGerald, Virus-L/comp.virus FAQ sheet maintainer.
  156.  
  157.  
  158. ================================================
  159. = Primary contributors (in alphabetical order) =
  160. ================================================
  161.  
  162. The following people have provided significant content and/or editorial
  163. input to this FAQ sheet:
  164.  
  165.      Mark Aitchison <m.aitchison@phys.canterbury.ac.nz>
  166.      Vaughan Bell <vaughan@computing-department.poly-south-west.ac.uk>
  167.      Claude Bersano-Hayes <hayes@urvax.urich.edu>
  168.      Matt Bishop <matt.bishop@dartmouth.edu>
  169.      Vesselin Bontchev <bontchev@complex.is>
  170.      Bruce Burrell <bpb@us.itd.umich.edu>
  171.      David Chess <chess@watson.ibm.com>
  172.      John-David Childs <con_jdc@lewis.umt.edu>
  173.      Olivier M. J. Crepin-Leblond <o.crepin-leblond@ic.ac.uk>
  174.      Nick FitzGerald <n.fitzgerald@csc.canterbury.ac.nz>
  175.      Richard Ford <virusbtn@vax.ox.ac.uk>
  176.      Alan Glover <aglover@acorn.co.uk>
  177.      Sarah Gordon <sgordon@dockmaster.ncsc.mil>
  178.      Yaron Y. Goland <ygoland@seas.ucla.edu>
  179.      Mikko Hypponen <mikko.hypponen@datafellows.fi>
  180.      John Kida <john_kida@ins.com>
  181.      Kevin Marcus <datadec@cs.ucr.edu>
  182.      Anthony Naggs <tony@vps.cis.co.za>
  183.      Donald G. Peters <Peters@Dockmaster.NCSC.Mil>
  184.      A. Padgett Peterson <padgett%tccslr.dnet@mmc.com>
  185.      Y. Radai <radai@hujivms.huji.ac.il>
  186.      Brian Seborg <bseborg@fdic.gov>
  187.      Fridrik Skulason <frisk@complex.is>
  188.      Rob Slade <roberts@decus.ca> or <rslade@sfu.ca>
  189.      Gene Spafford <spaf@cs.purdue.edu>
  190.      Otto Stolz <rzotto@nyx.uni-konstanz.de>
  191.      Ken van Wyk <krvw@assist.mil>
  192.  
  193. ====================
  194.  
  195.              Questions answered in this document
  196.  
  197. Section A:   Sources of Information and Antivirus Software
  198.              (Where can I find HELP?!!)
  199.  
  200. A1)  What is Virus-L/comp.virus?
  201. A2)  What is the difference between Virus-L and comp.virus?
  202. A3)  How do I get onto or off Virus-L/comp.virus?
  203. A4)  What are the guidelines for Virus-L?
  204. A5)  How can I get back-issues of Virus-L?
  205. A6)  What are the known viruses, their names, major symptoms and
  206.      possible cures?
  207. A7)  Where can I get free or shareware antivirus programs?
  208. A8)  Where can I get more information on viruses, etc?
  209. A9)  Why is so much of the discussion in Virus-L/comp.virus about PCs
  210.      and DOS?  Is this forum only for the PC world?
  211.  
  212.  
  213. Section B:   Definitions
  214.              (What is ...?)
  215.  
  216. B1)  What are computer viruses (and why should I worry about them)?
  217. B2)  What is a Worm?
  218. B3)  What is a Trojan Horse?
  219. B4)  What are the main types of PC viruses?
  220. B5)  What is a stealth virus?
  221. B6)  What is a polymorphic virus?
  222. B7)  What are "fast" and "slow" infectors?
  223. B8)  What is a sparse infector?
  224. B9)  What is a companion virus?
  225. B10) What is an armored virus?
  226. B11) What is a cavity virus?
  227. B12) What is a tunnelling virus?
  228. B13) What is a dropper?
  229. B14) What is an ANSI bomb?
  230. B15) Miscellaneous Jargon and Abbreviations
  231.  
  232.  
  233. Section C:   Virus Detection
  234.              (Is my computer infected?  What do I do?)
  235.  
  236. C1)  What are the symptoms and indications of a virus infection?
  237. C2)  What steps should be taken in diagnosing and identifying viruses?
  238. C3)  What is the best way to remove a virus?
  239. C4)  What does the <insert name here> virus do?
  240. C5)  What are "false positives" and "false negatives"?
  241. C6)  Can an antivirus program itself be infected?
  242. C7)  Where can I get a virus scanner for my Unix system?
  243. C8)  Why does my scanner report an infection only sometimes?
  244. C9)  I think I have detected a new virus; what do I do?
  245. C10) CHKDSK reports 639K (or less) total memory on my system; am I
  246.      infected?
  247. C11) I have an infinite loop of sub-directories on my hard drive; am I
  248.      infected?
  249. C12) Can a PC not running DOS be infected with a common DOS virus?
  250. C13) My hard-disk's file system has been garbled:  Do I have a virus?
  251.  
  252.  
  253. Section D:   Protection Plans
  254.              (What should I do to prepare against viruses?)
  255.  
  256. D1)  What is the best antivirus program?
  257. D2)  Is it possible to protect a computer system with only software?
  258. D3)  Is it possible to write-protect the hard disk with software only?
  259. D4)  What can be done with hardware protection?
  260. D5)  Does setting a file's attributes to READ ONLY protect it from
  261.      viruses?
  262. D6)  Do password/access control systems protect my files from viruses?
  263. D7)  Do the protection systems in DR DOS work against viruses?
  264. D8)  Does a write-protect tab on a floppy disk stop viruses?
  265. D9)  Do local area networks (LANs) help to stop viruses or do they
  266.      facilitate their spread?
  267. D10) What is the proper way to make backups?
  268.  
  269.  
  270. Section E:   Facts and Fibs About Computer Viruses
  271.              (Can a virus...?)
  272.  
  273. E1)  Can boot sector viruses infect non-bootable DOS floppy disks?
  274. E2)  Can a virus hide in a PC's CMOS memory?
  275. E3)  Can a PC virus hide in Extended or in Expanded RAM in a PC?
  276. E4)  Can a virus hide in a PC's Upper Memory or its High Memory Area?
  277. E5)  Can a virus infect data files?
  278. E6)  Can viruses spread from one type of computer to another?
  279. E7)  Are mainframe computers susceptible to computer viruses?
  280. E8)  Some people say that disinfecting files is a bad idea.  Is that
  281.      true?
  282. E9)  Can I avoid viruses by avoiding shareware, free software or games?
  283. E10) Can I contract a virus on my PC by performing a "DIR" of an
  284.      infected floppy disk?
  285. E11) Is there any risk in copying data files from an infected floppy
  286.      disk to a clean PC's hard disk?
  287. E12) Can a DOS virus survive and spread on an OS/2 system using the
  288.      HPFS file system?
  289. E13) Under OS/2 2.0+, could a virus infected DOS session infect another
  290.      DOS session?
  291. E14) Can normal DOS viruses work under MS Windows?
  292. E15) Can I get a virus from reading e-mail, BBS message forums or
  293.      USENET News?
  294. E16) Can a virus "hide" in a GIF or JPEG file?
  295.  
  296.  
  297. Section F:   Miscellaneous Questions
  298.              (I have heard...  I was just wondering...)
  299.  
  300. F1)  How many viruses are there?
  301. F2)  How do viruses spread so quickly?
  302. F3)  What is the correct plural of "virus"?  "Viruses" or "viri" or
  303.      "virii" or "vira" or...
  304. F4)  When reporting a virus infection (and looking for assistance), what
  305.      information should be included?
  306. F5)  How often should we upgrade our antivirus tools to minimize
  307.      software and labor costs and maximize our protection?
  308. F6)  What are "virus simulators" and what use are they?
  309. F7)  I've heard talk of "good viruses".  Is it really possible to use a
  310.      computer virus for something useful?
  311. F8)  Wouldn't adding self-checking code to your programs be a good idea?
  312.  
  313.  
  314. Section G:   Specific Virus and Antivirus Software Questions...
  315.  
  316. G1)  I was infected by the Jerusalem virus and disinfected the infected
  317.      files with my favorite antivirus program.  However, WordPerfect
  318.      and some other programs still refuse to work.  Why?
  319. G2)  Is my disk infected with the Stoned virus?
  320. G3)  I was told that the Stoned virus displays the text "Your PC is now
  321.      Stoned" at boot time.  I have been infected by this virus several
  322.      times, but have never seen the message.  Why?
  323. G4)  I was infected by both Stoned and Michelangelo.  Why has my
  324.      computer become unbootable?  And why, each time I run my favorite
  325.      scanner, does it find one of the viruses and say that it is
  326.      removed, but when I run it again, it says that the virus is still
  327.      there?
  328. G5)  My scanner finds the Filler and/or Israeli Boot virus in memory,
  329.      but after I boot from a clean floppy it reports no viruses.  Am I
  330.      infected?
  331. G6)  I was infected with Flip and now a large part of my hard disk
  332.      seems to have disappeared.  What has happened?
  333. G7)  What does the GenB and/or the GenP virus do?
  334. G8)  How do I "boot from a clean floppy"?
  335. G9)  My PC diagnostic utility lists "Cascade" amongst the hardware
  336.      interrupts (IRQs).  Does this mean I have the Cascade virus?
  337. G10) Occasionally the text "welcome datacomp" appears in my Mac
  338.      documents without me typing it.  Is this a virus?
  339. G11) How good are the antivirus tools included with MS-DOS 6?
  340. G12) When I do a "DIR | MORE", I see two files with random names that
  341.      are not there when I just use "DIR".  On my friends's system they
  342.      cannot be seen.  Do I have a virus?
  343. G13) What is the ChipAway virus?  (Or ChipAwayVirus?)
  344.  
  345.  
  346.  
  347. ===============================================================
  348. = Section A.   Sources of Information and Antivirus Software. =
  349. ===============================================================
  350.  
  351. A1)  What is Virus-L/comp.virus?
  352.  
  353. Virus-L and comp.virus are discussion forums which focus on computer
  354. virus issues.  More specifically, Virus-L is an electronic mailing list
  355. and comp.virus is a USENET newsgroup.  Both groups are moderated; all
  356. submissions are sent to the moderator who decides if a submission should
  357. be distributed to the groups.  For more information, including a copy of
  358. the posting guidelines, see the file virus-l.README, available by
  359. anonymous FTP on corsa.ucr.edu in the pub/virus-l directory.
  360.  
  361.  
  362. A2)  What is the difference between Virus-L and comp.virus?
  363.  
  364. Virus-L is a mailing list while comp.virus is a newsgroup.  Virus-L is
  365. distributed in "digest" format (with multiple e-mail postings in one
  366. large digest) and comp.virus is distributed as individual news postings.
  367. However, the content of the two groups is identical.
  368.  
  369.  
  370. A3)  How do I get onto or off Virus-L/comp.virus?
  371.  
  372. To subscribe to Virus-L, send e-mail to LISTSERV@LEHIGH.EDU saying "SUB
  373. VIRUS-L your-name".  For example:
  374.  
  375.   SUB VIRUS-L Jane Doe
  376.  
  377. To be removed from the Virus-L mailing list, send a message to
  378. LISTSERV@LEHIGH.EDU saying "SIGNOFF VIRUS-L".
  379.  
  380. To "subscribe" to comp.virus, simply use your favorite USENET news
  381. reader to read the group.
  382.  
  383.  
  384. A4)  What are the guidelines for Virus-L?
  385.  
  386. The posting guidelines are available by anonymous FTP on corsa.ucr.edu.
  387. Retrieve the file pub/virus-l/virus-l.README for the most recent copy.
  388. In general, however, the moderator requires discussions to be polite and
  389. non-commercial.  Objective postings of product availability, product
  390. reviews, etc, are fine, but commercial advertisements are not.  Requests
  391. for virus samples (binary or disassembly) are forbidden.  Technical
  392. discussions are strongly encouraged, however, within reason.
  393.  
  394.  
  395. A5)  How can I get back-issues of Virus-L?
  396.  
  397. Back-issues of Virus-L/comp.virus date back to the group's inception, on
  398. 21 April, 1988.  The anonymous FTP archive at cs.ucr.edu carries all of
  399. the Virus-L back issues.  Retrieve the file pub/virus-l/README for more
  400. information on the Virus-L/comp.virus archives.
  401.  
  402.  
  403. A6)  What are the known viruses, their names, major symptoms and
  404.      possible cures?
  405.  
  406. The reader should be aware that there is no universally accepted naming
  407. convention for viruses, nor is there any standard means of testing.  As
  408. a consequence nearly *all* virus information is highly subjective and
  409. open to interpretation and dispute.
  410.  
  411. There are several major sources of information on specific viruses.
  412. Probably the largest one is Patricia Hoffman's hypertext VSUM.  While
  413. VSUM is quite complete it only covers PC viruses and it is regarded by
  414. many in the antivirus field as being inaccurate, so we advise you not to
  415. rely solely on it.  It can be downloaded from most major archive sites.
  416.  
  417. A more precise source of information is the Computer Virus Catalog,
  418. published by the Virus Test Center in Hamburg.  It contains highly
  419. technical descriptions of computer viruses for several platforms: DOS,
  420. Mac, Amiga, Atari ST and Unix.  Unfortunately, the DOS section is quite
  421. incomplete.  The CVC is available by anonymous FTP from
  422. ftp.informatik.uni-hamburg.de (IP = 134.100.4.42), directory
  423. pub/virus/texts/catalog.  (A copy of the CVC is also available by
  424. anonymous FTP on corsa.ucr.edu in the directory pub/virus-l/docs/vtc.)
  425.  
  426. Another small collection of good technical descriptions of PC viruses,
  427. called CARObase is also available from ftp.informatik.uni-hamburg.de, in
  428. the directory /pub/virus/texts/carobase.
  429.  
  430. A fourth source of information is the monthly Virus Bulletin, published
  431. in the UK.  Among other things, it gives detailed technical information
  432. on viruses (see A8); a one year subscription, however, costs $395.  US
  433. subscriptions can be ordered by calling (203) 431 8720 (GMT-5/-4) or
  434. writing to 590 Danbury Road, Ridgefield, CT 06877; for European
  435. subscriptions, the number is +44 1235 555139 (GMT+0/-1) and the address
  436. is: 21 The Quadrant, Abingdon, OXON, OX14 3YS, ENGLAND.  General
  437. enquiries can be sent to virusbtn@vax.ox.ac.uk.
  438.  
  439. Another source of information is the book "Virus Encyclopedia" which is
  440. part of the printed documentation of Dr. Solomon's AntiVirus ToolKit (a
  441. commercial DOS antivirus program).  It is more complete than the CVC
  442. list and just as accurate; however it lists only DOS viruses.  This book
  443. may be available separately
  444.  
  445. The on-line help system of the shareware antivirus product Anti-Virus
  446. Pro contains a large and relatively exact collection of virus
  447. descriptions and even includes demonstrations of several of the audio
  448. and visual effects produced by some viruses. However the text can be
  449. difficult to read because English is not the author's native tongue.
  450.  
  451. The WWW site www.datafellows.fi has an on-line, cross-referenced
  452. database containing descriptions of about 1500 PC viruses, with an
  453. emphasis on viruses "in the wild".  Another network-accessible source of
  454. information pertaining to viruses is provided by IBM AntiVirus, at
  455. http://www.brs.ibm.com/ibmav.html or via gopher at the site
  456. index.almaden.ibm.com (choose "IBM Computer Virus Information Center"
  457. from the main menu).
  458.  
  459. An excellent source of information regarding Apple Macintosh viruses is
  460. the on-line documentation in the freeware Disinfectant program by John
  461. Norstad of Northwestern University.  This is available at most Mac
  462. archive sites.
  463.  
  464.  
  465. A7)  Where can I get free or shareware antivirus programs?
  466.  
  467. The Virus-L/comp.virus archive sites carry publicly distributable
  468. antivirus software products. Up-to-date listings of these antivirus
  469. archive sites are posted monthly to Virus-L/comp.virus (see A5 for
  470. details).
  471.  
  472. Many freeware/shareware DOS antivirus programs are available from the
  473. SimTel Software Repository.  This collection of software is available
  474. via anonymous FTP from ftp.coast.net (IP = 141.210.10.117), with
  475. antivirus software in the directory /SimTel/msdos/virus.  Note that the
  476. SimTel archive is "mirrored" at many anonymous FTP sites, including
  477. wuarchive.wustl.edu (IP = 128.252.135.4, /systems/ibmpc/simtel/virus),
  478. and nic.funet.fi (IP = 128.214.248.6, /pub/msdos/SimTel/virus).  Most of
  479. this software can also be obtained via e-mail in uuencoded form from
  480. various TRICKLE sites, especially in Europe.
  481.  
  482. Likewise, Macintosh antivirus programs can be found in /pub/tools/mac at
  483. coast.cs.purdue.edu.
  484.  
  485. A list of many antivirus programs, including commercial products and one
  486. person's rating of them, can be obtained by anonymous ftp from
  487. corsa.ucr.edu (IP = 138.23.166.33) in pub/virus-l/docs/reviews in the
  488. file slade.quickref.rvw.  This directory also contains detailed product
  489. reviews of many products.
  490.  
  491.  
  492. A8)  Where can I get more information on viruses, etc?
  493.  
  494. Five very good books on computer viruses that cover most of the
  495. introductory and technical questions you might have are:
  496.  
  497. "Computers Under Attack: Intruders, Worms and Viruses" edited by
  498.      Peter J. Denning, ACM Press/Addison-Wesley, 1990.  This is a
  499.      book of collected readings that discuss computer viruses,
  500.      computer worms, break-ins, and social aspects, and many other
  501.      items related to computer security and malicious software.  A
  502.      very solid, readable collection that doesn't require a highly-
  503.      technical background.  Price: $20.50.
  504.  
  505. "Rogue Programs: Viruses, Worms and Trojan Horses" edited by Lance
  506.      J. Hoffman, Van Nostrand Reinhold, 1990.  This is a book of
  507.      collected readings describing in detail how viruses work,
  508.      where they come from, what they do, etc.  It also has
  509.      material on worms, Trojan Horse programs, and other malicious
  510.      software programs.  This book focuses more on mechanism and
  511.      relatively less on social aspects than does the Denning book;
  512.      however, there is an excellent piece by Anne Branscomb that
  513.      covers legal aspects.  Price: $32.95.
  514.  
  515. "A Pathology of Computer Viruses" by David Ferbrache, Springer-
  516.      Verlag, 1992.  This is an in-depth book on the history,
  517.      operation, and effects of computer viruses.  It is one of the
  518.      most complete books on the subject, with an extensive history
  519.      section, a section on Macintosh viruses, network worms, and
  520.      Unix viruses.  Price $49.00.
  521.  
  522. "A Short Course on Computer Viruses", 2nd edition, by Dr. Fred B.
  523.      Cohen, Wiley, 1994.  This book is by a well-known pioneer in
  524.      virus research, who has also written dozens of technical
  525.      papers on the subject.  Price: $35.00 ($45.00 with
  526.      accompanying diskette).
  527.  
  528. "Robert Slade's Guide to Computer Viruses", by Robert Slade,
  529.      Springer-Verlag, 1994.  This book is a comprehensive
  530.      introduction to computer viruses, written in a clear and easy
  531.      style for non-experts.  Price $29.00.
  532.  
  533.  
  534. A somewhat dated, but still useful, high-level description of viruses,
  535. suitable for a complete novice with little computer background is
  536. "Computer Viruses: Dealing with Electronic Vandalism and Programmed
  537. Threats" by Eugene H. Spafford, Kathleen A. Heaphy, and David J.
  538. Ferbrache, ITAA (Arlington, VA), 1989.  ITAA (Information Technology
  539. Association of America) is a computer industry service organization and
  540. not a publisher.  While many people have indicated they find this a very
  541. understandable reference it is now out of print, but portions of it have
  542. been reprinted in many other places, including Denning and Hoffman's
  543. books (above).
  544.  
  545. It is also worth consulting various publications such as _Computers &
  546. Security_ and _SECURE Computing_ (both of which, while not limited to
  547. viruses, contain many relevant papers) and the _Virus Bulletin_
  548. (published in the UK, it contains many technical articles).
  549.  
  550.  
  551. A9)  Why is so much of the discussion in Virus-L/comp.virus about PCs
  552.      and DOS?  Is this forum only for the PC world?
  553.  
  554. No--neither the problem nor this discussion relate only to PCs.  Viral
  555. programs are a property of general-purpose computers, and therefore are,
  556. and will be, a problem for any computer system.  We *are* aware of the
  557. lopsided coverage and welcome the submission of material relevant to
  558. other systems.
  559.  
  560. There are several reasons for the apparent imbalance.  One very general
  561. reason is that users of DOS heavily outnumber the users of other
  562. operating systems.  The discussion in Virus-L/comp.virus therefore tends
  563. to have a preponderance of questions and chat about DOS specific
  564. infections and problems.  We welcome questions, comments and reports
  565. from users of other operating systems and platforms.  If you use a
  566. computer of another type, please do contribute to the discussion.  Just
  567. because the majority are talking about DOS does *not* mean that your
  568. contribution is not welcome.  It may be important precisely because you
  569. have a different perspective.
  570.  
  571. Therefore, let us assure you there is no deliberate attempt being made
  572. to exclude Amiga, Atari, Macintosh, OS/2, UNIX, VMS, Windows (NT, '95 or
  573. any other flavor) or any other platform or operating system from the
  574. discussion or the FAQ sheet.  If you feel that there *is* too much PC
  575. bias, please don't complain about it--tell us something about the virus
  576. situation on *your* system.
  577.  
  578.  
  579. ====================================================
  580. = Section B.   Definitions and General Information =
  581. ====================================================
  582.  
  583. B1)  What are computer viruses (and why should I worry about them)?
  584.  
  585. Fred Cohen "wrote the book" on computer viruses, through his Ph.D.
  586. research, dissertation and various related scholarly publications.  He
  587. developed a theoretical, mathematical model of computer virus behaviour,
  588. and used this to test various hypotheses about virus spread.  Cohen's
  589. formal definition (model) of a virus does not easily translate into
  590. "human language", but his own, well-known, informal definition is "a
  591. computer virus is a computer program that can infect other computer
  592. programs by modifying them in such a way as to include a (possibly
  593. evolved) copy of itself".  Note that a program does not have to perform
  594. outright damage (such as deleting or corrupting files) in order to be
  595. classified as a "virus" by this definition.
  596.  
  597. The problem with Cohen's human language definition is that it doesn't
  598. capture many of the subtleties of his mathematical model--as indeed, few
  599. informal definitions do--and questions arise that can only be answered
  600. by checking his formal model.  Using his formal definitions, Cohen
  601. classifies some things as viruses that most readers of Virus-L/
  602. comp.virus (and many experts) would not consider viruses.  For example,
  603. given certain circumstances on an IBM PC running DOS, the DISKCOPY
  604. program is classified as a virus by Cohen's formalisms.
  605.  
  606. This has led to some tension between what Cohen considers a "virus" and
  607. what is usually discussed on Virus-L.  Several other definitions of
  608. "virus" have been proposed, but it is probably fair to say that most of
  609. us are concerned about things that are viruses by the following
  610. definition:
  611.  
  612. A computer virus is a self-replicating program containing code that
  613. explicitly copies itself and that can "infect" other programs by
  614. modifying them or their environment such that a call to an infected
  615. program implies a call to a possibly evolved copy of the virus.
  616.  
  617. Probably the major distinction between Cohen's definition and "viruses"
  618. as we tend to use the word is that we see them as deliberately designed
  619. to replicate (although there is some debate over this too).  Cohen's
  620. definition does *not* require this (and this would be difficult to build
  621. into his formal model).
  622.  
  623. Note that many people use the term "virus" loosely to cover any sort of
  624. program that tries to hide its possibly malicious function and\or tries
  625. to spread onto as many computers as possible, though some of these
  626. programs may more correctly be called "worms" (see B2) or "Trojan
  627. Horses" (see B3).  Also be aware that what constitutes a "program" for a
  628. virus to infect may include a lot more than is at first obvious--don't
  629. assume too much about what a virus can or can't do!
  630.  
  631. These software "pranks" are very serious; they are spreading faster than
  632. they are being stopped, and even the least harmful of viruses could be
  633. life-threatening.  For example, in the context of a hospital life-
  634. support system, a virus that "simply" stops a computer and displays a
  635. message until a key is pressed, could be fatal.  Further, those who
  636. create viruses can not halt their spread, even if they wanted to.  It
  637. requires a concerted effort from computer users to be "virus-aware",
  638. rather than continuing the ambivalence that has allowed computer viruses
  639. to become such a problem.
  640.  
  641. Computer viruses are actually a special case of something known as
  642. "malicious logic" or "malware", and other forms of malicious logic are
  643. also discussed in Virus-L/comp.virus.  It can be important to understand
  644. the distinctions between viruses and these other forms of malware.
  645.  
  646.  
  647. B2)  What is a Worm?
  648.  
  649. A computer WORM is a self-contained program (or set of programs), that
  650. is able to spread functional copies of itself or its segments to other
  651. computer systems (usually via network connections).
  652.  
  653. Note that unlike viruses, worms do not need to attach themselves to a
  654. host program.  There are two types of worms--host computer worms and
  655. network worms.
  656.  
  657. Host computer worms are entirely contained in the computer they run on
  658. and use network connections only to copy themselves to other computers.
  659. Host computer worms where the original terminates itself after launching
  660. a copy on another host (so there is only one copy of the worm running
  661. somewhere on the network at any given moment), are sometimes called
  662. "rabbits."
  663.  
  664. Network worms consist of multiple parts (called "segments"), each
  665. running on different machines (and possibly performing different
  666. actions) and using the network for several communication purposes.
  667. Propagating a segment from one machine to another is only one of those
  668. purposes.  Network worms that have one main segment which coordinates
  669. the work of the other segments are sometimes called "octopuses."
  670.  
  671. The infamous Internet Worm (perhaps covered best in "The Internet Worm
  672. Program: An Analysis," Eugene H. Spafford, Purdue Technical Report CSD-
  673. TR-823) was a host computer worm, while the Xerox PARC worms were
  674. network worms (a good starting point for these is "The Worm Programs--
  675. Early Experience with a Distributed Computation," Communications of the
  676. ACM, 25, no.3, March 1982, pp. 172-180).
  677.  
  678.  
  679. B3)  What is a Trojan Horse?
  680.  
  681. A TROJAN HORSE is a program that does something undocumented that the
  682. programmer intended, but that some users would not approve of if they
  683. knew about it.  According to some people, a virus is a particular case
  684. of a Trojan Horse, namely one which is able to spread to other programs
  685. (i.e., it turns them into Trojans too).  According to others, a virus
  686. that does not do any deliberate damage (other than merely replicating)
  687. is not a Trojan.  Finally, despite the definitions, many people use the
  688. term "Trojan" to refer only to *non-replicating* malware, so that the
  689. set of Trojans and the set of viruses are disjoint.
  690.  
  691.  
  692. B4)  What are the main types of PC viruses?
  693.  
  694. Generally, there are two main classes of viruses.  The first class
  695. consists of the FILE INFECTORS which attach themselves to ordinary
  696. program files.  These usually infect arbitrary COM and/or EXE programs,
  697. though some can infect any program for which execution or interpretation
  698. is requested, such as SYS, OVL, OBJ, PRG, MNU and BAT files.  There is
  699. also at least one PC virus that "infects" source code files by inserting
  700. code into C language source files that replicates the virus's function
  701. in any executable that is produced from the infected source code files
  702. (see E5 for a more detailed discussion of the issue of "executable"
  703. code).
  704.  
  705. File infectors can be either DIRECT-ACTION or RESIDENT.  A direct-action
  706. virus selects one or more programs to infect each time a program
  707. infected by it is executed.  A resident virus installs itself somewhere
  708. in memory (RAM) the first time an infected program is executed, and
  709. thereafter infects other programs when *they* are executed (as in the
  710. case of the Jerusalem virus) or when other conditions are fulfilled.
  711. Direct-action viruses are also sometimes referred to as NON-RESIDENT.
  712. The Vienna virus is an example of a direct-action virus.  Most viruses
  713. are resident.
  714.  
  715. The second main category of viruses is SYSTEM or BOOT-RECORD INFECTORS:
  716. these viruses infect executable code found in certain system areas on a
  717. disk.  On PCs there are ordinary boot-sector viruses, which infect only
  718. the DOS boot sector, and MBR viruses which infect the Master Boot Record
  719. on fixed disks and the DOS boot sector on diskettes.  Examples include
  720. Brain, Stoned, Empire, Azusa and Michelangelo.  All common boot sector
  721. and MBR viruses are memory resident.
  722.  
  723. To confuse this classification somewhat, a few viruses are able to
  724. infect both files and boot sectors (the Tequila virus is one example).
  725. These are often called "MULTI-PARTITE" viruses, though there has been
  726. criticism of this name; another name is "BOOT-AND-FILE" virus.
  727.  
  728. Aside from the two main classes described above, many antivirus
  729. researchers distinguish either or both of the following as distinct
  730. classes of virus:
  731.  
  732. FILE SYSTEM or CLUSTER viruses (e.g. Dir-II) are those that modify
  733. directory table entries so that the virus is loaded and executed before
  734. the desired program is.  The program itself is not physically altered,
  735. only the directory entry of the program file is.  Some consider these to
  736. be a third category of viruses, while others consider them to be a sub-
  737. category of the file infectors.  LINK virus is another term occasionally
  738. used for these viruses, though it should be avoided, as "link virus" is
  739. commonly used in the Amiga world to mean "file infecting virus."
  740.  
  741. KERNEL viruses target specific features of the programs that contain the
  742. "core" (or "kernel") of an operating system (3APA3A is a DOS kernel
  743. virus and is also multipartite).  A file infecting virus that *can*
  744. infect kernel program files is *not* a kernel virus--this term is
  745. reserved for describing viruses that utilize some special feature of
  746. kernel files (such as their physical location on disk or a special
  747. loading or calling convention).
  748.  
  749.  
  750. B5)  What is a stealth virus?
  751.  
  752. A STEALTH virus is one that, while "active", hides the modifications it
  753. has made to files or boot records.  This is usually achieved by
  754. monitoring the system functions used to read files or sectors from
  755. storage media and forging the results of calls to such functions.  This
  756. means programs that try to read infected files or sectors see the
  757. original, uninfected form instead of the actual, infected form.  Thus
  758. the virus's modifications may go undetected by antivirus programs.
  759. However, in order to do this, the virus must be resident in memory when
  760. the antivirus program is executed and *this* may be detected by an
  761. antivirus program.
  762.  
  763. Example:  The very first DOS virus, Brain, a boot-sector infector,
  764. monitors physical disk I/O and re-directs any attempt to read a Brain-
  765. infected boot sector to the disk area where the original boot sector is
  766. stored.  The next viruses to use this technique were the file infectors
  767. Number of the Beast and Frodo (aka 4096, 4K).
  768.  
  769. Countermeasures:  A "clean" system is needed so that no virus is present
  770. to distort the results of system status checks.  Thus the system should
  771. be started from a trusted, clean, bootable diskette before any virus-
  772. checking is attempted; this is "The Golden Rule of the Trade" (see G8
  773. for help with making a clean boot disk and booting clean).
  774.  
  775.  
  776. B6)  What is a polymorphic virus?
  777.  
  778. A POLYMORPHIC virus is one that produces varied but operational copies
  779. of itself.  These strategies have been employed in the hope that virus
  780. scanners (see D1) will not be able to detect all instances of the virus.
  781.  
  782. One method of evading scan string-driven virus detectors is self-
  783. encryption with a variable key.  These viruses (e.g. Cascade) are not
  784. termed "polymorphic", as their decryption code is always the same.
  785. Therefore the decryptor can be used as a scan string by the simplest
  786. scan string-driven virus scanners (unless another virus uses the
  787. identical decryption routine *and* exact identification (see B15) is
  788. required).
  789.  
  790. A technique for making a polymorphic virus is to choose among a variety
  791. of different encryption schemes requiring different decryption routines:
  792. only one of these routines would be plainly visible in any instance of
  793. the virus (e.g. the Whale virus).  A scan string-driven virus scanner
  794. would have to exploit several scan strings (one for each possible
  795. decryption method) to reliably identify a virus of this kind.
  796.  
  797. More sophisticated polymorphic viruses (e.g. V2P6) vary the sequences of
  798. instructions in their variants by interspersing the decryption
  799. instructions with "noise" instructions (e.g. a No Operation instruction
  800. or an instruction to load a currently unused register with an arbitrary
  801. value), by interchanging mutually independent instructions, or even by
  802. using various instruction sequences with identical net effects (e.g.
  803. Subtract A from A, and Move 0 to A).  A simple-minded, scan string-based
  804. virus scanner would not be able to reliably identify all variants of
  805. this sort of virus; rather, a sophisticated "scanning engine" has to be
  806. constructed after thorough research into the particular virus.
  807.  
  808. One of the most sophisticated forms of polymorphism used so far is the
  809. "Mutation Engine" (MtE) which comes in the form of an object module.
  810. With the Mutation Engine any virus can be made polymorphic by adding
  811. certain calls to its assembler source code and linking to the mutation-
  812. engine and random-number generator modules.
  813.  
  814. The advent of polymorphic viruses has rendered virus-scanning an ever
  815. more difficult and expensive endeavor; adding more and more scan strings
  816. to simple scanners will not adequately deal with these viruses.
  817.  
  818.  
  819. B7)  What are "fast" and "slow" infectors?
  820.  
  821. A typical file infector (such as the Jerusalem) copies itself to memory
  822. when a program infected by it is executed, and then infects other
  823. programs when they are executed.
  824.  
  825. A FAST infector is a virus that, when it is active in memory, infects
  826. not only programs which are executed, but even those that are merely
  827. opened.  The result is that if such a virus is in memory, running a
  828. scanner or integrity checker can result in all (or at least many)
  829. programs becoming infected.  Examples are the Dark Avenger and the Frodo
  830. viruses.
  831.  
  832. The term "SLOW infector" is sometimes used to refer to a virus that only
  833. infect files as they are modified or as they are created.  The purpose
  834. is to fool people who use integrity checkers into thinking that
  835. modifications reported by their integrity checker are due solely to
  836. legitimate reasons.  An example is the Darth Vader virus.
  837.  
  838.  
  839. B8)  What is a sparse infector?
  840.  
  841. The term "sparse infector" is sometimes used to describe a virus that
  842. infects only occasionally (e.g. every tenth program executed), or only
  843. files whose lengths fall within a narrow range, etc.  By infecting less
  844. often, such viruses try to minimize the probability of being discovered.
  845.  
  846.  
  847. B9)  What is a companion virus?
  848.  
  849. A COMPANION virus is one that, instead of modifying an existing file,
  850. creates a new program which (unknown to the user) is executed instead of
  851. the intended program.  On exit, the new program executes the original
  852. program so that things appear normal.  On PCs this has usually been
  853. accomplished by creating an infected .COM file with the same name as an
  854. existing .EXE file.  Integrity checking antivirus software that only
  855. looks for modifications in existing files will fail to detect such
  856. viruses.
  857.  
  858.  
  859. B10) What is an armored virus?
  860.  
  861. An ARMORED virus is one that uses special tricks to make tracing,
  862. disassembling and understanding of its code more difficult.  A good
  863. example is the Whale virus.
  864.  
  865.  
  866. B11) What is a cavity virus?
  867.  
  868. A CAVITY VIRUS is one which overwrites a part of the host file that is
  869. filled with a constant (usually nulls), without increasing the length of
  870. the file, but preserving its functionality.  The Lehigh virus was an
  871. early example of a cavity virus.
  872.  
  873.  
  874. B12) What is a tunnelling virus?
  875.  
  876. A TUNNELLING VIRUS is one that finds the original interrupt handlers in
  877. DOS and the BIOS and calls them directly, thus bypassing any activity
  878. monitoring program (see D1) which may be loaded and have intercepted the
  879. respective interrupt vectors in its attempt to detect viral activity.
  880. Some antivirus software also uses tunnelling techniques in an attempt to
  881. bypass any unknown or undetected virus that may be active when it runs.
  882.  
  883.  
  884. B13) What is a dropper?
  885.  
  886. A DROPPER is a program that has been designed or modified to "install" a
  887. virus onto the target system.  The virus code is usually contained in a
  888. dropper in such a way that it won't be detected by virus scanners that
  889. normally detect that virus (i.e., the dropper program is not *infected*
  890. with the virus).  While quite uncommon, a few droppers have been
  891. discovered.  A dropper is effectively a Trojan Horse (see B3) whose
  892. payload is installing a virus infection.  A dropper which installs a
  893. virus only in memory (without infecting anything on the disk) is
  894. sometimes called an "injector".
  895.  
  896.  
  897. B14) What is an ANSI bomb?
  898.  
  899. An "ANSI bomb" is a sequence of characters, usually embedded in a text
  900. file, that reprograms various keyboard functions of computers with ANSI
  901. console (screen and keyboard) drivers.  In theory a special sequence of
  902. characters could have been included in this FAQ sheet to reprogram your
  903. Enter key to issue the command "format c:" with a return character
  904. tacked on the end.
  905.  
  906. Such a possibility however, need not translate into much of a threat.
  907. It is rare for modern software to require the computer it runs on to
  908. have an ANSI console, so few PCs or other machines should load ANSI
  909. drivers.  Also, few people use software that simply "types" output to
  910. the terminal device, so such an ANSI bomb in an e-mail or News posting
  911. would most likely not reprogram your keyboard anyway.  Further, although
  912. FORMAT C: may be catastrophic under certain versions of DOS, it won't
  913. hurt Macintoshes and would probably have very unexpected, or no, effects
  914. on other systems.
  915.  
  916. If you are at all worried about the possibility of having something
  917. untoward happen on your PC due to an ANSI bomb *and* you have to load an
  918. ANSI driver (some communications software still requires it), look for
  919. one of the third-party ANSI drivers which abound on BBSes and FTP sites.
  920. Most of these have improved performance over DOS's ANSI.SYS *and* either
  921. do not support, or let you disable, keyboard re-mapping.
  922.  
  923.  
  924. B15) Miscellaneous Jargon and Abbreviations
  925.  
  926. AV = antivirus.  A commonly used shorthand on Virus-L/comp.virus, as in
  927. "av software".
  928.  
  929. BSI = Boot Sector Infector: a virus that takes control when the computer
  930. attempts to boot.  These are found in the boot sectors of floppy disks,
  931. and the MBRs or boot sectors of hard disks (see B4 for more details).
  932. BSIs are also known as BSVs (Boot Sector Viruses).
  933.  
  934. CMOS = Complementary Metal Oxide Semiconductor: A memory area that is
  935. used in AT class, and higher, PCs for storage of system information.
  936. CMOS is battery backed RAM (see below), originally used to maintain date
  937. and time information while the PC was turned off.  CMOS memory is not in
  938. the normal CPU address space and cannot be executed (see E2 for further
  939. discussion of issues concerning CMOS memory and viruses).
  940.  
  941. DBS = DOS Boot Sector: The first sector of a logical DOS partition on a
  942. hard disk or the first absolute sector of a diskette.  This sector
  943. contains the startup code that actually loads DOS.  This is often
  944. confused with the MBR.  Some boot sector viruses infect the DBS rather
  945. than the MBR when infecting hard disks.
  946.  
  947. DETECTION = The ability of an antivirus program to detect that a virus
  948. is present, without necessarily reporting which particular virus it is
  949. (also see IDENTIFICATION and RECOGNITION, in this section).
  950.  
  951. DOS = Disk Operating System.  We use the term "DOS" to mean any of the
  952. MS-DOS, PC-DOS, DR DOS or Novell DOS systems for PCs and compatibles,
  953. even though there are operating systems called "DOS" on other, unrelated
  954. machines.
  955.  
  956. GERM = The first generation of a virus.  It normally cannot be produced
  957. again during the replication process and is usually created by compiling
  958. the source of the virus.
  959.  
  960. GOAT FILES = Programs which usually do nothing special (e.g., just exit,
  961. or simply display a message), that are used by antivirus researchers to
  962. capture samples of viruses.  This is done to make it easier to
  963. disassemble and understand the virus, because the infected "goat"
  964. program is (usually) simple and does not clutter the disassembly.
  965. Alternative terms are BAIT FILES, DECOY FILES and VICTIM FILES.  In any
  966. of these terms, the word "programs" often replaces the word "files".
  967.  
  968. IDENTIFICATION = The ability of an antivirus program (usually a scanner)
  969. to not only detect the virus and recognize it by name, but also to
  970. recognize it to a high degree of uniqueness.  This allows third parties
  971. to understand which particular virus it is without seeing a sample of
  972. the virus.  EXACT IDENTIFICATION occurs when every section of the non-
  973. modifiable parts of the virus body are uniquely identified.  ALMOST
  974. EXACT IDENTIFICATION occurs if the identification is only good enough to
  975. ensure that an attempt to remove the virus will not result in damage to
  976. the host object by the use of an inappropriate disinfection method (also
  977. see DETECTION and RECOGNITION, in this section).
  978.  
  979. MBR = Master Boot Record: the first absolute sector (track 0, head 0,
  980. sector 1) on a PC hard disk, that usually contains the partition table
  981. but on some PCs may only contain a boot sector.  The MBR is also known
  982. as the MBS (Master Boot Sector).  This is *not* the same as the DOS Boot
  983. Sector, logical sector 0 (see above).
  984.  
  985. PARTITION TABLE = A 64-byte data structure that defines the way a PC's
  986. hard disk is divided into logical sections known as partitions.  While
  987. there is often more than one partition table on a PC's hard disk, the
  988. most important is the one stored *in* the MBR.  This one contains
  989. important extra information such as which partition (if any) should be
  990. booted from.  The partition table is purely data, so is not executed.
  991. Some people erroneously use the term "partition table virus" as a
  992. synonym for "MBR virus".
  993.  
  994. RAM = Random Access Memory: the place programs are loaded into in order
  995. to execute; the significance for viruses is that, to be active, they
  996. must load themselves into part of the RAM.  However, some virus scanners
  997. may declare that a virus is active when it is found in RAM, even though
  998. it may only be left in a buffer area following a disk read operation,
  999. rather than truly being active (see C8 for further discussion of this
  1000. issue).
  1001.  
  1002. RECOGNITION = The ability of an antivirus program (usually a scanner) to
  1003. detect a virus and to recognize it by name (also see DETECTION and
  1004. IDENTIFICATION, in this section).
  1005.  
  1006. TARGETING VIRUS = A virus that tries to bypass or hinder the operation
  1007. of one or more *specific* antivirus programs.  Also known as RETALIATOR,
  1008. RETRO and ANTI-ANTIVIRUS viruses.
  1009.  
  1010. SCAN STRING = A sequence of bytes (characters) that occur in a known
  1011. virus but not, one hopes, in legitimate programs.  Some scanners allow
  1012. "wildcards"--positions that are matched by any character--in their scan
  1013. strings.  Authors of virus scanners reduce the likelihood of false
  1014. positives (see B7) by carefully selecting their scan strings and often
  1015. by only searching "likely" parts of target files.
  1016.  
  1017. SEARCH STRING = A synonym for scan string.
  1018.  
  1019. SIGNATURE = A poor synonym for scan string.  We recommend that you avoid
  1020. using this term and use "scan string" or "search string" instead.
  1021.  
  1022. TOM = Top Of Memory: the end of conventional memory--an architectural
  1023. design limit--at the 640KB mark on most PCs.  Some early PCs may not
  1024. have a full 640KB, but the amount of memory is always a multiple of
  1025. 64KB.  A boot-record virus on a PC typically resides just below this
  1026. mark and changes the value which will be reported for the TOM to the
  1027. location of the beginning of the virus so that it won't be overwritten.
  1028. Checking this value for changes can help detect a virus, but there are
  1029. also legitimate reasons why it may change (see C10).  A very few PCs
  1030. with unusual configurations or memory managers may report in excess of
  1031. 640KB.
  1032.  
  1033. TSR = Terminate but Stay Resident: these are PC programs that stay in
  1034. memory while you continue to use the computer for other purposes; they
  1035. include pop-up utilities, network software, and the great majority of
  1036. common viruses.  These can often be seen using utilities such as MEM and
  1037. MSD.
  1038.  
  1039. VX = Virus eXchange.  A shorthand usually reserved for those BBSes and
  1040. FTP sites, and their community of users, that make their virus
  1041. collections "openly" available for downloading.  Exchange of virus
  1042. samples between bona fide members of the antivirus community is not
  1043. tagged with the VX label.
  1044.  
  1045.  
  1046.  
  1047. ================================
  1048. = Section C.   Virus Detection =
  1049. ================================
  1050.  
  1051. C1)  What are the symptoms and indications of a virus infection?
  1052.  
  1053. Many people associate destruction--file corruption, reformatted disks
  1054. and the like--with viruses.  Machines infected with viruses that do this
  1055. kind of damage often display such damages too.  This is unfortunate, as
  1056. usually viruses can be detected or prevented from infecting long before
  1057. they can inflict any (serious) damage, though many viruses have no
  1058. "payload" at all.  Note that viruses that simply reformat the hard disk
  1059. shortly after infecting a machine tend to wipe themselves out faster
  1060. than they spread, so don't get far.
  1061.  
  1062. Thus, the more successful viruses typically try to spread as much as
  1063. possible before delivering their payload, if any.  As these tend to be
  1064. the viruses you are most likely to encounter, you should be aware that
  1065. there are usually symptoms of virus infection before any (or much!)
  1066. damage is done.
  1067.  
  1068. There are various kinds of symptoms that some virus authors have written
  1069. into their programs, such as messages, music and graphical displays.
  1070. The main indications, however, are changes in file sizes and contents,
  1071. changing of interrupt vectors, or the reassignment of other system
  1072. resources.  The unaccounted use of RAM or a reduction in the amount
  1073. reported to be in the machine are important indicators.  Examination of
  1074. program code is valuable to the trained eye, but even a novice can often
  1075. spot the gross differences between a valid boot sector and some viral
  1076. ones.  These symptoms, along with longer disk activity and strange
  1077. behavior from the hardware, may instead be caused by genuine software,
  1078. by harmless "joke" programs, or by hardware faults.
  1079.  
  1080. The only foolproof way to determine that a virus is present is for an
  1081. expert to analyse the assembly code contained in all programs and system
  1082. areas, but this is usually impracticable.  Virus scanners go some way
  1083. towards performing this analysis by looking in that code for known
  1084. viruses; some even use heuristic means to spot "virus-like" code, but
  1085. this is not always reliable.  It is wise to arm yourself with the latest
  1086. antivirus software and to pay close attention to your system.  In
  1087. particular, look for any unexpected change in the memory map or
  1088. configuration as soon as you start the computer.  For users of DOS 5.0+,
  1089. the MEM program with the /C switch is very handy for this.  If you have
  1090. DR DOS, use MEM with the /A switch; if you have an earlier DOS version,
  1091. use CHKDSK or the commonly-available MAPMEM utility.  You don't have to
  1092. know what all the numbers mean, only that they have changed
  1093. *unexpectedly*.  Mac users have "info" options, which give some
  1094. indication of memory use, but may need ResEdit to supply more detailed
  1095. information.
  1096.  
  1097. If you run Windows on your PC and you suddenly start getting messages at
  1098. Windows startup that 32-bit Disk Access cannot be used, this often
  1099. indicates your PC has been infected by a boot-sector virus.
  1100.  
  1101.  
  1102. C2)  What steps should be taken in diagnosing and identifying viruses?
  1103.  
  1104. Most of the time, a virus scanner program will take care of that for
  1105. you.  To help identify problems early, run a virus scanner:
  1106.  
  1107. 1.   On new programs and diskettes (write-protect diskettes before
  1108.      scanning them).
  1109. 2.   When an integrity checker reports a mismatch.
  1110. 3.   When a generic monitoring program sounds an alarm.
  1111. 4.   When you receive an updated version of a scanner (or you have
  1112.      a chance to run a different scanner than the one you have
  1113.      been using).
  1114.  
  1115. Because of the time required, it is not generally advisable to set a
  1116. scanner to check your entire hard disk on every boot.
  1117.  
  1118. If you run into an alarm and your scanner doesn't identify anything or
  1119. doesn't properly clean up for you, first verify that the version you are
  1120. using is the most recent.  Then get in touch with a reputable antivirus
  1121. researcher, who may ask you to send in a copy of the infected file.
  1122. (Also see C9; and F4 if you decide you need to ask for help on Virus-
  1123. L/comp.virus.)
  1124.  
  1125.  
  1126. C3)  What is the best way to remove a virus?
  1127.  
  1128. In order that downtime be short and losses low, do the minimum that you
  1129. must to restore the system to a normal state, starting with booting the
  1130. system from a clean diskette (see G8).  It is *never* necessary to low-
  1131. level format a hard disk to recover from a virus infection!
  1132.  
  1133. If backups of infected or damaged files are available and, in making
  1134. them, appropriate care was taken to ensure that infected files have not
  1135. been included in the backups (see D10), restoring from backup is the
  1136. safest solution, even though it can be a lot of work if many files are
  1137. involved.
  1138.  
  1139. More commonly, a disinfecting program is used, though disinfection is
  1140. somewhat controversial and problematic (see E8).  If the virus is a boot-
  1141. sector infector, you can continue using the computer with relative
  1142. safety (if the hard disk's partition table is left intact) by booting
  1143. from a clean system diskette.  However, it is wise to go through all
  1144. your diskettes removing any infections as, sooner or later, you will be
  1145. careless and leave an infected diskette in the machine when it reboots,
  1146. or give an infected diskette to a someone who doesn't have appropriate
  1147. defenses to avoid infection.
  1148.  
  1149. Most PC boot-sector infections can be cured by the following simple
  1150. process--pay particular care to make the checks in Steps 2 and 3.
  1151.  
  1152. Note that removing an MBR virus in the following way may not be
  1153. desirable, and may even cause valuable information to be lost.  For
  1154. instance, the One_Half virus gradually encrypts the infected hard drive
  1155. "inwards" (starting from the "end" and moving towards the beginning),
  1156. encrypting two more tracks at each boot.  The information about the size
  1157. of the encrypted area is *only* stored in the MBR.  If the virus is
  1158. removed using the method above, this information will be irrecoverably
  1159. lost and part of the disk with unknown size will remain encrypted.
  1160.  
  1161. 1.   Boot the PC from a clean system floppy--this must be MS-DOS
  1162.      5.0 or version 6.0 or higher of PC-DOS or DR DOS.  This
  1163.      diskette should carry copies of the DOS utilities MEM, FDISK,
  1164.      CHKDSK, UNFORMAT and SYS.  (See G8 for help on making an
  1165.      emergency boot diskette.)
  1166.  
  1167. 2.   Check that your memory configuration is "normal" with MEM
  1168.      (see C10 for assistance here).  Check that your hard disk
  1169.      partitioning is normal--run FDISK and use the "Display
  1170.      partition information" option to check this.  MS-DOS 5.0 (or
  1171.      later) users can use UNFORMAT /L /PARTN.
  1172.  
  1173. 3.   Try doing a DIR of your hard disk/s (C:, D:, etc).
  1174.  
  1175.      You should continue with Step 4 *only* if all the tests in
  1176.      Step 2 and this step pass.  Do *NOT* continue if you were
  1177.      unable to correctly access *all* your hard disks, as you will
  1178.      quite possibly damage critical information making permanent
  1179.      data damage or loss more likely.
  1180.  
  1181. 4.   Replace the program (code) part of the MBR by using the MS-,
  1182.      or PC-DOS FDISK /MBR command.  If you use DR DOS 6.0, or
  1183.      later, select the FDISK menu option "Re-write Master Boot
  1184.      Record".
  1185.  
  1186. 5.   Replace the DOS boot sector using the command SYS C: (or
  1187.      whatever is correct for your first hard disk partition).  For
  1188.      this step, the version of DOS on your boot diskette must be
  1189.      *exactly* the same as is installed on your hard disk (this
  1190.      may mean you have to first reboot with a clean boot diskette
  1191.      other than that used in Step 1).  If you are using a disk
  1192.      compression system, such as DoubleSpace of DriveSpace, check
  1193.      the documentation on how to locate the physical drive on
  1194.      which the compressed volume is installed, and apply the SYS
  1195.      command to that instead.  Usually this is drive H: or I:.
  1196.  
  1197. 6.   Reboot from your hard disk and check that all is well--if not
  1198.      (which is unlikely if you made the recommended checks), seek
  1199.      expert help.
  1200.  
  1201. 7.   As you will get re-infected by forgetting an infected
  1202.      diskette in your A: drive at boot time, you have to clean all
  1203.      your floppies as well.  This is harder, as there is no simple
  1204.      way of doing this with standard DOS tools.  You can copy the
  1205.      files from each of your floppies, re-format them and copy the
  1206.      files back, but this is a very tedious process (and prone to
  1207.      destructive errors!).  At this point you probably should
  1208.      consider obtaining some good antivirus software.
  1209.  
  1210. FDISK /MBR will only overwrite the boot loader code in the MBR of the
  1211. *first* hard drive in a system.  However, a few viruses will infect both
  1212. drives in a two drive system.  Although the second hard drive is never
  1213. booted from in normal PC configurations, should the second drive from
  1214. such a machine ever be used as the first drive in a system, it will
  1215. still be infected and in need of disinfecting.
  1216.  
  1217.  
  1218. C4)  What does the <insert name here> virus do?
  1219.  
  1220. If an antivirus program has detected a virus on your computer, don't
  1221. rush to post a question to this list asking what it does.  First, it
  1222. might be a false positive alert (especially if the virus is found only
  1223. in one file--see C5), and second, some viruses are extremely common, so
  1224. questions like "What does the Jerusalem virus do?" or "What does the
  1225. Stoned virus do?" are asked here repeatedly.  While this list is read by
  1226. several antivirus experts, they get tired of perpetually answering the
  1227. same questions over and over again.  In any case, if you really need to
  1228. know what a particular virus does (as opposed to knowing enough to get
  1229. rid of it), you will need a longer treatise than could be given here.
  1230.  
  1231. For example, the Stoned virus replaces the disk's boot record with its
  1232. own, relocating the original to a sector on the disk that may (or may
  1233. not) occur in an unused portion of the root directory of a DOS diskette;
  1234. when active, it sits in an area a few kilobytes below the top of memory.
  1235. All this description could apply to a number of common viruses; but the
  1236. important points of where the original boot sector goes--and what effect
  1237. that has on networking software, non-DOS partitions, and so on--are all
  1238. major questions in themselves.
  1239.  
  1240. Therefore, it is better if you first try to answer your question
  1241. yourself.  There are several sources of information about the known
  1242. computer viruses, so please consult one of them before requesting
  1243. information publicly.  Chances are that your virus is rather well known
  1244. and that it is already described in detail in at least one of these
  1245. sources (see A6 for some help in finding these.)
  1246.  
  1247.  
  1248. C5)  What are "false positives" and "false negatives"?
  1249.  
  1250. A FALSE POSITIVE (or Type-I) error is one in which antivirus software
  1251. claims that a given object is infected by a virus when, in reality, the
  1252. object is clean.  This is a failure of *detection* (see B15).  A FALSE
  1253. NEGATIVE (or Type-II) error is one in which the software fails to
  1254. indicate that an infected object is infected.  Clearly false negatives
  1255. are more serious than false positives, although both are undesirable.
  1256.  
  1257. Following from some of Fred Cohen's work, it has been proven that every
  1258. virus detector must have an infinite number of false positives, false
  1259. negatives, or both.  This is expressed by saying that detection of
  1260. viruses, either by appearance or behavior, is UNDECIDABLE.  The
  1261. interpretation and practical significance of this depends upon the
  1262. interpretation of the terms used, and as with Fred's definition of the
  1263. term "computer virus", there is some debate over this.
  1264.  
  1265. In the case of virus scanners, false positives are rare, but they can
  1266. arise if the scan string chosen for a given virus is also present in
  1267. some benign objects because the string was not well chosen.  In modern
  1268. scanners, most false positives probably occur because some virus
  1269. encryption engines produce very "normal looking" code and scanners that
  1270. only try to decide if a piece of code could have been generated by a
  1271. known virus encryption procedure will occasionally detect "innocent"
  1272. code as "suspicious".  False negatives are more common with virus
  1273. scanners because scanners will miss completely new or heavily modified
  1274. viruses.
  1275.  
  1276. One other serious problem could occur:  A positive that is misdiagnosed.
  1277. As an example, imagine a scanner faced with the Empire virus in a boot
  1278. record that reports it as the Stoned virus.  In this case, use of a
  1279. Stoned-specific "cure" to recover from an Empire infection could result
  1280. in an unreadable disk or loss of extended partitions.  Similarly,
  1281. sometimes "generic" disinfection (see D1) can result in unusable files,
  1282. unless a check is made (e.g. by comparing checksums) that the recovered
  1283. file is identical to the original file.  The better generic disinfection
  1284. products all store information about the original files to allow
  1285. verification of recovery processes.
  1286.  
  1287. A particular type of false positive, where (part of) an *inactive* virus
  1288. is detected, is known as a GHOST POSITIVE.  Ghost positives usually
  1289. occur in one of four situations (the first two of which are examples of
  1290. antivirus programs "upsetting" each other):
  1291.  
  1292. Ghost positives can be caused when the disinfection routine of an
  1293. antivirus program "unhooks" a virus from its target (be it a file or
  1294. boot sector) but it does so in such a way that part of the virus code is
  1295. left intact (though that code will never be executed).  Another
  1296. antivirus program might see this code and report it is an infection.  In
  1297. this case the second antivirus program is seeing a "ghost"--part of a
  1298. virus that was there.
  1299.  
  1300. A scanner may "see" the unencoded scan strings of another scanner, left
  1301. in memory after the first has run or held in memory by a resident
  1302. scanner, and report these "ghosts" as active viruses (see C6 and C8).
  1303.  
  1304. As explained elsewhere (see E10) a copy of an infected diskette boot
  1305. sector, sitting in the disk buffers, may be detected and reported as an
  1306. active virus.
  1307.  
  1308. Disinfection procedures can result in virus "remnants" being left in
  1309. "slack space" (disk space allocated to files but not actually occupied).
  1310. As in the case of copies of infected diskette boot sectors being held in
  1311. disk buffers, these remnants can be detected and incorrectly reported as
  1312. being active.  Ghost positives of this nature should disappear after
  1313. running disk defragmentation or "optimization" programs with the option
  1314. to "clean" slack space.  Occasionally running a defragmenter (like MS-
  1315. DOS 6's DEFRAG) after a full data backup (see D10), is a good idea
  1316. anyway--especially before installing new software.  Unfortunately, DOS's
  1317. DEFRAG does not have a "clean slack space" option, though some third-
  1318. party defragmenters do.  There are also utilities that clean unallocated
  1319. and slack space and these should remove ghost positives caused by
  1320. "remnants".
  1321.  
  1322.  
  1323. C6)  Could an antivirus program itself be infected?
  1324.  
  1325. Yes, so it is important to obtain this software from good sources, and
  1326. to trust results only after running scanners from a "clean" system.  But
  1327. there are situations where a scanner appears to be infected when it
  1328. isn't.
  1329.  
  1330. Most antivirus programs try very hard to identify viral infections only,
  1331. but sometimes they give false alarms (see C5).  If two different
  1332. antivirus programs are both of the "scanner" type, they will contain
  1333. "scan strings" from which they identify viral infections.  If the
  1334. strings are not "encoded", then they may be identified as a virus by
  1335. another scanner type program.  Also, if the scanner does not remove the
  1336. strings from memory after it has run, then another scanner may detect a
  1337. virus string "in memory".  This often causes the second scanner to
  1338. report that your system is "infected", *but* only after you have run the
  1339. first scanner (which may be a memory resident one).  The major
  1340. contributors to this group are so tired of dealing with non-virus
  1341. reports of this sort that they *strongly* recommend users to avoid
  1342. antivirus software which doesn't keep its scan strings encoded in
  1343. memory.
  1344.  
  1345. Some "change detection" antivirus programs add a snippet of code or data
  1346. to a program in order to "protect" it.  (This process is sometimes
  1347. called "inoculation", but this term is also used for other antivirus
  1348. techniques.)  These file changes will likely be detected by other
  1349. "change detection" programs, and may therefore raise a warning of a
  1350. suspicious file change (see F8 for a discussion of the inadvisability of
  1351. adding self-checking code to *existing* programs).
  1352.  
  1353. It is good practice to use more than one antivirus program but, by their
  1354. nature, multiple antivirus programs may confuse each other!
  1355.  
  1356.  
  1357. C7)  Where can I get a virus scanner for my Unix system?
  1358.  
  1359. Basically, you shouldn't bother scanning for Unix viruses at this point
  1360. in time.  Although it is possible to write Unix-based viruses we have
  1361. yet to see any instance of a non-experimental virus in that environment.
  1362. Someone with sufficient knowledge and access to write an effective virus
  1363. would be more likely to conduct other activities than virus-writing.
  1364. Furthermore, the typical form of software sharing in the Unix
  1365. environment does not support virus spread as easily as some others.
  1366.  
  1367. This answer is not meant to imply that Unix viruses are impossible, or
  1368. that there aren't security problems in a typical Unix environment--there
  1369. are, and Fred Cohen's first experimental virus was implemented and
  1370. tested on a Unix system.  True viruses in the Unix environment are,
  1371. however, unlikely to spread well.  For more information on Unix
  1372. security, see the book "Practical Unix Security" by Garfinkel and
  1373. Spafford, O'Reilly & Associates, 1991, price $29.95 (it can be ordered
  1374. via e-mail from nuts@ora.com).
  1375.  
  1376. There *are* special cases in which scanning Unix systems for non-Unix
  1377. viruses does make sense.  For example, a Unix system acting as a file
  1378. server (e.g., PC-NFS) for PC systems is quite capable of containing PC
  1379. file infecting viruses that are a danger to PC clients.  Note that, in
  1380. this example, the Unix system would be scanned for PC viruses, not Unix
  1381. viruses.  Also, *any* PC is vulnerable to PC MBR infectors, so special
  1382. care should be taken to prevent booting a PC hosted Unix OS from a
  1383. floppy infected with an MBR virus (see C12).
  1384.  
  1385. In addition, a file integrity checker (to detect unauthorized changes in
  1386. executable files) on Unix systems is a very good idea.  (One free
  1387. program that can do this test, as well as other tests, is Tripwire,
  1388. available by anonymous FTP from its "home" site of coast.cs.purdue.edu
  1389. in /pub/COAST/Tripwire, and from several other antivirus sites.)
  1390. Unauthorized file changes on Unix systems are very common, although they
  1391. are not usually due to virus activity.
  1392.  
  1393.  
  1394. C8)  Why does my scanner report an infection only sometimes?
  1395.  
  1396. There are circumstances where part of a virus exists in RAM without
  1397. being active.  If your scanner occasionally reports a virus in memory,
  1398. it could be due to the operating system buffering diskette reads or
  1399. harmlessly keeping disk contents that include a virus in memory, or
  1400. after running another scanner, there may be scan strings left (again
  1401. harmlessly) in memory.  These are known as GHOST POSITIVE alerts (see C5
  1402. for more details).
  1403.  
  1404.  
  1405. C9)  I think I have detected a new virus; what do I do?
  1406.  
  1407. Whenever there is doubt over a virus, you should obtain the latest
  1408. versions of several (not just one) major virus scanners.  Some scanning
  1409. programs now use "heuristic" methods (F-PROT and TBSCAN are examples),
  1410. and "activity monitoring" programs can report a program as being
  1411. possibly infected when it is in fact perfectly safe (odd, perhaps, but
  1412. not infected).  If no scanner finds a virus, but a heuristic program
  1413. raises some alarms (or there are other reasons to suspect a virus--e.g.
  1414. change in size of files, change in memory allocation) then it is
  1415. possible that you have found a new virus, although the chances are
  1416. probably greater that it is an "odd but okay" disk or file.  Start by
  1417. looking in recent Virus-L/comp.virus postings for "known" false
  1418. positives, then contact the author of the antivirus software that
  1419. reports the virus-like features; the documentation for the software may
  1420. have a section explaining what to do if you think you have found a new
  1421. virus.
  1422.  
  1423.  
  1424. C10) CHKDSK reports 639K (or less) total memory on my DOS system; am I
  1425.      infected?
  1426.  
  1427. If CHKDSK displays 639KB (654,336 bytes) for the total memory instead of
  1428. 640K (655,360 bytes)--so that you are missing only 1KB-- it is possibly
  1429. due to reasons other than a virus, but there are a few common viruses
  1430. that take only 1KB from total memory (Monkey and AntiEXE).  Non-virus
  1431. reasons for a deficiency of 1KB include:
  1432.  
  1433. 1.   A PS/2 computer.  IBM PS/2 computers reserve 1KB of
  1434.      conventional RAM for an Extended BIOS Data Area, i.e. for
  1435.      additional data storage required by its BIOS.
  1436. 2.   A computer with a BIOS, which is set to use the upper 1KB of
  1437.      memory for its internal variables.  (Most BIOSes with this
  1438.      option can be instructed to use lower memory instead.)
  1439. 3.   Some SCSI controllers.
  1440. 4.   The DiskSecure antivirus program.
  1441. 5.   Mouse buffers for older Compaqs.
  1442.  
  1443. If you are missing 2KB or more from the 640KB, 512KB, or whatever the
  1444. conventional memory normally is for your PC, the chances are greater
  1445. that you have a boot-record virus (e.g. Stoned, Form or Michelangelo),
  1446. although, even in this case there may be legitimate reasons for the
  1447. missing memory:
  1448.  
  1449. 1.   Many access control programs for preventing booting from a
  1450.      floppy.
  1451. 2.   H/P Vectra computers.
  1452. 3.   Some special BIOS'es which use memory for a built-in calendar
  1453.      and/or calculator.
  1454.  
  1455. However, these are only rough guides.  In order to be more certain
  1456. whether the missing memory is due to a virus, you should:
  1457.  
  1458. 1.   run several virus detectors;
  1459. 2.   look for a change in total memory every now and then;
  1460. 3.   compare the total memory size with that obtained when cold
  1461.      booting from a "clean" system diskette.  The latter should
  1462.      show the normal amount of total memory for your configuration
  1463.      (although several BIOSes now steal 1KB of conventional memory
  1464.      when booted from floppy but none when booting from a hard
  1465.      drive).
  1466.  
  1467. Note:  In all cases, CHKDSK should be run without software such as MS-
  1468. Windows or DesqView loaded, since these operating environments seem to
  1469. be able to open DOS boxes only on 1KB boundaries (some seem to be even
  1470. coarser); thus CHKDSK run from a DOS box may report unrepresentative
  1471. values.
  1472.  
  1473. Note also that some machines have only 512KB or 256KB instead of 640KB
  1474. of conventional memory.
  1475.  
  1476.  
  1477. C11) I have an infinite loop of sub-directories on my hard drive; am I
  1478.      infected?
  1479.  
  1480. Probably not.  This happens now and then, when something sets the
  1481. "cluster number" field of a subdirectory to the same cluster as an upper-
  1482. level (usually the root) directory.  On PCs the /F parameter of CHKDSK
  1483. should be able to "fix" this (as should many other popular disk-repair
  1484. programs), usually by removing the offending directory.  *Don't* erase
  1485. any of the "replicated" files in the "odd" directory, since that will
  1486. erase the "copy" in the root as well (these are not really copies at
  1487. all; just a second pointers to the same files).
  1488.  
  1489.  
  1490. C12) Can a PC not running DOS be infected with a common DOS virus?
  1491.  
  1492. Yes!  There are three distinct possibilities here.
  1493.  
  1494. One is Novell's NetWare (and possibly other network operating systems),
  1495. which boots from a DOS disk and loads a "standard" DOS executable that
  1496. takes complete control of the system from DOS.  This executable--
  1497. SERVER.EXE--could easily be infected by a DOS file infector.  For
  1498. example, a server's NetWare boot diskette may have to be taken from the
  1499. server to a DOS PC to edit some of the configuration and startup files
  1500. that have to be on that diskette.  If the PC where the editing is done
  1501. is infected with a file infecting virus, SERVER.EXE may well be infected
  1502. when the new startup files are saved to the diskette.  Such infections
  1503. are virtually guaranteed to render SERVER.EXE inoperative and the server
  1504. would fail at its next restart.  No viruses are known to target the
  1505. NetWare kernel specifically.
  1506.  
  1507. Another possibility is the case of a 386 (or better) system running
  1508. NetWare or a self-loading OS, such as Unix, NeXTStep486, Windows NT or
  1509. OS/2, since this system is still vulnerable to infection by MBR
  1510. infectors (such as Stoned or Michelangelo), as these are operating
  1511. system independent.  Note that an infection on such a system may result
  1512. in the disabling of non-DOS disk partitions (possibly beyond easy
  1513. recovery) because the tricks and system conventions these viruses employ
  1514. may not apply to operating systems other than DOS.  The issue here is
  1515. that MBR infectors are not really "DOS viruses" so much as "PC-BIOS
  1516. viruses"--they can infect any machine with a PC-compatible BIOS.
  1517.  
  1518. Third, *any* OS that offers a "DOS box" or "DOS emulator" to run DOS
  1519. programs can, potentially, run a virus-infected DOS program.  Such
  1520. activation of a virus should allow the virus to spread to any "targets"
  1521. available to it under that DOS emulator.  For example, a DOS program
  1522. infected with a multipartite virus, when run under OS/2 would probably
  1523. be able to infect other DOS executables, but not the MBR/DBS, as OS/2
  1524. only allows programs to read these critical areas of the hard drive (see
  1525. E12 for more details on DOS viruses running under OS/2).  With the
  1526. increasing sophistication and power of computing environments, DOS
  1527. emulators running on non-PC computers are increasingly available and
  1528. able to run DOS viruses.
  1529.  
  1530.  
  1531. C13) My hard-disk's file system has been garbled:  Do I have a virus?
  1532.  
  1533. Many things apart from viruses cause corruption of file systems.
  1534.  
  1535. With DOS machines possibly the most common is Microsoft's SmartDrive
  1536. disk cache program that came with Microsoft Windows 3.1 and subsequent
  1537. versions of MS-DOS.  Most versions of this software not only cache disk-
  1538. reads but, by default, also cache disk-writes.  This means that recently
  1539. "written" files (say from saving a document in your word processor) may
  1540. not have all the information about the associated file system updates
  1541. written to disk by the time you exit the application, close Windows and
  1542. turn off your PC.  Users who simply save work then turn their PC off are
  1543. even more likely to suffer from disk caching induced problems like this.
  1544.  
  1545. Regardless of what caused your file-system corruption, you should
  1546. probably seek expert help *before* trying to fix anything yourself.
  1547. While there are many powerful and interesting-sounding utilities of the
  1548. "disk fix" kind available, *all* of these have the stunning ability to
  1549. render your file system all but unfixable (or at least, fixable to a
  1550. much lesser degree) when presented with unusual situations their authors
  1551. hadn't considered when designing the programs.  Unfortunately, as these
  1552. programs (by definition) do not recognize these situations, they
  1553. confidently pronounce that you have such-and-such a problem then ask
  1554. your permission to fix it.  Even when these utilities have "undo"
  1555. options, they often cannot restore your file system to its originally
  1556. "broken" state to give human experts their best shot at fixing it.
  1557. Thus, detecting whether it is safe to let one of these programs loose on
  1558. your disks is something you should normally seek expert help in
  1559. deciding.
  1560.  
  1561.  
  1562.  
  1563. =================================
  1564. = Section D.   Protection plans =
  1565. =================================
  1566.  
  1567. D1)  What is the best antivirus program?
  1568.  
  1569. None!  Different products are more or less appropriate in different
  1570. situations, but in general you should build a cost-effective *strategy*
  1571. based on multiple layers of defense.  There are three main kinds of
  1572. antivirus software, plus several other means of protection, such as
  1573. hardware write-protect methods (see D4).  When planning your antivirus
  1574. strategy you should also look closely at your backup policies and
  1575. procedures (see 10).
  1576.  
  1577. 1.   ACTIVITY MONITORING programs.  These try to prevent infection
  1578.      before it happens by looking for virus-like activity, such as
  1579.      attempts to write to another executable, reformat the disk,
  1580.      etc.  An alternative term is BEHAVIOR BLOCKER.
  1581.  
  1582.      Examples: SECURE and FluShot+ (PC), and GateKeeper
  1583.      (Macintosh).
  1584.  
  1585.      These programs are considered the weakest line of defense
  1586.      against viruses on a system that does not have memory
  1587.      protection, because in such an environment it is possible for
  1588.      a tunnelling virus (see B12) to bypass or disable them.
  1589.  
  1590. 2.   SCANNERS.  Most look for known viruses by searching your
  1591.      disks and files for "scan strings" or patterns, but a few use
  1592.      heuristic techniques to recognize viral code.  Most now also
  1593.      include some form of "algorithmic scanning" in order to
  1594.      detect known polymorphic viruses.  A scanner may be designed
  1595.      to examine specified disks or files on demand, or it may be
  1596.      resident, examining each program which is about to be
  1597.      executed.  Most scanners also include virus removers.
  1598.  
  1599.      Examples:  FindViru in Dr Solomon's AntiVirus ToolKit, Frisk
  1600.      Software's F-PROT, McAfee's VirusScan (all PC), Disinfectant
  1601.      (Macintosh).
  1602.  
  1603.      Resident scanners:  McAfee's V-Shield, and F-PROT's VIRSTOP.
  1604.  
  1605.      Heuristic scanners:  the Analyse option in F-PROT, TBAV's
  1606.      TbScan and ChkBoot (from Padgett Peterson's FixUtils).
  1607.  
  1608.      Scanners are the most convenient and the most widely used
  1609.      kind of antivirus programs. They are a relatively weak line
  1610.      of defense because even the simplest virus can bypass them if
  1611.      it is new and unknown to the scanner.  Therefore, your virus
  1612.      protection system should not rely on a scanner alone.
  1613.  
  1614. 3.   INTEGRITY CHECKERS or MODIFICATION DETECTORS.  These compute
  1615.      a small "checksum" or "hash value" (usually CRC or
  1616.      cryptographic) for files when they are presumably uninfected,
  1617.      and later compare newly calculated values with the original
  1618.      ones to see if the files have been modified.  This catches
  1619.      unknown viruses as well as known ones and thus provides
  1620.      *generic* detection.  On the other hand, modifications can
  1621.      also be due to reasons other than viruses.  Usually, it is up
  1622.      to the user to decide which modifications are intentional and
  1623.      which might be due to viruses, although a few products give
  1624.      the user help in making this decision.  As in the case of
  1625.      scanners, integrity checkers may be called to checksum entire
  1626.      disks or specified files on demand, or they may be resident,
  1627.      checking each program which is about to be executed (the
  1628.      latter is sometimes called an INTEGRITY SHELL).  A third
  1629.      implementation is as a SELF-TEST, where the checksumming code
  1630.      is attached to each executable file so they check themselves
  1631.      just before execution.  It is generally considered a bad idea
  1632.      to add such code to existing executables (see F8).
  1633.  
  1634.      Examples: ASP Integrity Toolkit (commercial), and Integrity
  1635.      Master and VDS (shareware), all for the PC.
  1636.  
  1637.      Integrity checkers are considered to be the strongest line of
  1638.      defense against computer viruses, because they are not virus-
  1639.      specific and can detect new viruses without being constantly
  1640.      updated.  However, they should not be considered as an
  1641.      absolute protection--they have several drawbacks, cannot
  1642.      identify the particular virus that has attacked the system,
  1643.      and there are successful methods of attack against them too.
  1644.  
  1645. 3a.  Some modification detectors provide HEURISTIC DISINFECTION.
  1646.      Sufficient information is saved for each file so that it can
  1647.      be restored to its original state in the case of the great
  1648.      majority of viral infections, even if the virus is unknown.
  1649.  
  1650.      Examples: V-Analyst 3 (BRM Technologies, Israel), the VGUARD
  1651.      module of V-Care and ThunderByte's TbClean.
  1652.  
  1653. Note that behavior blockers and scanners are virus *prevention* tools,
  1654. while integrity checkers are virus *detection* tools.
  1655.  
  1656. Of course, only a few examples of each type have been given.  All of
  1657. these types of antivirus program have a place in protecting against
  1658. computer viruses, but you should appreciate the limitations of each
  1659. method, along with system-supplied security measures that may or may not
  1660. be helpful in defeating viruses.  Ideally, you should arrange a
  1661. combination of methods that cover each others' weaknesses.
  1662.  
  1663. A typical PC installation might include a protection system on the hard
  1664. disk's MBR to protect against viruses at load time (ideally this would
  1665. be hardware or in BIOS, but software methods such as DiskSecure and
  1666. Henrik Stroem's HS are pretty good).  This would be followed by resident
  1667. virus detectors loaded as part of the machine's startup (CONFIG.SYS or
  1668. AUTOEXEC.BAT), such as FluShot+ and/or VirStop and/or ChkBoot.  A
  1669. scanner such as F-PROT or McAfee's VirusScan and an integrity checker,
  1670. such as Integrity Master, could be put into AUTOEXEC.BAT, but this may
  1671. be a problem if you have a large disk to check, or don't reboot often
  1672. enough.  Most importantly, new files and diskettes should be scanned as
  1673. they arrive *regardless* of their source.  If your system has DR DOS
  1674. installed, you should use the PASSWORD command to write-protect all
  1675. system executables and utilities.  If you have Stacker or SuperStor, you
  1676. can get some improved security from these compressed drives, but also a
  1677. risk that those viruses stupid enough to directly write to the disk
  1678. could do much more damage than normal.  In this case a software write-
  1679. protect system (such as provided with Disk Manager or The Norton
  1680. Utilities) may help.  Possibly the best solution is to put all
  1681. executables on a disk of their own, with a hardware write-protect system
  1682. that sounds an alarm if a write is attempted.
  1683.  
  1684. If you do use a resident BSI detector or a scan-while-you-copy detector,
  1685. it is important to trace back any infected diskette to its source.  The
  1686. reason viruses survive so well is that usually you cannot do this,
  1687. because the infection is found long after the infecting diskette has
  1688. been forgotten due to most people's lax scanning policies.
  1689.  
  1690. Organizations should devise and implement a careful policy that may
  1691. include a system of vetting new software brought into the building and
  1692. free virus detectors for home machines of employees/students/etc who
  1693. take work home with them.
  1694.  
  1695. Other antivirus techniques include:
  1696.  
  1697. 1.   Creation of a special MBR to make the hard disk inaccessible
  1698.      when booting from a diskette (the latter is useful since
  1699.      booting from a diskette will normally bypass any protection
  1700.      measures loaded in the CONFIG.SYS and/or AUTOEXEC.BAT files
  1701.      on the hard disk).
  1702.  
  1703.      Some of these systems won't prevent attack by some MBR virus
  1704.      infections if booting from an infected floppy.  This approach
  1705.      is less important now, as most newer PCs allow you to change
  1706.      the boot order so the first hard drive is tried *before* any
  1707.      of the floppy drives.
  1708.  
  1709. 2.   Use of Artificial Intelligence to learn about new viruses and
  1710.      extract scan patterns for them.
  1711.  
  1712.      Examples: V-Care (CSA Interprint, Israel; distributed in the
  1713.      US by Sela Consultants Corp.), Victor Charlie (Bangkok
  1714.      Security Associates, Thailand; distributed in the US by
  1715.      Computer Security Associates).
  1716.  
  1717. 3.   Encryption of files (with decryption before execution).
  1718.  
  1719. 4.   Diskette "fences".  There are three different approaches to
  1720.      this.  One prevents executables from being accessed from
  1721.      floppy drives while another prohibits the use of unscanned
  1722.      (possibly "unclean") files or diskettes.  A third method uses
  1723.      a non-standard diskette format so diskettes can only be used
  1724.      on (and therefore shared among) machines using the
  1725.      appropriate antivirus software (usually all those within a
  1726.      site or company).  This last method is probably the most
  1727.      common diskette fence and provides better protection against
  1728.      boot sector viruses than the other "fence" types.
  1729.  
  1730.      The workings of the first and third are probably fairly clear
  1731.      from these brief descriptions.  The second approach works by
  1732.      writing special information to normally unused areas of the
  1733.      diskette as part of the scanning process and employing a
  1734.      driver in the users' machines prevents access to files that
  1735.      aren't marked as scanned (or to any part of a diskette that
  1736.      contains unscanned files).  Alternatives include encrypting
  1737.      scanned files and drivers that only allow access to encrypted
  1738.      files, and so on.  One advantage of this second type of
  1739.      system is that you only need scanners for "perimeter
  1740.      checking" machines, reducing the overhead and cost of keeping
  1741.      your scanners up to date.
  1742.  
  1743.      Examples: D-Fence, Virus Fence, TbFence, DiskNet.
  1744.  
  1745.  
  1746. D2)  Is it possible to protect a computer system with only software?
  1747.  
  1748. Not perfectly; although software defenses can significantly reduce your
  1749. risk of being affected by viruses *when applied appropriately*.  All
  1750. virus defense systems are tools--each with its own capabilities and
  1751. shortcomings.  Learn how your system works and be sure to work within
  1752. its limitations.
  1753.  
  1754. Using a layered approach, a very high level of protection/detection can
  1755. be achieved with software only.
  1756.  
  1757. 1.   ROM BIOS--password (access control) and selecting to boot
  1758.      from the hard drive rather than from diskette.  (Some may
  1759.      consider this hardware.)
  1760. 2.   Boot sectors--integrity management and change detection.
  1761. 3.   OS programs--integrity management of existing programs,
  1762.      scanning of unknown programs.  Requirement of authentication
  1763.      values for any new or transmitted software.
  1764. 4.   Locks that prevent writing to a fixed or floppy disk.
  1765.  
  1766. As each layer is added, undetected invasion becomes more difficult.
  1767. Nevertheless, complete protection against any possible attack cannot be
  1768. provided without dedicating the computer to pre-existing or unique
  1769. tasks.  International standardization on the IBM PC architecture is both
  1770. its greatest asset and its greatest vulnerability.
  1771.  
  1772.  
  1773. D3)  Is it possible to write-protect the hard disk with software only?
  1774.  
  1775. The answer is no.  There are several programs that claim to do this, but
  1776. *all* of them can be bypassed with techniques already used by some
  1777. viruses.  Therefore you should never rely on such programs *alone*,
  1778. although they can be useful in combination with other antivirus
  1779. measures.
  1780.  
  1781.  
  1782. D4)  What can be done with hardware protection?
  1783.  
  1784. Hardware protection can accomplish various things, including: write
  1785. protection for hard disk drives, memory protection, monitoring and
  1786. trapping unauthorized system calls, etc.  Again, no single tool will be
  1787. foolproof and the "stronger" hardware-based protection is, the more
  1788. likely it will interfere with the "normal" operation of your computer.
  1789.  
  1790. The popular idea of write-protection (see D3) may stop viruses
  1791. *spreading* to the disk that is protected, but doesn't, in itself,
  1792. prevent a virus from *running*.
  1793.  
  1794. Also, some existing hardware protection schemes can be easily bypassed,
  1795. fooled, or disconnected, if the virus writer knows them well and designs
  1796. a virus that is aware of the particular defense.
  1797.  
  1798. The big problem with hardware protection is that there are few (if any)
  1799. operations that a general-purpose computer can perform that are used by
  1800. viruses *only*.  Therefore, making a hardware protection system for such
  1801. a computer typically involves deciding on some (small) set of operations
  1802. that are "valid but not normally performed except by viruses", and
  1803. designing the system to prevent these operations.  Unfortunately, this
  1804. means either designing limitations into the level of protection the
  1805. hardware system provides or adding limitations to the computer's
  1806. functionality by installing the hardware protection system.  Much can be
  1807. achieved, however, by making the hardware "smarter".  This is double-
  1808. edged: while it provides more security, it usually means adding a
  1809. program in an EPROM to control it.  This allows a virus to locate the
  1810. program and to call it directly after the point that allows access.  It
  1811. is still possible to implement this correctly though--if this program is
  1812. not in the address space of the main CPU, has its own CPU and is
  1813. connected directly to the hard disk and the keyboard.  As an example,
  1814. there is a PC-based product called ExVira which does this and seems
  1815. fairly secure, but it is a whole computer on an add-on board and is
  1816. quite expensive.
  1817.  
  1818.  
  1819. D5)  Does setting a file's attributes to READ ONLY protect it from
  1820.      viruses?
  1821.  
  1822. Generally, no.  While the Read Only attribute will protect your files
  1823. from a few viruses, most simply override it, and infect normally.  So,
  1824. while setting executable files to Read Only a good idea (it protects
  1825. against accidental deletion), it is certainly not a thorough protection
  1826. against viruses!
  1827.  
  1828. In some environments the Read Only attribute does provide some
  1829. additional protection.  For instance, under Novell Netware a user can be
  1830. denied the right to modify file attributes in directories on the server.
  1831. This means that a virus that infects such a user's machine will be
  1832. unable to infect files in those server directories if the files have
  1833. their Read Only attribute set.
  1834.  
  1835.  
  1836. D6)  Do password/access control systems protect my files from viruses?
  1837.  
  1838. All password and other access control systems are designed to protect
  1839. the user's data from other users and/or their programs.  Remember,
  1840. however, that when you execute an infected program the virus in it will
  1841. gain your current rights/privileges.  Therefore, if the access control
  1842. system provides *you* the right to modify some files, it will provide it
  1843. to the virus too.  Note that this does not depend on the operating
  1844. system used--DOS, Unix, or whatever.  Therefore, an access control
  1845. system will protect your files from viruses no better than it protects
  1846. them from you.
  1847.  
  1848. Under DOS, there is no memory protection, so a virus could disable the
  1849. access control system in memory, or even patch the operating system
  1850. itself.  On more advanced operating systems (Unix, OS/2, Windows NT)
  1851. this is much harder or impossible, so there is much less risk that such
  1852. protection measures could be disabled by a virus.  Even so, viruses will
  1853. still be able to spread, for the reasons noted above.  In general,
  1854. access control systems (if implemented correctly) are only able to slow
  1855. down virus spread, not to eliminate viruses entirely.
  1856.  
  1857. Of course, it's better to have access control than not to have it at
  1858. all.  Just be sure to not develop a false sense of security or come to
  1859. rely *entirely* on your access control system to protect you.
  1860.  
  1861.  
  1862. D7)  Do the protection systems in DR DOS work against viruses?
  1863.  
  1864. Partially.  Neither the password file/directory protection available
  1865. from DR DOS version 5 onwards, nor the secure disk partitions from DR
  1866. DOS 6 were intended to combat viruses, but they do so to some extent.
  1867. If you have DR DOS, it is very wise to password-protect your files (to
  1868. stop accidental damage too), but don't depend on it as your only means
  1869. of defense.
  1870.  
  1871. The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM) will
  1872. stop more viruses than the plain DOS attribute facility (see D5), but
  1873. that isn't saying much!  The combination of the password system plus a
  1874. disk compression system may be more secure, because to bypass the
  1875. password system a virus must access the disk directly, but under
  1876. SuperStor or Stacker the physical disk will be meaningless to a virus.
  1877. There may be some viruses that, rather than invisibly infecting files on
  1878. compressed disks, very visibly corrupt such disks.
  1879.  
  1880. The main use of the "secure disk partitions" system, introduced in
  1881. DR DOS 6, is to stop people from fiddling with your hard disk while you
  1882. are away from the PC. The way this is implemented, however, may also
  1883. help against a few viruses that look for DOS partitions on a disk.
  1884.  
  1885. Furthermore, DR DOS is not fully compatible with MS/PC-DOS, especially
  1886. when you get down to the low-level tricks that some viruses use.  For
  1887. instance, some internal memory structures are "read-only" in the sense
  1888. that they are constantly updated (for MS/PC-DOS compatibility) but not
  1889. really used by DR DOS, so even if a sophisticated virus modifies them,
  1890. it will not have any effect, or at least not that intended by the
  1891. virus's author.
  1892.  
  1893. In general, using a less compatible system diminishes the number of
  1894. existing viruses that can infect it.  For instance, the introduction of
  1895. hard disks made the Brain virus almost disappear; the introduction of
  1896. the 80286 and DOS 4.0+ made the Yale and Ping Pong viruses next to
  1897. extinct, and so on.
  1898.  
  1899.  
  1900. D8)  Does a write-protect tab on a floppy disk stop viruses?
  1901.  
  1902. In general, yes.  The write-protection on IBM PC (and compatible) and
  1903. Macintosh floppy disk drives is implemented in hardware, not software,
  1904. so viruses cannot infect a diskette when the write-protection mechanism
  1905. is functioning properly (though many "friend of a friend" stories abound
  1906. contesting this).
  1907.  
  1908. But remember:
  1909.  
  1910. 1.   A computer may have a faulty write-protect system (this
  1911.      happens!)--you can test it by trying to copy a file to a
  1912.      diskette that is apparently write-protected.
  1913. 2.   Someone may have removed the tab for a while, allowing a
  1914.      virus on.
  1915. 3.   The files may have been infected before the disk was
  1916.      protected.  Even some diskettes "straight from the factory"
  1917.      have been known to be infected during the production process.
  1918.  
  1919. Thus, you should scan even new, write-protected disks for viruses.  You
  1920. should also scan new, pre-formatted diskettes, as there have been cases
  1921. of infected, shrink-wrapped new diskettes.
  1922.  
  1923.  
  1924. D9)  Do local area networks (LANs) help to stop viruses or do they
  1925.      facilitate their spread?
  1926.  
  1927. Both.  A set of computers connected in a well managed LAN, with
  1928. carefully established security settings, with minimal privileges for
  1929. each user, and without a transitive path of information flow between the
  1930. users (i.e., the objects writable by any of the users are not readable
  1931. by any of the others) is more virus-resistant than the same set of
  1932. computers if they are not interconnected.  The reason is that when all
  1933. computers have (read-only) access to a common pool of executable
  1934. programs, there is usually less need for diskette swapping and software
  1935. exchange between them, and therefore less chances for a virus to spread.
  1936.  
  1937. However, if the LAN has lax security and is not well managed, it could
  1938. help a virus to spread like wildfire.  It might even be impossible to
  1939. remove the infection without shutting down the entire LAN.  Stories of
  1940. LAN login programs, shared copies of which are run on every workstation,
  1941. becoming infected are, unfortunately, not uncommon.
  1942.  
  1943. A network that supports login scripting is inherently more resistant to
  1944. viruses than one that does not *if* this is used to validate the client
  1945. before allowing access to the network.
  1946.  
  1947.  
  1948. D10) What is the proper way to make backups?
  1949.  
  1950. A good backup regime is at the heart of any comprehensive virus defense
  1951. scheme.  No matter what combination of software and hardware defenses
  1952. you install, nor what "policy" you implement, there is always the
  1953. possibility that some new virus will be devised that can beat your
  1954. defenses *or* that someone will fail to follow "proper protocol" with
  1955. "foreign" media or file sources.  In corporate settings, the possibility
  1956. of the latter as a form of directed attack by disgruntled employees
  1957. cannot be overlooked.
  1958.  
  1959. Planning to minimize the impact of a virus infection on your computing
  1960. is much like planning to minimize the effect of an earthquake or fire.
  1961. You cannot be sure where, when or even *if* you will ever be "hit"; the
  1962. potential impact could fall anywhere in a very wide range of possible
  1963. damage; being "completely safe" can involve enormous expense; and you
  1964. cannot adequately test your preparations without exposing yourself to
  1965. serious risk of damage.  Therefore, finalizing on the defense scheme
  1966. that suits you involves deciding on the level of loss you can afford to
  1967. stand and probably settling on a system that, while not "perfectly
  1968. watertight," is "good enough".
  1969.  
  1970. Despite the importance of a good backup scheme, it is really beyond the
  1971. scope of this FAQ sheet to provide a definitive guide to planning your
  1972. backup procedure--that could easily take another document the size of
  1973. this!  All this said however, we provide the following advice as, we
  1974. hope, a good starting point.
  1975.  
  1976. Planning an effective backup scheme really starts with answering some
  1977. important questions.  Consider:
  1978.  
  1979. 1.   Who is dependent on the files on this system?  Is it a home
  1980.      computer mostly used by the kids for games, a standalone
  1981.      workstation running a small business, a networked workstation
  1982.      in a medium-sized company or the same in a large corporate
  1983.      environment, or a server with many (hundreds) of users?
  1984. 2.   How long can the most important user be without access to
  1985.      these files?  One hour, 2, 4, 8, a day, a week?  Remember to
  1986.      assume that your problems will arise at the worst possible
  1987.      moment (like 24 hours before a tax audit is due to start!).
  1988. 3.   What proportion (and volume!) of files are "fixed" (in the
  1989.      sense that they seldom change) versus those that change?  Do
  1990.      all changes have to be backed-up, or is a "once-some-given-
  1991.      time-period" backup acceptable?
  1992. 4.   What type of information is in the regularly changing files?
  1993.  
  1994. The answers to these (and other) questions help shape backup and
  1995. recovery plans and are fairly well understood issues amongst computer
  1996. systems professionals.  Highly critical systems containing crucial data
  1997. will be designed from the outset to have high redundancy (disk
  1998. mirroring, disk arrays, UPSes, maybe even redundant servers), though
  1999. such system options *alone* provide no real protection from virus
  2000. attacks.  You may opt for a backup system that records every change to
  2001. any files on your system (server-only or clients and servers) or regular
  2002. (often nightly) backup of changed data files, and so on.
  2003.  
  2004. When it comes to planning backup regimes with an eye to the possibility
  2005. of recovering from a virus attack, you also have to consider that
  2006. regularly backing-up executables (loosely, "programs") can cause
  2007. problems.  If you do and are infected by a virus, unless you can be
  2008. *absolutely sure* of the date of first infection (despite sounding
  2009. simple, this is not something that can commonly be done!), you may have
  2010. quite a few problems finding the best backup set to restore from, as you
  2011. will probably have several sets including infected executables.
  2012.  
  2013. For home or small business use, it may be best to maintain two kinds of
  2014. backups.  One would contain only your data files and one your operating
  2015. system and program files (issues to consider are covered in the next two
  2016. paragraphs).  This may be facilitated by maintaining a strict separation
  2017. of the two kinds of files, perhaps by putting the operating system and
  2018. programs on one drive or partition and your data files on another.
  2019. While this is probably not practical for many existing machines,
  2020. enforcing adherence to the "rule" that data files should only be placed
  2021. in appropriate sub-directories (folders) within a prescribed data
  2022. directory may not be a bad thing.
  2023.  
  2024. The best way to manage backup of data files depends on the answers to
  2025. too many of the questions listed above for us to give definitive advice
  2026. here.  While planning your backup regime, bear in mind that some viruses
  2027. damage some kinds of data files, while others make small, occasional,
  2028. random modifications as files are written to disk.  While viruses with
  2029. either of these "features" are quite rare, both of these possibilities
  2030. mean that vital data files should probably be backed-up to long-cycle
  2031. media sets as well as to shorter cycle sets and other steps taken to
  2032. ensure you can recreate the sequence of changes.  (For example, retain
  2033. all transaction records so they can be re-entered.)
  2034.  
  2035. You should probably backup executables once after installing them and
  2036. only *after* you are sure they are virus-free according to your current
  2037. antivirus screening procedures.  *Never* make a backup containing
  2038. executables over media that hold *any* of your current backups.  The
  2039. more cautious of us maintain several cycles of executable backups.
  2040. These precautions should ensure you don't face the problem outlined
  2041. several paragraphs ago, and mean that should a newly installed program
  2042. be infected with a virus your current defenses don't detect, you can
  2043. easily restore your system and installed software to how it was before
  2044. the infected software was installed, when you do become aware of its
  2045. presence.  You will probably have to manually reinstall any programs you
  2046. installed subsequent to installing the infected program.
  2047.  
  2048. Having referred to this second kind of backup as "executables only", we
  2049. should point out that a complete system backup is also acceptable for
  2050. this type of backup.  However, note that a sequence of full system
  2051. backups with interim "incremental" backups (when only those files that
  2052. have changed since the last complete backup are saved) is *not* what we
  2053. are advocating.  Such systems tend to be too "broad brush" to be truly
  2054. useful for recovering from an unknown, future virus attack.
  2055. Unfortunately, this tends to be the preferred/recommended backup scheme
  2056. for small-to-medium sized systems (including most personal computers),
  2057. and is typically what most popular backup software for such systems is
  2058. designed to do.  This doesn't mean that popular backup systems and
  2059. software aren't useful, just that you have to exercise some care in
  2060. using them (like excluding executable files from your incremental
  2061. backups).
  2062.  
  2063. Having said all this, there are still a few other problems to consider,
  2064. especially:  Which files should you count as "data" files?  This can be
  2065. problematic as most people immediately think of their word-processor and
  2066. spreadsheet files, and the like, as data, and that's about it.  What
  2067. about the files in which your programs store their configuration
  2068. information?  In a sense, these are as much "your data" as they are
  2069. program files, because they reflect your preferred screen colors and
  2070. layouts, default fonts, personalized button bars and so on.  When you
  2071. look at the time people spend finding the (often obscure) options
  2072. settings in their programs and making them work "just right", and how
  2073. upset they can be if they lose these settings, it makes sense to treat
  2074. such configuration files as you treat other "personal data files" in
  2075. your backup regimes.  Similarly, people tend to treat system
  2076. configuration files (in DOS/Windows PCs CONFIG.SYS, AUTOEXEC.BAT,
  2077. WIN.INI, SYSTEM.INI at a minimum!) as part of the system, often ignoring
  2078. the (sometimes considerable) fine-tuning these configuration files go
  2079. through *between* system and executable backups.
  2080.  
  2081. One last point--it cannot be stressed enough that you *MUST* have a
  2082. full, working copy of the software you need to restore your backups in a
  2083. safe place.  You must be able to guarantee that this software is not
  2084. virus infected should you ever have to use it, *AND* that it is fully
  2085. usable should you be facing a machine that has had its entire hard drive
  2086. "wiped clean".
  2087.  
  2088.  
  2089.  
  2090. ======================================================
  2091. = Section E.   Facts and Fibs About Computer Viruses =
  2092. ======================================================
  2093.  
  2094. E1)  Can boot sector viruses infect non-bootable DOS floppy disks?
  2095.  
  2096. Any DOS diskette that has been properly formatted contains some
  2097. executable code in its boot sector.  (There is some debate as to whether
  2098. this code should be called a program or not.  The important thing here
  2099. is that this code is *executed* at system startup if the diskette is in
  2100. the system's boot drive.)  If a diskette is not "bootable", all that
  2101. boot sector (normally) does is print a message (on a PC, typically
  2102. something like "Non-system disk or disk error; replace and strike any
  2103. key when ready").  However, the boot sector is still executable and
  2104. therefore vulnerable to infection.  Should you accidentally boot your
  2105. machine with a "non-bootable" diskette in the boot drive, and see that
  2106. message, it means that any boot virus that may have been on that
  2107. diskette *has* run, and had the chance to infect your hard drive, or
  2108. whatever.  So, when talking about viruses, the words "bootable" and "non-
  2109. bootable" are misleading.  All formatted diskettes are capable of
  2110. carrying boot sector viruses.
  2111.  
  2112. Most current computers will try to boot from their (first) floppy drive
  2113. before trying to load an operating system off their hard disks.  Because
  2114. of this and the fact that every floppy disk is possibly infected with a
  2115. boot sector virus, it is a *very* good idea to set your computer to try
  2116. to boot from its hard disk.  Many newer PCs offer the option to select
  2117. boot order in their system CMOS setup routines.  If your computer has
  2118. such an option, set it to try to boot from your hard disk first.
  2119.  
  2120.  
  2121. E2)  Can a virus hide in a PC's CMOS memory?
  2122.  
  2123. No.  The CMOS RAM in which PC system information is stored and backed up
  2124. by batteries is accessible through the I/O ports and not directly
  2125. addressable.  That is, in order to read its contents you have to use I/O
  2126. instructions rather than standard memory addressing techniques.
  2127. Therefore, anything stored in CMOS is not directly "in memory".  Nothing
  2128. in a normal machine loads the data from CMOS and executes it, so a virus
  2129. that "hid" in CMOS RAM would still have to infect an executable object
  2130. of some kind in order to load and execute whatever had been written to
  2131. CMOS.  A malicious virus can of course *alter* values in the CMOS as
  2132. part of its payload, but it can't spread through, or hide itself in, the
  2133. CMOS.
  2134.  
  2135. Further, most PCs have only 64 bytes of CMOS RAM and the use of the
  2136. first 48 bytes of this is predetermined by the IBM AT specification.
  2137. Several BIOS'es also use many of the "extra" bytes of CMOS to hold their
  2138. own, machine-specific settings.  This means that anything that a virus
  2139. stores in CMOS can't be very large.  A virus could use some of the
  2140. "surplus" CMOS RAM to hide a small part of its body (e.g. its payload,
  2141. counters, etc).  Any executable code stored there, however, must first
  2142. be extracted to ordinary memory in order to be executed.
  2143.  
  2144. This issue should not be confused with whether a virus can *modify* the
  2145. contents of a PC's CMOS RAM.  Of course viruses can, as this memory is
  2146. not specially protected (on normal PCs), so any program that knows how
  2147. to change CMOS contents can do so.  Some viruses do fiddle with the
  2148. contents of CMOS RAM (mostly with ill-intent) and these have often been
  2149. incorrectly reported as "infecting CMOS" or "hiding in CMOS".  An
  2150. example is the PC boot sector virus EXE_Bug, which changes CMOS settings
  2151. to indicate that no floppy drives are present (see G8 for more details).
  2152.  
  2153.  
  2154. E3)  Can a PC virus hide in Extended or in Expanded RAM in a PC?
  2155.  
  2156. Yes.  If one does though, it has to have a small part resident in
  2157. conventional RAM; it cannot reside *entirely* in Extended or in Expanded
  2158. RAM.  Currently there are no known XMS viruses and only a few EMS
  2159. viruses (Emma is an example).
  2160.  
  2161.  
  2162. E4)  Can a virus hide in a PC's Upper Memory or in High Memory Area?
  2163.  
  2164. Yes, it is possible to construct a virus which will locate itself in
  2165. Upper Memory Blocks (UMBs--640K to 1024K) or in the High Memory Area
  2166. (HMA--1024K to 1088K).  Some viruses (e.g. EDV) do hide in UMBs and at
  2167. least one, Goldbug, will use the HMA if it is available.
  2168.  
  2169. It might be thought that there is no point in scanning in these areas
  2170. for any viruses other than those that are specifically known to inhabit
  2171. them.  However, there are cases when even ordinary viruses can be found
  2172. in Upper Memory.  Suppose that a conventional memory-resident virus
  2173. infects a TSR program and this program is loaded high by the user (for
  2174. instance, from AUTOEXEC.BAT).  Then the virus code will also reside in
  2175. Upper Memory.  Therefore, an effective scanner must be able to scan this
  2176. part of memory for viruses too.
  2177.  
  2178.  
  2179. E5)  Can a virus infect data files?
  2180.  
  2181. Some viruses (e.g., Frodo, Cinderella) modify non-executable files.
  2182. However, in order to spread, the virus code must be executed.  Therefore
  2183. "infected" non-executable files cannot be sources of further infection.
  2184. Such "infections" are usually mistakes, due to bugs in the virus.
  2185.  
  2186. Even so, note that it is not always possible to make a sharp distinction
  2187. between executable and non-executable files.  One person's data can be
  2188. another's code and vice versa.  Some files that are not directly
  2189. executable contain code or data which can, under some conditions, be
  2190. executed or interpreted.
  2191.  
  2192. Some examples from the PC world are OBJ files, libraries, device
  2193. drivers, source files for any compiler or interpreter (including DOS BAT
  2194. files and OS/2 CMD files), macro files for some packages like Microsoft
  2195. Word and Lotus 1-2-3, and many others.  Currently there are viruses that
  2196. infect boot sectors, master boot records, COM files, EXE files, BAT
  2197. files, OBJ files, device drivers, Microsoft Word document and template
  2198. files, and C source code files, although any of the objects mentioned
  2199. above theoretically can be used as an infection carrier.  PostScript
  2200. files can also be used to carry a virus, although no currently known
  2201. virus does this.
  2202.  
  2203. Aside from the above, however, there is an increasing possibility of
  2204. viruses spreading through the sharing of data files.  More and more we
  2205. see the ease with which software producers give their programs the
  2206. ability to embed "objects" of many kinds into document files, and into
  2207. fields in databases and spreadsheets.  Perhaps the best-known of these
  2208. systems are Object Linking and Embedding (OLE) in MS Windows and the
  2209. OpenDoc format.  As these embedded objects often have the ability to
  2210. "display" themselves we see that many files traditionally thought of as
  2211. data-only, will increasingly be containers carrying data and executable
  2212. code.  We are not aware of any virus that specifically targets such
  2213. executable "objects", but it is now a trivial task to embed executable
  2214. files into some kinds of document files so they will be run when the
  2215. icon representing them is clicked in the finished document.  There is
  2216. nothing to prevent infected executables being embedded in this way, and
  2217. thus for viruses to be spread through the distribution of "data files".
  2218.  
  2219.  
  2220. E6)  Can viruses spread from one type of computer to another?
  2221.  
  2222. The simple answer is that no currently known viruses can do this.
  2223. Although some disk formats may be the same (e.g. Atari ST and DOS), the
  2224. different machines interpret the code differently.  For example, the
  2225. Stoned virus cannot infect an Atari ST as the ST cannot execute the
  2226. virus code in the boot sector.  The Stoned virus contains instructions
  2227. for the 80x86 family of CPUs that the 680x0 CPU family (used in the
  2228. Atari ST) can't understand or execute.
  2229.  
  2230. The more general answer is that such viruses are possible, but unlikely.
  2231. Such a virus would be quite a bit larger than current viruses and might
  2232. well be easier to find.  Additionally, the low incidence of cross-
  2233. platform sharing of software means that any such virus would be unlikely
  2234. to spread--it would be a poor environment for virus growth.
  2235.  
  2236. A related, but different, issue is that of viruses running under
  2237. operating system emulators on machines other than those for which the
  2238. operating system was originally designed.  This is covered in some
  2239. detail elsewhere in the FAQ sheet (see C12).
  2240.  
  2241.  
  2242. E7)  Are mainframe computers susceptible to computer viruses?
  2243.  
  2244. Yes.  Numerous experiments have shown that computer viruses spread very
  2245. quickly and effectively on mainframe systems.  To our knowledge,
  2246. however, no non-research computer virus has been seen on mainframe
  2247. systems.  (Despite often being described as such, the widely reported
  2248. Internet Worm of November 1988 was not a computer virus by most
  2249. definitions, although it had some virus-like characteristics.)
  2250.  
  2251. Many people think that computer viruses are impossible on mainframe
  2252. computers, because their operating systems provide means of protection
  2253. (e.g., memory protection, access control, etc.) that cannot by bypassed
  2254. by a program, unlike the operating systems of most personal computers.
  2255. Unfortunately, this belief is false.  As demonstrated by Fred Cohen in
  2256. 1984, access controls are unable to prevent computer viruses--they can
  2257. only slow down the speed with which viruses spread.  If there is a
  2258. transitive path of information flow from one account to another on a
  2259. mainframe computer, then a virus can spread from one account to the
  2260. other, without having to bypass any protections.
  2261.  
  2262. Consider the following example.  The attacker (A) has an account on a
  2263. machine and wants to attack it with a virus.  In order to do this, A
  2264. writes a virus and releases it.  Due to the protection provided by the
  2265. operating system, the virus can only infect the files writable by A.  On
  2266. a typical system, those would be only the files owned by A.
  2267.  
  2268. However, A is not alone on the system.  A works with B on some joint
  2269. projects.  At some time, B might want to check how far A has progressed
  2270. in her/his part of the project.  This might involve running one of the
  2271. programs that A has written--programs that are now all infected with A's
  2272. virus.
  2273.  
  2274. On a sytem with protection based on discretionary access controls (e.g.,
  2275. Unix, VMS, and most other popular OSes), the program that is being
  2276. executed usually runs with the privileges of the user who is executing
  2277. it--not with those of the program's owner.  (In the few instances where
  2278. this is not the case, it presents a different kind of security threat,
  2279. unrelated to viruses.)  That is, when B runs A's infected program, the
  2280. virus in it will run with B's privileges and will be able to infect all
  2281. programs writable by B.
  2282.  
  2283. At some later time, A and B's boss, C, might want to check whether they
  2284. have completed that joint project.  Even if the boss has reasons to
  2285. suspect A (e.g., as a disgruntled employee), s/he is likely to trust B
  2286. and execute one of her/his programs.  This results in the virus running
  2287. with C's privileges (which are likely to be significantly greater than
  2288. those of A and B) and infecting all programs writable by C.  Quite
  2289. possibly, these programs will include many owned by other employees,
  2290. thus creating many more distribution chains that nobody suspects.
  2291.  
  2292. The virus may interfere somehow with C's normal work, which causes C
  2293. (who is probably not very knowledgeable about such things as computer
  2294. security and viruses) to ask the system administrator, D, for help.  If
  2295. D executes one of C's infected programs (and s/he is much more likely to
  2296. trust a respectable person like C--who is quite probably D's boss as
  2297. well--than any of C's employees), this will cause the virus that A wrote
  2298. a long time ago to run with system administrator privileges and do
  2299. whatever it wants with the system--infect other users' files, attack
  2300. other systems, etc.
  2301.  
  2302. A trivial improvement of the above scenario (in terms of speeding up the
  2303. virus' spread) would be for the attacker to place the virus in some kind
  2304. of Trojan Horse--for example, in an attractive game or utility--placed
  2305. in a publicly accessible area.
  2306.  
  2307. Why, then, are there so many fewer viruses for mainframe computers than
  2308. for personal ones?  The answer to this question is complex.  First,
  2309. writing a well-made mainframe virus--one that does not cause problems
  2310. and is likely to remain unnoticed--is not a trivial task.  It requires a
  2311. lot of knowledge about the operating system.  This knowledge is not
  2312. commonly available and the typical youngster who is likely to hack a
  2313. quick-and-dirty PC virus is unlikely to possess it or be in a position
  2314. to learn it.  People who possess this knowledge are likely to use it in
  2315. more constructive, satisfying, and profitable ways.  Second, the culture
  2316. of software exchange in the mainframe world differs considerably from
  2317. that of the PC world--we don't see many VMS users running around with a
  2318. bootable tape of the latest game...  Third, very often it is easier to
  2319. attack a mainframe computer by using some security hole or a Trojan
  2320. Horse, instead of by using a virus.
  2321.  
  2322. So, computer viruses for mainframe computers are definitely possible and
  2323. several already exist (see question F1).  Also, some IBM PC viruses can
  2324. infect any IBM PC compatible machine, even if it runs a "real" OS like
  2325. Unix.  For more information, refer to questions D6 and E7.
  2326.  
  2327. Forms of malware other than computer viruses--notably Trojan Horses--are
  2328. far quicker, more effective, and harder to detect than computer viruses.
  2329. Nevertheless, on personal computers many more viruses are written than
  2330. Trojan Horses.  There are two reasons for this:
  2331.  
  2332. 1.   Since a virus is self-propogating, the number of users to
  2333.      which it can spread (and cause damage) can be much greater
  2334.      than in the case of a Trojan;
  2335.  
  2336. 2.   It's almost impossible to trace the source of a virus since
  2337.      (generally) viruses are not attached to any particular
  2338.      program.
  2339.  
  2340. For further information on malicious programs on multi-user systems, see
  2341. Matt Bishop's paper, "An Overview of Malicious Logic in a Research
  2342. Environment", available by anonymous FTP on Dartmouth.edu (IP =
  2343. 129.170.16.4) as pub/security/mallogic.ps.
  2344.  
  2345.  
  2346. E8)  Some people say that disinfecting is a bad idea.  Is that true?
  2347.  
  2348. Disinfection is completely "safe" only if the disinfecting process
  2349. completely restores the non-infected state of the object.  That is, not
  2350. only must the virus be removed from the object, but the original length
  2351. must be restored exactly, as well as any system attributes (such as time
  2352. and date of last modification, fields in the header, etc).  Sometimes it
  2353. is necessary to be sure that the object is placed on the same sectors of
  2354. the disk that it occupied prior to infection (this is particularly
  2355. important for some system areas and some files from programs which use
  2356. certain kinds of self-checking or copy protection).
  2357.  
  2358. None of the currently available disinfecting programs do all this.  For
  2359. instance, because of the bugs that exist in many viruses and because
  2360. some infection processes involve overwriting (part of) the objects of
  2361. infection, some of the information about the original object may be
  2362. irrevocably destroyed.  Sometimes it is not even possible to detect that
  2363. this information has been destroyed and to warn the user.  Furthermore,
  2364. some viruses corrupt information very slightly and in a random way
  2365. (Nomenklatura, Ripper), so that it is not even possible to tell which
  2366. objects have been corrupted.
  2367.  
  2368. Therefore, it is usually better to replace infected objects with clean
  2369. backups, provided you are certain that your backups are uninfected (see
  2370. D10), or from the original media.  You should try to disinfect files
  2371. only if they contain some valuable data that cannot be restored from
  2372. backups or recompiled from their original source.
  2373.  
  2374.  
  2375. E9)  Can I avoid viruses by avoiding shareware, free software or games?
  2376.  
  2377. No.  There are many documented instances in which even commercial
  2378. "shrink wrapped" software was inadvertently distributed containing
  2379. viruses.  Avoiding shareware, freeware, games, etc, only isolates you
  2380. from a vast collection of software (some of it very good, some of it
  2381. very bad, most of it somewhere in between...).
  2382.  
  2383. The important thing is not to avoid a certain type of software, but to
  2384. be cautious of *any and all* newly acquired software and diskettes.
  2385. Merely scanning all new software media for known viruses would be rather
  2386. effective at preventing virus infections, especially when combined with
  2387. some other prevention/detection strategy such as integrity management of
  2388. programs.
  2389.  
  2390.  
  2391. E10) Can I contract a virus on my PC by performing a "DIR" of an
  2392.      infected floppy disk?
  2393.  
  2394. Assuming the PC you are using is virus free before you perform the DIR
  2395. command, then the answer is "No".
  2396.  
  2397. When you perform a DIR, the contents of the boot sector of the diskette
  2398. are loaded into a buffer for use in determining disk layout etc, and
  2399. certain antivirus products will scan these buffers.  If a boot sector
  2400. virus has infected your diskette, the virus code will be contained in
  2401. the buffer, which may cause some antivirus packages to produce a message
  2402. like "xyz virus found in memory...".  In fact, the virus is not a threat
  2403. at this point since control of the CPU is never passed to the virus code
  2404. residing in the buffer.  Even though the virus is really not a threat at
  2405. this point, this message should not be ignored.  If you get a message
  2406. like this, and then reboot from a clean DOS diskette (see G8) and scan
  2407. your hard-drive and find no virus, then you know that the false positive
  2408. was caused by an infected boot-sector loaded into a buffer, and the
  2409. diskette should be disinfected before use.  The use of DIR will not
  2410. infect a clean system, even if the diskette it is being performed on
  2411. does contain a virus (see C8 also).  Please note, however, that running
  2412. DIR on a diskette can result in the infection of a clean diskette if the
  2413. PC is already infected.
  2414.  
  2415. Despite our categorical "No" answer above, there is a small risk that a
  2416. virus infection could be transferred from a floppy through a DIR
  2417. listing.  If you use an ANSI console driver that allows key remapping,
  2418. it is possible that a specially prepared diskette could reprogram your
  2419. keyboard so that pressing a particular key caused an infected program on
  2420. the diskette to run the next time the reprogrammed key was pressed.  The
  2421. risk of such an attack is very low and can easily be negated following
  2422. the general advice for preventing ANSI bombs (see B14).
  2423.  
  2424. Mac users with system software prior to version 7.0 should be aware of a
  2425. greater threat in their environment.  Various system resources (which
  2426. can contain executable code) are loaded from the automatic access to a
  2427. diskette that is part of the system building its desktop view of the
  2428. diskette's contents.  When such a resource is required, the most
  2429. recently loaded one will be used.  Thus, if a diskette with a virus-
  2430. infected resource in the Desktop file is in your Mac's drive, and an
  2431. uninfected copy of that resource has not subsequently loaded from
  2432. elsewhere, the next time that resource is required the infected copy
  2433. will be executed, along with the virus.  This kind of attack was removed
  2434. with the introduction of version 7.0 (and later) of the system software,
  2435. which handles such things quite differently.  A common Mac virus, WDEF,
  2436. uses this infection path, as do a few others.
  2437.  
  2438. Early versions of AmigaDOS are susceptible to a threat similar to the
  2439. Mac WDEF virus--on inserting a diskette into the drive, the operating
  2440. system runs the Disk Validator from the diskette.  At least one Amiga
  2441. virus, Saddam, attaches itself to Disk Validator to help it spread.
  2442. Version 2.0 of AmigaDOS eliminated the threat of this type of attack by
  2443. removing the need for the Disk Validator.
  2444.  
  2445.  
  2446. E11) Is there any risk in copying data files from an infected floppy
  2447.      disk to a clean PC's hard disk?
  2448.  
  2449. Assuming that you did not boot or run any executable programs from the
  2450. infected disk, the answer generally is no.  There are two caveats:
  2451.  
  2452. 1.   You should be somewhat concerned about checking the integrity
  2453.      of these data files as they may have been destroyed or
  2454.      altered by the virus.
  2455. 2.   If any of the "data" files are interpretable as executable by
  2456.      some other program (such as a Lotus macro) then these files
  2457.      should be treated as potentially malicious until the symptoms
  2458.      of the infection are known.
  2459.  
  2460. The copying process itself is safe (given the above scenario) although
  2461. you should be concerned with what type of files are being copied to
  2462. avoid introducing other problems.
  2463.  
  2464.  
  2465. E12) Can a DOS virus survive and spread on an OS/2 system using the
  2466.      HPFS file system?
  2467.  
  2468. Yes, both file-infecting and boot sector viruses can infect HPFS
  2469. partitions.  File-infecting viruses function normally and can activate
  2470. and do their dirty deeds, and boot sector viruses can prevent OS/2 from
  2471. booting if the primary bootable partition is infected.  Viruses that try
  2472. to address disk sectors directly cannot function under OS/2 because the
  2473. operating system prevents this activity.
  2474.  
  2475.  
  2476. E13) Under OS/2 2.0+, could a virus infected DOS session infect another
  2477.      DOS session?
  2478.  
  2479. Each DOS program is run in a separate Virtual DOS Machine (their memory
  2480. spaces are kept separate by OS/2).  However, any DOS program has almost
  2481. complete access to the files and disks, so infection can occur if the
  2482. virus infects files; any other DOS session that executes a program
  2483. infected by a virus that makes itself memory resident would itself
  2484. become infected.
  2485.  
  2486. Also, bear in mind that generally all DOS sessions share the same copy
  2487. of the command interpreter.  Hence if *it* becomes infected, the virus
  2488. will be active in *all* DOS sessions.
  2489.  
  2490.  
  2491. E14) Can normal DOS viruses work under MS Windows?
  2492.  
  2493. Most of them cannot.  A system that runs exclusively MS Windows is, in
  2494. general, more virus-resistant than a plain DOS system.  The reason is
  2495. that most resident viruses are not compatible with the memory management
  2496. in Windows.  Furthermore, most existing viruses will damage Windows
  2497. applications if they try to infect them as normal (i.e. DOS) EXE files.
  2498. The damaged applications will stop working and this will alert the user
  2499. that something is wrong.
  2500.  
  2501. Virus-resistant however, is by no means virus-proof.  For instance, most
  2502. of the well-behaved resident viruses that infect only COM files (Cascade
  2503. is an excellent example), will work perfectly in a "DOS box".  All non-
  2504. resident COM infectors will be able to run and infect too.  Aside from
  2505. DOS viruses, MS Windows users can also contract several currently known
  2506. Windows-specific viruses, which are able to infect Windows applications
  2507. properly (i.e., they are compatible with the NewEXE file format).
  2508.  
  2509. Any low level trapping of Interrupt 13, as by resident boot sector and
  2510. MBR viruses, can also affect Windows operation, particularly if
  2511. protected disk access (32BitDiskAccess=ON in SYSTEM.INI) is used.
  2512.  
  2513.  
  2514. E15) Can I get a virus from reading e-mail, BBS message forums or
  2515.      USENET News?
  2516.  
  2517. In general terms, the answer is no.  E-mail messages and postings on
  2518. BBSes and News are text data and will not be executed as programs.
  2519. Computer viruses are programs, and must be executed to do anything, so
  2520. the simple act of reading online messages doesn't pose a threat of
  2521. catching a computer virus.
  2522.  
  2523. There are a few provisos to be made.  If your computer uses ANSI screen
  2524. and keyboard controls, you may be susceptible to an ANSI bomb (see B14).
  2525. An ANSI bomb may, merely by being placed in text read on the screen,
  2526. temporarily redefine keys on the keyboard to perform various functions.
  2527. It is, however, very unlikely that you will ever see an ANSI bomb in
  2528. e-mail, or that it could do significant damage while you are reading
  2529. mail.
  2530.  
  2531. Another possibility is that mail can be used to send programs.  To do
  2532. this program files have to be encoded into a special form so the binary
  2533. (8-bit) program files are not corrupted by transfer over the text-only
  2534. (7-bit) e-mail transport medium.  Probably the commonest of these
  2535. encoding schemes is uuencoding, though there are several others.  If you
  2536. receive an encoded program, you normally have to use a decoding program
  2537. or special option in your e-mail program to extract it and decode it
  2538. before it can be run.  Once you have extracted the program though, you
  2539. should then treat it as you would any other program whose source you do
  2540. not know, and test it before you run it.
  2541.  
  2542. A third possibility is with the newer, highly-automated online systems.
  2543. Some of these attempt to make online access much easier for the user by
  2544. automating such features as file transfer and program updates.  At least
  2545. one commercial online service is known to have the capability of sending
  2546. new programs to the user and to invoke those programs while the user is
  2547. still online.  While there is no reason to assume that any service that
  2548. does this *will* infect you, any time things are going on that you are
  2549. not being told about, you are at greater risk.
  2550.  
  2551.  
  2552. E16) Can a virus "hide" in a GIF or JPEG file?
  2553.  
  2554. The simple answer is "no".  The complete answer is more complex.
  2555.  
  2556. GIF and JPEG (.JPG) files contain compressed graphical information.
  2557. Every now and then, rumors arise that is possible to infect those files
  2558. with a virus in such a way, that it will spread when you display one of
  2559. these images.  This is technically impossible--no part of the GIF or
  2560. JPEG format contains code that is executed by the viewer program.
  2561.  
  2562. It *is* possible to use the least significant bit of the color
  2563. information for each pixel in GIF files to store additional information,
  2564. without visibly altering the quality of the picture contained in the
  2565. file.  This is called "steganography" and is sometimes used to transmit
  2566. secretly encrypted messages.  Since a virus is nothing more than
  2567. information, it is possible to "encode" it into a GIF file and transmit
  2568. it this way.  However, the recipients must be aware that the GIF file
  2569. contains such hidden information and take some deliberate steps to
  2570. extract it--it cannot happen against their will.
  2571.  
  2572.  
  2573.  
  2574. ========================================
  2575. = Section F.   Miscellaneous Questions =
  2576. ========================================
  2577.  
  2578. F1)  How many viruses are there?
  2579.  
  2580. It is not possible to give an exact number because new viruses are
  2581. literally being created every day.  Furthermore, different antivirus
  2582. researchers use different criteria to decide whether two viruses are
  2583. different or one and the same.  Some count viruses as different if they
  2584. differ by at least one bit in their non-variable code.  Others group
  2585. viruses in families and do not count the closely related variants within
  2586. a family as different viruses.
  2587.  
  2588. Further, some antivirus researchers have samples in their collections
  2589. that they count as viruses, but that several other experts strongly deny
  2590. are viruses.  Sometimes these are "partial viruses", where a virus has
  2591. not properly infected a host and are therefore non-infective, other
  2592. times they are well-known non-viruses.  As some of these non-viruses are
  2593. known to be in some of the common test sets, some antivirus software
  2594. vendors count them amongst the viruses they detect.
  2595.  
  2596. As of January 1995 there were about 5,600 PC viruses, about 150 Amiga
  2597. viruses, about 100 Acorn Archimedes viruses, about 45 Macintosh viruses,
  2598. several Atari ST viruses, a few Apple II viruses, four Unix viruses,
  2599. three MS Windows viruses, at least two OS/2 viruses and two VMS DCL-
  2600. based viruses.
  2601.  
  2602. Fortunately, few of the existing viruses are widespread.  For instance,
  2603. only about three dozen of the known PC viruses cause most of the
  2604. reported infections and fewer than 200 PC viruses have been found in the
  2605. wild at all.
  2606.  
  2607.  
  2608. F2)  How do viruses spread so quickly?
  2609.  
  2610. This is a very complex issue, and some viruses don't spread quickly at
  2611. all (though talk of them often does!).
  2612.  
  2613. Those that do spread widely are able to do so for a variety of reasons.
  2614. A large target population--millions of compatible computers--helps. A
  2615. large virus population helps.  Vendors whose quality assurance relies
  2616. on, for example, outdated scanners, help.  Users who gratuitously
  2617. install new software on their systems without making any attempt to test
  2618. for viruses help.  All of these things are factors.
  2619.  
  2620.  
  2621. F3)  What is the correct plural of "virus"?  "Viruses" or "viri" or
  2622.      "virii" or "vira" or...
  2623.  
  2624. The correct English plural of "virus" is "viruses".  The Latin word is a
  2625. mass noun (like "air") and, therefore, there is no correct Latin plural.
  2626. Please use "viruses", and if people use other forms, please do *not* use
  2627. Virus-L/comp.virus to correct them.
  2628.  
  2629.  
  2630. F4)  When reporting a virus infection (and looking for assistance), what
  2631.      information should be included?
  2632.  
  2633. People frequently post messages to Virus-L/comp.virus requesting
  2634. assistance with a suspected virus problem.  Quite often the information
  2635. supplied is insufficient for the various experts on the list to be able
  2636. to help at all.  Also, please note that any such assistance from members
  2637. of the list is provided on a voluntary basis; be grateful for any help
  2638. received.  Try to provide the following information in your requests for
  2639. assistance:
  2640.  
  2641. 1.   The date and location (town and country) of suspected
  2642.      infection.
  2643. 2.   The name of the virus (if known)
  2644. 3.   The program (or programs) and version that called the virus
  2645.      by that name.
  2646. 4.   Any other antivirus software that you are running and whether
  2647.      it has been able to detect the virus or not, and if yes, what
  2648.      name it called the virus.
  2649. 5.   Your software and hardware configuration (computer type,
  2650.      kinds of disk(ette) drives, amount of memory and
  2651.      configuration (extended/expanded/conventional), the exact
  2652.      version of your OS, TSR programs and device drivers used,
  2653.      control panels and INITs, etc.).
  2654. 6.   Any "unusual" behavior that has occurred recently and any new
  2655.      software (including upgrades) you have recently installed.
  2656.  
  2657. It is helpful if you can use more than one scanning program to identify
  2658. a virus, and to say which scanner gave which identification.  However,
  2659. some scanning programs leave "scan strings" in memory which will confuse
  2660. others, so it is best to do a "cold reboot" between runs of successive
  2661. scanners, particularly if you are getting conflicting results (see C6).
  2662.  
  2663.  
  2664. F5)  How often should we upgrade our antivirus tools to minimize
  2665.      software and labor costs and maximize our protection?
  2666.  
  2667. This is a difficult question to answer.  Antivirus software is a kind of
  2668. insurance, and these type of calculations are difficult.
  2669.  
  2670. There are two things to watch out for here: the general "style" of the
  2671. software, and the scan strings that scanners use to identify viruses.
  2672. Scanners should be updated more frequently than other software, and it
  2673. is probably a good idea to update a scanner's set of scan strings at
  2674. least once every two months.  In the six or so months prior to January
  2675. 1995, most of the popular PC-based virus scanners typically added
  2676. detection of about 500-600 new viruses or variants--this averages out to
  2677. between two and three new viruses per day!
  2678.  
  2679. Some antivirus software looks for changes to programs or specific types
  2680. of viral "activity", and these programs generally claim to be good for
  2681. "all current and future viral programs".  However, even these programs
  2682. cannot guarantee to protect against all future viruses, as new "attack"
  2683. and anti-antivirus methods are continually being developed by virus
  2684. writers.  Thus, even this type of antivirus software needs to be
  2685. upgraded occasionally.
  2686.  
  2687. Of course, not every antivirus product is effective against all viruses,
  2688. even if upgraded regularly.  Thus, do *not* depend on the fact that you
  2689. have upgraded your product recently as a guarantee that your system is
  2690. free of viruses!
  2691.  
  2692.  
  2693. F6)  What are "virus simulators" and what use are they?
  2694.  
  2695. There are three different kinds of programs that are often called "virus
  2696. simulators". None of the three generate actual viruses.  The first kind
  2697. demonstrate the audio- and video-effects of some real computer viruses.
  2698. The second kind are programs that simulate a virtual environment--a
  2699. virtual computer, with virtual disks, virtual files, and virtual viruses
  2700. on them.  The user of such programs can manipulate the simulated
  2701. objects, letting the simulated viruses infect the simulated files on the
  2702. simulated disks, watching every step of the process, without a danger of
  2703. "real infection".  The third kind are programs that generate files
  2704. containing scan strings used by some scanners to detect real viruses.
  2705. The idea is that those scanners will detect the generated files too,
  2706. thus letting the user get the feeling of what discovering a virus is
  2707. like, but without the danger of risking a real infection.
  2708.  
  2709. There are three ways in which virus simulators are usually used:
  2710.  
  2711. 1) For educational purposes.  The second kind of virus simulators are
  2712. very useful and valuable for this purpose, provided the simulated
  2713. environment is realistic enough.  The first kind are also somewhat
  2714. useful--mainly teaching the users what the video- or audio-effects of
  2715. particular viruses are like.  There is the danger, however, that users
  2716. will get the incorrect impression that *every* computer virus
  2717. demonstrates itself in some visible or audible way.  The third kind of
  2718. virus simulators are not useful for this purpose--they do not show how
  2719. computer viruses work, do not show what computer viruses do, and because
  2720. their virus fragments are not reliably detected as viruses by many good
  2721. scanners, may give the wrong impression of a scanner's value.
  2722.  
  2723. 2) As an installation check that antivirus defenses are installed and
  2724. working.  The first and second kinds of virus simulators are unsuitable
  2725. for this, because they do not trigger any antivirus defenses.  Even the
  2726. third kind of virus simulators have a rather limited value in this
  2727. regard, as the files generated by them often fail to trigger virus
  2728. defenses, which are designed to protect against *real* viruses.  Unlike
  2729. the producers of such simulators, many believe it is the job of the
  2730. producer of an antivirus product to provide the means of checking
  2731. whether their product is installed and working.  This position is based
  2732. on the authors knowing their products better than anyone else and that
  2733. updated check methods will normally be provided as the antivirus
  2734. defenses employed in any given product change.
  2735.  
  2736. 3) As a test of the quality of the antivirus defense--usually a scanner.
  2737. Again, the first two kinds of simulators are unsuitable for this purpose
  2738. because they do not trigger antivirus defenses.  The third kind of virus
  2739. simulators often do, from which many users get the impression that they
  2740. are suitable for these testing purposes.  This is a serious
  2741. misconception.  The files that such programs generate are not real
  2742. viruses; antivirus programs, particularly virus-specific ones like
  2743. scanners, are designed to detect real viruses.  Therefore, one must not
  2744. draw a conclusion from the ability or the inability of a product to
  2745. detect "simulated viruses" of the third kind--the fact that they are
  2746. detected does not necessarily mean that a real virus will be detected,
  2747. and the fact that they are not detected does not mean that the real
  2748. virus it is supposed to represent will not be detected!
  2749.  
  2750. One exception to the above are simulators that do not generate files
  2751. containing scan strings, but which simulate the different kinds of
  2752. attacks that real viruses use, but without being able to replicate.
  2753. Examples of such attacks include different methods of tunnelling,
  2754. stealth, attacks against integrity checkers, and so on.  Such simulators
  2755. are useful for testing antivirus products that are not virus-specific,
  2756. especially if the simulator exercises a wide range of known attacks.
  2757.  
  2758.  
  2759. F7)  I've heard talk of "good viruses".  Is it possible to use a
  2760.      computer virus for something useful?
  2761.  
  2762. A very hotly debated topic that has flared-up dramatically several times
  2763. in Virus-L/comp.virus.  The answer to this is not simple and largely
  2764. hinges on your definition or interpretation of the term computer virus.
  2765.  
  2766. By definition (see B1), viruses do not have to do something "bad"
  2767. (although many people argue that the uninvited "resource wasting" that
  2768. is almost inherent in viral activity is necessarily bad).  From this
  2769. point (and based on his somewhat esoteric definition of the term
  2770. computer virus) Fred Cohen has argued that "good" or "useful" computer
  2771. viruses are a serious possibility.  In fact, Dr. Cohen offered a reward
  2772. of $1000 for the first clearly "useful" virus--despite several potential
  2773. claimants, however, he hasn't paid up.
  2774.  
  2775. Although there has never been a position that was widely agreed upon as
  2776. a result of any of these discussions, many contributors to this forum
  2777. believe that there are serious problems with the idea of implementing
  2778. useful computing functionality through self-replicating programs.
  2779. Vesselin Bontchev's paper originally delivered at the 1994 EICAR
  2780. conference, titled "Are `Good' Computer Viruses Still a Bad Idea?", is
  2781. available by anonymous FTP from ftp.informatik.uni-hamburg.de (IP =
  2782. 134.100.4.42), as pub/virus/texts/viruses/goodvir.zip.  *Anyone* wishing
  2783. to raise this discussion in Virus-L/comp.virus again should read and
  2784. carefully consider this paper before posting.  It contains many strong
  2785. arguments against the idea of "good computer viruses", and some
  2786. prescriptions of how good viruses would have to be implemented and
  2787. distributed to deserve the label "good".  To date no strong arguments
  2788. countering the points in this paper or otherwise arguing in favor of the
  2789. concept of good viruses have been posted to the group.
  2790.  
  2791.  
  2792. F8)  Wouldn't adding self-checking code to your programs be a good idea?
  2793.  
  2794. Every few months somebody suggests the idea of adding a small piece of
  2795. code to existing programs.  This code would check for virus infections
  2796. when the program is executed by comparing a previously computed CRC or
  2797. cryptographic checksum (hash value) of the file in its known clean state
  2798. with its current value.  The idea is that this will detect any virus
  2799. infection immediately, and is thus effective against unknown viruses.
  2800.  
  2801. A simple and intuitively attractive idea--in fact, some antivirus
  2802. programs have included options to do just this.  There are, however,
  2803. some serious flaws with this approach.
  2804.  
  2805. This method cannot prevent the program from getting infected in the
  2806. first place.  Further, if a program that has been protected this way
  2807. becomes infected later, whenever it is run the virus code will be
  2808. activated first.  The virus may then be able to detect or even remove
  2809. the self-checking code, or it might make it totally ineffective by using
  2810. stealth techniques, so the self-checking code only "sees" the original,
  2811. non-infected program.
  2812.  
  2813. Some programs contain an internal self-check--much antivirus software,
  2814. for example.  Such internal code might also be unable to detect stealth
  2815. viruses, but unless the external self-check code uses stealth techniques
  2816. too, the result will be a conflict, where the internal check will notice
  2817. the newly added code and decide that it has been "infected".
  2818.  
  2819. Moreover, this method is ineffective against "companion" viruses that
  2820. don't modify the applications they infect.
  2821.  
  2822. It may not be possible to protect all programs this way.  For example,
  2823. under DOS it is relatively easy to add code of this type to most COM
  2824. files (unless the original program was slightly less than 64K, and the
  2825. resulting file would break that limit).  However, EXE files are more of
  2826. a problem--especially those containing internal overlays, where one
  2827. cannot append the code to the file, as the resulting file might become
  2828. too big to load.  Windows applications are also a problem, as they have
  2829. two different entry points, and special care has to be taken to handle
  2830. that correctly.
  2831.  
  2832. On the other hand, adding internal self-checking to programs as part of
  2833. their development is a good idea.  Although it has the same limitations
  2834. regarding stealth viruses, it does not cause the conflicts described
  2835. above, and can be put in any program at compile-time.  It is also much
  2836. more difficult for viruses to bypass.
  2837.  
  2838.  
  2839.  
  2840. ===================================================================
  2841. = Section G.   Specific Virus and Antivirus Software Questions... =
  2842. ===================================================================
  2843.  
  2844. G1)  I was infected by the Jerusalem virus and disinfected the infected
  2845.      files with my favorite antivirus program.  However, WordPerfect
  2846.      and some other programs still refuse to work.  Why?
  2847.  
  2848. The Jerusalem virus and WordPerfect 4.2 program combination is an
  2849. example of a virus and program that cannot be completely disinfected by
  2850. an antivirus tool.  In some cases such as this, the virus will destroy
  2851. code by overwriting it instead of appending itself to the file.  The
  2852. only solution is to re-install the programs from clean (non-infected)
  2853. backups or distribution media (see D10 and E8).
  2854.  
  2855.  
  2856. G2)  Is my disk infected with the Stoned virus?
  2857.  
  2858. Of course the answer to this, and many similar questions, is to obtain a
  2859. good virus detector.  There are many to choose from, including ones that
  2860. will scan diskettes automatically as you use them.  As Stoned is a boot
  2861. sector infector, remember to check all diskettes, even non-system or
  2862. "data" diskettes (see E1).
  2863.  
  2864. It is possible, if you have an urgent need to check a system when you
  2865. don't have any antivirus tools, to run CHKDSK or MEM and note down the
  2866. values reported (see C1) and then to boot from a known clean system
  2867. diskette and compare the results returned by CHKDSK or MEM.  If the
  2868. total amount of conventional memory reported is different between the
  2869. two boots then you may have a viral problem but this information alone
  2870. cannot tell us if it is Stoned.  If you cannot see the PC's hard disk
  2871. (usually the C: drive) then it is even more likely you have a virus
  2872. problem, though definitely not Stoned.  If you have a "disk editor" type
  2873. program, looking at the boot sector of a suspect floppy, or the MBR of
  2874. the suspect hard drive may be helpful.  If you have Stoned, the first
  2875. byte will indicate the characteristic far jump of the virus (hex: EA)
  2876. instead of the more common short jump (hex: EB) of the boot loader.
  2877. Even if that is the first byte, you could be looking at a perfectly good
  2878. disk that has been "inoculated" against the virus *or* is infected with
  2879. some other virus which makes similar changes, or at a diskette that
  2880. seems safe but contains a totally different type of virus.
  2881.  
  2882.  
  2883. G3)  I was told that the Stoned virus displays the text "Your PC is now
  2884.      Stoned" at boot time.  I have been infected by this virus several
  2885.      times, but have never seen the message.  Why?
  2886.  
  2887. The "original" Stoned message was ".Your PC is now Stoned!", where the
  2888. "." represents the "bell" character (ASCII 7 or "PC speaker beep").  The
  2889. message is displayed with a probability of 1 in 8 *only* when a PC is
  2890. booted from an infected *diskette*.  When booting from an infected hard
  2891. disk, Stoned never displays this message.
  2892.  
  2893. Further, versions of Stoned with no message whatsoever or only the
  2894. leading bell character have become very common.  These versions of
  2895. Stoned are likely to go unnoticed by all but the most observant, even
  2896. when regularly booting from infected diskettes.
  2897.  
  2898. Contrary to some reports, the Stoned virus does *not* display the
  2899. message "LEGALISE MARIJUANA", although such a string is quite clearly
  2900. visible in the boot sectors of diskettes and MBR's of hard disks
  2901. infected with the "original" version of Stoned.
  2902.  
  2903.  
  2904. G4)  I was infected by both Stoned and Michelangelo.  Why has my
  2905.      computer become unbootable?  And why, each time I run my favorite
  2906.      scanner, does it find one of the viruses and say that it is
  2907.      removed, but when I run it again, it says that the virus is still
  2908.      there?
  2909.  
  2910. These two viruses store the original Master Boot Record at one and the
  2911. same place on the hard disk.  They do not recognize each other, and
  2912. therefore a computer can become infected with both of them at the same
  2913. time.
  2914.  
  2915. The first of these viruses that infects the computer will overwrite the
  2916. Master Boot Record with its body and store the original MBR at a certain
  2917. place on the disk.  So far, this is normal for a boot-record virus.  But
  2918. if now the other virus infects the computer too, it will replace the MBR
  2919. (which now contains the virus that has come first) with its own body,
  2920. and store what it believes is the original MBR (but in fact is the body
  2921. of the first virus) *at the same place* on the hard disk, thus
  2922. *overwriting* the original MBR.  When this happens, the contents of the
  2923. original MBR are lost.  Therefore the disk becomes non-bootable.
  2924.  
  2925. When a virus removal program inspects such a hard disk, it will see the
  2926. *second* virus in the MBR and will try to remove it by overwriting it
  2927. with the contents of the sector where this virus normally stores the
  2928. original MBR.  However, now this sector contains the body of the *first*
  2929. virus.  Therefore, the virus removal program will install the first
  2930. virus in trying to remove the second.  In all probability it will not
  2931. wipe out the sector where the (infected) MBR has been stored.
  2932.  
  2933. When the program is run again, it will find the *first* virus in the
  2934. MBR.  By trying to remove it, the program will get the contents of the
  2935. sector where this virus normally stores the original MBR, and will move
  2936. it over the current (infected) MBR.  Unfortunately, this sector still
  2937. contains the body of the *first* virus.  Therefore, the body of this
  2938. virus will be re-installed over the MBR ad infinitum.
  2939.  
  2940. There is no easy solution to this problem, since the contents of the
  2941. original MBR are lost.  The only solution for the antivirus program is
  2942. to detect that there is a problem, and to overwrite the contents of the
  2943. MBR with a valid MBR program, which the antivirus program has to provide
  2944. itself.  If your favorite antivirus program is not that smart, consider
  2945. replacing it with a better one, or try using the boot sector
  2946. disinfection procedure described elsewhere (see C3).
  2947.  
  2948. In general, infection of the same file or area by multiple viruses is
  2949. possible and vital areas of the original may be lost.  This can make it
  2950. difficult or impossible for virus disinfection tools to be effective,
  2951. and replacement of the lost file/area will be necessary.
  2952.  
  2953.  
  2954. G5)  My scanner finds the Filler and/or Israeli Boot virus in memory,
  2955.      but after I boot from a clean floppy it reports no viruses.  Am I
  2956.      infected?
  2957.  
  2958. This is almost certainly a "false positive" (see C5).  One particular,
  2959. popular antivirus product (usually its TSR scanner/monitor VSAFE) leaves
  2960. its scan strings in memory in an unencoded form, and is well-known for
  2961. causing false positives on Filler and Israeli Boot.  Your other scanner
  2962. sees the first's scan strings (at least those for Filler and/or Israeli
  2963. Boot) and reports a virus in memory.  When you boot from a floppy you
  2964. (probably) are not loading the resident scanner, so it doesn't have a
  2965. chance to "booby-trap" your other scanner.  To fix this problem, try
  2966. adding "REM " to the beginning of the line in your AUTOEXEC.BAT or
  2967. CONFIG.SYS file that loads the suspect TSR, and see if the problem
  2968. disappears.
  2969.  
  2970.  
  2971. G6)  I was infected with Flip and now a large part of my hard disk
  2972.      seems to have disappeared.  What has happened?
  2973.  
  2974. Flip has a logic error, probably based on its author only knowing about
  2975. hard disk partitioning schemes under DOS 3.x (where partitions could not
  2976. exceed 32MB in size).
  2977.  
  2978. Part of Flip's infection routine decrements by six the "total number of
  2979. sectors" field in the BIOS Parameter Block (BPB--a table of critical
  2980. disk geometry data) in the DOS boot sector of the boot partition.  For
  2981. partitions of 32MB and under this field is meaningful, but in larger
  2982. partitions, this field is set to zero and a field in the "extended BPB"
  2983. contains the "big number of sectors" for that partition instead.  Not
  2984. knowing about larger partitions, Flip renders the large partitions it
  2985. meets a shade under 32MB.  The fix for this is to use a disk sector
  2986. editor to set the word at offset 13h of the affected DOS boot sector to
  2987. "00 00" (they should be set to "FA FF" if the situation above applies).
  2988. If you don't understand these instructions, do *not* attempt to follow
  2989. them and seek the help of a more technically knowledgeable person.
  2990.  
  2991.  
  2992. G7)  What does the GenB and/or the GenP virus do?
  2993.  
  2994. There is no such thing as *the* GenB or GenP virus.  It is a heuristic
  2995. used by a very popular scanner to detect boot sector viruses and means
  2996. "There is something very suspicious in the boot sector (GenB) or in the
  2997. MBR (GenP), and I am pretty sure that it is a virus, however, I have no
  2998. idea which particular virus it might be".  You should run a scanner
  2999. which has better recognition and identification capabilities (see B15),
  3000. if you want to know which particular virus you have.  One advantage of
  3001. the GenB/GenP report is that you can often use the disinfection utility
  3002. from the same producer to remove the virus, even if no other scanner can
  3003. remove it.  When told to remove the GenB/GenP "virus", the utility scans
  3004. the disk for something that looks like a saved copy of the original boot
  3005. sector or MBR and will put it back in place, thus removing the virus, or
  3006. it writes a good generic MBR if there is an apparently valid partition
  3007. table in the virus MBR.
  3008.  
  3009.  
  3010. G8)  How do I "boot from a clean floppy"?
  3011.  
  3012. "Put it in the A: drive and turn the power on."
  3013.  
  3014. The facetious answer aside, the real question here is usually more one
  3015. of "How do I ensure I have a clean boot floppy?"
  3016.  
  3017. As with so many issues concerning viruses, the important thing is to be
  3018. prepared *in advance*.  As with backups, a current, clean boot disk
  3019. should be a standard part of every personal computer system, as there
  3020. are other occasions than when facing a real or suspected virus infection
  3021. where being able to boot your computer to a "known good" state are
  3022. useful or desirable (e.g. you accidentally delete your disk-compression
  3023. driver from your hard disk).  As with backups, a current, clean boot
  3024. disk is one of the standard parts of a personal computer system most
  3025. commonly missing.
  3026.  
  3027. The important thing in preparing a clean boot diskette, especially where
  3028. it has to be used with a (suspected) virus infection, is that it must
  3029. *not* run a single byte of code from your hard disk.  This means your
  3030. boot floppy must contain all the basic operating system files, device
  3031. drivers and configuration commands necessary to make your system
  3032. minimally usable.  This diskette must be prepared on a system that is,
  3033. itself, guaranteed "clean" and it should be write-protected immediately
  3034. after it is completed.  Aside from a basic, minimal operating system,
  3035. your emergency boot diskette should contain the utilities necessary to
  3036. install your OS to a hard disk *and* basic diagnostic or "fix it"
  3037. programs and your favorite antivirus tools.  Depending upon disk space
  3038. considerations, you may need additional diskettes to hold all these
  3039. utilities.  For example, if you use DOS it is a good idea to copy the
  3040. following utility programs to your emergency boot disk (if your version
  3041. of DOS includes them): FDISK, CHKDSK and/or SCANDISK, FORMAT, SYS, MEM,
  3042. UNFORMAT, UNDELETE, MSD.
  3043.  
  3044. When it comes to rebooting your computer from a clean system disk, it is
  3045. most important that you perform a "cold start".  On a PC, this means
  3046. pressing the reset button or turning the power off on again, *not* by
  3047. pressing Ctrl-Alt-Del.  Regardless of the machine type, if you are
  3048. unsure, use the power off then power on method just described.  It is
  3049. even more important that your machine is correctly configured to try
  3050. booting from the floppy first.  Most contemporary BIOSes have an option
  3051. to select the boot order (A: then C: or C: then A:)--this must be set to
  3052. A: then C: for this procedure, though normally we strongly recommend
  3053. that you set this option to C: then A:.
  3054.  
  3055. As systems change from time to time, you may occasionally need to update
  3056. this most critical of diskettes so it will still boot your system to a
  3057. usable state.  As you may have recently contracted a new virus that
  3058. bypasses your current antivirus precautions, this update process can put
  3059. you at risk of infecting your "clean" emergency boot diskette.  Because
  3060. of this, it is prudent to have two such diskettes.  With system changes
  3061. you would update these in a "leap frog" manner.  This means your
  3062. previous emergency boot diskette might still bring your machine up to a
  3063. minimally useful state (such that you may still be able to make repairs)
  3064. should your updated emergency boot diskette be infected by a previously
  3065. unknown virus.
  3066.  
  3067. Unfortunately, this isn't the whole story either!  A PC virus known as
  3068. EXE_Bug can fake out the boot process by setting the PC's CMOS to look
  3069. as if there are no floppy drives in the machine.  Most BIOS'es don't
  3070. even try to boot from a floppy in this case, and go straight to the hard
  3071. disk, loading the virus from the MBR.  When EXE_Bug first loads into
  3072. memory, it checks to see if there is a diskette in the first floppy
  3073. drive, and if there is, it loads the boot sector from the diskette and
  3074. lets the floppy boot as normal.  Most people don't notice the subtly
  3075. different boot time and drive access order involved in this, so they
  3076. think they have booted clean, when in fact the virus is active in
  3077. memory!  To circumvent this possibility, you have to check the PC's CMOS
  3078. settings before letting the floppy boot proceed, make sure that your PC
  3079. "knows" it has a floppy drive, *and*, with some PCs, make sure that the
  3080. boot order option is set to "A: then C:".  This presents a chicken-and-
  3081. egg situation on some machines, as you may have to boot DOS on the
  3082. machine to be able to run the utility program that lets you change its
  3083. CMOS settings.
  3084.  
  3085. Remember, if you changed your BIOS's boot order option, set it back to
  3086. C: then A: after disinfecting your PC.
  3087.  
  3088.  
  3089. G9)  My PC diagnostic utility lists "Cascade" amongst the hardware
  3090.       interrupts (IRQs).  Does this mean I have the Cascade virus?
  3091.  
  3092. No!  This is quite normal on AT-style (286 and better) PCs (and on a few
  3093. 8086 (XT) class machines).  The original IBM PC design had one
  3094. Programmable Interrupt Controller (PIC) to handle hardware interrupts
  3095. generated when devices like disk controllers, serial and parallel ports,
  3096. LAN adaptors, etc have to be serviced.  While developing the AT, IBM
  3097. decided that the eight Interrupt ReQuest (IRQ) lines the original PIC
  3098. supported were probably insufficient for likely future expansion needs,
  3099. so they added a second PIC.  The two PIC's had to cooperate, so both
  3100. didn't interrupt the CPU concurrently.  This was achieved by having the
  3101. second PIC use an IRQ to signal the first PIC when it has an IRQ to
  3102. service.  IRQs 2 and 9 were used for this and are commonly called the
  3103. "cascade" IRQ, as they allow the second PIC to cascade an IRQ down to
  3104. the first PIC.
  3105.  
  3106.  
  3107. G10) Occasionally the text "welcome datacomp" appears in my Mac
  3108.      documents without me typing it.  Is this a virus?
  3109.  
  3110. Most likely not.  This phenomenon has been reported for a particular
  3111. make/model of third-party Macintosh-compatible keyboard.  It appears to
  3112. be a practical joke, coded into the keyboard's ROM, that causes the
  3113. keyboard to output that text (as if it was typed) after a period of
  3114. keyboard inactivity.  The only practical fix is to replace the keyboard.
  3115. This is, in effect, a hardware (technically "firmware") Trojan Horse--
  3116. the keyboard has features or functions that are not advertised and that
  3117. will be performed without the owner's or user's wish or permission.
  3118.  
  3119.  
  3120. G11) How good are the antivirus tools included with MS-DOS 6?
  3121.  
  3122. While this FAQ sheet avoids answering specific questions about
  3123. particular antivirus software (partly because the ground tends to move
  3124. very quickly!), the antivirus tools included with MS-DOS 6 are very
  3125. widely distributed and accessible.  We will not give a wide-ranging
  3126. answer here, but will point out that Microsoft Corporation does not use
  3127. MSAV but a competitor's product.  We suggest that anyone considering
  3128. using the antivirus tools supplied with MS-DOS 6 as a significant part
  3129. of their virus defense should read the review available by anonymous FTP
  3130. from (amongst others) ftp.informatik.uni-hamburg.de (IP = 134.100.4.42)
  3131. as /pub/virus/texts/viruses/msaveval.zip.
  3132.  
  3133.  
  3134. G12) When I do a "DIR | MORE", I see two files with random names that
  3135.      are not there when I just use "DIR".  On my friends's system they
  3136.      cannot be seen.  Do I have a virus?
  3137.  
  3138. No.  DOS's default commandline interpreter (COMMAND.COM) creates two
  3139. temporary files with unique names for every pipe character ("|") used on
  3140. the command line.  Starting with DOS version 5.0, these files are
  3141. created in the directory pointed to by the TEMP environment variable,
  3142. not in the current directory as they were in earlier DOS versions.  If
  3143. your TEMP setting is invalid or you have an earlier version of DOS you
  3144. will see these files in the current directory when you pipe the output
  3145. of a DIR command through MORE (or any other filter). If you don't see
  3146. these files in the current directory's listing, performing the command
  3147. "DIR | MORE" on the directory specified by the TEMP variable will reveal
  3148. them.
  3149.  
  3150. Generally, you would be better to use "DIR /P" instead of "DIR | MORE",
  3151. as this avoids the creation of the temporary files.  If you use an
  3152. alternative commandline interpreter, none of the above may apply.
  3153.  
  3154.  
  3155. G13) What is the ChipAway virus?  (Or ChipAwayVirus?)
  3156.  
  3157. The ChipAway virus is not a virus at all.  In fact, it is a poorly
  3158. chosen name for a good idea.  Many PCs have an advanced BIOS feature
  3159. that, when activated, prevents any writes to the MBR through BIOS disk
  3160. routines.  If active, this feature can cause problems if you install non-
  3161. DOS operating systems (like OS/2, Windows 95 or Windows NT), as their
  3162. installation routines typically need to write to the MBR, but for
  3163. general purpose computers, it is a good idea to turn on these options,
  3164. if they exist.
  3165.  
  3166. Unfortunately, one of the earliest and most widely available
  3167. implementations of this idea prints a message on screen at each system
  3168. startup to the effect "ChipAwayVirus installed".  This is supposed to
  3169. calm the owner's nerves, making them confident that their BIOS antivirus
  3170. system is working for them.  For fairly obvious reasons, it tends to
  3171. have the opposite effect!
  3172.  
  3173. [End of Virus-L/comp.virus FAQ sheet]
  3174.  
  3175.  
  3176. -----BEGIN PGP SIGNATURE-----
  3177. Version: 2.6.i
  3178.  
  3179. iQCVAgUBMHhJLo2yC8NpBpE5AQHa7gQA1Ye63ZVHxrk5rqMuTfj0468b+8tmdsfi
  3180. UpAdPblOPR44TwTFi6vU9BUYxGBjwoegO4yqufTpxEHlJDeaGBG3T3ACllROmr/4
  3181. 1RqHm0oYh4APKgwZIM7vuWAevU3QFcM1cxY702w/5YD/AMnSXj5rIHfMHBtbYNo9
  3182. PFNR0XgrQ6o=
  3183. =q4G1
  3184. -----END PGP SIGNATURE-----
  3185.