±Forensic Focus Partners
±Your Account

![]() |
![]() |
![]() |
![]() |
±Latest Articles
±Latest Videos
±Latest Jobs
Back to top
Skip to content
Skip to menu
Back to top
Back to main
Skip to menu
FAT32 strangeness
Page 1, 2, 3 Next-
Fab4 - Senior Member
FAT32 strangeness
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 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.
-
mscotgrove - Senior Member
Re: FAT32 strangeness
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
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
-
jaclaz - Senior Member
Re: FAT32 strangeness
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
www.forensicfocus.com/...sc&start=0
jaclaz
-
Fab4 - Senior Member
Re: FAT32 strangeness
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?
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?

-
mscotgrove - Senior Member
Re: FAT32 strangeness
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 think item 2 or 3 on your list above.
-
jaclaz - Senior Member
Re: FAT32 strangeness
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
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
-
Wardy - Senior Member
Re: FAT32 strangeness
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.