SDelete with wear-leveling SSD

  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.
  • Larger Font Styles
    Guest:

    Just a quick heads-up that I've implemented larger font variants of our forum's light and dark page styles. You can select the style of your choice by scrolling to the footer of any page here. This might be more comfortable (it is for me) for those with high-resolution displays where the standard fonts, while permitting a lot of text to fit on the screen, might be uncomfortably small.

    (You can permanently dismiss this notification with the “X” at the upper right.)

    /Steve.

Intuit

Active member
Dec 27, 2020
37
8
With modern OS TRIM this is already practically the case. My buddy Krzys demonstrates:

hzClnwGeJUM

I like to add that even if those drives did not yet actually erase, reading the LBA addresses associated with the deleted files will almost immediately result in drive returning zeros without even actually reading the drive.
Depending on the scenario, garbage collection can be multiple power cycles down the road. But you're saying that for TRIM-aware Operating Systems, the drive effectively "hides" the data until garbage collection actually overwrites it. Since you mentioned it, users of Steve Gibson's Read Speed utility were observing bus saturation from just that... the drive returning data without actually performing the reads. Pretty efficient.
 

DiskTuna

Well-known member
Jan 3, 2021
83
8
Netherlands
But you're saying that for TRIM-aware Operating Systems, the drive effectively "hides" the data until garbage collection actually overwrites it. Since you mentioned it, users of Steve Gibson's Read Speed utility were observing bus saturation from just that... the drive returning data without actually performing the reads. Pretty efficient.

Drive removes such sectors from user addressable space after it was informed about those via TRIM command. Indeed it does not even have to read the sector, it just returns zeros when attempted.

DiskTuna said:
Yeah but SSD or better said flash is different. On a conventional hard drive you read 4096 bytes and write them back to exact same physical location. On SSD by definition you can not write back to same location*. So the operation requires an erased page, and then page that is read from become stale and has to be erased at a later time.

*Edit: You could but it means you need to erase entire block first.
I pretty much said that in my opening post. That's called wear-leveling.

No, this isn't wear leveling per se, it's a fundamental property of NAND flash memory that you can not write to same page without first erasing it. To erase the page, you need to erase the entire block. So that means you need to reallocate all data in the block. THAT is overhead. To avoid this overhead it's much simpler to just reallocate the data in page to erased page. Not because you want to 'wear-level', but because it's the most economical thing to do.
 
Last edited:

DiskTuna

Well-known member
Jan 3, 2021
83
8
Netherlands
As with many recent security exploit mitigations, obviously designers of the new secure erase protocol or command would have to take all forms of caching into account.

It's not caching, well depending on what we define to be caching. It's result of data being moved due to wear leveling algorithms etc.. If 16 stale copies of a file exist without anyone or anything tracking original file the data at some point belonged to (which is the case currently AFAIK), there's no way to erase those as well once someone at some point decides to secure erase the file.

Since these stale 'copies' aren't tracked (to SSD they're meaningless other than garbage collector needs processing them), recovery is very hard and I'd say many labs won't even attempt it. Although the data may still exist, it's not like you can instruct a recovery tool to recover file.xxx, as again the stale data isn't associated with any file. And it's certainly out of reach for undelete or file recovery software.

It would be more like a forensic fishing expedition.

One more thing about the overhead: Yes, there's always 'overhead' but the thing is that an SSD is fundamentally different than a HDD (SMR drives aside), as on HDD there's a direct relation between LBA and physical location of data which is not the case on a SSD. A Sector reallocation on a HDD is the exception on SSD it is the rule.
 
Last edited:

Intuit

Active member
Dec 27, 2020
37
8
Drive removes such sectors from user addressable space after it was informed about those via TRIM command. Indeed it does not even have to read the sector, it just returns zeros when attempted.
So the conclusion is, there's no concern about a casual user scanning an SSD to recover deleted files; provided that the O/S is TRIM aware; SDelete isn't necessary.

It would be interesting to test this by turning off TRIM, restart, delete a file, then run a file-recovery scan. Reactivate TRIM, restart, delete a file, then run a file-recovery scan.

Without going that far and knowing that the drive and O/S are TRIM capable, are starting a scan to see what if any deleted files are recoverable...
 
Last edited:

DiskTuna

Well-known member
Jan 3, 2021
83
8
Netherlands
So the conclusion is, there's no concern about a casual user scanning an SSD to recover deleted files; provided that the O/S is TRIM aware; SDelete isn't necessary.

It would be interesting to test this by turning off TRIM, restart, delete a file, then run a file-recovery scan. Reactivate TRIM, restart, delete a file, then run a file-recovery scan.

Without going that far and knowing that the drive and O/S are TRIM capable, are starting a scan to see what if any deleted files are recoverable...

Oh cool, an experiment!

Yes, it's how modern SSD's handle this AFAIK. Mind you, there's no standard that an SSD has to handle trim this way. AFAIK options are:

- return zeros
- return arbitrary data (often pattern like FF FF FF or actual random data)
- return actual contents

Now risks I see is: Although we expect OS to send TRIM command at some point, it does not mean by definition it immediately will. Also read somewhere a statement made by someone from MS 'defrag team' that defrag TRIMs because there's no guarantee all queued TRIM commands are actually sent to the drive. Because you could argue why have defrag TRIM at all if OS already did when cluster became vacant (after file deletion). So there may conditions that make OS decide to drop queued TRIM commands.

It would be interesting to test this by turning off TRIM, restart, delete a file, then run a file-recovery scan. Reactivate TRIM, restart, delete a file, then run a file-recovery scan.

Yes, which is also what guy in video I posted does.
 

Intuit

Active member
Dec 27, 2020
37
8
I was able to verify, TRIM-enabled, that the drive returns zeroes.
I mounted an inactive partition from the above SSD.
I created a human-readable text file containing the content, "THIS FILE IS HUMAN READABLE."
I used the program to view the file.
I deleted the file.
I then ran a recovery scan.
I opened the deleted file.
Content was null.

I'll now turn off TRIM and attempt the same experiment. 🙂
 

Intuit

Active member
Dec 27, 2020
37
8
Out of curiosity, I repeated the above experiment.
But instead of using the simple command prompt "del" command, I used SDelete.
SDelete hides the name of the file. Instead of the deleted "RecoverMe.Txt" file showing up with it's original name, it instead showed up as...
1614437702940.png


So if you don't mind the extra writes and the implications there-of, there is that benefit.
 
  • Like
Reactions: DiskTuna

DiskTuna

Well-known member
Jan 3, 2021
83
8
Netherlands
Yes. Indeed, delete, SSD and TRIM aside normally only removes pointers, it leaves file system entry as is for largest part as well as the clusters that were allocated to the file. What TRIM adds is clusters being zeroed. TRIM does not affect file system meta data though, it's why undelete/file recovery software still is able to list the file. From a security perspective this is may be undesirable so SDelete definitely serves a purpose there.

But now, let's go crazy ;)

Assume SSD. SDelete wants to edit an NTFS FRS to delete filename > reads associated FRS (1024 bytes) > SSD reads associated page (8192 bytes) > SDdelete edits FRS > SDdelete writes edited FRS back > SSD writes entire page to different location (erased page) > result: stale page still containing FRS with original filename.

Just a theoretical exercise, and still out of reach for undelete / file recovery software, but someone determined and with access to SSD and proper equipment/software complex may still have a go at it.