Unable to wipe physical devices (always fails) - SSD and HDD

[humm3r1]

Describe the bug DiskSlaw is not wiping physical machines. Detects "Frozen SSD" even in machines with mechanical drives. It looks like it tries to wipe the drives, but goes to 100% almost instantly, and shows (F) on the status line indicating it failed.

To Reproduce Steps to reproduce the behavior:

1. Boot DiskSlaw on a Dell machine (Latitude 5550/5450/5570, Precision 3510/3520) from USB.
2. When prompted (as it detects a frozen drive), let it sleep. Resume by pressing power button since keyboard wake does not work.
3. Watch the progress, and it will go to 100% (F) almost immediately.

Expected behavior I expect it to begin wiping the drives with the erase commands, instead of instantly failing.

Additional context I am more than happy to help work on this with you and test against my machines. My workplace is looking for a tool that can detect and wipe SSD's/HDD's properly (so that we only shred on mechanical drives and not overwrite the entire SSD and kill it). I took a quick peek and so far I am unsure why it is acting up. I will try against the same hardware with manual commands from your script to see what happens.

[maltob]

Could you try the ISO uploaded last night, 0.3.1.1?

The previous one was a bad build.

[humm3r1]

First two runs are failing with invalid sense data. I got this from the F2 console:

==> /tmp/diskslaw_main.log skipping loop3 because Device has no length sda is still frozen, will need to suspend going to sleep recovered from sleep starting wipes enhanced secure erase security erase sda all wipes started awaiting wipes all wipes done

==> /tmp/diskslaw_se_enhanced_err_sda.log SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

==>/tmp/diskslaw_se_enhanced_sda.log security_password: "pass"

/dev/sda: Issuing SECURITY_ERASE command, password="pass", user=user

==> /tmp/diskslaw_se_err_sda.log SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

==> /tmp/diskslaw_se_sda.log security_password: "pass"

/dev/sda: Issuing SECURITY_ERASE command, password="pass", user=user

I'm going to try this on legacy boot as well just in case UEFI network boot is causing issues (using GRUB2 to go into iPXE then chainloading the kernel, initrd and squashfs), I'll also try the commands manually in a live boot environment against the same hardware to see what is going on.

It is not a BIOS thing as far as I can tell since it does the same thing no matter if set to RAID or AHCI. I still need to try off a USB in legacy boot mode and the commands manually but am updating this comment whenever I find new information.

[maltob]

What model machine and model of storage is in the machine?

It appears to either not support ATA secure erase or doesn't unlock/unfreeze with the suspend.

[humm3r1]

I'll go get some more model numbers and update this comment this afternoon and do some manual commands to find out. For what it is worth, Parted Magic works fine with their secure ATA erase cycle, but this is all manually done in a GUI and not automated.

Dell Precision 3520. 500GB Seagate Thin HDD, should be Dell PN# 7P79P, Seagate PN#ST500LM021. I'll collect exact model numbers later today. The Seagate documentation(https://www.seagate.com/www-content/product-content/momentus-fam/momentus-thin/en-us/docs/100737930h.pdf 5.2.4 ATA Enhanced Security) mentions the secure erase, so it seems the drive should support it between the documentation and my experience with Parted Magic.

I have also tried this on a Dell Precision 3510 with the same HDD, 500GB Seagate Thin model.

I feel like it has to be some sort of bug if the secure ATA erase command is working in PartedMagic. I'm happy to try things to fix this with you.

So as I suspected, the manual commands work just fine on a Debian 9 Live CD burned to a USB stick and booted. I did an apt-get update and apt-get install hdparm, hopped into sudo su, and issued everything here https://grok.lsu.edu/Article.aspx?articleid=16716 I took photos on my phone of every command issued for reference.

It is presently wiping the disk and the HDD indicator light is solid (This unit has the 500GB spinning seagate thin HDD)

Step 1: Identify the drives sudo fdisk -l

Step 2: Check if frozen and sleep the machine to clear the frozen status check with sudo hdparm -I /dev/sda to sleep the machine: (in sudo su at this point to get past an issue about permissions) echo -n mem > /sys/power/state

Step 3: Confirm frozen status is cleared sudo hdparm -I /dev/sda

Step 4: set password sudo hdparm --user-master u --security-set-paass p /dev/sda

