Finally handling BD+ (?)

This happens about 20 times:

#002843 TRAP_AddWithCarry      (001EBC60, 001EDC60, 0000000F);
Register error at trap number 2843:
post_reg_snapshot:
00000000 00000000 001EBC60 001EFC60 001EFC60 0002282C 0000000F 00000190
00000190 001EFAD0 0000001F 000079E0 001EBAD0 001EDAD0 00000020 00000080
00000200 000088B8 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EBA64 001EFAD8 00059488
post_reg_execute:
00000000 00000001 001EBC60 001EFC60 001EFC60 0002282C 0000000F 00000190
00000190 001EFAD0 0000001F 000079E0 001EBAD0 001EDAD0 00000020 00000080
00000200 000088B8 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EBA64 001EFAD8 00059488
Memory Error at trap 2843

Seems like the current version returns 1 in R[1] all the time, whereas it should return 0 in case that the carry flag is not set and 1 only in the case that the carry flag is set.

Also:

#002963 TRAP_MultiplyWithRipple(001EDBE4, 001EEB5C, 0000002F, E9DE141D);
java.lang.ArrayIndexOutOfBoundsException
        at java.lang.System.arraycopy(Native Method)
        at bdvm.bdsvm_player_traps.MultiplyWithRipple(bdsvm_player_traps.java:688)
        at bdvm.bdsvm_player_interface.TRAP_handler(bdsvm_player_interface.java:669)

Could you please post the values at src and dst so i can verify it? TRAP_AddWithCarry returns only '1' if the resulting number is one byte longer than both input numbers which can only happen if an overflow occurred.

You obviously have a modified version of the debugger (a branch). Why don't you upload your changes to the repository?

Edit: i found the problem. It's again the inability of java to tread unsigned numbers correctly. I have uploaded a workaround. Please report back if there are still issues with those traps. All our values are unsigned and java only knows signed numbers

I only re-added the automatic loading of post-break-snapshots so that I could let it run past the first TRAP_Finish again (otherwise there's no way to get to all those trap-tests). Since you did not like the way it was implemented, I did not want to add it to the repository again. Anyway, apart from that small change, I always use the newest version from the repository, especially I do not interfere with the implementation of traps or parameter checks.

TRAP_AddWithCarry and TRAP_MultiplyWithRipple are fine now. Next problematic one is this:

#003895 TRAP_Aes               (001EE288, 001EE298, 00000000, 001EE238, FFF10000);
Register error at trap number 3895:
post_reg_snapshot:
00000000 00000000 00000000 00000000 0002282C 001EE298 001EE288 001EE238
001EE1D8 001EE248 001EE228 0003EC44 001EE198 001EE218 001EE158 00000200
00000200 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EE0DC 001EFAD8 00062764
post_reg_execute:
00000000 80000001 00000000 00000000 0002282C 001EE298 001EE288 001EE238
001EE1D8 001EE248 001EE228 0003EC44 001EE198 001EE218 001EE158 00000200
00000200 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EE0DC 001EFAD8 00062764

(bad parameter checking or bad treatmant of case OpOrKeyID=0xFFF10000)

another example:

#003899 TRAP_Aes               (001EE288, 001EE248, 00000004, 001EE238, FFF10000);
Register error at trap number 3899:
post_reg_snapshot:
00000000 00000000 00000000 00000000 0002282C 001EE298 001EE288 001EE238
001EE1D8 001EE248 001EE228 00000000 001EE198 001EE218 001EE158 00000200
00000200 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EE0DC 001EFAD8 00062978
post_reg_execute:
00000000 80000001 00000000 00000000 0002282C 001EE298 001EE288 001EE238
001EE1D8 001EE248 001EE228 00000000 001EE198 001EE218 001EE158 00000200
00000200 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EE0DC 001EFAD8 00062978
Byte 1EE288: snapshot: 3A execute: 00
Byte 1EE289: snapshot: D7 execute: 00
Byte 1EE28A: snapshot: 7B execute: 00
Byte 1EE28B: snapshot: B4 execute: 00
...
Byte 1EE2C4: snapshot: 04 execute: 00
Byte 1EE2C5: snapshot: 72 execute: 00
Byte 1EE2C6: snapshot: 5D execute: 00
Byte 1EE2C7: snapshot: D4 execute: 00
Memory Error at trap 3899

And then TRAP_DeviceDiscovery (probably bad parameter check again?):

#004006 TRAP_DeviceDiscovery   (00000002, 00000000, 001EE854, 001EE7D0);
Register error at trap number 4006:
post_reg_snapshot:
00000000 00000000 001EF850 0000000F 0002282C 001EE854 00000009 00000000
001EE854 00000000 00000080 00000027 07D6060D 00000000 00000000 FFFFFFC4
07D6060D 00000000 001EE7D0 0005CC60 001EF814 001EFAD0 00000000 00000000
001EE854 00000000 00000000 00000000 000994B0 001EE760 001EFAD8 0006CBB4
post_reg_execute:
00000000 80000001 001EF850 0000000F 0002282C 001EE854 00000009 00000000
001EE854 00000000 00000080 00000027 07D6060D 00000000 00000000 FFFFFFC4
07D6060D 00000000 001EE7D0 0005CC60 001EF814 001EFAD0 00000000 00000000
001EE854 00000000 00000000 00000000 000994B0 001EE760 001EFAD8 0006CBB4
Byte 1EE854: snapshot: 00 execute: 5C
Byte 1EE855: snapshot: 00 execute: AA
Byte 1EE856: snapshot: 00 execute: 14
Byte 1EE857: snapshot: 52 execute: 80
...
Byte 1EE8D0: snapshot: 00 execute: E6
Byte 1EE8D1: snapshot: 00 execute: 3C
Byte 1EE8D2: snapshot: 00 execute: D8
Byte 1EE8D3: snapshot: 00 execute: 27
Memory Error at trap 4006

Here the endianness of the result needs to be changed:

#004007 TRAP_DeviceDiscovery   (00000002, 00000001, 001EE8D4, 001EE7D0);
Byte 1EE8D4: snapshot: 00 execute: 2A
Byte 1EE8D7: snapshot: 2A execute: 00
Byte 1EE8DC: snapshot: 00 execute: 02
Byte 1EE8DD: snapshot: 2C execute: 08
Byte 1EE8DE: snapshot: 08 execute: 2C
Byte 1EE8DF: snapshot: 02 execute: 00
Byte 1EE8E0: snapshot: 00 execute: 03
Byte 1EE8E3: snapshot: 03 execute: 00
Byte 1EE8E4: snapshot: 00 execute: 01
Byte 1EE8E7: snapshot: 01 execute: 00
Memory Error at trap 4007

...

#004436 TRAP_DeviceDiscovery   (00000001, 00000001, 001EF814, 001EF810);
Register error at trap number 4436:
post_reg_snapshot:
00000000 80000001 80000001 001EF7E8 001EF7E8 0002282C 001EF810 001EF814
00000005 0006DD30 00000000 0003EC54 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EF7E8 001EFAD8 0006D7E0
post_reg_execute:
00000000 00000000 80000001 001EF7E8 001EF7E8 0002282C 001EF810 001EF814
00000005 0006DD30 00000000 0003EC54 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EF7E8 001EFAD8 0006D7E0
Byte 1EF812: snapshot: 00 execute: 01
Byte 1EF813: snapshot: 2A execute: 1C
Byte 1EF814: snapshot: 07 execute: 00
Byte 1EF815: snapshot: D8 execute: 00
...
Byte 1EF92C: snapshot: 75 execute: FA
Byte 1EF92D: snapshot: F2 execute: F3
Byte 1EF92E: snapshot: 13 execute: 72
Byte 1EF92F: snapshot: 8A execute: 6F

OK, apart from these two traps (TRAP_Aes and TRAP_DeviceDiscovery), there is only the problem with

IC: 37177656 Trap #2037: trap_0x420(1efd08,ffffffff)= TRAP-SlotRead

remaining.

Two mistakes were in the parameter check documentation/implementation of TRAP_Aes and TRAP_DeviceDiscovery. I have already committed the patch to fix those issues. The big endian issue is fixed too (not committed yet).

#004436 TRAP_DeviceDiscovery   (00000001, 00000001, 001EF814, 001EF810);

I don 't know why this call should fail. My best guess is that buf and len are too close together but i couldn't find and check for that but i should be able to find the problem soon. Some checks are done deep inside the trap implementation which is a bit more difficult to study.

Originally Posted by schluppo

OK, apart from these two traps (TRAP_Aes and TRAP_DeviceDiscovery), there is only the problem with

IC: 37177656 Trap #2037: trap_0x420(1efd08,ffffffff)= TRAP-SlotRead

remaining.

I think the current implementations for TRAP_Slot* are all wrong. Take a look at page 5 of the patent to see how complex the slot handling actually is. I have already expressed my concern in posting #220.

Referring to posting #220: Of course the hashing for slots still needs to be done. I have no information about how the slot-traps work on the inside, so I could only do what the snapshots showed, the 'security code' treatment hence is rudimentary. Never meant to create any other impression.

Apart from that, I noticed one more bug in TRAP_Aes:

#003977 TRAP_Aes               (001EFA90, 001EFA91, 00000002, 001EFAC0, FFF10000);
Register error at trap number 3977:
post_reg_snapshot:
00000000 80000001 80000001 0002282C 001EFA90 001EFAC0 0002282C 10010000
00000002 00063B24 00000000 0003EC44 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EFA6C 001EFAD8 00061B60
post_reg_execute:
00000000 00000000 80000001 0002282C 001EFA90 001EFAC0 0002282C 10010000
00000002 00063B24 00000000 0003EC44 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EFA6C 001EFAD8 00061B60
Byte 1EFA90: snapshot: 00 execute: D1
Byte 1EFA91: snapshot: 00 execute: 08
Byte 1EFA92: snapshot: 00 execute: 6A
Byte 1EFA93: snapshot: 00 execute: 97
...
Byte 1EFAAC: snapshot: 00 execute: 2B
Byte 1EFAAD: snapshot: 02 execute: 4A
Byte 1EFAAE: snapshot: 29 execute: 48
Byte 1EFAAF: snapshot: DC execute: 48
Memory Error at trap 3977

#003978 TRAP_Aes               (001EFA90, 001EFA9F, 00000002, 001EFAC0, FFF10000);
Register error at trap number 3978:
post_reg_snapshot:
00000000 80000001 80000001 0002282C 001EFA90 001EFAC0 0002282C 10010000
00000002 00063B24 00000000 0003EC44 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EFA6C 001EFAD8 00061BB4
post_reg_execute:
00000000 00000000 80000001 0002282C 001EFA90 001EFAC0 0002282C 10010000
00000002 00063B24 00000000 0003EC44 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000994B0 001EFA6C 001EFAD8 00061BB4
Byte 1EFA90: snapshot: 00 execute: 8E
Byte 1EFA91: snapshot: 00 execute: 59
Byte 1EFA92: snapshot: 00 execute: 9F
Byte 1EFA93: snapshot: 00 execute: B9
...
Byte 1EFAAC: snapshot: 00 execute: 0C
Byte 1EFAAD: snapshot: 02 execute: 1F
Byte 1EFAAE: snapshot: 29 execute: 51
Byte 1EFAAF: snapshot: DC execute: D3
Memory Error at trap 3978

The TRAP_Aes parameter checking should be fine now. I had forgotten to copy an important check from my notes
I am still not able to fix the checks for TRAP_SlotRead and TRAP_DeviceDiscovery though i made some observations. It's an illegal internal state which causes the failure of both calls. For TRAP_DeviceDiscovery i suggest we add a rule which lets the call fail if the "number of bytes written" pointer <len> points to a dword inside the output (which is written to <buf>). This has to be done on the trap implementation side because the interface (which does all the parameter checks) doesn't know the length of the output.

Regarding the slots i couldn't find any call of TRAP_SlotWrite which actually reads the data from <newContents>. Either all those calls i've checked have failed internally or the trap implementation of my player is wrong. I could see that slot 0 is read from non-volatile memory and that all 256 bytes are subsequently copied to the specified vm memory address.

Finally i suggest a command line interface for the debugger. The idea is to provide some basic commands to:
- set some environment variables (like where is the BDSVM or the snapshot directory)
- set/clear breakpoints (execution or data)
- execute n instructions or trap calls
- load a snapshot
- compare memory or register content with a snapshot
- dump or change parts of memory or registers
- record a instruction trace
- ...

All the snapshot stuff should be removed from the code. The user can run a script (maybe Tcl?) which does all the work.

Originally Posted by Accident

Oopho2ei:

I've been reading your forum, reminds me of the good old 8-bit days and the reverse engineering I did back then. Anyway, I know nothing of java at all, but I certainly know C, and assembler.All my sources are OpenSource, and I must admit it is very tempting, but I am not sure where to start, or if the reference docs that you have done (?) that I would need are easy to get/read/understand. I know DVD and CSS fairly well (..now) but BD is new.

You can find the most important facts here. A sample c(++) program is here.

The implementation consists of 3 basic steps:
1. implement the instruction processing (description of the instructions can be found here and search the web for the Hennessy and Patterson's DLX architecture)
2. trap processing (description of the traps can be found here, in the patent and in this thread)
3. event handling (still under research)
4. debugging (we use snapshots and traces from a licensed player which can be found here)

If you have any questions first look at this document and the patent. If you can't find an answer there post your question here.

There seems to be a new variant of BD+ out: http://forum.slysoft.com/showthread.php?t=21177

This is a nice oppurtunity for me to list the previous 'versions' (currently there are at least 65 titles which employ BD+):

1. The first version was on just the first twenty or so BD+ titles (such as "Day After Tomorrow", "Fantastic Four: Rise of the Silver Surfer" etc., maybe on all the titles released in 2007?). This version did not use TRAP_MediaSHAFileHash so that it was possible to first copy a disc to an image with AACS removed but BD+ still intact and then mount or burn this image and play it with a licensed player.
2. The second version of BD+ fixed this bug and used TRAP_MediaSHAFileHash to verify that the inserted disc still contained AACS (actually TRAP_MediaSHAFileHash just verifies that small parts of a few files on the disc have a hash which is identical to a hardcoded byte-sequence in the content code). Apart from that, there don't seem to be much differences between the first and the second version of BD+. This version appeared early in 2008 and was used till around the middle of 2008. (Maybe with a minor update around March 2008, I think I remember AnyDVDHD treatment of the BD+-version on "Hitman" to be problematic for a while.)
3. The next version of BD+ appeared in June 2008 (first title was "Jumper" - AnyDVDHD was not able to handle this for a while). I don't have much information about what may have changed with this version of BD+.
4. The newest 'version' just appeared a few days ago on "Die Another Day". Rather than it being a really new version of BD+, it seems to me as if this is just the first title with BD+ where the main feature is split across several files and not stuffed into one big file. This could become important when implementing the way in which the data is passed to the VM in execution of event 0x220.

It would be interesting to get more information about the newer versions of BD+, such as having a trace of trap-calls for a movie as new as or newer than e.g. "Jumper".

On another note, I am currently idle but willing to do more trap-analyzing whenever any snapshots or similar are handed to me The debugger may currently not run with correct memory contents to the first TRAP_Finished on it's own (because of the well known TRAP-SlotRead(*,ffffffff) problem). Otherwise, it would be possible to really start treating the event handling, since we could try and just feed any event to the VM (after it has initialized itself on it's own in the first ~2600 trap-calls) and see what happens.

It's really amazing how you and gioowe can read the hidden messages in those slysoft forum postings. When i look through my crystal ball at the posting i only see that he had chocolate cakes this morning and that his grandma is turning 80 next week. Maybe i need to look at the least significant bits of the fox image in the top left corner

Seriously we should focus on the correct implementation of all traps before we start anything new. When i started looking at events i was under the impression that the trap implementation is almost complete (e.g. with the details from the patent) and the code is in a good condition but i was really wrong. There is still a lot to be done.
I am currently looking at TRAP_SlotAttach and TRAP_SlotWrite will be next. In the meantime you should review the code and correct the short trap descriptions you can find in bdsvm_player_traps.java. I will upload new snapshots when i think it is appropriate.

This is a description of how TRAP_SlotAttach works. The example below is for the first call of TRAP_SlotAttach in "The Day After Tomorrow":

call: TRAP_SlotAttach( slot = ?, codeLen = 0x0000000C )
PC = 0001AC70h (already incremented)

That's the data which is hashed with SHA-1:

00 01 ac 6c 00 00 00 00                         ; PC-4 ( & 0x3FFFFC ) and instruction filter (IF)
6f bd 00 1c e0 3d 00 08 e3 fd 00 04 d4 20 00 00 ; 16 bytes from 0x1000
e4 00 04 10 58 1f 00 00 e4 00 04 20 58 1f 00 00 ; #codeLen dwords from PC-4
e4 00 04 30 58 1f 00 00 e4 00 02 30 58 1f 00 00 
e4 00 80 10 58 1f 00 00 e4 00 80 20 58 1f 00 00

The resulting SHA-1 hash:

h = 78f623b22178c6150c420a3bff949c85ae7f75bd

SHA-1 hash from hash:

h' = 3ac6e39ffddc1c66429aae0600c61bf0ec340d8a

This is the resulting hash to be compared against the hash stored in the slot. I have no idea why the hash is hashed again (makes no sense to me). The offset of the hash within the slot is probably 0x30. I couldn't reliably determine the beginning and the end of the slot so the address (0x30) is a good guess based on some assumptions.

Edit: the unknown dword is the instruction filter (IF)

[tteich]

Originally Posted by Oopho2ei

This is a description of how TRAP_SlotAttach works. The example below is for the first call of TRAP_SlotAttach in "The Day After Tomorrow":

call: TRAP_SlotAttach( slot = ?, codeLen = 0x0000000C )
PC = 0001AC70h (already incremented)

That's the data which is hashed with SHA-1:

00 01 ac 6c 00 00 00 00                         ; PC-4 ( & 0x3FFFFC ) and unknown dword
6f bd 00 1c e0 3d 00 08 e3 fd 00 04 d4 20 00 00 ; 16 bytes from 0x1000
e4 00 04 10 58 1f 00 00 e4 00 04 20 58 1f 00 00 ; #codeLen dwords from PC-4
e4 00 04 30 58 1f 00 00 e4 00 02 30 58 1f 00 00 
e4 00 80 10 58 1f 00 00 e4 00 80 20 58 1f 00 00

The resulting SHA-1 hash:

h = 78f623b22178c6150c420a3bff949c85ae7f75bd

SHA-1 hash from hash:

h' = 3ac6e39ffddc1c66429aae0600c61bf0ec340d8a

This is the resulting hash to be compared against the hash stored in the slot. I have no idea why the hash is hashed again (makes no sense to me). The offset of the hash within the slot is probably 0x30. I couldn't reliably determine the beginning and the end of the slot so the address (0x30) is a good guess based on some assumptions.

Perhaps they apply a Hash chain as authentication mechanism? http://en.wikipedia.org/wiki/Hash_chain

Originally Posted by tteich

Perhaps they apply a Hash chain as authentication mechanism? http://en.wikipedia.org/wiki/Hash_chain

I don't know how a valid slot looks like so it might be possible that h' wasn't compared against the hash from the slot but against the hash from the hash from the slot. So you could be right. It makes me wonder how the entire system looks like if there is an insecure channel between the slot memory and the BD+ core. Maybe the slot data is stored inside a smartcard? It would also mean that the content code can only successfully attach to this slot twice.

Some details about TRAP_SlotWrite:

TRAP_SlotWrite(UINT8 *newContents);

p = some address inside the player (volatile) memory

- copy 0x10 bytes from newContents+0x20 to p
- copy 0x14 bytes from newContents+0x30 to p+0x10
- copy 0xB4 bytes from newContents+0x4C to p+0x2C

So the data at

newContents+0x00 ... newContents+0x1F and 
newContents+0x44 ... newContents+0x4B

is ignored and could be reserved memory (eg. for the hash) inside the slot. Altogether it adds up to 256 which is supposed to be the size of a slot.

This is what i assume is the structure of a slot. The example data is from slot 0 (DAT).

Addr :                   Data                          - Description
-----------------------------------------------------------------------------------
0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Creator Media ID ?
0010 : 1d 2f c6 74 62 fd f9 86 35 7a 8f 80 8f a1 29 8b - Last Update Media ID ?
0020 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Slot Private Data ?
0030 : a9 78 8b 0b b2 8d e0 e1 3f 40 af de e9 a3 31 6b 25 3c fa 21 - Attach Authentication Hash
0044 : 00 00 00 00                                     - ?
0048 : 00 00 00 8e                                     - Last Update Sequence Counter ?
004C : d4 8e 75 57 c6 e6 0b 46 a7 14 60 99 46 ff 65 0d \
005C : fe e5 48 8a ee dd 48 ad dd 47 8d 1d 87 53 d7 04  |
006C : 59 5b 6d b1 57 b6 04 d9 aa 32 da c6 ff 9b fe 02  |
007C : 1f b2 1b 8e 5b 61 88 0d 85 8e 72 d1 5c c7 6f f2  |
008C : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  |
009C : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  } Data Payload (180 bytes)
00AC : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  |
00BC : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  |
00CC : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |
00DC : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |
00EC : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |
00FC : 00 00 00 00                                     /

