VIRUS-L Digest Wednesday, 20 Nov 1991 Volume 4 : Issue 221
Today's Topics:
PC Week's Skatt Column of Nov 11th: Word Perf. & Virus? (PC)
Re: Generic scanning - a small test (PC)
Re: DIR-2 found in USA (PC)
Re: Computer virus report from Bulgaria
Re: Disk Compression (PC for now)
AIDS trial
Re: two (2) excerpts from FIDO VIRUS echo conference
Protection...
Bug in VSHIELD? (PC)
Disk Defender (was: Virusproof systems; hardware) (PC)
NIST Naming Proposal
Re: McAfee84 fails on Stone, Azusa and Joshi? (PC)
Write-permit is not 100% reliable (reference articles)
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: Thu, 14 Nov 91 16:22:00 -0700
>From: "Rich Travsky" <
[email protected]>
Subject: PC Week's Skatt Column of Nov 11th: Word Perf. & Virus? (PC)
Interesting little tidbit in the Nov. 11th PC Week in Spencer Katt's
column:
Word Perfect, ..., was also hit by some network malevolance
late last month. What started out as a bug in printer format
functions turned into a persnickety nationwide virus. Seems
the mysterious seizure affected only LANs with Data General
PCs running WordPerfect 5.1
This certainly sounds goofy. Anyone have any idea what the Katt's
talking about?
Richard Travsky
Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming (307) 766 - 3663 / 3668
------------------------------
Date: Fri, 15 Nov 91 00:12:41 +0000
>From:
[email protected] (Warren Toomey)
Subject: Re: Generic scanning - a small test (PC)
>From article by
[email protected] (Fridrik Skulason):
> I just did a small test and I hope the results are of general interest.
Yes!
[ much deleted ]
> Generic analysis is not yet a substitute for virus scanning, but it
> is improving....
I'm sorry, I don't often read through comp.virus. Can you tell me if a
free/shareware generic anaysis tool like the one you used is available
for IBM PCs at the moment.
Thanks in advance,
Warren Toomey
Warren Toomey VK1XWT, cold but happy
Deep in the bowels of ADFA Comp Science.
`POSIX Job Control?! POXY job control more like!'
------------------------------
Date: 15 Nov 91 08:35:04 +0000
>From:
[email protected] (Mark Medici)
Subject: Re: DIR-2 found in USA (PC)
As a follow-up to Mike Martin's message, this may also be of interest:
1. Dir-2 (a.k.a. FAT) is a fast moving virus. In addition to the lab
Mike reported, we had infections at two other labs at nearly 100%.
All this happened in a matter of days from the time we suspect the
first infection occurred.
2. Though we will probably never learn how the virus arrived, it was
transported from PC to PC via key disks required for a copy-
protected computer-based instruction program. Yet another good
reason to avoid copy protection.
3. McAfee's SCAN and VSHIELD version 84 correctly identify the virus.
Unfortunately, due to a large staff relocation, we did not update
immediately when the new release was issued.
4. Microcom's VIRx version 1.8 and Fridrik Skulason's F-PROT version
2.01 also correctly identify the virus. I have not checked with
Central Point or Symantec about updates.
5. McAfee's CLEAN version 84 successfully removes the virus with no
after effects. I am not aware of any other programs that
currently do the same, though a back-up and restore of the infect-
ed disk may also be a means of recovery (read on).
6. The virus cannot infect NetWare volumes, as there is no DOS FAT
available for them to modify. I don't know if this holds true for
other networks, but would expect that they, too, would prohibit
anything from attempting to modify the FAT on shared volumes.
7. Once a program infected with DIR-2 is run, the virus immediately
installs itself on the hard disk and modifies the hard disk's FAT.
It is not necessary to run a program on the hard disk for the
virus to be transferred.
8. With the exception of some copy protection schemes failing (our
first clue to the virus) and un-explained (though infrequent)
system crashes, (especially in MS-Windows), the virus is invisible
while active.
9. If the system is booted from a clean DOS diskette, a DOS CHKDSK
will report cross-linked files. This is because the virus changes
the FAT so that all entries for executables point to the virus,
which then redirects to the actual file while after the virus
itself executes. CHKDSK will report no problems if the virus is
active.
10. Attempts to copy executables when the virus is not active will
only copy the virus itself. If you later run the copied file,
the virus will load into memory and you will return to the DOS
prompt without the desired program every running. Attempts to
copy executables while the virus is active will yield both the
executables and the virus.
11. Though not fully tested, it seems that using a DOS BACKUP of the
infected disk will yield the original, uninfected executables.
At least this is what I found, and it makes sense when you under-
stand how the Dir-2 virus works. This allows another method of
recovery from the virus: Back-up the entire system while the
virus is active, reboot from a clean DOS disk, reformat the
infected disk, and restore the backup. This did work for me the
3 times I tried it.
This is all I know about the virus at this time. Once detected,
recovery is simple with McAfee's CLEAN v84. If you elect to use the
backup/restore method of recovery, make certain to either low-level
format your disk or use a utility that will overwrite all data in all
clusters before the restore (e.g., Norton's WipeDisk or WipeInfo, or
PC Tools Compress with the "Clear Unused Clusters" option turned on),
and do another complete scan to make sure the virus hasn't somehow
been restored as well.
Standard Disclaimer: This information is provided as-is and without
any warantees as to accuracy. Though everything I've described is
accurate as far as I've determined, that's no guarantee that things
will work the same for you. Use this information at your own risk.
Any opinions are mine alone and don't necessary reflect those of my
employers.
- --
- ------------------------------------------------------------------------
Mark A. Medici / Systems Programmer III
Rutgers University Computing Services
<
[email protected]>
------------------------------
Date: Fri, 15 Nov 91 09:10:06 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Computer virus report from Bulgaria
In Message 11 Nov 91 16:16:48 GMT,
[email protected] (Vesselin writes:
>have been discovered, all of them of Bulgarian origin. These are
>Damage 1.1 and 1.3 (which, according to a string in them are made in
>Plovdiv),
I would rather suggest that they should be called "Plovdiv 1.1" and
"Plovdiv 1.3", rather than "Bulgarian Damage". "Damage" is already in
use - for a couple of Italian Diamond (V1024) derived viruses, and as
"Diamond" is of Bulgarian origin, it might be somewhat misleading.
> a new version of Murphy, a new version of Terror,
Neither of which seems to work properly....
>a new virus, called Brainy
Which appears related to a sample named "Warrier" (not "Warrior"). I have
not been able to get "Warrier" to infect anything, but "Brainy works without
problems.
A quite interesting little virus, by the way - It may insert itself into
the middle of a .COM program, without changing the beginning of the file -
a trick which is only used by one other virus so far.
- -frisk
------------------------------
Date: 15 Nov 91 10:07:52 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Disk Compression (PC for now)
[email protected] (Mark Aitchison, U of Canty; Physics) writes:
> What I meant was the combination of compressed disks plus other
> (simple) software protection. For example:
>User programs --> DOS --> Compression system --> ReadOnly driver --> int 1
3
> (Or, perhaps, DRDOS password protection in there as well). Obviously
> viruses that go via DOS get blocked by the "readonly" software
> protection driver (say, DMDRVR.BIN or DISKGARD or DS II?), but (as
> many have debated recently) it is easy to bypass software protection
> and call interrupt 13 directly. But in this case it doesn't do the
> virus any good, since they bypass the compression system when they
> bypass DOS and the Readonly driver. This leaves them with junk which
> the virus will either not be able to interpret, or will make a mess
> of, or will require much more complexity in the virus to do the same
> job as whichever compression system was used.
While the combination proposed by you is a good idea and will stop
most of the current viruses, it presents some difficulties to
implement and could create a false sense of security, since it does
not stop -all- viruses - not even all of the currently known ones,
lest those that could be written by using only the currenty known ways
of attack.
First about the difficulties. Currently no compression system or
readonly driver could be installed -beneath- DOS. However, you
probably mean that they should be installed as a device driver, that
is, -beneath- the DOS file managing level, but -above- the DOS sector
managing level. Even such a solution presents problems, since (as I
mentioned in a pervious posting), I currently don't know a way to
install both compression, disk locking and a separate INT 13h handling
program on the same volume.
As to the security problems, note that a virus does not have to
circumvent a protection in order to spread. The fact that most
Messy-DOS viruses do is because there is virtually no protection on
Messy-DOS and any tries to achive one are just doomed patches which
can be circumvented easily - which tempts the virus writers to do so.
Suppose that a virus does not try to circumvent the multi-layer
protection scheme that you proposed above. Say, it just writes to
files when the user does so, that is, when they are copied, compiled,
deleted or whatever. Since the user really intends to modify the file,
the protection scheme will either allow the operation without notice
(if it is intelligent enough to guess what the user wants), or will
ask for confirmation. Do you know a user (however experienced) who
will say "No" if the protection asks him whether he really wants to
write in the copy of the file which he is just creating? (In fact, do
you know a user who will continue to use a protection scheme which
asks such silly questions?) Agreed, if a virus adopts such an
infection scheme, its spread will be much slowlier. However, it'll
bypass the protection completely, which may pay off, causing it to
spread much wider than if it only tried to bypass standard monitoring
software. In general, implementation of disk/file protection (even if
it is implemented correctly, which is quite difficult under Messy-DOS)
has the effect of only slowing down the virus spread, not of stopping
it completely.
Next, consider a virus of the Dir II type (-not- the Dir II itself,
since it won't infect volumes driven by device drivers), which infects
the directory entries information. Since DOS often updates this
information (when you copy, delete, rename, etc. a file), the
modification of this information must be permitted, if you need
something more useful than a write-protected disk. And since the virus
does its I/O via calling the DOS device drivers directly, for any
monitoring/compressing/etc. software, the write requests will seem to
come from DOS itself...
> Now, my worry is with viruses that do, in fact, try to manipulate the
> disk behind a compression scheme. That's probably getting too far
Indeed. The result of the work of such viruses is usually that the
disk becomes highly corrupted... For instance, the random sector
destruction that the Dark Avenger viruses perform could easily make
a Stacked volume heavily crippled.
> "naughty", I guess, since it tries to bypass too much. Programs like
> Norton's DS are only slightly naught, and go in at the interrupt 26
> level (I think), which is still possible - I don't know what fraction
> of viruses use interrupt 26 instead of interrupt 13 or interrupt 21
> (anyone with an approximate percentage?) but these are the ones that
Currently none of the known viruses uses INT 26h for -spreading- (that
is, for writing its body in the infected objects). However, quite a
few of them use INT 26h for their payload, to cause damage.
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: 15 Nov 91 11:39:59 +0000
>From:
[email protected]
Subject: AIDS trial
I understand that the trial of the person charged with making
the AIDS Trojan was due to start at Southwark Crown Court, London, on
11th. November.
Does anyone have any knowledge about the proceedings so far?
Andrew.
-
-------------------------------------------------------------------------------
- -
Andrew Smith
Computing Services JANET:
[email protected]
Kingston Polytechnic
Surrey, U.K. Tel. +44 81 547 2000 ext. 2077
"...its origin and purpose still a total mystery."
-
-------------------------------------------------------------------------------
- -
------------------------------
Date: 15 Nov 91 12:13:08 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: two (2) excerpts from FIDO VIRUS echo conference
[email protected] writes:
> according to certain rules. My firmware has the option of
> rejecting operations that it doesn't like, and the PC can't
> get around it. So here's the plan: the user flips a switch
It all depends on how his system determines what it does like... It
must either stop dead any disk writing (i.e., write-protecting the
hard disk), or try to make clever guesses whether the write is legal
or not. If it does the latter, it's relatively easy to design a virus
which will bypass it - its write requests will seem to come from DOS.
> then turns off the "System Configure" switch. The SSPT then
> goes out and makes a record of all .EXE, .COM and .OVL files,
> the hidden files, and their corresponding FAT and directory
> entries. This info is stored on the reserved disk area. On
Even the FAT and the directory entries? This means that you cannot
rename or delete a file on the protected volume or even add a new file
to it while the protection is on. Therefore, it practically
write-protects the disk. But, if this is the main goal, it doesn't
need to remember all that stuff and use clever assumptions... Just
denying the write functions of INT 13h will be enough and will have
the same effect.
> Obviously the SSPT's job is to make sure that disk writes do
> not hit any of the protected files, nor delete their directory
> entries, nor fiddle the appropriate FAT bits. There could be
That is, nothing can be done with the protected disk except than
reading from it. Then why not just forbid writing without messing with
FATs and direntries?
> be added to the protected list. The SSPT board as currently
> produced has a microprocessor, eprom, ram, two scsi chips, two
> scsi connectors, a serial port, a 2x20 char LCD display,
> led's, switches, and a loud buzzer. It could be programmed to
All of this just to perform the same task, which could be achieved by
a switch on the write-enable wire of the hard disk cable... :-)
> This board would sell for about $400, so it would be most
No wonder, with all that hardware stuff...
> the AT system, for little additional cost. The user would
> have to insert an electronic key into a port on the board to
> allow tampering with protected files. The only type of virus
Even a smart card? Uh-uh...
> that I can think of that this system couldn't guard against is
> the one that adds a .COM file with the same name as a legit
> .EXE file. But there are easy preventions for that trick,
Oh, it does. If it protects the FAT and the dir entries, no virus can
create a new COM file for an existing EXE one. In fact, no one can
create a file (any file) at all...
> Of course, a sloppy user could add add'l programs to his
> system that are infected, but since the critical system boot
> stuff is protected, the virus can't become memory resident
> unless that program is executed after boot. Any comments?
If an infected file can be added to the disk and the system only
protects the system disk areas from tampering (although these two
things are pretty incompatible with each other), I don't see how it
will prevent the infected file from being executed. Whether the virus
in it will be able to infect other objects is another story.
> Any comments from our resident hardware gurus? Seems an interesting
> concept, except for its price, which will deterr a lot of individual
> users...
I have already seen something similar (although better, simpler and
cheaper) realized - the ThunderByte card. It's pretty good, but does
not stop all possible viruses, of course.
> trick on a hd, and not a floppy. The usal target of ansi-bombs, btw, are
> BBS's, where bombs left inside an e-mail msg can do a lot of damage (e.g.
> refformatting the hd, creating enough files to fill the hd, etc).
Hmm none of the mailer programs for BBSes that I have used was able to
interpret the keyboard redefinition codes in the ANSI bombs. This is
not a danger. The danger is if somebody puts an ANSI bomb in an
archive's comment or in a README file, so that if you view it later
(in DOS mode, not using your communication software). Anyway, I always
disable the keyboard reprogramming feature of my ANSI driver, there is
no real need for it - at least for me.
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: Thu, 14 Nov 91 19:58:20 -0800
>From:
[email protected] (Fred Waller)
Subject: Protection...
Writes
[email protected] (Jim Pinson):
> I once made a simple modification to a floppy drive so I could
> write to protected diskettes.
Disabling the write-protect detection mechanism in floppy drives
is a trivial task. It is, however, a task that software cannot
perform! The OPERATOR did that. A hammer, or other similarly-
persuasive device, will also defeat hardware protection.
There's no question about it...
> If I had malicious intent, I could have "borrowed" someone's
> original protected application diskette, and infect them.
Of course.
> If that person assumed that no virus could possibly be on
> that disk, and failed to scan them, they would find themselves
> infected.
Yes, but failing to scan is not the reason why he got infected.
Scanning is not foolproof either; the person could have scanned and
still gotten infected. Or, if the scanner was not too well designed
(as some are not), then the act of scanning itself might have spread
the virus further to other parts of the system.
In fact, of all the antiviral software methods, scanning is
the least foolproof. Useful, though, as a stopgap measure.
> Granted, this is not simple virus infection, but a combination
> of sabotage and virus attack.
Precisely.
> The point is that too much confidence that you have a "perfect"
> defense can leave you vulnerable to other forms of attack.
This is true in every case. Overconfidence makes bad security.
The same effect could have been achieved by subverting the scanner,
or whatever other defense system was in use.
It says nothing about the desirability or undesirability of
hardware protection.
Fred Waller
[email protected]
------------------------------
Date: Fri, 15 Nov 91 08:22:43 -0600
>From: Brian McGraw <
[email protected]>
Subject: Bug in VSHIELD? (PC)
Hi everyone.
I was wondering if anyone else has found a bug with Vshield v.84. It
seems that when installed, a regular Ctrl-Alt-Del which usually causes
a warm reboot, doesn't work the same. Instead, it does a cold boot,
causing my drives to spin atrociously, and a memory check at the
startup. When I removed Vshield from my UMB's, everything worked
fine.
Anyone else had this happen?
Thanks,
Brian McGraw
[email protected]
------------------------------
Date: Fri, 15 Nov 91 17:10:00 +0200
>From: Y. Radai <
[email protected]>
Subject: Disk Defender (was: Virusproof systems; hardware) (PC)
Brian Howard writes:
>Not to be extolling the virtue of a dead horse instead of beating it
>but, I use DD on older systems (at this point less than 10 of about
>70 still in service) protecting the MBR against Stoned and other
>similar ilk.
It's interesting to hear that someone is (almost) satisfied with DD,
but I do wish you'd relate to the specific problem that I mentioned:
>> ... one could specify
>>what cylinders one wanted to be write protected, but it had to be the
>>trailing cylinders (i.e. from a given cylinder to the end of the
>>disk). And since the Master Boot Record has to be on Cylinder 0, it
>>couldn't be protected. .... This
>>was apparently deliberate because there was an accompanying device
>>driver which modified the MBR at boot time. But this left the MBR
>>wide open to infections by Stoned, etc.
It's possible that the (1988) version of DD which I was using differs
from the version you use, but please answer the following question:
Are you able to put Cylinder 0 in the protected zone? If the answer
is Yes, doesn't your version use a device driver (ADDPART.SYS) to
modify the MBR at boot time? If the answer to the first question is
No, then how can DD protect the MBR against the Stoned and other MBR
infectors?
From your reply to Vesselin:
>(Oh, it has a third problem I just remembered about. It fails open.
>Yep, when it fails it usually renders the drive writable.
Would you mind explaining what you mean by "failing open"?
> The second [re-
>latively minor problem] is the company is out of business.
Hmm, if DD is such a great product, I wonder why the company went out
of business ....
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
Date: Fri, 15 Nov 91 11:47:02 -0500
>From: Tim Polk <
[email protected]>
Subject: NIST Naming Proposal
The NIST virus naming proposal has been mentioned in passing a couple
of times recently; this message is intended to provide a brief overview
of that proposal. This is an ongoing project, with documents in *draft*
status. The project was inspired by the difficulties we have experienced
when attempting to cross-reference and verify virus information.
The goals of the proposal are: 1) to reduce the confusion caused by
multiple names for a single virus; and 2) to ensure "good" virus names.
We believe that "good" names are ones are that are easy to remember,
are not offensive, and describe the behaviour or contents of the virus.
The proposal consists of two parts: naming guidelines and naming
procedures. To make a long story short, the naming guidelines
call for names of the form
"FAMILY-STRAIN;Variant#"
where STRAIN and Variant# are optional. Viruses which have minor
differences with existing viruses use the name of the existing virus
with a new variant number. Viruses which are derived from existing
viruses, but have substantial modifications in technique or side
effects, would use the existing family name but would recieve a new
STRAIN. Entirely new viruses are assigned a new FAMILY name.
The naming procedures assigns the laboratory which isolates and analyzes
the virus responsibilty for assigning the virus' name. A central site
would maintain the central naming database, arbitrate disputes between
laboratories, and generally enforce the naming guidelines.
This proposal has been presented to members of both EICAR (at the Sept.
conference) and the AVPD. We will be discussing this project again at the
AVPD conference later this month. We are hopeful that the proposal will
be widely accepted, but a number of unanswered questions remain.
For those who are interested, we have posted the latest drafts for
anonymous ftp from csrc.ncsl.nist.gov (129.6.54.11). The files are in
the directory /pub/viruslab. The documents are available in both ascii
text and PostScript formats. The ascii text versions are nameconv.txt and
nameproc.txt; the PostScript versions have the .ps extension.
Any comments may be sent to
[email protected]
Thanks,
Tim Polk
Larry Bassham
NIST
------------------------------
Date: Fri, 15 Nov 91 17:27:13 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: McAfee84 fails on Stone, Azusa and Joshi? (PC)
[email protected] (Tanu Kartawiria) writes:
>We are in the process of evaluating McAfee program, specifically the
>VSHIELD84. We have vshield installed on all machines's autoexec.bat
>with parameters '/m /chkhi /lock', however our computers are still
>infected by those 3 viruses. The Clean program was able to remove
>Stone and Azusa, but it failed to remove Joshi even though it reported
>that it was successful in removing Joshi.
Can you be more specific about what happened with the Joshi virus? Was
the virus found in the partition table of the hard disk afterwards?
>Isn't Vshield supposed to block those viruses from getting to our
>computer in the first place? Are we missing something? Or are we
>doing something wrong? I'd appreciate your comments and expertise.
VSHIELD will prevent you from performing a soft-boot (Ctrl Alt Del)
with an infected floppy in the A: drive, however, if you actually boot
up from an infected floppy, then VSHIELD (which I assume is on the
hard disk) is not run and a virus will have a chance of transferring
to the hard disk. VSHIELD will, however, detect the virus the next
time it is run.
>Or should I use different program?
If you want to prevent your PC's from being booted from a floppy disk,
you may want to consider a new BIOS that will allow you to "lock out"
boots from the floppy drives, or a card that will do something similar.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
- --
- - - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
Date: Thu, 14 Nov 91 09:40:08 +0000
>From: Anthony Appleyard <
[email protected]>
Subject: Write-permit is not 100% reliable (reference articles)
from: {A.Appleyard} (email:
[email protected]), Thu, 14 Nov 91 09:32:56 GMT
Re reliability of write-protect tabs, ref these articles in Virus-L vol 4:-
.....................................................................
<PC disks: writing to disk despite write protection> [vol]
[can we trust diskette write-protection? (PC)] My PC ignored it 071
[Re: can we trust diskette write-protection? (PC)] Light bouncing about
past the write protect tab; use black tabs not silvery tabs 072
[Re: can we trust diskette write-protection? (PC)] if I leave cover off my
PC, fluorescent lights confuse its write protection detecter 074
[Re: can we trust diskette write-protection? (PC)] color of tabs used 077
[re: Diskette write protection.] some drives will write to some 5.25inch
floppies that I have that have no write permit slot; description 078
[Which format for Partition Table Viruses (PC)]
reformatting tape is no use of virus stays in computer memory 087
[Re: Can such a virus be written .... (PC)] can write protect by covering
the write protect notch be bypassed by software? 115
[IBM Write-Protection (was: Can such a virus be written ... ) (PC)]
Software can't bypass it; but hardware often malfunctions 116
sometimes but not often ([Re: Can such a virus be written .... (PC)]) 119
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 221]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
