Finally handling BD+ (?) - Page 16

zeroprobe · 29th October 2008, 11:23

There are lots of talented people in here. Kudos to everyone involved. I feel stupid reading some of your posts lol.

29th October 2008, 17:43

Like Schluppo pointed out the event replay we currently use to get the decrypted conversion table won't work if the main movie is distributed over multiple m2ts files. So we should try now to identify the remaining unknown events by taking a closer look at the "answers" from the content code. I have made a small list of what we currently have identified.

For those who don't know what events are: They are major changes of which the content code has to be informed. For example the user pressed the 'play' button or the 'stop' button.

Furthermore i made a description of the conversion table syntax (including the non formal inital description from Schluppo).

We also still need a "real" name for TRAP_#0020 (currently called TRAP_Schluppo

). This trap seems to send the conversion table to the player (UINT32 length, UINT32 offset). The correct name has to fit alphabetically between TRAP_Finished and TRAP_MediaReadFile:

Code:

0010 TRAP_Finished
0020 TRAP_... ?
0540 TRAP_MediaReadFile

I would suggest a slightly modified version of the name Schluppo proposed:

Code:

TRAP_GetConversionTable( UINT32 length, UINT32 offset );

Let me know if you agree.

29th October 2008, 23:11

Some news on the events:

First: When event 0x220(0,2,n) happens (in "DAT"), the VM is just doing the trap testing but does not try to attach slot 0 and then read from it. Also the returned segment key is 16 bytes of 0x00 in this case. The same holds for event 0x220(0,0,n).

Also, the first four bytes after the event-id seem to be 0x00000000 for every event, so I think, these bytes are actually not a parameter to any event.

The following is a list of observations on events (the list also includes a lot of interpretation):

Code:

event 0x220 = EVENT_GetSegmentKey(UINT32 FileID, UINT32 SegmentNumber)

This event first tests parts of the trap-system of the VM (the ids/parameters of the testing trap-calls depend on
FileID and SegmentNumber in no recognizable way). After the tests were successfully passed, and if FileID and
SegmentNumber specify a valid, encrypted segment of the conversion table, the event will attach slot 0 and read from it.
Using the data which was read from slot 0, the SegmentKey for the specified segment is computed (without the use of
further traps) and stored at VM-memory 0x10. In the case, that FileID and SegmentNumber select an invalid file (i.e.
the FileID does not occur in the conversion table or it occurs in the conversion table but has no non-empty segment)
or an invalid segment (i.e. the SegmentNumber is larger than the number of segments for the according FileID), the event
writes 16 times the byte 0x00 to VM-memory at address 0x10.

----

event 0x010 = EVENT_Shutdown(void)

This event is probably signaled by the player whenever the eject-button is pressed and the player is getting ready to finish
playback of the movie. 

This event terminates the execution of the VM, most probably including the destruction of the conversion table.

----

event 0x110 = EVENT_BuildConversionTable(UINT32 TableID?)

This event is probably signaled by the player whenever the play-button is pressed and the player is getting ready to start
playback of the movie. 

If TableID = 0xFFFF or 0, the conversion table is reset (to length 0 at VM-memory 0x1000). My guess is, that enough memory to
hold the conversion table is reserved and filled with 0xFF in this case (effectively overwritting the table, in the
case that it previously resided in VM-memory).

If TableID has a different value (including the cases that TableID = 1, 2 etc.), the VM extensively tests itself (by
test-calling most of the traps, each several hundred times). After the testing, the complete (but still encrypted) conversion
table is read from one of the .svm-files (usually 00001.svm) and rebuilt (without the use of further traps). The rebuilt 
conversion table still has encrypted repair descriptors.

After the VM is done with handling this event, the new location and length of the conversion table is signaled to the player
by using TRAP_GetConversionTable.

----

event 0x210 = EVENT_CheckDrive(UINT32 OpID?)

I don't have much information about this event. When OpID = 1, the VM will execute TRAP_DeviceDiscovery(2,1) and then
TRAP_DeviceDiscovery(0,1). If OpID != 1 (especially the cases that OpID = 0 or 2), the VM will directly stop
execution with TRAP_Finished.

Furthermore, the order of events is important. It is for instance not possible to get segment keys before the conversion table has been built. On the other hand, I noticed, that it is not necessary to execute EVENT_BuildConversionTable(1) twice before executing EVENT_GetSegmentKey(1,n).

So here is the reasonable order of events:

Code:

- Let the VM initialize itself until it reaches TRAP_Finished for the first time.
- EVENT_BuildConversionTable(0xFFFF);
- EVENT_CheckDrive(1);
- EVENT_BuildConversionTable(1);
- EVENT_GetSegmentKey(1,1);
...
- EVENT_GetSegmentKey(1,n_1);
- EVENT_GetSegmentKey(2,1);
...
- EVENT_GetSegmentKey(2,n_2);
...
...
- EVENT_GetSegmentKey(m,1);
...
- EVENT_GetSegmentKey(m,n_m);
(- EVENT_Shutdown() )

