iOS: Defeating Swift jailbreak detection

Abstract.

Today we are looking at a simple Swift program that uses a jailbreak detection function. To increase the fun and get some practical code at the end of the day, I searched for a jailbreak detection function for Swift online. The foundation code can be found here. The main goal is, to bypass the Swift jailbreak detection function.

Code.

By taking a look at the following Swift function, you can see that it performs several checks for files and paths that usually exist on a jailbroken device. Furthermore, it will try to call a Cydia package URL as well as try to create a file in the /private/ directory.

import Foundation
import UIKit

func isJailbroken() -> Bool {
		
		guard let cydiaUrlScheme = NSURL(string: "cydia://package/com.example.package") else { return false }
		if UIApplication.shared.canOpenURL(cydiaUrlScheme as URL) {
            print("[Jailbreak detection]:\tCydia URL scheme.")
			return true
		}
		
		#if arch(i386) || arch(x86_64)
			// This is a Simulator not an idevice
            print("[Jailbreak detection]:\tSimulator detected.")
			return true
		#endif
		
		let fileManager = FileManager.default
		if fileManager.fileExists(atPath: "/Applications/Cydia.app") ||
			fileManager.fileExists(atPath: "/Library/MobileSubstrate/MobileSubstrate.dylib") ||
			fileManager.fileExists(atPath: "/bin/bash") ||
			fileManager.fileExists(atPath: "/usr/sbin/sshd") ||
			fileManager.fileExists(atPath: "/etc/apt") ||
			fileManager.fileExists(atPath: "/usr/bin/ssh") ||
			fileManager.fileExists(atPath: "/private/var/lib/apt") {
            print("[Jailbreak detection]:\tUncommon file exists.")
			return true
		}
		
		if canOpen(path: "/Applications/Cydia.app") ||
			canOpen(path: "/Library/MobileSubstrate/MobileSubstrate.dylib") ||
			canOpen(path: "/bin/bash") ||
			canOpen(path: "/usr/sbin/sshd") ||
			canOpen(path: "/etc/apt") ||
			canOpen(path: "/usr/bin/ssh") {
            print("[Jailbreak detection]:\tCan open uncommon path.")
			return true
		}
		
		let path = "/private/" + NSUUID().uuidString
		do {
			try "anyString".write(toFile: path, atomically: true, encoding: String.Encoding.utf8)
			try fileManager.removeItem(atPath: path)
            print("[Jailbreak detection]:\tCreate file in /private/.")
			return true
		} catch {
			return false
		}
	}
	
func canOpen(path: String) -> Bool {
		let file = fopen(path, "r")
		guard file != nil else { return false }
		fclose(file)
		return true
	}

Every check returns the boolean value true (0x1), if the execution was successful. If none of the checks resulted in a jailbreak detection the value false (0x0) will be returned.

The following screenshot shows the corresponding Swift ViewController, to manually trigger the isJailbroken() function:

Assumptions.

