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

     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     HRRWood@aol.com
                            Howard.Wood@Flagship.org   

    The Scanner is now available on the following FTP sites:

       FTP: informatik.uni-hamburg.de
       DIR:  /pub/virus/texts/scanner/
       ( Thanks to Vesselin V. Bontchev's assistance and time )

       FTP:  OAK.oakland.edu
       DIR:    SimTel/msdos/virus/SNR9501.ZIP
       ( Thanks to Wolfgang Stiller's assistance and time )

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




                                  Woody  



                           Contents
                               
                               
In This Issue ................................. Howard Wood
Retroviruses Part II  ......................... Mikko Hypponen
Viruethics .................................... Rob Slade

AV Around The World
     Argentina       ......................... 
         Avispa Virus ......................... Ruben Aries
     France          .........................  Gerard Mannig
     Spain           .........................
        The Virus situation in Spain .........  Mario Elkati

In The News           ......................... Howard Wood
The BookShelf         ......................... Rob Slade

                           Reviewing
IBM Dictionary of Computing ...............  George McDaniel 
Aether Madness    ................  Gary Wold and Michael Stein    

The Editors Review  ........................... Howard Wood
                           Reviewing
Rob Slade's Guide to Computer Viruses   ....... Rob Slade

Hacks, Viruses and Trojans .................... Howard Wood
Virus Spotlight   ............................. Howard Wood
                    This months bug EXEBUG
    About Exebug  ............................. Henri Delger
  Removing EXEBUG ............................. Howard Wood

The Green Catepillar  ......................... Bill Lambdin
From Woody's Desk ............................. Howard Wood




























                         In This Issue
                               

     Well here it is April already.  Halfway through April to be
exact and I am behind the power curve.  This is being released
later than I had hope it would be due to exams in college.  Ah
yes, the sacrifices for a better education. :-)

     This issue has some new articles and writers that I hope you
will enjoy.  Mikko Hypponen's second and final part to his
RETROVIRUSES paper is just as informative as the first part was. 
Rob Slade addresses a subject of great debate and we would like to
hear from you folks on Virus ethics.  What are your views on the
subject?  Read Rob Slade's Guide to Computer Viruses?  Well I did
and I tell you all about it in this issue.

     We "SPOTLIGHT" EXEBUG in this issue.  A nasty little critter
to say the least.  If you are an Integrity Master user or an F-
Prot user you won't want to miss the pointers on using them
against EXEBUG. 

     Hope you enjoy the issue.  Please keep those messages coming
in on what you think of The Scanner.  With the input I can keep up
with what you folks want to see in it.

     Keep those AV programs busy !!!!!

                     Woody


































                           VIRETHIC
                                
             Viral Morality: A Call for Discussion
                               
 
"Computer ethics" has been an ongoing study in the technical
world.  On the one hand is the study of the ethical, moral, or
proper use of computers.  On the other, is the study of computer
crime and vandalism.  Lately, I have noted a rather desperate
interest in courses or training in computer ethics, as well as an
increase in the frequency and depth of discussions regarding 
the ethics of virus writing.  I would like to address this latter
topic, specifically.
 
One problem with current discussions and literature regarding the
ethics of virus writing and distribution is the lack of dialogue
between two opposing camps.  This paper is not intended to present
any final answer, nor to add to the literature in the field, but
to open the field for comment.  My purpose in writing this is to
provide an initial overview and to elicit feedback from any and
all concerned with the topic.
 
For those of traditional moral stance, the current situation is
discouraging.

Peter Denning's "Computers Under Attack" (cf. BKDENING.RVW) has a
very thorough survey of the field, but it provides little in the
way of answers or hope. Deborah Johnson's work "Computer Ethics"
(cf. BKCMPETH.RVW) is pre-eminent in the field, but serves only to
clarify the problem.  Sarah Gordon's interviews with computer
students show responses typical of almost all such studies.  The
base attitude appears to be, "If I find it interesting, and I can
do it, why do you say I shouldn't?"
 
The proponents of security-breaking activities often question the
traditional ethical position by asking, "Where's the harm?"  This
query is directly relevant to discussions of the morality of virus
writing.
 
I should begin by defining two generally opposed groups in this
area.  First is the "antivirus", or "AV", research community. 
Many, though not all, of the members of this group would be
involved in producing antiviral software.  All would study viral
programs with a view to eliminating viral programs in the normal
computing environment.  They take a rather paranoid, and almost
obsessive, position with regard to the sharing and distribution of
viral code. (They would rejoin this last by pointing out that it
isn't paranoia if someone is *really* out to get you.)
 
The AV community is not really opposed to the writing of viral
programs.  It is seen as a trivial, and therefore pointless,
exercise; but not necessarily evil, in itself.  The communication
of viral program code is also a normal professional and academic
activity, as long as it is limited, done for a stated purpose, and
the recipients are known.  It is the unregulated exchange of virus
code and source, providing open access to anyone with a computer
and a modem, that is upsetting.  The opposing group is therefore
described as the virus exchange community, or "vx" for short. 
(This designation was first used by Sarah Gordon.)  For the
purposes of this paper, therefore, references to "virus writing",
"virus exchange" or "vx" will mean the uncontrolled or 
unregulated exchange or provision of access to virus source and
object code.
 
(This does not necessarily mean deliberate distribution of
infected programs by such means as infecting a legitimate program
and then posting it, without warning, to a bulletin board system. 
"Trojanizing" of normal software or malicious invasion of systems
is certainly happening in some areas, but it is not needed in the
current computing situation.  While there is debate over the
relative contribution of "natural spread" and virus exchange to
the current virus problem, it is known that code made available
only as openly published material does eventually infect machines
in the normal computing environment.

The term vx does not, therefore, require any imputation of
sinister motives or hidden activity for the purposes of this
discussion.)
 
There are some grey areas between these two poles.  Some people
have both written antiviral software *and* contributed to viral
spread.  Given, however, that one could expect a continuum of
opinion, those in the middle are remarkably few.  Either you are
for virus exchange, or against it.
 
One other, separate, group should be noted.  Viral programs are
often cited as an example of "artificial life", and the research
community in that field, both professional and amateur, have a
legitimate interest in viral programming. Work in the a-life
field, however, does not justify unregulated code and source
exchange.  For one thing, current viral programs "in the 
wild" (those which are to be found in normal home and business
computers, as opposed to those which exist only in a research or
laboratory environment) have only the most tenuous claim to
artificial life.  Common viral programs are simplistic snippets of
code without anything like the complexity of the simplest known
natural life forms.  In addition, those who really do work in 
the artificial life area will be well aware that it does carry
possible dangers, and that research should be subject to controls
similar to those imposed on biological and genetic study.
 
The most common argument for virus-writing tends to boil down to,
"You can't stop me."  Many promote virus writing on the grounds of
freedom of speech, a rather curious position in light of the
incoherence of the arguments.  (The most vocal of these tend to be
Americans, who frequently cite "First Amendment Rights".  This
refers to the first amendment to the U.S. Constitution, which
Americans tend to see as some universal law, rather than 
an arbitrary political document, however desirable.)
 
Rights, though, carry with them a weight of responsibility.  As is
often quoted, your "right" to swing your fist ceases at the end of
my nose.  You have a "right" to free speech--so long as you are
responsible and do not perpetrate fraud.  You have a "right" to
study whatever you like--so long  as you are responsible enough
not to carry out experiments in poison with human subjects. 

No PC is an island--at least, not where viral programs are
concerned. Therefore, your "right" to study, write and distribute
viral programs carries the responsibility to ensure that your
creations do not--ever--run on machines where they are not
authorized.
 
One of the most confusing aspects of the "exchange/no exchange"
debate is the concept of the "good" virus.  There is nothing
inherently evil in the concept of reproduction.  (Dangerous, yes.) 
In fact, the very earliest experiment with self-reproducing
programs was the Xerox Worm of Shoch and Hupp.  This was designed
to spawn "segments" of the central program on other machines in 
the network, thus bringing the power of many processors to bear on
a single problem.  Thus, in theory, viral programming could
represent the same level of advanced technology in software that
parallel processing represents in hardware.
 
That's the theory.  And it is promoted by no less eminent a
researcher than Dr. Fred Cohen, who did seminal work on the
security-breaking class of viral programs in a thesis, in 1984,
and dissertation, in 1986.  Unfortunately, the theory founders on
some rather hard facts.
 
There are three questions to ask of a new, inherently dangerous,
technology. Has it a useful application?  Can it fulfil that
application better than current technologies?  And, can the
danger, either inherently, or effectively, be controlled?
 
To date, no one has answered those three questions.  While a
variety of uses have been proposed for viral programs, there are
none which are not effectively being done by other means.  No
viral programs have, indeed, been seen to be as effective as
normal systems.  Operating system upgrades could not guarantee
universal coverage.  Network management tasks could not promise 
reliable feedback.  Automated utilities would confuse novice level
users, who never run utilities anyway.  The most useful function
is still that proposed by Shoch and Hupp--and their programs were
not, strictly speaking, viral.
 
(Vesselin Bontchev's examination of this question is the most
detailed to date, and is required reading for all who want to join
the debate.  His proposals,while demonstrating good ideas for
safety and control, are still primarily an advanced automated
distribution system.  The necessity for viral functions in this
regard is still unproven.)
 
Those in the vx camp will point to two current viral programs
which, they say,do have useful functions.  One of these programs
produces compressed executable files, thus saving disk space,
while the other performs encryption on files. However, both of
these functions are provided by other programs--from which,
indeed, code was stolen for those two "good" virals.  Neither of
the viral programs are as easy to use or control as the original
programs, and both have bugs which must place them firmly in the
malware grouping, for nuisance value, if nothing else.
 
Currently, therefore, the utility of viral programs is very much
unproven. This would, though, mean only that they are neutral,
were it not for the lack of any demonstrable control.  Methods of
control have been discussed primarily by Fred Cohen, but even he
remains unconvincing.  The mechanisms generally are limited to
environmental checks which can either fail, or be easily cut out
of the program.  Some have proposed "hunter" virals, to go 
after programs which "turn rogue", but a program which is
corrupted will behave in unpredictable ways and a hunter program
would likely consume a lot of resources, fail, or (most likely)
both.
 
(Cohen frequently cites viral "programs which have been running
since 1986 with no ill effects" and speaks of a VCE (viral
computing environment).  There are two points to be noted here. 
One is that Cohen has not yet described his viral programs in
anything like the detail he put into his earlier work, so there
can be no independent assessment of his claims.  The second point
is that the very term, VCE, implies that a viral computing 
environment is substantially different, and should be kept
separate, from the "normal" computing environment as it is
currently known.  A VCE may very well be a powerful entity, but it
is still an unknown and unproven concept.)
 
