Re: [gentoo-user] Corrupt USB pen drive

[Hans-Werner Hilse]

Hi,

On Fri, 18 May 2007 14:11:14 +0100 Mick <michaelkintzios@×××××.com>
wrote:

> > Did you try the recovery tools for the FS in question?
>
> I tried fsck.msdos but didn't fix it.

Doesn't make me wonder, as I'll explain below, there's no file system
starting at offset 0 in that image of your stick...

> Like most USB sticks I would assume that it is either FAT32 or
> FAT16.

I would have guessed that too. However: FAT file systems even carry
"FAT" as verbatim chars at the start of the partition... So it's quite
easy to spot the start of a FAT partition...

> Given that this is what I see when I dump the first few
> bytes, can you please tell me where the fs data starts and how to dd
> that without inc the initial partition table data?
> ==============================================
> 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa

I'll answer another question first: The asterisk indicates consecutive
lines w/ the same data. So here, we have a full block (512 bytes,
0x000-0x1ff) containing almost only zeros. It stops with a valid master
boot record magic number (0x55aa). This MBR doesn't contain anything,
so there's no partition table, either. It also might be a part of a FAT
file system's boot sector (the end-of-sector marker bytes).

> 000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> *
> 020000 [...]

OK, so from 0x00200-0x1ffff it contains only consecutive 0xff bytes,
i.e. (0x20000 / 0x200) = 0x100 = 256 (dec) blocks (à 0x200=512 bytes).
That's nearly 128 kBytes of 0xff. I wonder how it got there. I think
all this indicates that there might have been some tool which overwrote
the first 128k of this stick with some "default data" or similar. At
least, the first 128k are modified and can't work this way, since
there's neither a valid MBR, nor a valid partition table nor a valid
file system at offset 0.

What's following next? I think it might be the tail of a FAT16 (the FAT
itself). This means there is no boot sector anymore. The boot sector is
not redundant for FAT file systems, so it would have to be recreated.
The FAT itself, however, is usually present a second time (see
http://en.wikipedia.org/wiki/File_Allocation_Table for details). It
clearly looks like FAT, since this we have a end-of-file indication:

> 020000 01 df 02 df 03 df 04 df 05 df 06 df 07 df 08 df
> 020010 09 df 0a df 0b df 0c df 0d df 0e df 0f df 10 df
> 020020 11 df 12 df 13 df 14 df 15 df 16 df 17 df 18 df
> 020030 19 df 1a df 1b df 1c df 1d df 1e df 1f df 20 df
> 020040 21 df 22 df 23 df 24 df 25 df 26 df 27 df 28 df
> 020050 29 df 2a df 2b df 2c df ff ff 2e df 2f df 30 df
                                 -----
> 020060 31 df 32 df 33 df 34 df 35 df 36 df 37 df 38 df
> [...]

All the rest of data you've quoted doesn't mean a lot, I think it's all
from the FAT. I would suggest you find out whether there's a full copy
of the FAT intact after the data you quoted. Just search for some of
the byte sequences you quoted here and if you're lucky, there's an
intact FAT later on. After the FATs, there will most probably be the
directory table. You should be able to look up the file names there
verbatim.

OK, but how to continue? You probably need a new boot sector and a
clean FAT. You can manually create one, but it's a tedious process.
Look at the FAT documentation and try to figure out cluster size
(probably Stick size / 65536) and so on. OTOH, you can try to create a
new FAT16 fs on media with the same size as the stick (e.g. 
"dd if=/dev/zero") and then try to "implant" the backup copy of your
FAT (two times, once as new primary FAT, once as a secondary FAT) and
directory table and of course the data into that new FAT16.

Unfortunately, by default it seems that the backup copy of the FAT
itself for a 255744 sector Stick defaults to start at 0x1f600. So a
considerable amount even of the backup FAT would be destroyed if the
original layout resembles this geometry.

So at that point, there's not a lot you can do, aside from tools like
the mentioned Photorec and its commercial brothers, which can do a neat
job when you're back to heuristically determining start/stop of files
(which mustn't be too fragmented, of course) in a data stream.

-hwh
-- 
gentoo-user@g.o mailing list