RFE: Provide disk map; extract unallocated for further processing

[thinrope]

It will be great to be able to extract whats "left over", space that does not belong to any of hte recovered files, after processing with RecuperaBit.

I am not 100% sure how exactly will that work, but probably being able to write out an (dd) image of the original input with all blocks that are part of a recoverable file (attention 0-sized files), ideally as a sparse file (on NTFS/ext4) if possible. That will allow to run through it with a carver, instead of having to run through the whole disk. Saving some kind of index of the 0-blocks along (in a separate file) will be helpful.

Actually providing some kind of map of the block usage (0s, MFT, recoverable file...) as a text/db format will be a great addition to the upcoming GUI.

[Lazza]

being able to write out an (dd) image of the original input with all blocks that are part of a recoverable file

I am not sure I understand. Do you mean blocks that are NOT part of files detected by RecuperaBit?

[thinrope]

Yes exactly! RecuperaBit does a great job to reconstruct files based on carved metadata, but when there is no metadata for big chunks of the disk, those can be further processed by data carving methods. In other words:
image.dd + RecuperaBit ---> recovered_files + logs (bodyfile/CSV) + untouched_space.dd

Alternatively a map of the original image of some kind (0es, known_by_RecuperaBit, unprocessed) might substitute the actual untouched_space.dd as well, e.g.
#start:size:type
0:23454435:0
23454436:50000:unprocessed
...

[Lazza]

OK, I understand what you mean. I believe this is probably quite out of scope for a "file system reconstruction" tool, nevertheless I'll leave this issue open. If many people think this is an important feature it might be possible to implement it in the future.