Log in

View Full Version : Volume ID firmware patch for PX-B920SA/GGW-H20*/GGC-H20*


Pages : 1 2 [3] 4 5

loo3aem3ON
14th March 2009, 20:13
I've tried things on a intel sata controller in safe mode with raid-mode disabled. So I think I have to put up with that my drive is garbage :|
Any news about this issue? Were you able to recover the drive? What could have been the cause for the problem?

gringo5
21st March 2009, 15:15
I've been unable to recover the drive.
I think the cause for this is, that I tried to flash it too often after various alternations.
At the beginning after a reboot it started in normal mode, but at some point it only started in safe mode. And I think that was the point of no return.

richto
16th April 2009, 10:33
Hi,

I think I trashed my GGC-H20L. Tried to apply the 1.03 patch from doom9-forum with the patching-tool under wine. It does 'something' for about 20 secs and then fails with:
Code:
>D: HL-DT-ST BDDVDRW GGC-H20N COR4

Any help much appreciated!

Flash it to GGC-H20N 1.03. I suggest using native Windows.

Then use safe mode to Cross Flash it back to a GGC-H20L if you need lightscribe support.

This trick can also be used to upgrade a Dell OEM drive GBC-H20N to a GGC-H20N (gain HD DVD support).


nb - dont forget to use Media Cde Speed Edit to remove the rip lock and to set auto RPC2 on these frimwares...

wswartzendruber
25th April 2009, 09:19
I would just like to say thank you for the time and effort you have put into this. It works for me.

MPauley73
3rd June 2009, 17:09
I am trying to download the GGC-H20l v1.03 firware but the site is slooooooow. Can someone please mirror the download?

Thanks!

cRTrn13
31st August 2009, 13:51
Wine identifies my drive correctly, but for some reason the firmware update itself does not identify my drive at all when running under wine.
Any ideas? Can't be bothered to install windows on this machine - anyone successfully managed to flash their drives through a Win XP VM at all?

SeeMoreDigital
31st August 2009, 17:55
These links still seem to be working ok: -

http://forum.doom9.org/showthread.php?p=1212638#post1212638

ala42
31st August 2009, 23:53
Wine identifies my drive correctly,
What is the exact drive ID you see ?

cRTrn13
1st September 2009, 07:22
What is the exact drive ID you see ?

Drive D: mapped to /dev/sr1 in the wine config after autodetecting...

cRTrn13
2nd September 2009, 15:22
Drive D: mapped to /dev/sr1 in the wine config after autodetecting...

Ahh got it working through a winxp vm in the end!

bdc202
10th September 2009, 17:17
I don't have such a drive so development and testing are difficult. You are the first to ask for a firmware patch for that particular model.


1. find out the instruction set
2. locate the command 0xAD handler (format code 0x80)
3. find the conditional jump which checks if properly authenticated
4. make your modifications so the volume id is always sent (even if not authenticated)
5. locate the checksum of the firmware image and adjust it
6. update the firmware and test

hint: Look for the error codes which are sent by the drive. If your request for the volume id is denied it's: "5/6F/02" which means "COPY PROTECTION KEY EXCHANGE FAILURE – KEY NOT ESTABLISHED."

I am also looking to modify the Pioneer drive, as I want to be able to watch my bluray movies on Linux.

I have the drive's official firmware already. Please could you give me a few more hints on modification?

Do I need to use a hex editor, for example, or is there another way to disassemble the firmware?

Do you know of any online material that may help me work out what modifications I will need to make?

Thanks.

mrr19121970
24th September 2009, 09:21
I can't edit the first posting so here are the updates:

