USB Flash - Unknown Partition Table

littleonion · 12-30-2007, 06:48 AM

A friends USB device screwed up and now I am struggling with data recovery on this 2GB USB device (M-Systems Flash). The device can not be mounted (Key messages: "unknown partition table" and "Logical Sector Size is zero"). I already tried to backup an image on harddisk and replace the 1st sector by the 6th sector (because this is supposed to be the backup sector) using dd utility, unfortunately without success. The commands I used:

Code:

dd if=/dev/sdf of=backup.fat32.img bs=512 count=3903486 conv=noerror,sync
dd if=backup.fat32.img of=sector6.bin bs=512 count=1 skip=6 conv=noerror,sync
dd if=sector6.bin of=backup.fat32.img bs=512 count=1 conv=noerror,sync,notrunc

Mounting the resulting image using a loopback device has not been successful.

Any suggestions which tool might be able to recover the data properly (assuming we're talking FAT32)?
Is the hard disk backup image using dd sufficient for future data recovery actions (-> re-format stick and use it again) or is it recommended keeping the "original data" until data has been recovered?
Thanks in advance.

More details:

Code:

Initial info after inserting device into USB slot:
l1nuxw0rld: # lsusb
[...]
Bus 005 Device 008: ID 08ec:0020 M-Systems Flash Disk Pioneers

l1nuxw0rld: # dmesg
[...]
usb 5-6: new high speed USB device using ehci_hcd and address 9
usb 5-6: new device found, idVendor=08ec, idProduct=0020
usb 5-6: new device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-6: Product: cnmemory
usb 5-6: Manufacturer: cnmemory-drive
usb 5-6: SerialNumber: 03210B6003B2E8EB
usb 5-6: configuration #1 chosen from 1 choice
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 9
usb-storage: waiting for device to settle before scanning
  Vendor: cnmemory  Model: cnmemory          Rev: 6.50
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sdf: 3903487 512-byte hdwr sectors (1999 MB)
sdf: Write Protect is off
sdf: Mode Sense: 45 00 00 08
sdf: assuming drive cache: write through
SCSI device sdf: 3903487 512-byte hdwr sectors (1999 MB)
sdf: Write Protect is off
sdf: Mode Sense: 45 00 00 08
sdf: assuming drive cache: write through
 sdf: unknown partition table
sd 3:0:0:0: Attached scsi removable disk sdf
sd 3:0:0:0: Attached scsi generic sg5 type 0
usb-storage: device scan complete

l1nuxw0rld: # fdisk -l /dev/sdf
Platte /dev/sdf: 1998 MByte, 1998585344 Byte
62 heads, 62 sectors/track, 1015 cylinders
Einheiten = Zylinder von 3844 × 512 = 1968128 Bytes
Festplatte /dev/sdf enthält keine gültige Partitionstabelle

Attempting to mount the device results in:

l1nuxw0rld: # mount -t vfat /dev/sdf /media/vfat_backup/
mount: wrong fs type, bad option, bad superblock on /dev/sdf,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

... and dmesg tells:

l1nuxw0rld: # dmesg
[...]
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdf.

Deleriux · 12-30-2007, 07:07 AM

If you dump the entire drive to disk and mess with it on a loopback (think you've done this already) if you know the previous partition layout you can just recreate it in fdisk. You would need to know exactly which cylinders to start and end at to recover the partition though.

Once done, your disk geometry should match the previous geometry and mount should successfully pickup any vfat stuff on the disk if of course the fat32 layout is still intact.

The bytes that contain the partition table should be bytes 446-512 on the first sector.

To take an idea of what the partition table is you can go:-

Code:

dd if=/dev/sdf bs=1 skip=446 count=66 of=/some/safe/place.tbl

If you want to recover the partition table to its broken state you would do:-

Code:

dd if=/some/safe/place.tbl bs=1 seek=446 of=/dev/sdf

Deleriux · 12-30-2007, 07:32 AM

Looks like you cant fdisk in a virtual block device.

If you know the exact starting position in bytes of the fat32 table you can dd from that point onwards to recover the data.

To find out where it started you can use hexdump.

Code:

hexdump -C /your/disk/image | grep FAT16 #if your lucky you'll get the below

00000230  20 20 20 20 20 20 46 41  54 31 36 20 20 20 0e 1f  |      FAT16   ..|

If you get this multiply the first column by 16 (might need to work out the hexadecimal value first) and deduct 48. My checks show this should be the first byte of the vfat layout.

This number you can then skip from in dd and output the rest like so.

Code:

dd if/dev/sdf bs=1 skip=$magicnumber of=/some/safe/place.img

And hopefully you can then do

Code:

mount -t loop /some/safe/place.img

Good luck!

littleonion · 12-30-2007, 07:53 AM

Thanks for the idea - it sounds quite promising but unfortunately the hexdump output is empty. Actually the complete output (w/o grep) is

Code:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  e5 fc 01 00 00 00 00 00  |................|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
771ffc00

which does not really enlighten me for now - can you get any valuable info from this?
I guess I'm lacking fundamental basics about the FAT file system structure and I need further guidance here. Assuming there has not been any partition table present (meaning the device should have been mountable as /dev/sdf), how would I proceed repairing the image? Is it possible to simulate the correction on the image at all (without touching the stick and ruining the original)?

Deleriux · 12-30-2007, 08:03 AM

Well if all the lines in the hexdump say 00 00 00 00 etc (or there abouts) right to the bottom of the image there is no data to recover in the first place as the image itself looks to have been zeroed.

As a double check do the same thing on the disk itself to see if that yeilds any results.

Code:

hexdump -C /dev/sdf | grep FAT -m1

And as for fixing the partition table on the image, that wont be possible as the loopback devices dont play nice with paritions.

If you can mount the partition using the above solution it makes no difference anyway.

You can simply reformat the /dev/sdf device and copy the contents you recovered from your solution over to it.

littleonion · 12-30-2007, 08:22 AM

Well, this gives the very same result. As I interpret the output the "*" indicates that all following lines would look alike:

Code:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Is this understanding correct? This would indeed imply an empty device... Maybe someone tried to re-format the device already before I got it (without admitting)?
So I guess the Information I've been provided with (the stick should contian data and nothing has been done with it since the last proper usage) seems not to be totally true - too bad.

Anyway, thanks for your support - has been a helpful lesson!

Deleriux · 12-30-2007, 08:57 AM

Even if you format the disk it will retain data stored on it from previous formats, when you format the disk it wont overwrite every byte the disk can store, it will simply recreate a new partition tabling schema for the partition thus there would still be data on the disk to obtain just not readily accessible. This is why it is possible to "undelete" files.

There are a few obvious reasons that spring to mind why it would report this.

a) The disk has been zeroed (every byte reset to 0). This is a form of "securely*" wiping a disk so the entire data on it has been destroyed . (I.E dd if=/dev/zero of=/dev/sdf)

b) The device has a controller fault which causes it to report all bytes as 00 even if the storage device contains actual data.

