From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: Boot Record Disinfection (DOS) (PC)
Date: 7 Apr 92 14:40:58 GMT

Posted for Roger Riordan

>  In Australia dealers often
>booted PCs from infected master disks before partitioning the
>hard disk.  CLEAN puts back the whole of the hidden MBR, including
>the now incorrect partition information.

This is why my FixMBR takes a different approach, looking at the P-Table,
determining its validity, and (preferably though at the users option)
replacing all of the code. The major differences between FDISK/MBR and
FixMBR is that the SafeMBR code adds BIOS integrity checking to the boot
process and, unlike FDISK, FixMBR looks at more than just the first sector
for valid partition tables.

>With things like Stacker, etc, around we will be very wary of doing
>any more delving in the hardware.  If a virus crashes on 30 (or even
>50)% of PCs it will still propagate happily, but if our program
>crashes on one PC in 1000 we will get complaints about it.

Again, code operating from the BIOS level can do this kind of checking
without such risks (ask Rob Slade), it is only after DOS has loaded that
the path gets murkey. IMHO BIOS code can establish such hardware paths,
authenticate them, establish system integrity at this point, and pass such
information onto software loading after the OS.

Further, since disk compression drivers often make it impossible to check
they system files, boot record, MBR, or even CONFIG.SYS  safely or
reliably from the DOS level, such BIOS checking will become even more
necessary in the future (only been pushing it for two years now).

- ----------------------

Having said that, I would like to solicit some help. As you know FixFBR
is unbootable repair for floppy disk boot records. Like FixMBR, it does
not trust code on an infected disk, instead replacing the entire boot
record, generating the BPB from scratch if necessary.

My current project (code named "FixDBR") will complete the loop by
providing code replacement with virus detection to bootable disks
both hard and floppy. The code is complete and I have tested (so far)
with fourteen different DOS variants ranging from PC-DOS 2.10 to MS-DOS
5.0 and intermediate stops at Compaq, Zenith, & DRI.

What I have discovered is that unlike most MBRs where the termination
status is easy, Boot Records are liable to expect particular values to
be left in memory and in the registers. There is enough difference that
for example a boot record configured for Compaq 3.31 will hang a Zenith
3.30+ OS and turnabout even though both call their first system file
IBMBIO.SYS so a small custom "termination" module is necessary.

The problem is that while it can handle all OSs that I have seen, samples
are needed of the "off-brands" to ensure compatability. In particular,
I need the European "ERS" and "P16" variants (the first hidden file is
called ERSBIO.COM for the first and P16BIO.COM for the second. I do not
know if there is more than one variant of each or what DOS # they are
analogous to.

If anyone on V-L has copies of these, I do not need the whole thing
(though a formatted, bootable floppy with COMMAND.COM, FORMAT.*, and
DEBUG.* or equivalent would be welcome). What I need is:

1) Name of the Operating System
2) Ascii dump of the DOS boot record (NOT the MBR if from hard disk)
3) Name, size, and date of the first hidden system file (*BIO.COM or *IO.SYS)
4) Ascii dump of the first executable sector of the above file
   (may start with a Jump - I need the initial code that is executed).
5) When booted, what does the "ver" command return ?

UUencoded Zips are the easiest way to E-Mail. I can also handle TeleDisk
or SendDisk (can be very small if a newly formatted bootable 360k floppy
disk is used containing only programs (COMMAND, DEBUG, & FORMAT) described
above and then ZIPped).

In particular, I would appreciate such copies of those systems for which
a generic anti-viral remover (such as M-DISK) has *failed* OTHER than the
Zenith varients (I have them). In any event I should be able to release
a "beta" RSN.

						Warmly,
							Padgett

E-Mail:			padgett@tccslr.dnet.mmc.com
Surface Mail:    POB 1203, Windermere, Florida, USA 34786