Patched firmware for GGW-H20N: GGWH20N version XL05 (http://uploaded.to/?id=9degpr)
Patched firmware for GGW-H20L: GGWH20L version YL05 (http://uploaded.to/?id=fdfl6w)


The new firmwares.

steelgtr
24th September 2009, 14:36
The new firmwares.

Will this work for the GGC-H20L?

What does the new FW fix?


thx

bob

SvT
25th September 2009, 00:06
Will this work for the GGC-H20L?
What does the new FW fix?
thx

bob

Here you are ! :) GGC-H20L reads the Volume ID without aacs authentication. (http://forum.doom9.org/showpost.php?p=1159131&postcount=1)

Spork Schivago
30th September 2009, 22:41
Hello. Is there anyone willing to maybe work on the firmware and create a hacked version for the Sony BDU-X10S? I don't think they're going to be releasing any new firmware for it in the future because I think Sony discontinued it so if someone hacks it, they won't have to worry about hacking updated ones. Thanks.

bdc202
24th November 2009, 20:45
Any news on a firmware for the Pioneer BDC-202?

I would be up for working on the firmware, but I have no idea where to start. Tips anyone?

Thanks

ala42
26th November 2009, 01:07
Any news on a firmware for the Pioneer BDC-202?

I would be up for working on the firmware, but I have no idea where to start. Tips anyone?

Step one is to read out the drive's flash rom chip with hardware, as the firmware file is encrypted and transfered to the drive as it is.

shiva-x
18th January 2010, 22:53
Hello,

I've recently bought a Plextor PX-B940SA. Can I safely flash its firmware with the provided firmware for the 920 ? I don't think so actually :confused:

ala42
19th January 2010, 01:58
Hello,

I've recently bought a Plextor PX-B940SA. Can I safely flash its firmware with the provided firmware for the 920 ? I don't think so actually :confused:
The Plextor PX-B940SA is a PIONEER BDR-205 clone. There are not patches of any kind available for Pioneer BD drives.

shiva-x
19th January 2010, 12:22
Can't sg_raw be used to read the flash ROM of a Pioneer (Plextor here) BLURAY drive ?

The problem is that I can't download a firmware/firmware updater for the BDR-205. Maybe it's because there isn't any ...

Ghitulescu
13th August 2010, 14:17
Any progress in respect to this drive or maybe others?

ala42
14th August 2010, 01:06
Any progress in respect to this drive or maybe others?
If you are talking about Pioneer BD drives, there are still no patches of any kind.

pp3800
7th January 2011, 06:34
Hi there,

I was wondering whether any of these firmware patches would work with the LG CH10LS20 or whether anyone knows of a similar patch that would work with this drive?

Thanks!

Pablo.

marshalleq
8th January 2011, 08:56
I am also wondering if it would work with the LG CH10LS20 or the BH10LS30 as I haven't been able to find the other models yet.

mbk406
6th October 2011, 16:50
I am researching how to add a Bluray player to my Linux + MythTV based HTPC.
My current understanding is that a Bluray device with a "Volume Id" patch added to its firmware is the best approach for playing older disc.
Do newer disc (ex. with BD+) use the Volume Id and therefore work with the patched players?
Is using patched players still the recommended method (in light of newer developments on both sides) or is there a better way?
What currently available Bluray devices have "Volume Id" patchs available? Is there a list somewhere?
Sorry if these are foolish or redundant questions.
Thanks for any help.

dougaa
3rd December 2011, 08:53
The new firmwares.
The latest firmware for the GGW-H20L is now YL07. Is a patched version available?

ubuntosaure
2nd January 2012, 09:32
Yes please update firmware patch for LG GGW-H20L :
http://www.lg.com/us/support/product/support-product-profile.jsp?customerModelCode=GGW-H20L&initialTab=documents

------------------
Version History
------------------

YL07
- Write strategy improvement for new BD-R and BD-RE Media

YL05
- Write strategy improvement for new BD-R and BD-RE Media
(BD-R : 24kinds, BD-RE : 4kinds)

YL04
- Addition of write strategy

YL03
- Improved writing quality

YL02
- Improved writing quality


Thanks you.

Grok44
12th January 2012, 23:16
Hi,

New member here -- this is my first post.

Off and on over the past couple of years I have been trying to learn firmware patching because eventually I plan to put a BluRay drive on my Linux computer. The posts on Doom 9 have been very helpful in this effort, and hopefully I can contribute with some info on the GGWH20L YL07 firmware.

I have been learning FW patching by analyzing both the original and patched versions of other LG firmware, including the XL05 version for the GGWH20N drive [no lightscribe] and the YL05 version GGWH20L drive. I compared the patched version with the original to find the block of code where the changes were made and disassembled that to better understand what was being changed and why.

I have also started to analyze the YL07 FW for the GGWH20L drive. Because I am runing Linux the Windows .exe files with the firmware are not directly usable. Instead I extracted the firmware from them by use of Devilclaw's flasher program (very nice program -- available at http://sourceforge.net/projects/flasher/). This program can extract the CORE and MAIN firmware code from the .exe file. For example, running the command:

./flasher -r GGWH20N_XL05.exe

Gives 2 files CORE_GGWH20N_XL05.exe.hex and MAIN_GGWH20N_XL05.exe.hex

Only the MAIN file is changed between the original and the patched version. The disassemby of the changed portion of the code showed what was being done: Three conditional branch instructions are all changed to BRA, and the checksum is adjusted to allow this code to be loaded and run. I found a block of code in MAIN_GGWH20L_YL07.exe.hex similar to that of the YL05 version, disassembled it and from that I believe the following changes will patch the YL07 MAIN firmware to give the VID:

Address Orig Patched
000000 FF 13
0984B8 47 40
0984DE 47 40
098532 46 40

Note: The address is in hex and is relative to the start of the MAIN_GGWH20L_YL07.exe.hex file, NOT the original GGWH20L_YL05.exe file. The byte values are also given in hex. The change at 000000 is for the checksum, the other 3 are the changes of conditional branches to BRA.

Since I don't have this drive yet I am unable to test this change. Also, I do not have a way of putting these changes into a Windows executable file. Therefore, if anyone wants to try the I suggest the following steps:

1) Back up the drive's firmware or otherwise be sure you can return it to the original state.
2) Extract the MAIN_GGWH20L_YL07.exe.hex from GGWH20L_YL05.exe using flasher.
3) Open MAIN_GGWH20L_YL07.exe.hex with a hex editor (I use Okteta) and patch the code in the locations listed above.
4) Use flasher to load the patched firmware on the drive.

