iOS 5 Untethered Jailbreak: Pod2g Reveals Key Details on Corona, Hinting at iOS 5.1

Thanks to the Chronic Dev Team and the iPhone Dev Team, now we have utilities like Redsn0w and Corona that enable an untethered jailbreak on A4 devices running iOS 5.0.1. But it was Pod2g, who was actually responsible for discovering the untethered exploit that later paved the way for the long-awaited untethered jailbreak utilities.

The A4 device exclusive exploit has already been made public, but very few are aware about what really goes behind the entire process. In a blog post on Monday, Pod2g revealed key details related to the development of the untethered iOS 5.0.1 jailbreak and Corona. He explained what Corona is and how it functions.

What is Corona?

A jailbreak utility, Corona was designed by the Chronic Dev Team. It allows users, with a tethered Jailbreak on an iPhone 4, 3Gs, iPod Touch 4, 3, or an iPad, to have an untethered Jailbreak by installing a package in Cydia.

The Chronic and the iPhone Dev Teams initially relied on a set of userland exploits to infringe the strict iOS security structure. However, after Apple had patched all the pre-existing userland holes, Pod2g and others had to rummage around for other ways to make the untethered jailbreak for iOS 5 a reality.

In addition, in iOS 5.0 and up, data pages need also to be signed by Apple for the loader to authenticate the binary, something that made the jailbreaking process even more complicated.

Here are the rest of the details on the iOS 5.0.1 untethered jailbreak and Corona that Pod2g has explained in his blog. For those not familiar with the jargon of software development, the following explanation can be a real mind-twister.

The Userland Exploit

Apple has fixed all previous known ways of executing unsigned binaries in iOS 5.0, Pod2g wrote. Corona does it another way.

Before the release of the iOS 5, security researchers used to include the untethering payload as a data page rather than a code page in the Mach-O binary. Since the Macho-O loader never checked its authenticity, using a data page was always an advantage while seeking security flaws.

ROP (Return Oriented Programming) then enabled the code execution by utilizing existing signed code in the dyld cache, rather than writing a new executable code. In order to get the ROP started by the Mach-O loader, jailbreakers relied on different techniques, such as interposition and initializer exploits, discovered by JailbreakMe famed Comex.

For more detailed explanation on code sign tricks used before iOS 5.0, click here.

From the time Apple bounced back with further developments to iOS security, data pages now need to be signed by Apple for the loader to authenticate the binary. According to Pod2g, @i0n1c seems to be able to pass through the verification process. He was hopeful that @i0n1c's method could be used in a future iOS 5.1 jailbreak.

For Corona, a New Way

Thus, for Corona, I searched for a way to start unsigned code at boot without using the Mach-O loader, Pod2g wrote. He looked for flaws in existing Apple binaries that could be found using standard launchd plist mechanisms.

By using a fuzzer, he later discovered a format string vulnerability in the raccoon configuration parsing code. Racoon is the IPsec IKE daemon that comes by default with iOS and is started when you setup an IPsec connection. For more details, click here.

The term Corona comes from racoon. Corona is an anagram of raccoon, Pod2g said.

For the jailbreak to be applied at boot, racoon is started by a launchd plist file, which executes the command: racoon -f racoon-exploit.conf. This is a configuration file, responsible for exploiting the format string bug and getting the unsigned code going.

The format string bug is utilized to copy the ROP bootstrap payload to the memory and to execute it by overwriting a saved LR in the racoon stack by a stack pivot gadget.

The ROP bootstrap payload copies the ROP exploit payload from the payload file which is distributed with Corona then stack pivot to it. Pod2g wrote. The ROP exploit payload then activates the kernel exploit.

The Kernel Exploit

According to Pod2g, the kernel exploit relies on an HFS heap overflow bug, which he found earlier. However, Pod2g is not quite sure about what happens in the kernel code. Then what made him go along with it?

I just realized that it is a heap overflow in the zone allocator, so I started to try to mount clean, overflowed and payload images in a Heap Feng Shui way, he wrote. And hey, that worked. Thanks to @i0n1c for his papers on this subject.

The kernel heap overflow exploit then copies 0x200 bytes from the vnimage.payload file to the kernel sysent replacing a syscall to a write anywhere gadget. During the process, some syscalls (first 0xA0 bytes and the last 0x6 bytes) got trashed, because he needed to respect the HFS protocol.

Thus, I restore them as fast as possible to get a stable exploit, then the write anywhere is used to copy the kernel exploit and jump to it, Pod2g explained.

MUST READ: iOS 5 Untethered Jailbreak: A5 Powered iPhone 4S, iPad 2 Jailbreak Due 'in a Week'

MUST READ: iOS 5 Untethered Jailbreak: Redsn0w 0.9.10b3 Brings Remedy for Issues with MobileSubstrate

To report problems or to leave feedback about this article, e-mail: k.bora@ibtimes.com
To contact the editor, e-mail: editor@ibtimes.com