// pointer P points into A with tag T1 P = (T1 << 56) | 0x1000

// Valid store *(P + offset) = value // tag T1 matches allocation → allowed

// Overflow attempt: P’ = P + size_of_A (into B region) *(P’ + delta) = value → pointer includes tag T1 but memory block has tag T2 → mismatch → fault

// Free A, allocator retags it to T3 free(A)

// Use-after-free: *(P) = value → pointer still has old tag T1, memory region is now T3 → mismatch → fault

</details>

#### Sınırlamalar & challenges

- **Intrablock overflows**: Eğer overflow aynı allocation içinde kalır (boundary’i aşmaz) ve tag aynı kalmaya devam ederse, tag mismatch bunu yakalamaz.
- **Tag width limitation**: Tag için yalnızca birkaç bit (ör. 4 bit veya küçük bir domain) mevcut — sınırlı namespace.
- **Side-channel leaks**: Eğer tag bitleri (cache / speculative execution yoluyla) leaked olabiliyorsa, saldırgan geçerli tagleri öğrenip atlatabilir. Apple’ın tag confidentiality enforcement bunu hafifletmeyi amaçlar.
- **Performance overhead**: Her load/store sırasında yapılan tag kontrolleri maliyet katar; Apple donanımı optimize ederek overhead’i düşük tutmak zorunda.
- **Compatibility & fallback**: Eski donanımda veya EMTE desteklemeyen bölümlerde fallback mekanizmaları gerekli. Apple, MIE’nin yalnızca destekleyen cihazlarda etkinleştirildiğini iddia ediyor.
- **Complex allocator logic**: Allocator tag’leri, retagging, hizalama sınırlarını ve yanlış-tag çakışmalarını yönetmek zorunda. Allocator mantığındaki hatalar yeni zafiyetler ortaya çıkarabilir.
- **Mixed memory / hybrid areas**: Bazı bellek bölgeleri untagged (legacy) kalabilir; bu da birlikte çalışmayı daha karmaşık hale getirir.
- **Speculative / transient attacks**: Birçok mikro-mimari korumada olduğu gibi, speculative execution veya micro-op füzyonları kontrolleri transient olarak atlatabilir ya da tag bitlerini leak edebilir.
- **Limited to supported regions**: Apple EMTE’yi yalnızca seçili, yüksek-riskli alanlarda (kernel, security-critical subsystems) zorunlu kılabilir; evrensel olmayabilir.



---

## Key enhancements / differences compared to standard MTE

Here are the improvements and changes Apple emphasizes:

| Feature | Original MTE | EMTE (Apple’s enhanced) / MIE |
|---|---|---|
| **Check mode** | Supports synchronous and asynchronous modes. In async, tag mismatches are reported later (delayed)| Apple insists on **synchronous mode** by default—tag mismatches are caught immediately, no delay/race windows allowed.|
| **Coverage of non-tagged memory** | Accesses to non-tagged memory (e.g. globals) may bypass checks in some implementations | EMTE requires that accesses from a tagged region to non-tagged memory also validate tag knowledge, making it harder to bypass by mixing allocations.|
| **Tag confidentiality / secrecy** | Tags might be observable or leaked via side channels | Apple adds **Tag Confidentiality Enforcement**, which attempts to prevent leakage of tag values (via speculative side-channels etc.).|
| **Allocator integration & retagging** | MTE leaves much of allocator logic to software | Apple’s secure typed allocators (kalloc_type, xzone malloc, etc.) integrate with EMTE: when memory is allocated or freed, tags are managed at fine granularity.|
| **Always-on by default** | In many platforms, MTE is optional or off by default | Apple enables EMTE / MIE by default on supported hardware (e.g. iPhone 17 / A19) for kernel and many user processes.|

Because Apple controls both the hardware and software stack, it can enforce EMTE tightly, avoid performance pitfalls, and close side-channel holes.

---

## How EMTE works in practice (Apple / MIE)

Here’s a higher-level description of how EMTE operates under Apple’s MIE setup:

