105 lines
5.7 KiB
Plaintext
105 lines
5.7 KiB
Plaintext
Portal-Rmail-To: garyt@cup.portal.com
|
|
Received: by portal.com (3.2/Portal 8)
|
|
id AA13204; Wed, 26 Apr 89 01:40:03 PDT
|
|
Received: from Sun.COM (arpa-dev) by sun.Sun.COM (4.0/SMI-4.0)
|
|
id AA18592; Tue, 25 Apr 89 23:09:17 PDT
|
|
Received: from sun by Sun.COM (4.1/SMI-4.0)
|
|
id AB12617; Tue, 25 Apr 89 23:09:07 PDT
|
|
Message-Id: <8904260609.AB12617@Sun.COM>
|
|
Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.Edu (IBM VM SMTP R1.2) with BSMTP id 5947; Wed, 26 Apr 89 02:02:52 EDT
|
|
Received: by LEHIIBM1 (Mailer R2.03A) id 5724; Wed, 26 Apr 89 02:02:48 EDT
|
|
Date: Wed, 26 Apr 89 02:02:48 EDT
|
|
From: Revised List Processor (1.5o) <LISTSERV@IBM1.CC.Lehigh.Edu>
|
|
Subject: File: "V101 4" being sent to you
|
|
To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>
|
|
|
|
Date: Thu, 30 Mar 89 22:03 CST
|
|
From: Gordon Meyer <TK0GRM1@NIU>
|
|
Subject: Virus 101 chapter four
|
|
|
|
Subject: Virus 101: Chapter 4
|
|
To: info-atari16@score.stanford.edu
|
|
|
|
Having discussed the way viruses work, spread, and can be deterred, the
|
|
only remaining topic is how to recognize when an attack occurrs. It is not
|
|
always as simple, or as straightforward, as it may seem. What may appear to
|
|
be a hardware problem may be a virus, and vice-versa.
|
|
|
|
There is no absolute way to determine if a given symptom is being caused by
|
|
a program error, a hardware error, a virus, or something else. Not all
|
|
viruses cause destructive attacks, but those that do are usually devastating.
|
|
|
|
When files start vanishing or becoming unreadable, it may be due to any of
|
|
several reasons. Poor media, or abuse of media is not uncommon. A dirty disk
|
|
drive head, or one drifting out of alignment can cause previously reliable
|
|
disks to start producing errors. In the ST, there is the age old problem of
|
|
chip sockets and poor contact, and early versions of the ST had some component
|
|
reliability problems which could contribute to disk errors. Another source
|
|
becoming more frequent is the use of extended capacity disk formats, some of
|
|
which are not entirely reliable. There is also the potential of a real hardware
|
|
failure in the ST, or the drive. Finally there is the potential of a virus
|
|
attack. How do you tell? It's very difficult.
|
|
|
|
Actually, the virus is the easiest to detect. Use your favorite virus detect
|
|
program, and start searching. If you can't locate one, then you problem could
|
|
be any from the list above. If you find one, you must be certain you have taken
|
|
every step available to you to insure it has been eradicated before accessing
|
|
your backups.
|
|
|
|
When the virus does not destroy files, what does it do? It's rather like
|
|
the age old "Where does a 600 pound gorilla sit?". Most anyhere he wants,
|
|
obviously. A virus can do most anything that any other piece of software can
|
|
do. The bigger the code segment of the virus, the more capable it can become.
|
|
There are some rather surprising things accomplished by the viruses already
|
|
found in boot sectors, when you consider that it has to accomplish its own
|
|
loading, spreading, and eventual attack in about 120 instructions.
|
|
|
|
Some of the viruses currently spreading do nothing more than mess up the screen
|
|
display. When such an event occurs, it is not obvious that it is a virus
|
|
attack. It could be a momentary power fluctuation, a software bug of some
|
|
kind in the executing application, an intermittent hardware error, or any
|
|
of several other causes. The only hope of identifying the source as a virus
|
|
is, again, a methodic check of your disk library.
|
|
|
|
Familiarity with the appearance of the attacks of known viruses would be
|
|
helpful in recognizing when one is present. For that purpose, I have provided
|
|
the program "FLU". It is a demonstration program. It does not contain any of
|
|
the code present in any virus for the installation of the virus, or the
|
|
spreading of the virus. What it does contain is the non-destructive attack
|
|
code of several viruses. These attacks are either audio or visual, so that
|
|
there is evidence of the attack occurring. There is no simulation of any of
|
|
the virus attacks which cause damage to disk data, since there is no way
|
|
to recognize when such an attack is occurring (and, of course, the purpose
|
|
of the program is to aid in recognizing the symptoms, not to destroy disks!).
|
|
|
|
"FLU" is absolutely safe. The program can be viewed as a simple novelty,
|
|
which does some strange display alterations. But by running it, and becoming
|
|
familiar with the symptoms it displays, you will be capable of recognizing
|
|
the characteristics of the attack of several current ST viruses.
|
|
|
|
Two of the simulations, the "BLOT" virus and the "SCREEN" virus, attack in
|
|
a nearly identical manner. They step on a small portion of the screen. When
|
|
speeded up to display the symptoms, they have the appearance of drawing lines
|
|
from the top and bottom of the screen. However, when the attack occurs at the
|
|
speed at which the virus really operates, the attack would appear more like
|
|
a small blot appearing on the screen, since the screen would have most likely
|
|
been altered or redrawn by the application program between virus attacks.
|
|
|
|
The "FREEZE" virus is probably the most difficult of the non-destructive
|
|
viruses to recognize, since it is the most subtle. It takes over the
|
|
ST for an ever increasing period of time, causing a gradual slowing the
|
|
machine. Again, the demonstration runs at a significantly higher speed than
|
|
the real virus.
|
|
|
|
This concludes the virus discussions. It has been the goal of these postings
|
|
to inform the general public of the way viruses spread, attack, and can be
|
|
dealt with. It is clear to me that, as a defense, ignorance has been
|
|
unsuccessful.
|
|
|
|
--
|
|
*George R. Woodside - Citicorp/TTI - Santa Monica, CA
|
|
*Path: ..!{philabs|csun|psivax}!ttidca!woodside
|
|
|
|
------------------------------
|
|
|