<m> is the number of encrypted files, <n_i> is the number of segments in the file with id <i>.

In general, if the event parameters are ridiculously strange (such as starting event 0x220 with just one parameter given and the other parameter left undefined), the VM will just immediately terminate execution and not allow successful invocation of any more events. If the parameters are just a little off, the VM may show slightly different behaviour but still accept further events.

30th October 2008, 00:26

Thanks for the analysis. It contains some interesting details. Regard the names you have (quickly) proposed i suggest names which describe the event and not how the content code of this particular movie reacts to it. For example the content code would likely execute a "GetSegmentKey" function in the event of a segment switch (event #0220 ?) in the movie or execute a "BuildConversionTable" function in the event of starting playback of a m2ts file (event #0110 ?).

Quote:

Originally Posted by Content Protection for Optical Media

The interface defines 9 callbacks (Events), which devices may invoke to notify content code of outside events, or to request specific actions.

Keep in mind that the first file which is played back (00005.m2ts) is a short animation of the FOX logo which is not BD+ obfuscated. After that the playback of the movie starts (00001.m2ts).

Edit: It would be ok if you replace "EVENT" with "CALLBACK" if you think it's a specific callback function called by the player and not a general outside event for which different versions of content code can behave differently. For example event #0220 = CALLBACK_GetSegmentKey is ok.

Edit: I also wonder if the event identifiers are grouped like the trap identifiers. Maybe we have a group 0 (0x0000 and 0x0010), group 1 (0x0110) and a group 2 (0x0210 and 0x0220). So you could check if the events/callbacks within one group have something in common.

30th October 2008, 08:21

Feel free to heavilly change the proposed names of the EVENTS / CALLBACKS

I just used them to describe what the current content code seems to be doing upon invocation of the respective EVENT / CALLBACK.

Apart from that, I did some testing and noticed, that for "DAT", the content code is generating the correct conversion table AND correct segment keys, even if there is no VolumeID used (the VolumeID is set to 0x00000000 0x00000000 0x00000000 0x00000000 in this case). Of course I could not test the complete conversion table since I do not have the "00001.m2ts" and hence could not try to repair it using the conversion table which was created WITHOUT VolumeID. Still I came to the conclusion (or 'hope'), that it is possible to remove BD+ from at least the first bunch of released titles without using any VolumeID! Things may have changed starting with "Jumper" or later titles. Can you verify my observation?

Also, I tried to run the debugger on "I Robot", but did not get far, since I do not have the file "00012.m2ts" and the according SHA-Checksum is hence wrong. So the VM just called TRAP_Finished and stopped execution after ~1500 traps (not accepting any events). However, my guess is, that construction of the conversion table and obtainment of the segment keys should work fine, once this SHA-Checksum is correct. Could you try to repair "I Robot", Oopho?

30th October 2008, 21:29

This is the latest binary snapshot of the debugger: BDVM Debugger (testing) *updated*

These steps are supposed to guide you getting the decrypted conversion table for your BD+ protected disc. You don't need any other tools for this.

Code:

Preparations:
-------------

For windows you need the BouncyCastle security provider for java to perform ECDSA authentication to the content code.
Look at these postings for more details on how to install it:
- http://forum.doom9.org/showpost.php?p=1195864&postcount=218
- http://forum.doom9.org/showpost.php?p=1208775&postcount=315

Follow these steps please:
--------------------------

0. mount the disc (e.g.: "mount /dev/sr0 /media/cdrom"). You should see a BDSVM directory otherwise the disc is not
   BD+ protected and you should try a different movie.
1. start the debugger with "sh debugger.sh" from this directory
2. select "Settings -> Set disc mount point" and navigate to the mount point of your blue ray disc (e.g.: /media/cdrom/)
3. if you haven't edited the volume_id.bin with a hex editor to match the volume ID from this disc select
   "Settings -> set volume id" and enter the 16 byte number as hex (e.g.: "C659019F89718033F0FC54E894C98428")
   If you don't know the volume id you can either obtain it from the output of aacskeys or skip this point because
   the content code seems to ignore the volume id for the discs we checked.
4. press run or hit the "F5" key and watch the console output
5. after around 30s you should find a file named "conv_tab.bin" containing the decrypted conversion table in this
   directory.
6. Post the "conv_tab.bin" and the console output in the forum please.

You will find a small readme in the archive which contains the same description. Extract the archive in a directory, navigate to this directory and launch the debugger from there.

If you would like to test the resulting conversion table you need to decrypt the disc with DumpHD and then use this tool to repair the 00001.m2ts.

Thanks for your reports in advance.

@Schluppo: i get a conversion table for i robot and the decryption of the same seems to work fine. I currently have some problems with anydvd which is why i couldn't verify this yet. This issue will probably be solved soon. It doesn't seem to know my drive has it's firmware patched.

31st October 2008, 02:31

I have now successfully repaired "I robot". My 00001.m2ts and the one created by AnyDVD-HD are identical. There was however one bug which caused segment 0 of the first subtable in the conversion table never to be decrypted. The bug didn't show up with "The Day After Tomorrow" because that particular segment was empty there.

Anyway the bug is fixed in revision 116 and i have also updated the binary snapshot archive in the above posting. Furthermore for those who are curious of how these conversion tables look like: these are the conversion tables i used to successfully repair both movies.

Edit: i believe the checking of 00001.m2ts with TRAP_MediaSHAFileHash is because a particular version of a software player called "PowerDVD" allowed the playback a BD+ protected (but AACS decrypted) movies from hard drive. So those checks probably try to make sure the movie is still encrypted and therefor cannot be played from hard drive with this player (without hacks of course).

Edit: feel free to play around with the content code. If you get any other conversion tables for both movies than those i posted above something went wrong.

Turtleggjp · 31st October 2008, 18:29

Very nice work guys! So now that you have figured out most of BD+'s mysteries, what can they do to protect future releases? With AACS, it's easy, just revoke the keys used. Does your implementation of BD+ use any revokable keys, or are they limited to the unused instructions to try and fool you in the future?

31st October 2008, 18:50

- They could find bugs in our basic VM (such as treatment of divide by zero or similar) and then exploit the bugs in order to distinguish the emulated VM from a valid player. Anyway, our basic VM is behaving fine for hundreds of millions of instruction executions already, so they might have a hard time, to find any bugs.
- They can use previously unused traps or they might use previously used traps with unusual parameters. However, our trap-implementations are already close to the standard-implementation of traps, and it is easy to fix any bugs in our traps. So over time (as the VM is getting closer and closer to the standards), the BD+ developers will have trouble distinguishing our VM from a valid player by just looking at the correct treatment of traps.
- The current implementation of traps is using player specific data such as player keys (for AES), the player's public key (for ECDSA), memory footprints and player signatures. The BD+ developers can force a firmware update (including new player keys, public key, memory footprints or signatures) and then use the content code to 'revoke' (or rather interdict) the leaked player specific data in future. As I see it, this is the only tactic which may cause trouble in the long run, since it might become necessary to obtain the player specific data for every new version of BD+. I guess the situation could become similar to AACS.

31st October 2008, 18:55

Quote:

Originally Posted by Turtleggjp

Very nice work guys! So now that you have figured out most of BD+'s mysteries, what can they do to protect future releases? With AACS, it's easy, just revoke the keys used. Does your implementation of BD+ use any revokable keys, or are they limited to the unused instructions to try and fool you in the future?

The key set currently in use consists of 7 AES keys for TRAP_Aes (see posting #163) and two ECDSA public/private key pairs for TRAP_PrivateKey (see posting #188). These keys can theoretically be revoked (e.g. by adding 7 more AES keys and don't use the old ones anymore for new movies). Apart from that the purpose of the program (called "content code") running inside the player on a virtual machine is to detect any known compromised players or known unlicensed emulators (like ours). The content code is give a wide range of opportunities to do that. For example it has (limited) access to the player memory and can even execute arbitrary code on the machine though we haven't seen that yet and our emulator doesn't support this either.
As long as we have access to a working (licensed) players all these measures are useless as we can record traces from this player and adjust the data "injected" in the virtual machine address space by traps or events to perfectly match our recordings. Even if whitebox attack resistant AES or ECDSA algorithms are used and nobody manages to break them we can still use the obfuscated algorithms and their keys.

Edit: this project has left it's marks in wikipedia

KenD00 · 1st November 2008, 00:24

First i have to say you are doing amazing work here, thank you. I have to admit that i don't understand much of what you are doing here, but the conversion table, thats something i can handle

.

So i wanted to test this one out. Unfortunately i don't have any of the movies you are using here but two different ones, Die Hard 4 and Jumper. I have used the latest debugger binary package (maybe you should add to the readme that you need the BouncyCastle provider to run it) together with the correct volume id files. But somehow i'm not successful

.

Jumper failed quite fast, it produced the error "Unknown trap". For Die Hard 4 i got a conversion table but along with a lot of error messages about missing subtable 0001. I have uploaded that conversion table and the console output here.

Because im not so good at reading binary files i wrote a small viewer which decodes conversion tables and displays them more human readable, ConvTableView 0.1. My conversion table doesn't look so bad after all, an entry for every m2ts file, all entries are empty except for the main movie which has about 400 segments.

I modified the content repair program to fix that movie (it uses tableid 20) and changed it to copy the conversion table into memory to reduce seeking too speed it up (but it doesn't seem to be much faster now), you can download it here.

However, after applying the fix the movie is still broken and somehow it looks worse than before the patching

.

1st November 2008, 01:13

Quote: