Securely erasing SSDs

[belham2]

Hi all,

After much reading, surfing the net during various times over the past week, I've been trying to get a grasp on what is the best (and most easily accessible) way if you come across a SSD that needs to be completely wiped (for either data and/or infection reasons)? What have some of you come across that works best for you? Are we stuck with using only 'ATA Secure Erase' (HDDErase) via making a DOS Boot Disk and also configuring your BIOS to again recognize "IDE" so HDDErase can do its thing? Is there any other way, besides ponying up $$$$ to PartitionMagic for its take on things??


P.S. Labbe5, didn't you post somewhere about this on murga? I cannot find it (doggone using "search" inside/on murga really stinks sometimes.

[cthisbear]

A few quick searches.
Parted Magic is on the youtube link.

http://www.makeuseof.com/tag/securely-e ... destroying

https://www.kingston.com/us/community/a ... ticleId=10

http://www.pcworld.com/article/2910982/ ... ities.html

http://www.techrepublic.com/article/era ... -an-issue/

http://www.partition-tool.com/resource/ ... ws-10.html

https://www.youtube.com/watch?v=rpp9ECG6qCs

Chris.

[belham2]

Hi Chris,

Hey, did you even read my post ( I mean this in a nice way)? I am grateful for your quick search, but as I noted, I had done that and even more over the past week. We are either left with p-magic and $$$$ out the pocket, or the cumbersome HDDErase method. But I had wondered "if" anyone here on murga has had success when wiping their own SSD following something they've done possibly other than those 2 ways (there are reports in the Wild and on Wilder that other methods are available, but no one specifically cites what these are). Hopefully someone who has actually wiped their SSD, as I mentioned, will chime in here.

[belham2]

Hi again all,

Just wanted to follow up on this for anyone that wants to securely erase your SSD drive for any reason, i.e. wiping your data, getting rid of suspected viruses on it, just getting rid of multiple OSes on it, whatever.

First thing to do, is IGNORE Google if typing in any variation of "securely erase SSD drive(s)". Dam# idiot search engine bring back totally useless, outdated and, in fact, dangerous data on how to handle modern-day SSDs. Everything nowadays is handled through hdparm, not what Google brings back

Second thing to do, the answer lies in any recent puppy OS (booted however you want) and the PPM installation of the "hdparm" utility. Hdparm is everything you will need, and it is small and incredibly simple. Just PPM load/install it, and then follow everything that is written in this wiki devoted to 'ATA Secure Erase' of SSDs using hdparm:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase


My 120GB Kingston SSD took all of 3.4321 seconds (yes, you read that right, "seconds" ) to securely erase the whole drive. All you have to do is just follow the wiki's detailed, simple commands you execute in terminal in your pup. Really incredible. (Of course, as the wiki notes, if you use hdparm on a non-SSD drive, expect some hours to be taken out of your life, as we are all accustomed to with those spinning magnetic disk monsters).

Hope this helps someone out there.

[Burn_IT]

Unfortunately at present there is no reliable method for determining the optimal settings for a given controller/drive combination, except careful trial and error; nor is there yet any central database that collects and shares the combined experience of hdparm users.

hdparm has a more serious drawback: it can crash a computer and make data on its disk inaccessible if certain parameters are misused. Out of approximately sixty-seven parameters, several are dangerous and could result in "massive filesystem corruption" when used indiscriminately.

[Mike Walsh]

Hi, belham2.

Mm. I'm guessing this wouldn't work on a PATA/IDE interface SSD then (used by those of us with older hardware)? Any ideas?


Mike.

[Les Kerf]

Hi, belham2.

Mm. I'm guessing this wouldn't work on a PATA/IDE interface SSD then (used by those of us with older hardware)? Any ideas?


Mike.

dd if=/dev/zero of=/dev/hdx

[rufwoof]

Hi, belham2.

Mm. I'm guessing this wouldn't work on a PATA/IDE interface SSD then (used by those of us with older hardware)? Any ideas?


Mike.

dd if=/dev/zero of=/dev/hdx

I wonder if setting every bit off (zero) might still leave forensic imprint of what was set or not before. Perhaps setting every bit on might be securer ???

Maybe something like dd if=/dev/zero | tr '\000' '\377' > file

[belham2]

Hi, belham2.

