Testing tools based on a NIST image

National Software Reference Library (NSRL) and the National Institute of Standards and Technology (NIST) had work together in a project for collecting software from various sources and incorporate file profiles computed from this software into a Reference Data Set (RDS) of information.

The RDS can be used by law enforcement, government, and industry organisations to review files on a computer by matching file profiles in the RDS. This will help to alleviate much of the effort involved in determining which files are important as evidence on computers or file systems that have been seized as part of criminal investigations.

The RDS is a collection of digital signatures of known, traceable software applications. There are applications hash values in the hash set which may be considered malicious, i.e. steganography tools and hacking scripts.

Basically the idea is to load this products and understand if the tools that I decided to use do not change the or alter the evidence. Further information about the project and the NSRL can be found here.

Computer Forensics Tools Introduction

This was created by NIST in order to create a testing program for computer forensics tools. The main goal is to determine how well these tools perform core forensics functions such as imaging drivers and extracting information from devices. Further information can be found here.

For creating image, as mentioned earlier, I decided to use the tool called DCFLDD, and tests against this product are listed under the page 12. This says that there are some issues with this tool when there is some anomaly found in the disk. The complete accurate statement says the following:

• When a drive with faulty sectors was imaged (test case DA-09) the tool failed to completely acquire all readable sectors near the location of the faulty sectors. In test case DA-09, a source drive with faulty sectors was cloned to a target drive. Readable sectors that were near faulty sectors on the source drive were not acquired. The tool wrote zeros to the target drive in place of these sectors.
• When a drive with faulty sectors was imaged (test case DA-09) the data cloned to the target drive became misaligned after faulty sectors were encountered on the source drive. For example, sector 6,160,448 on the target drive cont ained the contents of sector 6,160,392 from the source, sector 6,160,449 on the target contained the contents of source sector 6,160,393, and so on. The size of the offset or misalignment between the data on the source and target drives grew as more faulty sectors were encountered on the source.

Full report is not longer available on the cyberfetch.org website.

For  the deleted file recovery, I decided to use The Sleuth Kit (TSK) / Autopsy. The report for this product is listed under page 216, and it says that under certain circumstances, the information cannot be recovered successfully from the image. The causes for this might be:

• The data are no longer present in the image, e.g., overwritten.
• Sufficient meta-data to locate the data is not present or reachable.
• The algorithm implemented by the tool does not use the meta-data that locates the missing data.
• The implementation of the tool algorithm is incorrect.

Report is also no longer available on the cyberfetch.org website.