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

[Oopho2ei]

We made a firmware patch which allows you to read the Volume ID without aacs authentication. The following two commands are enough to get the volume id of the disc inserted:
sg_raw -r 8 /dev/sr0 A4 00 00 00 00 00 00 02 00 08 00 00
sg_raw -r 36 /dev/sr0 AD 01 00 00 00 00 00 80 00 24 00 00

Patched firmware for GGC-H20L:
GGC-H20L version 1.03 (http://uploaded.to/?id=z5hzdx)
GGC-H20L version 1.02 (http://uploaded.to/?id=3k6dbb)

Patched firmware for GGC-H20N:
GGC-H20N version 1.03 (http://uploaded.to/?id=kcewkn)
GGC-H20N version 1.02 (http://uploaded.to/?id=dwbuqg)


Patched firmware for GGW-H20L:
GGW-H20L version YL04 (http://uploaded.to/?id=erxzsi)
GGW-H20L version YL03 (http://uploaded.to/?id=pxnydg)

Patched firmware for GGW-H20N:
GGW-H20N version XL04 (http://uploaded.to/?id=p1umev)
GGW-H20N version XL03 (http://uploaded.to/?id=5s0rxf)


Patched firmware for PX-B920SA:
PX-B920SA version 1.01 (http://uploaded.to/?id=95lnko)

If you encounter any problems after programming the drive enter safe mode (keeping eject pressed while power on for 10s) and then program the drive with the original firmware again to restore it to it's previous state. For more details see posting #5 of this thread.

If you need any help let me know. :)

[KenD00]

Interesting that something is happening in this area again. Why are you sending a REPORT KEY command first and then the READ DISC STRUCTURE? The key isn't used later, and why do both commands use a different AGID (00b vs. 11b)?

Hmm, the GGW can do 6x BD-R writing while the PX only 4x, i would be careful to use the PX firmware on the GGW.

:rolleyes:

[Oopho2ei]

Why are you sending a REPORT KEY command first and then the READ DISC STRUCTURE? The key isn't used later, and
Because of the calculation of the Volume ID MAC which would otherwise fail resulting in a delay of 2-3s. The volume id will be returned in any case so it's not necessary.

why do both commands use a different AGID (00b vs. 11b)?
That's my mistake. Actually you would even need to invalidate the agid before using it but those two commands posted here are sufficient to demonstrate that the firmware patch was successful.

Hmm, the GGW can do 6x BD-R writing while the PX only 4x, i would be careful to use the PX firmware on the GGW.
If you have any doubts about this just don't use the patched firmware and wait for other peoples reports of their experiences. If anyone has tested it on his LG GGW-H20L please leave a note here how it went.

[NanoBot]

Hi,

is there a chance to see a patched firmware for the GGC-H20L ( that's the combodrive which can only read BR and HD-DVD ) ?
I think that the firmware of this drive might be patched in a similar way. And because this drive is much cheaper, I can imagine that a lot of people might want to use it to backup their disks. So a patched firmware would be very helpful.

C.U. NanoBot

[Oopho2ei]

is there a chance to see a patched firmware for the GGC-H20L ( that's the combodrive which can only read BR and HD-DVD ) ?
I think that the firmware of this drive might be patched in a similar way. And because this drive is much cheaper, I can imagine that a lot of people might want to use it to backup their disks. So a patched firmware would be very helpful
The code to be patched is identical so this is probably easy. In the meantime please verify that this drive (GGC-H20L) has a safe mode:
1. switch it off
2. press the eject button and keep it pressed
3. power the drive back on
4. wait ~10s
5. release the eject button

Your drive name/id should have changed to some weird looking string and you won't be able to use many basic drive functions. You should however more importantly be able to update the firmware in this mode to recover your drive it if anything should have gone wrong. The drive will leave this mode either automatically (after the firmware update finished successfully) or manually by restart/(power off/on).

[NanoBot]

Hi,

I will check the existence of a safe mode as soon as I get the drive. I just ordered it yesterday and I hopefully will get a hand on it todays afternoon CET or tomorrow.

C.U. NanoBot

[KenD00]

@Oopho2ei:
You are confusing me, i don't see how you can perform VID MAC calculation with just the DRIVE KEY and why do you need to invalidate an AGID before using it, but well, i like more to know what your patch actually does:


Does it enable you to execute any protected command without beeing authenticated?
Do you have to request an AGID for the commands or
Do the commands request an AGID themself silently and
Do you have to invalidate an used AGID


:rolleyes:

[Oopho2ei]

You are confusing me, i don't see how you can perform VID MAC calculation with just the DRIVE KEY and why do you need to invalidate an AGID
Like i told you before you only need the "read disc structure" command to request the volume id. All the agid stuff is optional but recommended.

Does it enable you to execute any protected command without beeing authenticated?
the AD/80 subcommand handler is patched to output the volume id already stored in ram no matter if authentication succeeded or not. No other commands are affected.


[/LIST 1]
Do you have to request an AGID for the commands.
Do the commands request an AGID themself silently and
Do you have to invalidate an used AGID
[/LIST]
This is all about the 16 bytes following the volume id (the mac). These are not directly copied from memory but calculated every time this subcommand handler is called. The function doing this calculation fails if you haven't requested the agid before resulting (for the original firmware) in a hardware error (vendor code A0) message after a delay of multiple seconds. I can't tell you what exactly is causing the delay so i suggest you follow the protocol and invalidate all agids before you request a new one. Only after that you should directly request the volume id effectively skipping the aacs authentication process.

(There could be some cryptographic coprocessor which gets initialized when you request the agid but this is pure speculation.)

[Oopho2ei]

I have added firmware patches for the drives GGW-H20* and GGC-H20* as requested. Please post your feedback.

[NanoBot]

Hi,

I just got my GGC-H20L and the safe mode seems to be there.

Without pressing the eject button it identifies itself in the "Geräteinstanzkennung" ( should be something like deviceinstance in english, I only have a german XP installed ) as
IDE\CDROMHL-DT-ST_BDDVDRW_GGC-H20L_______________1.02____\354B38374F313241333020332020202020202020
Windows sees the drive as a DVD drive and it is fully operational.

When the eject button was pressed during startup, it identifies itself as
IDE\CDROMHL-DT-ST_BDDVDRW_GGC-H20N_______________COR4____\6&24F7E3F0&0&0.0.0
Windows sees the drive as a CD drive and like Oopho2ei said, some drive functions are inoperationable, e.g. the "eject" function of the explorer context menu is not working when in safe mode.

I am now going to flash the drive with the new firmware and will report back later. But before that I have to seek a program which is able to make use of the patched firmware. As far as I remember I need a program which is able to send raw atapi commands to the drive to check if the patch is succesful.

C.U. NanoBot

[Oopho2ei]

You can use PLSCSI if you are running windows or sg_raw (from the sg3-utils package) in linux. Please have a look here for further information: http://forum.doom9.org/showthread.php?t=124294

[NanoBot]

Hi,

back again. Flashing works like a charm, and I tried to use "vid.exe" for Windows, which originally was designed to work with a patched XBOX HD DVD drive. If neccessary I will try PLSCSI also.
For now I tried to read the VID from a Blu-Ray disk, thats "I am legend" europe and it reports:

D:\AACS\VID>vid l
Volume ID retriever 0.3 by Geremia/xt5

using device \\.\l:
Volume ID: 002200008700CEED36BC9800DF1ECA208A01B14F

Ok, now I tested it with PLSCSI:

Reading the VID only takes about 3 seconds to answer and delivers:

D:\AACS\PLSCSI>plscsi.exe -v -x "AD 01 00 00 00 00 00 80 00 24 00 00" -i x24
x 00000000 AD 01 00:00:00:00 00 80:00:24:00 00 .. .. .. .. "-A@@@@@@@$@@"
x 00000000 00:22:00:00 87:00:CE:ED 36:BC:98:00 DF:1E:CA:20 "@"@@G@Nm6<X@_^J "
x 00000010 8A:01:B1:4F 00:00:00:00 00:00:00:00 00:00:00:00 "JA1O@@@@@@@@@@@@"
x 00000020 00:00:00:00 .. .. .. .. .. .. .. .. .. .. .. .. "@@@@"
// 0 = plscsi.main exit int

Using both commands together like suggested gives immediate answers:

D:\AACS\PLSCSI>plscsi.exe -v -x "A4 00 00 00 00 00 00 02 00 08 00 00" -i x24
x 00000000 A4 00 00:00:00:00 00 02:00:08:00 00 .. .. .. .. "$@@@@@@B@H@@"
x 00000000 00:06:00:00 00:00:00:00 AE:AE:AE:AE AE:AE:AE:AE "@F@@@@@@........"
x 00000010 AE:AE:AE:AE AE:AE:AE:AE AE:AE:AE:AE AE:AE:AE:AE "................"
x 00000020 AE:AE:AE:AE .. .. .. .. .. .. .. .. .. .. .. .. "...."
// 0 = plscsi.main exit int

D:\AACS\PLSCSI>plscsi.exe -v -x "AD 01 00 00 00 00 00 80 00 24 00 00" -i x24
x 00000000 AD 01 00:00:00:00 00 80:00:24:00 00 .. .. .. .. "-A@@@@@@@$@@"
x 00000000 00:22:00:00 87:00:CE:ED 36:BC:98:00 DF:1E:CA:20 "@"@@G@Nm6<X@_^J "
x 00000010 8A:01:B1:4F E8:D7:64:F2 E0:07:E1:14 63:E3:BE:79 "JA1OhWdr`GaTcc>y"
x 00000020 F7:A1:F1:46 .. .. .. .. .. .. .. .. .. .. .. .. "w!qF"
// 0 = plscsi.main exit int

So for me it looks like the patch is working like it should. But to be able to verify the vid I would need the suitable processing key ?

C.U. NanoBot

[Oopho2ei]

Reading the VID only takes about 3 seconds to answer and delivers:
The volume id gets stored automatically in ram (of your drive) shortly after you insert the disc. What does take so long is the execution of a function which finally produces the volume id mac (last 16 bytes of the return) which is normally used for the verification of the volume id. Now this function has some requirements which have to be met before it runs successfully and one of those requirements is that you request a valid agid. I really don't know what the function does during these 3s so i suggest you better follow the normal authentication procedure at least to the point where you request the agid. I believe(!) the volume id mac will be wrong in any case unless you perform a successful authentication first so you can simply ignore it.

So for me it looks like the patch is working like it should. But to be able to verify the vid I would need the suitable processing key ?
You could also just try this with a disc you know the volume id of. Actually you only need the media key now. Together with the volume id you will get your volume unique key needed for decryption. Maybe we will see a updated version of aacskeys soon which exploits this patch so you can simply verify the decryption result (using dumphd or whatever tool you use).

Did you check that powerdvd and windvd are working with the patched firmware?

[KenD00]

I have tested the patched GGW-H20L firmware and it works without any problem. I can retrieve the VolumeID unauthenticated from BluRays and HD-DVDs and they are correct. I have that lag too when i directly read the VID, but its gone when i request an AGID before doing so.

Latest PowerDVD 7 doesn't complain about the patch and plays fine.

I was curious why vid works with my drive too although it shouldn't and investigated. Now I know why it does and why aacskeys doesn't detect all errors when reading the VID: it doesn't check the MMC command response, only the IO response (which says good although the MMC command failed). So the aacskeys update will take a little longer, i also need to install linux again ;). For now vid serves the purpose.

Another note, i just discovered that the xbox-hack works also with the Toshiba SD-H802A without any modification :).

:rolleyes:

[NanoBot]

Hi,

latest PowerDVD8 works without problems with the patched firmware installed.

If anybody with a C compiler for Windows installed would be so kind: Could you please modify "vid.exe" to use both commands to get the vid ? The sources for vid.exe are availabe here
http://www.ingenieria-inversa.cl/files/vid.rar

C.U. NanoBot

[Oopho2ei]

The patched firmware is now supported by the latest version of aacskeys: http://forum.doom9.org/showthread.php?p=1162510#post1162510

[chavonbravo]

1.03 firmware released for lg drives. Is it hard to patch this as well?

[Oopho2ei]

1.03 firmware released for lg drives. Is it hard to patch this as well?
It depends on how much has changed in the new Version. We will look at this soon. I generally recommend not to update the firmware with every new release. Are you having problems with Version 1.02?

[NanoBot]

Hi,

the only change in the new firmware is an improved write strategy on some media. Therefore the new firmware is not a "must have", but if you are able to provide a patched version of the new firmware, I would appreciate that.

C.U. NanoBot

[Oopho2ei]

Ok i have uploaded the patched firmware of GGC-H20L v1.03 and GGC-H20N v1.03.

[chavonbravo]

Thanks Oopho2ei!

[Oopho2ei]

Shouldn't this thread be stickied?
Well we will notify the community of new firmware update. This way it will move back to the top.

[NanoBot]

Hi everybody,

I would like just to report in that the modified 1.03 firmware works without problems until now. ATM I am dumping "Matrix HD-DVD" using DumpHD and AACSKeys.

C.U. NanoBot

[Oopho2ei]

I am glad the patch is working fine for you and others. Happy decrypting! :)

[mrr19121970]

my post in http://forum.slysoft.com/showthread.php?t=20116 has a reply that leads me here.

For the layman, what does 'read the Volume ID without aacs authentication' mean, and why would I need to be able to do it ?

Thanks for the help.

[NanoBot]

Hi everybody,

@mrr19121970

at the beginning of the aacs decryption process of a HD-DVD or BD you need to know two data blocks:

A processing key suitable for the media key block version used on that disk, and the volume unique id of the disk to be decrypted. Both data together are used to calculate the volume unique key, which then is used to decrypt the title keys, and at last the title keys are used to decrypt the content on the disk.

To prevent a hacker from doing this, the firmware of a HD-DVD / BD reader normally will refuse to unconditionally tell you the volume unique id. Instead, the player software on your pc ( e.g. WinDVD or PowerDVD ) needs to authenticate itself as a "legitimate" application with a player key, which has to be send to the drive first. And only after the drive has accepted the player key as "valid", it will report back with the volume unique id.

If a player key is known to be compromised, it can be invalidated through an update mechanism included on newly released disks. A list of invalidated player keys is stored in the flash rom of the drive. So e.g. if the aacs authorities may find out the player key used by AnyDVDHD to authenticate itself as a legitimate application, they would be able to invalidate this key, which would make AnyDVDHD temporarily inoperationable ( until Slysoft integrates a new player key into AnyDVDHD, which should not take longer then a few hours :) )

At this point, the patch provided by Oopho2ei comes into the game:

This patch modifies the drive firmware in a way that it will report the volume unique id without the need of an authentification with a player key. By doing so, one part of the aacs protection is completly knocked out, because it is no longer possible to prevent anybody from getting the volume unique id by invalidating the player key used by the ripping software.

C.U. NanoBot

[Oopho2ei]

Has anyone tried the patched firmware with a MKBv10 (or higher?) disc yet? According to "james" from the slysoft team they are now "poisoned". :confused:

Would it break anything if we disable the "update from disc" function of the drive?

[NanoBot]

Hi,

until now I have not tested any mkb10 disks, simply because I don't know which ( europaen ) titles use mkb v10, if they are already existing.

C.U. NanoBot

[Oopho2ei]

until now I have not tested any mkb10 disks, simply because I don't know which ( europaen ) titles use mkb v10, if they are already existing.
ok if you haven't done this already don't do it. I don't know what James means by "poisoned" in this (http://forum.slysoft.com/showpost.php?p=132072&postcount=4) posting and why he refers to our firmware patch. He certainly didn't eat the new discs and felt sick afterwards so this sounds to me like an exploit. I will try to dump the memory of my drive, insert a MKBv10 disc and then dump again and compare. If this is really an exploit i probably have to disable the aacs "update from disc" functions. The drive really shouldn't do more than saving the new MKB record.

[KenD00]

I think he just meant that the Host Certificate used by Anydvd HD got revoked, nothing more. What else should that MKBv10 disc have done? I don't believe that it has checked the firmware for hacks and has done evil things because of that.

:rolleyes:

[Oopho2ei]

I think he just meant that the Host Certificate used by Anydvd HD got revoked, nothing more. What else should that MKBv10 disc have done? I don't believe that it has checked the firmware for hacks and has done evil things because of that.
I know it's unlikely but it's not impossible to exploit a missing boundary check in the firmware (buffer overflow) to execute some code on the drive. I have logged the communication between anydvd and my drive and no authentication took place. Maybe this is only done for unknown discs? :confused:

[KenD00]

Hmm, because the drive updates itself, wouldn't that mean it has to exploit itself :D?

Indeed, Anydvd does authentication only if it doesn't have the disc in its database. So if you don't have a newer disc, try an older Anydvd.

:rolleyes:

[FoxDisc]

I think he just meant that the Host Certificate used by Anydvd HD got revoked, nothing more.

Yes, That's what I thought he meant, too. Host Certificates are revoked in a Host Revocation List on the new disc. When that new disc is inserted into a drive, the drive permanently stores the revocation. That's what I assumed he meant by the drive being "poisoned." ( I know you know this, but others may not)

Indeed, Anydvd does authentication only if it doesn't have the disc in its database. So if you don't have a newer disc, try an older Anydvd.

Of course, if the older AnyDVD uses a revoked Host Cert, and the drive has been poisoned as to that Host Cert, then AnyDVD won't be able to enter a legitimate AACS authenticated session with the drive, so the drive won't hand over the secrets on the disc.

[Oopho2ei]

Yes, there is no reason to panic. I have so far received no complaints about the patched firmware and i am really concerned it works perfectly for everyone. If there should be a problem with newer discs i would like to hear about it as soon as possible to fix it before more people run into the same problem. There is always a risk when using a patched firmware and because a respectable member of slysoft company called the new discs (MKBv10) "poisoned" and was referring in the same posting to this thread i felt like i had to issue this "warning" above.
I personally believe that using a patched firmware on blue ray drives will continue to be a reliable way to retrieve the volume id and that our patch for LG/Plextor drives won't cause any problems. :)

[TomZ]

For information, i've installed this patched bios on my LG drive with success directly under Linux with wine. (I have now windows OS at home so...)
Wine just pops-up me for a missing dll. I've dl it from the net, put it in the .wine tree and it did the trick.

Thx a lot for the patched firmware.

Cheers.

[kkloster21]

@TomZ:

I tried to do the firmware patch as you indicated, in linux but i don't think it is working. I had the same problem as you to start - i needed that dynamic link library. i dled it and put it in the .wine directory. I got this output when i ran wine with the patch executable:

$ wine GGC-H20L_1.03_VolumeID_Patch.exe
wine: Call from 0x402f2d to unimplemented function MFC42.DLL.6648, aborting
wine: Unimplemented function MFC42.DLL.6648 called at address 0x402f2d (thread 0009), starting debugger...
Unhandled exception: unimplemented function MFC42.DLL.6648 called in 32-bit code (0x7bc4569c).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7bc4569c ESP:0032e898 EBP:0032e8fc EFLAGS:00000206( - 00 - -IP1)
EAX:000019f8 EBX:7bc88444 ECX:0032e920 EDX:00d406a4
ESI:0032e8a4 EDI:ffffffff
Stack dump:
0x0032e898: 00000000 00000048 00000002 80000100
0x0032e8a8: 00000001 00000000 00402f2d 00000002
0x0032e8b8: 00410980 000019f8 7bc683db 00d406a4
0x0032e8c8: 0032fd44 0000003b 0000003b 00d406a4
0x0032e8d8: 0000005c 7ee3bb76 00d406a4 0000005c
0x0032e8e8: 00d406be 00000000 0032e920 00000000
Backtrace:
=>1 0x7bc4569c in ntdll (+0x3569c) (0x0032e8fc)
2 0x00402f2d in ggc-h20l_1.03_volumeid_patch (+0x2f2d) (0x0032ff08)
3 0x7b877b27 in kernel32 (+0x57b27) (0x0032ffe8)
0x7bc4569c: subl $4,%esp
Modules:
Module Address Debug info Name (61 modules)
PE 400000- 418000 Export ggc-h20l_1.03_volumeid_patch
PE 5f400000-5f4ed000 Deferred mfc42
ELF 7b800000-7b92d000 Export kernel32<elf>
\-PE 7b820000-7b92d000 \ kernel32
ELF 7bc00000-7bca4000 Export ntdll<elf>
\-PE 7bc10000-7bca4000 \ ntdll
ELF 7bf00000-7bf03000 Deferred <wine-loader>
ELF 7e4a5000-7e506000 Deferred rpcrt4<elf>
\-PE 7e4b0000-7e506000 \ rpcrt4
ELF 7e506000-7e5aa000 Deferred ole32<elf>
\-PE 7e510000-7e5aa000 \ ole32
ELF 7e5e2000-7e5f5000 Deferred libresolv.so.2
ELF 7e60a000-7e628000 Deferred iphlpapi<elf>
\-PE 7e610000-7e628000 \ iphlpapi
ELF 7e628000-7e65b000 Deferred uxtheme<elf>
\-PE 7e630000-7e65b000 \ uxtheme
ELF 7e683000-7e68c000 Deferred libxcursor.so.1
ELF 7e68c000-7e691000 Deferred libxfixes.so.3
ELF 7e691000-7e694000 Deferred libxcomposite.so.1
ELF 7e694000-7e69a000 Deferred libxrandr.so.2
ELF 7e69a000-7e6a2000 Deferred libxrender.so.1
ELF 7e6a2000-7e6a5000 Deferred libxinerama.so.1
ELF 7e6a5000-7e6c5000 Deferred imm32<elf>
\-PE 7e6b0000-7e6c5000 \ imm32
ELF 7e6c5000-7e6ca000 Deferred libxdmcp.so.6
ELF 7e6ca000-7e6e2000 Deferred libxcb.so.1
ELF 7e6e2000-7e6e5000 Deferred libxau.so.6
ELF 7e6e5000-7e7cc000 Deferred libx11.so.6
ELF 7e7cc000-7e7da000 Deferred libxext.so.6
ELF 7e7da000-7e7df000 Deferred libxxf86vm.so.1
ELF 7e7f4000-7e88b000 Deferred winex11<elf>
\-PE 7e800000-7e88b000 \ winex11
ELF 7e8c2000-7e8e3000 Deferred libexpat.so.1
ELF 7e8e3000-7e90d000 Deferred libfontconfig.so.1
ELF 7e90d000-7e922000 Deferred libz.so.1
ELF 7e922000-7e992000 Deferred libfreetype.so.6
ELF 7e992000-7e994000 Deferred libxcb-xlib.so.0
ELF 7e9a7000-7ea66000 Deferred comctl32<elf>
\-PE 7e9b0000-7ea66000 \ comctl32
ELF 7ea66000-7eabf000 Deferred shlwapi<elf>
\-PE 7ea70000-7eabf000 \ shlwapi
ELF 7eabf000-7ebd2000 Deferred shell32<elf>
\-PE 7ead0000-7ebd2000 \ shell32
ELF 7ebd2000-7ed19000 Deferred user32<elf>
\-PE 7ebf0000-7ed19000 \ user32
ELF 7ed19000-7ed6b000 Deferred advapi32<elf>
\-PE 7ed30000-7ed6b000 \ advapi32
ELF 7ed6b000-7ee06000 Deferred gdi32<elf>
\-PE 7ed80000-7ee06000 \ gdi32
ELF 7ee06000-7ee70000 Deferred msvcrt<elf>
\-PE 7ee20000-7ee70000 \ msvcrt
ELF 7ef90000-7ef9b000 Deferred libnss_files.so.2
ELF 7ef9b000-7efa5000 Deferred libnss_nis.so.2
ELF 7efa5000-7efbd000 Deferred libnsl.so.1
ELF 7efbd000-7efc6000 Deferred libnss_compat.so.2
ELF 7efc6000-7efeb000 Deferred libm.so.6
ELF f7c34000-f7c38000 Deferred libdl.so.2
ELF f7c38000-f7d87000 Deferred libc.so.6
ELF f7d88000-f7da0000 Deferred libpthread.so.0
ELF f7db5000-f7eeb000 Deferred libwine.so.1
ELF f7eed000-f7f0c000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
00000008 (D) Z:\home[...]\GGC-H20L_1.03_VolumeID_Patch.exe
00000009 0 <==
0000000c
00000013 0
00000012 0
0000000e 0
0000000d 0
0000000f
00000015 0
00000014 0
00000011 0
00000010 0
00000016
00000017 0
Backtrace:
=>1 0x7bc4569c in ntdll (+0x3569c) (0x0032e8fc)
2 0x00402f2d in ggc-h20l_1.03_volumeid_patch (+0x2f2d) (0x0032ff08)
3 0x7b877b27 in kernel32 (+0x57b27) (0x0032ffe8)
wine: Call from 0x402f2d to unimplemented function MFC42.DLL.6648, aborting
wine: Call from 0x402f2d to unimplemented function MFC42.DLL.6648, aborting

i am running 64-bit linux - could this be a problem? it looks like it is complaining about 32-bit code in the output.

can you offer any advice?

thanks.

[Oopho2ei]

Try to get a MFC42.DLL from win98 or so. When you look through the logfile wine tries to execute function 6648 from MFC42.DLL which is (not yet?) implemented. TomZ should be able to help you.

[TomZ]

Hum... I've taken a MFC42.dll file from a winXP install and used wine on a 32 bit debian...

[Oopho2ei]

Ok please try to use this one (http://uploaded.to/?id=htj82z) and tell me if it worked. At least check if your drive supports "safe mode" before you try that.

[TomZ]

Ok please try to use this one (http://uploaded.to/?id=htj82z) and tell me if it worked. At least check if your drive supports "safe mode" before you try that.

It works. I just tried on my ubuntu amd64 (8.04) with that .dll and it works like a charm. I've put the .dll file in the same directory as the .exe firmware.

[kkloster21]

okay, i used the mfc42.dll file that Oopho2ei posted and was able to run the patch program, but when i click "UPDATE" the status box says this:

Updating was failed. Please repeat that. (Error data = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )

and i've tried it a few times (i hope i haven't damaged the drive!). I have a LG GGC-H20L drive, and the appropriate patch executable. anybody have any ideas?

thanks TomZ and Oopho2ei for helping me out.

[Oopho2ei]

Maybe TomZ should write a small howto. How do you select the drive in the updater?

[TomZ]

ok, i'll do that, but this evening, i'm at work atm (I'm french, it's 9:55 am here ;) )

Have you tried to launch wine as root ? I don't remember if it's important or necessary but who knows.

[kkloster21]

okay, i've been trying things with wine and the patch program and i am still not able to get it to work. with some winecfg settings the patch program can't see the drive at all. if i click "Autodetect..." in winecfg then usually the patch program will see the drive but i still get this error in the command window:

$ wine GGC-H20L_1.03_VolumeID_Patch.exe
fixme:mountmgr:harddisk_ioctl unsupported ioctl 4d014
fixme:mountmgr:harddisk_ioctl unsupported ioctl 4d014
fixme:mountmgr:harddisk_ioctl unsupported ioctl 4d014
fixme:mountmgr:harddisk_ioctl unsupported ioctl 4d014
fixme:mountmgr:harddisk_ioctl unsupported ioctl 4d014
fixme:mountmgr:harddisk_ioctl unsupported ioctl 4d014
fixme:mountmgr:harddisk_ioctl unsupported ioctl 4d014
fixme:mountmgr:harddisk_ioctl unsupported ioctl 4d014

but the patch program will still run. in the patch program, it allows me to select my drive which shows up as:

d: HL-DT-ST BDDVDRW GGC-H20L 1.02

which looks right. if i click "UPDATE" then i get the following error in the patch program status box:

Updating was failed. Please repeat that. (Error data = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )

i tried running wine with sudo and it just said that i didn't own wine (?) - it didn't allow me to run it as superuser. not sure how to proceed. what process did you go through TomZ? did you have to configure wine at all?

[chavonbravo]

Is it possible to patch the firmware so that it won't revoke compromised keys with newer disc insertion?

What are you using to disassemble the firmware? What processor type?

[Oopho2ei]

Is it possible to patch the firmware so that it won't revoke compromised keys with newer disc insertion?
Sure. You would need to disable the MKB update procedure and possibly other aacs functions. This firmware patch instead let's you bypass aacs authentication so it's irrelevant if your certificate (public/private key pair) has been revoked because you don't need it anymore. The drive will always tell you the volume id.
What are you using to disassemble the firmware? What processor type?
There were other people involved who helped me creating this patch and i respect their wish not to make the technical details of the LG/Plextor drives and the update process public. If you have any questions about how the patch works or if you encounter any problems using it feel free to ask. :)

[TomZ]

I'm back. I have the same error when trying to update the firmware. Maybe the problem is due to 64bits version of wine. I've upgraded my firmware under linux 32 bits, before installing linux 64. Maybe you can try with a liveCD / 32 bits version.

[kkloster21]

i tried using a 32-bit LiveCD and i was not able to update the firmware. the patch program was not able to find the target drive. if i put a disc in and it mounted it then the patch program was able to see the drive and it would ask me to remove the disc. once i removed the disc it would give me the same error as before ("Updating was failed...").

seems like all i can do now is to get a small hard drive and actually install 32-bit linux on it. or throw the drive in a windows machine for a few minutes and patch the thing.

does this have something to do with the way linux mounts optical drives? i'm amazed that you were able to do this without any problems at all TomZ.

[Oopho2ei]

It works. I just tried on my ubuntu amd64 (8.04) with that .dll and it works like a charm. I've put the .dll file in the same directory as the .exe firmware.

I'm back. I have the same error when trying to update the firmware. Maybe the problem is due to 64bits version of wine. I've upgraded my firmware under linux 32 bits, before installing linux 64. Maybe you can try with a liveCD / 32 bits version.

These two statements seem to be contradictory.

or throw the drive in a windows machine for a few minutes and patch the thing.
I would suggest you carefully install the drive in a pc with windows operating system and verify that you can use safe mode. After that update to the patched firmware and run some tests. Then carefully put it back in your linux system.

[TomZ]

On my first post i did not try to upgrade my drive as it was already patched. I just launched the app.
But the 2nd time, i've clicked on upgrade even it's already patched to see what happened and i had the same result as kkloster. But maybe it's because my drive is already patched, i don't know...

[kkloster21]

I got the patch to work! TomZ, you were right - I needed to run wine as root. in order to be able to do that i had to change the owner of wine and i was hesitant to do that because the common advice is that you should never run wine as root. but i did and it worked, and the patch has worked beautifully. I can get the VUKs now straight from aacskeys. Thanks Oopho2ei for the great patch and TomZ for your help with getting it going in linux! look for some new keys in the VUK thread ;)

[Oopho2ei]

I got the patch to work! TomZ, you were right - I needed to run wine as root. in order to be able to do that i had to change the owner of wine and i was hesitant to do that because the common advice is that you should never run wine as root. but i did and it worked, and the patch has worked beautifully. I can get the VUKs now straight from aacskeys. Thanks Oopho2ei for the great patch and TomZ for your help with getting it going in linux! look for some new keys in the VUK thread ;)
I am happy to read the patch works well for you. Regarding the issues you had with wine i would recommend you try to find a configuration which can run in user mode (maybe you need to update the device access rights with udev or whatever you use). Everything you download from the internet is potentially hostile and this update you ran as root could have trashed both your linux installation and your drive. :rolleyes:

If you encounter any problems reading new discs (MKBv10 or higher) with the patched firmware please report back so we can fix it.

And again i am not the only one who contributed to this patch so don't thank only me. :)

[kkloster21]

I don't run wine regularly - i installed it only for the purpose of patching my blu-ray drive. i've already changed ownership of wine back to regular user and executing that patch file was the only command i performed with wine using sudo or while it was under root ownership.

as far as encountering problems with new discs, i've had problems playing some of the discs that i've already gotten VUKs for, but i'm pretty sure that it's an issue with mplayer and or my audio codecs/sound card configuration. i'm not sure how i'll know that the problem is due to the patched firmware.

I saw that you said "we" when you talked about uploading the patch but I never saw you mention any other names of people who worked on the patch with you. Again, a big thanks to Oopho2ei and anyone else who worked on these drive patches!

[Oopho2ei]

as far as encountering problems with new discs, i've had problems playing some of the discs that i've already gotten VUKs for, but i'm pretty sure that it's an issue with mplayer and or my audio codecs/sound card configuration. i'm not sure how i'll know that the problem is due to the patched firmware.
Yeah i am having those problems sometimes too. It often helps to set a lot of parameters on the start of mplayer (eg. mplayer -demuxer lavf -ac ffeac3 -fps 24000/1001 -aid 5 ...). There is a linux version of tsmuxer which you can use to scan the container. I once had to patch mplayer so it would recognize the audio id to get English sound. Those are all playback issues (which will be fixed soon by the mplayer development team) and it's not related to the volume id. If the volume id is wrong then the resulting volume unique key is wrong and the "decrypted" blue ray content is all random garbage.

The only exception is currently BD+: There is currently no program which can decrypt a BD+ protected disc in linux but we are working on that. So if you are having problems playing back those discs it's not a problem with mplayer. You should be able to playback the movie for a few seconds and then mplayer is likely to crash. :)

[Oopho2ei]

A new patched firmware (version 04) for the drives GGW-H20N and GGW-H20L is available now.

[TomZ]

Oopho2ei> What is the update for ?

kkloster> Very happy to read the update was successfull !
you can try to use this flag with mplayer to help flawlessly video decoding (with dual-core) :
-lavdopts threads=2:skiploopfilter=all or -lavdopts threads=2:fast:skiploopfilter=all
check the cpu usage with top

bye

[Oopho2ei]

Oopho2ei> What is the update for ?
It's the same volume id patch for a more recent firmware released by LG. If you don't have any problems then you don't have to update. I would announce any change in the patch we apply. :)

[TomZ]

Ok, i think i will not apply this update as it doesn't seem to be necessary for my drive for now ;)

[TomZ]

This week-end i've just patched another LG drive under linux with wine. One more time, it has worked like a charm (new firmaware, version 04).
Thx...

[Wimpy]

I also confirm that flashing YL04 under Wine works, although I grabbed the MFC42.dll from the cab file below.

http://activex.microsoft.com/controls/vc/mfc42.cab

[frogman]

GGC-H20L version 1.03 firmware for LG Dual Drive unit BluRay / HDDVD upgrade from 1.02 ---1.03 was eazy peeze.

Thank-you
PS.
I'm off to buy some BD+ disc in the morning. Oopho2ei any title you think might help the "open source project out just post your wish list. I was looking over the list myself. I was hoping to find the Forth of July "Independence Day by Fox, but I didn't see it in the list? Is it a BD+ Title.

edit: 2008.mar.11 Independence Day BD+ off to the store.

[evdberg]

Did anybody try to do this firmware update using Parallels? Or would it be better to use Bootcamp? Or is there a native firmware upgrade tool for OS-X?

[Oopho2ei]

Did anybody try to do this firmware update using Parallels? Or would it be better to use Bootcamp?
I suggest that everyone who tries to update the drive firmware should use a (temporary) windows installation. Maybe you can setup VMware with scsi/atapi passthrough enabled if you don't want to create a separate windows partition. This should always work (theoretically). I haven't tested it though.

Or is there a native firmware upgrade tool for OS-X?
Not that i know of.

[evdberg]

The reason I asked is that when I use the drive in Parallels, the VM session gets really slow. So I wonder if somebody successfully upgraded his drive using Parallels.

[raymondtrudeau]

hi is there a patch for liteon drives? thank you

[ggking7]

Which one of these patch-able drives would you guys recommend? Is there a clear winner?

[jpoet]

A new patched firmware (version 04) for the drives GGW-H20N and GGW-H20L is available now.

I just bought a GGW-H20L. Looks like the firmware is up to version 05. Once again, the new version is suppose to improve it's writing algorithm.

John

P.S. Thanks to everyone for their hard work!

[loo3aem3ON]

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)

[ggking7]

I'm having trouble patching my GGW-H20L in linux via wine. I'm running wine as root (which is generally not a good idea), and the only way the patch program will detect the drive is if I mount it. It won't patch in that state though because it tells me to remove the disc. Does anyone know how to fix this?

[ggking7]

Fixed this by changing the /dev/cdrom link from /dev/hda to /dev/sr0.

[loo3aem3ON]

Thanks for your replies. I've tried to read the number with a patched drive (cmd AD handler is modified) and for format code 81h i get:
Fixed format, current; Sense key: Illegal Request
Additional sense: Cannot read medium - incompatible format

format code 82h:
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
Sense Key Specific: Error in Command byte 7

I can't tell if the results would be any different after successful authentication.
I remember that i had the same results when i tried it with BD-ROM's and HD-DVD's, however i got a (somehow wrong looking) MediaID when using a non-AACS protected BD-RE. The MediaID should be present on recordables while the Volume ID is not.

However, i can't reproduce this behavior right know and i don't know why, the only thing i changed is that i have the patched YL05 firmware and that this time i misused aacskeys instead of DumpVID :confused:. Now i always get sense code 5/6F/00 - Authentication Failure.

I have also tested it now using my good old MKBv1 HD-DVD drive with aacs authentication and in that case (and using the XBox hack) i got in both cases 5/6F/01 - Key not present.

I've just tried a recordable media and i get a good looking media id but again no Pre-recorded Media Serial Number (as expected) and no volume id (as expected). So it looks to me the patch is working fine. The PMSN is optional according to the aacs specification and it seems it's not present?

[sl1pkn07]

hello

i have a (new) LG GGC-H20L, this firmware is now necesary for dumping BD discs?

the dumpHD 0.60 make me error

The given Host Certficate / Private Key has been revoked by your drive.

[loo3aem3ON]

i have a (new) LG GGC-H20L, this firmware is now necesary for dumping BD discs?
No it's not required if you can authenticate properly. The certificates used for authentication can be revoked. A patched drive doesn't require authentication and will grant you access to protected data on the disc (volume id etc) in any case. If you have no idea of what i am trying to tell you should better use AnyDVD-HD.

[sl1pkn07]

i'm linux user. Anydvd-hd not works for me

[Doom9]

@sl1pkn07: the first post in the DumpHD thread links to detailed instructions on how DumpHD is to be used. I just added a few words about the aacsbypass (patched firmware) and use on Linux.

[kaldi]

Is there anywhere to discuss other firmwares being hacked, make requests, or figure out how to help?

[loo3aem3ON]

Is there anywhere to discuss other firmwares being hacked, make requests, or figure out how to help?
Either in the current thread or in this (https://forum.doom9.org/showthread.php?t=144838) one.

[lchiu7]

Just to get my head around this. I also have a GGC-H20L drive in which the given Host Certficate / Private Key has been revoked by the drive.

Not a problem I thought. Either the discs own have published keys or I can use dumpvid and PowerDVD7 (OEM which came with my drive) to get the keys. And it's not like there is an increasing number of HD-DVD titles coming onto the marketplace!

That works fine for BluRay discs - alas the OEM version of PDVD7 that comes with the drive cannot play HD-DVD's (strange since it is a dual format drive) so I can't use dumpvid.

So I guess I have to flash the drive? Not sure which firmware the drive has and no idea how to find out but I suspect given the drive was purchased middle of last year. it's 1.02 so I need the 1.02 firmware hack?

I also downloaded 1.03 from LG's site in case the flashing doesn't work so I can get the drive back to a normal conditio (I hope)

Does this sound like the right strategy?

Thanks

[edit]

OK - tried to patch the drive (Vista) and the patch program can't find the drive. The dropdown list is empty?

Are you supposed to patch the drive when it's in safe mode? I know the drive is there - I use it all the time!

[update]

I think I need to do more experimenting before posting!

Got the drive into safe mode and this time the patch found the drive. But not sure (and too late to check now) if it was because the drive had firmware 1.03 already (not 1.02) and I was using the wrong patch.

Anyway the patch worked and now aacskeys also works and dumpvid no longer required

So I am pretty satisfied now

[KenD00]

The firmwares you can find in this thread and the new (http://forum.doom9.org/showthread.php?t=144838) thread are not patches for the existing firmware on your drive but patched complete firmwares, you can grab the latest one and use it just like you would use the original firmware from the vendor.

:rolleyes:

[lchiu7]

The firmwares you can find in this thread and the new (http://forum.doom9.org/showthread.php?t=144838) thread are not patches for the existing firmware on your drive but patched complete firmwares, you can grab the latest one and use it just like you would use the original firmware from the vendor.

:rolleyes:

I see. Then not entirely sure why the patching didn't work at first - could not find a drive until I rebooted my machine and set the drive into safe mode.

Anyway all is fine now so appreciate all the great work done by folks to free us from the DRM shackles:thanks:

[loo3aem3ON]

Then not entirely sure why the patching didn't work at first - could not find a drive until I rebooted my machine and set the drive into safe mode.
I was told it's possible to flash the drive with the firmware of a different model when in safe mode. Please double check that you downloaded the right firmware for your drive model. It should detect the drive in windows even when not in safe mode. If it doesn't something is wrong and you should report this here.

[lchiu7]

I was told it's possible to flash the drive with the firmware of a different model when in safe mode. Please double check that you downloaded the right firmware for your drive model. It should detect the drive in windows even when not in safe mode. If it doesn't something is wrong and you should report this here.

I can't really repeat the process (since the drive is correctly flashed) but when I tried both flash images as posted on this thread, they came up with not finding the drive. And I am 100% sure I had the right flash files.

It was only after I booted up in safe mode that the flash files found the drive and I was able to update the firmware. Could just be quirk on my machine - not sure really.

Just happy that it all worked out fine in the end.

[gringo5]

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:
>Updating was failed. Please repeat that. (Error data = 70 00 >04 00 00 00 00 10 0A 00 00 00 8F 81 00 00 00 00 00 00 00 00 >00 00 )

After the failed process it's blue light flashes in a constant rythm.
After a restart it makes no 'bios'-noise and no light - it always identifies itself (in Gentoo Linux and the flashing prog) as
Code:
>D: HL-DT-ST BDDVDRW GGC-H20N COR4

At the end I've tried in windoze: same error as mentioned above.
I've tried all available versions 1.02/1.03 of official and patched firmware. No success.
However I can bring it into so called 'safe-mode' if I hold the 'eject'-button at startup - it changes nothing though (besides it gets the drive blinking again).

Has anyone had something like this? Do I have to trash it - oh man, it is still brand new :´(
Any help much appreciated!

[loo3aem3ON]

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:
Double check that you downloaded the correct firmware. Look at the drive cover for the model/version string. Is the drive empty? Watch the blinking closely and see if you can identify a pattern (e.g. does it blink like 10 times and then there is a pause?). Has the drive been flashed before?

Otherwise unplug the drive and leave it. If you get the identification string (HL-DT-ST BD...) some commands are still executed properly and the drive is not dead. I'll see if i can get you an expert.

[gringo5]

Double check that you downloaded the correct firmware. Look at the drive cover for the model/version string. Is the drive empty? Watch the blinking closely and see if you can identify a pattern (e.g. does it blink like 10 times and then there is a pause?). Has the drive been flashed before?

The firmware matches the drive string on the box. But I will check on the drive cover itself to be sure.
The drive is empty.
There is a blinking pattern and it may actually be like -10times/pause- . But I will check that, too.
The drive has never been flashed before for my knowledge - it's right out of the box. And it was version 1.03 at the start.

[ala42]

After the failed process it's blue light flashes in a constant rythm.
After a restart it makes no 'bios'-noise and no light - it always identifies itself (in Gentoo Linux and the flashing prog) as
Code:
>D: HL-DT-ST BDDVDRW GGC-H20N COR4

LG drives automatically enter safe mode when the firmware checksum is not correct. The firmware CORE part takes over control, this is why you see the COR4 revision code. Possible reasons are:
- the flash rom is defective, which is quite unlikely
- your SATA controller or driver corrupts the firmware while uploading, which was seen with NVidea controllers and drivers before
- the firmware file you downloaded is corrupt

Starting with the last point is the easiest. Get the original firmware from http://au.lgservice.com and flash it from windows in windows safe mode.

In case this does not help, which SATA controller and driver do you use ? If your motherboard also has a different controller, try to use that.

[gringo5]

Thanks for the help!

I've been very busy with work this week so please pardon the delay. I have little time right now, so I will give detailed info later (if necessary).

- the flash rom is defective, which is quite unlikely
- your SATA controller or driver corrupts the firmware while uploading, which was seen with NVidea controllers and drivers before
- the firmware file you downloaded is corrupt
(...)
In case this does not help, which SATA controller and driver do you use ? If your motherboard also has a different controller, try to use that


I can definitely confirm that I'm using one nvidia chipset. I've tried on windows, with the same behaviour - but the windows pc I used actually might had a nvidia chipset as well.
I've somehow not seen the info in this thread, that points out, that nvidia controllers corrupt the bios.
I have a spare controller with a via chipset. I will try that on the weekend.
I'm 95% sure the downloaded firmware is sane.

[c3apollyon]

Any idea when/if there will be a patch for the LG GBW-H20L series? I'm not sure how similar it is to the GGW, etc. on here and wouldn't want to misapply the patch but I'm more than tired about the "revoked" message I get whenever I try to play my legit BDs in Linux.

[kaldi]

Is anyone working on a firmware hack for the Pioneer BDC-202? The firmware binary is pretty easy to get out of the latest update (http://www.pioneerelectronics.com/PUSA/Support/BusinessProducts/Blu-rayDisc+DVDWriters/Blu-rayDiscWriters/ci.BDC-202.Support?tab=B) but I don't really know what to do with it to bypass authentication? Anybody have any suggestions?

[ala42]

Any idea when/if there will be a patch for the LG GBW-H20L series? I'm not sure how similar it is to the GGW, etc. on here and wouldn't want to misapply the patch but I'm more than tired about the "revoked" message I get whenever I try to play my legit BDs in Linux.
A GBW-H20L uses the same hardware as a GGW-H20L. You can crossflash to a GGW-H20L firmware, instructions are here (http://club.cdfreaks.com/f142/lg-blu-ray-crossflash-ggw-h20l-gbw-h20l-be06lu10-be06lu11-260811/#post2187421). You will get better bluray media support and the HDDVD read feature. Crossflashing voids your warranty.

[loo3aem3ON]

Is anyone working on a firmware hack for the Pioneer BDC-202?
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.

I don't really know what to do with it to bypass authentication? Anybody have any suggestions?
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."

[gringo5]

Hi,
I've tested a few things.
First, the blinking pattern after a failed flashing try is 7times/pause.
I've tried with several computers always using my pci-sata controller card from de-lock with a via vt6421 chipset. Tried in safe-mode and normal windows mode. Always failes with above error message.
All tested computers had nforce chipsets onboard (if this matters somehow) - should I try on a non nforce system?
The firmware is definitely right and the drive is definitely a ggc-h20l.
Anything I could do?

[ala42]

Try to use a onboard SATA controller of an Intel chipset. Disable SATA RAID mode.

[ltooz_audis]

I loaded the firmware patch 1.03 for my GGC-H20L successfully, but is there a signature or a way to read the firmware to see the difference between the original & the patched one? I think mine is "poisoned" when I tried the "CHOCOLATE" (MKBv10) and "MADAGASCAR 2" (MKBv12) blu-ray.

[loo3aem3ON]

is there a signature or a way to read the firmware to see the difference between the original & the patched one?
The patched firmware differs by 5 bytes from the original firmware (3 instructions and 2 bytes checksum). The drives verifies the checksum before starting the update process.
I think mine is "poisoned" when I tried the "CHOCOLATE" (MKBv10) and "MADAGASCAR 2" (MKBv12) blu-ray.
The firmware updates mainly overwrite the executable code stored in the drive with a newer version. The drive memory is bigger than 2MB. Some memory sections are dedicated to hold data (like the drive certificate, the updated data structure of host certificate revocations, etc..) only which are left unchanged by the firmware updates.
What the SlySoft people mean by a drive being poisoned is that the host certificate AnyDVD-HD sends to the drive to authenticate has been revoked. The drive knows that (gets poisoned) by storing some data structures from the latest Blu-Ray discs which contain revocation information.
The software your drive is executing now has been modified to allow access to protected contents (volume id, etc.) without authentication. If you don't have to authenticate then you don't need to worry about revocation.

[kaldi]

Unfortunately, I think I'm really out of my league with firmware hacking. I've found the instruction set (I think) to be for the Hitachi H8S/2600. I can't find an IDE that has that instruction set in it, though, and I haven't figured out how to integrate an instruction set into an IDE. And I'm not really sure where to initiate in to the firmware binary if I was going to go through it by hand... Any other suggestions? Which type of conditional branch do other firmwares use in this situation?
I really want to thank loo3aem3ON for being so helpful and involved in so many of the BD projects here. I'm really impressed with his dedication.

[loo3aem3ON]

I've found the instruction set (I think) to be for the Hitachi H8S/2600.
The contents of the file "S1003581.107" (written by BDC202_FW107EU.EXE) looks very random (no visible pattern, high entropy) so it's very likely encrypted or packed. The firmware is transmitted to the drive in it's plain form (decrypted/unpacked). Could you please try TraceSPTI, BusHound or whatever you prefer to record the data passed to the windows api during a firmware update? The packets which carry the raw firmware are usually very long compared to the rest.

[gringo5]

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 :|

[ala42]

@gringo5: read your PM.

[ltooz_audis]

The patched firmware differs by
The software your drive is executing now has been modified to allow access to protected contents (volume id, etc.) without authentication. If you don't have to authenticate then you don't need to worry about revocation.
You're right on the dot.... I tried the "BODY OF LIES" today, which HDdump reported MKBv12, AnyDVD 6.5.2.6 works fine. The speed is great. Thanks guys.....

Safemode
http://i184.photobucket.com/albums/x193/Bmle06/BLURAYnHD/ggch20l_safemode.jpg

FIRMWARE UPDATE WITH ORIGINAL
http://i184.photobucket.com/albums/x193/Bmle06/BLURAYnHD/ggch20l_update.jpg

Put back in safe mode and update with the patch and finally
MKBv12 with 17Mb/sec transfer rate.

http://i184.photobucket.com/albums/x193/Bmle06/BLURAYnHD/AnyDVD_bodyoflies.jpg

Since the drive was "poisoned", I would like to thank all for the "Antidote"....

:thanks::thanks::thanks:

[loo3aem3ON]

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]

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]

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]

I would just like to say thank you for the time and effort you have put into this. It works for me.

[MPauley73]

I am trying to download the GGC-H20l v1.03 firware but the site is slooooooow. Can someone please mirror the download?

Thanks!

[cRTrn13]

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]

These links still seem to be working ok: -

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

[ala42]

Wine identifies my drive correctly,
What is the exact drive ID you see ?

[cRTrn13]

What is the exact drive ID you see ?

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

[cRTrn13]

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

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

[bdc202]

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]

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]

The new firmwares.

Will this work for the GGC-H20L?

What does the new FW fix?


thx

bob

[SvT]

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]

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]

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]

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]

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]

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]

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]

