	     The Scanner - The Anti-Virus Newsletter of Today
		  
			 Volume 3  Issue 1
	    ==============================================

    The Scanner is a newsletter compiled by Howard Wood with the
help of many people in the Anti-Virus community as well as users.
Those who contribute to The Scanner are primarily concerned with
'getting the word out' about the virus situation, and encourage
the free dissemination of this information.  Therefore, please
feel free to repost complete, unedited copies of The Scanner
wherever you feel there may be interest in the topic, or need for
the knowledge.  You are also encouraged to contact the authors
regarding an individual article'sCopyright.

    The Scanner is in no way liable for the accuracy of any or
all information it is passing along.  While accuracy and facts
are the paramount goal of The Scanner, it is humanly impossible
to verify all information and guarantee its accuracy 100%.

    The goal of The Scanner is to disseminate as much information
to as wide spread a group as possible. Researchers, developers
and users alike need various levels of information to deal with
the viruses, Trojans and hacks that are encountered daily.  The
Scanner will *attempt* to pass along viable information for all
groups.
      
    Most of all, The Scanner is *your* newsletter.  If you have
encountered any viruses, Trojans, or hacked programs let us know.
We need to all work together to combat the problems out there.
Since the last issue there have been some address changes.  Any
correspondence with either The Scanner staff or Howard Wood can
be sent to the following addresses:

	 The Scanner     SCNR@aol.com
	 Howard Wood     Woody@diversicomm.com   


  DISCLAIMER: The views represented herein do not necessarily
	   represent the views of the staff. Scanner
	   contributors assume all responsibility for
	   ensuring that articles submitted do not 
	   violate copyright protections.

----------------------------------------------------------------------
			   Contents
			       
			       
In This Issue ................................. Howard Wood

Antiviral Software Evaluation FAQ ............. Rob Slade

In The News           ......................... Howard Wood

The BookShelf         ......................... Rob Slade

			   Reviewing
Netscape Navigator ............................ Brian Pfaffenberger 
Web Publishing ................................ Asha Dornfest    

Whats NOT a Virus ............................ Chengi Jimmy Kuo

Hacks, Viruses and Trojans .................... Howard Wood

Virus Spotlight   ............................. Howard Wood
	     This months bug Stoned.Empire.Monkey
    About Stoned.Empire.Monkey  ............... Mikko Hypponen
						Wolfgang Stiller

    Killmonk3      ............................. Tim Martin

Bill's Desk  ................................... Bill Lambdin

	    This month: A review of Invirsible      

From Woody's Desk ............................. Howard Wood




==========================================================

		     In This Issue

     Well, its been a while since we last met. A lot of 
things have happened in the last fourteen months.  Macro
viruses, over 100 percent increase in the bugs at large and
over a 100 percent increase in the daily release rate.  Not
good statistics.

     The 'come' back issue is full of some great info
especially for you new folks. In the future issues we will be 
looking at the infamous Macro Viruses, some ofthe more elberate
viruses that are causing a lot of problems out there.

     Rob Slade and Chengi Jimmy Kuo were very generous in allowing
The Scanner to print their most recent papers.  Rob's paper,
Antiviral Sotware Evlauation FAQ, is an informative paper on
AV software that has something for everybody. Chengi Jimmy Kuo's
paper, What is NOT AVirus, is a paper anybody using WIN95 will
want to read.

   The Scanner now has a Home Page thanks to the folks at
Micro Source of Gulfport, Mississippi.  Stop in and see us at

		http://diversicomm.com/scanner.

     All 'constructive' comments are welcomed and appreciated
and can be sent to me direct or by leaving you comments and
suggestions on the Page.

     Enjoy the issue.                    
     
			    Woody

		     Woody@diversicomm.com

====================================================================


		      Antiviral Software Review FAQ  
			

AVREVIEW.FAQ   960624
 
Antiviral Software Evaluation FAQ
maintained by Robert M. Slade
 
(beta release)
 
    This list of questions is intended to provide a framework and
background information for review, evaluation and decisions
regarding antiviral protection software and systems.  The
companion files "Antiviral contacts listing" (CONTACTS.LST) and
"Quick reference antiviral review chart" (QUICKREF.RVW) provide
additional related information.  All three files are available in
the Computer Virus SIG of the Victoria (BC, Canada) Freenet
(telnet://guest@freenet.victoria.bc.ca and give the command "go
virus").  (This file is prepared from Chapter Six of "Robert
Slade's Guide to Computer Viruses".)
 
    This document is *not* intended to be an introduction to the
study of computer viral programs.  It is expected that you
already know the relevant concepts and terminology.  For general
background information on computer viruses, please see the
VIRUS-L/comp.virus FAQ
(ftp://cs.ucr.edu/pub/virus-l/vlfaq200.txt) which is also
available at the Victoria Freenet site.
 
Contents
 
1)  Why can't I get 100% protection?
2)  Why isn't there any one "best" antiviral?
3)  What is an activity monitor?
3a)  What are the strengths of activity monitors?
3b)  What are the weaknesses of activity monitors?
3c)  How should activity monitors be evaluated?
4)  What is authentication/change-detection software?
4a)  What are the strengths of change-detection software?
4b)  What are the weaknesses of change-detection software?
4c)  How should change-detection software be evaluated?
5)  What is a scanner?
5a)  What are the strengths of scanners?
5b)  What are the weaknesses of scanners?
5c)  How should scanners be evaluated?
6)  What is resident software?
7)  What is heuristic scanning?
8)  What is a false negative?
9)  What is a false positive?
10) How does disinfection work?
10a) What is "generic" disinfection?
10b) What is "heuristic generic" disinfection?
11) Can I get hardware antiviral protection?
12) Why can a "so-so" antiviral actually be harmful?
13) What aspects of an antiviral are important?
14) What aspects of an antiviral are *not* important?
15) What about "number of viruses detected"?
16) Why isn't disinfection very important?
17) Why should I support "free" software?
18) What about published reviews?
19) Where can I find published reviews?
 
 
Questions and answers
 
1)  Why can't I get 100% protection?
 
    An easy answer can be seen by noting that computer viruses
are programs, and they only do things that "real" programs do.
There is no magic secret that viral programs use.  Therefore,
there is no single distinctive or characteristic that can be used
to identify a viral program.
 
    A more rigorous explanation is found in Fred Cohen's ground
breaking work on the theoretical study of computer viruses
between 1983 and 1986.  Using mathematical and logical models of
the nature of computers and computation he determined that the
problem of accurately identifying a viral program, as opposed to
one which is not viral, is "undecidable".  A program to identify
computer viruses will always have the possibility of making
errors either in failing to identify viral programs (false
negative), or in falsely accusing a valid program of being viral
(false positive), or both.
 
    However, if you do your homework, you can get very solid
protection.
 
 
2)  Why isn't there any one "best" antiviral?
 
    This desire for one single "best" antiviral ignores three
vitally important points.  The first is that, as pointed out
above, "the best" may not be good enough by itself.
 
    The second point is that, even within the limited realm of
anti-viral programs, data security software operates in many
different ways.  Thus, one type of security may be better in one
situation, while another variety may be better in a different
environment.  There are basically three "classes" of anti-viral
packages:  activity monitors, authentication or change-detection
software, and scanners.  Each type has its own strengths and
weaknesses.  (Note that most commercial antiviral programs have a
combination of functions.)
 
    The final point is that security, of every type, is always a
"moving target," and the virus world moves faster than most.  Not
only are new viral programs being written every day, but new
types of viral functions are being coded all the time (albeit at
a much slower rate than the run-of- the-mill copycat virals).
Any antiviral program developer who purports to "guarantee"
protection against "all known and unknown" viral programs simply
does not comprehend the reality of the situation.
 
 
3)  What is an activity monitor?
 
    Activity monitoring software, as the name implies, oversees
the operation of the computer and alerts the user when suspicious
activity takes place.  It may, for example, check for any calls
to format a disk or attempts to alter or delete a program file
while a program other than the operating system is in control.
It may be more sophisticated, and check for any program that
performs "direct" activities with hardware, without using the
standard system calls. Although the analogy should not be
stretched too far, activity monitors do share some
characteristics, though not functions, of medical vaccines, being
memory-resident and preventive in nature.
 
    A minor variation on activity-monitoring software is
operation-restricting software.  Instead of watching for
suspicious activities, it automatically prevents them.  The
difference between a "monitor" and a "restrictor" is really only
one of degree in the information given to the user.  Most general
microcomputer security programs use operation restriction.
 
    Heuristic scanning, despite the name, has much in common with
activity- monitoring.  A heuristic scanner looks not for
signatures of a specific virus, but for code which performs
suspect activities.
 
3a)  What are the strengths of activity monitors?
 
    Activity monitors can detect "unknown" (that is, not
previously identified) viral programs, and do not require a
database of signatures of known viruses. Activity monitors
generally require less frequent updates than do scanners.
Activity monitors do not require the same level of setup as do
authentication or change detection systems.  Activity monitors
may be able to function on already infected systems.
 
    Activity monitors represent some of the oldest examples of
antiviral software. Generally speaking, such programs followed in
the footsteps of the earlier anti-trojan software, such as
BOMBSQAD and WORMCHEK in the MS-DOS  arena, which used the same
"check what the program tries to do" approach.  This tactic can
be startling effective, particularly given the fact that so much
malware is slavishly derivative and tends to use the same
functions over and over again.
 
3b)  What are the weaknesses of activity monitors?
 
    It is very hard to tell the difference between a word
processor updating a file and a virus infecting a file.
Activity-monitoring programs may be more trouble than they are
worth because they can continually ask for confirmation of valid
activities.  If you restrict the operations that a computer can
perform, you can eliminate viral programs.  Unfortunately, you
also can eliminate most of the usefulness of the computer.
 
    Activity monitors may also be bypassed by viral programs that
do low-level programming rather than using the standard operating
system calls, or those that actually replace the standard system
calls with viral triggers.  In addition, while new viral
technologies, such as stealth and polymorphism, have little
effect on activity monitoring, new concepts in viral spread, such
as companion or spawning viruses require new checks to be added
to monitors.
 
    Activity monitors have a good chance to detect viral activity
of new and unknown viral strains, but it would be very difficult
to agree with those that claim to be able to detect "all current
and future" viral programs.  Unfortunately, activity monitors
tend to encourage a set-and-forget mentality toward viral
protection.  This attitude should be avoided at all costs.  If
activity-monitoring software is your protection method of choice,
continue to keep up-to-date with viral methods and to test your
software regularly.
 
    As with mainframe security "permission" systems,
operation-restricting packages allow you to restrict the
activities that programs can perform, sometimes on a file-by-file
basis.  However, the more options these programs allow, the more
time they will take to set up.  The program must be modified each
time you make a valid change to the system, and, as with activity
monitors, some viral programs may be able to evade the protection
by using low-level programming.
 
    Activity monitors do not provide disinfection functions.  (A
possible exception is "heuristic generic" disinfection.)
 
3c)  How should activity monitors be evaluated?
 
    It is important, when evaluating both activity-monitoring and
operation- restricting software, to judge the extent to which the
operator is given the option of "allowing" an operation.  It is
also important, that the operator be informed, not only that a
particular program or operation should be halted, but also why.
There should not be too many false alarms generated by the
software, and it would be helpful to have the option of "tuning"
the software to be less, or more, sensitive to a given type of
activity.
 
    It is very difficult to specify in advance what you should
check for in activity-monitoring software, since the developers
are loath to state, in detail, exactly what the program will be
checking for.  (This reluctance is understandable:  if a
developer "advertises" exactly what the product checks for, virus
or trojan writers will simply use another route.)  In addition,
the work or computing environment must be considered, as well as,
in certain cases, the corporate climate.  Activity monitors, more
than scanners or change detectors, are subject to review on the
basis of political rather than technical grounds.
 
    Activity-monitoring software should be thoroughly tested in a
real working environment (one that uses all the programs you
normally use, in the ways you normally use them) for some time in
order to ensure that the vaccine does not conflict with normal
operation.  This "real" environment includes the "real" people
who will be using the software:  choose your sample population
carefully and avoid simply giving it to the tech support office
to test.  Two important factors to check for are the number of
false positives (or false alarms) that the software generates and
the level of information given to the user when an anomalous
condition is detected.  This last is difficult to judge:  user
populations that tend to remain at the novice level will not have
more confidence in the system, regardless of how much information
it gives them.
 
    Monitoring programs should be tested against a battery of