Schluppo could you please start implementing the slot traps from the above notes so i can focus on research?

I changed TRAP-SlotAttach according to posting #230. For the first call in "DAT v1.02", this gives the same h' as in the posting, so it seems to be fine. Then the new code compares the 20 bytes that are h' with the 20 bytes starting at 0x30 in slot number <slot> (where <slot> is the first parameter of the trap). If they are equal, the global variable AttachedSlot is set to <slot> and STATUS_OK is returned, otherwise AttachedSlot is set to 0 and STATUS_INVALID_PARAMETER is returned.

About TRAP-SlotWrite: What does the trap do if there is no slot attached? And since you changed the default-value of AttachedSlot (meaning 'no slot attached') to 0, what happens, if slot 0 is supposed to be attached?

[tteich]

I found an interesting patent which explains a bit how the different .svm files are used: http://www.freepatentsonline.com/EP1841120.html

00000.svm seems to contain code common to all players, and is supposed to select a different (player dependent) xxxxx.svm for known players, or a common file for all unknown players. The selected file contains security checks and content scrambling code.

Originally Posted by schluppo

I changed TRAP-SlotAttach according to posting #230. For the first call in "DAT v1.02", this gives the same h' as in the posting, so it seems to be fine. Then the new code compares the 20 bytes that are h' with the 20 bytes starting at 0x30 in slot number <slot> (where <slot> is the first parameter of the trap). If they are equal, the global variable AttachedSlot is set to <slot> and STATUS_OK is returned, otherwise AttachedSlot is set to 0 and STATUS_INVALID_PARAMETER is returned.

Thanks. I have made some changes on your code. Could you please run your tests again and see if everything is still alright?

Originally Posted by schluppo

About TRAP-SlotWrite: What does the trap do if there is no slot attached? And since you changed the default-value of AttachedSlot (meaning 'no slot attached') to 0, what happens, if slot 0 is supposed to be attached?

I am trying to figure this out now.

Originally Posted by tteich

I found an interesting patent which explains a bit how the different .svm files are used

Thanks a lot. I think it explains even more. Look at page 40 (FIG. 11) of the pdf version. This is probably the player certificate which we get from TRAP_DeviceDiscovery with parameters dev = 1 (player?) and qID = 1 and 2. The first dword is the length which is obviously correct.

Edit: From this patent i can also tell that the 'S' in BDSVM stands for "Secure" (and not "Secret" like i thought).

Edit: FIG.5 (p.34) and FIG.6 (p.35) illustrate the event handling and the final correction of broken segments in the decrypted video and audio stream. The process is described starting with page 13. To see the differences in the output for "The Day After Tomorrow" look at posting #13.

Your changes are fine, as far as I can see.

Originally Posted by schluppo

Your changes are fine, as far as I can see.

Good!

Some scenarios which should give you an idea how the AttachedSlot mechanism works.

- the first trap which is executed is TRAP_SlotWrite:
  -> writes to slot 0

