Finally handling BD+ (?)

[KenD00]

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

[Accident]

ID4:

[segment] Saving table 0 tableID 00000001, numSegments 408
[segment] Saving table 1 tableID 00000001, numSegments 408

Seems to be a bug in my conv_tab merger. They have the same IDs and should either be ignored, or, properly merged. But having the same number of Segments makes me think it is an identical table.

Edit:

             if (set2->Tables[ ctable ].tableID ==
-                set1->Tables[ i ].tableID) continue;
+                set1->Tables[ i ].tableID) break;

Edit 2:

Looking at Benders Game, it seems to generate a good looking conv_tab, but it uses a lot of type 0, and type 3, repair descriptors. Used in such a way which makes me think we are not doing the correct logic, for example an entire Segment are all removed and left empty as all repair descriptors are either type 0 or type 3, and we assume both are identical to type 2.

[Emp3r0r]

Originally Posted by yippiekayee

And as far as holding back and letting Slysoft take the lead - that just backfired. This will make handling of the latest batch of BD+ titles a much bigger story than it ever could've been if they'd be handled by now. It is generally acknowledged that it might take some time to catch up with copy protection..

One potential flaw I just noticed in the way BD+ uses RSA is that they use the public exponent e = 3. This low value is known to open up multiple theoretical attacks as described in section 4 of this paper [stanford.edu]. Too lazy to register a Doom9 account to post that info on their forums...

http://it.slashdot.org/comments.pl?s...1&cid=26105869

[loo3aem3ON]

Originally Posted by Accident

Looking at Benders Game, it seems to generate a good looking conv_tab, but it uses a lot of type 0, and type 3, repair descriptors. Used in such a way which makes me think we are not doing the correct logic, for example an entire Segment are all removed and left empty as all repair descriptors are either type 0 or type 3, and we assume both are identical to type 2.

Send me the content code please. Furthermore output the first 64 bytes on each call of TRAP_Finished and study the output for several movies. You should see some constant values (similar to C0200002 6420ED34 58010000 B801FFFC). There is also a table at 58h(?) which should look like this:

00 00 00 00 00 00 00 00 07 D6 06 0D 57 30 5D 64
D1 01 3F FF A4 D7 23 55 B4 C7 0B 27 A8 15 A3 43
05 E2 2B 42 F8 8A 5C 1A C5 E7 0D F4 66 35 3B DB
0A 83 22 8A 35 D2 90 CF 7E 2F 60 C1 AC 39 CE 1A
6D 31 08 CE F5 2F 91 C1 8E 39 1F 55 39 10 25 EA
DE 5A AE 40 92 D2 C0 6B 7E C2 2B DA 01 E7 B6 3E
83 95 E4 7B 1E F0 8A 2B AB F4 CB 6F D3 9D CC 71
F3 7A CF F7 23 07 32 69 9C D4 D5 07 E2 FC 4D 2B
59 21 A9 9D A4 7E EC DA E4 FF 76 7B 21 77 EF 20
2B 9A 2A BA FC CE 9D 1D 34 03 6D 36 BA 20 FB EE
21 93 A0 49 48 BC 13 82 14 04 B2 16 24 5B CD A4
FF DF 7D 2E EE FB A4 5D 43 67 55 80 E0 0D 57 BA
99 55 57 74 57 3C 00 AE 75 F2 13 8A 0B 38 5F D7
E4 C2 17 94 00 00 00 00 00 00 00 00 00 00 00 00

I don't know the meaning of these values but they might be useful to check if the segment keys/masks are correct. Keep in mind that the content code overwrites this area after TRAP_Finished with random data and it doesn't clear up the mess when writing new valid data and calling TRAP_Finished again.

Edit: Never mind. I found the content code for Benders Games.

[Accident]

Do you think it is more likely our key/mask is wrong, generating type 0, and 3. Or is it possible that it does in fact have a type 0/3 ?

With Benders Game, the masks we receive "seem" typical (most bits are set to 1), but the 5th mask "6E3158107F072F17", looks out of place and this is where type 0/3 starts. But that is hardly science.


Looking at the bytes after trap_Finish as you suggested, there is definitely a pattern (ID4):

Q:FAFEFBDF9AFF6EFFC02000026420272458010000B801FFFC40180CD2780D883F00000000000000
Q:FF3FDFFFF7DFFFDBC02000026420272458010000B801FFFC5B626DF440180CD200000000000000
Q:6BEDDDFF6767FE7BC02000026420272458010000B801FFFCFFFFFFFFFFFFFFFD00000005FFFFFF
Q:FF5C7F76FF6CDDEFC02000026420272458010000B801FFFCAE49044D7FFC262D00000005FFFFFF
Q:FEFFFFBFFF7DF77FC02000026420272458010000B801FFFC96D3A639B57F047B00000005FFFFFF
Q:FFFFF923FFFDDFEFC02000026420272458010000B801FFFC000000000000000000000000000000
Q:99FF4FDFDFFFCFFFC02000026420272458010000B801FFFCE67B5C9CF90AE60C00000000000000

The first 8 bytes is the mask for type 2. Then I always get a static string of "C02000026420272458010000B801FFFC" for ID4, then there is a 2nd lot of 8 bytes, similar to the mask. Different releases seems to have a different static string, but it remains constant within the release.

[loo3aem3ON]

I must say i am surprised none of the keys we use have been revoked (otherwise we wouldn't get a conversion table at all).

Originally Posted by Accident

Do you think it is more likely our key/mask is wrong, generating type 0, and 3. Or is it possible that it does in fact have a type 0/3 ?

There is no type 0 or 3. If you open the conversion table in ConvTableView you will see many errors so clearly the segment keys are wrong. This should be easy to fix once i provide a new snapshot package. Maybe TRAP_DiscoveryRAM is the troublemaker

Originally Posted by Accident

Looking at the bytes after trap_Finish as you suggested, there is definitely a pattern (ID4):

The pattern appears after all events on different addresses depending on the event id. Have you seen the table at 58h ?

Originally Posted by Accident

Different releases seems to have a different static string, but it remains constant within the release.

Yes it seems it's neither status code nor checksum.

Could you and Rupan start implementing AACS in libblueray?

[Accident]

Originally Posted by loo3aem3ON

There is no type 0 or 3. If you open the conversion table in ConvTableView you will see many errors so clearly the segment keys are wrong. This should be easy to fix once i provide a new snapshot package. Maybe TRAP_DiscoveryRAM is the troublemaker

There is no type 0/3 YET

Yes, DiscoveryRAM is indeed just about the only trap before it goes haywire.

The pattern appears after all events on different addresses depending on the event id. Have you seen the table at 58h ?

No did not look that far, I will do.

Could you and Rupan start implementing AACS in libblueray?

I would love to. But I would need a lot of information to know what to do. I can only hope they are as good as your documentation, which has been perfect.

[loo3aem3ON]

Originally Posted by Accident

There is no type 0/3 YET

I strongly believe that the BD+ specification doesn't introduce new features over time. My player ignores descriptors of type other than 1 or 2 and i see no reason to believe the implementation is incomplete. Isn't it more likely that you just have to flip one of the two most significant bits of the segment key to transform your type 0/3 descriptors to valid type 1/2 descriptors?

Originally Posted by Accident

I would love to. But I would need a lot of information to know what to do.

The AACS specification is available here. If you have any questions KenD00 will probably be able to help you. For new keys i could ask the almighty Oopho2ei.

[Accident]

Originally Posted by loo3aem3ON

I strongly believe that the BD+ specification doesn't introduce new features over time. My player ignores descriptors of type other than 1 or 2

Ah, I wasn't sure if you had checked the refence player already or not, but with that knowledge we know that something is wrong if we see type 0/3.

The AACS specification is available here. If you have any questions KenD00 will probably be able to help you. For new keys i could ask the almighty Oopho2ei.

Some general info would also be nice. Is it at all like CSS? I query the device for a challenge, do some work to eventually be authenticated. After that, I do similar work to gain title keys, after that it is plain decrypting.

What is the deal with player firmware? We can only work with certain drives? Ie, is it not going to feasible to be a full BD player that needs no modification (beyond perhaps player keys). Should this be in a new thread?

[loric]

Originally Posted by Accident

Some general info would also be nice. Is it at all like CSS? I query the device for a challenge, do some work to eventually be authenticated. After that, I do similar work to gain title keys, after that it is plain decrypting.

http://freedom-to-tinker.com/blog/fe...-code-released

http://forum.doom9.org/showthread.php?t=122363

[loo3aem3ON]

I've started a new thread here. Please stop making AACS related postings in this thread.

Thank you.

[Turtleggjp]

Looks like Slysoft has finished cracking the latest BD+.

http://forum.slysoft.com/showthread.php?t=24603

I'm curious to see what you guys find out about this new protection and why it took so much longer for them to fix.

[setarip_old]

@Turtleggjp

Hi!

Looks like Slysoft has finished cracking the latest BD+.

That doesn't seem to be the case, if you read that entire thread...

[pihug12]

Press release : http://forum.slysoft.com/showthread.php?t=24602
BD+ Titles AnyDVD 6.5.0.2 may not handle correctly : http://forum.slysoft.com/showthread.php?t=24613

[ron spencer]

they are adding titles manually...see their forum

6.5.0.3 is now out

[loric]

Originally Posted by ron spencer

they are adding titles manually...see their forum

6.5.0.3 is now out

But they're on the right track though. I am a Linux user but I might purchase their program. I think they deserve it.

[loo3aem3ON]

Originally Posted by Turtleggjp

Looks like Slysoft has finished cracking the latest BD+.

Thank you. I'll get one of the new releases and record snapshots.

[Accident]

Woohoo, finally we can move on! It was good to have a break though

[loo3aem3ON]

A new snapshots package is available to developers now (write me a private message if you need it). It has been taken from a player with a more recent firmware which sadly also leaks more environment information through an extended TRAP_DiscoveryRAM (this is why the snapshot package is currently not public). The old firmware seems no longer be compatible and a picture with update instructions is displayed on the screen. The picture probably originates from the content code because it's different compared with earlier discs. It usually shows up when i mess up the input or return of TRAP_Aes/ TRAP_Privatekey.
Anyway the new version key (aes key 6) is not known yet and the new obfuscation scheme is more sophisticated so be patient.

[loric]

Originally Posted by loo3aem3ON

A new snapshots package is available to developers now (write me a private message if you need it). It has been taken from a player with a more recent firmware which sadly also leaks more environment information through an extended TRAP_DiscoveryRAM (this is why the snapshot package is currently not public). The old firmware seems no longer be compatible and a picture with update instructions is displayed on the screen. The picture probably originates from the content code because it's different compared with earlier discs. It usually shows up when i mess up the input or return of TRAP_Aes/ TRAP_Privatekey.
Anyway the new version key (aes key 6) is not known yet and the new obfuscation scheme is more sophisticated so be patient.

Judging from what you can see, what are the differences between the previous and the latest BD+ implementation (except for the different keys and the new obfuscation, which you have already told us about)?