Flash Drive Recovery for CBM2091 Controller

by Nov 16, 2020

CBM2091 root translation table We recently completed a flash recovery case where the drive was not repairable, and a chip-off recovery was not, at first, successful. Once Clint had determined that the device was not physically repairable, it came to me to dump the memory chip to attempt a logical recovery.

The controller on the device was a Chipsbank CBM2091. The data is stored unscrambled and there are no transformations. It’s as simple as can be, but it unfortunately doesn’t use the common block number translation scheme, which is easier to deal with generally. It instead uses translation tables (two levels of table, actually) to keep track of the logical data blocks and what order they’re in. These tables are stored in their own blocks somewhere on the memory chip.

In this case, I read the dump and got a good read with only 12 KB of uncorrectable data. PC-3000 and Flash Extractor have translators for CBM2091, but both of them failed to assemble a logical image from the dump.

Raw recovery wasn’t a good option because the customer was looking for a non-standard file type that none of our raw recovery tools recognized. Some of the files spanned data block boundaries, so completely assembling all the files was virtually impossible. I made an attempt using PC-3000’s “virtual drive map” tool that can assemble a logical image using FAT32 metadata and known file format info found through raw recovery, but this was not very successful because of the unrecognized file type.

At this point it was either give up or decipher the translation scheme myself to determine why neither of the tools’ translators worked. So of course I decided to decipher the translation scheme. 🙂

We had a working CBM2091 device in our inventory, so I wrote a test pattern to it and dumped the memory chip. From this I was able to locate the translation tables and determine their format. This controller uses a “root table” that points to other tables that actually point to the logical data blocks. It turned out that the patient drive was missing this root table entirely. It looked like the block had been erased.

Armed with this new and important information, I was able to manually reconstruct the missing root table, allowing me to use standard recovery tools to assemble the logical image and completely recover the customer’s data.

In cases where thumb drive repair isn’t possible, advanced chip-off flash drive recovery like this is often necessary. Not all chip-off cases are quite this complex, but we dedicate considerable time and effort to studying these advanced cases to give clients (and ourselves) the best possible chance at a successful recovery.