can't rekey my 2TiB WD

[arno01]

Hello @KenMacD !

I am really happy to find this repo and related docs.

Though, I am unable to rekey my WD (My Passport 0820, idVendor=1058, idProduct=0820).

Would you be able to help me?

Here is what dmesg throws when I am attaching it via a USB-3 cable http://pastebin.com/8GEjpfYi

And here is my attempt of rekey'ing it:

# echo -ne "\x45\x00\x00\x01\x30\x00\x00\x20" > reset.bin ; dd if=/dev/urandom bs=1 count=32 >> reset.bin
32+0 records in
32+0 records out
32 bytes copied, 0.000700187 s, 45.7 kB/s
# ls -la reset.bin 
-rw-r--r-- 1 root root 40 Feb 14 02:20 reset.bin
# head -c8 reset.bin |hexdump -Cv
00000000  45 00 00 01 30 00 00 20                           |E...0.. |
00000008

# sg_raw -r 32 /dev/sg2 c0 45 00 00 00 00 00 30 00
SCSI Status: Good 

Received 17 bytes of data:
 00     45 00 00 01 30 00 00 20  2c ec e6 d8 00 00 00 01    E...0.. ,.......
 10     30                                                  0

# sg_raw -i reset.bin -s 40 /dev/sg2 c1 e3 2c ec e6 d8 00 00 28
SCSI Status: Check Condition 

Sense Information:
 Fixed format, current;  Sense key: Illegal Request
 Additional sense: Invalid field in parameter list

# echo $?
5

I am always getting Invalid field in parameter list.

Any ideas?

I am running Ubuntu with Linux 4.4.0 and sg_raw 0.4.11 (2014-10-18).

Thanks in advance!

[KenMacD]

Okay, lets see about this status:

 45 00 00 01 30 00 00 20  2c ec e6 d8 00 00 00 01 30  

Signature: 45 Reserved: 00 00 Security Status: 01 (locked) Current Cipher ID: 30 (FDE) Reserved: 00 Password Length: 00 20 (in bytes) Key Reset Enabler: 2c ec e6 d8 Reserved: 00 00 00 Number of Ciphers: 01 Cipher[]: 30 (FDE)

Reset command: c1 e3 2c ec e6 d8 00 00 28

Op Code: c1 e3 Key Reset: 2c ec e6 d8 Reserved: 00 Parameter List Length 00 28 Control: ?? <--- Should be 00

Okay, so that's one thing, not sure if it's the full issue. I'll look at the reset header:

45 00 00 01 30 00 00 20

Signature: 45 Reserved: 00 00 Reserved/Combine: 01 <-- Should be 00 for FDE Cipher: 30 (FDE) Reserved: 00 Key Length: 00 20 <-- Should be 0 for FDE Key:[[random]] <-- Should be /dev/zero for FDE

Some of the FDE stuff is different, so give the above a try and let me know if it helps.

[arno01]

It didn't help :/

# echo -ne "\x45\x00\x00\x00\x30\x00\x00\x00" > reset.bin ; dd if=/dev/zero bs=1 count=32 >> reset.bin
32+0 records in
32+0 records out
32 bytes copied, 0.00048301 s, 66.3 kB/s
# hexdump -Cv reset.bin 
00000000  45 00 00 00 30 00 00 00  00 00 00 00 00 00 00 00  |E...0...........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00                           |........|
00000028

# sg_raw -r 32 /dev/sg2 c0 45 00 00 00 00 00 30 00
SCSI Status: Good 

Received 17 bytes of data:
 00     45 00 00 01 30 00 00 20  97 1a 95 55 00 00 00 01    E...0.. ...U....
 10     30                                                  0

# sg_raw -i reset.bin -s 40 /dev/sg2 c1 e3 97 1a 95 55 00 00 28 00
SCSI Status: Check Condition 

Sense Information:
 Fixed format, current;  Sense key: Aborted Command
 Additional sense: No additional sense information

# echo $?
11

[KenMacD]

Hmm... okay, I see that I missed that only the key-length of bytes is sent with the reset.bin. Could you try it with just the 8 byte header, and no follow-up bytes?

Also I'm on freenode as kenny if you want to drop on there for a faster back and forth. Here works too though.

