Fuzzing iOS code on macOS at native speed

Or how iOS apps on macOS work under the hood

Posted by Samuel Groß, Project Zero

This short post explains how code compiled for iOS can be run natively on Apple Silicon Macs.

With the introduction of Apple Silicon Macs, Apple also made it possible to run iOS apps natively on these Macs. This is fundamentally possible due to (1) iPhones and Apple Silicon Macs both using the arm64 instruction set architecture (ISA) and (2) macOS using a mostly compatible set of runtime libraries and frameworks while also providing /System/iOSSupport which contains the parts of the iOS runtime that do not exist on macOS. Due to this, it should be possible to run not just complete apps but also standalone iOS binaries or libraries on Mac. This might be interesting for a number of reasons, including:

It allows fuzzing closed-source code compiled for iOS on a Mac
It allows dynamic analysis of iOS code in a more “friendly” environment

This post explains how this can be achieved in practice. The corresponding code can be found here and allows executing arbitrary iOS binaries and library code natively on macOS. The tool assumes that SIP has been disabled and has been tested on macOS 11.2 and 11.3. With SIP enabled, certain steps will probably fail.

We originally developed this tool for fuzzing a 3rd-party iOS messaging app. While that particular project didn’t yield any interesting results, we are making the tool public as it could help lower the barrier of entry for iOS security research.

The Goal

The ultimate goal of this project is to execute code compiled for iOS natively on macOS. While it would be possible to achieve this goal (at least for some binaries/libraries) simply by swapping the platform identifier in the mach-o binary, our approach will instead use the existing infrastructure for running iOS apps on macOS. This has two benefits:

It will guarantee that all dependent system libraries of the iOS code will exist. In practice, this means that if a dependent library does not already exist on macOS, it will automatically be loaded from /System/iOSSupport instead
The runtime (OS services, frameworks, etc.) will, if necessary, emulate their iOS behavior since they will know that the process is an iOS one

To start, we’ll take a simple piece of C source code and compile it for iOS:

> cat hello.c

#include <stdio.h>

int main() {

puts("Hello from an iOS binary!");

return 0;

}

> clang -arch arm64 hello.c -o hello -isysroot \

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk

> file hello

hello: Mach-O 64-bit executable arm64

> otool -l hello

…

Load command 10

cmd LC_BUILD_VERSION

cmdsize 32

platform 2 # Platform 2 is iOS

minos 14.4

sdk 14.4

ntools 1

tool 3

version 609.8

…

The Kernel

Attempting to execute the freshly compiled binary (on macOS 11.2) will simply result in

> ./hello

[1] 13699 killed ./hello

While the exit status informs us that the process was terminated through SIGKILL, it does not contain any additional information about the specific reason for that. However, it does seem likely that the process is terminated by the kernel during the execve(2) or posix_spawn(2) syscall. And indeed, the crash report generated by the system states:

Termination Reason: EXEC, [0xe] Binary with wrong platform

This error corresponds to EXEC_EXIT_REASON_WRONG_PLATFORM in the kernel, and that constant is only referenced in a single function: check_for_signature:

static int

check_for_signature(proc_t p, struct image_params *imgp)

