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