Before yellowsn0w, I used the “Virgin-Sim” sim proxy, and it worked quite well with T-mobile USA. When yellowsn0w was released on New Years Eve, I disregarded reading any forums and continued to restore my iphone to 2.2 (I was at 2.1) and install yellowsn0w. To my disappointment, it was a pain to get working (multiple reboots, airplane mode toggling, and sim removal and reinsertion).

yellowsn0w version 0.9.6 has seemed to solved most of the problems others and myself have experienced. No longer will you have to remove or insert the sim or toggle airplane mode to get signal. The Dev-Team is still working on issues with Sim Pins and such, but it cannot be long before they crack that problem. Unlocking the iPhone 3G can’t be any easier:

1. Restore your iPhone to version 2.2 (Not needed if you are already at 2.2)
2. Use Quickpwn to jailbreak your iPhone
3. Load up Cydia and add the yellowsn0w repo: Cydia source: http://apt9.yellowsn0w.com or Installer repo: http://i.yellowsn0w.com
   
4. Install yellowsn0w
5. Disable 3G and Data Roaming in Settings -> General -> Network (Step is mainly for T-Mobile USA whose 3G bands are not compatible with the iPhone 3G’s)
6. Reboot the phone and you should have signal. I have tested yellowsn0w on my 4 year old T-Mobile Sim and a half year old sim, both work perfectly.
7. If you have T-zones, you can get unlimited data by entering the APN: epc.tmobile.com in Settings -> General -> Networking -> APN

I was going to write up a guide and summary for the Sim-proxies\turbo sims that did work with the iPhone 3G, but now that is not necessary with a soft unlock. Remember, when a new iPhone 3G firmware comes out, do not upgrade right away. Wait until pwnage from the Dev-Team to disable the baseband update, or a version of yellowsn0w that does work with the new version of the baseband.

Kudos to the Dev-Team, thank you for this Christmas\New Years gift!

From the dev team blog:

3G Unlock

We have been working hard on a few other things. The main one being the 3G unlock codenamed “yellowsn0w”. This is now completed and is currently being packaged into a user-friendly application with the simplicity that you see in QuickPwn or BootNeuter.

• The target release date for the unlock is New Year’s Eve 2008.
• This unlock method is available to iPhone 3Gs that have 2.11.07 (FW 2.0 – 2.1) baseband or earlier, we did warn you.
• You can tell what version baseband you have by going to Settings->General->About->Modem Firmware
• The unlock requires a jailbroken 3G iPhone.  It’ll be installable via Cydia and so it doesn’t matter if you have a Mac or PC.
• Please refrain from updating your baseband, regardless of what version you’re at.  We’ll have complete directions on New Year’s Eve.
• We’ll stream a live demo of the unlock before Christmas (see the update at the end of this post)

Planetbeing wrote an outstanding post on the simularities and differences on pwnage, quickpwn, and ziphone. It is a very interesting read. The original post was here but you can read it here as well (posted with permission).

Similarities
Jailbreak

Both utilities jailbreak.

Payload medium

Primary jailbreak payload is placed into iPhone memory for both jailbreaks

Differences
Technique

ZiPhone uses, as the root filesystem device, a pseudo-device that provides a window to an arbitrary section of memory. This memory is not allocated or otherwise reserved by the operating system and hence will be used by other random processes in other random ways and will become more and more corrupted with every CPU clock cycle. The only safe way to use this is to mlock all memory used by the jailbreak binary as soon as possible, and then use data previously uploaded to flash. Anything else will cause either the jailbreak binary to crash at random moments or cause random data to be written to flash. I am not sure why Zibri elected not to implement ZiPhone in a safer fashion.

QuickPwn uses the same mechanism that Apple uses to send its update ramdisk. This memory is both allocated and reserved. It will not crash at random moments, or give you repeating BSD root errors. This is the way the XNU kernel is designed to use ramdisks.

Longevity

ZiPhone hinges on a BUG in iBoot that was quickly fixed by Apple.

QuickPwn uses an iBoot FEATURE that Apple cannot remove without rewriting their own software and undergoing lengthy QA. Even if Apple did change the architecture, it would be straight-forward to simply mimic what they do and adapt to it. The reason QuickPwn can do this is because it relies on a hardware exploit to bootstrap into this phase. Apple cannot fix this problem without changing the manufactured hardware.

Elegance

ZiPhone modifies an existing Apple ramdisk and ships it as a complete set.

QuickPwn contains all-original code and features a very tiny bootstrapper that allows it to use libraries and code that’s already on the iPhone.

