Need help old 256mb usb flash drive showing up 30mb corrupt

[MrAndersons]

I have a client who gave me his old 256mb generic thumb drive with corrupted docx files on it that he needs. The drive is 256mb and only showing up as 30mb. I can find the files but they are corrupted and will not open. The chipsets look good, but maybe I'm missing something as I don't have much experience with recovery other than logical and some soldering on these things. Any suggestions? I'm thinking its a corrupted file issue and he's out of luck. Here are some pics of the drive.

Attachments

[Vulcan]

The drive is 256mb and only showing up as 30mb.

Is the drive or the filesystem reporting its size as 30MB?

[italianrecovery]

It could be a problem of the controller..
You could try to unsold the NAND memory chip, read it and rebuild it's content.

If you don't know ho to do you could send it to a datarecovery company

[hddguy]

Usually for controller malfunctions the capacity shows size of '0' or otherwise shows the size of the cache, i.e 8MB.

If only 30MB is accessible, and this 30MB contains data (even corrupt data) then I would guess the controller is fine and you have problems with a specific bank/banks within the NAND.

Data would be corrupt because if the first 30MB is accessible then the FAT and Root are probably intact which could contain a list of files / folders regardless if the data belonging to them is present or not.

But without proper analysis nothing can be confirmed.

professional diagnostic should be considered here if data is required.

[MrAndersons]

http://www.lynx-india.com/index.php?productID=11664

What do you guys think of something like that? Or is it always better to find an identical flash drive and swap the nand chips? Like I said before I don't have much experience with flash drives, but would like to get my skills up. I use the DDI for hard drives, but flash drives are not supported with the DDI. What tool is the best for recovering flash drives?

Thanks for your help.

Attachments

Screenshot of the drive reading 30mb in FTK imager. The files are there, but most are corrupted.

[Vulcan]

@MrAndersons:
I won't spend much time on this reply, in case you've already decided on a different approach. However, here's something that looks relevant.

The drive is 256mb and only showing up as 30mb.

Although you didn't seem to give a direct reply to my earlier question about this, if you look at the partition table in your last post, you can see that this quickly leads to needing more clarification from the customer IMHO - your report suggesting that 30MB is wrong, seems to be incorrect. Therefore I wouldn't be spending time moving NAND chips - yet.

[MrAndersons]

@MrAndersons:
I won't spend much time on this reply, in case you've already decided on a different approach. However, here's something that looks relevant.

The drive is 256mb and only showing up as 30mb.

Although you didn't seem to give a direct reply to my earlier question about this, if you look at the partition table in your last post, you can see that this quickly leads to needing more clarification from the customer IMHO - your report suggesting that 30MB is wrong, seems to be incorrect. Therefore I wouldn't be spending time moving NAND chips - yet.

I'm not sure I understand what you mean. The drive is 256mb and the partition now only reads 30mb due to some sort of corruption. I'm not going to spend a ton of time on this since the information is not that valuable to him, but it's more or less for my own personal knowledge.

Thanks for replying

[Vulcan]

The drive is 256mb and the partition now only reads 30mb [my emphasis]

You hadn't said this clearly about the partition size before and yes, that's exactly what I was trying to lead you towards concluding - the (single) partition on that drive really is approx 30MB. Therefore when you said before that the drive was "only showing up as 30mb", this is actually expected, if the tool you are using is really showing the partition size (as FTK Imager is doing in your screenshot). Hint - IMHO that conclusion clearly identifies a piece of information previously given as "fact", which needs checking, as it appears to be inconsistent with the other information.

due to some sort of corruption.

I politely disagree. Look again at the whole of the (single) partition table entry. My back-of-an-envelope calculations show me that it is internally consistent (compare start & finish CHS addresses with partition size value, allowing for rounding to the last whole cylinder per normal fdisk convention). Therefore any "corruption" to that entry would have needed to change multiple bytes, in exactly the correct way for them to be consistent with each other! So, applying Occam's Razor, I conclude that corruption didn't happen to cause that current partition table entry .

I'm not going to spend a ton of time on this since the information is not that valuable to him

OK, understood. There are more checks that could be made to confirm my hypothesis about this situation, but I'll stop here too since this isn't important.

[MrAndersons]

Ok thanks, but you didn't answer any of my questions.

[Vulcan]

you didn't answer any of my questions.

Similarly, I didn't see you didn't actually answer my previous question - I decoded the partition table myself and answered my own question . IMHO asking questions on a free web forum is a two-way street; the original poster must answer questions they are asked - that is the "quid pro quo".

Instead of me guessing and giving answers which could be wrong, I have been trying to point you in (what I believe to be) the right direction (teach a man to fish and all that), because IMHO the new information from the partition table means your approach (especially the starting point of "I'm thinking its a corrupted file issue" and assumed partition table "corruption") is the wrong direction. Other readers here were misled by the original description as well, and therefore gave suggestions about the flash controller

If you don't think I've helped, then you don't understand the relevance of (a) the partition table entry, (b) your "it's only showing me 30MB on a 256MB stick" initial statement, and (c) the very limited range of possibilities of how that partition table entry was created - which IMHO do not include corruption as a cause (excluding partition table corruption was more help I've already given!). I could suggest much more with the USB stick in my hands, but obviously that won't happen.

As hddguy said, more diagnosis is needed. If this issue was more important, then there are further investigative steps that could be taken, which would need you to spend time supplying answers and performing tests etc. However one thing I've learned, over my decades of professional troubleshooting experience, is that if something is not important for the person who is asking me the questions (as you have recently stated), and certainly if they start to criticise me, then I can't allow the issue to become important to me - otherwise I just get frustrated when I ask for data, and don't get the necessary "engagement" from them.

Despite your criticism of my help, I'll give you one final comment - this answer is to your very general question of "Any suggestions?": Try different file carving software, from a disk image that you create. But since you haven't said which recovery software you've already tried, I don't know which alternatives to suggest! OK, I'm done here - good luck

[fzabkar]

@MrAndersons,

The partition table contains one partition whose data are as follows:

80 01 01 00 06 01 E0 FF 20 00 00 00 FF F7 00 00

0x80 = partition is bootable
01 01 00 = partition begins at head 1, sector 1, cylinder 0
0x06 = partition type is FAT16 ("BIGDOS")
01 E0 FF = partition ends at head 1, sector 32, cylinder 1023
20 00 00 00 = partition begins at LBA 0x20 (= LBA 32)
FF F7 00 00 = partition size is 0x0000F7FF sectors, ie 32,505,344 bytes

Clearly the reported capacity is reflected in the partition table, which tends to confirm that the corruption is purely logical.

That said, ISTM that there is a discrepancy between the reported partition size (0x0000F7FF) and that which is suggested by the starting and ending CHS values. If we assume that the [logical] number of heads is 2, then the calculated partition size would be ...

(1024 x 32 x 2) - (32) = 0xFFE0

If I were you, I would investigate the above error in the partition table before doing anything else. To this end, I would use your disc editor to search for the boot sector of the first partition. The first place to look would be LBA 32. I'd also examine LBA 63. If you could upload a hex dump of the boot sector, then we could compare its volume information against the information in the partition table.

My instinct tells me that the CHS geometry for your drive is being detected as 2 heads, 32 sectors per track, and 1024 cylinders. If so, then ISTM that 16 heads would be more appropriate for a 256MB capacity. I wonder if your client used Microsoft's FIXMBR on this drive.

References:

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

An Examination of the Standard MBR [Embedded in Microsoft's FDISK Programs
from DOS 3.30 through Window 95 (A):
http://mirror.href.com/thestarman/asm/mbr/STDMBR.htm

A Guide To Interpreting Partition Tables (PTGUIDE.TXT):
http://mirror.href.com/thestarman/asm/mbr/Mbrdemo.zip

[Vulcan]

Hi Franc,

My instinct tells me that the CHS geometry for your drive is being detected as 2 heads, 32 sectors per track, and 1024 cylinders.

FYI, yes, that was my analysis.

[MrAndersons]

Great now we're getting somewhere. It was not my intention to criticize you, the recovery is probably more important to me then to him so I can learn from it. The software I use are getdataback , rstudio, and ftk imager.

The client stated the drive read 256mb in windows and now only reads 30mb. So i'm assuming that the partition used to read the full size of the drive.

[networks]

Have you created a dd image with ftk imager of the entire USB Stick ? what is the size of the image file ? If not you need to do that now just in case the nand chip is indeed failing. Then you can make a copy of the image file and make changes to the partition table to re-align the data in an effort to recover the file(s).

[MrAndersons]

Yes I have created a dd image of the disk and the size is 32,521,728 bytes
I am going to attempt to edit the partition table, which is where my experience falls short. What tool do you recommend for doing that? HxD hex editor maybe?

[fzabkar]

HxD is a good editing tool, but your brain needs to provide the input.

The fact that there is an inconsistency in the data structure of the partition table means that whichever tool created it is not to be trusted. Instead I suggest that we reconstruct the table ourselves, using the volume data in the boot sector.

To this end, could we see the contents of sectors 32 and 63?

[MrAndersons]

Sure, here is sector 32 and 63 in disk explorer.

Attachments

Last edited by MrAndersons on June 26th, 2011, 19:18, edited 2 times in total.

[MrAndersons]

disk explorer

[fzabkar]

Sectors 32 and 63 are not MBRs. Therefore it makes absolutely no sense to interpret them as such. Hence the nonsense.

Once again, please upload the hexadecimal contents of each sector, ie something similar to your previous upload:
download/file.php?id=3780&mode=view

We do not want to see any interpretations of the data. We want the RAW data.

[MrAndersons]

sorry

Attachments