It’s not often I find myself needing to wipe digital media, but every time I do it seems that I have to re-invent the wheel. I sat down and believe I finally have a good grasp on how to securely erase drives.
- Occasionally I need to erase drives before either recycling, selling, or giving them away to someone else
- Researching the topic seems to bring up multiple answers
- Some existing tools give an inconsistent result
- Create a process for properly wiping digital media
- Provide a way to verify this process
- I am making a few assumptions about the reader here, and I am not including every piece of information that causes me to come to the conclusion documented here
- My definition of wipe is that only zeros are returned when checking the raw disk
Since my main desktop is Fedora, I was very excited to see the ATA Secure Erase option inside the Gnome Disk Utility. I’ve known about ATA Secure Erase for a few years, and usually do it from the command line. It’s much easier to plug the drive in and click the button. However, I have discovered that sometimes the process does not work. Even more confusing, the drive appears wiped – usually saying there are no partitions or the entire drive is unknown after pushing the button.
I made this discovery when trying to partition a SSD after performing this wipe, I was very confused when gdisk said there were already partitions on the device it found. I also used photorec and testdisk to confirm, the disk was NOT erased. For whatever reason the partition was gone, and perhaps even the filesystem, but the files were still there. This made me believe that ATA Secure Erase was not working for SSDs. Once you go down that rabbit hole you never come back. There are articles after articles about how to erase drives, and there is proof that SSDs sometimes just don’t erase. As you can image, this doesn’t work for me. I don’t want to physically destroy the drive, I believe that causes pollution and in my opinion its not recyclable if it’s smashed or crushed.
What I have found is that ATA Secure Erase does work, it just doesn’t work from Gnome Disk Utility (sometimes?). It’s better to just do it from the command line like I was before. And instead of using photorec or testdisk, I have found a much better way to determine if a drive is actually wiped or not. I have also confirmed that the option for overwriting with zeros also does work reliably, you could also use dd to do it as well.
Wipe a SSD or HDD:
- Follow steps here: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
If for whatever reason you cannot do the ATA Secure Erase, and the disk is either a HDD, or flash drive, you could use the Gnome Disk Utility option ‘Overwrite existing data with zeros‘. Almost every article I’ve read says do not zero a SSD, as it doesn’t work and actually reduces the lifespan. I’m sure that a flash drive is probably similar, but that’s the only thing you can do for those.
The key to this is verifying that the data is actually erased. As I said before I was using two tools meant for data recovery, and sometimes you had to wait a long time for anything to appear. If one of them started recovering data, it would be saved to my local drive – so it’s not really an ideal solution.
That’s when I discovered the od command. This command dumps the raw hex output of any file, including block devices. If you combine this with head, you have a very effective method for checking if a drive is actually zerod or not. ATA Secure Erase is supposed to zero the disk, or if you manually zero it – the result should be the same. This will not work if you dump random data to the disk.
ATA Secure Erase (SSD or HDD):
(1)[mfox@Desktop ~]$ sudo hdparm -I /dev/sdXX |grep Security: -A 5 Security: Master password revision code = 65534 supported not enabled not locked not frozen (2)[mfox@Desktop ~]$ sudo hdparm --user-master u --security-set-pass password /dev/sdXX security_password: "password" /dev/sdXX: Issuing SECURITY_SET_PASS command, password="password", user=user, mode=high (3)[mfox@Desktop ~]$ sudo hdparm -I /dev/sdXX |grep Security: -A 5 Security: Master password revision code = 65534 supported enabled not locked not frozen (4)[mfox@Desktop ~]$ sudo hdparm --user-master u --security-erase password /dev/sdXX security_password: "password" /dev/sdXX: Issuing SECURITY_ERASE command, password="password", user=user
Lets look at each of these commands:
- sudo hdparm -I /dev/sdXX |grep Security: -A 5
- The hdparm command gives us information about the drive, specifically we’re grepping for the security section
- It’s important to check if the security functions are supported, and the drive is not frozen
- sudo hdparm –user-master u –security-set-pass password /dev/sdXX
- Here we are enabling the security by setting the password ‘password’
- sudo hdparm -I /dev/sdXX |grep Security: -A 5
- This is the same command as earlier, we are checking if the security is enabled now and still not frozen
- sudo hdparm –user-master u –security-erase password /dev/sdXX
- This tells hdparm to start the erase, using the password we set earlier
[mfox@Desktop ~]$ sudo od /dev/sdXX |head 0000000 000000 000000 000000 000000 000000 000000 000000 000000 * 1576245660000
This is a simple check, combined with a simple trick. od dumps the hex output of a file (or in this case a block device). If the values are duplicate, it only shows a ‘*’ until it ends. If there was data on the disk, you’d see other output (I’ll give an example below). Combining this with head will stop the entire thing as soon as data is detected, since the output will change – creating more text – and the command will finish. This is useful so you can know if there is data on the drive without having to wait for the entire check to finish. It will stop as soon as data is found.
Example of data still on drive:
[mfox@Desktop ~]$ sudo od /dev/sdXX |head 0000000 134372 010000 150216 000274 134260 000000 154216 140216 0000020 137373 076000 000277 134406 001000 122363 020752 000006 0000040 137000 003676 002070 005565 143203 100420 177376 072407 0000060 165763 132026 130002 135401 076000 100262 072212 105401 0000100 001114 011715 000352 000174 165400 000376 000000 000000 0000120 000000 000000 000000 000000 000000 000000 000000 000000 * 0000700 000002 177756 177777 000001 000000 045657 006771 000000 0000720 000000 000000 000000 000000 000000 000000 000000 000000 *
head stopped the command when it detected enough text, so it didn’t waste 20 minutes checking the entire drive. This comes in handy for large or slow disks.