1. **Tag assignment**
- When memory is allocated (e.g. in kernel or user space via secure allocators), a **secret tag** is assigned to that block.
- The pointer returned to the user or kernel includes that tag in its high bits (using TBI / top byte ignore mechanisms).

2. **Tag checking on access**
- Whenever a load or store is executed using a pointer, the hardware checks that the pointer’s tag matches the memory block’s tag (allocation tag). If mismatch, it faults immediately (since synchronous).
- Because it's synchronous, there is no “delayed detection” window.

3. **Retagging on free / reuse**
- When memory is freed, the allocator changes the block’s tag (so older pointers with old tags no longer match).
- A use-after-free pointer would therefore have a stale tag and mismatch when accessed.

4. **Neighbor-tag differentiation to catch overflows**
- Adjacent allocations are given distinct tags. If a buffer overflow spills into neighbor’s memory, tag mismatch causes a fault.
- This is especially powerful in catching small overflows that cross boundary.

5. **Tag confidentiality enforcement**
- Apple must prevent tag values being leaked (because if attacker learns the tag, they could craft pointers with correct tags).
- They include protections (microarchitectural / speculative controls) to avoid side-channel leakage of tag bits.

6. **Kernel and user-space integration**
- Apple uses EMTE not just in user-space but also in kernel / OS-critical components (to guard kernel against memory corruption).
- The hardware/OS ensures tag rules apply even when kernel is executing on behalf of user space.

Because EMTE is built into MIE, Apple uses EMTE in synchronous mode across key attack surfaces, not as opt-in or debugging mode.



---

## Exception handling in XNU

When an **exception** occurs (e.g., `EXC_BAD_ACCESS`, `EXC_BAD_INSTRUCTION`, `EXC_CRASH`, `EXC_ARM_PAC`, etc.), the **Mach layer** of the XNU kernel is responsible for intercepting it before it becomes a UNIX-style **signal** (like `SIGSEGV`, `SIGBUS`, `SIGILL`, ...).

This process involves multiple layers of exception propagation and handling before reaching user space or being converted to a BSD signal.


### Exception Flow (High-Level)

1.  **CPU triggers a synchronous exception** (e.g., invalid pointer dereference, PAC failure, illegal instruction, etc.).

2.  **Low-level trap handler** runs (`trap.c`, `exception.c` in XNU source).

3.  The trap handler calls **`exception_triage()`**, the core of the Mach exception handling.

4.  `exception_triage()` decides how to route the exception:

-   First to the **thread's exception port**.

-   Then to the **task's exception port**.

-   Then to the **host's exception port** (often `launchd` or `ReportCrash`).

If none of these ports handle the exception, the kernel may:

-   **Convert it into a BSD signal** (for user-space processes).

-   **Panic** (for kernel-space exceptions).


### Core Function: `exception_triage()`

