This is the output of aacskeys for this movie:
Code:
MKBv: 4
Processing key: F190A1E8178D80643494394F8031D9C8
Encrypted C-value: 95247837F8A71FFDDBE8B0D3C2EE0575
Corresponding uv: 000000A0
Decrypted C-value: A174BE1DF3678FFCDBF8D43A7AF32B40
Media key: A174BE1DF3678FFCDBF8D43A7AF32BE0
Encrypted verification data: 810D5EE8B3011C4E8474E7702D12F55D
Decr verif data should be: 0123456789ABCDEF
Decrypted verification data: 0123456789ABCDEFD33493CD1DD12AC7
Drive FW info: 1.01
AGID: 00
Volume ID (AACSBYPASS): 1D2FC67462FDF986357A8F808FA1298B
Volume Unique Key: C5E868608ACD6700C2AC6A5E6AF533D9
Unit Key File Hash (DiscID): 6B63A40DD45F17A466B0C5CC35BF1500B4E0A9BA
Encrypted Unit Key 1: 6941CB89A6EEAB466AAB4B4F55DDA667
Decrypted Unit Key 1: 98E4D277F21AC464EFB0C0CA19FB50FD
I am posting this now because it's possible that some of these keys are used by the traps. It's unlikely that any of the important keys actually appear in memory though.
I have looked at the implementation of Trap_AES where the last parameter is a Key ID (in my particular case KeyID = 4). Like stated in the patent you have to first decrypt (aes-128-ecb) the encrypted aes key (pointed to by 4th parameter) using the player key and then use the resulting decrypted key to decrypt the data (second parameter) just like the last parameter were 0xFFF10001.
BUT the aes implementation doing the decryption of the key (first step) in my player has been transformed by some random mappings (different lookup tables basically) so the keys i could give you only work with the mapped aes version. Either i can figure out how to reverse the transformation or we have to use the mapped aes version for which i would provide a sample implementation in C. In the meantime you can play around with the keys above. Maybe it's one of them.
Quote:
Originally Posted by bmnot
|
Another great release. Thanks a lot!