NTFS CHEETSHEET

Irrespective of any file system, regardless of their name, they must perform certain basic
functions for the system:

 Track the name of the file (or directory).

 Track the point where the file starts.
 Track the length of the file along with other file metadata, such as date and time
stamps.
 Track the clusters used by the file (cluster runs).
 Track which allocations units (clusters) are allocated and which are not.

NTFS, compared to the FAT file system, is more robust, providing stronger security, greater
recoverability, and better performance with regard to read, write, and search capabilities.

In an NTFS partition, unlike FAT, all the important file system data is contained in actual files.
NTFS uses many system files, but at the very heart of the NTFS system are $MFT (master file
table) and $Bitmap. $MFT is similar to the directory entry in FAT, and the $Bitmap is similar
to the FAT1 and FAT2 in FAT.

$MFT is a database with an entry for every file and directory in the partition, including an
entry for itself.

 Each entry is fixed in length and is almost always 1,024 bytes.

 Each entry has a header (FILE0), which is followed by series of attributes.
 Everything about a file is an attribute, including the data itself.
 If a file is small, sometimes its data is stored within the $MFT and is called resident data
 Typically, the MFT is allocated about 12.5% of the partition size.

ORGANIZATION OF AN NTFS VOLUME.

NTFS MASTER FILE

BOOT MASTER FILE TABLE FILE SYSTEM DATA
TABLE COPY
SECTOR

Source: http://technet.microsoft.com/en-us/library/cc781134%28v=ws.10%29.aspx
 COMPONENT DESCRIPTION
NTFS BOOT SECTOR CONTAINS THE BIOS PARAMETER BLOCK THAT STORES INFORMATION ABOUT THE LAYOUT OF
THE VOLUME AND THE FILE SYSTEM STRUCTURES, AS WELL AS THE BOOT CODE THAT LOADS
WINDOWS SERVER 2003.

MASTER FILE TABLE CONTAINS THE INFORMATION NECESSARY TO RETRIEVE FILES FROM THE NTFS PARTITION,
SUCH AS THE ATTRIBUTES OF A FILE.

FILE SYSTEM DATA STORES DATA THAT IS NOT CONTAINED WITHIN THE MASTER FILE TABLE.
MASTER FILE TABLE COPY INCLUDES COPIES OF THE RECORDS ESSENTIAL FOR THE RECOVERY OF THE FILE SYSTEM IF
THERE IS A PROBLEM WITH THE ORIGINAL COPY.

NTFS BOOT SECTOR

The size of each MFT entry is defined in the boot sector, but all versions from Microsoft have
used a size of 1,024 bytes.

Byte Field Field Name

Offset Length
0 3 bytes Jump instruction
3 8 bytes OEM ID
11 2 bytes Bytes Per Sector
13 1 byte Sectors Per Cluster. The number of sectors in a cluster
14 2 bytes Reserved Sectors. Always 0 because NTFS places the boot sector at the
beginning of the partition. If the value is not 0, NTFS fails to mount the
volume.
16 3 bytes Value must be 0 or NTFS fails to mount the volume.
19 2 bytes Value must be 0 or NTFS fails to mount the volume.
21 1 byte Media Descriptor. Provides information about the media being used. A value
of F8 indicates a hard disk and F0 indicates a high-density 3.5-inch floppy disk
22 2 bytes Value must be 0 or NTFS fails to mount the volume
24 2 bytes Not used or checked by NTFS.
26 2 bytes Not used or checked by NTFS.
28 4 bytes Not used or checked by NTFS.
32 4 bytes Not used or checked by NTFS.
36 4 bytes The value must be 0 or NTFS fails to mount the volume.
40 8 bytes Total Sectors. The total number of sectors on the hard disk
48 8 bytes Logical Cluster Number for the File $MFT. Identifies the location of the MFT
by using its logical cluster number.
56 8 bytes Logical Cluster Number for the File $MFTMirr. Identifies the location of the
mirrored copy of the MFT by using its logical cluster number.
 64 1 byte Clusters Per MFT Record.
 The size of each record. NTFS creates a file record for each file and a
folder record for each folder that is created on an NTFS volume. Files
and folders smaller than this size are contained within the MFT. If this
number is positive (up to 7F), then it represents clusters per MFT
record. If the number is negative (80 to FF), then the size of the file
record is 2 raised to the absolute value of this number.
65 3 bytes Not used by NTFS
68 1 byte Indx buffer size indicator
69 3 bytes Not used or checked by NTFS.
72 8 bytes 32 Bit volume serial number.
80 4 bytes CHECKSUM-0 means instruction to skip its calculation.
84 426 bytes Boot strap code.
510 2 bytes Boot record signature.

1. Jump 3. Bytes Per 4. Sectors per

instruction 2. OEM id Cluster
Sector

Media
Descriptor
5. Total
Sectors
6. Logical
Cluster
Number for
the File $MFT 7. Logical
Cluster
Number for the
8. Clusters per File $MFTMirr
MFT Record

9. Index
buffer size
indicator

10. Boot
signature
Conclusions:

3. Bytes per Sector: The number of bytes per sector is 0x 02 00. (Translate from little endian),
or 512.

4. Sector per cluster: 8

5. Total no’s of sectors: 0xFF BF 32 0B 00 00 00 00.On converting to little endian becomes

0x0B 32 BF FF which is 187875327 in decimal.

6. Logical cluster number for $MFT: 0x00 00 0C 00 00 00 00 00.On converting to little endian
becomes 0x0C 00 00, which is 786432 in decimal.

7. Logical cluster number for $MFTMirr: 0x 02 00 00 00 00 00 00 00.On converting to little

endian becomes 0x02, which is 2 in decimal.

8. Clusters Per $MFT record: F6, which is 246 in decimal.

MASTER FILE TABLE

NTFS MASTER FILE FILE SYSTEM DATA MASTER
BOOT TABLE FILE TABLE
SECTO COPY

 The Master File Table (MFT) is the heart of NTFS because it contains the information
