VIRUS-L Digest Wednesday, 23 Oct 1991 Volume 4 : Issue 197
(International edition)
Today's Topics:
re: formatting problems (PC)
More on "Morris Appeal"
Re: Hardware and Software; Forget Turing...
Pakistani/Ashar (PC)
nVIR was Re: Virus on Mac (Mac)
michelangelo virus (PC)
Re: Version 84 of McAfee anti-virus programs now available (PC)
Can fprot handle Zenith Dos 3.30.1 yet? (PC)
Re: What is CoolCapture? (Amiga)
Re: Several subjects (PC)
Re: New virus - advanced symptoms (WAS: New virus)
Re: Virus Proof Machine ?
Re: DIR II removal (PC)
Re: DIR II virus and DOS 3.31 (PC)
Re: DIR II Removal Information (PC)
Help please (PC)
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Mon, 21 Oct 91 11:36:00 -0400
>From: Bob Babcock <
[email protected]>
Subject: re: formatting problems (PC)
> I am having a problem formatting disks in my b: drive. It is a
>1.44 M 3.5 floppy, but I am not able to format it to 720K; that is,
>when I try to format a double density disk as such : format b:/f:720 ,
>it says that the parameters are incompatible. This worries me because
>when I type format b: , the system says Formatting disk at 1.2 M...
>Then I had another problem at the same time - I booted up
>my computer and it said "ERROR - Run CMOS Setup"
Try running your CMOS setup program again and look at what it says about
your B: drive. The fact that FORMAT wanted to format to 1.2 MB suggests
that the CMS says you have a 1.2 MB drive, not a 1.44 MB. There are
many non-virus ways of corrupting the CMOS information. The obvious way
is a dead battery, but I've done it simply by turning a machine off and
on quickly, so a power glitch could also do it.
------------------------------
Date: 21 Oct 91 12:35:00 -0400
>From: "zmudzinski, thomas" <
[email protected]>
Subject: More on "Morris Appeal"
Quoting the Oct 14, Computerworld, Page 14: "The U.S. Supreme
Court refuswithout comment to hear Robert T. Morris' appeal last
week, ending a legal journey that began nearly three years ago when
he injected a worm into the Internet network." [...] "according to
Thomas Viles, an attorney at the Silvergate & Good law firm in
Boston." [...] "That affirmation goes against the widely accepted
tenet that an injury can amount to a crime only when deliberately
intended, Viles said. 'The law distinguishes, say, between murder
and manslaughter. You can't be guilty of murder if a killing was
utterly accidental and unintended.'"
/z/
Disclaimer: I am not a lawyer (my parents are married), but I hope
Mr. Viles goes back and reviews "felony-homicide" before he has to
defend someone who utterly accidentally and unintentionally commits
"manslaughter" while breaking-and-entering.
------------------------------
Date: Mon, 21 Oct 91 18:38:00 +0300
>From: Y. Radai <
[email protected]>
Subject: Re: Hardware and Software; Forget Turing...
Lars J:dal writes:
>It seems to me that this Turing talk is going along two *different*
>threads:
>
>1) Can computers (in principle) distinguish between a virus and a
> "normal" program?
>2) Can computers be build to be safe from virus infection?
>
>This is two different subjects! So the proof by someone-I-don't-know
>that 1) is undecidable on a Turing machine should only (or rather at
>most) discourage people designing programs to detect viruses, not people
>trying to design a system which cannot be infected.
>
>Right?
Yes, these are different subjects, and if we could design a system
which could never be infected, this would be preferable to detection
after infection. Unfortunately, it's impossible, at least under ordi-
nary operating conditions (e.g., no permanent hardware protection).
On the other hand, it is possible to *detect* all viruses, and this is
apparently the reason that Dr. Fred Cohen (the someone-you-don't-know)
concentrated on detection rather than prevention. That is, unlike
prevention, detection can be performed without any Type-II errors
("false negatives"). True, there will still be Type-I errors ("false
positives"), but these can be kept to a reasonably small number.
These goals can be achieved by sounding an alarm when and only when
modifications in files [and other regions containing executable (or
interpretable) code] are detected, assuming that no file was infected
when the files were first examined. As I understand him, this is to
be implemented by a resident program which checksums each program and
its dependent files just before that program is executed.
However, there are some points which call for comment:
1. Looking for modifications is not enough to detect all viruses.
One counter-example is companion viruses. (There are others.)
However, a good program will be able to deal with such cases.
2. While I've never tested it, I'm willing to bet that Cohen's own
PC implementation of his ideas, his ASP "integrity shell", would fail
to detect certain additional types of viruses, particularly stealth
viruses which infect the MBR or otherwise gain control before ASP
does. (This, however, does not mean that his goal cannot be achieved
by a better implementation.)
3. Cohen claims, without any attempt to justify the claim, that only
cryptographic checksumming is secure enough for modification detection
(for anti-viral purposes). I disagree.
4. There's no reason why one cannot combine both detection and pre-
vention. Cohen does not seem to consider the advantage of this com-
bination.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
Date: Mon, 21 Oct 91 10:50:28 +0500
>From: Mario Guerra <
[email protected]>
Subject: Pakistani/Ashar (PC)
One machine in my university (a PS/30 with a Seagate 30 MB. disk) was
infected with the Pakistani Brain/Ashar virus (according to Viruscan 84).
If I run Viruscan from a clean disk it does not detect the virus, but if
I boot from the hard disk, the same program says it is in memory.
I have tried everything: a Sys, running Norton 6.0 Disktool, using DE
for writing a new boot sector from other machine with a similar hard disk,
rewriting the partition table (once again, from a similar disk), etc.
Any help will be greatly appreciated.
+----------------------------+
| MARIO GUERRA |
| MGUERRA@UCRVM2 |
| SYSTEMS PROGRAMMER |
| UNIVERSIDAD DE COSTA RICA |
+----------------------------+
| VOICE: (506)24-88-29 |
| (506)25-92-92 |
| FAX: (506)53-60-75 |
+----------------------------+
------------------------------
Date: 21 Oct 91 15:16:00 -0400
>From: "J. SCOTT WEAVER" <
[email protected]>
Subject: nVIR was Re: Virus on Mac (Mac)
Dave Martin (
[email protected]) writes:
>I have always wondered something about nVIR, ... I booted from a
>clean, locked System floppy and used ResEdit to clean out the nVIR
>resources and correct the CODE resources. I copied rather than cut or
>cleared the nVIR resources so I could move them to a separate disk to
>examine them later. Immediately an alert popped up saying that it
>couldn't write to the System file (disk locked). It seems that simply
>by copying the nVIR resources was enough to activate it. Anyone know
>if this is possible (copy enabling code execution)? Now remember this
>was a couple years ago, so I can't recall everything that occurred,
>but I'm still curious as to whether that was enough to get nVIR to try
>and spread.
I observed similar behavior when I attempted to use ResEdit to examine nVIR
resources on an infected system. After looking at the virus CODE resources,
I would get errors whenever I tried to write. Never followed it up, since
there were simple cures for this virus -- mostly educating users to do
something about it.
J. Scott Weaver Bitnet: fweaver@ceramics
Geology Department Internet:
[email protected]
Alfred University <192.31.254.1>
Alfred, NY 14802 Phone: (607-871-2203)
------------------------------
Date: Mon, 21 Oct 91 15:41:11 -0500
>From: Anthony Di Nardo <EENG6719%
[email protected]>
Subject: michelangelo virus (PC)
Recently my friend's system was infectedwith the Michelangelo virus.
Does any one have any information on it, or know where I could obtain
some. SCANV82 identifies it, but in the included virlist.txt it is
not metioned at all.
Thanx in advance.
Anthony Di Nardo.
------------------------------
Date: 21 Oct 91 17:50:31 +0000
>From:
[email protected] (Barry T. Drake)
Subject: Re: Version 84 of McAfee anti-virus programs now available (PC)
For those of you without FTP:
I have downloaded and uuencoded SCANV84.ZIP, CLEAN84.ZIP, VSHLD84.ZIP, and
NETSCN84.ZIP. I would be happy to e-mail them to anybody who wants them.
- --Barry (
[email protected])
Occidental College Computer Center
------------------------------
Date: Tue, 22 Oct 91 01:36:55 +0000
>From:
[email protected] (Douglas A. Bell)
Subject: Can fprot handle Zenith Dos 3.30.1 yet? (PC)
I heard that a version of fprot that can handle ms dos 3.30.1 for
zenith was going to be ready two weeks ago.
Has it been finished?
We are in the midst of an out break of jerusalem here, but about
a third of the computers run the odd zenith dos.
The administration here has to buy something, but they won't buy
it if it doesn't work on their computers.
- --
Douglas Bell
[email protected]
If I didn't use this band width, it would probably have gone to waste.
------------------------------
Date: Tue, 22 Oct 91 02:30:25 +0000
>From:
[email protected] (Kevin Kadow)
Subject: Re: What is CoolCapture? (Amiga)
[email protected] (Brett L. Kessler) writes:
)I have been doing a lot of work recently on all of my floppies using
)VScan 5.10 to see whether or not I have an infection hiding in all of
)my TurboImploded executables.
)
)I've noticed that a lot of programs read and write to CoolCapture,
)etc., even though VScan reports them as clean. What are the major
)points of infection in an Amiga system? And what do those areas do in
)a normal situation?
)
)For example, I have heard of CoolCapture, WarmCapture, ColdCapture,
)and one or two other common entry points for viri (RomTagPtr?
)KickTagPtr? I can't remember...). What do all of these places do
)that make them so attractive to virus-writers?
They allow a virus to survive a warm reset, so ALT-AMI-AMI won't stop them
from doing their dirty work, and in fact will trigger many viruses...
What I'd like to know is WHERE is the FTP archive with the Amiga virus data?
What will DETECT and KILL australian parasite?
- --
Where it is a duty to worship the sun, it is pretty sure to be a crime to
examine the laws of heat. (Morley)
[email protected] kadokev@iitvax (bitnet)
My Employer Disagrees.
------------------------------
Date: 21 Oct 91 23:51:13 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Several subjects (PC)
[email protected] (Fridrik Skulason) writes:
> I am trying to compile a list of PC virus families, in an effort to
> reduce the naming confusion. There are some problems in defining
> just what a virus family is. For example, it is not 100% clear if
> the following groups of viruses should be considered to belong to
> the same family or not.
> 1) Jerusalem, Fu Manchu, Plastique and Slow
Definitively yes. I have a program, written by a friend of mine, which
tries to disinfect something he calls "generic Jerusalem variant".
When I tested it on Fu Manchu, it disinfected it successfully,
although the author has never seen this virus. The program called it
Jerusalem-2080.
> 2) Vacsina and Yankee
Well, they are different versions of a main strain, written by one and
the same author. They are also upward compatible. I would say that
they definitively belong to the same virus family, even if they are
not considered as variants of one and the same virus. For instance,
Brain-Ohio-Den Zuk also belong to the same family (althoug they are
definitively -not- one and the same virus or even variants of one and
the same virus).
> 3) W13, Vienna, Ghostballs, V2P2
Maybe the V2Px family should be separated, since it is really too
different from Vienna. The others I consider to belong to one and the
same family.
> 4) Cascade and JoJo
One and the same family.
> The release of version 2.01 has been delayed by a week, so I can add
> 60 (or so) new viruses from Poland.
There are a few interesting ones, aren't they? BTW, they are not only
from Poland; most of the new ones are from the Soviet Union
(Andrzej?). Which reminds me that the hackers out there are quickly
catching up after the Bulgarian ones... :-(
> My E-mail address has changed - it is now
[email protected], but
> mail sent to
[email protected] should still reach me.
Noted.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 21 Oct 91 23:15:53 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: New virus - advanced symptoms (WAS: New virus warning (PC))
[email protected] (Shulman Ilya A.) writes:
> No, I mean that it is very simple to identificate is virus present
> when it is active :-)
What symptoms did you have in mind exactly? This one is pretty
stealthy...
> >Sometimes DOS updates the second copy of the FAT itself, so this
> >method is unreliable. I have observed several cases in which the EOF
> >mark was present in both copies of the FAT. Better check whether the
> Are you sure that "Sometimes Dos updates" all copies of the FAT up to
> the end? When it happens? How I can initiate Dos to do it? I observed
I don't know, but I definitively have seen disks with the virus body
marked as used in both copies of the FAT. Maybe it happens when DOS
updates the same sector of FAT, where the virus mark resides? Try
creating and deleting a file on an infected system, so that it
occupies the end of the disk (you may temporarily mark almost all free
clusters as bad with Norton Utilities to enforce that).
> this virus on the few computers and the difference in FAT was on each
> of them. Two computers worked with this virus in memory nearly 1-1.5
> month and users didn't know about it. To my mind the difference in
> FAT is a stable symptom but not only _ONE_.
> Yep. Two times I found virus on the hard disk in the cluster 714 and
> 2371 (I can't remember this numbers exactly but) which are the last
> clusters on the 5" 1.2Mb and 3.5" 730Kb diskettes respectivly. I can't
> explain why there were the last clusters but not the pre-last but it
> was so. Also I know the other abnormal effects when virus infects disk
> but didn't write itself to the last cluster. May be it is an error
> too, but anti-virus developers _HAVE TO_ know this.
Maybe this referes to the COMPAQ DOS 3.31 situation that was described
by Dimitri Gryaznov?
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 22 Oct 91 00:31:49 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Virus Proof Machine ?
[email protected] (Chris Stops) writes:
> (Side note : In fact, the 80286 had a back door, the LOADALL
> instruction. This loaded ALL of the processor's registers, including the
> internal ones associated with the protection. However, LOADALL filled
> the registers with values read from a memory block at absolute location
> 800h, so this back-door can be closed simply by making sure that the
> memory at 800h is in a high priority region).
And how about the LIDT (Load Interrupt Description Table) instruction?
It is supposed (to my knowledge) to in protected mode only, but on a
80286 it runs perfectly in real mode. It allows you to swap the whole
interrupt vector table with something totally different, which resides
at a different address. Was this fixed in the 386? The author of the
Vacsina/Yankee Doodle viruses had told me that one of his advance
viruses (TP 50 or 51) uses this trick to avoid monitoring programs on
a 286. Unfortunately, I never got a copy of that virus.
> The entire operating system (i.e. BIOS, IO.SYS and MSDOS.SYS, but not
> the external commands) is held in ROM (or EPROM, or something similar.
Hmm, sounds a bit like a Mac to me... :-)
> Of course, viruses don't have to become resident to do their dirty work.
> They can act 'on the fly' just before an infected program is run. In
> this case, the operating system limits the operations which can be
> carried out on executable files. For example, executable files may be
> created (so compilers still work) or may be executed (of course!). But
> they cannot be opened for read access. Nor can their executable status
Why not just deny the write access to the executables? Also a good
heuristic is to permit programs to write to the files that they have
created OR to the files that have been stated on the command line as
arguments.
> be altered to look like a data file (e.g. in DOS terms, *.EXE becomes
> *.DAT, the 'DATA' file is processed, then *.DAT is renamed back to
> *.EXE). If we still allow executable files to be deleted, then about the
It's enough to forbid the non-executable --> executable extension
renaming.
> only sort of virus left is an overwriting virus, which deletes an
> application and then creates a copy of itself using the name of the
> application. But since the applications will no longer run, it should be
> obvious that something is wrong with the machine.
Also, don't forget about the companion viruses. Or viruses that infect
OBJ, .LIB, .BAT, .MAC, .INC, .H, .C, .PAS, .MOD, .FOR, .BAS, .PRG, or
whatever else gets interpretted/executed... :-)
> To allow copying of executables (e.g. from floppy to HD) there would need
> to be a new operating system call for copying files, becuase, of course,
> no application (e.g. COPY) can read the source file!
This is no problem if you forbid only writing, but allow
reading/creating.
> Now of couse, there will be some users who want/need read/write access
> to their executable files. In this case, we could have a three position
> switch inside the machine, mapped into a protected I/O location. It
> functions as follows...
Better implement it as a hardware switch. If it is software (even if
it is protected) either (1) the user will not be able to use it, or
(2) a virus would be able to use it too...
> Position A All attempts to read an executable file are stopped.
> Position B All attempts to read an executable file result in a
> Position C All attempts to read an executable file are allowed.
Just replace "read" with "write".
> In fact, earlier I mentioned an overwriting virus that could operate if
> deletion of executables was allowed. Maybe this could also be controlled
> by a similar switch.
> Similar protections could be put on batch files, if required, although a
> batch file virus would be easier to spot.
See my earlier remarks about companion and interpretted viruses.
> Now that the operating system is so well protected, we have a problem.
Yeah, that it is not very useful... :-)
> Not only can no virus modify it, but no extensions can be added either,
> for example, new device drivers. The virus proof way around this is that
> new drivers are supplied on ROMs which can be plugged into the machine,
> and patched into the O/S during initialisation. A slightly less secure
Updating through ROMs has been already discussed here, as far as I
remember... It is a good idea, but most computer manifacturers
consider it as too expensive. Don't forget - a practicable anti-virus
solution should be also marketable...
> Any comments anyone? Is a totally ROMed version of the machine virus
> proof? Is there a hole somewhere? I have a gut feeling that any holes
> would eventually map down to a hole in the processors protected mode.
> After all, surely the idea of a protected mode is that you can build a
> protected system?
If the hardware supports memory protection, and if it is used to
implement file-access rights, you can get a pretty secure system.
Something like Unix... Ooops, there are already viruses that spread
under Unix, so it doesn't seem to be -THE- solution. True, they spread
very slow, true, they can be catched much more easily, but
nevertheless they exist and they spread. Indeed, they use a completely
different trick. While Mess-DOS virus rely on the abilities to bypass
its protection (huh? what protection?), the Unix viruses rely on the
fact that Unix users share resources intensively...
> Of course, my machine would probably be incompatible with Mess-DOS. But
Almost certainly. Maybe OS/2 ver. 3.0?
> then, isn't it about time we establised a new microcomputer standard
> based on at least 32 bits of data and address?
Good idea. It rests "only" to convince IBM about it... :-)
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 21 Oct 91 20:08:28 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: DIR II removal (PC)
[email protected] (Andrzej Kadlof) writes:
> This particular virus is extremaly easy to remove. It may be done
> very quickly by any non qualified person in the following way:
> 1. Rename all executable COM and EXE file to something else (CCO and
> EXX).
> 2. Reset computer from clean disk.
> 3. Run CHKDSK /F
> 4. Rename all CCO and EXX back to COM and EXE..
I would suggest the COPYing of the files to non-executable extensions
(instead of renaming) and DELeting them afterwards (the ones with
executable extensions, that is). But you are right that since the
renaming cause the directory sector to be read, modified and written
back, this will case the virus to disinfect the entries on-the-fly
when the sector is read, and not to re-infect them (becase the do not
seem to belong to executables any more) when the sector is re-written
to the disk.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 21 Oct 91 20:13:59 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: DIR II virus and DOS 3.31 (PC)
[email protected] (Dmitry O. Gryaznov) writes:
> BUT COMPAQ DOS 3.31 USES DIFFERENT REQUEST HEADER LAYOUT! This leads
> to the virus body being written to sectors 65535-65536 (FFFFH-10000H)
> instead of the last cluster. If any file occupies these sectors -
> it'll be corrupted. It is still possible to recover affected files if
> these sectors were not overwritten which is possible since the virus
> doesn't protect them being sure it resides in the last cluster. All
> DIR II disinfectors are to be changed to detect the above case.
Hmm, I didn't notice that... Well, my disinfector will not corrupt
information in this case, but it will report that a mutation of the
virus has been found. It is not very clear how this situation could be
handled - since when the disinfector is run, it is not safe to assume
that the DOS version active in memory is the same that was used to
access the infected disk...
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 21 Oct 91 19:58:20 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: DIR II Removal Information (PC)
[email protected] (Dmitry O. Gryaznov) writes:
> First of all - a disinfection must be made only when there is no the
> virus in RAM.
..or when it is not active. For instance, my disinfector is able to
find it in RAM and to deactivate it.
> The virus code will not *ALWAYS* be found in the *LAST* cluster. In
> fact on 1.2 and 1.44Mb floppies it'll occupy two clusters starting
> with last-1. On a hard disk the virus can reside in a cluster far from
> the last if all the following clusters are marked as "bad".
Yes, the algorithm is: start from the last cluster of the disk; if it
is marked as bad, move to the previous one; when you find a non-bad
cluster, move one more cluster backwards if it is a high-capacity
diskette (or, more exactly, if the cluster size is < 2 sectors).
> This cluster number can be found in the virus body at offset 0334H.
> And the easiest and correct way to obtain the virus body is to read an
> infected file (we suppose there is no virus in RAM). So disinfector
No, because you may find a file that contains the virus, without the
disk being infected - for instance, if someone has copied the file
from and infected disk on a clean system, but has not tried to execute
the file yet. In this case, you should not try to disinfect the media.
Maybe the simple deletion of the file would be appropriate.
> can check all the .EXE and .COM files for the virus body. When found,
> it is necessary to check if the cluster (its number is at offs. 334H)
> *REALLY* contains the virus - you could get an infected file by
> copying it on a not infected PC. In the latter case a disk most likely
> is not infected and a file contains just the virus body, its directory
> entry being quiet normal.
Yeah, that's what I mean... My disinfector does not delete such files.
Maybe it should?
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: Wed, 23 Oct 91 11:37:00 +0000
>From: "I'M YOUR NO.1 FAN.........." <
[email protected]>
Subject: Help please (PC)
As the subject line suggests I NEED HELP!!!!!
And, surprise surprise it has to do with viruses (I think...)
The only clues I have to help with the naming of the virus is that
when I load WordStar 1512 it sometime crashes and the words
CRAZY EDDIE
appear somewhere on the screen. It does'nt happen all the time
but it would be nice to find a way to solve the problem.
I use McAfee Associates SCAN util (version 84) but this does not
report anything wrong with my hard disk of files.
Any help would be gratefully received.
..... THANKYOU!!!!!
__
/ \
--< alan >--
\ __ /
" Hasta La Vista ..... baby " (Terminator II)
- ------------------------------------------------------------------------------
-Everyone needs something to beleve in and I beleve I'll have another drink-
- ------------------------------------------------------------------------------
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 197]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