Mm. I'm guessing this wouldn't work on a PATA/IDE interface SSD then (used by those of us with older hardware)? Any ideas?


Mike.

dd if=/dev/zero of=/dev/hdx

I wonder if setting every bit off (zero) might still leave forensic imprint of what was set or not before. Perhaps setting every bit on might be securer ???

Maybe something like dd if=/dev/zero | tr '\000' '\377' > file

Hi rufwoof,

The absolute randomness this method (Secure Erase) generates generates in the system after it has ran that, when someone tried to reconstruct anything after, wouldn't it would be past impossible to overcome this randomness. I mean, every NAND cell gets hit with ATA Secure Erase, if I understand how it operates correctly. But who knows? I cannt find one statement and/or story out there that a SSD had recovered data after Secure Erase ran. Supposedly, it is the death nuclear option for SSD data recovery.

[belham2]

Hi, belham2.

Mm. I'm guessing this wouldn't work on a PATA/IDE interface SSD then (used by those of us with older hardware)? Any ideas?


Mike.

Hi Mike,

Me thinks on a PATA/IDE interface SSD, I'd stick with doing the U.C. Sand Diego method (HDDERASE) since it specifically asks you to make sure the BIOS is set to "IDE" and/or "compatability" mode Hdparm and ATA Secure Erase, from reading, can be a fickle mother when it decides whether to give new life, so to speak, to your SSD. And it IS picky about connection types

[april]

My 120GB Kingston SSD took all of 3.4321 seconds (yes, you read that right, "seconds" :shock: ) to securely erase the whole drive. Hope this helps someone out there.

Um my calculator tells me that's 9.5 hours?

Is that what you meant?
And I'm wondering exactly what was the line of code you ran to do it ?

I see on your link above a fellow named Chris has put up big warnings all over about not using this . So could you review it please?

Can I use it to do my USB stick which is a SSD ?
I had a little look and got this

Code: Select all

# hdparm -gI /dev/sdb1

/dev/sdb1:
 geometry      = 1015/64/62, sectors = 4026368, start = 2048
SG_IO: bad/missing sense data, sb[]:  70 00 02 00 00 00 00 0a 00 00 00 00 3a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ATA device, with non-removable media
Standards:
	Likely used: 1
Configuration:
	Logical		max	current
	cylinders	0	0
	heads		0	0
	sectors/track	0	0
	--
	Logical/Physical Sector size:           512 bytes
	device size with M = 1024*1024:           0 MBytes
	device size with M = 1000*1000:           0 MBytes 
	cache/buffer size  = unknown
Capabilities:
	IORDY not likely
	Cannot perform double-word IO
	R/W multiple sector transfer: not supported
	DMA: not supported
	PIO: pio0 
# 

[perdido]

Belham,

Something you may wish to look at after the secure erase of SSD drive - look at the drive with
Testdisk Photorec recovery and see what is still on there.

SSD and flash drives use proprietary software referred to as "wear levelling". What that does
is put areas of the disk that have been used more than other areas of the disk "off-limits" to
writes, no matter what software you are using. https://en.wikipedia.org/wiki/Wear_leveling

What that accomplishes is extending the life of SSD drives as SSD drives have a limited amount
of write cycles per segment. The only way to get a full wipe in one pass is to use a utility from the drive
manufacturer, if they have one available. It is all proprietary, there are no industry standards for wear levelling.

When I was playing with Bleachbit and writing all zero / 1's to flashdrives, I found that the whole drive
was not being written to when examined with Testdisk. It took up to 12 overwrites of the drives
(some took less) to completely erase the drives. No drive was erased after one pass. FWIW.

[april]

Hmm considering you won't answer and the warnings written all over your referenced page , I think I will just leave it all alone and try bleachbit or that other one that was put on the forum that I cannot remember the name of . Ill think about it for a while and it will come back to me.
OscarTalks posted it I think. Might have been called Obliterate

Otherwise the line above might suffice
dd if=/dev/zero of=/dev/hdx or
dd if=/dev/zero | tr '\000' '\377' > file perhaps
dd if=/dev/urandom/

Or just write anything on it that fills it and then delete.Chances of anything useful being recovered are pretty slim.

[peterw]

I occasionally use hdparm and knew it had an erase option. Never tried it but if anyone wants to give it a go then here is some instructions. https://grok.lsu.edu/article.aspx?articleid=16716