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.
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.
It's most probably one of those controllers with embedded wear leveling techniques, the topic was discussed a bit here
http//www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=3542&postdays=0&postorder=asc&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 roll
Now, who in the lab is looking bored? wink
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. 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.
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.
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
Thanks for your additional thoughts. I have not researched wear-levelling before so this is a great heads up. I will absolutely check it out with Chipgenius or other to establish whether wear-levelling is even a possibility. The manufacturer is PQI which I recall was mentioned in relation to wear-levelling in the thread you kindly referred me to.
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 don't know enough about the subject yet to accept this as read but it will most certainly be borne in mind as something for verification during my own research - thanks.
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.
As stated above, it's definitely a PQI. When I back in the lab tomorrow I will post the model number. Perhaps you would kindly post a summary of your findings when you get around to it.
Thanks guys.
Right then;
pqi Traveling Disk U172P
Extract of CheckUdisk output;
VID&PID Vid_3538&Pid_0070
Speed high speed
VendorID Generic
ProductID USB Flash Disk
Product Revision 8.07
Vendor Description PQI
Product Description USB Flash drive
Wear-leveling is definitely a technology pqi deploy on some 2.5" drives but I cannot see it noted in relation to USB drives in their corporate blurb.
Well, you won't find the data on the PQI site.
http//
PQI Traveling PQI traveling i270 16 Gb 3538 0070 Alcor AU6983 AlcorMP(081208)
The used chip is Alcor
http//
It seems like ther is not a page for the AU6983, there is one for AU6981 and one for 6984
http//
http//
It is probable that AU6983 is similar to the AU6984
jaclaz