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.
The $Boot metadata file has three static data points that analysts should be familiar with.
- $Boot can be found at MFT entry 7. See
- 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:
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:
- Bytes 11 — 12 and 13 provide the bytes per sector and sectors per cluster, respectively. Remember our
fsstatoutput from previous posts:
:/mnt/ewf# fsstat ewf1
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:
- Bytes per sector is
- 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:
F8at 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
- Bytes 48–55 (
00 00 0C 00 00 00 00) provide the cluster where the
$MFTstarts. This translates to 786,432, which can be confirmed with
- Bytes 56–63 (
02 00 00 00 00 00 00 00) show the starting cluster of the
$DATAattribute 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
- 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
fsstatoutput, 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:
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:
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:
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:
Until tomorrow, Happy Forensicating!