Hope this helps.

G44

d9w
21st January 2012, 02:55
Address Orig Patched
000000 FF 13
0984B8 47 40
0984DE 47 40
098532 46 40



Unfortunately, I can confirm this does not work. The drive still works with these bytes changed, but I get "The given Host Certficate / Private Key has been revoked by your drive."

Can someone post a copy of the patched YL05 (or any known good firmware)? Or a diff between normal and patched YL05? Every link to every version of the patched firmware seems to be broken at this point...

Update: I tried backporting your patch to the YL05 firmware (which is available from http://www.firmwarehq.com/LG/GGW-H20L/files.html). I didn't know how to disassemble the code, but by pattern-matching based on the context around your diff in YL07, I think I re-created the original patch:

Address Orig Patched
00001 ff 13
971cc 46 40
97241 47 40
97267 47 40

I haven't tried burning a disk yet, but the drive still seems to work fine, and aacskeys is now able to extract volume IDs.

hajj_3
21st January 2012, 13:09
I wish flasher was able to decrypt HP's encryption, can't backup my firmware and can't extract firmware from a sony optiarc .exe file :(

Ghitulescu
21st January 2012, 14:51
I wish flasher was able to decrypt HP's encryption, can't backup my firmware and can't extract firmware from a sony optiarc .exe file :(

What has Optiarc and HP to do with the subject-matter of this thread?

Grok44
21st January 2012, 17:03
Sorry to hear the patch didn't work.

Here is an extract of my notes from comparing the original and patched versions of the YL05 firmware:

Using flasher extracted the CORE and MAIN YL05 firmwares. A compare of the CORE files shows they are all the same. Comparing the original YL05 with the patched version:
[----@---- GGWH20L]$ cmp -l MAIN_GGWH20L_YL05.exe.hex MAIN_GGWH20L_YL05_VolumeID_Patch.exe.hex
1 377 23
619073 107 100
619111 107 100
619167 106 100

And then making the usual address adjustments and octal to hex conversions gives:
Location Orig Patched
000000 FF 13
097240 47 40
097266 47 40
09729E 46 40

----------------------------------------------------------------

Since I can't test the patch myself myself I am posting the VID section disassembly for both the YL05 and YL07 versions.

Here is the section of the YL05 code that gets patched for VID:

ROM Add. Code Disassembly
004A6E16 0110 STM.L <ER2-ER3>,@-SP
004A6E1A 0120 STM.L <ER4-ER6>,@-SP
004A6E1E 1B87 ADDS #2, ER7
004A6E20 0F83 MOV.L ER0, ER3
004A6E22 0F94 MOV.L ER1, ER4
004A6E24 0100 MOV.L @(1E, ER7), ER5
004A6E2A 1AE6 SUB.L ER6, ER6
004A6E2C 6E7E MOV.B @(1B,ER7), R6L
004A6E30 1076 SHLL.L #2, ER6
004A6E32 1076 SHLL.L #2, ER6
004A6E34 1076 SHLL.L #2, ER6
004A6E36 7860 MOV.B @(8022B1,ER6), R2L
004A6E3E AA05 CMP.B #5, R2L
004A6E40 471A BEQ 4A6E5C 401A BRA 4A6E5C Patched
004A6E42 FA05 MOV.B #5, R2L
004A6E44 68FA MOV.B R2L,@ER7
004A6E46 0100 MOV.L ER5, @-ER7
004A6E4A FA01 MOV.B #1, R2L
004A6E4C 6DF2 MOV.W R2, @-ER7
004A6E4E 0FF1 MOV.L ER7, ER1
004A6E50 7911 ADD.W #6, R1
004A6E54 7A00 MOV.L #6F020500, ER0
004A6E5A 4058 BRA 4A6EB4
004A6E5C 7860 MOV.B @(8022B2,ER6), R0L
004A6E64 A803 CMP.B #3, R0L
004A6E66 471A BEQ 4A6E82 401A BRA 4A6E82 Patched
004A6E68 0C8E MOV.B R0L, R6L
004A6E6A 68FE MOV.B R6L,@ER7
004A6E6C 0100 MOV.L ER5, @-ER7
004A6E70 F801 MOV.B #1, R0L
004A6E72 6DF0 MOV.W R0, @-ER7
004A6E74 0FF1 MOV.L ER7, ER1
004A6E76 7911 ADD.W #6, R1
004A6E7A 7A00 MOV.L #24000500, ER0
004A6E80 4032 BRA 4A6EB4
004A6E82 0FF0 MOV.L ER7, ER0
004A6E84 0100 MOV.L ER0, @-ER7
004A6E88 0100 MOV.L ER4, @-ER7
004A6E8C 6E79 MOV.B @(25,ER7), R1L
004A6E90 1751 EXTU.W R1
004A6E92 0FB0 MOV.L ER3, ER0
004A6E94 5E58 JSR @58A904
004A6E98 0B97 ADDS #4, ER7
004A6E9A 0B97 ADDS #4, ER7
004A6E9C 0C88 MOV.B R0L, R0L
004A6E9E 4620 BNE 4A6EC0 4020 BRA 4A6EC0 Patched

And here is the corresponding section of the YL07 code:

ROM Add. Code Disassembly
004A8088 0110 STM.L <ER2-ER3>,@-SP
004A808C 0120 STM.L <ER4-ER6>,@-SP
004A8090 1B97 ADDS #4, ER7
004A8092 1B87 ADDS #2, ER7
004A8094 0F84 MOV.L ER0, ER4
004A8096 0100 MOV.L ER1, @(2, ER7)
004A809C 0100 MOV.L @(2A, ER7), ER6
004A80A2 1AD5 SUB.L ER5, ER5
004A80A4 6E7D MOV.B @(29,ER7), R5L
004A80A8 1075 SHLL.L #2, ER5
004A80AA 1075 SHLL.L #2, ER5
004A80AC 1075 SHLL.L #2, ER5
004A80AE 7850 MOV.B @(8022B1,ER5), R2L
004A80B6 AA05 CMP.B #5, R2L
004A80B8 471A BEQ 4A80D4 401A BRA 4A80D4 Patched
004A80BA FA05 MOV.B #5, R2L
004A80BC 68FA MOV.B R2L,@ER7
004A80BE 0100 MOV.L ER6, @-ER7
004A80C2 FA01 MOV.B #1, R2L
004A80C4 6DF2 MOV.W R2, @-ER7
004A80C6 0FF1 MOV.L ER7, ER1
004A80C8 7911 ADD.W #6, R1
004A80CC 7A00 MOV.L #6F020500, ER0
004A80D2 4074 BRA 4A8148
004A80D4 7850 MOV.B @(8022B2,ER5), R0L
004A80DC A803 CMP.B #3, R0L
004A80DE 471A BEQ 4A80FA 401A BRA 4A80FA Patched
004A80E0 0C8D MOV.B R0L, R5L
004A80E2 68FD MOV.B R5L,@ER7
004A80E4 0100 MOV.L ER6, @-ER7
004A80E8 F801 MOV.B #1, R0L
004A80EA 6DF0 MOV.W R0, @-ER7
004A80EC 0FF1 MOV.L ER7, ER1
004A80EE 7911 ADD.W #6, R1
004A80F2 7A00 MOV.L #24000500, ER0
004A80F8 404E BRA 4A8148
004A80FA 0FF1 MOV.L ER7, ER1
004A80FC 0FC0 MOV.L ER4, ER0
004A80FE 5E58 JSR @58BE72
004A8102 0C88 MOV.B R0L, R0L
004A8104 472E BEQ 4A8134
004A8106 0100 MOV.L @(22, ER7), ER0
004A810C 0100 MOV.L ER0, @(10, ER4)
004A8112 0FF0 MOV.L ER7, ER0
004A8114 0100 MOV.L ER0, @-ER7
004A8118 0100 MOV.L @(22, ER7), ER0
004A811E 0100 MOV.L ER0, @-ER7
004A8122 7901 MOV.W #14, R1
004A8126 0FC0 MOV.L ER4, ER0
004A8128 5E58 JSR @58BE90
004A812C 0B97 ADDS #4, ER7
004A812E 0B97 ADDS #4, ER7
004A8130 0C88 MOV.B R0L, R0L
004A8132 461E BNE 4A8152 4020 BRA 4A8152 Patched

Code is very similar - differences seem to be in the branch to addresses (but are in same relative positions) and in the swapping of the use of some registers, i.e. ER0 <-> ER1 and ER5 <-> ER6.

Note: In the above listings the address is the address in ROM that the code is stored. To get the corresponding location in the MAIN_ firmware file subtract 0x40FC00.

Hopes this helps figure out what went wrong.

G44

d9w
22nd January 2012, 00:54
Comparing the original YL05 with the patched version:
[----@---- GGWH20L]$ cmp -l MAIN_GGWH20L_YL05.exe.hex MAIN_GGWH20L_YL05_VolumeID_Patch.exe.hex
1 377 23
619073 107 100
619111 107 100
619167 106 100

And then making the usual address adjustments and octal to hex conversions gives:
Location Orig Patched
000000 FF 13
097240 47 40
097266 47 40
09729E 46 40

----------------------------------------------------------------

Since I can't test the patch myself myself I am posting the VID section disassembly for both the YL05 and YL07 versions.

Here is the section of the YL05 code that gets patched for VID:

ROM Add. Code Disassembly


Thanks. The new patch (for YL05) also works. I must have done something weird in my other patch. However, note that if you compare the bytes at YL07 offset 098532, it looks a lot more like YL05 offset 971cc then YL05 offset 09729E. So I wonder if things just moved around.

What tool are you using for the disassembly? What architecture is the embedded CPU?

hajj_3
22nd January 2012, 15:35
What has Optiarc and HP to do with the subject-matter of this thread?

I was just commenting on the Flasher application that was discussed a few posts up. I was hoping if might be able to break hp's encryption, unfortunately it can't :(

Grok44
23rd January 2012, 23:19
Thanks. The new patch (for YL05) also works. I must have done something weird in my other patch. However, note that if you compare the bytes at YL07 offset 098532, it looks a lot more like YL05 offset 971cc then YL05 offset 09729E. So I wonder if things just moved around.

I'm not surprised the "new" patch works for the YL05 firmware. I derived those patch locations by comparing the original YL05 FW (from firmwarehq) with the patched YL05 FW that had previously been linked to on this site. So what you did was to re-create the previously posted patch. You also confirmed that it works http://forum.doom9.org/images/smilies/biggrin.gif

I don't see the YL07 offset 098532 looking more like YL05 offset 971CC. Here is the YL05 code that includes your patch address of 0971CC:

ROM Add. Code Disassembly MAIN FW Add
004A6DB0 0100 MOV.L @(1E, ER7), ER0
004A6DB6 0100 MOV.L ER0, @-ER7
004A6DBA 7901 MOV.W #14, R1
004A6DBE 0FD0 MOV.L ER5, ER0
004A6DC0 5E58 JSR @58A904
004A6DC4 0B97 ADDS #4, ER7
004A6DC6 0B97 ADDS #4, ER7
004A6DC8 0C88 MOV.B R0L, R0L
004A6DCA 461E BNE 4A6DEA
004A6DCC 0100 MOV.L ER6, @-ER7 0971CC
004A6DD0 F801 MOV.B #1, R0L
004A6DD2 6DF0 MOV.W R0, @-ER7
004A6DD4 0FF1 MOV.L ER7, ER1
004A6DD6 7911 ADD.W #6, R1
004A6DDA 7A00 MOV.L #44A00400, ER0
004A6DE0 5E49 JSR @499BC4
004A6DE4 0B97 ADDS #4, ER7
004A6DE6 0B87 ADDS #2, ER7
004A6DE8 4020 BRA 4A6E0A
004A6DEA 18EE SUB.B R6L, R6L
004A6DEC 1AC4 SUB.L ER4, ER4
004A6DEE 0CEC MOV.B R6L, R4L
004A6DF0 0FB0 MOV.L ER3, ER0
004A6DF2 0AC0 ADD.L ER4, ER0
004A6DF4 0FD1 MOV.L ER5, ER1
004A6DF6 0AC1 ADD.L ER4, ER1
004A6DF8 6819 MOV.B R1L,@ER1
004A6DFA 6889 MOV.B R1L,@ER0
004A6DFC 0A0E INC.B R2L
004A6DFE AE10 CMP.B #10, R6L
004A6E00 45EA BCS 4A6DEC
004A6E02 6E78 MOV.B @(25,ER7), R0L
004A6E06 5E4A JSR @4A62D6
004A6E0A 0B87 ADDS #2, ER7
004A6E0C 0120 LDM.L @SP+, <ER4-ER6>
004A6E10 0110 LDM.L @SP+, <ER2-ER3>
004A6E14 5470 RTS 097214
004A6E16 0110 STM.L <ER2-ER3>,@-SP
004A6E1A 0120 STM.L <ER4-ER6>,@-SP

Two things to note here:
1) Location 0971CC contains a 01, not the 46 that you posted and changed to 40.
2) Location 097214 is a RTS instruction (return from subroutine). The next 2 lines, which are the start of the code I previously posted, are the pushing of several registers onto the stack. This appears to be the end of one subroutine and the start of the subroutine that gets patched for the VID. So it doesn't appear to me that location 0971CC should be patched for VID.

