[SOLVED] SSD bricked after setting password with hdparm?

w4rum · 2017-01-14 23:45:32

Evenin'!

First of all, my hardware:

CPU: Intel i5-6600
GPU: AMD R9 280x
MB: ASRock H170 Pro4/D3
RAM: 2x GeiL Black Dragon RAM DDR3 1333MHz 4GB
HDD: Hitachi HDS721010CLA332 (1TB, connected via SATA3)
SSD: Intenso SSD Sata III (256 GB, connected via SATA3)

While trying to clear my SSD following the wiki instructions on how to clear SSD memory cells, I set the password using

hdparm --user-master u --security-set-pass password123 /dev/sdb

When I tried to follow up with

hdparm --user-master u --security-erase password123 /dev/sdb

the operation failed, returning

security_password: "password123"

/dev/sdb:
 Issuing SECURITY_ERASE command, password="password123", user=user
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 40 01 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Trying any other --security-* command yields the same results.
On rebooting, my motherboard points out that the HDD is locked, requesting the password. To my surprise, "password123" does not work, even though I double-checked that I did not make a typo while setting it. After three failed attempts, the master password was requested, which I do not know and doesn't happen to be the one I set earlier. So my system boots up after noting that the "HDD is locked".

When running my system with the SSD connected, my log gets spammed with

Jan 15 05:03:45 tim-desktop kernel: ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Jan 15 05:03:45 tim-desktop kernel: ata6.00: irq_stat 0x40000001
Jan 15 05:03:45 tim-desktop kernel: ata6.00: failed command: READ DMA
                                             res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
Jan 15 05:03:45 tim-desktop kernel: ata6.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 28 dma 4096 in
Jan 15 05:03:45 tim-desktop kernel: ata6.00: status: { DRDY ERR }
Jan 15 05:03:45 tim-desktop kernel: ata6.00: error: { ABRT }
Jan 15 05:03:45 tim-desktop kernel: ata6.00: configured for UDMA/133
Jan 15 05:03:45 tim-desktop kernel: ata6: EH complete

[... and later on ...]

Jan 13 23:02:22 tim-desktop kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L6F] (20160422/evgpe-592)
Jan 13 23:02:22 tim-desktop kernel: ACPI Error: [PGRT] Namespace lookup failure, AE_NOT_FOUND (20160422/psargs-359)
Jan 13 23:02:22 tim-desktop kernel: ACPI Error: Method parse/execution failed [\_GPE._L6F] (Node ffff88026c8d09b0), AE_NOT_FOUND (20160422/psparse-542)

hdparm reports that the drive is in "locked" state:

$ sudo hdparm -I /dev/sdb
/dev/sdb:

