Beta Offline decryption utility

[EEPhil]

Don't recall how I found it, but:

Thanks, but It'll take me longer to decipher the pages I can access than it would to crack the keys .

 

[Black Hole]

On the face of it (not going into the nitty-gritty), I didn't find the concept hard to follow. You create plaintext blocks that are mainly zeros, and see what comes out of encryption/decryption (being symmetrical, the operations are identical). That reveals a byte of the key. Then you build some more complex plaintext guided by the previous result, and get the next byte... and so on.

 

[MymsMan]

On the face of it (not going into the nitty-gritty), I didn't find the concept hard to follow. You create plaintext blocks that are mainly zeros, and see what comes out of encryption/decryption (being symmetrical, the operations are identical). That reveals a byte of the key. Then you build some more complex plaintext guided by the previous result, and get the next byte... and so on.

But how do you persuade the Humax to encrypt a file that it hasn't created by recording.

 

[prpr]

But how do you persuade the Humax to encrypt a file that it hasn't created by recording.

If it's symmetric, by getting it to 'decrypt' an unencrypted file (presumably by manipulating the flags in the .hmt file).

 

[af123]

Are you sure it's symmetric? 3DES does encryption with key 1, decrypt with key 2, encrypt with key 3 - decryption is the reverse.

I'm pretty sure the 2000-T will be using 2-key 3DES too.. the reason being that from everything I've seen the Broadcom SoC API takes a 128-bit key and an algorithm type, the type being either 3DES or AES. Keeping the key at 128-bits for both makes for a simpler API I suppose.

 

[Black Hole]

Everything I've read says it's symmetric, but maybe that's just DES. Easy to test: pass some plaintext through the decryption twice and see if it comes out the same. It would certainly be easier to implement in hardware if it is symmetric.

3DES does encryption with key 1, decrypt with key 2, encrypt with key 3 - decryption is the reverse.

I'm pretty sure the 2000-T will be using 2-key 3DES too..

How do these two statements marry up? If it's two-key, why have we only been talking about one key?

 

[MontysEvilTwin]

Everything I've read says it's symmetric, but maybe that's just DES. Easy to test: pass some plaintext through the decryption twice and see if it comes out the same. It would certainly be easier to implement in hardware if it is symmetric.


How do these two statements marry up? If it's two-key, why have we only been talking about one key?

I think that the long string (derived from the MAC address and serial number) is split into smaller keys. If I am correct, with the HDR-FOX, key 1 = key 3 so there are effectively two keys derived from the main string.
Edit: This is already explained in post #25.

 

[MontysEvilTwin]

I wonder why I didn't think of that... I took a different approach of setting the encryption key on my HD to the same as my main HDR, then I can just rsync the recordings across and watch them on the HDR (or decrypt them there if I want).

So it is possible to overwrite the default encryption key at boot then.
I don't know much about cryptography, so please set me straight if I am talking nonsense. Is it possible to to set the encryption key so that the output equals the input? Either a dummy or null string (don't know what to call it) which does not change the transport stream or, if this is not possible, a string that is designed to cancel out its own effects, ultimately producing an unencrypted output?
AFAIK, the encryption procedure involves a three pass process: encrypt (key 1), decrypt (key 2), and encrypt (key 3). With the HDR-FOX, key 1 = key 3 already. If you make key 2 = key 1 too then two of the passes will cancel each other out so that decryption should just involve a simple one pass procedure. If you do this on the HD-FOX, will this speed up the processing?

 

[Black Hole]

Is it possible to to set the encryption key so that the output equals the input?

I suggested this a while back and was told that there is no such key.*

* Update: I've acquainted myself with the structure of DES, and it involves multiple convolutions of subsets of the data bits with subsets of the key bits, with data scrambling and non-linear bit field substitution between each convolution. It's hard to see how any key choice could have zero effect on the output, even if the input were also zeros, although the literature talks about there being "weak" key choices. In our case, the key is severely weakened (against a brute-force attack) already by being chosen from a relatively short list.

If you make key 2 = key 1 too then two of the passes will cancel each other out so that decryption should just involve a simple one pass procedure. If you do this on the HD-FOX, will this speed up the processing?

That's an interesting idea, it effectively converts the Triple DES to just DES and (conceivably) could result in software decryption at 2.4 MiB/s. However, I don't know whether we have direct access to K1 and K2 individually, or if they are derived from K outside our control.

 

[Black Hole]

Everything I've read says it's symmetric, but maybe that's just DES.

Okay, I now see my mistake: it's symmetric-key as opposed to symmetric, and the encryption & decryption algorithms are different (although use the same processing elements applied in a different sequence). I have been under a longstanding misapprehension that encryption and decryption were identical.

