In ReclaiMe Pro, you can get forensic trace file(s) for the recovered files in .CSV format. This feature allows you to know where file metadata like timestamps and file content are located on the storage device you are investigating.
There are three modes of the Forensic trace feature:
- One trace for all files — for each file recovered a trace file is created
- One trace per file — each file trace is placed into a single .CSV file
Forensic trace format
Each line in a trace file starts with Object type, which can be one of File, Extent, or Timestamp.
General trace structure for a single file is:
- File entry, specifying a file name.
- Zero or more Timestamp entries, specifying timestamps whenever available, in no particular order.
- One or more Extent entries, specifying data extent on disk, in order of increasing offset in file.
Object type — File
When Object type is File, it is followed by a single field — Target, which specifies a file name.
Object type — Timestamp
Target field of Timestamp object defines what timestamp is for: creation, modification, or last access.
Different filesystems store timestamps in different formats with regard to the time zone.
Since generally it is impossible to determine time zone settings used by filesystem when writing a file, timestamps are given in the same form as they are written in the filesystem.
You will have to establish timezone whenever appropriate by some other means, most likely by cross-referencing with other sources.
Each filesystem stores timestamps in different metadata structures. In ReclaiMe Pro, the Offset on disk field points to the different structures depending on a filesystem type.
FAT — Offset on disk points to the FAT directory entry for the file.
exFAT — Offset on disk points to the primary exFAT directory entry for the file.
NTFS — Offset on disk points to an MFT record containing the corresponding STANDARD_INFORMATION attribute of this file.
HFS/HFS+ — Offset on disk points to a corresponding leaf node entry in the Catalog file.
EXT, XFS, UFS, BTRFS — Offset on disk points to a corresponding inode containing file/folder metadata.
Object type — Extent
This object specifies an extent of data on a corresponding storage device.
The extent data may be plain, compressed, or it may require some other processing to convert from its raw form to the actual data.
The sequence of reading the data extent is as follows:
- Read Size on disk bytes from Offset on disk.
- Apply whatever transformation necessary; if an extent is compressed, this will result in more bytes than the on-disk extent size.
- Take Target Length bytes at Read offset bytes from the start of the unpacked extent, and place these data at Target offset in a file.
Extent fields are defined as follows:
Offset in a file where this extent should be placed, in bytes from the start of the file.
Length of extent data in a file, in bytes.
Object subtype defines processing of this extent.
- Plain — the extent holds the exact data, no processing required.
- NTFS resident. Specifies an NTFS resident file content, for which fixups (generation numbers) of the MFT entry must be corrected before the data can be used.
For more information see , page 93.
- Sparse — the extent is sparse, and does not have any data in it. Stream of zeros should be produced.
- Preallocated — this is an EXT filesystem preallocated (uninitialized) extent.
Although it has data area defined on disk, that data should not be read; stream of zeros should be produced instead. See Extent Tree in .
- Compressed-NTFS. See , page 74 for more information.
- Compressed-LZO — standard Lempel—Ziv—Oberhumer compression algorithm, used in BTRFS filesystem.
- Compressed-ZLIB — standard ZLIB implementation, typically used in BTRFS filesystem.
Specifies a device on which extent in question is located.
Offset on disk
Byte offset to the start of the extent data on disk.
Size on disk
Byte size of the extent on disk.
Byte offset from the start of the uncompressed extent to the start of the file data. This is used when the extent is compressed or needs some other transformation before use.
 NTFS Documentation by Richard Russon and Yuval Fledel, dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf