Hacking the on-board Encryption Chip...?

[Black Hole]

If you know how to implement the decryption, that is! I suppose it might be possible to reprogram another HDR to do it.

 

[af123]

See https://hummy.tv/forum/threads/offline-decryption-utility.8676/

I suppose it might be possible to reprogram another HDR to do it.

Yes, I've managed to do that in testing too. It might be nice to have a package to allow reprogramming - at least I could give all of my boxes the same key for example (or my HD unit the same key as my HDR); just thinking out loud. Of course, if I achieve the goal of removing encryption entirely, it will be unnecessary.

 

[Eric]

You think the two events are connected?

Apologies for the late reply, i've been recuperating after major surgery, and i'm only now starting to engage in 'normal life'.

In answer to your reply, there's a distinct possibility! In any case, anything that reduces the workload of these OAP machines has got to be good, in the long run.

I'm sure we've all experienced the ridiculous slow-down of our hummy's when it's simultaneously recording, and on-the-fly decrypting - two tv programmes, whilst your trying to access (or navigate media) the 'Video' menu to watch something. The long wait in-between remote control button presses is painfully slow. Then 5 minutes later, the boxes decides it's had enough and reboots itself!

I've even had so called successful recordings being made, and then upon watching them, there are these bloody huge pixels all over the place, meaning you've just completely wasted your time!

As i said, in my opinion simultaneously performing labour intensive tasks puts a massive strain on the internals - at least accumulatively anyway! These boxes won't be around forever, and then we'll all be stuffed!

 

[Eric]

Your evidence for this is what exactly? A sample of 1?

The evidence of my own eyes, the experiences of family members, and friends who have also suffered from slow-down issues, and rebooting from time to time. Just because yours (or anyone else's for that matter) hummy might be perfect and never experiences the problems we have, doesn't mean it's not happening at all, and perhaps to the vast majority of users who don't subscribe to this forum, or just watch from the sidelines.

And in any case, common sense knows that everything suffers from wear and tear, and nothing lasts forever, so a reduction in workload (whether it be your machine or your body) can help prolong the inevitable - something i'm painfully experiencing in my own life right now!

...i'd use "the tortoise and the hare" analogy

Preservation is the key to longevity!

...and eating your greens! lol
.

 

[Eric]

Agreed, but in the WebIf you can specify times when the auto-processing (including decryption) does and does not run. I have mine set not to run between 5pm and midnight, which is the time when (a) I watch TV the most and (b) it is most likely to be dual-recording.
Avoiding encryption, and subsequent decryption, entirely would be nice, though...

Alas, my hummy doesn't wake-up from Standby anymore, only the rear switch - so i can't schedule it to do labour intensive tasks when i'm out or sleeping. And i don't want the box on constantly through the night when i'm asleep for example, as i know the unit needs to cool down and rest.

 

[Eric]

I used to find that decryption while recording resulted in unwatchable recordings (the discussions are on these forums). We never got to the bottom of why I had problems when other didn't, so I just continue to avoid doing the two together.

Thank god i'm not the only one! lol

The pixilation is horrendous and sometimes when the recording has finished and you go to 'play' it, there's an error saying "recording not found"

...SO annoying

 

[Eric]

Yes, that's the eventual aim but given the 1,373,453 lines of assembly language here, I'm starting by trying to get a better understanding of anything I can...

@af123 - hi, how are you doing wading through the million lines of assembly language? - any closer to understanding the encryption process and switching it off?

Or are we more likely to 'work with the problem' and try to make all our machine's universal (as i've seen in a new topic by re-coding our machines/serial no's to 33333333's or something) - so we can then play encrypted recordings on any of our hummy's without the need to decrypt at all ??

After all, the main reason (in my case) for switching off the flag, as it were, is to watch recordings on different hummy's or replacement ones when our's eventually pack up!

thanks
.

 

[Trev]

It's fine om mine. Just a little pixelation at the crop point on the auto ad crop points. Haven't noticed any particular slow down when detectads is running doing its magic.

 

[Eric]

It might be nice to have a package to allow reprogramming - at least I could give all of my boxes the same key for example (or my HD unit the same key as my HDR

@af123 - i think is a fabulous solution, albeit temporary, until we're able to switch off the whole decryption process altogether!

I had a quick look at the link you supplied but in the absence of reading all 11 pages and not fully understanding all the technical jargon, is there a 'package' we can/could add in the webif (similar to adding the 'Auto-Unprotect' package for example) that completely automates the whole "...changing the encryption/serial number" thing, so all our hummy's are the same, thus being able to watch recordings without the need to remove the encryption protected flag on high Def recordings, for example, or fully decrypting by the 'copy' process, via the remote control etc.. ??

Many thanks

 

[Eric]

It's fine om mine. Just a little pixelation at the crop point on the auto ad crop points. Haven't noticed any particular slow down when detectads is running doing its magic.

Yeah, what's with that 'crop point pixilation' anyway!!??

Good (or not) to hear i'm not the only one who suffers when trimming recordings. In my basic world, if you cut then it should seamlessly join, no? - so why the pixel crap!

Anyone know a better solution?

 

[peterworks]

is there a 'package' we can/could add in the webif (similar to adding the 'Auto-Unprotect' package for example) that completely automates the whole "...changing the encryption/serial number" thing,

It is already there in WebIF. Go to Settings then Advanced Settings. This is how I have done it on my two machines:

This setup allows recordings in the original key or the custom key to be viewed. And, of course, recordings can be transferred between machines and play fine as long as the custom key is the same on both.

 

[Ezra Pound]

This setup allows recordings in the original key or the custom key to be viewed.

I'm wondering if it does, I had assumed that any recordings encrypted with the original key would not get decrypted if you 'set' the custom key to something different, I have not tried it but thought that you needed to decrypt all existing recordings before changing the key

 

[peterworks]

I'm wondering if it does

The decryption de-queue process now tries a number of encryption keys in direct mode - it will try whatever is in /mod/boot/cryptokey, the current key as reported by nugget and the box native key. This allows changing the key but still allowing old files to decrypt properly (and other scenarios..)

Hopefully I don't have the wrong end of the stick...

 

[Ezra Pound]

Sorry, Yes you are correct, I missed that bit of af123's post

 

[Stardust]

...i was wondering if you've made any progress on your "side project" ?? - I'm sure i'm not alone in wanting future recordings to bypass the automatic encryption process completely.

No, I'm afraid not, but it is still on my list (just below making disks > 4TB work)

...The task should be to identify whether there is a configuration flag which determines whether received video data is fed through the encryption engine at all

I think the object of the exercise is to bypass the whole encryption process as was done by nowster on the Foxsat.

@af123

[as a new member joining today i'd like to revive this thread/post as it's been dormant since last August]

Hello.

I see this was originally raised way back in 2017, so with regards to the above, have you got any closer to understanding and subsequently removing the automatic decryption of recordings yet? I'm keen to see all of us bypassing the automatic encryption process completely!

I'm looking for something like the 'nowster's patch' for the Fox-T2.

Our family has three Humax box's in different rooms and it's getting very arduous copying all our recordings over to external USB-Drives for archiving. I don't mind the slight delay in the copying per-say, but the decrypting process adds a significant amount of time to it. A typical 2-hour HD movie can take nearly half and hour!

We've tried "decrypting on the fly" - (don't like that as it slows the box too much and has caused several recordings to fail)

Running the decryption process at night, after we've gone to sleep - (can't do that anymore as the Humax box now won't come out of standby - have to reboot every day)

