How root/jailbreak detection works on Android & iOS. Is it effective enough to actually rely on?

I started thinking about how it's possible to detect a rooted device, especially when rooting a device means the user can load software that can actively prevent root/jailbreak detection.

In Jack’s article yesterday, he mentioned how MobileSpaces could detect whether a device had been rooted, and, of course, we’ve mentioned this in the past when talking about iOS MDM/MAM. I started thinking about how it’s possible to detect a rooted device, especially when rooting a device means the user can load software that can actively prevent root/jailbreak detection. More importantly, though, I wondered how effective this might be and if focusing on it was all that important in the grand scheme.

How are rooted or jailbroken devices detected?

There’s a few ways to detect rooting in Android. For the most part, it involves trying to execute code that shouldn’t be executed, like switching to SU or shelling out a command. It can also be done by checking for software or executing processes and comparing the output against a list of known, uncompromised outputs. There is a great article on StackOverFlow that give some example code for checking an Android device to see if it’s rooted, but as one of the commenters brings up, these only work if the device was rooted in a common way. With all the fragmentation in the Android world, it would stand to reason that different tactics are in use in the wild.

For iOS, things appear slightly more elegant. Testing for jailbroken devices can involve looking for files or directories that shouldn’t exist, like or any of the files/directories that rogue applications create. You could also check to see if OpenSSH is installed, since that’s usually enabled on jailbroken phones, by simply trying to establish a connection to the loopback address. Like Android, there are also low-level functions that can be called that will return different values if the device has been compromised. For iOS, the example I found was the system() function, which checks for the existence of the /bin/sh folder. Doing so would return 0 on a secure device and 1 on a jailbroken device.

Is it all that effective?

Those are the ways that I, a relative user when it comes to hacking phones, could find. Though it's probably easier to detect if an iPhone is jailbroken simply because the OS is more tightly controlled, not to mention the number of different devices is significantly smaller, with a small amount of searching users can find step-by-step instructions on how to thwart root/jailbreak detection. Just because a company can address a problem now doesn’t stop people from looking for other ways around the security. Another thing to consider is that the developers who create apps for rooted/jailbroken devices know the techniques that the security vendors are using, so they can, for instance, use a different file or folder name, or intercept calls to certain functions and have them return an output that coincides with an uncompromised device.

Even if you’re not much of a coder, there are other ways. For example, Eric Gruber at NetSPI posted a way to circumvent AirWatch’s root restriction. It’s an excellent article that details the process of root detection and how information is exchanged between the device and MDM server. In it, Eric had trouble finding the method of detection that the AirWatch agent was using, so rather than dig deeper into that rabbit hole, he manipulated the data being sent to the AirWatch server. That meant that the agent saw a rooted device, but through Eric’s intervention, it reported to the server that it was within policy. AirWatch, of course, noticed the article and within a month found a solution that involved enforcing a setting to ensure secure communications. Still, they were behind the curve, just like all EMM vendors.

It seems this is more about keeping honest people honest. Mobile device and data security is a lot like your home security. You do what you can to keep the wayward person with the misfired synapse from getting into your house, but if someone is actually plotting to do harm or to circumvent your security, they’re just going to smash a window, take what they want, and be on their way. Jailbreak or root detection solutions are similar to the deadbolt lock on your door–it makes it harder to do it, but if someone really wants to and has the wherewithal to pull it off, it’s probably going to happen.

If you find your users are consistently trying to circumvent your MDM, perhaps you should revisit your approach. After all, we’re trying to manage a device that, regardless of who owns it, is very personal to the user. If multiple people are attempting to get around the controls you put in place, maybe those controls are too tight. Using a lighter touch with MDM and using MAM to secure apps is likely the way to go, and may render root/jailbreak detection unnecessary in many circumstances. Most MAM vendors have some sort of solution that gives some sort of security even on known compromised devices.

If you go back to the analogy of locking your front door, sure, you could do more. You could put up electrified barbed wire fences and the like, but you don’t. You settle for a relatively small amount of security in order to strike a balance with flexibility. You don’t take chances, but you’re also not about to let anyone in the easy way. It’s the same with our mobile strategy. Try to avoid rooted/jailbroken devices, even audit them, but staying ahead of the curve is going to be tough.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

"It seems this is more about keeping honest people honest."

Bingo. We in IT tend to forget where our jobs as IT admins end and the jobs of HR, legal, and the police begin. If a user wants to be a criminal, let HR and the FBI deal with that. No amount of EMM prevents criminals from being criminals.

Also I love the statement that if you have tons of users rooting their phones, then really that's a problem with your policy, not your users.


I think companies should get out of the business of locking down the user's BYOD device.  They should provide a client package that gives access to corporate info via an app and not manage the user's device.

I own my device and I intend to have my own set of wallpapers, lockscreen security choices, and ringtones.  Companies have no business managing my device if all I am doing is access email and intranet web content.

Give me a client to install and access corporate data and stop being big brother to my property.


Kyle, you hit the nail on the head.

The problem with many existing solutions is that they do not respect device ownership.  You own the device and should be able to install your choice of apps/wallpapers/ringtones/security.

The enterprise should secure its own data on your device, not manage your entire device.

The admin should not care about apps you install for personal use.  It does make sense for the enterprise to take jailbreaking/rooting into account when deciding whether your device is trusted, but the distance between checking rooting status and managing your entire device is huge.

Regarding jailbreaking/rooting detection, the methods mentioned in the post are polling for specific apps or files, but detection can go far beyond that.  Rooting and jailbreaking has side effects that are hard to hide.  For example, in iOS the kernel does not let processes run unsigned code in their memory space.  Any form of jailbreaking disables that protection, since it is a fundamental requirement for jailbreaking.  If an app tries to execute such code in memory as part of its logic, the results tell you a lot about the security state of the device.  One could argue that anything can be virtualized so any test could be fooled, see the old redpill/bluepill debate around hypervisor-based attacks, but at some point it becomes impractical to fool all tests and still have a usable operating system.

Yoav Weiss

MobileSpaces founder & CTO