Nearing the End of the ReFS Adventure

I am nearing the end of my semester and finishing up my Capstone project. I have made quite a bit of progress in discovering ReFS's structure and how it compares to NTFS. Below are my findings, including updates to the findings talked about in my post, File Tables in ReFS.

Findings:

• There is a file table like structure in ReFS that could be compared to NTFS. My last post, ReFS/NTFS Comparison, shows a comparison breakdown between the two file systems.

• The beginning of each table has MACE times associated with them. The created time for each of the tables is the same, which could indicated that the file was copied and then modified by the system to reflect new files being created or other changes.

• According to Microsoft, ADS is not supported in ReFS. While an alternate steam cannot be found on the system, if an ADS consists of text, the text can be found in the file table. If the text is too long for the file table, it will be pushed into unallocated space. An ADS consisting of a file or executable is not possible. When the command is run to make this type of ADS, the response is "The requested operation could not be completed due to a file system limitation."

•  ReFS is not bootable. This is an important fact because not being bootable means that it cannot be the only volume on a system. As of right now, ReFS drives are mainly going to be data storage devices such as drives found in servers. This is due to their resiliency and ability to house extremely large files.

•  Compared to NTFS there is the possibility for a significantly more slack space with ReFS. This is due to the file system defaulting to large cluster sizes. This allows for users to hide data in slack space, the space at the end of a file before the next cluster begins, and forensic examination tools do not always pick up on this.

 These findings will allow investigators to be aware of where data can be hidden on a ReFS drive and  allow them to manually parse the file system to find any necessary metadata. Future work such as analyzing RAM dumps, decoding metadata files, and continuing to parse the file table will be important in order to fully understand how ReFS works.

ReFS/NTFS Comparison

In my last post I talked about the ReFS file table. Here's a visual comparing ReFS to NTFS:

File Tables in ReFS

I recently discovered what could be considered a file table in ReFS. When searching for the file table I found a number of instances of the file table that looked very similar, but had minor differences and some of which were missing a few files in them. I was able to see in EnCase 7 that only one of these tables was actually in allocated space, the rest being in unallocated space. At first I wasn't sure why there would be multiple file tables that essentially showed the same files. After additional analysis I was able to see that the most recent file table, the one in allocated space, was the file table that had all the current files listed with the most up-to-date metadata. It seems that the beginning of each table has MACE times associated with them. The created time for each of the tables is the same which could indicated that the file was copied and then modified by the system to reflect new files being created or other changes. So far I have been able to determine that the file table includes the file name, MACE times, size of the file in bytes, and a pointer to the physical cluster location of the file.

The images below show an example of the MACE times from an entry in the unallocated space and updated table in allocated space. Both show the created time as being 1/30/14 4:28:44 UTC, but the unallocated space modified and accessed times show 1/30/14 4:46:19 UTC, while the allocated space times show 1/30/14 5:12:06 UTC. The changes to the file table could be used in a forensic investigation to show data that was once on the drive.

MACE times in unallocated space file table

MACE times in allocated space file table

The image below shows an example of a file table entry. The orange highlights the name of the file, Paragraph.txt. The blue highlights the MACE times for the file which are in Windows 64-bit Little Endian. The red highlights the file size in bytes. In this case the hex 80 04, stored in Little Endian, converts to 1,152 bytes. The green highlights the hex, also in Little Endian, that points to the starting cluster of the file. In this case 70 03 converts to cluster 880.

File Table Entry Example