fdisk /mbr == DAMAGE? (PC)
Achim Trosien
Jan 2. Ken van Wyk (I think so) wrote:
> [Moderator's note: All due respects to Ian, but *DO NOT* **EVER** use
> FDISK/MBR unless you *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 ....
regards,
Oliver
- --------------------------------------------------
<mailto:71124...@CompuServe.com | Oliver Trosien>
When Do You Want To Crash Today ? ;)
Nick FitzGerald
Achim Trosien <71124...@CompuServe.COM> wrote:
>Jan 2. Ken van Wyk (I think so) wrote:
'twas me actually...I've been moderator for the last 50.5 weeks...
>> [Moderator's note: All due respects to Ian, but *DO NOT* **EVER** use
>> FDISK/MBR unless you *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...) 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... 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...
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...
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...
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...
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...
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...).
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... 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...).
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:
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...). 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...
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... (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.fitz...@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
James R. Bunch
Nick FitzGerald <n.fitz...@csc.canterbury.ac.nz> wrote:
[snip of a very good write-up]
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 ...
- -
- ----------------------------
James R. Bunch "A Byte is a terrible thing to waste ...
jbu...@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
- -----------------------------
Nick FitzGerald
W.R.D...@soton.ac.uk wrote:
> 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
This is, in fact, one example of what I was referring to as "problem case
type 3" ("A pre-OS driver to support "large drives").
> 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?
The virus per se would probably not do any "damage" beyond the fact that
it had trashed (part of) the disk driver, though if it tries to write to
an arbitrary sector on the drive (a few try to write to a specific sector
or the last sector or two), it may do a bit more damage.
I did not specifically cover what could go wrong if a virus infected any
of those "non-standard" systems--I was solely focussing on the damage
FDISK/mumble can do in many "not unusual" situations *that it was not
designed to "know about"/deal with*.
I don't have time today (or maybe till June!) but I'll write a similar
(but possibly longer!) piece explaining all the complications we can add
by slotting a virus infection into all the non-viral compications I
already mentioned... (hmmmm--maybe I won't...)
Nick FitzGerald
John L Rinehart <jrine...@juno.com> wrote:
<<snip "problems" 2 and 4 from my earlier message>>
> My question is: what would be the correct procedure to recover from these
> two situations? I am currently using both F-PROT and McAfee. I have a
> clean boot disks for each. And I have a backup of the MBR on disk that
> can be restored. Would restoring the MBR from a backup cause the same
> problem as FDISK /MBR? thank you for your help.
In the case of 2 (MBR virus that didn't save the partition table "in
place"), this would likely restore normal functionality (but beware that
it could be a new virus with a twist like the one I detailed in point
6...).
In case 4 (virus like One_Half), you would restore "normal partitioning"
(which FDISK/mumble wouldn't), *BUT* you would not repair the other
damage. In the case of viruses like One_Half, you would have just
overwritten the only record of the number of cylinders the virus had
encrypted to date *AND* the key used for the encryption/decryption, so now
have a disk with an unknown number of irrecoverably encrypted cylinders.
I am independent and do not work for any AV company in any way.
The "correct" way to recover from *any* virus attack is to use good,
reliable, up to date AV software. "Hick" fixes you heard about on the net
are about as reliable as the modem virus story, the Good Times Email virus
warning and most MS software!
I do not believe that AV software is perfect, but to date I would say, on
balance, it is more reliable than any other method short of having a "pet
AV expert" to call on.
John L Rinehart
nick wrote:
>2. A virus that does not preserve the original partition table in the
>right place *or* that encrypts it.
>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...
My question is: what would be the correct procedure to recover from these
two situations? I am currently using both F-PROT and McAfee. I have a
clean boot disks for each. And I have a backup of the MBR on disk that
can be restored. Would restoring the MBR from a backup cause the same
problem as FDISK /MBR? thank you for your help.
regards, john
W.R.D...@soton.ac.uk
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
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.
Bill East
Nick FitzGerald <n.fitz...@csc.canterbury.ac.nz> wrote:
[in reference to large hard disks remapped to older BIOSes]
|> Hmmm... so would even a "harmless" MBR virus cause damage to such a system
|> if it loaded before the driver?
|
|The virus per se would probably not do any "damage" beyond the fact that
|it had trashed (part of) the disk driver, though if it tries to write to
|an arbitrary sector on the drive (a few try to write to a specific sector
|or the last sector or two), it may do a bit more damage.
Hmmmn... you mean like making the disk utterly unrecoverable?
When I went to try and retrieve a user's (large, remapped) disk
last year, I found that the data on the disk were gone... but
found two MBR virii on her floppy diskettes. Backup? The tape
drive was still in its box.
I'm not sure that the virii were what caused the problem, but I
suspect them, especially since she admitted to having booted with
one of them in the drive. And maybe someone better than I could
have recovered the disk - but no-one in our (large, talented) IT
department could.
Bill East : http://www.cris.com/~eastb/
ea...@cris.com : Protect your privacy...
PGP public key available at all keyservers
"Mi aerodeslizador esta lleno de anguilas"
Padgett 0sirius
The basic problem is that FDISK/MBR simply replaces the code portion
of whatever it is handed without changing the Partition table area. In
fact it makes only the most trivial check that there is a partition table
at all and not whether it is a valid one.
Way back in 1990 when I first wrote FixMBR, it performed a "samity" check
to determine if the partition table matched the BIOS information on the
hard disk and warn the user if there is a discrepancy. MicroSoft has
apparently never felt that necessary.
A. Padgett Peterson, P.E.
Cybernetic Psychophysicist
Totally Obsessed with TransOceanics
My other car is a Pontiac too
We also walk dogs
PGP 2.7 Public Key Available
David Zimmerman
In article <0032.01IE0Q...@csc.canterbury.ac.nz>,
Padgett 0sirius <pad...@goat.orl.mmc.com-antispam> wrote:
>The basic problem is that FDISK/MBR simply replaces the code portion
>of whatever it is handed without changing the Partition table area. In
>fact it makes only the most trivial check that there is a partition table
>at all and not whether it is a valid one.
>
>Way back in 1990 when I first wrote FixMBR, it performed a "samity" check
>to determine if the partition table matched the BIOS information on the
>hard disk and warn the user if there is a discrepancy. MicroSoft has
>apparently never felt that necessary.
The easiest way to correct the problem is with a product called Drive
Wizard MBR. Where most other "recovery" type products have the problem is
with the DDO's. This product will also convert the the drive to LBA. Info
can be found at "http://www.learningcurveinc.com/mbr.htm"