Hello Laszlo,

there is indeed a step I haven’t detailed enough on my blog post. Sorry for that.

In my article, I was simply stripping off the OOB data because by looking at the dump, it was easy to tell that the file system was UBIFS. The particularity of that filesystem is that it does not rely on OOB for the Flash Translation Layer (FTL) and this is why I had no use of it.

NAND flash memory technology implies that you can only write by turning bits from 1 to 0. When you want to do the opposite, you have to request an erase operation. Unfortunately, that operation can only happen at a page level. Therefore when you are simply changing a small amount of information, it’s more efficient to duplicate the page to an empty one with the byte changed rather than reading the page, erasing it and then writing it back with the changes. Also, just like your cellphone battery with slowly age over time, a flash memory page can only sustain a certain amount of erase cycles before degrading. In order to optimize the life-span of a NAND flash, people started using Flash Translation Layer: the OOB area is leveraged to store metadata such as error correction code (ECC), whether or not the page is “deleted” and also the index of the page in the filesystem.

Once you’ve understood the FTL (which is implementation specific), you are able to filter out the “deleted” or “invalid” pages and re-order the flash pages in a linear order. At that moment you can remove the OOB data and you end up having a file that is the equivalent of a disk image. Depending of the filesystem being used, you may be able to mount it on Linux without having to create a virtual flash chip.

I hope this clarifies a bit the steps required to handle NAND flash dumps.

If I manage to find a good (and simple enough) example, I may write a more detailed article about going from the chip to a mountable disk image when you have to deal with an FTL. But I have no idea when this will happen as I already have some other articles waiting.