[arno01]

8 bytes header

# echo -ne "\x45\x00\x00\x00\x30\x00\x00\x00" > reset.bin
# ls -la reset.bin 
-rw-r--r-- 1 root root 8 Feb 14 16:49 reset.bin

# sg_raw -r 32 /dev/sg2 c0 45 00 00 00 00 00 30 00
SCSI Status: Good 

Received 17 bytes of data:
 00     45 00 00 01 30 00 00 20  78 f9 21 5a 00 00 00 01    E...0.. x.!Z....
 10     30                                                  0

# sg_raw -i reset.bin -s 8 /dev/sg2 c1 e3 78 f9 21 5a 00 00 28 00
>>> transport error: Host_status=0x07 [DID_ERROR]
Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]

SCSI Status: Good 

# echo $?
99

After that, unplug/plug => is still lockedSense Key : Data Protect [current]

8 bytes header + modified PARAMETER LIST LENGTH

Here I have set PARAMETER LIST LENGTH to 08 as size of reset.bin is 8 bytes. Let me know if this was correct to do ?

# sg_raw -r 32 /dev/sg2 c0 45 00 00 00 00 00 30 00
SCSI Status: Good 

Received 17 bytes of data:
 00     45 00 00 01 30 00 00 20  4e c0 ee 0c 00 00 00 01    E...0.. N.......
 10     30                                                  0

# sg_raw -i reset.bin -s 8 /dev/sg2 c1 e3 4e c0 ee 0c 00 00 08 00
SCSI Status: Check Condition 

Sense Information:
 Fixed format, current;  Sense key: Aborted Command
 Additional sense: No additional sense information

# echo $?
11

Still locked ...

Edit

I have made a "one-liner" for easier use :-) Since I've been trying different approaches...

8 bytes header only

# KRE="$(sg_raw -r 32 /dev/sg2 c0 45 00 00 00 00 00 00 30 00 2>&1 | grep '^ 00' | awk '{print $10,$11,$12,$13}')" ; python -c "print('45 00 00 00 30 00 00 00')" | xxd -r -p > reset.bin ; sg_raw -i reset.bin -s $(stat -c %s reset.bin) /dev/sg2 c1 e3 $KRE 00 00 28 00

8 bytes header + 32 bytes of repeated XX XX XX XX (from device's PRNG)

# KRE="$(sg_raw -r 32 /dev/sg2 c0 45 00 00 00 00 00 00 30 00 2>&1 | grep '^ 00' | awk '{print $10,$11,$12,$13}')" ; python -c "print('45 00 00 00 30 00 00 00'); print('$KRE' * 8);" | xxd -r -p > reset.bin ; sg_raw -i reset.bin -s $(stat -c %s reset.bin) /dev/sg2 c1 e3 $KRE 00 00 28 00

[KenMacD]

Good call on changing the length... odd it didn't work though, it looks right.

Have you tried compiling wdutils.c and running it with erase /dev/sg2 FDE?

[arno01]

I have been trying wdutils, but neither it helped :/

Here is my outputs:

# ./wdpassport-utils/wdutils dump /dev/sg2
wdutils: Handy Store size 16 blocks * 512B (max transfer size 1 block)
SecurityState=1 (Locked), CurrentCipherID=30 (FDE)
PasswordLength = 32
KeyResetEnabler = 7C 37 C8 24
1 supported ciphers: 30 (FDE)
wdutils: Wrong HSB1 signature 
wdutils: Handy Store Block 1 is not readable (error = 1)
wdutils: Wrong HSB2 signature 
wdutils: Handy Store Block 1 is not readable (error = 1)
-- MODE PAGE 0x20, length=6
ParamSavable = true
Signature=0x30 (&0x00)
DisableAP = false (ro)
DisableCDROM = true (rw)
reserved3 = 0x08 (&0x08)
DisableSES = false (rw)
TwoTBLimit = false (ro)
DisableWhiteList = false (ro)

-- MODE PAGE 0x21, length=10
ParamSavable = true
Signature=0x30 (&0x00)
eSATA = false (ro)
LooseSB2 = false (ro)
enableCDEject = false (rw)
CDMediaValid = true (rw)
reserved4 = 0x00 (&0x04)
powerLEDBrite = 0xFF (rw)
backlightBrite = 0x00 (ro)
whiteOnBlack = false (ro)

# ./wdpassport-utils/wdutils erase /dev/sg2 FDE
Do you want secure erase ? (write 'YES!'): YES
# echo $?
0

# sg_raw -r 32 /dev/sg2 c0 45 00 00 00 00 00 00 30 00
SCSI Status: Good 

Received 17 bytes of data:
 00     45 00 00 01 30 00 00 20  95 2f a9 29 00 00 00 01    E...0.. ./.)....
 10     30                                                  0