ATA device, with non-removable media
	Model Number:       Intenso SSD Sata III                    
	Serial Number:      HYC2016071902306    
	Firmware Revision:  O0617A  
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
	Supported: 9 8 7 6 5 
	Likely used: 9
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:    16514064
	LBA    user addressable sectors:   268435455
	LBA48  user addressable sectors:   500118192
	Logical  Sector size:                   512 bytes
	Physical Sector size:                   512 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:      244198 MBytes
	device size with M = 1000*1000:      256060 MBytes (256 GB)
	cache/buffer size  = unknown
	Nominal Media Rotation Rate: Solid State Device
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 2	Current = 2
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	   *	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	    	SET_MAX security extension
	    	Automatic Acoustic Management feature set
	   *	48-bit Address feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	WRITE_{DMA|MULTIPLE}_FUA_EXT
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Segmented DOWNLOAD_MICROCODE
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Gen3 signaling speed (6.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
	   *	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Software settings preservation
	    	Device Sleep (DEVSLP)
	   *	SANITIZE feature set
	   *	BLOCK_ERASE_EXT command
	   *	DOWNLOAD MICROCODE DMA command
	   *	WRITE BUFFER DMA command
	   *	READ BUFFER DMA command
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM
Security: 
	Master password revision code = 65534
		supported
		enabled
		locked
	not	frozen
		expired: security count
		supported: enhanced erase
	Security level high
	4min for SECURITY ERASE UNIT. 4min for ENHANCED SECURITY ERASE UNIT.
Device Sleep:
	DEVSLP Exit Timeout (DETO): 40 ms (drive)
	Minimum DEVSLP Assertion Time (MDAT): 31 ms (drive)
Checksum: correct

Trying to access the SSD in any way always fails.
Fdisk leaves a rather large gap where the SSD (/dev/sdb) should be listed:

$ sudo fdisk -l
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 66E03BFF-051E-4C58-B626-3101702C06E0

Device       Start        End    Sectors  Size Type
/dev/sda1     2048    1050623    1048576  512M EFI System
/dev/sda2  1050624 1953525134 1952474511  931G Linux LVM




Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xcd407128

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdd1  *       64 1953520063 1953520000 931.5G  7 HPFS/NTFS/exFAT

Writing to it with dd returns

dd: writing to '/dev/sdb': Input/output error

I've seen the master passwords for other drives published on other forums or blogs but I fail to find anything more specific to my drive.
I doubt that I could even use it if I found one, given that the controller doesn't seem to accept anything.

EDIT 1: Added another log entry.

Last edited by w4rum (2017-01-25 23:05:00)

Soukyuu · 2017-01-15 13:06:39

This looks like a badly programmed controller (either you mainboard's or the SSD's). I have encountered the "missing sense data" message on USB-HDD enclosures, where the controller didn't pass the commands correctly.
You could try setting/entering the password again on a different mainboard/controller, but other than... I'd RMA the SSD and get one from a more well-known brand (for SSDs at least).

w4rum · 2017-01-15 20:37:13

Well, seems that I'll contact the manufacturer and ask whether they can reset the drive. I'll update when I get the the drive back. Thanks for the advice!

Last edited by w4rum (2017-01-15 20:58:09)

R00KIE · 2017-01-19 14:45:57

I would be surprised that using the bios for unlocking the disk would work, you should still be able to unlock it once you manage to boot and connect the disk without expiring the attempt counter. See what the manufacturer says about your issue and if they don't want to help try to do the security erase on another machine.

frostschutz · 2017-01-19 14:57:10

I never use the HDD password (regardless hdparm or bios) because if nothing else, it's so easy to lock yourself out and there might be no way to recover.

Secure erase is superfluous either way. With SSD you can just do 'blkdiscard /dev/deletemyssd' and you won't see your data ever again. If that's not good enough or HDD, you can 'shred -v -n 1' the whole thing.

As for your issue, if power cycling the drive (while PC is running) in case it's frozen, and then issuing --security-erase-enhanced doesn't fix it ... there is not much you can do.

If your password was longer than 8 chars, you could try truncating it to 8 for a lark. (Even though it's supposed to be 32).

mich41 · 2017-01-19 22:16:22

frostschutz wrote:

Secure erase is superfluous either way. With SSD you can just do 'blkdiscard /dev/deletemyssd' and you won't see your data ever again.

SE is an overkill for just clearing a drive but it's not equivalent to TRIM. TRIM leaves readable data in physical flash chips until garbage collection time, SE doesn't/shouldn't.

frostschutz wrote:

If that's not good enough or HDD, you can 'shred -v -n 1' the whole thing.

Running shred on SSDs is pointless. It's no better than TRIM due to remapping in the disk and it only takes more time and wears out flash for no reason.

frostschutz · 2017-01-20 00:20:27

Secure Erase and TRIM is equivalent, in that you can't verify anything about either. It's a black box, what actually happens on a hardware level is not in your control and hard to verify.

shred on the entire SSD beats the black box by a long shot. Writing data irrecoverably displaces other data. SSD might shuffle things around a bit, but in the end it has to write somewhere. Thus, filling the entire SSD with randomness gives you so-and-such many flash cells worth of storage no longer holding data, and you can verify it easily even if you don't trust the hardware.

As for additional capacity and wear-balancing, that might survive but so what? How does that make it pointless entirely? It will be a tiny fraction (it's expensive, so 512G SSD might be 516G but not 1024G), and most likely that will be erased too anyhow, assuming the SSD wants to stay performant. Erase-before-write is order of magnitude slower than writing already erased blocks, so it's in the interest of the SSD to erase things sooner rather than later.

People make SSD out to be some kinda magic that refuses to delete your data no matter what you do, but the opposite is the case. SSD is better at deleting data than keeping it. SSD is happy to toss all your data away in an eyeblink. SSD are optimized for max performance, not max data remanence. Getting rid of data on HDD is certainly harder (and it takes much longer too).

Last edited by frostschutz (2017-01-20 00:23:07)

mich41 · 2017-01-20 13:22:20

OK, maybe not exactly pointless, but wear leveling may still play tricks on you. For example, by avoiding to use some block which has already seen more writes than others and picking the next one. By Murphy's law, this will work against you when you need it most

You are right that as long as firmwares are proprietary it's all black box and nothing can be verified, but SE is at least specified to render data unreadable for good while TRIM just isn't.

To put it simply, if you have a disk full of CP and you see the cops on your yard, you run SE, not blkdiscard. Write a convenience script for it now

frostschutz · 2017-01-20 14:13:27

mich41 wrote:

By Murphy's law, this will work against you when you need it most

If you're screwed even if only 8 bytes of anything survive, you should have used full disk encryption in the first place.

mich41 wrote:

To put it simply, if you have a disk full of CP and you see the cops on your yard, you run SE, not blkdiscard.

Whoa... Let's stick to selling disks on Ebay and not sell bank account statements and password databases along with it...

mich41 wrote:

Write a convenience script for it now

If you find a way to write one that works reliably without locking people out and without bricking devices (maintain a blacklist if nothing else works). Make it. It should be as easy as `secerase /dev/deletemyssd` and done. Seriously, hdparm is way too dangerous (both because the ata security itself sucks and it's a multi-step process in hdparm so user error is another thing to worry about).

As long as such program does not exist, blkdiscard is still better (due to sheer simplicity), and shred even more so. You can still attempt to Secure Erase on top of that, but only if you're willing to risk losing the device itself.

Last edited by frostschutz (2017-01-20 14:14:48)

w4rum · 2017-01-25 23:03:49

Alright, thanks for outlining the different alternatives to SE and the attached pros and cons! Always nice to learn related things when fiddling around with a very specific one.

I ended up RMA'ing the device. The manufacturer didn't give a lot of detail as to whether the controller was faulty or doesn't execute the command correctly by default. I was merely told that they suspect the device may be defective and that they'd sent me a new one in exchange for the supposedly broken drive, which they did, so I'm grateful to at least have a working SSD again. I'll probably abstain from trying specialized low-level operations on it again, given that there are few official specifications published for the device.

Glad to have tapped into the topic though, I'll mark the thread as solved.

Last edited by w4rum (2017-01-25 23:04:17)

R00KIE · 2017-01-27 12:05:55

w4rum wrote:

I ended up RMA'ing the device. The manufacturer didn't give a lot of detail as to whether the controller was faulty or doesn't execute the command correctly by default. I was merely told that they suspect the device may be defective and that they'd sent me a new one in exchange for the supposedly broken drive, which they did, so I'm grateful to at least have a working SSD again.

I'd say you have probably done some free testing for them and may have found a firmware bug. They don't want bad publicity so replacing the disk for free is not surprising

parity3 · 2018-02-23 19:49:29

Same thing happened to me with a sandisk extreme 64GB. Was able to unlock using

--security-disable NULL

Found out by googling and finding shadowmoo's post on tomsguide:
http://www.tomsguide.com/forum/id-18445 … nlock.html

V1del · 2018-02-23 20:31:32

Thanks for sharing, however since this is an older post that has been marked as solved, I'll close this one now.

Closing.

Arch Linux

#1 2017-01-14 23:45:32

[SOLVED] SSD bricked after setting password with hdparm?

#2 2017-01-15 13:06:39

Re: [SOLVED] SSD bricked after setting password with hdparm?

#3 2017-01-15 20:37:13

Re: [SOLVED] SSD bricked after setting password with hdparm?

#4 2017-01-19 14:45:57

Re: [SOLVED] SSD bricked after setting password with hdparm?

#5 2017-01-19 14:57:10

Re: [SOLVED] SSD bricked after setting password with hdparm?

#6 2017-01-19 22:16:22

Re: [SOLVED] SSD bricked after setting password with hdparm?

#7 2017-01-20 00:20:27

Re: [SOLVED] SSD bricked after setting password with hdparm?

#8 2017-01-20 13:22:20

Re: [SOLVED] SSD bricked after setting password with hdparm?

#9 2017-01-20 14:13:27

Re: [SOLVED] SSD bricked after setting password with hdparm?

#10 2017-01-25 23:03:49

Re: [SOLVED] SSD bricked after setting password with hdparm?

#11 2017-01-27 12:05:55

Re: [SOLVED] SSD bricked after setting password with hdparm?

#12 2018-02-23 19:49:29

Re: [SOLVED] SSD bricked after setting password with hdparm?

#13 2018-02-23 20:31:32

Re: [SOLVED] SSD bricked after setting password with hdparm?

Board footer