- slot 0 is attached ( TRAP_SlotAttach( 0, 4 ) finished successfully ):
  -> the following TRAP_SlotWrite writes to slot 0

- TRAP_SlotAttach( 0x1F3, 0c0C ) succeeded and the following trap "TRAP_SlotAttach( 0x1F3, 0c0C )" failed ( hash missmatch ):
  -> the following TRAP_SlotWrite writes to slot 0

- TRAP_SlotAttach( 0x1F3, 0c0C ) succeeded:
  -> TRAP_SlotWrite writes to slot 0x1F3
  -> another TRAP_SlotWrite does not write to slot 0 (so probably writes to slot 0x1F3 as well)
  -> the following TRAP_SlotRead calls read the contents of slots 0 (unchanged) and 0x1F3 correctly

If you need more information just ask.

Edit: As you might have noticed the (Creator/Last Update) Media ID in the Slot is the Volume ID. For "The Day After Tomorrow" it is 1D2FC67462FDF986357A8F808FA1298B.

Edit: i've added a new class to handle the slots. All changes can be viewed here as usual.

[Accident]

The DLX reference documentation mention that R0 is always set to 0 and any writes are ignored. Is this the case here as well, should I force R0 read-only?

Originally Posted by Accident

The DLX reference documentation mention that R0 is always set to 0 and any writes are ignored. Is this the case here as well, should I force R0 read-only?

