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)

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.  

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
www.cnwrecovery.com
www.goprorecovery.co.uk 

It's most probably one of those controllers with embedded wear leveling techniques, the topic was discussed a bit here:
www.forensicfocus.com/...sc&start=0


jaclaz  

Thanks jaclaz - very interesting read.

So my main suspects appear to be;

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

Joy.....!

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

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.  

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. )

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.


jaclaz  

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.