Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ub!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson)
Newsgroups: comp.virus
Subject: STONED Problems (PC)
Message-ID: <0008.9103251532.AA25003@ubu.cert.sei.cmu.edu>
Date: 21 Mar 91 21:44:18 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 31
Approved: krvw@sei.cmu.edu


   Recently a number of people have mentioned STONED infections
trashing hard disks & think that the following is why.

  Today, nearly every partitioning software aligns the partitions on
even track boundarys for simplicity. Since the Partition Table resides
on track (cyl) 0 head 0 sector 1, the balance of this track is usually
left alone and the first partion starts on the next track. However,
this is just convension and not a requirement. In fact FDISK 1.00
which came with DOS 2.x began the first partition on track 0 head 0
sector 2 and has no "hidden" sectors.

   Since DOS version 3.0 came out in 1984, the later convension has
been followed and Norton's DI usually reports 17 "hidden" sectors (all
of track 0 head 0).

   STONED does not bother to check and just copies the original
partition table code to track 0 head 0 sector 7. No problem if this is
a "hidden" sector but disastrous (to DOS) if not. THIS IS REPAIRABLE.

   DOS keep two copies of the FAT (which STONED just overwrote) and
several utilities exist (Norton Disk Doctor is one) that will copy #2
onto #1 if some utility (like CHKDSK/F) hasn't corrupted the second
copy. It can also be fixed manually by someone with a bit of
experience.

   Consequently, I suspect that those experiencing FAT-type problems
had the misfortune to have a drive that was partitioned using "old"
software and then became infected with STONED.

							Padgett