Not only does ZiPhone’s distribution of Apple’s binaries violate copyright laws, it also takes up a large portion of room on the ramdisk that could be used for the payload. Keeping its existing algorithm, ZiPhone would never have been able to install Cydia, for example. The maximum feasible ramdisk size is 32 MB; Cydia takes 13 and Apple’s library take up a significant amount. With some work, Zibri could possibly make it just under the 32 MB limit, but with the large number of files in Cydia, and the large size of the corruptible area of memory, corruption would be inevitable.

Some history / A personal note
Zibri claims to have “invented the ramdisk jailbreak”. Even if this were true, it would have as much relevance to QuickPwn as the 1.0.2 jailbreak does: The techniques used are entirely dissimilar. Not a single step in the process is the same.

However, this is not even true. Before Zibri left, we already had a prototype ramdisk jailbreak in our SVN (which Zibri later leaked parts of). It was written by myself and stored under the very obvious name of “ramdisk-jb” and it contained a modified version of a launchd written by Turbo (who should be considered the father of the ramdisk payload). It basically untarred a SSH installation onto the rootfs. It was rudimentary, and required a lot of work to get up to production standards.

While it’s obvious that Zibri has picked every bone of that SVN repository clean, I am puzzled why he did not learn from that example source code. It had mlock and it was written in proper C, unlike the rather make-do replacement of launchd with sh. Perhaps he did not understand the code.

A week before his release, we became aware that Zibri was going to write a ramdisk exploit. We considered racing him to it, but we were constrained by the fact that we had already publicized one working method of jailbreaking: The oft-loathed 1.1.3 soft-jailbreak, which we considered perfectly acceptable until the release of the SDK (we were not aware at the time the SDK release would take so long). In addition, 1.1.3 was a minor update and there was no reason people could not stay on 1.1.2 for awhile longer. The issue is that while a ramdisk jailbreak would certainly be easier and better, we would be burning this great exploit that allowed us to reliably decrypt ramdisks (which we had no other way of doing at the time).

Therefore, we chose not to build our own implementation and instead pursue Pwnage, a longer term project. It was ironic months later that Zibri came to flame us out about releasing the dual-boot method, accusing us of burning the exploit. It was amusing because it was so much lower value than the ramdisk exploit, which he was responsible for burning and really had no future prospects because of pwnagetool.

We are aware that the dual-boot method was the last remaining bit of non-public knowledge from our SVN that he had, and my belief was that the flame was caused by his soreness at losing his last chance at remaining relevant after the pmd (”ramdisk”) vulnerability was patched.

Pumpkin from the iPhone Dev Team posted his thoughts. I found it interesting and posted it here for you all to read. It does a nice job explaining the situation with Zibri as well as how pwnage and iPhone 2.0 hacks work. Enjoy.

The following opinions are mine, and not those of the DevTeam as a whole, although many members agree with me:

Free thoughts…

There’s something that’s been on my chest for awhile, and it’s been bothering others on the team as well. The name of this particular thorn in our sides begins with the letter Z and ends with “ibri”. Yes, I’m sure all of you are rolling your eyes at the “drama” we hacker “kids” are stirring up, but I’m sure if you had your work taken without permission, you would feel the same way. It’s particularly galling that he is still spreading FUD on his blog in an attempt to save face. I’m going to try to address some of them in this post.

Zibri implies that our jailbreak is not “real”, saying instead that our release is a “software upgrade, total internat [sic] firmware modification and custom firmware”.

For him, a “real hack” works in a few minutes because it only needs to modify a few bytes here and there.

When Pwnage 1.0 was released, it was indeed the ultimate hack for the iPhone/iPod Touch. Never before had the devices been under the user’s control from the very bottom up. Prior, less sophisticated jailbreaks were still subject to the whims of the kernel, which couldn’t be modified because the bootloader checked its signature and refused to boot if it was incorrect.

Back in those days, the definition of “hack” above was still a feasible one, as the chain of trust ended at the kernel. Once you gained write access to the root filesystem, you could run arbitrary programs and make patches at will to many system components. Indeed, many such patches were needed, to make activation allow unapproved SIM cards, and to make Springboard display unauthorized apps.

Fast forward back to the present, and you’ll see the situation has changed. Solutions that using a ramdisk simply made a change or two to the filesystem now must contend with the mighty kernel’s signature checking of all installed apps and libraries. Mounting the root filesystem and modifying /etc/fstab to make it writable is quite alright, but the moment you make patches for activation or anything else, the kernel will refuse to run the modified programs, unless you can somehow steal Apple’s private signing key. Furthermore, such a jailbreak would be essentially useless because the system would refuse to run any of your custom software (such as Installer.app or Cydia), again because of the lack of signatures on it.

Given the above situation, it becomes clear that if you want to use 2.0 for anything but screenshots, you either need to get ahold of Apple’s signing key (start preparing your army now) or you need to patch the 2.0 kernel. Hard as we tried, we couldn’t find much of an army, so we took the latter approach.