about all files and directories.
 Every file and directory has at least one entry in the table, and the entries are 1 KB in
size, but only the first 42 bytes have a defined purpose. MFT is divided into records of
the fixed size (usually 1 KB), and each record corresponds to some file.
 The remaining bytes store attributes, which are small data structures that have a very
specific purpose. For example, one attribute is used to store the file's name, and
another is used to store the file's content. Figure below shows the basic layout of an
MFT entry.
 In NTFS, everything is a file. The MFT is also a file. The most interesting thing in NTFS is
that the MFT has an entry for itself in the MFT. The first entry in the table is named
$MFT and it describes the on-disk location of the MFT. One basic concept for all
versions of NTFS is the MFT Zone. Windows creates the MFT as small as possible and
expands only when more entries are needed. Therefore, there is a risk that it could
 easily become fragmented if the space after the MFT is allocated to a file. To prevent
this, Microsoft reserves part of the file system for the MFT. The MFT Zone is a
collection of consecutive clusters that are not used to store file or directory content
unless the rest of the disk is full. By default, Microsoft allocates 12.5% of the file system
to the MFT. If the rest of the file system fills up, the MFT Zone will be used.

The starting location of the MFT is given in the boot sector, which is always located in the
first sector of the file system.

In the shown Figure the boot sector

is used to find the first MFT entry,
which shows that the MFT is
fragmented and goes from clusters
32 to 34 and 56 to 58.

Like FAT, NTFS uses clusters, which

are groups of consecutive sectors.

FILE SYSTEM METADATA FILES

Because the MFT stores information about itself, NTFS reserves the first 16 records of the MFT
for metadata files (approximately 16 KB), which are used to describe the MFT.

The name of each file system metadata file begins with a "$," and the first letter is capitalized.

MFT File System PURPOSE

Record Name File
0 $Mft Master The entry for the MFT itself. Contains one base file record for
file table each file and folder on an NTFS volume.
1 $MftMirr Master It is a duplicate image of the first four records of the MFT.
file table
mirror
2 $LogFile Log file This file is a relational database that records transactions to
and from the disk.
  The size of the log file depends on the size of the
volume; It can be used to recover from a system
failure.
 NTFS uses a “lazy write “caching system where data is
not immediately written to disk and it also needs more
than one transaction to complete a filing task. For
example, two transactions are needed to update a file:
one to update the file itself and a second to update
the details in the MFT with respect to file dates and
times and so forth.
 Should a power failure occur between the two
transactions, recovery can be effected by completing
the missed task, as indicated by the $Logfile.
3 $Volume Volume Contains information about the volume, such as the volume
label, the NTFS version number, the creation time and date
and the “dirty flag”. This latter item is used to indicate
whether or not a clean shutdown took place on the last use
of the volume.
4 $AttrDef Attribute Contains Attribute names, allocated identifier numbers, and
definitions descriptions. Its record length is 160 bytes
5 $. (dollar Root file Contains the root directory of the file system.
dot) name
index
6 $Bitmap Contains the allocation status of each cluster in the file
system.
It is simply made up of binary flags, where “1” symbolizes
Cluster that a cluster is in use, and “0” symbolizes that a cluster is
bitmap not in use. In some respects, it is similar to a FAT but without
the pointer values. $Bitmap simply records the use of the
storage blocks on the volume.
7 $Boot Contains the boot sector and boot code for the file system.
This is the Boot Record for the volume. It includes the BPB
Boot (BIOS
sector Parameter Block) which is used to mount the volume as well
as additional bootstrap loader code which is used if the
volume is bootable.
8 $BadClus Contains bad clusters for a volume. This is a file which
addresses the whole volume and which reports its size as
Bad being the whole volume size.
cluster file It should be noted that this file only refers to clusters and
not to sectors. If one sector in a cluster is found to be bad
then the whole cluster is marked as bad and an appropriate
 entry is made in the $Bad stream of this file. The cluster is
also marked as “used” in $Bitmap to ensure that no data is
stored there. NTFS does implement a feature on fault-
tolerant volumes where, on identifying a bad sector, all data
within the cluster concerned is moved to another location
and the file details are amended appropriately.
9 $Secure
Security Contains information about the security and access control
file for the files (Windows 2000 and XP version only).
10 $Upcase Upcase Converts lowercase characters to matching Unicode
table uppercase characters.
11 $Extend NTFS A directory that contains files for optional extensions.
extension Microsoft does not typically place the files in this directory
file into the reserved MFT entries.

FIGURE SHOWING THE DIFFERENT NTFS METADATA FILES.

The first field in each MFT entry is the signature, and a standard entry will have the ASCII string
"FILE." If an error is found in the entry, it may have the string "BAAD."
STORING & DELETING A FILE
To store a file on the system, the following processes are carried out, though not necessarily in
the order shown:

 A search is made of the MFT to find the first available record.

 If the file is small enough to fit into the MFT record together with the file Attributes it is
written there; otherwise a search is made of the volume storage area bitmap to identify
a location and space where the file data can be recorded out on the volume.
 The Attributes of the file are written to the MFT.
 The file data is written to the MFT or volume.
 Pointers are updated in the MFT to identify the location where the file data is stored.
 For non-resident data the bitmap is updated to show that the cluster(s) occupied by the
file are now in use.
 The parent directory listing is updated and re-sorted.

To delete a file on the system, the following processes are carried out, though not necessarily
in the order shown:

 The MFT record is marked as deleted (a one byte flag).

 For non-resident data the bitmap is updated to show that the cluster(s) occupied by the
file are now available for use.
 The file entry in the parent directory listing is removed and the listing is re-sorted.
 Note, however that the MFT record for the file itself will remain intact until overwritten.
NTFS FILE ATTRIBUTES & RESIDENT DATA
The NTFS file system views each file (or folder) as a set of file attributes.

Elements such as the file's name, its security information, and even its data, are all file
attributes.

