Working complete PC
Student Diskette, "New Boot A Ver 2.0+"
Student CD-ROM, "Room 6359"
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 FAT32 DBR layout.
Analysis of the Microsoft FAT32 DBR.
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 analyze it.
The student should complete the previous module: Locate, Read and Display the DBR using DEBUG, then proceed with the following procedures.
Upon completion of the preceding module the student should have displayed the FAT32 DBR on screen in DEBUG. However, the FAT32 DBR has a different EDPB (Extended Drive Parameter Block) from the FAT16 DBR. And includes a second sector that usually immediately follows it called the FSI (File System Information) sector. The fields of the FAT32 DBR are as follows:
|00h||3 bytes||EB 58 90||Jump Instruction to bypass the DPB|
|03h||8 bytes||"MSWIN4.1"||Driver Signature (Windows 98)|
|0Bh||1 word||02 00||Bytes/Sector|
|0Eh||1 word||00 20||Reserved Sectors1|
|10h||1 byte||02||# of FAT's|
|11h||1 word||00 00||max. # of root dir entries2|
|13h||1 word||00 00||total sectors (partitions < 32MB)|
|15h||1 byte||F8||Media Descriptor|
|16h||1 word||00 00||sectors/FAT3|
|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||dword||00 00 04 F3||sectors/FAT3|
|28h||1 word||00 00||flags4|
|2Ah||1 word||00 00||FAT32 Version|
|2Ch||dword||00 00 00 02||Start Cluster of Root Dir|
|30h||1 word||00 01||Offset of FSI Sector|
|32h||1 word||00 06||Offset to backup FAT32 DBR|
|34h||12 bytes||00's||Reserved Field|
|40h||1 byte||80||BIOS Drive #|
|42h||1 byte||29||EDPB Signature|
|43h||dword||xx xx xx xx||Volume Serial #|
|47h||11 bytes ASCII||"NO NAME"||Volume Label|
|52h||8 bytes ASCII||"FAT32 "||File System Label|
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.
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 DPB.
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 uses the file system driver signature "MSWIN4.1" in this case.
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 standard way the operating systems instruct the BIOS to access magnetic storage devices in the PC is with 512 byte sized sectors. 200 (stored as "00 02" little endian reversed) is hexadecimal for 512. So this field should ALWAYS hold this value.
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:
FAT32 Partition Size to Cluster Size Table
|Partition Size||Sectors/cluster||Cluster Size|
|512MB to <8GB||8||4KB|
|8GB to <16GB||16||8KB|
|16GB to <32GB||32||16KB|
|32GB to 2TB||64||32KB|
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:
Since this value reads "00 20" the starting sector of the first FAT is the sector number 32 counting from the DBR which is sector #0. This is not always the case, FORMAT may position the start of the first FAT anywhere from sector #2 to sector #65535. 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 and/or LBA 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".
The field at offset 11h indicates the maximum number of root directory entries. For FAT32 file system based partitions the size and location of the root directory are NOT fixed as they are in FAT16. The root directory is considered just another file like a subdirectory. Because of this, the root directory can grow and therefore fragment and is therefore unlimited in size and therefore unlimited in number of entries that it can hold. It is however, HIGHLY prefereable to keep it from becoming fragmented and its number of entries should be kept below the number that would fit into one cluster. Since the cluster size of this partition (less than 8GB in size) is 4KB and each entry is 32 bytes in size just like FAT16 based file systems, then 4096/32 = 128. The root should never exceed 128 entries (files and subdirectories). Since the FAT32 root has no limit to the number of entries it can hold this field is left zeroed.
As with FAT12 and FAT16, FAT32 also stores both FATs 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 first data cluster of the partition will be known precisely. The root directory's starting cluster is listed in an upcoming field here in the DBR and this is how the file system will be able to locate its start. It gets FAT table entires as well which is how the file system can pursue it if it grows larger than one cluster.
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 all FAT32 partitions are larger than 32MB and use Partition ID types other than 04h then this field will be left zeroed.
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.
The field at offset 16h indicates sectors/FAT or the size of each FAT. However, FAT32 supports huge file allocation tables and as such this field is NOT used by FAT32 and is left zeroed. The true FAT size field is coming up is a 32-bit sized field of the FAT32 EDPB.
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.
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.
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:
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.
The field at offset 20h indicates the total size of the partition (in sectors) if it is a FAT32 partition it will be larger than 32MB. Any partition larger than 32MB will cause FORMAT to use this field, but the criterion is: only if the partition is not a type 04. Remember that this is a single double word value (32-bit) and must be byte reversed as read off of the sector in the DEBUG screen. 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 rare cases this field may be slightly smaller than the size found in the MBR's partition table. In this case, the two values do match.
The field at offset 24h is the first field of the FAT32 EDPB and has a different piece of data from the FAT16 EDPB. The field at this location is a 32-bit (4 bytes reversed) value that holds the FAT size in sectors. In this case the value is 00 00 04 F3 = 1267. So each FAT is 1,267 sectors in size and these are relatively small file allocaton tables for FAT32. A 2TB partition would have file allocation tables (in theory) occupying 524,288 sectors each (that is over 260 million bytes in size!) We'll have to wait until someone strings together a hardware level 2TB RAID and partitions it FAT32 or until the HDD manufaturers release a cheap 2TB drive before we can know for sure if FAT32 can actually handle a partition this size.
The field at offset 28h of the FAT32 DBR, holds the flags. This is a word sized field so reverse the bytes then find the meaningful bits within it. Bit 7 indicates if FAT mirroring is enabled. Note that for FAT12 and FAT16 it is always enabled. Any activity is automatically updated to BOTH copies of the FAT simultaneously. Under normal conditions the FAT32 second copy is also updated automatically (FAT mirroring is therefore enabled. If the bit 7 = 0 then mirroring is enabled. If it is "1" then it has been disabled. If it is disabled, then bits 0 - 4 indicate which FAT is the active and therefore reliable File Allocation Table. For example, if the flags field reads: 81 00, then first reverse the bytes: 00 81. Then convert to binary and find bit 7:
BIT 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 VALUE 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 ^
Bit 7 indicates that FAT mirroring has been disabled. Bits 0 to 4 hold the value 0 0 0 1 which is binary for the number "1" indicating that the first FAT is the active FAT. In our example, the flags field is "00 00" indicating that FAT mirroring is enabled and this will usually be the case.
The field at offset 2A of the FAT32 DBR is the FAT32 file system version. This word sized field is almost always "00 00" in that Microsoft never changed the file system since they began to concentrate all of their efforts on NTFS which would ultimately replace FAT32.
The field at offset 2C is a double word (32-bit, or 4 byte) value holding the starting FAT entry (cluster number) of the root directory. Cleanly formatted new FAT32 partitions will always place the start of the root directory in the first usable cluster; data cluster #2. Converted partitions, converted from some other file system, such as FAT16, may have the root start at some other cluster. If the root does not start in cluster #2, it is a good indication that it has been converted from some other file system either by Microsoft's CONVERT.EXE or a third party utility like Partition Magic. In our example, the value is 00 00 00 02, the expected value indicating that the root directory begins in cluster #2.
The field at offset 30h of the FAT32 DBR is a word sized value that holds the offset to the FSI (File System Information) sector. This is a second sector that has been added to the DBR that holds optimization infromation for the Windows 98+ file system drivers to use in writing new files to the partition. It will be examined in detail in another module. In the example the value read off of the DEBUG screen was: 01 00 which when byte reversed is 00 01, indicating that the sector that immediately follows the DBR holds the FSI sector.
The field at offset 32h of the FAT32 DBR is a word sized value that holds the offset to the backup DBR. This sector is a fully functional duplicate of this sector. And the backup FAT32 DBR will launch the operating system in the event that this DBR is completely zeroed. The only way that this could work is if the MBR 1st stage OS loader code were built for it to launch the backup in case the primary DBR were found to be missing. This means that the MBR code dictates the location of the backup DBR and it is probably inflexible. The value usually found is: "00 06"
The field at off set 34h of the FAT32 DBR is listed as reserved and usually contains all zeros. It is 12 bytes in length.
The field at offset 40h of the FAT32 DBR consists of the fields originally found in the FAT16 DBR's EDPB and starts with the BIOS drive number identity of the hard drive on which the partition was at the time it was formatted. In the example the value found was 80h indicating that it was most likely the master on the primary ATA channel.
The field at 41h is usually 0, but does mean the "current head" the file system drivers may temporarily insert this value into this location during large operations. But this is a transient and therefore unreliable value that does not have much practical value to the data recovery operations of the partition's contents.
The field at 42h is the EDPB signature, usually 29h as was observed above.
The field at offset 43h of the FAT32 DBR holds the volume serial number. A randomly generated 32-bit (4 reversed bytes) number created by format and inserted into this field. While DOS has almost no use for the value, Windows file system drivers do use it and changing it can have disastrou effects on the Windows NT family of operating systems (i.e. Blue Screens of Death and failure to launch the operating system will occur)
The field at offset 47h holds the volume label as 11 ASCII encoded bytes. Like FAT16, it will hold the value "NO NAME" followed by five spaces if none is specified by the user during the formatting process.
The field at offset 52h holds the file system type as 8 ASCII encoded characters. For FAT32 it MUST read: "FAT32" followed by three spaces as it does in this example.
Like the FAT16 DBR, the FAT32 DBR holds the mapping to the layout and location of all important file system structures within the partition. Although FAT32 is slightly different and as such there are some extra fields the concepts are the same. In the following exercise, the information contained within this DBR will be used to peruse the partition and its structures.
In working with a FAT32 based partition, it will be necessary to verify values found within the FAT32 DPB within the DBR. The following table is a foundation that holds typical vaues for the various fields:
|00h||3 bytes||EB 58 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|
|0Eh||1 word||Reserved Sectors|
|10h||1 byte||02||# of FAT's|
|11h||1 word||0 ("00 00")||max. # of root dir entries|
|13h||1 word||00 00||total sectors (partitions < 32MB)|
|15h||1 byte||F8||Media Descriptor|
|1Ah||1 word||total heads|
|20h||dword||total sectors (partitions > 32MB)|
|2Ch||dword||2 ("02 00 00 00")||Root start cluster|
|30h||word||1 ("01 00")||offset to FSI sector|
|32h||word||6 ("06 00")||offset to backup DBR|
|34h||12 bytes||0's||reserved field|
|40h||byte||80 (rarely: 81,etc)||BIOS drive #|
|43h||dword||xx xx xx xx||volume serial #|
|47h||11 bytes ASCII||"NO NAME "||Volume Label (irrelevant)|
|52h||8 bytes ASCII||"FAT16 "||File System Type|
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.
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.
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 FAT32 partition.
Copyrightę2000-2006 Brian Robinson ALL RIGHTS RESERVED