Hacking the on-board Encryption Chip...?

Trev said:
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.
Click to expand...
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.
 
Eric said:
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
Click to expand...

Eric this sounds like a capacitor has blown in the power supply. If you still have the unit take the lid off and look at the components around where the mains comes in and around that area.
It may be obvious where it's gone pop or you may need to look a bit harder.
Capacitors come in various types but the ones that blow up are cylindrical and have a plastic cover with aluminium at the end usually with a cross in the aluminium.
The cross is a deliberate weakness to allow the expansion when it blows.
Look at the ends of the capacitors closely - if they are flat it is fine, if it is bulging or even has spectacularly exploded that one needs replacing. There may be more than one gone, if there are a few burnt components you are in a different world altogether. Chris
 
Actually I just remembered- it's a separate power supply.
Get on eBay.
There's one on there but I can't post external links on here
 
hairy_mutley said:
I used to find that decryption while recording resulted in unwatchable recordings
Click to expand...
Yes, me too. Well at least, severe blockiness. Even now, rewinding an HD channel and pressing record gives problems while it's processing the buffer.
 
Ad detection, specifically ffmpeg, adds a more significant load on the humax cpu than decryption alone.
I run with concurent addetection whilst recording for all non-BBC programs without significant problems but I only record from SD channels because I find HD unreliable in my area even without any other activity.
 
Trev said:
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.
Click to expand...
I did notice media navigation on my V2 machine could be a bit sluggish when decrypting/shrinking - about the same as when you've got it saving the buffer and want to watch something else in the meantime.
 
If anyone has a few minutes to try something on an HDR T2 with CFW based on 1.03.12...

I think that the following memory areas represent the TSR buffer + two tuners so can you try
Code: 
nugget dump 0xdadc00 0x19c
nugget dump 0xdadd9c 0x19c
nugget dump 0xdadf38 0x19c

Don't paste the output here as it's quite long, just see if you observe the same as me.
The first byte seems to be 01 for an idle tuner and 02 for one in-use and the pathname of the current (or last) recording is in there too.
The MAC address followed by part of the unit's serial number seems to be towards the end.. Making me wonder if it's a seed for the encryption engine.

Any thoughts on the other values in there appreciated.

Thanks.
 
Last edited:
af123 said:
If anyone has a few minutes to try something on an HDR T2 with CFW based on 1.03.12...

I think that the following memory areas represent the TSR buffer + two tuners so can you try
Code: 
nugget dump 0xdadc00 0x19c
nugget dump 0xdadd9c 0x19c
nugget dump 0xdadf38 0x19c

Don't paste the output here as it's quite long, just see if you observe the same as me.
The first byte seems to be 01 for an idle tuner and 02 for one in-use and the pathname of the current (or last) recording is in there too.
The MAC address followed by part of the unit's serial number seems to be towards the end.. Making me wonder if it's a seed for the encryption engine.

Any thoughts on the other values in there appreciated.

Thanks.
Click to expand...
I agree with the observation
with two recordings in progress I had 02 for the first byte and recording path in the first 2 buffers and 01 and TSR in the third.
With no recordings I have 01 and TSR in all three (the last recording path disappeared after I changed channel (I think))

No guesses on other content
 
With two recordings in progress while watching a different channel I had 0x02 as the first byte in all three buffers.

If the pathname is part of the encryption key, it should not be possible to decrypt a recording that has been renamed and/or the pathname has been changed in the hmt file. Is that what happens?
 
No, that isn't what happens. The key is fixed and programmed into each individual unit.

There must be some kind of flash memory containing the key which then gets read into the encryption system at boot time, because there have been situations which indicate the key has been lost, and functionality is restored by a reboot. This is indicative of the encryption system being implemented as general purpose hardware which gets configured at boot time using a hardware configuration boot memory.
 
xyz321 said:
If the pathname is part of the encryption key,
Click to expand...
I didn't mean the whole data, just the last part that contains the unit MAC address and partial serial number. On a freshly booted box, that area is zeroed out. The penultimate 4 bytes is a pointer to a semaphore used to control access to this data but it could still be the case that the data at offset 0x150 onwards is part of the encryption story... analysis continues.

Black Hole said:
The key is fixed and programmed into each individual unit.
Click to expand...
We've always assumed that (and certainly the key is unique to each unit) but there's no reason it couldn't be based on the MAC address and serial number rather than being in some kind of TPM or enclave on the chip. One observation that would be really valuable is what is in these memory areas for a box which has "lost its encryption key".
 
af123 said:
One observation that would be really valuable is what is in these memory areas for a box which has "lost its encryption key".
Click to expand...
No doubt, but the event itself is rarely reported, and it would be even rarer that we got the chance to intervene before it got rebooted to a working state.
 
af123 said:
it could still be the case that the data at offset 0x150 onwards is part of the encryption story
Click to expand...
I've got two units where the serial numbers only differ in the last 4 digits, so this partial serial number is the same on both.
Interestingly, but possibly not surprisingly, the difference between the complete serial numbers is also the difference between the MAC addresses.
 
I don't see where a knowledge of the key or its storage location gets us. It has already been refuted that there could be a null key, and the aim is not so much to gain knowledge of the key as to turn off the encryption pathway (as opposed to the decryption pathway).

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 - but of course we have no comparison example where the received video data is not fed through encryption.
 
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...
 
I would have thought that the encryption key is more likely to be based on the serial number/security system contained within the main processor.
 
I think the object of the exercise is to bypass the whole encryption process as was done by nowster on the Foxsat. If this were to be done, then surely the location and makeup of the encryption key would be irrelevant.
 
That's what I said (post 34). The counter argument is that it could track back to the relevant code to disable it.
 
Trev said:
I think the object of the exercise is to bypass the whole encryption process as was done by nowster on the Foxsat. If this were to be done, then surely the location and makeup of the encryption key would be irrelevant.
Click to expand...
Whilst probably not relevant for bypassing encryption it might be of use for enabling off-box decryption to recover recordings from a failed box.
 
You must log in or register to reply here.
Back
Top