Walking through NTFS File System Attributes

Scenario

One of the important tasks when analyzing a file system is to know how to locate and find a file's true logical location on disk. Which clusters is it occupying and why is extremely important. This lab is designed to understand how to do that manually. You are required to locate a couple of files by analyzing the NTFS attributes and especially the NTFS data-runs used.

Use the forensic image named "Lab12.001" file [located at C:\DFP\Labs\Module05\Lab12\Lab12.001] for this lab.

Goals

What you will learn

Recommended tools

FTK Imager

SOLUTIONS

Task 1: Basic NTFS Attribute Analysis

Start by opening the first disk which is [Lab12.001] [located at C:\DFP\Labs\Module05\Lab12\Lab12.001] and loading it using FTK Imager.

FTKImager

Now, let's start answering the required questions.

What is the cluster size used for this disk?

This can be found by viewing the volume boot record (VBR). Click on the NTFS Partition "CarveMe2" and switch your view to hexadecimal. Bytes 11-12 bytes per sector. Byte 13 will tell you the sectors per cluster. Sweep bytes 11-12, and click on Hex Value Interpreter.

Bytes per sector

Now sweep byte 13 for sectors per cluster

Sectors Per Cluster

There are 512 bytes per sector and 8 secors in a cluster. That means each cluster is 4096kb.

Check this by switching from Hex Value Interpreter to Properties.

Cluster Size Properties

How many user files (pdf, exe, etc.) did you find and what was the size of each one of them.

Item File Name Size
1 bin2sc.py 373 bytes
2 Document1.pdf 531 Kilobytes
3 File02.exe 7.9 Megabytes
4 Photo05.jpg 1.4 Megabytes

Now we need to locate the MFT entry for each file and report back the following: a. Attribute ID for the Standard Information Attribute and its size b. File Name Attribute and its size c. Data Attribute and whether the file is resident or not (check residency flag) d. Offset to the data-run, and the data run itself

[Answer for the first file:] bin2sc.py

Right click in the hexadecimal space and select find. Search for: "bin2sec.py", leaving the options at default. You will need to press F3 to continue to search. You are looking for the filename to me near the FILE0 entry. You should find this at offset 069946608, with FILE0 being at 069946368. You may need to switch to decimal offsets by right clicking in the hexadecimal space and selecting the option.

bin2sec offset

The File record header is from offset 1-55, The $STANDARD_INFORMATION attribute begins at offset 56 and continues through the next 80 bytes.

Now, based on the NTFS documentation and the course notes, the standard information attribute has a type ID of 0x10.

Therefore at offset 56 we find 10000000 which is the $STANDARD_INFORMATION attribute id 0x10. To locate the next attribute, we need to calculate the length of the $STANDARD_INFORMATION attribute, which is found in the next four bytes after the 4 bytes related to the attribute type ID. So, here we find the value (0x60000000 little endian) which means this attribute is 0x60 bytes long or 96 bytes (decimal).

This can be seen in the figure below.

StdAttribute

Now, as you can see, we have arrived at the next attribute which is 0x30000000 or 0x30. The attribute that has an ID of 0x30 is the $FILE_NAME attribute. The size is calculated the same way; we take the next four bytes to get the size of the attribute. Here we see 0x70000000 which means 0x70 or 112 in decimal. This can also be seen in the next figure.

File Attributes

Now we reach the next attribute which starts with 0x80000000 or 0x80. The $DATA attribute is the one that uses an ID of 0x80. Now, if you go back and look at the size of this file, you will find that it is 373 bytes, which is under 700 bytes, and means we have a resident attribute here. This means the file content is going to be found within the MFT File Record entry, or in other words; within the 1024 bytes, allocated for the entry.

If we calculate the length of the file, we will find that it is 0x90010000 or 0x0190 bytes long, and this leads that our file has been allocated 400 bytes. Don't forget this includes the header. Before we finish the analysis for this file, just remember that at offset 0x8 we can find a single byte that is used to mark the attribute whether resident or not. So, if you go to offset 0x8, we find that it has the value 0x00, which means our file is resident (non-resident = 0x01).

Since this is not a non-resident file, then we don't have a data run for it. Let us move on to the next file.

Answer for the second file: Document1.pdf

Same as before, we start by right-clicking on the file and then select Navigation -> Seek FILE Record. Again, at offset 0x14 in hexadecimal, we can find a two bytes value which represents the offset to the first attribute for this file. So, if we check offset 0x14 (20 decimal), we find the value 0x3800 (little endian). This means that our first attribute is at offset 0x38 in hex or 56 in decimal.

Again, at offset 56 we found 10000000 which is the \$STANDARD_INFORMATION id 0x10. As we did before, to locate the next attribute, we need to calculate the length of the $STANDARD_INFORMATION attribute, which can be found in the next four bytes after the 4 bytes related to the attribute type ID. So, here we find the value (0x60000000 little endian) which means this attribute is 0x60 bytes long or 96 bytes (decimal). This can be seen in the next figure.

Now, as you can see, we have arrived at the next attribute which is 0x30000000 or 0x30. The attribute that has an ID of 0x30 is the $FILE_NAME attribute. The size is calculated the same way; we take the next four bytes to get the size of the attribute. Here we see 0x78000000 which means 0x78 or 120 in decimal. This can be seen in the next figure.

Now we reach the next attribute which starts with 0x80000000 or 0x80. The $DATA attribute is the one that uses an ID of 0x80. Now, if you go to offset 0x8, we find that it has the value 0x01, which means our file is non-resident. Also, the length of this attribute is 0x48000000 or 0x48 (72 decimal) as seen in the next figure.

To find where this file is stored, we need to locate the data run for the file. This can be done by checking offset 0x20, which is two bytes long. So, by going to offset 0x20 or 32 in decimal, we find that the data run is located at 0x40 or 64 in decimal. Now, by going to that location, we find the following:

So, the data run is: 0x2285009107. We will come back to this later in Task #2.

BTW, the values 0xFFFFFFFF82794711 are the marker of the end of the MFT File Record.

Now, all you need to do is repeat the same process for the rest of the files (File02.exe and Photo05.jpg).

Summary of findings:

File Name SIA (size) FNA (size) Data (size) Resident Data-run
Bin2sc.py 10 (0x60) 30 (0x70) 80 (0x190) Yes None
Document1.pdf 10 (0x60) 30 (0x78) 80 (0x48) No 0x2285009107
File02.exe 10 (0x60) 30 (0x70) 80 (0x48) No 0x22DD071608
Photo05.jpg 10 (0x60) 30 (0x70) 80 (0x48) No 0x2264012D06

Task 2: Parsing the NTFS Dataruns

Now, let's use the results we got in Task #1 to answer the questions below:

What does each part of the data run mean? [Answer:]

The data run string is defined like this:

The first byte is actually divided and parsed like this:

a. The first nibble represents the number of bytes that represent the first cluster number

b. The second nibble represents the number of bytes that represent the number of clusters this file is occupying

Byte Bytes Bytes
Nibble Nibble Representing No. of Clusters Representing No. of the First Cluster

So, as you can see, it all goes down to the first byte in the data run.

Let's answer both questions 2 and 3 together.

What is the first cluster for each file?

How many clusters are being used for each file?

Answer:

Since the first file is resident, we are not going to calculate where the first cluster is.

The first cluster for the second file Document1.pdf is calculated like this:

Data run: 0x2285009107

2: 91 07 -> number of the first cluster (little endian)

= 1937

2: 85 00 -> number of clusters allocated (little endian)

= 133

And for the data run for File02.exe = 0x22DD071608

2: 16 08 -> the first cluster

= 2070

2: DD 07 -> no. of clusters

= 2013

Finally, the data run for file Photo05.jpg = 0x2264012D06

2: 2D 06 -> the first cluster

= 1581 2: 64 01 -> no. of clusters = 356

What is the first sector number for each non-resident file? Answer:

Here is when the size of the cluster comes in handy! Now, to locate the first sector for each file, we can do that based on the equation found below:

First sector = (First cluster no. * cluster size ) / sector size

Means, for the second file Document1.pdf

First sector = 1937 * 4096 / 512 = 15496

For the third file File02.exe

First sector = 2070 * 4096 / 512 = 16560

Means, for the second file Photo05.jpg

First sector = 1581 * 4096 / 512 = 12648

Verify your results with the results automatically given to you by WinHex. Answer:

This is easily done by right-clicking on the file and then Navigation List Clusters. The proof for each file is below. (Cluster = First cluster and Total = No. of clusters)

Document1.pdf

Document1Info

File02.exe

File02Info

Photo05.jpg

Photo05Info

Summary of findings:

File Name First Cluster No. of clusters First sector
Document1.pdf 1937 133 15496
File02.exe 2070 2013 16560
Photo05.jpg 1581 356 12648