Abstract

Finding and proving a defect. The second course of the iOS Security Research sequence, and the one that turns a reader of the platform into a researcher who produces findings.

Given a component and no further guidance, a student who finishes this class splits it into parts small enough to read, decides what to read first and says why, reads it, and reaches one of two honest outcomes: a defect with a minimal reproducer that demonstrates a boundary being crossed on a device, bounded to the releases it affects and written up the way a vendor needs it; or a negative result with its coverage stated, which is a finding of a different kind and is taught as one.

The course is organised in four parts. The first is the method: the research cycle and the condition for stopping, the attack surface map, and reachability measured rather than assumed. The second is reading for defects — each bug class presented as a short program the student compiles, runs, breaks and disassembles, so the class is recognised later by its shape in compiled code rather than by its name in a list. The third is the instruments, and how each one lies; a tool that reports nothing is the central hazard, because an empty result and a clean surface look identical. The fourth is proving it: the reproducer with both of its controls, bounding the affected releases, and the report a vendor can act on.

The One Thing This Course Refuses To Do

It does not promise that every student finds a vulnerability in fifty hours. Nobody can promise that, and a course that implies it teaches students to force a finding, which is how bad reports get filed.

What it promises is the loop, the instruments, the judgement to stop, and the ability to prove whichever answer is true.

Who Should Attend

Researchers who can already locate and read an iOS kernel subsystem and measure its behaviour on a device, and who now want to produce findings a vendor will accept. It is the natural continuation of iOS Security Research 1.

Taken together, courses 1 and 2 are a complete programme on their own: they produce a researcher who can find a defect and report it, which is a whole professional outcome and the one most employers are buying.

Key Learning Objectives

This class has the following goals:

  • Split a component into parts small enough to read, ordered, with a stated reason for the order.
  • Apply the research cycle, and recognise its exit condition: two hypotheses that do not narrow means the part is finished.
  • Build an attack surface map in the binary rather than from documentation, and finish it when every entry point has an owner.
  • State a reachability result so that it stays true — which program, which profile, which arguments, which release.
  • Recognise each bug class by its shape in compiled code.
  • Determine whether a given driver was built with bounds checking, and say how you know.
  • Explain the memory model: what one core may observe of another, what each of the three barriers orders, and why a race is possible at all.
  • Distinguish a collision from an ordering violation, and classify a race before choosing a technique.
  • Find logic and authorization defects — the class that survives a decade of fuzzing, because a fuzzer has an oracle for a crash and none for a call that succeeded and should have been refused.
  • Choose and check a pair that must agree: a validator against its consumer, a declared size against the bytes touched, this release against the last.
  • Build a census, and recognise the five ways one lies.
  • Perform dynamic analysis with no kernel debugger, and read a panic report properly — joining it to the exact binary that produced it.
  • Reduce a working trigger to a minimal reproducer that keeps both of its controls.
  • Bound the affected releases, separating a change from a relocation.
  • Write a report a vendor can act on, and work inside coordinated disclosure rules.

Prerequisite Knowledge

Students should have:

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.

As in the rest of the sequence, no jailbreak, no unlocked device and no kernel debugger is required. Dynamic work is the application harness, the return code, the panic log and the differential between two releases — and this course teaches that set as a method in its own right rather than as a substitute for something better.

Summary of Training Topics

The method

  • The research cycle, and the condition for stopping
  • The attack surface map
  • Reachability, measured rather than assumed

Reading for defects

  • The bug classes, as code you can break
  • Memory safety, and what the compiler has already removed
  • The memory model, and why races are possible at all
  • Races, and the two things the word means
  • Logic and authorization defects
  • The pair discipline

The instruments, and how each one lies

  • Static analysis: the tools and their blind spots
  • Building a census, and the five ways one lies
  • Dynamic analysis without a kernel debugger
  • Panics and crashes, read properly

Proving it

  • The reproducer
  • Bounding the affected releases
  • The report a vendor can act on
  • Ethics, disclosure and the programme rules
  • Final exercise: a finding, or an honest negative

The Final Exercise

One component, worked to a conclusion. The deliverable is either a finding document with a reproducer and a version range, or a negative result that states which lenses were applied, what was read, what was not read, and the coverage reached.

Both are marked to the same standard, and that is the point: the profession does not reward the lucky, it rewards the researcher whose verdict can be trusted.

What This Course Does Not Cover

Fuzzing as a discipline in its own right; analysis of patched defects for technique; the file system, networking and browser surfaces as worked examples; the full catalogue of published bug classes with citations.

Fuzzing is excluded because it is a separate craft with its own tooling and its own failure modes, and because the defects this sequence aims at are the ones a fuzzer structurally cannot find — a call that succeeded and should have been refused raises no crash for a fuzzer to notice. A student who wants it should take Fuzzing for Vulnerability Research rather than four hours of it here. The other three are applications of what this course does teach: a patched defect is read with the release differential, and a new surface is approached with the attack surface map and the reachability method.

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