FDISK /MBR is often suggested as a solution for fixing a virus attack.
One “cure” for partition sector viruses suggested by people who think they know what they are doing is the FDISK command using the parameter /MBR. But, understand that there are good reasons why the /MBR parameter was undocumented (it’s largely known now). It is dangerous.
The following [somewhat edited] detailed description was posted to comp.virus by Nick FitzGerald and is used here with permission. Please do not further use the material without obtaining your own permission to use it.
<Start quote>
Before describing what can to wrong, let’s first see what the command does…
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 operating system, 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 configuration 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 operating systems) then analyze the partition table to find a primary, active DOS partition, and, if found, (there are other conditions depending on the DOS version among other things) the first sector of that logical partition (the operating system boot sector) is loaded into memory and execution passes to it (and that traditionally bootstraps the operating system 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 the DOS 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.”
Now, 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.
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 Information Technology professional, I cannot conscientiously 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 go wrong and what happens:
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 DOS to interpret the file system, the “driver” is usually stored in the “wasted space” on track one (after the MBR) I referred to earlier. (A dual-boot MBR, e.g., OS/2, is another example that might fit into this category.)
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 (after all, 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?)
A virus that does not preserve the original partition table in the right place or that encrypts it.
How many people do we get here [posted in the newsgroup comp.virus] 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…).
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 above.
Such large disk drivers (which are effectively a software BIOS extension) are quite common. (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–after all, 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.
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.
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 disease!
Some antivirus (or general “system integrity”) software may have loaded a special MBR to allow itself to check for possible MBR infection/change attempts.
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 of your hard drive until the system is reinstalled/reconfigured.
A currently unimplemented virus attack I will not describe in detail here.
I know of a boot virus attack that has only been partially implemented in a real world 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).
I could have named examples of the first five, 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.
Now you understand why FDISK/MBR is DANGEROUS!
<End quote>
Bottom line:
Don’t Use FDISK /MBR!
What can you do? Use some sort of utility to make a backup copy of the critical areas on your disk and save those copies to a recovery floppy. There are a number of commercial utility products (and even some anti-virus software) that will do this for you and, if you care to experiment and search some, even some free ones. No specific recommendations here except to DO BACKUP THE MBR.
Summary
- Do I have to repeat? DO NOT USE FDISK /MBR.
 Miscellaneous Pages |
|
 |
 |
| DOS Boot Sector | False Authority Syndrome |
Comments from original:
mike
Said this on 2009-11-21 At 02:16 pm
hello, well i read every thing you wrote, and i have somthing to say, it might not be clear and thats becoz its not (for me i guesse).
so, the problem is that i was installing gentoo linux on a partition i my maxtor 80gb, and there was pc linux on the first partition, and GRUB….so i havint got the time to continue gentoo installation and i wanted to putt my hard disk (ata) on another pc, so i worked with fdisk and i partitioned my the drive in gentoo live cd console.
after a while (AND STILL DDNT FINISH THE SETUP)
#3
DaBoss
Said this on 2009-11-21 At 03:03 pm
In reply to #1
The page you are commenting on is more of a “why you should not” page than a “how to” page so it’s not surprising that it did not tell you how to install multiple partitions and operating systems on a single drive. I have to admit that I’ve never done that and so have no personal experience to help you with. The errors you are getting in your other comment can be caused by many things. The BIOS may not be set correctly to recognize the disk. The disk itself may be bad (that was the case when I got similar messages awhile back). The controller may be bad either overall or relating to that particular disk. The cable may have small stress breaks in it from being changed multiple times. Etc. See if the diagnostics that should have come with the drive can recognize the disk at least as a starting point. If you don’t have the diagnostic program(s) then go to the manufacturer’s website and look in the support section for a download. Most all have those for their drives.
#4
mike
Said this on 2009-11-22 At 06:25 am
In reply to #3
hello DABOSS and exuse me coz i have commented here (2 times), i know that im out of the subject, butt i thought that the persone that will comment on it will know what im talkin about and is experienced about mbr functions. ? know what im talkin about.
so what im trying to say is tha my hard disk is seein in all the programes i can even make partitions and create folders on them..butt i cant boot…so i filled the first sector with zeroz, after a low level format…and the first sector still having problems…sometimes i can read ???? and somtimes i can read it and he have very unfamiliar codes and im sure they ??? mean any thing…so my final question is,,,,:
is there any way the hard disk can be failing only on the first sector and the fail is a virus or can be a physical damage to it, (and i dt here any wierd sound)?
as is it possible, in dos not other operating systems, or without the use of grub and lilo, is it possible to replace the first boot sector and let the hard disk skip it…..thank you verry much. gd luck in furthure projects.
#2
mike
Said this on 2009-11-21 At 02:18 pm
hello, i have tryed every single software in windows pe minicd, nothing worke….
im getting, partition table read error, mbr read error, sector 0 read error, hard disk i/o read error…and much more….was is that!
thank you in advance..
#5
Tony
Said this on 2010-02-26 At 01:29 pm
DaBoss is spot on with his advice. The FDISK/MBR command sucks big time. Can anyone help me out. I will try to cut the story short. The hdd in my old machine is paritioned as an ntfs file system. The machine really sucked big time, following power on you could make a cup of tea come back and the machine would still be trying to boot. Anyway I’ve recently aquired a more up to date pc from a friend. I’ve since installed a new disk drive and upgraded the memory and it works like a dream. I tried to copy the data on my old pc to an external usb but it kept freezing up. I took out the hard drive from the old pc and installed it in my new pc. I set it up as cable select on the second ide master channel. My dvdrom is also setup as cable select on the second ide slave channel. Everything worked like a dream first time, the machine came up and recognised the new hard drive straight away. I was even able to go over to the second hard drive and everything seemed to work okay. My partner was very impressed as there is important data on the drive. She tried to access a word document from the second hard drive and the pc just froze. I then had to reboot the pc and the file system was not longer recognised on the second hard drive. Windows just kept asking if I wanted to format the drive. I’m running Windows XP Professional. Anyway I read about the fdisk /mbr command. Booted from a windows 98 bootable floppy, issued the dreaded command and now I’ve totally screwed the drive. I’ve also tried booting from the original XP installation CD and dropping to the recovery command prompt issued the fdisk /mbr command from the recovery prompt but to no avail. Can anyone please help. Yes I know I’m an idiot for not reading up on the issue but hey we all make mistakes. Many thanks, any help greatly appreciated.
#6
DaBoss
Said this on 2010-02-27 At 11:13 pm
In reply to #5
Can’t say for certain how to access the drive but have you at least checked the DOC file you accessed? Use one of the on-line scanners to see if it has been somehow infected.
Two are listed on this page…
If infected the beast may have attacked the hard disk (depending on which beast it is).
Also, consider looking around various anti-virus sites. I seem to recall some have downloadable boot records which can replace one.
Finally, maybe some undelete software might be able to read the disk structure at the lowest level.