lastly, manually decrypting content adhoc - (stopped this now as you have to physically be at home doing it, and i've spent hours wasted over the years waiting for a recording to finish before decrypting another)

So the only concludion for us (and i'm sure a lot of others on here) is to bypass the whole encryption process altogether, as was done by nowster on the Foxsat.

Surely there must be a patch that can be made 'af123'...? - i can't see anyone else working on it unfortunately.

Is there anything i can do to help you? - go through codes... testing... etc? - (alas i'm not as technically minded as yourself and you seem to be the go to expert on most package creations).

Cheers

 

[Trev]

How about decrypt all then put the same encryption keys on all three boxes. Or put the key bof the 'main one' on the other two after decrypting what's on them already.
Be a bit of a pain to start with, but once done, the material will run on any of them.
As per post #51

 

[Stardust]

How about decrypt all then put the same encryption keys on all three boxes. Or put the key bof the 'main one' on the other two after decrypting what's on them already.
Be a bit of a pain to start with, but once done, the material will run on any of them.
As per post #51

@Trev

Good day to you sir, and many thanks for your reply.

I will raise the following points:

- Why should we have to decrypt at all? For us of an older generation, we never had decryption on VHS recordings, so why now just because it's digital and not analogue? Or some fat-cat boss of Freeview, or content provider companies decided to over-protect everything for secrecy - why the bloody protection anyway! (forgive the language) - It's hardly the crown jewels, so why all the security!

Most shows are bloody repeats anyway, which have all been paid for out of our tv licence over the years, so i regard All content on Freeview FREE! - free to access and free to retain (externally).

- Also, i don't always watch content on the Humax a lot, neither do my children - i actually like to take the content abroad with me and plug it into a foreign tv; or watch it on my laptop whilst travelling on the train; or when staying in hotels etc etc.

(...which if i'm not mistaken needs to be decrypted beforehand?)

- I'd like to spend more time NOT performing pathetic tasks in my life - i have enough of those already lol.

- Processing power is another one. All three Humax boxes now won't wake from standby. We all get old and so does our Humax equipment, unfortunately there's no NHS for Humax boxes is there...? lol

These units are completely irreplaceable and i've not seen another on the market that allows us to copy content externally (if i'm not mistaken). All post HDR-Fox T2's don't allow Custom Firmware. So what do we do when all of them have died?

As quoted by Black Hole:-

"Everything could be implemented so much neater if the encryption was turned off at source. Ad detect, for example, wouldn't have to go through the juggling act of live decryption. There would be no delay between a recording ending and it being available over the network - it may even be possible to stream live from the 0.ts file."

"Without any kind of management of load, uncontrolled decryption potentially increases the peak data transfer rate to/from the HDD and therefore the load on the thermal management."

Just a few reasons why we SHOULDN'T have to decrypt any content, so bypassing automatic encryption process alltogether completely makes sense.

 

[Trev]

so bypassing automatic encryption process alltogether completely makes sense.

I suspect that most of us know that anyway, but the very clever people here have not yet been able to create the 'Nowster's patch' equivalent.
Allowing the key to be ported from one box to another has been extremely useful for some.
I decrypt 'on the fly' and have not noticed my box grinding to a halt and that's when recording 2 HD programmes. And it has yet to suffer thermal runaway (fan package)

 

[TonyC]

It's probably worth pointing out that, while not encrypting at all would be the ideal solution, it is also possible to decrypt afterwards on a PC (for example for watching on laptops / tablets). Stardust, I think you know about this already, but for the benefit of anyone else reading this thread, EEPhil has very kindly provided a Windows-based decryption tool - see this thread. A combination of this, and using the same key on all boxes, does solve pretty much all the issues.

As an aside: as I understand it, the programs are not broadcast encrypted (unlike Sky), but all boxes licenced to receive Freeview EPG data must as a condition of that licence encrypt recordings to prevent watching on other devices (or multiple copying). I guess this is a measure some content providers may insist on before allowing their programs to be shown on Freeview. You can use alternative recording devices (eg PC tuners) to capture unencrypted recordings then but need another source of EPG data. And while there are many such alternative recording devices, I don't think any have the same level of ease-of-use as the 'Fox.

 

[Black Hole]

Why should we have to decrypt at all?

Because we do! It doesn't matter how much you would like it to be otherwise – it isn't, and until somebody comes up with a solution such as the equivalent of Nowster's Patch, that's the way it is. It is entirely possible there is no way to do this at all.

There are several alternatives:

1: Use a general purpose Linux box, install tuner cards/dongles, and use something like Kodi to run it as a media centre with recording capability etc. The recordings will be in the clear, although you may find the lack of broadcast EPG inconvenient (can be plugged with Internet resources). This works out a lot more expensive than buying the HDR-FOX.

2: Use the WebIF facilities to give all your boxes the same encryption key. Make sure everything recorded before you change the key has been decrypted first. That way, everything you record with one box can be played on any other (that share the same key) without decryption.

3: Do like I do and simply decrypt everything by routine (but not chase decryption). It's not that much of a problem.

4: Share recordings by DLNA. No decryption or any other special measures required, this is the facility provided by Humax as standard.

"Give me the strength to change what I can change, the serenity to accept what can't be changed, and the wisdom to know the difference"