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 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 MBR?

The MBR is the Master Boot Record.  This is a very important peice of code the exists on the first sector (Sector 0) of most standard  hard drives, and certainly all Windows based computers and is 1 sector (512 bytes) long. The last two bytes of the MBR are  55AA (in hex) this is sometimes known as the “magic number”

The MBR tells the computer how to boot, what type of partitions are on the hard drive, how big they are  and were to find them. The code  within the MBR, which tells it how to boot,  is called the “bootloader”. The bootloader is 446 bytes long.

Within the MBR, at offset 440 for 4 bytes, is the Windows Disk Signature.  This value is unique for the disk, and can be a useful forensic artefact. It is this value that is stored in the resigtry, under “Mounted Devices”, and can be used to match a hard drive to a computer, even if the data has been deleted/wiped.

Like most forensic artifacts the MBR consits of a series of offsets, these are described in this article, including a working example of an MBR.

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.

Forensics: NTFS Deleted Entry

When a file is deleted in NTFS, it is marked as deleted within the MFT entry for that file. The clusters that were allocated to the fille are now marked as free, within the $BitMap

This is is shown at offset 22 for 2 bytes; i.e. bytes 22 and 23 of the MFT for that entry.

  • For an active file the 22nd and 23rd offsets read “01 00”  (though in tools like EnCase it will display 00 01 due to the big endian/little endian flip required.
  • For a deleted file the 22nd and 23rd offsets read “00 00”. Though the big endian/little endian conversion still applies it makes no difference in this case.

Forensics: RAM Slack and File Slack

What is the difference between RAM slack and file slack?

Slack, in general, refers to the difference between the logical file size and physical file size.  However slack can be broken down into two different areas, RAM slack and File Slack. 

RAM slack is the slack between the end of the logical file and the rest of that sector. File Slack is the remaining sectors to the end of the cluster. To put it another way RAM slack is the slack at the byte and sector level. File slack is the sectors to the cluster level.


On an NTFS drive with with 512 byte sectors, and 8 sectors per cluster the size of a cluster is 4096 bytes. If a file is 5100 bytes long, this means that there 3092 bytes of slack, this is broken down into 20 bytes of RAM slack and 3072 bytes of file slack (or 6 sectors).

The reason is this:

The file is 5100 bytes which is 9 sectors. But the NTFS file system works on clusters not sectors, therefore the file will be assigned 2 clusters. The first cluster (8 sectors) will be completed filled by the first file, however the second cluster will only contain 1004 bytes of the file (4096+1004 = 5100). 

This means that the first sector (512 bytes) of the second cluster will be completely filled  with the file, but the second sector of the second cluster will only contain 492 bytes. The space at the end of the second sector on the second cluster is known as RAM slack, and is a dump from the RAM, in this case its just 20  bytes (492+20 = 512).

After that there are 6 more sectors to the end of the cluster (the file is assigned two clusters, 16 sectors in total). The 6 sectors remaining are known as file slack.

RAM slack, is therefore very small amounts of data, a maximum of 511 bytes. File slack as the potential to be bigger, but is still small. The maximum size of file slack, assuming a cluster size of 8 sectors, is  7 sectors or 3,584.


RAM Slack does not exist on a modern version of Windows, and has not done for some time.

Forensics: Viewing the MFT in EnCase

To view the MFT in EnCase in the most efficient manner, you should view it in a 1024 text style.  The steps below show how to do this. The attached PDF includes screen shots.

  1. Create a new text style in the “Text Style” panel. 
  2. Once in the Text Style “Attributes” section, do the following
    1.  Enter the Name of the style. The name is only for reference, and does not affect the view itself.
    2. Set the Line Wrap to Max Size
    3. Set the Wrap length to 1024
    4. Then select the “Code Page”
  3. In the code page select Western European ISO. Then press OK. 
  4. Then view the $MFT in text, and all the MFT headers should line up correctly