Volume ID firmware patch for PX-B920SA/GGW-H20*/GGC-H20*

[libredr]

Thanks. I have tried to reflash with the original firmware I dumped using flasher. I dumped it after I used a MKB v19 disc, but before using a MKB v25 disc. Unfortunately, it did not "reset" my HRL to the MKB v19 HRL. I flashed with both core and main firmwares. Do you know what I am doing wrong?

[GumbieSlayer]

You only need to flash back the Main section unless the core section is changed during an actual FW change (nothing to do with HRL's etc)

As for the flashing, if you are using Flasher.exe it should just raw flash the data into the drive with whatever you give it as long as the checksums are correct etc.

[libredr]

You only need to flash back the Main section unless the core section is changed during an actual FW change (nothing to do with HRL's etc)

As for the flashing, if you are using Flasher.exe it should just raw flash the data into the drive with whatever you give it as long as the checksums are correct etc.

OK, but I tried to reflash with the old dumped main firmware and did not "reset" the HRL it seems. Does it work on your drive? Thanks.

[GumbieSlayer]

On mine it works fine.
It could be that the software player on the PC has updated and in turn when the drive next tries to play using the player, updates it as well with the keys etc stored in the software player.
Remember on a PC it is not just the drive being updated.

If you dont have it - install AnyDVD HD and try to reflash back to what you started with to see if it sticks this time.

Failing that, send me your original & updated main firmware section compressed with winrar etc (send location of file via PM) and I will have a look at it to see if I can spot anything from here.

[libredr]

Hi, this does not apply: I use Linux and libaacs, so can completely control the VUK storage and software access. Maybe I missed something or am wrong when I assume that I dumped the firmware before inserting the mkb v25 disc. Thanks a lot for your offer anyway, I'll send you the file asap.

[libredr]

Failing that, send me your original & updated main firmware section compressed with winrar etc (send location of file via PM) and I will have a look at it to see if I can spot anything from here.

Hi,

Thanks again for your offer. Please check your PMs, I'll give you the link.

[Wilbert]

@yuanyelss, please remove the spam links from your signature. thanks.

[Guest]

I removed it for him via the mod panel.

[bugmen0t]

All firmware Links are down.

Can someone provide me with a recent patched firmware for GGW-H20L like YL05 or YL07?

[shadowofdarkness]

With the current firmware (BH12LS38 v1.00) you need to change:
Offset 0x5315A - 471A Patch to 401A
Offset 0x53180 - 471A Patch to 401A
Offset 0x531C0 - 4620 Patch to 4020

Then run the checksum option in Flasher.exe on the FW to correct it and flash back.

Poking around inside the BH10NS30 v1.01 it seems the correct offsets should be:
0x550E2 - 471A Patch to 401A
0x55108 - 471A Patch to 401A
0x55148 - 4620 Patch to 4020

A note for anyone doing this:
Backup you firmware
Create a copy of that firmware and modify that
Your original FW contains the drives HRL and AACS keys
Without those, you will not be able to play Bluray movies

I have a BH12LS38 v1.00 and want tomake sure those are all the changes needed for the vid patch so I can watch movies with newer mkb versions then libaacs supports.

II found the right flasher software and backed up my firmware but when I open the main firmware file in a hex editor and go to those offsets they are different values.

[bugmen0t]

All firmware Links are down.

Can someone provide me with a recent patched firmware for GGW-H20L like YL05 or YL07?

Please can someone help me? I desperately need a patched firmware for my GGW-H20L.

PM me if you don't want to post a link publicly.

[spock2000]

I have the patched YL05 firmware. Just PM me with your email address and i'll send it to you:)

[Rupan]

Im also looking for the GGW-H20L patched firmware. Is anyone still around who has a copy?

[tiny]

Here (http://www.mediafire.com/?kw6t6fevul34mu2) is the last version I have.

[sl1pkn07]

anyone have GGC-H20L version 1.03 patched firmware?

[Rupan]

Thank you very much, Tiny. sl1pkn07, you can download the GGC-H20L patch here:
http://www.mediafire.com/?o7ftyf494gi9f7h

[sl1pkn07]

thanks!

[an3k]

Can someone please repost the PX-B920SA 1.03 patched firmware? Couldn't find it anywhere :(

Thank you very much!

[Rupan]

1) Download, compile, and install the Renesas drive firmware utility, flasher (http://sourceforge.net/projects/flasher/). Note: it seems that support for real drive interaction is broken on 64-bit Linux, but compiling it as a 32-bit application works well.


git clone git://flasher.git.sourceforge.net/gitroot/flasher/flasher
cd flasher
CFLAGS='-O2 -m32' cmake .
make
sudo cp ../build/bin/flasher/flasher /usr/local/bin


2) Apply for access and download the KPIT GNU tools (http://www.kpitgnutools.com/index.php) for H8. Note: the upstream version of binutils has not maintained support for the H8 family and (the upstream) objdump contains at least one known bug which affects the accuracy of disassembled instructions.

You can download the binary RPM and extract its contents, then install the relevant objdump executable:

rpm2cpio gnuh8300_v12.02_elf-1-1.i386.rpm | cpio -idmV
sudo cp ./usr/share/gnuh8300_v12.02_elf-1/bin/h8300-elf-objdump /usr/local/bin


Or you can build it from source for your platform:

tar xf binutils-2.23-20121219_rl78_v13.01.tar.bz2
cd binutils-2.23-20121219
./configure --prefix=/usr/local --target=h8300-elf
make
sudo make install


3) Obtain a copy of the firmware file you're interested in (e.g. the GGW-H20L YL05 (http://www.firmwarehq.com/download_409-file_GGW-H20L_YL05%28EW%29.zip.html) firmware) and extract then disassemble it:


unzip 'GGW-H20L_YL05(EW).zip'
flasher -r GGWH20L_YL05.exe
h8300-elf-objdump -D -b binary -m h8300s -EB --start-address=0x400 MAIN_GGWH20L_YL05.exe.bin > h8300s.out

[Rupan]

I can confirm the patch locations. The addresses are absolute file offsets in hex.

YL04 without patch. I can confirm that this particular patch works:

96b04: 01 10 6d f2 stm.l er2-er3,@-sp
96b08: 01 20 6d f4 stm.l er4-er6,@-sp
96b0c: 1b 87 subs #2,er7
96b0e: 0f 83 mov.l er0,er3
96b10: 0f 94 mov.l er1,er4
96b12: 01 00 6f 75 mov.l @(0x1e:16,er7),er5
96b16: 00 1e
96b18: 1a e6 sub.l er6,er6
96b1a: 6e 7e 00 1b mov.b @(0x1b:16,er7),r6l
96b1e: 10 76 shll.l #2,er6
96b20: 10 76 shll.l #2,er6
96b22: 10 76 shll.l #2,er6
96b24: 78 60 6a 2a mov.b @(0x8022b1:32,er6),r2l
96b28: 00 80 22 b1
96b2c: aa 05 cmp.b #0x5,r2l
96b2e: 47 1a beq .+26 (0x96b4a) ; Patch to '40 1A' (BRA .+26)
96b30: fa 05 mov.b #0x5,r2l
96b32: 68 fa mov.b r2l,@er7
96b34: 01 00 6d f5 mov.l er5,@-er7
96b38: fa 01 mov.b #0x1,r2l
96b3a: 6d f2 mov.w r2,@-er7
96b3c: 0f f1 mov.l er7,er1
96b3e: 79 11 00 06 add.w #0x6,r1
96b42: 7a 00 6f 02 mov.l #0x6f020500,er0
96b46: 05 00
96b48: 40 58 bra .+88 (0x96ba2)
96b4a: 78 60 6a 28 mov.b @(0x8022b2:32,er6),r0l
96b4e: 00 80 22 b2
96b52: a8 03 cmp.b #0x3,r0l
96b54: 47 1a beq .+26 (0x96b70) ; Patch to '40 1A' (BRA .+26)
96b56: 0c 8e mov.b r0l,r6l
96b58: 68 fe mov.b r6l,@er7
96b5a: 01 00 6d f5 mov.l er5,@-er7
96b5e: f8 01 mov.b #0x1,r0l
96b60: 6d f0 mov.w r0,@-er7
96b62: 0f f1 mov.l er7,er1
96b64: 79 11 00 06 add.w #0x6,r1
96b68: 7a 00 24 00 mov.l #0x24000500,er0
96b6c: 05 00
96b6e: 40 32 bra .+50 (0x96ba2)
96b70: 0f f0 mov.l er7,er0
96b72: 01 00 6d f0 mov.l er0,@-er7
96b76: 01 00 6d f4 mov.l er4,@-er7
96b7a: 6e 79 00 25 mov.b @(0x25:16,er7),r1l
96b7e: 17 51 extu.w r1
96b80: 0f b0 mov.l er3,er0
96b82: 5e 58 a1 ea jsr @0x58a1ea:24
96b86: 0b 97 adds #4,er7
96b88: 0b 97 adds #4,er7
96b8a: 0c 88 mov.b r0l,r0l
96b8c: 46 20 bne .+32 (0x96bae) ; Patch to '40 20' (BRA .+32)
96b8e: 01 00 6d f5 mov.l er5,@-er7
96b92: f8 01 mov.b #0x1,r0l
96b94: 6d f0 mov.w r0,@-er7
96b96: 0f f1 mov.l er7,er1
96b98: 79 11 00 06 add.w #0x6,r1
96b9c: 7a 00 44 a0 mov.l #0x44a00400,er0
96ba0: 04 00
96ba2: 5e 49 94 b2 jsr @0x4994b2:24
96ba6: 0b 97 adds #4,er7
96ba8: 0b 87 adds #2,er7
96baa: 18 88 sub.b r0l,r0l
96bac: 40 0a bra .+10 (0x96bb8)
96bae: 6e 78 00 1b mov.b @(0x1b:16,er7),r0l
96bb2: 5e 4a 5b c4 jsr @0x4a5bc4:24
96bb6: f8 01 mov.b #0x1,r0l
96bb8: 0b 87 adds #2,er7
96bba: 01 20 6d 76 ldm.l @sp+,er4-er6
96bbe: 01 10 6d 73 ldm.l @sp+,er2-er3
96bc2: 54 70 rts

YL05 with the volume ID patch already applied:

97216: 01 10 6d f2 stm.l er2-er3,@-sp
9721a: 01 20 6d f4 stm.l er4-er6,@-sp
9721e: 1b 87 subs #2,er7
97220: 0f 83 mov.l er0,er3
97222: 0f 94 mov.l er1,er4
97224: 01 00 6f 75 mov.l @(0x1e:16,er7),er5
97228: 00 1e
9722a: 1a e6 sub.l er6,er6
9722c: 6e 7e 00 1b mov.b @(0x1b:16,er7),r6l
97230: 10 76 shll.l #2,er6
97232: 10 76 shll.l #2,er6
97234: 10 76 shll.l #2,er6
97236: 78 60 6a 2a mov.b @(0x8022b1:32,er6),r2l
9723a: 00 80 22 b1
9723e: aa 05 cmp.b #0x5,r2l
97240: 40 1a bra .+26 (0x9725c) ; Already patched
97242: fa 05 mov.b #0x5,r2l
97244: 68 fa mov.b r2l,@er7
97246: 01 00 6d f5 mov.l er5,@-er7
9724a: fa 01 mov.b #0x1,r2l
9724c: 6d f2 mov.w r2,@-er7
9724e: 0f f1 mov.l er7,er1
97250: 79 11 00 06 add.w #0x6,r1
97254: 7a 00 6f 02 mov.l #0x6f020500,er0
97258: 05 00
9725a: 40 58 bra .+88 (0x972b4)
9725c: 78 60 6a 28 mov.b @(0x8022b2:32,er6),r0l
97260: 00 80 22 b2
97264: a8 03 cmp.b #0x3,r0l
97266: 40 1a bra .+26 (0x97282) ; Already patched
97268: 0c 8e mov.b r0l,r6l
9726a: 68 fe mov.b r6l,@er7
9726c: 01 00 6d f5 mov.l er5,@-er7
97270: f8 01 mov.b #0x1,r0l
97272: 6d f0 mov.w r0,@-er7
97274: 0f f1 mov.l er7,er1
97276: 79 11 00 06 add.w #0x6,r1
9727a: 7a 00 24 00 mov.l #0x24000500,er0
9727e: 05 00
97280: 40 32 bra .+50 (0x972b4)
97282: 0f f0 mov.l er7,er0
97284: 01 00 6d f0 mov.l er0,@-er7
97288: 01 00 6d f4 mov.l er4,@-er7
9728c: 6e 79 00 25 mov.b @(0x25:16,er7),r1l
97290: 17 51 extu.w r1
97292: 0f b0 mov.l er3,er0
97294: 5e 58 a9 04 jsr @0x58a904:24
97298: 0b 97 adds #4,er7
9729a: 0b 97 adds #4,er7
9729c: 0c 88 mov.b r0l,r0l
9729e: 40 20 bra .+32 (0x972c0) ; Already patched
972a0: 01 00 6d f5 mov.l er5,@-er7
972a4: f8 01 mov.b #0x1,r0l
972a6: 6d f0 mov.w r0,@-er7
972a8: 0f f1 mov.l er7,er1
972aa: 79 11 00 06 add.w #0x6,r1
972ae: 7a 00 44 a0 mov.l #0x44a00400,er0
972b2: 04 00
972b4: 5e 49 9b c4 jsr @0x499bc4:24
972b8: 0b 97 adds #4,er7
972ba: 0b 87 adds #2,er7
972bc: 18 88 sub.b r0l,r0l
972be: 40 0a bra .+10 (0x972ca)
972c0: 6e 78 00 1b mov.b @(0x1b:16,er7),r0l
972c4: 5e 4a 62 d6 jsr @0x4a62d6:24
972c8: f8 01 mov.b #0x1,r0l
972ca: 0b 87 adds #2,er7
972cc: 01 20 6d 76 ldm.l @sp+,er4-er6
972d0: 01 10 6d 73 ldm.l @sp+,er2-er3
972d4: 54 70 rts

and the corresponding section of YL07:

986be: 01 10 6d f2 stm.l er2-er3,@-sp
986c2: 01 20 6d f4 stm.l er4-er6,@-sp
986c6: 1b 87 subs #2,er7
986c8: 0f 83 mov.l er0,er3
986ca: 0f 94 mov.l er1,er4
986cc: 01 00 6f 75 mov.l @(0x1e:16,er7),er5
986d0: 00 1e
986d2: 1a e6 sub.l er6,er6
986d4: 6e 7e 00 1b mov.b @(0x1b:16,er7),r6l
986d8: 10 76 shll.l #2,er6
986da: 10 76 shll.l #2,er6
986dc: 10 76 shll.l #2,er6
986de: 78 60 6a 2a mov.b @(0x8022b1:32,er6),r2l
986e2: 00 80 22 b1
986e6: aa 05 cmp.b #0x5,r2l
986e8: 47 1a beq .+26 (0x98704) ; Patch to '40 1A' (BRA .+26)
986ea: fa 05 mov.b #0x5,r2l
986ec: 68 fa mov.b r2l,@er7
986ee: 01 00 6d f5 mov.l er5,@-er7
986f2: fa 01 mov.b #0x1,r2l
986f4: 6d f2 mov.w r2,@-er7
986f6: 0f f1 mov.l er7,er1
986f8: 79 11 00 06 add.w #0x6,r1
986fc: 7a 00 6f 02 mov.l #0x6f020500,er0
98700: 05 00
98702: 40 58 bra .+88 (0x9875c)
98704: 78 60 6a 28 mov.b @(0x8022b2:32,er6),r0l
98708: 00 80 22 b2
9870c: a8 03 cmp.b #0x3,r0l
9870e: 47 1a beq .+26 (0x9872a) ; Patch to '40 1A' (BRA .+26)
98710: 0c 8e mov.b r0l,r6l
98712: 68 fe mov.b r6l,@er7
98714: 01 00 6d f5 mov.l er5,@-er7
98718: f8 01 mov.b #0x1,r0l
9871a: 6d f0 mov.w r0,@-er7
9871c: 0f f1 mov.l er7,er1
9871e: 79 11 00 06 add.w #0x6,r1
98722: 7a 00 24 00 mov.l #0x24000500,er0
98726: 05 00
98728: 40 32 bra .+50 (0x9875c)
9872a: 0f f0 mov.l er7,er0
9872c: 01 00 6d f0 mov.l er0,@-er7
98730: 01 00 6d f4 mov.l er4,@-er7
98734: 6e 79 00 25 mov.b @(0x25:16,er7),r1l
98738: 17 51 extu.w r1
9873a: 0f b0 mov.l er3,er0
9873c: 5e 58 be 90 jsr @0x58be90:24
98740: 0b 97 adds #4,er7
98742: 0b 97 adds #4,er7
98744: 0c 88 mov.b r0l,r0l
98746: 46 20 bne .+32 (0x98768) ; Patch to '40 20' (BRA .+32)
98748: 01 00 6d f5 mov.l er5,@-er7
9874c: f8 01 mov.b #0x1,r0l
9874e: 6d f0 mov.w r0,@-er7
98750: 0f f1 mov.l er7,er1
98752: 79 11 00 06 add.w #0x6,r1
98756: 7a 00 44 a0 mov.l #0x44a00400,er0
9875a: 04 00
9875c: 5e 49 b0 6c jsr @0x49b06c:24
98760: 0b 97 adds #4,er7
98762: 0b 87 adds #2,er7
98764: 18 88 sub.b r0l,r0l
98766: 40 0a bra .+10 (0x98772)
98768: 6e 78 00 1b mov.b @(0x1b:16,er7),r0l
9876c: 5e 4a 77 7e jsr @0x4a777e:24
98770: f8 01 mov.b #0x1,r0l
98772: 0b 87 adds #2,er7
98774: 01 20 6d 76 ldm.l @sp+,er4-er6
98778: 01 10 6d 73 ldm.l @sp+,er2-er3
9877c: 54 70 rts

[Rupan]

It is possible to assemble the output of objdump with relative ease. Just stick a header such as the following on your assembly code:

.h8300sn ; 9.1.4 H8/300 Machine Directives

.section .text
.globl _volume_id_yl07
_volume_id_yl07:
stm.l er2-er3,@-sp
stm.l er4-er6,@-sp
...

then run it through as:

$ h8300-elf-as -h-tick-hex -o yl07.o yl07.S
$ h8300-elf-ld -Ttext 0x986be -e _volume_id_yl07 -A h8300sn --oformat binary -o yl07.bin yl07.o

[bugmen0t]

Download links being down for GGC-H20N, I desperately tried to patch the rom myself but I really cant figure out the 1.3 GGC-H20N rom offsets myself....

Can someone provide me a download link for the GGC-H20N v1.03 ?

Best regards

[Rupan]

GGC-H20L 1.03 without the Volume ID patch:

96136: 01 10 6d f2 stm.l er2-er3,@-sp
9613a: 01 20 6d f4 stm.l er4-er6,@-sp
9613e: 1b 87 subs #2,er7
96140: 0f 83 mov.l er0,er3
96142: 0f 94 mov.l er1,er4
96144: 01 00 6f 75 mov.l @(0x1c:16,er7),er5
96148: 00 1c
9614a: 1a e6 sub.l er6,er6
9614c: 6e 7e 00 1b mov.b @(0x1b:16,er7),r6l
96150: 10 76 shll.l #2,er6
96152: 10 76 shll.l #2,er6
96154: 10 76 shll.l #2,er6
96156: 78 60 6a 2a mov.b @(0x8022a9:32,er6),r2l
9615a: 00 80 22 a9
9615e: aa 05 cmp.b #0x5,r2l
96160: 47 1a beq .+26 (0x9617c) ; Patch to '40 1a' (BRA .+26)
96162: fa 05 mov.b #0x5,r2l
96164: 68 fa mov.b r2l,@er7
96166: 01 00 6d f5 mov.l er5,@-er7
9616a: fa 01 mov.b #0x1,r2l
9616c: 6d f2 mov.w r2,@-er7
9616e: 0f f1 mov.l er7,er1
96170: 79 11 00 06 add.w #0x6,r1
96174: 7a 00 6f 02 mov.l #0x6f020500,er0
96178: 05 00
9617a: 40 56 bra .+86 (0x961d2)
9617c: 78 60 6a 28 mov.b @(0x8022aa:32,er6),r0l
96180: 00 80 22 aa
96184: a8 03 cmp.b #0x3,r0l
96186: 47 1a beq .+26 (0x961a2) ; Patch to '40 1a' (BRA .+26)
96188: 0c 8e mov.b r0l,r6l
9618a: 68 fe mov.b r6l,@er7
9618c: 01 00 6d f5 mov.l er5,@-er7
96190: f8 01 mov.b #0x1,r0l
96192: 6d f0 mov.w r0,@-er7
96194: 0f f1 mov.l er7,er1
96196: 79 11 00 06 add.w #0x6,r1
9619a: 7a 00 24 00 mov.l #0x24000500,er0
9619e: 05 00
961a0: 40 30 bra .+48 (0x961d2)
961a2: 0f f0 mov.l er7,er0
961a4: 01 00 6d f0 mov.l er0,@-er7
961a8: 01 00 6d f4 mov.l er4,@-er7
961ac: 0f b0 mov.l er3,er0
961ae: 79 01 00 10 mov.w #0x10,r1
961b2: 5e 58 97 62 jsr @0x589762:24
961b6: 0b 97 adds #4,er7
961b8: 0b 97 adds #4,er7
961ba: 0c 88 mov.b r0l,r0l
961bc: 46 20 bne .+32 (0x961de) ; Patch to '40 20' (BRA .+32)
961be: 01 00 6d f5 mov.l er5,@-er7
961c2: f8 01 mov.b #0x1,r0l
961c4: 6d f0 mov.w r0,@-er7
961c6: 0f f1 mov.l er7,er1
961c8: 79 11 00 06 add.w #0x6,r1
961cc: 7a 00 44 a0 mov.l #0x44a00400,er0
961d0: 04 00
961d2: 5e 49 88 62 jsr @0x498862:24
961d6: 0b 97 adds #4,er7
961d8: 0b 87 adds #2,er7
961da: 18 88 sub.b r0l,r0l
961dc: 40 0a bra .+10 (0x961e8)
961de: 6e 78 00 1b mov.b @(0x1b:16,er7),r0l
961e2: 5e 4a 51 f6 jsr @0x4a51f6:24
961e6: f8 01 mov.b #0x1,r0l
961e8: 0b 87 adds #2,er7
961ea: 01 20 6d 76 ldm.l @sp+,er4-er6
961ee: 01 10 6d 73 ldm.l @sp+,er2-er3
961f2: 54 70 rts

The patch for the GGC-H20N firmware version 1.03 appears to be identical.

[bugmen0t]

GGC-H20L 1.03 without the Volume ID patch:

...


The patch for the GGC-H20N firmware version 1.03 appears to be identical.

:goodpost:

This is exactly what I was looking for, you're the best.

I modded, crc'd and flashed back the patched firmware using this patch, it worked like a charm.

Many thanks Rupan

[Rupan]

The base address at which the MAIN firmware appears to be loaded is 0x40FC00. For YL04, the firmware offset for the interesting function is 0x96B04 so its address in memory would be 0x4A6704. Searching for this value through the YL04 firmware yields 4 offsets:
* 0xAB55C (jsr, in subroutine starting at 0xab2e6)
* 0xAD2B4 (jsr, in subroutine starting at 0xad210)
* 0xAD38E (jsr, in subroutine starting at 0xad306)
* 0xAD48E (jsr, in subroutine starting at 0xad3e0)
I imagine there would be some sort of "ordinal array" (for lack of a better term) which defines function start addresses in some deterministic manner. I've yet to locate this table. Or perhaps there is some main program loop.

[Rupan]

So if you base the ROM segment correctly the jumps start making sense. However, there are also mov instructions like this one:

mov.b @0x812DAC:32, r0l

which seem to reference a RAM section. The values I've seen seem to be pretty close to 0x800000. Does anyone have information about the base for the RAM segment and how large it is, or suggestions to determine these values?

Okay so in firmware GGWH20L-YL07 at virtual address 0x471596 I see this instruction:

mov.b r1l, @(0x800008:32,er0)

and shortly thereafter, at virtual address 0x4715AE, I see a similar instruction:

mov.l #0x800028, er0

so I suppose a good guess is that the RAM is based at 0x800000. Now I wonder how large it is...

[Grok44]

The base address at which the MAIN firmware appears to be loaded is 0x40FC00.

The MAIN firmware for YL07 is loaded at ROM address 0x410000. Bytes 0x0000 to 0x03FF (1024 bytes) of the MAIN firmware file are a header giving the load address and firmware size. The load address (0x00410000) is in location 0x0040:0x0043 and the firmware size (0x001E0000) is in locations 0x0044:0x0047. Location 0x0000:0x0001 contains the checksum.

The actual firmware starts at 0x0400 and it is that byte gets loaded at the load address of 0x410000, as noted above. This is why there is an offset of 0x40FC00 from the location in the firmware file to the corresponding location in ROM.

All of the above appears to apply to all the other GGWH20L and GGWH20N firmware that I have looked at.


I imagine there would be some sort of "ordinal array" (for lack of a better term) which defines function start addresses in some deterministic manner. I've yet to locate this table. Or perhaps there is some main program loop.


In the YL07 firmware file there is a block of code containing 256 4-byte addresses. This starts at 0x38D52 in the MAIN file, 0x448952 in the ROM. This appears to be a jump table that ia indexed by the SCSI code. So to find the starting point for SCSI code AD [READ DISC STRUCTURE], do this:

AD handler address (hex) = 38D52 + 4 * AD = 39006 which is 0x448306 in the ROM.

Since AD has a lot of options there is a chain of subroutines that eventuallyget to the VID code.

Recently I downloaded the firmware file WH14NS40_N.100-A4(ew).zip for one of the newer LD drives and tried flasher on it. Unfortunately flasher failed to extract the firmware from that file -- it gave a "Unknown encryption type" error. Anyone have any better luck with that firmware?

G44

[Rupan]

Regarding the firmware file -

flasher's cmd_ripexe function eventually calls this function:

int get_enckeypos(char* buff,int type){
char udtag[] = "Update Data for HLDS's Drive";
...

so its trying to "decrypt" the firmware until it finds the right key.

The older firmware releases had limited changes to the binary data, likely indicating that a simple XOR was in use for protection. Not a block cipher in any case, otherwise far more bits would be flipped. Unless they've changed that, this firmware probably is similar but slightly different.

Short of disassembling the attached executable to determine the key, I suggest flashing it to the drive in Windows and reading back the firmware using flasher.

Edit:

The interesting function here is called, unsurprisingly, firm_decrypter. The protection is indeed xor-based, but the key is updated at each byte using differing transformation rules for each drive generation. (presumably they change it once in a while for good measure).

[Rupan]

I believe I've found the decryption code for WH14NS40_N1.00-A4.exe in the subroutine starting at 0x411FD0. Grok44, can you confirm?

[Rupan]

WH14NS40_N1.00-A4.exe

Yup, the key is constructed at runtime in the subroutine starting at address 0x411E80 while the subroutine imediately after it (starting at address 0x411FD0) actually does the decryption.

[Grok44]

Rupan,

Glad to hear you uncovered the decryption code for WH14NS40_N1.00-A4.exe.

Unfortunately, I am not able to confirm your results. I don't have any disassembler/decompiler for Windows files and have never really had any experience analyzing Windows programs. I am running Linux on all my computers now. Best I can do with an .exe file is look at in a hex editor.

Also, I do not have the WH14NS40 drive yet -- I was considering getting one but wanted to wait until I could find if a patch could be found for its firmware. Based on what you've found do you think it is feasible to modify the firm_decrypter function in flasher to handle this new encryption?

G44

[Rupan]

I'm not really sure if this is the decryption code. The file it outputs looks pretty random to me (no obvious strings). The putative decryption routine is far more complex than those found in flasher.

For analyzing 32-bit Windows executables I've found that the free version of IDA (here (https://www.hex-rays.com/products/ida/support/download_freeware.shtml)) does an excellent job. You'll need to find a Windows system. I highly recommend using the built-in debugger, setting a breakpoint after the interesting code has executed, then taking a full memory dump. It fills in quite a lot of data that isn't available until runtime.

If you place a breakpoint at address 0x410CD8 then run the updater you'll find a zip file (HDLSBIN.ZIP) containing HLDS_JB7_BRAND_1.00-A4_NOBJ.bin under %APPDATA%\Local\Temp (or somesuch). In any case the filenames are right and you can just do a search to find the exact path. The subroutine which handles this file output starts at address 0x410B00.

[Rupan]

Upon further investigation I've changed my mind about the purpose of these subroutines. It appears that they are related to an unzip operation instead of binary protection. They actually use an open-source wrapper for zlib 1.1.4, as follows:

unzip 0.18 Copyright 1998-2002 Gilles Vollant - http://www.winimage.com/zLibDll

A previous subroutine extracts a bundled ZIP file, HDLSBIN.ZIP, writing it to disk. The subroutine I've identified just unzips it and writes out HLDS_JB7_BRAND_1.00-A4_NOBJ.bin. You could so the same with any other zip-capable archiver, the extracted file and the compressed contents of the ZIP are identical.

This BIN file appears to still be protected somehow. You could place a breakpoint on some Windows APIs to catch file I/O, searching for references to the BIN file. I'll leave that as an exercise to the reader :)

[Rupan]

Here is the GGW-H20L YL07 RPC2 auto-reset patch, courtesy of MCSE (http://ala42.cdfreaks.com/MCSE/):

Offset | Offset | Address | OR | AR | Notes
--------+---------+----------+----+----+---------------------------------------
622212 | 0x97E84 | 0x4A7A84 | 47 | 00 | beq .+0x10 -> nop
622213 | 0x97E85 | 0x4A7A85 | 10 | 00 |
622224 | 0x97E90 | 0x4A7A90 | 46 | 00 | bne .+0x04 -> nop
622225 | 0x97E91 | 0x4A7A91 | 04 | 00 |
622302 | 0x97EDE | 0x4A7ADE | 40 | 46 | bra .+0x02 -> bne .+0x02
622750 | 0x9809E | 0x4A7C9E | 4E | 4F | mov.w #0x4E47, r1 -> mov.w #0x4F4B, r1
622751 | 0x9809F | 0x4A7C9F | 47 | 4B |
622796 | 0x980CC | 0x4A7CCC | AC | AA | cmp.b #1, r4l -> cmp.b #0xFF, r2l
622797 | 0x980CD | 0x4A7CCD | 01 | FF |

[Rupan]

And here is the GGC-H20L 1.03 RPC2 auto-reset patch, also courtesy of MCSE:

Offset | Offset | Address | OR | AR
--------+---------+----------+----+---
612604 | 0x958FC | 0x4A54FC | 47 | 00
612605 | 0x958FD | 0x4A54FD | 10 | 00
612616 | 0x95908 | 0x4A5508 | 46 | 00
612617 | 0x95909 | 0x4A5509 | 04 | 00
612694 | 0x95956 | 0x4A5556 | 40 | 46
613142 | 0x95B16 | 0x4A5716 | 4E | 4F
613143 | 0x95B17 | 0x4A5717 | 47 | 4B
613188 | 0x95B44 | 0x4A5744 | AC | AA
613189 | 0x95B45 | 0x4A5745 | 01 | FF

As expected, the patch is identical.

[Grok44]

.

For analyzing 32-bit Windows executables I've found that the free version of IDA (here (https://www.hex-rays.com/products/ida/support/download_freeware.shtml)) does an excellent job. You'll need to find a Windows system.



Thanks for the link. I downloaded the free IDA and was able to run it on a netbook that has Win7 on it. I loaded the WH14NS40_N.100-A4.exe file, set the breakpoint at 0x410CD8 and started the debugger. But no luck getting it to produce the HDLSBIN.ZIP file. Instead it hit a breakpoint at 0x7744E60E and I also noted an error window popped up saying "ATAPI Device can not be found". That was not an IDA error -- I get the same error when I just try to run the WH14NS40 file by itself which isn't a surprise since my netbook has no ATAPI devices. And that's the only computer I have with an anywhere recent Windows on it.

I suspect there may have been major changes between the GGWH20 and the WH14NS40 firmwares. The GGWH20L_YL07.exe is 2.0 MB and the WH14NS40_N.100-A4.exe is 2.6 MB. Either the new firmware is much larger or they've added to the bloatware in the distribution file.

At this point I think I'll be better off getting a GGW-H20L or N since there is a known patch for it.

As for your RPC2 patches: Does there need to be a change to the checksum to accommodate the other changes?


G44

[sakman]

In the WH14NS40_N1.00-A4.exe, the HLDS_JB7_BRAND_1.00-A4_NOBJ.bin is zipped. The starting address is 0x1653F8 with the bytes in each nibble swapped. Normal "PK" header.

I cut from 0x1653F8 to the end, swapped the bytes, and was able to extract the HLDS_JB7_BRAND_1.00-A4_NOBJ.bin which is 2.00MB.

[Rupan]

Grok44: indeed, you do need to patch the checksum as well.

Here's a pre-packaged changeset for the GGC-H20L 1.03 firmware:

begin 664 MAIN_GGC-H20L_1.03_VolumeID_RPC2_Patch.bsdiff
M0E-$249&-#`V`````````&0```````````0>``````!"6F@Y,4%9)E-9)6V0
M@@```^101"`$`0@`0``0`"``,0P($H:,BW*'83FIXNY(IPH2!*VR$$!"6F@Y
M,4%9)E-9??,+/@`\5?XHY0`0!"!`(```0`!```@`-$(](`!0HT9`T:9&@BE-
M`-`:;4[^ME%Z)I",P`J(AM`(B*3L`J@BEZ^4M`S]6EX]M>BJ@"L^3^+N2*<*
4$@^^86?`0EIH.1=R13A0D```````
`
end

and the same for the GGW-H20L YL07 firmware:

begin 664 MAIN_GGWH20L_YL07_VolumeID_RPC2_Patch.bsdiff
M0E-$249&-#`V`````````&````````````0>``````!"6F@Y,4%9)E-9^,L&
MQ````^#(1"`$`0`$0```("``,0P($H:,BW*'8/HIXNY(IPH2'QE@V(!"6F@Y
M,4%9)E-9(3!_N@`\6'PHY0`0!"!`"``!0``(`#1`/2``4*!IH9&3$$4D``PU
M+UBVD4Q`;0C,*``H<0@@"D\**H(I/5LB\#?DIBML9@`@*S]/XNY(IPH2!"8/
0]T!"6F@Y%W)%.%"0````````
`
end

[Rupan]

Grok44: the breakpoint at 0x7744E60E is in a system library. You can tell because the address is outside of the executable's address space. When running this particular executable you'll hit an exception - you must not pass it to the application or the debugger may lose control of the debugged program. IDA will offer to let you ignore the exception and continue as if it hadn't occurred.

The fact that you're seeing that pop-up window indicates that your breakpoint is not actually being hit. I explicitly chose code which executes prior to generating that error message. If you've set up your breakpoints correctly and not passed the exception to the application the dialog box will not pop up.

[Rupan]

The first two patches (at 0x4A7A8{4,5} and 0x4A7A9{0,1}) cause the subroutine which starts at address 0x4A7A5C to unconditionally return 1 (instead of potentially returning zero). This subroutine is (indirectly) referenced by two SCSI commands: REPORT KEY / MAINTENANCE OUT (0xA4) and READ DISC STRUCTURE (0xAD).

The third patch (at 0x4A7ADE) changes a BRA instruction in the subroutine starting at 0x4A7AC6 into a BNE instruction. The previous instruction copies a byte from (RAM? Flash memory?) to a register. If the byte is nonzero then the BNE instruction branches as it would have originally, otherwise the register is set to the value 5. This probably corresponds with the number of region changes allowed by most DVD/Blu-Ray drives.

The fourth patch (at 0x4A7C9{E,F}) changes an immediate value in a mov.w instruction from 0x4E47 to 0x4F4B. The instruction actually starts at address 0x4A7C9C and is part of the subroutine starting at 0x4A7C72. It isn't immediately clear to me what this change accomplishes.

The final patch (at 0x4A7CC{C,D}) changes the instruction "cmp.b #1, r4l" to "cmp.b #0xFF, r2l". This is part of the same subroutine as patch #4. Prior to the change, the next instruction skips to the end of the loop body if r4l is not exactly equal to 1. Which is interesting, considering that r4l isn't initialized anywhere prior to that instruction in the subroutine.

[Grok44]

Grok44: the breakpoint at 0x7744E60E is in a system library. You can tell because the address is outside of the executable's address space.

I figured the 0x7744E60E was outside the WH14NS40 file's space but I thought it was because I may not have set the breakpoint properly and the analysis just ran off the end and got into the system library. Clearly I wasn't thinking properly. I repeated the analysis and had it continue until the breakpoint was hit. But still no HDLSBIN.ZIP.

However; using the information from sakman (thanks!) I wrote a short program to extract the bytes and swap them. Then unzipping that file I did get HLDS_JB7_BRAND_1.00-A4_NOBJ.bin file.

My extract and swap code (somewhat of a hack job):

/*piznu -- a utility to extract a block of data from a file, swap each pair of bytes,
and then write the result to another file. By Grok44
Usage: piznu -f Inputfile -o Outputfile -s start address (hex)*/

#include <stdio.h>
#include <string.h>
#include <ctype.h>

char *rem;
int readword(int, FILE *);
void writeword(FILE *);

unsigned char byte[10];

int main(int argc, char *argv[])
{
int i, j, k, choice, yn;
long org, start = 0;
short d32k;
FILE *opPtr, *swPtr;
char fname[64], ofname[64];
char dsp1;
int words = 0;
while (--argc)
{
argv++;
if (strcmp (argv [0], "-f") == 0){
strcpy(fname, argv[1]);
argc--; argv++;
}
else if (strcmp (argv [0], "-o") == 0){
strcpy(ofname, argv[1]);
argc--; argv++;
}
else if (strcmp (argv [0], "-s") == 0){
start = strtoul(argv[1], &rem, 16);
argc--; argv++;
}
else
printf("unrecognized option '%s'\n", argv [0]);
}
printf("\nByte swapping %s, starting at location 0x%X and writing to %s\n", fname, start, ofname);

unsigned int add = start, pairs = 0;

if ((swPtr = fopen(ofname, "wb")) == NULL)
printf("Output file could not be opened");
else
fseek(swPtr, 0, SEEK_SET);

if ((opPtr = fopen(fname, "rb")) == NULL)
printf("Input file could not be opened");
else {
fseek(opPtr, start, SEEK_SET);
while(!feof(opPtr)){
words = 0;
words = readword(words, opPtr);
writeword(swPtr);
pairs++;
}
}
fclose(opPtr);
fclose(swPtr);

printf("\n %d byte pairs swapped", pairs);

printf("\n THE END \n");
}

int readword(int wdcnt, FILE *fPtr)
/*Reads a 2-byte word and stores in array byte, then increments word count*/
{
int j;

for (j = 0; j <= 1; j++)
fread(&byte[2 * wdcnt + j], sizeof(char), 1, fPtr);
wdcnt++;

return wdcnt;
}

void writeword(FILE *fPtr)
/*Writes a 2-byte word to file*/
{
int j;

for (j = 1; j >= 0; j--)
fwrite(&byte[j], sizeof(char), 1, fPtr);

return;
}

[Rupan]

For WH12LS30 firmware version I101 (ver. 1.01-C0) can someone confirm the following?:

The SCSI jump table starts at address 0x417982. The subroutine starting at address 0x4629D8 appears to be the "interesting function" for AACSBYPASS. The flow of execution (i.e. inbound code cross references as well as assembly logic) appear here to be identical to the known patches for the GG{W,C}-H20{N,L}. The compiler has made some different choices regarding register usage however, so the instruction mapping is not precisely 1:1.

It seems that the requisite branch patches occur at addresses 0x462A0A, 0x462A30, and 0x462A70. (The same three as for the known patches.)

[Grok44]

Rupan:

I downloaded the WH12LS30_I101.exe, extracted and examined the code. I believe you are right in your conclusions.

One good test to identify the SCSI table is that the jump addresses for SCSI commands 0x02, 0x05, 0x06, 0x07 [and many more] are to the same address. Probably codes that are not used in this firmware. Taking the start of the table at 0x417982 we see that the jumps for the 0x02 et al codes all go to 0x4577C6.

I did a quick disassembly of the 0x4629D8 subroutine and I think you have identified the "design defects" in the code.

No more progress on the WH14NS40 code. It is beginning to look like this is a new species of firmware -- at least in how the code is packaged and encrypted in the loader. I've gone ahead and ordered a GGWH20L.


G44

[Rupan]

I can confirm that the patches I posted above for WH12LS30 firmware version 1.01-C0 do work. I was able to retrieve the volume ID for a MKBv4 Blu-Ray using aacskeys 0.4.0c and forcing AACSBYPASS.

[Rupan]

It turns out that the PX-B920SA uses nearly identical binary code to the GG{C,W}-H20{N,L} family. Of course this makes patching trivial.

The AACSBYPASS patch for the PX-B920SA firmware version 1.03 is identical to the GG{C,W}-H20{N,L} patches. The "interesting function" (which I've started calling "verify_auth") starts at address 0x4A6E16 (MAIN firmware file offset 0x97216). Just apply the previously-posted patches...

Edit:

PX-B920SA firmware 1.03 is nearly identical to GGW-H20L firmware YL05. There are only 14 changes between the files, with no insertions or deletions, most of which are simple changes to firmware version strings. The YL05 patches can be applied as-is to this firmware.

[Rupan]

The LG UH12NS29 is on sale at Newegg (part number N82E16827136252) for $40 this weekend. It is based on a Renesas CPU and the firmware can be decrypted by flasher.

For firmware version 1.00-G0 can someone confirm the following?:
* the SCSI jump table starts at 0x41A580
* the verify_auth function starts at 0x465D12

[Grok44]

For firmware version 1.00-G0 can someone confirm the following?:
* the SCSI jump table starts at 0x41A580
* the verify_auth function starts at 0x465D12

I did a quick check of that firmware and I agree with your analysis.

I compared the verify_auth function with that of the YL05 firmware and it looks like the patch locations are 465D44, 465D6A and 465DAA.

Interesting to note that the MAIN firmware identifies itself as CH10NS20MAIN REV LVL 1.00

G44

[Rupan]

So, for UH12NS29 firmware version 1.00-G0 the following changes are documented:

RPC2 Auto-Reset:
0x465540 : 0x4710 -> 0x0000 ; nop out a branch instruction
0x46554C : 0x4604 -> 0x0000 ; nop out a branch instruction
0x46559A : 0x4002 -> 0x4602 ; change the branch type
0x465764 : mov.w {#0x4E47 -> #0x4F4B}, r1 ; perhaps a function offset?
0x465794 : ORIGINAL: 0xAC01 -> cmp.b #0x01, r4l
CHANGED: 0xAAFF -> cmp.b #0xFF, r2l

AACSBYPASS:
0x465D44: 0x47 -> 0x40 (unconditional branch)
0x465D6A: 0x47 -> 0x40 (unconditional branch)
0x465DDA: 0x46 -> 0x40 (unconditional branch)

The last 2 RPC2 Auto-Reset patches aren't 100% clear to me. One changes the immediate value used in a mov.w instruction - this looks like an offset into a function to me. I've seen some functions where there is a relative jump forward in the code, in small chunks, and maybe this change modifies the behavior ofone of those functions? The other is a comparison based on the FLAGS, I'll have to dust off the instruction manual.

[Rupan]

The two subroutines starting at 0x5455B2 and 0x545634 (the second immediately follows the first in the disassembly) make references to bytes in the firmware starting at 0x5D0000. It appears that at least one of these subroutines actually modifies a significant chunk of the firmware at runtime, even updating the checksum. Hundreds or thousands of bytes.

Hmm, another WTF moment. Why would the firmware risk writing to the flash memory at a static offset, potentially damaging the flash cells there over time? I can only thnk of one reason OTOH: host certificate revocation lists. Can you make heads or tails of it, Grok44?

[Grok44]

I took a look at he 0x5455B2 and 0x545634 subroutines [the '5B2 calls the '634]. There's a loop starting at 0x545652 that appears to be writing to locations 0x5D0000 to 0x5D1FF3 -- that is an area that is all zeros in the firmware file.

If this is a host revocation list as you suggest [and I think you may be right] it may not run every time -- there may be a flag set once it is first writen and then left alone until a later list infects the drive. According to the specs the Host_Cert is 52 bytes long plus a 40 byte signature. However, it would seem that just the 6 bytes of the unique Host ID would be enough for a revocation list.

AACSBYPASS:
0x465D44: 0x47 -> 0x40 (unconditional branch)
0x465D6A: 0x47 -> 0x40 (unconditional branch)
0x465DDA: 0x46 -> 0x40 (unconditional branch)


As for your patches: I believe you have a typo in that last address -- 0x465DDA should really be 0x465DAA. And, as usual, the checksum needs to be fixed. I have found for all these Renesas firmwares that the big-endian 16-bit modular sum of all the 16-bit words, including the checksum, always comes to 0x0001.