Notifications
Clear all

FAT32 strangeness

20 Posts
7 Users
0 Likes
2,493 Views
Fab4
 Fab4
(@fab4)
Posts: 173
Estimable Member
Topic starter
 

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.

 
Posted : 13/10/2009 4:25 pm
(@mscotgrove)
Posts: 938
Prominent Member
 

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.

 
Posted : 13/10/2009 5:39 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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

 
Posted : 13/10/2009 6:14 pm
Fab4
 Fab4
(@fab4)
Posts: 173
Estimable Member
Topic starter
 

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

 
Posted : 13/10/2009 8:31 pm
(@mscotgrove)
Posts: 938
Prominent Member
 

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.

 
Posted : 13/10/2009 9:47 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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

 
Posted : 13/10/2009 11:05 pm
Wardy
(@wardy)
Posts: 149
Estimable Member
 

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.

 
Posted : 14/10/2009 12:49 am
Fab4
 Fab4
(@fab4)
Posts: 173
Estimable Member
Topic starter
 

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.

 
Posted : 14/10/2009 12:36 pm
Fab4
 Fab4
(@fab4)
Posts: 173
Estimable Member
Topic starter
 

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.

 
Posted : 15/10/2009 3:29 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Well, you won't find the data on the PQI site.
http//flashboot.ru/iflash.html

PQI Traveling PQI traveling i270 16 Gb 3538 0070 Alcor AU6983 AlcorMP(081208)

The used chip is Alcor
http//flashboot.ru/index.php?name=Files&op=cat&id=7

It seems like ther is not a page for the AU6983, there is one for AU6981 and one for 6984
http//www.alcormicro.com/content/c_product/product_02b.php?CategoryID=3&IndexID=2
http//www.alcormicro.com/content/c_product/product_02b.php?CategoryID=3&IndexID=3
It is probable that AU6983 is similar to the AU6984

jaclaz

 
Posted : 15/10/2009 8:01 pm
Page 1 / 2
Share: