Thursday, October 9, 2008

Unlock 3G, Jailbreak 2nd gen iTouch? Guess Not Yet.

From the iPhone Dev Team:

Disclaimer!! This is a purely technical post with no pragmatic use! There is no 3G unlock in this post. There is no iPod Touch 2G jailbreak in this post. It’s just a random technical post related to the 3G unlock.

We’ve been exploring different ideas with the 3G unlock, but this past weekend one of us hit a big snag. For whatever reason, all of our poking and prodding of the 3G baseband caused it to finally have a breakdown. After one specific exploit run, all of a sudden our baseband stopped responding to the OS. Even after multiple restore attempts, we were plagued with errors like this:

Somehow our software hacking had caused the baseband chip’s SPI bus to stop responding (so it looked like a hardware problem). Even though BBUpdaterExtreme reported the correct baseband version, it failed basic tests like memtest:

If you’re familiar with the baseband revision history for the 3G iPhone, you may have noticed that the above captures were done at the original 01.45 baseband. As dire (and hardware-related) as these messages sounded, though, there was a simple solution. We just updated to 01.46 and then downgraded again (because we can run unsigned code on the baseband CPU) to 01.45.

We tried to recreate the problem by using the same exploit over again, but it doesn’t appear to be reproducible (which is actually disappointing, as it might have been exploitable).

Anyway, there you go…a random, technical snapshot of dev team work.


Here are sources for ALL FIRMWARES
BigBoss & Planet-iPhones:
iClarified: Repo:
Niklas Schroder:
Ste Packaging:
Telesphoreo Tangelo:

NEW Cydia Language Sources

comcute&gecko (Estonian):
CZ&SK: http://csid. tym.cs/repo/
iPhone-patch (Bulgarian): (Chinese): (Hebrew):
Marcin Laber (Polish?):

Sources for Installer 4.0

Big Boss:
Rip Dev:

A27 Dev Team:
Norwegian Source:
iPhone Handheld:
Installer Apps:


Sources for Installer 3.1

Community Sources for Installer 3.11


BigBoss’s Apps and Things:
iSpazio Official:
RiP Dev (Kate, formerly Caterpillar):
Ste Packaging: (make sure you include the last /)

Other Sources for Installer 3.11

CopyCoders: (Network Apps)


AlliPodHax Source: or
AlohaSoft 1.0.2 -
AlohaSoft 1.1.1:
AlohaSoft 1.1.2:
Apple (not really Apple):
Apple Daily Times:
AppTapp Official:
Apogee LTD:
Blaze Official:
BigBoss Beta:
BlackWolf: (Extended Preferences)
Byooi Digicide: (Jiggy Apps)
CedSoft (iSnake/Bounce):
Chris Miles Repository (iSolitare):
Conceited Software Beta:
Conceited Software:

Death to Design:
Digital Agua:
Dlubbat’s Apps:
Ettore Software Ltd:
Fight Club:
Gogosoft Source:
GravyTrain ’s Vault: (Includes user submitted themes)
Hijinks Inc.:
hitoriblog Experimental Pack:
Intelliborn (Cydia Source):
iPhone Cake:
iPhone For Taiwan (SummberBoard Themes):
i.Marine Software (Caissa):
imimux Repository (Real Artist):
iPod Touch Fans:
iPod Touched:
iSwitcher (old):
iSwitcher (new) = MeachWare:
Jeremie Engel:
Jiggy Main Repository (Jiggy):
Limited Edition iPhone:
Loring Studios:
McAfeeMobile Dev Repository:
Makayama Software (CameraPro):
Mateo (BeatPhone):
McCarron’s Repo:
MeachWare (new iSwitcher):
Mkv iPhone Repository:
Mobile Stacks: (iBirthday):
MTL Repository:
Nuclear Design:
Polar Bear Farm:
Polleo Limited:
Private Indistury:
Pyrofer’s Projects:
R4m0n (iPhysics):
Robota Softwarehouse:
Sanoodi Repository:
Saurik’s Coding Toolbox (Cydia):
scummVM: (MobileChat)
Shai’s Apps:
Simek’s Graphic:
sipgate repository:
Slezak’s Stuff:
Soneso Repository:
SOS iPhone (ContactFlow):
Touchmod Team:
weiPhone (weTools/weDict):
Wizdom on Wheels (Common Website Links):
XK72 Repository: Releases:

Language Sources for Installer 3.11

German aXP:
Hebrew ?????:
Norwegian - iFon:
Polish - iPolish:
Polish - iPolish(1.1.2):
Russian iPhone.RU:
Russian iPhone ??-??????:
Russian Tools (in English):
Spanish Phyros iPhone-ES:

Ziphone can jailbreak and unlock 2.0 firmware

Zibri officially announces that his upcoming version of the oh-so-popular ZiPhone software is able to unlock and jailbreak firmware 2.0 successfully.

Zibri states:

“Firmware 2.0 will require a new iTunes version and a new “mobiledevice” framework. If it were for me I would not even bother to hack this version but I know many of you are going to upgrade so I will release a new ziphone version after the official release. I already patched activation (lockdownd) and unlock / Fake IMEI (baseband firmware).”

Some pre-release editions of iPhone OS 2.0 can already be unlocked and jailbroken with the use of Pwnage, a tool exploits a low-level vulnerability in the iPhone’s boot process to allow the installation of custom OS files. This has allowed users to install pre-release versions of the iPhone OS, such as OS 2.0, which normally require expressed authorization and a special signature from Apple.

Similarities and Differences between QuickPwn and ZiPhone

Here is what PlanetBeing said about the Similarities and Differences between QuickPwn and ZiPhone:


Both utilities jailbreak.

Payload medium

Primary jailbreak payload is placed into iPhone memory for both jailbreaks



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.


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.


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.


The creator of Cydia, Saurik writes a great tutorial on how

LayerKit -> CoreAnimation

Pretty much everything in LAyerKit has been moved to QuartzCore. LayerKit was really just the older name of CoreAnimation, and now most anything that was LK* maps to something similar in CA*. The names, however, aren't always the same. For example, LKCurrentTime has become CACurrentMediaTime.

UIFont/UIColor vs. CG/GS*Ref

Fonts and colors are handled by GraphicsServices and CoreGraphics, respectively. This used to be exposed directly in UIKit for 1.x (setColor: for example would normally take a CGColorRef). The new UIKit, however, has wrapped these primitives in Objective-C guises. Converting back/forth between these types is typically easy.

Using PrivateFrameworks

In order to keep application developers from using backend APIs of other applications (i.e., APIs that are going to change often and lead to unstable, brittle applications), Apple has moved most of their internal-use-only libraries into /System/Library/PrivateFrameworks, which is not normally on the link path. To add this back you need to pass this directory to gcc with -F.

Using Undocumented UIKit

The #1 thing to understand about UIKit is that Apple mostly didn't change it. For some unknown backwards compatibility reason they left in most of the 1.x classes, which means most of the code for 1.x can be compiled with only minor naming differences for the new platform. (Thanks goes to Jonathan Zdziarski (NerveGas) for figuring this out.)

UIAlertSheet - UIActionSheet
UIButtonBar - UIToolbar
UISliderControl - UIOldSliderControl
UISwitchControl - _UISwitchSlider
UIWebView - UIWebDocumentView

Alert/Action Sheet Dismissal

Pretty much all usages of dialog boxes involved dismissing the dialog box during a buttonClicked: event. Apple has renamed this to didDismissWithButtonIndex: and does the call to -(vod)dismiss.

Double vs. Single Precision

A few places in the original UIKit libraries Apple was using double's, even though pretty much everywhere they use floats. These places have been changed. One such example is [UIProgressBar setProgressfloat)].

Automatic Keyboard Support

Apple has decided that manually having to manage the keyboards that go with text input fields is stupid, and I must say I agree with them. Unfortunately, this means that code used to manually bring up keyboards is now dangerously out of date: you end up with two keyboards, only one of which normally works.

CoreGraphics vs. ImageIO

Most programs that need to draw things to the screen do not need to have complex data input/output from said graphics buffers. All of this file format and color munging code was probably taking up too much memory, so it got forked out to a different library: ImageIO. Examples: CGImageDestination/Source.


Previous, UIApplicationMain() was passed the metaclass object of a type that derived from the class UIApplicationMain, which it would then instantiated. Now it optionally takes the names of two separate classes that take on different aspects of UIApplication's functionality. If you pass the name of your old class for both these arguments you will get seemingly identical behavior.

mprotect(), NX, and max_prot

While this information doesn't apply to applications developed for JailBroken devices, it is still useful to understand that Apple has started taking measures to protect against arbitrary code execution. In addition to code signing, pages that were once writable can never be marked executable, which means no JIT compilers or dynamic trampolines (in other words, bye bye performance). This particular issue has been patched out of the kernel by Pwnage.