• 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.

Hacking the on-board Encryption Chip...?

Eric

Member
Without the original box in working order you are pretty stuffed. All the recordings are encrypted, the Custom Firmware allows decryption in situ. A bog standard HDR-FOX-T2 will decrypt SD recordings if you copy them to a usb storage device. The hard drive is formatted in Linux EXt3 , surprised you can see anything on it unless you boot your PC into Linux.

Hi all.

Is there no way to 'Hack' the Humax box...? ie to get round the auto-encryption on every bloody recording; or even to access recordings from a dead Humax (hdd)?

My old Humax died last year and, as i've found to my cost, after extracting the hdd none of the saved recordings on that hard drive are available on my other Humax, which in my opinion is completely ridicules!

No where are you told that you must transfer all your recordings to an external hdd in case of a box failure! What was Humax thinking! (i don't care what rules about encryption where made by the tv broadcasters originally - why did Humax not make the encryption chips/software universal... why is every humax box unique?).

If a Humax box breaks down and is no longer able to work, how are we supposed to access our recordings? (SD and HD) ....after all we paid good money for these units!

What exactly is (in computing terms) preventing us from accessing an old box's hdd recordings on a different box? ie. can't the decryption chip be removed and installed on another box somehow...?

There has to be some way, surely....

kind regards
 
Sorry, no, unless you feel adept at transplanting the whole SoC (which is surface mount, no doubt with connections under-chip). If it is the SoC that killed the unit, you would be transplanting the problem.

1. You could have prepared for this eventuality by decrypting everything routinely, either by archiving off to USB or using the CF to decrypt in place (which is what most of us here do).

2. It's only telly. The repeats will be along soon.

3. We paid "good money" for the means to timeshift stuff. It's marketed as a Personal Video Recorder, "personal" being the operative word. No warranty is implied beyond that.

Things Every... (click) section 5.
 
Last edited:
1. You could have prepared for this eventuality by decrypting everything routinely, either by archiving off to USB or using the CF to decrypt in place (which is what most of us here do).

I only just discovered the wonderful world of Humax Custom Firmware... isn't hindsight a wonderful thing..??!!
 
We don't know of any way to access the encryption key on a box. We're not even sure where it is but presume it's some sort of hardware security module (HSM) on the Broadcom SoC.

We have a good way of automatically decrypting everything either just after it has recorded or almost at the same time and I have a side project working on a way to stop the encryption altogether but once they're encrypted, you need the original box in order to decrypt them.
 
....and I have a side project working on a way to stop the encryption altogether

GREAT NEWS! - two fingers up to the broadcasters!! Lol
....you've got a willing guinea pig here ready to test anything you come up with :)

What sort of time-scale were you thinking of releasing, post testing?
 
It will be nice, but it's not essential - our automated post-recording decryption has served well thus far.

Encryption defeat involves finding the configuration data that sets up the encryption data path and bypassing it. Don't hold your breath.
 
...encryption defeat involves finding the configuration data that sets up the encryption data path and bypassing it

...and I have a side project working on a way to stop the encryption altogether


fao: 'af123'

Hi.

It's been a few months since we last spoke, and 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.

Kind regards
 
It can already decrypt recordings that with the custom firmware, so why do you want to bypass it? The only advantage that I can see is that of time and processing power.
 
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.

fao: 'af123'
There's a way to do this: @af123. That produces an alert: @af123. See Newbies' Guide to the Forum (click)
 
It can already decrypt recordings that with the custom firmware, so why do you want to bypass it? The only advantage that I can see is that of time and processing power.


Hi there. Quite simply i've learned the hard way - i've already destroyed one hummy, and not i'm willing to sacrifice another!

'Decrypt on the fly' was something i used to do, however when you consider that most of these units in circulation are coming up to 10 years old now (i know i can't quite believe it!) it puts a massive strain on the internals, and unfortunately for me, one day it died mid-way through the task, with the hummy giving off a horrid acrid smell.

In my experience, when you're recording two tv programmes; and the hummy is decrypting both of them at the same time; while simultaneously accessing the menu (from the remote) to watch a saved recording; it's just too much for some of the older units to cope with. On more than one occasion the unit rebooted mid-way, thus loosing the current recordings - which is a real pain in the ass!

I really do think there's a real genuine need to reduce the workload of these hummy's long term by not encrypting at all. I appreciate i may be in the minority, but if a fix is possible, i think we should try....?

Lastly, i don't have internet at home to access the Webif daily. I also prefer minimum webif usage anyway. Custom firmware is great, but i only want to use it for the odd specific task, not as an extra daily feature.
 
It's been a few months since we last spoke, and 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)
 
'Decrypt on the fly' was something i used to do... it puts a massive strain on the internals, and unfortunately for me, one day it died mid-way through the task, with the hummy giving off a horrid acrid smell.
You think the two events are connected? The only thing that suffers is the throughput on the disk sometimes. Decrypt is done in hardware and doesn't generate lots of CPU activity that's going to cook anything, like you seem to be implying.
I expect your PSU just went bang for whatever coincidental reason.
it's just too much for some of the older units to cope with.
Which is why there are settings in the WebIf now to stop simultaneous recording and decrypting.
I really do think there's a real genuine need to reduce the workload of these hummy's long term by not encrypting at all.
Your evidence for this is what exactly? A sample of 1?
 
In my experience, when you're recording two tv programmes; and the hummy is decrypting both of them at the same time; while simultaneously accessing the menu (from the remote) to watch a saved recording; it's just too much for some of the older units to cope with. On more than one occasion the unit rebooted mid-way, thus loosing the current recordings - which is a real pain in the ass!
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...
 
I don't have a time restriction on mine and have never noticed anything untoward happening. What is the real (not imaginary/assumed/theoretical) problem(s) having it doing the decryption etc. whilst the box is in normal use.
 
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. It can only go as fast as it can go, of course. As noted above, encryption/decryption has its own hardware subsystem, so does not impose any particular increased load on the processor, although obviously increasing the data throughput for the system chip overall also increases the instantaneous watts it needs to dissipate.

Deferring routine decryption to a "quiet" time will reduce the peak load, although not the overall work done. This may have some preservation effect, but personally I don't worry about it.
 
Back
Top