The rapid formalization of the tethered jailbreak for iPhone OS 5.1, with Redsn0w andSn0wbreeze, did a little thinking at all that the release of final output devoted to the new operating system from Cupertino, it could be, unlike the jailbreak iPhone IOS 5.0.1, much faster and easier.
The situation does not seem to be exactly this: yesterday pod2g fact, even with the same enthusiasm as ever, has reported all down to earth, saying, they are already working to find exploits useful, but it can not predict timing regarding the safe release of the untethered jailbreak for iPhone IOS 5.1.
Today, however, check his blog here, a “strange” post titled, “How to help the community of Jailbreak”, a sort of decalogue, dedicated to us ordinary users. with allthe steps to follow to make a fundamental and practical help.
To communicate the new initiative has been the same hackers through a messageappeared on Twitter:
“You want a quick jailbreak 5.1? Then help us “
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 usually 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 as it reboots the device.
- 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 SIGSEGV.
- The crash should be repeatable, which means you should know what exact steps produced it and how to produce it on another device.
How and where to report:
Send an email to ios.pod2g ‘at’ gmail ‘dot’ com