Modifying the MBR of Windows

Question

I need to modify the MBR of Windows, and I would really like to do this from Windows.

Here are my questions. I know that I can get a handle on a physical device with a call to CreateFile. Will the MBR always be on \\.\PHYSICALDRIVE0? Also, I'm still learning the Windows API to read directly from the disk. Is readabsolutesectors and writeabsolutesectdors the two functions I'm going to need to use to read/write to the disk sectors which contain the MBR?

Edit from from what I've learned on my own. The MBR will not always be on \\.\PHYSICALDRIVE0. Also, you can write to the bootsector (at least as Administrator on XP) by call CreateFile with the device name of the drive that contains the MBR. Also, you can write to this drive by simply calling WriteFile and passing the handle of the device created by calling CreateFile.

Edit to address Joel Coehoorn. I need to edit the MBR because I'm working on a project that needs to modify hardware registers after POST in BIOS, but before Windows will be allowed to boot. Our plan is to make these changes by modifying the bootloader to execute our code before Windows boots up.

Edit for Cd-MaN. Thanks for the info. There isn't anything in your answer, though, that I didn't know and your answer doesn't address my question. The registry in particular absolutely will not do what we need for multiple reasons. The big reason being that Windows is the highest layer among multiple software layers that will be running with our product. These changes need to occur even before the lower levels run, and so the registry won't work.

P.S. for Cd-MaN. As I understand it, the information you give isn't quite correct. For Vista, I think you can write to a volume if the sectors being written to are boot sectors. See http://support.microsoft.com/kb/942448

Pedant

Answer 1

Once the OS is started the MBR is typically protected for virus reasons - this is one of the oldest virus tricks in the books - goes back to passing viruses from floppy to floppy.

Even if it wasn't restricted, you have to write low level code - it isn't part of the file system, but exists on a specific location on the hard drive.

Due to that, you pretty much are restricted to writing low level (most programs implement this in assembly) or C code targeting 16 bit DOS.

Most of these programs use the BIOS interface (13h, I believe) to access the sectors of the disk directly. You can access these in C using some inline assembly, or compiler provided interfaces. You will generally not get access to BIOS without the cooperation of the OS, though, so your program, again, will be restricted to DOS. If you can access these you're almost home free - the nice thing about BIOS is you don't have to worry about what type of HD is in the system - even RAID cards often insert themselves into the BIOS routines so they can be accessed without knowing where in memory the ATA or SATA controller is, and executing commands on that low level.

If you absolutely must access it within an OS, though, you pretty much have to write a device driver to access the BIOS or the memory space where the HD controllers exist. I wouldn't recommend it, though, as this is very tricky to deal with - modern computers put the HD controllers in different spots in memory, with different IRQs, and each chipset has become a little more esoteric because they can provide a minimum interface to bios for bootup, and then a specific driver for Windows. They skip all the other interface niceties that would be considered compatible with other controllers because it's more expensive to be compatible.

You may find that at the driver level inside windows you'll have methods for accessing the drive sectors directly (or pseudo directly), but again, they are likely very well protected due to the aforementioned virus issues.

Good luck!

Provisional

Answer 2

Modifying the bootloader is bad, bad idea. Here are just a few of the possible gotcha's:

• it will potentially kill full disk encryption products (Truecrypt, PGP, Vista's BitLocker, etc)
• it will potentially trip up AV products (scaring users)
• it will potentially kill complicated booting scenarios (chained boot loaders, etc)
• it will kill off the chain of trust when using the TPM module (because it checks the MBR for change before executing it)
• direct disk access is not allowed starting from Vista (only using drivers)

Alternatives (like modifying the hardware register during the Windows bootup via a driver which is set to load at boot time or after Windows has booted) should really be considered. If the modification is as simple as writing to a port, ie:

OUT AX, BL

then drivers exists for all versions of Window which can do this (reading/writing a value from/to a certain port) which can be called from user mode.

Wellbred

Each bootsector code programmer should know the list of possible issues. Thanks! – Fearful

and would you say these gotchas apply to win 9x's fdisk /mbr, and xp's fixmbr Very few have full disk encryption.. Tripping an AV is not even a concern if the MBR is corrupted, or at all. Most people don't have complicated boot scenarios and if they did i'm sure if they ever needed to fix their MBR then fdisk /mbr or fixmbr won't cause more havoc than they have.. – Merchant

Answer 3

Maybe a PXE boot scenario could help you? Simply boot on your crafted PXE image which modify the hardware registers you need to modify, and then return the control to the Master Boot Record or to the active partition's boot record.

This way you don't have to modify the boot records.

Haroldharolda