Hi,
I believe that recovery of the old $MFTMirr is not possible, as this is always located in the middle of the hard drive (but whether it is the exact middle, or just roughly in the middle, I do not know; hopefully someone may be able to clarify this further). The $MFT referenced in the $MFTMirr will be the new one.
What I would suggest would be to search with a Hex editor like WinHex, or HxD for the unicode string "FILE*" or "FILE0". This may return some false positives, but you can easily tell an $MFT entry that contains this, as the "FILE*" or "FILE0" will be butted right against the start of a sector boundary (you could just search for "FILE" but this will return a LOT of false positives).
$MFT entries for specific files appear in chunks of 1024 within the $MFT (occupying 2 sectors each).
I'd also recommend you look at some reference material on NTFS and MFT if you're going to manually look for files like this. It may seem complicated at first, but it pays off as you can use it to easily verify/validate any push-button tools you might be relying upon. Plus it helps you understand completely what the tools are doing for you!
I'd recommend looking at Forensic Computing A Practitioner's Guide by Sammes and Jenkinson as they have a very thorough chapter including worked examples of doing $MFT analysis manually. I'm pretty sure its on Google Books if you can't get hold of a hard copy!
Hope this helps!
Ben
Awesome Ben, thanks! I did find that book on Google books, and I'm going to start reading that section. I appreciate the tips!
John
No problem!
Just one thing that I forgot to mention before is to watch out for the update sequence array (aka fix-up code). Basically the last 2 bytes within each sector is swapped to be the same in every sector occupied by the specific file addressed by that $MFT entry (it's used to show which sectors contain data pertaining to a specific entry, and to aid in recovery and data redundancy, amongst other things); the problem arises when you don't swap the data back to what it should read.
For example If you are manually carving out a file such as a picture, you will get a garbled/corrupted image. Fortunately the data that should be put back into the last 2 bytes of each sector is stored in the $MFT file for you to reconstruct it. Again, Sammes' and Jenkinson's book talks you through this nicely, just be aware of it; if you manage to recover the files and you don't get back what you expected, then this might be your culprit!
Cheers
Ben
The two bytes mentioned by benfindlay only applies to the MFT and INDX file entry. The fixup will affect bytes 0x1fe and 0x1ff. Actually it is very rare for these values to interfere with the MFT as the large majority are less than 0x200 bytes in length.
These bytes will not affect data carving with the exception of files stored within the MFT, which will normally be less than 0x180 bytes in length.
Data carving for pictures will only be affected by file fragmentation, and possible overwriting
I have a thumb drive that has the pin code lock on the device, classified 8100 black box by Innovations. If one does not have the PIN code then you cannot access the thumb drive files as they are locked/encrypted. I did find instructions regarding resetting the pass code but the instructions say the device needs to be reformatted and data will be lost.
I am looking for ideas as to how I can get around the encryption and recover the data..