Gurus,

The specific thumb drive in question is a Sandisk Cruzer Titanium 512Mb model number SDCZ3-512 part number 0112-512. If it helps any my research shows this drive to use a Silicon Motion SM320T controller chip. The drive has been cloned using your HDD Raw Copy utility to a similar sized but non-dentical flash drive. Any experiments that required writing to the drive have been done to the clone. BTW, even though the source and clone drives were the same size Raw Copy produced an error. Apparently there were slightly more sectors on the bad drive than the clone drive. I don't know if that is significant but though I would mention it anyway. I hope that nothing important is stored at the end of the drive.

The event that led to this condition was simply ejecting it from one PC and when inserted into another Windows came up with the warning that the disk was unformatted and asked to format it. I immediately answered "no" and ejected the drive. Because of this I don't suspect malware to be involved.

I have tried about a half a dozen disk and file recovery programs without much success including the two recommended by Sandisk. They manage to find pieces and assemble a lot of files but without file names it is hard to know what is real and what is junk. None of the programs has been able to find or recover the directory tree. This drive probably has more deleted files and fragments on it than active files. Without the directory it is a big mess!

I had a small breakthrough last evening. I know that the drive has geometry problems. I have Partition Magic 7 but have only used it to move and resize partitions and nothing else. I found here a utility PTEDIT32.exe. With a good flash drive PTEDIT32 showed realistic geometry. When I inserted the bad drive it showed all zero's for the geometry! I took the clone drive and added geometry parameters from a working similar sized Cruzer Micro drive.

I ejected and reinserted the drive but still no joy. I went into PTEDIT32 once more and now that the geometry was reasonable it would let me look at the rest of the boot record. It was also all zero's! This helps to explain the missing directory tree. So it appears that some malfunction has resulted in some sectors in the partition table getting zero'ed out.

Any suggestions on where to go from here? I guess I need to go look for the FAT. If it is gone then it is Game Over! Any recommended tools that would make this easier? Where is Norton Disk Editor (or modern equivalent) when you need it! If I had a good identical drive I might try to replace the missing partition table and boot record sectors. Unfortunately this drive is pretty old and finding a duplicate won't be easy.

Your thoughts?


Thanks,

Steve

Could you upload a dump of the first 100 sectors of your clone, before you messed with sector 0?

BTW, you can clone your flash drive to an IMG file on your HDD and then mount/open this image in a disc editor such as HxD or DMDE.

You could also use HxD or DMDE to dump the first 100 sectors.

Be aware that your flash drive may have been formatted as a "super floppy", in which case it will not have a partition table, just a FAT boot sector.

_________________
A backup a day keeps DR away.

Fzabkar,

Thanks for the response. I went and got DMDE. It appears that it's image file format is different than the one used by HDD Raw Copy Tool which I used to make the original image and clone. Because of this I made a fresh image of the bad drive with DMDE to mount and mess with.

How should I upload the requested first 100 sectors? As raw text? I don't see any places to put files in this forum. 100 sectors would be a pretty long text post.

Thanks,

Steve

To save the requested sectors, launch DMDE.

In the Select Device/Disk tab, select the Physical Drive, choose the Physical Devices radio button, uncheck the Show Partitions box, and click OK.

You should now see LBA 0 (sector 0) of your drive.

Now select Tools -> Copy Sectors

Start Sector -> 0
Number of Sectors -> 100

In the Destination pane, select File.

You will be offered a filename of lba_0_100.bin (not on your flash drive).

Click Save, OK, etc.

IIRC, you will need to ZIP the file before uploading it as an attachment to this forum. The "Upload attachment" input box is below the reply window. Otherwise upload your file to RapidShare or some other file sharing site.

_________________
A backup a day keeps DR away.

My guess is that you are not actually reading from the memory and just getting a dump generated by the controller. You will likely need to remove the memory and recover the data with tool like PC3000-Flash or SoftCentre or send to a data recovery professional who does have the tools for the job. Assuming that the unit was not encypted and password protected with U3 software, the recovery should be relatively straight forward for an older and smaller chip.

_________________
Luke
Recovery Force Data Recovery

Fzabkar,

I followed your instructions and you should find the requested BIN file attached. Things are beginning to look up. There appears to be an MBR and at least one copy of the FAT. It appears that PTEDIT may not have known how to properly handle a flash drive leading to my previous possibly erroneous conclusions.

Thanks for your help.

Steve

Short version:

You need to edit sector 0 so that it looks like the following:


==============================================================================

Long version:

Offsets 0x4000 - 0x41FF comprise a FAT16 boot sector. That's physical sector 0x20.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F


Offset 0x4200 is the first sector of the first copy of the FAT.

The information is the BIOS Parameter Block is indicating that the FAT volume begins at sector 0x00000020 and has a size of 0x000F7BDF sect

