I have a HGST HUH721212ALE600 which I attempted to secure erase using the option in my (ASUS B560M-C/CSM) BIOS but lost power mid way through, now when I boot the machine with the drive plugged in it’s asking for a password.
I have very limited experience with SEDs, but from what I can gather it sounds like I need to send it a ‘revert’ command to reset it to factory state. I have tried booting to a sedutil USB stick and resetting the drive using what I presume looking at the drive label is the PSID, but it comes back with ‘invalid or unsupported disk’.
Does anyone know if there is a method/utility to just nuke it back to factory defaults? I don’t care about the data on the drive, I just want to be able to reuse the drive.
Hey thanks for the reply, I actually found this page just before you posted
‘hdparm -I /dev/sda’
Output under the ‘Security’ section in my case shows the drive password as supported+enabled+locked
I tried the following sanitize command from the article,
‘hdparm --yes-i-know-what-i-am-doing --sanitize-overwrite passes 1 --sanitize-overwrite hex:11111111 /dev/sda’
And got back ‘invalid PATTERN format (must be hex:XXXXXXXX)’. I’m assuming the ‘11111111’ is a placeholder and I need to be inputting something else after ‘hex:’? Any searching of the above error seems to lead me back to the tinyapps.org page.
there are a couple of different ways to ‘secure’ a drive. if yours is software encrypted, some combination of commands from there should over write it. if your drive has a password set via some firmware mechanism it may be unrecoverable in any way.
I thought when a secure erase operation is started, the issuing app locks the drive with a one-time “Master” password.
If power loss, you need to use the same password to unlock the drive?
I think each app uses their own one each time, so quack the default from the secure erasing app, and try and unlock the drive, if it is in “locked” status?
yes, some use a standardized temp lock of all 1s, or all 0s. ‘all’ can have a varied length based on HEX or word length though.
theres also a totally different ‘drive lock’ still supported by pretty much every pc on the planet but is almost never used. it was a common option in IBM laptops like 15 years ago. in the BIOS you could enable ‘hard drive password’ this was NOT the same as ‘BIOS PASSWORD’ and this feature can be accessed with software now if you know how to find it.
i only bring this up because when looking for ‘secure drive wipe’ stuff a lot of times info will bleed back and forth, further confusing an already difficult situation.
hardware vendors that use standard hard drives in a ‘secure enclosure’ use this to make it so you can’t easily swap drives. IE: RDX drives, and a lot of car head units with hard drives in them all work this way. and there are utilities in linux to unlock these hard drives too, and that is where things start to get crossed up. so when searching for what the default password is you will get answers like ‘it is 11111111’ or ‘1 to the 12 power’ or ‘MitsubishiDriveSecure’ etc.
it was also used in the original XBOX, and that key is floating around the net also.
Within the BIOS of the motherboard there was an option for secure erase and it listed the drive as compatible. I was under the impression this was going to be the mechanism (I think this is how ISE works, please correct me if this isn’t the case) where the internal drive generated encryption password is reset and the disk marked as blank, so essentially the previous data that is left on disk becomes encrypted gibberish and is written over as the drive is writen to?
When I tried to do this the progres bar wen’t from 0>100% within seconds, then sat unresponsive at 100% for hours. I left it overnight and when I came back to check on it next morning found there had been a power cut in the area, long enough that my little UPS shut down
::edit:: when the progress bar was sat at 100%, there were no physical signs of any activity of the drive
I’ve sent a support ticket in to Asus, see if they can shed some light on what state the motherboard has left the drive in.
i do not know about ASUS. the term ‘Secure Erase’ as far as the DOD standard is concerned is just a matter of writing over a drive completely, multiple times, with variance between what is written. Some times all 0 to the drive, sometimes all 1 to the drive, sometimes random to the drive. This mess of manufactures using encryption in their utilities has also caused further confusion and work. if one of the DOD supported APPS were to fail part way through, the drive would just be recognized on any PC as blank unformatted.
Quick update for anyone interested, I have finally managed to recover this drive
ASUS tech support was pretty useless, they kept asking me to fill in forms with the details of my hardware over and over without actually giving any information or suggestions. I presume they were trying to give a false impression of progress while they worked out what to do.
Western Digital were much better and sent me what looks like an internal utility they use to work on drives. Unfortunately it seems to be a customised version of hdparm and had the same issues doing anything with my drive. The advice I got from WD was to attempt a sanitize operation using their utility and if that failed they admitted there wasn’t much they would be able to do. While it didn’t solve the issue I appreciate the honesty and not wasting my time like ASUS.
Having exhausted those options I remembered the motherboard in my pfsense router (ASUS B250M-C/CSM) had a secure erase option like the B560M-C/CSM that locked the drive in the first place, this was a no go as it asked for a password at boot. Even turning hot plug on and plugging the drive in after boot, running the secure erase it instantly came back saying ‘operation failed’.
Something I noticed while messing around trying to get this drive working was when it was plugged in to a modern UEFI motherboard I would get the password prompt at boot, yet with older hardware there would be no prompt (any read/writes would just return an I/O error instead).
The thing that finally fixed it… my trusty old Synology DS1512+ (running DSM 6.2.4-25556 Update 6). This has a secure erase option that after ~14 hours managed to get the drive back in to a usable state!
I’m not sure if the newer models would be able to do the same thing, based on my above findings with older motherboards I think it being older may have been an advantage in this case.
tl:dr I was able to unlock the drive using an ~11 year old Synology Diskstation.
Though we might not all have 11 year old boxes we can plug a drive into, glad you fixed your drive, and future peeps may find a similar fix with an old box they might have access to.
I hope anyone in a similar situation finds the above info, fingers crossed it’ll save them some time and stress!
I found a forum post elsewhere where someone with the same issue found that some old Dell PERC RAID adapter was able to do a secure erase operation to recover a drive, which is what reminded me to go dust off the old faithful Synology.
Just a couple of further notes. For the duration of the secure erase in the DS1512+ the drive stopped updating its temperature and the disk usage/transfer rate was showing as zero in DSM as if the drive was idle. I presume whatever operation the drive was doing was something handled internally, hence nothing meaningful being transferred over the SATA interface.
And some people will say not to collect old things that only gather dust.
One of the reasons why I personally prefer encryption without using hardware encryptors. Maybe performance is worse in some applications, but usually the encryption software won’t kill the hardware if something goes wrong.
The most important thing is that you were able to solve the problem.
Stumbled upon this thread searching for something different with HGST Enterprise drives that don’t 1:1 share the same commands as Opal standard, but have something to add.
While it’s good to know that Synology’s secure erase option can remedy this (I too have an old device, an 1813+ acting as the local backup for a newer 8-bay), I had the same issue with the current version of sedutil RESCUE bootable USB. With some older drives, not that the drive here is that old, but my SAS drives are, an older version of sedutil may resolve the issue.
So, if you happen to be using a controller card (like my LSI SAS3008) or board that doesn’t like to expose connected drives intended for raid (namely IR firmware) to UEFI, try sedutil RESCUE32 1.15.1-9 (which is BIOS not UEFI) and change your BIOS/UEFI boot mode to legacy or compatible. That combo sees my drives and I can work with their SED config.