Good question. All i know is that the licensed player i study has memory reserved for r00. I have placed a check in our java debugger to see if r00 has at any point a value different from zero but it seems this is never the case. So at least the compiler doesn't use it to store values. I suggest you output a warning when it's different from zero.

Some news about TRAP_SlotAttach and TRAP_SlotRead with parameter slot=0xFFFFFFFF. When TRAP_SlotRead is called with slot=0xFFFFFFFF it writes 3 dwords (DW0 DW1 DW2) to dst. DW1 and DW2 are two bytes B1 and B2 which were expanded to UINT32 and DW0 seems to be originally a 16 or 32 bit value. TRAP_SlotRead only seems to read and expand those values but TRAP_SlotAttach really changes them if called with slot = 0xFFFFFFFF which is supposed to be the way a new slot is allocated.

The output of TRAP_SlotRead before TRAP_SlotAttach (both with slot = 0xFFFFFFFF):

00000000 00000000 00000007

Looking at the source for DW0, DW1 and DW2 the following things happen now when TRAP_SlotAttach is called with slot = 0xFFFFFFFF:

if ( B2 > 2 )
{  
  B2 = B2 - 1;
}
B1 = B2;

Initially B1=0 and B2=7 so the result is B1=6 and B2=6. Also DW1 now contains a slot number. When TRAP_SlotRead is called now (with slot = 0xFFFFFFFF) the result is:

