This course, modeled after Jonathan Levin's "*OS Internals: Volume III", takes a practical approach to explaining the security of Apple's operating systems, by explaining the various mechanisms employed by Apple to secure the system - and yet demonstrating how they fail, time and time again. Through case studies of jailbreaks and Pegasus (the only weapons-grade malware caught in the wild), the techniques for protecting the OS integrity - as well as measures used to bypass them - are detailed.
Code samples detailing usage of each mechanism are provided as actual examples for discussion in class. Actual jailbreak code, including the latest KFD family of jailbreaks, is presented. Advanced tools - such as Xn00p, our live kernel inspection/debugging tool - allow unprecedented visualization of what happens behind the scenes in every step of the jailbreak process. This course is updated to the latest Darwin 23 releases (iOS17, macOS 10.19)!
Reverse Engineers, Security and/or Malware Researchers - both Mac and iOS - interested in getting to know Apple's Operating Systems and their security measures intimately.
Important: This course is an advanced course, and requires a priori familiarity with MacOS or iOS, as per Jonathan's Levin or Amit Singh's "Mac OS [and iOS] Internals" books. It does not discuss basic internals, but rather builds on them so as to focus on security. Participants are highly encouraged to read the books (see below, "Required Reading") throughly.
We would also suggest participants consider the basic MacOS/iOS Internals course prior to this one. This special edition training takes portions of that training (notably, mach-O and debugging techniques) and includes them here.
This course contains quite a few hands-on exercises, and walks through code samples (often in the form of guided instructor demos), as shown below
The following books are suggested as additional references for this course:
An overview of the architecture of *OS variants, from a threat assessment perspective. Focus on different abuse cases, and the mitigation techniques devised by Apple to address and prevent them.
Explaining the reactive mechanisms by means of which system activity can be monitored (though not intercepted) and logged. This includes a detailed discussion of:
The boot sequence - aside from starting up the system - is responsible for establishing and securing the chain of trust, which ensures component integrity. MacOS boot is (still) fairly lax, but that of the *OS variants is rigorously designed to be as bulletproof as possible.
This module takes a close look at the stages of boot, focusing in particular on iBoot. Focusing on a purely reverse engineering approach, this module takes apart iBoot - from BootROM to kernelcache loading:
Code Signing in Darwin not only secures code by authenticating and tamper proofing it - but also provides the substrate for all of its security features. Entitlements, Code Signature Requirements, and (more recently) Launch Constraints are all based on this important facility, which we discuss in unprecdented detail.
The Mandatory Access Control Framework (MACF) is the de-facto standard for all of Apple's security mitigation techniques - from code signing, through sandboxing. A legacy of TrustedBSD, although it is a "private" KPI, it is remarkably simple and, at the same time, powerful.
Sworn nemesis of jailbreakers, AppleMobileFileIntegrity (amfi) has become the linchpin of Darwin security, controlling the kernel-enforcement of code signing and kernel-level entitlements.
The Apple Sandbox mechanism has evolved dramatically since its inception in MacOS 10.5 as "SeatBelt". It has also diverged in its implementations outside MacOS.
Ports are mere 32-bit identifiers in user space, but kernel space reveals a vast menagerie of complicated objects, of which IPC ports are but one type. This module examines thoese objects in detail, showing live kernel memory using xn00p2 of various objects, including:
Everything that user mode "sees" and touches is a figment of the kernel's memory. Understanding memory structures and management is paramount - for researchers and exploiters alike. This module discusses in depth the various allocation mechanisms of kernel memory
Apple is one of the only vendors to adopt proprietary protections for physical memory. Starting with the simple "WatchTower" KPP, Apple moved to introduce KTRR in the A10, followed by APRR (A11), GXF (A12) and applications such as PPL and, most recently (in iOS 17.0), SPTM & TXM. But what do all these acronyms mean? And what is their impact on exploitation?
IOKit is the most advanced and powerful feature of XNU, allowing C++ code in kernel with all its might - Object orientation and inheritance - and all its weaknesses. IOKit objects have become crucial for many an exploit, both as a vector for vulnerabilities, and as a mechanism for kernel code execution.
We turn our attention to discuss a few practical examples - as many as time permits, with actual code samples showing point proofs of concept on vulnerable (past) versions of MacOS and *OS. Exact samples may change by time of training, but at this point are:
Jonathan Levin is an expert on operating system internals, known for his “macOS/iOs internals” and “android internals” books. Jonathan is a cofounder of DataFlow Forensics, a security company specializing in the detection of malware and APT on mobile devices.