Computer viral programs have an inherent danger:  that of
reproduction and spread.  If you study explosives, and pass along
that knowledge, you also have to pass along the materials before
there is any risk of a blast.  Even then,the materials do not
multiply themselves:  when exhausted, another supply must be
found.  The same is *not* true of viral programs.  These entities
are *designed* to reproduce.  And, unlike the study of dangerous 
animals, or even germ warfare, viral programs are built to
reproduce, multiply and spread without the aid of a skilled, or
even aware, operator.  If you are careless with a deadly animal or
weapon, it is still only a single danger in a localized area.  If
you are careless with a computer virus, it can spread world-wide.
 
We do not use computers because they are smart.  Computers
*aren't* smart. Sometimes we use them because they can do
calculations very quickly, but even this is only a special case of
the real value of computers.  Computers always do the same thing
in the same way.  They are repeatable.  They are, in this manner,
reliable.  Even a computer error can be useful to us--so long as
it always happens the same way.
 
Consider, then, the computer virus.  In order to reproduce without
the informed assistance of the user, the virus must be, in the
computer sense, transparent. It must operate without alerting the
operator, or interfering with the operator's interaction with the
computer.  If the virus even posts a notice ("Hi! I am infecting
object X!"), it has a nuisance value and is, therefore,not good. 
(Vesselin Bontchev notes that even such a notice, by possibly
delaying a process, may have grave consequences far beyond 
annoyance.)
 
If, however, the virus does *not* notify the operator, then the
operator is not aware of some additional code in the machine. 
This extra code will have an unknown, and inherently unknowable,
effect on the computer.  The operations of the computer are,
therefore, no longer repeatable.  This is a Bad Thing (TM).
 
Some will protest that I have overblown the danger of both the
notification messages and the possibility of conflicts.  The point
that I am trying to make is that you cannot predict the harm which
may arise from interference either with the operator or the
programs.  Software is digital, and is subject to catastrophic
collapse without prior warning.  For those without a background in
computer risk assessment, an excellent overview for the
non-professional is found in Lauren Wiener's "Digital Woes" 
(cf. BKDGTLWO.RVW).  An intriguing compilation of the types of
things that can go wrong is to be found in Peter Neumann's
"Computer Related Risks" (cf. BKCMRLRS.RVW).  At the very least,
as Sarah Gordon points out, the virus is an autonomous agent,
making decisions and carrying out activities according to it's own
internal constructs and the intention of its programmer.  This is
very likely not in correspondence with your own intention, and is 
therefore an invasion of privacy.
 
A number of virus writers will object that their creations simply
are not harmful.  Not only is it impossible to guarantee that your
virus will not conflict with existing systems, you also cannot
guarantee that a given system will not conflict with your virus. 
Almost all file infecting viral programs will interfere with
applications which have an internal integrity checksum or
a non-standard loader, and will cause those applications to fail. 
(An example of this is that Windows programs infected with DOS
viral programs always fail to load.)  The "Ohio" virus (a prior
version of Den Zuk) was not intended to carry any destructive
payload, but an unusual interaction with a certain network
operating system caused fatal disk corruption.  Since both Ohio
and Den Zuk are examples of the often proposed "virus hunter
virus", it should be clear that the concept of using a viral
program to hunt down and disinfect other viral programs is not a
good one.
 
Historically, and statistically, virus exchange people have been
careless and incompetent programmers.  Remember that we are
talking vx, here, and those viral programs which have been
released into the wild.  There may be, carefully hidden in the
desk of a virus writer, the "perfect" and harmless virus.  If
so, we haven't seen it yet.  The majority have obvious bugs,
sloppy coding and derivative programming.  Less than one percent
are interesting for *any* reason; only a handful have unique
styles of algorithms.  And even these last have programming
pathologies.
 
There are two other reasons often given to justify virus exchange. 
The first is generally described as experimentation and education. 
The second is described as antiviral research, or, more commonly,
assessment of antiviral programs.  These arguments *do* have some
validity, and should be examined. Ultimately, though, the reality
fails to support the claim.
 
The call for experimentation is somewhat tied to the argument for
a "good" virus.  Current viral technology may be crude and
ridiculous, but how can it be improved if there isn't any work or
sharing of results?  Quite true.  The vx community, however, have
obviously not read or noted any programming journals or texts. 
Discussions of programming and algorithms are supported by well-
annotated code fragments.  You don't present a whole program to
discuss a specific function any more than you send an entire car
with a manual on auto repair.  You certainly don't use encoded or
"DEBUG script" object code:  that has no explanatory value at all.
 
And I have yet to see, in the vx materials, any discussion of
legitimate and positive uses for viral technology, any discussion
of control technology, or any discussion directed at ensuring that
viral programs do not create conflicts.
 
In regard to education, it is true that a study of viral programs
is related to a knowledge of operating system internals, as well
as assembly language programming.  However, viral study *requires*
such knowledge, rather than providing it.  Giving someone a virus
and expecting them to learn from it is akin to "teaching" a
surgeon by handing him a scalpel and pointing at a patient.  Even
the vx "old guard" are beginning to realize this.  Viral programs
use normal computer functions.  If you understand computers, a
virus is trivial.  If you don't, well ...
 
As far as virus exchange tutorials go, well, let me put it this
way.  I am a teacher.  Many of you will also know that I review
technical books on a daily basis.  Some are great, enough are
good, many are bad and some are just plain awful.  Only a few are
worse, in terms of tutorial effectiveness, than vx "zines"
(electronic periodicals).
 
Recently, someone who makes his living pushing virus source code
promoted a collection of viral programs by suggesting you could
test antiviral programs with it.  This, superficially, sounds like
a good idea--if you don't know what *real* software testing is
like.  What do we know about the quality of this "zoo" (set of
virus samples)?  What do we know about the structure,
organization, documentation and so forth?  How many duplicates are
there?  Of course, we *do* want duplicates in some cases; we want
every possible variation on polymorphs.  (For Tremor, that works
out to almost six billion files.) But then, this collection was on
a CD-ROM.  What a pity.  The most successful viral programs are
boot sector infectors, and you need to have real, infected disks
to truly test for them.  At a minimum, you'd want all seven
"common" disk formats, in both system and non-system versions. 
That's fourteen disks--for *each* BSI.
 
For all the length of this piece, it is still only an overview. 
And, for all it's length, it probably hasn't convinced anyone. 
Ethics education (it used to be called "values education"), in
whatever form and however presented, has very little to show that
it works.  There are various theories and models of moral
training, the most sophisticated probably being Lawrence
Kohlberg's "Moral Development" schema.  All, though, basically
boil down to sitting around talking about ethical dilemmas.  They
may develop debating skills and rhetorical sophistry, but there is
no evidence to suggest that any of these programs leads to any
significant change in behaviour.
 
While Kohlberg's model of moral development has the most detailed
construction,its utility is questionable.  His system is not so
much one of values education as of values measurement.  It is,
therefore, a guideline for evaluating other ethical training
methods rather than a means of instruction and change. Moral
development is a six stage structure, assessing the type of 
reasoning which goes into ethical choices.  The stages range from
"fear of punishment" to "internal ethical principles".  There is
great difficulty, however, in determining the "stage" of a given
individual.  Most ethical discussions will be judged as having
reasoning at all of stages three, four and five.  This entire
document, for example, could be dismissed as being level one
reasoning since it mentions the possibility of the danger of virus 
distribution and could therefore be seen as a "fear of punishment"
(negative consequences) on my part. 

On the other hand, most of Kohlberg's proponents dismiss level
six, since even a psychopath could be said to be acting from
internal principles.  
Kohlberg,himself, has stated that he does not know if anyone
consistently acts from stage six reasoning.
 
Probably the major reason for this is that modern society has no
fundamental moral foundation.  The most widely cited (and Johnson
gives an excellent critique of it) is utilitarianism--"the
greatest good for the greatest number". 

Leaving aside the difficulties of assessing such a measure,
utilitarianism, along with all the other modern "humanistic"
philosophies, has nothing to support itself.  Why is "the greatest
good for the greatest number" to be chosen over "what *I* want"? 
An alternative is deontology; ethical principles derived from the
concept of duty.  (Ironically, this philosophy, while arguably
superior to utilitarianism, is limited to Kohlberg's stage four
almost by definition.)  Again, however, there is no underpinning
to the concept of duty,itself.
 
Ironically, the much maligned "Judeo-Christian Ethic" did have
such a foundation for moral standards--God.  The theistic universe
may yet have the last laugh over the mechanical universe of B. F.
Skinner's "Beyond Freedom and Dignity".  Maybe Jesus *is* the
answer--or there may be no answer.
 
Bibliography
 
Bontchev, "Are `Good' Viruses Still a Bad Idea?", Proceedings of
the EICAR '94
Conference, pp.25-47, also
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/goodvi
r.zip
 
Clarkson, "Windows Hothouse", 1994, 0-201-62669-1, U$34.95/C$44.95
- lots of artificial life fun with Visual C++
 
Cohen, "It's Alive!", 1994, 0-471-00860-5, U$39.95 - an
intriguing, provoking and practical exploration of computer
programs as "artificial life", but somewhat narrow
 
Denning, ed., "Computers Under Attack", 1990, 0-201-53067-8 -
collection of essays roughly related to security, also "the net"
 
Ermann/Williams/Gutierrez, "Computers, ethics and society" -
textbook for computer ethics course: not great
 
Gordon, "Technologically Enabled Crime", 1994
 
Forester/Morrison, "Computer Ethics", 1994, 0-262-56073-9 - lots
of great stories, but short on analytical depth
 
Johnson, "Computer Ethics", 1994, 0-13-290339-3 - the basic work
in the field, thorough coverage and good discussion starter
 
Levy, "Artificial Life", 1992, 0-679-73489-8, U$13.00/C$17.00 - an
interesting wander through fields studying artificial life but no
strong points 
 
Neumann, "Computer-Related Risks", 1994, 0-201-55805-X, U$24.75 -
exhaustive examples from the RISKS-FORUM Digest of potential
technological perils
 
Slade, "Robert Slade's Guide to Computer Viruses", 1994,
0-387-94311-0/3-540-94311-0, U$29.95 - chapter seven looks at the
computer virus and society
 
Thro, "Artificial Life Explorer's Kit", 1993, 0-672-30301-9,
U$24.95/C$31.95
-
good fun, but little analysis
 
Wiener, "Digital Woes", 1993, 0-201-62609-8, U$22.95/C$29.95 -
excellent introduction to the risks of software
 
(A fuller bibliography on values education readings is available
for those demonstrating a willingness to put some effort into it,
since, frankly, it's a really disappointing field.  Sarah Gordon's
"Generic Virus Writer" paper has significant resources here.)

copyright Robert M. Slade, 1995
Permission is granted to post this file, in full, on any system.

======================
DECUS Canada Communications, Desktop, Education and Security group
newsletters Editor and/or reviewer ROBERTS@decus.ca,
RSlade@sfu.ca, Rob Slade at 1:153/733 
Author "Robert Slade's Guide to Computer Viruses" (US contact
1-800-SPRINGER)


                                ****               


RETROVIRUSES - How Viruses Fight Back, part 2
---------------------------------------------

Mikko Hypponen, who works in Data Fellows Ltd's F-PROT-
support, presented the following paper in the Virus Bulletin 
'94 conference. The treatise is published in two parts. The
first part was published in F-PROT 2.15 Update Bulletin.

6. Attacks against disinfectors

A retrovirus can attack programs that try to disinfect boot 
sectors and files. The purpose of such an attack might be to 
cause the disinfector to damage the host files while 
disinfecting. If a disinfection program does not do an exact 
identification on a virus before disinfecting it, any virus 
that contains a known search string for another virus can 
cause such damage during the disinfection process.

6.1 Cleaning the clean

There even exists a virus called Mirror, which is the exact 
opposite of a stealth-virus: when Mirror is resident in 
memory, it makes all programs look like they have been 
infected by it. This can be potentially dangerous when 
disinfection is attempted, but this technique poses no 
danger if the disinfection is done in a proper way, ie. 
after a clean boot.

6.2 Complicating the recovery

The recovery process of an infected machine can be severely 
complicated if the virus denies access to the hard drive. 
Several MBR-viruses (for example, members of the Monkey 
family) do this by modifying the partition data in such a 
way that no logical DOS drives can be found when the machine 
is booted from a clean floppy. A recovery attempt done by 
overwriting the MBR code with the FDISK /MBR or a similar 
command will not return access to the hard drive. 

The ExeBug virus family uses another way to make it 
difficult to boot up an infected machine from a clean 
diskette. The virus modifies the BIOS Setup information to 
indicate that the machine does not have A: drive at all. 
Such machine will always boot up from the hard drive. Once 
the booting has started and the virus code is executed, the 
virus will check if there is a diskette in drive A:. If so, 
it will continue the booting from there. In most cases the 
user is unable to notice this, and thinks that the machine 
has been booted clean when the virus is already resident.

Yet another way to complicate the recovery process is to set 
the BIOS boot-up password on with a random password during 
an activation routine. The method of doing this is 
documented on most new BIOS brands.

Some integrity checkers are capable of performing a generic 
disinfection. This means that they try to restore the 
original file according to the information the checker has 
previously saved (typically length, checksum, first and last 
bytes). Such generic routines won't work if a virus makes 
extensive changes to the program files, for example by 
encrypting the host file during infection.

6.3 Attacking heuristic cleaners

Viruses use a different kind of an attack against heuristic 
disinfection programs. A heuristic cleaner works by loading 
the infected file to memory and emulating the program code. 
It uses a combination of disassembly, emulation and 
sometimes execution to trace the flow of the virus and to 
emulate what the virus is normally doing. When the virus 
restores the original first instructions of the host file 
and jumps back to the original entry point, the cleaner 
stops the emulation. The repaired start of the program is 
copied back to the program file on disk, and the part of the 
program that was 'executed' will be removed. [Veldman]

The inherent risk of heuristic cleaning is that if the 
cleaner tries to emulate everything, the virus may assume 
control inside the emulated environment and finally escape 
from it - after which it can propagate further or trigger a 
destructive retaliation routine. There are documented cases 
of at least one virus doing this, see below.

7. Attacks against integrity checkers

The operation of integrity checking programs varies between 
vendors but they almost always rely upon some form of a 
database which contains details of objects (typically files 
and boot sectors)  to be checked. 

7.1 Deleting the database

Several viruses have attacked integrity checkers by locating 
the integrity database and deleting it. In some cases, the 
result of deleting the database files is that the integrity 
checker will blindly assume that the original checksums have 
not been calculated yet, and proceeds to initialise the 
database without informing the user that something might be 
amiss. This was exactly the case with the Peach virus.

Peach attacked an integrity checker which worked by creating 
a checksum file,  containing checksums of all executable 
programs. Peach attacked by deleting this file. After the 
database was deleted and the checker was executed again, it 
recreated the file, calculating new checksums from the 
infected files and failing to report any changes in the 
system [VB1].

It should be noted that the Peach virus will not be 
successful against newer versions of this integrity checker, 
as the name of the checksum file has been changed in newer 
versions of the product. Similar types of attack still seem 
to be possible, though.

Even if a checksumming package did report to the user that 
the database has been deleted without approval, it would be 
difficult to find the affected files if no recent backup of 
the database exists.

7.2 Making checked unchecked

A similar attack works also against programs that do not 
store the integrity data in a separate database, but add it 
to the end of the executable files themselves. Since there 
is no info about which files have been checksummed, a virus 
can just remove the validation data without any side effects 
- and the checker will not complain that the file has 
changed.

Several generic attack methods against integrity checkers 
are discussed in length in [Bontchev].

8. Real world retroviruses

When we look at viruses that attack specific anti-virus 
products directly, we notice that they mostly seem to target 
McAfee Associate's ViruScan (SCAN.EXE), Microsoft Anti-virus 
from MS-DOS 6 (MSAV.EXE), Central Point Antivirus (CPAV.EXE) 
and the resident parts of these applications (VSHIELD and 
VSAFE). This is not surprising, as these are some of the 
most popular anti-virus products, and thus good targets for 
retroviruses.

Here are some examples of known viruses that incorporate 
retro-routines:

CPW virus family:
     tries to delete programs called TOOLKIT, GUARD, CHKVIRUS, 
     SCAN, CLEAN, CPAV and VSAFE

     deletes CHKLIST.CPS files created by CPAV

Cybertech:
     deletes CHKLIST.CPS files

     removes the validation information added by SCAN and CPAV

Firefly:
     uninstalls VSAFE from CPAV or MSAV

     contains a segment of nested loops to confuse F-PROT's 
     heuristic scanning

     deletes files called IM, VIRX, PCRX, VIRSTOP, MSAV, NAV, 
     SCAN, CLEAN, TBAV, TBCSCAN, TBCLEAN, TBCHECK, TBMEM,
     TBSCANX, TBFILE, VC, and VCHECK

GoldBug:
     by-passes VSAFE.COM and DISKMON.EXE

     deletes or stops the execution of programs called SCAN, 
     CLEAN, NETSCAN, CPAV, MSAV, TNTAV - and deletes the
     contents of CMOS memory at the same time

     specifically by-passes the TBAV boot-sector check

     deletes CHKLIST.* files, by-passing CPAV and MSAV 

Lemming:
     disables TBDriver from TBAV by patching it in memory

     when TBScan is executed, adds the command-line parameter 
     'co', which will allow the stealth routines of the virus
     to operate

     patches text strings inside TBScan's code to make the 
     operation of the program look like it has been started
     without the 'co' switch

Lockjaw virus family:
     deletes F-PROT, SCAN, IM, CPAV

     uninstalls VSAFE

MtE.Groove and MtE.Encroacher:
     tries to delete files belonging to the following products: 
     Central Point Anti-Virus, Certus Novi, Fifth Generation
     Systems Untouchable, Norton Anti-Virus, Dr. Solomon's
     Antivirus Toolkit and VDS Virus Secure.

November_17th.890:
     overwrites the first 256 sectors of first hard disk 
     whenever SCAN is run

Peach:
     deletes CHKLIST.CPS files

Sandra:
     tries to delete files belonging to CPAV, NAV, Untouchable, 
     Dr. Solomon's Antivirus Toolkit and Integrity Master

     will not infect if FluShot is installed

Satanbug:
     tries to remove the validation codes added by SCAN

     guards its own are-you-there interrupt call to make it 
     difficult to detect the virus in memory with it [CM-Base]

Tequila:
     deletes files that have validation codes added by SCAN

     does not infect EXE-files which have the letters SC or V 
     in their names

Tremor:
     hooks INT 13h via a VSAFE back-door

     modifies its own memory allocation when F-PROT is executed 
     [VB2]

Varicella:
     tries to escape and go resident during the cleaning 
     process of TBClean

9. Is there a real problem with retroviruses?

Do retroviruses pose a realistic threat to current anti-
virus products? The most popular anti-virus tool nowadays is 
a stand-alone scanner, which by itself is almost always 
helpless against any new virus. Are there any special risks 
in a virus that, in addition to being a new one, also 
specifically tries to by-pass a product? 

9.1 Dangers of optimised virus analysis systems

If a retrovirus exploits a specific flaw or the back door of 
a product, it cannot be considered a very special case, as 
the detection of a new virus requires usually an update to 
the product anyway. At the same time, it is possible to 
upgrade the product so that the attack method used by the 
virus can be circumvented or made obsolete.

The main problem in this case is whether the anti-virus 
vendor notices what the virus is trying to do. Today, when 
several new viruses are found every day, there is a limited 
time in which to analyse any single virus. Virus analysis 
systems are automated as much as possible, and a virus 
typically only gets a cursory look - which is usually enough 
to add detection, identification and disinfection. Such ana-
lysis will not reveal any special features the virus may 
contain. This also explains why there are no anti-virus 
products which can provide detailed information about each 
and every virus.

If a retrovirus is run through a standard analysis system, 
and the product is tested by running it against a sample 
that is not resident in memory, the retro-features of a 
virus may not become known until they are observed directly 
in the real world - after which the virus will certainly get 
more attention, but this might already be a bit too late. 
The virus may also start its attack behaviours only after a 
certain latency time.

9.2 Opening the door to other viruses

It should also be noted that a virus which disables an anti-
virus product in some way may also make the system 
vulnerable to other viruses, which the product might 
otherwise have handled fine.

In many cases this is the only benefit a retrovirus gains 
from unloading a resident scanner. The scanner can't be 
unloaded before it is resident. If the virus is known to the 
scanning engine, a resident scanner will not let the virus 
run. If the virus is unknown to the scanner, it can operate 
even when the scanner is resident. The case is different 
with behaviour blockers, as they are not trying to find 
known viruses.

There is very little a product can do against an attack 
which consists of deleting or replacing the program file 
itself - if the virus gets control before the anti-virus, 
the virus makes the rules.

10. How should an anti-virus product protect itself?

It is obvious that viruses can utilise a variety of tricks 
against anti-virus products. However, anti-virus programs 
can fight back just as efficiently.

10.1 Making the program difficult to locate

First of all, the anti-virus program itself should be 
renameable by the user. This alone would make it a lot 
harder for a virus to locate its enemy. Unfortunately, many 
anti-virus products refuse to run if they find that their 
program files have been renamed.

As the virus can try to locate the anti-virus program by its 
contents as well as by name, the structure or contents of 
the program file should change with each update.

The best way to make sure that no retrovirus is making its 
tricks is the old, well-known recipe: boot from a clean 
diskette and run a fresh copy of the anti-virus program from 
diskette.

10.2 Self-checks

Since many attack routines work by modifying an anti-virus 
program, it is imperative that all anti-virus programs make 
thorough checks on their own code. A cursory check against 
modifications that would result from an infection is not 
enough: if the code is not protected internally against 
patching, the integrity of the whole program code should be 
checked during start-up. 

It is not enough to ensure that the program code has not 
been changed. As demonstrated earlier in this paper, it is 
enough for a retrovirus to modify the texts or configuration 
info belonging to the application.

Even though the size of an anti-virus application probably 
changes during every update, a clever retro-virus can still 
locate the code it wants to patch by using a search string. 
This can be overcame by encrypting the application. The 
protection will be even better if the encryption method or 
key is changed with every update. Another, easier way to 
achieve the same results is to provide the executable in 
packed form, as the packing algorithm will invalidate search 
strings between different versions of the same program.

10.3 Resident security

Since it is often much easier to patch a program in memory 
rather than on disk, an anti-virus application should make 
checksum checks on its memory image to ensure that no 
unwanted changes have taken place. This is especially 
important with resident anti-virus utilities.

The communication channels to a resident part of an anti-
virus program should be carefully thought out. If the TSR 
needs to have an uninstallation routine, it should be 
implemented so that other programs will find it difficult to 
request the uninstallation without the user noticing it.

10.4 Prohibiting disassembly

It can be expected that determined virus writers will try to 
disassemble anti-virus products in order to find out what 
makes them tick. Thus, some anti-debug and armouring code to 
protect the application might be a good idea - although 
nothing will stop a dedicated cracker. 

At least three different scanners are known to have been 
analysed by crackers, up to the point of extracting all 
search strings of the program. Such attack can be harmful in 
several ways: the virus writers get to see exactly what they 
will have to change in a virus to make a new, undetectable 
variant, and well-chosen search strings are also closely 
guarded trade secrets.

Popular, easy-to-get programs are the most probable targets 
for attack routines. This makes commercial products 
theoretically more safe than shareware or freeware products.

11. Conclusions

Retroviruses are nothing new - the first ones were found in 
the late 1980's. There are several attack methods that will 
certainly be used in future viruses - and some of these can 
be quite efficient. Therefore, extreme care should be taken 
by producers of anti-virus software to avoid the possible 
pitfalls.

It's time to make sure your anti-virus product is not 
vulnerable to an attack it could avoid.

References

[CM-Base]    Virus Test Center, University of Hamburg, CM-Base
          v3.0, March 1994, Satanbug entry by Padgett Peterson

[Veldman]    Frans Veldman, Combating Viruses Heuristically,
          Proceedings, 3rd International Virus Bulletin
          Conference, September 1993, pp. 67-76

[Bontchev]   Vesselin Bontchev, Possible Virus Attacks Against
          Integrity Programs And How To Prevent Them,
          Proceedings, 2nd International Virus Bulletin
          Conference, September 1992, pp. 131-141

[VB1]        Virus Bulletin, Peach Virus Targets Central Point,
          Virus Bulletin May 1992, pp. 17-18

[VB2]        Virus Bulletin, Tremor - A Shaky Start for DOS 6?,
          Virus Bulletin March 1993, pp. 10-11

[Fellows]    Data Fellows Ltd, F-PROT Professional User Guide rev
          4.21

[Siilasmaa]  Risto Siilasmaa, Building a Corporate Security
          Strategy - Coping With Computer Viruses,
          Proceedings, Cope'IT Conference 1993



                              ***

                      AV Around the World
                               

Argentina:

Avispa Virus. The first aproach to polymorphic in Argentina ???
by Ruben Arias.


Some months ago (June 1994), my wife phoned me advising that the
person who usually gives her information about the statement of
our account in the bank, told her that the system in the bank was
halted by a virus attack.

(Between us, what a drain of information! No security at all.) 
Of course, She didn't have any info of our account this day.

A further call to the System Administrator of the bank reveals
that the Virus attack "knocked out" about 150 machines connected
with some servers over Novell 3.12. I proceeded to meet this
person and talk with him.

After an hour of talking I have the following information:

- The enterprise who provides security to this Bank can't deal
with the identification and disinfection of the virus in the short
term.
  [These are the words of the System Administrator not my opinion]

- The Anti-Virus Package that they represent here does not detect
the virus completely (incomplete string) and left the infection in
some files.
  [This is a fact because they corrected it in later versions]

- The virus mutates the appearance of the file.

- Infects the files (predefined targets ?? - see note) 

   * EMM386.EXE
   * SETVER.EXE
   * MEM.EXE
   * XCOPY.EXE


- The virus which attacked the bank was Avispa (Wasp).


I analyzed this virus a few months before. I found it in February
1994 but the quantity of work I had postpone this analysis for a
few months. Finally I did the job around May 19 and submitted my
analysis to Wolfgang Stiller. 


 ------------------
|  Avispa Virus    |
 ------------------

Preliminary analysis of Avispa virus by Ruben M. Arias (RALP
Computer Security)


Name        : Avispa (means wasp in English)
Size        : Varies between 2048 (+15 bytes).
Infects     : EXE files.
Scan string : BB ? 01 ? ? 80 C3 ? ? ? 2E 8B 07 ? ? B9.
In the wild : Yes.
Interrupts  : Hooks interrupt 21h and 13h.
Load Address: -----
Polymorphic : Slightly (not exactly performs some bytes encryption
in fixed
              places).
Resident    : Yes.
Size in RAM : 2304 bytes.
Stealth     : No.
Text        : Not visible its encrypted and varies, exists at
least two
              version of this virus and one dropper.
              The text says:

db "$$ Virus AVISPA $$ Republica Argentina$$ Elijah Baley "
db "$$ Noviembre 10 de 1993 "    
db "$$ This program is not an old virus variant, and it was
written "
db "in Argentina by Elijah Baley. It uses polymorphic technics
to"
        db " avoid conventional scanning."

                                         
Type : Infects .EXE files, and the virus is appended to the end of 
     :the infected host files.Unusual     
      : Have a routine for overwrite with the text described       
      :before but this takes place in memory everytime int 13 is   
     :used to read the disk.

Other info  : This virus was submitted to Wolfgang Stiller
              about 03/01/94 and my final analysis 05/19/1994.
              Also submitted to David Chess to check some
information
              on request of a friend of mine (Claudio Toriano) who
              works for IBM here in Argentina (10/21/94).

              Both, the explanation of the name and a part of the
encrypted 
              text (not transcribed by "ethic") are insults to our
actual
              president.
==============================================================


Note:

Some time after I could verify some things that I skipped about
this virus.

Every time I verify an infection of this virus the four files
listed before result infected. They're .EXE files of course, but
some other analysis I read in a local magazine about security
published here describe them as "targets" predefined by the
author. Other version of this virus ??, maybe.

The source of this virus was published in an "underground" review 
(about July 1994) and distributed to BBS's. I found this source
too and a closer look to it shows that the virus avoid the 
infection of EXE files which the last two letters of it name ended
with:

- AN, an (Scan)
- LD, ld (Vshield)
- OT, ot (F-prot)

Another important point that I wish to comment on is the "quick"
spread of this virus in Argentina.

Some time later I made a revision of the dates in which success
happened and I was surprised. Hope this could help and be
significant in the study about dispersion of viruses:

 Month/Year               Observation
-----------------------------------------------------------------
 11/1993         -> The virus was programmed.
 02/1994         -> I Found the virus. 
 03/1994         -> Send the virus sample to Stiller Research.
 04/1994          -> Talking with Vesselin Bontchev, he confirmed
                    this virus as polymorphic. He had a sample.
 06/1994         -> Virus Attack the Bank.
 07/1994         -> Code was published in underground review.
 08 to 12/1994   -> Begin to appear infections masive.



Aclaration:

The name of the Bank, the security company that assist the Bank
and the name of the Antivirus used in the Bank are confidential.

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

FRANCE:

     Editor's Note:  Last issue I misspelled Gerard Mannig's last
name as MannING. This is incorrect.  The proper spelling of
Gerard's last name is Mannig.  I regret the error Gerard, sorry
mon ami :-)

