OXUF943SE info

[ojfd]

themaddoctor, I have MyBook Studio Firewire enclosure with Oxford Semi OXUF943SE chip and I have gained quite a bit of knowledge about it during past few months (SInE blob locations etc.). In your FAQ you mention that there is not a lot of information regarding this chip's implementation. Since there isn't email address provided anywhere, please post what pieces of puzzle are you missing. I don't wan't to spam the issues page with excessive information that maybe nobody would read.

These two screenshots are from the freshly initialized 2TB WD Green drive, no password set. Drive connected to machine (Mac) via generic USB adapter. Blobs are on the part of the drive that is seen by the system as a read only CDROM, when it is in WD MyBook enclosure.

Cheers,

[themaddoctor]

The important bits of information which are relevant to this project and which are missing are

• keyblock locations for any sizes other than 3TB
• where the keyblock is kept on those disks for which it is not on the disk (EEPROM, service module, or wherever)

Your screenshots indicate that you are showing blocks from a partition. Can you give the block numbers FROM THE BEGINNING OF THE DISK, rather than from the beginning of the partition?

I don't have many samples from disks with OXUF chips. To save me some time typing, could you copy-paste the hex values for your keyblock into a comment? And could you do the same for block 0, so that I can test whether I correctly decrypt it?

Thank you.

[themaddoctor]

Also, please, what other interesting things have you learned?

[ojfd]

keyblock locations for any sizes other than 3TB

For that I have to re-flash the board with original firmware and format the drives I don't mind experimenting with** using WD utilities. Also, to be 100% sure, each time the drive is changed, the controller board has to be flashed anew, since it gets its serial number from the drive's serial number in the process and I suspect it plays role in creation of contents of the SInE blob ***, and, maybe its location. On my 2 TB drive they were at the end of the drive, in the last 48 blocks. The virtual CD occupies around 30 MB in my case.

** I don't trust WD utils. They load various kexts during formatting and I'm not sure if they don't write something to the drive's firmware (if it is a WD drive) in the process. I think I have 4TB and 6TB Red drives with bad blocks, I could try those. *** During my experiments I used abc123 password, like the author of 'Got crypto' paper did and, IIRC, my SInE blob looked different than his.

where the keyblock is kept on those disks for which it is not on the disk

I don't quite understand the question. If by that you mean where else SInE related code/strings show up, then it is 2 to 6 times in various WD OXUF943 firmware files. In case of my device (111D), two more are written to EPROM when board is flashed. Whether they change when password is set, needs to be verified by examining the before/after dumps.

Please do not try to compare the SInE blob contents below with those from my previous post, these might be from different experiment.

Your screenshots indicate that you are showing blocks from a partition.

No, I think they are from the beginning of the disk. I am on a Mac and diskutil gives me the same numbers.

/dev/disk2

: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *2.0 TB disk2 1: EFI 209.7 MB disk2s1 2: Apple_HFS Unencrypted 2.0 TB disk2s2

Device Identifier: disk2 Device / Media Name: WDC WD20 EARX-00PASB0 Media Total Size: 2.0 TB (2000398934016 Bytes) (exactly 3907029168 512-Byte-Blocks)

Device Identifier: disk2s1 Device / Media Name: EFI System Partition Total Size: 209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Blocks)

Device Identifier: disk2s2 File System: Journaled HFS+ Total Size: 2.0 TB (2000021315584 Bytes) (exactly 3906291632 512-Byte-Blocks)

I used this excellent tool in my experiments, btw. https://apps.tempel.org/iBored/ Try it, he has Linux version too.

could you copy-paste the hex values

Sorry, I can't. That part is already overwritten with zeroes. Same goes for block '0'. The drive is in unencrypted state now. ;)

If it is really important and you want me to conduct experiments (time permitting), then, please, set the exact methodology.

what other interesting things have you learned?

Found out blocks responsible for hiding virtual CD from OS. Controller reads it from there. Also, it appears that controller on its own can write to partition that is occupied by virtual CD, which the OS thinks is read only! After writing all zeroes to that partition and examining it a few minutes later by connecting disk to generic USB again, I found some bytes here and there written to it. Almost any drive can be used with WD controller board. I've tried non-original WD Reds, HGST, Seagate, 2.5 inch drives and SSDs. If I remember anything else that's relevant to this topic that I've missed, I'll post. Otherwise - just ask.

Please bear in mind, I'm on a Mac and I'm approaching this OXUF943 issue from a different angle - I'm fighting that mandatory encryption, so that the problem with data recovery/decryption is not created in the first place. Btw, I can brick my WD MyBook Studio (in its original state with password set) in no time. One failed firmware update and it is toasted.

[themaddoctor]

OK, to clarify:

Most people who have asked for help to decrypt their drives with the OXUF chip are unable to find their keyblocks. In other words, the keyblock is not on the magnetic portion of the disk. We usually been unable to find them on the user-accessible portions or in the service modules. Reading an EEPROM is beyond the abilities of most people, who are just computer users and not computer builders. Nevertheless, it may be useful for me to know where they are written to the EEPROMs, someday.

