The release of iOS 5.1, along with the 4G-enabled new iPad and the Apple TV, has got hackers across the world working to release jailbreak solutions.
The release of Redsn0w 0.9.10b6 allowed users to run tethered jailbreaks on non-A5 devices like the iPhone 4, the iPhone 3GS, the original iPad and the iPod Touch. Unfortunately, users of A5-run gadgets - the iPhone 4S and the iPad 2 - are still looking for their jailbreaks.
The hacking efforts are led by three people - "MuscleNerd", "pod2g" and "i0n1c" - who are working on the latest exploits. A public release in the near future is probably a certainty.
The growing popularity of jailbreak utilities like Redsn0w and Sn0wbreeze has meant Apple has had to make progress of their own... in terms of both hardware and software security. It is, therefore, becoming increasingly difficult for jailbreakers to find potential vulnerabilities.
The Chronic Dev Team released the Chronic Dev Crash Reporter Tool last year. The tool allowed iOS-run devices to covertly send crash logs to the team; it was hoped those logs might contain some answers. The trend of asking users for help in finding bugs is continuing, with "pod2g" the latest to join the queue.
In his official blog, "pod2g" writes stating his specific information requirements.
"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."
Other key facts that jailbreakers must note:
- 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.
- Along with the report users should also include steps to reproduce the bug.
Users may send crash reports to iOS.firstname.lastname@example.org. Before sending the report, it must be noted that they conform to at least one of exception types mentioned above.
"Crash reports are useless without explanations on how to reproduce them!!!" pod2g tweeted. The users are asked not to send bug reports of third-party, App-store apps like Angry Birds, Soccer Sounds, etc.