Update: I tried backporting your patch to the YL05 firmware (which is available from http://www.firmwarehq.com/LG/GGW-H20L/files.html). I didn't know how to disassemble the code, but by pattern-matching based on the context around your diff in YL07, I think I re-created the original patch:

I am somewhat surprised that your "backported" patch seemed to work. Essentially what you did was the 2 BEQ to BRA patches I had suggested and then a BNE to BRA patch at 0971CC rather than at 09729E. Maybe only the 2 BEQ to BRA patches are all that is required and the BNE's can stay un-patched. Might be worth experimenting on, both on the YL05 and YL07.

The CPU apears to be of the Renesas H8S/2600 family. You can find all the details of the op-codes etc. in the User Manual: rej09b0139_h8s2600.pdf (Google and ye shall find). My disassembler is a home brew hack job. I wrote it because I couldn't find anything available that didn't cost a lot -- OK, so I'm cheap.

G44

DRMsucksballs
14th February 2012, 20:37
Is there somebody who has a working link to the original 1.03 GGC H20N firmware? I'd really like to try it out but all the links are 404s and I've searched everywhere and am unable to find them :-(

xkodi
19th February 2012, 20:57
Address Orig Patched
000000 FF 13
0984B8 47 40
0984DE 47 40
098532 46 40


as 'd9w' confirmed with test in practice your offsets are wrong, but i can confirm they are wrong with not even testing in practice, but just with looking in the YL07 firmware binary code.

so, as far as i can tell, even without owning such drive the correct offsets for YL07 firmware are:

Address Orig Patched
000000 FF 13
0986E8 47 40
09870E 47 40
098746 46 40

so, good luck to the owners of such drives - i'm fairly certain about those offsets based on what i checked.

Grok44
20th February 2012, 02:43
Originally Posted by Grok44 View Post
Address Orig Patched
000000 FF 13
0984B8 47 40
0984DE 47 40
098532 46 40
as 'd9w' confirmed with test in practice your offsets are wrong, but i can confirm they are wrong with not even testing in practice, but just with looking in the YL07 firmware binary code.

so, as far as i can tell, even without owning such drive the correct offsets for YL07 firmware are:

Address Orig Patched
000000 FF 13
0986E8 47 40
09870E 47 40
098746 46 40

so, good luck to the owners of such drives - i'm fairly certain about those offsets based on what i checked.

xkodi:

I took a look at the section of code you indicated needs to be patched. I think you are right -- I compared that code to the section of the YL05 code that is known to work and it is essentially identical. The only differences I see are in the absolute addresses for the JSR's, but that is to be expected. Apparently in my initial post I missed that and instead found a block of code that was close -- but that only counts in horeshoes and hand grenades. My bad!

My disassembly of the YL07 patched subroutine is as follows (as before, subtract 40FC00 to convert from the ROM address to the address in the MAIN_ FW file):

ROM Add. Code Disassembly
004A82BE 0110 STM.L <ER2-ER3>,@-SP
004A82C2 0120 STM.L <ER4-ER6>,@-SP
004A82C6 1B87 ADDS #2, ER7
004A82C8 0F83 MOV.L ER0, ER3
004A82CA 0F94 MOV.L ER1, ER4
004A82CC 0100 MOV.L @(1E, ER7), ER5
004A82D2 1AE6 SUB.L ER6, ER6
004A82D4 6E7E MOV.B @(1B,ER7), R6L
004A82D8 1076 SHLL.L #2, ER6
004A82DA 1076 SHLL.L #2, ER6
004A82DC 1076 SHLL.L #2, ER6
004A82DE 7860 MOV.B @(8022B1,ER6), R2L
004A82E6 AA05 CMP.B #5, R2L
004A82E8 471A BEQ 4A830 Patch to 401A (BRA)
004A82EA FA05 MOV.B #5, R2L
004A82EC 68FA MOV.B R2L,@ER7
004A82EE 0100 MOV.L ER5, @-ER7
004A82F2 FA01 MOV.B #1, R2L
004A82F4 6DF2 MOV.W R2, @-ER7
004A82F6 0FF1 MOV.L ER7, ER1
004A82F8 7911 ADD.W #6, R1
004A82FC 7A00 MOV.L #6F020500, ER0
004A8302 4058 BRA 4A835C
004A8304 7860 MOV.B @(8022B2,ER6), R0L
004A830C A803 CMP.B #3, R0L
004A830E 471A BEQ 4A832A Patch to 401A (BRA)
004A8310 0C8E MOV.B R0L, R6L
004A8312 68FE MOV.B R6L,@ER7
004A8314 0100 MOV.L ER5, @-ER7
004A8318 F801 MOV.B #1, R0L
004A831A 6DF0 MOV.W R0, @-ER7
004A831C 0FF1 MOV.L ER7, ER1
004A831E 7911 ADD.W #6, R1
004A8322 7A00 MOV.L #24000500, ER0
004A8328 4032 BRA 4A835C
004A832A 0FF0 MOV.L ER7, ER0
004A832C 0100 MOV.L ER0, @-ER7
004A8330 0100 MOV.L ER4, @-ER7
004A8334 6E79 MOV.B @(25,ER7), R1L
004A8338 1751 EXTU.W R1
004A833A 0FB0 MOV.L ER3, ER0
004A833C 5E58 JSR @58BE90
004A8340 0B97 ADDS #4, ER7
004A8342 0B97 ADDS #4, ER7
004A8344 0C88 MOV.B R0L, R0L
004A8346 4620 BNE 4A8368 Patch to 4020 (BRA)

Compare that to the YL05 version in my Post #132 above.

G44

Kowalski
19th March 2012, 05:56
Hi ,
Is there a Patched firmware to BDDVDRW CH10LS28 ?

GumbieSlayer
5th May 2012, 15:37
First post here - long time reader of the forums though ;)
This is just a quickie that I will update later with the specifics if anyone s still doing this mod.
I just modded an LG BH12NS35 using these same methods after hunting through the firmware.
They are still (in code) almost exactly the same.

libredr
8th May 2012, 14:36
First post here - long time reader of the forums though ;)
This is just a quickie that I will update later with the specifics if anyone s still doing this mod.
I just modded an LG BH12NS35 using these same methods after hunting through the firmware.
They are still (in code) almost exactly the same.

