MFT-Access - Reading & parsing the Master File Table on NTFS Filesystems

[joakim]

Not in the current form. However a datarecovery solution may emerge from it soon, and along the way something related may also pop up..

[TobalJackson]

So i'm taking a look at the progress you've made so far with this tool, and Haven't yet managed to play with it. But I've been dabbling in data recovery techniques for several months, and am looking for something specific which I think your program can (probably) already do.

I see many data recoveries on a daily basis, and almost all of them boil down to being able to use gnu ddrescue (http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html) to image the drive, and then I'll either chkdsk or just use photorec to carve all the data files from the disk. This usually works with little issue. The cases specifically that led me to finding your project are those where the drive is just beginning to fail, and only have a few gigabytes of transfer left in them before failing completely (Head assembly or drive motor). In many of these cases, ddrescue fails at imaging the device anywhere between 10% and 80%, after which the drive is pretty much inaccessible.

What I've been trying to research is a way to parse the $MFT and "browse" the hdd's contents (non-destructively) by accessing JUST the (copied) $MFT, and then prepare a block/sector/byte list which I can target for ddrescue's super-nice data reading techniques. GNU ddrescue accepts as input the byte-level input and output position on the drive/partition which would minimize copying useless operating system or empty blocks/sectors. The only thing needed would be a block/sector/byte list of selected files and folders (extracted from $MFT) and a script which I can try throwing together to plug that list into ddrescue.

What I'm imagining is a program that will open an MFT file, then display a file/folder tree with checkboxes. Once the checkboxes are checked for individual files/folders, the program should recursively build a list of byte/sector/block ranges that make up each of the contained files. It will output a csv or tab-delimited file with block/sector/byte ranges that comprise the selected files which can then be parsed and input to the ddrescue program. Please let me know how much, if any, of this is possible. Thank you for all your hard work.

[joakim]

With some very very great help of user DDan at forensicfocus we (or mostly he) managed to transform my original code into a data recovery solution. It worked nice on some nt5.x x86 systems as you could run it on your local system drive (or any ntfs formatted drive) and it would extract all content from $MFT including deleted entries, resident, non-resident, compressed, uncompressed and sparse. However on Windows 7 x64 it always crashed somewhere in the midle and it took a lot of time to trace it, and of course it was also difficult. I needed a little break from it, and it has now gone 2 months since. The code was never made public, but I think it really should, because lots of people would certainly find it interesting and helpful.

It was capable of correctly extracting most if not all $MFT entries, and extract it with correct and full path, and mark deleted files with a custom text/mark. The underlying code for the data recovery is certainly there to facilitate what you're asking for, but requires modifications, of course. I am not sure I will be able to support the code if made public, because there will be just too many questions I guess. And of course the time for customizing the stuff you request, which I don't have.

But others may have the time, skill or interest, so let me see if we can arrange something over the next few days..

[joakim]

The code was posted here;

[Iczer]

Is there are possibility of function "_FullDriveMFTFileListToArray"? I hope it would be many times faster than usual FileListToArray

[joakim]

Is there are possibility of function "_FullDriveMFTFileListToArray"? I hope it would be many times faster than usual FileListToArray

I am not sure what program or version you refer to, but if my assumptions are ok then the function DoFileTree is what you're looking for, and probably very close to your requested _FullDriveMFTFileListToArray function. But it is not at all fast, as it first must resolve the MFT on disk (read as runs/extents), then traverse and decode it to identify its content, and then finally build the array of file/directories including full paths. I never compared it to anything else though. But I am not convinced it will be faster than FileListToArray because that one depends on shipped winapi which I assume is highly optimized (however with the drawback of only showing you the files that you are allowed to see using those winapi's..). I guess importance of power and speed matters.

[KaFu]

But I am not convinced it will be faster than FileListToArray because that one depends on shipped winapi which I assume is highly optimized (however with the drawback of only showing you the files that you are allowed to see using those winapi's..).

 

Fully acknowledged, that's what I thought too. Maybe give Melba23's excellent UDF >RecFileListToArray a try instead.