Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Tuesday, May 31, 2011

The master boot record in NT5.x

Source (excerpts) Thanks a lot for the best info!
This MBR code is installed on blank hard drives when Disk Management is used by a Windows™ 2000, XP or 2003 OS.
[When dealing with Dynamic Disks, the partition type is set to 42h and the data in the Partition Table may become useless!]
Note: Like all other code presented in this series, this MBR code could still be used to boot any OS on an x86 PC if it meets the conditions listed here*.

Windows 2000 ( NT5.0 )
Windows XP ( NT5.1 )
This page examines the MBR code most likely to be found in a Microsoft® Windows™ 2000, XP or 2003 installation. All of these operating systems contain the same exact MBR code embedded in files such as DMADMIN.EXE (there are a few more places we didn't list above where either the MBR code or Boot Records can be found; if you're interested in that, read our Where's the code? page). This code will be written to Cylinder 0, Head 0, Sector 1 of a Hard Drive by various OS routines, such as the Disk Management Console,  if  the drive does not already have an existing MBR sector (recognized by Windows®) when it is installed. [Note: These OSs will still write data to the MBR sector when required (see our Disk Signature comments below).]
For Windows™ XP (SP2), the MBR code is contained inside the file:
C:\WINNT\system32\dmadmin.exe
This file which is "224,768 bytes" and has a Modification Date of "Wednesday, August 04, 2004, 4:00:00 AM" is described as a "Logical Disk Manager service process" with "File version: 2600.2180.503.0" and:

"Copyright © 1985-2000 Microsoft Corporation. All rights reserved.
Portions Copyright © 1997-2000 Veritas Software. All rights reserved."

The MBR code itself is found between offsets 34E28h through 35027h (of which only the last 80 bytes are shown here):

Figure 1. Note that the bytes "2c 44 63"are part of the MBR's image file in dmadmin.exe
    Under the original Windows™ XP, the MBR code was in the same file, but at offsets 2FFF8h (196,600) through 301F7h (197,111) for its August 23, 2001 5:00:00 AM version of 204,800 bytes.
 The following is a disk editor view of how the bytes in this MBR are stored on your hard drive's first sector; that's Absolute (or Physical) Sector 0, or CHS 0,0,1. (See Examination of the Code below to find out where this data ends up in Memory when it's executed.)
 Absolute Sector 0 (Cylinder 0, Head 0, Sector 1)

        0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
 0000  33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C  3.....|.P.P....|
 0010  BF 1B 06 50 57 B9 E5 01 F3 A4 CB BD BE 07 B1 04  ...PW...........
 0020  38 6E 00 7C 09 75 13 83 C5 10 E2 F4 CD 18 8B F5  8n.|.u..........
 0030  83 C6 10 49 74 19 38 2C 74 F6 A0 B5 07 B4 07 8B  ...It.8,t.......
 0040  F0 AC 3C 00 74 FC BB 07 00 B4 0E CD 10 EB F2 88  ..<.t...........
 0050  4E 10 E8 46 00 73 2A FE 46 10 80 7E 04 0B 74 0B  N..F.s*.F..~..t.
 0060  80 7E 04 0C 74 05 A0 B6 07 75 D2 80 46 02 06 83  .~..t....u..F...
 0070  46 08 06 83 56 0A 00 E8 21 00 73 05 A0 B6 07 EB  F...V...!.s.....
 0080  BC 81 3E FE 7D 55 AA 74 0B 80 7E 10 00 74 C8 A0  ..>.}U.t..~..t..
 0090  B7 07 EB A9 8B FC 1E 57 8B F5 CB BF 05 00 8A 56  .......W.......V
 00A0  00 B4 08 CD 13 72 23 8A C1 24 3F 98 8A DE 8A FC  .....r#..$?.....
 00B0  43 F7 E3 8B D1 86 D6 B1 06 D2 EE 42 F7 E2 39 56  C..........B..9V
 00C0  0A 77 23 72 05 39 46 08 73 1C B8 01 02 BB 00 7C  .w#r.9F.s......|
 00D0  8B 4E 02 8B 56 00 CD 13 73 51 4F 74 4E 32 E4 8A  .N..V...sQOtN2..
 00E0  56 00 CD 13 EB E4 8A 56 00 60 BB AA 55 B4 41 CD  V......V.`..U.A.
 00F0  13 72 36 81 FB 55 AA 75 30 F6 C1 01 74 2B 61 60  .r6..U.u0...t+a`
 0100  6A 00 6A 00 FF 76 0A FF 76 08 6A 00 68 00 7C 6A  j.j..v..v.j.h.|j
 0110  01 6A 10 B4 42 8B F4 CD 13 61 61 73 0E 4F 74 0B  .j..B....aas.Ot.
 0120  32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 49 6E 76 61  2..V.....a..Inva
 0130  6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61  lid partition ta
 0140  62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E  ble.Error loadin
 0150  67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74  g operating syst
 0160  65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61  em.Missing opera
 0170  74 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00  ting system.....
 0180  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
 0190  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
 01A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
 01B0  00 00 00 00 00 2C 44 63 A8 E1 A8 E1 00 00 80 01  .....,Dc........
 01C0  01 00 07 7F BF FD 3F 00 00 00 C1 40 5E 00 00 00  ......?....@^...
 01D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
 01E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
 01F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA  ..............U.
        0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
    The first 300 bytes (000h through 12Bh) of this 512-byte sector are executable code and the next 80 bytes (12Ch through 17Bh) contain error messages. The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh); data in the Table area will depend upon the size, structure and file systems on each hard disk. The sector ends with the Word-sized signature ID of AA55h (often called the sector's Magic number); on PCs using an Intel (or x86 compatible) CPU, hex Words are stored with the Low-byte first and the High-byte last. The remaining 66 bytes (between the Error Messages and the Partition Table; 17Ch through 1BDh) begin as padding (which are first filled with all zero-bytes by Win 2000/XP); with the exception of the three bytes (2C 44 63) at 1B5h through 1B7h (described in detail below) that are actually part of the dmadmin.exe file (see Figures 1 and 2 above). However, after a drive has any of the NT-type Operating Systems installed and running, they will write a Disk Signature in the MBR. The four bytes from offsets 1B8h through 1BBh are called the Windows™ 2000/XP Disk Signature or NT Drive Serial Number (The digits shown in the disk editor view above are only an example and could be anything; but we've noticed a high tendency under Windows 2000/XP for the first and third and the second and fourth bytes to be the same digits, as in the example above: A8 E1 A8 E1. In other NT-type MBRs, we've observed signatures such as these: "87 04 88 04" and "6B 40 6C 40" and "84 1A 85 1A". So there's a high probability that at least the 2nd and 4th bytes will almost always be the same and that some kind of algorithm is being applied by the OS to create these digit patterns. However, we've also seen NT-type MBRs with no discernible pattern at all, such as: "ED 19 EB BF" and "80 EF A0 FB," so we have no idea exactly how these OSs 'decide' to write these kind of Disk Signature digits versus those having patterns as seen above.) See here for details on Disk Signature use in the Registry! The three bytes at offsets 1B5h through 1B7h ("2C 44 63") are used by Microsoft Windows™ for a very specific purpose; for English versions of Windows 2000/XP, you'll always see these same Hex values ("2C 44 63") in the MBR. They're used by the MBR code to display Error Messages on your screen. But for those using Windows™ with a different language, their MBRs may have different values in the second and third bytes depending upon how many characters are in the error messages. If you look in the code section below, starting at offset 063Ah (instruction: "MOV AL,[07B5]"), you'll see these three bytes are used to reference the offset in Memory of the first byte of each Error Message that can be displayed on screen at boot up: 072Ch, 0744h and 0763h. Since the code will always be the same, the first offset (072Ch) should never change. If you had the German (Deutsch) version of Windows™ 2000 or XP, your error messages and message offsets would look like this:
    0120 32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 55 6E 67 81  2..V.....a..Ungü
    0130 6C 74 69 67 65 20 50 61 72 74 69 74 69 6F 6E 73  ltige Partitions
    0140 74 61 62 65 6C 6C 65 00 46 65 68 6C 65 72 20 62  tabelle.Fehler b
    0150 65 69 6D 20 4C 61 64 65 6E 20 64 65 73 20 42 65  eim Laden des Be
    0160 74 72 69 65 62 73 73 79 73 74 65 6D 73 00 42 65  triebssystems.Be
    0170 74 72 69 65 62 73 73 79 73 74 65 6D 20 6E 69 63  triebssystem nic
    0180 68 74 20 76 6F 72 68 61 6E 64 65 6E 00 00 00 00  ht vorhanden....
    0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    01B0 00 00 00 00 00 2C 48 6E                          .....,Hn
          0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
    Now that you know what the bytes at offsets 1B5h through 1B7h are used for, you could change these error messages to display whatever you wish (as long as they all fit into the space between offsets 12Ch and 1B4h) by counting their character lengths and using a disk editor on the MBR sector to make the appropriate changes.
Disk Signatures in the Registry
Searching for my Disk Signature (as "a8 e1 a8 e1") in the Registry taught me a valuable lesson: You cannot trust Microsoft's Registry Editor to find all your data! Although we entered the values both with and without spaces between them, and also tried both upper and lower case characters, their editor never found the very clearly displayed Values in our Registry, under the Key:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

which also contains information (in the form of GUIDs) to reference all logical drives (including removable
storage, such as USB devices) ever connected to the computer!
Note, however, that the Disk Signature (or NT Serial Number) is actually a four-byte Hex Word, so for our example Signature above, upon searching for "E1A8E1A8" Hex, the Registry editor did show it being used in these keys:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\STORAGE\Volume
and even
HKLM\SYSTEM\ControlSet001\Control\DeviceClasses\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

among many others. Keys using Disk Signatures contain a wealth of information about your hard disk's partitions! For example, one of the “SymbolicLink” Key Name's value (that begins with \\?\STORAGE#Volume#1& ) continues as:

30a96598&0&SignatureE1A8E1A8Offset7E00Length1AE735E00#

followed by the GUID {53f5630d-b6bf-11d0-94f2-00a0c91efb8b} which you'll see in most of these key values. I'm not exactly sure how the digits in red are used, but I did find them as the Key Value for the Name ParentIdPrefix under the Key: HKLM\SYSTEM\CurrentControlSet\Enum\Root\ftdisk\0000.
Interpreting the Data: The "Signature " value should be obvious. The "Offset " value is the Hexadecimal equivalent of the number of bytes before the beginning of this partition; thus, 7E00h is 32,256 bytes or 63 sectors (at 512 bytes/sector) which also means this is the first partition on the disk (every Basic Disk leaves the first track unused; except for the MBR sector, so its first partition always begins at CHS 0,1,1), and the "Length " value is the exact number of bytes in the whole partition (1AE735E00h = 7,221,763,584 bytes for about a 6.7 GiB partition size).

After executing the POST (Power-On Self Test), the BIOS loads this sector into memory at 0000:7C00 (as it does any MBR) then transfers control to this code.
Unlike an OS boot sector though, this code must first copy itself into another area of Memory. This is necessary because the code must also load the Boot Sector of the Active Partition into the same area of Memory that it was first loaded into! But just as we saw for the Windows 98 MBR, this code doesn't copy any bytes it has already executed before jumping to the new location in Memory; it copies only the 485 bytes from 7C1Bh through 7DFFh to Memory locations 0000:061B through 0000:07FF, rather than simply copying the whole block of 512 bytes to 0000:0600 and following as the the old Standard MBR code did! For the first 25 instructions, this code is quite similar to that of a Windows 98 (FAT32) MBR, but then diverges into completely new routines.

No comments: