00.1 macOS 27: The New Kernel Research Map

Phase 00 · Module 1 of 5 · Free preview

Download the Phase 00 lab package. kernel27-phase00-lab-setup-lab.zip. Unzip it into your lab workspace; every file this phase uses comes from it.

Start with the question that should shape the rest of the course:

On macOS 27, where is the real kernel research surface now, and where do researchers still waste months chasing the wrong thing?

That is what this module answers first, because the rest of the course only makes sense once the modern map is clear.

Older Apple kernel training could get away with a simpler story. Enumerate drivers, find an IOKit user client, reverse a selector, trigger memory corruption, and then climb toward proof. That path still exists. It still matters. But it is no longer the whole map, and anyone teaching macOS kernel research as if it were still 2021 is teaching a partial model. macOS 27 changed the research landscape in a way that serious students need spelled out before they open a single disassembler window:

• some surface is still unmistakably kernel
• some former kernel-adjacent surface has moved into user space
• some of the most interesting new trust boundaries live in privileged daemons, not in classic kext-style code
• and the fastest way to waste a quarter is to confuse those categories

This course is built around fixing that confusion.

The one-sentence shift

The old lazy heuristic was:

  "Apple kernel research" = "find a kext and start reversing"

On macOS 27, the correct opening heuristic is:

  "Apple kernel research" = "map the boundary first, then choose the right class of target"

That change sounds small, but it controls everything downstream. If you pick the wrong class of target, you can do excellent technical work and still produce a weak report, a non-kernel finding, or a path that never reaches the attacker model you actually care about.

So before the course teaches you how to read a selector table, a panic log, or a refcount bug, it makes you internalize the new map.

What changed on macOS 27

There are six changes that matter enough to alter how a good researcher allocates time.

1. The kernel is still rich, but the easy story is gone

IOKit user clients still exist. In-kernel parsers still exist. Security subsystems, networking paths, storage paths, peripheral families, and a surprising amount of accelerator logic still cross kernel trust boundaries. The kernel did not disappear. What disappeared is the fantasy that every valuable Apple low-level target looks like a classic "just reverse the driver" target.

You will still spend real time in the kernelcache in this course. Phases 02 through 05, then 07 through 11, are unapologetically kernel-facing. But now you will enter them with the right expectation: they are the high-value core of the map, not the whole map.

2. DriverKit matters because it is not the kernel

Apple kept pushing some hardware-facing logic out of the kernel and into DriverKit. That means some things that feel like a driver bug are now user-space bugs in a dext. Those can still be important. They can still be exploitable. They can still produce good reports. But they are not the same class of finding, do not carry the same ceiling, and do not justify the same claims.

That distinction matters commercially as much as technically. If a student cannot explain, in one sentence, why their target is kernel-resident versus DriverKit-resident, they are not ready to call it a kernel finding.

3. FSKit changed how filesystem work must be triaged

On modern macOS, some filesystem logic that researchers historically treated as "mount the image, get kernel parsing" is no longer automatically a kernel bug. Filesystem work now sits on a split map. Some parser classes still run in kernel context. Others land in FSKit or adjacent user-space machinery. The attack surface is still there, but the report category, trust boundary, and impact ceiling depend on exactly where the parser executes.

That is why this course does not teach filesystem hunting as a cargo-cult mount-and-pray exercise. It teaches the classification first, then the parser class.

4. Privileged daemons now matter more than many researchers admit

As Apple hardens classic memory-corruption paths, more interesting logic and authority lives in root or privileged daemons that accept structured input over XPC, Mach services, filesystem operations, or brokered helper paths. Some of the best modern Apple low-level findings are not "kernel RCE from a selector." They are authorization, proxy, confused-deputy, and trust-boundary failures in code that stands between a user and the kernel, or a user and a protected capability.

This matters doubly on macOS 27 because the system keeps adding service layers around new features rather than exposing all of that behavior through one obvious low-level kernel door.

5. Apple Intelligence added new target population

macOS 27 added and expanded a visible tier of on-device AI and intelligence-related daemons, frameworks, and entitlement-bearing service processes. These are not automatically kernel bugs. Most of them are not kernel at all. But they are absolutely part of the modern research map because they:

• hold privileges you do not hold
• broker access to gated accelerators or protected data paths
• add fresh state machines and fresh parsers
• create new deputy opportunities

Fresh code is where under-reviewed mistakes live. Fresh privileged code is where expensive mistakes live.

6. Hardening means target selection matters more than raw reversing skill

Pointer authentication, allocator behavior, page-protection layers, modern trust enforcement, and the general hardening of Apple silicon all mean the field punishes vague bug claims harder than it used to. An uncontrolled crash in the wrong place is less valuable than it once was. A well-characterized logic bug or a tightly demonstrated partial-control primitive in the right place may be worth more than a louder but weaker "kernel crash" story.

This is why the course spends so much time on proof discipline, attacker modeling, and the ceiling of a finding. macOS 27 rewards correct classification first and deep exploitation second.

What people mean when they say "show me the macOS 27 kext story"

Most serious students do not literally mean "I only want kernel extensions." They mean:

• what low-level surface still lives in kernel context
• what moved out
• what is newly worth hunting
• where should I spend time first if I want modern Apple results

That is the real question, and it needs a direct answer.

Here is the short version.

The macOS 27 target matrix

Use this matrix as the orientation map for the rest of the course.

If a student cannot place a target in one of those rows, they are starting too early.

Run the first classification pass on the lab

The phase package includes 00.1_surface_map.sh. It is deliberately simple. Its job is not to exploit anything. Its job is to make the system answer the first orientation questions with real evidence on the macOS 27 lab host.

Run it from the unpacked Phase 00 lab directory:

