HDR-2000T delayed updates.

This applies equally to yourself. I have no reason not to accept that the issue has been resolved, and that an updated firmware will be released when Humax are ready.
I haven't made any unsubstantiated claims - unless you say calling their bluff is itself a claim? You, on the other hand, are accepting the word of somebody who refuses to back up theirs (and no, the issue is not resolved until users' HDR-2000Ts are passing through aerial on standby). If you have good reason for accepting the claim, let's hear what it is.

I have solid reasons to be sceptical. Let's think for a moment what the are the hardware aspects of passing a UHF aerial signal from a tuner input socket to a pass-through output socket.

This can be done passively, in which case there will be some signal drop between input and output, but the pass-through will be the same whatever the power state of the unit (ignoring some loading effects), or it can be done actively with an amplifier between the two. It seems to me extremely unlikley there will be any other kind of switching to enable or disable the signal path, other than to power the amplifier on or off.

OK, so they want to offer a lowest possible power standby option where the amplifier (and other things) is turned off. If I were designing it, there would be a power rail to support everything that is only required in normal operation, another power rail for everything that needs to be powered in standby but can be done away with for low-power standby, and another separate rail for everything that has to be on all the time. Selecting low-power standby is then a case of turning the medium-power standby rail on or off with the main rail.

My hypothesis is that they made a mistake and connected the pass-through amplifier to the main power rail. This can't be fixed by firmware.

Your hypothesis is that either nothing else uses the medium-power standby rail and they forgot to switch it on for medium-power standby, or that all the systems that could require power in medium-power standby have separate switching and they forgot to switch on just the aerial amplifier (or, even worse, they forgot to make the medium-power standby option do anything different from low-power standby).

We'll see. If Humax do ultimately release a firmware update that fixes it, then your hypothesis is proven and mine is disproven. I don't mind being disproven, but I do object to people saying that it is not a valid hypothesis (until disproven). While the existence of this firmware fix remains conjecture (which it is), my hypothesis is as valid as any other - but if they do have a fix, why announce it and then hold it back without explanation?

[Edit: extensively updated since first posted]
 
Last edited:
Asked Humax Tech today about loopthru update for 200T. Answer went along the lines of 'Could not be done whilst the Commonwealth Games were on and we have to wait for the Broadcaster to give us time on the transmitter. They are doing repair work [presumably the one for my area] but it should be in the next week or two'....... Deja Vu???
Has anyone tested the 1800T??
 
part unknown of the Update Saga.
Asked humax if it might be a early Xmas prezzie or belated Easter egg.
Reply just in "The update should be ready in the coming weeks but we do not have
a specific frame Im afraid"
Have to go just saw a pink elephant flying acrooss the sky!!!!!
 
part unknown of the Update Saga.
Asked humax if it might be a early Xmas prezzie or belated Easter egg.
Reply just in "The update should be ready in the coming weeks but we do not have
a specific frame Im afraid"
Have to go just saw a pink elephant flying acrooss the sky!!!!!

So the pink elephant I saw was real!!!. there is now an update. Looks like 2000t will now be a better machine.
Sorry to say, bit of a pessimist. So wonder what other faults are gonna come along.
 
Does this mean that AF123 now has the ability to acquire a copy of the Firmware?
If so does this offer the opportunity to dissect it with a view to a future CF?

I know AF123 probably already has enough to do, I don't have a 2000T myself but was thinking more to the future when the Fox HDR is no longer available...
 
The HDF can be examined, but with no knowledge of the signature authentication mechanism there is no way to create a new (or modified) one.
 
The HDF can be examined, but with no knowledge of the signature authentication mechanism there is no way to create a new (or modified) one.

Ah, the 2000T builds are signed are they? That's a pity. I take it the HDR/HD builds aren't which is how it was possible to start the custom firmware project.
 
Ah, the 2000T builds are signed are they? That's a pity. I take it the HDR/HD builds aren't which is how it was possible to start the custom firmware project.
Black Hole has commented here. The HD and HDR files are signed but the technical wizards found a way around it. These new updates are about 20% larger than the last HDR-FOX update which makes me wonder if there are extra authentication protocols built in? I wonder if af123 has had time to inspect the HDF files yet?
 
Black Hole has commented here. The HD and HDR files are signed but the technical wizards found a way around it. These new updates are about 20% larger than the last HDR-FOX update which makes me wonder if there are extra authentication protocols built in? I wonder if af123 has had time to inspect the HDF files yet?

Black Hole is very helpful (though I have argued with him a couple of times), but I do not take everything he says as the absolute truth. I hope nobody takes everything I say as absolute truth either. It would require a statement from whoever was involved in getting around the signing for me to be convinced of the facts.