I thought you might be reading only a partition, because of the title in the top bar of the app in the screenshot. Your block number doesn't match our best guess based on the locations for other chips. They always seem to be the same distance apart, so the JMS chip's keyblock will always be X number of blocks from the Simwave's keyblock, for a given disk size. Now that I know the 2TB and 3TB OXUF keyblock locations, it seems that they break the pattern.

---

I don't know of any official check on the decryption of the DEK for the OXUF chip. So you could extract a DEK using any KEK. They won't be the same, however, and only one is the correct one. I see that yours looks very different from the sample in "Got HW Crypto?". However, I do have two samples from others (with 3TB disks), and when I decrypt the keyblock to get the DEK, there is a long string of zeroes. The same is true for the sample from Got HW Crypto? if I use their password. I do not see the same when I do your keyblock, either with pi or with the password. Having an encrypted sector 0 would come in handy at this point, to check the DEK. (Do you have any encrypted sectors available?)

The reason that keyblocks come in pairs is that the OXUF chip writes a backup. That backup is not changed when the password is changed the first time, so it can be used to recover the old DEK. Got HW Crypto? mentions that, as you must know.

If I can ask you to do anything, it would be this: for the 4TB and 6TB disks, first find the original keyblocks and their locations, and a copy of (encrypted) sector 0. They might not use the OXUF chip; you didn't say. But whatever chip, I'd like to see that info. Then, if you can turn them into OXUF-based drives (it sounds like you can, with the bridge card and the WD utils), also find the keyblocks and locations. I would prefer that you don't use a password, if that is possible. Otherwise, continue to use abc123. When the disk encryption is set up, write a bunch of zeroes to some place. Then read that place back with the generic enclosure. That will give me a good check on the DEK.

BTW, my 4TB MyBook (JMicro chip) contained a disk that was not branded as WD. Hitachi, if I remember correctly.

Thanks/Cheers/Mahalo

[ojfd]

If I can ask you to do anything, it would be this: for the 4TB and 6TB disks, first find the original keyblocks and their locations, and a copy of (encrypted) sector 0. They might not use the OXUF chip; you didn't say. But whatever chip, I'd like to see that info.

There must be some error in our communication. ;) The 4TB, 6TB and 2TB drives are all plain stock drives, as bought in the shop. They don't have any 'keyblocks' - i.e. blocks that start with 'SInE' anywhere, prior to formatting them with either regular system tools, WD Quick Formatter or WD SmartWare, while being attached to WD MyBook bridge board containing OXUF943SE chip. Also, they don't have any OXUF chips on their own controller boards.

If I take any drive that has been used in a regular way on a Mac/Win/whatever and connect it to WD MyBook bridge board containing OXUF943SE chip, system sees it as unformatted. If I look at it with iBored tool mentioned above, all I see is garbage. That all is because of the so called 'transparent encryption' - 943 chip "decrypts" what used to be a valid data into nonsense. The opposite is also true - if one connects the drive that has been formatted and used inside stock WD MyBook/Passport enclosure to computer via plain SATA or USB adapter, system also sees it as unformatted. This is what has bitten so many MyBook users out there.

This is what I would suggest.

1. I start with 4TB drive
2. Write about 100MB of zeroes starting with block 0, while connected to computer via SATA/USB adapter.
3. Write about 100MB of zeroes at the end of the drive - it might ease locating the relevant bytes.
4. Flash bridge board back to its original state - i.e. 'transparent encryption' in the 943 chip activated.
5. Examine the drive while on the bridge board. Write blocks at the beginning and at the end of the drive to files. They can be looked at later on. (see note).
6. Dump the EPROM.
7. Examine the drive while on the USB adapter. Write blocks to files, same as above.
8. Format the drive, while connected to the 943 bridge board, by either system tools, WD Quick Formatter or WD SmartWare. SmartWare is newer, but, IIRC, it hides the virtual CD from the system by default and uses several kexts in the process that Quick Formatter doesn't. On the other hand, by using system tools (and all WD kexts deinstalled) one could determine what the 943 chip itself, without WD utils interfering, writes to the drive. You decide. Or I can do one after the other, possibly zeroing out data inbetween, if needed. This is the step where SInE blobs will show up.
9. Repeat steps 5-7.
10. Set the password to abc123 using SmartWare. Verify that it works.
11. Repeat steps 5-7.
12. Change the passwort to something else. def456 ?
13. Repeat steps 5-7.
14. Enter the wrong password 5 times to force SmartWare to reformat the drive.
15. Repeat steps 5-7. ..
16. Write zeroes to some known location? At what stage?

That should be it. What do you think? Did I miss any important steps? Can any of the steps be omitted?

Note. Drive block dumps will be saved as .dimg files and could be examined by either iBored (quite handy) or any hex editor. I also don't think that the whole 100MB sections will be needed. The virtual CD at the end of the drive is 30MB. At the beginning of the disk probably not more than a 1MB will be needed.

