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

How is this going to work?

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:

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 t

Re:

I really hope Apple didnt know about the buffer overrun that allowed the first unlocking tool to work [unlockedip...orsale.com]

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

Re:How is this going to work?

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:How is this going to work?

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?

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?

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.

The Drawbacks?

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

Re:The Drawbacks?

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

Re:

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 App

Not safer

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

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

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:

I think that the type of people looking to unlock their phones are the type of people who would be interested in seeing how the unlock code works.

Re:

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

The process I went through involved jailbreakme.com & then installing AnySim from the installer.

To trojan that process, someone would have to hack the 'trusted source' I used or provide instructions that point the user to a trojaned source.

Why would a

Much safer

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:

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

Re:

No shit end users won't. Parties who are trying to figure out ways to unlock the iPhone themselves, will, however. Open Source does allow end users to participate in documentation, translation, sending crash dumps, etc. You're right, end users won't be

To what?

I am not understanding title article what

Re:

iPhone Dev Team

Gotta say that I'm a pretty rabid Slashdot reader, I also immediately took that phrase to mean Apple itself. Which seemed pretty damned strange, but then again every time that I use Finder I get the same feeling that some things Apple d

Re:

can we make this AC an editor?

Re:

I love how there's a verb used as a noun AND a noun used as a verb in that title.

Open Source

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 [google.com] 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.

This is very confusing

By "iPhone dev team" do they mean the team at Apple that develops the iphone? why would they get to decide if the tool gets released without input from their corporate overlords? or is it just a bunch of people in their mom's basement who have nothing to d

Re:

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