Does this work for JMS561?

[eckss]

I have a my book duo that I'm attempting to run this on and it has a JMicron JMS561 chip. I'm not getting any error message it just starts and creates a decrypted.img file with 0 bytes. Anyone have luck with this chip?

[MrDecay]

Did you take it out of the external case

On Oct 31, 2016 1:22 PM, "eckss" [email protected] wrote:

I have a my book duo that I'm attempting to run this on and it has a JMicron JMS561 chip. I'm not getting any error message it just starts and creates a decrypted.img file with 0 bytes. Anyone have luck with this chip?

— 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/15, or mute the thread https://github.com/notifications/unsubscribe-auth/AQE6xZu4DwaKh_HUMDOWVCgK7vGk17_Iks5q5jH4gaJpZM4KlVur .

[eckss]

I did! I have it attached to a sata to usb converter, and I can see it listed in fdisk.

[MrDecay]

Maybe the USB adapter is having an issue. Is it possible to connect to. Sata

On Oct 31, 2016 1:26 PM, "eckss" [email protected] wrote:

I did! I have it attached to a sata to usb converter, and I can see it listed in fdisk.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andlabs/reallymine/issues/15#issuecomment-257378248, or mute the thread https://github.com/notifications/unsubscribe-auth/AQE6xTVJ0HisK1_1IAJbVBZtmaE2RAQ-ks5q5jLtgaJpZM4KlVur .

[andlabs]

I forget if the 561 is different or not. What happens with the dumplast command?

[eckss]

I get sector at 0x3A3817D5C00

I zipped up the bin and attached it. testt.zip

[andlabs]

Try again, this time passing -disk-size 0x3A3817D5C00. I'm surprised there's an EFI partition there...

[eckss]

Same results, I'll try using SATA directly.

[eckss]

Bust. Any other ideas? Thank you.

[MrDecay]

Are you using a 64 bit Linux distro?

On Nov 1, 2016 7:26 AM, "eckss" [email protected] wrote:

Bust. Any other ideas? Thank you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andlabs/reallymine/issues/15#issuecomment-257554106, or mute the thread https://github.com/notifications/unsubscribe-auth/AQE6xUhZsq25Z8cH4KRwz3u4UMFLvLShks5q5y_zgaJpZM4KlVur .

[eckss]

Yes, 64-bit Rolling Kali.

[jgan96]

I can confirm that I have never had luck using SATA to USB cables with reallymine.

[andlabs]

I can confirm that I have never had luck using SATA to USB cables with anything; I usually go for drive cases or docking stations. (If I accidentally referred to using a cable in any of the documentation, let me know.)

[themaddoctor]

When you plug it into the Kali machine, does it add any new lines to /proc/partitions ? Any new devices into /dev ? "file -s /dev/sdb1" (for example) will tell you if a partition is encrypted or not. If encrypted, it will say "data". If not, it will say something like "DOS MBR boot sector".

[themaddoctor]

I looked at a whitesheet for the 561, and it doesn't mention encryption. I'll bet that the drive has one partition, and that partition is encrypted by software rather than hardware.

[themaddoctor]

I'm able to exploit a weakness in the key generation for JMS538S drives. Maybe it will work here too. Can you dump the first MB of the first partition, so that I have something to work with?

[themaddoctor]

I'm looking at another JMS561 MyBook Duo at the moment (Jan 2018), and it appears to be encrypted, and we cannot find a recognizable keyblock. Still waiting on the service-area modules, if possible.

[metafizx]

hello, any resolution on this problem ? I have the same issue with My Book Duo also with JMS561 I'd really appreciate any updates on this. thanks.

[themaddoctor]

Nope. They never got back to me about the modules.

