Profile picture
, 18 tweets, 3 min read Read on Twitter
This is a fun thread to read, having spent time working in SSD manufacturing and debug prior to finding a role in infosec. This particular comment can be expanded upon. There are a couple reasons why data recovery on SSDs is a hard problem.
First and foremost is something called an indirection table. SSDs don't store your data physically together. For wear leveling and performance purposes, data gets spread out across the drive. The indirection table provides a mapping from logical block address and physical address
NAND cells aren't written to at the singular cell level. A NAND package is broken up into a number of dies, each of which are broken up into a number of planes. Each plane has a number of blocks, and each block a number of pages.
The page is the smallest unit which can be written to, but the block is the smallest unit that can be erased. This means when you want to erase a block, you might still have data on it you want to keep, so you have to read that data, write it elsewhere, and then erase.
But obviously your data being moved around physically can't be exposed to the user, otherwise your files would be changing places all the time and would always get corrupted. This is why the indirection table helps. The data can retain the same LBA but be at a different physical
This type of thing happens on basically all SSDs just due to the way NAND is programmed and erased at different sizes. Then there is wear levelling, which the controller uses to try to prevent a particular chunk of flash wearing out more quickly than others.
So wear levelling will move data around to try to more evenly distribute program-erase cycles across the flash. Then there's a matter of blocks going bad, unable to be trusted due to high bit errors rates, or other reasons.
SSDs have extra flash in them that is never exposed to the user. It's one reason why drives marketed as 256GB might only show up with around 240-248 GB of usable space. The rest is extra flash that gets used to make up for bad blocks.
That's just one reason recovering data on SSDs is hard. Another is that there are often times encryption happening between the controller and the NAND. Usually AES, with the keys stored in integrated memory in the controller.
This is different than drive encryption, the SSD might do this entirely behind the scenes with a set of keys that you know nothing about. This encryption makes it much harder to chip-off and read flash, unless you can also dump the keys from the controller.
There's an ATA command called Secure Erase, and this can be implemented in one of two easy, typically. The fastest way an erase is done is that the controller just forgets it's old encryption key and creates a new one. Now all old data is considered invalid and marked as deleted
This means that the drive is ready to use again faster, and the actual data will get overwritten during the normal PE cycles that the drive goes through. The other way to do an erase is slower and involves actually erasing each block.
This tends to be avoided because it can cause unnecessary PE cycles on the drive, reducing the longevity of the memory. NAND can only be programmed and erased so many times.
Erases are also slower than doing a read or a program operation, which contributes to why the drive tries to minimize its use of them.
Fun fact: when a page of NAND is empty, you might think it's all 0s, but it's actually all 1s.
Oh and all of this isn't taking into account that a single NAND cell can contain one, two, or three bits per cell. This is called SLC, MLC, and TLC, respectively.
Advances in the number of bits stored per cell are one of the reasons SSD sizes have been able to grow. Basically a NAND cell traps a charge. In SLC this charge is either above or below a certain threshold, representing a 1 or a 0.
This gets into levels of electrical engineering and material science that I don't particularly understand too well, but you can look up the differences and people much smarter than I can explain it.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to dade
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!