-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: Provide disk map; extract unallocated for further processing #85
Comments
I am not sure I understand. Do you mean blocks that are NOT part of files detected by RecuperaBit? |
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: 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. |
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. |
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.
The text was updated successfully, but these errors were encountered: