Finally handling BD+ (?)

[loo3aem3ON]

just to report that it doesn't work with Ice Age, both "BDVM Debugger v0.1.1" and libbluray-0.0.2 produce the same byte by byte identical conv_tab.bin, but the reconstructed M2TS file with content_repair.c is even more broken than the BD+ protected one.
Please upload the conv_tab.bin (uploaded.to/rapidshare/whatever..). Also try to use DumpHD v0.5 which supports repairing BD+ protected movies with a given decrypted conversion table.

Thanks for reporting.

[KenD00]

Have you opened the conv_tab.bin with ConvTableView 0.2? Does the log show any messages?

:rolleyes:

[xkodi]

Please upload the conv_tab.bin (uploaded.to/rapidshare/whatever..).

http://rapidshare.de/files/40895949/conv_tab.bin.html

Have you opened the conv_tab.bin with ConvTableView 0.2? Does the log show any messages?

yes, i can see the segments with ConvTableView 0.2 without any errors, also no errors are reported by the BDVM Debugger:


java -jar bdvmdbg-0.1.1.jar "$@"
[W] No post-trap snapshot archive found!
[W] No post-break snapshot archive found!
[W] No program counter trace found!
[W] No instruction trace found!
[W] No timer trace found!
Loading /iceage/BDSVM/00000.svm ...
[Event #00000000] 0110 ( 00000000, 0000FFFF )
[Event #00000001] 0210 ( 00000000, 00000001 )
[Event #00000002] 0110 ( 00000000, 00000001 )
Conversion table set
[Event #00000003] 0220 ( 00000000, 00000001, 00000000)
[Event #00000004] 0220 ( 00000000, 00000001, 00000001)
[Event #00000005] 0220 ( 00000000, 00000001, 00000002)
[Event #00000006] 0220 ( 00000000, 00000001, 00000003)
[Event #00000007] 0220 ( 00000000, 00000001, 00000004)
[Event #00000008] 0220 ( 00000000, 00000001, 00000005)
[Event #00000009] 0220 ( 00000000, 00000001, 00000006)
[Event #0000000A] 0220 ( 00000000, 00000001, 00000007)
[Event #0000000B] 0220 ( 00000000, 00000001, 00000008)
[Event #0000000C] 0220 ( 00000000, 00000001, 00000009)
[Event #0000000D] 0220 ( 00000000, 00000001, 0000000A)
[Event #0000000E] 0220 ( 00000000, 00000001, 0000000B)
[Event #0000000F] 0220 ( 00000000, 00000001, 0000000C)
[Event #00000010] 0220 ( 00000000, 00000001, 0000000D)
[Event #00000011] 0220 ( 00000000, 00000001, 0000000E)
[Event #00000012] 0220 ( 00000000, 00000001, 0000000F)
[Event #00000013] 0220 ( 00000000, 00000001, 00000010)
[Event #00000014] 0220 ( 00000000, 00000001, 00000011)
[Event #00000015] 0220 ( 00000000, 00000001, 00000012)
[Event #00000016] 0220 ( 00000000, 00000001, 00000013)
[Event #00000017] 0220 ( 00000000, 00000001, 00000014)
[Event #00000018] 0220 ( 00000000, 00000001, 00000015)
[Event #00000019] 0220 ( 00000000, 00000001, 00000016)
[Event #0000001A] 0220 ( 00000000, 00000001, 00000017)
[Event #0000001B] 0220 ( 00000000, 00000001, 00000018)
[Event #0000001C] 0220 ( 00000000, 00000001, 00000019)
[Event #0000001D] 0220 ( 00000000, 00000001, 0000001A)
[Event #0000001E] 0220 ( 00000000, 00000001, 0000001B)
[Event #0000001F] 0220 ( 00000000, 00000001, 0000001C)
[Event #00000020] 0220 ( 00000000, 00000001, 0000001D)
[Event #00000021] 0220 ( 00000000, 00000001, 0000001E)
[Event #00000022] 0220 ( 00000000, 00000001, 0000001F)
[Event #00000023] 0220 ( 00000000, 00000001, 00000020)
[Event #00000024] 0220 ( 00000000, 00000001, 00000021)
[Event #00000025] 0220 ( 00000000, 00000001, 00000022)
[Event #00000026] 0220 ( 00000000, 00000001, 00000023)
[Event #00000027] 0220 ( 00000000, 00000001, 00000024)
[Event #00000028] 0220 ( 00000000, 00000001, 00000025)
[Event #00000029] 0220 ( 00000000, 00000001, 00000026)
[Event #0000002A] 0220 ( 00000000, 00000001, 00000027)
[Event #0000002B] 0220 ( 00000000, 00000001, 00000028)
[Event #0000002C] 0220 ( 00000000, 00000001, 00000029)
[Event #0000002D] 0220 ( 00000000, 00000001, 0000002A)
[Event #0000002E] 0220 ( 00000000, 00000001, 0000002B)
[Event #0000002F] 0220 ( 00000000, 00000001, 0000002C)
[Event #00000030] 0220 ( 00000000, 00000001, 0000002D)
[Event #00000031] 0220 ( 00000000, 00000001, 0000002E)
[Event #00000032] 0220 ( 00000000, 00000001, 0000002F)
[Event #00000033] 0220 ( 00000000, 00000001, 00000030)
[Event #00000034] 0220 ( 00000000, 00000001, 00000031)
[Event #00000035] 0220 ( 00000000, 00000001, 00000032)
[Event #00000036] 0220 ( 00000000, 00000001, 00000033)
[Event #00000037] 0220 ( 00000000, 00000001, 00000034)
[Event #00000038] 0220 ( 00000000, 00000001, 00000035)
[Event #00000039] 0220 ( 00000000, 00000001, 00000036)
[Event #0000003A] 0220 ( 00000000, 00000001, 00000037)
[Event #0000003B] 0220 ( 00000000, 00000001, 00000038)
[Event #0000003C] 0220 ( 00000000, 00000001, 00000039)
[Event #0000003D] 0220 ( 00000000, 00000001, 0000003A)
[Event #0000003E] 0220 ( 00000000, 00000001, 0000003B)
[Event #0000003F] 0220 ( 00000000, 00000001, 0000003C)
[Event #00000040] 0220 ( 00000000, 00000001, 0000003D)
[Event #00000041] 0220 ( 00000000, 00000001, 0000003E)
[Event #00000042] 0220 ( 00000000, 00000001, 0000003F)
[Event #00000043] 0220 ( 00000000, 00000001, 00000040)
[Event #00000044] 0220 ( 00000000, 00000001, 00000041)
[Event #00000045] 0220 ( 00000000, 00000001, 00000042)
[Event #00000046] 0220 ( 00000000, 00000001, 00000043)
[Event #00000047] 0220 ( 00000000, 00000001, 00000044)
[Event #00000048] 0220 ( 00000000, 00000001, 00000045)
[Event #00000049] 0220 ( 00000000, 00000001, 00000046)
[Event #0000004A] 0220 ( 00000000, 00000001, 00000047)
[Event #0000004B] 0220 ( 00000000, 00000001, 00000048)
[Event #0000004C] 0220 ( 00000000, 00000001, 00000049)
[Event #0000004D] 0220 ( 00000000, 00000001, 0000004A)
[Event #0000004E] 0220 ( 00000000, 00000001, 0000004B)
[Event #0000004F] 0220 ( 00000000, 00000001, 0000004C)
[Event #00000050] 0220 ( 00000000, 00000001, 0000004D)
[Event #00000051] 0220 ( 00000000, 00000001, 0000004E)
[Event #00000052] 0220 ( 00000000, 00000001, 0000004F)
[Event #00000053] 0220 ( 00000000, 00000001, 00000050)
[Event #00000054] 0220 ( 00000000, 00000001, 00000051)
[Event #00000055] 0220 ( 00000000, 00000001, 00000052)
[Event #00000056] 0220 ( 00000000, 00000001, 00000053)
[Event #00000057] 0220 ( 00000000, 00000001, 00000054)
[Event #00000058] 0220 ( 00000000, 00000001, 00000055)
[Event #00000059] 0220 ( 00000000, 00000001, 00000056)
[Event #0000005A] 0220 ( 00000000, 00000001, 00000057)
[Event #0000005B] 0220 ( 00000000, 00000001, 00000058)
[Event #0000005C] 0220 ( 00000000, 00000001, 00000059)
[Event #0000005D] 0220 ( 00000000, 00000001, 0000005A)
[Event #0000005E] 0220 ( 00000000, 00000001, 0000005B)
[Event #0000005F] 0220 ( 00000000, 00000001, 0000005C)
[Event #00000060] 0220 ( 00000000, 00000001, 0000005D)
[Event #00000061] 0220 ( 00000000, 00000001, 0000005E)
[Event #00000062] 0220 ( 00000000, 00000001, 0000005F)
[Event #00000063] 0220 ( 00000000, 00000001, 00000060)
[Event #00000064] 0220 ( 00000000, 00000001, 00000061)
[Event #00000065] 0220 ( 00000000, 00000001, 00000062)
[Event #00000066] 0220 ( 00000000, 00000001, 00000063)
[Event #00000067] 0220 ( 00000000, 00000001, 00000064)
[Event #00000068] 0220 ( 00000000, 00000001, 00000065)
[Event #00000069] 0220 ( 00000000, 00000001, 00000066)
[Event #0000006A] 0220 ( 00000000, 00000001, 00000067)
[Event #0000006B] 0220 ( 00000000, 00000001, 00000068)
[Event #0000006C] 0220 ( 00000000, 00000001, 00000069)
[Event #0000006D] 0220 ( 00000000, 00000001, 0000006A)
[Event #0000006E] 0220 ( 00000000, 00000001, 0000006B)
[Event #0000006F] 0220 ( 00000000, 00000001, 0000006C)
[Event #00000070] 0220 ( 00000000, 00000001, 0000006D)
[Event #00000071] 0220 ( 00000000, 00000001, 0000006E)
[Event #00000072] 0220 ( 00000000, 00000001, 0000006F)
[Event #00000073] 0220 ( 00000000, 00000001, 00000070)
[Event #00000074] 0220 ( 00000000, 00000001, 00000071)
[Event #00000075] 0220 ( 00000000, 00000001, 00000072)
[Event #00000076] 0220 ( 00000000, 00000001, 00000073)
[Event #00000077] 0220 ( 00000000, 00000001, 00000074)
[Event #00000078] 0220 ( 00000000, 00000001, 00000075)
[Event #00000079] 0220 ( 00000000, 00000001, 00000076)
[Event #0000007A] 0220 ( 00000000, 00000001, 00000077)
[Event #0000007B] 0220 ( 00000000, 00000001, 00000078)
[Event #0000007C] 0220 ( 00000000, 00000001, 00000079)
[Event #0000007D] 0220 ( 00000000, 00000001, 0000007A)
[Event #0000007E] 0220 ( 00000000, 00000001, 0000007B)
[Event #0000007F] 0220 ( 00000000, 00000001, 0000007C)
[Event #00000080] 0220 ( 00000000, 00000001, 0000007D)
[Event #00000081] 0220 ( 00000000, 00000001, 0000007E)
[Event #00000082] 0220 ( 00000000, 00000001, 0000007F)
[Event #00000083] 0220 ( 00000000, 00000001, 00000080)
[Event #00000084] 0220 ( 00000000, 00000001, 00000081)
[Event #00000085] 0220 ( 00000000, 00000001, 00000082)
[Event #00000086] 0220 ( 00000000, 00000001, 00000083)
[Event #00000087] 0220 ( 00000000, 00000001, 00000084)
[Event #00000088] 0220 ( 00000000, 00000001, 00000085)
[Event #00000089] 0220 ( 00000000, 00000001, 00000086)
[Event #0000008A] 0220 ( 00000000, 00000001, 00000087)
[Event #0000008B] 0220 ( 00000000, 00000001, 00000088)
[Event #0000008C] 0220 ( 00000000, 00000001, 00000089)
[Event #0000008D] 0220 ( 00000000, 00000001, 0000008A)
[Event #0000008E] 0220 ( 00000000, 00000001, 0000008B)
[Event #0000008F] 0220 ( 00000000, 00000001, 0000008C)
[Event #00000090] 0220 ( 00000000, 00000001, 0000008D)
[Event #00000091] 0220 ( 00000000, 00000001, 0000008E)
[Event #00000092] 0220 ( 00000000, 00000001, 0000008F)
[Event #00000093] 0220 ( 00000000, 00000001, 00000090)
[Event #00000094] 0220 ( 00000000, 00000001, 00000091)
[Event #00000095] 0220 ( 00000000, 00000001, 00000092)
[Event #00000096] 0220 ( 00000000, 00000001, 00000093)
[Event #00000097] 0220 ( 00000000, 00000001, 00000094)
[Event #00000098] 0220 ( 00000000, 00000001, 00000095)
[Event #00000099] 0220 ( 00000000, 00000001, 00000096)
[Event #0000009A] 0220 ( 00000000, 00000001, 00000097)
[Event #0000009B] 0220 ( 00000000, 00000001, 00000098)
[Event #0000009C] 0220 ( 00000000, 00000001, 00000099)
[Event #0000009D] 0220 ( 00000000, 00000001, 0000009A)
[Event #0000009E] 0220 ( 00000000, 00000001, 0000009B)
[Event #0000009F] 0220 ( 00000000, 00000001, 0000009C)
[Event #000000A0] 0220 ( 00000000, 00000001, 0000009D)
[Event #000000A1] 0220 ( 00000000, 00000001, 0000009E)
[Event #000000A2] 0220 ( 00000000, 00000001, 0000009F)
[Event #000000A3] 0220 ( 00000000, 00000001, 000000A0)
[Event #000000A4] 0220 ( 00000000, 00000001, 000000A1)
[Event #000000A5] 0220 ( 00000000, 00000001, 000000A2)
[Event #000000A6] 0220 ( 00000000, 00000001, 000000A3)
[Event #000000A7] 0220 ( 00000000, 00000001, 000000A4)
[Event #000000A8] 0220 ( 00000000, 00000001, 000000A5)
[Event #000000A9] 0220 ( 00000000, 00000001, 000000A6)
[Event #000000AA] 0220 ( 00000000, 00000001, 000000A7)
[Event #000000AB] 0220 ( 00000000, 00000001, 000000A8)
[Event #000000AC] 0220 ( 00000000, 00000001, 000000A9)
[Event #000000AD] 0220 ( 00000000, 00000001, 000000AA)
[Event #000000AE] 0220 ( 00000000, 00000001, 000000AB)
[Event #000000AF] 0220 ( 00000000, 00000001, 000000AC)
[Event #000000B0] 0220 ( 00000000, 00000001, 000000AD)
[Event #000000B1] 0220 ( 00000000, 00000001, 000000AE)
[Event #000000B2] 0220 ( 00000000, 00000001, 000000AF)
[Event #000000B3] 0220 ( 00000000, 00000001, 000000B0)
[Event #000000B4] 0220 ( 00000000, 00000001, 000000B1)
[Event #000000B5] 0220 ( 00000000, 00000001, 000000B2)
[Event #000000B6] 0220 ( 00000000, 00000001, 000000B3)
[Event #000000B7] 0220 ( 00000000, 00000001, 000000B4)
[Event #000000B8] 0220 ( 00000000, 00000001, 000000B5)
[Event #000000B9] 0220 ( 00000000, 00000001, 000000B6)
[Event #000000BA] 0220 ( 00000000, 00000001, 000000B7)
[Event #000000BB] 0220 ( 00000000, 00000001, 000000B8)
[Event #000000BC] 0220 ( 00000000, 00000001, 000000B9)
[Event #000000BD] 0220 ( 00000000, 00000001, 000000BA)
[Event #000000BE] 0220 ( 00000000, 00000001, 000000BB)
[Event #000000BF] 0220 ( 00000000, 00000001, 000000BC)
[Event #000000C0] 0220 ( 00000000, 00000001, 000000BD)
[Event #000000C1] 0220 ( 00000000, 00000001, 000000BE)
[Event #000000C2] 0220 ( 00000000, 00000001, 000000BF)
[Event #000000C3] 0220 ( 00000000, 00000001, 000000C0)
[Event #000000C4] 0220 ( 00000000, 00000001, 000000C1)
[Event #000000C5] 0220 ( 00000000, 00000001, 000000C2)
[Event #000000C6] 0220 ( 00000000, 00000001, 000000C3)
[Event #000000C7] 0220 ( 00000000, 00000001, 000000C4)
[Event #000000C8] 0220 ( 00000000, 00000001, 000000C5)
[Event #000000C9] 0220 ( 00000000, 00000001, 000000C6)
[Event #000000CA] 0220 ( 00000000, 00000001, 000000C7)
[Event #000000CB] 0220 ( 00000000, 00000001, 000000C8)
[Event #000000CC] 0220 ( 00000000, 00000001, 000000C9)
[Event #000000CD] 0220 ( 00000000, 00000001, 000000CA)
[Event #000000CE] 0220 ( 00000000, 00000001, 000000CB)
[Event #000000CF] 0220 ( 00000000, 00000001, 000000CC)
[Event #000000D0] 0220 ( 00000000, 00000001, 000000CD)
[Event #000000D1] 0220 ( 00000000, 00000001, 000000CE)
[Event #000000D2] 0220 ( 00000000, 00000001, 000000CF)
[Event #000000D3] 0220 ( 00000000, 00000001, 000000D0)
[Event #000000D4] 0220 ( 00000000, 00000001, 000000D1)
[Event #000000D5] 0220 ( 00000000, 00000001, 000000D2)
[Event #000000D6] 0220 ( 00000000, 00000001, 000000D3)
[Event #000000D7] 0220 ( 00000000, 00000001, 000000D4)
[Event #000000D8] 0220 ( 00000000, 00000001, 000000D5)
[Event #000000D9] 0220 ( 00000000, 00000001, 000000D6)
[Event #000000DA] 0220 ( 00000000, 00000001, 000000D7)
[Event #000000DB] 0220 ( 00000000, 00000001, 000000D8)
[Event #000000DC] 0220 ( 00000000, 00000001, 000000D9)
[Event #000000DD] 0220 ( 00000000, 00000001, 000000DA)
[Event #000000DE] 0220 ( 00000000, 00000001, 000000DB)
[Event #000000DF] 0220 ( 00000000, 00000001, 000000DC)
[Event #000000E0] 0220 ( 00000000, 00000001, 000000DD)
[Event #000000E1] 0220 ( 00000000, 00000001, 000000DE)
[Event #000000E2] 0220 ( 00000000, 00000001, 000000DF)
[Event #000000E3] 0220 ( 00000000, 00000001, 000000E0)
[Event #000000E4] 0220 ( 00000000, 00000001, 000000E1)
[Event #000000E5] 0220 ( 00000000, 00000001, 000000E2)
[Event #000000E6] 0010 ( 00000000, 00000001 )

[loo3aem3ON]

Thanks. The conversion table looks correct but i can't tell for sure. I noticed that you haven't manually set the volume id. Did you modify the volume_id.bin to match your volume id?

My current guess is the conversion table wasn't correctly applied to the movie. Could you please try to run dumpHD like this (thanks to kkloster21):
/dumphd-0.5/dumphd.sh --infile:BDMV/STREAM/00001.m2ts --convtable:conv_tab.bin /media/cdrom/ > /tmp/00001.m2ts
Also keep in mind that once you apply a conversion table to the *.m2ts files they are modified irreversibly. For instance if you made a mistake adapting the content_repair.c to your movie the *.m2ts files are broken and they cannot be repaired even if you subsequently apply the correct conversion table in a correct manner. You have to get a clean copy of the original (AACS decrypted) m2ts files and try again.:rolleyes:

[xkodi]

Thanks. The conversion table looks correct but i can't tell for sure. I noticed that you haven't manually set the volume id. Did you modify the volume_id.bin to match your volume id?

no, matter what i set for volume id the conv_tab.bin is always the same. i tried with Die Hard 4 and even with wrong volume id the produced conv_tab.bin is correct one - the same as the one posted earlier in this thread. so, it seems that volume id is not used at all !?

if you made a mistake adapting the content_repair.c to your movie

i think that changes to content_repair.c are not needed, because Ice Age uses table 1 and 00001.m2ts, which are the same as The Day after Tomorrow. so, i don't expect using dumphd to make any difference.

maybe, i'm doing something wrong and hope that someone else will try with Ice Age and report back too.

[MickJT]

no, matter what i set for volume id the conv_tab.bin is always the same. i tried with Die Hard 4 and even with wrong volume id the produced conv_tab.bin is correct one - the same as the one posted earlier in this thread. so, it seems that volume id is not used at all !?



i think that changes to content_repair.c are not needed, because Ice Age uses table 1 and 00001.m2ts, which are the same as The Day after Tomorrow. so, i don't expect using dumphd to make any difference.

maybe, i'm doing something wrong and hope that someone else will try with Ice Age and report back too.
Which version of Ice Age do you have, and is it Ice Age or Ice Age 2? Which region? Or more specifically what's the Disc ID for it?

Here in Australia:

Unit Key File Hash (Disc ID): 655E67484F36F5734ED4BDDBA3FBC2CAA938ECEB

I used DumpVID to get the VID and then aacskeys to do the rest.

Edit: Furthermore, convtab and convtabv crashes on this disc (at least under Vista) and no .bin file is made. How peculiar. Should I supply a log in verbose mode?
Edit2: bdvm debugger 0.1.1 works fine however, and using the conv_tab.bin in DumpHD works perfectly and produces a m2ts file with BD+ properly removed... Also under Vista. (AnyDVD HD not running obviously).. tested without using conv_tab.bin and BD+ is indeed present and glitchy as always.

[loric]

Looks like there's a new version of BD+ out there, one that Slysoft's AnyDVD-HD can't circumvent as of now:
http://forum.slysoft.com/showthread.php?t=21985

It would be interesting to know how well this open project library can cope with it.

[Doom9]

Speaking of BD+ updates, I compiled a little list on Slysoft's BD+ updates and affected discs by the update - so if you're looking at validating the software against more advanced titles this should provide useful:

October 31st 6.4.7.9 (die another day, the happening, possibly: firefly/bender's game) - Slysoft now says they need 1-2 months to take care of those
August 22, 6.4.6.2 (Prison Break S03 US, Street Kings US)
August 1st, 6.4.5.9 (Jumper DE/UK release)
June 17th, 6.4.5.0 (Jumpger US release)
March 27 6.4.0.4 (Hitman, US release)

[loo3aem3ON]

The debugger can't handle jumper and probably most recently released titles. The implementation of TRAP_DiscoveryRAM has changed. A new second certificate for TRAP_DeviceDiscovery is used (consequently a new public/private ECDSA key) and the version key (aes key number 6) was updated as well. Furthermore there are bugs in TRAP_Sha and TRAP_MediaSHAFileHash which didn't show up before. The libblueray library from Accident might not have these problems because it's a different implementation.
I saw "the happening" in stores lately but the movie is awful so i didn't buy it.

[loric]

The debugger can't handle jumper and probably most recently released titles. The implementation of TRAP_DiscoveryRAM has changed. A new second certificate for TRAP_DeviceDiscovery is used (consequently a new public/private ECDSA key) and the version key (aes key number 6) was updated as well.

What happens with people that bought a stand-alone player? Do they need to update the firmware to play discs protected with the latest BD+ scheme? Or does that work like AASC, i.e. with revocations affecting only software players and, maybe, the PS3?

[loo3aem3ON]

What happens with people that bought a stand-alone player? Do they need to update the firmware to play discs protected with the latest BD+ scheme? Or does that work like AASC, i.e. with revocations affecting only software players and, maybe, the PS3?
They might have to update the player firmware by allowing the player to temporary access the internet or downloading the update manually and burning it to disc. Note that the content code is selecting which program to run based in it's analysis of TRAP_DeviceDiscovery, TRAP_DiscoveryRAM etc ("fingerprint"). It can skip any intensive testing if the player is considered trustworthy (because no hacks known) and therefor it is unlikely that this player would need regular updates if any.
Furthermore don't think of it like the BD+ specification is constantly changing and everyone has to flash it's firmware every month or so. As usual the vendors haven't implemented every detail so their implementations are not fully BD+ conform but these players will probably work fine for a long period of time. This is changing once hacks for a particular player model are known. In this case the content code starts running a lot of checks and might even refuse to generate the conversion table if the certificates and other keys are too old. This is when the vendor is forced to release updates. I believe it is known to the industry which player AnyDVD-HD is emulating but SlySoft doesn't seem to be willing to switch to a different model. :rolleyes:

Slysoft now says they need 1-2 months to take care of those
That would be longer than we needed to reverse engineer the entire thing. strange...

[tteich]

[...]
That would be longer than we needed to reverse engineer the entire thing. strange...
Fox released quite a bit of titles, perhaps with different varieties of BD+ code. Should take a while to analyze and circumvent it. Perhaps we should try to get some of those advanced BD+ "debugged". I think the .zip files which user post on the slysoft forum contain the necessary bdvm files from the related disc.

Edit: just checked and realized that the zip file doesn't contain the /BDSVM contents :-(

[loo3aem3ON]

Edit: just checked and realized that the zip file doesn't contain the /BDSVM contents :-(
I have snapshots for jumper and i am optimistic to get this to work without the help of the snapshots as well. Be patient.

[Accident]

I would be interested in receiving content files for releases that are more advanced, or at least hear how it runs.

[Accident]

I have just checked-in version 0.0.3, which adds a streaming method to using the conv_tab.bin. For those wanted to include it is their own code, this is the pseudo code required.


bluray_init();
vm = dlx_VM_new(DLX_MEMORY_SIZE);
dlx_load_slots(vm, opt_flashfile ? opt_flashfile : "flash.bin");
dlx_setVolumeID(vm, volumeid);
dlx_loadsvm(vm, 0x0, "BDSVM/00000.svm");
dlx_setPC(vm, 0x1000);
dlx_setWD(vm, 0x7fffffff);
dlx_run_convtab(vm);
dlx_patchseek(vm, 1/*title*/, 0x00000000 /*seek*/);
while((rbytes = fread(buffer, 1,
sizeof(buffer),
stdin)) > 0) {
dlx_patch(vm, rbytes, buffer);
fwrite(buffer, rbytes, 1, stdout);
}


I have included Windows binaries again.

Download here:
http://uploaded.to/?id=ge5h4v

Unix style use are:

# ./configure
# make
# mount /dev/cdrom /mnt
# cat /mnt/BDMV/STREAM/00001.m2ts | test/convtab -d /mnt/BDMV -t 1 -U | mplayer
(Use -f and -i or -I to specify flash file, and VolumeID)

[MickJT]

convtab(d).exe still crashes on the Ice Age 1 Blu-Ray (Australian). Haven't checked under Linux.

Should I upload the contents of BDSVM somewhere? (excluding the BACKUP folder).

Edit: Other discs are fine.. It's just this one, and the bdvm debugger .jar works fine with it.
Edit2: I have read this thread thoroughly, but i'm unaware as to what flash.bin is used for, how it is obtained/created and where it's needed, if needed. I haven't needed it yet and BD+ is removed without any problems.

[saint-francis]

October 31st 6.4.7.9 (die another day, the happening, possibly: firefly/bender's game) - Slysoft now says they need 1-2 months to take care of those


I ripped the happening last night with no problem at all using anydvd. And I watched it from my HDD. Am I missing something here?

[dirio49]

I ripped the happening last night with no problem at all using anydvd. And I watched it from my HDD. Am I missing something here?

Please read the thread. It has nothing to do with anydvd. it is about opensource BD+ implementation.
Later

Edit:
James for anydvd says that they need at least one month. This is for Blu-ray not dvds. :)

[saint-francis]

Please read the thread. It has nothing to do with anydvd. it is about opensource BD+ implementation.
Later

Edit:
James for anydvd says that they need at least one month. This is for Blu-ray not dvds. :)

It is the BD that I ripped.

Sorry I thought that doom9 was mentioning Slysoft's inability to break the BD+ on those disks as a method of demonstrating that there is/will be difficulty for the open source project with these lines:
so if you're looking at validating the software against more advanced titles this should provide useful:

October 31st 6.4.7.9 (die another day, the happening, possibly: firefly/bender's game) - Slysoft now says they need 1-2 months to take care of those

[dirio49]

It is the BD that I ripped.

Sorry I thought that doom9 was mentioning Slysoft's inability to break the BD+ on those disks as a method of demonstrating that there is/will be difficulty for the open source project with these lines:

True, i think maybe there was another BD.
well here is the list
http://forum.slysoft.com/showthread.php?t=21985

BTW did you try to rip the BD with the tool found here?

[loo3aem3ON]

A new obfuscated aes implementation is being used which looks a bit more complex than the previous one. But i guess it will be no problem for you to break again :rolleyes:

Should I upload the contents of BDSVM somewhere? (excluding the BACKUP folder).
Yes please. Furthermore i need to you rip the disc with anydvd and dumphd (without the bd+ option) and tell me the first few differences you see. For example the first four 5-byte blocks which are different including their address. This is for me to verify that the repair descriptors of the first nonempty segment are correct. You can use WinHEX or similar to automatically compare the files.

thank you

Edit2: I have read this thread thoroughly, but i'm unaware as to what flash.bin is used for, how it is obtained/created and where it's needed, if needed. I haven't needed it yet and BD+ is removed without any problems.
It's the slot memory. If the content code wants to store data in a nonvolatile memory region of the player it uses the slot memory. This can for example be used to collect data about your viewing habits or to restrict how many times you may watch a particular movie.

[saint-francis]

BTW did you try to rip the BD with the tool found here?

No I didn't. I haven't tried it yet.

BTW the BD I ripped was the happening. It is on doom9's list but not on the one you linked to.

[xkodi]

Ice Age (US version) BDSVM folder (without the BACKUP folder):

http://rapidshare.de/files/40917565/BDSVM_ICE_AGE_US.rar.html

first four different 5-byte blocks between BD+ aware and BD+ unaware rip of 00001.m2ts and their addresses:

1. file offset 0x00045B9D:

DA D6 C6 16 1D (AnyDVD rip, i.e. BD+ removed)

99 50 D6 AD A4

2. file offset 0x00046FE1:

D6 09 61 41 C6 (AnyDVD rip, i.e. BD+ removed)

C3 24 9C B0 05

3. file offset 0x0004B772:

2F A2 81 92 2D (AnyDVD rip, i.e. BD+ removed)

38 07 6C BE 2D

4. file offset 0x0004C858:

FD D5 2D 79 60 (AnyDVD rip, i.e. BD+ removed)

A5 F7 60 9A 9D

[loo3aem3ON]

3. file offset 0x0004B772:

2F A2 81 92 2D (AnyDVD rip, i.e. BD+ removed)

38 07 6C BE 2D
You probably mean 0x0004B771. Apart from that i can't see any problems. Both repair descriptors which contain the four patches you told me are correct. You can verify this by loading the conversion table in ConvTableView 0.2 (http://rapidshare.com/files/161925290/convtableview-0.2.zip):
1. click on "0x00000002: TableID 00001"
2. click on "0x00000394: Segment 0"
3. look at the table at the right hand side. Address0/1 is the address for the patch "patch0" and "patch1". You may ignore all columns but the last four.

I suggest you check a few more differences yourself. Maybe the problems start in one of a later segments. If you can't find any differences between these conversion table entries and your file comparison you should apply the conversion table to the m2ts file created by dumphd and then compare the result with the m2ts file created by anydvd. Please tell me the first few differences you find.

thank you

[xkodi]

You probably mean 0x0004B771.

yes, you're right, it's 0x0004B771, not 0x0004B772.

Apart from that i can't see any problems. Both repair descriptors which contain the four patches you told me are correct. You can verify this by loading the conversion table in ConvTableView 0.2 (http://rapidshare.com/files/161925290/convtableview-0.2.zip):
1. click on "0x00000002: TableID 00001"
2. click on "0x00000394: Segment 0"
3. look at the table at the right hand side. Address0/1 is the address for the patch "patch0" and "patch1". You may ignore all columns but the last four.

now i know how to interpret the conversion table. thank you!

I suggest you check a few more differences yourself. Maybe the problems start in one of a later segments. If you can't find any differences between these conversion table entries and your file comparison you should apply the conversion table to the m2ts file created by dumphd and then compare the result with the m2ts file created by anydvd. Please tell me the first few differences you find.

will do all these things and will report the results.

[xkodi]

will do all these things and will report the results.

finally, full success - no difference with the AnyDVD rip, the two files are byte by byte identical now.

btw, i found out why last time i tried:

http://forum.doom9.org/showthread.php?p=1212526#post1212526

it didn't work - that is because i compiled the content_repair.c with 32 bit fseek function that doesn't support large files. after recompiled content_repair.c with 64 bit fseek it also started to work and produced the same file as dumphd and AnyDVD.

so, BDVM Debugger generates good conv table for Ice Age (US version) and all my troubles were caused by bad compilation of content_repair.c

[Accident]

Thanks for the files, I do not have the correct volume-id so I don't know if it is going to be correct, but the first couple previously mentioned is correct:


# test/convtab -v 65 -d iceage/ -I 1d2fc67462fdf986357a8f808fa1298b -f dat/flash.bin -t 1 -u 00001.m2ts

segment: direct patch title 0 started.
[segment] index 059F
[segment] flags 42
[segment] adjust0 0030
[segment] adjust1 001B
[segment] offset0 5D
[segment] offset1 61
[segment] patch0 DAD6C6161D
[segment] patch1 D6096141C6
[segment] would seek to 0000000000045b9d to write patch0
[segment] would seek to 0000000000046fe1 to write patch1


Run against a 0-byte files, we get these patches:

00045b90 00 00 00 00 00 00 00 00 00 00 00 00 00 da d6 c6
00045ba0 16 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00046fe0 00 d6 09 61 41 c6 00 00 00 00 00 00 00 00 00 00

0004b770 00 8f 2f a2 81 92 00 00 00 00 00 00 00 00 00 00

0004c850 00 00 00 00 00 00 00 00 fd d5 2d 79 60 00 00 00

0006dd50 00 00 00 00 00 00 00 00 00 00 00 00 79 18 45 8a
0006dd60 86 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0006e820 00 00 00 00 00 00 00 00 00 00 00 3e 52 37 04 8e

000fef30 00 00 00 00 00 00 00 00 00 00 c7 38 1a 9e 15 00

00106190 00 00 00 00 00 00 00 00 00 00 00 00 33 a9 6e 2f

001061a0 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00184a30 00 00 00 00 00 35 94 69 89 50 00 00 00 00 00 00



Edit:
I see your edit. excellent.

[xkodi]

I do not have the correct volume-id so I don't know if it is going to be correct,

at least with Ice Age and Die Hard 4 volume-id is not important for BD+, both with libbluray and BDVM Debugger i use wrong values and conv table is always correct, but maybe this isn't true for other BD+ protected titles.

but the first couple previously mentioned is correct

they are correct, here is my log and the values are the same as yours:

0x00045B9D:
DA D6 C6 16 1D

0x00046FE1:
D6 09 61 41 C6

0x0004B771:
8F 2F A2 81 92

0x0004C858:
FD D5 2D 79 60

0x0006DD5C:
79 18 45 8A 86

0x0006E82B:
3E 52 37 04 8E

0x000FEF3A:
C7 38 1A 9E 15

0x0010619C:
33 A9 6E 2F 60

0x00184A35:
35 94 69 89 50


Edit:
I see your edit. excellent.

i uploaded BDSVM folder from the US release of Ice Age and that release works fine with libbluray, but there are problems with the Australian release:

http://forum.doom9.org/showthread.php?p=1213379#post1213379

so, after MickJT upload BDSVM folder from the Australian release, then you will be able to look at the problem with libbluray.

[loo3aem3ON]

so, BDVM Debugger generates good conv table for Ice Age (US version) and all my troubles were caused by bad compilation of content_repair.c
Have you tried repairing the movie with dumphd yet? I believe dumphd v0.5 works fine and you would have saved yourself a lot of work trying it immediately like i suggested in my first reply to your "bug report".
Anyway thank you for finding a bug in this little demonstration repair tool. Could you upload the corrected version please? :)

[Accident]

libbluray uses autoconf and AC_SYS_LARGEFILE, so it should have no such issues.

fopen and big files depend on OS. Some use fseeko, some use fopen(name, "rbF") (or was that the Solaris 256 descriptor problem).. and so on.

[MickJT]

I'm uploading to rapidshare now, slowly. I'll also test it on Ice Age 2 and see if convtab works on that... and i'm assuming you'd like the Volume ID?

I'll also test it under Linux.

I'm assuming you want me to rip with AnyDVD fully enabled (AACS and BD+ removal), and then DumpHD with just AACS removal, and compare the differences in the .m2ts file? What software is best to do this in? Also, can I use AnyDVD without BD+ removal to do the same function as DumpHD (without BD+) removal?

Perhaps WinHEX can do it.

Edit: Seems to be that the -d path option no longer works?

C:\Users\<name>\Desktop\win32>convtab.exe -d e: -s conv_tab.bin -f flash.bin
Failed to load volume_id.bin. This will fail.
Failed to load C:\Users\<name>\Desktop\win32/BDSVM/00000.svm.

Edit2: Believe it or not, Ice Age 2 doesn't have BD+ protection.

Edit3: OK, the path option works, but when you supply a wrong path or it can't find it, it shows the wrong path in the "Failed to load" line.

[Accident]

Yeah, if you use "-d path" it will chdir there. I will fix the error print. So is there still a problem?

[MickJT]

Well, when I stuck in Ice Age 1, which actually has BD+ protection unlike Ice Age 2, the -d path option works fine.. although it crashes of course. I don't know what it does under Linux as i'm still uploading the BSJVM folder which will be done in mere minutes... and i'm ripping Ice Age 1 to the Hard Drive with AnyDVD HD as you requested.

I still have a question about flash.bin. Is it absolutely required to specify it in the command line? convtab also creates one with the -F command, so i'm assuming a blank one is created if you don't specify one, and -F writes it out to a file, which here it's been 128000 bytes exactly. If -f or -F isn't used, a clean one is still used in memory? Is that right? .. and then what use is loading up a previous one? Sorry for the silly questions :)

[Accident]

That is correct, if you don't specify one, it starts from a blank one. Which may be strange since slot0 at least seems to be formatted. You can use dat/flash.bin in the tarball specifying -f. Don't bother with -F, it is more for comparing changes for developers.

[MickJT]

Thanks. I'm still trying to figure out the point of loading up dat/flash.bin if it uses a blank one anyway.

The BDSJVM folder has been uploaded here: http://rapidshare.com/files/164219168/iceage1-aus.rar.html

655E67484F36F5734ED4BDDBA3FBC2CAA938ECEB = Ice Age (AUS) | D | 2008-01-24 | V | ABC2457BA0055C2D3AE9A953FE720E0F

Edit: Segmentation fault under Linux. A lot of warnings when compiling, but they seem normal.

[Accident]

Ah ok, it crashes as I was not checking of ->conv_tab was NULL. Quite easy to fix so it at least runs cleanly, but unfortunately, we do not get a conv_tab.bin at all.

[MickJT]

I'm guessing it won't be too hard for you to fix since it does work under the bdvm debugger. It's not anything new.

[Accident]

It uses trap_MediaSHAFileHash(), in which I had many bugs (testing wrong items before even calling it, and incorrect math (>>10 is not / 0x200) and a few others. Interestingly, it even opens files like: "AACS/MKB_RO.inf".

I have another issue that I am looking at now:

[trap] reading '' at pos 00000000013ffe00

It appears I am given empty names. Or perhaps it is supposed to keep the last file open?


Edit:
Sequence goes:

trap_MediaSHAFileHash(0007E6C8, 15, 512, 0007E6B0, 003DFCC8)
[trap] reading 'BDSVM/00002.svm' at pos 00000000013ffe00
trap: read bytes and SHA_BLOCK
8E 5F D3 81 EF 4E 63 5C 98 63 76 38 5C 2E 83 35 B1 FB E4 42

trap_MediaSHAFileHash(00080E1C, 15, 512, 003DFC10, 003DFC0C)
[trap] reading 'AACS/MKB_RO.inf' at pos 0000000000000000
trap: read bytes and SHA_BLOCK
A1 45 9A 34 84 E7 A4 AB E7 2E 50 1F C6 47 FF 83 1F 9A A7 F9

[trap] trap_Aes(KeyID 00000007)
[dlx] TRAP return: R1 = 80000001

[trap] trap_Aes(KeyID 00000008)
[dlx] TRAP return: R1 = 80000001

[trap] trap_Aes(KeyID 00000005)
[trap] trap_Aes(AES_DECRYPT_PLAYERKEYS): 0x207b20->0x218bd4 (1 key 5)
[dlx] TRAP return: R1 = 00000000

trap_MediaSHAFileHash(0007E6C8, 15, 512, 0007E6B0, 003DF920)
FileName: 00:. 00:. 00:. 00:. 00:. 00:. 00:. 80:. 00:. 00:. 00:. 00:. 00:. 00:. 00:.
[trap] reading '' at pos 00000000013ffe00
[dlx] TRAP return: R1 = 80FFFFFF

[loo3aem3ON]

Interestingly, it even opens files like: "AACS/MKB_RO.inf".
I suggest to record the results of TRAP_MediaSHAFileHash in a file which a user can attach to a bug report. This would eliminate the need to upload files other than those in the BDSVM/ directory.

I don't know which error code should be returned if the file to be hashed can't be found or if the specified section to be hashed lies outside it's borders. Maybe 0x80000001 or 0x80FFFFFF. Let me know if you want me to run a few tests with my player. This should be easy to figure out.

I still have a question about flash.bin. Is it absolutely required to specify it in the command line? convtab also creates one with the -F command, so i'm assuming a blank one is created if you don't specify one, and -F writes it out to a file, which here it's been 128000 bytes exactly. If -f or -F isn't used, a clean one is still used in memory? Is that right? .. and then what use is loading up a previous one? Sorry for the silly questions :)
The flash.bin is primarily for developers. You may use a blank file of the same size which is most likely the case for a new/unused player. The flash contains 500 slots each 256 byte long hence the size of 128000 bytes.

[MickJT]

What i'm trying to ask, is in what scenario would you need a non-blank flash.bin file to do BD+ decryption? As Accident says, if you don't specify one, it uses uses a blank one in memory, and doesn't write it out to a file (without -F).

That's fine, so, why have it at all? Why do I see examples of usage with -f flash.bin there when you don't even need it? Why is a flash.bin provided? Why is the one provided larger than 128000 bytes?

[loo3aem3ON]

That's fine, so, why have it at all? Why do I see examples of usage with -f flash.bin there when you don't even need it? Why is a flash.bin provided? Why is the one provided larger than 128000 bytes?
Like i said it is for developers. We can obtain a series of snapshots from any licensed player and compare them with our emulator. In order to achive accurate results we need to download the slot memory prior recording.

Why is the one provided larger than 128000 bytes?
It was initially believed the slot memory consists of 512 slots but now it seems there are only 500. This is why previous version of this file are a bit bigger. All data above 0x1F3FF is currently ignored but might be used later to store other data like the global write counter.

[Accident]

Actually, I was dd'ing around to make my flash.bin fit that of the snapshots, and I dd'ed one extra at the end. Since slots do not access anything about 500ed, I didn't bother truncating it. It is nothing, please ignore it.

I am not at all sure why it fails still, I have fixed all obvious bugs. Either my ShaMediaFile is still not producing the right contents, or the lazy code in DiscoveryRAM is messing it up.

[loo3aem3ON]

I am not at all sure why it fails still, I have fixed all obvious bugs. Either my ShaMediaFile is still not producing the right contents, or the lazy code in DiscoveryRAM is messing it up.
Don't waste your time with this. Instead add support for the diffarchive snapshots. The user will be able to _create_ diffarchive snapshots and TRAP_MediaSHAFileHash recordings with a new version of the debugger. But first i will give KenD00 some time to commit his improvements until i start working on this.

[Accident]

Comparing our implementations of TRAP_MediaSHAFileHash I found this line to interesting to me:


// get the section length
mem = Debugger.vm.ReadMemory32( pLen, 1 );
length = (int) ( mem[0] >> 2 ); // <====

// allocate a buffer to contain the data from the file
byte[] buffer = new byte[ length ];


There is no description for TRAP_MediaSHAFileHash, but that seems to be that the length is actually in 32bit-sized elements, then converted to size in number of bytes. I did not have this, but adding it makes quite a difference. Now the code path is:


trap_MediaSHAFileHash(0007E6C8, 15, 512, 0007E6B0, 003DFCC8)
[trap] reading 'BDSVM/00002.svm' at pos 00000000013ffe00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

trap_MediaSHAFileHash(00080E1C, 15, 512, 003DFC10, 003DFC0C)
[trap] reading 'AACS/MKB_RO.inf' at pos 0000000000000000
FF FF FF FF 00 3D FF 94 00 07 EB 04 00 3D FF 94 00 01 9E F8
[dlx] TRAP return: R1 = 00000000

trap_MediaSHAFileHash(0003C448, 22, 512, 003DFC04, 003DFC00)
[trap] reading 'BDMV/STREAM/00001.m2ts' at pos 00000000fd2c2800
[dlx] TRAP return: R1 = 80000001


Now I don't have the actual stream, but that is more encouraging than a 0-byte filename. I shall tarball it up so we can try it again. I need to do that for the coredump fixes anyway,

Edit:
libbluray-0.0.4.tar.gz (http://uploaded.to/?id=1uqkux) Updated.

[loo3aem3ON]

Comparing our implementations of TRAP_MediaSHAFileHash I found this line to interesting to me:


// get the section length
mem = Debugger.vm.ReadMemory32( pLen, 1 );
length = (int) ( mem[0] >> 2 ); // <====

// allocate a buffer to contain the data from the file
byte[] buffer = new byte[ length ];


In posting #359 (https://forum.doom9.org/showpost.php?p=1213151&postcount=359) i told you there is a bug in TRAP_MediaSHAFileHash and it looks like you have just found it. The ">> 2" is wrong! Thank you! :)
There also was a problem with sign extension of the offset because both FileOffsetHigh and FileOffsetHigh were accidentally converted to 32-bit integers in the TRAP_handler(). I have compared the results using the jumper snapshots and they seem to be fine now. One thing i noticed though is that the licensed player omitted the hash of the second 0x200 chunk when the whole block was 0x400 bytes long. The hash of the first 0x200 byte chunk was identical only the second hash for the second chunk is not written back to the vm memory. :confused:

Edit: i am holding back my repository updates to make it easier for KenD00 who wanted to commit some patches too.

[Accident]

Ok, I see you removed the "len >> 2" section so I have gone back with mine as well. Luckily I get the same code path now, when I change TRAP_MediaSHAFileHash to use an internal "SHA_CTX" instead of over-loading the "dst" memory area. It seems "dst" only has space to hold 20bytes and no more, so the SHA_CTX was clobbering the trailing bytes.

I also changed the trap_sha(SHA_BLOCK) method to do the same, just in case.

I don't suppose I could get 512 bytes from iceage1-aus/STREAM/00001.m2ts at byte offset 0xfd2c2800, or the SHA digest of that area.

dd if=STREAM/00001.m2ts of=shablock.bin bs=512 skip=8295956 count=1

Edit:

Thanks to MickJT for sending me sha_block2.bin (completely untouched block) I now have the following results:


# time test/convtab -d iceage1-aus/ -s saved_conv_tab.bin
real 0m1.194s

[segment] Starting decode of conv_tab.bin: 0x4dfafc (1014544)
[segment] num tables 29
[segment] Table 0 ID 00000001, 227 segments.
Segment 1 offset 00000398 -> 184 entries
Segment 2 offset 000011FC -> 148 entries
Segment 3 offset 00001D90 -> 184 entries

-rw-r--r-- 1 owner group 1014544 Nov 17 16:17 saved_conv_tab.bin

[MickJT]

I've sent you the files you require, but i'm not sure skipping 8 megabytes is enough. BD+ only seems to start happening after the 20th Century Fox logo.

[Rupan]

It seems to me that having the volume ID stored in a binary file is not too usable for a large audience. Asking someone to open a hex editor, when the tools that are readily available to recover these values output hex strings, is a major roadblock for the normal user.

I realize that there is a menu option to input the key in the GUI. But I think a better option would be to store the VUK and other encryption parameters in a separate file that is human-editable. This will allow easy updates in case e.g. keys are revoked, so that people do not have to rebuild the software in order to change them.

To these ends I have written a simple FileIO class to add accessibility to the bdvm. I think it would be a good idea to write out a basic configuration file, possibly with headers like

[Known VUKs]
$DiscID $VUK

I'll leave it to you to take or leave this as you see fit.

[oibaf]

libbluray-0.0.4.tar.gz (http://uploaded.to/?id=1uqkux)

I noticed that the readme.txt file says:
It is released anonymously to protect the author and
without any license.

OK for the anonymity, but releasing it without a license make the library not usable by anyone. It should be released at least under public domain, while with a GPLv3 or later, free projects could use it while avoiding that improvements will be kept secret under a closed source license.

[Accident]

Pick a license that you think would be best, and I'll put it on the files I made. I've used New-BSD in the past, but I care not about these things.

Heh evvktvh (http://www.evvk.com/evvktvh.html#english)