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:

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

An Introduction to the ReFS Forensics Adventure

This is my first post in a series of posts for my Digital Forensics Capstone. At Champlain College, each senior has the ability to chose one project and conduct cutting-edge research on it; I have chosen to do my project on Resilient File System (ReFS).

ReFS is a new file system, currently available in Windows Server 2012. The features of ReFS are said to include integrity, availability, scalability, compatibility, and proactive error identifications. The resiliency comes from its ability to survive even the most severe corruption.

I will be using a clean Windows Server 2012 virtual machine (VM) for this project. Inside this VM will be two virtual drives, one formatted as ReFS and one formatted as New Technology File System (NTFS). Additionally, I will use an external hard drive formatted as ReFS. I will image each drive using Forensic Toolkit (FTK) Imager Lite before making any changes to the drive. Once I have these baseline images I will add identical data to each of the drives and image them again.  This process will be repeated multiple times. I can then analyze these images to attempt to answer the research questions below.

Windows Server 2012: Main operating system being used for this project

The questions I would like to answer through my research include:

• What does the structure of ReFS look like?
• Are there any logs or file tables specific to ReFS?
• What actions cause the metadata of a file to change in ReFS?
• How does the metadata of a file on a ReFS volume compare to the metadata of a file on an NTFS volume?
• How does a file's metadata change when it is moved from NTFS to ReFS or ReFS to NTFS?

Sources:
MSDN: Resilient File System
Building the Next Generation File System for Windows: ReFS