[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: HDHomeRun firmware downgrades



In article <Bp6dnZZw1_ZUGWHbnZ2dnUVZ_vamnZ2d@xxxxxxx>, ROBERT_GREEN1963@xxxxxxxxx (Robert Green) writes:
| "Dan Lanciani" <ddl@danlan.*com> wrote in message
| news:1341986@xxxxxxxxxxxxxxxxxxxxxx
| > In article <Q_2dnYZauKzHXmbbnZ2dnUVZ_rqlnZ2d@xxxxxxx>,
| ROBERT_GREEN1963@xxxxxxxxx (Robert Green) writes:
| > | "Dan Lanciani" <ddl@danlan.*com> wrote in message
| > | news:1341975@xxxxxxxxxxxxxxxxxxxxxx
| > | > Sometime after the version of firmware that I'm currently running
| > | > (20070131) SiliconDust has apparently added a lock to the HDHomeRun
| > | > to prevent the loading of firmware older than the current version.
| > | > Can anyone who has been following the versions tell me the latest
| > | > version I can load without being locked in?  SiliconDust won't say.
| > | > This lock makes it impossible to back out an upgrade if there are
| > | > application compatibility problems.
| > |
| > | Why would they do something that idiotic?
| >
| > I don't know.  They have now responded with two different explanations
| > (one about different "factory calibration" and another about a new
| > firmware format that has the property that if you were to be able to
| > downgrade to the previous version it could "damage" the hardware).  They
| > also said that there are two classes and it's just that you can't
| downgrade
| > between classes.  But that doesn't seem to agree with a message from a
| user
| > who couldn't downgrade from a beta to the previous real release, both
| > well into the second "class."  The user is unable to make recordings
| longer
| > than 38-40 minutes.
|
| Two different explanations?

Yeah, I would have been happier with one. :(

You can read the thread here:

http://www.silicondust.com/forum/viewtopic.php?t=4223

| The "damage the hardware" theory sounds just like the BS Apple is
| spreading about hacks to the I-phone rendering the phones useless after they
| issue a SW upgrade.

I have seen cases where embedded flash updaters failed in bad ways for
certain combinations of file size, leaving the device in an unbootable
state.  But in each of those cases the solution was to fix the bug in
the next release and to warn users about the bad ones (or bad combinations).
And of course, if you know about the problem in advance you could just as
well fix the bug (which has to be in the _new_ firmware) as add the downgrade
lockout...

| > |Are the DRM police after them?
| >
| > I asked that and they said no.  They have been adding various phone-home
| > "features" which are supposed to be off unless explicitly turned on, but
| > one user reported that the device was hitting his firewall with outgoing
| > requests 300(?) times per day even though he had never enabled it to phone
| > home.  The firmware also got a lot bigger recently with no obvious
| significant
| > increase in user-visible functionality.
|
| I'm amazed at how quickly HW and SW makers have assumed everyone has an
| Internet connection and will gleefully let both talk to whomever they
| choose.  When I worked in a classified lab, hooking a PC to the internet,
| even for a FW bump, would invalidate the unit's security and it would have
| to be completely recertified under the assumption that once it's connected
| to the WWW, all bets are off in terms of data security.  What do the "home
| phone" features do for the end user?  Or is this just more of nosey
| manufacturers wanting to know everything about their customers, even if
| those customers don't want to participate knowingly in their data collection
| efforts?

My understanding is that they are trying to create a channel lineup
database by combining information on what channels are available
in each area where an HDHR is operating.  I think this is used by
some software on the PC for PVR/guide functionality.  (I use my own
software so I'm not sure exactly what's supposed to happen.)

| > I find it hard to believe that they do not understand the debugging 101
| > rule that says that if a change breaks something the first thing you test
| > is undoing the change.  They claim that all firmware releases are
| completely
| > backwards-compatible so you never need to back out an upgrade, but this
| was
| > certainly not true in the past.  I think they must have a really good (for
| > them) reason for doing this and I'm concerned that it will turn out to be
| > a bad reason for users (beyond the debugging issue).
|
| I suspect you're entirely correct.  I would suspect they've added something
| to prevent recording of material broadcast with the "no copy" flag set, but
| they're not a recording device, per se, although it's obvious that HDHR
| owners will likely be recording programs as VCR owners have been doing for
| decades.

The primary use of the HDHR is as a tuner for various recording software,
so yes, I'd say it is likely that owners will be recording programs. :)

| > I was never really comfortable with the encrypted firmware (preventing a
| > quick "strings" from showing the latest command changes) but I understood
| > they want to protect their intellectual property from reverse engineering.
| > Taking that in combination with this new change, though, I must
| regretfully
| > withdraw my recommendation of the product...
|
| Perhaps someone figured out how to break their encryption so they've moved
| to a stronger protection algorithm.

That's a good possibility that did not occur to me, though I'm not sure
why anyone would care about breaking the encryption as long as the firmware
wasn't creating DRM problems.

| I just
| got a hi-rez LCD TV only to discover that nearly every HDTV signal I get on
| my Comcast connection is 720, not 1080, so I've got black bars everywhere!

The black bars aren't there because of a resolution mismatch but because of
the horrible mishandling of aspect ratios.  A number of my OTA ATSC stations
broadcast always claiming 16:9.  When they have 4:3 material (which is a
lot of the time) they pillar-box it.  When displaying this "16:9" content
on my 4:3 TV the default is to letter-box.  So I get black bars all the way
around a little 4:3 picture on a big 4:3 screen.  Fortunately, some devices
have an option to expand the 4:3 picture-in-a-picture to full screen.  The
other night I was confused that none of the usual selection of options was
giving me the expected result.  It turned out that they were broadcasting
actual 16:9 content letter-boxed in a 4:3 window which was then pillar-boxed
in their standard 16:9 format!

				Dan Lanciani
				ddl@danlan.*com


comp.home.automation Main Index | comp.home.automation Thread Index | comp.home.automation Home | Archives Home