Why does Humax encrypt SD material?

peterh337

Member
I can see why HD is encrypted (it is broadcast encrypted AIUI) but SD is not broadcast encrypted so why encrypt it on the HDD, especially as the stock box decrypts it if you copy a file to a flash stick?

The general drift seemed to be to prevent movies ending up on the internet but if you can get in on a USB stick then you can just do that.

Just been reading about Freely and the whole idea behind that being to block recording and advert skipping. The history of this stuff is interesting...

The decryption key for HD is stored inside every player, just like the key for movie DVD playback was. It was the software player (PowerDVD) which enabled the extraction of this key, many years ago. Somebody must have disassembled the Humax code to extract the HD key, if I've got this right.
 
I can see why HD is encrypted (it is broadcast encrypted AIUI)

Get your facts straight: not even HiDef is broadcast encrypted, all the encryption/decryption takes place in the recorder.
The recorder manufacturers are obliged to implement copy protection as a condition of their licensed use of EPG data, to carry the "Freeview" badge. The Freeview EPG data is encoded (not encrypted), and the decoder is proprietary but easily obtained.

A PVR is supposed to be just that – Personal. The idea is that it acts as a private library and time-shifter, as opposed to sharing cassette tapes around.

Somebody must have disassembled the Humax code to extract the HD key, if I've got this right.

No, there is no broadcast HiDef key, and the internal encryption is in hardware (like you were previously told). Nonetheless there has been limited selective disassembly for other reasons.

Things Every... (click) section 5, and follow the links.

"HD" disambiguation: see Glossary (click)

Just been reading about Freely and the whole idea behind that being to block recording and advert skipping. The history of this stuff is interesting...

Yes, it's a battle between users wanting convenience and broadcasters needing revenue in order to produce content and broadcast it. People are in danger of killing the goose. They complain, but IMO the BBC's licence fee model isn't such a bad idea (just needs a decent non-woke governance, focused on being a PSB and not an "influencer").
 
Last edited:
Somebody must have disassembled the Humax code to extract the HD key, if I've got this right
Not quite. I don't think it's an HD key because for Fox-T2 and 1800/2000T models all recordings are encrypted. These machines allow the copying to USB or streaming of StdDef recordings which get decrypted. HiDef recordings can be saved after a small amount of faffing about. Someone ( was it af123?) discovered the format of the decryption key (reverse engineering of some Humax code IIRC) that applies to one or more of the Fox-T2 models. (Doesn't work for later models).
If you know the serial number and MAC address of the device you can decrypt all the recordings, even HiDef.
 
@EEPhil you might want to review my post above, it's definitely not a "HD" (HiDef) key.

The encryption system was reverse engineered, yes, but by examination of the data and intelligent guesswork. It is not implemented in firmware.
 
The encryption system was reverse engineered, yes, but by examination of the data and intelligent guesswork. It is not implemented in firmware.
I guess I might be misremembering something from ages ago. I'm too lazy to check back through all the posts - and search often doesn't help.
As for reviewing your post above, I would have done had it been there when I started trying to write my post. ;) ( I deleted my first draft and your post was notified to me close to when I posted the second version - so I didn't read it until after I posted)
 
"not even HiDef is broadcast encrypted, all the encryption/decryption takes place in the recorder."

That means it is fairly trivial to implement a PC based box, with an SDR receiver (like I use for ADS-B logging) which produces completely open HD recordings. Probably one could not sell it freely for fear of litigation? But that is how one would build a PVR nowadays.

I do know the CF can decrypt any recording, and have used that a few times to get an mp4 of something.

"by examination of the data and intelligent guesswork"

Must have been fairly simple, not any 1970s onwards algorithm like DES, AES, etc. Maybe those would be too slow. I have AES256 running on a 168MHz ARM32 and it does 800kbytes/sec done entirely in software. Probably not fast enough for HD?

Ultimately if you can get at the code, you will find the key. I heard from someone who used to work for some PVR maker and they used to put epoxy over the FLASH chips to make disassembly harder.
 
Must have been fairly simple, not any 1970s onwards algorithm like DES, AES, etc.
Oh really? 3DES. Just read...

Ultimately if you can get at the code, you will find the key.
It's not in the code, it's burnt into the SoC crypto hardware. Just read...

That means it is fairly trivial to implement a PC based box
We have a forum section for that....


Honestly... been there done that, you're not telling us anything new and sometimes not even right. Continued discussions are welcome, but PLEASE go find the existing conversation and add to it, don't just start new ones as if nothing had gone before.
 
Last edited:
OK I found some stuff by searching on 3DES. There must be hardware for that, to do it fast enough. This chip runs at 400MHz IIRC. OTOH I recall a friend having done a DES implementation c. 1995 which did a megabyte/sec, but used large tables in RAM (megabytes of RAM) which were precomputed at startup (the S-boxes converted into lookup tables etc).

"If you know the serial number and MAC address of the device you can decrypt all the recordings"

Yes I saw that a while ago. Quite amusing ;)

I wonder who dictated the use of 3DES? Was it Freeview? It is a fairly "heavy duty" way of doing this. There is no publicly known attack on DES or 3DES, other than an exhaustive key search (not possible on 3DES but possible with some high end graphics cards on DES) although even that relies on keyspace reduction (from 2^56) by the use of known plaintext (which in this case you would have) and some clever techniques. So if this was done say 10 years ago, the key would have been extracted from the firmware somehow, not by examination of the ciphertext (in the way that e.g. the internal operation of the Fish machine was deduced c. 1942 at BP without ever seeing the actual machine).

I am familiar with DES as I have worked in crypto for last 30 years and used to build DES line encryptors as used back then in banking. The CESD (GCHQ) would require plain DES else you would never get an export license ;)

BTW, arrogant replies just drive intelligent participants away from a forum, leaving just a small clique ;)
 
Last edited:
BTW, arrogant replies just drive intelligent participants away from a forum, leaving just a small clique ;)
Well, if you insist on coming in with left field ideas when the work is done and documented, and you were pointed at the documentation, but then keep spouting on, expect some push back in the replies you receive.

In short, do the research when you get pointers to it.
 
Calm down. You wrote "It's not in the code, it's burnt into the SoC crypto hardware. Just read..." which, referring to where the key is, does not mean that actual algorithm used is in hardware. For example in my last project I have aes256 in hardware and all the others e.g. des, 3des, chacha, rsa, ec, and various hashes, are in software despite the CPU having crypto hardware. Actually the CPU has des and 3des in hardware but for reasons I won't go into I am not using it. But I also have aes256 in software, elsewhere (google for tiny-aes, 1k code size, 100kbytes/sec).
 
Back
Top