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.
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
Read these papers
http//
http//
Unfortunately, I didn't found a complete answer for the wear-leveling question.
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.
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
Understood.
I examined the drive thru a Tableau T8 at the outset of all of this strangeness and the behaviour was as described.
Scott Moulton presented 'Solid Stated Drives Destroy Forensic & Data Recovery Jobs' at DefCon 16.
"Data on a Solid State Device is virtualized and the Physical Sector that you are asking for is not actually the sector it was 5 minutes ago. The data moves around using wear leveling schemes controlled by the drive using propriety methods. When you ask for Sector 125, its physical address block is converted to an LBA block and every 5 write cycles the data is moved to a new and empty previously erased block. This destroys metadata used in forensics & data recovery. File Slack Space disappears, you can no longer be sure that the exact physical sector you are recovering was in the same location or has not been moved or find out what it used to be!"
I shall watch it over the weekend, but I thought I'd post it's presence beforehand for others' interest.
Yep, but "sector exchange" is rather normal when a wear leveling algorithm is used interrnally, but the change affects whole blocks, not single bytes.
This is exactly what I initially overlooked and mscotgrove pointed out, and if the algorithm is what (or similar to what) Scott Moulton describes in the snippet you posted, the "triggering" is 5 (or a similar number of) writes.
If the writes are blocked, there should be no sector exchange or shift. ?
Have you tried imaging the stick with dd or a similar tool and work on the image?
Possibly making several images and comparing them as mscotgrove suggested.
It seems like it is the only way.
jaclaz
Standard VBR in logical sectors 0 and 6. Disk area allocated to volume boot was unusually large - 2,678 sectors.
What version of EnCase? (It probably doesn't matter, but late versions seem a bit bug-infested…)
You verified that the VBR is standard – you checked the code?
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.
Double-check your USB drivers before you do anything else. "USBC" appears in USB command block wrapping, so my first guess would be that you see command block data (SATA over USB). That may indicate a USB driver problem; it may also indicate a USB device problem. (Also check your system log for error or warning messages.)
Wear-levelling seems an unlikely explanation – the whole point of that is to ensure that writes are not concentrated to some particular blocks (as the FAT sectors of a FAT drive), which will wear them out before the rest of the drive. If the block changes because it has been written to, wear-levelling must be faulty.
However, it may be a side effect wear-levelling 'knows' about unallocated sectors in the file system, and I can easily imagine that a device that does wear-levelling may return any random garbage when it gets a request for a sector it knows to be undefined – i.e. it won't even try to make a real read, but it returns anything already in buffer memory. It won't harm anything in normal Windows – but it does go against the current assumption that most forensic programs come with namely, that data in unallocated sectors won't change between reads.
I find it somewhat unlikely to find wear-levelling on a standard USB stick, though, even if it is 16 GB (right?).
There are mentions on the net of finding "USBC" in data from USB drives, but those I have found all suggest some kind of device driver or hardware problem. Have you tried WinHex on another computer?
With some older memory sticks, typically <= 256MB I think the crystal would not always work. The memory could be brought into life with a 'damp' finger or similar. It might also cause the type of problem reported. Newer chips do not respond to this treatment
I remain convinced it is a dodgy chip rather than wear leveling, but it would be nice to find out for certain.
Thanks jaclaz - very interesting read.
So my main suspects appear to be;
1) Wear-levelling
2) Faulty disk/controller
3) A 'fake' Chinese USBJoy…..!
Testing for item 1 shall begin soon roll
Now, who in the lab is looking bored? wink
In addition to wear leveling, in SSD drives at least, there is also garbage collection going on where unused (from the disk controller point of view) sectors are being cleared for faster writes in the future. But even that does not explain some of the things you see. One thought is that there is a lot of extra information that is kept with each memory block, such as an error correction code, counts for wear leveling, etc. Is it that you are seeing these? The hardware is supposed to hide all this from you but maybe that is not happening.
