Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: Pro vs Reactive Protection (PC)
Message-ID: <0002.9106202012.AA20764@ubu.cert.sei.cmu.edu>
Date: 19 Jun 91 16:51:57 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 65
Approved: krvw@sei.cmu.edu

In recent issues, there has been considerable outcry concerning the
"unremovable" infections that seem to plague many users and that the
generic anti-viral packages are not able to deal with them.

To repond, I have one PC (an XT) that has been infected with everything
possible yet recovery is trivial, it has been low-level formatted only
once (when it was delivered), and high-level formated an equal amount.

Of course, being an "infection" machine, it has some special qualities,
but none that I do not practise on my home machines as well.

For one, before every infection, the machine is fully backed up including
MBR, hidden sectors, DOS Boot Record, and both FATs (Bernoullis help &
it is only a 10 MB disk), however the special portions mentioned all fit
on a bootable 360k floppy and are self-restoring (similar disks exists
for each of the other machines except I usually do not save the FATs on
these).

This process has a number of advantages but does require a "recovery" disk
(preferably two) for each PC, however the process is nothing a good tech
cannot accomplish in five minutes using nothing more sophisticated than
DEBUG - less if automated, then the longest delay is SYSing the recovery disk
with the OS in use & copying any special drivers in use.

Unfortunately for many users, this MUST be done with an uninfected machine.
Since many call for help only after infection, this pro-active activity is
useless at that point.

Currently, the tool of choice seems to be McAfee's CLEAN, a generic
tool that is designed along the lines of the Oath of Hippocrates:
"First, Do No Harm". Even if it recognizes the virus (e.g. MusicBug),
and knows where the it stores the Boot Record, it must verify each
step of the way (is this really the mk 1 MusicBug or might it be a
clone ? Does it look like register values in the proper location ?
Does the retrieved sector look like a real Boot Sector ? Do the table
values match this disk ?) If any step fails, a generic disinfector
MUST refuse to continue. (those who have experienced total loss as a
result of certain "doctor" programs please raise your hands).

One of the things that can cause such problems are multiple
infections, another is the sheer diversity of boot record/MBR codes -
last year a european testing program recorded a PNCI boot record as
suspect, early versions of PC-Tools had an incredible boot record that
is the only one I have ever seen that would work with both MS-DOS and
PC-DOS. Sometimes it is hard to tell the good guys from the bad guys.

Recently, I have seen reports that some viruses use code that is so
close to each others that many scanners cannot tell the difference yet
the EMPIRE and the AZUSA need radically different cures if the
original table was not backed up somewhere off-PC (have had reports of
EMPIRE being reorted as AZUSA/Hong Cong).

In this case, you are just going to have to re-read your back issues
of Virus-L for the identifiers of each strain and the manual removal
methods that should have appeared along with the report (or soon
after).

Just to add one final note of cheer: as the strins keep increasing,
the likelyhood of misidentification will continue to increase but for
me, I would rather have a "false positive" to alert me to changes than
"false negatives" any day. After all, we have the tools, training, and
backups to handle just about anything but we "can't fix it if we don't
know its broke".
					Cooly,
						Padgett