That works out to about 520MB (= 495MiB).

http://www.google.com/search?q=0x000F7B ... in+decimal
http://www.google.com/search?q=0x000F7B ... +megabytes

There are 0x200 (= 512) bytes per sector.

There are two FATs each consisting of 248 (= 0xF8) sectors. The first FAT begins at logical sector 1 (physical sector 0x21).

The CHS geometry is ...

0x20 (= 32) sectors per track
0x81 (= 129) heads per cylinder

Sector 0 (offsets 0x000 - 0x1FF) contains the MBR and the partition table.

The current partition table (offsets 0x1BE to 0x1CD) is empty.


You need to edit sector 0 so that it matches the data in the boot sector. It should look like the following:


In order to edit your disk image, select Edit -> Edit Mode.

Your root directory should be located immediately after the second copy of the FAT. It should contain identifiable filenames.

The two FATs should be identical copies.

sector 32 = boot sector
sector 33 = first sector of FAT #1
sector 281 = first sector of FAT #2 (281 = 33 + 248)
sector 529 = first sector of root directory (529 = 281 + 248)

If the above edits don't quite work, try changing the partition ID byte at offset 0x1C2 from 04 to 06.

References:

FAT Boot Sector:
http://averstak.tripod.com/fatdox/bootsec.htm

Partition Table and Boot Record Editor by PowerQuest:
ftp://ftp.symantec.com/public/english_u ... EDIT32.zip

CHS/LBA Conversion Utility:
http://homepage2.nifty.com/cars/misc/chs2lba.html

List of partition identifiers for PCs:
http://www.win.tue.nl/~aeb/partitions/p ... pes-1.html

_________________
A backup a day keeps DR away.

Fzabkar,

Thanks for all of your hard work! I got in late today and am still working on digesting and trying to understand all of this information.

From what you are saying it appears that the partition table entry in the MBR for this drive somehow did actually get zeroe'd out. Seen this before? Any thoughts on how this might happen (so it can be prevented)? You are then using information from the BPB in the actual boot record in LBA:32 to reconstruct the partition table entry.

What is the best way to try this fix out? Write the changes directly back to the bad drive? Write the changes to the clone? Keep in mind that the clone has a few sectors less than the bad drive. Is it possible to just change the image and then somehow mount the image file? Any tools available for this?

Thanks,

Steve

A partition table is often zeroed unintentionally by people who accept Windows' innocuous sounding invitation to "initialise" their drive.

I would clone the bad flash drive to an image file on your HDD. Then write the changes to the image file. Alternatively you could try writing the changes to the clone. However, I don't know whether your OS will complain about the truncated file system.

That said, I suspect that your drive will have additional problems since a missing partition table is something that should be easily handled by any data recovery software. Since you have tried several programs without success, my next approach would be to verify the two copies of the FAT. I can show you how to do that, depending on what you find after repairing the partition table.

_________________
A backup a day keeps DR away.

Fzabkar,

I repaired the partition table to your specifications, saved it to the image file, closed the image file, and then reopened it in DMDE. I tried to open the partition in DMDE but the root directory was not displayed as it should have been. I did a search and it did find some recognizable file names but most were not. Also when I opened the partition DMDE came up with the "do not use FAT" box checked below the choice of using either FAT1 or FAT2.

I did verify that there were two FATs in the locations that you specified. Unfortunately when I went to look for the first sector of the root directory at LBA 529 all I found were zeros. So this means that the root directory is either missing or is not where you think it is due to the variable layout of these flash drives.

In case it will help I grabbed an image of the first 1000 sectors and posted it along with this message.

Thanks,

Steve

P.S. I am beginning to wonder if this drive screwed itself while performing a wear leveling sector swap.

I carved out the range of sectors from sector 33 to 280 and wrote them to FAT_1.bin. Then I carved out sectors 281 to 528 and wrote them to FAT_2.bin. Comparing them as follows produced no differences.


So it appears that the two FATs have been correctly identified and are consistent. This means that the root directory should have been at sector 529.

As for DMDE complaining about FAT, it could be that it doesn't like the partition ID byte. Type 04 is usually reserved for FAT16 partitions less than 32MB in size. Change it to 06. Different tools tend to be less pedantic about this distinction.

000001C0 01 00 06 6A 1F F5 20 00 00 00 DF 7B 0F 00 00 00

_________________
A backup a day keeps DR away.

According to my analysis of the FAT, the number of clusters in use is 4597, amounting to 36776 KB of used space (@ 16 sectors per cluster).

There appear to be no bad clusters.

AFAICT the partition table in sector 0 was zeroed, and the root directory was also zeroed. However the two copies of the FAT appear to be untouched.

_________________
A backup a day keeps DR away.

Fzabkar,

Thanks for the analysis. So it looks like the chances for recovery are pretty small if the root directory is gone. Most of the files on the drive were in the root directory. Is there any way to work with the FAT to recreate the root directory less file names? The total size of only 37MB also seems kind of small although most of the files were small i.e few image files.

I am going out of tow for the weekend and won't be able to do anything else with this until early next week. I'll try changing the partition type byte and take a closer look at what DMDE can pull out using just the FAT table and see if this adds up to 37MB.

Have a good weekend.

Steve

AISI, your damaged file system has the following structure:


The first part of the FAT looks like this:



Each 16-bit word in the table corresponds to a particular cluster. In your case the cluster size is 16 sectors.

The directory entry for a particular file indicates its starting cluster. The FAT then tells the OS how to find the remaining clusters in the file. Note that the data in the above table are little endian, ie low byte first.

The following article explains the meaning of each word:
http://en.wikipedia.org/wiki/File_Allocation_Table

A table entry of 0x0000 indicates that the associated cluster if free.

A value of 0xFFF7 indicates a bad or reserved cluster.

Values in the range 0x0002 - 0xFFEF point to the next cluster in the chain. A value of 0xFFFF is an end-of-chain marker.

For example, offset 0x80 appears to be the entry associated with cluster number 0x0040. It points to cluster 0x0041 as the next in the chain. Offset 0x82 is the entry for cluster 0x0041. It points to cluster 0x0042 as the next in the chain, and so on until we arrive at the 0xFFFF end-of-chain marker.

So this is telling us that we have an unfragmented file which occupies clusters 0x0040 through 0x004A. It remains to be seen whether these clusters have been zeroed like the others. If they're intact, then data recovery software should have no trouble reconstructing the file. The name of the file should be in some directory or subdirectory cluster.

_________________
A backup a day keeps DR away.

I would have thought the recovery software should have been able to find the files, it will be interesting to see if these are zeroed. What do you think the cause would have been? malware? or some kind of routine of the controller interrupted

If the drive had been "initialised", then the partition table would have been zeroed and nothing else would have been touched, AFAIK.

If the drive had been formatted, then the FATs would have been zeroed and the root directory would have been initialised.

If files had been deleted, then we would still see the root directory, and all the other directories would still be intact, albeit with the leading character of each filename replaced with 0xE5. The associated clusters would also have been cleared in the FATs.

If the files had been wiped, then their contents and directory entries would have been zeroed. However, the FATs would have been cleared as well.

AISI, the observed damage to the file system doesn't fit any of the above scenarios. Therefore I would suspect malware.

_________________
A backup a day keeps DR away.

A couple more things that the OP might like to try would be to compress the 500MB image file. I calculate that there should be about 37MB of used space. If this space were occupied by JPEGs and GIFs, then the compression ratio would be 1:1. OTOH, if the files were DOC or TXT, then the ratio would be more like 3:1 or greater. If the data area were filled with zeros, then the ZIP would shrink to almost nothing.

I would also scan the data area for remnants of directories or subdirectories. In DMDE you would select Tools -> Search for Special Sector -> FAT Directory. Look for the 0xE5 byte at the start of any filename. This would indicate that the file had been deleted.

_________________
A backup a day keeps DR away.

Hello,

I finally had some time to dig back into this tonight. I tried the zip test and the image was compressed to 389MB. This is believable since the drive was one time full of mostly image files which had long since been deleted.

As far as the cause of this file system corruption anything is possible but I am not big on the Malware theory. I have never heard of malware that would attack a flash drive on insertion or removal. I have also plugged in other flash drives without damage and have not had any hard drive issues with any of the machines that this drive has seen. I tend to think that it was a controller firmware bug or the drive may have been interrupted on removal by intermittent power contact in the horribly designed USB socket.

DMDE was able to recover some sub-directories and even showed some deleted sub-directories. However, most of what I would like to recover from this drive was in the root directory which DMDE has so far been unable to recover. Unless I am missing something the root files may be unrecoverable.

I guess the next step is to recover some of the sub-directory files and see if they are intact. If not it may mean that some of the data sectors might have been zeroed as well. If this happened it is definitely Game Over! Time to kick the horse one more time...

Thanks,

Steve

Most people at HDD Guru recommend R-Studio as the gold standard for data recovery software. It's not free, but the demo version should allow you to see what it would be able to recover.

_________________
A backup a day keeps DR away.

Are you specifically needing to recover filenames, or will the data alone be sufficient (ie, photos, documents)?

If you can live with generic file names you can use a combination of ddrescue (or dd) and photorec on Linux (not sure to recover your data regardless of the existence of a valid filesystem as it reassembles things based on file signatures. It's not always perfect, but it's a good tool for when things don't look so good.

Even just making a USB-based Ubuntu (or Mint) install can be a great tool in the toolbox.