Beta Offline decryption utility

[prpr]

I've published updated webif, stripts & nugget packages.

• The timestamp problem in nugget should be fixed;
• stripts -@ can now function without a .hmt file being present;
• there's a new stripts -/ for checking an encryption key against a file;

Are you going to update the non-native versions of stripts ?

 

[Black Hole]

Decryption is necessary for the likes of detectads, but if you are not interested in that, and now we have the means for off-line disaster recovery, a case could be made for not routinely decrypting to reduce the duty cycle on the HDD (and other components), using a common key, and only decrypting when there is a particular need (export).

detectads has chase decryption, so WebIF recursive auto-decryption can be turned off for that. However, I still have auto-MPG running for some stuff, so...

If thumbnail generation could be made to work without having to do a full decrypt then that would be mega-useful for me and I could stop having to decrypt everything.

Is there any way to trigger the box's shutdown process without actually shutting down? That's when thumbnails are auto-generated.

 

[EEPhil]

[2000T version]
I'm beginning to think Humax really clamped down on the 2000T. I've tried many combinations of the MAC and serial number, including wild ideas like all 3 keys are different and using the whole serial number and brute-forcing the remaining bytes. No luck. It's clear from the repeating patterns that the form of encryption is the same, but the keys... I've even wondered whether they used an MD5 hash on something to produce a 128 bit result (ie 2 keys). If so, what was used to create the hash could be anything. Most likely the MAC and serial number are there somewhere. In the absence of many super computers and a time machine I can't brute-force the result. I may have to give up on this [looking for the 2000T keys] unless anyone else has some suggestions.

 

[Ezra Pound]

there's a new stripts -/ for checking an encryption key against a file

Could we have an example of the syntax for this new command

EDIT

I have an example in the Wiki here https://wiki.hummy.tv/wiki/Custom_Firmware_Package_Notes#Stripts

 

[Black Hole]

[2000T version]
I'm beginning to think Humax really clamped down on the 2000T. I've tried many combinations of the MAC and serial number, including wild ideas like all 3 keys are different and using the whole serial number and brute-forcing the remaining bytes. No luck. It's clear from the repeating patterns that the form of encryption is the same, but the keys... I've even wondered whether they used an MD5 hash on something to produce a 128 bit result (ie 2 keys). If so, what was used to create the hash could be anything. Most likely the MAC and serial number are there somewhere. In the absence of many super computers and a time machine I can't brute-force the result. I may have to give up on this [looking for the 2000T keys] unless anyone else has some suggestions.

How about you post a (say) 1KiB sample of the cyphertext and the equivalent decrypted plaintext - then we can all have a go at finding the encryption key. With the key, we might be able to spot how it is derived (the risk being that it is a crypto-hash of some system parameters, and therefore unrecognisable).

Update:

https://hpkg.tv/misc/pointless.zip

 

[af123]

How about you post a (say) 1KiB sample of the cyphertext and the equivalent decrypted plaintext -

No need for that...

For your test recording data, from the PAT I have the following crib: 4c4d65d47880c8ef should decrypt to ffffffffffffffff

 

[Black Hole]

No need for that...

Are you sure?

Is it certain that for any particular 8-byte input, there is only one key that would produce the same output? I was working on the premise that there may be several keys that "correctly" decrypt a particular packet, but only one key that correctly decrypts all the packets. This seems likely, because with 64 bits input/output there are only 2^64 possible outputs for any particular input, but the key space is 2^112 (or 2^168), so there are on average 2^48 keys that can produce the "correct" 64-bit output for any particular 64-bit input.

Therefore, having found a candidate key by brute force from knowledge of the encrypt and decrypt of a 64-bit packet, it is then necessary to check the candidate against further 64-bit packets, and there is only a 1-in-2^48 (or even 1-in-2^104) chance that the candidate won't be rejected somewhere down the line.

 

[MymsMan]

If thumbnail generation could be made to work without having to do a full decrypt then that would be mega-useful for me and I could stop having to decrypt everything.

I suggested earlier in this thread that if we could just decrypt the frame containing the thumb nail image we could avoid the need to decrypt the entire file

To do this I think we would need:

1. Use the nts file to identify a i-frame nearest the required time offset
2. Extract the frame from .ts to a temporary file
3. Decrypt the temporary file using stripts
4. Use ffmpeg to extract the image
5. Convert the image to .thm format
6. Save thm and clean up

None of the above looks too complicated - but I still have other calls on my time

 

[Black Hole]

HD-FOX test process:

1. Make test recording A
2. Make key 1 = key 2
3. Make test recording B (similar file size as A)
4. Play A - should fail
5. Play B - should pass
6. Cold restart
7. Play A - should fail
8. Play B - should pass
9. Decrypt A
10. Decrypt B - should take ~⅓︎ the time of decrypt A

