Join Us!

Recovering from ful...
 
Notifications
Clear all

Recovering from full format?  

  RSS
jblakley
(@jblakley)
Active Member

All,

I'm testing a theory, but it's failing. I had 4 files on a thumb drive. This drive was formatted with ntfs. I reformatted the drive as ntfs, and I'm trying to get the data back. The MFT shows to be from yesterday when I formatted the drive, so I know the MFT is new. Is there a way to get this data back? Using fls, I only show the following

r/r 4-128-4 $AttrDef
r/r 8-128-2 $BadClus
r/r 8-128-1 $BadClus$Bad
r/r 6-128-4 $Bitmap
r/r 7-128-1 $Boot
d/d 11-144-4 $Extend
r/r 2-128-1 $LogFile
r/r 0-128-1 $MFT
r/r 1-128-1 $MFTMirr
r/r 9-128-8 $Secure$SDS
r/r 9-144-6 $Secure$SDH
r/r 9-144-5 $Secure$SII
r/r 10-128-1 $UpCase
r/r 3-128-3 $Volume
d/d 256 $OrphanFiles

I'm trying to look at the $MFTMirr, but I'm not able to see anything from it. The only thing I can get back from it are it's attributes using istat.

I'm going to copy more files back to this drive, and then do a quick format instead of a full to see if there is any change. So, the main question is Is there a way to truly get data back if the drive's been formatted?

Thanks!
John

Quote
Posted : 08/09/2010 8:53 pm
mscotgrove
(@mscotgrove)
Senior Member

It does depend which version of Windows you used to format. XP will just write the MFT again, while Windows 7 (often) erases every sector. The late, the data is lost.

For a quick format, the method I use is to scan the whole drive to find any existing MFT entries. With a new format, there are often old entries, but not part of the current $MTF file. Not every MFT entry you find will be valid, but many will and a very high level of recovery is possible. All the files you list above will be new, and so have no knowledge of previous information on the drive.

A similar process can be used if the format changed from NTFS to FAT, or FAT to NTFS, ie sarch for previous directory entries.

If all else fails, then there is always data carving, but this should be considered a last resort as most file meta data will be lost. Data carving will indicate if there is data to be found.

ReplyQuote
Posted : 08/09/2010 10:52 pm
jblakley
(@jblakley)
Active Member

It does depend which version of Windows you used to format. XP will just write the MFT again, while Windows 7 (often) erases every sector. The late, the data is lost.

I did use Windows 7 to format this usb drive. I could retest this with Windows XP to see how I could recreate the data. Do you have any tips on how to recreate or even find the data from the $MFT after a format?

Thanks for the response! (Nice blog btw…I'll be reading it. )

John

ReplyQuote
Posted : 08/09/2010 11:02 pm
mscotgrove
(@mscotgrove)
Senior Member

My 'biased' answer is the (demo) of my software does have a wizard function to do what you require. I am sure that other software packages can also perform the required steps to discover unallocated MFTs.

My suggestion for your testing is to fill the thumb drive with known files, JPEGs can be good as they are easy to view. After a format, look at sectors that where used and see if blank or not. If not blank, then investigate recovery methods

ReplyQuote
Posted : 08/09/2010 11:34 pm
TonyC
(@tonyc)
Junior Member

As mscotgrove said, if you used Windows 7 FULL FORMAT the data is gone. Beginning in Windows Vista Microsoft changed the behavior of the format command. In both Vista and 7 a FULL format, which is the default, writes every sector with 0x00. The data is gone and is not recoverable. See http//support.microsoft.com/kb/941961

In Windows XP neither a FULL format nor a quick format overwrite the data. In Vista and 7 a quick format also will not overwrite the data.

Software such as GetDataBack or any other similar tool will be able to recover most of the data from a Windows XP FULL or quick format or a Windows Vista or Windows 7 quick format.

TonyC

ReplyQuote
Posted : 09/09/2010 2:37 am
bgrundy
(@bgrundy)
Member

Do you have any tips on how to recreate or even find the data from the $MFT after a format?

Assuming you can test on a quick formatted volume (no zeroing), then I would look for MFT Entry signatures. When you reformat a volume with NTFS, it will write a basic $MFT with only those entries that are required. This means that entries from the OLD MFT will still exist on the disk, but not be visible in the new MFT. You SHOULD be able to find old entries if the new volume had less files (in theory).

Since you started using TSK already, I would use blkls to carve out the unallocated space from the newly formatted volume - so that you exclude the new MFT and it's entries - and search for old MFT entry signatures using sigfind and a sector offset of 0 with the signature "FILE". If you find that, then you can look at the next 42 bytes for information on the file attributes (I'm sure you can find the structure of an MFT entry somewhere). The entries should be 1k in size (so carve them out with 2 block using dd).