[themaddoctor]

I don't think 12 and 13 are necessary. And I think that 14 will only change the DEK, and get you new SInE blobs.

I don't know enough about the software to make many suggestions about step 8. Are you saying that WD installs kexts to your system? What are they called? Do you know what any of them do? Are you also saying that if you format with system tools, the blobs are created? Maybe the chip creates them no matter what the user tries to write to disk. Just so long as the SInE blobs are created, you decide what to do in step 8.

The information I would want to have is the location of the blobs, counting from the beginning of the disk, the content of the blobs, a copy of zeroed-out sector 0 through the bridge card and through SATA/USB (whether or not disk get formatted, since formatting leaves some blocks of 0 in sector 0), and a zip file of the EEPROM contents. For 4 and 5TB.

One last experiment you should try is to set the drive up so that the SInE blobs are created and transparent encryption is working. Then overwrite both blobs on disk with zeroes through SATA. Then reconnect with the bridge card. See if the chip reads the blobs from EEPROM, and whether it rewrites them back to disk. See if decryption is still working when you read from the disk. This experiment should be done with and without a password set.

When you said earlier that data was being written to the virtual CD while the disk was in use with the bridge card, I think maybe something else is happening. The virtual CD may only occupy part of the hidden space at the end of the drive, and the remaining space is used to store the blobs etc. A tool called isoinfo (part of cdrkit or cdrtools) can read the headers of the virtual CD and tell you how large its file system is.

Thanks again and have fun.

[ojfd]

Ok, parts 1 thru 7 are done and documented. No SInE blobs in sight, but there was one surprise and one discovery. I'll post details and will respond to you later. Also, do you or others want me to continue to post screenshots or is it better to put them all in one zip file?

[themaddoctor]

zip file

[ojfd]

At the moment I am somewhere in the middle of step 8. Drive Encryption Key is set, but no volume is created or password used. SInE blobs are present.

If you're eager to try out the results, attached are the 3 relevant blocks as raw binary files. See whether the data makes any sense to you.

Total number of blocks: 7814037168

Virtual CD part starts at block: 7813969920

SInE block locations: 7814037120 7814037128

bits and blobs.zip

[themaddoctor]

When I decrypted the keyblock, I got this:

00000000 1c 81 36 61 3d 81 89 e5 94 81 3c 88 58 81 67 e5 |..6a=.....<.X.g.| 00000010 f7 ee 9a cf 1a 62 5c 0f 69 ab 5d 00 1b 21 5d a9 |.....b.i.]..!].| 00000020 22 dd d0 90 00 00 00 00 00 00 00 00 00 00 00 00 |"...............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 2b e4 8a 7f 6f 94 a7 9c f3 fa 25 51 c8 f9 a9 31 |+...o.....%Q...1| 00000050 2b e4 8a 7f 6f 94 a7 9c f3 fa 25 51 c8 f9 a9 31 |+...o.....%Q...1| 00000060 2b e4 8a 7f 6f 94 a7 9c f3 fa 25 51 c8 f9 a9 31 |+...o.....%Q...1| 00000070 2b e4 8a 7f 6f 94 a7 9c f3 fa 25 51 c8 f9 a9 31 |+...o.....%Q...1| 00000080 f9 3d 0d 47 af 77 1a 74 15 96 fb f6 98 be 6f 6b |.=.G.w.t......ok| 00000090 f9 3d 0d 47 af 77 1a 74 15 96 fb f6 98 be 6f 6b |.=.G.w.t......ok| 000000a0 f9 3d 0d 47 af 77 1a 74 15 96 fb f6 98 be 6f 6b |.=.G.w.t......ok| 000000b0 89 ef b5 b0 7d da d6 21 1f 9b 38 bf 79 96 f8 13 |....}..!..8.y...| 000000c0 00 4a 69 35 30 83 12 40 df 52 f8 2a c2 d7 7d e3 |.Ji50..@.R.*..}.| 000000d0 b8 6a 46 c7 70 0e 7c ad e6 c0 aa cb 14 91 87 8c |.jF.p.|.........| 000000e0 a4 7d fe 46 ee 1b 65 57 07 ae 95 c6 35 69 bf 2f |.}.F..eW....5i./| 000000f0 9f 42 4d 98 85 58 d3 eb c4 bc 32 72 31 ed b7 55 |.BM..X....2r1..U|

As you can see, there is a long string of zeroes. So now maybe we have a way to know if the DEK is extracted correctly. To double-check, I used the extracted DEK and decrypted block 0 to get this:

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe |................| 000001c0 ff ff ee fe ff ff 01 00 00 00 fe ff ff ff 00 00 |................| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|

It contains this partition table:

Disk ojfd-4TB-OXUF943SE-block0-decrypted.bin: 512 B, 512 bytes, 1 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: dos Disk identifier: 0x00000000

Device Boot Start End Blocks Id System ojfd-4TB-OXUF943SE-block0-decrypted.bin1 1 4294967294 2147483647 ee GPT