Amazing! I have a BH10LS30, I did not look at the firmware yet but this is great news! Please do not hesitate to post more information about this!

GumbieSlayer
9th May 2012, 01:01
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

libredr
10th May 2012, 14:33
Many thanks.

libredr
10th May 2012, 16:27
Hi again,

I am under Linux and was able to use flasher utility (which I already successfuly used to update the drive from 1.00 to 1.01 stock firmware). I used an hex editor to do the changes you mentioned (and double checked the offset, etc). Unfortunately, flasher fails to flash this modified main firmware:
$ sudo ../flasher -d /dev/sr0 -f main_firmware.bin
Devilsclaw's LG Renesas Drive Utility
cmd_drive: Opening Drive: /dev/sr0.
cmd_flashfirm: Flashing process started

firm_flasher: Drive should be flashing its light.
firm_flasher: This indicates its flashing its self.
firm_flasher: This can take a while, Please be patiant.
firm_flasher: Failed to write at 0x001E0000
firm_flasher: your drive should still be fine.
cmd_flashfirm: Flashing process failed

The drive is fine indeed, and I could anyway reflash it with the original 1.01 firmware.

Should I use the --checksum option of flasher? (the help says not to use it!)

EDIT: yes, I needed to use checksum to sign the firmware.

libredr
10th May 2012, 17:48
I answer to myself. I went to the original thread about flasher at http://forum.rpc1.org/viewtopic.php?f=2&t=46137 and indeed had to validate the checksum. After this, I could flash my drive with it. After shutting down the computer (note rebooting is not enough, I had to switch off and restart, otherwise the drive is in lock mode), then amazingly, this worked!
Once patched, the drive does read the BR discs even with a revoked host key/cert. Fab!
However, there was a little issue: when I switched from one disc to another, then the drive was unable to read the new disc. The new disc could only be read after rebooting the drive. I reflashed with the unpatched firmware 1.01 and this issue disappeared (but of course I had to put the latest unrevoked host key/cert).