Even just looking through the resulting blocks (with xxd, for example), you should see recognizable attributes like the file name.

HTH,
Barry

ReplyQuote
Posted : 09/09/2010 3:37 am
jaclaz
(@jaclaz)
Community Legend

A (seemingly unrelated) thread that may interest you
http//www.msfn.org/board/index.php?showtopic=145574

A couple of apps that may also be of use
http//dmitrybrant.com/ntfswalker
http//softdm.com/

For the record, unlike what a lot of people apparently thinks, the $MFTMirr is pretty much useless, as it consists of ONLY the first 4 (four) records of the $MFT.
Obviously once you re-format, it represents the mirror of the first 4 records of the NEW $MFT, unless you changed CONSIDERABLY the partition size (thus causing the new $MFT and $MFTmirror to be "somewhere else") or you used a NT system that uses a different "default" for the placement of these structures - like Windows 2000, in which case the OLD filesystem structure may be not overwritten.

jaclaz

ReplyQuote
Posted : 09/09/2010 9:55 pm
jblakley
(@jblakley)
Active Member

A couple of apps that may also be of use
http//dmitrybrant.com/ntfswalker

That's a very handy piece of software!

I ended up using TestDisk to get the data back from the formatted drive. That's a very good piece of software too. I did test some things though, and here's what I found.

Like everyone here has already said, Windows 7 full format completely gets rid of the data. Here's what I did

1. Copy files to thumbdrive (TB) and full format on WinXP. Data recoverable with TestDisk.

2. Copy files to TB and Quick Format on WinXP; Data recoverable using TestDisk.

3. Copy files to TB and Quick Format on Windows 7 Data recoverable using TestDisk.

4. Copy files to TB and Full format on Win7 Data is NOT recoverable; nothing found with TestDisk.

Thanks for everyone's response!
John

ReplyQuote
Posted : 09/09/2010 10:10 pm
jaclaz
(@jaclaz)
Community Legend

Here's what I did

Yep ) , that's exactly what is expected.

But the OP (unless I got it wrong) was about (partially) recovering data after BOTH a non-destructive format (i.e. any 2K/XP/2003 one or a /q Vista/7/2008 one) AND a partial overwriting with new files (in which case TESTDISK won't be useful).

jaclaz

ReplyQuote
Posted : 09/09/2010 11:46 pm
jblakley
(@jblakley)
Active Member

partial overwriting with new files (in which case TESTDISK won't be useful).

jaclaz

I didn't try overwriting after the format initially. I just wanted to see how I could recover data should I ever run into a formatted drive issue D

Thanks!

ReplyQuote
Posted : 09/09/2010 11:48 pm
benfindlay
(@benfindlay)
Active Member

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

ReplyQuote
Posted : 10/09/2010 2:00 pm
jblakley
(@jblakley)
Active Member

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

ReplyQuote
Posted : 10/09/2010 4:58 pm
benfindlay
(@benfindlay)
Active Member

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

ReplyQuote
Posted : 10/09/2010 6:57 pm
mscotgrove
(@mscotgrove)
Senior Member

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

ReplyQuote
Posted : 11/09/2010 12:23 am
cnjranch
(@cnjranch)
New Member

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..

ReplyQuote
Posted : 23/01/2011 7:59 am
Share: