±Forensic Focus Partners

Become an advertising partner

±Your Account


Forgotten password/username?

Site Members:

New Today: 0 Overall: 36604
New Yesterday: 0 Visitors: 144

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

FAT32 strangeness

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page 1, 2, 3  Next 

Senior Member

FAT32 strangeness

Post Posted: Oct 13, 09 16:25

Bear with me...

I had a strange (to me) FAT32 USB pen drive land on my desk late yesterday and I'm betting that it's one of those circumstances that has passed me by, which has a straighforward explanation that will have countless numbers of you diving for your keyboards to educate me (it was a long day) Wink

I attatched it to my Tableau USB write blocker and loaded it into EnCase.

No MBR in physical sector 0. No partition table therefore available although volume C present on device. (in itself not strange, just scene setting).
Standard VBR in logical sectors 0 and 6. Disk area allocated to volume boot was unusually large - 2,678 sectors.
FAT1 and FAT2 present and happy - correctly referencing the total 1,925,760 clusters.
Cluster = 8 sectors and 512B per sector.

When using EnCase's Disk View & hex in the View Pane it came to my attention that data within sectors in unallocated clusters was not remaining *static* - what I mean by this is I would navigate to a particular sector and view its data in hex, before navigating away to another sector. Upon returning to the sector the data has changed. If I traversed downwards to the sector from within the allocated sectors, the whole sector appeared complete with deleted data. If however, I traversed upwards to the sector byte offsets 34-511 would be shown as 00h or FFh.

Of the first 34 bytes (0-33), most remained the same regardless from which direction I returned to the sector (I actually can't believe I'm typing this...) - bytes 0-3 remained as 55 53 42 43 (USBC). Byte offsets 8-30 and 32 also remained static.

Byte offset 20 is counting up 1 hex value per sector, remaining constant at 3E for the sector under scrutiny.

The other byte offsets changed as follows;

Byte offset 4 - steps up in alternate hex values (say 37-39-3B-etc) but sometimes only steps up by 1 hex value and sometimes 3.

Byte offset 5 - steps up 1 hex value whenever value in byte offset 4 passes FF

Byte offset 6 - random hex character

Byte offset 7 - either 88h or 89h

Byte offsets 31 and 33 seemingly rotates at random around 8 different hex characters, which are the same when flicking backwards and forwards from another constant sector. The 8 hex values change if you select a different sector to flick backwards and forwards from. The two bytes are identical to each other as they cycle.

I verified these findings with WinHex.

Please someone, put a confused soul out of his misery. Thanks.  

Senior Member

Re: FAT32 strangeness

Post Posted: Oct 13, 09 17:39

I came across a similar memory chip. I doubt you are doing anything wrong, it is the memory stick.

I ended up reading/imaging it several times, each with different results. It took a lot of tolerant reading, and the odd manual byte change to recover a reasonable number of files.

I doubt there is a simple hardware fix, so you just have to recover what you can.

There are companies who will take memory sticks apart, I have no experience of such jobs and do not know what the success rate, but you could investigate.

Forget about hashing, it won't be repeatable.
Michael Cotgrove

Senior Member

Re: FAT32 strangeness

Post Posted: Oct 13, 09 18:14

It's most probably one of those controllers with embedded wear leveling techniques, the topic was discussed a bit here:


Senior Member

Re: FAT32 strangeness

Post Posted: Oct 13, 09 20:31

Thanks jaclaz - very interesting read.

So my main suspects appear to be;

1) Wear-levelling
2) Faulty disk/controller
3) A 'fake' Chinese USB


Testing for item 1 shall begin soon Rolling Eyes
Now, who in the lab is looking bored? Wink  

Senior Member

Re: FAT32 strangeness

Post Posted: Oct 13, 09 21:47

I don't think wear leveling would give this symptom. It might point you to an incorrect sector, but not different data in the correct sector.

I think item 2 or 3 on your list above.  

Senior Member

Re: FAT32 strangeness

Post Posted: Oct 13, 09 23:05

I see a logical flaw.

If it's not wear leveling, and probably it isn't in your case, due to the "queer" behaviour you report, it cannot also be #3, the "fake" Chinese can be (besides reporting a "fake capacity") be either:
a. fully working
b. defective

If #a., it's NOT #2 and won't give you those symptoms
If #b., it's simply defective, being Chinese and fake has no relevance, and it's #2

So, I would re-list as:
1) Wear-levelling
2) Faulty disk/controller (regardless of nationality, race, religion, etc. Wink )

As said in the other thread, post the Vid/Pid of the device and/or check it with Chipgenius or CheckUdisk, from the actual Controller Maker/Part Number it is maybe possible to completely exclude the wear-leveling hypothesis.


Senior Member

Re: FAT32 strangeness

Post Posted: Oct 14, 09 00:49

Can I have the make of the USB key and possibly model number? I'd like to purchase one and conduct some studies into this reported behaviour.  

Page 1 of 3
Page 1, 2, 3  Next