Given the bunch of 00's from offset 0x350, my guess is that attribute lists where not present for that particular file (meaning all data runs are located inside that $MFT record). However, with just 1 record and nothing else, it is hard to say. 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. Maybe that in combination with the information found in your provide MFT record at offset 0x238-0x33F (what can that be?), combined can shed some more light onto what and where and when..
Bottom line there likely does not exist any method that will do this for you in automated way, and you will have to dig into and prepare to spend a lot of time on this without any guarantee whatsoever about being able to recover more than fragments of the original.
Good luck.
hello joakim!!
I also feel that there is only a single MFT entry.
Where is the $LogFile located?
Is on the troubled disk? Or in the Windows disk?
The problem in the troubled disk occurred last september, and since then
I've been using the Windows disk.
okay, for what I am reading, it seems that each volume keeps itw own log file. Is that correct?
In this case, it is very possible that the last write operations, are still stored there, and the pointers to the clusters. )
How can I decode this file?
edit ok, I see that the $LogFile is at the beginning of the disk. I can see it with NTFSWalker and with DMDE. But it doesn't seem to appear in the folder tree in Windows Explorer.
Is it possible to decode this Log File easily?
The file's data, is more than 10 Mbyte long. Most of it is due to the pictures, of course.
Yep, I have a copy of a previous edit, and I have carved out the new fragments, so I think I have it all, but for me it would be reassuring to recover the file elegantly, using the pointers that were contained in the MFT before the crash/froze. When Windows froze, the file's MFT was updated, and the size was set to zero. But I wonder if the pointers are still at the end of the MFT-entry.You can try using DMDE
http//softdm.com/
feature of mapping clusters.Another approach is "negative logic".
Make an image of the disk.
On the image, start deleting (and wiping), as an example with sdelete, each and every file.
What remains (and is not 00) should be only "previously deleted files" or "remainders not anymore indexed".
You will still be searching for needles, but maybe not anymore in a haystack, but inside a box. winkjaclaz
jaclaz, I am not sure if sdelete can be applied to an image file of a disk. Also, being a command-line program, I think it is easy to mess things up and end up deleting the container drive instead of the image file.
jaclaz, I am not sure if sdelete can be applied to an image file of a disk. Also, being a command-line program, I think it is easy to mess things up and end up deleting the container drive instead of the image file.
Sure, you need to mount the image as a drive.
A suitable driver will be needed, for the scope of the test IMDISK
http//
http//
will do nicely.
Of course you need to make sure to provide to sdelete the "right" drive letter/path to delete (and double check that).
jaclaz
okay, jacklaz, I will mount the image as a virtual drive.
Regarding deleting, do I simply have to apply "sdelete" to the drive's letter? So simple?
Other possibility is using the program "Eraser"/Heidi. This one has a GUI and can erase the file's data area too. Hopefully, there is an option to erase with zeroes.
http//eraser.heidi.ie/
But I am also waiting for joakim's reply on the Log File and how to decode it.
$logfile analysis is where it's at.
$logfile analysis is where it's at.
sorry, what do you mean?
okay, jacklaz, I will mount the image as a virtual drive.
Regarding deleting, do I simply have to apply "sdelete" to the drive's letter? So simple?
Well, it is not something difficult.
Try with the recursive switch, (-r or -s)
http//
Even if it doesn't work from the ROOT, at the most you will have to recursively delete a few files and directories.
Just try it, if it doesn't work we'll find a way.
Personally I don' t like/use eraser (not that is not good, but it is yet another contributor to the spreading of the myth)
http//www.forensicfocus.com/Forums/viewtopic/t=3237/
jaclaz
is there any problem with Eraser?
I don't mind if they spread any miths (I see you are referring to the need of several passes to effectively delete the data).
I fear command line microsoft software. I recently used a software named "robocopy", to copy a few files, I messed up the parameters, and I accidentaly erased a whole disk LOL. Fortunately it was backed up.
is there any problem with Eraser?
Not that I know of. )
I don't mind if they spread any miths (I see you are referring to the need of several passes to effectively delete the data).
I fear command line microsoft software. I recently used a software named "robocopy", to copy a few files, I messed up the parameters, and I accidentaly erased a whole disk LOL. Fortunately it was backed up.
Well, that can happen, with command line as well as with GUI's.
As a matter of fact I tend to trust more a VERIFIED/TESTED command line tool than a GUI, not because of the GUI, but because the "false perception" that GUI means easy, and you can give to it any command, make any choice and it will automagically do what is best for you (usually they tend to do what they think it is best for you, which might not be the same thing).
Of course there are "simple" tools still with a GUI, but the general trend is "don't worry, I know what to do, just press the button" approach.
jaclaz