[themaddoctor]

Is everything then as you've expected? Yes.

Adding a file system will really not give me any more useful information. Doing so only exercises the "transparent encryption."

I'm more interested in the EEPROM dump, and the keyblock info for the 5TB.

[themaddoctor]

In the first images you posted, the parts that hold the key are holding a repeating 4-byte sequence instead.

Something interesting: I have two samples from different people for 3TB drives, and they have a bunch of identical chunks, and they match your 4TB keyblock. The match occurs after decryption.

[ojfd]

set the drive up so that the SInE blobs are created and transparent encryption is working. Then overwrite both blobs on disk with zeroes through SATA

Just did it. Guess what? The drive keeps working! How's that for a starter!

There's longish story before that until I got volume created, but then, I probably have to write a tutorial ;)

[ojfd]

Info regarding step 8. Apparently neither Mac Disk Utility nor WD Quick Formatter are able to erase/format/create volume on a blank, unformatted disk that is connected to non-factory flashed 943 bridge board. Disk Utility threw an error, Quick Formatter complained that the drive is locked. I then installed WD SmartWare with all its kexts, bells and whistles and look what I saw in the SmartWare menu.

I went and erased the drive with it and menu changed to this.

I assume by 'Drive not encrypted' they ment that password is not set. No Mac volume was created by this action.

At this point I posted the first blobs.

[ojfd]

Blobs in the EPROM. So far they are always at offsets 0x7d000 and 0x7e000 in the dumps and both are identical. They do change. Surrounding bytes are FF.

Initial flash

00000000  53 49 6E 45 01 00 00 00  01 00 64 00 EB 21 FF FF  |SInE......d..!..|
00000010  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000020  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000030  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000040  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000050  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

============

1st erase.

00000000  53 49 6E 45 01 00 00 00  02 00 64 01 47 B8 01 00  |SInE......d.G...|
00000010  00 00 7C 4D 63 FA C1 66  70 4E 8D B4 1F 4A 20 5F  |..|Mc..fpN...J _|
00000020  96 FE 0E E8 C7 3C 4B 51  4C B9 C1 9C DE 17 70 E2  |.....<KQL.....p.|
00000030  B9 EA 77 1B A6 D8 E5 69  2F 6F BD 1A 56 75 13 B0  |..w....i/o..Vu..|
00000040  CC 35 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |.5...t..WR......|
00000050  11 F3 FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

Remained unchanged after Disk Utility and Quick Formatter failed to create a Mac volume.

============

2nd erase - created Mac volume.