Each attribute is identified by an attribute type code and, optionally, an attribute name.

When a file's attributes can fit within the MFT file record, they are called resident attributes.
For example, information such as filename and time stamp are always included in the MFT file
record.

When all of the information for a file is too large to fit in the MFT file record, some of its
attributes are nonresident. The nonresident attributes are allocated one or more clusters of
disk space elsewhere in the volume.

If all attributes cannot fit into one MFT record NTFS creates additional MFT records and puts
the Attribute List attribute to the first file's MFT record to describe the location of all of the
attribute records.

Directories are dealt with in a similar manner. If the directory listing (which is similar to a text
file) can be accommodated within the MFT record then it becomes resident data.

It is possible that the MFT record retains some entries as resident and some entries as non-
resident. Non-resident data is stored out on the volume in “Index Buffer” files.

These do not appear as files to the operating system or, indeed, to forensic software.

These files start with the keyword “INDX” and are laid out internally in a similar manner to
MFT records using attributes.

FIGURE SHOWING THE INDEX RECORD.

ATTRIBUTE CONTENT
The content of the attribute can have any format and any size. For example, one of the
attributes is used to store the content for a file, so it could be several MB or GB in size. It is not
practical to store this amount of data in an MFT entry, which is only 1,024 bytes.

To solve this problem, NTFS provides two locations where attribute content can be stored. A
resident attribute stores its content in the MFT entry with the attribute header. This works
for only small attributes. A non-resident attribute stores its content in an external cluster in
the file system. The header of the attribute identifies if the attribute is resident or non-
resident.

If an attribute is resident, the content will immediately follow the header. If the attribute is
non-resident, the header will give the cluster addresses.

TYPE ATTRIBUTE NAME DESCRIPTION

IDENTIFIER TYPE
16 Standard $STANDARD_ Information such as access mode (read-only,
Information INFORMATIO read/write, and so forth) timestamp, the last
N accessed, written, and created times, and link
count; and the owner and security ID.
32 Attribute $ATTRIBUTE_ Locations of all attribute records that do not fit in
List LIST the MFT record.
48 File Name $FILE_NAME File name, in Unicode, and the last accessed,
Written, and created times. A repeatable attribute
for both long and short file names. The long name
of the file can be up to 255 Unicode characters.
The short name is the 8.3, case-insensitive name
for the file
64 Object ID $OBJECT_ID A 16-byte unique identifier for the file or
directory. Exists only in versions 3.0+ and after
(Windows 2000+).
80 $SECURITY_ The access control and security properties of the
DESCRIPTOR File

96 Volume $VOLUME_NA Volume name.

Name ME
112 Volume $VOLUME_ Used only in the $Volume system file. Contains the
 Information INFORMATION volume version.
128 $DATA File data. NTFS supports multiple data attributes
per file. Each file typically has one unnamed data
attribute. A file can also have one or more named
data attributes.

Nearly every allocated MFT entry has a $FILE_NAME and a $STANDARD_INFORMATION type
attribute.

Every file has a $DATA attribute, which contains the file content. If the content is over roughly
700 bytes in size, it becomes non-resident and is saved in external clusters.

When a file has more than one $DATA attribute, the additional attributes are sometimes
referred to as alternate data streams (ADS). The $DATA attribute can store any content that
an application or user wants to store there.

Every directory has an $INDEX_ROOT attribute that contains information about the files and
subdirectories that are located in it.

$AttrDef contains attribute definitions.

$STANDARD_INFORMATION contains a number of forensically interesting bits, including file

creation time, metadata change time, data modification time, last accessed time, a flag value
that can describe various properties of the file, file owner information, a security ID value that
is used to map the file to applicable access controls.
 PARTITION TABLE 1 PARTITION TABLE 2

PARTITION TABLE

NTFS FILE SYSTEM

FIGURE SHOWING A PARTITION HOLDING AN NTFS FILE SYSTEM

PARTITION TABLE 1 PARTITION TABLE 2

NTFS FILE SYSTEM

VOLUME
BOOT SECTOR MORE FILES
MFT METAFILES

PARTITION TABLE PARTITION TABLE

1 2

NTFS FILE SYSTEM

VOLUME BOOT
MORE FILES
SECTOR

FREE SPACE HIDDEN COPY

MORE
MFT FREE SPACE FREE SPACE OF VOLUME
METADATA
BOOT SECTOR

$ MFT

$MFTMirr

$Logfile

$Volume

$AttrDef  Because the MFT stores information about

itself, NTFS reserves the first 16 records of the
$Bitmap
MFT for metadata files (approximately 16 KB),
$Boot
which are used to describe the MFT.
$BadClus

$Secure

$Upcase

$Extend
MFT ATTRIBUTES

PARTITION TABLE PARTITION TABLE

1 2

NTFS FILE SYSTEM

VOLUME BOOT
MORE FILES
SECTOR

FREE SPACE HIDDEN COPY

MORE
MFT FREE SPACE FREE SPACE OF VOLUME
METADATA
BOOT SECTOR

MFT ENTRY ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE

HEADER HEADER PROPER HEADER PROPER
MFT ENTRY ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE
HEADER HEADER PROPER HEADER PROPER
MFT
ENTRIES

MFT ENTRY ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE

HEADER HEADER PROPER HEADER PROPER
 MFT ENTRY HEADER
The attribute header identifies the type of attribute, its
size, and its name. It also has flags to identify if the
value is compressed or encrypted. The attribute type is
PARTITION PARTITION a numerical identifier based on the data type.
TABLE 1 TABLE 2
Each MFT entry header is 48 bytes in length.

Every MFT entry also has a 16-bit sequence number

that is incremented when the entry is allocated.

NTFS FILE SYSTEM  For example, consider MFT entry 313 with a
sequence number of 1. The file that allocated
entry 313 is deleted, and the entry is reallocated
to a new file.
VOLUME MORE FILES  When the entry is reallocated, it has a new
BOOT SECTOR sequence number of 2. The MFT entry and
sequence number are combined, with the
sequence number in the upper 16-bits, to form a
64-bit file reference address
FREE MORE
HIDDEN COPY
SPACE MFT FREE
METADATA
FREE OF VOLUME
SPACE SPACE BOOT SECTOR

MFT ENTRY ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE

HEADER HEADER PROPER HEADER PROPER

SIGNATURE OFFSET TO # OF ENTRIES IN SEQUENCE OTHER

(FILE) FIX UP FIXUP ARRAY NUMBER VALUES
FIXUP VALUES
ARRAY
 UPDATE SEQUENCE ARRAY AND FIXUP ARRAY
The Update Sequence Array holds values that are used to verify that a group of sectors are valid.

Microsoft uses a method called a ‘Fixup‘ to verify that the sectors it is reading are free from corruption.
Here is how it works:

The offset to the Update Sequence Array in this particular case is 30h or 42 decimal. If you look 42
bytes from the beginning of the sector you will see a two byte number. This number is also written at
byte offset 1FEh or 510 decimal. If the sector is valid then these two numbers should match. If you take
a look at the second sector of the MFT record at offset 510 you should see that number again. So the
number at offset 42 was taken and written to offset 510 for the first and the second sector of the MFT
record.

When the record is created the data at those two

offsets is read into memory. That data is then
stored in the next four bytes of the Update
Sequence Array. Two bytes for the first sector
and two bytes for the second sector. Those bytes
replace the ‘Fixup’ number placed at offset 510.
In this particular case both of the values are ’00
00’ as shown in the figure. However, there are
many times when that data is not a zero and
may contain security information, dates, file
sizes, and even the cluster mapping.
The following is a sequence of events the
operating system uses when reading an MFT
record. There may be other steps but these are
the ones that must be used in order to process
the ‘Fixup’ verification logic.

1. Read the records two sectors from the MFT.

2. Read the two byte offset of the Update
Sequence Array located right after the four byte
record magic value
3. Compare the first number in the array to the
number at offset 510 in sector 1.
4. If the values do not match indicate and error.
This is when ‘chkdsk’ could be run
5. Repeat steps 3 and 4 for sector 2.
6. Take the next value in the Update Sequence
Array and write it at offset 510 in sector 1
7. Repeat step 6 for sector 2
MFT RECORD HEADER LAYOUT
All MFT records follow the same structure.
 They are 1024 bytes in size, and start with a 48-byte header section and a 8-
byte Fixup Array (the header length is variously described as 48 or 56 bytes,
depending on whether the Fixup Array is classed as an attribute or not).
 At offset 0x38 is the start of a string of attributes (the header is not an
attribute). The header describes the properties of the record, and the attributes
describe all aspects of the file from its name to its data

BYTE RANGE DESCRIPTION

0-3 MFT RECORD SIGNATURE(“FILE”)
4-5 OFFSET TO UPDATE SEQUENCE
6-7 NUMBER OF 2 BYTE ENTRIES IN FIXUP ARRAY
8-15 $LOGFILE SEQUENCE NUMBER (LSN)
16-17 RECORD USAGE NUMBER(SEQUNCE VALUE)
18-19 HARD LINK COUNT
20-21 OFFSET TO FIRST ATTRIBUTE
22-23 FLAGS (IN-USE AND DIRECTORY)
FLAGS:01 00RECORD IN USE,02 00 DRIECTORY

24-27 USED SIZE OF MFT ENTRY

I.E NUMBER OF TIMES THIS RECORD HAS BEEN USED.
28-31 ALLOCATED SIZE OF MFT ENTRY
32-39 FILE REFERENCE TO BASE FILE RECORD
40-41 NEXT ATTRIBUTE ID
42-1023 ATTRIBUTES AND FIXUP VALUES
 5. RECORD USAGE NUMBER 3. NUMBER OF
4. $LOGFILE SEQUENCE
(SEQUNCE VALUE) ENTRIES IN FIXUP ARRAY
NUMBER (LSN)

2. OFFSET TO
10. ALLOCATED SIZE
UPDATE SEQUENCE
1. MFT RECORD OF MFT ENTRY
SIGNATURE

6. HARD LINK COUNT

7. OFFSET TO
FIRST ATTRIBUTE

8. FLAGS
(IN-USE AND DIRECTORY)

9. USED SIZE OF MFT ENTRY

I.E NUMBER OF TIMES THIS
RECORD HAS BEEN USED

11. FILE REFERENCE

TO BASE FILE RECORD

12. NEXT ATTRIBUTE ID

CONCLUSIONS
1. BYTE RANGE-0 TO 3- MFT RECORD SIGNATURE (“FILE”)

-Record identifier 'FILE'. If the entry is unusable the record identifier would be
'BAAD'.

2. BYTE RANGE-4 TO 5- OFFSET TO UPDATE SEQUENCE

-30 00: This output is in little-endian ordering, so we need to reverse the order of
the numbers. So it becomes 00 30, which is 48 in decimal. This shows that the fixup array is
located 48 bytes (0x0030) into the MFT entry.

3. BYTE RANGE-6 TO 7- NUMBER OF BYTE ENTRIES IN FIXUP ARRAY.

-03 00: This output is in little-endian ordering, so we need to reverse the order of
the numbers. So it becomes 00 03, which is 3 in decimal. This means that the array has three
values in it. The fixup array is used to validate sectors within the MFT record.

4. BYTE RANGE 8 TO 15-$LOGFILE SEQUENCE NUMBER (LSN)

- Holds the sequence number of the logfile entry that tracks every change to the file. The
log records when metadata updates are made to the file system so that a corrupt file system
can be more quickly fixed.

-4A 43 22 D4 0C 00 00 00: This output is in little-endian ordering, so we need to reverse

the order of the numbers. So it becomes 00 00 00 0C D4 22 43 4A, which is 55098622794 in
decimal.

5. BYTE RANGE-16-17: RECORD USAGE NUMBER (SEQUNCE VALUE)

- The sequence value is incremented when the entry is either allocated or

unallocated, determined by the OS. i.e it holds the sequence number of the logfile entry that
tracks every change to the file

-01 00: This output is in little-endian ordering, so we need to reverse the order of the
numbers. So it becomes 00 01, which is 1 in decimal. This means that this is the first time this
entry has been used.
6. BYTE RANGE-18-19: HARD LINK COUNT

-The link count shows how many directories have entries for this MFT entry. If hard links
were created for the file, this number is incremented by one for each link.

Microsoft defines hard links as:

“NTFS-based links to a file on an NTFS volume. By creating hard links, you can have a single file
in multiple folders without duplicating the file. You can also create multiple hard links for a file
in a folder if you use different file names for the hard links. Because all of the hard links
reference the same file, applications can open any of the hard links and modify the file.”

-01 00: in little endian becomes 00 01 which is 1 in decimal. This brings us to a

conclusion that only one directory has entry for this MFT record/entry.

7. BYTE RANGE-20-21: OFFSET TO FIRST ATTRIBUTE

-This is the first attribute for the file. All other attributes follow the first one, and we find
them by advancing ahead using the size field in the attribute header. The end of file marker
0xffffffff exists after the last attribute. If a file needs more than one MFT entry, the additional
ones will have the file reference of the base entry in their MFT entry.

-38 00: This output is in little-endian ordering, so we need to reverse the order of the
numbers. So it becomes 00 38, which is 56 in decimal. This indicates that the first Attribute
starts at byte offset 56.

8. BYTE RANGE-22-23: FLAGS (IN-USE AND DIRECTORY)

- The two bytes, and in particular the byte at offset 22, refer to the current state of this
particular record. The possible values are: 00 00 = a deleted FILE record, 01 00 = a FILE record
in use, 02 00 = a deleted DIRECTORY record, and 03 00 = a DIRECTORY record in use.

- In this case we note that the value is 01 00 and that it is a FILE record in use.

9. BYTE RANGE-24-27: USED SIZE OF MFT ENTRY (i.e number of times this record has been
used)

-Indicates the “real” length of the file record. If this MFT record is the base entry for the
file then this field is zero: if the record is an extension then this field holds the base record
reference address. Here it is referred to here as the “logical size”. This “logical” size is the
actual number of bytes of data stored in the record.
 - B0 01 00 00: which becomes 00 00 01 B0; which equates to 432 in decimal. Therefore it
can be concluded that the entry size is 432 bytes.

10. BYTE RANGE: 28-31: ALLOCATED SIZE OF MFT ENTRY

- indicate the allocated storage size of the file record. This is referred to as the “physical”
size and this size has already been preset to 1024 bytes by the BPB.

-00 04 00 00:In this case translation from the little endian format gives
00000400h,which does indeed equate to 1024 decimal.

9. BYTE RANGE- 32-39: FILE REFERENCE TO BASE FILE RECORD (BASE FILE REFERNCE)

- It is used when the record to be stored exceeds the allocated space of one or more
MFT records.

10. BYTE RANGE-40-41: NEXT ATTRIBUTE ID

-
EXAMPLE

Figure given above shows two word file created on a NTFS pen drive with a cluster size of
1024 KB.

Let’s analyze the given scenario using Winhex.

When en viewing an MFT record with a hexadecimal editor, such as WinHex, the data is
displayed in little endian format, meaning it’s read from right to left. For example, the
hexadecimal value 40 0 is displayed as 00 04 00 00, and the number 0x40000 is displayed as
0 0 00 0 4 00.

STEP 1
1. Open the NTFS formatted pen drive in Winhex using the Logical View.
2. The disk opens in logical view and following files as shown below are found to be on the
disk.
STEP 2.

In order to find out the file record in the $MFT for the file READ ME.docx, first select the file
READ ME.docx and then right click on it, then click on Navigation Go to File Record. This
opens up the File record for the file READ ME.docx as shown below.

NOTE: The header describes the properties of the record, and the attributes describe all aspects of
the file from its name to its data.
STEP 3

A
B C
D

A: ALL MFT RECORDS START WITH FILE0

B: OFFSET TO FIRST ATTRIBUTE
C: ATTRIBUTE TYPE IDENTIFIER
D: LENGTH OF ATTRIBUTE (VALUE: 96 BYTES)
E: NON RESIDENT FLAG (0x00 = Resident, 0x01 = Non-resident)
F: LENGTH OF NAME
G: OFFSET TO NAME
H: FLAGS (0x00FF = Compressed, 0x8000 = Sparse, 0x4000 = Encrypted)
I: ATTRIBUTE IDENTIFIER
 OFFSET TO FIRST ATTRIBUTE FIGURE 1
ATTRIBUTE ID

From figure 1, it is clear that byte 20-21 points to the starting of the first attribute for the file.
Here the data is stored in little endian, so 38 00 h becomes 00 38 h which is 56 in decimal. This
indicates that the first Attribute starts at 0038 h which is byte offset 56.

At byte 56 starts the attribute header.

The highlighted field shows us the attribute id as 10 which is for $STANDARD_INFORMATION.

$STANDARD_INFORMATION HEADER.

ATTRIBUTE ID
FIGURE 2 LENGTH OF ATTRIBUTE

Figure 2 shows us the length of attribute as 96 bytes. i.e. 96 bytes on from the beginning of
this Attribute (offset 56), at byte offsets 152 to 157, are the four values 30 00 00 00h. This is a
set of four bytes which should be another Attribute ID.

In this case it is the ID for a File Name Attribute.

 FIGURE 3
RESIDENT/NON-RESIDENT FLAG

As shown in figure 3, at byte 64 is the resident/non-resident flag. This is signified by 00h for a
resident Attribute and 01h for a non-resident Attribute.

FIGURE 4
LENGTH OF NAME OF ATTRIBUTE.

