Doom9's Forum - View Single Post

22nd September 2008, 18:13

I was using the old version of "Day after Tomorrow" with the 5000 snapshots in 5 big packages. Apart from the AES-Traps which are using player keys (especially TRAP_AES(..,..,..,..,0)) and apart from TRAP_Random which should produce random numbers, the first 1600 of those snapshots are identical to the memory after execution of the coded treatment of those traps. Anyway, I'm extracting v1.02 of both movies now and will look at them soon in order to improve the treatment of traps.

Further, trap 0x120 could have any other name, I have no observation telling me for sure, that it's "Trap_PrivateKey". I was just using that name since it's in the trap-list at this position.

Also, a thing about trap 0x410: I'm not sure wether this really is TRAP-SlotAttach, since that should have three parameters, according to the patent. Until now, I found just one call of trap 0x410:

Code:

trap 1002 at ic 6732573 is trap_410(0x1f3,0xc)			// slot-attach(499,12)?
returns 0x80000001

Notice, that I think, that 0x800000001 is the 'error' return status number.

Later, the program tries to read from this slot 499 (just receiving 256 times 0x00 and returning 0x0 in R1) and afterwards tries to write to slot 499 (returning 0x0 in R1 indicating successfull execution of the write-process?).

Maybe BD+ is using a more simple variant of this trap without security code / hash.

Edit: I compared the behaviour of the traps in the old snapshot-pack (the one with the 5 big archives) and the new v1.02 (both packs are for the movie "Day After Tomorrow"). Here is a list of traps with different behaviour in the first 1600 trap-calls:

Code:

 TRAP_DeviceDiscovery(1,3,4514,1eff84)				- qID #3: ~5 bytes difference due to timestamp
 TRAP_120(0, 0x5514, 0x2348, 0x10, 0) (TRAP_PrivateKey?)	- all 40 bytes of the result are different
 TRAP-SlotRead(0x1efb14,0)					- 32 bytes different content in slot 0

The other trap-calls behave in exactly the same way as before (apart from TRAP_Random of course).

Edit2: For "I Robot", there's the following problematic traps:

Code:

 TRAP_DeviceDiscovery(1,3): ~5 bytes difference due to timestamp and 16 bytes difference since the Volume-ID of this BD is different.
  I will implement this soon (we need a text file (or so) input anyway, containing all the keys needed to emulate the traps).
 The AES-Trap behaves badly - as expected (we still need a way to emulate AES-decryption using player-keys).
 TRAP_120(0, 0x54F0, 0x2348, 0x10, 0): all 40 bytes of the result are different.
 At IC 2123976, trap_0x550(0x7F868,0xF,0,0x13FFE00,0x3DFCC8,0x7F850) writes 20 bytes to 0x7F850 and returns 0x0 in R1. Don't know what this trap could be.
  Another call of this: trap_0x550(0x81FBC,0xF,0,0,0x3DFC0C,0x3DFC10) writes 20 bytes to 0x3DFC10 and returns 0x0 in R1.
  One more call writing 20 bytes to the last parameter and returning 0x0 in R1: trap_0x550(0x3D5E8,0x16,5,0x27123800,0x3DFC00,0x3DFC04)
 TRAP-SlotRead(xx,0): 68 bytes different content in slot 0.

Edit 3:
For trap 0x120 (TRAP_PrivateKey?), I found the following: It's second parameter is a pointer <pDst> where the result is going to be put. It's third parameter is a pointer <pSrc> to the input of this trap. It's fourth parameter <source_len> is the length of this input (this input is 0xFF-terminated). Further, this trap seems to behave non-deterministic.

