Abstract

Reading the system. The first course of the iOS Security Research sequence, and the one that makes the other two possible.

Given an iOS release they have never seen and an iPhone in its shipped state, a student who finishes this class builds the laboratory, obtains and symbolicates the kernelcache, locates any kernel subsystem inside it, reads that subsystem’s code to a conclusion, drives it from a program running on the device, and produces an attack surface map whose reachability claims are measured rather than assumed.

The course is organised in four parts. The first builds the laboratory and gets the artifact: what an installer image contains, how the kernelcache is packed, where function starts come from, how to merge two independent sources of names — and why a symbol may be wrong and how to tell. The second teaches the privileged machine the kernel runs on, which is not general ARM64: the exception levels this silicon actually uses, the exception path and the syndrome decoded by hand, translation and the shape of the address space, and pointer authentication as a scheme rather than as a set of instructions. The third is the kernel itself — Mach tasks, threads, ports and IPC, virtual memory, the zone allocator, and the BSD layer where credentials live. The fourth is the driver surface, which is the largest attacker-reachable surface on the platform, and the security model stated as what each defence stops and what it does not.

Who Should Attend

Professionals who intend to do original security research on Apple’s mobile platform, and who already read ARM64 disassembly fluently. Reverse engineers, exploit developers, malware analysts and vulnerability researchers moving onto iOS from another platform are the intended audience.

Key Learning Objectives

This class has the following goals:

  • Build a research laboratory on a Mac and an iPhone in its shipped state, and get a citable measurement out of it.
  • Download an installer image, extract the kernelcache, symbolicate it, and decide which of two disagreeing symbol sources is right.
  • Explain the exception levels this silicon uses, and establish by measurement what an application may not touch.
  • Decode an exception syndrome by hand before letting a tool do it.
  • Explain pointer authentication as a scheme: the keys, what each one covers, where a signature’s bits live, and why the context value is the part an attacker wants.
  • Locate the four distinct entry conventions an application can use to reach kernel code, in the binary rather than in documentation.
  • Read a large kernel function — several hundred instructions — to a written description of what it does with each argument.
  • Explain the Mach object model, inter-process communication, and virtual memory as the objects that every kernel technique manipulates.
  • Predict the kernel heap: how an allocation is routed to a zone, what the free path does, and why per-processor caching makes prediction harder than a textbook suggests.
  • Explain how an application reaches a driver through IOKit, and enumerate which user clients this application can open.
  • State, for each of the six platform defences, what it stops and what it does not.
  • Confirm or refute a published claim about iOS internals on your own kernelcache and your own device.

Prerequisite Knowledge

Students should have:

  • ARM64 Assembly and Reverse Engineering, or equivalent fluency measured against the sixteen-item contract published at the end of that course.
  • The ability to read AArch64 disassembly without reaching for a manual.
  • Daily use of IDA Pro on any platform.
  • The ability to decode a pointer authentication instruction, even if nobody has yet explained what the scheme is for.
  • No Apple platform experience and no kernel experience is assumed.

Lab Requirements

Students must prepare the following lab configuration:

  • A Mac with Apple Silicon (M series).
  • One iPhone, in its shipped state.
  • IDA Pro for ARM64 binaries.

Additional lab instructions will be sent to students prior the class.

Nothing in this sequence asks for a jailbreak, an unlocked device or a kernel debugger, and no exercise depends on a laboratory a student cannot rebuild afterwards. That constraint is deliberate, and it is a teaching asset rather than a limitation, because it is the situation a researcher is actually in. Four consequences run through every module:

  • Every device measurement is taken by a signed application the student builds, deploys, runs and removes. The application writes its report to disk as it goes, so an exercise that ends in a dead process still produces a result: where the file stops is the measurement.
  • The kernel is read statically, from a kernelcache the student extracts themselves out of an installer image they download themselves. That is the first laboratory of this course and it is deliberately not prepared in advance.
  • There is no kernel debugger, so dynamic work is the application harness, the return code, the panic log and the differential between two releases.
  • The instructor demonstrates what the student cannot run. Measurements needing several machines or a debug connection are shown live, with their commands and outputs, and labelled as demonstrations.

Summary of Training Topics

The laboratory and the artifact

  • The research laboratory, and how to get a result out of it
  • The installer image, the kernelcache, and symbols

The machine the kernel runs on

  • ARM64 as the kernel is written in it
  • Exception levels, and the wall around an application
  • The exception path, and reading a fault
  • Translation, and the shape of the address space
  • Pointer authentication, and the other security instructions

The kernel

  • What XNU is, the four ways in, and where it lives
  • Reading a large kernel function
  • Mach: tasks, threads, ports and the object model
  • Mach inter-process communication
  • Mach virtual memory
  • The kernel heap, and why you must predict it
  • The BSD layer: processes, credentials, descriptors and files

The driver surface and the security model

  • IOKit, and how an application reaches a driver
  • The security model, and what each part actually stops
  • Final exercise: a claim, confirmed or refuted

The Final Exercise

The student takes a published claim about iOS internals — from a talk, a blog post, a book or a manual page — and confirms or refutes it on their own kernelcache and their own device. The deliverable is one page: the claim, the command, the output, the interpretation, and the verdict.

It is the smallest piece of work that requires the whole course, it produces something a student can show an employer, and it teaches the habit the rest of the sequence depends on. A surprising number of published claims do not survive it, which is itself the lesson.

What This Course Is Not

It does not find a vulnerability and it does not write an exploit. It is the course that makes both possible, and saying so plainly is the reason students arrive at iOS Security Research 2 able to work.

What This Course Does Not Cover

Named so that the boundary is visible: the boot chain and the signing of each stage; the file system; the networking stack; the scheduler; the secure enclave and the other coprocessors; the dynamic loader and the shared cache.

All six are kernel subsystems or signed components, and the capability this course delivers is reading one of those to a verdict. A student who has finished it opens any of the six in a disassembler, locates its entry points by the method taught here, and reads it — slower than they would read something taught in class, and by the same route. That is a design choice rather than an omission: six subsystems demonstrated would cost the hours the method itself takes, and the method generalises while six examples do not.

Note: Topics can be added, merged or removed without prior notice!