Finally handling BD+ (?)

• Some info about trap return values: So far, I have only observed the return values 0x0 (STATUS_OK), 0x80000001 (EXECUTION_ERROR?) and 0x80000002 (BAD_PARAMETERS?). I never saw any trap returning its value in another register than in R1. Only trap 0x110 is changing PC and WD, the other traps don't change any machine data besides memory and R1. And there are some traps which don't return anything (trap 0x10, 0x230). This last thing still needs to be handled correctly at the end of trap execution (easy to do).
• And here's some information about TRAP_PrivateKey, taken from the patent (in case you didn't read it yet ): " For the player's main RSA private key (keyID=0), this operation produces a 2048-bit RSA signature of a SHA-1 hash. The hash is computed as follows: (a) hashing the value of srcLen, encoded as 4 bytes (MSB first); (b) hashing the contents of the user-specified buffer (i.e., srcLen bytes at src); (c) hashing the value of controlWord, encoded as 4 bytes (MSB first); (d) If controlWord bit 31 (the MSB) is set, hashing the value of the media ID; (e) If controlWord bit 30 is set, setting the destination pointer to PC+4, overriding dst; (f) if controlWord bit 29 is set, hashing the (control word mod 2.sup.16) code bytes beginning with the current program counter; then (g) if controlWord bit 28 is set, incorporating the current value of PC in the hash. The SHA-1 hash result is then padded by prepending "0x001.parallel.0x01.parallel.0xFF (repeated 233 times).parallel.00" to the SHA-1 hash. The padded value is then raised to the player's secret exponent, modulo the player's public modulus. "

Thanks.

TRAP_PrivateKey: I was able to trace both the obfuscated key (~ 96 byte) and the hash result to the heavily obfuscated code (virtualized, lot's of garbage,...). Not sure if i can do it. You would probably kill me if i convert this mess to c code.

Looks like i have to record a instruction trace and then somehow analyze it automatically. I need to think about it.

Edit: Any idea of how the result of TRAP_PrivateKey is verified? It's obviously a 320-bit signature which is probably not created by the RSA algorithm. The footer of every section of in the 0000?.svm files is 40 bytes long too. Note that the signatures used in the AACS authentication process are 40 bytes long as well. The way the result of of TRAP_PrivateKey is verified would give us a vital clue of what algorithm created the signature.

Edit: When the hash is all zero the resulting signature is also all zero. If i overwrite the key with zeros i get stack overflows (wtf?)

Actually, until trap-call ~5000, this trap is called just once with real parameters (for both movies). All other calls of this trap have bogus parameters and return 0x80000001.

And for this one real call, the program directly calls DeviceDiscovery(1,3) afterwards. The 40 bytes which are written by this call of TRAP_PrivateKey are (according to 'data read breakpoint' of the debugger) not accessed in the next 20 million instructions. Furthermore, before overwriting the register which is holding the adress of these 40 bytes, the progam writes this same adress to two places in memory which are also not accessed in the next 20 million instructions. So to me it seems as if this result is not verified at all (or maybe way later in the BD+ initialization).

I will try and check a bit more, whether I can find any code accessing the 40 bytes.

Just like i expected: the unknown algorithm produces different results for the same hash (and the same key). It furthermore always produces a signature consisting entirely of zeros (wtf?) when the input hash is all zero. So now it is even more likely that it's some elliptic-curve signature algorithm like the one used in AACS. I now need to find the third (random) parameter...

Originally Posted by schluppo

The 40 bytes which are written by this call of TRAP_PrivateKey are (according to 'data read breakpoint' of the debugger) not accessed in the next 20 million instructions.

Do the data read breakpoints work reliable yet? Maybe they are cleared when a new snapshot is loaded? Or maybe the result (40 bytes) is not accessed by the content code (instructions) and instead another trap call reads them? There must be a check somewhere...

I was told the first byte from Trap_PrivateKey(...) is accessed by instruction "C8440000h" at address "091A98h" (this is instruction number 6585958). So there must be a problem with the data breakpoints of the debugger.

Hm, if I find some time, I will look into the breakpoint-system of the debugger.

On another note, some info on trap 0x550: It is not called in "DAT" v1.02, but it is called three times in "I Robot" v1.02.

It takes as first parameter a pointer to these strings:
1) "BDSVM/00002.svm"
2) "AACS/MKB_RO.inf"
3) "BDMV/STREAM/000012.mts"
The second parameter is the length of this string.

Parameter three holds 0x00, 0x00 and 0x05. Fourth parameter is either 0x00 or a big value (>0x3FFFFFF) - this is not a pointer, but four bytes of data.

The fifth parameter is a pointer to 0x200. The sixth parameter is the destination pointer (this trap seems to always write 20 bytes).

I assume this trap is computing some kind of hash of the file. Could be CRC or SHA, my bet is on SHA since that outputs 20 bytes anyway. The values in parameters three, four and five should be additional inputs to this hashing algorithm.

According to your description Trap#0550 would be something like:

UINT32 TRAP_MediaHashFile(UINT8 *FileName, UINT32 FileNameLen, UINT32 Unknown, UINT32 Unknown, UINT32 *len, UINT8 *dst);

When you look at the parameter checking you will see that it doesn't always produce 20 bytes. Instead it writes 20 * ( mem[len] / 0x200 ) bytes. Also the filename/path length may not exceed 1024 (!) bytes.
One of the two unknown parameters could be a file offset.

schluppo: could you please fix the data breakpoint problem? I need the value of n for testing (see ECDSA).

Edit: Someone gave me a hint how to fix the problem with the data breakpoints. I have pushed the fix in the repository.

I currently don't have the curve parameters (and therefor can't present a real example) but i don't want to withhold anything. The signature is created with ECDSA and consists of two 20 byte long numbers: r followed by s. How the signing process works is explained here.

You can forge signatures without the curve parameters simply by using a fixed point on the curve all the time which means your random number k and r (first 20 bytes) are constants.

So these are all the constants you need:

r   = 7c7d84d310c42436daff10af116f80448dc3f88b
k   = 7AA9A10C3E90AA8FDAF34DD28F665D3C609CACD7
d_A = 735E0356EA6356E099AD83152E2D81EA1164A866 (keyID == 0)
n   = 96609d9e935e52c683dafdc49216143f9a24373d

That's the only variable - our message hash we have to create a valid signature for (see posting #178 about how this is calculated):

e = 1111111111111111111111111111111111111111

so now you calculate s: s = 1/k * (e + r * d_A) mod n

The result is:

s = 532b4944f80565075ea9b8894e61c692ed71f3c8

Edit: this is arithmetic over a finite field with the numbers 0,1,2,...,n-1. Any other number (negative, fraction,...) doesn't exist.

Edit: you need the extended euclidean algorithm to calculate 1/k. The result is "1/k = 210974BC85725B5FB0E04FA473FD988001F89088h". So simply multiply with that value.

Edit: There were problems with the previous values so this is a new example and a new private key. It has been tested and should work fine.

Edit: If you the signature verification fails then TRAP_DeviceDiscovery will be called instead of TRAP_Aes after TRAP_PrivateKey (first call of TRAP_PrivateKey in DAT v1.02)

Edit: That's the second private key:

d_A = 87E22D06A699EE311CD73F19B91E67414C44F4F5 (keyID == 1)

It's the same curve (same parameters) so you can use the same (k,r) pair.

Edit: We have found the remaining curve parameters:

q   = 96609D9E935E52C683DBFC3A7D783EA942BDE8CB
a   = 96609D9E935E52C683DBFC3A7D783EA942BDE8C8 = -3 (mod q)
b   = 3E567D8DEC27873BCF86F5FBB595DB288C62C721
x_G = 05FC5B0B2360AC50A76E1511BC5C9AF67A004D0D
y_G = 09B0D43F319B09A5B679CCF264E1ABA4D56594EA

The corresponding public key for keyID == 0 (can be calculated from above values):

x_Q = 31dbb17fea9d7d0eb8bfbb6b8d29ac938c13b599
y_Q = 2465dd38f4214edee4da4e7f62b77a41ce962757

The corresponding public key for keyID == 1 (can be calculated from above values):

x_Q = 57305D64D1013FFFA4D72355B4C70B27A815A343
y_Q = 05E22B42F88A5C1AC5E70DF466353BDB0A83228A

Great job everyone!

Regarding Trap#0550 i was told that the fourth parameter is the file offset and that this trap really calculates the SHA-1 hash.

UINT32 TRAP_MediaHashFile(UINT8 *FileName, UINT32 FileNameLen, UINT32 FileOffsetHigh, UINT32 FileOffsetLow, UINT32 *len, UINT8 *dst);

It works fine unless the third parameter (still unknown) is not zero but 5. We don't know what this means yet. Maybe only every fifth block of the file is hashed. Or maybe a block larger than 512 bytes (5*512 bytes) is hashed and results in a 20 byte SHA-1 hash. This still has to be figured out...

