Finally handling BD+ (?)

[yippiekayee]

Here's an idea to make it easier for people to help: The debugger should have a function to zip up everything needed for you guys to reproduce... volume id, hashes database, bdsvm folder and snapshots - or at the very least copy all this to one folder which can be zipped up and uploaded somewhere. And if there's every any other files needed, those could be added as well so that whomever posts a problem could immediately post all the files you guys need to reproduce as well thus making the process of error reporting a lot more efficient.

@loo3aem3ON: is there any point to me creating snapshots for the latest BD+ titles that the debugger can currently not handle properly?

Also, check your PMs..

[loo3aem3ON]

I discovered that event#0000 starts the virtual machine. So when we clear the first 1000h bytes and then start execution at 1000h we actually call the handler for event#0000 :D
We already knew that event#0010 shuts the vm down so the event/callback ids seem to be grouped too. Those two belong to group 0 obviously. I am still tracing the second parameter of event#0110 backwards to it's source. So far i've figured out that it's a 16-bit value. I actually wanted to take a small break now but i got so many new messages...

The debugger also has a non fatal bug: if there's no hash_db.bin there's an uncaught FileNotFoundException... just wrap the file loading attempt into a try/catch and that won't happen again.
Yes, you should not delete this file. I will create a new (empty) file in case it is missing.

Here's an idea to make it easier for people to help: The debugger should have a function to zip up everything needed for you guys to reproduce... volume id, hashes database, bdsvm folder and snapshots - or at the very least copy all this to one folder which can be zipped up and uploaded somewhere. [...]
I will think about that.

@loo3aem3ON: is there any point to me creating snapshots for the latest BD+ titles that the debugger can currently not handle properly?
No there is no point doing that. Only create snapshots for those who work correctly.

Also, check your PMs..
Please don't send me the snapshots. Accident is the one who needs them. ;)

Also please don't spam the thread with unnecessary postings. If you made the last posting in the thread you should edit it to add more comments.

[Accident]

Slight bug left from trying to merge convtabs meant 0.0.7 was very broken.

