Skip to content

Instantly share code, notes, and snippets.

@CraigsOverItAll
Forked from Siguza/JBdetection.md
Created August 25, 2018 03:28
Show Gist options
  • Save CraigsOverItAll/f6221136222172257e2214e48a6f08e9 to your computer and use it in GitHub Desktop.
Save CraigsOverItAll/f6221136222172257e2214e48a6f08e9 to your computer and use it in GitHub Desktop.

Thoughts on jailbreak detection

The controversy of jailbreak detection has been brought up multiple times in my Twitter feed, so in order to not have to repeat myself, I'll write my thoughts down here.
One day I'll hopefully get round to set up a realistic blog and then I'll move this there, but for now I'll just dump it here on GitHub.

Motivation

Hi. I'm Siguza, and among other things I write exploits for a hobby and help make jailbreaks. One of the reasons I do that is because I believe we should have the ability to run whatever we want on our iDevices, just as we do with laptops and desktop computers. Now, a lot of app developers however seem to despise jailbreaks, and try to make their apps refuse service on jailbroken devices. I think that firstly sucks big time, and secondly always misses the point. From what I gathered, the two arguments for using jailbreak detection seem to be:

  • "Jailbreaking makes devices insecure."
  • "Jailbreaking allows cheating."

These two arguments create for different assumptions and goals, and thus need to be addressed separately.
Now, besides the fact that jailbreak detection can always be bypassed (as is the case for any client-side check, because you can literally rewrite the code that does the check), I will try and explain why all jailbreak detection still misses the point in every case even if not tampered with, and what, if anything, app developers should be doing instead.

Jailbreak detection "for security"

  • This is most commonly seen with banking apps or other monetary services such as PayPal.
  • The intention is to protect the user from malicious third parties.
  • The assumption is that jailbroken devices are insecure, while non-jailbroken ones are secure.

That assumption is wrong. A jailbreak by itself does in no way reduce the security of a device. Sure, a user could install malware, but they could just as well install patches for vulnerabilities - being jailbroken alone means nothing in that regard. What does carry meaning however, is whether a device could be jailbroken. If you're worried about malicious third parties, it doesn't matter whether your users are using some security holes, what matters is whether known ones are present in the first place or not. So if you really wanted to protect your users, you'd have to refuse service on unjailbroken devices as well, if they were running any non-up-to-date OS (you might actually still wrongly detect jailbroken devices with patches installed as vulnerable, but I would argue that for someone with vuln patches, spoofing their iOS version is easy enough).

To illustrate the above, take a look at the Wifi firmware exploit developed by Gal Beniamini last fall. All versions below 11.0 are vulnerable and can be remotely hacked, merely requiring the victim to connect to a rogue access point. For all 32bit devices, including e.g. the iPhone 5 and 5c, that means that even on the latest version, they are terribly vulnerable, even if not jailbroken. On the other hand, I patched the Wifi firmware of 11.2.6 into the iOS 9.3.3 installation on my phone, so even though it is running an old version AND is jailbroken, no public remote exploit is getting the better of me. :P

So, what should be done instead of jailbreak detection, for the sake of users' security? Most likely nothing. Or, alert the user but at least let them continue anyway. You might also try and detect tampering on your app's process, which makes a lot more sense than checking whether Cydia exists, but that won't help at all against malware that sits in the kernel, or has a send right to your task port.
Also, you get bonus hypocrisy points if your service also has a web interface, because apparently there you're just fine with not being able to learn anything about the user's OS.

Jailbreak detection "against cheating"

  • This is most commonly seen with games or other apps that want to prevent cheating (e.g. Snapchat), as well as apps that have in-app purchases and want to prevent users from gaining access to those for free.
  • The intention is to protect the developer from malicious users.
  • The assumption is that jailbroken users are cheating, while non-jailbroken are unable to so.

That assumption is wrong, to both sides. It is very obviously possible to be jailbroken and not cheat, but it is also possible to sideload a patched version of your app that allows cheating, without being jailbroken at all. Depending on what exactly you're trying to prevent, you may have other options though:

  • If you have an online game or something similar where you're trying to prevent cheating: move the checks to the server side. You have no control over the client, so you cannot trust them, ever.
  • If your app has one-time IAPs, or repeatable IAPs that get associated with an account (like gambling tokens or whatever), take the content out and make it downloadable (if applicable), and have the server ask for the IAP receipt. Piracy tweaks can fool local checks, but they can't forge a digitally signed receipt.
  • If your app has IAPs that do not unlock new content and are not verified online, you're out of luck anyway. Because you'll have to keep track of that data somehow, and even without a jailbreak, I can just back up my device with iTunes, modify the data in the back up, restore the backup, and you won't even know it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment