18.8   FDISK and Master Boot Record

Article 27821 of comp.virus
From: Nick FitzGerald <n.fitzgerald@csc.canterbury.ac.nz>
Date: 3 Jan 1997 23:20:18 -0000
X-Digest: Volume 10 : Issue 2

Achim Trosien <71124.2716@CompuServe.COM> wrote:

  --Jan 2. Ken van Wyk (I think so) wrote:

  'twas me actually\ldots I've been moderator for the last 50.5 weeks ...

  -- -- [Moderator's note:  All due respects to Ian, but
  -- -- {\bf DO NOT EVER} use FDISK/MBR unless you
  -- -- {\bf really} know what you are doing.]
  -- 
  -- I have never heard of "fdisk /mbr" causing any damage,
  -- why should it !?!  I have tried it out on various computers
  -- with various equip. without any probs!!
  -- JUST CURIOUS ...

It may be best to answer this question by ensuring we understand what the command does, then work through the possible situations where it will ``fail'' ...

To understand what it does, first we have to get some terminology clear. The Master Boot Record (MBR) of a PC's hard drive is the very first physical sector on the disk (0,0,1 in head, cylinder, sector terms). There are some special things about the MBR. It contains (at a minimum) some executable code to start the bootstrap of the OS, a 64 byte data area known as the partition table and a two byte signature (that some BIOSes reputedly do not check for).

Assuming that the basic BIOS hardware integrity tests pass and the BIOS config is set to allow booting from a hard drive, at power-up the MBR will be copied from the disk and execution passes to the beginning of the MBR. Standard DOS MBRs (they have slightly different code for different DOS versions and other OSes) then analyze the partition table to find a primary, active DOS partition, and if found (there are other conditions depending on the DOS version and\ldots) the first sector of that logical partition (OS boot sector) is loaded into memory and execution passes to it (and that traditionally bootstraps the OS proper). This may seem to be getting away from the MBR, but you also need to understand something about the typical disk layout of these structures.

Since DOS 3.0 (Padgett?) the OS boot sector has conventionally started at the first sector of a track (often 1,0,1, but never count on it). This has meant that all of the first physical track except the MBR (first sector) is ``wasted space'' ... .

On to what FDISK/MBR does\ldots. Normally it overwrites what would be the DOS pre-bootstrap code part of the MBR, leaving the partition table and signature mentioned earlier. I have not tested this, but people who wouldn't lie to me about such things have told me that if the partition table is completely blank (full of zeroes) and/or the signature bytes are the wrong values (I can't remember exactly what I was told and haven't tested for myself) then FDSK/MBR may be a bit more ruthless\ldots.

Generally though, it sounds fairly harmless, right?? ``Generally'' it is, and that explains why on many, many machines thousands of people have ignorantly done no damage to their drives\ldots.

The problem is, there are an awful lot of machines where my earlier description of the MBR contents and the layout of things on the first track of the hard drive do not match what FDISK is programmed to assume, and, as an IT professional, I cannot consciencably recommend something that can trash someone's disk without giving them a clear understanding of the possibility of making matters worse. This is why I refuse to post submissions that basically just say ``Try FDISK/MBR'' in response to ``"How do I clean <some boot virus>?'' questions.

Examples of things that can have gone ``wrong'':

1. A security system that does on-the-fly encryption and decryption of the hard drive may be installed with a pre-OS "driver" loading from the MBR bootstrap code. Such a scheme, being non-standard, has its own special MBR bootstrap code. Such code is typically much more than one sector (512 bytes) and as there is no OS to interpret the file system, the ``driver'' is usually stored in the ``wasted space'' on track one (after the MBR) I referred to earlier.
2. A virus that does not preserve the original partition table in the right place or that encrypts it.
3. A pre-OS driver to support ``large drives'' has been installed so a drive greater than 528MB can be used in a machine with an old BIOS. The mechanism for this is much the same as in \#1.
4. A virus that leaves the partition table in place, but stores critical viral variables in what is normally the bootstrap code portion of the MBR. A particularly nasty possibility here is that a virus may be running on-the-fly encryption/decryption of the drive's contents using an encryption key that was randomly generated at infection time\ldots
5. Some antivirus (or general ``system integrity'') software may have loaded a special MBR to allow itself to check for possible MBR infection/change attempts.
6. A currently unimplemented virus attack I will not describe in detail here\ldots

I could have named examples of 1-5, though the risk in doing that is people who do not know better will think they are the *only* possibilities, rule them out and blunder on\ldots

Just in case it is not clear at this point, all of these things replace (part of) the ``normal'' bootstrap code in the MBR with their own code and/or data and in some way critically modify the function of the bootstrap process.

So, what ``threat'' does running FDISK/MBR present in each of the above cases?

