4 ms·

I've done this kind of "NAND mirroring" technique before but in the context of SSD failure analysis and debugging. We built a special board that would dump the

by pkaye 11y ago

I've done this kind of "NAND mirroring" technique before but in the context of SSD failure analysis and debugging. We built a special board that would dump the contents of the NAND to a file and restore it. That way we could be free to do failure analysis without losing our only evidence. And the effort to build this infrastructure was not difficult at all and paid back in the first use.

rsync 11y ago
I would love to see pictures of the testing / analysis rig, etc. That would be very interesting.
- pkaye 11y ago
  Its from a company I no longer work at. Not much really to it. The hardest part is connecting to the NAND. We had special debug connections provisioned to make it easy. Other options include desolder the part and putting into a socket, using a interposer, using boundary scan. Then we had a FPGA board that connected to the NAND and via USB to a PC. The FPGA board issued the proper signal patterns to control the NAND and the PC had a GUI interface to issue all kinds of commands to the NAND including doing a raw read and write to files. Obviously we cannot decrypt anything stored on NAND. When we get a failed SSD, I would read the internal logs and try to root cause it. Sometimes, we have to power up the firmware or change contents of the NAND to help determine the root cause and the concern is the problem is no longer reproducible. By keeping a backup, I have a good chance of recovering things back to the original state. Having a backup gives me lots of freedom to experiment. I've seen weird multi-factor failures where a batch of NAND parts would fail due to high temperature, with particular data pattern written using specific commands. One of those things that even manufacturing screening could catch in reasonable time. Debugging these failures was always one of those moments where I would go in wondering "what the heck is going on" to ... "ah now it makes sense."
Philipp__ 11y ago
Care to elaborate on this topic a little bit more?
- pkaye 11y ago
  What we build was a way to save and restore a raw copy of the NAND in an SSD. Since that is the only persistent media on the SSD, it is kind of like a "save game" situation where you can try different things and recover back to the previous state if you screw up. Now this is not exactly 100% true for NAND because some bits will be unstable and with multiple write cycles you make the data in a few locations progressively uncorrectable over time. So with this technique, assuming the iPhone has no other persistent media, they could save the contents, attempt a password unlock and then restore the NAND contents when it gets too many retries. As for ways to thwarts these attempts, most NAND memory have a pseudo OTP section and unique serial numbers which could be combined to make things more difficult. But these were not meant for cryptographics secure protection so I'm sure someone could find a way around them.

by pkaye 11y ago

rsync 11y ago

I would love to see pictures of the testing / analysis rig, etc. That would be very interesting.

pkaye 11y ago
Its from a company I no longer work at. Not much really to it. The hardest part is connecting to the NAND. We had special debug connections provisioned to make it easy. Other options include desolder the part and putting into a socket, using a interposer, using boundary scan. Then we had a FPGA board that connected to the NAND and via USB to a PC. The FPGA board issued the proper signal patterns to control the NAND and the PC had a GUI interface to issue all kinds of commands to the NAND including doing a raw read and write to files. Obviously we cannot decrypt anything stored on NAND. When we get a failed SSD, I would read the internal logs and try to root cause it. Sometimes, we have to power up the firmware or change contents of the NAND to help determine the root cause and the concern is the problem is no longer reproducible. By keeping a backup, I have a good chance of recovering things back to the original state. Having a backup gives me lots of freedom to experiment. I've seen weird multi-factor failures where a batch of NAND parts would fail due to high temperature, with particular data pattern written using specific commands. One of those things that even manufacturing screening could catch in reasonable time. Debugging these failures was always one of those moments where I would go in wondering "what the heck is going on" to ... "ah now it makes sense."

Philipp__ 11y ago

Care to elaborate on this topic a little bit more?

pkaye 11y ago
What we build was a way to save and restore a raw copy of the NAND in an SSD. Since that is the only persistent media on the SSD, it is kind of like a "save game" situation where you can try different things and recover back to the previous state if you screw up. Now this is not exactly 100% true for NAND because some bits will be unstable and with multiple write cycles you make the data in a few locations progressively uncorrectable over time. So with this technique, assuming the iPhone has no other persistent media, they could save the contents, attempt a password unlock and then restore the NAND contents when it gets too many retries. As for ways to thwarts these attempts, most NAND memory have a pseudo OTP section and unique serial numbers which could be combined to make things more difficult. But these were not meant for cryptographics secure protection so I'm sure someone could find a way around them.