Finally handling BD+ (?)

[Accident]

Excellent, I have applied those tests as well. I finally also found a real problem in libbluray:

[dst] MemSearch(003BF9B0, 00000014, 003BF9C2, 00000002, 003BF8F0
[dlx] MemSearch: storing 00000000 in *dst
[bdtest] comparing with 'post_trap_snapshots/post_trap_reg_010911.bin'
+003BF8F0 00 00 00 00 E2 70 1A D3 00 00 01 00 00 00 02 00  |.....p..........|
-003BF8F0 00 3B F9 C2 E2 70 1A D3 00 00 01 00 00 00 02 00  |.....p..........|

Which was off-by-one error, probably only related to C version.

Edit: Not too surprising I suppose, but I had my trace-WD simply fix the differences when they occurred, and turning that off is enough for it to derail. So it does seem to depend on the 0x140 differences or others. Also amusingly enough, TRAPs (at #10147) will cause WD to trigger, which requires some special handling. It seems to just set it to 4000 without generating a BREAK though.

[loo3aem3ON]

We need to reverse engineer TRAP_DiscoveryRAM for memory range (0x00250000 - 0x0028FFFF) and (0x00290200 - 0x00290293). I'm taking snapshots of these sections after every trap call now. It is the only system call which still returns wrong data (for the given content code up to the point where the first segment key is returned).

Edit: The structure of the snapshots is:

00000000-00000003: last instruction (E400????)
00000004-0000001B: 6 parameters
0000001C-0000001F: trap return value
00000020-0004001F: snapshot (00250000-0028FFFF)

everything little endian

Edit:

Originally Posted by Accident

Which was off-by-one error, probably only related to C version.

The debugger once had the same problem and this was fixed some time ago.

Originally Posted by Accident

Not too surprising I suppose, but I had my trace-WD simply fix the differences when they occurred, and turning that off is enough for it to derail. So it does seem to depend on the 0x140 differences or others. Also amusingly enough, TRAPs (at #10147) will cause WD to trigger, which requires some special handling. It seems to just set it to 4000 without generating a BREAK though.

I'll give a short summary. Maybe you are making things to complicated.

If the content code is idle:
Trap calls cost 0x140 cycles if executed successfully. If the trap execution aborts with an error the timer remains unchanged. At the end of every instruction (this includes the TRAP instruction) the timer is decremented and subsequently checked if still greater than zero. If it's zero or below it is reset to 0xFA0.

If the content code is busy:
Basically identical to the above case except trap calls cost 0x7FFFFFFF cycles and the timer reset value is 0x7FFFFFFF.

TRAP_Finished and event set the timer to 0xFA0 or 0x7FFFFFFF and therefor require special treatment.

[loo3aem3ON]

A snapshot package of the virtual player memory range 00250000-0028FFFF is now available. The structure is as described in the previous posting. Each snapshot was taken after a trap call from the content code.
The snapshot data is BIG endian and the header little endian. Note that i already removed the obfuscation layer "^= ( 3 * address * address + 1 )".

Looking at the first 1000 snapshots i noticed that this area seems to change only after TRAP_Aes with player keys 3,4,6 so there might be a relationship. Also note that the player is caching the decrypted key so it won't decrypt the same encrypted key with the same player key again and again.

Send me a private message if you would like to help in the analysis of the contents of this section.

[loo3aem3ON]

Accidents recent findings show that TRAP_DeviceAccess is involved in the segment key calculation which i claimed is not. I've now double checked my previous results. It's easy to see that running the content code with snapshot guidance up to a certain point and then resuming without snapshot support can always be used to identify the last problematic trap call (using divide&conquer to search efficiently). I've now applied this technique to the new content code and the last problem is:

#005013 TRAP_DeviceAccess      (00000002, 00000000, 003DF9E0);

My apologies.

Edit: the second parameter of TRAP_DeviceAccess seems to be the data direction ( 0 = write, 1 = read )

(0,1,?) : reads 4 bytes from pBuf (doesn't write)
(1,0,?) : writes 4 bytes to pBuf (doesn't read)
(2,1,?) : reads 4 bytes from pBuf (doesn't write)
(2,0,?) : writes 4 bytes to pBuf (doesn't read)

[Accident]

Not entirely sure what is wrong with libbluray's TRAP_PrivateKey, I updated key 1 (x, y and d) with the new values, but it still produces quite different results.

TRAP 000851

[dlx] PrivateKey(00000001, *00002CA8, *00002C94, 00000010, 00000000)
Computed message:
42 44 53 56 4D 5F 50 4B 00 00 00 00 00 00 00 10 31 96 92 A9 31 EB BC 05 0A B3 B8 3D 45 6F 36 01
                       | controlwd |   srcLen  | Data, 16 bytes. -> 

SHA Hash computed from that message :
AD 03 B0 6A 8D 91 FF 63 21 8C 70 F1 68 7A 64 3B CB 15 B6 72

Computed signature, starting 8 bytes in. First 4 bytes are in the message above, so data copy is ok:
+00002CA0 45 6F 36 01 00 00 00 04 69 85 69 3B B8 58 9F 2E  |Eo6.....i.i..X..|
+00002CB0 CD AD DF 56 95 0C FA 70 C0 8F 0F 4C 2D 11 8F CB  |...V...p...L....|
+00002CC0 2E 76 0B 17 0C A8 BC 97 F4 47 B9 72 B8 D5 25 BA  |.v.......G.r....|

Expected signature.
-00002CA0 45 6F 36 01 00 00 00 04 45 8C F0 B1 E0 26 05 E5  |Eo6.....E.......|
-00002CB0 1A F5 44 12 78 06 B7 1A 70 EA 43 32 71 0D D8 5B  |..D.x...p.C2q...|
-00002CC0 9D 82 19 54 67 6F 6D F8 F8 F5 D6 BE 48 E8 BA D5  |...Tgom.....H...|

Perhaps I should spend some time to get the Java debugger to run so I can dump the interim values there and see where it goes wrong.


Edit:
Ah, this I was not aware of. That explains why the Debugger calls Verify after. Perhaps I should as well, to feel more secure.

[loo3aem3ON]

Originally Posted by Accident

Not entirely sure what is wrong with libbluray's TRAP_PrivateKey, I updated key 1 (x, y and d) with the new values, but it still produces quite different results.

That's perfectly correct and the strength of ECDSA is based on this randomness. Lot's of signatures (r,s pairs) are valid for the same message/hash. The content code will verify the signature and will abort prematurely if the signature is wrong.

[loo3aem3ON]

I've traced the values returned by TRAP_DeviceAccess backwards and ended up in the java virtual machine interpreter
Is it possible that this trap is interacting with the java program (gui?) on the disc?
Could anyone give me a short summary of what the java program on the blue ray discs does? My current understanding is that it creates the animated gui for the user.

Edit: Btw the values returned by TRAP_DeviceAccess(2,0,?) seem to be different each time.

[KenD00]

Originally Posted by loo3aem3ON

My current understanding is that it creates the animated gui for the user.

Thats one function. However, it has some more advanced features too, e.g. it can access the AACS layer to provide online functions and managed copy. I don't have the BD+ specs (lol, who on this forum has them ) but maybe the BD-J application can access the BD+ stuff too? But what sense would that make? BD+ protected online content? But this shouldn't affect the actual decryption process of the disc, except the BD-J code actually works together with the BD+ content code to decrypt the disc .

[dirio49]

Hi,
Searching though Google
it seems that TRAP_DeviceAccess has 4 parameters, not 3
UINT32 TRAP_DeviceAccess(UINT32 dev, UINT32 opID, UINT8*buf, UINT32*len);
http://www.freepatentsonline.com/y2008/0137848.html

Sorry if you already knew this

[loo3aem3ON]

Originally Posted by KenD00

But this shouldn't affect the actual decryption process of the disc, except the BD-J code actually works together with the BD+ content code to decrypt the disc

I've read somewhere that BD+ is sitting on top of BD-J so it could be that the data is only forwarded through this BD-J layer. I'm not sure about what i saw but it looks like the BD-J code is calling some function (callback?) which writes the 4 bytes into the memory. The data is later fetched by TRAP_DeviceAccess. The load/store procedures used to exchange the data look like the "shared memory" (shared between BD+ and BD-J) is well structured using 128 registers of length 32-bit each. The registers in use during TRAP_DeviceAccess activity are 67h and 68h.
(I haven't seen this code before and some of the statements above are based on assumptions.)

Originally Posted by dirio49

it seems that TRAP_DeviceAccess has 4 parameters, not 3

It's likely that the length was omitted because this trap seems to read or write a single 32-bit dword on each call only. I am not even sure it really is TRAP_DeviceAccess although the name seems to fit in alphabetically. But thanks for pointing out this difference.

[loo3aem3ON]

I've made a list of the important TRAP_DeviceAccess calls showing the exchange of data between the content code and some unknown device. A similar list has previously been made by js06078 in posting #608 but it didn't show the data transmitted from the content code to the device.

Send == from content code to device
Receive == from device to content code

#004963 TRAP_DeviceAccess(1, 0, *) // Receive "F1000000"
#004964 TRAP_DeviceAccess(1, 0, *) // Receive "F1000000"
#004965 TRAP_DeviceAccess(2, 0, *) // Receive "00000000"
#004966 TRAP_DeviceAccess(2, 1, *) // Send    "00000001"
#004967 TRAP_DeviceAccess(2, 1, *) // Send    "FFFFFFFE"
#004968 TRAP_DeviceAccess(0, 1, *) // Send    "04000004"

#004970 TRAP_DeviceAccess(1, 0, *) // Receive "00004000"
#004971 TRAP_DeviceAccess(1, 0, *) // Receive "00004000"
#004972 TRAP_DeviceAccess(2, 1, *) // Send    "3EA9DAFF"
#004973 TRAP_DeviceAccess(0, 1, *) // Send    "04000008"

#004975 TRAP_DeviceAccess(1, 0, *) // Receive "00008000"
#004976 TRAP_DeviceAccess(1, 0, *) // Receive "00008000"
#004977 TRAP_DeviceAccess(2, 1, *) // Send    "B23259D5"
#004978 TRAP_DeviceAccess(0, 1, *) // Send    "0400000C"

#004980 TRAP_DeviceAccess(1, 0, *) // Receive "0000C000"
#004981 TRAP_DeviceAccess(1, 0, *) // Receive "0000C000"
#004982 TRAP_DeviceAccess(2, 1, *) // Send    "53B07B58"
#004983 TRAP_DeviceAccess(0, 1, *) // Send    "04000010"

#004985 TRAP_DeviceAccess(1, 0, *) // Receive "00010000"
#004986 TRAP_DeviceAccess(1, 0, *) // Receive "00010000"
#004987 TRAP_DeviceAccess(2, 1, *) // Send    "60FBC4BB"
#004988 TRAP_DeviceAccess(0, 1, *) // Send    "04000014"

#004990 TRAP_DeviceAccess(1, 0, *) // Receive "00014000"
#004991 TRAP_DeviceAccess(1, 0, *) // Receive "00014000"
#004992 TRAP_DeviceAccess(2, 0, *) // Receive "60FBC4BB"
#004993 TRAP_DeviceAccess(2, 1, *) // Send    "60FBC4BC"
#004994 TRAP_DeviceAccess(0, 1, *) // Send    "00000014"

#004996 TRAP_DeviceAccess(1, 0, *) // Receive "04014004"
#004997 TRAP_DeviceAccess(1, 0, *) // Receive "04014004"
#004998 TRAP_DeviceAccess(2, 0, *) // Receive "BC79595F"
#004999 TRAP_DeviceAccess(0, 1, *) // Send    "00004014"

#005001 TRAP_DeviceAccess(1, 0, *) // Receive "04014008"
#005002 TRAP_DeviceAccess(1, 0, *) // Receive "04014008"
#005003 TRAP_DeviceAccess(2, 0, *) // Receive "97F05643"
#005004 TRAP_DeviceAccess(0, 1, *) // Send    "00008014"
                                        
#005006 TRAP_DeviceAccess(1, 0, *) // Receive "0401400C"
#005007 TRAP_DeviceAccess(1, 0, *) // Receive "0401400C"
#005008 TRAP_DeviceAccess(2, 0, *) // Receive "07A0ABF2"
#005009 TRAP_DeviceAccess(0, 1, *) // Send    "0000C014"

#005011 TRAP_DeviceAccess(1, 0, *) // Receive "04014010"
#005012 TRAP_DeviceAccess(1, 0, *) // Receive "04014010"
#005013 TRAP_DeviceAccess(2, 0, *) // Receive "CC10F7C5"
#005015 TRAP_DeviceAccess(2, 1, *) // Send    "10000000"
#005016 TRAP_DeviceAccess(0, 1, *) // Send    "04010018"

#005018 TRAP_DeviceAccess(1, 0, *) // Receive "00018010"
#005019 TRAP_DeviceAccess(1, 0, *) // Receive "00018010"
#005020 TRAP_DeviceAccess(2, 1, *) // Send    "00000000"
#005021 TRAP_DeviceAccess(0, 1, *) // Send    "0201001A"

#005023 TRAP_DeviceAccess(1, 0, *) // Receive "0001A010"
#005024 TRAP_DeviceAccess(1, 0, *) // Receive "0001A010"
#005025 TRAP_DeviceAccess(2, 0, *) // Receive "00000000"
#005026 TRAP_DeviceAccess(2, 1, *) // Send    "00000001"
#005027 TRAP_DeviceAccess(0, 1, *) // Send    "0001001A"

Your ideas about what is happening here and what kind of device/module the content code could be communicating with are welcome.

Edit: About 16 bytes are sent and then 16 totally different bytes are received. Maybe a cryptographic coprocessor?

[tteich]

Originally Posted by loo3aem3ON

I've made a list of the important TRAP_DeviceAccess calls showing the exchange of data between the content code and some unknown device. A similar list has previously been made by js06078 in posting #608 but it didn't show the data transmitted from the content code to the device.

Send == from content code to device
Receive == from device to content code

#004963 TRAP_DeviceAccess(1, 0, *) // Receive "F1000000"
#004964 TRAP_DeviceAccess(1, 0, *) // Receive "F1000000"
#004965 TRAP_DeviceAccess(2, 0, *) // Receive "00000000"
#004966 TRAP_DeviceAccess(2, 1, *) // Send    "00000001"
#004967 TRAP_DeviceAccess(2, 1, *) // Send    "FFFFFFFE"
#004968 TRAP_DeviceAccess(0, 1, *) // Send    "04000004"

#004970 TRAP_DeviceAccess(1, 0, *) // Receive "00004000"
#004971 TRAP_DeviceAccess(1, 0, *) // Receive "00004000"
#004972 TRAP_DeviceAccess(2, 1, *) // Send    "3EA9DAFF"
#004973 TRAP_DeviceAccess(0, 1, *) // Send    "04000008"

#004975 TRAP_DeviceAccess(1, 0, *) // Receive "00008000"
#004976 TRAP_DeviceAccess(1, 0, *) // Receive "00008000"
#004977 TRAP_DeviceAccess(2, 1, *) // Send    "B23259D5"
#004978 TRAP_DeviceAccess(0, 1, *) // Send    "0400000C"

#004980 TRAP_DeviceAccess(1, 0, *) // Receive "0000C000"
#004981 TRAP_DeviceAccess(1, 0, *) // Receive "0000C000"
#004982 TRAP_DeviceAccess(2, 1, *) // Send    "53B07B58"
#004983 TRAP_DeviceAccess(0, 1, *) // Send    "04000010"

#004985 TRAP_DeviceAccess(1, 0, *) // Receive "00010000"
#004986 TRAP_DeviceAccess(1, 0, *) // Receive "00010000"
#004987 TRAP_DeviceAccess(2, 1, *) // Send    "60FBC4BB"
#004988 TRAP_DeviceAccess(0, 1, *) // Send    "04000014"

#004990 TRAP_DeviceAccess(1, 0, *) // Receive "00014000"
#004991 TRAP_DeviceAccess(1, 0, *) // Receive "00014000"
#004992 TRAP_DeviceAccess(2, 0, *) // Receive "60FBC4BB"
#004993 TRAP_DeviceAccess(2, 1, *) // Send    "60FBC4BC"
#004994 TRAP_DeviceAccess(0, 1, *) // Send    "00000014"

#004996 TRAP_DeviceAccess(1, 0, *) // Receive "04014004"
#004997 TRAP_DeviceAccess(1, 0, *) // Receive "04014004"
#004998 TRAP_DeviceAccess(2, 0, *) // Receive "BC79595F"
#004999 TRAP_DeviceAccess(0, 1, *) // Send    "00004014"

#005001 TRAP_DeviceAccess(1, 0, *) // Receive "04014008"
#005002 TRAP_DeviceAccess(1, 0, *) // Receive "04014008"
#005003 TRAP_DeviceAccess(2, 0, *) // Receive "97F05643"
#005004 TRAP_DeviceAccess(0, 1, *) // Send    "00008014"
                                        
#005006 TRAP_DeviceAccess(1, 0, *) // Receive "0401400C"
#005007 TRAP_DeviceAccess(1, 0, *) // Receive "0401400C"
#005008 TRAP_DeviceAccess(2, 0, *) // Receive "07A0ABF2"
#005009 TRAP_DeviceAccess(0, 1, *) // Send    "0000C014"

#005011 TRAP_DeviceAccess(1, 0, *) // Receive "04014010"
#005012 TRAP_DeviceAccess(1, 0, *) // Receive "04014010"
#005013 TRAP_DeviceAccess(2, 0, *) // Receive "CC10F7C5"
#005015 TRAP_DeviceAccess(2, 1, *) // Send    "10000000"
#005016 TRAP_DeviceAccess(0, 1, *) // Send    "04010018"

#005018 TRAP_DeviceAccess(1, 0, *) // Receive "00018010"
#005019 TRAP_DeviceAccess(1, 0, *) // Receive "00018010"
#005020 TRAP_DeviceAccess(2, 1, *) // Send    "00000000"
#005021 TRAP_DeviceAccess(0, 1, *) // Send    "0201001A"

#005023 TRAP_DeviceAccess(1, 0, *) // Receive "0001A010"
#005024 TRAP_DeviceAccess(1, 0, *) // Receive "0001A010"
#005025 TRAP_DeviceAccess(2, 0, *) // Receive "00000000"
#005026 TRAP_DeviceAccess(2, 1, *) // Send    "00000001"
#005027 TRAP_DeviceAccess(0, 1, *) // Send    "0001001A"

Your ideas about what is happening here and what kind of device/module the content code could be communicating with are welcome.

Edit: About 16 bytes are sent and then 16 totally different bytes are received. Maybe a cryptographic coprocessor?

16bytes smells like DES, perhaps a CBC or ECB. But since AES supports different blocksizes it could also be a 16byte AES encryption / decryption. Some of the patents show an embedded security chip (kind of SmartCard chip). This could be one of the "devices" that the content code is able to access.

[loo3aem3ON]

Originally Posted by tteich

16bytes smells like DES, perhaps a CBC or ECB. But since AES supports different blocksizes it could also be a 16byte AES encryption / decryption. Some of the patents show an embedded security chip (kind of SmartCard chip). This could be one of the "devices" that the content code is able to access.

DES uses a 56-bit key and not 128. I need more time to trace the data through the java virtual machine.

[loo3aem3ON]

One of our contributers gave us a list with the correct trap names. Below you can see those we named incorrectly:

0510 TRAP_ApplicationLayer       (former TRAP_DeviceAccess)
0520 TRAP_Discovery              (former TRAP_DeviceDiscovery)
0020 TRAP_FixUpTableSend         (former TRAP_GetConversionTable)
0550 TRAP_MediaCheck             (former TRAP_MediaSHAFileHash)
0220 TRAP_MultiplyWithCarry      (former TRAP_MultiplyWithRipple)
0140 TRAP_Sha1                   (former TRAP_Sha)

As you can see there is no TRAP_DeviceAccess and the correct name for this system call is TRAP_ApplicationLayer. This explains why i ended up in the java virtual machine interpreter with my trace.

Thanks a lot for this information!

[loo3aem3ON]

To implement TRAP_ApplicationLayer allocate an array of 128 32-bit integer. The first parameter of TRAP_ApplicationLayer is the register number + 66h you are accessing. The second parameter specifies the direction (read/write or send/receive respectively).

Examples:
TRAP_ApplicationLayer( r, 1, 1234h ) == read the 32-bit integer at 1234h (vm memory) and write it to register 66h + r
TRAP_ApplicationLayer( r, 0, 1234h ) == read the register 66h + r and write its contents to 1234h (vm memory)

This array you are accessing is also present in the virtual player memory. If you call TRAP_DiscoveryRAM and request the range 0x00304000-003041FFF you will get it.

The folder BDMV/JAR/ on this disc contains a file 77770.jar. After extraction i could find the files BDClassLoaderException.class, BDPlusSocketException.class, bluray.Handshake.perm, Handshake.class and LibHandshakeException.class and others in the folder com/macrovision/bdplus/.

I can see the java opcode which is loading and storing the data in this array but i couldn't find it on the disc. The code contains lots of strings like areInputMethodsEnabled() so it is maybe a common java library.

[Accident]

I can confirm that it thinks TRAP_ApplicationLayer is 0x510, and takes 3 arguments.

I also noticed TRAP_FixUpTableSend() can return 0x80FFFFFF when "[$a0 + $9C] != 3". I am not sure what that check is, or what $a0 contains. Perhaps it is not important.

[loo3aem3ON]

Originally Posted by Accident

I can confirm that it thinks TRAP_ApplicationLayer is 0x510, and takes 3 arguments.

Thanks.

Originally Posted by Accident

I also noticed TRAP_FixUpTableSend() can return 0x80FFFFFF when "[$a0 + $9C] != 3". I am not sure what that check is, or what $a0 contains. Perhaps it is not important.

Yes i have ignored a few checks. I can see that TRAP_FixUpTableSend can return 80FFFFFFh too and it probably is important but other things like TRAP_ApplicationLayer have a higher priority now.

I've run a few tests with a BD+ protected disc without any java code. In this case TRAP_ApplicationLayer seems to be accessing a simple memory of 3 registers. Nothing else is changing the contents of these registers.

I have further tried other discs with different java code and they already behave differently when reading register 67h (calling TRAP_ApplicationLayer(1,0,*)). For example for "The Day After Tomorrow" i get F0000000h instead of F1000000h.

I was given a few debug messages which suggest that these registers are named PSR:

66h = PSR 102
67h = PSR 103
68h = PSR 104 (shared status register)

[loo3aem3ON]

From the bits and pieces I was given i can tell that the registers we are looking at are called "Player Status Registers" (PSR) and for some of them i could find a short description (see this file). A part of the data i received also suggests a relationship between PSR103 and AACS.

Edit: Renamed "Player State Registers" to "Player Status Registers" (thanks KenD00)

[KenD00]

PSR sounds familiar, they are mentioned in the AACS spec but called Player Status Registers there, looks like they are the same. From what you have written in your documentation it looks like they are, in comparison to DVD-Players, the SPRM's of the Blu-Ray player. The AACS spec says that PSR96 and PSR97 contain the Playlist_Indicators when playing back a title that uses Sequence Keys.

[loo3aem3ON]

Originally Posted by KenD00

PSR sounds familiar, they are mentioned in the AACS spec but called Player Status Registers there

I've just double checked my notes and indeed they are called "Player Status Registers". My mistake, sorry. At least the meaning is about the same.

Originally Posted by KenD00

looks like they are the same. From what you have written in your documentation it looks like they are, in comparison to DVD-Players, the SPRM's of the Blu-Ray player. The AACS spec says that PSR96 and PSR97 contain the Playlist_Indicators when playing back a title that uses Sequence Keys.

Thank you. I've updated the documentation for PSR96 and PSR97. If anyone finds a description for some of the remaining unknown registers please post it here. It's required for a proper implementation of TRAP_DiscoveryRAM and also helps us with TRAP_ApplicationLayer.