If you dump the last 5MB of one of the drives (assuming they were mirrors of each other, and dump the service-area modules, I'd be happy to look at them, to see if the keyblock can be found.

[andlabs]

I want to do service area stuff; blocked on copyright clearance for now.

[themaddoctor]

Huh?

[andlabs]

https://opensource.google.com/docs/iarc/

(The other option is Google owning the copyright on future development and me having to go through a formal patching process in the short term. I don't want to do this, at least not yet.)

[piperov]

Did some experimenting with my WD MyBook Duo today (after disassembling and reassembling it, to confirm the presence of the JMS561 chip on the board). Moved one of the disks back and forth between the Duo, and a regular eSATA single-disk enclosure.

Observations:

1. When in the Duo, the disk reports 61616 fewer 512-b blocks compared to the normal enclosure. 3906967552 vs 3907029168.

I wanted to figure out if the 'missing' 61616 blocks are chopped from the start or the end of the disk. For that, I wrote 2*61616 512-b blocks of ones at the start of the disk, followed by the same number of zeroes: badblocks -b 512 -svwt 0xff /dev/sdi 123232 badblocks -b 512 -svwt 0x00 /dev/sdi 246464 123233

and then did the inverse order at the end of the disk: badblocks -b 512 -svwt 0x00 /dev/sdi 3907029134 3906782670 badblocks -b 512 -svwt 0xff /dev/sdi 3907029134 3906905902

Now I moved the disk back in the Duo, and checked the results:

dd if=/dev/sdi bs=512 count=246486 2>&- |hexdump -C

00000000 a8 c4 c5 ae bd ae b4 e8 fe b0 5a 5a bf b1 59 70 |..........ZZ..Yp| * 03c2c200 c9 8f 82 cf f9 9e c8 a6 27 62 48 ee 93 7e 68 79 |........'bH..~hy| * 07858200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 0785ac00

So, my 123232 blocks of ones were still there, but were translated into identical rows of

a8 c4 c5 ae bd ae b4 e8 fe b0 5a 5a bf b1 59 70

and the zeroes were transformed into identical rows of

c9 8f 82 cf f9 9e c8 a6 27 62 48 ee 93 7e 68 79

Finally, looking at the end of the disk:

dd if=/dev/sdi bs=512 count=246464 skip=3906721088 |hexdump -C

00000000 c9 8f 82 cf f9 9e c8 a6 27 62 48 ee 93 7e 68 79 |........'bH..~hy| * 05a3dc00 a8 c4 c5 ae bd ae b4 e8 fe b0 5a 5a bf b1 59 70 |..........ZZ..Yp| * 07858000

which seems about right, except that I expected to see 184848 512-b blocks of zeroes, followed by 61616 blocks of ones (that would have been consistent with the hypothesis that 61616 blocks are chopped from the end of the disk by the JMS561). Instead, there are 184814 blocks of zeroes, followed by 61650 blocks of ones.

That's a difference of 34 blocks - which is (maybe by pure coincidence - or not?) the offset in blocks of the first partition that was created on the disk (in the normal eSATA enclosure) by gparted, when I asked it to align partitions to cylinders.

So, is it possible that the JMS561 is skipping the first (boot) sector, and the last 3, and then uses some very elementary encryption (or byte-swapping, or whatever) for the data in the resulting truncated disk?

That is consistent with the reported disk geometries - a difference of 4 cylinders:

(from running testdisk /dev/sdi in the normal eSATA enclosure)

Disk /dev/sdi - 2000 GB / 1863 GiB - WDC WD2003FYYS-02W0B1 CHS 243201 255 63 - sector size=512

(from running testdisk /dev/sdi in MyBookDuo)

Disk /dev/sdh - 2000 GB / 1862 GiB - WD My Book Duo 0A10 CHS 243197 255 63 - sector size=512

The only contradiction to this theory is the 123232 blocks of ones and zeroes in the beginning of the disk - why are those not shifted by 34 blocks?

Hope this is useful feedback regarding the JMS561.

[themaddoctor]

I am confused about your use of the command "badblocks".

[themaddoctor]

@piperov

1. Can you dump the service-area modules?
2. Can you write a block of zeroes to the disk WHILE it is in the Duo, then tell me what it encrypts them to onto the bare disk? I mean, what they become after you take the disk out of the Duo. The way you did it was backwards from my standpoint.
3. Can you tell us what is on the hidden sectors? I.e., what is on the sectors that you cannot see while the disk is in the Duo, but can see when the disk is outside the Duo?

Thank you.

[piperov]

@themaddoctor

badblocks is very useful for writing blocks filled with bit-patterns on the disk (through its -t option). Not only it writes them on the device, but afterwards it reads them back and makes sure they were successfully written.

Anyway.

Here's what I got when I

1. zeroed out large regions at the beginning and end of the disk in the normal eSATA enclosure badblocks -b 512 -svwt 0x0 /dev/sdh 1232320 badblocks -b 512 -svwt 0x0 /dev/sdh 3907029168 3905796848
2. moved the disk in the Duo and wrote a block of zeroes in the beginning: badblocks -b 512 -svwt 0x00 /dev/sdi 123232
3. moved the disk back in the eSATA enclosure and read those blocks back: dd if=/dev/sdh bs=512 count=123232 2>&- |hexdump -C

00000000 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 03c2c000

So the Duo encoded the rows of zeroes to identical rows of 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6

(and if I read past the 123232-th sector, I start getting zeroes, as expected. So, the Duo really wrote only the 123232 blocks of encoded zeroes at the start of the disk.)

4. Looking at the end of the disk, in the sectors which are inaccessible while in the Duo, I do not see anything but the zeroes I initially wrote: dd if=/dev/sdh bs=512 count=1232320 skip=3905796848 |hexdump -C

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 259b8000

So, it looks like the Duo is NOT writing anything in those 'hidden' sectors.

Finally: What exactly do you refer to as 'service-area modules'?

• Stefan

[piperov]

P.S. If it is of any help, I wrote a block of ones (0xFF), zero-ones (0x55) and one-zeroes (0xAA) to the disk while in the Duo, to see how they will be encoded.

badblocks -b 512 -svwt 0xff /dev/sdi 246464 123232 badblocks -b 512 -svwt 0x55 /dev/sdi 369696 246464 badblocks -b 512 -svwt 0xaa /dev/sdi 492928 369696

Here's the result in the eSATA enclosure: dd if=/dev/sdh bs=512 count=1232320 |hexdump -C

00000000 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 03c2c000 f0 ae 86 6b bd 3c 90 5f cc d7 f8 84 7f 8b 8e ef |...k.<._........| * 07858000 db 9a 17 3e a7 a7 9e af c8 21 12 96 74 2a e4 1b |...>.....!..t*..| * 0b484000 ba 5b cf 5b c6 d0 ad f0 6f ea 41 77 22 47 54 f2 |.[.[....o.Aw"GT.| * 0f0b0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 259b8000 1232320+0 records in 1232320+0 records out 630947840 bytes (631 MB) copied, 4.39965 s, 143 MB/s

[piperov]

PP.S. I never stated this explicitly, but for the record - my MyBookDuo is set to JBOD mode, using the WD-provided tools, in Win7.

[piperov]

@themaddoctor

One more test:

While the disk was in the Duo, I created a GPT partition table, and created the following partitions:

gdisk -l /dev/sdi

GPT fdisk (gdisk) version 0.8.10

Partition table scan: MBR: protective BSD: not present APM: not present GPT: present

Found valid GPT with protective MBR; using GPT. Disk /dev/sdi: 3906967552 sectors, 1.8 TiB Logical sector size: 512 bytes Disk identifier (GUID): 4FC0D30F-07EA-4F23-91F2-2A67543CE71E Partition table holds up to 128 entries First usable sector is 34, last usable sector is 3906967518 Partitions will be aligned on 8-sector boundaries Total free space is 7714 sectors (3.8 MiB)

Number Start (sector) End (sector) Size Code Name 1 34 2104514 1.0 GiB 0700 ext3 2 2104515 18876374 8.0 GiB 8200 swap 3 18876375 223672994 97.7 GiB 0700 ext4 4 223672995 3906959804 1.7 TiB 0700 xfs

Then I moved the disk back in the eSATA enclosure. See where the backup GPT partition table gets located - it may be a clue to the layout of the disk while in Duo.

dd if=/dev/sdh bs=512 count=1232320 skip=3905796848 |hexdump -C

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 23b9de00 b1 4d 5a ee 9b 76 5e df ca 77 89 b8 f0 7b 94 b0 |.MZ..v^..w...{..| 23b9de10 f3 bf c3 4b 26 09 1c 12 40 65 29 86 d5 40 3b fd |...K&...@e)..@;.| 23b9de20 c0 da 5b 23 ac e4 c2 32 27 41 5e 4c 2b f4 7d 55 |..[#...2'A^L+.}U| 23b9de30 7c ca 29 db e9 05 fb a0 ed 21 cd b7 09 44 de 7e ||.)......!...D.~| 23b9de40 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 23b9de80 f4 22 f7 2d 7e ac c6 d6 be 1d 7f 49 1d 85 47 53 |.".-~......I..GS| 23b9de90 08 ea c3 44 ee b6 d6 d3 a2 64 fb d9 0f 43 5f cc |...D.....d...C_.| 23b9dea0 b0 35 61 22 bf 10 38 c0 7e 27 c1 aa e5 e9 85 91 |.5a"..8.~'......| 23b9deb0 2d ea 18 01 f1 ce d4 0a 44 b2 3e 41 28 12 9c e1 |-.......D.>A(...| 23b9dec0 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 23b9df00 b1 4d 5a ee 9b 76 5e df ca 77 89 b8 f0 7b 94 b0 |.MZ..v^..w...{..| 23b9df10 00 83 46 fa ee cd ad d4 fa 2e 5a a4 47 4f 1b cf |..F.......Z.GO..| 23b9df20 a0 62 03 63 a7 ac 13 24 a6 5a 3f 5a b5 b3 23 52 |.b.c...$.Z?Z..#R| 23b9df30 7e b4 a0 9c 00 4d d1 81 53 e8 89 47 77 dc 6b 8e |~....M..S..Gw.k.| 23b9df40 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 23b9df80 b1 4d 5a ee 9b 76 5e df ca 77 89 b8 f0 7b 94 b0 |.MZ..v^..w...{..| 23b9df90 ce f3 eb d0 a1 9d 7d d7 cd 8e 82 99 08 3e 34 78 |......}......>4x| 23b9dfa0 4b 82 71 02 c0 ab 2b 2d 45 1b 64 5d 5e 69 74 6b |K.q...+-E.d]^itk| 23b9dfb0 92 49 61 cc b0 26 e1 94 fc ed a1 da 39 64 0e f6 |.Ia..&......9d..| 23b9dfc0 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 23ba1e00 42 44 cb 71 49 36 c2 16 f5 c9 bf be 21 cc ef fa |BD.qI6......!...| 23ba1e10 7d 42 5e a4 9f e1 5f 1a 87 9d 94 e9 ac 7f 04 17 |}B^..._.........| 23ba1e20 70 3a ff 73 55 4a e1 04 b7 d6 6f c3 f8 b1 92 83 |p:.sUJ....o.....| 23ba1e30 3d e1 f0 40 30 4c eb e9 bf 4f e5 33 b1 88 12 d6 |[email protected]....| 23ba1e40 b6 12 61 c8 eb 05 78 32 3a fd 48 02 ca e7 2c 62 |..a...x2:.H...,b| 23ba1e50 14 48 e1 c5 e3 08 69 54 15 72 2f 8e 9f 4f d2 98 |.H....iT.r/..O..| 23ba1e60 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 23ba2000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 259b8000

The primary GPT table seems to be located at 0x400:

dd if=/dev/sdh bs=512 count=64 2>&- |hexdump -C

00000000 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 000001c0 8e 0a 72 28 26 36 c9 f9 6a c2 4a c4 fb d9 ce e9 |..r(&6..j.J.....| 000001d0 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 000001f0 ea 0a 7d a7 88 2b db 73 5f cd ce 36 58 48 d3 0e |..}..+.s_..6XH..| 00000200 42 44 cb 71 49 36 c2 16 f5 c9 bf be 21 cc ef fa |BD.qI6......!...| 00000210 7e 9c 92 d3 2c f4 44 9b c1 fb 53 93 b6 59 14 9f |~...,.D...S..Y..| 00000220 c5 6f 89 ad d4 42 59 a5 e4 7a 9d 21 44 10 4f a3 |.o...BY..z.!D.O.| 00000230 3d e1 f0 40 30 4c eb e9 bf 4f e5 33 b1 88 12 d6 |[email protected]....| 00000240 3f b3 78 94 53 e5 74 17 92 0a 3d 93 ce d1 9a a6 |?.x.S.t...=.....| 00000250 14 48 e1 c5 e3 08 69 54 15 72 2f 8e 9f 4f d2 98 |.H....iT.r/..O..| 00000260 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 00000400 b1 4d 5a ee 9b 76 5e df ca 77 89 b8 f0 7b 94 b0 |.MZ..v^..w...{..| 00000410 f3 bf c3 4b 26 09 1c 12 40 65 29 86 d5 40 3b fd |...K&...@e)..@;.| 00000420 c0 da 5b 23 ac e4 c2 32 27 41 5e 4c 2b f4 7d 55 |..[#...2'A^L+.}U| 00000430 7c ca 29 db e9 05 fb a0 ed 21 cd b7 09 44 de 7e ||.)......!...D.~| 00000440 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 00000480 f4 22 f7 2d 7e ac c6 d6 be 1d 7f 49 1d 85 47 53 |.".-~......I..GS| 00000490 08 ea c3 44 ee b6 d6 d3 a2 64 fb d9 0f 43 5f cc |...D.....d...C_.| 000004a0 b0 35 61 22 bf 10 38 c0 7e 27 c1 aa e5 e9 85 91 |.5a"..8.~'......| 000004b0 2d ea 18 01 f1 ce d4 0a 44 b2 3e 41 28 12 9c e1 |-.......D.>A(...| 000004c0 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 00000500 b1 4d 5a ee 9b 76 5e df ca 77 89 b8 f0 7b 94 b0 |.MZ..v^..w...{..| 00000510 00 83 46 fa ee cd ad d4 fa 2e 5a a4 47 4f 1b cf |..F.......Z.GO..| 00000520 a0 62 03 63 a7 ac 13 24 a6 5a 3f 5a b5 b3 23 52 |.b.c...$.Z?Z..#R| 00000530 7e b4 a0 9c 00 4d d1 81 53 e8 89 47 77 dc 6b 8e |~....M..S..Gw.k.| 00000540 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| * 00000580 b1 4d 5a ee 9b 76 5e df ca 77 89 b8 f0 7b 94 b0 |.MZ..v^..w...{..| 00000590 ce f3 eb d0 a1 9d 7d d7 cd 8e 82 99 08 3e 34 78 |......}......>4x| 000005a0 4b 82 71 02 c0 ab 2b 2d 45 1b 64 5d 5e 69 74 6b |K.q...+-E.d]^itk| 000005b0 92 49 61 cc b0 26 e1 94 fc ed a1 da 39 64 0e f6 |.Ia..&......9d..| 000005c0 65 51 44 f7 32 8c 4f 04 6b 7f ad 26 0b 8d 12 c6 |eQD.2.O.k..&....| *

[piperov]

Argh... The formatting looks awful, but I don't see how else to do it. Sorry. Hope it is readable.

[themaddoctor]

Whatever was in those hidden sectors is gone now.

Service-area modules are information in areas of the disk that are inaccessible to normal users. There is a tool called hddsupertool. You can google it because I don't remember the address. It runs on linux and has an option to dump all the WD modules. Maybe the key is hidden in there.