000001F2 00000006 00000006

When i try to read the slot 0x1F2 now with TRAP_SlotRead i get the output:

0000:0010 1d 2f c6 74 62 fd f9 86 35 7a 8f 80 8f a1 29 8b
0000:0010 1d 2f c6 74 62 fd f9 86 35 7a 8f 80 8f a1 29 8b
0000:0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0000:0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0000:0040 00 00 00 00 00 00 00 00 00 00 01 15 00 00 00 00 
0000:0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0000:0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0000:0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0000:0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So the TRAP_SlotAttach did create a new slot and attached it as well (otherwise we would get 256 zeros). The "Creator Media ID" (first 16 bytes) and the "Last Update Media ID" are both set to the AACS Volume ID. For some reason the "Last Update Sequence Counter" already contains a value 0x00000115.

Now when i again call TRAP_SlotAttach followed by a call of TRAP_SlotRead (both with slot=0xFFFFFFFF) i get the result:

000001F1 0000005 00000005

So from these observations i can tell that TRAP_SlotAttach really allocates a new slot when called with parameter slot = 0xFFFFFFFF. But TRAP_SlotRead does not read the currently attached slot when called with parameter slot = 0xFFFFFFFF as described in the patent. Instead it returns three dwords which seem to describe what slot is currently attached and how many slots have been allocated or still can be allocated . Or something similar

Edit: If attached successfully with TRAP_SlotAttach( 0x1F3, 4 ) then the output if TRAP_SlotRead( 0x100, 0xFFFFFFFF ) is:

000001F3 0000000 00000007

So this leaves now little doubt that the first dword always is the currently attached slot identifier.