{

…;

#if XNU_TARGET_OS_OSX

/* Check for platform passed in spawn attr if iOS binary is being spawned */

if (proc_platform(p) == PLATFORM_IOS) {

struct _posix_spawnattr *psa = imgp->ip_px_sa;

if (psa == NULL || psa->psa_platform == 0) {

…;

signature_failure_reason = os_reason_create(OS_REASON_EXEC,

EXEC_EXIT_REASON_WRONG_PLATFORM);

error = EACCES;

goto done;

} else if (psa->psa_platform != PLATFORM_IOS) {

/* Simulator binary spawned with wrong platform */

signature_failure_reason = os_reason_create(OS_REASON_EXEC,

EXEC_EXIT_REASON_WRONG_PLATFORM);

error = EACCES;

goto done;

} else {

printf("Allowing spawn of iOS binary %s since

correct platform was passed in spawn\n", p->p_name);

}

#endif /* XNU_TARGET_OS_OSX */

…;

}

This code is active on macOS and will execute if the platform of the to-be-executed process is PLATFORM_IOS. In essence, the code checks for an undocumented posix_spawn attribute, psa_platform, and in the absence of it (or if its value is not PLATFORM_IOS), will terminate the process in the way we have previously observed.

As such, to avoid EXEC_EXIT_REASON_WRONG_PLATFORM, it should only be necessary to use the undocumented posix_spawnattr_set_platform_np syscall to set the target platform to PLATFORM_IOS, then invoke posix_spawn to execute the iOS binary:

posix_spawnattr_t attr;

posix_spawnattr_init(&attr);

posix_spawnattr_set_platform_np(&attr, PLATFORM_IOS, 0);

posix_spawn(&pid, binary_path, NULL, &attr, argv, environ);

Doing that will now result in:

> ./runner hello

...

[*] Child exited with status 5

No more SIGKILL, progress! Exit status 5 corresponds to SIGTRAP, which likely implies that the process is now terminating in userspace. And indeed, the crash report confirms that the process is crashing sometime during library initialization now.

Userspace

At this point we have a PLATFORM_IOS process running in macOS userspace. The next thing that now happens is that dyld, the dynamic linker, starts mapping all libraries that the binary depends on and executes any initializers they might have. Unfortunately, one of the first libraries now being initialized, libsystem_secinit.dylib, tries to determine whether it should initialize the app sandbox based on the binary’s platform and its entitlements. The logic is roughly:

initialize_app_sandbox = False

if entitlement(“com.apple.security.app-sandbox”) == True:

initialize_app_sandbox = True

if active_platform() == PLATFORM_IOS &&

entitlement(“com.apple.private.security.no-sandbox”) != True:

initialize_app_sandbox = True

As such, libsystem_secinit will decide that it should initialize the app sandbox and will then contact secinitd(8), “the security policy initialization daemon”, to obtain a sandbox profile. As that daemon cannot determine the app corresponding to the process in question it will fail, and libsystem_secinit.dylib will then abort(3) the process:

(lldb) bt

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT

* frame #0: libsystem_secinit.dylib`_libsecinit_appsandbox.cold.5

frame #1: libsystem_secinit.dylib`_libsecinit_appsandbox

frame #2: libsystem_trace.dylib` ...

frame #3: libsystem_secinit.dylib`_libsecinit_initializer

frame #4: libSystem.B.dylib`libSystem_initializer

frame #5: libdyld.dylib`...

frame #6: libdyld.dylib`...

frame #7: libdyld.dylib`dyld3::AllImages::runLibSystemInitializer

frame #8: libdyld.dylib`...

frame #9: dyld`...

frame #10: dyld`dyld::_main

frame #11: dyld`dyldbootstrap::start

frame #12: dyld`_dyld_start + 56

As a side note, logic like the above will turn out to be a somewhat common theme: various components responsible for the runtime environment will have special handling for iOS binaries, in which case they tend to enforce various policies more aggressively.

One possible way to solve this would be to sign the iOS binary with a self-signed (and locally trusted) code signing certificate and granting it the “com.apple.private.security.no-sandbox” entitlement. This would then cause libsystem_secinit to not attempt to initialize the app sandbox. Unfortunately, it seems that while AppleMobileFileIntegrity (“amfi” - the OS component implementing various security policies like entitlement and code signing checks) will allow macOS binaries to be signed by locally-trusted code-signing certificates if SIP is disabled, it will not do so for iOS binaries. Instead, it appears to enforce roughly the same requirements as on iOS, namely that the binary must either be signed by Apple directly (in case the app is downloaded from the app store) or there must exist a valid (i.e. one signed by Apple) provisioning profile for the code-signing entity which explicitly allows the entitlements. As such, this path appears like a dead end.

Another way to work around the sandbox initialization would be to use dyld interposing to replace xpc_copy_entitlements_for_self, which libsystem_secinit invokes to obtain the process’ entitlements, with another function that would simply return the “com.apple.private.security.no-sandbox” entitlement. This would in turn prevent libsystem_secinit from attempting to initialize the sandbox.

Unfortunately, the iOS process is subject to further restrictions, likely part of the “hardened runtime” suite, which causes dyld to disable library interposing (some more information on this mechanism is available here). This policy is also implemented by amfi, in AppleMobileFileIntegrity.kext (the kernel component of amfi):

__int64 __fastcall macos_dyld_policy_library_interposing(proc *a1, int *a2)

{

int v3; // w8

v3 = *a2;

...

if ( (v3 & 0x10400) == 0x10000 ) // flag is set for iOS binaries

{

logDyldPolicyRejection(a1, "library interposing", "Denying library interposing for iOS app\n");

return 0LL;

}

return 64LL;

}

As can be seen, AMFI will deny library interposing for all iOS binaries. Unfortunately, I couldn’t come up with a better solution for this than to patch the code of dyld at runtime to ignore AMFI’s policy decision and thus allow library interposing. Fortunately though, doing lightweight runtime code patching is fairly easy through the use of some classic mach APIs:

Find the offset of _amfi_check_dyld_policy_self in /usr/lib/dyld, e.g. with nm(1)
Start the iOS process with the POSIX_SPAWN_START_SUSPENDED attribute so it is initially suspended (the equivalent of SIGSTOP). At this point, only dyld and the binary itself will have been mapped into the process’ memory space by the kernel.
“Attach” to the process using task_for_pid
Find the location of dyld in memory through vm_region_recurse_64
Map dyld’s code section writable using vm_protect(VM_PROT_READ | VM_PROT_WRITE | VM_PROT_COPY) (where VM_PROT_COPY is seemingly necessary to force the pages to be copied since they are shared)
Patch _amfi_check_dyld_policy_self through vm_write to simply return 0x5f (indicating that dyld interposing and other features should be allowed)
Map dyld’s code section executable again

To be able to use the task_for_pid trap, the runner binary will either need the “com.apple.security.cs.debugger” entitlement or root privileges. However, as the runner is a macOS binary, it can be given this entitlement through a self-signed certificate which amfi will then allow.

As such, the full steps necessary to launch an iOS binary on macOS are:

Use the posix_spawnattr_set_platform_np API to set the target platform to PLATFORM_IOS
Execute the new process via posix_spawn(2) and start it suspended
Patch dyld to allow library interposing
In the interposed library, claim to possess the com.apple.security.cs.debugger entitlement by replacing xpc_copy_entitlements_for_self
Continue the process by sending it SIGCONT

This can now be seen in action:

> cat hello.c

#include <stdio.h>

int main() {

puts("Hello from an iOS binary!");

return 0;

}

> clang -arch arm64 hello.c -o hello -isysroot \

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk interpose.dylib

> ./runner hello

[*] Preparing to execute iOS binary hello

[+] Child process created with pid: 48302

[*] Patching child process to allow dyld interposing...

[*] _amfi_check_dyld_policy_self at offset 0x54d94 in /usr/lib/dyld

[*] /usr/lib/dyld mapped at 0x1049ec000

[+] Successfully patched _amfi_check_dyld_policy_self

[*] Sending SIGCONT to continue child

[*] Faking no-sandbox entitlement in xpc_copy_entitlements_for_self

Hello from an iOS binary!

[*] Child exited with status 0

Fuzzing

With the ability to launch iOS processes, it now becomes possible to fuzz existing iOS code natively on macOS as well. I decided to use Honggfuzz for a simple PoC of this that also used lightweight coverage guidance (based on the Trapfuzz instrumentation approach). The main issue with this approach is that honggfuzz uses the combination of fork(2) followed by execve(2) to create the child processes, while also performing various operations, such as dup2’ing file descriptors, setting environment variables, etc after forking but before exec’ing. However, the iOS binary must be executed through posix_spawn, which means that these operations must be performed at some other time. Furthermore, as honggfuzz itself is still compiled for macOS, some steps of the compilation of the target binary will fail (they will attempt to link previously compiled .o files, but now the platform no longer matches) and so have to be replaced. There are certainly better ways to do this (and I encourage the reader to implement it properly), but this was the approach that I got to work the quickest.

The hacky proof-of-concept patch for honggfuzz can be found here. In addition to building honggfuzz for arm64, the honggfuzz binary is subsequently signed and given the “com.apple.security.cs.debugger” entitlement in order for task_for_pid to work.

Conclusion

This blog post discussed how iOS apps are run on macOS and how that functionality can be used to execute any code compiled for iOS natively on macOS. This in turn can facilitate dynamic analysis and fuzzing of iOS code, and thus might make the platform a tiny bit more open for security researchers.

Attachment 1: runner.c

// clang -o runner runner.c

// cat <<EOF > entitlements.xml

// <?xml version="1.0" encoding="UTF-8"?>

// <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"\>

// <plist version="1.0">

// <dict>

// <key>com.apple.security.cs.debugger</key>

// <true/>

// </dict>

// </plist>

// EOF

// # Find available code signing identities using `security find-identity`

// codesign -s "$IDENTITY" --entitlements entitlements.xml runner

#include <stdlib.h>

#include <stdio.h>

#include <string.h>

#include <dlfcn.h>

#include <signal.h>

#include <unistd.h>

#include <spawn.h>

#include <sys/wait.h>

#include <mach/mach_init.h>

#include <mach/vm_map.h>

#include <mach/vm_page_size.h>

#define page_align(addr) (vm_address_t)((uintptr_t)(addr) & (~(vm_page_size - 1)))

#define PLATFORM_IOS 2

extern char **environ;

extern int posix_spawnattr_set_platform_np(posix_spawnattr_t*, int, int);

void instrument(pid_t pid) {

kern_return_t kr;

task_t task;

puts("[*] Patching child process to allow dyld interposing...");

// Find patch point

FILE* output = popen("nm -arch arm64e /usr/lib/dyld | grep _amfi_check_dyld_policy_self", "r");

unsigned int patch_offset;

int r = fscanf(output, "%x t _amfi_check_dyld_policy_self", &patch_offset);

if (r != 1) {

printf("Failed to find offset of _amfi_check_dyld_policy_self in /usr/lib/dyld\n");

return;

}

printf("[*] _amfi_check_dyld_policy_self at offset 0x%x in /usr/lib/dyld\n", patch_offset);

// Attach to the target process

kr = task_for_pid(mach_task_self(), pid, &task);

if (kr != KERN_SUCCESS) {

printf("task_for_pid failed. Is this binary signed and possesses the com.apple.security.cs.debugger entitlement?\n");

return;

}

vm_address_t dyld_addr = 0;

int headers_found = 0;

vm_address_t addr = 0;

vm_size_t size;

vm_region_submap_info_data_64_t info;

mach_msg_type_number_t info_count = VM_REGION_SUBMAP_INFO_COUNT_64;

unsigned int depth = 0;

while (1) {

// get next memory region

kr = vm_region_recurse_64(task, &addr, &size, &depth, (vm_region_info_t)&info, &info_count);

if (kr != KERN_SUCCESS)

break;

unsigned int header;

vm_size_t bytes_read;

kr = vm_read_overwrite(task, addr, 4, (vm_address_t)&header, &bytes_read);

if (kr != KERN_SUCCESS) {

// TODO handle this, some mappings are probably just not readable

printf("vm_read_overwrite failed\n");

return;

}

if (bytes_read != 4) {

// TODO handle this properly

printf("[-] vm_read read to few bytes\n");

return;

}

if (header == 0xfeedfacf) {

headers_found++;

}

if (headers_found == 2) {

// This is dyld

dyld_addr = addr;

break;

}

addr += size;

}

if (dyld_addr == 0) {

printf("[-] Failed to find /usr/lib/dyld\n");

return;

}

printf("[*] /usr/lib/dyld mapped at 0x%lx\n", dyld_addr);

vm_address_t patch_addr = dyld_addr + patch_offset;

// VM_PROT_COPY forces COW, probably, see vm_map_protect in vm_map.c

kr = vm_protect(task, page_align(patch_addr), vm_page_size, false, VM_PROT_READ | VM_PROT_WRITE | VM_PROT_COPY);

if (kr != KERN_SUCCESS) {

printf("vm_protect failed\n");

return;

}

// MOV X8, 0x5f

// STR X8, [X1]

// RET

const char* code = "\xe8\x0b\x80\xd2\x28\x00\x00\xf9\xc0\x03\x5f\xd6";

kr = vm_write(task, patch_addr, (vm_offset_t)code, 12);

if (kr != KERN_SUCCESS) {

printf("vm_write failed\n");

return;

}

kr = vm_protect(task, page_align(patch_addr), vm_page_size, false, VM_PROT_READ | VM_PROT_EXECUTE);

if (kr != KERN_SUCCESS) {

printf("vm_protect failed\n");

return;

}

puts("[+] Successfully patched _amfi_check_dyld_policy_self");

}

int run(const char** argv) {

pid_t pid;

int rv;

posix_spawnattr_t attr;

rv = posix_spawnattr_init(&attr);

if (rv != 0) {

perror("posix_spawnattr_init");

return -1;

}

rv = posix_spawnattr_setflags(&attr, POSIX_SPAWN_START_SUSPENDED);

if (rv != 0) {

perror("posix_spawnattr_setflags");

return -1;

}

rv = posix_spawnattr_set_platform_np(&attr, PLATFORM_IOS, 0);

if (rv != 0) {

perror("posix_spawnattr_set_platform_np");

return -1;

}

rv = posix_spawn(&pid, argv[0], NULL, &attr, argv, environ);

if (rv != 0) {

perror("posix_spawn");

return -1;

}

printf("[+] Child process created with pid: %i\n", pid);

instrument(pid);

printf("[*] Sending SIGCONT to continue child\n");

kill(pid, SIGCONT);

int status;

rv = waitpid(pid, &status, 0);

if (rv == -1) {

perror("waitpid");

return -1;

}

printf("[*] Child exited with status %i\n", status);

posix_spawnattr_destroy(&attr);

return 0;

}

int main(int argc, char* argv[]) {

if (argc <= 1) {

printf("Usage: %s path/to/ios_binary\n", argv[0]);

return 0;

}

printf("[*] Preparing to execute iOS binary %s\n", argv[1]);

return run(argv + 1);

}

Attachment 2: interpose.c

// clang interpose.c -arch arm64 -o interpose.dylib -shared -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk

#include <stdio.h>

#include <unistd.h>

typedef void* xpc_object_t;

extern xpc_object_t xpc_dictionary_create(void*, void*, int);

extern void xpc_dictionary_set_value(xpc_object_t, const char*, xpc_object_t);

extern xpc_object_t xpc_bool_create(int);

extern xpc_object_t xpc_copy_entitlements_for_self();

// From https://opensource.apple.com/source/dyld/dyld-97.1/include/mach-o/dyld-interposing.h.auto.html

* Example:

* static

* int

* my_open(const char* path, int flags, mode_t mode)

* {

* int value;

* // do stuff before open (including changing the arguments)

* value = open(path, flags, mode);

* // do stuff after open (including changing the return value(s))

* return value;

* }

* DYLD_INTERPOSE(my_open, open)

#define DYLD_INTERPOSE(_replacment,_replacee) \

__attribute__((used)) static struct{ const void* replacment; const void* replacee; } _interpose_##_replacee \

__attribute__ ((section ("__DATA,__interpose"))) = { (const void*)(unsigned long)&_replacment, (const void*)(unsigned long)&_replacee };

xpc_object_t my_xpc_copy_entitlements_for_self() {

puts("[*] Faking com.apple.private.security.no-sandbox entitlement in interposed xpc_copy_entitlements_for_self");

xpc_object_t dict = xpc_dictionary_create(NULL, NULL, 0);

xpc_dictionary_set_value(dict, "com.apple.private.security.no-sandbox", xpc_bool_create(1));

return dict;

}

DYLD_INTERPOSE(my_xpc_copy_entitlements_for_self, xpc_copy_entitlements_for_self);