00000000  53 49 6E 45 01 00 00 00  02 00 64 01 09 40 01 00  |SInE......d..@..|
00000010  00 00 1F B6 F5 B7 5A FD  55 49 32 57 1E 04 20 B3  |......Z.UI2W.. .|
00000020  D5 B9 B3 FA AB EA D3 3C  BA E9 8B CE 10 65 58 11  |.......<.....eX.|
00000030  9B B3 F9 54 BE A3 08 19  C3 87 67 BC 5B 62 90 FB  |...T......g.[b..|
00000040  9C 2F 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |./...t..WR......|
00000050  11 F3 FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

After blobs at the end of the drive were zeroed, it remained unchanged. After whole virtual CD section at the end of the drive was zeroed, it also remained unchanged.

[ojfd]

Info regarding step 8, continued. Since no volume was created by SmartWare's erase, I went back and tried to create a volume with Mac Disk Utility. It went quite far, but failed at the end with error. I then tried WD Quick Formatter and it failed too. I ran ir from the Terminal to see what's going on. SCSI commands, responses etc. (I' can't really decipher SCSI send/response commands myself, since there aren't any SCSI tools on a Mac therefore I'm lacking the experience. I hope someone will chime in.) Log is attached.

WD Quick Formatter failed.log.zip

Then I installed Smartware again (I uninstalled it after the first erase) and erased the drive with it again. This time the volume was created and drive showed up on the desktop. One Interesting note - after Smartware's actions, virtual CD is no longer seen by the system and its tools.

Here's the second set of bits and blobs corresponding to this state.

bits and blobs 2.zip

[ojfd]

Erased the blobs at the end of the drive (see above). It is still working correctly. Wow!

[ojfd]

Zeroed out the whole virtual CD section at the end of the drive. Drive keeps working. Virtual CD part is now visible to the system.

[ojfd]

The virtual CD may only occupy part of the hidden space at the end of the drive, and the remaining space is used to store the blobs etc.

Yes, this is exactly the case. I've missed this nuance previously. Virtual CD partition on this 4TB drive starts at block 7813969920. When it is connected to 943 bridge, CD image is shown as having 61440 blocks, starting at 7813969920. When it is connected via USB adapter, there are 67247 remaining blocks (x512) after 7813969920. Difference is around 2.8 MB. Blobs are at 67200 and 67208 counting from 7813969920 First non zero data is at 67071 (I zeroed out 100MB at both ends before flashing, remember?)

A tool called isoinfo (part of cdrkit or cdrtools) can read the headers of the virtual CD and tell you how large its file system is

Thanks, I'll take a look. What interests me more is what lines of code in firmware create this virtual CD and reserve disk space for it. I'd like to kill it completely.

[ojfd]

Are you saying that WD installs kexts to your system?

Yes

What are they called?

SmartWare installs WDUSBHPDriver.kext, WD1394HPDriver.kext plus WDUIKit.framework

Do you know what any of them do?

No. But I suspect they're not what they pretend to be.

Are you also saying that if you format with system tools, the blobs are created?

No, actually. As it turns out, only WD software can create them. I had no idea prior to this experiment.

EDIT: This needs further investigation. I'll check that later.

[themaddoctor]

Thanks for that.

So, it seems that the offset to the encrypted key is different in the EEPROM blob, but it also contains a check (last several bytes decrypt to zeroes). This is helpful to know, when I come across another disk with no keyblocks on the disk.

I think that the junk in the rest of the disk keyblock stores some information about the random number generator. I am probably wrong. But, anyway, if you grab 512 bytes after "SInE", do you see any nonsense? Or just FF? Just curious; knowing this won't help me.

One way to see if the kexts have some encryption-handling stuff in them is to see if they contain the PI KEK: 03141592653589793238462643383279fcebea6d9aca7686cdc7b9d9bcc7cd86 There is another secret number that I should not reveal here. It is for the Symwave chip.

Are you ready to do the 5TB disk?

[ojfd]

if you grab 512 bytes after "SInE", do you see any nonsense?

No, it's all FFs. Firmware is 258K in my case, full dump is 512K. Structure is as follows: first come firmware with only a few changes (load different addresses), then padding (FF), then configuration sectors (created on the basis of separate configuration file), then small amount of padding again. Both blobs are placed in the area between firmware and configuration sectors. Offsets I already posted.

Are you ready to do the 5TB disk?

If you don't want to try abc123 password, then yes. And, it's 6TB.

[themaddoctor]

Ah, forgot about the password stuff. Don't change anything else, so we can see that the DEK stays the same.

[ojfd]

Here's another interesting piece of the puzzle - OXUF936xxx chip. Has the hardware encryption capability. OXUF936DSE_Oct08.pdf Product selector guide.pdf OXUF936DSE is used in WD MyBook Duo II enclosure. Can only be set to RAID0 or RAID1 by WD RAID Utility. Defaults to RAID0 if formatted by system tools. I have this one too, but am not using it. I haven't seen where the encryption can be set. Maybe in SmartWare?

[ojfd]

This should answer the question what creates blobs at the end of the drive past the virtual CD section.

Bridge board untouched and assumed to be in the state more or less representing factory flashed board.

Blobs in EPROM were as follows:

00000000  53 49 6E 45 01 00 00 00  02 00 64 01 3F 44 01 00  |SInE......d.?D..|
00000010  00 00 A9 15 50 71 EA 0A  C6 74 97 2F CC D9 55 E5  |....Pq...t./..U.|
00000020  B5 4F 1F 96 FF 36 5E 54  55 9E 8A 32 D1 BD 57 C3  |.O...6^TU..2..W.|
00000030  2B 79 B0 69 CF 1E 9E B2  45 7C 54 62 02 95 18 29  |+y.i....E|Tb...)|
00000040  FC E7 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |.....t..WR......|
00000050  11 F3 FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

• Zeroed both ends while on USB.
• Formatted using Mac's Disk Utility (GUI to diskutil) while on bridge board.
• Drive works.
• Virtual CD part is visible to system tools, but nothing is mounted, since that part on the drive is all zeroes.

/dev/disk3

: TYPE NAME SIZE IDENTIFIER

0: CD_partition_scheme *36.1 MB disk3 1: CD_ROM_Mode_1 31.5 MB disk3s0

• EPROM blobs not changed.
• No blobs created at the end of the drive.
• Several blocks at the end were changed (see attachments). Either one or two of them are responsible for hiding virtual CD from the system.

7814036991 7814036992 7814037131 7814037132 7814037167

Next.

• Zeroed both ends while on USB.
• Formatted using WD Quick Formatter while on bridge board. It requested admin rights! The app has WDUIKit.framework in its package.
• Drive works.
• Virtual CD part is visible to system tools
• EPROM blobs not changed.
• No blobs created at the end of the drive.
• Same blocks as above at the end were changed. Contents are identical.

Attached are

• 6400 blocks from the beginning of the drive from both attempts
• Everything from 7813969920 + 2 previous blocks to the end of the drive. 0-6440 blocks.zip CD part+2 previous blocks.zip

[themaddoctor]

OXUF936xxx chip. Has the hardware encryption capability.

This I knew. But I was curious to know where the KDF is. The KDF is the function that takes a password and generates the KEK. The default is the PI KEK, as you know.

[ojfd]

