In the previous post in this series on NTFS file systems, we were just dipping our feet in the complicated waters by examining the output of fsstat. Let's pick up where we left off. Below is the $AttrDef Attribute Values section of fsstat's output from the previous post:
$AttrDef Attribute Values: $STANDARD_INFORMATION (16) Size: 48-72 Flags: Resident $ATTRIBUTE_LIST (32) Size: No Limit Flags: Non-resident $FILE_NAME (48) Size: 68-578 Flags: Resident,Index $OBJECT_ID (64) Size: 0-256 Flags: Resident $SECURITY_DESCRIPTOR (80) Size: No Limit Flags: Non-resident $VOLUME_NAME (96) Size: 2-256 Flags: Resident $VOLUME_INFORMATION (112) Size: 12-12 Flags: Resident $DATA (128) Size: No Limit Flags: $INDEX_ROOT (144) Size: No Limit Flags: Resident $INDEX_ALLOCATION (160) Size: No Limit Flags: Non-resident $BITMAP (176) Size: No Limit Flags: Non-resident $REPARSE_POINT (192) Size: 0-16384 Flags: Non-resident $EA_INFORMATION (208) Size: 8-8 Flags: Resident $EA (224) Size: 0-65536 Flags: $LOGGED_UTILITY_STREAM (256) Size: 0-65536 Flags: Non-resident
Each line of output in this section gives the name of an NTFS attribute followed by the attribute's numeric ID in parentheses. Following the attribute's numeric ID, is an indicator of that attribute's minimum and maximum size limits in bytes, if there are any and finally, we are told if the attribute is resident (contained within the MFT entry) or non-resident. Details for each attribute come from one of NTFS' hidden system files, $AttrDef. $AttrDef is made up of multiple 160 byte records, one for each attribute. Each record contains the attribute's name (see the green highlight in Figure 1), numeric ID (pink highlight), flags (a four byte value at byte offset 140), minimum size (blue highlight), a maximum size (yellow highlight). If an attribute has no size limitations, the minimum size will be set to 0 and the maximum will have all bits set to 1. There are additional fields in each attribute record, see Brian Carrier's File System Forensic Analysis for complete details of the data structures contained in $AttrDef.
As an experiment, I opened the $AttrDef file in a hex editor and changed the $STANDARD_INFORMATION attribute's name. The name change was reflected in the output of various Sleuthkit utilities. What, your NTFS file system doesn't have the Rob_Lee_Forensicator attribute?
Figure 1: Here the $STANDARD_INFORMATION attribute has been renamed (see green highlight)
So $AttrDef contains attribute definitions. What is the purpose of each attribute? $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. Complete details can be found in Carrier's File System Forensic Analysis, pages 316-318 and 359-362.
The $ATTRIBUTE_LIST attribute is used to indicate where other attributes can be found for the given MFT entry, see Carrier pages 320 - 321 and 365 - 367. $ATTRIBUTE_LIST is only found in MFT entries that have attributes that won't fit in a single MFT entry. Recall that every file on the file system will have at least one MFT entry and that MFT entries are only 1024 bytes in length. If a file has more attributes than can fit in a single MFT entry, additional MFT entries can be linked to from the base MFT.
Next we have the $FILE_NAME attribute. Obviously the name of the file will be found here, this attribute also contains the same time stamps as the $STANDARD_INFORMATION attribute, though according to Carrier, they are less reliable. We will spend more time examining the $FILE_NAME attribute in future posts.
In addition to the file name, files may have a 128-bit Globally Unique Identifier (GUID) or $OBJECT_ID attribute that can be used to access the file. This attribute may be used to locate files even if the file's name has been changed, though on two NTFS file systems I examined in writing this post, no $OBJECT_IDs were found for any file.
Following the $OBJECT_ID attribute, comes the $SECURITY_DESCRIPTOR attribute, an artifact of previous versions of NTFS kept for backwards compatibility. For versions of NTFS prior to 3.0, this attribute contains the access control policy for the file. After 3.0, access control information is stored in a hidden system file called $Security because many files on the file system will use the same access control policy. Storing those policies in one file allows multiple files to point to the same policy entry, conserving disk space.
$VOLUME_NAME, attribute ID 96 contains the name of the volume. Attribute ID 112, $VOLUME_INFORMATION contains the file system version information in addition to flags such as the dirty flag, that may indicate that the volume was unmounted improperly, or imaged while mounted or that chkdsk may need to be run on the file system. See the screen shot below for an example hex dump of the $VOLUME_INFORMATION attribute as found assigned to the hidden system file $Volume.
Figure 2: Hidden system file $Volume and related attributes
Note the use of istat to dump the metadata information for the $Volume file and the use of icat to dump the specific contents of the $VOLUME_NAME and $VOLUME_INFORMATION attributes using the type IDs for those attributes. More details about $VOLUME_INFORMATION's Flags field, as well as a comprehensive guide to NTFS can be found at http://www.scribd.com/doc/2187280/NTFS-Documentation, a document written by Richard Russon and Yuval Fledel.
After the volume related attributes, we have the $DATA attribute that contains the actual data for our file. Note that for small files, around 700K or less, this attribute may be resident, meaning that the actual data contained in the file will be stored within the MFT entry for the file. In a future post, we'll take a look at Alternate Data Streams and the $DATA attribute.
We've made it through just over half the attributes and this post is getting long, so let's call it a day and in the next post in the series, we'll finish our introduction.
Follow up 12/30/2009:
Reader Harry Parsonage wrote me offline, asking about my comment that I had no files with the $OBJECT_ID attribute assigned. He found this odd and wanted to know more about the file systems I was working with. The file systems I searched for $OBJECT_IDs were both created for this series of posts. One is an empty file system with only the system files that are created when a newly formatted file system is created. The other, is the same file system with a few thousand zero length files created via shell script on a Linux system where the NTFS partition was mounted.
I did mount up a file system that I am working for a case and did find numerous files with the $OBJECT_ID attribute set.
Parsonage added more useful information to the exchange and I wanted to post it here:
"OK it sounded odd, I believe that the file system only allocates an ObjectID to a file as part of the link tracking process. So a file will get an ObjectID when it is accessed via the File Open/Save As dialog or when it is executed in Windows Explorer. If there has been no activity on the system and there have been no files created or opened that would have a link file associated with them then I don't believe there will be any ObjectIDs."
Great info and it gives us something to test in a future post. Thanks Harry for the contribution, which brings up another thing I always love to rant about. So much of what we know in the forensics community comes from experimentation and the open exchange of little discoveries that experimentation leads to. This is a huge field and no one knows everything, though clearly some know more than others and many know more than me. Through the application of the scientific method, we can expand what we know.
Dave Hull, GCFA, GCIH, GREM, CISSP, is founder of Trusted Signal and describes his working life as "on the Venns" of incident response, digital investigations and web application security. He'll be teaching SANS Security 508: Computer Forensics, Investigation and Response in South Lake Tahoe, CA from January 25 through January 30.