Spain:

     We have a new contributing author, Mario Elkati from Spain. 
Mario works for ANYWARE AV software.  He tells us about the virus
stats in Spain today.

The Percentage of viruses reported fall into the following viruse
families:

25% Barrotes
25% Natas de Satan
25% Curuna 4
10% Junkie
15% Others

Regards!

Mario Elkati

                              ***

                          In The News
                               
                     Virus writer retires:
                    ======================
                               
     Recently one of the better known viruse writers decided to
pack it in and retire.  Stormbringer,of Phaclon/Skism, posted the
following retirement letter on the net:

Editor's note:  There has been some slight rewording do to the age
of some of our readers. :-)

Greetings,
    For those of you who know me, you may know my various handles,
my activities, and causes for what little fame I may possess...  I
am Stormbringer of Phalcon/SKISM, Black Wolf, and Jesus of the
Trinity, and even some others probably no one would recognize. 
And today, I am retiring.
 
    Last night, I got email from a guy in Singapore.... a nice
guy, really, extraordinarily polite for the circumstances.... he
had been infected with one of my viruses, Key Kapture 2, by some
guy who wanted to mess with his computer.  It was filling up his
drive (he had only 2 megs left) with captured keystrokes, and he
had no way to disinfect it, so he wrote me,asking me for help to
cure one of my own creations that had attacked his computer...  I
called him up voice, and talked with him.... and even then he was
kind, almost like he didn't really blame me, although I feel he
should. Now, I never released my viruses against the public
myself, never wanted them to be in the wild, but it happened. 
Fortunately, I also never wrote destructive viruses, so I didn't
trash the poor guy's computer. It will be fixed, with the main
harm being his time and security.
 
    For some reason, this really shook me.  I had always written