• Zeroed both ends while on USB.
• Formatted using WD SmartWare while on bridge board. It also requested admin rights!
• First attempt failed, like before.
• Second and all consecutive attempts were successful.
• EPROM blobs were changed.
• Blobs at the end of the drive were created.
• Each consecutive erase (format) attempt changed EPROM blob contents and, I assume, blobs on the drive. I didn't check every run, it's too time consuming.
• Virtual CD part is not visible to system tools now.
• Several blocks at the end were also changed.

EPROM blobs.

2nd erase

00000000  53 49 6E 45 01 00 00 00  02 00 64 01 F0 08 01 00  |SInE......d.....|
00000010  00 00 85 7C E4 63 B1 44  0E 13 BD BB 29 5C 90 8C  |...|.c.D....)\..|
00000020  42 A8 E8 EC BF 1F 76 A8  47 FC 5E C9 12 68 60 E8  |B.....v.G.^..h`.|
00000030  0B 25 8A 1B 46 26 A3 F6  DC F1 57 F9 65 ED BA 1F  |.%..F&....W.e...|
00000040  CA 37 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |.7...t..WR......|
00000050  11 F3 FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

3rd erase

00000000  53 49 6E 45 01 00 00 00  02 00 64 01 86 36 01 00  |SInE......d..6..|
00000010  00 00 53 9B F9 C6 E1 14  12 26 B3 72 2A 04 41 4A  |..S......&.r*.AJ|
00000020  12 3E 4B 4E 70 59 44 BE  B6 C3 06 05 26 17 00 AC  |.>KNpYD.....&...|
00000030  CD BC D0 CE 90 5F 17 E5  6D A7 93 07 0B 23 DD BE  |....._..m....#..|
00000040  FC 2F 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |./...t..WR......|
00000050  11 F3 FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

4th erase

00000000  53 49 6E 45 01 00 00 00  02 00 64 01 1D 89 01 00  |SInE......d.....|
00000010  00 00 6A EB 2B 22 82 A4  32 B7 5A ED 39 7C 04 E1  |..j.+"..2.Z.9|..|
00000020  27 15 04 82 C0 8B AC 1E  7C 91 8E A2 D8 2D C5 7C  |'.......|....-.||
00000030  61 60 68 83 BC 04 00 22  01 F6 FF 5C 3B 0D 30 25  |a`h...."...\;.0%|
00000040  A2 83 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |.....t..WR......|
00000050  11 F3 FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

Blocks other than SInE blobs changed/added by SmartWare.

7814036991 7814036992 7814037131 - changed 7814037132 - changed 7814037133 - added 7814037135 - added 7814037150 - added 7814037152 - added 7814037167

SmartWare both ends 2.zip SmartWare both ends 4.zip

I'm on the 4th erase at the moment. I'll apply abc123 now.

[ojfd]

But I was curious to know where the KDF is. The KDF is the function that takes a password and generates the KEK. The default is the PI KEK, as you know.

Unlike in WD 943 firmware, I don't see any traces of PI or CRC-16/32 stuff in WD 936 firmware. But, I've seen the option to enable encryption in 3rd party, Oxford Semi based configuration application that does not want to talk to WD's MyBook Duo II.

[ojfd]

abc123

Funny thing - drive is not visible to the system and its tools. It appears to be unmounted and can only be mounted by unlocking it with SmartWare or whatever else they (WD) had. Eek!

EPROM blobs

00000000  53 49 6E 45 01 00 00 00  04 00 64 01 B1 7C 01 00  |SInE......d..|..|
00000010  00 00 AD 7E F0 6A 9B 1C  38 94 6A 63 20 41 46 39  |...~.j..8.jc AF9|
00000020  9B DE A3 74 9B A2 93 6C  A4 8D D9 FE 88 DF B4 2D  |...t...l.......-|
00000030  73 EA C5 F5 02 AE CE B7  7E 04 85 B4 32 42 63 B9  |s.......~...2Bc.|
00000040  90 BC AD 00 89 B3 0D CB  EF A1 E7 C5 75 9A E2 DB  |............u...|
00000050  1F 5F FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |._..............|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

abc123 both ends.zip

I'll try to zero both blobs on the drive now.

[themaddoctor]

So, the keyblocks at the end of the disk contain the DEK encrypted with both pi and abc123. Notice the extra SInE header in them.

[ojfd]

Yeah, I saw that.

Zeroed both blobs - drive keeps working. Zeroed whole virtual CD section - drive is still working. I'll check the EPROM contents and CD section whether there's some stuff other than 0's and that should be it.

[ojfd]

• EPROM blob not changed.
• Blocks with data other than 0's:

7814036991 7814036992 7814037131 7814037132 7814037167

abc123 both ends-CD part zeroed.zip

[ojfd]

6TB WD60 EFRX-68L0BN1

Total number of blocks: 11721045168

Virtual CD part starts at block: 11720978432

SInE block locations: 11721045120 11721045128

