![](https://csdnimg.cn/release/download_crawler_static/12204893/bg5.jpg)
thing to note is that ReFS v1.2 always has 64 KiB clusters. The
format tools in Windows 10 did not support formatting ReFS v1.2
with cluster sizes other than 64 KiB, even though the documenta-
tion (Microsoft, 2018c) claims support for both 4 KiB (default) and
64 KiB cluster sizes. Our observations show that ReFS v3.2 corre-
sponds to the documentation in (Microsoft, 2018c).
ReFS volume boot record
For ReFS, the volume boot record is in the first sector of the fi le
system volume, as it is for FAT32 and NTFS (Carrier, 2005). For
FAT32 and NTFS the first 3 bytes are jump instructions to the boot
code [5, p. 254]. However, since ReFS v1.2 and ReFS v3.2 can not be
booted, the 3 first bytes are just zeros. We also found a C structure
from Microsoft (Computing, 2018)defining the fields of the file
system recognition structure (FSRS) as can be seen in Fig. 1
1
.
Therefore, we got a kick start in interpreting the ReFS VBR. The first
6 fields in Table 1 were found by using Fig. 1. When interpreting the
length of the types, we assume a Windows OS.
The names used for the FSRS structure are the names from the
developers of ReFS, while the names from byte offset 0x18 are given
based on our experiments.
Entry block
During our reverse engineering we found blocks of 16 KiB and
blocks of 64 KiB. The blocks of 16 KiB were used for metadata and
system files. However, for data streams 64 KiB allocation blocks
were used. We named the 16 KiB blocks, entry blocks.
The first entry blocks we identified were file system metadata
blocks with pointers to other entry blocks, and finally to the first
entry block containing a Bþ tree. We will describe how we found
these entry blocks in section 4.4. Entry blocks in the Bþ tree include
nodes that followed a typical Bþ tree pattern. We found a similar
structure as used by other file systems that use Bþ trees. We
identified that all these 16 KiB blocks started with a descriptor for
the block. The entry block includes a descriptor (size 0x30) and can
include one or more nodes as shown in Fig. 2. When using the
structure tables presented in this paper, the E offset means a byte
offset relative to the entry block, while the R offset means a relative
offset to the actual structure. Whenever the E and R offsets are
equal, we will only show the E offset.
The first 8 byte field found at offset 0x0 of the entry block
descriptor contains its entry block number. We also found at offset
0x18 a field describing the node identifier (Node ID). However,
nodes that contain metadata will typically have the value 0 for the
node id.
We found just one or two nodes in an entry block, but it could be
more. Each node can have one or more records. A record contains
the sub entries of a node. A node describing a directory will contain
records of files and sub directories. There will be more than one
record per file. In NTFS each file has at least one MFT record, which
consists of a number of attributes, while in ReFS each of the attri-
butes are contained within records in directory nodes. A file's
standard information attribute is often more than 1000 bytes,
which means there are not many files required until the entry block
node is full. If an entry block contains a node that runs out of space
for new records, then the Bþ tree system will utilize a new entry
block which consists of a node that has extent records. Extents
make it possible for a node to extend its capacity by including re-
cords to other entry blocks, and adding more nodes, which for
instance allows for more files within a directory node. In this case
record 1 will contain an extent pointer to the entry blocks con-
taining the existing node that is running out of space, and record 2
will have another extent pointer that points to a new entry block
where the new records can be stored in a new node. We have not
tested if the records could be reorganized between the two nodes.
The order of records within a node is decided by the order of
pointers in the pointer area. This means that records can appear in
any order in the hex dump. We detected the extents records when
we were experimenting with different numbers of files in the same
directory.
Superblock
At first we had only identified this superblock as an entry block
that points to $Tree_Control. When we reversed engineered ReFS
v3.2, we found the string SUPB in the entry block descriptor, which
we believe is an abbreviation for superblock. From other file sys-
tems, such as ext4, we know the superblock is similar to the volume
boot record. We were experimenting by trying to find pointers to
the structures within the volume boot record, however we were
looking in the wrong place. Microsoft has included these pointers in
these superblock entries. We find it strange that they did not
included all the information found in the VBR within the
superblock.
Fig. 1. File system recognition structure.
Table 1
Structure of the volume boot record.
Offset Length Description
0x00 3 Jmp (Jump instructions)
0x03 8 FSName
0x0B 5 MustBeZero
0x10 4 Identifier
0x14 2 Length (of FSRS)
0x16 2 Checksum (of FSRS)
0x18 8 Sectors in volume
0x20 4 Bytes per sector
0x24 4 Sectors per cluster
0x28 1 File system major version
0x29 1 File system minor version
0x2A 14 Unknown
0x38 8 Volume Serial Number
Table 2
Structure of the entry block descriptor.
E offset Length Description
0x00 0x8 Entry Block number
0x08 0x08 Unknown
0x10 0x08 Unknown
0x18 0x08 Node ID
0x20 0x08 Unknown
0x28 0x08 Unknown
1
We added comments to make the structure easier to read for those not familiar
with C structures.
R. Nordvik et al. / Digital Investigation 30 (2019) 127e147 131