LW WD15EARS ist immer noch 'locked'

Hallo Nachlese,
die zusätzliche Verkabelung ist vorgenommen, die gelockte HD steht bereit.
Habe es nicht lange ausgehalten und komme dank Deinem Angebot auf Dich zurück - vorausgesetzt es ist noch ‘aktuell’. Hier die erste LW Abfrage:

[miro@i7c4 ~]$ sudo hdparm -I /dev/sdb
/dev/sdb:

ATA device, with non-removable media
	Model Number:       WDC WD15EARS-00Z5B1                     
	Serial Number:      WD-WMAVU1588304
	Firmware Revision:  80.00A80
	Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
	Supported: 8 7 6 5 
	Likely used: 8
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:  2930277168
	Logical/Physical Sector size:           512 bytes
	device size with M = 1024*1024:     1430799 MBytes
	device size with M = 1000*1000:     1500301 MBytes (1500 GB)
	cache/buffer size  = unknown
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, with device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Recommended acoustic management value: 128, current value: 128
	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
	    	Power-Up In Standby feature set
	   *	SET_FEATURES required to spinup after power up
	    	SET_MAX security extension
	   *	Automatic Acoustic Management feature set
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	64-bit World wide name
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Segmented DOWNLOAD_MICROCODE
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	Phy event counters
	   *	NCQ priority information
	   *	DMA Setup Auto-Activate optimization
	   *	Software settings preservation
	   *	SMART Command Transport (SCT) feature set
	   *	SCT Features Control (AC4)
	   *	SCT Data Tables (AC5)
	    	unknown 206[12] (vendor specific)
	    	unknown 206[13] (vendor specific)
Security: 
	Master password revision code = 65534
		supported
		enabled
		locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	Security level high
	336min for SECURITY ERASE UNIT. 336min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50014ee0ac954cf0
	NAA		: 5
	IEEE OUI	: 0014ee
	Unique ID	: 0ac954cf0
Checksum: correct
[miro@i7c4 ~]$
-----------------------

… na den Beitrag hast Du ja gut versteckt -
einfach so ein neuer Beitrag über den ich nur zufällig gestolpert bin
mit einem kryptischen Titel und nur für mich verständlichem Inhalt …

Wir kamen von hier

So wie ich verstanden habe was in den drei verlinkten Artikeln beschrieben wird ist es so, daß man eine so gesicherte Festplatte auf zwei Wegen wieder “entsichern” kann.
Der erste ist ganz offensichtlich: das Benutzer Passwort zu kennen und zu nutzen.
Das hast Du nicht mehr - hast Du gesagt.

Der zweite Weg ist der über das Master Passwort.

Das läßt sich (angeblich) einmalig setzen.
Dann kann es genutzt werden um die Platte zu entsichern und zu löschen, selbst wenn ein Benutzer Passwort gesetzt war.

Das ist die Prozedur, die ich versucht habe Dir zu erkären bzw Dich Schritt für Schritt da durch zu führen.
Dafür brauchte ich das Feedback - um zu sehen ob und was nach jedem Kommando passiert ist.
(der letzte Teil der Ausgabe von:

sudo hdparm -I /dev/sdb

was unter dem Punkt “Security” gelistet wird)

Security: 
	Master password revision code = 65534
		supported
		enabled
		locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	Security level high
	336min for SECURITY ERASE UNIT. 336min for ENHANCED SECURITY ERASE UNIT.

Diese Ausgabe bedeutet, daß noch das Hersteller default Passwort gesetzt ist,
daß die Sicherheitsfeatures aktiv sind,
daß die Platte “locked”, also nicht zugänglich ist,
daß sie nicht eingefroren ist,
daß und daß ein Passwort noch nicht zu oft falsch eingegeben wurde

Ich wollte nun das Hersteller Passwort setzen - in meinem Beispiel auf “geheim”.

sudo hdparm --user-master m --security-set-pass geheim /dev/sdb

Danach hätte in der obigen Ausgabe von
sudo hdparm -I /dev/sdb

die erste Zeile anders aussehen müssen:

Security: 
	Master password revision code = 1

Wenn Du bei einem erneuten Versuch bis dahin kommst, dann können wir weitermachen mit:

sudo hdparm --user-master m --security-unlock geheim /dev/sdb

danach wieder check was sich getan hat:

sudo hdparm -I /dev/sdb


Bisher war das aber nicht der Fall.
Also konnte das Master Passwort nicht gesetzt werden.

Und an dieser Stelle ist dann auch schon Schluß.

Man kann die Platte ohne eines der beiden Passworte nicht entsichern - und mit einer gesicherten Platte kannst Du nichts mehr anfangen.
Die ist dann nur noch ein Briefbeschwerer.

The End.

Erstaunliche, habe das LW gerade eingesteckt, sudo hdparm… Kommando eingegeben und folgendes kam heraus:

Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
Checksum: correct

jedoch nicht:
Security: 
	Master password revision code = 1

Keine Ahnung was sich geändert hat - jedenfalls sieht es für mich so aus als sollte sich die Platte ganz normal benutzen lassen.

Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked

Ja das sind die verwirrende Reaktionen des LW’s. Danke, ich probiere einiges - mal sehen.
Ende und erledigt.

Ich habe scheinbar nicht mitbekommen, daß die Verkabelung u.U. ein verursachender Faktor gewesen sein könnte für Deine Probleme mit der Platte - und daß Du daran was geändert hast.

Diese Bemerkung, die ja offensichtlich als Abschluß der Sache gemeint war, kann ich nicht eindeutig interpretieren.

Alles was mich dann doch ein wenig interessieren würde - nach all dem …:

Geht’s jetzt oder gehts nicht?

Cheers!

Danke Deiner Rückfrage, die zusätzliche Verkabelung war nötig wg. der SATA SDD die als /(root) hinzugefügt habe - da PCIe SSD nicht akzeptiert worden ist.
Danach passierte folgendes, die neue LW Aufteilung /dev/sda und /dev/sdc war bestätigt worden. Die hinzugefügte WD15EARS blieb als /dev/sdb unverändert.
Ich vermute, dass das NVRAM (BIOS-Speicher) die Bezeichnung von /sdb und /sdc vertauschte. Daraufhin behandelte hdparm die neu hinzugefügte SATA SSD mit neue Partition-Tabelle und löschte die /dev/sdc komplett!
Nachdem ich dieses, wohl bekanntes und uraltes Desaster repariert habe (Nach-Installation), habe ich die Platte sofort ohne Hemmung und rigoros entsorgt - sorry es war mir einfach zu viel - an den BIOS Speicher NVRAM - dachte ich zuerst nicht.
Meine Vermutung seit Urzeiten, dass das NVRAM an den vielen ‘Ungereimtheiten’ beteiligt ist, scheint sich zu bestätigen - s. Coreboot, Linux-Boot, u.v.a.
CU

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.