grack.com

Blog

HDCP Conspiracy Attack

After reading up on Prof. Felton’s description of the major HDCP weakness and reading the paper he referenced, I cooked up a small proof-of-concept conspiracy attack for HDCP in Java.

It turns out that you can trivially solve for a private system key by solving for the simple case of public keys that look like this (for a four-length array system):

[1 0 0 0]
[0 1 0 0]
[0 0 1 0]
[0 0 0 1]

This yields a symmetric matrix that can be used to generate any private key given any public key in milliseconds. The code implements this in HdcpKeyGenerator.

So, all you need to do to start generating your own codes is:

HdcpSystem system = new HdcpSystem(4); // key size
Conspiracy conspiracy = new Conspiracy( system, /* the keys */ );
HdcpKeyGenerator gen = conspiracy.solveForKeyGenerator();

gen.createDevice(new PublicKey(system, /* public key */));

Here’s a solvable system you can use to trace through things by hand:

 Secret Key         Public Key
 [ 26, 19, 12, 7 ]  [ 1 2 ]
 [ 13, 13, 22, 5 ]  [ 2 4 ]
 [ 22, 16, 5, 19 ]  [ 1 3 ]
 [ 12, 19, 9, 16 ]  [ 2 3 ]

The symmetric “solution” matrix for the key generator is:

 Secret Key       
 [ 18, 8, 4, 5 ]  
 [ 8, 11, 8, 2 ]  
 [ 4, 8, 1, 14 ]  
 [ 5, 2, 14, 3 ]  

To solve for any key, just add up the number in the columns that correspond to the public key. The first row is the first number, second row is the second number, etc. For the public key [ 1 2 ], we get [ 18+8, 8+11, 4+8, 5+2 ] == [ 26, 19, 12, 7 ], the same result as the input we used to generate this matrix (as you would expect).

The documentation is in the unit tests themselves. I recommend unzipping this project and opening it with Eclipse to check out and run the unit tests.

Download: hdcp.zip

Not Dead Yet

No, I’m not dead. Having a baby just sucks the energy out of you to do anything besides looking after the baby.

In other news, Everett was born on March 1 and he’s getting pretty big now!

Treo 650 Memory Management

Just a quick overview of what memory looks like on the Treo 650. Note that there is 32MB of non-volatile storage (the disk-on-chip flash) and 32MB of volatile SDRAM (lost on reset/power down).

Disk-on-chip (“non-volatile” storage):

32MB 1
ROM Partition 2
(anywhere from 7-10MB)
NVFS Partition
(remainder of space)

RAM (volatile storage):

32MB
Uncompressed ROM 3
(11MB-15MB)
Dynamic RAM
(approx. 5.3MB)
DBCache
(remainder of space)

Notes

  1. In reality this isn’t really 32MB, as 512kB is allocated for the SPL and some of the space may be allocated for bad block reassignment.

  2. The ROM partition contains the TPL, SPL, HTC bootloader and the ROM zip.

  3. Note that the uncompressed ROM size may exclude alternate languages in any ROMs with a language selection (via the LLid token).

How to roughly calculate DBCache

The formula is pretty easy:

32MB – 5.3MB (dynamic RAM) – Uncompressed ROM size = DBCache

If you have more than one language in your ROM, you can exclude the unused language files from the uncompressed ROM size.

Treo Linux GPE

Luke has posted instructions on getting GPE working with the Treo 650:

This is about as simple as it gets right now to build and load a gpe image. The assumption is that you know enough about Linux to compile a custom kernel for your dist and that you can complete tasks like making a filesystem on an SD card.

Screenshots: