Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!ub!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: CHESS@YKTVMV.BITNET (David.M.Chess)
Newsgroups: comp.virus
Subject: re: Reoccurence of Stoned on formatted drives (PC)
Message-ID: <0005.9101161910.AA06668@ubu.cert.sei.cmu.edu>
Date: 15 Jan 91 14:59:18 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 22
Approved: krvw@sei.cmu.edu

Hm, interesting.  The Stoned infects the master boot record
(synonymous with "partition table") on the first physical hard drive
(BIOS drive id "80" hex).  In your case, that's the master boot record
on the 80Mb hard disk.  The master boot record (and therefore the
partition table) are stored at the very bottom of the disk, lower than
any of the partitions (E F G and H).

Did you test whether or not, after booting from a clean floppy and
then switching to E: and back to A:, the virus was actually *active*
(infecting new diskettes), as well as being in memory?  My guess would
be that, although the virus code was in memory (in the buffer used by
DOS to hold the partition table of the hard drive), the virus was not
active (that is, not hooked into INT 13, and never actually getting
control passed to it).  That is, after step <4> I would suggest that,
although the virus was in memory, it wasn't actually -doing- anything.
(Memory scanning in general has the problem that it can't tell an
active virus from a "ghost" of the virus that just happens to be
sitting in a buffer somewhere, never running).  The only way the usual
Stoned virus can get control is if it's present on the boot record or
the disk or diskette that the system is booted from.

DC