1. You will lose access to your drive, at least until appropriate actions can be taken to reinstall the encryption software. Well-designed software of this kind will have been designed with data-integrity as well as security in mind so should have install options to allow reinstalling over a ``corrupted'' setup. Once FDISK/MBR has been run, the hard drive will most likely be completely inaccessible (afterall, this is the point of most disk encryption schemes!). Given someone was ignorant enough to corrupt it in the first place, what do you reckon the chances are they will have any idea they had a disk encryption scheme in the first place?? (Or, at least, what are the chances they know how to have the installation fixed?)
2. How many people do we get here per year with horror stories of ``losing their C: drive'' after FDISK/MBR against a Monkey-infected drive?? (or several other quite common viruses that also do not preserve the MBR in place?). These are usually quite easily fixed once someone who really knows what they are doing gets involved (unless the ``expert'' who just trashed the disk insists on continuing\ldots).
3. Such large disk drivers (which are effectively a software BIOS extension) are quite common. I mean--you've hardly been able to buy new drives smaller than 750MB for over a year, so anyone with a machine more than about 18 months old who has ``upgraded'' their hard drive is likely running one. FDISK/MBR removes the driver that correctly allows access to cylinders 1024+, but the effect of removing it varies depending on all kinds of variables to do with the machines BIOS, the way the drive was partitioned, etc. As with encryption systems, many users of such large disk drivers have no idea that they are running one--afterall, computers are just ``tools'', you don't have to understand how they work to use them\ldots. Because the driver load mechanism is similar to the security products mentioned in \#1, similar comments apply about fixing these should they be damaged by an unwanted FDISK/MBR.
4. At least one family of ``in the wild'' viruses--One_Half--does what I described here. FDISK/MBR against a drive infected with a One_Half variant (or any future/unknown virus that uses a similar ``trick'') will remove the MBR infection (One_Half is multi-partite, so it doesn't necessarily clean One_Half completely), BUT leaves you with a hard drive whose contents are partially encrypted with a now unknown and irretrievable key. This is definitely a case of the ``cure'' being worse than the diesease!
5. FDISK/MBR against such integrity systems has a wide range of effects depending on the design of the system, from simply warning you of a change to the MBR to completely locking you out from your hard drive until the system is reinstalled/reconfigured.
6. I know of a boot virus attack that has only been partially implemented in a realworld virus to date, where FDISK/MBR would apparently clean the virus, but on rebooting from the hard drive, the virus would be able to reinstall itself AND would ``know'' that a (clumsy) disinfection attempt had been made against it. If the virus' author was so inclined, this could be used as a trigger for some nasty payload (like reformatting your drive\ldots).

Now, ask yourself how many of these things (that many of you were previously unaware of) can you 100\% accurately diagnose via Email or through Usenet News postings?

Now you understand why FDISK/MBR is DANGEROUS?

As Bruce Burrell has been saying for a looooong time:

\hspace{0.5in} Just say ``No'' to FDISK/<mumble>

But why did it become so popular, and why is knowledge of it so widespread? Well, way back when about the ``worst'' virus you could expect to see on a realworld PC was Michaelangelo, it was relatively safe. There were no (ITW) viruses that didn't preserve the partition table (though the Empire and Monkey families soon changed that), there were no ``load from the MBR bootstrap'' large disk drivers and encryption, security and integrity systems that loaded from the MBR bootstrap were not at all common (not that they are now, either, but I'd hazard much less common than they are now\ldots). DOS v5 was quite readily available and it was discovered that, in keeping with ``tradition'' MS had built in several ``neat'' but undocumented options for various standard utilities. One of these was the /MBR option for FDISK, though this was a standard, documented feature of some earlier OEM DOSes (Toshiba, Compaq, Zenith and others actually licensed the code from MS and were able to make machine/system-specific modifications--from memory at least one of the sub-versions of Compaq DOS v3.31 documented the /MBR option). As with such things, these ``cool secrets'' were spread around by word of mouth, Email, Usenet and BBS postings, etc, etc, as knowing such secrets imparts some special status in a geekoid techie community\ldots.

Unfortunately, about the time responsible IT professionals wanted to kill the notion that FDISK/MBR was a general-purpose AV measure for MBR infectors, knowledge of it had reached critical mass\ldots. (Spaf's comments about Uenet and elephants come to mind!)

Lastly, I am considering removing mention of it from the FAQ for this list/group (at a minimum, I'll be changing our current coverage of it to strengthen the ``only do this if you can afford to make things much worse'' warning).

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
n.fitzgerald@csc.canterbury.ac.nz  TEL:+64 3 364 2337, FAX:+64 3 364 2332
            Virus-L/comp.virus moderator and FAQ maintainer
  PGP fingerprint =  2E 7D E9 0C DE 26 24 4F  1F 43 91 B9 C4 05 C9 83

Article 27829 of comp.virus
From: "James R. Bunch" <jbunch@primenet.com>
Date: 6 Jan 1997 08:11:48 -0000
X-Digest: Volume 10 : Issue 3

Nick -- I'd like to add one more circumstance to your list:

On any system that uses a dual-boot capability (OS/2 comes to mind), fdisk /mbr can ``replace'' the non-DOS bootstrap code with DOS code. Obviously not a Good Thing! It should be recoverable without too much effort if you know how the specific OS implements dual-boot. Otherwise it's a real pain in the \dots.

- ----------------------------
James R. Bunch         "A Byte is a terrible thing to waste ...
jbunch@primenet.com     ... a MByte 1048576 times worse"

PGP Key available via finger
PGP Key fingerprint =  B5 31 10 77 BF B0 FD B2  10 54 CB E6 13 7C 26 58
- -----------------------------

Article 27869 of comp.virus
From: W.R.Dickson@soton.ac.uk
Date: 7 Jan 1997 07:02:37 -0000
X-Digest: Volume 10 : Issue 4

Another case where fdisk /mbr is a bad idea (or at least must be used with some caution) is where an older PC with a non-translating BIOS is configured to use a large EIDE hard disk via a driver such as ``EZ-Drive''. This patches itself into the boot code (AFAIK) and if this driver is not loaded then the partition becomes unreadable (and, I imagine, susceptible to damage if any attempt to write to it is made - the ``partition table'' read by the old BIOS does not reflect the actual drive and so is effectively corrupt.) fdisk /mbr will overwrite the driver code.

Hmmm... so would even a ``harmless'' MBR virus cause damage to such a system if it loaded before the driver?

Regards

Will Dickson.