my viruses as educational, research programs for people to learn
more from, and for myself to explore my computer and a type of
program that I found almost obsessively interesting.  All of my
viruses were written to explore something new that I had learned,
something different, something cool..... and yet, I still managed
to hurt someone...
 
    A lot of you people are probably thinking that I'm a wuss, or
whatever, and I really could care less.... messing up people's
stuff was never my intention, and yet it happened.  I have decided
that it is time for me to quit writing viruses, and continue on
with something more productive, perhaps even benificial to others.
 
    Don't really know what else to say, 'cept that it was an
interesting journey..... and I'll still be hanging around
somewhere on the nets.....
 
Cheers,
Stormbringer, Phalcon/Skism
Ex-Virus Writer

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





     Rob Slade found this interesting tidbit:


                    Friends across the sea?

Vancouver's "Our Computer Player" newspaper, in a story without a
dateline but probably from a newswire service, reports that a
federation of Japanese computer clubs has stated it will be
presenting US President Bill Clinton with a "harmless" computer
virus.  The stated purpose is to raise awareness of the danger of
viri.  The purported virus, named as "Kyoto Ichigo" (Kyoto Number
One) is said to display the lyrics of a song by a Kyoto amateur
band.  A spokesman for the federation, identified as Takao
Yamamoto, is reported to state that malicious viral programs in
Japan are virtually all of US origin, and that he hopes this will
suppress the export.  (Sounds like these guys have a very tenuous
grasp of the concepts, here.)


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



                        The Book Shelf
                               
                               
                 "IBM Dictionary of Computing"
                        George McDaniel
                               

