A Journey into NTFS: Part 3

For today’s post, I’m going to look at the NTFS file $Boot. As easily guessed, this file is related to the booting process and contains the NTFS boot sector. This file is extremely important, not only to the booting of the system, but also for data interpretation by many forensic tools.

$Boot File

The $Boot metadata file has three static data points that analysts should be familiar with.

• $Boot can be found at MFT entry 7. See istat output below:

istat output for MFT entry 7, $Boot

• The second static data point is that the boot sector, and thus this file, is always in the first sector of the file system. This is for obvious reasons — so that the file system can be booted! Take a look at the bottom of the screenshot above; notice that the file starts in cluster 0, and occupies 2 clusters. This leads us to…
• The third data point is that this file is typically allocated 8192 bytes in size. Again, looking at the output above, we can see the size is 8192. I can see this in a file listing as well:

:/mnt/windows_mount# ls -l \$Boot
-rwxrwxrwx 1 root root 8192 Nov 10  2010 $Boot

The NTFS Boot Sector

As previously mentioned, the first sector of this file contains the NTFS boot record (the first sector can also referred to as the Volume Boot Record, which is just the first sector of a partition). Here’s a screenshot of that first sector:

Screenshot of an NTFS boot record, from sector 0 in a test image

Whilst it may seem like jibberish, there is actually a TON of useful data in here. In fact, this particular sector is really the key to understanding everything else.

• The first handful of bytes (EB 52, followed by 90 4E 54 46 53) contain the assembly instructions to jump to the boot code (see below), and the OEM name of the file system. In this case, we definitely recognize the NTFS. Jump instructions below:

Screenshot of disassembled boot sector instructions

• Bytes 11 — 12 and 13 provide the bytes per sector and sectors per cluster, respectively. Remember our fsstat output from previous posts:

:/mnt/ewf# fsstat ewf1

fsstat output on a test image

We have a sector size of 512 and a cluster size of 4096, or 8 sectors. We should be able to match this up with these bytes in our boot record:

Screenshot of the first 16 bytes of an NTFS boot record

• Bytes per sector is 0x200 = 512
• Sectors per cluster is 0x08 = 8 (512*8 = 4096)

Parsing these two values allows forensic tools to now determine where files are located and how space is allocated. Let’s look at additional data:

Screenshot of the first 80 bytes of an NTFS boot record

• The F8 at byte 21 is the media descriptor, which represents a fixed disk.
• Bytes 40–47 (FF 17 18 03) provide the total number of sectors. This translates to 51,910,655, which we also saw in our fsstat output above.
• Bytes 48–55 (00 00 0C 00 00 00 00) provide the cluster where the $MFT starts. This translates to 786,432, which can be confirmed with istat:

Screenshot of istat output from $MFT, showing the first cluster

• Bytes 56–63 (02 00 00 00 00 00 00 00) show the starting cluster of the $DATA attribute from the NTFS file $MFTMirr (I’ll be covering this file in a later post, but for now, know that it can be used for recovery purposes). This translates to 2, which again can be verified using istat:

Screenshot of istat output from $MFTMirr, showing the first cluster

• Byte 64 (F6) is a tricky one to just glance it, as we must interpret if the value is negative or not. In this particular case, F6 translates to -10, which represents 1,024 bytes (2¹⁰) in an MFT entry.
• Byte 68 (01) provides the number of clusters per index record (yet another NTFS element I’ll cover in a later post), which in this case is just one. This would indicate that index records are 1 cluster, 8 sectors, or 4096 bytes, in size.
• Bytes 72–79 (25 65 03 AC A3 03 AC 2E), the last of our screenshot above, provide the serial number. As we can see from our fsstat output, as well as in the record itself, that value is 2EAC03A3AC036525. NTFS uses an 8-byte Volume Serial Number, but in some artifacts we are only given the last four bytes (thanks FAT).

Analyst Note: You’ll see four bytes from this serial number again in LNK files (which I haven’t covered in a post yet). Yes, we can tie LNK files to $Boot. Here’s a teaser screenshot:

Screenshot of parsed LNK file showing a volume serial number

The remainder of the boot sector, provided below, contains boot code — except for the last eight bytes, which are very interesting. A boot sector has a signature of AA 55 , which can be seen in bytes 510–511 below:

Screenshot of the last 432 bytes of an NTFS boot sector

By the way, just to tie in the boot sector header, you’ll notice that our boot code starts at 54, which is where our very first assembly instructions said to jump to. I won’t dive too deeply into the boot code, just note that towards the “end” of the boot code, we can see error messages that may seem familiar to some.

The previous 6 bytes before our signature, technically bytes 504-509, contain signatures that I’ve found to be operating system version specific. Here’s a few screenshots to support this:

Windows XP

End of boot sector from a Windows XP Operating System

Windows 7/2008R2

End of boot sector from a Windows 2008 R2 Operating System

Windows 10

End of boot sector from a Windows 10 Operating System

That’s a fair amount of data thrown into one sector! As I’ve mentioned before, this particular sector is parsed by many forensic tools to extract information about the file system and understand how to interpret data. As file systems grow and change, as well as hard disk structures, we can rely on these data points to help guide us and ensure that we’re viewing the data the correct way.

The remaining sectors in this file are related to additional boot stages, and are instrumental to booting up the operating system. Here’s a screenshot of the first part of the second sector, where we can clearly see references to BOOTMGR and NTLDR:

Partial screenshot of the second sector in the NTFS file $Boot

Until tomorrow, Happy Forensicating!