# lsusb |grep West
Bus 003 Device 025: ID 1058:0820 Western Digital Technologies, Inc. My Passport Ultra (WDBMWV, WDBZFP)

# ./usbreset /dev/bus/usb/003/025
Resetting USB device /dev/bus/usb/003/025
Reset successful

# ~~~ Checking status after USB reset (also after USB re-plug in another session), says it is still locked :/ ~~~
# sg_raw -r 32 /dev/sg2 c0 45 00 00 00 00 00 00 30 00
SCSI Status: Good 

Received 17 bytes of data:
 00     45 00 00 01 30 00 00 20  ac 09 c8 28 00 00 00 01    E...0.. ...(....
 10     30                                                  0

For some reason wdutils dump /dev/sg2 says that I have wrong HSB1 & HSB2 signatures ...

Maybe a little history will help, the device has been attempted to --security-erase (by hdparm) or --security-erase-enhanced I cannot remember exact commands I have been using :/ This happened last August. And the process was taking really long, so I did a very stupid thing -> disconnected a USB3 cable... that rendered this device to its current state, so I thought re-keying would help.

Let me know if you have some ideas why wdutils dump shows wrong HSB1, HSB2 signatures?

Would you want me taking a photo of HDD's PCB back part ? and top ? :-)

[KenMacD]

Hmm... it should ask you for a new password after that. Did you try YES! (or you can change that line in the code, but then it won't ask you to confirm).

[arno01]

My my ! I think I've spent too much of my time with luksFormat, where it was required typing "YES" without exclamation mark :-D

Though, it didn't help ... :/ am I doing something wrong? :-)

# ./wdutils erase /dev/sg2 FDE
Do you want secure erase ? (write 'YES!'): YES!
Enter new device password: 
Repeat new password: 
wdutils: Wrong HSB1 signature 
wdutils: Unreadable HSB#1 (cc=1), trying default
wdutils: Device status: 01 (Locked)
# echo $?
1

# ./wdutils unlock /dev/sg2
Enter device password: 
wdutils: Wrong HSB1 signature 
wdutils: Unreadable HSB#1 (cc=1), trying default
wdutils: Device status: 01 (Locked)
# echo $?
1

Edit as the password, I've tried 123 and just empty (hit Enter). neither one worked...

[KenMacD]

I'm not sure on the HSB1/HSB2. I've never tried them on drives using the FDE cipher, so maybe they're different. Could you try commenting out the loading of that. I don't think it's actually needed for a secure erase. The lines would be:

https://github.com/KenMacD/wdpassport-utils/blob/master/wdutils.c#L663-L671

[arno01]

Removed the lines, recompiled. Trying on a replugged device.. still KO.

# ./wdutils erase /dev/sg2 FDE
Do you want secure erase ? (write 'YES!'): YES!
Enter new device password: 
Repeat new password: 
wdutils: Device status: 01 (Locked)
# echo $?
1

I have some feeling that something important got overwritten on my drive... I was wondering, could it be a 3907024928 sector ? I've found somewhere on the Internet, they say, that the key is located there. Though, maybe not that particular sector.

[KenMacD]

I don't know... after that command it should have switched to unlocked. It does in non-FDE drives.

At this point I'd be tempted to bring up a little XP virtual machine and trying the true utilities in there. (https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/#downloads)

[arno01]

@KenMacD yep, I can launch Windows 10 in a VM and passthrough the USB3 (USB3 should be OK nowadays I think) there. :-) I will try that, meanwhile, do you have some links to some SW for WD Passport Ultra that I could try? Or some other interesting tools? :-)

[KenMacD]

You mean other than the WD utils? (https://support.wdc.com/downloads.aspx?DL)

I don't really. I just took apart the utilities to figure out what they were doing, and it works well enough for me (although I pretty much only unlock day-to-day). I'm not sure what exists for other utilities.

Please let me know if it ends up working in Windows.

[arno01]

Sure, I will keep posted!

And much thanks for your promptness! :-)

[DanLukes]

On 14.2.2017 17:24, Andrey Arapov wrote:

My Passport 0820, idVendor=1058, idProduct=0820

OK, guys, now my turn. And no good news for you.

Well, I have no same My passport here, but I have My Passport 259B, idVendor=1058, idProduct=259B instead.

It is FDE kind of My Passport.

Output of wdutils dump is almost the same.

I can lock, unlock and erase WD using my ./wdutils utility.

For some reason wdutils dump /dev/sg2 says that I have wrong HSB1 & HSB2 signatures ...

Yes, those special sectors are empty on FDE kind of disc, thus "no signature" announcement. It's not sign of error of any kind - it just claim the fact that those sector are empty. HSB1 sector is not used on FDE disc.

Maybe a little history will help, the device has been attempted to --security-erase (by hdparm) or --security-erase-enhanced I

Lets bad news begin here.

Well, it IS important. According my observation, the proprietary WD locking and data encryption is build on top of standard WD disc. I will call it WDS layer in the future. The service data of WDS are stored on disc itself, but some of them may be stored inside of controller chip.

Standard disc behind supports standard security features. I will call it SEC layer in future text.

