My mother recently returned home from her trip to Hong Kong with a pair of ‘novelty’ “”16Gb”” USB keys as a present. They cost about AU$12 each, which is in the ballpark of what a reputable USB memory stick would cost – and the dealers (of course) were very reassuring of their quality.
Seasoned veterans of buying flash memory would know that it’s a big risk to buy flash from eBay and from the streets of Hong Kong and China. Fakes proliferate the market – and by fakes, these can be one of several sorts – ones that look like genuine products with boxes, holograms, and printing and are functionally similar, and ones that really aren’t functionally as described (i.e. they are smaller than their stated size but have their controllers reprogrammed to appear larger).
Either product is dangerous – the former due to the fact that the functionally similar products tend to fail quicker and corrupt data – and the latter due to the fact the data was never stored in the first place.
But there are more dangers to these devices …
Lets look at one of the USB devices – as both were purchased from the same place in Golden Computer Centre and they feature “identical” looking memory.
I was told by my mother that the vendor asked her about the capacity, and then stuffed a given “device” into the outer shell. This does ring some alarm bells – on the one hand, they might be legitimately putting in the right capacity – or on the other hand, they’ve just shoving in low quality memory.
Extracting the core of the device requires a firm grip, no adhesive was used in the construction of the device. It reveals the metal “shell” of the USB plug extending all over the main PCB with two “tongues” at the end holding the PCB in.
Bending the tongues back, the whole core PCB slides out with a slight push from the connector end.
We can see the Chipsbank CBM2096 controller with a crystal wrapped in heatshrink just beside it. Other than that, it’s quite unremarkable from the top. It’s not a controller that I’m familiar with, but a quick glance of the datasheet tells me it is supposedly fast and supports a very wide range of flash memory based on software reconfiguration.
The rear of the USB key has unmarked flash. It doesn’t look like it would be quality stuff by the looks of it – but I find it highly unlikely that the 16Gb (i.e. 128Gbit) would be in one package – only the best manufacturers have managed to get to 128Gbit with the use of TLC technology, and almost certainly, it should bear their markings. This is the sign of a fake flash key, or at least a low quality one.
Plugging it in
Upon plugging it in, it was already trouble. This is another danger of USB keys from China/Hong Kong – the addition of “free” autorun viruses …
Interestingly, thanks to Windows 7 and the “default” disabled Autorun, this isn’t effective on patched modern Windows machines (and all other OSes). The autorun.inf seems to have a really primitive polymorphic structure (through the use of random case and random comments …)
But it’s definitely a virus. In this case, it’s a dangerous virus by the name of Sality – VirusTotal confirms it:
A right click format banishes the virus, only to bring up another inconsistency – one of the keys will work when cold-plugged, but once unplugged, must be left to sit for a while before it can be plugged in and detected properly. If it is plugged in immediately, it appears as an 8Mb flash disk and refuses format.
While it does format – strange things start happening one the key is filled. The files will appear to exist, but their contents are damaged.
Salvaging it without Manufacturer Tools
While these keys are cheap, and the simplest thing would be to throw them out – I didn’t want to waste them. There are tools you can “buy” that will work it all out for you, but I wanted to deal with it myself, and all you really need is to directly edit the disk.
A closer examination shows that for one of the drives, accesses past a given address return 0x00, whereas the other returns 0xFF. But how can we find the end address? Get out a hex editor and do a pattern fill – in this case 0xBAADF00D and see where the pattern runs out!
Here, we can see the data is fine between sectors 0-8138751, and fails at 8138752. We can use this information to partition the key so that only the first 8138751 sectors are used.
The first thing you need to do is format the key with a proper MBR. By default, Windows will format the key as a “superfloppy” (or VFAT) configuration where there is no partition table at all – like the following:
In order to format it with an MBR, you can use Linux or you can use the SDFormatter tool which changes the layout to the following:
We can see that the first partition starts at Sector 8192, meaning that 8192 sectors are already used (by the MBR/Partition Table, and the slack space left by SDFormatter to ensure “block/page” alignment). This leaves us 8130559 sectors remaining – so we have to consult the MBR format and replace the number of LBA (little endian) in the partition table with this value.
Afterwards, remove and re-insert the key and we’ll find it appears as a smaller drive, and I have created a file to pattern fill all the sectors and verify the pattern – it’s worked!
Interestingly, it seems I may have been slightly off with my arithmetic – I filled the file with 0xAA55 pattern, but some of the 0xBAADF00D pattern is still left (8 sectors). That’s a little conservative but it’s not a problem – we’ve lost 4kB off the end.
In general, this approach should work with all USB keys even if you don’t know the controller. It doesn’t help once someone does a full format on it which restores the reported size by the USB key (i.e. the fake size).
Unfortunately, that doesn’t solve the fact that the key is cheap, nasty and likely to be unreliable in the long run. Once flash wears out and the wear levelling (if any) takes place, it may try to swap in non-existent blocks and thus ruin stored data within the “real flash” boundaries. But it’s better than having nothing …
Doing it Properly with the Manufacturers Tools
If you know what chipset is in your “fake” key, like I do, you can go searching for a manufacturers tool for it. This does involve cracking the device open, or possibly just searching the Vendor ID and Product ID on the internet (if they haven’t been customized). These executables normally run on Windows machines and are used at the factory to program the type of flash, the mode of the USB key (U3, standard, read-only), the Vendor ID and Product ID and description strings, etc.
It can actually be quite handy – I’ve come across a Phison manufacturer’s tool for Phison chipsets which is quite handy for customizing the vendor ID/product ID and description, as well as enabling U3 with a custom ISO (say, a Windows Install CD) to make a “virtual” USB CD-ROM on a key.
It seems that Chipsbank has their own UMPTool which can be found (with a lot of digging - ultimately a Chinese website had it, although it needed to be “unpacked” as it had some additional things packaged into the exe) online – although with different versions for different chipsets.
You must run it as Administrator to get it to work because it needs to talk to devices directly. One of the components is not workable under x64 versions of Windows as it appears to be a 16 bit program – you can ignore that.
Interestingly it seems to report that the flash is a recognized Micron flash chip – which wouldn’t be a bad chip, recognized as an Micron MT29F64G08CBAAA-8192M device … with 4002Mb space.
Under MP Settings, with a blank password, I customized the settings a bit (Vendor ID,- I like my USB keys to bear my name on the actual device itself :). Unfortunately, most of the settings aren’t documented (e.g. Scan Number? ECC number – bits? Stability Priority?) And then I hit Start All …
And now it’s off and running. It seems to take a while, flash sorting several times over …
… and then Scanning, again, several times over …
… and then it takes a sec to format …
… and we’re done.
Lets take a quick look at the log to see what happened …
Start date/time: 2013-05-08 21:17:19. 00(M) Cap:4002M(2096,2095),3860M(3085),[5.88M/S],Time:0:19:56,2C88044B[MICRON_MT29F64G08CBAAA-8192M],SN:CCBB1305082117190769312600
I’m not quite sure what the numbers mean – but I suppose it means that it’s 4002Mb of “usable storage”. The key shows up as the “right” size, meaning that even a full format will be fine as it reports the correct capacity. It operates properly – this time with the controller being programmed “back” to what the proper size is, and nicely, it’s slightly larger than what the previous method ended up with (possibly due to formatting differences and the ability to test the flash to see what is really good and what is really bad).
I wonder if we disabled Stability Priority and chose Maximum Size instead, whether we could get 8Gb … *strokes chin* … One thing it didn’t solve was the tendency for one of the two keys to recognize as 8Mb (which, I suppose, is what happens when it can’t initialize the flash – so maybe it’s a timing or solder joint issue).
There may be some tweaks you can apply in UMPTool to improve the performance by changing the timing of the flash, but it’s unlikely to make things too much better before possibly making corruption more likely.
The drive was first filled with random data before beginning these tests as some drives return anomalously high read numbers for all 0x00-filled, or all 0xFF filled.
HDTunePro 4.60 Read
Looks a little better than I expected especially on the sequential reads, but otherwise, an unremarkable result.
Fake USB keys and flash memory from Hong Kong and China can be trouble. Viruses, fake capacities cause trouble, and the reliability of these are questionable. Of course, if you have a choice, don’t buy them. But if they do land in your hands, all is not lost. With the right techniques, the drives may be recoverable to the point of actually being usable for a casual “transfer” here and there.