iOSDefender SDK API
Jailbreaking an iOS device is complicated: Apple implements iOS and hardware to be resilient against attempts to jailbreak them, and jailbreak providers have to figure out ways around the protections. There are also many different jailbreaks that use different approaches to circumvent the security protections. Some jailbreak tools provide the means to remove the jailbreak and related support files from the device. But once the security of a pristine iOS device has been compromised by a jailbreak, there are no guarantees that this process will entirely remove code or settings added by the jailbreak. Also some jailbreaks require interaction with a host computer: "semi-tethered" and "semi-untethered" jailbreaks. Detection of "jailbroken" state is thus fairly complicated.
We recognize four states from "jailbroken" to "not jailbroken":
- Actively Jailbroken - a jailbreak is active and it is possible to install apps from an app store other than Apple's app store
- Jailbroken but Inactive - the device is jailbroken, but it is probably not possible to install apps from another app store without reactivating the jailbreak
- Restored - the device was jailbroken at some point, but the user tried to restore the device using the jailbreak's restore operation
- Clean - the device shows no signs of a jailbreak being present: it was either never jailbroken or the device was wiped and a new iOS image installed
The API provides three methods to check for these different states:
iOSDefender.isActivelyJailbroken()- true if the device is in the active state
iOSDefender.isJailbroken()- true if the device is in either the active or inactive state
iOSDefender.hasBeenJailbroken()- true if the device is in the active, inactive, or restored state
These methods are available for Swift apps in the
iOSDefender class, and for Objective-C in the
As jailbreaks evolve over time and as new ones are developed and appear in the field, indicators of different states may change or become ineffective. For example, what once indicated that a device was jailbroken and then restored may indicate an active jailbreak in the future. This is one reason why the SDK describes the intuitively boolean question "is jailbroken?" with a set of three boolean methods instead.
hasBeenJailbroken() checks the broadest set of jailbroken indicators, and is most likely to be effective with future jailbreaks, but is thus the most likely to produce a false positive.
isActivelyJailbroken() checks the narrowest set of jailbroken indicators, and thus most certainly indicates a jailbreak today, but is most likely to produce a false negative.
isJailbroken() is a balance between these two.
This does also illustrate the need to keep iOSDefender SDK up-to-date so that your Apps will pick up on the latest indicators.
These calls do not need to be called in conjunction: if
isJailbroken() is true then
hasBeenJailbroken() will also return true, similarly for
Choosing the right method depends on your application, how you intend to respond to the condition, and your company's tolerance for false positives and false negatives.
The right answer might be different behavior in response to two or more of the methods.
Since it is not exactly clear what "jailbroken" means in the context of an iOS app running on a Mac with Apple silicon or in Simulator, iOSDefender SDK treats these platforms as actively jailbroken. This behavior can be adjusted as desired. All of the API methods take an optional list of the following configuration options:
AppleSiliconIsSafe- do not trigger when running as an iOS App on Apple silicon (this does not affect running in Simulator on Apple silicon)
SimulatorIsSafe- do not trigger when running in Simulator
In Objective-C, the names in the Swift
Config enum are presented concatenated with the name of enum:
So for example:
[iOSDefenderObjC hasBeenJailbroken:@[@(ConfigAppleSiliconIsSafe), @(ConfigSimulatorIsSafe)]]
The default behavior is handy for testing responses to jailbroken states, because you can test the jailbroken behavior on Simulator, and non-jailbroken behavior on a (non-jailbroken) device.
This also means that testing or debugging your App's normal functionality with checks from the SDK in place, you will either need to test on a device or pass the
SimulatorIsSafe option (remembering to remove the option later).