viral programs, but the test suite should be collected on the
basis of function rather than simply diversity.  If the activity
monitor is effective against Stoned, then Empire, Michelangelo,
and Monkey variants are unlikely to trouble it.
 
 
4)  What is authentication/change-detection software?
 
    Change-detection software determines whether the program,
file, or system has changed as compared against a previously
established database.  It examines system and/or program files
and configuration, stores the information, and compares it
against the actual configuration at a later time.  Most of these
programs perform a checksum or cyclic redundancy check (CRC) that
will detect changes to a file even if the length is unchanged.
Some programs will even use sophisticated encryption techniques
to generate an authentication signature that is, if not
absolutely immune to malicious attack, prohibitively expensive,
in processing terms, from the point of view of a virus.  If a
sufficiently broad overview of the system is taken, this will
provide 100 percent effective detection of a viral infection, but
it also may raise a number of false alarms.
 
    Change-detection software is also often referred to as
integrity-checking software.  It does check the integrity of the
program in terms of alterations, but shouldn't imply that the
program will be functional or useful.  Authentication properly
refers to strong encryption systems which both guarantee that a
program is unaltered and identify its source.  Change detection
can be seen as a weaker version of authentication.
 
4a)  What are the strengths of change-detection software?
 
    A sufficiently advanced change-detection system, which takes
all factors including system areas of the disk and the computer
memory into account, has the best chance of detecting all current
and future viral strains.  Even with the most esoteric stealth
technology, a virus must change *something* in the system.
Therefore, adequately broadly based change detection is the best
bet for absolute detection of all viral programs--if you can put
up with the false alarms.
 
4b)  What are the weaknesses of change-detection software?
 
    Change detection has the highest probability of false alarms,
since it will not know whether a change is viral or valid.
(Additional thought put into the installation of change-detection
software will go a long way to reducing the level of
false-positive results.  As always with security systems, there
is a trade-off between the easy and the effective.)  The addition
of intelligent analysis of the changes detected may assist with
this failing.
 
    Change-detection software provides no protection, but only
after-the-fact notification of an infection.  It is, therefore,
quite possible to install an infected program on your system and
have it continue to infect other programs.  The subsequent
infections will (or should) be detected, but the change-
detection software will not identify the original culprit.
(Deductive reasoning, along with the software's assistance,
though, may.)
 
    You must inform the software of any changes *you* make in the
system, otherwise the change detection software will generate a
false alarm.  This means you must have sufficient knowledge of
the system to know *when* you are making changes. Each invocation
of SETVER, for example, changes the program file, whereas setup
changes made to WordPerfect sometimes alter the program file
and/or change an external data file.
 
    As with scanning software, change-detection software may not
see changes made, and hidden, by stealth viral programs.
 
4c)  How should change-detection software be evaluated?
 
    There are numerous implementations of change-detection
software.  Some versions of this software run only at boot time;
others check each program as it is run. Some of these programs
attach a small piece of code to the programs they are protecting,
and this may cause programs which have their own change-detection
features, or nonstandard internal structures, to fail.  Some
programs only protect system software; others only protect
program files.  Some change detectors keep the signature file in
the root directory; some in the "local" directories.  Some allow
you the option of keeping the file on a diskette offline and out
of the reach of viral programs that might try to damage it.
 
    A major factor in judging change-detection systems is
installation and operation time.  Since the system will be
calculating signatures of all (or all selected) programs on your
system (sometimes with very sophisticated algorithms), it may
take some time to install, and to update each time you make a
change to your system.  It may also take an unacceptable amount
of time to boot or to check out a program before allowing
software to run.  You may find that a change-detection system
with a "weaker" calculation algorithm is more effective for your
situation given the time savings.
 
  The answers to these questions should actually be available to
you in the documentation.  You shouldn't need to run the program
to test it out.  Unlike activity-monitoring software, there is no
need for the producer of change detection-software to hide
anything from either you or virus writers.  A truly complete
change-detection package is unbeatable (dependent, of course, on
a "clean start") and does not require any hidden "tricks."  A
package with documentation that does *not* answer all of your
questions suggests lack of confidence on the part of the author,
and possible weakness in the program.
 
    Note that the above is presuming that you are protecting a
single computer or a local office.  Change detection has other
uses, including authentication of material sent via email or
retrieved from an archive site.  The calculation algorithms used
in those situations must be much stronger.  Delays of mere
seconds caused by trying to "crack" protection will be detectable
locally: it would be no problem to spend weeks or months cracking
the security of an archived file.
 
 
5)  What is a scanner?
 
    Scanning programs, or scanners, look for viral signatures,
sections of program code that are known to be in specific viral
programs but not in most other programs.  The developer of a
scanner will build a database of such viral signatures, along
with a search program which can examine files, disk areas or
memory.
 
5a)  What are the strengths of scanners?
 
    Scanners, particularly signature scanners, are currently the
most popular of antiviral software.  This is likely due to three
factors:  the fact that viral programs are specifically
identified; the inclusion of disinfecting software with most
scanners; and the fact that it's easy to play numbers games with
signature-scanning programs.
 
  Scanners can only find infections after they occur, but that
does not mean that scanners cannot play a preventative role in
protecting the system.  If scanning software is used consistently
to check each disk or file that enters a system (and kept up to
date), the chance of a viral infection being allowed to enter is
greatly reduced.
 
5b)  What are the weaknesses of scanners?
 
  Scanners look for known viral signatures.  Because of this,
scanning software will generally detect only known viruses and
must be updated regularly.  Some scanners will alert users to
programs which are "close" to a given signature.  (The MS-DOS
scanner F-PROT uses at least two signatures to identify a given
virus and has always been particularly good at identifying "new"
variants.)
 
5c)  How should scanners be evaluated?
 
  Scanning software should be able to identify the largest
possible number of viral programs, and should be able to identify
variations on the more important sections of code (that is, it
should be able to "accept" the removal of text strings and other
simple modifications that bush-league hackers might make.) Note,
however, the proviso that it is more important to identify some
viral programs than others.  For ease and speed of updating, the
signatures should be stored in a separate file, and there should
be a means to add new viral signatures to the file.  For
security, both scanning software programs and signature files
should be renameable.
 
  Areas scanned should include not only the identifiable program
files, but all files, if necessary.  (This has become much more
important recently with the advent of successful Windows viral
programs coincident with the Windows "embedding" function, and
also "macro" viruses.)  Scanners should have the ability to
search the more common archiving formats as well, particularly
those that support self-extraction functions.  Disk boot sector
and hard-disk partition boot records should be scanned, as well
as (in this day of stealth viruses) memory.
 
  Identification and naming of viruses can be important when you
want to ask for help or use one of the various computer virus
references.  A scanner should use the CARO naming conventions as
far as possible.
 
  Speed of operation is a consideration when running scans
manually or at boot time every day.  However, while speed can
vary greatly, this is less of a concern with modern higher speed
computers.  Even relatively slow scanners may take less than a
minute to complete a full scan.
 
 
6)  What is resident software?
 
  Resident software, once started, operates in the background of
the computer.  Most of the time it does not interact with the
user.  Most "successful" viral programs run resident, but
antiviral software can also run this way.  Resident programs are
usually started from the AUTOEXEC.BAT or CONFIG.SYS files in
MS-DOS , or are INITs or CDEVs in the System Folder on Macs.
Resident software provides an additional layer of protection that
you won't forget to use, but it should not be set up and then
forgotten.  You are always responsible for your own protection.
 
  The term resident refers only to this background mode of
operation.  All three types of antiviral software may be run in
this fashion.  Classic activity monitors always run resident,
since they must always be operating while other programs are, in
order to check on different activities.  Change detection
software may be run resident so that it can check programs being
started against the initial data base.  Scanners may be run
resident in order to quickly check each program for virus
signatures as the software is started.  Resident antivirals may
combine two, or all three, types of antiviral checking.
 
 
7)  What is heuristic scanning?
 
  A recent addition to scanners is intelligent analysis of
unknown code, currently referred to as heuristic scanning.  More
closely akin to activity- monitoring functions than traditional
signature scanning, this looks for "suspicious" sections of code
that are generally found in viral or malicious programs.  While
it is possible for normal programs to want to "go resident," look
for other program files, or even modify their own code, such
activities are telltale signs that can help an informed user come
to some decision about the advisability of running or installing
a given new and unknown program.  Heuristics, however, may
generate a lot of false alarms, and may either scare novice
users, or give them a false sense of security after "wolf" has
been cried too often.
 
  This field is really the application of "expert systems" to
antiviral software: an "expert" antiviral disassembler is
checking the code for you.  Along with hoped-for advances in
change detection, this bodes well for the future of antiviral
software.  Indeed, not only will it identify suspect viral
programs, but, with only minor additions, trojans and other
malware as well.
 
  Heuristic scanners are currently tools best used by those with
some background in virus identification and prevention, but they
hold promise to become very useful tools, even for the novice,
with future development.
 
 
8)  What is a false negative?
 
  False negative is the term for when antiviral software fails to
alert you when a virus infection actually is present.  Many would
simply say that the software had failed, but it can also fail by
giving you a false positive.
 
 
9)  What is a false positive?
 
  False positive is the term for the failure of antiviral
software when it alerts you to a virus infection, but there is no
virus present.  This is also known as a false alarm.
 
 
10) How does disinfection work?
 
  The best way to disinfect a file is to erase it, and restore
from a clean backup.
 
  Failing that, disinfecting software will contain a description
of the specific viral operation of a given viral program, so that
the infection process can be reversed.  You have to know what a
virus changes, and how, in order to change the object back to the
way it was.  Scanner developers have to examine the virus code,
so they have an advantage in knowing how the virus works, and it
is scanners which usually have disinfection modules.
 
  In some cases the file or disk sector cannot be returned to its
original state by this method.  Viruses that overwrite sections
of code leave no means of recovering the original material.
 
10a) What is "generic" disinfection?
 
  Some change-detection programs store sufficient information
about the file to make an attempt to restore it if the damage is
not too severe or complicated.  In this case, how the file has
become damaged is not important: only that enough remains of the
file that it can be recreated to match the stored image.  In
fact, checksum disinfection can be tried for files damaged by
means other than viral infection.  This type of software uses
checksum, CRC, hamming, or image calculations that *must* be done
while the software is clean, since this software only tries to
return the disk, drive, or program files to an "original" state.
If you know that you have a virus infection, don't bother
purchasing a "checksum" disinfector.  So far, checksum
disinfectors have a lower success rate with disinfection than do
scanners.
 
10b) What is "heuristic generic" disinfection?
 
  Heuristic disinfection is the newest type of antiviral
technology.  Using methods similar to those of heuristic
scanning, the program attempts to analyze the object to see how
it was infected, and how it can be returned to its original
state.  Heuristic disinfectors have not had a very good success
rate.  Even worse, they sometimes harm "good" programs.
Heuristic disinfection should only be used as a "last ditch"
effort.
 
 
11) Can I get hardware antiviral protection?
 
  There are a variety of hardware devices that assist in
providing antiviral protection.  To date, none of them are able
to completely replace a well set up software system.
 
  There are a number of cards which act as write protection for
the hard disk.  It would be nice (as well as a lot cheaper) to
have a hard disk controller card with an external write protect
switch.  (Those who have removable media drives have an
advantage: the cartridges usually have write protect tabs or
toggles.)
 
  Some cards, or chips for LAN cards, provide extensions to the
ROM BIOS.  These extensions generally prevent booting from the
floppy drive, and usually do some checking of the memory and
interrupts.  Some of them may also call software antivirals at
boot time.
 
  There was an activity monitoring and operation restricting
system built on the Western Digital 7855 system controller chip.
A number of computer vendors announced plans to build computers
built around the system.  To date I have not seen any that were
actually produced.
 
 
12) Why can a "so-so" antiviral actually be harmful?
 
  Some people would suggest that half a loaf is better than none,
so a mediocre antiviral is better than none at all.
Unfortunately, because viruses usually operate outside of the
user's perception, having a poor antiviral engenders a false
sense of security.  Not only can the user be harmed by this--and
likely at the worst possible time--but the infected system will
be continuing to spread copies of the virus to other systems and
users.
 
  In addition, antiviral programs which have loopholes may
themselves become sources of antiviral spread.  Antiviral
programs are programs like any other, and must have special
protection built in to ensure that they don't become infected.
Antiviral scanners also must "open" the files they are checking.
Viruses often infect "on file open", and if such as virus is
active in memory and remains undetected when a scanner sweeps the
disk, it is possible that all files on the disk may become
infected.
 
  Finally, any weaknesses in a particular piece of antiviral
software tend to be subject to attack from the virus writing
community.  In the case of one particularly widely distributed
antiviral program, it was found that only a few bytes of machine
code would turn off the resident module.  This code quickly
became a standard feature of new viruses.
 
 
13) What aspects of an antiviral are important?
 
  The most important factor in judging an antiviral is accurate
and complete detection of all possible viruses.  Unfortunately,
since it is proven that this is impossible, we are left with
trying to determine which antiviral will detect, accurately, the
most viruses that the user is likely to encounter.  Complete and
accurate detection, though, is the number one priority.  It
should never be superceded by *any* other factor in a trade-off.
 
  Also of very high importance in testing antiviral systems is
the fact that the proportion of computer users who have a
thorough understanding of viral operations, in comparison to the
total user population, is so small that it is statistically
insignificant.  Therefore, it is vital that any antiviral program
be judged on the basis of installation and use by "naive" users.
A naive user in this case may be one with significant technical
skills, but little background in regard to viral programs.
 
  It is critical, therefore, to judge the interaction of the
program with the user.  Again, this interaction is not simply the
presence or absence of a menu or GUI (graphical user interface),
but the total communication between the program and the user, by
way of the documentation, installation, user interface, and
messages.  It is important to note how the total package "comes
to" the user.  Given that the user's system may already be
infected, what can the package do to remedy the situation?  Also,
while the package may have significant strengths if installed
correctly, is the "normal" user likely to be able to do the setup
and installation properly?
 
  Remember that for the seeming simplicity of some programs,
antiviral software is still a part of computer security.
Security is not now, has never been, and never will be obvious to
the majority of the population.
 
  Part of the assessment of the user is the user environment.
This aspect covers not only the "corporate culture" (for example,
is this computer being used in the home, a small business office,
by a user in a large corporation with internal support staff,
etc.), but also the operating system environment.  For example,
the MS-DOS environment has a very large number of viral strains,
with more being produced every day.  The Macintosh environment
has relatively few viral programs.  Therefore, generic
identification of new and unknown viral programs is more
important to MS-DOS users than to Macintosh.  (Interestingly,
while Macintosh antivirals are quite mature, and protected
Macintosh systems have a negligible infection rate, the infection
rate on unprotected Macs is astronomical.  This, too, should be
taken into account.)
 
  An antiviral program, therefore, must be matched to the
environment in which it is to be used.  In a "low risk, low
change" situation, such as a word- processing office,
change-detection software provides very effective protection,
without too much interference with operations.  In a "high
change" milieu, such as a software development team,
change-detection software is less useful against viral programs,
although it has other helpful features.  In a "high risk,
multirisk" environment such as a college computer lab, operation-
restricting software may prevent not only viral infection, but
may help to "idiot-proof" the computers as well.
 
  Related to the interaction of the user and the program is the
potential negative impact of the security program.  Antiviral
programs consume time and disk space, and may also interfere with
the normal operation of the computer system.  You can guarantee
security only if you don't buy a computer.  Computer systems can
be secured more and more by restricting the operations more and
more, but restriction of "dangerous" operations also restricts
useful ones.  There comes a point at which the trade-off for
greater security becomes more than users want to pay.
 
  However, strange as it may seem, antiviral and security
software may actually do as much damage as viruses themselves.
Some systems fail to prevent infections but prevent the user from
getting rid of the virus.  Some systems actually delete files
without informing the user.  Disinfection has been known to leave
the computer in a worse state than the infection did.  Perhaps,
then, this should be the ultimate decider: first, do no harm.
 
 
14) What aspects of an antiviral are *not* important?
 
  Some aspects of antivirals are consistently overrated on
published reviews.  One such factor is a GUI.  After all, say the
proponents, a program is only as good as its use.  A GUI, the
promoters will say, encourages use.  That is only true in
situations where the GUI aids in the interaction between the
program and the user.  In many cases the GUI does nothing to
assist the user to increase the level of security.  In fact, the
inclusion of a GUI may be responsible for certain problems in
design and documentation.  In that case, the user may be given a
false sense of security, thinking that the system is using a
variety of protection methods, when, in fact, the user may have
failed to invoke some of them because their use is not intuitive
or obvious.
 
  The LAN antiviral seems to be something of a growth market with
almost everyone bringing out an NLM version of their product.
NLM stands for NetWare Loadable Module, and will only work with
Novell NetWare.  Network management is always a problem,
particularly with antiviral software which requires constant
updating.  However, these advanced network systems really only
provide a simple set of functions.  Email is used by some of the
specialized LAN antivirals to alert the administrator to a
security breach or possible infection.  This can be duplicated on
almost any network.  The same can be said of "centralised"
logging of scanning and audit reports, updating of scanners,
enforcement of virus checking, and a number of other supposedly
advanced features.  One need not accept an inferior antiviral
product simply because it has LAN capabilities.  Because LAN
systems are more complex, it is also harder to determine the
effectiveness and accuracy of such antivirals.  A simple and
effective antiviral which is known to work well may be more
effective than a specialized LAN product, particularly when
enhanced by some simple scripted functions.  The same applies to
Web and Internet scanners.
 
  In a similar way, the new Windows 95/VxD products may not be as
effective as more mature DOS programs.  The new internal features
of Windows 95 make it a more complex environment, and therefore
make it much more diffcult to assess the total effectiveness of
security systems.
 
 
15) What about "number of viruses detected"?
 
  It is very easy to "rank" antiviral software on the basis of
how many viral programs or strains that it will identify.  It is
not quite as easy to assess many other, more important, features.
(Note, as well, that it is only easy to rank only scanning
software in this regard.  Activity monitors and change- detection
software have to be tested in completely different ways.)
 
  Although there may be more than 10,000 different strains of
viral programs in the MS-DOS world (fewer in the other
environments), it is likely that only 1 percent of that number is
responsible for 99 percent of infections.  Thus the choice of a
"test suite," sometimes called a "zoo," is made more difficult
than it might be otherwise.  Certain programs are very
significant in terms of danger of attack, and therefore must hold
higher ranking than others.
 
  The test suite should, however, contain a range of viral
programs that are functionally distinct.  A good test suite
should contain programs from different categories of viruses,
such as BSIs versus file infectors and MBR infectors versus BSIs.
Self-encrypting, polymorphic, stealth, tunneling, multipartite,
and companion viral programs should all be represented.  Kami's
Anti-Viral Toolkit Pro (AVP) gained a good reputation for itself
by accurate detection of polymorphic viruses at a time when other
antivirals were having some difficulty in that field.  On the
other hand, the otherwise excellent Disinfectant (for the
Macintosh) has never been able to detect HyperCard or Word Macro
viruses.
 
  If at all possible, some rare, or even unknown viral programs
should be included in the test suite.  The assertion by some
software producers that they can catch all "known and unknown"
viral programs should never be left unchallenged.  The only way
to get completely unknown viral programs is to make them up.
This is beyond the scope of most users, of course, and so it is
not a realistic suggestion in most cases.  In addition there is
the danger of letting another beast loose in an already
overcrowded environment.
 
  The analysis of virus type and function may even be beyond the
capabilities of some reviewers.  Many of the problems of
"numbers" reviews are much more basic than that.
 
  The test suites for most numeric reviews now generally contain
in excess of 1,000 items.  Even granting that this is only a
fraction of the known viruses, each of those items *should* have
gone through a screening process.  At a minimum, one should know
certain things about it, such as, is it actually a virus?  Does
it reproduce?  Under what conditions does it reproduce?  Is it
the same for each type of object it infects? Is it the same for
each succeeding copy?  When invoked, does it infect memory?  It
is unlikely that each of the 1,000 or more items has been tested
for all these criteria.
 
 
16) Why isn't disinfection very important?
 
  Disinfection is by no means the optimal way to deal with viral
infections.  The best solution is to delete (and, preferably,
overwrite) the affected file or area, and restore programs from
original sources.  BSIs affect a whole disk, and therefore
present greater problems, but in most cases material can be
recovered from infected disks, and the disks themselves
"cleansed" in various ways.  There comes a point at which the
trade-off between security and convenience tips the scales in
favour of disinfection, but be aware of the dangers.
 
  In many cases, disinfection is simply not possible.  An
overwriting virus, for example, will not keep any track of the
material it destroys when it dumps itself into a file.  Many
viruses contain bugs that prevent the recovery of the original
file.  Also, disinfection software has been known to contain bugs
that left the situation worse after the attempted cleanup than
after the infection.
 
 
17) Why should I support "free" software?
 
  Price is always a consideration when purchasing anything, and
antiviral software is no exception.  However, in the case of
antiviral software, there is an additional consideration:  how
much is charged to other people, not just yourself.  Some
antiviral software is free to individuals, or provides or
sponsors free versions for the general public.  These should be
supported.
 
  The current situation with regard to computer "hygiene" is
terrible.  Thousands of people are "carriers" of computer viral
infections--and don't know it.  This is not through any malice on
their part, it is simply that too few people understand the
problem.  During the months leading up to March 1992, no less
than 15 different companies, all reputable (some major), sent out
products infected with the Michelangelo virus.  Computer retail
and repair stores are, as of this writing, a major vector for the
spread of computer viral programs.  Anything, therefore, that
helps to eliminate any viral programs will help the "hygiene" of
the computer environment as a whole.  If a company, or
individual, provides materials that help keep the numbers of
viral infections down, then regardless of whether you or your
company actually use that service or product, that company, or
individual, is helping to keep you safe.  It is, therefore, in
your own interest to support all such services.
 
  The shareware version of F-PROT, in the MS-DOS world, is
currently free for individual, noncommercial use.  This means
that you can legitimately give it to all employees for their home
computers.  For the Macintosh, Disinfectant always has been free.
DISKSECURE and FixUTIL are both freeware, although customized
versions of DISKSECURE can be ordered.
 
 
18) What about published reviews?
 
  It is said, in the computer world, that if you can tell the
difference between good advice and bad advice, you don't need any
advice.  This is particularly true in regard to reviews of
antiviral systems.  Performing an effective review of a piece of
antiviral software is an enormous challenge.  Because of this,
there are only a few independent reviewers of antiviral software,
and even fewer who have provided consistent reviews over time.
 
  Let the buyer beware.  Four major sources of antiviral reviews
have all had business relationships with antiviral vendors in the
past.  On the face of it, this would present the possibility of a
conflict of interest.  (To be fair, in two cases this does not
appear to have materially affected the quality of reviews.)  A
major computer periodical regularly prints reviews of antivirals,
and those in the know realize that mediocre products with large
advertising budgets regularly win.
 
  The "Reader's Guide to Antiviral Reviews," an article by Dr.
Alan Solomon (for some reason credited to Sarah Tanner) in the
November 1993 issue of the *Virus News International* (now
*Secure Computing*), is an excellent eye-opener.  Each of the 28
points discussed is a way to skew the results to favour one
product or denigrate another.  Some of them strain credulity, but
each is known to have been used in major published antiviral
reviews.  It can be read online at
http://www.drsolomon.com/avtk/vircen/choose.html#7
 
 
19) Where can I find published reviews?
 
  With the one major exception, computer magazines aremuch less
keen to review antiviral software than other applications.  Some
have stated that they will not do so because of the possible
liability should they make an error with software which is, after
all, more critical than any word processor could be.
 
Reviews can be found in:
 - "Virus Bulletin", and in "Survivor's Guide to Computer Viruses", Lammer
    (ed.)., 1993, Virus Bulletin (6 DOS, 4 OS/2)
 - "Robert Slade's Guide to Computer Viruses", Slade, 1996, Springer-Verlag
    (1 Amiga, 4 Atari, 34 DOS)
 - "Secure Computing"
 
They can also be found online at:
    http://www.virusbtn.com
    http://www.datafellows.com
    ftp://cs.ucr.edu/pub/virus-l/docs/reviews/pc
    telnet://guest@freenet.victoria.bc.ca (command "go virus")
    http://csrc.ncsl.nist.gov/virus/virrevws/
    http://www.drsolomon.com/avtk/reviews 
(This last site also has reviews from a number of computer magazines.)
 
Contributors
 
'Mike' M Ramey <mramey@u.washington.edu>
Graham Cluley <sandspm@cix.compulink.co.uk>
 
