discourse: why do corporations allow "jailbreaking" and "flashing" at all?

[JdGordon]

People removing their software doesn't directly affect their bottom line... People buying their hardware to put different software on it does.

This is *only* true when they sell the hardware at a loss and expect to make it up on peripheral sales (like the PS3 and games at the beginning), but the only reason that happens is because the company doesnt have the market share and somehow needs to build it up, which means they are selling it at a loss with the knowledge that a *tiny* proportiion of the sales will never buy anything but the rest will still make it profitable.

Or in other words, companies have nothing to lose from quietly acknowledging hacker communities, sure they bang fists about it but it is all free advertising for them.

[Confuseling]

I think you've misunderstood what I was saying (which is partly my fault for phrasing it oddly...)

A sale is a sale, is what I was getting at. People buying the hardware to install different software affects the bottom line in the same way as people buying the hardware to take it home and stick it in the microwave at full power for twenty minutes.

Jus abutendi, and all that... 

Except, as you say, in the 'loss leaders' case. Makes you wonder whether the 'app store' model will lead to us being deluged by cheap (hopefully hackable) portable hardware... 

[cowonoid]

If he a-posteriori doesn't like the effect, his product has on his customers, he can try to bend the legal guidlines directly (that's what Apple tried) to prohibit it.

I'm not sure where Apple tried to change the law.  I'd like to be informed.

Oh, I derived that from the EFF link you sent me and in general from Apples attitude. Maybe "that's, what Apple tried" is kind of hard written. What I mean is more like "they would change the law to prohibit jailbreaking if they could"

I think you're saying they are a "special case" in that they are integrated products with the hardware and the software (firmware) tied together.  I say they are not.  They are general-purpose computers shipped with a custom operating system.

I would say: the firmware IS the DAP as well as the hardware. The software is not only a nonbinding suggestion, it should be the last word of the producer!

You have no firm footing for this line of argumentation outside personal belief.  Neither logical nor legal.

Okay, that's where our opinions distinguish very concretely.
If I imagine myself developing a DAP, I would like to develop the software as rigorous as the hardware. I don't differentiate between "adding a feature to the while-playing-screen" and "soldering an additional IC to free µC-pins"! And if I would say it's the hardware general-purpose *product* plus the custom software, then I also must say it's the custom hardware (and thus just a suggestion how to interpret the product) because people could also have enough know-how to see the hardware as customizable.
If BMW sells a car, it's not a general purpose bodywork with a customizable engine; (maybe the minority of car tweakers sees it like this) for the masses its just a car. Or the old cassette or CD players. It's a complete system, which is seen as customizable in respect of different cassettes or CDs.

It is just as ludicrous for Steve Jobs to tell me what I can do with my iPod as it for me to tell him what he can do with his spoon.

Don't missunderstand me: however both, car and cassette player *can* and are allowed to be modified!

Confuseling already addressed this, and while you appear to acknowledge his words, it appears to me you're dodging around them on the other hand.

But I don't. I stick to his words insofar, that I can do all the things I want to my property if I am not "hurting somone". What I am growing more and more curious about is

- the definition of the system limit of (for example) a DAP: "computer plays audio software plays music" or "audioplayer plays music"? What is the point of view dependent of? The technical qualification of my customers? If I am creative with my newly bought scissors, then I cut funny and artistic holes in a carpet. If I am creative with my DAP, I either can do the same (while hearing music) OR disassemble it and play doom on it!

- can I cause interpretations of products intentionally? How? Am I to prevent certain interpretations? How far reaches my responsibility if my product has the power to change guidlines instead of just being constrained by them?

- would my idea of securing the device work out?

EDIT:  I think this is the thrust of your query?  Can I paraphrase what I think you're driving at:
"Apple / Cowon / et al could 100% lock down the hardware they sell if they choose to, therefore the fact they do not implies they are "allowing" jailbreaking / flashing / hacking."

