Analysis of the FAT16 DBR

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:
using the partition table to determine the DBR's location,
use the BIOS INT 13h Interface to read the partition's DBR
the Microsoft FAT16 DBR layout.
Analysis of the Microsoft FAT16 DBR.
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 of BIOS drive 80h, analysis of the partition table including the calculation of the location of the DBR, develop the INT 13h call to acquire that DBR, display it on screen and analyse it.

    Preparation

  1. The student should complete the previous module: Locate, Read and Display the DBR using DEBUG, then proceed with the following procedures.

  2. Procedures

  3. Upon completion of the preceding module the student should have compiled the following DBR field data worksheet:

    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 40 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 00 3F FA 86 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

  4. The student may have noticed that the Jump Instruction at offset 00h of the DBR is refered to as a separate entity from the DPB, and then included as the first field of the DPB in the DPB structure table. Technically it IS the first field of the DPB, but it does NOT comtain any significant data for the file system concerning the layout of the file system within this partition. The reason that it is technically part of the DPB, is because if it is zeroed, IO.SYS will reject the entire DPB as invalid. In contrast, if the 2nd stage OS boot strap loader code located behind the DPB is zeroed, this will have NO EFFECT on access to the drive letter, and only prevent the drive from booting up. This fortifies the definition of the Jump Instruction as a legitimate field of the DPB, while the OS loader code is NOT.

  5. Considering the Jump Instruction as a field of the DPB then, it should be noted that different versions of DOS jump to different offsets within the DBR. A DPB with the EDPB for DOS using FAT16 will have the instruction "EB 3C 90" Note that in all versions the third byte is always a "90" which is the machine language instruction "NOP" or "No Operation." It is the machine language instruction that does nothing, but it is useful for taking up space without locking up the machine. The CPU can execute huge blocks of NOP's but continues functioning normally and will reach the instructions that lie beyond them, so they are used to reserve space for future instructions. This is why Microsoft put it here. For DOS FAT32 DBRs the Jump Instruction is "EB 58 90" due to the larger EDPB.

  6. However, the most important detail of this analysis is that it starts with "EB" and ends with "90". The next field is the file system driver signature. As already mentioned in previous modules "MSDOS5.0" is the signature for MSDOS Version 5.0 through MSDOS version 6.22. Windows 98 Second Edition will be used in future exercises. Its file system driver signature is "MSWIN4.1"

  7. The next field at offset 0Bh is the bytes/sector of the partition. This however is dictated by the way the physical disk is being handled by the BIOS. Being a magnetic storage disk, the BIOS will always use 512 byte sectors with it. 200 (stored as "00 02" little endian reversed) is hexadecimal for 512. So this field should ALWAYS hold this value.

  8. The next field at offset 0Dh is the sectors/cluster of the partition. This value is automatically determined by FORMAT when the partition is actually formatted. Recall that it is FORMAT that creates the file system of the partition and it is the one that will calculate the sectors/cluster and construct the File Allocation Tables, Root Directory, and this DBR sector including THIS DPB which maps all of these structures. FORMAT attempts to create an optimal balance in cluster size versus File Allocation Table size based on the total number of clusters that will be defined for the partition which in turn will be influenced by its total size. This formula that FORMAT uses results in cluster sizes to partition sizes from this table:

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

  9. Because the partition size in sectors is expressed in one of the upcoming fields the analysis of this field will continue when that field is reached. The field at offset 0Eh is a word sized value called ambiguously the "Reserved Sectors" This is the COUNT of the sectors PRECEDING the first sector of the first FAT. Or it can be thought of as the logical sector number of the first sector of the first FAT IF this DBR is considered sector #0 of the partition. To illustrate:

    MBR       DBR
    Sector #0
    FAT
    Sector #1
          ...

  10. Since this value reads "00 01" the starting sector of the first FAT is the sector that immediately follows the DBR within the partition. This is not always the case, but it is usually the case. It is a logical offset from the DBR and is NEITHER an LBA coordinate or a geometric coordinate. If and when the starting sector of the first FAT is needed, its geometric coordinate will have to be calculated. The field at offset 10h specifies the number of FAT's. For all true magnetic storage disks DOS keeps two FATs back to back at the beginning of the partition. This value when working on the HDD should always be "02".

  11. The field at offset 11h indicates the maximum number of root directory entries. For FAT16 file system based partitions the size and location of the root directory are fixed and they are indicated here in the DPB. The root directory ALWAYS starts in the sector that follows the end of the second FAT. And both FATs are also stored back to back. So if the starting sector of the first FAT is known (indicated by the field at offset 0Eh) and the number of FATs is known (indicated by the field at offset 10h) and their sizes are known (in an upcoming field) and DOS always stores the FATs back to back, then the starting sector of the root directory will be known precisely. Now if the root directory's size is also known then the first data cluster's starting sector will also be known precisely as the sector that immediately follows the root directory. For FAT16 root directories on hard drive partitions this value is almost always 200 (stored as "00 02" little endian reversed) or 512 entries. Since each entry is exactly 32 bytes in size, then 512 x 32 bytes = 16,384 bytes / 512 bytes/sector = 32 sectors; the size of the root directory.

  12. The field at offset 13h holds the total number of sectors in the partition. It is however a word (16-bit number) and is therefore limited to a maximum value of 65,535. Multiplied by 512 bytes/sector = 33,553,920 bytes or roughly 32MB. This is a deprecated field that was used in DOS Partition ID Type 04h partitions. Type 04 FAT16 file systems do NOT support clusters such that each FAT entry points to one sector, and not one cluster which is a group of sectors. Since almost all partitions are larger than 32MB and use Partition ID Type 06h (FAT16 using clusters) then this field will be left zeroed.

  13. The field at offset 15h is also a somewhat deprecated field used to indicate the type of physical drive that this DPB is located on. For hard drives the value is F8h. All DPB's of hard drives should indicate F8h at this offset. It has very little functional value within the DPB. But, it it good for verifying the DPB. It should not be any other value.

  14. The field at offset 16h indicates sectors/FAT or the size of each FAT. Armed with this information and the location of the first sector of the first FAT, the location of the starting sector of the second FAT and of the root directory behind it can be found and untlimately the first sector of the first data cluster and then the locations of ALL data clusters on the partition can be calculated. This field is therefore more than casual in importance it is an integral part of the calculation for locating ALL data on the partition. It also varies in size depending on the size of the partition. In this case the value is 100 (stored as "00 01" little endian reversed) or 256 sectors; the largest possible FAT by the way. Since each FAT16 entry is 16-bits in size (hence the name FAT16) and the largest number of unique 16-bit numbers is 65,536 then 65,536 x 2 bytes/entry = 131,072 bytes as the largest possible FAT. Divide this by 512 bytes/sector = 256 sectors as the largest possible FAT.

  15. The field at offset 18h is the sectors/track for geometric coordinate access of sectors in the partition. It will match the translations being used by the BIOS on the HDD. This value will be verified later.

  16. The field at offset 1Ah is the total number of heads being used for geometric coordinate access of sectors in the partition. It will match the translations being used by the BIOS on the HDD. This value like the preceding one will be verified later.

  17. The field at offset 1Ch of the DPB is a double word or 32-bit value indicating another cryptic value called "Hidden Sectors." Do not forget that the four bytes must be byte reversed as they are read off of the DEBUG display on screen. So the "3F 00 00 00" on screen becomes =x=> "00 00 00 3F" This field indicates the logical offset of THIS DBR from the sector that holds the partition table that defines the partition. In this case the sector that holds the partition tables where this partition is defined is the MBR itself. So if the MBR is considered LBA sector #0, then this sector is LBA sector #3F (63). To illustrate:

    MBR
    Sector #0
      ...   DBR
    Sector #3F
            ...

  18. The Hidden Sectors field is a relative location. It is the location of this DBR relative to the location of the MBR in this case. Other sectors besides the MBR can define partitions which is why it is important to bear in mind that this is a relative offset from the sector that contains the partition tables that define its location. This value MUST match the field at offset 08h of the partition table that defined this partition. This is the case and one of the main fields used in rebuilding the DPB and/or the MBR partition table.

  19. The field at offset 20h indicates the total size of the partition (in sectors) if it is a type 06h (FAT16 using clusters) and therefore more than likely larger than 32MB. Any partition larger than 32MB MUST be a type 06h but in theory FORMAT will use this field only if the partition not a type 04. And will use the field at offset 13h if the partition IS a type 04h. Remember that this is a single double word value (32-bit) and must be byte reversed as read off of the drive. The value "86 FA 3F 00" that was found will be recorded as "00 3F FA 86" on the worksheet. This value MUST match the value of the field at offset 0Ch of the partition table that defines this partition and this is another tool for verifying the DPB as corrupt or not, and for rebuilding either the DBR or the MBR. In this case, the two values do match.

  20. The field at offset 24h is the first field of the EDPB. MSDOS5.0 drivers use the EDPB as a standard extension of the DPB and it is therefore present. The field at this location is one byte and indicates the BIOS physical drive number when the drive was formatted. In this case the value is 80h indicating that the hard drive that this partition resides on was the first physical HDD at the time this DPB was built by FORMAT.

  21. The field at offset 25h of the DBR, is the current head. This is a dynamic value used by the operating system during live operations of the file system. While resting dormant it is unused which is the case during a data recovery operation. Since this value is always changing and only used by the operating system file system drivers while they are acessing the drive, it is fairly useless and should be zero. A nonzero value could indicate an OS crash while a file system operation was pending.

  22. The field at offset 26h is the EDPB signature. Either a 28h or a 29h are valid EDPB signatures. It should be noted that Windows NT operating systems may reject access to the drive if this value is absent.

  23. The value at offset 27h is the volume serial number that is displayed in the header of the DOS DIR output on screen. While volume serial numbers are of little importance to the operation of DOS, Windows does rely on them more and more as it evolves. Changing the volume serial number in Windows XP will cause a catastrophic blue screen of death at start up. DOS will not care what the value is. Remember that this is treated as a double word and must be byte reversed. The value is irrelevant in simple operations, but later versions of Windows in which this value has been lost may not ever be able to startup if the value cannot be found elsewhere.

  24. The field at offset 2Bh is the volume label. This is an aesthetic feature of the file system, but again, if it is changed (without the proper renaming event within the Windows environment) Windows may fail to be able to startup or access the drive. NOTE: when the drive is not given a volume label during FORMAT ("...or press ENTER for none") FORMAT DOES NAME the volume as "NO NAME" padded with four spaces. In cases of unnamed volumes this value should be inserted here. For any other volume label a file entry with the same name will be found in the root directory with the Volume Label Attribute set.

  25. The field at offset 36h holds the ASCII encoded file system type ID. In this case the partition has been formatted using FAT16 and the field indicates this with "FAT16" padded by three spaces.

  26. In verifying the DPB within the DBR the following is noted:

    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

  27. The red boxes must be calculated manually as part of the verification process. The green boxes match the BIOS translations in effect at the time the drive was originally formatted. This may have been accidentally incorrect, leading to the current data recovery scenario. This situation will be further discussed in the lecture review of translation mathods. Some details are avaiable here.

  28. The blue boxes must match the values in the partition table that defined this partition. In some rare cases especially when the partition uses the entire physical disk, the partition size may not match, the difference however should be slight and within reason.

  29. All other fields in the above table should be as listed or they are irrelevant to the accessibility of the partition from the DOS prompt. This concludes the preliminary investigation into the verification of the DPB and EDPB within the DBR of a FAT16 Type 06h partition.

Back to Page Top

Copyright©2000-2006 Brian Robinson ALL RIGHTS RESERVED