What has been deleted, what has been renamed, find fragments from old files. Ignore known good files
CnW NTFS recovery software has tools to assist in investigating both good and corrupted NTFS disks. Deleted files, and compressed files can be viewed, along with all associated dates. Sectors used in each data run are stored in the log, and both data and directory slack space can be recovered. If the disk has been corrupted, or reformatted, the disk can be scanned for any remaining MFTs.

Areas to examine
As with all operating systems, NTFS has several areas that may be investigated on a disk. These include
● Known good files
● Known operating system files - checked with hash values so can be eliminated
● Deleted files
● Alternate Data Streams (ADS)
● Slack space - data area and directory area
● Scanning for all MFTs
● Unallocated space
● Compressed files and sectors
● Dates of files

Added complexities can include data compression by the operating system, encrypted files, and sparse files. CnW Software at the moment will restore encrypted files, but cannot decrypt them.

On most PC disks, there is a mixture of operating system files, and data files. To help speed up any investigation, it is nice to be able to skip any operating system files, but to do this, one must be 100% sure that they have not been changed in any way, and for this Hash values can be used. If a file is found with a hash value that matches a know released file, such as part of Windows operating system, or an antivirus package, then there is no need to investigate the file further, as it will be known to be unchanged.

Known good files
For many investigations, a starting point may well be just the known good files. These are files that would be read through the operating system. However, one very import piece of information will be dates related to the files. If any files are read with with the operating system, these dates, in particular, last accessed date will be changed. CnW Recovery software never changes anything one hard drive, but will log all of the dates as found. The base of knowledge for good files is the Master File Table (MFT) which is a file of file entries, also linked to index files.

Deleted files
Many users are still amazed that a deleted file can still often be read. For users that have accidentally deleted a file, they are delighted, but for somebody trying to hide a file, this may be less good news. The success rate of recovering deleted files does depend on what has happened to the disk after the deletion. A file is deleted by setting a flag in the MFT, and clearing down the table that says the sectors have been used. Fortunately though, the pointers to the data in the MFT are not removed, nor is the data. If though files are written to the disk after a deletion, it is possible that the space used by the original file may be overwritten. The data is then lost to the extent of the overwriting.

CnW Software will determine if the data in a deleted file has been overwritten and will mark it in the log this way. It will still be worth investigating the recovered file, but any such data should be treated with caution. CnW Software will restore all files detected as deleted, to a subdirectory tree marked deleted. All such files determined as overwritten, will be stored in a subdirectory tree called overwritten.

Slack space - Forensic option only
An NTFS disk has two areas of possible slack space, firstly the main data area, as secondly in the directory. Slack space is due to the fact that data on disks can only be written in fixed sized blocks - or often clusters. If the data length is short than a cluster, then there is an area of non defined data. Forensically, this can be interesting, as it may contain data from a previously deleted file, or the system memory at the time of writing. A typical cluster size for an NTFS disk is 4K.

The reason why the directory can contain slack data is that short files, normally less than 500-600 bytes are written at the end of an MFT, rather than taking up a complete cluster in the data area of the disk. CnW Software will optionally restore all slack space for further investigation. The directory slack is stored in a single file, called Slack_dir.slk with each header contained within tags, such as

<<mft:sssss-mmmm>> ...........................<</mft>>

The two numbers are the physical sector (ssss), and the logical MFT (mmm)value.
For slack detected at the end of each cluster, this is stored in a second file, called Slack_clust.slk. Again the data is surrounded by tags with the structure. It should be noted that (cuurently) not attempt is made to expand slack space that has been compressed.

<<clust:ssss-cccc>> .............................<</clust>>

ssss is the sector number of the start of the cluster, and cccc is the cluster number.
The resulting files can be examined with any suitable file editor.

Alternate Data Streams
NTFS disks have the ability to store multiple data streams for a file. However, secondary streams are in effect hidden and Windows Explorer, and normal DOS commands to not show these streams. The streams can be used to store special information, or version information, but they can also store complete data files. Forensically they can be interesting as a normal file could also have a secondary file associated with important information, or possibly illegal images. CnW will find these files and extract them. To distinguish the data, the file name is corrupted by added first a ‘-#-’ string and then the name of the extra stream. The CnW log also shows the number of streams in a file as part of the file flags parameter.

Unallocated space
Unallocated space on a disk is space that is not currently used for files. ie these are complete clusters (rather than partial clusters for slack space above) that are currently free. The reason for interest is that they may contain information from previously deleted files, or even previous uses of the disk. CnW Recovery software will analyse these clusters and extract logical files. Scanning unallocated space, old files that have been compressed with NTFS will still be found and decompressed. Thus CnW Recovery will carve NTFS compressed disks.

Scanning for all MFTs
Each file on an NTFS system has an associated MFT entry. These are normally stored in the $MFT file. When a drive has been reformatted, or partitions changed, then the location of MFTs may change. It is therefore very useful to scan the whole disk for potential MFTs. This process can be slow, but can assist in finding files that may not otherwise be recovered.

Files in MFTs
As described above (in the notes on slack) it will be seen that short files are written to the end of the MFT, rather than the main data area of the disk. The MFT is 1024 bytes long, so files less than say 600 bytes may fit (it does depend on many factors such as name length). However, once a file grows, the whole file is then stored in a normal cluster(s). It should be noted, that if a file then decreases in size, it is never reallocated to the MFT The short file that may have been written to the MFT can be recovered as Slack data.

Orphan files
When scanning for all MFTs, it is very common to find files that are no longer part of the operating system, and so have no parent directory structure. This can also happen when the disk has failures, or has been badly corrupted. The solution that CnW uses is to create dummy directories, and name them with the number of the missing parent MFT. An example would be dir54289. All related files are the stored in the relevant directory, including subdirectories. These dummy directories logged in the forensic report.

Logs
One of the most important aspects of forensic investigation is a good log of what is found. With the forensic option of the program enabled, full logs are provided including MD5 values for all files. Certain tests and results are stored in the forensic report but mcuh information is part of the standard log. In particular, it includes all dates, file sizes, and file attributes, as well as locations on the disk. If the Scan fir directory stubs is used, the log will be a report of all MFTs on the disk.

Forensic XML report
The forensic XML report is a summary of several logs relating to different stages of a disk recovery. It does include analysis such as file signature and extension matching and mismatching.

Which file a sector is in
If is very useful to determine which file a particular sector is in. Once a disk has been read, this information is stored within the log. To access it, use the Search button and enter the sector number when prompted. The log will then be searched and any file (or files) that the sector relates to will be displayed. A related feature is the Frag column of the log. This displays the number of fragments that a file is stored in. When the number is double clicked, a list of each fragment location, and length (in sectors) is displayed.

Typical uses of this feature is if a bad sector is detected, find which file it affects, or if a key word is found in a raw search, where did it originate.

File filtering
There is little point on spending time investigating known good files. By applying a file filter with Hash values of known good operating system files, a significant number of files may be eliminated from any further investigation. At the same time, if a known good file is not filtered out, it is probably because it has been changed, even by a single bit, and so may be investigated See http://www.nsrl.nist.gov for more details of down loadable hash tables

Download demo program now