Recover a destroyed MBR

Materials:
Working complete PC
Blank Diskette
Student Diskette, "New Boot A Ver 2.0+"
Student CD-ROM, "Room 6359"
Objectives:
The student will become familiar with:
Determining that the MBR is damaged/destroyed,
using the BIOS INT 13h Interface to read the MBR and DBR,
Analysis of the Microsoft FAT16 DBR,
Design and implement a new MBR.
Competency:
The student will continue learning how to use the BIOS INT 13h interface for the purposes of data recovery including routine acquisition of the MBR and DBR of BIOS drive 80h, analysis of the DBR, and use the information it holds to design a new partition table to point to it. The student will then develop the new MBR in the DEBUG RAM workspace and use the INT 13h call to write it to the HDD. Upon reboot the original C: drive will be accessible once again.

    Preparation

  1. The student should GHOST the DOS image onto the hard drive with a partition size of 600MB. Then run DEBUG and write zeros to the MBR with the following series of instructions:

    f 100 2ff 0
    a 300
    mov ax, 301
    mov bx, 100
    mov cx, 1
    mov dx, 80
    int 13
    int 3
    g=300
    
  2. Upon reboot the drive will fail to boot with the BIOS Boot Strap Loader "disk boot failure" message. Booting to a floppy and attempting to read the C: drive will result in the "Invalid drive specification" error. With the MBR destroyed, the usual response is: "So sorry, all data has been permanently lost." We shall see that this is certainly not so.

  3. Procedures

  4. Upon completion of the preparation steps above, the student should boot to a floppy, run DEBUG and use the INT 13h call to read the MBR and then display it on screen. Obviously it will be all zeros because of the damage done purposely to it in the preparation steps above, but these procedures must always be done on systems that fail to boot and that fail to allow access to the C: drive in order to determine the nature of the problem. Corrupted values in the partition tables can result in the "Invalid partition table" message from the MBR 1st stage OS boot strap loader code, but ONLY if that code is in tact. Otherwise the system will simply hang after the BIOS startup screens. Again, in true data recovery scenarios the HDD should never be allowed to boot up in the event that the agent that has caused the damage is a virus many of which operate from the MBR and load into RAM immediately and begin doing damage. Logic bombs can also insert themselves into the MBR or be purposely inserted into there by the PC's owner such that they will wipe the HDD if booted by someone who does not know how to stop the bomb from going off.

  5. Having ascertained the nature of the damage, a completely zeroed out MBR, the next step is to try to acquire the DBR. Under almost all circumstances the DBR will be located at C = 0, H = 1, S = 1. Write the DEBUG program to read this sector and run it. Display the top half of the DBR on screen:

    -a 300
    242C:0300 mov ax, 201
    242C:0303 mov bx, 100
    242C:0306 mov cx, 1
    242C:0309 mov dx, 180
    242C:030C int 13
    242C:030E int 3
    242C:030F (press [Enter] here to exit the assembler)
    -g=300
    AX=0001  BX=0100  CX=0001  DX=0180  SP=FFEE  BP=0000  SI=0000  DI=0000  
    DS=242C  ES=242C  SS=242C  CS=242C  IP=030E   NV UP EI PL ZR NA PE NC 
    242C:030E CC            INT	3                                  
    -d 100 1ff
    242C:0100  EB 3C 90 4D 53 44 4F 53-35 2E 30 00 02 20 01 00   .<.MSDOS5.0..@..
    242C:0110  02 00 02 00 00 F8 00 01-3F 00 FF 00 3F 00 00 00   ........?...?...
    242C:0120  CE DF 12 00 80 00 29 76-04 21 22 4E 4F 20 4E 41   ..?...)v.!"NO NA
    242C:0130  4D 45 20 20 20 20 46 41-54 31 36 20 20 20 FA 33   ME    FAT16   .3
    242C:0140  C0 8E D0 BC 00 7C 16 07-BB 78 00 36 C5 37 1E 56   .....|...x.6.7.V
    242C:0150  16 53 BF 3E 7C B9 0B 00-FC F3 A4 06 1F C6 45 FE   .S.>|.........E.
    242C:0160  0F 8B 0E 18 7C 88 4D F9-89 47 02 C7 07 3E 7C FB   ....|.M..G...>|.
    242C:0170  CD 13 72 79 33 C0 39 06-13 7C 74 08 8B 0E 13 7C   ..ry3.9..|t....|
    242C:0180  89 0E 20 7C A0 10 7C F7-26 16 7C 03 06 1C 7C 13   .. |..|.&.|...|.
    242C:0190  16 1E 7C 03 06 0E 7C 83-D2 00 A3 50 7C 89 16 52   ..|...|....P|..R
    242C:01A0  7C A3 49 7C 89 16 4B 7C-B8 20 00 F7 26 11 7C 8B   |.I|..K|. ..&.|.
    242C:01B0  1E 0B 7C 03 C3 48 F7 F3-01 06 49 7C 83 16 4B 7C   ..|..H....I|..K|
    242C:01C0  00 BB 00 05 8B 16 52 7C-A1 50 7C E8 92 00 72 1D   ......R|.P|...r.
    242C:01D0  B0 01 E8 AC 00 72 16 8B-FB B9 0B 00 BE E6 7D F3   .....r........}.
    242C:01E0  A6 75 0A 8D 7F 20 B9 0B-00 F3 A6 74 18 BE 9E 7D   .u... .....t...}
    242C:01F0  E8 5F 00 33 C0 CD 16 5E-1F 8F 04 8F 44 02 CD 19   ._.3...^....D...
    -_
    
  6. The DBR is here, but it must be analyzed to be sure that it does not contain corrupt data. There are only two actions that are taken against these sensitive sectors by malicious code: total destruction (overwriting them completely with zeros or any other value), or corruption of the critical values within them. Those attacks that only corrupt the data fields within the MBR or DBR are particularly nasty because it is impossible to tell that this has happened at a casual glance; the values must be tediously analyzed to be sure that they are uncorrupted. At this point follow the Analysis of the DBR module and verify all fields.

  7. Once the DBR has been confirmed, the DBR worksheet should be filled out and look like this:

    Offset Size Value Field
    00h 3 bytes EB 3C 90 Jump Instruction to bypass the DPB
    03h 8 bytes "MSDOS5.0" File System Driver Signature
    0Bh 1 word 02 00 Bytes/Sector
    0Dh 1 byte 20 Sectors/Cluster
    0Eh 1 word 00 01 Reserved Sectors
    10h 1 byte 02 # of FAT's
    11h 1 word 02 00 max. # of root dir entries
    13h 1 word 00 00 total sectors (partitions < 32MB)
    15h 1 byte F8 Media Descriptor
    16h 1 word 01 00 sectors/FAT
    18h 1 word 00 3F sectors/track
    1Ah 1 word 00 FF total heads
    1Ch dword 00 00 00 3F Hidden sectors
    20h dword 0012 DF CE total sectors (partitions > 32MB)
    24h 1 byte 80 BIOS drive #
    25h 1 byte 00 current head
    26h 1 byte 29 extended DPB signature
    27h dword 22 21 04 76 volume serial #
    2Bh 11 bytes ASCII "NO NAME    " Volume Label
    36h 8 bytes ASCII "FAT16   " File System Type

  8. All values are valid. That is to say, they make sense. For example, the cluster size of 32 sectors/cluster (16KB) is correct for a 600MB partition according to the standard cluster size to partition size chart for FAT16B:

    Partition SizeSectors/clusterCluster Size
    <16MBFAT12FAT12
    16MB to <64MB21KB
    64MB to <128MB42KB
    128MB to <256MB84KB
    256MB to <512MB168KB
    512MB to <1024MB3216KB
    1024MB to <2048MB6432KB

  9. There is enough information within the DBR to perform two important tasks: 1) Manually configure translations in the BIOS (if necessary) and 2) rebuild a partition table in the MBR that will allow DOS to recognize this partition again. For now it will be assumed that the translations are correct ,which they are since the BIOS was not modified in this exercise, (and known in this case to be Heads = 255 and Sectors/track = 63) and that only the partition table within the MBR needs to be rebuilt. The reconstruction of the partition table will now begin.

  10. The reconstruction of the partition table must begin with an empty worksheet:

    Offset Size Value
    00h 1 byte  
    01h 1 byte  
    02h 1 byte  
    03h 1 byte  
    04h 1 byte  
    05h 1 byte  
    06h 1 byte  
    07h 1 byte  
    08h 4 bytes  
    0Ch 4 bytes  

  11. For now, the partition will be left non-bootable so the first field at offset 00h will be left as 00h.

  12. The next three fields comprise the CHS address of the starting sector of the partition which is this DBR sector located at the expected address of C = 0, H = 1, S = 1. This means that the field at offset 01h will be 01, the field at offset 02h will be 01 and the field at offset 03h will be 00h.

  13. The partition type is determined by the fields at offsets 13h, 20h and 36h of the DBR. The field at offset 36h reads "FAT16   " but this does not differentiate between types 04 (early FAT16 not supporting clusters), 06h (FAT16"B" supporting clusters), and type 0Eh (WIN9X FAT16B supporting LBA access to the HDD). Since the largest FAT16 partition is 2GB which does not require LBA the type 0Eh partition type is exceedingly rare and only needs to be tried when the type 06h does not work properly. So the work is to determine if the partition is a type 04 versus a type 06. If the field at offset 13h is empty and the field at offset 20h holds the partition size in sectors, then it is a type 06. On the other hand if the field at offset 20h is empty, and the field at offset 13h holds the partition size in sectors, then it is a type 04. In this example the field at offset 13h is empty and the field at offset 20h holds the partition size, therefore this is a type 06 partition and this is the value that must be placed into the partition table at offset 04h. Here is the new partition table worksheet so far:

    Offset Size Value
    00h 1 byte 00
    01h 1 byte 01
    02h 1 byte 01
    03h 1 byte 00
    04h 1 byte 06
    05h 1 byte  
    06h 1 byte  
    07h 1 byte  
    08h 4 bytes  
    0Ch 4 bytes  

  14. The next three fields of the partition table hold the CHS coordinate of the ending sector of the partition. This information is not found directly in the DBR, but it can be determined directly from the information that is provided. Given that the partition starts in the sector at C = 0, H = 1, S - 1 and given the size of the partition in sectors, then adding the size to the LBA address of the starting sector will yield the LBA address of the sector that follows the last sector. Subtract one and the LBA address of the last sector will be found. Convert that back to CHS and the address will have been found that can then be placed into the fields at offsets 05h, 06h, and 07h:

    SSLBA + StrucSize - 1 = ESLBA
    63 + 1,236,942 (00 12 DF CE from field at offset 20h of the DBR) - 1 = 1,237,004
    LBA-to-CHS
       LBA  
     (TH X TS)   = C, R1
       R1  
      (TS)   = H, R2
      R2 + 1  = S
    So:
      1,237,004
      (255 x 63)   = C:76, R1:16064
      16064
        63    = H:254, R2:62
      62 + 1 = S:63
    
  15. Therefore the CHS of the ending sector of the partition is C = 76, H = 254, S = 63. These numbers make sense, the sector is located on the last sector of the last head of a cylinder, exactly where FDISK likes to put it. Converted to hexadecimal: C = 4Ch, H = FE, S = 3F. The cylinder number is NOT larger than FFh so there will be no bits to carry into the sector number field. The field at offset 05h is then FE, the field at offset 06h is 3F, and the field at offset 07h is 4Ch. Here is the updated partition table worksheet:

    Offset Size Value
    00h 1 byte 00
    01h 1 byte 01
    02h 1 byte 01
    03h 1 byte 00
    04h 1 byte 06
    05h 1 byte FE
    06h 1 byte 3F
    07h 1 byte 4C
    08h 4 bytes  
    0Ch 4 bytes  

  16. The field at offset 08h of the partition table must be identical to the field at offset 1Chof the DBR. It means the same thing in both structures. In the case of the partition table it means the LBA-style offset to the starting sector or the distance to it in sectors. In the DBR it means the distance back to the MBR or EMBR that holds the partition table that defines it. Inserting the value of the field at 1Ch of the DBR the partition table worksheet now reads:

    Offset Size Value
    00h 1 byte 00
    01h 1 byte 01
    02h 1 byte 01
    03h 1 byte 00
    04h 1 byte 06
    05h 1 byte FE
    06h 1 byte 3F
    07h 1 byte 4C
    08h 4 bytes 00 00 00 3F
    0Ch 4 bytes  

  17. The partition size field at offset 0Ch of the partition table is obtained directly from the field at offset 20h of the DBR. The two both mean exactly the same thing (the size of the partition in sectors):

    Offset Size Value
    00h 1 byte 00
    01h 1 byte 01
    02h 1 byte 01
    03h 1 byte 00
    04h 1 byte 06
    05h 1 byte FE
    06h 1 byte 3F
    07h 1 byte 4C
    08h 4 bytes 00 00 00 3F
    0Ch 4 bytes 00 12 DF CE

  18. At this point the entire partition table has been designed. Now it must be implenmented on the hard drive and then the system will be rebooted to see if IO.SYS recognizes the new partition table and assigns a letter that is then accessible. Clear the DEBUG RAM workspace froom offset 100 to 2FF with zeros:

    -f 100 2ff 0
    -_
    
  19. Now write the partition table into offset 2BEh of the planned new MBR. Important safety tip: DON'T FORGET ABOUT BYTE REVERSAL! Use the values directly from the partition table worksheet:

    -e 2be 00 01 01 00 06 FE 3F 4C 3F 00 00 00 CE DF 12 00
    -_
    
  20. Now write the boot signature into the last two bytes of the planned new MBR for the hard drive:

    -e 2fe 55 aa
    -_
    
  21. At this point the MBR is ready to be written to the hard drive. Create the program code to write the data from offset 100 to 2FFh to the first physical sector of the hard drive, then execute it:

    -a 300
    242C:0300 mov ax, 301
    242C:0303 mov bx, 100
    242C:0306 mov cx, 1
    242C:0309 mov dx, 80
    242C:030C int 13
    242C:030E int 3
    242C:030F (press [Enter] here to exit the assembler)
    -g=300
    AX=0001  BX=0100  CX=0001  DX=0180  SP=FFEE  BP=0000  SI=0000  DI=0000  
    DS=242C  ES=242C  SS=242C  CS=242C  IP=030E   NV UP EI PL ZR NA PE NC 
    242C:030E CC            INT	3                                  
    -_
    
  22. At this point the new MBR has been designed by hand, created in DEBUG RAM and written to the first physical sector of the hard drive. Reboot, remember that the hard drive is NOT bootable, to a floppy or bootable CD-ROM and then try "DIR C:" and the drive will be fully accessible at this point. The MBR has been recreated by hand and all files on the C: drive can be safely copied out to another drive. In the next module, the DBR will be the one that is destroyed and it will be rebuilt using the MBR.

Back to Page Top

Copyright©2000-2006 Brian Robinson ALL RIGHTS RESERVED