Over a million developers have joined DZone.

Why Are Established Jailbreakers So Good?

DZone's Guide to

Why Are Established Jailbreakers So Good?

Creating a jailbreak is a long and complicated process, so why does it seem others can do it so fast? They're just building on what they've already done.

· Mobile Zone
Free Resource

So jailbreaking is hard.

Rooting is too. Same thing really - one's for iPhones, the other for Android devices. But why? Why is it so difficult to do, and why are the same people releasing jailbreaks time after time?

Well, first, let's take a step back and look at the kinds of things that need to go into a jailbreak (or rooting kit - I'll just use the term jailbreak from here on out). We need to have a few things in hand to create a jailbreak to begin with, let alone one that other people can use.

First, you need actual exploits. You need a few of them, in fact. First, you need to get code execution in a process. There's a variety of ways to do this, ranging from the time-honored buffer-overflow to heap corruption attacks. Today, you never see stack buffer-overflow attacks on modern mobile devices, there's just too many protections that get in the way. From stack defenses like write-or-execute/data execution prevention to stack canaries to ASLR, stack attacks have become just about impossible on modern computers. Heap-based attacks are very common, on the other hand - double free or use-after-free bugs have been the go-to exploits for the past year.

So your first exploit allows you to execute code. Great! Now you need to break out of the process and do it again. This means you need to find yet another exploitable vulnerability.

So, to even get out of the gate, you need at least two 0-days, and you need exploits for them.

Then, you need to have your payload. The payload will run with administrative privileges. This payload is pretty common across jailbreaks, in fact - it needs to turn off certain security features, move a few things around in the filesystem, and generally set the device up to allow general administrative access and install software without typical security controls (e.g. without being authenticated by Apple, in the case of iDevices). You'll also need to install various tools (I'm looking at you Cydia).

Prior to any of this, you need an effective delivery system. Today, in the iPhone world, we're living with what we call semi-tethered (or semi-untethered) jailbreaks. Basically, you need to side-load an application (despite what you hear, you can do this from tools like XCode, for example). The application needs to be signed (you can self-sign) to run. Then you run it - it will run the exploit code, install and run the RoP chains, and then execute the payload, setting up the jailbreak. The jailbreak itself will persist until you reboot, at which point you'll need to go through the cycle again.

So, take a look at the code we've outlined - a significant amount is reusable. The payload is reusable, and so is the side-loaded application. Much of the RoP chain is likely reusable too. The only new code is the exploit trigger. This is why the same people release jailbreaks time after time - all they need to do is find the vulnerabilities, and perhaps tweak the exploits. You, on the other hand, would need to build this, creating the app to trigger the jailbreak as well as the payload used to break and configure the device. And this stuff is not shared - you'd need to do it on your own.

So if you're thinking about building a jailbreak, and it's taking forever, don't sweat it. It's not easy. The only reason others can do it so fast is because they've already built so much. If you can build that stuff, then it'll be faster for you, too.

jailbreak ,mobile ,ios ,android

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}