Volume Boot Sector Format of FAT

by Kush Wadhwa, NII Consulting

There are times when you don’t have sufficient tools to understand the file system. At that time your knowledge in field of digital forensics will play a crucial role. In this article we will study a volume boot sector format of FAT32 file system and will see how to take out crucial information from it like sectors in particular volume, bytes per sector etc…I will be using Encase to explain this article but users can view their hard disk in any hex viewer like for win hex or xxd in Linux. Just open your hard disk’s fat volume in hex editor and follow the steps to understand it.

Volume boot sector is 512 bytes in size and is present after 63 sectors which are fixed for MBR (master boot record). Let’s understand this with the help of figure1

Rectangular block which is red in color is MBR (Master Boot Record). If we count sectors from red block till the last green block then we can see that they are 63 in number. This area is reserved for MBR. After sixty third sector is the volume boot record. Volume Boot Record is again 512 bytes in size and stores a lot of information. Volume Boot Record has its mirror copy at sector number 6 keeping in mind that we are giving number 0 to master Volume Boot Record.


As my pointer is on Volume Boot Sector therefore I can easily see what’s inside Volume Boot Record. Volume Boot Record is 512 bytes in size. Now let’s move to explanation of these 512 bytes so that any forensic investigator can understand all 512 bytes.


At this offset we have assembly jump instruction to Bootstrap the code. It is usually 0xEB3C90 or 0xEB5890



Offsets from 3-10 contains OEM id. OEM id is basically a string of characters that identifies the name and version number of the operating system that formatted the volume. Some examples of OEM id for different OS versions are:-




We can see in the above figure that OS version is windows 2k/XP. Figure2 is given below.



These two offsets contain the information on bytes per sector. Number of bytes per sector by default is 512 but it can be 1024, 2048 or 4096. As we can see in the figure hex value of 11-12 is 00 02. Encase shows all values in little Endian form. If we decode this in Hex and write in Big Endian form then the value is written as 0x200 which in decimal is 512 bytes. Magnified image of 11-12 bytes of figure1 is shown below in figure3.


This offset contains information on number of sectors per cluster. It’s necessary to have these values in power of two and should always be greater than zero. In the above figure number of sectors per cluster is 1. Let’s see how we calculated this value. At 13th position we have hex value as 10. Converting this value to decimal, we get the value as 16 which means there are 16 sectors in a cluster.


This field will tell about the number of sectors in the reserved area. In figure4 the number of reserved sectors is 2.


We can see the value on 14th offset is 20 and on 15th offset is 00. Converting this value in Big Endian form the value comes out to be 0020 which is written in hex as 0x020. Converting this value to decimal we get 2.


Number of FAT tables present. In FAT32 file system this is 2, with FAT1 and FAT2. FAT2 is exact replica of fat1 and is used when fat1 is corrupted or some error occurs while reading FAT1. Figure5 given belows shows the number of FAT present.



These offsets are for maximum number of 32 byte directory entries in the root directory. It is usually 0 for FAT32 and 512 for FAT12/FAT16.


This field is a 16 bit integer describing the number of sectors in the partition. If the value at these offset is 0 then it means the value of number of sectors is greater than 65,536. If this is the case then look the values of 32-35 which is a 32-bit integer describing the number of sectors in a partition. This is explained in detail in figure6 below.


We can see that offset 19-20 have value zero which means the number of sectors in a given partition is greater than 65,536. Therefore we will see the value at offset 32-35. It shows the value as “FC 8A 38 01”. This is in little Endian form. Converting this to Big Endian form we get value as “01 38 8A FC”. This value can be written in hex as 0x1388AFC. If we convert this hex value into decimal value then we get number of sectors as 20482812. Is this the answer? Answer is simply no. Answer is 20482812-63=20482749. We have deducted 63 sectors because the starting sector of partition is from 64th sector. Let’s confirm our answer. We will use professional tool encase to do this job. Figure7 given below will prove it.


We can see relative sector number is 63 and total size is equivalent to 20482812 sectors. Hence our answer


This field is a media descriptor which tells weather it is a removable media or non removable media. If the value is 0xF8 then it is non removable media. If it is 0xF0 then it is removable media. We can see the offset 21 has value of 0xF8 which shows it is a removable media.


These two offsets are 0 for FAT32 but for FAT12/FAT16 it tells the number of sectors used. Since the example shown above is using FAT32 therefore offsets 22-23 has value of 0.


These offsets tell about the sectors per track value. It is usually 63 for hard disk.


Writing it in Big Endian form we get “00 3F”. Decoding this to decimal we have the value as 63 which is for hard disk.


These two offsets represent heads value for interrupt 13h. It is typically 255 for hard disk. We can see in figure above that the next two bytes have value of “FF 00”. Solving this we get 255.


28-31 offset will tell how many sectors are hidden before the start of the partition. Its value is typically 63 for the first volume on a hard disk. Let’s see with the help of figure9 what the value in our example is?

