HDR-2000T delayed updates.

BootHDR just runs the humaxtv file that is pulled from the HDR hdf afaik.. nothing special like you're alluding to.
 
ChrisDaniels said:
BootHDR just runs the humaxtv file that is pulled from the HDR hdf afaik.. nothing special like you're alluding to.
Click to expand...
Just interested to know how it works and if it is possible to run the software on the HD-FOX to have a look at (play with) it. I wasn't alluding to anything: I certainly didn't think that this would magically crack the signature encryption issue.
 
Its pretty much as i said, it kills the existing humaxtv process and launches the replacement copy which is the HDR version.. the script will also set certain things up in the environment such as mapping the USB drive to emulate a built in HDD, but even without that, it runs..
 
MontysEvilTwin said:
Do you have to give the software a spoof HDR-FOX signature?
Click to expand...
No, only the firmware update process checks the validity of the update file by examining the signature (and rejecting it if the signature is wrong). Hence the need to create a valid signature in order to inject new code in the first instance, but not to just read the update file. The HD-FOX is directed to read the HDR-FOX update file and execute that, having already been modified.
 
Black Hole said:
No, only the firmware update process checks the validity of the update file by examining the signature (and rejecting it if the signature is wrong). Hence the need to create a valid signature in order to inject new code in the first instance, but not to just read the update file. The HD-FOX is directed to read the HDR-FOX update file and execute that, having already been modified.
Click to expand...

Signature checking is too slow to do it on every switch on. It's very computationally intensive.
 
Black Hole said:
Did I say it was checked at each switch-on? What would be the need?
Click to expand...

I was agreeing with you, and explaining why the signature is only checked on download. Why do it on every power on? Paranoia of course! Maybe someone tampered with the software etc.

Actually at work we would like to signature check on every power on for security reasons and to guard against flash corruption. But it takes too long. So instead we signature check on download, and calculate a CRC32 at the same time and store that. On every power on we check the CRC32 is correct, which there is enough time to do.
 
If somebody can spoof the signature for the download, wouldn't they be able to spoof it for the stored code? Once the download is validated, any hash scheme should be sufficient to protect against non-deliberate corruption (we used to use a simple checksum on the program store in the start-up self-test).

I'm intrigued AF reckons there may be a way in for the 2000T. What I don't understand is that if they are paranoid enough to use a secure signature in the first place, why not just encrypt the whole download?
 
Signing is to make sure the contents are what they are meant to be and no-one else can inject code. Encryption is to stop people being able to read the code in transit. They serve completely different purposes. Often you want both.

You use the phrase "non deliberate corruption". Now think about what other types of modification to the code there might be. For a set top box this probably isn't a concern, though YouView appear to be pointlessly paranoid. It's only telly.
 
Owen Smith said:
Signing is to make sure the contents are what they are meant to be and no-one else can inject code. Encryption is to stop people being able to read the code in transit. They serve completely different purposes. Often you want both.
Click to expand...
There are three levels of security:

1) Ensure the download is valid (not corrupted in transit) before committing to EEPROM. Humax only need a simple checksum or hash for this.

2) Protect against external parties spoofing a download. This is achieved by a cryptographic signature.

3) Protect against external parties reading (and analysing) the download. This could be achieved by message encryption.

Level 2 also achieves level 1, level 3 also achieves levels 2 and 1, so although you might want both there is no need to implement more than one. Level 1 is low-overhead, levels 2 and 3 require similar amounts of effort.

My point in post 48 was that if Humax are paranoid enough to require level 2, why not go for level 3? And if all they actually wanted to do was ensure the download is valid, why not settle for level 1? It seems to me that, having beefed up level 2 for the new generation, they have clearly responded to the amateur hacking and tried to kill it off, and yet still allowed the raw code to be read (at very little reduction in overhead).
 
Your level 1 ie. a simple checksum or hash misses a reasonably likely set of faults in the download. Multiple bit errors can cancel each other out, some cruder checksums don't detect lost or extra zeros etc. Given that a failed download renders the equipment potentially useless, I agree with Humax using a proper cryptographic strength signing algorithm to ensure the download is valid.
 
Yes I realise that about checksums, but there are well-established hash algorithms which avoid that difficulty.
 
I had another go at installing BootHDR but using Telnet so I could see what was happening. It did not work, as expected. I think the part of the HDF that is required is in a different location and this makes the process fail. I did notice though that the update lists system I.D.s for both the 1800T and the 2000T. The HDF files for each machine are also exactly the same size. Is it just the filenames that are different?
 
You must log in or register to reply here.
Back
Top