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 MBR, and use the information it holds to design a new Drive Parameter Block and DBR. The student will then develop the new DBR 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
This data recovery operation is designed to handle the albeit rare circumstance in which the MBR is present but the DBR has been destroyed. It is more instructional than it is practical since most attacks on the HDD will destroy the MBR first or in addition to the DBR. Rarely is the MBR left in tact while the DBR is destroyed, but this scenario is certainly possible and also gives the student the first experience in rebuilding a destroyed DBR.
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 w 100 2 0 1
Upon reboot the drive will fail to boot with the MBR 1st stage OS Boot Strap Loader "Missing operating system" message. Booting to a floppy and attempting to read the C: drive will result in the "Invalid media type reading drive C" error. With the DBR destroyed, the usual response is: "So sorry, all data has been permanently lost." We shall see that this is certainly not so.
Procedures
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. In this data recovery scenario, based on the specific boot up error coming from the hard drive of "Missing operating system" and "Invalid media type..." while trying to access the hard drive from another boot device, it is known that the problem most likely lies with the DBR. The C: drive is recognized meaning that the partition table to some extent exists, and the "Missing operating system" message indicates that the MBR 1st stage OS loader code is functional enough to identify the problem and display this message on screen. If the partition table for the C: drive turns out to be reliable (no strange values in it) then it holds all the information necessary to rebuild the DBR. This is why it must be retrieved at the outset. The student may notice that in almost every low level data recovery scenario, retrieval of the MBR is the first step and establishes a baseline of valuable information: either the MBR itself is damaged and is therefore the problem, or it contains valuable information that can lead to the recovery of the partitions that are inaccessible due to damage to other critical structures. This second scenario is the case for this module.
Having retrieved the MBR and displayed it on screen, the student should now record the first partition table values in a standard partition table worksheet. This is done even though the exact nature of the problem with the internal structures of the C: drive has not been ascertained yet, simply because the information in this partition table can often be used to recover the partition in later operations. To be expedient, record it now while it is in the DEBUG RAM workspace:
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 |
With the partition table information recorded, attempt to read the first sector of the partition as indicated within the fields of the partition table itself; specifically the sector at CHS coordinate: C = 0, H = 1, S = 1. Then display it on screen. It will be found to be completely zeroed. Having now verified that the DBR has been destroyed, the extent of the damage to the file system structures within the C: drive must be ascertained. Since this is a type 06 FAT16B, the first FAT is expected to start in a sector fairly close to the missing DBR. The student should load the next 32 sectors into the DEBUG RAM workspace and then search it for the start of a FAT16B file allocation table. IMPORTANT: this is a multi-sector read so the code must be located at offset 100 and the 32 sectors must be read into offset 200 (they will reach up to offset 41FFh):
-a 100 242C:0300 mov ax, 220 242C:0303 mov bx, 200 242C:0306 mov cx, 2 242C:0309 mov dx, 180 242C:030C int 13 242C:030E int 3 242C:030F (press [Enter] here to exit the assembler) -g=100 AX=0001 BX=0200 CX=0001 DX=0180 SP=FFEE BP=0000 SI=0000 DI=0000 DS=242C ES=242C SS=242C CS=242C IP=010E NV UP EI PL ZR NA PE NC 242C:030E CC INT 3 -_
Now that the thirty two sectors starting at the sector at C = 0, H = 1, S = 2 have been loaded into DEBUG RAM, search them for the start of a FAT16B file allocation table. All FAT16B file allocation tables start with the values "F8 FF FF FF" making them relatively easy to spot. That is, if this series of bytes is matched at the beginning of a sector closely after the DBR sector, then that must be the FAT::
-s 200 41FF F8 FF FF FF
242C:0200
-_
The file allocation table starts in the first sector of the thirty two sectors that were loaded into RAM; specifically the sector at C = 0, H = 1, S = 2 which is usually where a FAT16B format operation will put it. Since this structure does exist apparently in tact, the only structure that has to be repaired is the missing DBR itself. This operation will now begin.
Start with a DBR reconstruction worksheet developed in the module DBR analysis:
Offset | Size | Expected Value | Field |
00h | 3 bytes | EB xx 90 | Jump Instruction to bypass the DPB |
03h | 8 bytes | "8 ASCII CHARS" | File System Driver Signature |
0Bh | 1 word | 200 ("00 02") | Bytes/Sector |
0Dh | 1 byte | 2n | Sectors/Cluster |
0Eh | 1 word | Reserved Sectors | |
10h | 1 byte | 02 | # of FAT's |
11h | 1 word | 200 ("00 02") | max. # of root dir entries |
13h | 1 word | 00 00 | total sectors (partitions < 32MB) |
15h | 1 byte | F8 | Media Descriptor |
16h | 1 word | sectors/FAT | |
18h | 1 word | sectors/track | |
1Ah | 1 word | total heads | |
1Ch | dword | Hidden sectors | |
20h | dword | total sectors (partitions > 32MB) | |
24h | 1 byte | 80 (or 81,81,83) | BIOS drive # |
25h | 1 byte | 00 | current head |
26h | 1 byte | 29 (or rarely 28) | EDPB signature |
27h | dword | (any nonzero) | volume serial # |
2Bh | 11 bytes ASCII | "NO NAME " | Volume Label (irrelevant) |
36h | 8 bytes ASCII | "FAT16 " | File System Type |
Note that the field at offset 0Dh: Sectors/Cluster must also be determined although its possible values are highly restricted to powers of 2. The red boxes must also be determined based on the particular partition. The green boxes will be given by the translations in effect when the drive was formatted. NOTE: this CAN be different from one BIOS to another. The translations in effect on the drive in the original system must be determined prior to the rebuilding of this DBR and this process will be covered in a subsequent module. The blue boxes take their values directly from the MBR fields 08h and 0Ch. So first copy the value from the MBR partition table offset 08h (offset to the starting sector) into the DBR worksheet field data at offset 1Ch (the first blue box). Then copy the value from the MBR worksheet field data of offset 0Ch (partition size in sectors) into the DBR worksheet field data at offset 20h (the second blue box):
Offset | Size | Expected Value | Field |
00h | 3 bytes | EB xx 90 | Jump Instruction to bypass the DPB |
03h | 8 bytes | "8 ASCII CHARS" | File System Driver Signature |
0Bh | 1 word | 200 ("00 02") | Bytes/Sector |
0Dh | 1 byte | 2n | Sectors/Cluster |
0Eh | 1 word | Reserved Sectors | |
10h | 1 byte | 02 | # of FAT's |
11h | 1 word | 200 ("00 02") | max. # of root dir entries |
13h | 1 word | 00 00 | total sectors (partitions < 32MB) |
15h | 1 byte | F8 | Media Descriptor |
16h | 1 word | sectors/FAT | |
18h | 1 word | sectors/track | |
1Ah | 1 word | total heads | |
1Ch | dword | 00 00 00 3F | Hidden sectors |
20h | dword | 00 12 DF CE | total sectors (partitions > 32MB) |
24h | 1 byte | 80 (or 81,81,83) | BIOS drive # |
25h | 1 byte | 00 | current head |
26h | 1 byte | 29 (or rarely 28) | EDPB signature |
27h | dword | (any nonzero) | volume serial # |
2Bh | 11 bytes ASCII | "NO NAME " | Volume Label (irrelevant) |
36h | 8 bytes ASCII | "FAT16 " | File System Type |
Now fill in the HDD geometry fields with total sectors/track = 63 (3Fh) and total heads = 255 (FFh) into the DBR worksheet fields at offsets 18h and 1Ah respectively (we assume that these are known for now!):
Offset | Size | Expected Value | Field |
00h | 3 bytes | EB xx 90 | Jump Instruction to bypass the DPB |
03h | 8 bytes | "8 ASCII CHARS" | File System Driver Signature |
0Bh | 1 word | 200 ("00 02") | Bytes/Sector |
0Dh | 1 byte | 2n | Sectors/Cluster |
0Eh | 1 word | Reserved Sectors | |
10h | 1 byte | 02 | # of FAT's |
11h | 1 word | 200 ("00 02") | max. # of root dir entries |
13h | 1 word | 00 00 | total sectors (partitions < 32MB) |
15h | 1 byte | F8 | Media Descriptor |
16h | 1 word | 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 | 00 12 DF CE | total sectors (partitions > 32MB) |
24h | 1 byte | 80 (or 81,81,83) | BIOS drive # |
25h | 1 byte | 00 | current head |
26h | 1 byte | 29 (or rarely 28) | EDPB signature |
27h | dword | (any nonzero) | volume serial # |
2Bh | 11 bytes ASCII | "NO NAME " | Volume Label (irrelevant) |
36h | 8 bytes ASCII | "FAT16 " | File System Type |
This leaves the red boxes and the value for the field at 0Dh to be determined and they are based on the partition size. First multiply the partition size (value at offset 0Ch of the partition table by 512 bytes/sector:
0012DFCE =d=> 1,236,942 sectors X 512 bytes/sector = 633,314,304 bytes 633,314,304 bytes / 1,048,576 = 603.9755859375 or roughly 604MB
Check the partition size - to - cluster size chart:
Partition Size | Sectors/cluster | Cluster Size |
<16MB | FAT12 | FAT12 |
16MB to <64MB | 2 | 1KB |
64MB to <128MB | 4 | 2KB |
128MB to <256MB | 8 | 4KB |
256MB to <512MB | 16 | 8KB |
512MB to <1024MB | 32 | 16KB |
1024MB to <2048MB | 64 | 32KB |
The correct value is 32 sectors/cluster. 32 = h=> 20h This is the value for the field at offset 0Dh:
Offset | Size | Expected Value | Field |
00h | 3 bytes | EB xx 90 | Jump Instruction to bypass the DPB |
03h | 8 bytes | "8 ASCII CHARS" | File System Driver Signature |
0Bh | 1 word | 200 ("00 02") | Bytes/Sector |
0Dh | 1 byte | 20 | Sectors/Cluster |
0Eh | 1 word | Reserved Sectors | |
10h | 1 byte | 02 | # of FAT's |
11h | 1 word | 200 ("00 02") | max. # of root dir entries |
13h | 1 word | 00 00 | total sectors (partitions < 32MB) |
15h | 1 byte | F8 | Media Descriptor |
16h | 1 word | 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 | 00 12 DF CE | total sectors (partitions > 32MB) |
24h | 1 byte | 80 (or 81,81,83) | BIOS drive # |
25h | 1 byte | 00 | current head |
26h | 1 byte | 29 (or rarely 28) | EDPB signature |
27h | dword | (any nonzero) | volume serial # |
2Bh | 11 bytes ASCII | "NO NAME " | Volume Label (irrelevant) |
36h | 8 bytes ASCII | "FAT16 " | File System Type |
The first FAT started at the sector at C = 0, H = 1, S = 2, the sector that immediately follows the sector at C = 0, H = 1, S = 1; the DBR sector. The field at offset 0Eh of the DBR holds the 16-bit number that represents the logical offset of the start of the first FAT where the DBR is sector #0, the next sector 9where the first FAT actually was found) is then sector #1. Therefore the value that must go in this red box is 00 01 (NOTE: this must be byte reveresed when written to the actual physical DBR sector like all other multibyte fields!):
Offset | Size | Expected Value | Field |
00h | 3 bytes | EB xx 90 | Jump Instruction to bypass the DPB |
03h | 8 bytes | "8 ASCII CHARS" | File System Driver Signature |
0Bh | 1 word | 200 ("00 02") | 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 | 200 ("00 02") | max. # of root dir entries |
13h | 1 word | 00 00 | total sectors (partitions < 32MB) |
15h | 1 byte | F8 | Media Descriptor |
16h | 1 word | 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 | 00 12 DF CE | total sectors (partitions > 32MB) |
24h | 1 byte | 80 (or 81,81,83) | BIOS drive # |
25h | 1 byte | 00 | current head |
26h | 1 byte | 29 (or rarely 28) | EDPB signature |
27h | dword | (any nonzero) | volume serial # |
2Bh | 11 bytes ASCII | "NO NAME " | Volume Label (irrelevant) |
36h | 8 bytes ASCII | "FAT16 " | File System Type |
The data for the red box field at offset 16h is of the greatest concern. Being off by a single sector will misplace the root and ALL data clusters across the partition making no file readable (all files corrupt with the wrong sectors assigned to them). Since the DBR is the only structure damaged, it can be assumed that the second FAT exists in tact within the partition. If the start of that sector is found, then the exact size in sectors of each FAT can be directly determined. First a rough estimate can be developed mathematically to prevent the need to make repetitive multisector reads necessary:
PartitionSize Sec/Clust = TotalClusters TotalClusters x 2 = TotalBytes/Fat TotalBytes/Fat ÷ 512 bytes/sector = Sectors/FAT Therefore: 1,236,942 32 = 38654.4375, ROUND DOWN = 38,654 clusters 38,654 x 2 = 77,308 bytes/FAT 77308 512 = 150.9921875 round up (since it is close) = 151 =h=> 97
In theory then the second FAT should start at the LBA address of the first sector plus this size. Since the LBA address of C = 0, H = 1, S = 2 is 64, 64 + 151 = 215. Convert to CHS with the LBA to CHS formula:
LBA-to-CHS Formula LBA (TH X TS) = C, R1 R1 (TS) = H, R2 R2 + 1 = S Therefore: 215 (255 x 63) = C:0, R1:215 215 (63) = H:3, R2:26 26 + 1 = S:27
The second FAT should start somewhere near the sector at C = 0, H = 3, S = 27. Subtract 10 sectors from this location and load the thirty two sectors that start from that sector into DEBUG RAM. This means the DEBUG code must load the thirty two sectors that start at the sector located at C = 0, H = 3, S = 17 (11h):
-a 100 242C:0300 mov ax, 220 242C:0303 mov bx, 200 242C:0306 mov cx, 11 242C:0309 mov dx, 380 242C:030C int 13 242C:030E int 3 242C:030F (press [Enter] here to exit the assembler) -g=100 AX=0001 BX=0200 CX=0011 DX=0380 SP=FFEE BP=0000 SI=0000 DI=0000 DS=242C ES=242C SS=242C CS=242C IP=010E NV UP EI PL ZR NA PE NC 242C:030E CC INT 3 -_
Search the RAM workspace from offset 200 to 41FF for the start of a FAT (i.e. F8 FF FF FF):
-s 200 41FF F8 FF FF FF
242C:1600
-_
Which sector is this? Subtract 200h: 1600h - 200h = 1400h. Now divide this by 200h (the size of each sector) 1400h ÷ 200h = Ah =d=> 10. It is the tenth sector loaded into RAM. Since the first one was the sector at C = 0, H = 3, S = 17, then this one is the sector at C = 0, H = 3, S = 27. Obviously this is tricky if the load starts at sector 60 and wraps around to the next head. In that case convert the sector addresses to LBA, then convert back again as needed. For example:
CHS to LBA C(TH x TS) + H(TS) + (S - 1) = LBA 0(255 x 63) + 3(63) + (17 -1) = 205 Now, 205 + 10 = 215 (the expected sector) LBA to CHS of 215 was already done above yielding C = 0, H = 3, S = 27
Since this is the expected sector, then the mathematical calculation of the sectors/FAT was exactly correct. But it should noted that format does round strangely on occasion. Convert 151 to hex = 97. Place this as a 16-bit number into the field at offset 16h of the DBR wroksheet:
Offset | Size | Expected Value | Field |
00h | 3 bytes | EB xx 90 | Jump Instruction to bypass the DPB |
03h | 8 bytes | "8 ASCII CHARS" | File System Driver Signature |
0Bh | 1 word | 200 ("00 02") | 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 | 200 ("00 02") | max. # of root dir entries |
13h | 1 word | 00 00 | total sectors (partitions < 32MB) |
15h | 1 byte | F8 | Media Descriptor |
16h | 1 word | 00 97 | 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 | 00 12 DF CE | total sectors (partitions > 32MB) |
24h | 1 byte | 80 (or 81,81,83) | BIOS drive # |
25h | 1 byte | 00 | current head |
26h | 1 byte | 29 (or rarely 28) | EDPB signature |
27h | dword | (any nonzero) | volume serial # |
2Bh | 11 bytes ASCII | "NO NAME " | Volume Label (irrelevant) |
36h | 8 bytes ASCII | "FAT16 " | File System Type |
FAT16B DBR's use the jump instruction EB 3C 90. Make this correction at the top of the worksheet as the data for the field at offset 00h:
Offset | Size | Expected Value | Field |
00h | 3 bytes | EB 3C 90 | Jump Instruction to bypass the DPB |
03h | 8 bytes | "8 ASCII CHARS" | File System Driver Signature |
0Bh | 1 word | 200 ("00 02") | 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 | 200 ("00 02") | max. # of root dir entries |
13h | 1 word | 00 00 | total sectors (partitions < 32MB) |
15h | 1 byte | F8 | Media Descriptor |
16h | 1 word | 00 97 | 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 | 00 12 DF CE | total sectors (partitions > 32MB) |
24h | 1 byte | 80 (or 81,81,83) | BIOS drive # |
25h | 1 byte | 00 | current head |
26h | 1 byte | 29 (or rarely 28) | EDPB signature |
27h | dword | (any nonzero) | volume serial # |
2Bh | 11 bytes ASCII | "NO NAME " | Volume Label (irrelevant) |
36h | 8 bytes ASCII | "FAT16 " | File System Type |
At this point all fields have been filled in, the expected values from the original reconstruction worksheet and the new field values that had to be calculated for this particular drive and partition. Now a new DBR can be constructed based on the new DPB and EDPB values that have been developed on this worksheet. First clear the DEBUG RAM workspace from 100 to 2FF with zeros. Then enter the new DPB/EDPB values into the RAM workspace. DO NOT FORGET TO BYTE REVERSE MULTIBYTE VALUES, and enter the values in reasonable groups (not the entire DPB/EDPB in one command):
-f 100 2ff 0 -e 100 EB 3C 90 "MSDOS5.0" 00 02 20 01 00 -_
This enters the first 16 bytes into the RAM workspace. Note that ASCII fields can be entered as ASCII if surrounded by double quotes. Now enter the next 16 bytes of data for the fields from offsets 10h to 1Ch of the DBR worksheet:
-e 110 02 00 02 00 00 F8 97 00 3F 00 FF 00 3F 00 00 00
-_
Now enter the data for the fields from offsets 20h to 27h (NOTE: the volume serial number must be a non-zero value so the value 11 11 11 11 will be used):
-e 120 CE DF 12 00 80 00 29 11 11 11 11
-_
Now enter the volume label value of "NO NAME" padded with four spaces, and the file system value of "FAT16" padded with three spaces. DON'T FORGET the correct number of spaces, machine language drivers are reading these and don't like to find strange values like zeros:
-e 12B "NO NAME FAT16 "
-_
The DBR will be rejected as invalid by IO.SYS if the boot signature is not found, write it in now:
-e 2FE 55 AA
-_
Review the values by displaying them on screen with the "d 100 1ff" command. Verify all values with the worksheet to make sure that there are no mistakes. Once verified write the code at offset 300 to write the 512 bytes of data from offset 100 to 2ff to the physical sector at C = 0, H = 1, S = 1 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, 180 242C:030C int 13 242C:030E int 3 242C:030F (press [Enter] here to exit the assembler) -g=300 AX=0001 BX=0200 CX=0011 DX=0380 SP=FFEE BP=0000 SI=0000 DI=0000 DS=242C ES=242C SS=242C CS=242C IP=010E NV UP EI PL ZR NA PE NC 242C:030E CC INT 3 -_
At this point the DBR has been reconstructed, however it is certainly not bootable because we have not inserted the 2nd stage OS bootstrap loader code into it, only the DPB/EDPB and the boot signature. Reboot the system to a bootable diskette or CD-ROM and the C: drive will be fully accessible and files can be copied out to another drive.
A future exercise will explore the difficult task of rebuilding BOTH the MBR and DBR when both get destroyed such as what happens from the ZAP.COM tool or a partial WIPE. The next recovery operation explored will be recovery of subdirectories after a FORMAT C: drive has been executed.
Copyright©2000-2006 Brian Robinson ALL RIGHTS RESERVED