I don't think wear leveling would give this symptom.
The manufacturer is PQI which I recall was mentioned in relation to wear-levelling in the thread you kindly referred me to. I will absolutely check it out with Chipgenius or other to establish whether wear-levelling is even a possibility. I have not researched wear-levelling before so this is a great heads up. Thanks.Īs 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. Please someone, put a confused soul out of his misery. The two bytes are identical to each other as they cycle. The 8 hex values change if you select a different sector to flick backwards and forwards from. The other byte offsets changed as follows īyte 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.īyte offset 5 - steps up 1 hex value whenever value in byte offset 4 passes FFīyte 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. Byte offsets 8-30 and 32 also remained static.īyte offset 20 is counting up 1 hex value per sector, remaining constant at 3E for the sector under scrutiny. 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). If however, I traversed upwards to the sector byte offsets 34-511 would be shown as 00h or FFh. If I traversed downwards to the sector from within the allocated sectors, the whole sector appeared complete with deleted data. Upon returning to the sector the data has changed. 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. Disk area allocated to volume boot was unusually large - 2,678 sectors.įAT1 and FAT2 present and happy - correctly referencing the total 1,925,760 clusters. (in itself not strange, just scene setting). No partition table therefore available although volume C present on device. I attatched it to my Tableau USB write blocker and loaded it into EnCase. 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
0 kommentar(er)