Edit: The file offset is 64 bit (FileOffsetHigh << 32 | FileOffsetLow). A 32 bit address is too small for those large files (00001.m2ts is > 20GB).

Edit: TRAP_MediaHashFile is fully analyzed now and i have updated the documentation in svn

Edit: We need proper names for Trap#0540 and Trap#0550. In alphabetical order name(Trap#0540) has to stand before name(Trap#0550) which is currently not true:

name(Trap#0540) = TRAP_MediaReadFile <-- maybe change in TRAP_MediaFileRead ?
name(Trap#0550) = TRAP_MediaHashFile <-- or maybe change this in TRAP_MediaSHA1HashFile

Suggestions?

Edit: The naming issue is solved. The "official" name for Trap#0550 is TRAP_MediaSHAFileHash

Great work on TRAP_PrivateKey!

Trap 0x550 is implemented now. Works fine (for the two files that I have ).

I named it 'trapMediaHashFile' in my code but do not care about the name actually. Just change it to whatever you think is appropriate.

trap 0x320 is trapMemSearch, will implement it soon.

is it possible to code trapPrivateKey yet or should I wait until you posted some more examples / parameters?

Only big thing remaining now is trap 0x530 aka DiscoveryRAM. This is called around 500 times, taking memory from lots of different areas of the player's RAM. Maybe we need a memory dump and let the trap-emulation read from that dump-file or something like that. I checked a few example trap-calls with identical parameters and did not see differing results. Maybe this trap is just asking for areas of the RAM which are constant throughout execution?

Originally Posted by schluppo

trap 0x320 is trapMemSearch, will implement it soon.

Are the parameters identical to the TRAP_MemSearch() in the patent?

Originally Posted by schluppo

is it possible to code trapPrivateKey yet or should I wait until you posted some more examples / parameters?

You can start to implement it now. I am currently looking at events. The area 0x000-0xFFF seems to be used for passing events after the content code signals it's readiness to the player with Trap_Finished().

Originally Posted by schluppo

Only big thing remaining now is trap 0x530 aka DiscoveryRAM. This is called around 500 times, taking memory from lots of different areas of the player's RAM. Maybe we need a memory dump and let the trap-emulation read from that dump-file or something like that. I checked a few example trap-calls with identical parameters and did not see differing results. Maybe this trap is just asking for areas of the RAM which are constant throughout execution?

If you need to know where this data comes from i will look at this trap.

It's like this:

trapMemSearch(UINT8 *Region, UINT32 RegionLen, UINT8 *SearchData, UINT32 SearchDataLen, UINT8 *Dst)

I will be gone for a few days now. But I will try to implement 0x320 and fix 0x140 and 0x520 in the meantime.

Originally Posted by schluppo

It's like this:

trapMemSearch(UINT8 *Region, UINT32 RegionLen, UINT8 *SearchData, UINT32 SearchDataLen, UINT8 *Dst)

Thanks. I assume at "dst" a pointer to the first match is stored? Also it can't be "UINT8 *Dst" because of:

if ( Dst & 0x03 != 0 ) return 0x80000001

One of our anonymous contributers has suggest to use a optimized format for our snapshots. Instead of always storing the full snapshot only the differences to the previous snapshot are saved. This saves a large amount of disc space and probably also speeds up execution because the harddrive is currently the bottleneck.
The implementation would look like this: you load the first snapshot and compare as usual and continue execution but keep the last snapshot in memory. For the next snapshot you use the previous snapshot (saved in memory) and the difference to the previous snapshot (which is stored on disc now).
A sample implementation of how to handle the "differential snapshots" is given here

I have updated the trap documentation of TRAP_Memsearch and made some minor changes to wbaes.

Also what traps actually return a value (write to r01)? According to the documentation most of them return "UINT32". I was only guessing. Has anyone verified that?

Edit: All traps for which the parameters are checked return a value. I have corrected the documentation and also renamed Trap#0550. The "official" name is now TRAP_MediaSHAFileHash. Thanks again to our anonymous contributers

Now that the instruction processing seems to work without problems and only very few traps still have to be explored it is time to start looking at events. The event passing and handling will be quite a challenge not only because it's barely documented but also because events are somewhat nondeterministic. It should also be the last thing left to do.

These are some useful informations which are given by the pdf:

• The interface defines 9 callbacks (Events), which devices may invoke to notify content code of outside events, or to request specific actions
• examples for possible events are successful media reads/writes, shutdown or media eject events, player security operations and idle events sent with each frame displayed
• Event data is provided to content code in the Event Parameter area, which is a section of memory designated by content code.
• response values are returned to the device via the same area

Observations of event handling we have already made:

• at the end of the initialization phase the content code seems to signal the player it's readiness to process events with Trap_Finished()
• after the execution of Trap_Finished() the watchdog counter is set (and after a break reset) to 0xFA0 so execution is interrupted in very short intervals (4000 DLX clock cycles)
• the regular interruption of content code execution is used to check for events
• if an event occurred and the execution is interrupted (watchdog reached <= 0) the following things happen:
  • parts of the memory space 0x000000-0x000FFF (that possibly is or very likely contains the "Event Parameter area") are modified
  • the program counter is set to 0x1000 (always?) after a copy of it's current value is stored in r28
  • the watchdog counter is reset to 0x7FFFFFFF which stops the regular interruption now that the content code is already processing an event
• if no event occurred then only the watchdog counter is reset (to 0xFA0) and execution resumes normally
• on the next call of Trap_Finished the following things happen:
  • the program counter is restored from r28
  • the watchdog counter is set (and after a break reset) to 0xFA0
  • this call likely signals the completion of the event processing to the player so the player will probably read the designated memory area 0x000000-0x000FFF to fetch the requested results
• the memory space 0x000000-0x00003F seem to be special and is likely to hold meta data like parameters or the event id.

A great deal of the above observations were made by our anonymous contributers.

I would like to introduce a new snapshot file format for our event analysis. The structure is shown below:

 struct 
 {
    uint32 pc;
    uint32 if;
    uint32 regs[32];
    uint32 event_area[1024];
} snapshot_t

struct 
{
    snapshot_t snapshot0
    snapshot_t snapshot1
 } event_snapshot_file_t

Each file contains two snapshots: one snapshot before and one after the interruption of instruction processing (due to watchdog <= 0). All files which contain two identical snapshots are discarded. The remaining files are left for analysis.
As you can see each snapshot contains the program counter, the instruction filter, all 32 registers and most importantly the first 1000h bytes of vm memory (address space 0x000000-0x000FFF). The filenames have the format "epa_diff_%06d.bin".
You can write a program which analyses all the differences made by the player in the dedicated memory space (Event Parameter area) and finally creates a list/summary of all changes. Aim is to identify the section where the event id and the event parameters are stored and to create a list of all event types.

A snapshot package of that kind will be available soon.

Edit: This is a sample package: http://uploaded.to/?id=rfr3ew

Edit: That's the event snapshot package i have promised you: http://uploaded.to/?id=6ca19v

It seems every time i fast forwards or rewind a event is created. During the movie playback i have noticed about every 30s a new event.

There are still some other minor issues apart from event passing/handling. For example there is still no exception handling for cases like "division by zero", "arithmetic overflow" etc. The literature says a trap call would handle the exception but in the case of BD+ they seem to have defined the result of a division (both signed and unsigned) by zero to be zero. I had expected that our debugger would crash in this case but it didn't. Instead a message box with the text "/ by zero" is displayed.

I will look at the other cases soon and upload a list to the repository.

Edit: the documentation can be found here

I have looked at the remaining Traps #0020 and #0530 (TRAP_DiscoveryRAM).

Trap#0020 has two parameters which are both vm memory addresses from which the player is reading a lot of data. I don't know what is done with the data yet. This is probably related to TRAP_Finished because both traps are in the same group. We still need a name for this trap which fits in alphabetically between TRAP_Finished and TRAP_MediaReadFile.

For TRAP_DiscoveryRAM the player fills a section of memory with some pattern and then loads the data which the content code is expecting from different places and thereby overwrites parts of the pattern again. I don't know if the pattern is really needed or just some sort of vendor specific countermeasure against memory analysis by malicious content code. The memory organization can be found here (work in progress)

Implementation of trap_0x320 (TRAP_MemSearch) finished, works fine (for the few examples).
The title's VolumeID is now taken from a file called "volume_id.bin" which has to be in the same dir as the .jar. When trap_0x520(..,..,1,3) (TRAP_DeviceDiscovery) is called, the VolumeID is inserted into the result. Works fine for the two movies.

Things to code / fix:

- trap_20 (TRAP_EventGet??) is still untreated.
- trap_120 (TRAP_PrivateKey) is still untreated.
- trap_140 (TRAP_Sha) intermediate results are still wrong. I will fix this soon.
- trap_510 (TRAP_DeviceAccess?) is still untreated - there are just two calls of this trap in the 5000 snapshots for both movies. They both don't change memory.
- trap_520 (TRAP_DeviceDiscovery) - for parameters 1,3 there needs to be a timestamp in the result. Currently the timestamp is static, I will fix this soon.
- trap_530 (TRAP_DiscoveryRAM) - is still untreated, I am planning to look at this later today.
- trap_560 (TRAP_RunNative?) - there are no example calls for this yet.

Will upload new sources to the repository later today.

Edit: They are in the repository now. Also contain a try at TRAP_PrivateKey. Up to the end of the SHA-part, it works fine. Feel free to bugfix

Edit2: Timestamp added to the result of TRAP_DeviceDiscovery(...,...,1,3); Should be fine now.

Edit3: TRAP_DiscoveryRAM is now reading <len> bytes from a file called "RAM.bin", starting at <offset>. It then writes this data to <pDst>. It would be convenient to have a player memory-dump of the first 4mb to read from. Since that's probably not possible, I am working on a different solution now.

Originally Posted by schluppo

trap_20 (TRAP_EventGet??) is still untreated

I was told that there is no TRAP_EventGet (see posting #145). The event passing is likely done via a dedicated memory area (probably 0x000000-0x000FFF). The implementation of this trap is a bit strange. Some details can be found in posting #197

Originally Posted by schluppo

- trap_120 (TRAP_PrivateKey) is still untreated.

We are still trying to figure out the curve parameters but i was told it works fine with the fixed (k,r) pair from posting #188.

Originally Posted by schluppo

- trap_520 (TRAP_DeviceDiscovery) - for parameters 1,3 there needs to be a timestamp in the result. Currently the timestamp is static, I will fix this soon.

I was told that TRAP_DeviceDiscovery needs player specific keys too. Do you see some kind of signature in the output of this trap? Or is it just the timestamp which is different? Otherwise it's likely that the public key (used by the content code to verify the signature created by TRAP_PrivateKey) can be found somewhere in the output of the trap. I was able to see that two different keys were accessed for qID == 1 and qID == 2 but no key seems to be necessary for qID == 3. Sadly i didn't check if those keys were really used somewhere.

Originally Posted by schluppo

- trap_560 (TRAP_RunNative?) - there are no example calls for this yet.

And i hope there won't be an example.

Originally Posted by schluppo

Will upload new sources to the repository later today.

Have a look here to see what i changed to make the data breakpoints work. Please only upload the source code (*.java files) to the repository because we have only 200MB disc space and all revisions are stored. When you upload a snapshot (to uploaded.to or whatever) could you please include a description of what files have to be present and in which directory? The output of "find *" will probably be enough.

There are no updates visible in the repository for the latest changes you announced. Also for some reason you have deleted all sources in revision 48 and added new sources in revision 49 and 50. One revision later (51) you have finally added the description of what files are needed.

The result (revision 51) is correct but the way you work with the repository (it's not a ftp server!) has to be improved. First of all to upload your latest changes you need a single simple command:

svn commit -m 'this is a little description of what i have changed'

This command compares your source with the current (locally stored) snapshot of the repository and analyses the lines of code you have changed. It creates a patch (like this one) which it tries to apply to the real repository on the assembla server (which might have changed because other people applied their changes in the meantime). When you delete one of the source files from the repository and upload your own version you destroy the work of other people which have made updates to the files in the meantime. You should commit your changes every time you made an important change which leads to a still working implementation.

Originally Posted by schluppo

Feel free to bugfix

I think people are discouraged from doing that because the latest version of the repository is already outdated (you have made other changes):

Originally Posted by schluppo

Edit2: Timestamp added to the result of TRAP_DeviceDiscovery(...,...,1,3); Should be fine now.

Originally Posted by schluppo

Edit3: TRAP_DiscoveryRAM is now reading <len> bytes from a file called "RAM.bin", starting at <offset>. It then writes this data to <pDst>. It would be convenient to have a player memory-dump of the first 4mb to read from. Since that's probably not possible, I am working on a different solution now.

In posting #197 i've tried to explain that TRAP_DiscoveryRAM doesn't read parts of memory (security problems (access to secret keys etc) -> data would have to be relocated -> other player threads which access the previous address in the meantime might crash ....) instead depending on the address the data the content code expects is fetched from different places to build the requested section of player memory. This could be called "reading the virtual player memory".

Also you don't have to edit the postings to announce your changes. People can read the latest changes here.

Anyway thanks for your work and the updates.

Edit: i make daily backups of TRAC and SNV so we can quickly move if necessary. But reverse engineering for interoperability (bd+ for linux) is normally considered legal so i doubt there will be any problems.