We adapted our Pwnage technique to the 2.0 firmware, using a new unreleased exploit that we’d been keeping to ourselves, in the hope that Apple wouldn’t patch it. This allows us to cut the signature checks out of the device bootloaders, allowing us to remove signature checking from the kernel, and enabling you to run all the custom software and patches you please.

Please note other than my facetious army suggestions, patching the bootloaders is the _only_ way to get a functional jailbreak for 2.0. Under the aforementioned definition of “real hack”, there is no such thing as a “real hack” for 2.0. I hope you agree with me by now that Pwnage, the exploit it uses, and its subsequent obliteration of the device’s chain of trust, is a “real hack”.

More FUD is spread by this undying rumor of “Palladium” (or TPM) being used fully on Apple’s devices, making it impossible for you “to play online with legit buyers.” This is nothing but uninformed nonsense, and while there is the potential for some definition of trusted computing on iPhone and iPod Touch, Apple is not using it, and they have no way to remotely distinguish your pwned device from a legitimately activated one. This should have been obvious from our examples of running App Store applications next to our custom ones, but “obvious” is a very relative term.

On an unrelated note, I and the others take issue with Zibri’s definition of open source. No, Linux distributions are not stealing, but our work was not released as open source, with any kind of permissive license, so the open source he brings into the discussion is entirely irrelevant. He took our work, our private exploits (such as the unreleased one we were able to use for Pwning 2.0), and without our permission (trying to defame us with fake comments, no less) used them in his work, that he made significant amounts of money on. He did this not by selling “his work”, but by portraying himself as the reasonable “dev” who fought against the tyranny of the dev team and Apple, and requesting donations to his “cause” (recall his older iphone-elite.googlecode.com and his self-righteous bashing of the dev team for accepting donations; funny how principles change). Furthermore, with his millions of hits and occasionally obscene ads, he made his site into a complete money machine. So although he did not sell our work, it is more than fair to say that he made plenty of money from it.

And as to his most recent update, I’m not really sure what to say. I’d call it the swan song, but that would imply he was a swan, which is certainly not my intention. Maybe the chicken song would be more appropriate. ZiPhone was “developed” 9 months after the iPhone release, so he’s justifying his lack of releases now, okay. Once again he pushes the “real hack” idea, which we hope we’ve already pounded sufficiently into the ground above. We’re not sure how the fact that we were so popular it took down multiple unmetered gigabit servers is a point in his favor. We’ve had close to a third of his total visits since last week.

I want to dedicate a special paragraph to something that’s been bugging us for a while, too. The myth that ZiPhone never harmed a phone. Certainly, we all know that iPhones are almost impossible to brick, but flashing unmatched fls/eep pairs to the baseband is plain irresponsible on Zibri’s part. Does he not care about messing up phones, or does he simply not know better? And the laughable WiFi fix he released for issues that he called “user error” (actually a consequence of the above design choice) where he unconditionally set every ZiPhone WiFi MAC address to 0:Z:i:b:r:i? How did he expect that to work? It doesn’t take a networking genius to figure out that two such phones on the same network would cause havoc, and indeed it did.

The following few “facts” on his blog are just more FUD. Our tools can’t kill iPhones, because the only way to kill an iPhone through software (and even then just the radio) is to flash an incomplete image as the S-Gold bootloader. Apple cannot remotely kill pwned iPhones because as I mentioned earlier, it has no way to detect which iPhones are pwned.

I’m not sure why he goes on to say that you should be satisfied with Apple’s AppStore. It certainly contains many good programs, but to quote Zibri just a couple of weeks earlier:

As of today you will have 2 choices:
1) Believe in the community and don’t upgrade to 2.0
2) Say goodbye to Installer and freedom and upgrade.

So are you suggesting we say goodbye to freedom now? I guess we can’t expect much from someone who made a reputation for himself by denouncing the devteam for accepting donations (not even soliciting them) and who now has a website full of ads, exhortations to donate, and very little content? Now we have given you a nice opportunity to upgrade to 2.0, use the AppStore _and_ use community apps. If he really wanted the good of the community, why is he not recommending it?

I would normally just ignore his entries, but as many still look at Zibri as an authority in the scene, I felt the need to dispel some of the FUD he was spreading, and finally denounce his pathetic attempts to stay relevant. Posting the latest root filesystem key after we release PwnageTool? PwnageTool exposes all the keys right within its plist files. And if he knew about the DFU exploit all along, as he implies, why didn’t he take advantage of it? We would like to see him write up an article on how it all works, just to prove that Zibri knows all.

Thank you for your patience reading this. We will continue working hard on providing quality hacks and software, but please, to anyone who’s tempted, stop spreading bullshit about us and our work.