Skip to main content

Core OS Layer

The Core OS layer is the lowest software layer above the hardware. It provides the kernel, drivers, and the fundamental system services that everything else runs on top of. For a pentester this is where sandboxing, codesigning enforcement, and system call filtering actually live.

XNU: Mach + BSD​

iOS's kernel, XNU, is a hybrid kernel with two main personalities:

  • Mach: the microkernel-derived part. Handles tasks, threads, virtual memory, IPC (messages, ports), and scheduling.
  • BSD: the BSD-derived part layered over Mach. Provides processes, file systems, networking (sockets), the POSIX API, and security policies (including part of the sandbox enforcement).

A process on iOS is a Mach task running threads, but it also has a BSD process identity. Most syscall-level debugging you do (syscall, socket, file I/O) is talking to the BSD layer.

Kernel Extensions (kexts) and Drivers​

  • Kernel extensions (kexts) and on newer platforms DriverKit/built-in drivers extend the kernel with hardware and I/O support.
  • iOS is much more locked down than macOS: third-party kexts cannot be loaded on a non-jailbroken device. Everything is signed and bundled into the kernelcache.
  • The kernelcache (/System/Library/Caches/com.apple.kernelcache) contains the pre-linked kernel plus all needed kexts in a single encrypted, signed image.

Apple Mobile Device (AMD) drivers​

A large part of the attack surface historically lives in IOKit drivers, the hardware-abstracting framework used by kernel extensions. IOKit drivers parse data coming from userspace, and malformed input has led to countless kernel vulnerabilities. When auditing iOS, IOKit driver interaction is a prime hunting ground.

File System Layout​

Apple exposes a sandboxed view of the filesystem to apps; here is the real layout:

/System            # the read-only signed system volume
/Library           # system-wide preferences and support data
/private/var       # the data volume (user data, apps, caches)
/var/mobile        # the "mobile" user's home (apps + app data)
/var/mobile/Containers/Data/Application/<UUID>   # per-app sandbox
/var/mobile/Containers/Bundle/Application/<UUID> # per-app .app bundle
  • /System is mounted read-only and cryptographically sealed; tampering with it is what the boot chain prevents.
  • App data lives under /var/mobile/Containers and is protected by Data Protection classes (see the security features note).

The Kernel's Role in Security​

The kernel is the security boundary you are trying to cross when you jailbreak:

  • Code signing enforcement: every executable page must be signed or mapped from a signed binary (mac_execve, dynamic code signing checks).
  • Sandbox: the Sandbox.kext enforces the per-app sandbox profile via the sandbox_check() system call and MAC (Mandatory Access Control) hooks.
  • Entitlement checks: AMFI (Apple Mobile File Integrity) in the kernel validates entitlements before letting a process use restricted APIs or hold a signed app's trust.
  • Memory mitigations: W^X (write XOR execute), kernel pointer authentication (kPAC), and hardened page tables are all enforced here.

A sandbox escape is a kernel bug by definition, which is why "jailbreak = kernel exploit" is a good mental model. Understanding the Mach/BSD split also helps you read exploit writeups: Mach bugs (port/message handling) and BSD bugs (syscalls, VFS) are distinct categories with different exploitation techniques.

Pentest relevance​

  • Inspect the sandbox profile of a target app to understand what system resources it can touch (see sandbox_check, or dump the profile on a jailbroken device).
  • Check which kernel entropy and mitigations are present via sysctl; this tells you how hard an exploit would be.
  • On a jailbroken device, tools like ps, frida, and the kernel log (/var/log) are your eyes into the Core OS layer.