Although there may be some implications for the theoretical security of the system, for our purposes "encryption" and "decryption" are only labels for a transformation T and its inverse /T, but by convention cyphertext = T(plaintext) and plaintext = /T(cyphertext) rather than the other way around. T(x) <> /T(x)

Readers: note that this discussion has two sub-discussions:- 1. "rescue" decryption of recordings from machines with unmodified keys; 2. encryption and decryption using modified keys for (a) compatibility with other machines, or (b) increased performance of software decryption.

 

[af123]

How do these two statements marry up? If it's two-key, why have we only been talking about one key?

You almost definitely know this now but 3DES uses a key bundle which is comprised of 1, 2 or 3 separate 56-bit keys with check bits making the input length 64-bits.
In the case of the Broadcom API, the key bundle is 128-bits long so K3 == K1 (I presume this is so that they same key can be used for either 3DES or AES128 although those have different block sizes so it can't be that simple)..

So it is possible to overwrite the default encryption key at boot then.

Yes, that's definitely possible.

That's an interesting idea, it effectively converts the Triple DES to just DES and (conceivably) could result in software decryption at 2.4 MiB/s. However, I don't know whether we have direct access to K1 and K2 individually, or if they are derived from K outside our control.

It's most likely that K1 & K2 are just the first and last 64-bits of the 128-bit input key - easy enough to test.
For the HD model, that's a really interesting idea that should really speed up decryption.

 

[EEPhil]

If I am correct, with the HDR-FOX, key 1 = key 3

It certainly is. I tried af123's pointless test first with an external (Java) encryption library that allowed just key1 & key2. When I got it to work, I went back to the standard Java libraries which will only work with the 24 byte key - and this had key3 = key1.

I'm pretty sure the 2000-T will be using 2-key 3DES too..

Just a thought, and I'm going to look into this later, I've just discovered that the 2000T (and maybe others) have a System ID. On the 2000T that is given as a 4 byte hex number in System Information. 6 byte MAC, 14 byte serial number and 4 byte System ID = 24 bytes. It can't be that simple - can it?

 

[MartinLiddle]

I've just discovered that the 2000T (and maybe others) have a System ID.

All the Humax boxes I am familiar with have a System ID; it is checked when applying software updates to try and prevent people from bricking their boxes by applying an update intended for a box with different hardware.

 

[EEPhil]

It can't be that simple - can it?

It isn't. No combination of the three items worked. Neither did truncating them to 16 bytes.

 

[EEPhil]

If it's symmetric, by getting it to 'decrypt' an unencrypted file (presumably by manipulating the flags in the .hmt file).

That is easy. I can fill a .ts file with some bytes and get the Humax to decrypt it - piece of cake. Unfortunately, we want to encrypt it to follow the method in the paper that BH referenced. I'm not sure I can do that.

 

[Black Hole]

Yes, my earlier misconception produces that problem. However, the encryption and decryption processes are so similar there must be a similar process to follow that uses decryption rather than encryption to create the data. Not that I would know how...

 

[MontysEvilTwin]

I found a useful reference here. The main aim of this is to explain different padding types, i.e. methods to use when the data to be encrypted is not an exact multiple of the block size, but it exemplifies how the decryption works.

 

[Black Hole]

It's most likely that K1 & K2 are just the first and last 64-bits of the 128-bit input key - easy enough to test. For the HD model, that's a really interesting idea that should really speed up decryption.

I think what's needed here is:

1. A utility to enable the user to manipulate the key(s);
2. For the stripts decrypt function to test for K1 = K2, and if true decrypt with DES instead of 3DES.

 

[af123]

• A utility to enable the user to manipulate the key(s);

Not wrapped up tidily yet, but...

humax# nugget cryptokey
Native key: dc d3 21 01 02 03 36 33 37 31 30 35 37 36 33 30
Using key:  <no custom key in use>

humax# nugget cryptokey 01.01.01.01.01.01.01.01.01.01.01.01.01.01.01.01
Using key:  01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

humax# nugget cryptokey
Native key: dc d3 21 01 02 03 36 33 37 31 30 35 37 36 33 30
Using key:  01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

humax# nugget cryptokey -clear
Cleared custom encryption key.

humax# nugget cryptokey
Native key: dc d3 21 01 02 03 36 33 37 31 30 35 37 36 33 30
Using key:  <no custom key in use>

 

[af123]

And the optimisation for a repeated key is definitely worth doing:

Before:

humax# stripts -d1 -@@ Ambulance_20180426_2123 l
SD recording.
Encrypted: 1
+ Total size: 59125760
00000000: 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08  ................
Key appears correct.
Processed in: 72.30s

After:

humax# stripts -d1 -@@ Ambulance_20180426_2123 l
SD recording.
Encrypted: 1
+ Total size: 59125760
00000000: 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08  ................
DES key detected.
Key appears correct.
Processed in: 29.86s