               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 