• Zeroed 100MB at both ends while on USB.
• Connected 6TB drive to the bridge board, which was left in the same abc123 state from 4TB experiment. SmartWare asked for password. abc123 worked. Formatted the drive, which is not encrypted now.
• Virtual CD part is not visible to system tools.
• EPROM blob has changed. I guess it doesn't make sense to post it, you already have many.

6TB SmartWare both ends.zip

[themaddoctor]

The samples you sent for 6TB are encrypted, but not with a password.

[ojfd]

For completeness sake.

2TB WDC WD20 EARX-00PASB0

Total number of blocks: 3907029168

Virtual CD part starts at block: 3906963456

SInE block locations: 3907029120 3907029128

2TB SmartWare both ends.zip

[ojfd]

It's interesting to note that bloblocks(tm) are always at locations ending with -120 and -128 Also, virtual CD sizes do differ.

[themaddoctor]

All four chips have a pattern in their keyblock locations, if you look at them in hex.

Thanks for all the information. I will leave this thread here for future use. Maybe @andlabs will find it interesting.

[themaddoctor]

@ojfd, I forgot to ask you how you read the EEPROM. What tool do you use? Do you physically remove it and use a chip reader or do you know some VSC commands to do it over the USB or FireWire? Thanks.

[ojfd]

I will leave this thread here for future use. Maybe @andlabs will find it interesting.

Yes, it might be useful to general public too. To avoid some pitfalls. As to the andlabs, it seems that he's abandoned his reallymine project. I wrote to him about a year ago and got no response. (I hoped he could shed some light on ARM7/ROM stuff).

[themaddoctor]

And just to be clear, the EEPROM is on the bridge card, right? Maybe a photo would be useful.

[ojfd]

Since you were/are interested in keyblock locations, I'd like to bring up the drive size issue.

I've investigated all available WD resources regarding their My Book Studio / My Passport Studio product lines - the ones that use 943 chip. One common property is that they all have FireWire ports and hence could be easily identified. To my knowledge, no "pure" USB 2.0 or USB 3.0 WD My Book enclosures have Oxford Semiconductor 943 chip in them. Probably too expensive.

According to data I've collected, no factory delivered, FireWire equipped MyBook Studios had drives larger than 3TB and no MyPassport Studios had drives larger than 2TB. MyBook Studios used WD Green Caviar drives and that line stopped at 3TB. Not sure about MyPassport Studios.

There were 6 models, 3 in each line. Table in 'Got Crypto' paper lists all of them by their PID's.

Here's the data that I have.

My Passport Studio (WDMT) - with display https://support-en.wd.com/app/products/product-detailweb/p/199

WD1600MS USB2 / FW400 160 GB WD2500MS USB2 / FW400 250 GB WD3200MS USB2 / FW400 320 GB WD4000MS USB2 / FW400 400 GB WD5000MS USB2 / FW400 500 GB WD3200MT USB2 / FW800 320 GB WD4000MT USB2 / FW800 400 GB WD5000MT USB2 / FW800 500 GB WD3200MTE USB2 / FW800 320 GB

My Passport Studio (WDBAAE) - with display https://support-en.wd.com/app/products/product-detailweb/p/202

WDBALG5000ABK FW800, USB2 500 GB WDBK8A7500ABK FW800, USB2 750 GB WDBK8A0010BBK FW800, USB2 1 TB WDBS8P0020BBK FW800, USB2 2 TB WDBGJA0010BBK FW800, USB2 1 TB WDBU4M0020BBK FW800, USB2 2 TB

My Passport Studio (WDBU4M/WDBGJA) no display, latest https://support-en.wd.com/app/products/product-detailweb/p/213

WDBU4M0020BBK FW800, USB2 2 TB WDBGJA0010BBK FW800, USB2 1 TB WDBK8A0010BBK FW800, USB2 1 TB WDBK8A7500ABK FW800, USB2 750 GB WDBALG5000ABK FW800, USB2 500 GB WDBS8P0020BBK FW800, USB2 2 TB

My Book Studio (Starts with WDBC3G) - latest, no display, aluminium case. PID:111D https://support-en.wd.com/app/products/product-detailweb/p/239

WDBC3G0030HAL FW800 / USB2 3 TB WDBC3G0020HAL FW800 / USB2 2 TB WDBC3G0010HAL FW800 / USB2 1 TB

My Book Studio LX (Starts with WDBACH) - older, with display, aluminium case. PID: 111C https://support-en.wd.com/app/products/product-detailweb/p/243

WDBACH0030HAL FW800 / USB2 3 TB WDBACH0020HAL FW800 / USB2 2 TB WDBACH0010HAL FW800 / USB2 1 TB

My Book Studio (Starts with WDBAAJ) - oldest, with display, plastic case. PID: 1112 https://support-en.wd.com/app/products/product-detailweb/p/1445

WDBAAJ0020HSL FW800 / USB2 2 TB WDBAAJ0010HSL FW800 / USB2 1 TB