When I compiled the program, I were pretty sure that I will also discover the name of the function isJailbroken() somewhere inside of Hopper, guess what? I was wrong :). As we have learned earlier (see Blogpost #0 and #1), we most likely will find the string values that exceed the size of 15 bytes in the Str section of Hopper, which will make it easy to discover the code that represents the isJailbroken() function. But what if some fancy developer was into some obfuscation, encoding all string values with whatever technique? So it would be nice to find a way, to be still able to discover the function of interest.

Runtime analysis.

Let’s assume, that we have not been able to discover the code responsible for jailbreak detection with Hopper Disassembler. What could we do next? How about analyzing the iOS Swift app during the runtime? Well we could do that, but how? Which tools can be used? The first tools that came to my mind were the following:

  • GDB
  • FRIDA

GDB a very popular debugger, can be used to attach to a running process or even starting the binary and then analyzing and manipulating the app during runtime.

Problem:

  • no-stable version available for iOS > 10.x (as long as I know)

Frida, a very popular tool that can be used for many purposes, but one of the main functionalities (that I use) is tracing and hooking objective-c methods during runtime and manipulating the return values.

Problem:

  • Swift is not supported out, of the box, the only project I discovered so far is here but I don’t know the capabilities

As we can see, GDB and Frida don’t fit our needs. Well there is another tool … lldb, which comes with every XCode installation. Let’s see if we can use lldb to analyze and bypass the jailbreak detection! lldb is very similar to GDB, I found the tool to be super intuitive! Many app’s that you can download from the iOS app store, also suffer from protecting against debugging.

Bypass.

Of course, we will not cover all functionalities of lldb (not that I know all of them), but I will show you how to find the function of interest and how to manipulate the return value!

First fire up the app with XCode which will automatically attach lldb to the process:

Next we hit the Pause program execution button:

This will give us a lldb shell, here we can get information on the available functions by entering the command help. Next we are going to find our Swift isJailbroken() function by using the breakpoint utility with the regex option.

(lldb) breakpoint set -r "Jail"

This will create more breakpoints than necessary but we will be able to also see our jailbreak detection function which is super helpful (Yes I know, what if the fancy developer also obfuscated the Swift function name? We assume that this is not the case…). The following screenshot shows all created breakpoints:

Oh, breakpoint 1.10 looks interesting, so we just discovered the isJailbroken() Swift function:

1.10: where = Swift challenge two`Swift_challenge_two.isJailbroken() -> Swift.Bool + 36 at JailBreak.swift:8, address = 0x00000001044f8a3c, resolved, hit count = 1 

We could also create the breakpoint with the following command, but I wanted to show the power of the regex “-r” parameter, because most of the time in a blackbox assessment we must guess the function names:

(lldb) breakpoint set -F isJailbroken 

So we hit the Jailbreak detection button in the UI on the test device and wait until a breakpoint is triggered. We can now examine the content of the arm64 registers, which will give us a lot of information where we are and where we are coming from 🙂

(lldb) register read
General Purpose Registers:
x0 = 0x000000010550c560
x1 = 0x000000010550c560
x2 = 0x000000010550c560
x3 = 0x00000001c0103ba0
x4 = 0x00000001c0103ba0
x5 = 0x00000001c0103ba0
x6 = 0x0000000000000000
x7 = 0x0000000000000403
x8 = 0x0000000000000000
x9 = 0x0000000000000000
x10 = 0x0000000000000006
x11 = 0x0000000000000000
x12 = 0x0000000105825410
x13 = 0x000005a1044fd495 (0x00000001044fd495) (void *)0x01b5404c38000001
x14 = 0x0000000000000000
x15 = 0x00526401005264c0
x16 = 0x00000001044fd490 (void *)0x000001a1044fd5e1
x17 = 0x000000018cc6ce10 UIKit'-[UIViewController(UIKitManual) retain]
x18 = 0x0000000000000000
x19 = 0x00000001c0103ba0
x20 = 0x00000001055098d0
x21 = 0x00000001044fa23a "buttonJailbreakDetection:"
x22 = 0x00000001055098d0
x23 = 0x00000001055098d0
x24 = 0x00000001c001d280
x25 = 0x0000000000000000
x26 = 0x000000018d9b453e "objectAtIndex:"
x27 = 0x0000000000000001
x28 = 0x00000001c4052660
fp = 0x000000016b90cff0
lr = 0x00000001044f6fec Swift challenge two'Swift_challenge_two.ViewController.buttonJailbreakDetection(__C.UIButton) -> () + 44 at ViewController.swift:20
sp = 0x000000016b90cb50
pc = 0x00000001044f8a3c Swift challenge two'Swift_challenge_two.isJailbroken() -> Swift.Bool + 36 at JailBreak.swift:8
cpsr = 0x00000000

The pc register holds the address value of the actual function and the lr register holds the address of where code execution should resume after a called function returns. Now we step through the code flow, and every step we examine the content of the registers, this will give us a brief understanding of what is going on:

(lldb) step     
(lldb) register read
General Purpose Registers:
        x0 = 0x0000000000000001
        x1 = 0x00000001c00c9680
        x2 = 0x0000000000000008
        x3 = 0x0000000182b2506c  libsystem_malloc.dylib`nano_free_definite_size
        x4 = 0x0000000104ba05d0  libswiftCore.dylib`protocol witness table for Swift._Stdout : Swift.TextOutputStream in Swift
        x5 = 0x000000016b90c920
        x6 = 0x0000000000000001
        x7 = 0x0000000000000000
        x8 = 0x0000000000000001
        x9 = 0x0000000000000000
       x10 = 0x00008cfd4b9132f9
       x11 = 0xbaddc0dedeadbead
       x12 = 0x000000000000000b
       x13 = 0xfffffffe3fdd47bf
       x14 = 0x0000000000000002
       x15 = 0x05a03ece641e795a
       x16 = 0x0000000182c778cc  libsystem_platform.dylib`OSAtomicEnqueue$VARIANT$mp
       x17 = 0x0000000104b51624  libswiftCore.dylib`-[_SwiftNativeNSStringBase release]
       x18 = 0x0000000000000000
       x19 = 0x00000001c0103ba0
       x20 = 0x00000001055098d0
       x21 = 0x00000001044fa23a  "buttonJailbreakDetection:"
       x22 = 0x00000001055098d0
       x23 = 0x00000001055098d0
       x24 = 0x00000001c001d2f0
       x25 = 0x0000000000000000
       x26 = 0x000000018d9b453e  "objectAtIndex:"
       x27 = 0x0000000000000001
       x28 = 0x00000001c4052660
        fp = 0x000000016b90d090
        lr = 0x00000001044f6fec  Swift challenge two'Swift_challenge_two.ViewController.buttonJailbreakDetection(__C.UIButton) -> () + 44 at ViewController.swift:20
        sp = 0x000000016b90d000
        pc = 0x00000001044f6fec  Swift challenge two'Swift_challenge_two.ViewController.buttonJailbreakDetection(__C.UIButton) -> () + 44 at ViewController.swift:20
      cpsr = 0x60000000

Suddenly the previous caller appears in the pc register. Furthermore, x0 holds a value that looks pretty much like a boolean true value 0x0000000000000001. Let’s change the value in register x0, from true (0x1) to false (0x0), with another lldb command:

(lldb) register write x0 0x0000000000000000     
(lldb) continue

The following screenshot shows the result of the jailbreak detection, on a jailbroken iOS 11.4 device:

Conclusion.

As you can see, we were able to successfully bypass the jailbreak detection. A pretty easy task, once we discovered the responsible function. Possible countermeasures you’ll discover in the wild are obfuscation and frequent calling of the isJailbroken function, which would make patching super annoying.

Tip of the day.

If you want to attach to a running app, with lldb and XCode you start the app on the iOS device, then goto XCode and perform the following steps:

  • Make sure that the connected device is set as target
  • Select Debug -> Attach to Process -> App