Have you observed the same issue? Note I am on Linux and depends on udev to detect the disc changes. However it seems the problem is with the drive, since when I put the new disc (MKB v25, if this is of any importance), the light flashes forever, as if it was not able to detect it.

GumbieSlayer
11th May 2012, 01:05
I have a similar issue but have not looked into it.
Possible it just needs a reset cmd sent to the drive between discs.

The cheksum section is important since contents of the firmware have been changed.
Original patches changed this as patch 1 (offset 0x00) 2 bytes that needed to be changed along with the 3 patches.
I left that part out since it will depend on your drive/firmware as to what they should be and instead recommend using the checksum tool inside the flasher to change it for you.

As for the HRL (and to see what version you have stored on the drive) for those playing along at home:
If you do a hex search for 0x10 00 00 0C 00 you will come accross something that looks like:
10 00 00 0C 00 04 10 03 00 00 00 07 21 00 00 6C
00 00 00 07 00 00 00 07 00 09 FF FF 00 00 00 0B
00 00 FF FF 00 00 00 16 00 08 FF FF 00 00 00 21
00 03 FF FF 00 00 00 35 00 04 FF FF 00 00 00 4E
00 03 FF FF 00 00 00 54 00 03 FF FF 00 00 00 5E
1D E7 C3 77 3D 41 2E 6D 92 7A D1 2C 75 74 FB E9
A9 0C 8B 68 78 E1 D3 68 38 90 5D 44 C2 86 D8 62
33 D6 44 B9 A5 CD 2C 87