I would guess, it is indeed TRAP_PrivateKey, just because the parameters are so close to what they should be. Imagine we have controlWord=0 and keyID=0 (indicating the case where this trap produces a signature of it's input, using a private key), then a call of this trap looks similar to the specification of the trap in the patent text:

Code:

trap_120(0, <pDst>, <pSrc>, <source_len>, 0)

vs.

Code:

TRAP_PrivateKey(UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 controlWord, UINT32 keyID);

Furthermore, the patent mentions, that the keyID is "normally" 0 for TRAP_PrivateKey, and in every call of trap_120 that I have seen so far, the first and last parameter were 0.

However, the patent also says, that for keyID=0, the result of TRAP_PrivateKey will be a "2048-bit RSA-Signature". I guess that means 256 bytes of result, but trap_120 just produces 40 bytes of result.

22nd September 2008, 18:13	#157 \| Link
schluppo Guest Posts: n/a	I was using the old version of "Day after Tomorrow" with the 5000 snapshots in 5 big packages. Apart from the AES-Traps which are using player keys (especially TRAP_AES(..,..,..,..,0)) and apart from TRAP_Random which should produce random numbers, the first 1600 of those snapshots are identical to the memory after execution of the coded treatment of those traps. Anyway, I'm extracting v1.02 of both movies now and will look at them soon in order to improve the treatment of traps. Further, trap 0x120 could have any other name, I have no observation telling me for sure, that it's "Trap_PrivateKey". I was just using that name since it's in the trap-list at this position. Also, a thing about trap 0x410: I'm not sure wether this really is TRAP-SlotAttach, since that should have three parameters, according to the patent. Until now, I found just one call of trap 0x410: Code: trap 1002 at ic 6732573 is trap_410(0x1f3,0xc) // slot-attach(499,12)? returns 0x80000001 Notice, that I think, that 0x800000001 is the 'error' return status number. Later, the program tries to read from this slot 499 (just receiving 256 times 0x00 and returning 0x0 in R1) and afterwards tries to write to slot 499 (returning 0x0 in R1 indicating successfull execution of the write-process?). Maybe BD+ is using a more simple variant of this trap without security code / hash. Edit: I compared the behaviour of the traps in the old snapshot-pack (the one with the 5 big archives) and the new v1.02 (both packs are for the movie "Day After Tomorrow"). Here is a list of traps with different behaviour in the first 1600 trap-calls: Code: TRAP_DeviceDiscovery(1,3,4514,1eff84) - qID #3: ~5 bytes difference due to timestamp TRAP_120(0, 0x5514, 0x2348, 0x10, 0) (TRAP_PrivateKey?) - all 40 bytes of the result are different TRAP-SlotRead(0x1efb14,0) - 32 bytes different content in slot 0 The other trap-calls behave in exactly the same way as before (apart from TRAP_Random of course). Edit2: For "I Robot", there's the following problematic traps: Code: TRAP_DeviceDiscovery(1,3): ~5 bytes difference due to timestamp and 16 bytes difference since the Volume-ID of this BD is different. I will implement this soon (we need a text file (or so) input anyway, containing all the keys needed to emulate the traps). The AES-Trap behaves badly - as expected (we still need a way to emulate AES-decryption using player-keys). TRAP_120(0, 0x54F0, 0x2348, 0x10, 0): all 40 bytes of the result are different. At IC 2123976, trap_0x550(0x7F868,0xF,0,0x13FFE00,0x3DFCC8,0x7F850) writes 20 bytes to 0x7F850 and returns 0x0 in R1. Don't know what this trap could be. Another call of this: trap_0x550(0x81FBC,0xF,0,0,0x3DFC0C,0x3DFC10) writes 20 bytes to 0x3DFC10 and returns 0x0 in R1. One more call writing 20 bytes to the last parameter and returning 0x0 in R1: trap_0x550(0x3D5E8,0x16,5,0x27123800,0x3DFC00,0x3DFC04) TRAP-SlotRead(xx,0): 68 bytes different content in slot 0. Edit 3: For trap 0x120 (TRAP_PrivateKey?), I found the following: It's second parameter is a pointer <pDst> where the result is going to be put. It's third parameter is a pointer <pSrc> to the input of this trap. It's fourth parameter <source_len> is the length of this input (this input is 0xFF-terminated). Further, this trap seems to behave non-deterministic. I would guess, it is indeed TRAP_PrivateKey, just because the parameters are so close to what they should be. Imagine we have controlWord=0 and keyID=0 (indicating the case where this trap produces a signature of it's input, using a private key), then a call of this trap looks similar to the specification of the trap in the patent text: Code: trap_120(0, <pDst>, <pSrc>, <source_len>, 0) vs. Code: TRAP_PrivateKey(UINT8 dst, UINT8 src, UINT32 srcLen, UINT32 controlWord, UINT32 keyID); Furthermore, the patent mentions, that the keyID is "normally" 0 for TRAP_PrivateKey, and in every call of trap_120 that I have seen so far, the first and last parameter were 0. However, the patent also says, that for keyID=0, the result of TRAP_PrivateKey will be a "2048-bit RSA-Signature". I guess that means 256 bytes of result, but trap_120 just produces 40 bytes of result. Last edited by schluppo; 22nd September 2008 at 22:57.