Reverse Engineering A NAND Flash Device Management Algorithm

unsoldered flash chip

Put your hand under you chin as here comes a 6 months long jaw-dropping reverse engineering work: getting the data back from a (not so) broken SD card. As you can guess from the picture above, [Joshua]’s first step was to desolder the card’s Flash chip as the tear-down revealed that only the integrated SD-to-NAND Flash controller was damaged. The flash was then soldered on a breadboard so it could be connected to a Digilent Nexys-2 FPGA board. [Joshua] managed to find a similar Flash datasheet, checked that his wire-made bus was reliable and generated two 12GiB dump files on his computer.

In order to extract meaningful data from the dumps he first had to understand how SD-to-NAND controllers work. In his great write-up he provides us with a background of the Flash technology, so our readers can better understand the challenges we face with today’s chips. As flash memories integrate more storage space while keeping the same size, they become less reliable and have nifty problems that should be taken care of. Controllers therefore have to perform data whitening (so neighboring blocks of data don’t have similar content), spread data writes uniformly around the flash (so physical blocks have the same life expectancy) and finally support error correcting codes (so damaged bits can still be recovered). We’ll let our users imagine how complex reverse engineering the implementation of such techniques is when you don’t know anything about the controller. [Joshua] therefore had to do a lot of research, perform a lot of statistical analysis on the data he extracted and when nothing else was possible, use bruteforce…

18 thoughts on “Reverse Engineering A NAND Flash Device Management Algorithm

  1. I guess my first question would be why not swap the NAND to an identical donor card from eBay? If the card was damaged, but the NAND was okay, it would have been a 10 minute or less job to remove the flash, disassemble the donor card, remove it’s NAND, and swap ’em. Don’t get me wrong, reverse engineering of this level is impressive, but when a light bulb burns out, I replace it, not torch the bulb glass, remove the neck, crimp in a new filament, reseal the bulb, and evacuate the air.

        1. I never lose priceless content these days. I run Linux. I also back up data I wish to keep too. Although you’d be surprised how unimportant that really is being as I run Linux. Tux doesn’t lose data, or even abuse hardware to the point where it fails in my experience. My experience goes back to 1995 too. As does some of my data. heh

          1. That’s why I still use Ext3 with full journaling. Never lost a file due to a power cut, nor did I experience data trashing by a controller (as tends to happen with ntfs and reiserfs)

          2. Don’t get too cocky. Linux can loose data, for all sorts of reasons. For one thing, journaling doesn’t protect you from data loss due to a power cut. It protects you from data loss due to filesystem corruption due to a power cut. There are still opportunities to loose data that was written to the FS, but not yet flushed to disk.

            And keep in mind, this was an SD card. A lot of devices that use SD cards don’t really offer backup options, like most cameras, for example.

    1. he tried this but it did not work. see https://news.ycombinator.com/item?id=8133450

      jwise0 1 day ago | link

      Ha, yes, good point :-) I didn’t write about that, but I did take some pictures of failed attempts at that.

      That’s one of the first things I did, actually. After dumping the contents of the flash off, I went on Amazon and hit ‘reorder’ on the same SD card that I’d bought before. Unfortunately, it was not the same: in the picture [1], the left is the one I’d purchased this time, and the right is the one I’d destroyed. The deals that low-cost SD card makers get on NAND flash vary greatly from day to day, so they just manufacture based on whatever controller and flash combination they can get cheapest on any given day: even the same SKU is unlikely to stay the same internally very long.

      I did also try soldering to the BGA pads on the damaged one [2] [3], but no joy: I imagine that there were some traces that went backwards on the board before going towards the controller (for instance, to meet the TSOP leads), and on inserting the SD card into my laptop, I still had no signs of life.

    2. in the reddit post of this he answered that question, he tried finding a replacement but the few he bought even though identical on the outside were very different on the inside, preventing him from doing it.

    3. Because the management controllers have their own firmware that can vary from device to device, and blindly re-soldering the flash chip to something that looks the same is a good way to irreparably destroy his data, dipshit.

  2. Minor nitpick – that’s not why data whitening is done. Whitening makes the distribution of 0/1 bits look like white noise, so you don’t get large blocks of zeros or ones, which can have undesirable side effects at the electrical level.

Leave a Reply to bremenplCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.