This version copyright Robert M. Slade, 1996   AVREVIEW.FAQ   960624
 
====================== 
roberts@decus.ca         rslade@vcn.bc.ca      slade@freenet.victoria.bc.ca 
"If you do buy a computer, don't turn it on." - Richards' 2nd Law of Security 
Author "Robert Slade's Guide to Computer Viruses" 0-387-94663-2
(800-SPRINGER)
============= for back issues: 
AV contacts   : telnet://guest@freenet.victoria.bc.ca (command "go virus") 
list, reviews : ftp://cs.ucr.edu/pub/virus-l/docs/reviews
and review FAQ: http://csrc.ncsl.nist.gov/virus/virrevws/ 
Viral Morality: http://www.bethel.edu/Ideas/virethic.html 
Book reviews:   telnet://guest@freenet.victoria.bc.ca (command "go tbooks") 
	  http://www.webwaves.com/books/slade
	  ftp://x2ftp.oulu.fi/pub/books/slade 
	  http://mag.mechnet.com/mne/books/reviews/slade/ 
	  gopher://gopher.technical.powells.portland.or.us:70 
	  http://www.utexas.edu/computer/vcl/bkreviews.html 
RobertS Rules of Internet Order: http://www.techbabes.com/zine/rules.html
	  http://www.brandonu.ca/~ennsnr/Resources/order.htm

=================================================================
			   
			   The Bookshelf  
			    Rob Slade

     Rob addresses the WEB this month.  With the WEB Pages growing
in popularity, one needs to know what the best books are to avoid 
spending money needlessly.  These two books are a good starting point.



========================

BKNTSNVW.RVW   960524
 
"Netscape Navigator", Brian Pfaffenberger, 1995, 0-12-553132-X
%A   Brian Pfaffenberger
%C   1300 Boylston Street, Chestnut Hill, MA   02167
%D   1995
%G   0-12-553132-X
%I   Academic Press Professional
%O   app@acad.com jmills@acad.com publisher@igc.org
%P   362
%T   "Netscape Navigator"
 
  This book serves as a very complete documentation of Netscape
Navigator.  It starts from the beginning.  For once, the section on
getting a connection to the Internet actually has some good advice,
although you'll still need to know your way around a modem to make the
connection.  The organization makes some sense, in terms of the things
that novice users are most likely to want to do first, although some
important points on configuration are relegated to the end in favour of
some early surfing.  "Helper applications" are given a high priority.
Use of Netscape to access other Internet applications (ftp, gopher,
news, and so forth) is also covered.
 
copyright Robert M. Slade, 1996   BKNTSNVW.RVW   960524

======================
 
"Web Publishing with Word", Asha Dornfest, 1996, 0-7821-1807-0, U$24.99
%A   Asha Dornfest
%C   2021 Challenger Drive, Alameda, CA   94501
%D   1996
%G   0-7821-1807-0
%I   Sybex Computer Books
%O   U$24.99 510-523-8233 800-227-2346 Fax: 510-523-2373 jjigarjian@sybex.com
%P   296
%T   "Web Publishing with Word"
 
  The Internet Assistant add-on module for MS Word is a very simplistic
HTML (HyperText Markup Language) tool, and this book fits very neatly
with the IA target audience.  It is a simple, lock-step, keystroke by
keystroke guide to the HTML production portion of Internet Assistant.
 
  This approach only works well, of course, with the page markup aspect
of Web page production.  The sections on forms and CGI (Common Gateway
Interface) programming really only tell half the story, and even the
creation of anchor links is a slightly more complicated task than the
book makes out.
 
  Unlike Ross, in "The Underground Guide to Microsoft Internet
Assistant" (cf.  BKMSINAS.RVW), Dornfest does not delve deeply into the
intricacies of the use of IA as a browser and so forth.  On balance this
is a good thing, since it allows the book to concentrate on a field
independent approach, and the simple page layout where IA is strongest.
 
copyright Robert M. Slade, 1996   BKWPWORD.RVW   960523






******************************************

Heres one for the books.  When talking about "weird" incidents on 
trouble calls, Frisk Skulason had this little story to tell:
===============

  I remember the lady that called in a panic because there was a
mouse in her computer...It took a long time for her to get anyone
to take her seriously...perhaps caused by the fact that this
happened on April 1st, but we did finally go there, and
fortunately with a camera...because otherwise nobody would have
believed us...but yes...the mouse was there all right...even more
scared than the owner of the machine.  We opened the box outside
and managed to get a nice picture of the mouse when it was
running away.  The machine smelled a bit strange, but it worked
OK after cleaning.

  I think this was the second most weird support call I have ever
received.

-frisk
 

 [ Question: One has to wonder what the "weirdest" was !!!? :-)]

=================================================================


What's NOT a Virus
Chengi Jimmy Kuo
Director, AV Research
McAfee Associates Inc.

  The "Virus Lab" is a misnomer.  But "Where They Explain to You
Why it's NOT a Virus" just doesn't have the same ring.  However,
each day, far more cases of "Not A Virus" are reported by
customers than actual cases of virus infections.  This phenomenon
is true at all levels of customer support.  So, instead of
talking about some neat, new antivirus technology, I hope to be
able to help you with something useful in your everyday work.

  Urban legends have inundated the computer virus world such that
any computer malady is blamed on a computer virus being in the
system.  But there are multitudes of situations blamed on viruses
which are not.  This paper is based on many customer situations
through McAfee's Technical Support, questions raised on the
Internet, with experience and contribution from the Tech Support
or Customer Support of other companies in the industry.

1.0 PC Architecture

1.1 I Don't Have 640K

  At memory location 40:13 is a word representing how much base
memory is in the machine.  The value usually found at 40:13 is
280h which means the machine has its full complement of 640K
(655,360).  Utilities such as CHKDSK or MEM can be used to fetch
this value.

  Starting with the introduction of the IBM PS/2 in 1987, IBM and
then others, started to fake the total memory count by one K or
two by decrementing this number and using the space for
additional system storage space.  For IBM, this area was referred
to as the Extended BIOS Data Area (EBDA).  The IBM PS/2s reserved
1K.

  It is true that most boot sector viruses do steal memory from
40:13 and place themselves at the memory it has reserved by doing
so.  So, when a user sees something other than 640K, he usually
jumps up and down about having a virus.

  Since DOS supplies other methods to reserve memory, in finer
granularity than 1K, most software solutions will use DOS to
reserve memory.  However, many things which I call "hardware
related software" (such as drivers for monitors, drivers for ROM
addons, etc.), that require the use of some memory but cannot
address DOS to reserve memory, will also "steal" a K or two using
this architected way of reserving memory.

  Officially, the architecture for this mechanism includes the
requirement to store a word at xxxx:0 with the value of how many
K is reserved in that block.  Thus correct implementation of this
schemeh as values like this (assuming 640K available in system):

	40:13           Address         Value
	0280h           (full 640K)

	027Fh           9FC0:0000       1

	027Eh           9F80:0000       1
			9FC0:0000       1
			or
			9F80:0000       2

	etc.

  So, if less than 640K is reported, check the memory using the
table above. If there is a boot sector virus in memory, chances
are, you will also find the values 55h AAh near the top of memory
at a memory address of xxxx:xxFE.

1.2 Happy Birthday on November 13th

  On November 13th, some PCs around the world will play the Happy
Birthday song through the PC speaker.

  A "former" programmer at American Megatrends managed to
sabotage a BIOS run.  The specific information is listed below:

	BIOS Manufacturer:      American Megatrends
	BIOS Version:           M82C498 Evaluation BIOS v1.55
	BIOS Category:          IBM PC/AT
	BIOS ID Bytes:          FC 01 00
	BIOS Date:              04/04/93

  If you have one of these BIOS chips, you can contact AMI to get
a replacement.

2.0 Windows 95

2.1 LongFileName Directory Entries

  The way Windows 95 manages its LongFileNames is to use a trick
associated with volume labels.  According to documentation (See
Appendix A.), if the volume label bit is set, all other
information in that directory entry is ignored.

  Here is a sample of a Windows 95 directory as interpreted by
DEBUG (uninteresting parts chopped out to save space):

0E0  41 50 00 72 00 6F 00 67-00 72 00 0F 00 20 61 00   AP.r.o.g.r... a.
0F0  6D 00 20 00 46 00 69 00-6C 00 00 00 65 00 73 00   m. .F.i.l...e.s.
100  50 52 4F 47 52 41 7E 31-20 20 20 11 00 00 00 00   PROGRA~1   .....
110  00 00 00 00 00 00 CC 80-17 1F 81 1E 00 00 00 00   ................
180  41 45 00 78 00 63 00 68-00 61 00 0F 00 15 6E 00   AE.x.c.h.a....n.
190  67 00 65 00 00 00 FF FF-FF FF 00 00 FF FF FF FF   g.e.............
1A0  45 58 43 48 41 4E 47 45-20 20 20 10 00 78 BC 81   EXCHANGE   ..x..
1B0  17 1F 17 1F 00 00 BC 81-17 1F 38 16 00 00 00 00   ..........8.....
1C0  43 4F 4D 4D 41 4E 44 20-43 4F 4D 20 00 00 00 00   COMMAND COM ....
1D0  00 00 6E 20 00 00 40 4E-EB 1E 3D 42 C6 6A 01 00   ..n ..@N..=B.j..

Here is the output of DiskEdit as it interprets the above information:

Name     .Ext    Size     Date     Time  Cluster Arc R/O Sys Hid Dir Vol
------------------------------------------------------------------------
      AP        7536741  3-12-80 12:03 am      0     R/O Sys Hid     Vol
PROGRA~1              0  8-23-95  4:06 pm   7809     R/O         Dir
      AE     4294967295 15-31-7   7:63 pm      0     R/O Sys Hid     Vol
EXCHANGE              0  8-23-95  4:13 pm   5688                 Dir
COMMAND  COM      92870  7-11-95  9:50 am  16957  Arc

  This behavior by Windows 95 is often misinterpreted by
unsuspecting users as a virus which creates HUGE illegal files
onto their drives, or as a virus which corrupts file entries.

  All it actually is, is people looking at absolutely correct
information with inappropriate tools.

2.2 Windows 95 Writes to Diskette OEM Fields

  With Windows 95, when you insert a diskette into the drive, it
will write to the diskette OEM Name field (see Appendix B).  I
believe this is done for volume change detection.  If the
diskette is not write-protected, Windows 95 will write 4 random
characters plus the 3 letters "IHC".

  This activity has sometimes been interpreted as a virus
constantly writing to diskettes.  After all, the user has done
nothing of note to cause a write to the diskette.

  [Curiosity item: IHC and 4 spaces makes one believe that at one
point, " OGACIHC" was the string being written in this location.
"Chicago" was Microsoft's codename for Windows 4.0 which was
later renamed to Windows 95.]

2.3 I Didn't Have a Label For My Harddisk, But Now I do

  Every disk is allowed to have a label.  One can assign a label
to a disk by using the LABEL command supplied with DOS. When the
LABEL command is used, it creates a directory entry with the
volume label bit enabled.

  The first entry with a label bit in the root directory is
interpreted to be the label of the disk.

  If we look at Appendix A, you will note that if the label bit
is set, all other fields are ignored.  Windows 95 uses this trick
for its LongFileName entries.

  If you did not initially give your disk a label, the first
LongFileName will then satisfy the LABEL criteria.  And your disk
will now bear a weird looking LABEL name.

2.4 Windows 95 Says You Have a Boot Sector Virus

  Windows 95 has a dialogue box which will show up on certain
occasions.  It is true most of the time that if the box shows up,
you do indeed have a virus.  However, the mechanism behind this
determination is that the INT 13h vector has been changed.

  Again, the most likely thing is indeed that a boot sector virus
was responsible for this change.  However, installation of
certain security related software may also result in the report
of this message.

2.5 SUHDLOG.DAT

  SUHDLOG.DAT is a file found on Windows 95 systems.  It contains
images of the master boot record (partition sector) and boot
sectors of your hard disks.  Therefore, if a boot sector virus
had once gotten on the machine, it will be saved in the file
SUHDLOG.DAT.  Depending on the technology used by the scanner
involved, scanning the file might produce a warning of a boot
virus in the file.

  Why is this not a virus?  After all, it does indicate that a
boot virus had at one point been on the machine.

  If this occurs, it means a virus was once on the machine.  It
does not mean that the file is infected by a boot sector virus.
After all, a boot sector virus is being reported in a file.  But
do boot clean and check the system.  Also, delete the file.

3.0 Windows

3.1 386SPART.PAR

  This is a hidden file to mark the swap space used by Windows
3.x.  Swap space allows an operating system (or normal
executable) to write things that are not currently being used,
onto disk and free up RAM memory for things that need to be
there.

  Sometimes, a scanner will detect a virus in this file.  There
are a number of possible causes for this:

1) There's actually a virus on the system.  It was captured in
   memory and written to this file.

2) One scanner is picking up another scanner's strings which
   were only supposed to be alive in memory.  That is, even if the
   first scanner is otherwise known as a well-behaved scanner that
   encoded its strings, at some point, the scanner decrypted the
   strings so it could use them.  It was unlucky to have had that
   piece of memory swapped out at that point.  When that scanner
   finished, it cleaned its memory.  But there's no chance to
   "clean" the swap file.

3) A scanner is picking up itself in memory, similar to 2).
   But actually more likely than 2).

  To remove or adjust its size, use the interface found in 386
Enhanced settings in the Control Panel.  One last note, a "really
big" swap file does not necessarily mean faster speed. There is
an optimal setup for your machine depending on how you use it.


3.2 Black box as mouse pointer

  The arrow used by Windows to show where the mouse currently
points is something called a sprite.  There's a whole different
science for how to deal with sprites.

  In this case, Windows simply wasn't able to read in the sprite
associated with its current environment.  Thus, the sprite is
just a black box.

4.0 DOS

4.1 DIR | MORE

  Pipes, the concept of allowing output from one program to be
used as input to another program, was an afterthought of DOS
introduced in DOS 2.0. The method of implementation was to direct
the output of one process to be written to a file.  The first
program finishes execution.  Then the second program runs.  It
reads from this temporary file and uses it as its input stream.

  This temporary file is created in the directory designated by
the TEMP environment variable.

  As it happens, DOS creates 2 temporary files for the process
"DIR | MORE".  These two files have names generated as some
random set of 8 characters.  Thus, each invocation creates 2
differently named files.

  No one happenstance generates more phone calls and questions
than this one.

  [I happen to use NDOS, a derivative of 4DOS.  It also creates
temporary files in the directory designated by the TEMP
environment variable.  But, this set of circumstances only
creates one file and it is always a constant name.]

4.2 PEAT and \REPEAT\REPEAT\REPEAT\...

  This is the issue of infinitely recursive subdirectories.
Looking at Appendix A, you will see that one of the fields
represents the cluster number of the subdirectory.  Thus, if you
replace the cluster number of a subdirectory with the cluster
number of the directory itself, you can generate this scenario.

  Well, that's not all that easy to do, except... if you're in
the root directory.  Any subdirectory with its cluster number set
to 0 will point back to the root directory.  So, if you overlay a
random data file over the root directory, a random byte will have
the subdirectory bit set and if there happens to be a NULL in the
cluster field, you will create this situation.

5.0 Software Applications

5.1 Where's Waldo?

  A version of CorelDraw 5.0 had the capability of presenting the
message "Where's Waldo?" to the user. If you hear this from a
user, ask first if he's using CorelDraw.

No virus currently presents this message to the user.

5.2 Word Perfect

  Ever since Macro Viruses for Word for Windows came into being,
there have been many people attributing any Word Perfect problem
to "Is this a new Word Perfect virus?"

Until you hear otherwise, the answer is, "No."

  Presently, Word Perfect manages its macros in a separate file
from that of the text.  Since it's the macros that would contain
a virus, should there ever be one, and since people don't
generally pass macros when they pass around Word Perfect
documents, chances of a Word Perfect virus becoming a threat to
users is close to nil.

5.3 What's UNWISE.EXE?

  It's probably the worst marketing choice for a program name
I've ever come across.

  The truth is, UNWISE.EXE is a program called Wise Uninstall
which is included with some Windows shareware programs.

6.0 AntiVirus Software

6.1 ChipAway Virus Enabled

  A particular antivirus product instituted in BIOS has
inappropriately chosen the activation messages of "ChipAway Virus
Enabled."  When this phrase is seen during the bootup process, it
represents that this product has been activated.

6.2 Traces of a Virus Found in Memory

  While this message is the message presented by McAfee's Scan,
it represents the concept of one antivirus product finding
another antivirus' strings in memory.  One of the best known of
this circumstance is the combination of Scan and CPAV/MSAV.
Running CPAV and then SCAN will usually generate this message.

6.3 Virus Found in ANTIVIR.DAT

  In 6.2, we showed circumstances where one antivirus product
locates another in memory.  There is also the circumstance of one
antivirus finding strings in another antivirus' data files or TSR
executables.  This is especially true now that there are
heuristic analyzers.

  What the heuristic analyzers are perhaps finding are viral
snippets that are used to identify viruses.  But it is not the
complete virus.

  A similar situation arises when some antivirus packages are
used to scan data files when "Scan All Files" is chosen.  In this
situation, the viruses "detected" are usually some kind of
polymorphic virus.  This brings forth the issue, "Should you be
scanning all files?"  My answer is, each product is presented to
you with a default mode.  Careful thinking is applied to choose
the right set of defaults.  Yet no product that I'm aware of has
a default setting of scanning all files.  All products recommend
a certain configuration.  Think about that.

  [The chance that an antivirus package is distributed with a
virus is actually relatively high if you are not downloading the
package from a known and trusted site.  Antivirus packages have
been known to be trojanized many times in secondary
redistribution channels.

Be safe.  Download originals from official supported sites.]

6.4 Loading Bootstrap...

  This is a message placed by SCAN in the MBR bootup process
after it has cleaned certain boot sector viruses.  Because the
user has just completed an encounter with a virus, he is very
alert to any new strangeness he encounters.  Seeing this new
message, he immediately believes this is something laid by the
virus.

This message has been removed as of last summer.

6.5 Something is Writing to Your Boot Sector...

  Antivirus products vary in technology.  One technology
implemented by some antivirus products is called behavior
blocking. However, use of this technology often involves giving
too much power to users who do not understand the capabilities
nor the circumstances.

  The most common behavior blocking issue raised to our technical
support is, "Something is writing to my boot sector!"  This could
be a virus.  But it could be that the user just typed FORMAT.

  I would recommend, in a corporate environment, you allow users
to decide for themselves whether they wish to run a behavior
blocker.  If the user is unaware that he is using behavior
blocking technology, you will be confronted with more non-virus
cases than situations where it actually stopped a virus.  Yet,
you may decide that you would be able to live with a 10 to 1
non-viral to viral ratio because the one virus infection that it
catches costs more to clean up than the on-going support.

  The choice of using an antivirus is the determination that the
cost of running an antivirus is less than the cost of cleaning up
after virus infections.  Therefore, only you can evaluate the
cost for your organization.


7.0 Macintosh

7.1 Welcome Datacomp

  Users of Apple's Macintosh have been mystified by the
occasional occurrence of the string "welcome datacomp" appearing
amidst their typed text, knowing that they hadn't typed it.  This
has been traced to a particular make and model of a third-party
Macintosh-compatible keyboard.  This string is apparently
programmed into the keyboard's ROM.

From the alt.comp.virus FAQ:

  "It appears to be a practical joke, coded into the keyboard's
ROM, that causes the keyboard to output that text (as if it was
typed) after a period of keyboard inactivity.  The only practical
fix is to replace the keyboard."

7.2 August 27, 1956

  If your Mac has this date, it's time to replace the battery.
This is the default, time-0 for the Mac.

8.0 Hoaxes

8.1 Good Times

  "If you see Good Times in the subject header of your message,
delete it!"

  Actually, this is good advice, because the rest of the message
is bound to be worthless.

  A message warning of the Good Times virus first appeared in
November of 1994.  The warning for the virus reports that if you
read a message with "Good Times" in the title, your hard disk
will be damaged beyond repair as well as a number of other
wondrous things.  When the reports first surfaced, the report was
easily and quickly dismissed.  Nothing can have such effects
across the spectrum of operating systems and processors as
claimed by this omnipotent e-mail virus.

  However, fall of 1995 saw a resurgence of messages warning
again of the Good Times virus.  It is believed that news stories
regarding macro viruses lent more credence to the e-mail aspects
of the report.  But, the story remains a hoax.  The things it
claims to be possible across the spectrum of e-mail programs
remain an impossibility.

  The reports continue to spread.  And in effect, the message
itself has become the virus.

8.1.1 GT-Spoof

  To try to give credibility to the Good Times story, some virus
writers immediately created a virus using one of the virus
creation programs with the name "Good Times" inside the virus.
The antivirus community, seeking to insure that no confusion came
about from this, named this virus GT-Spoof.

8.1.2 FormatC

  FormatC is a trojan horse written as a Word document.  It is a
Word document which contains one macro which does a call to
execute the DOS command FORMAT.  It was written and posted to an
Internet newsgroup.

  Because it was written during the initial hoopla over Word
macro viruses, many people have also included FormatC in their
list of Word macro viruses.  Also, many people freely associate
trojan horses as viruses.  Thus FormatC is often referred to as a
virus.  It is not.  It is a trojan horse.

  It is being discussed here because it may have had a bearing on
lending credibility to the Good Times scare.

8.2 Viruses Destroying Hardware

  Because every unknown computer malady has been associated with
viruses, many pieces of damaged hardware have been attributed to
viruses as well. In order to explain the issue of viruses
destroying hardware, we must step back and explain the concept of
software destroying hardware.

  The truth behind the ability of software to destroy hardware is
that generic software cannot destroy generic hardware.  However,
every piece of hardware has recommended parameters of use. Thus,
in order to damage hardware, one either uses the hardware outside
its recommended parameters or wears it out through repetitive
overuse.

  No virus has yet to do this.  Chances of any virus successfully
accomplishing this (and spreading) are not high.  In real terms,
this issue is myth, not fact.

  Remember, the only possible ways to destroy hardware through
software is through a directed attack or through repetitive
overuse.

8.3 Internet Cleanup Day

  All I can say is that it was wonderful to use my Internet
connections on Feb 29th.  To those who complied with Internet
Cleanup Day, thank you.

Acknowledgments

Dave Chess, IBM
Shane Coursen, Symantec
Sarah Gordon, Command
Tom Simondi
Heather Stern, McAfee; and many others at McAfee



Appendix A

The Directory Entry

A directory file consists of sequential 32 byte entries:

