I am giving away a shitty 128GB SSD, which was used with LUKS 2 for most of it’s lifetime. As far as I know, it’s good practice to secure-erase it, but I’m too lazy to reinstall the OS on it (I already did it once). Is it really needed?
You must log in or # to comment.
I think one TRIM cycle should make any data unrecoverable by all but the most determined. Feel free to correct me if i’m wrong though.
It you really care, throw this on a usb stick and sleep well. It replaces to old dban system, which has gone commercial. https://github.com/PartialVolume/shredos.x86_64
Secure erase just drops the ssd controllers table of where logical blocks are in the physical memory and trims the disk. Which is good and you should do.
That means a person would have to address the memory directly with flying leads or a bed of nails or something. Or have special software that makes the controller tell them what’s on each physical block and then put that data together into a bunch of files.
If that worries you, do dd if=/dev/urandom of=/dev/<disk> before you secure erase.
Then everything on the drive will be random static before the secure erase drops the block table and trims, so even if someone uses magic power to read the block contents directly they just get to see static.
That has the benefit of speeding up the drive by resetting read fatigue at the expense of one layer of writes which is always worth it.
Ah, fun fact, dd won’t actually cover all the blocks since SSDs have reserve blocks and IIRC they do rotate which ones are in use vs which are not, to even out wear
Yes of course this will only rewrite some number of blocks that total the disks reported capacity. In the case that a person is worried about hidden blocks being preserved by a wear leveling algorithm they could just run the same command again and that would get em all.
Useless use of dd. cat or cp are better suited in this case.
That’s only true for some environments.
E: this is the first time I’ve read that blog post since it was published (or at least a long time ago) and there’s now a comment specifically referencing the actual behavior I observed in the wild when I tried to sub other things in for “normal” uses of dd:
Nobody says: 2016-12-30 at 15:17
cat /dev/cdrom > myfile.iso
Works
cat myfile.iso > /dev/cdrom
Won’t – dd allows you do handle writes in various block sizes, so if a device can’t handle a one-byte write, cat could well end up writing your byte followed by zeros (and because of where the pointer now is, do it again for the next byte).
Still, all your other points stand – nice piece.
While that comment was written seventy years ago, in this age of people with questionable intent, capability and integrity rewriting system tools in rust there’s no better time to linger thoughtfully over cp or cat or any number of other commands that begin with the letter “c” before grabbing the ol’ reliable footgun whose fifty years of script backwards compatibility ensure that no one can get their dd replacement accepted in normal use until it behaves as expected.
deleted by creator
You said that:
I am giving away a shitty 128GB SSD, which was used with LUKS 2 for most of it’s lifetime.
This leads me to assume that it is not now? Is this the case? If it still has LUK2 on it, you can run cryptsetup-erase on the luks2 container. This won’t wipe any unencrypted data, though.
One needs to be careful and avoid block level wipes wherever possible for SSD as this will wear it out quicker. Obviously, if you have sensitive data unencrypted, you may have to. Shred is your friend, here. It works on entire devices as well as individual files. The individual files option is preferable if you the sensitive data is at known locations.
Does shred work on journaling file systems?
I doubt it. I think some filesystems have mount options that disable the journal for that session.
Huh, pretty serendipitous exchange. I found this: https://www.webconn.tech/kb/disable-or-enable-journaling-on-ext4-filesystem
cat /dev/urandom > /dev/your-diskshould do it in your case. And in 99% of cases.this is just gonna cause useless wear on the ssd. only do this to hdds
I think you mean doing that for more than once has no extra effect on an SSD. Shouldn’t we overwrite the unencrypted content for at least once?
nope, i mean that’s just useless. (it does kinda do the job, but wears it down, and not as effective since SSDs aren’t really predictable because of wear leveling stuff and lie to the OS) there’s an ATA Secure Erase feature that can be used instead.
some relevant link https://grok.lsu.edu/article.aspx?articleid=16716
I’m assuming when you “reinstalled the OS” you just repartitioned the drive and installed normally without encryption for the person? If that’s the case then all your old data is encrypted and will be unrecoverable without your password and the LUKS header.
If however you reinstalled the OS within the already made LUKS partition and are giving them the password (for some reason) then yeah, you wanna secure erase it.
If you were selling on eBay or something I would still recommend a secure erase (they’re really quick on SSDs)
You don’t have to install anything on it, just connect it to a running PC and do a dd if=/dev/zero, that should be enough to get rid of any remnants directly accessible.
Unless you are part of a drug distribution organization, in that case just use a hammer, a microwave and a blowtorch.Not really great on SSDs, though. It’ll likely make them slower because now the controller thinks 100% of the memory is allocated. And some small percentage of the data will still be around, because they do overprovisioning.
Shouldn’t matter for OP, though. If they set up LUKS properly, there’s no way to decrypt the data.
But I mean secure wipe isn’t hard… It’s copy-pasting 2 more commands from the Arch wiki, compared to the dd command.
some small percentage of the data will still be around, because they do overprovisioning.
That’s why I wrote “directly accessible data”. You are certainly right that safely erasing all data on SSDs is hard to impossible, but so is the read access to it.
That means if we disregard the drug distribution or similar scenarios, should be enough for the normal person.But I mean secure wipe isn’t hard… It’s copy-pasting 2 more commands from the Arch wiki, compared to the dd command.
But it will take significantly longer (typically using /dev/random and multiple passes) without noticably increasing security for SSDs.It will have also have the same possible write-speed-penalty issue as the zero-overwriting, but this won’t be OPs problem any more because he is selling the SSD.
Most likely not. Did you have anything on it that you would even be concerned about someone else finding? Is anyone even likely to be curious enough to look?
Is anyone even likely to be curious enough to look?
Well, can only speak for me, but first thing I do.
I mean, you can never know which administrative scandal you might uncover…
I stop the moment I find private stuff, though.
Had that three or four times already, the only case I was considering doing something about it was a completely unsecured and unerased phone still containing a bunch of business emails that clearly were sensitive or even confidential stuff.
I just told the seller how he screwed up here, instead of making a bigger fuss out of it.Sure, but are you pulling out forensic analysis tools, or just checking what didn’t even get erased in the first place?
The devices in question all were fat formatted, for which it is quite easy to reconstruct most of the “deleted” content using readily available simple tools (which I did).
But that was some time in the past, nowadays most systems use some kind of base encryption, making it less likely to easily find something.
The phone, on the other hand, was just not doing a factory reset before selling it, but only deleting files (and missing stuff, like some mail folders) and not having a password-protection at all… 😬
