iPhone Dev Team to Open Source Free Unlock

An anonymous reader writes "In an effort to keep up with changes from Apple at a faster speed, the iPhone Dev Team is considering open sourcing AnySIM, the free unlocking solution for the iPhone. In a chat with Gizmodo, iPhone Dev Team member Sam said that this move could 'open a lot of possibilities for the future,' mainly in terms of the speed of the updates and avoiding sloppy and possibly dangerous binary patches. They are now looking for community input to get the project started."

Comments

How is this going to work?

[Trintech]

I could be completely wrong about this but I though that the unlocking programs utilized exploits, buffer overruns, etc to unlock the iPhone. If thats the case, how is releasing the source going to help this project? Won't Apple just read the code and release updates keeping the program from working?

Re:How is this going to work?

[4D6963]

Won't Apple just read the code and release updates keeping the program from working?

Yeah, because until now Apple had no idea at all how that anySIM thing worked. Now that they'll be able to access the source, they'll like instantly know how to prevent the hack from working.

You see that's as if makers of cutting pliers published the plans of their products, then car makers would as soon know how to prevent thieves from cutting the wires of a car in order to steal it.

Re:How is this going to work?

[thePowerOfGrayskull]

Quite possibly. Puts us OSS fans in a quandary, doesn't it? On the one hand, proprietary software is Teh Ebil. On the other hand, keeping this proprietary allows to keep a platform pseudo-open. It's really no choice at all though - either you believe in the principles FOSS or you don't. If so, then this should be released. If not, it should not. If you find yourself on the fence, perhaps you're not as firm an OSS believer as you liked to think. (Note: 'you' here is in the plural sense, not directed at parent who didn't express an opinion one way or the other...)

Re:How is this going to work?

[Trintech]

I really hope Apple didnt know about the buffer overrun that allowed the first unlocking tool to work

I can appreciate your point that Apple will never be able to keep people from reverse engineering the iPhone but saying that Apple won't be able to do a better job of preventing this if they know exactly how the "crackers"(not sure if thats the right word for the phone world) are going to accomplish their goals is highly unlikely.

Re:How is this going to work?

[arivanov]

Some of the exploits have been public for ages and Apple knows that these are the exploits used. It still does not fix the underlying buggy code for some reason. They are not the only ones as PSP and other small devices have a similar history of not caring about security fixes. On a second thought I am not surprised. People in corporate environments tend to check in an open source lib in the local repository once (often as a binary) and they are not bothered to follow it for ages after that. Following external components and updating them for stability and security is the exemption, not the norm.

Re:How is this going to work?

[DaleGlass]

Right, because Apple is a tiny poor company that doesn't have the resources to watch the traffic over the wire, or to disassemble the program. They couldn't possibly figure it out without the source.

Re:How is this going to work?

[mrsteveman1]

If Apple doesn't have the source already, they must have found out about that exploit somewhere.......the source had nothing to do with it. Closed source is not going to stop Apple from running the latest binary unlocker on a test machine and watching what it does.

The Drawbacks?

[TubeSteak]

Wouldn't this make it easier for Apple to break AnySim?

Re:The Drawbacks?

[larry bagina]

break it? You mean fix buffer overflows and other vulnerabilities? That would be a good thing.

Re:The Drawbacks?

[DECS]

How persuasive would that be? It sounds like saying the popularity of DVD rip software "will eventually win over the labels to embrace the idea of piracy."

Are you suggesting that some profitable new market will emerge from FOSS users that will convince Apple to change its sales strategy to target "people who don't want to pay for things" as opposed to "people to pay a premium for higher end products"?

Without a service subsidy (and it is a subsidy, even if AT&T is paying Apple rather than the customer), can you imagine a scenario where the iPhone would cost $399 unlocked? Does it look like any other new $399 phones? Which $399 phones have 8GB of RAM and a large touch screen?

The only phones I can see that are comparable hardware wise with the iPhone are high end phones from Nokia, HTC and others which cost around $800. Sure you might be able to find a discounted model that has been around for a year (and has already made its "new" profit) and has an upfront subsidy that reduces the price to the consumer, but there are no $399 touch screen wireless computers that can be manufactured new at a profit. Apple is clearly getting AT&T to subsidize the cost of hardware for consumers.

That being the case, how will Apple be convinced by a surge of interest behind making it easier to cheat the company out of its AT&T subsidy and destroying its bargaining chip with service providers? I'm sure you're all about freedom, but how is it you expect Apple to be persuaded here?

iPhone Grabs 27% of US Smartphone Market

Not safer

[SuperBanana]

this move could 'open a lot of possibilities for the future,' mainly in terms of the speed of the updates and avoiding sloppy and possibly dangerous binary patches.

Ugh. This is just another version of "open source code is more secure because you can review it and compile it yourself." Open source code can be more secure, because a qualified individual can conduct a lengthy security audit, and maybe catch some malicious or insecure code."

• virtually nobody that uses the code will be even remotely qualified to even understand how the code works, much less be able to tell if it'll screw up their phone.
• Opening development to more people makes the chances of someone SUBMITTING (note, I said "submitting", not "successfully getting away with putting malicious code into an official release) go up; now the few people who know what they're doing have to spend a lot of time reviewing code not just for correctness but malicious intent, something they may not be qualified to do.
• Releasing the source code now makes it exceptionally easy for people to trojan the code and release a compiled version. The bar has been lowered from "knows assembler and iPhone internals" to "is decent with C."

Re:Not safer

[vertinox]

virtually nobody that uses the code will be even remotely qualified to even understand how the code works, much less be able to tell if it'll screw up their phone.

All it takes is one person who knows how to read the code to make a rambling blog post detailing the vulnerabilities and submit it to Slashdot.

Then all the people who didn't know how to read code will now know and the code reader will have his share of adsense for the month.

But more seriously... When I have doubts about a software package, I just hit it up in Google to see if there has been wide spread complaints or other issues.

As far as your other issues you bring up, in a closed source scenario what is to prevent a malicious person from just renaming any old trojan that they compiled to be the same exact size as the closed source exe and putting up a torrent of it? Sure it won't work at all as far as running the program, but it will do what they need to do. (Checksums anyone?)

Even if a person uploads something maliciously into the main package, someone will eventually notice and with more eyes the faster this will happen. Of course this also helps out if the original coder is the one who is malicious.

Re:Not safer

[palegray.net]

Thank heavens we have a ton of security firms who make a living finding holes in both open and closed source software and publishing the results. Of course, their work is just a bit easier if the source is available, and it's just slightly easier to write a patch that solves the problem ;). I guess my main point is this: it isn't just the average user who looks at the source code for high-profile projects.

Re:Sold out?

[QuietLagoon]

Yikes, I posted the comment on the wrong thread. this is sooooo embarrassing....

To what?

[noidentity]

I am not understanding title article what

Open Source

[BigZaphod]

The iPhone dev community is largely open source already and the closed nature of some of the hack projects has always bothered me. I've released all of my code from my iApp-a-day project which took place last month, and a lot of people are learning from it and building better things now. I know I'd be interested to see how something like AnySim actually works under the hood. It's one thing to have an academic knowledge of how these things work, but quite another to see and experiment with it first hand.

Much safer

[bit01]

Enough with the "closed source is inherently superior" propaganda. Whether you like it or not open source for the user is everything that closed source is. Plus the source is available.

The idea that "closed source" is magical security pixie dust needs to die.

this move could 'open a lot of possibilities for the future,' mainly in terms of the speed of the updates and avoiding sloppy and possibly dangerous binary patches.

Ugh. This is just another version of "open source code is more secure because you can review it and compile it yourself."

No, it hasn't. Try to understand that it's not just you reviewing the code but potentially many other parties apart from the originator. Are you trying to tell us independent third party review is not a good idea?

Open source code can be more secure

No, open source is likely to be more secure. Because many independent third parties can review it. Not just a vendor who has a commercial, ego or "not-enough-manhours" incentive to hide mistakes.

, because a qualified individual can conduct a lengthy security audit,

No, because many different individuals with many different levels of expertise can conduct all sorts of audits, security and otherwise, and in addition use the code in ways the the original author[s] never even envisaged.

and maybe catch some malicious or insecure code."

Better than no chance at all.

* virtually nobody that uses the code will be even remotely qualified to even understand how the code works, much less be able to tell if it'll screw up their phone.

So, out of a population of billions that leaves a population of thousands, or more, who are more than qualified to look at it. Think the statistics.

* Opening development to more people makes the chances of someone SUBMITTING (note, I said "submitting", not "successfully getting away with putting malicious code into an official release) go up; now the few people who know what they're doing have to spend a lot of time reviewing code not just for correctness but malicious intent, something they may not be qualified to do.

Malicious code is a strict subset of incorrect code. You check all your code for correctness, right? If you're not qualified to do that then you're not a programmer.

* Releasing the source code now makes it exceptionally easy for people to trojan the code and release a compiled version. The bar has been lowered from "knows assembler and iPhone internals" to "is decent with C."

No, it hasn't. Let me know when you've managed to break code signing and vendor repositories. Every binary package I use was either compiled/signed by the vendor or compiled by myself from vendor signed source code.

---

I want a free and open market. Do you?

Re:Much safer

[TheSeer2]

The idea that "open source" is magical security pixie dust needs to die.