When I’ve finished using a hard disk for a customer project I’ll erase the data on it so the drive can be reused without the customers data getting exposed. A simple reformat of the disk would cover most scenarios but there’s a chance data can still be recovered after this so I need to be sure its not recoverable. The Secure erase feature of the disk would be perfect for this, or so I thought.
Background#
Back in 2018 I used an external Hard Disk as a backup for a data store for a customers server during an upgrade process. It was a Western Digital “My Passport Ultra” USB 3 external hard disk.
Thankfully the backup itself was never needed during the upgrade as it all went according to plan.
As the data on the HDD was no longer needed and the drive was still in good working order it needed to be erased so it could be used for other projects.
Options for erasing the disk#
I have 2 options for erasing this disk:
- Use
ddto erase the disk - Use the onboard security erase feature
The dd process can some times take quite a long time to complete and may need to be run a number of times to comply with certain data erasure standards ( as needed ).
The onboard security features can help here. So long as the device is powered up the erase can continue without using up a computer and can typically perform multiple erasure cycles inline with a standard or two.
If you’re extra lucky this can also be much quicker than performing a block by block write to the disk with dd.
Not all devices support the security erase features however but this one did so I thought I’d use it given the success I’d had with other disks.
Onboard Security#
To use this option we have to make sure that the device supports it first.
To discover if its there run the command:
hdparm -I /dev/sda
You should see lots of output but the thing to look out for is this:
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
120min for SECURITY ERASE UNIT. 120min for ENHANCED SECURITY ERASE UNIT.
not is absent from the supported line indicating that it is a supported feature of the device.
To perform an erasure the security features have to be enabled. This can be done so with this command:
hdparm --user-master u --security-set-pass pass /dev/sda
If this command is successful you should see the following output:
security_password="pass"
/dev/sda:
Issuing SECURITY_SET_PASS command, password="pass", user=user, mode=high
All good so far, or so I thought…
At this point it should be ready to perform the erasure process.
This command will trigger the erasure of the device:
hdparm --user-master u --security-erase pass /dev/X
However when this command was issued I received an error 😬
At this point the drive stopped responding normally and access to the data on the disk was prevented. The only thing it would allow me to talk to would be the security interface.
When attempting to access the security features again the disk would lock out after an attempt and would then refuse further access until it was reset ( power off and on again )
The fix#
I’d periodically have a stab at trying to fix the issue without any luck for a number of years.
The fix came when I discovered:
Western Digital Decryption tools
( Originally forked from: SofianeHamlaoui/WD-Decrypte )
The repository contained some info on the security mechanisms of the device and what data needed to be sent where. Thankfully SofianeHamlaoui had done most of the work on this already and had found what needed to be sent to the device.
Merci!
The cookpw.py script generated the raw bin file with which to unlock the drive and another bin file with which to disable the security measures.
Each of the files contain slightly different instructions for the device. You’ll notice that the password used earlier is visible here in each of the binaries; “7061 7373” = “pass”
The files generated by the python script looked like this when run via xxd
pass.bin:
4500 0000 0000 0020 7061 7373 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
unset.bin:
4500 0010 0000 0020 7061 7373 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 7061 7373 0000 0000
0000 0000 0000 0000
To unlock the device I would need to run the following command:
sg_raw -s 40 -i pass.bin c1 e1 00 00 00 00 00 00 28 00
Once unlocked I could then remove the security features with the following command:
sg_raw -s 72 -i unset.bin c1 e2 00 00 00 00 00 00 48 00
🎉 The device is now unlocked and access to the data is now allowed again!
In the end it took about 4 hours to perform a full single pass write of zero’s to the disk using dd
… Plus the 3 years it took to find this unlock info
Lessons learned#
Not every device supports the ATA security feature set referenced here. Some devices will say this explicitly with a simple Not Suported line in the hdparm output or by not outputting any security info at all.
For example you may see an error in place of the expected hdparm output.
Where USB devices are concerned be very very careful!
A lot of high capacity USB storage devices will be interfaced as:
Depending on who’s made what component there is a chance that something along this chain doesn’t understand the command being fed to it and will either ignore it or miss represent it to the underlying storage device.
In the case of the drive above the USB interface is directly attached to the logic board … I only know this because I shucked drive with a view of a potential fix by connecting it differently.
The same issue can be discovered when using cheaper USB HDD docks. The dock itself will allow access to the storage device but wont support any further features to a decent or operational standard to rely on.