Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!sun-barr!lll-winken!iggy.GW.Vitalink.COM!widener!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: Mutation of Stoned/Implications for self check boot sectors(PC)
Message-ID: <0004.9104081309.AA03138@ubu.cert.sei.cmu.edu>
Date: 5 Apr 91 16:42:14 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 28
Approved: krvw@sei.cmu.edu

>From:    frisk@rhi.hi.is (Fridrik Skulason)

>I think somebody may be confusing this with the practice of Zenith DOS
>(or at least some versions of it) to write to the DOS boot record -

Our experience with Zenith XT class machines (model 158 & 159) was that
they did write occasionally to the boot record (not the MBR) as Frisk says.
This action seemed to occur with Zenith DOS 3.0 through 3.2 and the location
written to varied with the O/S but was inside the "reserved" area of the boot
record.

As with Frisk's software, this surfaced when we began installing integrity
checking mechanisms in our PCs last year and started getting changes flagged
on each boot, before we had the checking software "fixed" to recognize that
it was dealing with a Zenith (ATs & 386s did not exhibit this).

Since then, I have been told that early HP Vectras are likely to exhibit this
same condition. For more detailed discussion, I posted a number of items to
Virus-L last year concerning this.

Possibly, the confusion seems to come from the number of different names
applied to the "Master Boot Record" (cyl 0 hd 0 setor 1) which contains both
executable code and the partition table. The DOS Boot Record (first sector
of any DOS partition - only the record of the partition marked "active" is
executed) is something else entirely. The DOS Boot Record can be accessed
with a "load" (L) command from DEBUG. The MBR cannot.

							Padgett