Forensics: NTFS Practical Quiz

The first NTFS practical quiz from “Where is Your Data” has been made available.

This practical requires the examination of an image. The image format is in the EnCase E01, for compression purposes.

The image can be downloaded from the quiz directly.

Advertisements

Forensics: What is $Boot?

What is $Boot?

The $Boot is known as the Volume Boot Record, or Volume Boot Sector, or Parition Boot Sector. It stores a vareity of important informaiton, including:

  • Size of the partition
  • location of the MFT for the partition
  • location of the MFT mirror for the parition

$Boot is the first file in a volume, and for the first parition on a drive this will normally reside at sector 63. The exact location of the $Boot file is described in the MBR (Master Boot Record) which is on sector 0 (zero) of a hard drive.

A video showing a manual investigation of the $Boot, using EnCase, is featured below:

Forensics: What is the $BadClus?

What is the $BadClus?

The $BadClus is one of the 16 key NTFS metadata files. Its role is to track sectors that a damaged/unable to be used on the drive. The Bad Clus  has a MFT record number of 8 and, in the MFT, it comes just below $BitMap and $Boot.

The file $BadClus, as the name implied, is to store a reference of the bad clusters on the hard drive.  Its the same concept as the $BitMap, which stores a list of available and not available sectors across the parition. However the $BadClus keeps track of sectors which is believes are bad/faulty and should not be written to.  If data exists on a sector it will remain there even if the $BadClus marks the sector as bad. Remeber it does not mean that the sector is bad, only that the NTFS file system thinks it is.

If a drive is formatted “Quickly” the $BadClus, will be empty as it does not know what is and is not a bad cluster. If a drive is formatted via the longer method then every cluster will be checked and the $BadClus will be fully updated.

Forensics: What does “File Extent” mean in EnCase?

What does “File Extent” mean in EnCase?

The term “File Extent” in EnCase is reffers to how many different fragments or “data runs” there are for a file. A file that consists of 1 contiguous block of data, i.e one that is not fragmented, will have a File Extent of 1, any file that that a value greater than 1, will be fragmented. [This is for an NTFS file system]

This information is obtained from the MFT which gives exact details about the size, number, and location of all of the data runs associated with a file.

Forensics: What is the MFT Mirror?

What is the MFT Mirror?

The MFT Mirror, seen as $MFTMirror in computer forensics tools, is a partial backup of the MFT. It is not, as is sometimes reported a complete backup of the MFT.

The MFT Mirror contains  a backup of the first 4 NTFS system files:

  • $MFT
  • $MFT Mirror
  • $Log
  • $Volume

The MFT Mirro is designed to allow for as error handling, and can allow for recovery of deleted/wiped partitions.

If the MFT is partially wiped, i.e the first few entries (which somes viruses have done in the past) then the MFT Mirror can be used to rebuild the MFT. EnCase, which is a forensic tool, rather than a data recovery tool,  even has a function to allow for the rebuilding of a partition, using the MFT Mirror (as do other data recovery tools).

The MFT Mirror can be viewed, like the MFT in EnCase, using the correct text styles.

It should be noted, and this is where there is often confusion, the MFT Entry for the MFT Mirror is, as are all files, in the MFT. But the MFT Mirror itself, the actual file, like all other normal files, is out on the hard drive space and not in the MFT.

Forensics: What is the $MFT?

What is the $MFT?  The $MFT, Master File Table,  is the most important file in a NTFS file system.  It keeps track of all files on the volume, their logical location in folders, their physical location on the hard, and metadata about the files, including:

