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

[chavonbravo]

Thanks Oopho2ei!

Originally Posted by Octo-puss

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

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

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

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

Originally Posted by NanoBot

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

Originally Posted by 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.

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?

[KenD00]

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

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.

[FoxDisc]

Originally Posted by KenD00

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.

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.

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

Ok please try to use this one and tell me if it worked. At least check if your drive supports "safe mode" before you try that.

[TomZ]

Originally Posted by Oopho2ei

Ok please try to use this one 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.