Step 5: check if enhanced secure erase is supported sudo hdparm -I /dev/sda

Step 6: begin wiping sudo hdparm --user-master u --security-erase-enhanced p /dev/sda

[humm3r1]

Hello,

So I tried the pm-suspend command just to check and it seems to be clearing the frozen state fine manually under Debian. Is this perhaps an issue with Ubuntu? Looks like you are using bionic and I'm using debian 9, that's so far the only thing I can think of right now.

I'm going to see if I can build it off of Debian 9 and if that makes any difference.

I presume all I need is a linux environment (such as my debian 9 live CD) to clone the github repo and begin running build.sh?

[humm3r1]

New info:

I modified your build so I could use a proper shell when it boots up for root (so I removed the autorun diskslaw.sh part in etc/passwd, basically)

I see the drive is able to unfreeze just fine with your script, but then it still instantly fails and throws sense data errors.

Looks like it is mismatching: I get a warning in /tmp/DiskSlaw.csv: "Mismatch: secure erase vs enhanced secure erase". Is this the root issue? Edit: Tried changing main.yml to disable enhanced, no more mismatch but still instantly failing.

OK so i might have some successful information now: I changed the check in diskslaw_erase_secure (i think) so that when it checks if there is already a password set, it will still try to set a ATA password. It is actually taking time to finish and I cannot query SDA anymore on the second Getty window.

If this shows progress and actually wipes the device, then it looks like it is this subroutine that is broken (get_drive_has_master_password). I'll keep an eye on it and try a few other machines.

Confirmed, HDD lights are going solid now while waiting for the first % to show (0% showing but HDD light is 100% active)

Maybe check for Security Level high instead of the enable check? That only shows up in my hdparm when a password is set.

[maltob]

Hi Humm3r1,

I'm going to work on this more over this weekend.

The mismatch error is caused by it trying enhanced then falling back to normal secure erase, this isnt unexpected in my testing as some drives don't support enhanced secure erase. It's just letting you know the config file specifies enhanced but it didn't succeed with enhanced.

If you try one of the older builds (not 0.3.x) you may have better luck for now, I'm with you in thinking my function isn't handling this properly.

[humm3r1]

Hey Maltob,

Thanks for your reply!

I can for sure tell you these drives support enhanced erase. I’ve done it manually many times and checked the manufacturer spec sheets. Hdparm can also see that it supports enhanced erase. For what it is worth, your /tmp/DiskSlaw.csv file even says enhanced secure erase was completed.

My guess is the password function since basically forcing it to set a password makes it work whereas before it fails instantly. I haven’t tried to set it manually myself yet and then see if diskslaw can handle it. I suspect if that works then it has to be this routine to set the passwords.

For what it’s worth I can confirm those drives from last week erased properly as there is no Data on them now.

I’ll keep an eye on here in case you update this with any information. Thanks for all the help and hard work!

[maltob]

I wasn't able to replicate it on my test machine, but it shouldn't hurt anything to remove the password check function and just always set the password like you've tested.

I'll try to get an updated ISO made with that setup this week.

[humm3r1]

Thats interesting, lol. Anything in particular you'd want me to check on my machine? I can retry with the SATA mode set to AHCI instead of RAID just in case (it didn't make a difference when I tested at first but just to be sure I'll retry).

The only other thing I can think of is just the function checking for not\tenabled might be to blame if the output is somehow different (maybe an extra whitespace etc?). It's so weird yours works fine. What hardware do you have to test on? I can try to replicate with a mix of Dell and Lenovo hardware we have on site and see if I can track anything down.

Thanks very much for your time and help with this! I really appreciate it.

[maltob]

Hi @humm3r1,

You were correct, there was a bug in both the frozen and the password check, my testing didn't find them because both were evaluating the way I had expected.

I've uploaded a new ISO with the fixed checks and an input for the disk password below: https://github.com/maltob/DiskSlaw/releases/tag/0.3.2-alpha

Could you try out this revision and see if it fixes the issue you were experiencing?

Thanks!

[humm3r1]

Hey Maltob,

Thanks for all your hard work tracking down the bug! It seems to be working now on the first machine i tried. I'll try a bunch of models to confirm it is working! 👍

Only thing that isn't now from my side is the progress bar is always 0%. I'm not sure how to check for progress but I'll experiment and if I figure it out, i'll let you know!