All of this information is stored in an entry within the MFT, called (somewhat unsurprisingly)  “MFT Entries“.
The MFT Entries are 1024 bytes, as standard. Every file and folder, has to have an MFT entry, to be recognized by the computer, including the MFT itself.
The first 16 entries of the MFT are reserved for NTFS system files, these include:
$MFT, $MFT Mirror, and $BitMap.
The MFT can expand but it never contracts, under normal use. This is very important for computer forensics investigators, as it effects the recovery of data and identification of deleted files.
When a file is deleted the MFT entry is marked as ready to be re-used. This entry will continue to exist until it is overwritten by a new file. When a new file is to created on the hard drive it  overwrites the next available MFT entry, if they are no spare entries ready to be overwritten then the MFT will start to expand.
Example1:
If there are 100 entries in the MFT and one file, File X,  is deleted and then 1,000 more  files are immediately created then the MFT entry for File X would be overwritten. Though the contents of the file may exist on the hard drive, the MFT entry which includes the name, metadata, etc, would be overwritten.
Example2:
There are 10,000 entries in the MFT. 1,000 are deleted and 2 new files are  immediately added to the drive. Therefore 998 entries should be recoverable.  Though if the data for the files is recoverable or not will depend on if they have been over written.
These numbers may sound unlikely, but with website data being cached and then cleaned out, temorpary files created from software installs, and then deleted, these sudden changes in file counts are not unlikely at all.

Note:
The data for the file is seperate from the MFT Entry. This leads to several possibilities during deletion and subsequent use of a hard drive.
1) The file is deleted but the MFT entry and the file data are 100% recoverable. The deleted file can be 100% recovered.
2) The file is deleted and the MFT entry is recoverable but a portion of the file data is overwritten. This means that the file can only be partialy recovered.
3) The file is deleted and the MFT entry is recoverable but the file data is 100% over written. The file is not recoverable, but informaiton about the file, name, dates, sizes, etc is.
4) The file is deleted and the MFT entry and file data is 100% recoverable. The file is 100% lost. However forensic investigation could reveal a lot of information about the file, but not through the MFT, rather other forensic artefacts.
5) The file is deleted and the MFT 100% overwritten but the file data has not been 100%  overwritten.  The remaining file can be carved out from the unallocated space on the hard drive. The ability to carve the data would depend on fragmentation, amount of recoverable data (it could be 100%) and nature of the file
There are other permutations, where the MFT entry is not 100% over written, leaving MFT file slack.
More information on the MFT is available here.

A good resource on the MFT, and NTFS in general is the book – File System Forensic Analysis

Forensics: What is the $BitMap?

The $BitMap is a special file within the NTFS file system. This file keeps track of all of the used and unused clusters on an NTFS volume.  When a file takes up space on the NTFS volume the location is uses is marked out in the $BitMap.

The method of keeping track of cluster allocation is relevatively simple.  Each bit in the Bitmap represents 1 cluster, if that bit is “1” then the cluster is in use. For example if a byte in the BitMap is “F”, this means that 4 clusters are in use as F (hex)  = 1111 in binary.

Therefore if two bytes of the $BitMap are “FF”  this means that the 8 clusters are in use, as FF  = 11111111.

When a file is deleted the cluster becomes unallocated or unused (allowing new data to overwrite it) and the bits go back to zero.  If 8 consqecutive clusters were in use by files, FF, and then one file was deleted taking which took up just 1 cluster from those 8, the  $BitMap entry would change from FF to 7F, as 7F = 1111111. The screen shot below shows the $BitMap (through EnCase) after the drive has been freshly formatted. While there are no user created files, the $BitMap still has clusters allocated because the of the NTFS system files on the partition. The hex values being shown are: FF FF FF FF FF FF FF FF 07 00 00 00 00 00 , this means that 67 clusters are in use.

BitMap on NTFS Volume just formatted

The screen shot below shows the same volume after a single file has been copied onto the drive. This file was 1,091,631 bytes in size. The hex values being shown in the BitMap are now : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 3F 00 00 00.

This is 334 clusters

Bitmap from an NTFS volume with a single 1 MB file added Bitmap from an NTFS volume with a single 1 MB file added

This maths can be verified as 1,091,631 will take up 267 clusters (including slack). 67 (clusters in use on the freshly formatted drive, in this example)+267 (file size added) = 334 (total clusters in use)

Note:  There is one $BitMap per NTFS volume (not per disk). The $BitMap is the 7th entry (MFT record number  6) in the MFT.