You claimed you used 'security-erase', It's not possible to use such command unless security is enabled. And security can't be enabled unless SEC password is set. Thus I assume you configured SEC password and enabled security (it's not enabled by default).

SEC lock can be removed by either unlock, or by security erase procedure (which must not be interrupted). As you interrupted the procedure, the drive is still locked at SEC level. Neither read nor write to media is allowed because of it.

It mean the WDS layer above can neither read or write it's service data saved on medium - medium is not accessible because of SEC block.

Unfortunately, you can't unlock SEC layer, even if you know the correct password - as long as WDS layer is blocked, no command is passed thru, thus no command can reach the SEC engine.

Conclusion ?

IF you know the correct WDS password AND the WDS layer can verify it even with no access to the underlying media (still locked by SEC layer) THEN You may have luck. [A] Unlock the WDS layer, then [B] disable SEC (either by correct password or by security-erase procedure), then [C] run FDE erase - it may recover required structures on media erased by SEC erase procedure.

Warning - DO NOT disconnect or power off the WD drive until all three steps (A-B-C) become completed. Note that SEC security erase will take long time (all sectors will be rewritten) while WDS erase is fast (it generate new encryption key only). ELSE You are out of luck. WDS lock blocks your access to SEC engine, which in turn blocks WDS access to media. As long as WDS require access to media to unlock self, it is dead-lock with no software recovery known.

Well, I'm just guessing, so I may be wrong.

But the analysis is based on my best knowledge of WD Passport implementation.

I tried to analyze WDS<->SEC interactions few years ago, but I interrupted such activity because it's so easy to brick the device, moreover, the results depends on exact chip used as well as firmware version.

Yes, I has been lucky, my drive has been successfully recovered by A-B-C sequence described above.

I wish not to test it again with my current drives.

Dan

[KenMacD]

Thanks @DanLukes. Quick question for you. Does it make sense for the SecureErase() to be calling ReadHandyStoreBlock(), if it not available in FDE, and isn't used anywhere else in the erase?

[arno01]

@DanLukes it's great to read your comment here! very insightful, thanks!

I have not been using "My Passport" SW to touch the proprietary encryption layer (WDS), since at that time I had no clue that they (WD) implemented it at all ... :/

The way I was running security-erase back then:

#hdparm --user-master u --security-set-pass passw0rd /dev/sdb
#hdparm --user-master u --security-erase passw0rd /dev/sdb

Now, I have re-plugged the MP (My Passport) and executed the following commands, but I am getting SG_IO: bad/missing sense data -- is this normal? Is this a WDS chip locking me out now?

# hdparm --security-unlock "passw0rd" /dev/sdb
security_password: "passw0rd"

/dev/sdb:
 Issuing SECURITY_UNLOCK command, password="passw0rd", user=user
SG_IO: bad/missing sense data, sb[]:  70 00 07 00 00 00 00 0a 00 00 00 00 74 71 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

# hdparm --security-disable "passw0rd" /dev/sdb
security_password: "passw0rd"

/dev/sdb:
 Issuing SECURITY_DISABLE command, password="passw0rd", user=user
SG_IO: bad/missing sense data, sb[]:  70 00 07 00 00 00 00 0a 00 00 00 00 74 71 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 07 00 00 00 00 0a 00 00 00 00 74 71 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

# hdparm --user-master u --security-erase passw0rd /dev/sdb
security_password: "passw0rd"

/dev/sdb:
 Issuing SECURITY_ERASE command, password="passw0rd", user=user
SG_IO: bad/missing sense data, sb[]:  70 00 07 00 00 00 00 0a 00 00 00 00 74 71 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 07 00 00 00 00 0a 00 00 00 00 74 71 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 07 00 00 00 00 0a 00 00 00 00 74 71 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

And what would be the proper command to reset & disable the security when the key is forgotten/lost? (is there such an option at all?)

Thanks!

Edit So IIUC, the disrupted secure-erase caused the drive to lock on a SEC level, which (potentially) in turn caused the important service data/sector (probably the last sectors of the drive which are supposed to be accessible only by the chip) be unreadable by the chip. Then, having that, the WD utils show 01 - Locked NOT because it was locked at the WDS layer (since I was not using any WD tools to lock it), but because the WDS layer just sees some unreadable (randomized) data in the service sector? Pff... if this is true, then I would remain wondering, why did not they implemented some kind of protection against issuing secure-erase / lock or a on-chip service data to recover from this situation?

[arno01]

@KenMacD meanwhile, I have tried the following in Windows 10 (in VM):

- WD SES Driver (64-bit)  <-- I think I didn't need to have it installed as mentioned there, though...
- WD Security 1.4.0.92   <-- 5 bad password attempts, suggested to Erase Drive using WD Drive Utilities
- WD Drive Utilities 1.4.0.92  <-- 5 bad password attempts, drive Erase Failed.
- Data Lifeguard Diagnostic v1.31  <-- could not read SMART, and immediately tells that disk has bad blocks
- WD Universal Firmware Updater 3.2.5.1  <-- to update FW, it asked me for the passphrase, 5 bad attempts, then offered me a Drive Erase which, again, failed ... probably due to SEC WD locking mechanism as Dan mentioned before.

So no much luck with Windows 10... which is obvious, after Dan's comment regarding the possibility that device is locked on a SEC layer (drive-level) which makes the WDS layer (chip on a PCB) unable to read the service data/sector.. :/ If someone is interested, the way I was passing the USB3 device through was the following:

(lsusb) Bus 003 Device 037: ID 1058:0820 Western Digital Technologies, Inc. My Passport Ultra (WDBMWV, WDBZFP)

$ sudo qemu-system-x86_64 -enable-kvm -M q35 -m 1G,slots=4,maxmem=4G -boot order=c -drive file=win10-installed.qcow2,format=qcow2,if=ide,media=disk -device nec-usb-xhci,id=xhci -device usb-host,bus=xhci.0,vendorid=0x1058,productid=0x0820

Edit I forgot to mention, that the WD Universal Firmware Updater has detected my FW v1.012, offering me an update to v1.022 FW. But it did not change the result, since it wanted to erase the drive without success as mentioned before. So I see the only way is to reset/erase the drive in a way that SEC is not locking it (without WDS preventing the SEC disabling act)... not sure if it's possible on the SW level now, since hdparm security-erase throws SG_IO now... :/

[DanLukes]

On 15.2.2017 1:49, Andrey Arapov wrote:

I have not been using "My Passport" SW to touch the proprietary encryption layer (WDS), since at that time I had no clue that they implement it ... :/

But such layer report self to be "Locked" which is not default state. Unless you locked it unintentionally, it may mean the WDS layer consider self locked as consequence if inaccessible media (because of SEC layer lock).

In such case it's pure dead-lock. WDS layer consider self locked as a result of SEC lock active and SEC layer lock can't be removed because commands can't pass thru WDS layer with active lock.

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

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

Now, I have re-plugged the MP (My Passport) and executed the following commands, but I am getting ``SG_IO: bad/missing sense data`` -- is this normal? Is this a WDS chip locking me out now?

Yes, as far as I know.

All Security layer commands are inaccessible because of WDS lock active.

And what would be the proper command to reset & disable the security if the key is forgotten? (is there such an option at all?)

You are using proper command for such purpose, but soch command is rejected by other layer (WDS).

Well, the WD USB drive is casual drive with additional WDS protection layer implemented on to of it. Unfortunately, WD doesn't considered properly interactions between this layer and standard SEC layer of underlying disc. In the fact, it seems WD doesn't expect the SEC feature will be used here at all.

It can be considered design/firmware bug. As long as the device is covered by warranty, the replacement may be most easiest way to recover it. Contact seller or visit

http://support.wdc.com/warranty/warrantystatus.aspx?lang=en to check you are eligible to ask replacement directly from WDC.

But remember, it's still possible I'm completely wrong.

Thus, before you consider to continue with further steps, download original WDC Security aplication and try to unlock device by it. Yes, you need to have Windows for it, but I'm sure you have some around ...

If even vendor original utility will fail to unlock, it's time for RMA.

Dan

[DanLukes]

On 15.2.2017 1:16, Kenny MacDermid wrote:

Does it make sense for the SecureErase() to be calling ReadHandyStoreBlock(), if it not available in FDE, and isn't used anywhere else in the erase?

Well, the code reads the HSB1 block, but it doesn't fail even if unavailable. It assume "reasonable defaults inside" instead.

Moreover, in the case of FDE, the result is not used at all, thus it doesn't make sense - but it doesn't harm.

Dan

[DanLukes]

On 15.2.2017 1:56, Andrey Arapov wrote:

• WD Drive Utilities 1.4.0.92 <-- 5 bad password attempts, drive Erase Failed.

It's final and authoritative result. Apply for replacement.

• Data Lifeguard Diagnostic v1.31 <-- could not read SMART, and immediately tells that disk has bad blocks
• WD Universal Firmware Updater 3.2.5.1 <-- to update FW, it asked me for the passphrase, 5 bad attempts, then offered me a Drive Erase which, again, failed ... probably due to SEC WD locking mechanism as Dan mentioned before.

S.M.A.R.T commands as well as firmware upgrade commands are blocked by WDS lock, thus both results are not surprising here.

But before you will send your drive for replacement, do simple test for me.

Use wdutils writehsb to write any data to a HSB block. It's safe operation (not only because your drive is broken already, but because HSB blocks are not used on FDE model at all). Then try to read them (wdutils readhsb).

Because of WDS lock, the write command should be rejected with ASC 74,71 (Logical unit access not authorized) but read command should be successful (HSB reads are excluded from WDS lock). Of course, you will receive "empty block" as write has failed.

Lets me know, if you observe different behavior. Specifically, I'm interested to know the readhsb will be completed with no error.

Thanks

Dan

[arno01]

@DanLukes thanks for the explanation, so the drive is under WD warranty until 2018 ! But I will try to reclaim it in the local shop first, where I bought it.

I have tried to writehsb & readhsb here https://gist.github.com/arno01/2b52928909ae49841b6d5079e4930440

And I have noticed, that reading HSB from sector 0 up to sector 15 is always returning 512 bytes of zeroes. Reading any other block would return the following https://gist.github.com/arno01/7516e5c8855de840885e245e22921129

What is strange or maybe is normal (since on-board PRNG is playing its role probably?) - is that reading the same sector multiple times, gives different output, you can see it here https://gist.github.com/arno01/7516e5c8855de840885e245e22921129 (The only first 17 bytes remain the same of course)

Thanks

[arno01]

As mentioned in got HW crypto? paper, I have also thought of enforcing the "blind mode" by shorting the data IN (DI) or data OUT (DO) pins of the EEPROM to ground in order to bypass USB chip and directly access the drive and reset ATA-password. But that would likely void the warranty. And yet, I am not sure whether I am having the U14 on the PCB (I am going to send my drive out tomorrow for the replacement)

[DanLukes]

On 15.2.2017 11:28, Andrey Arapov wrote:

I have tried to writehsb & readhsb here https://gist.github.com/arno01/2b52928909ae49841b6d5079e4930440

And I have noticed, that reading HSB from sector 0 up to sector 15 is always returning 512 bytes of zeroes.

Yes, those sectors are unused and empty on FDE kind of drive, thus full of zeroes (untill you write something other to them).

But the matter is - they are readable. So, they are not stored on media (which is inaccessible because of SEC lock) but they are stored within chip controller itself, or I my analysis is wrong and I missed the true issue cause.

Did you tried writehsb as well ?

And reading any other block, is returning the following https://gist.github.com/arno01/2b52928909ae49841b6d5079e4930440

There are only 16 HSB sectors (e.g. 0..15). Attempt to read other should fail.

What is strange or maybe is normal (since on-board PRNG is playing its role probably?) - is that reading the same sector multiple times, gives different output, you can see it here https://gist.github.com/arno01/7516e5c8855de840885e245e22921129 (The only first 17 bytes remain the same of course)

Skilled eye doesn't consider those data random ;-)

It's "drive security status block":

45 00 00 01 30 00 00 20 f2 59 52 bd 00 00 00 01 30 E r r S C r -p- --code--- r r r # L

where 'E' is signature, S security State (01=Locked), C is cipher scheme (30 = FDE), p is password length, code is current key reset enabler code, # is number of ciphers supported and L is list of ciphers supported (30=FDE), r are reserved bytes

Yes, rest of sector is random garbage.

Well, those attempt to read nonexistent HSB sectors require further analysis. I will spent some time on it later.

Dan

[DanLukes]

On 15.2.2017 12:19, Andrey Arapov wrote:

As mentioned in got HW crypto? paper, I have also thought of enforcing the "blind mode" by shorting the data IN (DI) or data OUT (DO) pins of the EEPROM to ground in order to bypass USB chip and directly access the drive and reset ATA-password. But that would likely void the warranty. And yet, I am not sure whether I am having the U14 on the PCB (I am going to send my drive out tomorrow for the reclamation)

Yes, I'm familiar with such paper, although I never tried to follow it. Unfortunately, there are so many hardware revisions of WD drive (sold under the same product name) and different chips and wiring on it.

Some USB<->ATA bridges may not have external EEPROM (but internal instead, thus no way to sort pins). Well you still can identify the SATA bus wires behind the bridge and you may be able to connect here - and then you may use secure-erase to wipe SEC lock.

But it's hardcore hacking ;-)

Dan

[arno01]

@DanLukes I was able to read E r r S C r -p- --code--- r r r # L even before the legend explanation you gave :D (probably thanks to my interest in cryptography & reading through the got HW crypto? paper :D)

Yeah, the data does not look random, but it was changing every read attempt (and .. not sure .. but I think it never repeated).

Yes, I have been trying to writehsb into 0..15 sectors, but readhsb always returned zeroes.. (writehsb is at line 3 https://gist.github.com/arno01/2b52928909ae49841b6d5079e4930440#file-gistfile1-txt-L3 )

Anyway, I have returned the drive back, they (shop) have taken it pretty much without questions :D and I've got a brand new My Passport Ultra Metal one :-]

I would like to thank you guys for your participation and helping me digging into this deeper!

Feel free to close this issue.

[DanLukes]

On 16.2.2017 12:31, Andrey Arapov wrote:

Yeah, the data does not look random, but it was changing every read attempt (and .. not sure .. but I think it never repeated).

The "Security Status" doesn't change every read (well, key reset enabler code is random, but it's intentional).

The rest of sector is random, but not in the term of PRNG - it's just random piece of internal memory.

Yes, I have been trying to writehsb into 0..15 sectors, but readhsb always returned zeroes.. (writehsb is at line 3 https://gist.github.com/arno01/2b52928909ae49841b6d5079e4930440#file-gistfile1-txt-L3 )

But you hot no error. Either the wdutils are buggy, or there's something other suspicious ...

Anyway, I have returned the drive back, they (shop) have taken it pretty much without questions :D and I've got a brand new My Passport Ultra Metal one :-]

I assumed this scenario.

Dan