Interested in learning more? It’s covered in the official docs.

*sometimes there are mechanisms for exchanging data between apps, that are implemented intentionally

If we rename sandbox to jail, then the term jailbreak makes more sense. By definition, a jailbreak is a privilege escalation for the purpose of removing software restrictions imposed by Apple on iOS, tvOS and watchOS.

In case you didn’t understand a word from above, it means giving apps admin (root) level access, which in term allows installation of other apps, tweaks and themes not on the App Store. Think Cydia – the unofficial official jailbreak software manager.

So, now that we’re familiar with what jailbreaking isn’t and what it is, it’s time to discuss how developers detect a jailbreak. While there’s no official way to detect a jailbreak, and false positives are possible, most methods rely on attempts to access resources that are usually inaccesible on a sandboxed app.

For example we will try to:

The reason for having so many different methods is due to many different types of jailbreaks and iOS versions. Usually, if any of the methods above succeeds, we assume we’re dealing with a jailbroken phone.

In order to demonstrate that detecting a jailbreak doesn’t pose a significant obstacle to a determined hacker, we’ll need a few things:

Let’s roll up our sleeves.

For the sake of this article, I’ve developed a simple app with an elaborate name Jailbreaking Bad. Its only purpose is to detect if a device is jailbroken.

If you’re interested in the source code, you can find that here:

GitHub – Adis/jailbreaking-bad

The jailbreak detection is contained inside a class named JBChecker, which is just a wrapper for a more complicated class that does all the heavy lifting, for clarity.

This class only has one method that checks if the device is jailbroken or not, and returns the result. This is also our entry point when jailbreaking the app a few steps later.

After opening the app, you will be presented with a single button; tap it, and the app will tell you if it has detected a jailbreak or not.

Obviously, a major part of testing this yourself is getting your hands on a jailbroken device. I won’t be covering how to perform a jailbreak in this article as this info is widely available online.

In case you were wondering how the app looks like on a jailbroken iPhone, here’s a handy gif:

In order to develop a tweak for an app, you will have to figure out the behaviour you want to change.

Depending on your level of curiosity, there are plenty of tools out there which allow you to deconstruct and observe the ins and outs of a certain app.

In order to get familiar with with our own app, first, we’ll want to inspect the IPA (not the beer, the extension) file from the device on a unix machine. The tool of our choice will be class-dump.

IPA file is just an archive, so unarchive it, and take a look at its content. You’ll find icons, folders, .plist files – but we’re looking for a mach-o file that represents our app in a binary format. This file will usually have the app’s name. To dump the headers from the file, use the class dump:

and you will be presented with a lot of output, but the part we’re interested in is this one:

What we can see here is the header of our checker class (the wrapper we added as described before), with the method name from which we can easily infer the usage and the return value we want to override. Gotcha.

In a jailbreak world, a tweak is an improvement that allows you to hook into existing classes and methods of installed third-party and system apps. Tweaks are hosted on repositories or repos usually handled by Cydia. Default Cydia repos are community maintained and imply a certain level of trust and safety.

For the sake of this blog post, I’ve made a repo of my own:

GitHub – Adis

I won’t go into details on how to develop a tweak or host it on a repo since there’s a lot of work involved there, but my tool of choice for tweak development was Theos.

Back to work. Now that you know which method is responsible for making jailbreak checks, you’ll want to write a tweak that will override the behavior of that method. This is just a bit more of programming. Here’s the entire content of my own tweak:

The syntax is simple – %hook %end block injects itself into a class that checks for the jailbreak, and I rewrote the method that checks for jailbreaks to simply return false in all cases and skip any other checks.

In order to get this tweak on your own device, you’ll need to add a new source in Cydia. The app will warn you that this is not a trusted repo, and that’s fine. As mentioned above, only a selected few are trusted.

When the repo is there, you’ll find a single tweak called JBBad. After you install the tweak, go back and open the Jailbreaking Bad app. The app will – regardless of device status – report that the device is not jailbroken until you uninstall the tweak.

And a handy .gif with the boring parts sped up:

While the process described above might seem simple, it by no means implies that iOS apps lack security. Building truly secure apps includes far more than implementing a simple jailbreak check, and a threat that would justify the effort of blocking app usage based on jailbreak detection would have to be substantial and take copious amounts of work to devise.

The purpose of the article is to demonstrate that, at best, jailbreak detections are a tiny security upgrade. Such detections might only deter a part of your user base which is most likely well aware of the security issues a jailbreak presents.