In figure 4, offset 65 the length of the name of the Attribute. In this case the length is zero,
since this Attribute is not allocated a name.

FIGURE 5
OFFSET TO NAME OF ATTRIBUTE.
As shown in figure 5, offset 66-67 indicate the offset value to the start of the Attribute proper.

FIGURE 6
FLAGS

Shown above, bytes 68-69 are identified as a set of flags which signify the following states:

 00 00h = normal,
 01 00h = compressed, 40
 00h = encrypted &
 80 00h = sparse.

FIGURE 7
 FIGURE 8 LENGTH OF
ATTRIBUTE PROPER

As shown in figure 8, bytes 56-59 indicates length of attribute proper in little endian.

In this case the value is 00000048h, which is 72 in decimal.

FIGURE 9
OFFSET TO START OF
ATTRIBUTE PROPER

The next two bytes: 60 -61, as shown in figure 9, indicates the offset from the beginning of
this Attribute to the start of the Attribute proper. This is where the Standard Information
Attribute details start, after the header. The value is 0018h which equals 24 decimal.
 FIGURE 10
ATTRIBUTE HEADER
Here the attribute is Standard Information.

The attribute header is 24 bytes and the attribute is 72 bytes long. ATTRIBUTE PROPER
$Standard Information attribute proper.
$Standard Information attribute is always resident and contains the basic metadata for a file
or directory. It exists in every file and directory and is typically the first attribute.

Figure 11 given below shows the Data structure for the $STANDARD_INFORMATION attribute

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 FILE CREATION DATE & TIME LAST FILE ALTERED/MODIFIED DATE & TIME

1 LAST MFT RECORD MODIFIED/ALTERED DATE & TIME LAST FILE ACCESSED DATE & TIME

2 FLAGS MAXIMUM NOS. OF VERSION NUMBER CLASS ID

VERSIONS
3 OWNER ID SECURITY ID QUOTA CHARGED

4 UPDATE SEQUENCE NUMBER

FIGURE 11

Figure 12 below shows the hex view of $STANDARD_INFORMATION attribute proper.

FIGURE 12
 FIGURE 13

FILE CREATION TIME

FILE ALTERED/MODIFIED TIME

MFT RECORD MODIFIED/ALTERED TIME

FILE CREATION TIME

FILE ACCESSED TIME

The first 32 bytes of this Attribute proper from byte offset 72 to byte offset 103 as
shown in figure 13 refer to four dates and times.

The values stored in these bytes are in a format known as a “FILETIME”.

All dates and times are stored in the Win32 Filetime format.

This is a 64 bit number (held here in little endian format) that represents the
number of 100 nanosecond intervals that have elapsed since 00:00:00 GMT on 1
January 1601

Figure 14 given below shows how to configure Winhex to view the file creation
time, file modification, MFT RECORD MODIFIED/ALTERED time & file access time.

In order to view the date & time, the DATA INTERPRETER view of Winhex has to be
selected as shown in figure 14 given below.
 Figure 14 showing how
to select the data
interpreter view of
Winhex

FIGURE 14

Since all dates and times are stored in the Win32 Filetime format, the Data
Interpreter also has to be configured to show the time in Win32 Filetime format.
Following show the steps to configure the Data Interpreter.

FIGURE 15

As shown in figure 15, in the data interpreter options select the Win32 FILETIME
(64 bit) check box & the Big Endian check box. This will interpret the selected data
in Win32 FILETIME format.
 FIGURE 16
DATE: 30TH SEPTEMBER, 2013
TIME: 17:43:24 UTC

As shown in figure 12, bytes 72-79 provides the file creation time.

From Figure 16, on selecting the bytes form 72-79, the data interpreter shows the
file creation time in UTC. It is evident that the file Creation date is 09/30/2013 &
time is 17:43:24.

Similarly bytes 80-87 provide the file altered/modified date & time.

FIGURE 17

FILE MODIFICATION DATE: 30TH SEPTEMBER, 2013

FILE MODIFICATION TIME: 17:46:24 UTC
 FIGURE 18
$MFT FILE MODIFICATION DATE: 30TH SEPTEMBER, 2013
$MFT FILE MODIFICATION TIME: 17:46:25 UTC

FIGURE 19
FILE ACCESSED DATE: 30TH SEPTEMBER, 2013
FILE ACCESSED TIME: 17:46:24 UTC

Four dates and times.

BYTES 72-29 FILE CREATION DATE AND TIME 30/09/2013 17:43:24 GMT FILETIME (local):
9/30/2013 11:13:24 PM

BYTES 80-87 FILES LAST MODIFICATION DATE & TIME 30/09/2013 17:46:24 GMT FILETIME (local):
9/30/2013 11:16:24 PM

BYTES 88-95 LAST MFT RECORD DATE & TIME 30/09/2013 17:46:25 GMT FILETIME (local):
9/30/2013 11:16:25 PM

BYTES 96-103 LAST FILE ACCESS DATE & TIME 30/09/2013 17:46:24 GMT FILETIME (local):
9/30/2013 11:16:25 PM
Figure 19 given below shows the FILETIME values of the selected bytes 72-79 using
FTK imager.

FIGURE 19

Bytes offsets 104-107 are used for file permissions

FIGURE 20

Table given below shows different file permissions.

FLAG VALUE DESCRIPTION

0x0001 Read Only
0x0002 Hidden
0x0004 System
0x0020 Archive
0x0040 Device
0x0080 Normal
0x0100 Temporary
0x0200 Sparse file
0x0800 Compressed
0x2000 Content is not being indexed for faster searches
0x4000 Encrypted
Read-Only Attribute
A Read-Only file can be viewed, but not changed.

Hidden and System Attributes

Files marked Hidden and System do not normally display unless the file manager option to display them is selected. Any
file can be marked as Hidden; however, operating system and other control program files are marked as System files as a
means of identification.

