-
Notifications
You must be signed in to change notification settings - Fork 75
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
Recuperabit doesn't find any partitions, while the partition table is still intact. #17
Comments
I have to ask you the same question as here:
|
I'll have to ask the owner of the borked drive. I'd guess the drive was formatted in windows XP, but it could have been windows 2000. Also, I'd expect the partition to be listed under 'other' if it's not detected as ntfs? After all the partition table is still ok? Or do I misunderstand how it's supposed to work? |
NTFS up to version 3.0 (corresponding to Windows 2000) didn't include the identifier in file records. So when file records are scanned it is impossible to distinguish them and figure out how they should be divided. While one could (in the lucky case of a working partition table) put them "all together" in one partition, the issue would still be of figuring out exactly where the MFT starts (so you must have the first records there as well) and if it is fragmented. You would also need to avoid using records from a previously formatted/old file system. Otherwise you would end up with a "heap" of random files smashed together which is not a very forensic approach. Actually using wild guesses to rebuild the file system doesn't seem a reasonable solution if one wants to ensure that the extracted information is correct. Also, you must assign an id to each entry otherwise the directory tree reconstruction cannot work.
The partition table is not used at all. RecuperaBit only supports NTFS reconstruction so any other file system type is ignored. You may want to check out the slides for further information. Going back to your original point: if it is at least NTFS 3.1 then it is a bug (so please let me know). If it is an older NTFS version then unfortunately you cannot reconstruct it with this approach. You may want to use other tools such as Restorer Ultimate Pro, but keep in mind the accuracy might not be excellent. |
I seem to be having a similar problem, but it was a windows 7 partition. EDIT: I get the same output. No partitions found, but it has found records. I have also tried allparts and had no partitions returned. |
@rockofclay please can you show the output? |
|
It would be really interesting to see those records at a lower level. Could you send me a dump of a few of them via email? |
@Lazza I am trying to run this on a dd_rescue output of a failing Apple_HFS drive but get |
Why? 😮 HFS has nothing to do with NTFS. |
I'm currently running the script again. What did you want me to do to dump the records? |
Please open the disk image with wxHexEditor (or another tool that can handle huge files) and extract a couple of megabytes starting from:
Sector 435761 starts at byte 223109632. You will see that the first characters are |
I am going to close this as it was not possible to reproduce and was (probably) due to a old, unsupported NTFS version. |
I have a disk image with a corrupted ntfs filesystem. The partition table is still intact. RecuperaBit prints a lot of messages about finding file entries. and then it prints
0 partitions found
The
allparts
command does not return anything.The partition table of the disk is still intact, so I would expect RecuperaBit to find the partition (and maybe tell me it's not recoverable)
Output follows:
The text was updated successfully, but these errors were encountered: