“Jailbreak Detection” is a set of checks, mostly performed by Mobile Device Management solutions like MobileIron / Good Technologies or other third party Apps to determine if a device is jailbroken or not. It checks if all security controls of Apple’s iOS are still in place and if we can / should / want “trust” this device.

Such a check could for example search for eye-catching files like the Cydia App Store which can only run on jailbroken devices. Other checks may be:

  • Is the root partition mounted read / writable
  • Is it possible to write outside of the App’s Sandbox
  • Is it possible to fork into another process
  • …

If we break this down into a sequence diagram it could look like this (for simplicity reasons I divided the app into two components):

To know if a device is jailbroken is very important as it should never be the case that a jailbroken device can access services from the corporate environment like email or document management systems.

Apple itself introduced a jailbreak detection API ready to use for third party developers, but dropped it quietly with iOS 4.2. The reasons remain a mystery. I think Apple was aware of the fact that such an API can never work by design and dumped it for liability reasons: Software is supervising other software, telling it the device is jailbroken … and software can always be manipulated. In this case by disguise the fact that something has been compromised.

The idea is simple: write a malware that will “Hook” the original code and bypass the detection.

The most difficult part of this approach is to find the correct entry point in the code. (Un)fortunately, Objective-C is a huge help and may let us dump all the header files of the implementation. If the developer was nice enough to call its classes “JailbreakDetector” we should be thankful and send him a nice gift:

#import <Foundation/Foundation.h>

@interface JailbreakDetector : NSObject

+ (BOOL)isDeviceJailbroken;

@end

My Hook could look something like this:

+ (BOOL)isDeviceJailbroken{
   return false;
}

Lucky us, we are not completely at an attacker’s mercy; creative developers exist and have a proper feature set to deal with such attacks. I like the approach that Jonathan Zdziarski published in his book Hacking and Securing iOS Applications. He writes about pushing the attacker into the wrong direction by implementing a decoy class with an obvious naming.While most attackers will first try to manipulate this code, they will by mistake trigger kill switches that for example invoke tamper responses
to erase data and disable remote resources. Other solutions may be to implement the detection as static inline C code, which is much harder to manipulate.

To summarize this post: Jailbreak detection is valuable and it should definitely be a part of your tool-set to secure integration of mobile devices into the company. However, it should not be trusted blindly.