Archive Attribute
The archive attribute is used for backup. When a file is created, the archive bit is turned on, and when a program copies
the file, the archive bit is turned off. For example, the /m parameter in the Xcopy command in Windows turns off the
archive attribute. When the file is edited and saved again, the attribute bit is turned on.
$FILE_NAME Attribute
For a standard file or directory, this will be the second attribute and is always
resident.

The start of the File Name Attribute is signaled by the identifier 30 00 00 00h at
byte offset 144.

It is placed in an MFT entry to store the file's name and parent directory
information, and it is used in a directory index. When it is used in an MFT entry, it
does not contain any essential information, but it does when it is used in a
directory index.

At byte offsets 144 to 167 are the details of $FILE_NAME Header.

FIGURE 21

STANDARD INFORMATION
ATTRIBUTE HEADER

STANDARD INFORMATION
ATTRIBUTE PROPER

FILENAME ATTRIBUTE
HEADER
Table given below shows the data structure of FILENAME attribute header.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
RESIDENT/N
LENGTH OF
ON OFFSET TO START OF
0 ATRIBUTE 1D LENGTH OF ATTRIBUTE NAME OF FLAGS NOT YET KNOWN
RESIDENT ATTRIBUTE PROPER
ATTRIBUTE
FLAG

PADDING
OFFSET TO START OF INDEXED
1 LENGTH OF ATTRIBUTE PROPER TO 8 BYTE
ATTRIBTE PROPER FLAG
BOUNDARY

ATTRIBUTE ID LENGTH OF ATTRIBUTE

FIGURE 22
OFFSET TO START OF ATTRIBUTE PROPER
LENGTH OF ATTRIBUTE PROPER

Figure 22 above shows important sections of the FILENAME attribute header.

Attribute Header Analysis.

Bytes 144 to 147- Attribute ID.

Bytes 148 to 151– Length of Attribute - 00 00 00 78h = 120.

Here the length of attribute points to the length of the header & attribute
proper.
I.e. the attribute spans from offset 144 to offset 263.

Bytes 160 to 163-Length of attribute proper- 00 00 00 5A = 90.

i.e the attribute proper spans from offset 174 to offset 263.
 Bytes 164 to 165- Offset to the start of attribute proper-00 18H=24.
i.e. 144+24=168. Starting from byte offset 168 is the File Name Attribute Proper.

THE FILE NAME ATTRIBUTE PROPER

The file name attribute proper starts form offset 168.

Following shows the Data Structure of $Filename Attribute proper.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 FILE REFERENCE OF PARENT DIRECTORY FILE CREATION TIME

1 FILE MODIFICATION TIME MFT MODIFICATION TIME

2 FILE ACCESS TIME ALLOCATED FILE SIZE(physical size)

3 REAL/LOGICAL SIZE OF FILE(size on disk) FLAGS REPARSE VALUE

LENGTH NAME
4 OF TYPE NAME(VALIABLE LENGTH)
NAME

FIGURE 23
The $Data attribute proper has no specific
layout following the attribute header.

However if the attribute is resident it will

contain the file's data in its entirety, if that data FILENAME ATTRIBUTE HEADER
is small enough to fit within the MFT record, or
if non-resident it will hold one or more cluster
start and length fields.
FILENAME ATTRIBUTE PROPER
 FIGURE 23
FILE REFERENCE OF PARENT DIRECTORY

Starting from byte offset 168 is the File Name Attribute Proper. The first 8 bytes of
the Attribute are a reference to the parent directory.

The value in these first six bytes is 00 00 00 00 05h, which is equivalent to 5 in

decimal. This is the record number of the directory. This is the record number of
the directory which this file appears.

Therefore, the parent directory is MFT entry 5, and its sequence is 5, which is the
entry for the root directory.

For further illustration, let us consider a file named diskeditor which is inside a
folder named New folder.

During investigation if it is required to find the file record of the directory in which
the file (diskeditor) exists, the offsets 168-175 provides the reference to the file
record of parent directory.
Following steps can be taken to find the file record of parent directory of the file
“diskeditor.exe”

STEP 1

Go the File record of the file-diskeditor using winhex.

For this right click on the file then go to Navigation->Go to file record.

Figure 24 illustrates the above.

FIGURE 24

STEP 2

FIGURE 25
As shown in figure 25, offsets 168-175 provides FILE REFERENCE OF PARENT
DIRECTORY.

The value in these first six bytes is 00 00 00 00 25h, which is equivalent to 37 in

decimal. This is the record number of the directory in which this file appears.

Therefore the 37th File record is the file record of the parent directory of the file
“diskeditor”.

So if we navigate to File record nos. 37, we can find the file record of the parent
directory of the file “diskeditor”.

For finding the file record nos 37, go to Navigation -> Go to File Record.

Following figure illustrates the navigation to File record nos. 37.

FIGURE 26
Navigation to file record nos. 37 yields the following.

FIGURE 26
Name of the parent directory of the file “disk editor”

Figure given below shows the Four Time stamps .

FIGURE 27
 FIGURE 28

File Creation time.

Similarly other FILETIME time stamps can be easily found by using the data
interpreter of WinHex.

Figure given below shows the ALLOCATED FILE SIZE (Physical file size).

FIGURE 29
Allocated file size

Byte offsets 208 to 215 as shown in Figure 29 are an 8 byte number specifying the
“physical” size of the file. In this case the “physical” size is 00 00 00 00 00 00 34
00h which is equivalent to 13312 bytes.
Figure Given below shows the REAL SIZE/LOGICAL SIZE OF FILE (size on disk)

FIGURE 30

REAL SIZE OF FILE= 13207 BYTES

Figure given below shows the Flags.

FIGURE 31
FLAGS
Byte offsets 224 to 227 are stated to be “Flags”.

In this case 20 00 00 00h represents a file with the Archive bit set.

Figure given below shows the Length of file name in characters.

FIGURE 32
Length of file name in characters.

Byte offset 232 as shown in figure 32 is a one-byte field containing the length of
the filename in characters. In this case it is seen to be 0Ch, which is 12 decimal.
Inspection of the filename READ ME.DOCX reveals that the calculation to be
correct
Figure given below shows the Type of file name.

FIGURE 33
Type of file name

Byte offset 233 (black background) at Table 6.52 is a one-byte field that records
the type of the file name. In this case it is seen to be 01h, which indicates that it is
Win32 compliant according to the following table.

TYPE OF FILE NAME VALUE DESCRIPTION

0 POSIX: The name is case sensitive and allows all Unicode
characters except for '/' and NULL.
Win32: The name is case insensitive and allows most
1 Unicode characters except for special values such as '/', '\',
':', '>', '<', and '?'.
DOS: The name is case insensitive, upper case, and no
2 special characters. The name must have eight or fewer
characters in the name and three or less in the extension.
3 Win32 & DOS: Used when the original name already fits in
the DOS namespace and two names are not needed

Note:
1. It should be noted that Unicode characters occupy 2 bytes but count as one character.
2. An examination of the MFT shows that where a file name is outside the constraints of
the 8.3 DOS name, then two File Name Attributes are present in the record; one
containing the Win32 Long File Name and one containing the DOS-compliant 8.3 file
name.
Figure below shows the Filename.

FIGURE 34
File name

As can be seen from figure 34, byte offsets 234 to 257 contain the file name, the
character length of which (12).

As mentioned earlier that if in case an examination of the MFT shows that where a
file name is outside the constraints of the 8.3 DOS name, then two File Name
Attributes are present in the record; one containing the Win32 Long File Name and
one containing the DOS-compliant 8.3 file name.

Figure given below shows the MFT record with two file name Attribute.
$DATA ATTRIBUTE
The $Data attribute has no specific layout following the attribute header.

However if the attribute is resident it will contain the file's data in its entirety, if
that data is small enough to fit within the MFT record, or if non-resident it will hold
one or more cluster start and length fields.

Following Figure shows Four Attributes.

FIGURE 35

$STANDARD INFORMATION ATTRIBUTE

$FILENAME ATTRIBUTE

$OBJECT_ID ATTRIBUTE $DATA ATTRIBUTE

$DATA ATTRIBUTE(NON RESIDENT) HEADER

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 ATTRIBUTE ID ATTRIBUTE LENGTH RESIDENT/ NAME NAME FLAGS ATTRIBUTE
NON LENGTH OFFSET ID
RESIDENT (offset to
FLAG name of
attribute)

1 START VIRTAUL CLUSTER NUMBER ENDING VIRTUAL CLUSTER NUMBER

2 OFFSETS TO COMPRESSION 0X0000 SIZE OF ATTRIBUTE CONTENT(PHYSICAL SIZE OF ATTRIBUTE)
DATA RUNS UNIT SIZE

3 SIZE ON DISK OF ATTRIBUTE CONTENT(LOGICAL SIZE OF DATA RUN DESCRIPTOR

ATTRIBUTE)
4 DATA RUN LISTS

A non - resident attribute stores its content in external clusters.

Nonresident attributes are stored in cluster runs.

Figure 36 given below shows the $DATA attribute proper.

FIGURE 36

Figure 37 given below shows the data structure of the $DATA attribute header.

FIGURE 37
 ATTRIBUTE ID END VIRTUAL
CLUSTER
NUMBER
START VIRTUAL ATTRIBUTE RESIDENT/NON NAME NAME FLAGS ATTRIBUTE ID
CLUSTER LENGTH RESIDENT FLAG LENGTH OFFSET
NUMBER

OFFSETS TO COMPRESSION LOGICAL SIZE PHYSICAL SIZE

DATA RUNS UNIT SIZE OF ATTRIBUTE OF ATTRIBUTE

BYTES 0-3 ATTRIBUTE ID 80 00 00 00

BYTES 4-7 LENGTH OF ATTRIBUTE 00 00 00 48H=72
BYTES 8-8 RESIDENT/NON RESIDENT 01H=NON RESIDENT FLAG
BYTES 9-9 LENGTH OF NAME OF ATTRIBUTE 00H=NO NAME
BYTES 10-11 OFFSET TO NAME OF ATTRIBUTE 00H-NOT USED
BYETS 12-13 FLAGS 00 00H=NORMAL
BYTES 14-15 ATTRIBUTE ID 00 01H-POSSIBLE ID
BYTES 18-23 STARTING VCN 00 00 00 00 00 00 00 00H=0
BYTES 24-31 ENDING VCN 00 00 00 00 00 00 00 FFH=255
BYTES 32-33 OFFSETS TO DATA RUN 00 40H=64
BYTES 34-35 COMPRESSION UNIT SIZE 00 00H=UNCOMPRESSED
BYTES 40 - 47 PHYSICAL SIZE 00 00 00 00 00 04 00 00H= 262144 bytes
BYTES 48 -55 LOGICAL SIZE OF ATTRIBUTE 00 00 00 00 00 04 00 00H= 262144 bytes
Non-resident attributes are stored in intervals of clusters called runs. Each run is
represented by its starting cluster and its length.

Data runs have three components:

 The first component declares how many bytes in the attribute field are
needed to store the values for the second and third components.
 The second component stores the number of clusters assigned to the data
run.
 The third component contains the starting cluster address value (the LCN or
the VCN)

Non-resident attributes are stored in a series of data runs, with each data run
specifying:

 the number of contiguous clusters in the run and

 the starting cluster number for the run.

END OF RECORD MARKER AND CRC

 SECOND COMPONET
THIRD COMPONET
FIRST COMPONET

31 0D 3B FE 09

The second digit of the first

component- 1, means that the next
1byte contains the number of
clusters assigned to this data run.

The first digit of the first component, 3,

means that the next 3 bytes (after the
number of clusters assigned) contain the
cluster address value.

Starting LCN address

09 FE 3BH=654907

31 0D 3B FE 09

Bytes needed to store the

starting LCN address. Nos. clusters
assigned to data
run.

Clusters assigned for

file-read me.docx