This is a basic walk through of the boot sector of a FAT file system. It’s boring and dull and, I figure if I’m ever going to be worth a flip at forensics, necessary. In this post, we’re just going to look at the first 36 bytes, which is the same whether it’s FAT12, FAT16 or FAT32. I’m not going to spend much, if any, time going into detail what each byte means. Today, we’re just going to focus on reading through the first 36 bytes. Following is a table detailing the layout.
As you can see, hex is zero-offset, which means we start counting from 0.
I’ve created a disk image of a 2GB USB stick. If you want to follow along, you can create a disk image of any FAT USB stick, regardless of size. Just be aware that some of the numbers that follow might be different for you. Most USB sticks, out of the box, are FAT32. Naturally, you can format them however you want, but this is a standard, vanilla FAT32. Tonight, I’m using the OxED hex editor because I can. (I’ve been playing with it, Hex Fiend, and HexEdit, and I’ll probably be switching between them as I settle on a favorite.)
Once we open the file, we see the following:
My cursor, noted by the blue square over the E in EB, is setting in the first byte, byte 0. From the table, bytes 0, 1 and 2 contain the jump code. In the image, bytes 0-2 contain EB 58 90. Because we’re dealing with FAT, we’re dealing with little endian. I’ll write more about this later. The important thing to know is that with little endian, we work backwards. We’ll be reversing (most) numbers we pull from this image. Yay. So, EB 58 90 is actually 90 58 EB, which is the address on the USB stick for any boot code.
Bytes 3 through 10 contain the OEM name in ASCII. These values are 42 53 44 20 20 34 2E 34, which equate to BSD^^4.4 where ^ equates to one space. Endian ordering is out the window here.
Bytes 11 and 12 give the bytes per sector, which is 00 02. Reordering for little endian, we have 02 00. Using a hex calculator, we find that this value is 512. So we have 512 bytes per sector, which is fairly standard.
Byte 13, containing 08, gives us the sectors per cluster. This will always be in powers of 2 to a maximum of 32KB. 8 x 512 is 4,096. So our cluster sizes are 4,096.
Bytes 14-15 give the size of the sectors in the reserved area. We have 20 00, which is actually 00 20, which is 32.
Byte 16 is the number of FATs and is typically 2. And what do you know, we’re typical.
Bytes 17 and 18 tell us the number of files in the root directory for FAT12 and FAT16. For FAT32, this usually zero. And again, we’re typical. 00 00.
Bytes 19-20 is a 16-bit value giving the number of sectors in the file system for FAT12 or FAT16. As in this image, if bytes 32-35 contain a value, this will be zero.
Byte 21 indicates the media type. 0xF8 for a hard drive and 0xF0 for a removable disk. Here we have F0, which is accurate for a USB stick.
Bytes 22-23 give a 16-bit size in sectors for each FAT in a FAT12 or FAT16 file system. As here, it’s zero for FAT32.
Bytes 24 and 25 give the sectors per track. Here we see 20 00, or 00 20, which is 32.
Bytes 26-27 show the number of heads in the storage device. FF 00 is 00 FF or 255.
Bytes 28-31 give the number of sectors before the start of the partition. 00 00 00 00 is, of course, zero.
Lastly, we have bytes 32-35. Remember, we’ll have a value here if bytes 19-20 are zero. Since 19-20 are zero, we’re expecting to see something here and we do. This is a 32-bit value for FAT32s. 9A 7F 3D 00, which is 00 3D 7F 9A, or 4,030,362 sectors in the file system. Multiplying this by 512 (bytes per sector, see bytes 11-12), we get 2,063,545,344, which equates to our 2GB USB stick.
And that’s it. It’s boring, but you’ll probably never be expected to commit this stuff to memory. Even the GCFA exam is open book. But it’s good to be comfortable with it, and walking through images in a hex editor is the best way I know to get comfortable with the layout.