What I want to say is that drives other than WD Green and larger than 3TB (2TB for Passports) were probably installed and formatted by the users. If they used anything but WD SmartWare to do this, there will be no SInE blobs at the end of their drives. That's kind of scary. How do you recover data in such case? Most of the MyBooks came pre-formatted for the Mac. If user decided to move it over to Win/Linux, it is also unknown how they were formatted.

[ojfd]

.. the EEPROM is on the bridge card, right?

Yes.

Maybe a photo would be useful.

Pulled from the web.

MyBook Studio. Lower left corner.

https://www.storagereview.com/review/western-digital-my-book-studio-review-3tb

MyPassport Studio. Upper right corner.

https://www.storagereview.com/review/western-digital-my-passport-studio-review-1tb

[themaddoctor]

Do you mean U2 for both?

[ojfd]

Speaking of WD MyPassports.. I have a couple of smaller (under 1TB) 2.5" drives that I don't care about that I can turn into WD encrypted ones, if needed. None of them are by WD, though.

[ojfd]

Yes, U2. Winbond W25X40. You've asked previously how I read it. Well, I do it over USB with something that I cobbled together and modified. And, no, it's not flashrom. But I don't want to discuss it here.

[themaddoctor]

Speaking of WD MyPassports.. I have a couple of smaller (under 1TB) 2.5" drives that I don't care about that I can turn into WD encrypted ones, if needed. None of them are by WD, though.

If you want to. I could add the keyblock locations for 500GB, 750GB, and 1TB to this project, if you find them.

[ojfd]

500GB 2.5" Hitachi HTS547550A9E384 TOSHIBA MK5065GSXF (identical number of blocks/SInE locations)

Total number of blocks: 976773168

Virtual CD part starts at block: 976707584

SInE block locations: 976773120 976773128

EPROM blobs (Hitachi)

00000000  53 49 6E 45 01 00 00 00  02 00 64 01 AD 51 01 00  |SInE......d..Q..|
00000010  00 00 87 10 77 06 68 F2  AD 37 39 F9 4B CC F8 BF  |....w.h..79.K...|
00000020  A6 1B 79 1A C2 6F FA FA  E0 88 BC 95 C5 26 32 95  |..y..o.......&2.|
00000030  9D 5C B3 CA AB 11 1B 6A  08 55 1C 0F 22 61 31 0F  |.\.....j.U.."a1.|
00000040  B3 71 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |.q...t..WR......|
00000050  11 F3 FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
00000060  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

500GB SmartWare both ends.zip

[themaddoctor]

You might find this interesting: The decrypted keyblock contains the CRC32 of the DEK.

Here are two decrypted keyblocks:

00000000 da 2e 0a 07 80 2e 59 34 41 2e 8c 54 db dc 09 7a |......Y4A..T...z| 00000010 bb 20 09 35 bb 6f 6a 37 c6 4d 94 54 64 59 5c 54 |. .5.oj7.M.TdY\T| 00000020 e9 14 ac c4 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000000 c9 1f 2f 64 bb 1c e0 69 4d 9a 23 69 14 9a 2e eb |../d...iM.#i....| 00000010 3a 51 a9 78 bd 1d a9 a3 bd 1d aa ee 1c 9a e9 6c |:Q.x...........l| 00000020 e2 68 d4 a1 00 00 00 00 00 00 00 00 00 00 00 00 |.h..............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

The CRC of the DEK in the first one is c4ac14e9, which is the byte-reversed number immediately after the key. For the second, the CRC is a1d468e2, which you can also see.

[ojfd]

It's also interesting to note that all 943 firmwares, that I have seen (WD and non WD), contain CRC16 and 32. WD has additional PIs, but that you already know. Firmware for 924/934/936 chips don't have this stuff. 3d838-3dc3c.zip

[ojfd]

What do you make of this set of data? Makes any sense? Keyblocks not available.

EPROM blob

00000000  53 49 6E 45 01 00 00 00  02 00 64 03 46 E4 01 00  |SInE......d.F...|
00000010  00 00 84 60 DC 63 DB 56  96 06 80 EC 4F 5F B5 DB  |...`.c.V....O_..|
00000020  45 DD 14 5B E3 C4 97 F4  B9 93 D6 D3 9A E2 7D 2E  |E..[..........}.|
00000030  00 03 77 4C D0 E7 C4 1A  2D 2F 9F 37 A3 B6 F5 FA  |..wL....-/.7....|
00000040  73 13 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |s....t..WR......|
00000050  11 F3 84 60 DC 63 DB 56  96 06 80 EC 4F 5F B5 DB  |...`.c.V....O_..|
00000060  45 DD 14 5B E3 C4 97 F4  B9 93 D6 D3 9A E2 7D 2E  |E..[..........}.|
00000070  00 03 77 4C D0 E7 C4 1A  2D 2F 9F 37 A3 B6 F5 FA  |..wL....-/.7....|
00000080  73 13 1A D8 85 74 11 9E  57 52 B0 83 06 0D 8F CD  |s....t..WR......|
00000090  11 F3 FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|
000000A0  FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

HDD part 6440 blocks-a.zip