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.

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

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.