libbluray-0.0.8.tar.gz (http://uploaded.to/?id=k8gjl8)

[Rupan]

I purchased The Simpsons Movie to help debug the VM. It produces a conversion table which, when used with DumpHD, produces identical output to AnyDVD. The VM had some interesting output this time:

[Event #00000001] EVENT_0210( 00000000, 00000001 )
[W] TRAP_DeviceAccess not implemented!

Is there any documentation available for event 210 and/or DeviceAccess? Depending on what they do I may be able to help. Just a pointer to the document that I should read would suffice.

@Accident: I've produced a diffarchive snapshot for The Simpsons Movie and will upload it later tonight. Look in your PMs for the link.

[yippiekayee]

Slight bug left from trying to merge convtabs meant 0.0.7 was very broken.Does that mean that convtable merging should now be working (and thus this version would be ready for Prison Break)?

And as far as holding back and letting Slysoft take the lead - that just backfired (http://it.slashdot.org/article.pl?sid=08/12/13/137257). 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.. but take too long and it will be chalked up as a (temporary) win for the studios and that makes it a newsworthy story. It also made it up to engadget so I figure it's just a matter of time until it's up on ars and other more mainstream tech news outlets.

[Accident]

I don't know. The version of Jumper that was supposed to produce multiple conv_tabs, just produced two (almost) identical files, so there was nothing to be gained there. If the Prison Break you mentioned is PBS3D4 files, then it already produces a conv_tab (libbluray-0.0.8 version). I also grabbed the first 5 files releases sent in PM, and they all produce conv_tabs. Do we know of any releases that are still broken with libbluray-0.0.8 ?


-rw-r--r-- 1 owner group 1044836 Dec 10 14:23 PBS3D4-conv_tab.bin

[yippiekayee]

Do we know of any releases that are still broken with libbluray-0.0.8 ?I'll have to check. I hope it is okay if I get you the debugger and the libbluray convtables as I didn't keep md5sums (plus even though DumpHD is considerably faster than AnyDVD HD it takes a long time to rip a title) - and so far the output of the two applications has always differed.
And I mostly meant the first three discs of Prison break - they produce significantly larger convtables (4 MB) so I figure that would be the real test.
Did you compare the convtables I already sent you (you should have the Prison Break Disc4 from the debugger if I'm not mistaken) with the one you created on your own? Do you know if they produce the same outcome?

[Accident]

I merely confirmed they produced tables that "look good". I will compare against the actual files. I would love the svm files for a release that produces the 4mb tables, since that would have to use multiples.

[loo3aem3ON]

It is generally acknowledged that it might take some time to catch up with copy protection.. but take too long and it will be chalked up as a (temporary) win for the studios and that makes it a newsworthy story. It also made it up to engadget so I figure it's just a matter of time until it's up on ars and other more mainstream tech news outlets.
If have no doubt that SlySoft could support the latest batch of BD+ damaged disc (and so do we). If we go forward and correct the bugs which prevents the new content code generation to execute properly the DRM industry will go after us. And this is something SlySoft probably wants to see. So we are holding back bugfixes like SlySoft does. Final decision.

[yippiekayee]

That's your prerogative, however I feel compelled to point out some obvious flaws in your argument:
The number of titles that can be handled versus those that cannot is much larger.. so why did Macrovision sit on their collective asses and let Slysoft handle BD+ titles since November 20th 2007 and strip BD+ since March 19th 2008? Why would they suddenly change their minds and get the lawyers involved just now and wouldn't they face the same situation when they finally update their BD+ handling code regardless of when they do that? And on the other hand they have a number of paying customers obviously waiting for the release which handles all the latest titles - so delaying something to let somebody else have first crack doesn't make a lot of sense to me. January 1st I'd understand because of the subscription model (and who knows, maybe it'll happen then), but why February?

And the other part of it is that since I've been the one person (now joined by Rupan) who listened to your call for support and invested quite a bit of time (I have no illusions that it's nowhere near what you guys invested) and money (you have a list of my titles.. about half of it I got specifically to help out here and not because I wanted to get them) I cannot help but feel a bit betrayed and ask why I should bother going on if you're not willing to. If the titles that can be handled right now are all that are ever going to be handled then I guess I could just as well sit back and wait for Slysoft since I do have a license and who cares about those who cannot or don't want to use AnyDVD HD.

I realize you don't owe anybody anything, but that cuts both ways and at that point I feel a bit disillusioned about what I've been doing since I've started posting here.

[loo3aem3ON]

That's your prerogative, however I feel compelled to point out some obvious flaws in your argument:
The number of titles that can be handled versus those that cannot is much larger.. so why did Macrovision sit on their collective asses and let Slysoft handle BD+ titles since November 20th 2007 and strip BD+ since March 19th 2008?
The industry is probably unable to sue SlySoft because it is legal on the small island they are on.

Why would they suddenly change their minds and get the lawyers involved just now and wouldn't they face the same situation when they finally update their BD+ handling code regardless of when they do that?
You yourself sent the links to the recorded snapshots as private messages in fear of prosecution. Avoiding prosecution is everyones top priority.
I must admit i don't quite understand your question. The execution environment is not changed (there is only one version of BD+) but the content code running in this virtual machine can be unique for each disc. Bugs in our implementations are exploited to distinguish between a licensed player and an unlicensed emulator.

And on the other hand they have a number of paying customers obviously waiting for the release which handles all the latest titles - so delaying something to let somebody else have first crack doesn't make a lot of sense to me.
The open source tools can become a threat to the business model of SlySoft. The open source tools aim for blue ray playback in linux without proprietary software so the users will probably accept if the latest movies are not supported.

I realize you don't owe anybody anything, but that cuts both ways and at that point I feel a bit disillusioned about what I've been doing since I've started posting here.
Without any doubt you have helped the project. One of the major problems you've helped correcting was the handling of multiple calls of TRAP_GetConversionTable which each time gives another part of a larger conversion table (fix-up table). Libblueray seems to have some other problems too but your snapshots will probably help fixing those issues.

SlySoft won't delay the bugfixes forever or otherwise their customers will lose faith in this company. Therefor there is no reason to believe that those movies you have had problems with will never be supported. Finally I told you very early that i don't want our implementations to compete with SlySoft's AnyDVD-HD (see posting #490 (https://forum.doom9.org/showpost.php?p=1219291&postcount=490)) but you kept on going.

[zeroprobe]

Is it possible to have some sort of brief layman term update of what the status is with the bd+ decryption here?

And what happened to Oopho2ei if you don't mind me asking?

[LoRd_MuldeR]

And what happened to Oopho2ei if you don't mind me asking?

He stopped his work on breaking BD+ (in the public) because he fears the consequences, now that his work became famous on the net. The AACS LA will certainly try to find out his identity to put a lawsuit on him (if not worse). So consequently he tries to protect his identity and his life now. Seems his Doom9 account has been deleted too.

[yippiekayee]

You yourself sent the links to the recorded snapshots as private messages in fear of prosecution.Prosecution isn't the right term.. as you know neuron2 objected to an attachmend I made and when I inquired on what is okay and what isn't (this board has strict policies and I don't want to get myself or the board operators into trouble) and so unless the admin gives different directions on that issue, I figured it would be prudent to refrain from posting any content files.
The open source tools can become a threat to the business model of SlySoft.Umm.. hasn't backuphddvd, backupbluray, dumphd, etc. always been the competition and aren't all of those tools running on Windows? In fact, it was the community here that came up with the first tools to circumvent AACS when Slysoft had nothing in their hand.
And, Slysoft's ripper was an afterthought.. it all started out with on-the-fly decryption so I figure on-the-fly-decryption is the main market for Slysoft. Just look at how complex the whole process of backup up a Blu-ray disc still is.. it is way beyond the capabilities of most (not on this board but most people aren't as knowledgeable). And even prior to HD there were plenty of tools who at least on a ripper level (there hardly is any on-the-fly decryption tool for DVDs) competed (and those that are still updated still do compete) with Slysoft's offering. Take DVD Fab HD Decrypter for instance.. it is probably AnyDVD ripper's number one contestant and it is free. And the demise of DVD Decrypter and RI4M had nothing to do with Slysoft either (check the Doom9 news for details).

Anyway.. I guess we can argue this all day long and neither one of us is going to change their mind.. so I'll just finish the things I'm working on for Accident and then retire.

@zeroprobe: It seems the debugger can handle any titles except those that are on Slysoft's list of currently unsupported BD+ titles (http://forum.slysoft.com/showthread.php?t=21985) - and that includes any future titles that might be added to that list. If you read through this thread (the last few pages) you'll notice a number of titles that are confirmed to be handled correctly.

[loo3aem3ON]

Is it possible to have some sort of brief layman term update of what the status is with the bd+ decryption here?
First of all BD+ doesn't do any decryption of the movie content. Instead BD+ protection means that your *.m2ts files are damaged after AACS decryption. To get the repair instructions you have to execute the program on the disc called "content code". The execution takes place inside a virtual machine which basically is a DLX like processor with a more complex player interface. The content code runs a series of tests to distinguish a licensed player from an unlicensed emulator. If one of these tests fails this content code won't give you the repair instruction (at least not without manual intervention).
Now to your question: the content code shipped with the newer discs usually runs more tests and evaluates the results more strictly. This way new bugs in our emulators show up which have to be fixed.

And what happened to Oopho2ei if you don't mind me asking?
Nothing has happened to him. Actually neither AACS nor BD+ has been broken and if these tools are only used to playback the contents and not to make the copy how can this be called a break of copy protection?

[zeroprobe]

Nothing has happened to him. Actually neither AACS nor BD+ has been broken and if these tools are only used to playback the contents and not to make the copy how can this be called a break of copy protection?

I just remember he was a big part of getting this going. So as I understand progress is on pause for now?

Could you guys if you wanted, overcome the BD+ on the newest of discs? I'm just curious how far you guys could go, or are these new revisions alot more complicated like what Slysoft have said?

[Wilbert]

Your questions have been answered a dozen times (implicitly) in this thread, so i don't understand why you ask them again.

[loo3aem3ON]

yippiekayee reported a bug which occurs when the debugger is started without the hash_db.bin present. Are there any more problems? Are the snapshots created properly? Accident, have you had any problems with the new snapshots created by the debugger?

I would like to release version 0.1.5 soon because KenD00 has been working on dumpHD to load the debugger as a library and this needs some testing. On the other hand i would rather not release 0.1.5 if there are major problems with the recent development snapshots (0.1.5 dev).

Btw. Rupan has joined our development team. I hope he can help us improving the debugger. :)

[KenD00]

What yippiekayee reported is not a bug but more a cosmetical problem. Before an entry gets written it is tried to load the same one too see if its already present, this causes the exception when the file is missing, but it is caught and the code behaves properly, its just the stack trace that gets printed out.

:rolleyes:

[Accident]

Accident, have you had any problems with the new snapshots created by the debugger?


Sorry, I'm still catching up on the 15 titles or so I received, so I've not actually got to the stage of trying the new diffarchives.

Do not hold back on account of me though.

I have received an example of multiple conv_tabs (PB3S1) so I will work on merging conv_tabs, then push out 0.0.9.

Edit:

Oh I see, I cheated and just kept the "offsets" to write out, but when merging conv_tab, that clearly will not work. So it was writing 1MB data in place multiple times. I need just to re-compute the correct offset and we should be set.


-rw-rw-rw- 1 4136246 Dec 3 03:30 conv_tab-prisonbreak_s3d1.bin
-rw-r--r-- 1 4136246 Dec 15 11:11 new_conv_tab.bin


Edit 2:

I compute the new offset values, and I think the new conv_tab.bin are correct. They differ with the Debugger, but it appears to be merely an ordering. At offset 001f51c0 the Debugger writes tableID 00000002, whereas libbluray writes tableID 00000005. libbluray writes tableID in order it receives it, whereas Debugger appears to sort per tableID. Apart from that, I would like to think it handles multiple conv_tabs.

Edit 3:

Quick call to qsort() and diff(1) confirms both conv_tabs are identical.

Edit 4:

libbluray-0.0.9.tar.gz (http://uploaded.to/?id=a2tcyn)

[Peer van Heuen]

If have no doubt that SlySoft could support the latest batch of BD+ damaged disc (and so do we). If we go forward and correct the bugs which prevents the new content code generation to execute properly the DRM industry will go after us. And this is something SlySoft probably wants to see. So we are holding back bugfixes like SlySoft does. Final decision.

Now let me please put a stopper on this, before it gets out of control.

We are not the mafia.

By no means would we ever use tactical measures to watch any of you get into trouble. That would be the most shabby thing to do and silly and ineffective just as much.
We don't even wish that anything of this sort happens to our commercial competitors.

Also: we are not holding anything back.
Neither are you.

I know this whole DRM-related business is a hotbed for conspiracy theories - and up to a certain point I enjoy reading them...

[yippiekayee]

Good news.. I just ran the new libbluray on the entire Prison Break series and it produced byte identical output do the debugger.
I also ran it again on Independency Day in the hopes that now all tables created would be the same.. but that's not the case. I'm hoping that with the convtables I've sent you from both the debugger and libbluray you can determine if they'd produce the same output - perhaps some convtable analyzation tool would be in order so that anybody could test their convtables on their own and just report back any problems and which titles work okay without having to rip and compare against AnyDVD HD.

[loo3aem3ON]

[Event #00000001] EVENT_0210( 00000000, 00000001 )
[W] TRAP_DeviceAccess not implemented!

Is there any documentation available for event 210 and/or DeviceAccess? Depending on what they do I may be able to help. Just a pointer to the document that I should read would suffice.
Have a look here (http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220070033419%22.PGNR.&OS=DN/20070033419&RS=DN/20070033419).
TRAP_DeviceAccess sends commands to a device within the player and TRAP_DeviceDiscovery receives data from a device.

[Accident]

Ah, I don't seem to have ID4 BDSVM files anywhere. Is there a link somewhere? I have got everything sent to me in PM btw.

[loo3aem3ON]

I think (hope) i am getting close to the source of the second parameter of event#0110.

Anyway during a short break i found a comment of "Nate Lawson" who co-designed BD+ here (http://rdist.root.org/2008/04/11/designing-and-attacking-drm-talk-slides/):
Modern DVD and BD replication equipment can write a unique number on each disc (called burst cutting area on DVD, PMSN on Blu-ray). The entire disc is still the same but each one is slightly personalized.

When you write the BD+ code, you can put some “poison pill” logic in as well. For example, it might be “run SHA1(readPMSN(), secretValue) and if it equals magic value 87B2A058…, stop playback
Anyone knows about this PMSN? How can i read this number?
This "readPMSN()" call is probably TRAP_DeviceDiscovery with some special parameters. Maybe it also requires TRAP_DeviceAccess to send some low level atapi/scsi commands.

Edit:
The Pre-Recorded Media Serial Number is optional for BD-ROM disc. For BD-ROM, the Pre-Recorded Media Serial Number shall be stored in the BCA record of the BD-ROM disc.

[xkodi]

Anyone knows about this PMSN? How can i read this number?

Burst Cutting Area is used to store Media ID for CPPM/CPRM protected media like DVD-Audio discs:

http://www.geocities.com/columbiaisa/dvd_copy_protect.htm :

CPRM is similar to CPPM in using a MKB. All media used with CPRM must include a BCA (Burst Cutting Area) which can be used to record a unique media ID as part of the manufacturing process. This will then prevent the data from being copied to another disc because it will not have the same unique media ID and therefore the data cannot be decrypted.

Burst Cutting Area can be read under Windows with the functions defined in ntddscsi.h header file, which allow you to access SCSI port adapters. you should be able to use ntddscsi.h functions with every drive (IDE, SATA) under Windows, because they are emulated as SCSI.

i'm sending you a PM with example how to use ntddscsi.h header file to read BCA on DVD. i hope it will help you to do the same thing with PMSN.

[derbeDeus]

Anyone knows about this PMSN? How can i read this number?

PMSN is for online stuff to provide additional services. As the docs say, it's unique per disc copy. So the only use in BD+ would be to ban a certain disc from a naughty user :sly:

btw: it was not available on the disc i tried (i got a scsi err)

[KenD00]

PMSN sounds like Pre-recorded Media Serial Number defined in the AACS specs. It is read with the same command as the Volume ID, just the Format Code is different (0x81 instead of 0x80). And it has the same restrictions, you need to be AACS authenticated to get it. So without a new firmware patch we won't be able to get it currently :(.

:rolleyes:

[loo3aem3ON]

BDVM Debugger v0.1.5: download (http://uploaded.to/?id=xcco6l)

The new version of the debugger can now interact with DumpHD. So if everything works as expected all the BD+ damages are repaired in the background. :)

What yippiekayee reported is not a bug but more a cosmetical problem.
I create the file in case it is missing. Every stack dump indicates a bug ;)

[loo3aem3ON]

Thanks for your replies. I've tried to read the number with a patched drive (cmd AD handler is modified) and for format code 81h i get:
Fixed format, current; Sense key: Illegal Request
Additional sense: Cannot read medium - incompatible format

format code 82h:
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
Sense Key Specific: Error in Command byte 7

I can't tell if the results would be any different after successful authentication.

[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 :confused:. Now i always get sense code 5/6F/00 - Authentication Failure.

I have also tested it now using my good old MKBv1 HD-DVD drive with aacs authentication and in that case (and using the XBox hack) i got in both cases 5/6F/01 - Key not present.

:rolleyes:

[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]

And as far as holding back and letting Slysoft take the lead - that just backfired (http://it.slashdot.org/article.pl?sid=08/12/13/137257). 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 (http://crypto.stanford.edu/~dabo/abstracts/RSAattack-survey.html) [stanford.edu]. Too lazy to register a Doom9 account to post that info on their forums...
http://it.slashdot.org/comments.pl?sid=1061451&cid=26105869

[loo3aem3ON]

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

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 :devil:

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 ?

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]

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 :devil:


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]

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?

I would love to. But I would need a lot of information to know what to do.
The AACS specification is available here (http://www.aacsla.com/specifications/). If you have any questions KenD00 will probably be able to help you. For new keys i could ask the almighty Oopho2ei.

[Accident]

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 (http://www.aacsla.com/specifications/). 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]

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/felten/aacs-decryption-code-released

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

[loo3aem3ON]

I've started a new thread here (https://forum.doom9.org/showthread.php?t=143547). 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]

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]

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]

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)?