$ bash 00.1_surface_map.sh
macOS product version : 27.0
build                 : 26A5388g
kernel                : Darwin 27.0.0

== kernel-facing inventory ==
kernelcache present
IOUserClient classes: 550
sample user-client classes:
  127 IOHIDEventServiceUserClient
  116 AppleKeyStoreUserClient
   34 IOSurfaceRootUserClient
   28 AGXDeviceUserClient
   19 AppleSmartIOUserClient

== user-space driver / filesystem split ==
DriverKit extensions discovered: 19
FSKit components discovered: 8

== privileged and intelligence daemons ==
launchd system services (Apple): 428
interesting intelligence daemons:
  com.apple.intelligenceflowd
  com.apple.intelligencecontextd
  com.apple.intelligentroutingd
  com.apple.visualintelligenced
  com.apple.modelmanagerd

== first-party telemetry tools present ==
/usr/bin/eslogger present
/usr/bin/estrace present
/usr/bin/fm present

== takeaways ==
kernel-facing surface remains broad
modern user-space privileged surface is also broad
classification must come before depth

That output is not there for atmosphere. It tells you four specific things immediately.

First, the kernel-facing user-client surface is still large. Five hundred fifty user-client class hits on the lab box is not a dead ecosystem. Anyone saying "Apple moved everything out of the kernel" is simply wrong.

Second, DriverKit and FSKit are not theoretical architecture notes. They are present on the system right now. That means a researcher who does not classify execution site before writing up a target is guessing.

Third, the privileged and intelligence daemon population is large enough that ignoring it is now a strategic mistake. Four hundred-plus Apple LaunchDaemon entries and a visible cluster of intelligence daemons means the low-level map is broader than classic kernel memory corruption alone.

Fourth, Apple ships first-party tracing and AI-era tooling on the platform itself. The course uses those facts directly rather than pretending the environment never changed.

The biggest waste pattern this course is designed to stop

The most common expensive mistake in Apple kernel research is not bad reversing. It is this sequence:

1. find a low-level target that looks promising
2. assume it is kernel
3. assume it is reachable
4. assume the report ceiling is high
5. spend two or three weeks proving a statement that was false on day one

The refreshed course is designed to break that sequence early.

That is why the opening phases go in this order:

• Phase 00: map the modern territory and establish disciplined workflow
• Phase 01: build the internal model of XNU and the boundary
• Phase 02: learn the real kernel-local attack surface
• Phase 03: classify what is reachable, walled, brokered, or moved out

The ordering is deliberate. On macOS 27, target choice is part of exploitation.

The four multipliers still decide what pays

The old bounty logic did not disappear just because the surface map changed. A finding is still worth:

value = reachability x impact x novelty x proof

The reason this matters more on macOS 27 is that the hidden zero now appears earlier and in more places:

• a beautiful bug in a path only reachable by root
• a convincing crash in user-space code you mislabeled as kernel
• an AI daemon that holds powerful entitlements but never exercises them on attacker-controlled bytes
• a filesystem parser bug that lives in FSKit when you needed kernel impact
• a deputy path that looks dramatic until you realize the caller could already do the same write

The multipliers still govern the money. The macOS 27 delta changes where the hidden zero tends to hide.

What this course is actually promising

This course is not promising "here is a bag of kext bugs."

It is promising something much stronger:

• a modern, macOS 27-accurate map of the Apple low-level attack surface
• a kernel-first workflow that does not confuse kernel with kernel-adjacent
• concrete training on the bug classes that still matter in real Apple code
• disciplined triage of reachability, proof, and report ceiling
• offensive use of current platform realities, including AI-era service layers and modern first-party tooling

That is the practical difference in approach. An outdated kext-only mental model is not enough for modern Apple research; the work now depends on getting the low-level map and the target classification right before the deep reversing starts.

What stays kernel, what becomes kernel-adjacent

Burn this distinction in early.

Still true kernel research:

• IOKit user clients with kernel-resident handlers
• in-kernel parser paths
• memory-corruption classes inside kernel code
• race, refcount, and state bugs in kernel objects
• security subsystem logic that still enforces in kernel context

Kernel-adjacent but not automatically kernel:

• DriverKit dext bugs
• FSKit user-space parser issues
• privileged helper and daemon deputy paths
• intelligence service logic bugs
• user-space components that broker access to gated accelerator or policy paths

Both matter. Only one should be called a kernel finding without qualification.

Why this matters before the first lab

If this module does its job, the rest of the course reads differently.

When you reach an IOKit user client in Phase 02, you know why that surface still matters on macOS 27.

When Phase 03 teaches fresh-code strategy and deputy reopening, you understand why a new intelligence daemon can be a better lead than a familiar but over-audited target.

When the filesystem phase forces you to classify parser execution site before bragging about a mount bug, you know that is not caution for caution's sake. It is the difference between a real kernel report and a weak, overstated writeup.

When the privileged-daemon phase arrives later, it does not feel like a detour away from kernel research. It feels like part of the same low-level map.

That is the mindset this opening module is here to set.

Checkpoints

1. Name three surfaces on macOS 27 that still clearly qualify as kernel research.
2. Name three surfaces that are low-level and valuable but are not automatically kernel findings.
3. Why is "find a kext and start reversing" an incomplete opening heuristic on macOS 27?
4. What specific changes make DriverKit, FSKit, and privileged daemons important to classify before writing up a result?
5. From the lab output, what tells you the system still has broad kernel-facing surface, and what tells you the modern user-space privileged surface also matters?
6. Why is it not enough to say "this course covers kexts," and why does the modern Apple low-level map need to be taught explicitly first?

Next: 00.2 Ethics, Scope, Authorization, and Coordinated Disclosure, where the research boundary gets locked down before the first destructive loop.