prpr
Well-Known Member
Are you going to update the non-native versions of stripts ?
Beta Offline decryption utility
- Thread starter af123
- Start date
Black Hole
May contain traces of nut
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...
Is there any way to trigger the box's shutdown process without actually shutting down? That's when thumbnails are auto-generated.
EEPhil
Number 28
[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'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
Well-Known Member
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
Last edited:
Black Hole
May contain traces of nut
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:
Last edited:
OP
Black Hole
May contain traces of nut
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.
Last edited:
MymsMan
Ad detector
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:
- Use the nts file to identify a i-frame nearest the required time offset
- Extract the frame from .ts to a temporary file
- Decrypt the temporary file using stripts
- Use ffmpeg to extract the image
- Convert the image to .thm format
- Save thm and clean up
Black Hole
May contain traces of nut
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
Well-Known Member
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
May contain traces of nut
https://en.wikipedia.org/wiki/Weak_key#Weak_keys_in_DES said:
We already know the Humax implementation ignores the parity bits, so all-zeros should be indistinguishable from repeating 01.
OP
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.
OP
Well, it's currently pretty much unoptimised.. There are probably faster DES implementations that the one in libcrypto too.
prpr
Well-Known Member
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
Well-Known Member
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
May contain traces of nut
But if it's the same as before, why the drop from 0.8 MiB/s to 0.75 MiB/s?
Black Hole
May contain traces of nut
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
May contain traces of nut
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.
OP
Did a bit of optimisation last night.. this is a natively encrypted recording on a HDR.
New version is around 8% faster - might be more for just DES.
Code:
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.18sNew version is around 8% faster - might be more for just DES.