padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) (03/22/91)
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
CCTR132@csc.canterbury.ac.nz (Nick FitzGerald) (03/27/91)
In VIRUS-L Digest V4 #47: Padgett Peterson <padgett%tccslr.dnet@uvs1.orl.mmc.com> wrote: > 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). Whilst Padgett's postings are usually very valuable, the above is a little misleading. Some OEM versions of DOS (some of them still labelled MS DOS) with version numbers 3.0 and above have versions of FDISK that still begin the first partition at 0,0,2 - from memory, I think Falcon DOS 3.1 is one such. This may give a tiny bit more usable disk space, but causes grief after a Stoned strike. > 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. Unfortunately, this implies that recovering from Stoned on such a disk is much simpler than it really (usually) is. FAT#2 is not "used" by DOS, in that all DOS file allocation work is done on the basis of FAT#1, but FAT#2 is maintained and updated by DOS. Not knowing exactly how this is done, I just shelled back to DOS and did a bit of FAT editing and file creation/ updating work and discovered that with 3.3 and a 20 Meg HD not all of the FAT is held in memory by DOS (not surprising given that it is about 50 sectors - with floppies I think all of FAT#1 is held in RAM). Any alterations to the file structure are saved to both copies of the FAT, but only the modified sectors are written out to disk. That last point is important - when the FAT is updated not all of FAT#1 is copied to FAT#2, only the changed sectors are copied. What this means for a Stoned HD is that if there has been *NO* file creation, deletion, or updating that affects the area of the disk *near* (sorry, can't be specific) the part of the disk that is mapped by the 6th sector of FAT#1, you can recover from Stoned by copying the sector at 0,0,7 (the original MBR) back to 0,0,1 and then copy the sector in FAT#2 that corresponds to FAT#1's 6th sector back to 0,0,7 (exactly which sector will depend on disk size, and possibly on whether the disk has 12 or 16 bit FAT's). So Padgett's recovery scheme only works if you happen to discover your HD is infected between the actual infection (booting from an infected floppy) and the first attempt to create or update a file, which results in the 6th sector of FAT#1 being updated (at which point the Stoned code is copied to FAT#2). PLEASE NOTE: Whilst the FAT handling is the same, the above advice about disinfecting a Stoned HD *ONLY* applies to disks which were FDISK'ed with an "old" version of DOS - i.e. where FAT#1 starts at the sector after the MBR. On other HD's it is usually just a matter of copying the sector at 0,0,7 back to 0,0,1. > 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. Yes, but note my rider above, about what is an "old" version of FDISK. If your HD is defragged then recovery from Stoned on a system prepared with "old" versions of FDISK is simple and relatively straightforward, even if both FAT's do get corrupted. - --------------------------------------------------------------------------- Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. Internet: n.fitzgerald@csc.canterbury.ac.nz Phone: (64)(3) 642-337
LBA002@PRIME-A.TEES-POLY.AC.UK (04/17/91)
We are having problems with STONED here at Teesside Polytechnic. We can detect it on our hard disks using SCAN and then get rid of it using CLEAN, although we can detect it on floppies CLEAN hangs when we try to get rid of it and the floppy is subsequently unusable. The weird thing is that the floppies don't have any programs on them, the particular case I dealt with just had 3 disks of wordstar files. Does STONED scramble the FAT? Can it "hang around" in memory so that SCAN reports the A drive as being infected although it is not on the floppy in the A drive? Can STONED scramble the FAT of a floppy in the A drive from the C drive or from memory? Any help gratefully received. Rgds, Iain Noble - ----------------------------------------------------------------------------- Iain Noble | LBA002@pa.tp.ac.uk | Post: Main Site Library, JANET: LBA002@uk.ac.tp.pa | Teesside Polytechnic, EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL | Middlesbrough, INTERNET: LBA002%pa.tp.ac.uk@cunyvm.cuny.edu | Cleveland, UK, TS1 3BA UUCP: LBA002%tp-pa.ac.uk@ukc.uucp | Phone: +44 642 342121 - -----------------------------------------------------------------------------