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).