Good discussion.

Elena - is this a direction of travel you intend to take with ReclaiMe Pro? e.g. by introducing more "forensic" functionality?
_________________
Jamie Morris
Forensic Focus
Web: www.forensicfocus.com
Twitter: twitter.com/ForensicFocus
Facebook: www.facebook.com/forensicfocus 

Sure.

See, there are two types of logs/traces that can be theoretically produced.

First are decision logic traces, related to data recovery process. These are more-or-less trade secret, especially when we're around knowledge produced by reverse engineering something.

Second are file/data location traces, like, "this file was produced from such and such sectors on said disk, and timestamps came from that sector". These can be easily provided and do not contain anything untoward. These can be used, for example, to verify the data, say, with WinHex or other disk editor (referring to "other tools"). The reliability of metadata (like timestamps) on a modern CoW filesystem in case of deleted files is a moot point, but that's a full different can-o-worms.

Considering these "copy traces", can anyone suggest a common format for these, if it even exists?  

- ReclaiMe

Considering these "copy traces", can anyone suggest a common format for these, if it even exists?

Possibly NOT exactly the answer to your question, but what I find an interesting approach is the one used by FTK imager of recreating the filesystem items or filelist in a .csv which though possibly not the best format in terms of access/indexing/efficiency, remains nonetheless the most "portable" and "cross platform/cross application" one, and as an example it would allow to produce a graphical/browsable interface, like the one Francesco put together here:
www.forensicfocus.com/...c/t=11359/
while allowing easy search/access by everyone else from scripts or *whatever*.

The point maybe deciding which fields to insert in it, find a way to add in a sensible way the list of sectors occupied[1] and "refine" the format that "as is" has some "issues", see:
www.forensicfocus.com/...2/#6572932

Of course a more "proper" database could be more suitable but it would IMHO create interchange problems or the need of a given specific database engine/tool, the only candidate could be possibly SQLite, since it is Public Domain and there are several tools that can deal with that format.

jaclaz


[1] Most probably it would be needed to create a field containing either a range of absolute sectors (for files found to be contiguous) or the name of a separate file containing the list of sectors (for non-contiguous files).
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

We probably will be releasing the update addressing these issues in a couple of weeks. For a copy "trace", we settled for the moment for one CSV file per copied file. Fields are, well, for each extent, the disk location and the extent format (compression method for compressed extents, NTFS resident, or just plain extent).  

So, we now have an update including,

1. Traces, where the file data comes from on-disk? where timestamps come from?
2. File content-type classifier (what content type is that file?)
3. Prototype file content tester (is this a good file, or damaged?) for JPEG only
4. Hash calculation for recovered files, and also search by hash function (load text file with MD5s or SHA1s).

if you have any input on these, I'd be glad to hear it.