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