"IBM Dictionary of Computing", George McDaniel, 1994,
0-07-031489-6, U$24.95
%A   George McDaniel ibmterms@vnet.ibm.com
%C   2600 Tenth St., Berkeley, CA   94710
%D   1994
%G   0-07-031489-6
%I   McGraw-Hill, Inc.
%O   U$24.95 510-548-2805 800-227-0900
lkissing@osborne.mhs.compuserve.com
%P   758
%T   "IBM Dictionary of Computing"
 
The fact that the cover of this book is red is the last piece of
humour you'll find in it.  There isn't even an entry for "This
page intentionally left blank."  Pity.
 
The jargon contained herein is oriented to IBM's technology,
though not uniquely.  Terms are included from two ANSI
dictionaries (X3.172-1990 and EIA 440-A) and the International
Organization for Standardization document ISO/IEC JTC1/SC1
document.  Still, this will be quite handy when those who work
with *real* computers have to translate for the blue suits.  Net
people can regard this as a rather old document:  ftp is listed
(capitalized) but neither HTML nor Gopher appear.
 
Given that the majority of entries are either special definitions
for common English words, or phrases of English words, the lack of
any pronunciation or part-of-speech guidance is understandable. 
Less usual is the listing of cross references (see also, contrast,
etc.) as additional definitions.  (This format is not consistent
throughout.)  Some of the additional definitions are decidedly
odd, such as:
 
    "About...  (1) In SAA Common User Access architecture, a help
action     that displays ownership and copyright information about
the application.  (2) In SAA Common User Access architecture, a
help action that displays the logo window of the application."
 
It is also very easy for errors of omission to slip into a work of
this size,though I must say that I'm a bit put out that *both*
"virus" and "worm" point to "attack", while "attack" points back
to neither.
 
The need for a definition for a lapel mike (especially since it is
defined as "synonymous with lavalier") escapes me.  I thought I
had found some good old hacker-speak when I got to "punch and
crunch editing", until I found that the "preferred"
term--"assemble editing"--refers to video production.  I guess
IBMers have to deal more directly with media people than with
programmers.
 
copyright Robert M. Slade, 1995   BKIBMDCT.RVW   950307



                            ******


                       "Aether Madness"
                  Gary Wolf and Michael Stein
                               

BKAETMAD.RVW    950303
 
"Aether Madness", Gary Wolf/Michael Stein, 1995, 1-56609-020-2,
U$21.95/C$30.95
aether@igc.apc.org
%A   Gary Wolf gary@wired.com
%A   Michael Stein mstein@igc.apc.org
%C   2414 6th St., Berkeley, CA   94710
%D   1995
%G   1-56609-020-2
%I   Peachpit Press
%O   U$21.95/C$30.95 510-548-4393 fax: 510-548-5991 800-283-9444
%P   297
%T   "Aether Madness"
 
Despite the title, this is a very gentle book.  It is a topical
(and therefore almost automatically superficial) guide to
information and resources in the online world.  The coverage is
broadly based, drawing from BBSes, commercial online systems, and
the Internet.  Unlike many other works in the same vein,this one
is refreshingly free of arrogance and dogma.
 
The major part of the book (Travel Tales) reads like a series of
short magazine articles.  The articles can't be exhaustive (nor
can the list of topics), but both material and variety is well
chosen.  The entries are readable, and easy to take.
 
An interesting feature is the glossary.  There is no attempt to
provide a tutorial for life online, but the glossary entries are
at least a paragraph in length, and sometimes extend to a page or
more.  This allows the reader to pursue explanations at his or her
own pace.
 
This book is neither complete enough to serve as a reference, nor
organized enough to be a training guide.  Those who are curious
about the online world,however, will find it an easy and probably
appealing entre.  Read the "Travel Tales" that sound interesting. 
Look up the glossary references for new terms. Eventually, you may
find it worthwhile to buy a "modem".
 
Online aficionados may also find this a way to expand horizons. 
The net is wide.  There are lots of interesting tidbits herein.
 
copyright Robert M. Slade, 1995   BKAETMAD.RVW   950303

======================
DECUS Canada Communications, Desktop, Education and Security group
newsletters Editor and/or reviewer ROBERTS@decus.ca,RSlade@sfu.ca,
Rob Slade at 1:153/733
Author "Robert Slade's Guide to Computer Viruses" (US contact:
1-800-SPRINGER)


                                   ******


                   "Robert Slade's Guide to Computer Viruses"
                                 Robert Slade


"Robert Slade's Guide to Computer Viruses", Robert Slade, 1994,
0-387-94311-
0(New York), 3-540-94311-0(Berlin)
U$31.50 (S/H)
roberts@mukluk.decus.ca
%A   Robert Slade roberts@mukluk.decus.ca
%C   175 Fifth Avenue, New York, N.y. 10010-7858
%D   1994
%G   0-387-94311-0(New York), 0-540-94311-0 (Berlin)
%I   Springer-Verlag
%O   U$31.50 (S/H) 1-800-SPRINGER  fax: 
%P   472
%T   "Robert Slade's Guide to Computer Viruses"


Mr. Slade takes the beginner and walks him through the mystical
world of viruses unveiling the mystery.  Chapter One and Two are
to get the reader past the myths and misconceptions of viruses. 
He explains what they are and how they work.  While this is at the
basic level, the reader is not bombarded with "techno babble" and
lost in the shuffle.  His easy manner and "on the same level"
approach allows the reader to gain the basics of viruses at ease.

From that point on the reader is taken into the basics of virus
operations and how they work on various systems. The basics of
ploymorphism, tunneling, and stealth as well as payloads and
triggers are explored.

Chapters Five and Six get into anti-viral procedures and
techniques and follow up with AV Software evaluations.

The "appendices are longer than the book" to quote Mr. Slade,
however they are very informative.  FAQs about viruses, quick
reference antiviral review chart, vendors and contacts listing and
a bookshelf review are well written and very well catalogued.  The
glossary is very helpful to the beginner trying to understand the
terminology in AV.

Mr. Slade did a wonderful job bringing an otherwise complicated
subject matter down to the grass roots level to where the everyday
user can get a basic education in anti-virus prevention and
techniques.  I highly recommend this book to any beginner who is
serious about learning all they can about computer viruses and
protecting their systems.


                                     Woody




                                 ******
                                 
                               
                        Hacks, Viruses and Trojans
                               

     I want to put this first article at the top of the list this
month.  Please read this carefuly and if you happen to see this
get a hold of Kieth Peer and let him know:

==================================================================
 WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
==================================================================

AVP 2.2 has been found on BBS's in North Amercia

It was not released by any AVP agent!
This archive did NOT come for CENTRAL COMMAND INC.!

This archive can be named AVP22.ZIP or AVP22US.ZIP

 =====================================================
 PLEASE DELETE AND REMOVE THIS ARCHIVE IF YOU FIND IT!
 =====================================================

     If you find this archive please notify Central Command Inc.
at our e-mail address at: kapeer@netcom.com or call Keith Peer
directly at 216-273-5743. Please leave a message as to what BBS
you found it on and what there phone number is. Also, contact the
Sysop and have him remove it from his BBS.

     If you are a REGISTERED AVP user contact your nearest AVP
agent for a authentic version of 2.2. If you need assistance
finding your nearest AVP agent you may contact the North Amercia
AVP agent Central Command Inc. for a list.

          Central Command Inc.
          P.O. Box 856
          Brunswick, Ohio 44212
          216-273-5743
          Contact: Keith A. Peer

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

Lyle Jenson is an alert sysop and passed this along on the net:
 
I received a message and a file from a new user on my system.. The 
original message that he sent me is as follows.. Since this Person
was not able to Totally UUENCODE it and send it in a message to
me, he uploaded it and believe it or not, it did pass my file
scanner. Please, if you have the following user upload or send you
a file,please erase it.  It DOES contain the AIDS Virus...
 
As You Can Notice From the message below, he logged onto my system 
under the name "JOSH GERWIN" but at the end of the message it is 
spelled Josh Garwin, so this more than likely is not his name. 
Please be aware of this person or the file "TriN11.zip"
 
Thanks
 
Lyle
Sysop@sphnxbbs.sbay.org
 
======================================


Bill Lambdin sent this along:

Woody:
 
I received the message below from Mark West on Delphi
------------------------------------------------------------------
MARKWEST@DELPHI.COM  To BILL LAMBDIN about Whisper virus on CD on
03-27-95

Bill,

   I have just received a note from the member on Delphi Internet
that discovered the Whisper virus on the CD-ROM I spoke of in my
last message. The information in my last message has been
verified.  Here it is again to confirm: 

   Here is the info on the CD and the infected files:
 
 CD:  Companion (second in the series)
 Company:  GCW,  
           11 US Route 15 North, 
           Village Shops, 
           Dillsburg,PA. 1
          (717)432-0404. 
 
     The program on the CD is part of  "Rise of the Triad" (rott). 
It is a sound setup file SNDSETUP.EXE. 

 Mark West
 Host, Paradox / Virus & Security Forum at Delphi (GO CUS 320)
 markwest@delphi.com

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

Editor's Note:  The following has been labled as a HOAX.
                This is the message passed along to us
                at The Scanner:

Woody:
 
This message was posted into the UNI NET virus conference.

_________________________________________________________________B
RYAN SULLIVAN To ALL  about JPEG or GIF VIRUS ? on 04-02-95

 Does anyone know anything about the following???  Is it just
another uninformed scare from someone on the net???
 
=================================================================
                   W A R N I N G :
 
     If you are using a DOS or Windows machine, then you are
vulnerable to attack from the JPEG virus.  THIS IS NOT A JOKE! 
The JPEG virus has already destroyed the hard disk of a major BBS
in Chicago and has caused much grief to several users already (see
the section on my personal experience with the JPEG virus for more
details).
 
             HOW THE JPEG VIRUS WORKS:
 
 The JPEG virus hides in the comment field of the JPEG (JFIF)
file.  the JPEG image is loaded into video memory, the JPEG virus
is loaded into shadow ROM, affecting the video driver interrupts
(int 0x10) and some of the DOS file interrupts (int 0x21).
 
 The JPEG virus takes advantage of a little-known undocumented
featur DOS that has been around since DOS 3.3 known as direct
execution. For some reason (known only to Microsoft) loading a
data file can cause immediate execution of a program file
contained within the data file When a DOS interrupt 0x21 is
invoked with a function call 0x3F (read from file or device) DOS
will scan the data file as it reads it for following information:
 
     Offset  Size    Description
     ------  ----   