Byte    Description
0-7     Filename
	
	Byte 0 indicates the status of the directory entry.

  Value   Meaning
  00h     This entry has never been used. (Directory searches can
	  stop here.)
  05h     The actual first character is an E5h.
  E5h     This entry has been erased (it's free).
  2Eh     Dot.  This is the entry which holds information
	  about this directory  cluster. If the second character is
	  also 2Eh, then this entry is  dot-dot, or the parent directory.
	  If the parent directory is the root   directory, then cluster
	  number will be 0000h.

8-10    Filename extension

11      File Attribute

	The file attribute is a bit mapped value.

Bit     Meaning
01h     1 = Read-only file.  If function 3Dh or 6Ch is used to open
	    the file for output, an error code is returned.
02h     1 = Hidden file. This file is excluded from normal directory
	    searches.
04h     1 = System file. This file is excluded from normal directory
	    searches.
08h     1 = Volume ID in the first 11 bytes. This file is excluded from 
	    normal directory searches.  No other fields are interpreted.
	    Windows 95 marks this bit for its LongFileName entries.
10h     1 = Subdirectory file.  This entry points to a subdirectory and thus 
	    is not searched.
20h     1 = (Archive bit) File has been written to and closed.  BACKUP and 
	    RESTORE uses this bit to determine if a file has been changed
	    since the last BACKUP.

12-21   Reserved (OS/2 uses some of these bytes)

22-23   File Creation or Last Changed Time

The time is encoded into 16 bits:

Bits    Meaning
0-4     Seconds (in 2 second increments)
5-10    Minutes (0-59)
11-15   Hours (0-23)


24-25   File Creation or Last Changed Date

The date is encoded into 16 bits:

Bits    Meaning
0-4     Day (1-31)
5-8     Month (1-12)
9-15    Year + 1980 (0-119: 1980-2099)

26-27   First Cluster of the File.  One uses this number to index
through the File Allocation Table to determine the chain of the
full file. (Standard Intel 16 bit value).

28-31   File Size (standard Intel 32 bit value)

Appendix B

The DOS Boot Record

A Boot Record is found on each DOS volume.  It describes the media.

Byte    Description
0-2     Code
	
The boot up process passes execution to the sector which is read in.
Thus, this code must be able to do something intelligible.

Prior to DOS 4 or 5, the following definition was documented but was
not being checked by DOS. Sometime around DOS 4 or 5, DOS started
requiring this:

	Byte    Value           Description
	0       EB              Short jump opcode
	1       any             Distance of short jump
	2       90              NOP

		or

	0-2     E9 xx xx        Jump instruction
	3-10    OEM Name        Anyone can write anything they want here.
	11-12   Bytes per sector
	13      Sectors per cluster (must be a power of 2; maximum = 128; 
	real maximum = 64)
	14-15   Reserved sectors at beginning
	16      Number of File Allocation Tables
	17-18   Maximum number of Root Directory Entries
	19-20   Total sectors on media
	21      Media Descriptor


	Bit     Description
	0       1 = 2 sided     0 = not 2 sided
	1       1 = 8 sector    0 = not 8 sector
	2       1 = removable   0 = not removable
	3-7     reserved = 1

	Value   Description
	F8h     Fixed disk
	F9h     5.25", double sided, 15 sectors/track
	FCh     5.25", single sided, 9 sectors/track
	FDh     5.25", double sided, 9 sectors/track
	FEh     5.25", single sided, 8 sectors/track
	FFh     5.25", double sided, 8 sectors/track
	FEh     8", single sided, 26 sectors/track
	FDh     8", double sided, 26 sectors/track
	FEh     8", double sided, 8 sectors/track

	[Note: There are more notes on 8" diskettes, but I don't think 
	they're that pertinent.]

	22-23   Number of sectors used by a File Allocation Table
	24-25   Sectors per track
	26-27   Heads
	28-31   Hidden sectors
	32-35   Huge sectors
	36      Physical drive number
	37      Reserved
	38      Boot signature
	39-42   Serial number
	43-53   Volume label
	54-61   Filesystem type


	Value           Description
	"FAT12   "      12 bit FAT (8 byte string, last 3 are spaces)
	"FAT16   "      16 bit FAT (8 byte string, last 3 are spaces)
	 
	 
	 62-     Start of code
	
	Usually where the code at 0 jumps to.


Appendix C

Beep Codes

A Beep Code is audible output from the machine intended to deliver 
information when no visible means are possible.  Beep codes different, 
depending on the manufacturer.

IBM POST Audio Error Codes:

1 short beep            All OK or Display error
2 short beeps           POST error - Error code on CRT, or Display error
No beep                 Power, motherboard
Continuous beep         Power, motherboard
Repeating short beeps   Power, motherboard, stuck keyboard key
1 long, 1 short beep    motherboard, clock speed too fast
1 long, 2 short beeps   Display adapter (MDA, CGA)
1 long, 3 short beeps   Enhanced Graphics Adapter (EGA) video RAM
3 long beeps            3270 keyboard card

AMI BIOS Audio POST Codes:

1 short beep            DRAM refresh failure
2 short beeps           Parity circuit failure
3 short beeps           Base 64K RAM failure
4 short beeps           System timer failure
5 short beeps           Processor failure
6 short beeps           Keyboard controller Gate A20 error
7 short beeps           Virtual mode exception error
8 short beeps           Display memory Read/Write test failure
9 short beeps           ROM BIOS checksum failure
10 short beeps          CMOS Shutdown Read/Write error
11 short beeps          Cache Memory error
1 long, 3 short beeps   Conventional/extended memory failure
1 long, 8 short beeps   Display/retrace test failed


______________________________________________________________________
Chengi Jimmy Kuo                April 1-2, 1996
NCSA Conference, Washington, DC

======================================================================
		     

		  Hacks, Viruses and Trojans 


 Apparently Novell had put some extra coding into the disks 
after disk 2 which will cause certain AV programs to hit on
them.  Novell has varified that there is NO Boot Sector virus.  
The programs and their reports are as follows 
(according to COREL techs)

Program             Report

Dr Solomom          AntiCMOS
ViruSafe            Gazell virus
PCRX                Boot Sector virus
PC Cillin           Boot Sector virus
VirNet  PC          Adnormal Boot Sector
F-Prot              Adnormal Boot Sector     
AVP                 AntiCMOS
Nortons AV          Read IO.sys virus
Intel Lan Detect    Read IO.sys virus
SOPHO Suite         AntiCMOS

Grahnm Cluley of Dr. Solomon's team confirmed with this:


------------------------------

Date: Fri, 05 Jul 1996 18:28 +0000
From: Graham Cluley <sandspm@cix.compulink.co.uk>
Subject: Re: WP 6.1 intall (PC)
X-Digest: Volume 9 : Issue 108

In-Reply-To: <01I6P0A73T6KWHZC3A@csc.canterbury.ac.nz>
Howard Wood <Woody@diversicomm.com> writes:

> This past week I encountered a situation with WP 6.1 for
>Windows that I need to pass along.Apparently Novell had put
>some extra coding into the disks after disk 2 which will cause
certain AV programs to hit on them.  Novell has varified that
there is NO Boot Sector virus.  The programs and their reports
are as follows (according to COREL techs)

[snip!]

  I passed this by the chaps in our technical support department
and one of them said it sounded familiar.  It turns out that we
first saw this problem about a year ago.  From what they recall,
Novell's original WordPerfect master disk was infected with
AntiCmos.  The virus was cleaned up but, unfortunately, the
scanner they used to clean it didn't do a very good job as it
left fragments of virus code behind.  Instead of building a new
disk, they used the cleaned one to duplicate copies of
WordPerfect.

Subsequently, when the disk was scanned, a virus was reported by some
anti-virus products.

> Novell has varified that there is no Boot Sector virus.

That's right.  The disk is clean.

Regards
Graham
- --
Graham Cluley                                 CompuServe: GO DRSOLOMON
Senior Technology Consultant,     UK Support: support@uk.drsolomon.com
Dr Solomon's Anti-Virus Toolkit.  US Support: support@us.drsolomon.com
Email: gcluley@uk.drsolomon.com             UK Tel: +44 (0)1296 318700
Web: http://www.drsolomon.com                 USA Tel: +1 617-273-7400
Evaluation version of Dr Solomon's FindVirus available on our website!

=============================


Microsoft distributes the Sampo virus by accident
-------------------------------------------------
Microsoft accidentally distributed approximately 1500
diskettes infected with the Sampo boot sector virus (see
Update Bulletin 2.16) at a recent Microsoft Business
Solutions Conference in Hong Kong. The diskettes contained
the Microsoft Internet Explorer 2.0 web browser. The
infection took place at the diskette duplication company,
and Microsoft will replace the infected diskettes.


Source: F-PROT Professional Update Bulletin 2.23  
	Copyright (c) 1996 Data Fellows Ltd.

==================================================================





		     STONED.EMPIRE.MONKEY.A Removal

  This seems to be one of the most active viruses at this time.
I am constantly seeing questions about it in the Virus-L Digest
and on the various virus conferences.  Rather than me trying to
explain it, I felt it best the "experts" pass along their
summations and techniques in its removal.


Mr. Mikko Hypponen of Datafellows LTD, Finland on 
Stoned Monkey Empire A virus and F-Prot: ( Latest version 2.23a)


STONED.EMPIRE.MONKEY.A
----------------------

  The Monkey virus was first discovered in Edmonton, Canada, in
1991.  The virus quickly spread to USA, Australia and UK. Monkey
is one of the most common boot sector viruses.

  As the name indicates, Monkey is a distant relative of Stoned.
Its technical properties make it quite a remarkable virus,
however. Like Stoned, the virus infects Master Boot Records on
hard disks and DOS boot records on diskettes. Monkey spreads only
through diskettes.

  The original Stoned leaves the partition table in its proper
place in the hard disk's zero track, but Monkey does not .
Instead, it copies the whole Master Boot Record to the hard
disk's third sector to make room for its own code. The hard disk
is inaccessible if the computer is booted from a diskette, since
the operating system cannot find valid partition data in the boot
sector - attempts to use the hard disk result in the DOS error
message "Invalid drive specification".

  When the computer is booted from the hard disk, the hard disk
can be used normally because the virus is executed first. The
virus can, therefore, escape notice, unless the computer is
booted from a diskette.

  As Monkey not only moves but also encrypts the Master Boot
Record, it is difficult to remove. The changes to Master Boot
Record cannot be detected while the virus is active, since it
reroutes the BIOS-level disk calls through its own code. Upon
inspection, the hard disk seems to be in its original shape.

  There are two often-used procedures, either of which can
disinfect most boot sector viruses. One of these is the MS-DOS
command FDISK /MBR, which rewrites the code in the Master Boot
Record, and the other is using a disk editor to restore the
Master Boot Record back on the zero track. In this case, the
relocation and encryption of the partition table render these
methods unusable. Although both procedures destroy the actual
virus code, the computer cannot be booted from the hard disk
afterwards.

There are five viable ways to remove the Monkey virus:

  1. The original Master Boot Record and partition table can be
     restored from a backup taken before the infection. Such a
     backup can be made with the MIRROR /PARTN command of MS-DOS 5,
     for example.
     
  2. The hard disk can be repartitioned by using the FDISK
     program, after which the logical disks must be formatted.
     The procedure will also destroy all data on the hard disk,
     however.

   3. The command FDISK/MBR can be used to overwrite the virus
      code, after which the partition table can be restored manually.
      In this case, the partition values of the hard disk must be
      calculated and inserted in the partition table by using a disk
      editor. The method requires expert knowledge on the disk structure.

   4. It is possible to exploit Monkey's stealth capabilities by
      taking a copy of the zero track while the virus is active. Since
      the virus hides the changes it has made, this copy will actually
      contain the original Master Boot Record. This method is not
      recommendable, because the diskettes used in the copying may well
      get infected.

   5. The original zero track can be located, decrypted and
      moved back to its proper place. As a result, the hard disk is
      restored to its exact original state. F-PROT uses this method to
      disinfect the Monkey virus.
     
  The Monkey virus is quite compatible with different kinds of
diskettes.  It has a built-in table containing structural data
for the most common diskette types. Using this table, the virus
is able to move a diskette's original boot record and a part of
its own code to a safe area on the diskette. If Monkey does not
recognize a diskette, it moves the boot record to the diskette's
third physical sector. This is what happens also to, for
instance, 2.88 megabyte ED diskettes, with the consequence that
Monkey partly overwrites their File Allocation Tables.

  The virus is difficult to spot, since it does not activate in
any way.  A one-kilobyte reduction in DOS memory is the only
obvious sign of its presence. The memory can be checked with, for
instance, DOS's CHKDSK or MEM programs. However, even if MEM
reports that the computer has 639 kilobytes of available memory
instead of the more common 640, that does not necessarily mean
that the computer is infected. In many computers, BIOS allocates
one kilobyte of DOS memory for its own use.

F-PROT recognizes and removes all known variants of the 
Stoned.Empire.Monkey virus.

			     ************

Mr. Wolfgang Stiller of Stiller Research, and the Author of Integrity Master,
on the Stoned.Empire.Monkey.A virus and Integrity Master: 
(Latest version 2.61b)


  Monkey: (Description quoted from Integrity Master User's
	  Guide)
Synopsis: Resident, stealth infector of floppy boot
	  sectors and partition sectors
Symptoms: Inaccessible hard disk
	  after floppy boot, 1K less available memory

 Details:
     Monkey is unusual in that it completely replaces the partition
     sector with its own code. If you boot from a floppy the hard
     disk will be inaccessible since there is no valid partition
     table in the partition sector.  If the virus is resident in
     memory, it will use stealth techniques to return the original
     unmodified partition sector.


  Once Integrity Master (AKA IM) is installed, removing Monkey is
trivial. It will detect the virus in memory and ask you to boot
from a diskette.  (The hard disk will of course seem inaccessible
at this point but Integrity Master can access it anyway.) After
you boot, you just use the "ReLoad" menu to restore the "missing
partition sector" (AKA Master Boot Record or MBR). Other products
call this the master boot record but we prefer to call it the
"partition sector" since it contains the hard disk's partitioning
information and to more clearly differentiate from the operating
system boot sector (usually a DOS boot sector).

  What if you get the Monkey virus but you don't have Integrity
Master installed already?  You could remove Monkey, with an
"FDISK /MBR" but then you would lose access to your hard disk.
Not a good idea!  Removal with Integrity Master is easy.  Running
IM on your infected PC, you use the Initialize menu to capture
your partition sector. IM writes this to part.srl. What IM
manages to do at this point is to get you a copy of the
uninfected (clean) partition sector (Master Boot Record). You
copy this to a diskette (realizing that this diskette is now
infected).  You now boot from a clean write-protected DOS
diskette and run IM from floppy.  You can now use the "ReLoad"
menu to reload the missing partition sector as before.  (You will
need to insert the diskette with Part.srl in any one of the
floppy drives at the point you do the reload.)

  Don't forget to disinfect all your diskettes.  The best way to
do this is to scan your diskettes  (use the scan Multiple
diskettes menu option in IM for this or the command IMSCAM a:
where "a" is your drive letter.)  If the diskette is infected,
copy all data to another diskette and trash or reformat the
diskette. It's not safe to just remove the infected boot sector
since Monkey will damage the file structure on the diskette
causing possible data loss, if the diskette is not reformatted.

-Wolfgang

===================================================
		     KillMonk

  There is one program out there that is made explicitly for the
removal of the Monkey viruses and the INT 10 virus.  The progam
is called Killmonk3.

  Killmonk3 was written by Dr. Tim Martin of Vancouver Canada.
Tim was kind enough to allow me to reprint his notes on the
Monkey virus along the instructions to run killmonk.

============================================================

Dr. Tim Martin:


  Monkey infects during a "restart" of the computer.  The restart
might be by turning on the power, or by pressing the RESET
button, or by pressing CTRL-ALT-DEL. The diskette in drive A:
doesn't have to be a system diskette, in fact it can be a "blank"
diskette.  All it needs to be is a diskette that was used in an
infected computer at least once in its history.  Any time you see
the message

  "Non system disk or disk error: Replace and press any key to
   continue ...."

if that diskette was infected, the hard disk is now infected as well.

  The MBR is the first software to run on a computer, when you
start the computer from a hard disk.  This means the virus runs
first, before any DOS programs, before even DOS or any other
operating system is loaded.  The virus installs itself in memory,
sets itself up to watch all attempts to read from or write to any
disk, and then reads the original MBR from where it hid it in
sector 3, decodes it, and runs it.  The MBR then proceeds to load
the operating system in its normal fashion, but with the virus
running in the background, watching all disk access.

While the virus is running, it does three things.  

  1) If an attempt is made to "look at" the virus on the disk,
     that is, an attempt to read sector one, then the virus shows a
     decoded copy of sector three.  So a program looking for the virus
     will see a clean MBR instead.

  2) If an attempt is made to write to sector one (thereby
     overwriting the virus) no write happens.

  3) On any other disk or diskette access, the virus might decide
     to infect the disk or diskette being accessed, if it isn't
      already infected.

  On diskettes, the virus infects the first sector, which is
called the "boot sector".  This is the first software the
computer runs if the diskette is left in drive A: when the
computer is restarted.  The infection cycle is complete.

NOTES:

  1.  Monkey does not keep a copy of the partition table intact
in sector one.  The only way to read the partition table of a
hard drive that is infected with Monkey is by decoding sector
three.  If the virus is running, it does this automatically
whenever any software ask for the information in the
"traditional" way.  Unfortunately, with accelerated disk
controllers and "32-bit Windows access" or OS/2, the hard disk
isn't accessed in the "traditional" way.

  2.  Monkey DOES NOT damage file systems.  It does not write to
the file system in any way.  If your file system has become
corrupted, or files have been erased, something else caused that.
The analogy I use is that Monkey is like a vandal damaging the
front door lock on a house.  The contents of the house are
untouched, but until the door lock is fixed, one can't get into
the house to see or use the contents.

  3. Monkey does not spread via modem, networks, or the Internet.
If it is on your hard disk, it got there from a diskette that was
in drive A: sometime in the past.  Even if you have never used a
diskette in drive A: of your computer, the people who set your
computer up for you, or last did maintenance on it, likely have.

  4. Monkey was first discovered in February 1992 (the beginning
of the "Year of the Monkey", and has been reported all over the
world.  If it has gotten to your corner, I'm not surprised.

----------------------------

Question: How does Killmonk work?

 Answer:

   If Monkey is running on a computer, it is visible in
memory, as long as a program knows where to look.  And if Monkey
is not running, then it is visible on the hard disk.  In both
cases, Killmonk knows where to look.  If the virus is currently
running, then Killmonk uses the virus' own tricks to decode the
hidden copy of the MBR and rewrite it to sector one.  If the
virus isn't currently running, the cleanup steps are even easier.

  If the hard disk was cleaned by Killmonk, then Killmonk insists
on rebooting the computer.  If the hard disk wasn't infected,
then Killmonk will give you the option of cleaning diskettes.

  Killmonk v. 3.0 also removes a virus related to Monkey, called
Int_10, and it has improvements to remove the virus from second
hard drives, as well as improvements in its ability to clean up
after other programs have messed up the cleanup effort.

----------------------------

Question: What can I do if Killmonk fails?

[EDITOR'S NOTE: This is *ONLY FOR EXPERIANCED USERS* ]

Answer:

 That's a tricky one.  The task has two parts: first fix
the boot program part of the Master Boot Record, and second, fix
the partition table.  For someone who knows what they are doing,
these tasks are not difficult.  But few people know how to do it. 

  First, make sure you have tried Killmonk from both a clean
diskette and from the hard drive -- if you can still boot the
computer from the hard drive.

  Or you might try to do the job yourself.  The easiest way to do
it yourself is with a combination of "FDISK /MBR" to reinstall
the DOS boot program code, and Norton Disk Doctor to rebuild the
partition. You will need a clean system diskette, a clean
diskette with FDISK.EXE and a diskette with Norton Disk Doctor.

1. Confirm that the CMOS BIOS setting is set for your computer to
   boot from A: if there is a diskette in A:  On most systems, this
   involves pressing the DEL key while the computer is first starting
   up, and working your way through a "setup" menu of some kind.

2. Write protect your clean system diskette.

3. Confirm that it is clean.  (You can do this by checking it with
   Killmonk running on a clean computer.)

4. Boot your computer from the clean diskette.

5. Run 
      FDISK /MBR
   This will put the proper boot code back into the first sector of
   the hard drive.

6. Run Norton Disk Doctor, and follow the menu steps to rebuild a
   corrupted partition table.


===================================================================


		     Bill's Desk

  I am an independent Virus researcher, and test A-V software
because users needs to know which software really works, and
which doesn't.

  In the results of my fourth test of InVircible, I have included
the following.

  a. The exact reports that InVircible's modules displayed when
detecting viruses, or not detecting the viruses active in RAM.

  b. The CARO (Computer Anti-virus Research Organization) name
for the viruses used in the test for identification purposes.

  c. I list the 32 bit CRCs of the archive I tested.

  All of my facts and data are on the table, and anyone wishing
to duplicate my test is welcome to do so.

			      W.H. (Bill Lambdin


	       Bill Lambdin's Fourth test of IV.

	   InVircible 6.10c tested February 13, 1996

  This is my fourth  test of InVircible called IV. later in this
document Unfortunately; IV has failed again. Pay close attention
to the results dealing with Jerusalem.antiscan, Lehigh,
Pinky.952, and Tremor.

  IV combines a combination of a virus scanner (IVscan), and
generic A-V routines (IVB, IVINIT, IVTEST, and others. After
testing, I am unable to recommend IV as either a scanner, or
Generic A-V software in good conscience because of security
flaws.

  I will NOT recommeend IV until passes my test. I do not
recommend A-V software lightly..

    Some insisted this report contain everything I did. If
    you find this too boring. Please skim down to the
    section "VIRUSES USED", then read this boring part later.

  This test was performed on a 33 MHZ 486 computer with 4 MEG of
RAM.  and a 170 MEG IDE hard drive. See FINAL COMMENTS below.

  I started by performing the following tasks.

    a. backing up the hard drive.

    b. Preparing a bootable diskette with the necessary programs

    I would need during this test.


  c. Placed the viruses to be used during the test on a second
diskette

  d. placed bait files to be used during this test on a third
diskette.

  e. formatted the hard drive with a minimum DOS 6.2 on the hard
drive.

  f. wrote minimum CONFIG.SYS. and AUTOEXEC.BAT files.

	  CONFIG.SYS

	  FILES=30
	  BUFFERS=30

	  AUTOEXEC.BAT

	  PATH=C:\

  I run this test on this type of a system because there is less
to clean up, and save a lot of time..


  g. Install InVircible 6.10C to the hard drive.

  h. copied bait files to the hard drive.

  i. Had IV prepare the ResQdisk for the system I was testing IV
on.

  IV complained SYS.COM was not present in the path. I rebooted
from a system diskette and copied SYS.COM to the hard drive. then
rebooted from the hard drive and had IV prepare the Rescue
diskette.

  j. archived the files on the hard drive to a diskette. This is
a backup so I could restore the files on the hard drive quickly.

  k. Ran CHK-SAFE to calculate MD5 Hash values for the files
prior to infection so I could determine whether IV detected all
infected files, and repaired the files to the byte as IVB and
IVSCAN claim to do.


	       VIRUSES USED IN THE TEST.


     Cascade.1701.b.

	  This virus was selected because it is a simple
	  resident appending virus.

	  IVINIT.EXE reported

	       "WARNING! activity of a memory resident virus
	       detected!.

  After successfuly reporting this virus active in RAM. I booted
clean from the rescue diskette, and ran IVB to detect the
infected files.

	  (A clean boot is to turn off the computer. Insert a
	  bootable diskette in A: like the system diskette that
	  comes with DOS. Turn on the computer, and boot from
	  this diskette.)

  I Run IVB /R to remove the virus from the files. IVB reported
the infected files had been restored to their original status.

  I Calculated new MD5 Hash values for the files after infection,
& removal, then compared these hash values to the ones I had
prepared earlier. The Hash values matched.

	  Success



     Emmie.2823

  This virus was selected because it is a resident, and partialy
stealthed, appending infector of .COM files.  It doesn't modify
the entry point of files. The virus puts a JMP to it's body not
at the beginning of the file; but at the place where the initial
JMP at the beginning of the file points to.

	  IVINIT.EXE reported

	       "Warning! activity of a memory resident virus
	       detected"

  After successfuly reporting this virus active in RAM. I booted
clean from the rescue diskette. Ran IVB to detect infected files.
IVB correctly detected the infected file.

  I ran IVB /R to remove the virus from the infected files. IVB
reported the files had been restored to their original status.

  I Calculated new MD5 Hash values for the files, then compared
these to the hash values prepared prior to infection. The Hash
values matched.

	  Success



     Frodo.Frodo.A

	  This virus was selected because it is a resident,
	  appending, fully stealthed virus.
 
	  IVINIT.EXE reported

	       "Warning! a stealthy virus is active"

  After successfuly reporting this virus active in RAM. I booted
clean from the rescue diskette, and. Ran IVB from the rescue
diskette. IVB reported four infected files.

  I ran IVB /R to remove the virus. and IVB reported these four
files had been cleaned.

  I Calculated new  MD5 Hash values for the files, then compared
these to the hash values prepared prior to infection.  The Hash
values matched.

	  Success



     Jerusalem.Antiscan

  This virus was selected because it is a resident. COM and .EXE
file infector. It Prepends on .COM files and appends on .EXE
files.

	  IVINIT.EXE reported

	       "Activity of a memory resident virus detected"

  After successfuly reporting this virus active in RAM. I booted
clean from the rescue diskette. I ran IVB to detect the infected
files. IVB reported the infected files, and reported that IVINIT
grew in size by 1609 bytes.

  The IV modules are supposed to detect infection and repair
themselves if infected to prevent piggybacking.
     
  I ran IVB  /r, and IV reported the files had been restored to
their original status.


	  partial failure (because IVINIT.EXE was infected, and
	  did not report this infection or clean itself to
	  prevent piggybacking.)



     Lehigh.A

	  This virus was selected because it is a resident
	  infector of COMMAND.COM. The virus is written to a
	  cavity inside COMMAND.COM. There is no filesize
	  increase to COMMAND.COM.

     when running amother file after this virus was run; the system
     hangs.

     I re-boot the computer (from the hard drive).

     At Bootup IVINIT.EXE reported

  The COMSPEC data has changed. this might indicate an
infection."

	  "Do you accept the change? Please confirm! [Y/N]?


  After successfuly reporting this virus. I booted clean from the
rescue diskette. I ran IVB, and it reported "COMMAND.COM was
modified, not necessarily by a virus".

  I ran IVB /R to remove the virus. IVB reported "COMMAND.COM
changed in size by 0 bytes. COMMAND.COM is restored to it's
original status."

  I calculated new  MD5 Hash values for the files after
infection, & removal to the ones on file. The Hash values did not
match.

	  Before infection by Lehigh

COMMAND.COM     54619  09-30-93  06:20 
c98e0df201047722fec01cfda0db3ce0

	  After infection by Lehigh

COMMAND.COM     54619  09-30-93  06:20 
71612f0eea595e731c544185c1e6831b

	  Partial failure (on detection) IV did not properly
	  label this change to COMMAND.COM due to a virus.

	  failure (on removal) The virus was reportedly removed;
	  but the  file was NOT returned to the original
	  uninfected status. The "clean" file was a somewhat
	  corrupted file that should not be trusted.



     Pinky.952

  This virus was selected because it is a resident companion
infector.

	  IVINIT.EXE reported

	       "Warning! a companion virus to this program
	       was found!"


  After successfuly reporting a companion virus. I boot clean
from the rescue diskette. and run IVB. IVB mindlessly added file
signatures for the additional 952 byte .COM files, to the
integrity datafile and reported. "All file(s) match their
recorded signature(s)"

  IV reports companion infectors that use the same name of an IV
module. but disregards the othres.

	  Partial Failure.



     Tremor

	  This virus was selected because it is a resident,
	  appending, polymorphic, fully stealthed, and Tunneling
	  virus. This virus is in the wild.

	  IVINIT.EXE reported

	       "No virus activity detected in memory!"

	  IVTEST.EXE reported

	       "No virus activity detected at this time!"

	  IVB.EXE reported

	       "All file(s) match their recorded
	       signature(s)."

  Since none of these report anything (while Tremor was active in
RAM. the users would incorrectly assume there is no virus
activity while Tremor continued to infect their programs.

  Since IV's Modules were unable to detect Tremor active in RAM
or on infected files while Tremor is active. Users of IV are very
succeptable to this and other similar viruses.

  The only way IV  can find Tremor is to boot clean and run IVB
from the secured rescue diskette mentioned earlier. After I
booted clean. and IV was in a position to take control; IV found
Tremor easily.

     How are users supposed to know there is anything wrong, and
     know to boot clean from a secured diskette?

	  Failure.


		    FINAL COMMENTS.

    IVTEST runs bait files to entice viruses to infect them.

    There are seven problems with this.

  a. Not all viruses will infect the same bait files.  b. The
bait files are too small. 8 Tunes refuses to infect any files
smaller than 9216 bytes. Tremor refuses to infect any files
smaller than 10240 bytes, and there are other viruses that refuse
to infect anything smaller than 30720 bytes.  c.
Icelandic.saratoga only infects every 10th .EXE file run.  if the
.EXE file were appropriate for Icelandic.Saratoga to infect,
there is only a 1 in 10 chance of Saratoga infecting the bait
file.  d. These bait files still do not detect companion
infectors.  e. These bait files will not detect path companion
infectors.  f. IVtest can not detect non resident file infectors.
as demonstrated with the Trivial.45.A virus.  g. boot sector
viruses do not infect files.

  IV still doesn't detect Tremor in RAM or on infected files When
Tremor is active. Tremor hooks INT 21h, and steals 4228 bytes of
RAM.

  IVB still doesn't detect many companion infectors.

  IVB doesn't detect path companion infectors.

  IVB still doesn't check the entire file, but only gathers a
small signature from file areas likely to be modified by a virus.
This is flawed technology at best; and does fail to detect
several types of viruses.

  IVB Still doesn't give the users an option to check the
integrity of all files. Many viruses also infect files regardless
of extension as they are loaded and executed with DOS function
call 4Bh when accessed through INT 21h. Two good examples of
executable files with non executable extensions are the small
programs in Side Kick, and PC-Tools Desktop.

  IVB still places the integrity data files on the hard drive,
leaving them open to attack from viruses. There are several
viruses that delete integrity datafiles used by CPAV, MSAV, NAV,
NOVI, and others. Users can Rename the integrity Datafiles used
by IVB, and the hypertext online manual suggests for users to
rename the integrity datafiles. But a virus would only need to
check the filenames in directories, and when it encounters the
same filename in multiple directories, and delete these files.

  In my honest opininion: generic A-V software should use one of
the two options below.

  1. Place all integrity datafiles on a secure diskette.

  2. Place all integrity data in one data file, and allow users
to rename this integrity datafile.

  IVB still names all integrity data files the same. Any virus
could be modified to delete these integrity data files.

  If the integrity data files are corrupted or deleted, the
generic detection, and generic removal capabilities are rendered
non functional.

  If the integrity datafiles are deleted, IVB generates a new
integrity data file for the directory. I might add this new
integrity data file is generated AFTER infection. so IV can't
detect or remove the virus because IV doesn't have a file
signature that was generated before infection.


  I wish Zvi would close these security problems in IV. I have
been complaining about many of these same security problems since
version 5.07; thyat I tested in August 1994.

  For anyone wishing to duplicate any portion of this test; Here
are the contents of the archive tested.

- ----------------------------------------------------------------------
Searching ZIP: INVBFREE.ZIP

 Length  Method   Size  Ratio   Date    Time    CRC-32  Attr  Name
 ------  ------   ----- -----   ----    ----   -------- ----  ----
   3719  DeflatN   1524  60%  01-24-96  00:04  826edb7b --w-  AGENTS.LST
    548  DeflatN    368  33%  01-24-96  00:34  d4ff2a53 --w-  AVEXTRA.TXT
    548  DeflatN    368  33%  01-24-96  00:34  d4ff2a53 --w-  EXPIRY.TXT
    250  DeflatN    207  18%  01-24-96  00:32  fa3237da --w-  FILE_ID.DIZ
  14999  DeflatN  14560   3%  11-17-95  06:10  c19a8e1a --w-  FIND-SIG.EXE
   1421  DeflatN    698  51%  01-24-96  00:20  e4104d71 --w-  FIXBOOT.DOC
  16365  DeflatN  15878   3%  01-23-96  06:10  21c5cf52 --w-  FIXBOOT.EXE
  13468  DeflatN  13029   4%  11-17-95  06:10  ac6e0f9e --w-  GET-HD.EXE
  27156  DeflatN  10228  63%  11-17-95  11:52  7536c6ed --w-  HISTORY.TXT
  39400  DeflatN  38058   4%  01-01-96  06:10  c39b1331 --w-  INSTALL.EXE
  35729  DeflatN  34706   3%  01-01-96  06:10  16fe57d8 --w-  IV.EXE
   2608  DeflatN    415  85%  09-03-95  06:10  eb8bb52c --w-  IV.ICO
    545  DeflatN    159  71%  09-17-95  17:23  3bdda439 --w-  IV.PIF
  13691  DeflatN   5403  61%  01-24-96  00:17  59dffb10 --w-  IV4WIN95.TXT
  69090  DeflatN  68945   1%  01-24-96  00:07  fa6d6d9f --w-  IV4WIN95.ZIP
  39892  DeflatN  38653   4%  01-24-96  00:35  7f901cf7 --w-  IVB.EXE
    924  DeflatN    728  22%  01-01-96  14:50  95fa9116 --w-  IVB.NTZ
  22197  DeflatN  21591   3%  09-03-95  06:10  6baa5a14 --w-  IVHELP.EXE
  41676  DeflatN  21197  50%  11-17-95  11:45  a3c44ccb --w-  IVHELP.H!
  28572  DeflatN  27785   3%  01-01-96  06:10  5f717488 --w-  IVINIT.EXE
  18938  DeflatN  18385   3%  01-01-96  06:10  607086ea --w-  IVLOGIN.EXE
  91007  DeflatN  90907   1%  01-24-96  00:18  d40e8621 --w-  IVMANUAL.ZIP
  53118  DeflatN  51550   3%  01-01-96  06:10  fee1db81 --w-  IVSCAN.EXE
  21201  DeflatN  20615   3%  01-01-96  06:10  dc0656c4 --w-  IVTEST.EXE
  34292  DeflatN  33304   3%  01-01-96  06:10  0a6393e3 --w-  IVX.EXE
 167148  DeflatN  78309  54%  12-28-95  02:13  7db38f14 --w-  MANUAL.H!
   5678  DeflatN   5477   4%  11-17-95  06:10  e70ab8aa --w-  NOCMOS.EXE
   5527  DeflatN   2496  55%  10-02-95  21:07  cf6a54d6 --w-  README.1ST
   3349  DeflatN   1341  60%  01-24-96  00:16  09cb6c9b --w-  REGISTER.TXT
  40653  DeflatN  39406   4%  01-01-96  06:10  1f3f146d --w-  RESQDISK.EXE
   5259  DeflatN   2292  57%  10-25-95  17:57  59ab5b5d --w-  UPGRADE.TXT
   2386  DeflatN   1131  53%  11-17-95  12:10  d15a80b9 --w- 
WHATSNEW.10C
 ------          ------  ---                                  -------
 821354          659713  20%                                       32
- ----------------------------------------------------------------------


		      GLOSSARY

  Appending: These viruses are tacked onto the end of the file
and modify a .JMP instruction at the beginning of the file
that runs the virus, then returns to the host file.

  Bait files: These are small do nothing programs that attempt to
entice viruses to infect them.

  Boot Sector Virus: These viruses infect the boot sector of
diskettes, and the Master Boot Record, or boot sector of hard
drives.

  Cavity virus: This is an area in files where there will be a
series of bytes. 00, 20, 90 etc This usually represents an
internal buffer for the program.

  Companion Infectors: These viruses generaly create small .COM
files with the same name of an .EXE files (These .COM files are
placed in the same directory). If you do not specify an
extension, DOS tries to load a .COM file with the same filename
first. The .COM file contains the virus with a link to run the
.EXE file after the virus has run.

  Data file: These are small files (created by A-V software) that
contain information about the files on the computer, and other
data about the file.

  Fully stealthed File infectors: The virus will temporarily
disinfect infected host files when the infected host files are
opened for any reason, then reinfect the file when the file is
closed.

  Overwriting Virus: These viruses overwrite the beginning of
.COM files generaly (trivial.vootie.66.a overwrites the beginning
of all files in the currect directory). The host file is
corrupted and will no longer run.

  Path Companion Infectors: PATH companions do not rely on the
existence of an EXE file and do not necessarily put their body in
a file with a COM extension. They just copy themselves in a
directory which is listed earlier in the PATH than the directory
of the attacked file - and copy themselves in a file with the
same name as the name of the attacked file; the extension doesn't
matter.

  Polymorph: The virus mutates on every infection, so the virus
never looks the same twice. A simple scan string to detect the
virus is useless.

  Prepending: A prepending virus is a virus which inserts itself
at the beginning of the file, shifting the original file
backwards.

     Resident: Hook Interrupts and remain active in RAM.

  Stealthed Boot sector viruses: These intercept the call to
access the MBR, then displays the uninfected copy of the MBR. An
example a stealthed Boot Sector Virus is NO-INT.

  Trojan: This is a program that appears to do something useful,
but is slyly doing something destructive.

  Tunneling: Tunneling is a technique used by viruses to bypass
resident software that monitors or attempts to stop disk access.

			   Bill Lambdin
====================================================================

		       From Woody's Desk

  Well, we got a bit bigger than I expected on this issue.  There are 
so many great articles and I was anxious to get back I couldn't resist 
packing the issue full. Future issues will be smaller I am sure.

  My sincere thanks to Rob Slade, Jim Kuo, Wolfgang Stiller, Mikko
Hypponen, Nick Fitzgerald, and  Bill Lambdin for their contributions 
to both this issue and the Homepage.  I would also like to thank 
Richard Calhoune (owner of Micro Sourse, Gulfport, Ms.) and his 
staff ,  Jeff MaGee and Rob Tiley for their help and donations in getting 
The Scanner Homepage set up and running.  Visit the Homepage and see what
it has to offer.  The address is:

	      http://diversicomm.com/scanner

   [ A word of warning, it is best viewed via Netscape. ]

  If you have any questions or wish to contribute to The Scanner just
send me a message at the following address:

		   Woody@diversicomm.com  
			 or
		   SNCR@aol.com
			 or

	   Visit the page and leave me a note there.


   Until next time, keep those AV programs busy.

			Woody