The top line of that includes the highest version stored on the drive (07 in this case)
The 6C on the top line is the length of the stored HRL (calculated from the 0x21 before it)

libredr
11th May 2012, 11:45
Thanks for the info. Do you knowe if it is possible to reflash (and erase or reset) the HRL and DRL in the drive itself?

GumbieSlayer
11th May 2012, 11:51
In theory it would be possible.
The safest and by far easiest route would be to backup the FW on a regular basis.
Then its just a simple case to reflash it back again.

The other option would be to make a backup, play higher MKB disc, backup again and compare the area that was changed.

Edit:
I should add that just changing the HRL will not work.
Each HRL has a matching set of keys issued along with it.
So the HRL, keys and possibly other data would need to be restored to change the version back.

libredr
11th May 2012, 18:17
But do the stock firmwares (provided by LG) have empty DRL and HRLs? I mean, does reflashing resets the drive to the original state? Or is the HRL stored in a non flashable area?
Do you reset your drive when you reflash with the original firmware?
Also, do you reflash with both the core and main firmware parts?

GumbieSlayer
12th May 2012, 02:01
If you look at a few of the posts in the thread you will see there are mentions of "empty" sections of the FW update.
These empty sections are areas where the HRL/keys are stored on the drive but are nothing to do with a FW update.
Flashing directly overwrites the data there with the non-data from the file - essentially it just writes and cares not what it writes over.
When you do the update the traditional way (with the original firmware exe file) it only writes what is needed and skips the blocks where HRL etc are.

There is no "default" version inside the firmware update files at all - just an empty space.