Recovery of a text file with damaged MFT (zero sized file)

$logfile analysis is where it's at.

sorry, what do you mean?

This perhaps

The $LogFile might also provide you with some information about certain of the clusters that the file is on, because it logs details about write operations.

So, in order to get at that file, you must extract the file with reference (index/inode/whatever you like) number 2, using a low level tool. Explorer will not see this file as it is part of the systemfiles of NTFS. I don't know of any tool that will automate anything with the $LogFile as part of datarecovery, so you are left with studying and manual work, unfortunately. Prepare for a timeconsuming challenge. Good luck.

From the mouth of the wolf
http//support.microsoft.com/kb/101670/en-us

DMDE can extract the $logfile alright, the issue is it's parsing.

It's format is one of the most "undocumented" thingies around
http//inform.pucp.edu.pe/~inf232/Ntfs/ntfs_doc_v0.5/files/logfile.html
http//www.forensicfocus.com/Forums/viewtopic/t=7148/

But there is this nice thing in the works
http//hackingexposedcomputerforensicsblog.blogspot.it/2012/08/updates-and-status.html
http//hackingexposedcomputerforensicsblog.blogspot.it/search?updated-min=2013-01-01T000000-0600&updated-max=2014-01-01T000000-0600&max-results=2
which is seemingly about to be released…

jaclaz

$logfile analysis is where it's at.

sorry, what do you mean?

http//hackingexposedcomputerforensicsblog.blogspot.com/2013/01/happy-new-year-new-post-ntfs-forensic.html

@joakim
yes, the logFile is in MTF entry number 2, I can see it with NTFS Walker.
I think I could extract it using DMDE, as jaclaz suggests.

joakim, I am not in a position to reverse-engineering the Log File by myself. I am barely starting in this field.

@jaclaz
okay, I prefer GUIs. My brain feels more confortable with grafics, than text, and for me its very cumbersome to put the parameters in the command line. I feel its very easy to make mistakes.

@jaclaz&TuckerHST
So, these guys at that blog are working on a Log File parser? it would be great if it works.
But in the prototype's sample screen capture, it only recovers the names and dates, but not the dataruns locations.

Then, aside from this novelty, right now, there is no other such tool yet, is that correct?

sorry guys for the blackout, I am having urgent matters to deal with in real life.
I will be back as soon as I can, with my file-rescuing adventure.

In the meantime I have created a $LogFile parser that will among many things, retrieve and reconstruct all file location related information (dataruns, file size, etc) for any file referenced as the source of a transaction in the $LogFile http//code.google.com/p/mft2csv/wiki/LogFileParser

That means, if you in your $LogFile have records concerning the target file, then the tool may be able to reconstruct parts of the datarun list. It is a bit tricky and this method certainly has lots of limitations. However after having tried it, you will at least with certainty know if there was any such relevant information to be found in the $LogFile. If there are any dataruns found and reconstructed for the target file, you can use this tool to extract the data with; http//mft2csv.googlecode.com/files/ExtractFromDataRun_v1.0.0.0.zip

If you did not image the drive earlier, so that the only copy of the $LogFile has been written to since then, you can probably just forget about it right away, as all history will likely be gone.

Send me a message if you have problems understanding or interpreting the output.

In the meantime I have created a $LogFile parser that will ….

Nice ) .

jaclaz

Thanks Joakim.
After I had the problem, I immediately created an image with Easeus Todo Backup, but later I found that this is not a true image. The information is not a raw copy of the original disk.
In fact, it looks totally different under a drive editor.

The affected drive was online for several months, but I didn't write anything to the disk, so maybe the $Log file still contains the data.
I have a real raw image (done with dmde), but I created this one much later.

I don't have much time now, but I will try your parser.

After I had the problem, I immediately created an image with Easeus Todo Backup, but later I found that this is not a true image.

With all due respect, not so surprisingly wink , you created a backup with Easeus Todo Backup

The information is not a raw copy of the original disk.
In fact, it looks totally different under a drive editor.

But - I am not at all familiar with what exactly Easeus Todo Backup does - it is still possible that the file that was created is an "intermediate" format that once restored does provide a valid/unmodified $LogFile ) .

jaclaz

With all due respect, not so surprisingly wink , you created a backup with Easeus Todo Backup
jaclaz

LOL. of course I chose the "sector by sector" option when making the backup file.

(before I said "byte by byte" but I was wrong. Specifically it is "sector by sector" backup).

But again, the result is not a true image. It looks totally different under a disk editor.

But - I am not at all familiar with what exactly Easeus Todo Backup does - it is still possible that the file that was created is an "intermediate" format that once restored does provide a valid/unmodified $LogFile ) .

jaclaz

It is possible. But now I don't have a spare hard drive to try a restore. And as I am totally and miserably ruined, right now I cannot afford to buy a new disk. )
Maybe in a couple of months. But hard disks are very expensive nowadays, as a result of the disk duopoly (WD+SG). a 2TB drive is more expensive today than 2 years ago.

I will keep that EASEUS backup file, just in case it is useful.

note The EASEUS file is 5% smaller than the .bin image created by DMDE. So either the EASEUS file is compressed, or the non-allocated space has been left out. If it is compressed, then it might contain all the original bytes after all.

@joakim, I have not forgotten you. Lets see if tomorrow I finally test your $LogFile parser. )