PC-3000 Flash. How to Recover Data from NAND Flash Drives with the Newest AU89102DF Controller

The PC-3000 Flash supports the biggest variety of damaged NAND Flash controllers from different manufacturers, including one of the oldest – Alcor Micro. For the last 15 years, this company has developed a huge number of different modifications of USB Stick CPUs. It had started the business from simple but very popular AU6980 and now it has conquered the entire market of Flash USB drives with its famous AU6989/AU6998 family.

Not that long ago Alcor Micro released a new controller with extremely complex internal data scrambling – AU89102DF. It becomes more and more popular, especially in the segment of USB Flash drives with a very high capacity (128 GB and above). The PC-3000 Flash is keeping up with the controllers’ manufacturers, so the latest software update allows you to recover data from the storage media based on this new controller! Read the article below, to learn more about how to do it.

The picture is provided by http://flashspeicher.net/

As you remember from our article about the AU6989 controller, modern AU controllers have a pretty complex internal structure.

1. There are several modifications of AU6989/AU6998, and some of them might use a XOR data scrambling or might not use it at all (which is uncommon for modern Flash CPU);
2. If AU6989/AU6998  uses XOR and has BadBytes, this BB also becomes XORed, and as a result, the Bad Columns look very strange and smooth! It’s very hard to detect them (but not that HARD if you already have at least the PC-3000 Flash Ver. 7.2.9 from 2018 )
3. In the case of XOR scrambling, we have to use two different XORs – one for ECC, and another one for data or image building. That’s why XORs always go in pairs for AUxxx controllers;
4. Finally, it’s very hard to build an image, because AU controllers use add-on subblocks for the File System description. If we use a common Block Number Type 1 [0000], we have to forget about a good File System in most cases. (But there is still an option!).

But that’s not all. The XORs for AU controllers used to be pretty tough, but it was possible to calculate their values and add them into the PC-3000 Flash database fast. A few months ago, the new modification of AU89102DF (AU87xxx/89xxx Family) brought new difficulties:

1. A HUUUGE XOR key, which includes unique data for every single block inside the memory;
2. Full support of TLC 3D NAND and QLC memory, which brings large values of Page and Block size inside the NAND;
3. Full support of USB 3.x interface;

This AU89102DF controller is usually installed in a high capacity USB stick. Such drives might have just two NAND chips, but the total capacity of them might get up to 1 TB!

That’s why we must be ready for long rereading operations and a huge number of ECC errors along with the dumps when we deal with new Flash drives based on the TLC 3D NAND or QLC memory.

Today one of our examples is the AU89102DF which is based on two physical TLC 0x2CC41832 chips with 4 parts each:

2×4 2CC41832 A2000000, part size=65536Mb, page size=18656 bytes, block size=5184 pages:

The total capacity is 512GB. It’s not the largest USB drive in our practice, but definitely – one of the most compact – just two chips from each side of the PCB and that’s all.

Look at the Block Size in this memory – 5184 pages! We can only imagine how large the Block and Page sizes inside the future NANDs are going to get in a few years…

So, let’s add a transformation graph and choose one of the existing XORs:

Here we got two XORs – one for ECC, and another for DATA decryption. Let’s choose ID=2715 for ECC. After that, it will be possible to launch the ECC correction on the XOR result:

When the ECC correction is over, we have to make a rereading. For time-saving on the AU case, we recommend you to use a REREAD MAP GENERATOR:

When Rereading is done and our dumps are in a perfect condition, we can change the XOR from ID=2715 to ID=2717 (AU8910 for DATA) and perform the Interleave and joining by pages:
Finally, we can launch RAW recovery and look for files:

Unfortunately, without a good Translator Assembling, complete image with FileSystem is impossible, but we are planning to find out how the original translator tables work and add assembling algorithm in future updates.

For now, if all FS files are located inside the RAW, you can try to assemble the image using our new Image Based on File System assembling algorithm.

More XORs for AU8910 will soon be made available! Please don’t forget to update your Resources Database weekly! 

If you have any questions regarding your data recovery cases,  you’re welcome to address them to the Technical Support department.