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

Of course, then Apple will have access, too

[Anonymous Coward]

Which should help them in breaking any workarounds used, until a true valid unlock is achieved.

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?

[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.

Re:The Drawbacks?

[larry bagina]

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

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.

To what?

[noidentity]

I am not understanding title article what

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?