• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Humax recording encryption

Since it is probably symmetric (encryption process = decryption process), would preparing some very specific probe files and then running them through decrypt reveal the key? One would have to know a lot about the process to design the probes, but I guess somebody somewhere has done that already. Everyones key would be different of course.
ChrisDaniels said:
Or indeed turn it off :)
Click to expand...
I don't see any chance of that, except to access the hardware by JTAG or something and write a null key into it.
 
Sam Widges said:
I'd be surprised if 3DES was in use because that would result in a lot of encryption processing. It's much more likely that AES is being used as that was designed to use less processing power.
Click to expand...
All of the crypto operations are performed in hardware so both are feasible.
 
Black Hole said:
Since it is probably symmetric (encryption process = decryption process), would preparing some very specific probe files and then running them through decrypt reveal the key? One would have to know a lot about the process to design the probes, but I guess somebody somewhere has done that already. Everyones key would be different of course.
Click to expand...

No, that doesn't work, brute force is the only way, and with AES128 or 3DES it isn't that practical.
JTAG could possibly let you get at the key, depending on the FIPS rating of the HSM.
 
af123 said:
No, that doesn't work, brute force is the only way, and with AES128 or 3DES it isn't that practical.
JTAG could possibly let you get at the key, depending on the FIPS rating of the HSM.
Click to expand...

Cryptography always turns into a key management management and best practices problem. The best algorithm in the world can be compromised by weak keys and/or poor procedures eg. encrypting know plaintext, repeating things etc. Since we can get both the encrypted and decrypted form of any file on the box, that gives an incredible way into the crypto. We have virtually infinite amounts of known plaintext.

wget tricks and DLNA etc are all well and good. But I don't want to change the software in my HDR Fox T2, I simply want to FTP off the encrypted files and then decrypt them on my PC.

Setting the key to all zeros won't turn off the crypto, it will just encrypt the files with a known key. This would be OK, if we generate the keys the box uses to encrypt then we'll have the decryption key.
 
Black Hole said:
By "null key" I didn't mean all zeros, I meant a key which generates cyphertext = plaintext.
Click to expand...

No such key exists for many encryption algorithms, all keys are valid and encrypt the content in some way. Of course they may be weak and easily broken keys. It is a weakness of crypto algorithms to have some key values which cannot exist, it provides a way in. It's similar to what the Enigma machine did whereby it never encrypts a character to itself, this was intended to strengthen security but in fact weakens it since the range of possible outputs is reduced making brute force searches easier.
 
Sam Widges said:
Possibly you're thinking of 'null encryption' which is a test mode for cryptosystems that allows you to test everything except for the actual encryption.
Click to expand...

Real encryption systems have no such thing, you just use test keys instead of the real ones. Test modes have a nasty habit of turning into vulnerabilites to exploit. Of course if the HDR Fox T2 has such a thing then that would be exactly what we want to exploit...
 
Owen Smith said:
Real encryption systems have no such thing, you just use test keys instead of the real ones. Test modes have a nasty habit of turning into vulnerabilites to exploit. Of course if the HDR Fox T2 has such a thing then that would be exactly what we want to exploit...
Click to expand...

IPSec, SSL and TLS support null encryption and they are all "real encryption systems". I suspect that it's all academic though, because those are network encryption schemes that are designed to interwork between computers, so negotiation is feasible. In the case of the Humax, encryption either happens or it doesn't, although finding some test mode that disables the encryption would be still be very helpful :)
 
Just trying to think outside the box: is encryption done on the fly or immediately after a recording?
Can you stream from it while its still recording a file? like the TSR..

Would it be possible to locate the file that deals with encryption and kill it or replace it with a dummy file?
Might sound like too simple a solution, but you never know.
 
ChrisDaniels said:
Just trying to think outside the box: is encryption done on the fly or immediately after a recording?
Can you stream from it while its still recording a file? like the TSR..

Would it be possible to locate the file that deals with encryption and kill it or replace it with a dummy file?
Might sound like too simple a solution, but you never know.
Click to expand...

It has to be on the fly, otherwise after a recording the whole file would need replacing, just the same as replay decrypts on the fly. There is no such file.
 
We have already agreed that the crypto is in hardware, and the key is embedded in the hardware and not in some file system data.
 
WRT disabling encryption - Has anyone ever tried changing the value of OPERATOR_TYPE in TBL_FACTORYCONFIG ( /var/lib/humaxtv/setup.db ) - its set to 11 on mine.. I would change it on mine but if it somehow mucked things up and risk'd a recording of "Strictly" I would be in big trobs.
 
ratx said:
WRT disabling encryption - Has anyone ever tried changing the value of OPERATOR_TYPE in TBL_FACTORYCONFIG ( /var/lib/humaxtv/setup.db ) - its set to 11 on mine.. I would change it on mine but if it somehow mucked things up and risk'd a recording of "Strictly" I would be in big trobs.
Click to expand...

It's also 11 on mine, It wouldn't surprize me if this is the Default On Screen Language like TBL_MENUCONFIG - AUDIO_LANG and SUBTITLE_LANG also 11 (or 44 for Welsh)
 
Well, I had a go at this, too. It looks like a 64bit block cypher is used in ECB mode. But the key is not stored in memory, assuming it is DES or 3DES. So that's a bit of a shame, because the decryption process is kind of annoying on the HD.
 
We believe the encryption engine is embedded in the Broadcomm chip, with the key programmed into it. If we knew the algorithm and could reverse-engineer the key (after all, we have access to a lot of cyphertext/plaintext material) the decryption could be off-loaded to a PC.
 
Black Hole said:
We believe the encryption engine is embedded in the Broadcomm chip, with the key programmed into it. If we knew the algorithm and could reverse-engineer the key (after all, we have access to a lot of cyphertext/plaintext material) the decryption could be off-loaded to a PC.
Click to expand...
Yes, unless it is 3DES, in which case breaking it seems nearly impossible. Even for DES the effort is huge, probably more than the box is worth.

But I have another idea: instead of decoding each programme individually, it should be possible to concatenate them. Because ECB is used, every block is treated exactly the same way. So whether you decode 20 short programs or one 20h file, it does not make a difference. Except you save a lot of button presses.
 
You must log in or register to reply here.
Back
Top