Join Us!

Notifications
Clear all

FAT32 strangeness  

Page 1 / 2
  RSS
Fab4
 Fab4
(@fab4)
Active Member

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.

Quote
Posted : 13/10/2009 5:25 pm
mscotgrove
(@mscotgrove)
Senior 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.

ReplyQuote
Posted : 13/10/2009 6:39 pm
jaclaz
(@jaclaz)
Community Legend

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

ReplyQuote
Posted : 13/10/2009 7:14 pm
Fab4
 Fab4
(@fab4)
Active Member

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

ReplyQuote
Posted : 13/10/2009 9:31 pm
mscotgrove
(@mscotgrove)
Senior 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.

ReplyQuote
Posted : 13/10/2009 10:47 pm
jaclaz
(@jaclaz)
Community Legend

I see a logical flaw.

If it's not wear leveling, and probably it isn't in your case, due to the "q***r" 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

ReplyQuote
Posted : 14/10/2009 12:05 am
Wardy
(@wardy)
Active 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.

ReplyQuote
Posted : 14/10/2009 1:49 am
Fab4
 Fab4
(@fab4)
Active Member

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.

ReplyQuote
Posted : 14/10/2009 1:36 pm
Fab4
 Fab4
(@fab4)
Active Member

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.

ReplyQuote
Posted : 15/10/2009 4:29 pm
jaclaz
(@jaclaz)
Community Legend

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

ReplyQuote
Posted : 15/10/2009 9:01 pm
Fab4
 Fab4
(@fab4)
Active Member

Well, you won't find the data on the PQI site.

Wasn't expecting that to be taken as that the pqi corporate pages were going to be the extent of my research lol

Just another busy day with deadlines meaning that I didn't have any more time this morning than to simply post the detail that others had asked for.

Thanks for the pointer to the site. I don't think you've posted the closest entry, rather I think that this is it;

PQI U173 8 Gb 3538 0070 6986 – AlcorMP(081208)

So I think its the Alcor 6986 which is of interest.

AU6986

ReplyQuote
Posted : 15/10/2009 9:47 pm
jaclaz
(@jaclaz)
Community Legend

Whatever.
84 seems to me nearer to 83 than 86, but the good thing in opinions is that they are free, both as in freedom as in free beer. wink

Anyway all have "bad block management" (which may mean also some form of wear leveling) and ECC correction (whatever it is) and that may be part of the cause.

jaclaz

ReplyQuote
Posted : 15/10/2009 11:03 pm
thefuf
(@thefuf)
Active Member

Read these papers
http//www.dataio.com/pdf/NAND/MSystems/TrueFFS_Wear_Leveling_Mechanism.pdf
http//www.snia.org/events/storage-developer2009/presentations/thursday/NealChristiansen_ATA_TrimDeleteNotification_Windows7.pdf

Unfortunately, I didn't found a complete answer for the wear-leveling question.

ReplyQuote
Posted : 15/10/2009 11:19 pm
Fab4
 Fab4
(@fab4)
Active Member

84 seems to me nearer to 83 than 86

Let me explain - the CheckUdisk output I posted earlier was only an extract. You kindly sought out an entry for PQI Traveling PQI traveling i270 16 Gb with the correct Pid/Vid. I'm stating that the entry for PQI U173 8 Gb is a closer match to my usb drive model, also with correct Pid/Vid and that entry states Alcor 6986. I'm not attempting to convince you about any ill-formed maths!

I think we're agreeing that wear-leveling cannot be ruled out in this case and I need to investigate/test further.

ReplyQuote
Posted : 16/10/2009 4:46 am
jaclaz
(@jaclaz)
Community Legend

Sure ) ,
but you see, the problem is a bit different, from experience.

Unless you actually physically open the stick and read the chip #, any "theory" is good as the other.

For unknown reasons (though I do suspect some form of "compatibility" issues) sometimes a chip "declares" itself as "something else", to which you add that the makers of tools like USBdeview, CheckUdisk or ChiopGenius use NOT "official" data from the Manufacturers, but rather "databases" that, just like the one on the iflash.ru, are compiled by reports of users that can be incorrect, or just plainly wrong.

Even the available data from manufacturers is often partial, incorrect or plainly deceiving.

To give you just an example I have right now before me a USB microdrive that "declares itself" as being an OTi 2118 in ALL the utilities of the world, but that, once opened, reveals a chip marked OTi 2119.

Thus anything you can find is usually not really "evidence", but more like a "number of clues" or, if you prefer, "circumstantial evidence".

You could try analyzing the device through a write blocker, that may result in different behaviour. ?

jaclaz

ReplyQuote
Posted : 16/10/2009 4:18 pm
Page 1 / 2
Share: