A day ago, we have reported you that Pod2G, the iOS Hacker behind the iOS 5.0.1 Untethered Jailbreak Exploit has begun its work for the iOS 5.1 jailbreak exploit, and start testing the iOS 5.1 kernel exploits to produce another iOS 5.1 Untethered jailbreak exploit quickly for the devices. However, it appears that the process of searching a new jailbreak exploit is not easy, and it requires a lot of time, like the last untethered jailbreak exploit takes a whole year, and therefore, to do this job, the iOS jailbreaking community wants your help in contributing the number of crash reports, and your own findings of the kernel exploits in the iOS 5.1.


Pod2G, the iOS Hacker – has today published a new blog post on his website containing some points on which he highlighted how a random user with iOS 5.1 on its device can help them in finding the new iOS 5.1 jailbreak exploit. He has posted a number of methods that help you in looking for new exploits, and as well as detailed the different kind of exploits along with the basic identification of the kernel exploits. He stated that kernel exploits are the most important need of the jailbreaking community, and users can help them in looking for new kernel exploits on the newer iOS 5.1.

Like the Chronic Dev Team, he also requested to the jailbreakers to stop sending their iOS crash reports content back to the help, and told them to look manually in the crash logs to find out kernel exploits, as it named number of terms on his blog as an identifier of the kernel exploits. Pod2g, ask users to try crashing the stock applications on their devices such as: Safari, Mail, etc.… or identify a kernel exploit on their devices, and confirm the finding by again applying the same steps on your device to crash it at a kernel level.


To jailbreak a device, hackers need a set of exploitable vulnerabilities :

  • a code injection vector : a vulnerability in the core components of iOS that leads to custom, unsigned code execution.
  • a privilege escalation vulnerability : it’s usualy not enough to have unsigned code execution. Nearly all iOS applications and services are sandboxed, so one often need to escape from the jail to trigger the kernel exploit.
  • a kernel vulnerability : the kernel is the real target of the jailbreak payload. The jailbreak has to patch it to remove the signed code enforcement. Only the kernel can patch the kernel, that’s why a code execution vulnerability in the context of the kernel is needed.
  • an untethering vulnerability : when the device boots, it is unpatched, thus cannot run unsigned code. Thus, to start the jailbreak payload at boot time, a code execution vector either in the services bootstrap or in the loading of binaries is mandatory.
You can help if you can crash either a core application (Safari, Mail, etc…) or the kernel in a repeatable way. A kernel crash is easy to recognize : it reboots the device.
Important facts :
  • Always test on the latest iOS version before reporting a crash (at the time of writing, iOS 5.1)
  • Be sure to not report crashes to Apple : on your iOS device, go to Settings / General / About / Diagnostics & Usage,  and verify that “Don’t Send” is checked.
  • Not all crashes are interesting : aborts, timeouts or out-of-memory kind of crashes are useless. Verify the crash dump in Settings / General / About / Diagnostics & Usage / Diagnostic & Usage Data that the crash report you created is of Exception Type SIGILL, SIGBUS or SIGSEV.
  • The crash should be repeatable, which means you should know what exact steps produced it and how to reproduce it on another device.
How and where to report :
  • Send an email to ios.pod2g ‘at’ gmail ‘dot’ com detailing the steps to produce the crash and the associated crash report.