For SATA SSDs i've used the hdparm secure erase and then verified that dd | hexdump is all zeros. That was good enough for me.

▲

aidenn0 21 hours ago | parent | next [-]

Depending on your threat model, your check is insufficient, since dd |hexdump will be all zeros even if you just trim all the blocks for a drive that is trim-to-zero.

Securely erasing flash drives with a threat model of "someone will dump the raw data of the chips" is only fully solvable for self-encrypting drives where you can replace the key. Even if you can issue a block-erase for every single block of the device, block erase doesn't always succeed on NAND.

▲

Joel_Mckay 21 hours ago | parent | prev [-]

For Sata HDD shingled writes and SSD sector replacement it can't be cleaned that way.

Tools like dban stopped working once firmware sector re-mapping chips on modern storage became common. If you see the reported spare replacement count drop on your older s.m.a.r.t reports, than partial sectors may no longer be accessed from the OS without vendor specific forensic software. =3

https://sourceforge.net/projects/dban/

▲

SoftTalker 3 hours ago | parent [-]

hdparm secure erase runs on the drive controller though, the "hdparm" utility just initiates it? So it's not depending on whether the OS can or cannot see specific sectors. At least that's my understanding.

	▲	Joel_Mckay 2 hours ago \| parent [-]
		Even with vendor specific forensic software it is unwise to trust the relocated sector mapping is handled cleanly. A cheap XGecu T76 Programmer can pull orphaned data fragments off most flash chips completely bypassing the drive controller. In this case, the other posts suggesting a hammer is not sarcasm. =3