Hello guys!
Sometimes, Data Recovery Lab may get a USB Flash drive with a no name controller inside in the COB (chip-on-board) package. Usually such controllers are extremely cheap, and you can find them inside “10 bucks” drives from Amazon / Alibaba or inside souvenir USB Flash sticks.
Anyway, people don’t care about the internal component quality: a Flash stick is a Flash stick that needs to be used! And if we have it, why don’t we put the most important and regularly used data on it?! Without a backup of course!
Here is the story of a tiny drive brought in by a friend of our TS engineer.
COB (Chip on Board) – is a package-less technology of chip manufacturing. Such chips don’t have any plastic cover, or readable marking – just a chip crystal soldered on the main board and fully covered with resin.
8-bit Game Cartridge with COB crystals
Such COB chips are extremely popular in low-cost electronic devices, like toys, keyboards, video games cartridges, and of course – USB Flash sticks.
If we talk about the NAND Flash controllers, there were a few manufacturers who produce low-cost controllers in a COB package: Alcor Micro and Chipsbank. So in theory, if during your data recovery practiсe you will meet one – it should be AU or CBM. At least our experience tells us that it’s mostly a rule, then an exception.
So, back to our story. A friend of our ACE Lab TS engineer asked to check his old flash stick without a marking. The current stick was used in a small shop for storing some accounting and promotional materials. And of course – as always in our life, there was no any backup of the original files.
After disassembling of this no name stick (we even didn’t know the real capacity), we found a COB controller inside:
Sometimes, the PCB of such Unknown sticks may contain some information about the controller name, but this guy had nothing. Also, using the Chip Genius free software, it is possible to detect the controller name by a direct connection of the USB stick to your PC. But in our case, the controller was absolutely dead and was not detectable at all.
Here is another example, where the PCB at least contains some marking. AU – means Alcor Micro. There was AU6989 inside… 🙂
On the back of the PCB we saw a TSOP-48W (Wide) memory chip produced by Samsung.
For reading this wide chip, we need to use a special TSOP-48W adapter, because the classic TSOP-48 has plastic fix borders that don’t allow us to fit a larger chip inside:
So, as an option, you can use the TSOP-48W adapter or make some modifications with your current adapter on your own risk (like we did ;))
So, after the task creation we need to read the dump from this TSOP-48W Samsung chip:
As we can see, it’s an old MLC 0xECD71476 – 54C20000 NAND memory chip with 4GB capacity. Continue reading:
After we read the NAND dump, it’s better to check the bad bytes inside. Low-quality Flash sticks usually have a lot of them inside:
After the BAD Bytes cutting, we can try to detect ECC type here:
We found ECC codes and now – it’s time to fix all bit errors inside the dump. The ECC type here is 1085 x8. The good thing here is MLC memory. The quality of this chip is good enough to skip the rereading procedure at all – all errors have been fixed via Error Correction Codes. An amazing result for such an old MLC memory!
The next step is data decryption. We were not able to find any readable file headers inside this dump, so the XOR operation is required here.
But how do we know which XOR to use here? As you remember, I already mentioned that COB controllers are usually based on AU or CBM technology. At the same time, ECC 1085 x8 is not typical for AU and more typical for ChipsBank controllers. In the list of static XORs there was no any compatible pattern, but in Dynamic XOR list – we got one which fully fits:
After XOR, Page Transformation will be automatically selected. Now, we can try to find some data in RAW Recovery:
Finally, we need to assemble the image. RAW data is ok, but Partition Structure is always better 🙂
As we found out, the current controller is a sort of ChipsBank CBM209x with dynamic XOR. The CBM controller family doesn’t have any markers inside – only translator tables that allow the controller to sort blocks together in a correct sequence.
That’s why if we want to get a folder structure, we have to use just a single option – Translator Algorithm for CBM209x controllers:
Unfortunately, it’s not all here, because the CBM209x Translator Algorithm will require some additional steps of Bank sorting inside the build image. Otherwise, the File Structure will not be available to us:
When you follow the Manual alignment banks for CBM209x controller, a Banks table will appear. It is necessary to press on Find first Bank to detect the bank with MBR record:
When the correct Bank is found, we should move it to the beginning of the image:
Now, we are fully ready for translator assembling. The final image will be available for data saving:
Final thoughts: CBM controllers are tricky. Sometimes you can find them inside the COB (Chip on Board) package with no marker inside. Such controllers are typical for cheap Chinese USB Flash drives that you can buy in Internet marketplaces.
The only way to get the File Structure – use the translator algorithm, because ChipsBank controllers don’t use Block Number marker inside SA. Only translator tables.
And of course – please, feel free to ask ACE Lab TS in case of any troubles!
Hi,
Can i have this dump for practice in pc 3000 flash ?
Unfortunately, it was the real task with the real customer data. We can’t share it.