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

The ReFS Forensics Adventure Continues

Over the past few months I have been attempting to understand ReFS. This post will outline what I have done with the project so far and what discoveries I have made.

Methods:

In order to investigate how ReFS works, I had to be able to work with the file system.  I did this by creating a Windows Server 2012 R2 Datacenter virtual machine and made multiple virtual hard drives 10GB and 1GB in size.  I attached these virtual drives to my virtual machine, and formatted them ReFS and NTFS.  Two of the drives, one ReFS and one NTFS, were used for comparisons. This means that the data generated was the same on each of them. Additional drives were used to get a more in depth look at ReFS. Data was created on these drives by creating files of various sizes and types, creating folders, creating links, deleting folders and files, and creating alternate data steams (ADS). After generating the data, I captured the RAM from the virtual machine and made images of the drives. These images were then used for analysis.

Sample ReFS Virtual Drive

Initial Findings:

• ReFS is not bootable. This was an expected result based on prior research and information posted on MSDN.
• According to Microsoft, Alternate Data Steams (ADS) are not supported in ReFS. I have found that this is not necessarily true. An ADS consisting of text can be found in the hex.

ADS in ReFS

• Files only appear as deleted from a hex level when they have been emptied from the recycle bin, otherwise they can still be found in tact at the previous offset. Further research needs to be done to find out what makes these files not appear in Windows Explorer prior to the trash being emptied.
• ReFS has a 64k default allocation unit size (cluster size). When formatting the drive this cannot be changed like in other file systems such as NTFS or FAT.
• Timestamps are in same format as NTFS (Windows 64 bit Little Endian).