We see the value in Big Endian form is “0x3F”. Converting this value into decimal we get 63. This 63 sector is for the sectors occupied by the MBR. Since MBR takes 63 sectors therefore they are considered as hidden sectors before the start of the partition.


Already described in offset 19-20


These offsets is a 32 bit integer which describes the number of sectors used by one FAT (FAT1/FAT2) on FAT32 partition. It is explained with the help of figure10.


First we will convert the selected value in BIG Endian which is “00 27 08”. Now writing this into hex value we get 0x2708. Converting this value into decimal form we get number of sectors used by FAT as 9992.


This field describes if the FAT entries are duplicated or not i.e. FAT1 has duplicate entry or not. If the value is 0 then they are duplicated. If the value is not zero then duplication doesn’t occur.


These offsets tell about the major number and the minor number of FAT32. Usually the values are 0x00 and 0x00 meaning the major number and the minor number of FAT is 0.



These offsets store the value of the cluster number where the root directory begins which is usually 2.Cluster 2 starts immediately after mirror copy of FAT1 i.e. FAT2 ends. Figure12 explains in clearer way.


Above figure shows the cluster of the root directory starts from cluster number 2. Let’s see if it is true. Figure13 will prove it.


It tells about the sector number where FSINFO is found. It is generally located at sector number 1 and the backup of FSINFO is found at sector 7.


These offsets will define the location of backup boot sector which is usually sector 6.


These sectors are currently not in use.


Interrupt 13h driver number. It is 0x00 for floppies and 0x80 for hard drives.Figure14 shows the driver number as 0x80. So it is hard drive.



This offset is not used by any version of windows except for Windows NT.



It is for extended boot signature and if its hex code is 0x29 then it means that the next three fields (Serial Number, Volume Label, File system type) are present. If it is 0x00 then none is available.


Volume serial numbers. Every volume has got a serial number which can be seen by using ‘vol’ command in dos. Lets see with the help of figure15.


The marked field is in Little Endian form. Converting it to Big Endian form we get “A0 CF 43 A3”. Lets verify this by using vol command in dos. Figure16 will give us the answer



Volume label in ASCII. If none is give by user then it should show “NO NAME”. Figure17 is given below.



File system which was present on media at time of formatting. This is of no use after formatting and can be changed to any arbitrary value. Figure18 shows the file system present at the time of formatting was FAT32



Boot strap program code and error messages.


Signature value; It is of 2 bytes and should be 0x55AA.



What a great and thorough walkthrough. I’ll get my hex viewer out, along with a disk as soon as I can. Once I’ve got to grips with FAT32, I’d like to get to know more about NTFS (hint, hint!). I know there was a brief introduction about NTFS a while ago so I’m sure that a similarly detailed walkthrough for NTFS would be appreciated by all.

Keep up the good work which is very educational.

Thanx Iain. I will surely write an article on Volume Boot Record of NTFS file system. Keep reading forensic article on checkmate;)

Good job,
Anatomy of the whole FAT filesystem, with each offset derscibed with examples. After going through the article I have a better understanding for FAT.
Checkmate is a wonderfull way for disseminating knowledge.

This is very good document to learn disk structure.

Thanks & Best Regards,

Shambhunath Pandey

“Disk Image With Corrupted MBR Partition Table Cannot Be Acquired

EnCase cannot properly acquire disks with certain corrupted MBR partition tables. When running linen
on a system with a disk with a carefully crafted partition table (including many partition table entries), linen
won’t start up properly. If linen is started prior to corrupting the image, it will start up, but EnCase will
hang inde nitely while acquiring the image. While the acquisition is hung, it is possible to cancel out of the
import from the GUI.
If a disk image is manually captured and transferred to the EnCase workstation and acquired as a raw
disk image, EnCase will hang inde nitely while attempting to acquire the image. There is no way to cancel
out of this process | the GUI becomes unresponsive. We have not identi ed the root cause of this issue,
but it appears to be due to the overly large values in the 29th partition table entry. We were unable to
reproduce this issue in similar situations with a small number of partitions.”

more details:
“Breaking Forensics Software:
Weaknesses in Critical Evidence Collection”


Great, I love to know more and more please feed me back with any interesting topics about BootSectors on my e-mail.
Thanks again.

Hello Mikha,

Thanks for reading the article. There are lot more articles to come on digital forensics. Keep reading articles on checkmate.


Kush Wadhwa

Minor typo in this paragraph, “We can see the value on 14th offset is 20 and on 15th offset is 00. Converting this value in Big Endian form the value comes out to be 0020 which is written in hex as 0×020. Converting this value to decimal we get 2.”

You may want to correct the paragraph for the 14th and 15th offset to read. “…be written in hex as 0x0020. Converting this value to the decimal we get 512.” The bit pattern is interpreted in big endian form as indicated which means that the most significant value is at the right.

Thank you,

I have learn several good stuff here. Certainly value bookmarking for revisiting.
I wonder how much attempt you place to make such a great informative

Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.