Join Us!

Forensic Capabilities of ReclaiMe Pro

Presenter: Elena Pakhomova, Co-Founder, ReclaiMe Data Recovery








Join the forum discussion here.
View the webinar on YouTube here.
Read a full transcript of the webinar here.



Transcript

Hi Forensic Focus community. My name is Elena Pakhomova and I’m a co-founder of ReclaiMe Data Recovery Company. After my previous webinar where I talked about capabilities and features of our software ReclaiMe Pro, Forensic Focus members pointed out that our software is missing features that are necessary for computer forensics specialists.

We tried to consider your comments, talked with our friends among computer forensics experts, and added some features, which I now want to talk about in this webinar.

The first thing we did are forensic traces. Using this feature you can determine what data of a file is obtained from what place on the disk. This applies to both file content and timestamp traces using which you can know creation date, modification date, or last access.

ReclaiMe Pro gives you forensic traces for the recovered files in .CSV format. I should note that understanding of the traces is an easy task only for the old filesystems. Simple cases include HFS +, FAT, ExFAT, and the results of file carving.

For these filesystems the location of a non-fragmented file can be described simply by the location of the beginning of the file on a disk and the length of the file. A fragmented file is described by several parts which when glued together provide the exact content of a file. Modern filesystems are often arranged in a much more complex way, and simply copying data from the disk is not enough.

To get the actual file data additional data processing is often required: uncompressing data for NTFS and BTRFS, patching out generation numbers in NTFS, or processing of different variants of sparse extents if you deal with NTFS, BTRFS, EXT, and XFS. Now let’s discuss extent traces. As we know unfragmented uncompressed file has one extent. As filesystems grow complicated, fragmented file will have multiple extents. Compressed file will have extents where on-disk size does not match the in-file size of the data. Sparse file will have extents for which there is no data on disk. Preallocated file will have extents where there is data on disk, but it should be ignored. Mirrored file will have two on-disk locations of single in-file data. Deduplicated file will have single on-disk location for two different in-file blocks, or two different files. NTFS resident file needs to have generation numbers patched in on-disk data before use.

Any of these variants can be described by the scheme including three stages:

1. First, read data from a disk;
2. Then to process them to obtain file data
3. And finally to target the needed part from the processed data.

As usual, data on the disk is defined by the start address and the size. The size can be 0 in case of sparse extent which has no data on a disk.

Processing is applied to the data and provides either a data block with the size larger than data on the disk (decompression) or a data block of the same size as data on the disk (for example when removing generation numbers in NTFS). Theoretically, the size of the uncompressed data can be less than the compressed block, but in practice we have not seen this yet.

Once data is processed, the needed part of the processed data is accessed. Data is used partially for example in BTRFS when the same on-disk extents are used by different versions of the same file in different snapshots.

The second forensic feature we have added is a content type classifier. The content type classifier allows you to quickly find out to what type some or other file belongs to – namely you can detect what file type you deal with – doc, jpg, or say with png. ReclaiMe Pro reads some parts of the file, and decides what the content type is. This analysis is pretty quick, but says nothing about the status of the file – good file or bad.

The third new feature in ReclaiMe Pro is File testing. File testing is more detailed file analysis which is done to detect a file condition – whether a file is good or bad, whether it contains bad sectors, and also to detect the quality of the recovery. Although File testing feature in our in-house tests showed fairly stable and reliable results, you should not rely entirely on it. The main limitation is due to the fact that nothing can replace manual check. For example there is no way using which software can distinguish last, in other words – useful, version of a file from old ones. More than that, typically ReclaiMe Pro cannot and does not seek to read a file in detail. Whenever possible, the software quickly scans files checking only the key points. Such method is applied for the following reasons:

– There are a lot of file formats. Some of them are quite complex. It would be too expensive to implement complete reader for every file format out there.
– For some file formats, especially for compressed files, full-scale testing requires excessive amounts of computing power.

Additionally, sometimes it may happen that format of a file does not match its extension. For example some files have .DOC extension while actually they are just text files. When testing, files are checked in accordance with found data format. If you want to select all files for which extension does not match file content, use a special search function built into ReclaiMe Pro.

So, you should use the result of testing files with some healthy skepticism like, take it as approximate estimate of the recovery quality.

And the last feature we have added is calculating file hashes. File hashes can be used either just as they are, or to filter files against a known hash database, for example, based on a database of known system files to throw uninteresting information.

Today, that’s all. Also I should note that you can test all the discussed features in evaluation version of ReclaiMe Pro. I very much hope that you will find these features useful. I look forward to your feedback and suggestions so that we continue improving our software.

End of Transcript

Leave a Comment