Any progress in respect to this drive or maybe others?

[ala42]

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]

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]

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]

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]

The new firmwares.
The latest firmware for the GGW-H20L is now YL07. Is a patched version available?

[ubuntosaure]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Hi ,
Is there a Patched firmware to BDDVDRW CH10LS28 ?

[GumbieSlayer]

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]

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]

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]

Many thanks.

[libredr]

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]

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]

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]

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]

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]

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]

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.

[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.

[Rupan]

Yes, that typo was my bad; 0x465DDA should have been 0x465DAA - thanks for the correction.

Actually I have an update for the WH14NS40 1.00A4 firmware. I've confirmed that the incorrectly identified function at 0x411FD0 is in fact a part of the zlib 1.1.4 code available here:

http://www.winimage.com/zLibDll/index.html

This subroutine corresponds to crc32() function from zlib. I can also confirm that most (all?) of the code between 0x00410E70 0x004149C0 is also zlib.

[ranXerox]

Hi,

I didnt see this mentioned in the threads but since its another plextor i though ti would inquire if this was possible to mod as well?

- ranXerox

[ranXerox]

Anyone have an answer to this?

All im trying to do is play some BR movies on my linux workstation..

Ive went through the usual steps but im running into a issue where the keys are revoked so im trying to figure out how to extract the VolumeID keys which apparently is whats needed ?

If someone wants to point me to a particular post or wiki that might help, PM me..

thanks.

ranXerox