The function `exception_triage()` routes Mach exceptions up the chain of possible handlers until one handles it or until it's finally fatal. It's defined in `osfmk/kern/exception.c`.
```c
void exception_triage(exception_type_t exception, mach_exception_data_t code, mach_msg_type_number_t codeCnt);

Tipik Çağrı Akışı:

exception_triage() └── exception_deliver() ├── exception_deliver_thread() ├── exception_deliver_task() └── exception_deliver_host()

Hepsi başarısız olursa → bsd_exception() tarafından işlenir → SIGSEGV gibi bir sinyale çevrilir.

Exception Ports

Her Mach nesnesi (thread, task, host) exception ports kaydedebilir; bu portlara istisna mesajları gönderilir.

Bunlar API tarafından tanımlanırlar:

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

Her exception port şunlara sahiptir:

• A mask (hangi exception’ları almak istediği)
• A port name (mesajları almak için Mach portu)
• A behavior (kernel’in mesajı nasıl gönderdiği)
• A flavor (hangi thread state’in dahil edileceği)

Debuggers ve Exception Handling

Bir debugger (ör. LLDB), hedef task veya thread üzerinde genellikle task_set_exception_ports() kullanarak bir exception port ayarlar.

Bir exception oluştuğunda:

• Mach mesajı debugger process’ine gönderilir.
• Debugger, exception’ı handle (resume, registerları değiştir, instruction’ı atla) etmeye veya etmemeye karar verebilir.
• Eğer debugger handle etmezse, exception bir sonraki seviyeye yayılır (task → host).

Flow of EXC_BAD_ACCESS

1. Thread geçersiz bir pointer’ı dereference eder → CPU Data Abort yükseltir.

2. Kernel trap handler exception_triage(EXC_BAD_ACCESS, ...) çağırır.

3. Mesaj gönderilir:

• Thread port → (debugger breakpoint’i intercept edebilir).

• Eğer debugger yok sayarsa → Task port → (process-seviyesinde handler).

• Eğer yine yok sayılırsa → Host port (genellikle ReportCrash).

4. Kimse handle etmezse → bsd_exception() bunu SIGSEGV’ye çevirir.

PAC Exceptions

Pointer Authentication (PAC) başarısız olduğunda (signature uyuşmazlığı), özel bir Mach exception yükseltilir:

• EXC_ARM_PAC (tip)
• Kodlar detay içerebilir (ör. key type, pointer type).

Eğer binary’de TFRO_PAC_EXC_FATAL flag’i varsa, kernel PAC hatalarını fatal olarak ele alır ve debugger intercept’ini atlar. Bu, saldırganların debugger kullanarak PAC kontrollerini atlamasını önlemek içindir ve platform binaries için etkindir.

Software Breakpoints

Bir software breakpoint (int3 on x86, brk on ARM64) kasıtlı bir fault oluşturularak uygulanır.
Debugger bunu exception port üzerinden yakalar:

• Instruction pointer veya belleği değiştirir.
• Orijinal instruction’ı geri yükler.
• Execution’ı resume eder.

Aynı mekanizma bir PAC exception’ı “yakalamanıza” da izin verir — TFRO_PAC_EXC_FATAL set değilse. Eğer flag set ise, debugger’a hiç ulaşmaz.

Conversion to BSD Signals

Eğer hiçbir handler exception’ı kabul etmezse:

• Kernel task_exception_notify() → bsd_exception() çağırır.

• Bu, Mach exception’ları signal’lara map eder:

Key Files in XNU Source

• osfmk/kern/exception.c → exception_triage(), exception_deliver_*()’in çekirdeği.

• bsd/kern/kern_sig.c → Signal teslimat mantığı.

• osfmk/arm64/trap.c → Düşük seviye trap handler’ları.

• osfmk/mach/exc.h → Exception kodları ve yapıları.

• osfmk/kern/task.c → Task exception port kurulumları.

Old Kernel Heap (Pre-iOS 15 / Pre-A12 era)

Kernel, sabit boyutlu “zone“lara bölünmüş bir zone allocator (kalloc) kullanıyordu.
Her zone yalnızca tek bir boyut sınıfındaki allocation’ları tutardı.

Ekran görüntüsünden:

Nasıl çalışıyordu:

• Her allocation isteği en yakın zone boyutuna yuvarlanır. (Örn. 50-byte istek kalloc.64 zonuna düşer).
• Her zone’daki bellek bir freelist içinde tutulurdu — kernel tarafından freed edilen chunk’lar o zone’a geri giderdi.
• Eğer 64-byte’lık bir buffer’ı overflow ederseniz, aynı zone’daki bir sonraki objeyi overwrite ederdiniz.

Bu yüzden heap spraying / feng shui bu kadar etkiliydi: aynı boyut sınıfında allocation’lar spray yaparak obje komşularını tahmin edebilirdiniz.

The freelist

Her kalloc zone’unun içinde, freed edilmiş objeler doğrudan sisteme geri verilmez — bir freelist’e, kullanılabilir chunk’ların bağlı listesine giderdi.

• Bir chunk free edildiğinde, kernel o chunk’ın başlangıcına bir pointer yazar → aynı zone’daki bir sonraki free chunk’ın adresi.

• Zone, ilk free chunk’a işaret eden bir HEAD pointer tutardı.

• Allocation her zaman mevcut HEAD’i kullanırdı:

1. HEAD’i pop et (o belleği caller’a döndür).

2. HEAD = HEAD->next (freed chunk’ın header’ında saklanan).

• Free etmek chunk’ları geri iter:

• freed_chunk->next = HEAD

• HEAD = freed_chunk

Yani freelist, freed bellek içinde inşa edilen basit bir bağlı listedendi.

Normal durum:

Zone page (64-byte chunks for example):
[ A ] [ F ] [ F ] [ A ] [ F ] [ A ] [ F ]

Freelist view:
HEAD ──► [ F ] ──► [ F ] ──► [ F ] ──► [ F ] ──► NULL
(next ptrs stored at start of freed chunks)

freelist’i İstismar Etme

Bir free chunk’ın ilk 8 baytı freelist pointer olduğu için, bir saldırgan bunu bozabilir:

1. Heap overflow ile bitişik freed chunk’a → onun “next” pointer’ını üzerine yazma.
2. Use-after-free ile freed object içine yazma → onun “next” pointer’ını üzerine yazma.

Sonraki aynı boyuttaki allocation sırasında:

• Allocator bozulmuş chunk’ı poplar.
• Saldırgan tarafından verilen “next” pointer’ını takip eder.
• Rastgele belleğe işaret eden bir pointer döndürür; bu fake object primitives veya hedefe yönelik overwrite’a olanak tanır.

freelist poisoning’in görsel örneği:

Before corruption:
HEAD ──► [ F1 ] ──► [ F2 ] ──► [ F3 ] ──► NULL

After attacker overwrite of F1->next:
HEAD ──► [ F1 ]
(next) ──► 0xDEAD_BEEF_CAFE_BABE  (attacker-chosen)

Next alloc of this zone → kernel hands out memory at attacker-controlled address.

This freelist tasarımı, hardening öncesinde exploit’i son derece etkili kılıyordu: heap sprays kaynaklı öngörülebilir komşular, raw pointer freelist bağlantıları ve tür ayrımı olmaması saldırganların UAF/overflow hatalarını rastgele kernel bellek kontrolüne yükseltmesine izin veriyordu.

Heap Grooming / Feng Shui

The goal of heap grooming is to shape the heap layout so that when an attacker triggers an overflow or use-after-free, the target (victim) object sits right next to an attacker-controlled object.
That way, when memory corruption happens, the attacker can reliably overwrite the victim object with controlled data.

Steps:

1. Spray allocations (fill the holes)

• Zamanla kernel heap parçalanır: bazı zone’larda eski nesnelerin serbest bırakıldığı boşluklar oluşur.
• Saldırgan önce bu boşlukları doldurmak için çok sayıda dummy allocation oluşturur, böylece heap “packed” ve öngörülebilir hale gelir.

2. Force new pages

• Delikler dolduktan sonra, sonraki allocation’lar zone’a eklenen yeni sayfalardan gelmek zorunda kalır.
• Yeni sayfalar demek, nesnelerin eski parçalanmış belleğe dağılmak yerine birlikte kümeleneceği anlamına gelir.
• Bu, saldırganın komşuları çok daha iyi kontrol etmesini sağlar.

3. Place attacker objects

• Saldırgan şimdi tekrar spray yapar ve bu yeni sayfalarda çok sayıda saldırgan-kontrollü nesne oluşturur.
• Bu nesnelerin boyutu ve yerleşimi öngörülebilirdir (hepsi aynı zone’a ait oldukları için).

4. Free a controlled object (make a gap)

• Saldırgan kasıtlı olarak kendi nesnelerinden birini free eder.
• Bu, allocator’ın daha sonra aynı boyuttaki bir allocation için tekrar kullanacağı bir “delik” oluşturur.

5. Victim object lands in the hole

• Saldırgan, kernel’in hedef (victim) nesneyi (bozmak istediği) allocate etmesini tetikler.
• Delik freelist’teki ilk uygun slot olduğundan, victim nesne tam olarak saldırganın boşalttığı yere yerleştirilir.

6. Overflow / UAF into victim

• Artık saldırgan, victim’in çevresinde saldırgan-kontrollü nesnelere sahiptir.
• Kendi nesnelerinden birinden overflow yaparak (veya freed olanı yeniden kullanarak), victim’in bellek alanlarını seçilmiş değerlerle güvenilir şekilde overwrite edebilir.

Neden işe yarıyor:

• Zone allocator öngörülebilirliği: aynı boyuttaki allocation’lar her zaman aynı zone’dan gelir.
• Freelist davranışı: yeni allocation’lar en son free edilen chunk’ı önce yeniden kullanır.
• Heap sprays: saldırgan belleği öngörülebilir içerikle doldurur ve yerleşimi kontrol eder.
• Sonuç: saldırgan victim nesnenin nerede yerleşeceğini ve yanında ne tür verilerin olacağını kontrol eder.

Modern Kernel Heap (iOS 15+/A12+ SoCs)

Apple allocator’u sertleştirdi ve heap grooming çok daha zor hale geldi:

1. From Classic kalloc to kalloc_type

• Before: her boyut sınıfı için tek bir kalloc.<size> zone’u vardı (16, 32, 64, … 1280, vb.). O boyuttaki herhangi bir nesne oraya yerleştirilirdi → saldırgan nesneleri yetkili kernel nesnelerinin yanına gelebiliyordu.
• Now:
• Kernel nesneleri typed zones (kalloc_type) üzerinden allocate ediliyor.
• Her nesne türünün (örn. ipc_port_t, task_t, OSString, OSData) kendi adanmış zone’u var, aynı boyutta olsalar bile.
• Nesne türü ↔ zone eşlemesi compile zamanında kalloc_type system tarafından üretilir.

Artık saldırgan controlled veri (OSData) ile hassas kernel nesneleri (task_t) aynı boyutta olsa bile yan yana geleceğini garanti edemez.

2. Slabs and Per-CPU Caches

• Heap, slablara bölünmüştür (o zone için sabit boyutlu chunk’lara bölünmüş sayfalar).
• Her zone, contention’u azaltmak için bir per-CPU cache içerir.
• Allocation yolu:

1. Per-CPU cache denenir.
2. Boşsa, global freelist’ten çekilir.
3. Freelist boşsa, yeni bir slab (bir veya daha fazla sayfa) allocate edilir.

• Avantaj: Bu merkezsizleştirme, allocation’ların farklı CPU’ların cache’lerinden karşılanabilmesi nedeniyle heap spray’leri daha az deterministik kılar.

3. Randomization inside zones

• Bir zone içinde, freed elemanlar basit FIFO/LIFO sırasıyla geri verilmez.
• Modern XNU, encoded freelist pointers (Linux benzeri safe-linking, yaklaşık iOS 14’ten itibaren) kullanır.
• Her freelist pointer bir per-zone gizli cookie ile XOR-encoded edilir.
• Bu, saldırganların bir write primitive kazandıklarında sahte freelist pointer’ı oluşturmasını engeller.
• Bazı allocation’ların slab içinde yerleşimi randomize edilir, bu yüzden spraying adjacency’yi garanti etmez.

4. Guarded Allocations

• Bazı kritik kernel nesneleri (örn. credentials, task yapıları) guarded zones içinde allocate edilir.
• Bu zone’lar slab’lar arasında guard pages (unmapped memory) ekler veya nesnelerin etrafına redzones koyar.
• Guard page’e yapılan herhangi bir overflow bir fault tetikler → sessiz bozulma yerine hemen panic.

5. Page Protection Layer (PPL) and SPTM

• Freed bir nesneyi kontrol etseniz bile kernel belleğinin her yerini değiştiremezsiniz:
• PPL (Page Protection Layer), belirli bölgelerin (örn. code signing verileri, entitlements) kernel için bile read-only olmasını zorunlu kılar.
• A15/M2+ cihazlarda, bu rol SPTM (Secure Page Table Monitor) + TXM (Trusted Execution Monitor) ile değiştirilmiş/geliştirilmiştir.
• Bu donanım tarafından uygulanmış katmanlar, saldırganların tek bir heap corruption’dan kritik güvenlik yapılarını keyfi olarak patch’lemeye yükseltmesini engeller.
• (Added / Enhanced): ayrıca kernel pointer’ları (özellikle function pointer, vtable) korumak için PAC (Pointer Authentication Codes) kernel içinde kullanılır; bu da onları sahteleştirmeyi veya bozmayı zorlaştırır.
• (Added / Enhanced): zone’lar zone_require / zone enforcement uygulayabilir; yani bir nesnenin free edilmesi sadece doğru typed zone üzerinden geri döndürülebilir; geçersiz cross-zone free’lar panic’e veya reddedilmeye yol açabilir. (Apple bu konudan memory safety yazılarında bahseder)

6. Large Allocations

• Tüm allocation’lar kalloc_type üzerinden gitmez.
• Çok büyük istekler (~16 KB üzeri) typed zone’ları atlar ve sayfa allocation’ları yoluyla doğrudan kernel VM (kmem) üzerinden servis edilir.
• Bunlar daha az öngörülebilirdir, ama aynı zamanda daha az exploitable’dır çünkü diğer nesnelerle slab paylaşmazlar.

7. Allocation Patterns Attackers Target

Bu korumalara rağmen saldırganlar hâlâ şunları ararlar:

• Reference count objects: retain/release sayaçlarını bozabiliyorsanız use-after-free oluşturabilirsiniz.
• Objects with function pointers (vtables): bunları bozmak hâlâ kontrol akışı sağlayabilir.
• Shared memory objects (IOSurface, Mach ports): bunlar user ↔ kernel köprüsü oldukları için hâlâ hedeflerdir.

Ama — eskisi gibi — sadece OSData spray yapıp bir task_t yanında olmasını bekleyemezsiniz. Başarılı olmak için type-specific bugs veya info leaks gerekir.

Example: Allocation Flow in Modern Heap

Suppose userspace calls into IOKit to allocate an OSData object:

1. Type lookup → OSData maps to kalloc_type_osdata zone (size 64 bytes).
2. Check per-CPU cache for free elements.

• If found → return one.
• If empty → go to global freelist.
• If freelist empty → allocate a new slab (page of 4KB → 64 chunks of 64 bytes).

3. Return chunk to caller.

Freelist pointer protection:

• Each freed chunk stores the address of the next free chunk, but encoded with a secret key.
• Overwriting that field with attacker data won’t work unless you know the key.

Comparison Table

Modern Userland Heap (iOS, macOS — type-aware / xzone malloc)

In recent Apple OS versions (especially iOS 17+), Apple introduced a more secure userland allocator, xzone malloc (XZM). This is the user-space analog to the kernel’s kalloc_type, applying type awareness, metadata isolation, and memory tagging safeguards.

Goals & Design Principles

• Type segregation / type awareness: group allocations by type or usage (pointer vs data) to prevent type confusion and cross-type reuse.
• Metadata isolation: separate heap metadata (e.g. free lists, size/state bits) from object payloads so that out-of-bounds writes are less likely to corrupt metadata.
• Guard pages / redzones: insert unmapped pages or padding around allocations to catch overflows.
• Memory tagging (EMTE / MIE): work in conjunction with hardware tagging to detect use-after-free, out-of-bounds, and invalid accesses.
• Scalable performance: maintain low overhead, avoid excessive fragmentation, and support many allocations per second with low latency.

Architecture & Components

Below are the main elements in the xzone allocator:

Segment Groups & Zones

• Segment groups partition the address space by usage categories: e.g. data, pointer_xzones, data_large, pointer_large.
• Each segment group contains segments (VM ranges) that host allocations for that category.
• Associated with each segment is a metadata slab (separate VM area) that stores metadata (e.g. free/used bits, size classes) for that segment. This out-of-line (OOL) metadata ensures that metadata is not intermingled with object payloads, mitigating corruption from overflows.
• Segments are carved into chunks (slices) which in turn are subdivided into blocks (allocation units). A chunk is tied to a specific size class and segment group (i.e. all blocks in a chunk share the same size & category).
• For small / medium allocations, it will use fixed-size chunks; for large/huges, it may map separately.

Chunks & Blocks

• A chunk is a region (often several pages) dedicated to allocations of one size class within a group.
• Inside a chunk, blocks are slots available for allocations. Freed blocks are tracked via the metadata slab — e.g. via bitmaps or free lists stored out-of-line.
• Between chunks (or within), guard slices / guard pages may be inserted (e.g. unmapped slices) to catch out-of-bounds writes.

Type / Type ID

• Every allocation site (or call to malloc, calloc, etc.) is associated with a type identifier (a malloc_type_id_t) which encodes what kind of object is being allocated. That type ID is passed to the allocator, which uses it to select which zone / segment to serve the allocation.
• Because of this, even if two allocations have the same size, they may go into entirely different zones if their types differ.
• In early iOS 17 versions, not all APIs (e.g. CFAllocator) were fully type-aware; Apple addressed some of those weaknesses in iOS 18.

Allocation & Freeing Workflow

Here is a high-level flow of how allocation and deallocation operate in xzone:

1. malloc / calloc / realloc / typed alloc is invoked with a size and type ID.
2. The allocator uses the type ID to pick the correct segment group / zone.
3. Within that zone/segment, it seeks a chunk that has free blocks of the requested size.

• It may consult local caches / per-thread pools or free block lists from metadata.
• If no free block is available, it may allocate a new chunk in that zone.

4. The metadata slab is updated (free bit cleared, bookkeeping).
5. If memory tagging (EMTE) is in play, the returned block gets a tag assigned, and metadata is updated to reflect its “live” state.
6. When free() is called:

• The block is marked as freed in metadata (via OOL slab).
• The block may be placed into a free list or pooled for reuse.
• Optionally, block contents may be cleared or poisoned to reduce data leaks or use-after-free exploitation.
• The hardware tag associated with the block may be invalidated or re-tagged.
• If an entire chunk becomes free (all blocks freed), the allocator may reclaim that chunk (unmap it or return to OS) under memory pressure.

Security Features & Hardening

These are the defenses built into modern userland xzone:

Interaction with Memory Integrity Enforcement (MIE / EMTE)

• Apple’s MIE (Memory Integrity Enforcement) is the hardware + OS framework that brings Enhanced Memory Tagging Extension (EMTE) into always-on, synchronous mode across major attack surfaces.
• xzone allocator is a fundamental foundation of MIE in user space: allocations done via xzone get tags, and accesses are checked by hardware.
• In MIE, the allocator, tag assignment, metadata management, and tag confidentiality enforcement are integrated to ensure that memory errors (e.g. stale reads, OOB, UAF) are caught immediately, not exploited later.

If you like, I can also generate a cheat-sheet or diagram of xzone internals for your book. Do you want me to do that next?

:contentReference[oai:20]{index=20}

(Old) Physical Use-After-Free via IOSurface

ios Physical UAF - IOSurface

Ghidra Install BinDiff

Download BinDiff DMG from https://www.zynamics.com/bindiff/manual and install it.

Open Ghidra with ghidraRun and go to File –> Install Extensions, press the add button and select the path /Applications/BinDiff/Extra/Ghidra/BinExport and click OK and isntall it even if there is a version mismatch.

Using BinDiff with Kernel versions

1. Go to the page https://ipsw.me/ and download the iOS versions you want to diff. These will be .ipsw files.
2. Decompress until you get the bin format of the kernelcache of both .ipsw files. You have information on how to do this on:

macOS Kernel Extensions & Kernelcache

3. Open Ghidra with ghidraRun, create a new project and load the kernelcaches.
4. Open each kernelcache so they are automatically analyzed by Ghidra.
5. Then, on the project Window of Ghidra, right click each kernelcache, select Export, select format Binary BinExport (v2) for BinDiff and export them.
6. Open BinDiff, create a new workspace and add a new diff indicating as primary file the kernelcache that contains the vulnerability and as secondary file the patched kernelcache.

Finding the right XNU version

If you want to check for vulnerabilities in a specific version of iOS, you can check which XNU release version the iOS version uses at [https://www.theiphonewiki.com/wiki/kernel]https://www.theiphonewiki.com/wiki/kernel).

For example, the versions 15.1 RC, 15.1 and 15.1.1 use the version Darwin Kernel Version 21.1.0: Wed Oct 13 19:14:48 PDT 2021; root:xnu-8019.43.1~1/RELEASE_ARM64_T8006.

JSKit-Based Safari Chains and PREYHUNTER Stagers

Renderer RCE abstraction with JSKit

• Reusable entry: Recent in-the-wild chains abused a WebKit JIT bug (patched as CVE-2023-41993) purely to gain JavaScript-level arbitrary read/write. The exploit immediately pivots into a purchased framework called JSKit, so any future Safari bug only needs to deliver the same primitive.
• Version abstraction & PAC bypasses: JSKit bundles support for a wide range of iOS releases together with multiple, selectable Pointer Authentication Code bypass modules. The framework fingerprints the target build, selects the appropriate PAC bypass logic, and verifies every step (primitive validation, shellcode launch) before progressing.
• Manual Mach-O mapping: JSKit parses Mach-O headers directly from memory, resolves the symbols it needs inside dyld-cached images, and can manually map additional Mach-O payloads without writing them to disk. This keeps the renderer process in-memory only and evades code-signature checks tied to filesystem artifacts.
• Portfolio model: Debug strings such as “exploit number 7” show that the suppliers maintain multiple interchangeable WebKit exploits. Once the JS primitive matches JSKit’s interface, the rest of the chain is unchanged across campaigns.

Kernel bridge: IPC UAF -> code-sign bypass pattern

• Kernel IPC UAF (CVE-2023-41992): The second stage, still running inside the Safari context, triggers a kernel use-after-free in IPC code, re-allocates the freed object from userland, and abuses the dangling pointers to pivot into arbitrary kernel read/write. The stage also reuses PAC bypass material previously computed by JSKit instead of re-deriving it.
• Code-signing bypass (CVE-2023-41991): With kernel R/W available, the exploit patches the trust cache / code-signing structures so unsigned payloads execute as system. The stage then exposes a lightweight kernel R/W service to later payloads.
• Composed pattern: This chain demonstrates a reusable recipe that defenders should expect going forward:

WebKit renderer RCE -> kernel IPC UAF -> kernel arbitrary R/W -> code-sign bypass -> unsigned system stager

PREYHUNTER helper & watcher modülleri

• Watcher anti-analysis: Adanmış bir watcher binary cihazı sürekli profillendirir ve bir araştırma ortamı tespit edildiğinde kill-chain’i sonlandırır. security.mac.amfi.developer_mode_status’ı, bir diagnosticd console varlığını, US veya IL lokallerini, Cydia gibi jailbreak izlerini, bash, tcpdump, frida, sshd veya checkrain gibi süreçleri, mobil AV uygulamalarını (McAfee, AvastMobileSecurity, NortonMobileSecurity), özel HTTP proxy ayarlarını ve özel root CA’ları inceler. Herhangi bir kontrol başarısız olursa daha fazla payload teslimatı engellenir.
• Helper surveillance hooks: Helper bileşeni diğer aşamalarla /tmp/helper.sock üzerinden iletişim kurar, ardından DMHooker ve UMHooker adlı hook setlerini yükler. Bu hook’lar VOIP audio yollarına erişir (kayıtlar /private/var/tmp/l/voip_%lu_%u_PART.m4a altında yer alır), sistem çapında bir keylogger uygular, UI olmadan fotoğraf çeker ve SpringBoard’u bu eylemlerin normalde tetikleyeceği bildirimleri bastıracak şekilde hook’lar. Bu nedenle helper, Predator gibi daha ağır implantlar indirilmeden önce gizli bir doğrulama + hafif gözetim katmanı olarak görev yapar.

iMessage/Media Parser Zero-Click Chains

Imessage Media Parser Zero Click Coreaudio Pac Bypass

Referanslar

• Google Threat Intelligence – Intellexa zero-day exploits continue

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!
• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter’da bizi takip edin 🐦 @hacktricks_live.**
• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.