I work for a company that signs all software we deliver. This is because there are various governments that require us to only supply software they have reviewed and approved. If it were possible for a third party to fake our signing and download any code they chose we would be in serious trouble. I am aware of the mathematical complexities of the signing algorithms and the difficulty of breaching properly done public key cryptography. If someone breached this for the HDR/HD then one or more of the following apply: 1) Humax used piss poor keys or algorithms, 2) someone at Humax leaked something they shouldn't have done, 3) someone in the HDR/HD community has made a mathematical breakthrough worthy of a Nobel prize and has rendered all security and encryption on the Internet worthless. Option 1) seems the most likely.
 
The HD/HDR Fox T2 and Foxsat HDR updates are indeed cryptographically signed but not using public key cryptography. Instead the signature involves symmetric encryption (AES128) with a fixed key applied to a 32-byte checksum . The checksum is computed using a slightly broken SHA256 implementation.

It looks like the new HDR-2000T updates use some form of PKI - the signatures are 256 bytes long - probably RSA.
 
The HD/HDR Fox T2 and Foxsat HDR updates are indeed cryptographically signed but not using public key cryptography. Instead the signature involves symmetric encryption (AES128) with a fixed key applied to a 32-byte checksum . The checksum is computed using a slightly broken SHA256 implementation.

It looks like the new HDR-2000T updates use some form of PKI - the signatures are 256 bytes long - probably RSA.

Ah, so the HDR/HD Fox T2 suffer form poor choice of signing mechanism plus a buggy implementation. That would be my option 1) as I predicted except it isn't even public key cryptography.

Sounds like the HDR-2000T could be a tougher nut to crack. But don't forget human nature, it's very easy to make mistakes which significantly weaken cryotography (or for the NSA to deliberately insert such mistakes). Weak keys is one of the most common.
 
The checksum part is buggy, nothing wrong with the encryption implementation. The bugs in the checksum algorithm just made it even harder to crack! As to whether it's poor choice, they probably considered it good enough to deter idle curiosity (and possibly stop corrupt updates from being loaded - although there are plenty of other levels of checksum for that). The key was that the bootloader code is accessible via JTAG and, with it, the encryption key.

It's likely that the JTAG interface on the HDR-2000T is disabled or password protected (one of the YouView requirements that they may have carried over to this model) although if all that's in there is the public key then that doesn't directly help anyway.
 
Out of interest, what sort of approach would be needed to have a chance of defeating the type of encryption described. Presumably some sort of brute force method is not feasible?

Edit. I didn't see af123's last post when I wrote this.
 
The checksum part is buggy, nothing wrong with the encryption implementation. The bugs in the checksum algorithm just made it even harder to crack! As to whether it's poor choice, they probably considered it good enough to deter idle curiosity (and possibly stop corrupt updates from being loaded - although there are plenty of other levels of checksum for that). The key was that the bootloader code is accessible via JTAG and, with it, the encryption key.

It's likely that the JTAG interface on the HDR-2000T is disabled or password protected (one of the YouView requirements that they may have carried over to this model) although if all that's in there is the public key then that doesn't directly help anyway.

There's a lot to be said for signing good enough that it prevents corrupt software being installed. It avoids people turning their boxes into useless doorstops if an update is corrupted somehow.

Indeed if the HDR 2000T uses properly implemented public key cryptograhy, JTAG access to the boot code won't help you in the slightest. Don't discount the possibility of mistakes in the implementation or use of it that make life easier though. And even if the code is correct, something as simple as an accidentally weak private key can make things easier. JTAG access would let you see both the encrypted data and plaintext of the same thing, and that's one of the first things you need to break crypto.
 
Black Hole is very helpful (though I have argued with him a couple of times), but I do not take everything he says as the absolute truth.
That is fair enough, but in this case the authentication for my comments is that I have been in this discussion since the very beginning of any custom firmware at all, and know its history.
 
Don't discount the possibility of mistakes in the implementation or use of it that make life easier though. And even if the code is correct, something as simple as an accidentally weak private key can make things easier. JTAG access would let you see both the encrypted data and plaintext of the same thing, and that's one of the first things you need to break crypto.
I can actually see a couple of possibilities for a way in but since I don't have a 2000 nor the time I'd need, I'll keep recommending the Fox T2 over the 1800/2000T. Extracting the filesystem and kernel from the update is easy enough (although the currently released humidify utility won't do it properly as the HDF archive contains a hole), but I doubt the box would accept a modified one.
 
Out of interest, a couple of days ago I tried to see if I could get the HDR-2000T software to run on the HD-FOX in BootHDR mode. It did not work, perhaps unsurprisingly. I knew that you couldn't just install the software directly on the box, but I know that the BootHDR installer somehow extracts the portions of the HDF file it needs and makes the HDR-FOX software run on the HD-FOX. How does this work? Do you have to give the software a spoof HDR-FOX signature?
 
Back
Top