reallymine
reallymine copied to clipboard
andlabs
Oxford Semiconductor OXUF943SE
I have a 2TB WD MyBook whose SATA-USB bridge is dead. I can only get the drive recognised and initialised by OS X if I use this docking station, but since the data is decrypted, I can't really do much with it.
The chip on the bridge says Oxford Semiconductor OXUF943SE, but I understand that this is not supported/recognised by reallymine at the moment.
Can I help in get this implemented in any way?
reallymine does recognize the bridge chip, but it can't decrypt a drive that uses it. If you can run both the dumpkeysector and dumpfirst commands and send me the resultant files, I should be able to figure out what the decryption method is. dumpfirst only extracts 32KB from the drive, so no personal data will be taken (only the partition table and boot sectors). (You can, in addition, use the decryptfile command to play along at home.)
Thanks a lot for this in the meantime! :D
What is the difficulty with this chip? With the key, I think I could do it on linux with cryptsetup. Can you send me those files as well, so that I can try it. So far, I have been able to mount drives with the JMicro and Symwave chips on my linux machine, by setting up an encryption filter with cryptsetup. I'd like to try the other chips too.
@themaddoctor there is no difficulty, I just need a sample of encrypted data (not the key sector) so I know what operations to perform on the bytes to properly decrypt it.
Sorry for the lack of response, I kind of gave up on the drive (for now). Last I tried, I couldn't get dumpkeysector or dumpfirst to work, so I suspect there's something else going on with the drive.
ncococola, what OS do you have? If linux or Mac, then you can use dd to get the information that andlabs is asking for. In linux, use the terminal; on Mac, the terminal app is in Applications/Utilities. Then you have to figure out where the disk device is on the system. Try 'find /dev > 1.txt' before you plug it in, and 'find /dev > 2.txt' after. Then 'diff 1.txt 2.txt' should tell you what changed. Then something like dd if=/dev/sdb bs=1024 count=1024 of=start.img will dump the first 1MB into start.img, and dd if=/dev/sdb bs=1024 skip=1950000 of=end.img will dump the end of the disk into end.img. You will have to play around with the "skip" number until you get only one or two MB in the file end.img. And change "sdb" to whatever your system calls the new disk.
The "client" I was talking about has the OXUF chip, but the keyblock is not on the disk. Maybe it's in the service area or on the EEPROM, but I don't know how to access them yet.
andlabs, have you examined the firmware for the OXUF chip? Do you know the algorithm that it uses to generate a new DEK for the "quick erase" feature?
If you do, I might be able to find a way to get the factory-set DEK for drives without an accessible keyblock. I did it for the JMS538S over the weekend. Had to simulate the PRNG from the chip and the one used at the factory. (The Norwegian group has such a method for JMS and INIC chips.)
You really are the Mad doctor
On Mar 23, 2017 6:07 PM, "themaddoctor" [email protected] wrote:
If you do, I might be able to find a way to get the factory-set DEK for drives without an accessible keyblock. I did it for the JMS538S over the weekend. Had to simulate the PRNG from the chip and the one used at the factory. (The Norwegian group has such a method for JMS and INIC chips.)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/andlabs/reallymine/issues/14#issuecomment-288887395, or mute the thread https://github.com/notifications/unsubscribe-auth/AQE6xf44yKlsbuWb-WOLFiXS6CV914x4ks5rovsvgaJpZM4Kasb7 .
So I finally have a real live PLX drive to examine. Here is the keyblock:
00000000 53 49 6e 45 01 00 00 00 06 00 64 01 b2 73 84 00 |SInE......d.²s..| 00000010 01 00 00 00 b1 b9 7d e4 72 99 7d 3f 4c 6e dd f6 |....±¹}är.}?LnÝö| 00000020 4e 4c 36 c3 6a e0 bb 7a 1d a7 e4 67 38 9c 90 a5 |NL6Ãjà»z.§äg8..¥| 00000030 47 5d 15 9a 26 32 50 db e3 f4 8f 5f 3e 55 1a fd |G]..&2PÛãô.>U.ý| 00000040 16 51 b4 4a 1a d8 85 74 11 9e 57 52 b0 83 06 0d |.Q´J.Ø.t..WR°...| 00000050 8f cd 11 f3 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 |ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ| * 00000090 ff ff ff ff 01 00 00 25 88 a3 50 5d 01 00 00 00 |ÿÿÿÿ...%.£P]....| 000000a0 44 07 00 80 44 07 00 80 44 07 00 80 53 49 6e 45 |D...D...D...SInE| 000000b0 01 00 00 00 05 00 64 01 91 68 08 01 01 00 00 00 |......d..h......| 000000c0 53 e4 f1 d2 3b cf e4 e5 38 41 bd c2 e7 10 73 80 |SäñÒ;Ïäå8A½Âç.s.| 000000d0 5d de 47 ff 77 c3 30 2e eb e7 b0 35 f7 a4 bd 78 |]ÞGÿwÃ0.ëç°5÷¤½x| 000000e0 e3 19 4f 31 fe 6c d4 dc c3 02 3b 7c 0a 64 be ea |ã.O1þlÔÜÃ.;|.d¾ê| 000000f0 8d 27 38 2f 51 21 08 fa 9f ec dd 36 59 86 35 fb |.'8/Q!.ú.ìÝ6Y.5û| 00000100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ| * 00000140 01 00 00 00 b1 b9 7d e4 72 99 7d 3f 4c 6e dd f6 |....±¹}är.}?LnÝö| 00000150 4e 4c 36 c3 6a e0 bb 7a 1d a7 e4 67 38 9c 90 a5 |NL6Ãjà»z.§äg8..¥| 00000160 47 5d 15 9a 26 32 50 db e3 f4 8f 5f 3e 55 1a fd |G]..&2PÛãô.>U.ý| 00000170 16 51 b4 4a 1a d8 85 74 11 9e 57 52 b0 83 06 0d |.Q´J.Ø.t..WR°...| 00000180 0c 06 00 02 00 07 00 d0 00 00 00 80 0c 06 00 02 |.......Ð........| 00000190 00 07 00 d0 00 0e 00 00 90 39 00 80 00 00 00 4b |...Ð.....9.....K| 000001a0 ff 00 00 00 9c 39 00 80 84 00 00 00 30 3a 00 80 |ÿ....9......0:..| 000001b0 0e d0 07 00 0c ff 00 80 44 3a 00 80 20 00 00 80 |.Ð...ÿ..D:.. ...| 000001c0 44 3a 00 80 1d 1e 00 80 84 00 00 00 0e d0 07 00 |D:...........Ð..| 000001d0 d0 07 00 00 1b 77 03 00 01 00 00 00 84 00 00 00 |Ð....w..........| 000001e0 30 3a 00 80 0e d0 07 00 84 00 00 00 84 00 00 00 |0:...Ð..........| 000001f0 01 00 00 00 f7 bb 01 00 30 3a 00 80 00 00 ff ff |....÷»..0:....ÿÿ| 00000200
There is a copy of the old keyblock (actually identical because no pw set) 8 sectors later.
Sorry, I don't know the sector number yet.
Here is the first sector (encrypted):
00000000 b4 54 d9 50 68 03 c2 df f0 f1 c7 2d 6a 86 b9 0e |´TÙPh.ÂßðñÇ-j.¹.| * 000001b0 c4 51 30 b2 1c 1d 50 c0 b7 ec 75 5e 19 d2 ba dc |ÄQ0²..PÀ·ìu^.ÒºÜ| 000001c0 00 f7 f8 2f 86 c0 e0 01 42 09 75 05 9b 8d fe 0e |.÷ø/.Àà.B.u...þ.| 000001d0 b4 54 d9 50 68 03 c2 df f0 f1 c7 2d 6a 86 b9 0e |´TÙPh.ÂßðñÇ-j.¹.| * 000001f0 50 1a 2d 65 c7 b5 eb 55 7a 98 26 28 de a7 0b b9 |P.-eǵëUz.&(Þ§.¹| 00000200
To decrypt, I had to do this:
- reverse and change endianness (swapbytes) of the KEK
- remove 20 bytes from the beginning of the keyblock
- use the fixed KEK to decrypt the fixed keyblock with AES-ECB
- extract the first 32 bytes of the result as the DEK
- fix the DEK by reversing it and changing endianness (swapbytes)
- decrypt disk as AES-ECB. No additional manipulation of disk blocks needed.
(You should wrap those hexdumps in Markdown code blocks to prevent formatting weirdness. Have three backticks on their own line at the start and again at the end.)
00000000 53 49 6e 45 01 00 00 00 06 00 64 01 b2 73 84 00 |SInE......d.²s..|
00000010 01 00 00 00 b1 b9 7d e4 72 99 7d 3f 4c 6e dd f6 |....±¹}är.}?LnÝö|
00000020 4e 4c 36 c3 6a e0 bb 7a 1d a7 e4 67 38 9c 90 a5 |NL6Ãjà»z.§äg8..¥|
00000030 47 5d 15 9a 26 32 50 db e3 f4 8f 5f 3e 55 1a fd |G]..&2PÛãô.>U.ý|
00000040 16 51 b4 4a 1a d8 85 74 11 9e 57 52 b0 83 06 0d |.Q´J.Ø.t..WR°...|
00000050 8f cd 11 f3 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 |ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|
*
00000090 ff ff ff ff 01 00 00 25 88 a3 50 5d 01 00 00 00 |ÿÿÿÿ...%.£P]....|
000000a0 44 07 00 80 44 07 00 80 44 07 00 80 53 49 6e 45 |D...D...D...SInE|
000000b0 01 00 00 00 05 00 64 01 91 68 08 01 01 00 00 00 |......d..h......|
000000c0 53 e4 f1 d2 3b cf e4 e5 38 41 bd c2 e7 10 73 80 |SäñÒ;Ïäå8A½Âç.s.|
000000d0 5d de 47 ff 77 c3 30 2e eb e7 b0 35 f7 a4 bd 78 |]ÞGÿwÃ0.ëç°5÷¤½x|
000000e0 e3 19 4f 31 fe 6c d4 dc c3 02 3b 7c 0a 64 be ea |ã.O1þlÔÜÃ.;|.d¾ê|
000000f0 8d 27 38 2f 51 21 08 fa 9f ec dd 36 59 86 35 fb |.'8/Q!.ú.ìÝ6Y.5û|
00000100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|
*
00000140 01 00 00 00 b1 b9 7d e4 72 99 7d 3f 4c 6e dd f6 |....±¹}är.}?LnÝö|
00000150 4e 4c 36 c3 6a e0 bb 7a 1d a7 e4 67 38 9c 90 a5 |NL6Ãjà»z.§äg8..¥|
00000160 47 5d 15 9a 26 32 50 db e3 f4 8f 5f 3e 55 1a fd |G]..&2PÛãô.>U.ý|
00000170 16 51 b4 4a 1a d8 85 74 11 9e 57 52 b0 83 06 0d |.Q´J.Ø.t..WR°...|
00000180 0c 06 00 02 00 07 00 d0 00 00 00 80 0c 06 00 02 |.......Ð........|
00000190 00 07 00 d0 00 0e 00 00 90 39 00 80 00 00 00 4b |...Ð.....9.....K|
000001a0 ff 00 00 00 9c 39 00 80 84 00 00 00 30 3a 00 80 |ÿ....9......0:..|
000001b0 0e d0 07 00 0c ff 00 80 44 3a 00 80 20 00 00 80 |.Ð...ÿ..D:.. ...|
000001c0 44 3a 00 80 1d 1e 00 80 84 00 00 00 0e d0 07 00 |D:...........Ð..|
000001d0 d0 07 00 00 1b 77 03 00 01 00 00 00 84 00 00 00 |Ð....w..........|
000001e0 30 3a 00 80 0e d0 07 00 84 00 00 00 84 00 00 00 |0:...Ð..........|
000001f0 01 00 00 00 f7 bb 01 00 30 3a 00 80 00 00 ff ff |....÷»..0:....ÿÿ|
00000200
00000000 b4 54 d9 50 68 03 c2 df f0 f1 c7 2d 6a 86 b9 0e |´TÙPh.ÂßðñÇ-j.¹.|
*
000001b0 c4 51 30 b2 1c 1d 50 c0 b7 ec 75 5e 19 d2 ba dc |ÄQ0²..PÀ·ìu^.ÒºÜ|
000001c0 00 f7 f8 2f 86 c0 e0 01 42 09 75 05 9b 8d fe 0e |.÷ø/.Àà.B.u...þ.|
000001d0 b4 54 d9 50 68 03 c2 df f0 f1 c7 2d 6a 86 b9 0e |´TÙPh.ÂßðñÇ-j.¹.|
*
000001f0 50 1a 2d 65 c7 b5 eb 55 7a 98 26 28 de a7 0b b9 |P.-eǵëUz.&(Þ§.¹|
00000200
@ncocacola are you still working with this disk? Can you run this script to look for the keyblock?
FILE="$1"
DEVICE="`echo $FILE | cut -d / -f 3`"
SIZE=`cat /proc/partitions | grep -e "$DEVICE" | awk '{print $3}' | head -n 1`
SIZE=`expr $SIZE \* 2`
LOWERLIMIT=`expr $SIZE - 8192` # 4 MB should be enough
for i in `seq $SIZE -1 $LOWERLIMIT`; do
FIRSTLINE=`dd if=/dev/$DEVICE skip=$i count=1 status=none | xxd -p | head -n 1`
if [ `echo $FIRSTLINE | grep "^57447631"` ]; then
echo "found JMicron keyblock at sector $i"
break
fi
if [ `echo $FIRSTLINE | grep "^574d5953"` ]; then
echo "found Symwave keyblock at sector $i"
break
fi
if [ `echo $FIRSTLINE | grep "^57440114"` ]; then
echo "found Initio keyblock at sector $i"
break
fi
if [ `echo $FIRSTLINE | grep "^53496e45"` ]; then
echo "found PLX keyblock at sector $i"
break
fi
done
echo "dumping to keyblock-$i.bin"
dd if=/dev/$DEVICE skip=$i count=1 of=keyblock-$i.bin status=none
Save it as "findkeyblock.sh" and run like this:
sudo bash findkeyblock.sh /dev/sdX
where you replace "sdX" with the name of your WD disk on your system ('cat /proc/partitions' can help you find the name).
Is this issue ever get resolved? I have a similar Oxford chipset as the OP's drive with 1TB WD. I ran reallymine and it all returns "key sector not found". I retrieved a few part of the disk with dd to search for the key starting bit "SInE" but didn't see any. The "dumpfirst" and "dumplast" files don't have them either. I also ran those shell scripts without success as in nothing found.
The drive has not been format or initialized but it was taken out the case and put in another and plugged it in a windows machine and run a recovery scan before realizing it was encrypted. I make a backup with ddrescue before attempted the reallymine and other stuffs. The drive seems to work fine with no error reading it.
Thanks for any help.
The keyblock might be in the service area modules, or it might be on one of the ROM chips. To look in the SA modules, there is a tool called HDDSuperTool. You'll have to google it.
If the keyblock were on the data area, it would be sector 1953524608 or 1953524616 (sectors are 512 bytes; first sector is 0).
Thanks Themaddoctor.
Search through those sectors and the modules dumped from HDDSuperTool and didn't find anything. One question, the original WD enclosure has firewire but I'm not able to read the drive when connect through the firewire either. I thought the MBR might be corrupted since it was plugged into another windows machine but it should at least show something in the disk manager, right?. Anyway to fix the MBR record without damaging any existing data?
Thanks.
@themaddoctor the script you provided a few posts above, is it meant to be run on the HDD while it is in it's enclosure, or if you take it out and connect it directly?
I ask because, in my case, the HDD has a rather strange layout when it's directly connected to the PC.
| Offset (hex) | Notes |
|---|---|
| 0 | Start of unknown data |
| 8000 | Start of null |
| 100000 | Start of data |
| ... | Losts of data here. Some sectors contain the unknown data bytes |
| 1D1970FF000 | Start of null |
| 1D1970FFE00 | Start of unknown data. Different than at offset 0. |
| 1D197100000 | Start of null |
| 1D1971F0000 | Start of unknown data. Same as at offset 0. |
| 1D197200000 | Start of null |
| 1D1972F8000 | Start of unknown data. Different than at offset 0. |
| 1D1972FD000 | Start of unknown data. Same as at offset 0. Has some variation at offset 1D1972FDC00 |
| 1D197300000 | Start of Virtual Compact Disk (VCD)? |
| 1D1C1115FFF | Last byte |
Also, is the SInE marker supposed to be sector/LBA aligned? I searched for the marker on the entire HDD but found no offset that is at the begging of the sector/LBA.
Sorry, I did not see the mention in the PDF, but even so, I ran the script and it dumped a all zero block, because of the layout (and the fact that it dumps the last offset if no magic bytes found)...
The last 37 sectors of the HDD look like this.
Before that there are only zeros (as far as I can tell; I scrolled up from the end, inspecting visually; I might have missed some bytes, buried in zeros somewhere), until sector 3907020178 (offset 1D1C0CB2400) where there is a transition from all FF sectors to all 00 sectors link.
The 4MB search area is before that, so it mostly looks at zeros. This is why I asked. I did do a full HDD search for the magic bytes and found almost 500 occurrences, but none seem sector aligned.
Then to answer your question, the SInE is sector-aligned if your sectors are 512 bytes. It is not aligned to blocks of megabyte size.
If the keyblock is not in the unencrypted portion of the disk at the end, then the next place to look is in the service-area modules. See my comments above. If it is not there, then the keyblock may be stored in one of the chips. I'm sorry, but I didn't make it this hard; blame WD.
For a 4TB drive, I would expect the keyblock (if it is on the user area of the disk) at sector 0x1D1C0BB80