Again, I believe this premise is mistaken.  The problem is much harder that it appears to me you believe.
If you have a foolproof way to insure secure loading of firmware onto hardware which allows for firmware updating and a modicum of error robustness (real world needs) which is easy and does involve much effort (or money) there is a very well paying job waiting for you at your employer of choice.

If they can get their firmware updated, they can get hacked. I believe that has been proven a million times if you look at other devices as well as DAPs.

Come on, I could even train my grandmother in verifying digital signatures of e-mails! All the same I could implement it on my DAP, so that it just takes *my* firmware. And apps are nothing else than pieces of additional firmware, which can be signed, too. So the update feature cannot honestly be the hard thing to do, can it? And as for I know, there is no MP3 which can content malicious code and cause a buffer overflow! As well as the classic webbrowser, which only translates HTML code directly into lines and text. And if every app process is additionally embedded into a nice rights management... (I hope this wasn't a good idea which I could have sold!)

Corporations aren't monolithic entities - especially not the large ones. I suspect the engineers mostly want to create an interface not unlike Rockbox. The marketers tell them where to stick it, because they want a maximum of five menu options, "So your granny could use it". Some of the board want to lock down the device completely because what they know about hackers they've gleaned from Sandra Bullock films, some of them don't want to pay for the expense of trying to lock down the device when it's probably futile, and some of them have been persuaded by the engineers' argument that actually, having a few "unofficial updates" to your firmware isn't always such a bad thing...

So you think, it's not even that they don't care; their intention is just.... not yet decided. Internal, democratical delay of things..

I think if I would be Steve Jobs, I would be very happy if my device was not yet hacked. Both reasons would be okay for me: no one had the idea because of my OS being so good and/or having good security on the devices (which *I* could sell him for 1MIO$... Hello Steve, read this!!!!  )

[soap]

And as for I know, there is no MP3 which can content malicious code and cause a buffer overflow!

http://webcache.googleusercontent.com/search?q=cache:ZirKy2NefJIJ:tools.cisco.com/security/center/viewAlert.x%3FalertId%3D21022

[saratoga]

If they can get their firmware updated, they can get hacked. I believe that has been proven a million times if you look at other devices as well as DAPs.

Come on, I could even train my grandmother in verifying digital signatures of e-mails! All the same I could implement it on my DAP, so that it just takes *my* firmware. And apps are nothing else than pieces of additional firmware, which can be signed, too. So the update feature cannot honestly be the hard thing to do, can it?

Digital signing is fairly rare, but even so many devices that use it have been cracked. 

And as for I know, there is no MP3 which can content malicious code and cause a buffer overflow! As well as the classic webbrowser, which only translates HTML code directly into lines and text. And if every app process is additionally embedded into a nice rights management... (I hope this wasn't a good idea which I could have sold!)

I'm guessing you've either never looked, or else don't really understand what a buffer overflow is. 

[Confuseling]

So you think, it's not even that they don't care; their intention is just.... not yet decided. Internal, democratical delay of things..

I think if I would be Steve Jobs, I would be very happy if my device was not yet hacked. Both reasons would be okay for me: no one had the idea because of my OS being so good and/or having good security on the devices (which *I* could sell him for 1MIO$... Hello Steve, read this!!!!  )

I'm not even really saying delay, so much as a permanent balance of irreconcilable interests. I suspect that some engineer says "Our device is wide open due to exploit X! If we go to market like this, it'll be hacked within months!", some executive says "Well, that'll cost an awful lot to plug, and we're behind schedule already", some marketing strategist says "Well, our last player's figures suggest that 1% of our users actually bought the device specifically because they could install aftermarket firmware", and another engineer points out "And we only ended up fixing bugs Y and Z because we borrowed the solution from them..."

Someone or other then decides, after much head scratching, whether to budget for increased security, decrease it, or leave it as it is. Historically, no doubt, there was often an a priori assumption that hackers were evil brutes who ruined your carefully designed product out of sheer spite - and therefore that the only consideration was how much it would cost for the level of security you felt you needed. Nowadays, I suspect most companies are clever enough to see the whole thing more subtly - as contributing advantages and disadvantages to a complex overall product strategy.

As to the last bit - well, I'm inclined to trust the judgement of the programmers. If Apple could lock their systems up tight for a reasonable price, they certainly have the temperament to do so. They don't seem to have managed it yet...

[torne]

Come on, I could even train my grandmother in verifying digital signatures of e-mails! All the same I could implement it on my DAP, so that it just takes *my* firmware. And apps are nothing else than pieces of additional firmware, which can be signed, too. So the update feature cannot honestly be the hard thing to do, can it? And as for I know, there is no MP3 which can content malicious code and cause a buffer overflow! As well as the classic webbrowser, which only translates HTML code directly into lines and text. And if every app process is additionally embedded into a nice rights management... (I hope this wasn't a good idea which I could have sold!)

Loads of hackable devices sign their firmware and their application binaries. People hacked them anyway. Implementing these things *correctly* is very hard (see the 24kpwn exploit for the iPhone 3GS) and implementing them so that they cover all possible attack vectors is basically impossible (see the original free60 exploit on the 360, which relies on the fact that while executables are signed, game data isn't unless the game developer chose to do so, and "GPU shaders" were considered game data even though they have the ability to write to RAM). Even if you think you've done everything, there are certain people who are willing to devote heroic efforts to cracking a sufficiently interesting device (see the PS3 hypervisor glitch exploit, which relies on interfering with the power supply to the processor at *exactly* the right moment to cause it to miscalculate whether a signature is valid or not - it only succeeds one time in many thousands, but the hacking device can just try over and over until it wins).

You say an MP3 can't contain malicious code, but it clearly can; many of the exploits on modern devices are buffer overflows in things like JPEG decoders or font renderers. Also, a web browser is a really huge attack target, even if it doesn't support any kind of scripting: web browsers use loads of libraries to display different image/sound/etc formats, any one of which might have a bug in.

[Bagder]

Come on, I could even train my grandmother in verifying digital signatures of e-mails! All the same I could implement it on my DAP, so that it just takes *my* firmware.

Many have done so. They have been hacked anyway, using many different approaches. Here are three:

1 - the digital signatures could be removed/worked around (Sansa v1 Rhapsody style)

2 - the digital signature had a known mathemathical flaw not taking into account by the manufacturer (Sansa e200 v1 style)

3 - by triggering a buffer overflow in the original firmware that then exposed the correct digital keys

And as for I know, there is no MP3 which can content malicious code and cause a buffer overflow!

That's... just.. wrong. There are MANY such vectors. Every single music file have custom data embedded that can potentially overflow a buffer.

I think you need to do your homework a lot better.

[cowonoid]

Thanks, saratoga, torne, Bagder for the technical explanations. I will read about the links you sent / the exploits you mentioned soon to understand it better.

How I said, I am not a computer scientist. I find it just very weird, that producers can't produce a flawless system even if they are in full control of the whole creation process. From what you're telling, it appears to me that producing a completely secure system is like producing secure safes. With a big enough saw (and enough courage, motivation, fun) you can penetrate even the hardest wall..

Nevertheless I still don't understand how a x-bit asymmetric-cryptography-signed file can be fudged without having the private key? They don't even have the public key! Coupled with a 24h "try again"-interval, if upload was unsuccesfull, they couldn't find out by bruteforce. Additionally one could equip each system with a different private/public key couple. They're then assigned to the serial number of the device and the firmware update is automatically signed on download from the vendor page.

Regarding buffer overflows and arbitrary code execution:
squelching all security bugs would be possibly the wrong (and impossible) apporach. What I was thinking of: the whole system hasn't write permissions to the place, where the programs run from. There's an independent micro controller, who is responsible for signature checking and flash-writing tasks. He has no attack area because the only information input is the firmware!

Or one could even utilize a watchdog like principal; encapsuled in a seperate µC, which will request an "act of faith" - lets say - every 10 minutes. The main system must then send "a signed checksum of all the stuff, going on on the device" to the watchdog. If this is not kosher to the watchdog, he simply shuts down the power line. It's like "corporation staff visiting your device every 10 minutes for a maintenance".

All the ideas are kind of introducing a "supervising level" to the device; if it's not allowed to sent Apple security in persona to check all the devices, you just put it *into* your device.
I find this idea exciting! Basically it would be like the in-persona visit, just that you put the will/intention into a piece of chip. Thus it becomes legal; it's inside of the generally accepted system limit of a DAP. Apple staff knocking on your door is not.

[soap]

1 - On public key cryptography:  That's all well and good, but processors don't execute cryptotext, they execute plaintext.  The firmware may be encrypted when stored, but is decrypted when run.

Either the firmware is stored in plaintext on the DAP, or the DAP itself must have the key (in order to decrypt the firmware before execution.)

This is the classic struggle, you are selling the end user both the lock and the key, you're just trying your best to hide the key from them.  It MUST be there, though.
 
2 - On a watchdog.  If the watchdog controls behavior by controlling the power lines... bypass it and feed power from somewhere else. 

This is no different than most software copy protection schemes, a tacked-on "watchdog" routine which disables the software if the dongle / authentication server / CD-check isn't found.  All these sound great!  How do you fake a cryptographic challenge and response dongle?  How do you fake a cryptographicly sound authentication server?  How do you fake a proprietary optical disc?

You don't!

You snip out the watchdog.

[cowonoid]

1 - On public key cryptography:  That's all well and good, but processors don't execute cryptotext, they execute plaintext.  The firmware may be encrypted when stored, but is decrypted when run.

Either the firmware is stored in plaintext on the DAP, or the DAP itself must have the key (in order to decrypt the firmware before execution.)

This is the classic struggle, you are selling the end user both the lock and the key, you're just trying your best to hide the key from them.  It MUST be there, though.

Oh, the firmware is decrypted from the beginning and is readable by everyone! Only the device won't take the file if the signature, coming with it, is not fitting to the content. And a fully understood firmware is worth nothing if you can't alter it.
For that, it's necessary for the device to "encrypt" at least the signature and thus it has to have the (public) key, thats right. You would give it to the customer, but inside of a read-only filesystem, which is completely locked up. (Even if you could get the public key, you wouldn't have the private key to make own firmware versions trustable for the device..)

2 - On a watchdog.  If the watchdog controls behavior by controlling the power lines... bypass it and feed power from somewhere else. 

Bypass the watchdog and manually power these little smd copper lines? For 99.99% of the customers this would mean to give it away to an electrician and even he would find it hard if he had to solder a wire to the trace in the middle-layer of the board which leads to the power pins of a BGA package.

[soap]

This has been attempted and failed.  This has been attempted and succeeded.  The difference between success and failure can be strongly correlated to the effort put forth by the attackers.  It appears to me you're waving your hand and saying "this can be done in a foolproof manner" and while theoretically that is true, in practice it is not.

Bypass the watchdog and manually power these little smd copper lines? For 99.99% of the customers this would mean to give it away to an electrician and even he would find it hard if he had to solder a wire to the trace in the middle-layer of the board which leads to the power pins of a BGA package.

Yea, there is no market for console modchips. 
And as I hinted, you don't always need to physically bypass a watchdog.  A watchdog is operating on inputs which can be, and have been, faked.

[TexasRockbox]

I suppose the challenge of "getting out of jail" has fueled the demand.  There are plenty of programmers "out there" who seem to be more than willing to program their own devices.  One would think Apple, Microsoft, Cowon, Archos, etc. would try to encourage that activity and incorporate what is learned into the next generation of devices.  Guess not.

I guess it's Apple's worst nightmare that the iPod 5.5g hardware (and others) have survived well into 2010 -- not quite as disposable as they had hoped!