Any results?

All good.

Decrypt with custom key [all zeros]: 1.73 MiB/s​

​

Decrypt with OEM key: 0.754 MiB/s​

This is slower than I expected, maybe the additional complexity in stripts has reduced its performance a little. Decryption with the OEM key required that stripts checked the custom key didn't work first (that shouldn't take long).

 

[MontysEvilTwin]

[2000T version]
I'm beginning to think Humax really clamped down on the 2000T. I've tried many combinations of the MAC and serial number, including wild ideas like all 3 keys are different and using the whole serial number and brute-forcing the remaining bytes. No luck. It's clear from the repeating patterns that the form of encryption is the same, but the keys... I've even wondered whether they used an MD5 hash on something to produce a 128 bit result (ie 2 keys). If so, what was used to create the hash could be anything. Most likely the MAC and serial number are there somewhere. In the absence of many super computers and a time machine I can't brute-force the result. I may have to give up on this [looking for the 2000T keys] unless anyone else has some suggestions.

I'll have a look at at a high-def recording from the YouView DTR-T1000 when I have time. That model came between the HDR-FOX and the HDR-2000T; it may be that YouView made them beef up their encryption and they have used this on later models?
One idea. It may not be possible without custom firmware, but is there a way of doing a memory dump to disk on the HDR-2000T? The location where the key is stored on the HDR-FOX is known: the HDR-2000T key could be stored in the same or a similar location so if the flash memory could be read it may be possible to find the key.

 

[Black Hole]

It probably makes little difference but I am using 01(x16) as the decryption key. The reason is that this is one of the two weak keys in DES (the other being FE (x16)].

If an implementation does not consider the parity bits, the corresponding keys with the inverted parity bits may also work as weak keys:

• all zeros (0x0000000000000000)

We already know the Humax implementation ignores the parity bits, so all-zeros should be indistinguishable from repeating 01.

 

[af123]

Decryption with the OEM key required that stripts checked the custom key didn't work first (that shouldn't take long).

The check should be pretty much instant... with logging turned up sufficiently, you'd be able to see how long it took in the auto log but I expect it would be under a second. It just needs to find, decrypt and verify the first payload starting PAT packet in the stream.

 

[af123]

This is slower than I expected, maybe the additional complexity in stripts has reduced its performance a little.

Well, it's currently pretty much unoptimised.. There are probably faster DES implementations that the one in libcrypto too.

 

[prpr]

Is there any way to trigger the box's shutdown process without actually shutting down? That's when thumbnails are auto-generated.

I expect af123 could find it, given enough lifetimes to trawl through 1.3 million lines of code. But without that, I expect not.

 

[MontysEvilTwin]

Another useful feature, if you have the same keys on your HDR- and HD-FOX boxes, is that doing a network copy from a HD-FOX to a HDR-FOX using the HDR-FOX to start the copy procedure with the remote control, decrypts on the fly.

 

[Black Hole]

Well, it's currently pretty much unoptimised.. There are probably faster DES implementations that the one in libcrypto too.

But if it's the same as before, why the drop from 0.8 MiB/s to 0.75 MiB/s?

 

[Black Hole]

We already know the Humax implementation ignores the parity bits, so all-zeros should be indistinguishable from repeating 01.

I have confirmed by experiment that (on HD-FOX, using hardware encryption/decryption) key 0x00000000000000000000000000000000 is identical in effect to key 0x01010101010101010101010101010101.

Therefore, I propose that we adopt all-zeros as the recommended custom key.

 

[Black Hole]

Lastly, there's a crude(1) method for changing a box's encryption key through Settings->Advanced. That will change it straight away and it will persist over reboots.

A button to copy the OEM key into the set key field would be nice, and maybe another to configure it to all-zeros. Also, grey out the "set" button if the set field data is the same as the current key.

 

[af123]

Did a bit of optimisation last night.. this is a natively encrypted recording on a HDR.

humax# ls -l New_\ Family\ Guy_20180416_2059.ts
-rw-r--r-- 1 root root 492M Apr 16 21:31 New_ Family Guy_20180416_2059.ts 

humax# for f in `seq 0 3`; do
> /mod/af/stripts/stripts -@@ New_\ Family\ Guy_20180416_2059 l
> stripts -@@ New_\ Family\ Guy_20180416_2059 ll
> cmp l.ts ll.ts
> done
Processed in: 515.01s
Processed in: 610.45s
Processed in: 528.26s
Processed in: 586.98s
Processed in: 528.64s
Processed in: 595.18s

New version is around 8% faster - might be more for just DES.

 

[af123]

Half-hour BBC news from BBC1 today with all-zeroes key.
old - 398.56s
new - 336.41s
so an improvement but only 6-7% there..