c) It is a brand new device and the manufacturer formatted and zeroed it before release.

d) There is a bug in your distro.

A and D are not likely. Its more secure to wipe a disk using random data - a number of times - if you want to software destroy a disk.

B and C are likely culprits.

To test B you could just try adding data to the first 512 bytes of the disk (do a grub-install /dev/sdf), unplugging it and replugging it to see if the data remains intact when you check it.
Note: Doing this risks compromising any data that might of been on it or any partition table that could of been recovered through it.

In any case if your getting zeroes when you plug it in, you cant recover any data off of it as there is no data to recover.

If you really needed the data that badly you would have to purchase the same model device again, and physically remove the storage chip from the faulty device and place it in a new device. That is of course assuming the fault lies on the storage controller.

Do you have a soldering iron handy at all?

littleonion · 12-31-2007, 09:13 AM

Of course it should be possible to restore at least some data, but I am wondering if this is possible without using extra tools.
Got new info from the device owner: He used it in a Win XP environment and while editing a document the OS was not longer able to write the file back to the stick. The device has been recognized as empty since then. According to his info there has been no attempt of re-formatting the stick. Therefore (A) seems not to be it.

Since it has already been used and I investigated on different distors and OS now, that's why I do also not think (C) and (D) might be an explanation.

Talking (B) - of course there might be a hardware error which I could easily test but I do not want to ruin it's actual state until being sure that we have no other choice.

Quote:

If you really needed the data that badly you would have to purchase the same model device again, and physically remove the storage chip from the faulty device and place it in a new device. That is of course assuming the fault lies on the storage controller.

Do you have a soldering iron handy at all?

... yeah heating it up already ;-)

Seriously - considering the error-description I still assume there is some data left on the stick (and if I did not mention already, the device owner has some quite valuable, not yet backed up data on that stick), although it does not look good. As I understand the current results it seems to be unlikely that the device has been formatted as NTFS - what do you think. Do we have any other options in that case?

marexel · 05-01-2009, 03:40 PM

hello,

it seems that i have nearly the same problem as described but unfortunately i can't help myself with your postings. so here is my problem:
plugging a 1gb xd-card to the reader i get:
scsi 8:0:0:2: Direct-Access Generic USB SM Reader 1.02 PQ:0 ANSI: 0
sd 8:0:0:2: [sdd] 2048000 512-byte hardware sectors: (1.04GB/1000MiB)
sd 8:0:0:2: [sdd] Write Protect is off
sd 8:0:0:2: [sdd] Mode Sense: 03 00 00 00
sd 8:0:0:2: [sdd] Assuming drive cache: write through
sd 8:0:0:2: [sdd] 2048000 512-byte hardware sectors: (1.04GB/1000MiB)
sd 8:0:0:2: [sdd] Write Protect is off
sd 8:0:0:2: [sdd] Mode Sense: 03 00 00 00
sd 8:0:0:2: [sdd] Assuming drive cache: write through
sdd: unknown partition table

i already know that fat32 has been on the card so i tried:
hexdump -C /dev/sdd | grep FAT32
00007650 20 20 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac | FAT32 ...w|.|
00008250 20 20 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac | FAT32 ...w|.|

but now i don't understand what i should do next because for:
dd if/dev/sdf bs=1 skip=$magicnumber of=/some/safe/place.img

i'm missing the magicnumber and i don' understand the posting.
anybody who can help?
thanks,

marexel

p.s.: i an working with the card, not with an image of it

elelab · 06-13-2011, 04:32 PM

Hi Deleriux

in my case, the hexdump output is FAT32. How to calculate the exact starting position in bytes?

hexdump -C /dev/sdc | grep FAT -m1
00400050 20 20 46 41 54 33 32 20 20 20 33 c9 8e d1 bc f4 | FAT32 3.....|

thanks