------------------------------------------------
     0x00   0x08    Magic 8-byte ``Load program'' string
     0x08   0x04    Location inside current file where program
                    begins
     0x0C   0x04    Length of program
     0x10   0x02    Segment address of environment string to pass  
                  to loaded program
    0x12   0x04    Pointer to the loaded program's command line
    0x16   0x04    Pointer to the first default File Control
                   Block (FCB)
   0x1A   0x04    Pointer to the second default FCB
   0x1E   0x02    Checksum
 
 When the magic 8-byte signature is read by DOS, the next 24 bytes
are read, the checksum is computed, and compared to the checksum
stored the 32-byte header.  If the two checksums match, DOS
finishes loading the data file, then immediately proceeds to load
and execute the program.  (Actually, it may first load the data
file, then do the ckecksum stuff, but that's an irrelevant
detail.)
 
 In the case of the JPEG virus, the 32-byte header is located
inside comment field, and the JPEG virus is catenated to the end
of the JPEG file.  When the JPEG virus is loaded, it installs
itself into shadow ROM, then executes an  IRET which then returns
execution back to the original picture viewer.  Note that if you
have not correctly configured your computer, that the virus will
load improperly, and the picture program may appear to crash when
you try to load the JPEG image.
 
         HOW TO FIND OUT IF YOUR JPEG FILES ARE INFECTED:
 
 At present, there are no anti-viral utilities which scan for the
JPE virus. This is because several strains of the virus are known
to exist and there is no simple common pattern which can be used
to different between valid JPEG comment fields and infected JPEG
files.  To be on safe side, you can scan for the JPEG virus
yourself.  Get a hex edit from WUARCHIVE (or your favorite ftp
site) and examine the first few bytes of each one of your JPEG
files.  The comment field comes in between the first three header
bytes (FF D8 FF) and the file type last (4A 46 49 46 == "JFIF"). 
If you see no comment field, or a valid ASM comment field, then
your JPEG file is OK. However, if you see a rand string of hex
characters, then your JPEG file may be corrupt.

  
Sample output from the HEXDUMP program is shown below on an
uninfect JPEG file.  Note that the comment field contains a valid
ASCII comments between bytes 0x06 and 0x4E.

 
 00000000   ff d8 ff fe 00 K  *  *  *  *  J  P  E  G     C
 00000010   o  m  p  r  e  s  s  o  r     C  o  p  y  r  i
 00000020   g  h  t     (  C  )     1  9  9  1  -  1  9  9
 00000030   2     P  o  t  a  p  o  v     W  O  R  K  S  ,
 00000040      S  T  O  I  K     L  t  d  .  *  *  *  *  ff
 00000050   e0 00 10 J  F  I  F  00 01 01 00 00 01 00 01 00
 00000060   00 ff db 00 C  00 0a 07 07 08 07 06 0a 08 08 08
 00000070   0b 0a 0a 0b 0e 18 10 0e 0d 0d 0e 1d 15 16 11 18
 
 I strongly urge that you should scan all your JPEG files for the
JPEG virus by examining them with the hex editor found at the end
of this post.  If you find any strange hex characters where the
comment field should be, then you will want to destroy the
infected file.  Note: if you have a hex editor, you can just
over-write the nasty 32-byte header with nice blank spaces. This
will ``kill'' the virus and let you keep your nice images.
 
             History of the JPEG Virus:
 
 The first known strain of the JPEG virus was discovered by Dr.
Charles Forbin at CERT on 31 October 1993.  He immediately
informed NSA officials, who promptly declared that such a thing
was ``physically impossible.''  In honor of this profound
judgement, Dr. Forbin named first JPEG virus ``Physically
Impossible.''  Soon, other strains were discovered, most notably
being the strains ``Cruel Tricks 4'', ``Dead Friends'',
``Clueless'', and ``Brain-Dead''.

 If you think your JPEG files are infected, it's probably
Physically Impossible, but it might also be Clueless and/or
Brain-Dead.
 
 Note that multiple JPEG viruses may simultaneously infect JPEG
files If too many viruses infect a file, then there is a comment
field overflow which can cause the JPEG file to crash your
computer.  In addition, infected JPEG files can also cause some
JPEG viewers to be unpredictably, producing poor quality output. 
If your JPEG files dont look very good, they may be infected and
you should check their comm fields right away.
 
                   W A R N I N G :
 
 Although only JPEG files are known to have been infected, there
are several other types of image formats with comment fields,
including files. This means that ALL your picture files may be
subject to infection.  If you suspect that your pictures are
infected, then check the comment headers right away!

             R E C O M M E N D A T I O N :
 
 Do not view ANY JPEG files until you have scanned their headers. 
Be wary of JPEG files from disreputable sources (FTP/FSP sites,
BBS,USENET, etc.) Check the headers of all your JPEG files AT ONCE
befor they are infected. 

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

EDITOR NOTE :This is what I received from Rob Sade on the HOAX:
                                                               

I don't know whether you would have seen the original JPEG
"warning" message or a reposting of it, but the original was
posted on April 1st this year. In fact, it was posted on April 1st
last year as well.  The message is a hoax: there is no JPEG virus.

There are several tips in the message that brand it as a fake. 
First, it states that the purported virus takes advantage of a bug
in MS-DOS when loading data files.  Such a bug is unlikely to have
survived for fourteen years without being detected and fixed.  In
any case, DOS does not have special routines for handling data:
that is done by application programs. (The wording of this "bug"
is probably supposed to recall the sendmail data overrun problem
used in the Internet Worm.)

Secondly, this is another re-run of the dreaded "monitor
destroying virus"-- which doesn't exist.  There is no known virus
that destroys hardware.  In any case, the alleged virus is
supposed to change the frequency on the "flyback transformer". 
This is a combination of two technologies.  In some very early
graphics cards, it was possible to change the frequency of the
"sweep rate" of the monitor--and, by changing it to zero, you
could stop the scan at one point one the screen.  After some time,
this would burn the phosphor off that one spot, and leave a tiny
dead spot on the screen. The flyback transformer, however, is a
high voltage device used on all cathode ray tubes, and is not
addressable by software.

Finally, the "expert" quoted in the message, Dr. Charles Forbin,
is a fictional character, hero (?) of the book "Colossus" and the
movie "The Forbin Project" made from it.

                                  Rob Slade


                               *******

                          The Virus Spotlight
                               
                                 EXEBUG
                               
                               
     I asked Henri Delger ( virus GURU at PRODIGY ) about the
EXEBUG virus.  Here is what Henri had to say:



          While ExeBug is in memory, it will mis-direct attempts 
to read its code in (cylinder&head 0, sector 1) to the relocated
MBR data (in cylinder&head 0, sector 17) which makes it a
"stealth" type virus.

     From then on, the virus will be in memory, ready to infect
other diskettes, on any access (even DIR).  The FORMAT command
cannot remove this type of virus, since FORMAT doesn't write to
sector (cylinder&head 0, sector 1) where the virus code is
written.

     In addition, ExeBug alters the CMOS data, so that the A>
drive is shown as "Not Installed," which may prevent some PCs from
being booted from an uninfected DOS boot disk, at least until the
CMOS/Setup is restored.

     Depending on the computer's BIOS, the A> drive may be
accessed temporarily with the <F1> key to allow a boot from an
uninfected floppy, necessary before attempting to remove the
virus.  The CMOS Setup itself may be accessed at the start of the
boot process, with the <F2> or <DEL> key, or by a combination of
the <Ctrl>+<Alt> plus either <S>, <Esc>, or <Ins> keys. (Some PCs
do not have the Setup program built-in, but on a separate
diskette.)

     Once the PC has been booted from an uninfected boot diskette,
DOS won't be able to access the hard disk,displaying an "Invalid
drive specification" message, because the partition data which was
in sector (cylinder&head 0,sector 1) was written over by the
virus.

     This virus is an example where the undocumented DOS5/6
command FDISK /MBR is futile, since the partition data will still
be missing from (cylinder&head 0, sector 1).  Copying the original
data from (cylinder&head 0, sector 17 to 1)will write over the
virus code, allowing a re-boot from the hard disk.

     ExeBug will "trojanize" EXE files, writing a small program in
the "slack" space at the end of the file, which can destroy
Directory and File Allocation table data in the month of March,
thus causing files to be inaccessible to DOS, and if fragmented,
lost to most data recovery programs.

     Antivirus programs do not find these trojans, nor are they
shown with the DIR command.  Although they are harmless once the
virus itself is removed, they can be wiped off the disk if a
utility is used to "wipe" the file "slack," or if a utility is
used to fully de-fragment the disk.

Regards,
Henri Delger 



      Thanks Henri, now, lets take this to "The Lab".  First thing I
am going to do is put an infected disk in the drive and boot from
that disk.  This is a very common way for bootsector viruses to
travel.  An unsuspecting user has a disk in the drive and forgets
about it and turns the system on.  The system tries to boot from
the disk and if it is a non-systems disk the error message will
appear on the screen.  So lets use that scenario.


      I put an infected floppy disk into the drive the booted the
system. This is a very typical scenario.  An infected disk is in
the system and the user turns the system on.  The usual error
message comes up and the user removes the disk not knowing that
the system is now infected.  Well, we see the message:

     Non-system disk or disk error
     Replace and press any key when ready.
 
(NOTE: this message will vary from system to system depending on
the DOS used and the language being used in the DOS)

     So, I remove the disk and the system comes up all is hunky
dorie right? Wrong.  I do a chkdsk and see that there are only
654336 total free bytes when there should be 655360 bytes free. 
The system is infected. At this point I would like to tell you
that some systems use a part of the memory for their
BIOS operations.  If your system is one of these then be sure you
know how much memory the system reserves for these operations so
you will be familiar with what the total free meory should be.

     Lets start with F-Prot 217 this time.  I turn the system off
and put my F-Prot 217 bootable floppy in the A: drive.  Turn the
system back on.  It will come up but there will also be an error
message:

       Diskette drives or Type mismatch error - use setup
       Press F1 key to continue or CTL-ALT-ESC for setup

       (NOTE: this message will vary from system to system, the
point is EXEBUG has messed up the CMOS and removed the A: drive
information so the system will not recognize the A: drive, forcing
the system to boot from the C: drive.  If your boot drive is B:
then the B: drive will be disabled )


 Make the proper data inputs to the CMOS then continue on.  We
finally arrive at the start up screen for F-Prot.( those of you
that are more familiar with the program and prefer to use line
commands probably don't use this, so be sure you read the DOCs
that explain these commands in order to be sure to properly use
the program).  Now, there are some things one must be aware of. 
If we just do a SCAN, F-Prot will come up and say:

         Master Boot Sector infection: EXEBUG.A

    The following message will appear in a red box:

             Error: No hard disk found.

     This is all you get.  You must go back to the opening screen
and Tab down to Action.  Go into to Action and you can either
choose Disinfect/Query or Automatic disinfection.  Because this is
in the Bootsector these are your only choices for removing this
type of infection.  Now run the program again. This time you will
see a red box with the following message in it:

         The Master Boot Sector is infected with the
         A variant of  the Exbug virus.

         Disinfect (Y/N)?

     Obviously you would choose Y. The program will then put
another red box on the screen saying:

          Error: No hard disk found.

     Look very carefully below the red box:

     Master Boot Sector infection: EXEBUG.A 
     Virus removed.

      See the message that tells you the virus has been removed? 
This message comes up because while F-Prot has removed the bug we
have not reset the system so it can see the hard drive.  Turn the
system off and then back on again and you will be back in
business.  If you want to make sure you got it, turn the system
off and put the bootable disk in the system and bootup again. 
This time just do a Scan and you will find that the Exebug virus
is no longer there.  F-Prot has removed the virus from the system
and you are now ready to move on.

      A note from Mikko reminded me to tell you that if you use
F-Prot from the command line use F-Prot /HARD/DISINF, do not use
F-Prot C:/DISINF.  For more information see COMMAND.DOC on the F-
Prot disk.


     F-Prot will remove both variants A and C the same way.  It
takes longer reading about it than the actual process takes.
         


     Now Lets get into Integrity Master.  We are using IM 242c
for this demonstration.


     The setup of Integrity Master is crucial to its proper use. 
I speak from experience. :-)  I had some problems at first because
I did not set it up properly. Thanks to Wolfgang Stiller and Bill
Lambdin assisting me I now have the proper set up.  So, let me go
over the set up first with you so those of you running Integrity
Master have a proper set up.

     1. Format a floppy disk and use the FORMAT/S ( or SYS A: to
transfer the system files to it. Substitute the proper drive label
if A: is not your boot floppy).  Make a directory called IM_HOME. 
Put it aside for the moment.  

2.  Install Integrity Master on your hard drive.  Do the entire
system setup within Integrity Master.  Now, put that new floppy
you just formatted and made bootable into the drive.  Copy IM*.*
to that drive.  Go into the IM_HOME directory on the HD and copy
all .SRL files to A:\IM_HOME.


     Now you are ready for any situation that arises.  Be sure to
copy any new additions you make to the hard drive to the
"emergency disk"


   Now, I boot the system form this bootable floppy with the IM
files on it. Again, I get the drive mismatch error.  Make the
changes in the CMOS as needed and continue. 

     For those of you more familiar with the program, you may be
more comfortable with the command line commands.  Be sure you keep
abreast of any possible changes or add on to these commands as the
newer versions come out.

     When the main screen comes up tell IM to change disk to C. 
You will get a big red box with the following text in it:

    Disk Change failed.  Disk C is not ready.
    
    Please check and make sure the drive is ready.

    There are other possible causes for this problem.
    They are described in file QUESTION.TXT.  TO read
    this file, locate your original IM files and enter
    the command: IMVIEW QUESTION.TXT

    If you have experienced disk corruption or if IM
    previously found a virus in memory, you will need
    to use the "Missing Partition" option on the 
    "ReLoad" menu to fix your disk.

After you read this and hit ENTER you will be confronted again
with an other red box.  This box will tell you there is an error
reading the disk.  Keep going, hit ENTER again. This will take you
back to the main screen.  Tab over to ReLOad and Tab down to
Missing Partition.  Hit ENTER then Tab down to DOS logical drive
letter (A to Z).  Press enter and a box will come up asking you
what drive you want to reload the Partition on.  Enter C.

     At this point you will be warned ( again via the red box )
that you are about to replace the partition sector with the file
on A:.  This is what you want to do.  Remember, you loaded this
onto the rescue disk earlier after you loaded it form the HD to
the IM_HOME directory on the floppy.  SO, tab down to:

     Yes, continue reloading.

     You will see a red box again telling you that there has been
an error writing to the file on C: drive.  Keep going at this
point, press enter and you will see another box ( blue this time)
that says:

     Reload of partition sector completed.

    Turn the system off and bring it back up again and you are
ready to go.


FURTHER INFORMATION ON EXEBUG.

     I went ahead and put a 720kb 3 1/2 inch disk into my a drive
and just went from C: to A;.  The drive ran for a few seconds and
it was writing to the A:.  I put t 1.4kb disk in A; and did it
again.  The same results.  This is a good indication that the disk
is being infected.  I put a 1.2 and a 360kb disk in the B: drive
and went from A to B; and again, the drive was running and
writing.  I then cleaned the system and did a scan on the system
and scanned the disks.  Each of the disk were infected with
EXEBUG.

     This is a perfect example of how bootsector viruses can
spread so rapidly.  If the user does not practice some sort of
Anti Virus technique they can infect an office or even a small
company in no time.

     I tired to get an EXE file to become infected with the Trojan
but did not succeed, unfortunately.  I will have to do some
further tests to check this out.

                                    Woody



                               ******

     Bill Lambdin sent along the information on Green Catepillar
virus. An intersting "bug" to say the least.


Preliminary analysis of Green Catepillar by W.H. (Bill) Lambdin


Name         ] Green Catepillar
Size         ] 1579-1591 bytes
Infects      ] .COM .EXE files including  COMMAND.COM
Scan String  ] No scan string necessary. All scanners detect this
In the wild  ] Yes
Activates    ] This virus activates by displaying a green
catepillar
             ] crawling down the left side of the screen.
             ]
Armored      ] No
Detected     ] Yes
Encrypted    ] No
Interrupts   ] 21h 
Load Address ] 9F8D:0100h on my test machine. The load address
will 
             ] vary depending on the amount of RAM available.
Marker       ] Date and Time Stamps on Infected host files are 
             ] updated to the date and time of infection
Polymorphic  ] No
Resident     ] Yes
Size in RAM  ] 1840 bytes
Stealthed    ] No
Text         ] No text visible in files or in memory
Type         ] Resident file infector. The virus is appended to
the 
             ] end of infected host files
Unusual      ] Will infect files as small as two bytes.

Bill Lambdin
__________________________________________________________________


                      From Woody's Desk
                               

     So ends another month of virus info.  With new viruses
coming out everyday it is a job and a half just keeping up with
what is already out there, let alone what is new and where it came
from.  Rob Slade hits on a subject that we all need to look at. 
With Stormbringer retiring I am sure there will be someone else to
take his place.  Why do they do it?  I don't know.  Some say for
fun, some say to get a message across, some do it because they
enjoy making others miserable, and then again some don't have a
clue as to why the do it other than it being cool.  What ever the
virus creators reason is for turning the bugs loose, you as a user
need to stay alert.  Stay on top of the new techniques and the new
AV programs.  The Scanner is just one of the ways to keep up with
the times.  There are many conferences you can follow and other
publications that will keep you informed as well. Use them.

     There are many many AV products out there.  Some better than
others. Some promise the program of all programs to end the need
to ever need another AV program. Well, I believe the old adage "If
it sounds too good to be true then it probably is" applies here. 
The AV product you use is a personal choice just like the type of
computer you choose to use.  What ever your choice is pick one and
learn it.  It takes just a few seconds to properly maintain your
system and scan those new programs you download.  It will all be
worth the time believe me.

     Til next month, have a bug free month.

                            Woody
