// 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>

#### Limitations & challenges

- **Intrablock overflows**: यदि overflow उसी allocation के अंदर रहता है (doesn’t cross boundary) और tag वही रहता है, तो tag mismatch इसे पकड़ नहीं पाता।
- **Tag width limitation**: tag के लिए केवल कुछ bits (e.g. 4 bits, या छोटा domain) उपलब्ध हैं—सीमित namespace।
- **Side-channel leaks**: यदि tag bits cache / speculative execution के माध्यम से leaked हो सकते हैं, तो attacker valid tags सीख सकता है और bypass कर सकता है। Apple की tag confidentiality enforcement इसे mitigate करने के लिए है।
- **Performance overhead**: हर load/store पर tag checks अतिरिक्त लागत जोड़ते हैं; Apple को hardware को optimize करना होगा ताकि overhead कम रहे।
- **Compatibility & fallback**: पुराने hardware या उन हिस्सों पर जो EMTE को support नहीं करते, fallback मौजूद होना चाहिए। Apple का दावा है कि MIE केवल उन devices पर enabled है जिनमें support है।
- **Complex allocator logic**: Allocator को tags, retagging, boundary aligning संभालना होगा और mis-tag collisions से बचना होगा। Allocator logic में bugs vulnerabilities ला सकते हैं।
- **Mixed memory / hybrid areas**: कुछ memory untagged (legacy) बनी रह सकती है, जिससे interoperability और जटिल हो जाती है।
- **Speculative / transient attacks**: कई microarchitectural protections की तरह, speculative execution या micro-op fusions समयिक रूप से checks को bypass कर सकते हैं या tag bits को leak कर सकते हैं।
- **Limited to supported regions**: Apple संभवतः EMTE को केवल चुनिंदा, high-risk क्षेत्रों (kernel, security-critical subsystems) में लागू करे, न कि सार्वत्रिक रूप से।

---

## 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 leak 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.|

क्योंकि Apple हार्डवेयर और software stack दोनों नियंत्रित करता है, वह EMTE को कड़ाई से लागू कर सकता है, performance pitfalls से बच सकता है, और 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**
- जब memory allocate होती है (e.g. kernel या user space में secure allocators के द्वारा), उस block को एक **secret tag** असाइन किया जाता है।
- user या kernel को लौटाया गया pointer उसके high bits में वह tag शामिल करता है (using TBI / top byte ignore mechanisms).

2. **Tag checking on access**
- जब भी pointer का उपयोग कर load या store execute होता है, hardware यह चेक करता है कि pointer का tag memory block के tag (allocation tag) से मेल खाता है। यदि mismatch हो, तो यह तुरंत fault करता है (since synchronous)।
- चूंकि यह synchronous है, इसलिए कोई “delayed detection” विंडो नहीं रहती।

3. **Retagging on free / reuse**
- जब memory free होती है, allocator block का tag बदल देता है (ताकि पुराने pointers जिनके tags पुराने हैं वे अब मैच न करें)।
- इस तरह use-after-free pointer के पास stale tag होगा और access पर mismatch होगा।

4. **Neighbor-tag differentiation to catch overflows**
- Adjacent allocations को अलग-अलग tags दिए जाते हैं। यदि buffer overflow पड़ोसी की memory में spill करता है, तो tag mismatch fault पैदा करेगा।
- यह खासकर छोटे overflows को पकड़ने में प्रभावशाली है जो boundary cross करते हैं।

5. **Tag confidentiality enforcement**
- Apple को tag values के leaked होने को रोकना होगा (क्योंकि अगर attacker tag सीख लेता है, तो वे सही tags वाले pointers बना सकते हैं)।
- वे protections (microarchitectural / speculative controls) शामिल करते हैं ताकि tag bits के side-channel leakage से बचा जा सके।

6. **Kernel and user-space integration**
- Apple EMTE का उपयोग सिर्फ user-space में नहीं बल्कि kernel / OS-critical components में भी करता है (kernel को memory corruption से बचाने के लिए)।
- Hardware/OS यह सुनिश्चित करता है कि tag नियम तब भी लागू हों जब kernel user space की ओर से execute कर रहा हो।

क्योंकि EMTE MIE में बना हुआ है, Apple प्रमुख attack surfaces पर EMTE को synchronous mode में इस्तेमाल करता है, इसे opt-in या 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`, ...).

यह प्रक्रिया user space तक पहुँचने या BSD signal में convert होने से पहले कई स्तरों की exception propagation और handling शामिल करती है।

### 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()` तय करता है कि exception को कैसे route किया जाए:

-   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`).

यदि इन में से कोई भी port exception को handle नहीं करता, तो kernel कर सकता है:

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

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


### Core Function: `exception_triage()`

The function `exception_triage()` Mach exceptions को संभावित handlers की श्रृंखला में ऊपर route करता है जब तक कोई इसे handle न कर दे या यह अंततः fatal न हो जाए। यह `osfmk/kern/exception.c` में परिभाषित है।
```c
void exception_triage(exception_type_t exception, mach_exception_data_t code, mach_msg_type_number_t codeCnt);

सामान्य कॉल फ्लो:

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

यदि सभी विफल होते हैं → bsd_exception() द्वारा संभाला जाता है → SIGSEGV जैसे सिग्नल में परिवर्तित किया जाता है।

Exception Ports

प्रत्येक Mach ऑब्जेक्ट (thread, task, host) exception ports रजिस्टर कर सकता है, जहाँ exception messages भेजे जाते हैं।

ये API द्वारा परिभाषित होते हैं:

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

Each exception port has:

• A mask (कौन से exceptions यह प्राप्त करना चाहता है)
• A port name (Mach port to receive messages)
• A behavior (how the kernel sends the message)
• A flavor (which thread state to include)

Debuggers and Exception Handling

A debugger (e.g., LLDB) लक्ष्य task या thread पर एक exception port सेट करता है, आमतौर पर task_set_exception_ports() के माध्यम से।

When an exception occurs:

• Mach message debugger process को भेजा जाता है।
• Debugger निर्णय ले सकता है कि वह exception को handle करे (resume, registers modify करना, instruction skip करना) या not handle करे।
• अगर debugger इसे handle नहीं करता, तो exception अगले स्तर पर propagate होता है (task → host).

Flow of EXC_BAD_ACCESS

1. Thread एक invalid pointer को dereference करता है → CPU Data Abort उठाता है।

2. Kernel trap handler कॉल करता है exception_triage(EXC_BAD_ACCESS, ...)।

3. Message भेजा जाता है:

• Thread port → (debugger breakpoint को intercept कर सकता है).

• अगर debugger ignore करे → Task port → (process-level handler).

• अगर ignored रहे → Host port (usually ReportCrash).

4. अगर कोई इसे handle नहीं करता → bsd_exception() इसे SIGSEGV में translate कर देता है।

PAC Exceptions

जब Pointer Authentication (PAC) fail करता है (signature mismatch), एक special Mach exception उठता है:

• EXC_ARM_PAC (type)
• Codes में विवरण हो सकते हैं (e.g., key type, pointer type).

अगर binary में flag TFRO_PAC_EXC_FATAL सेट है, तो kernel PAC failures को fatal मानता है और debugger interception को bypass कर देता है। यह attackers को debuggers का उपयोग करके PAC checks को bypass करने से रोकने के लिए है और यह platform binaries के लिए enabled होता है।

Software Breakpoints

एक software breakpoint (int3 on x86, brk on ARM64) सामान्यतः deliberate fault पैदा करके लागू किया जाता है.
Debugger इसे exception port के ज़रिये पकड़ता है:

• instruction pointer या memory को modify करता है।
• original instruction restore करता है।
• execution resume करता है।

यह वही mechanism है जो आपको PAC exception “catch” करने की अनुमति देता है — सिवाय इसके कि TFRO_PAC_EXC_FATAL सेट हो, तब यह कभी debugger तक नहीं पहुँचता।

Conversion to BSD Signals

अगर कोई handler exception स्वीकार नहीं करता:

• Kernel कॉल करता है task_exception_notify() → bsd_exception()।

• यह Mach exceptions को signals में map करता है:

### Key Files in XNU Source

• osfmk/kern/exception.c → Core of exception_triage(), exception_deliver_*().
• bsd/kern/kern_sig.c → Signal delivery logic.
• osfmk/arm64/trap.c → Low-level trap handlers.
• osfmk/mach/exc.h → Exception codes and structures.
• osfmk/kern/task.c → Task exception port setup.

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

Kernel ने एक zone allocator (kalloc) का उपयोग किया जो fixed-size “zones” में विभाजित था। हर zone केवल एक ही size class की allocations रखता था।

From the screenshot:

कैसे काम करता था:

• हर allocation request को नज़दीकी zone size पर rounded up किया जाता था। (उदाहरण के लिए, 50-byte request kalloc.64 zone में जाएगा).
• हर zone की memory एक freelist में रखी जाती थी — kernel द्वारा freed किए गए chunks वापस उसी zone में चले जाते थे।
• अगर आप एक 64-byte buffer को overflow करते थे, तो आप उसी zone के अगले object को overwrite कर देते थे।

यही वजह है कि heap spraying / feng shui इतना प्रभावी था: आप एक ही size class की allocations करके object के पड़ोसी का अनुमान लगा सकते थे।

The freelist

हर kalloc zone के अंदर, freed objects सीधे system को वापस नहीं जाते थे — वे freelist में चले जाते थे, जो कि उपलब्ध chunks की एक linked list थी।

• जब कोई chunk free होता था, तो kernel उस chunk की शुरुआत में एक pointer लिखता था → उसी zone के अगले free chunk का address।

• Zone के पास HEAD pointer होता था जो पहले free chunk को इंगित करता था।

• Allocation हमेशा current HEAD का उपयोग करता था:

1. Pop HEAD (वह memory caller को वापस की जाती है)।

2. Update HEAD = HEAD->next (जो freed chunk के header में store होता है)।

• Freeing chunks को वापस push कर देता था:

• freed_chunk->next = HEAD

• HEAD = freed_chunk

तो freelist बस freed memory के अंदर बनाई गई एक linked list थी।

Normal state:

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)

Exploiting the freelist

क्योंकि किसी free chunk के पहले 8 बाइट्स = freelist pointer होते हैं, एक attacker इसे corrupt कर सकता है:

1. Heap overflow into an adjacent freed chunk → overwrite its “next” pointer.

2. Use-after-free write into a freed object → overwrite its “next” pointer.

फिर, उसी साइज के अगले allocation पर:

• The allocator pops the corrupted chunk.
• Follows the attacker-supplied “next” pointer.
• Returns a pointer to arbitrary memory, enabling fake object primitives or targeted overwrite.

Visual example of freelist poisoning:

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 डिज़ाइन hardening से पहले exploitation को बहुत प्रभावी बनाता था: heap sprays से predictable neighbors, raw pointer freelist links, और कोई type separation न होने के कारण attackers UAF/overflow बग्स को arbitrary kernel memory control में escalate कर पाते थे।

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)

• Over time, the kernel heap gets fragmented: some zones have holes where old objects were freed.
• The attacker first makes lots of dummy allocations to fill these gaps, so the heap becomes “packed” and predictable.

2. Force new pages

• Once the holes are filled, the next allocations must come from new pages added to the zone.
• Fresh pages mean objects will be clustered together, not scattered across old fragmented memory.
• This gives the attacker much better control of neighbors.

3. Place attacker objects

• The attacker now sprays again, creating lots of attacker-controlled objects in those new pages.
• These objects are predictable in size and placement (since they all belong to the same zone).

4. Free a controlled object (make a gap)

• The attacker deliberately frees one of their own objects.
• This creates a “hole” in the heap, which the allocator will later reuse for the next allocation of that size.

5. Victim object lands in the hole

• The attacker triggers the kernel to allocate the victim object (the one they want to corrupt).
• Since the hole is the first available slot in the freelist, the victim is placed exactly where the attacker freed their object.

6. Overflow / UAF into victim

• Now the attacker has attacker-controlled objects around the victim.
• By overflowing from one of their own objects (or reusing a freed one), they can reliably overwrite the victim’s memory fields with chosen values.

Why it works:

• Zone allocator predictability: allocations of the same size always come from the same zone.
• Freelist behavior: new allocations reuse the most recently freed chunk first.
• Heap sprays: attacker fills memory with predictable content and controls layout.
• End result: attacker controls where the victim object lands and what data sits next to it.

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

Apple ने allocator को harden किया और heap grooming बहुत कठिन बना दिया:

1. From Classic kalloc to kalloc_type

• Before: a single kalloc.<size> zone existed for each size class (16, 32, 64, … 1280, etc.). Any object of that size was placed there → attacker objects could sit next to privileged kernel objects.
• Now:
• Kernel objects are allocated from typed zones (kalloc_type).
• Each type of object (e.g., ipc_port_t, task_t, OSString, OSData) has its own dedicated zone, even if they’re the same size.
• The mapping between object type ↔ zone is generated from the kalloc_type system at compile time.

An attacker can no longer guarantee that controlled data (OSData) ends up adjacent to sensitive kernel objects (task_t) of the same size.

2. Slabs and Per-CPU Caches

• The heap is divided into slabs (pages of memory carved into fixed-size chunks for that zone).
• Each zone has a per-CPU cache to reduce contention.
• Allocation path:

1. Try per-CPU cache.
2. If empty, pull from the global freelist.
3. If freelist is empty, allocate a new slab (one or more pages).

• Benefit: This decentralization makes heap sprays less deterministic, since allocations may be satisfied from different CPUs’ caches.

3. Randomization inside zones

• Within a zone, freed elements are not handed back in simple FIFO/LIFO order.
• Modern XNU uses encoded freelist pointers (safe-linking like Linux, introduced ~iOS 14).
• Each freelist pointer is XOR-encoded with a per-zone secret cookie.
• This prevents attackers from forging a fake freelist pointer if they gain a write primitive.
• Some allocations are randomized in their placement within a slab, so spraying doesn’t guarantee adjacency.

4. Guarded Allocations

• Certain critical kernel objects (e.g., credentials, task structures) are allocated in guarded zones.
• These zones insert guard pages (unmapped memory) between slabs or use redzones around objects.
• Any overflow into the guard page triggers a fault → immediate panic instead of silent corruption.

5. Page Protection Layer (PPL) and SPTM

• Even if you control a freed object, you can’t modify all of kernel memory:
• PPL (Page Protection Layer) enforces that certain regions (e.g., code signing data, entitlements) are read-only even to the kernel itself.
• On A15/M2+ devices, this role is replaced/enhanced by SPTM (Secure Page Table Monitor) + TXM (Trusted Execution Monitor).
• These hardware-enforced layers mean attackers can’t escalate from a single heap corruption to arbitrary patching of critical security structures.
• (Added / Enhanced): also, PAC (Pointer Authentication Codes) is used in the kernel to protect pointers (especially function pointers, vtables) so that forging or corrupting them becomes harder.
• (Added / Enhanced): zones may enforce zone_require / zone enforcement, i.e. that an object freed can only be returned through its correct typed zone; invalid cross-zone frees may panic or be rejected. (Apple alludes to this in their memory safety posts)

6. Large Allocations

• Not all allocations go through kalloc_type.
• Very large requests (above ~16 KB) bypass typed zones and are served directly from kernel VM (kmem) via page allocations.
• These are less predictable, but also less exploitable, since they don’t share slabs with other objects.

7. Allocation Patterns Attackers Target

Even with these protections, attackers still look for:

• Reference count objects: if you can tamper with retain/release counters, you may cause use-after-free.
• Objects with function pointers (vtables): corrupting one still yields control flow.
• Shared memory objects (IOSurface, Mach ports): these are still attack targets because they bridge user ↔ kernel.

But — unlike before — you can’t just spray OSData and expect it to neighbor a task_t. You need type-specific bugs or info leaks to succeed.

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)

Recent Apple OS versions (especially iOS 17+) में Apple ने एक अधिक सुरक्षित userland allocator पेश किया है, xzone malloc (XZM). यह kernel के kalloc_type का user-space समकक्ष है, जो type awareness, metadata isolation और memory tagging safeguards लागू करता है।

Goals & Design Principles

• Type segregation / type awareness: अलग-अलग types या usage (pointer vs data) के आधार पर allocations को group करना ताकि type confusion और cross-type reuse रोका जा सके।
• Metadata isolation: heap metadata (जैसे free lists, size/state bits) को object payloads से अलग रखना ताकि out-of-bounds writes से metadata कम प्रभावित हो।
• Guard pages / redzones: allocations के चारों ओर unmapped pages या padding डालना ताकि overflows पकड़े जा सकें।
• Memory tagging (EMTE / MIE): hardware tagging के साथ मिलकर use-after-free, out-of-bounds, और invalid accesses को डिटेक्ट करना।
• Scalable performance: कम overhead बनाए रखना, fragmentation कम करना, और high allocation rates के साथ low latency बनाए रखना।

Architecture & Components

नीचे xzone allocator के मुख्य घटक हैं:

Segment Groups & Zones

• Segment groups address space को usage कैटेगोरीज़ से partition करते हैं: जैसे data, pointer_xzones, data_large, pointer_large.
• प्रत्येक segment group में segments (VM ranges) होते हैं जो उस category के allocations होस्ट करते हैं।
• हर segment के साथ एक metadata slab जुड़ा होता है (अलग VM क्षेत्र) जो metadata (जैसे free/used bits, size classes) स्टोर करता है। यह out-of-line (OOL) metadata यह सुनिश्चित करता है कि metadata object payloads के साथ intermingled न हो, जिससे overflows से नुकसान कम होता है।
• Segments को chunks (slices) में काटा जाता है जो बदले में blocks (allocation units) में विभाजित होते हैं। एक chunk एक specific size class और segment group से संबंधित होता है (यानी chunk के सभी blocks एक ही size & category शेयर करते हैं)।
• छोटे/मध्यम allocations के लिए fixed-size chunks का उपयोग होता है; बड़े allocations अलग से map किए जा सकते हैं।

Chunks & Blocks

• एक chunk एक क्षेत्र है (अक्सर कई pages) जो एक size class के allocations के लिए समर्पित होता है।
• Chunk के अंदर, blocks allocation के लिए उपलब्ध slots होते हैं। Freed blocks को metadata slab द्वारा ट्रैक किया जाता है — जैसे bitmaps या out-of-line free lists के माध्यम से।
• Chunks के बीच (या अंदर) guard slices / guard pages डाले जा सकते हैं (उदा. unmapped slices) ताकि out-of-bounds writes पकड़े जा सकें।

Type / Type ID

• हर allocation site (या malloc, calloc, आदि कॉल) एक type identifier (malloc_type_id_t) के साथ जुड़ा होता है जो बताता है कि किस तरह का object allocate हो रहा है। वह type ID allocator को दी जाती है, जो zone/segment चुनने के लिए इसका उपयोग करती है।
• इसलिए, भले ही दो allocations का size समान हो, वे अलग types होने पर पूरी तरह अलग zones में जा सकते हैं।
• शुरुआती iOS 17 versiones में, सभी APIs (उदा. CFAllocator) पूरी तरह type-aware नहीं थे; Apple ने iOS 18 में कुछ कमजोरियों को address किया।

Allocation & Freeing Workflow

यहाँ xzone में allocation और deallocation का high-level flow है:

1. malloc / calloc / realloc / typed alloc को size और type ID के साथ कॉल किया जाता है।
2. Allocator type ID का उपयोग करके सही segment group / zone चुनता है।
3. उस zone/segment के अंदर, वह ऐसे chunk की तलाश करता है जिसमें requested size के free blocks हों।

• यह local caches / per-thread pools या metadata से free block lists देख सकता है।
• अगर कोई free block नहीं मिलता, तो वह उस zone में नया chunk allocate कर सकता है।

4. Metadata slab अपडेट होता है (free bit cleared, bookkeeping)।
5. अगर memory tagging (EMTE) लागू है, तो returned block को एक tag दिया जाता है, और metadata को उसकी “live” state दिखाने के लिए अपडेट किया जाता है।
6. जब free() होता है:

• Block को metadata में freed के रूप में चिह्नित किया जाता है (OOL slab के माध्यम से)।
• Block को reuse के लिए free list में रखा जा सकता है या pooled किया जा सकता है।
• वैकल्पिक रूप से, block contents को cleared या poisoned किया जा सकता है ताकि data leaks या use-after-free exploitation की संभावना कम हो।
• उस block से जुड़ा hardware tag invalidated या re-tagged किया जा सकता है।
• अगर पूरा chunk free हो जाता है (सभी blocks free), तो allocator उस chunk को reclaim कर सकता है (unmap या OS को return) memory pressure में।

Security Features & Hardening

ये modern userland xzone में built-in defenses हैं:

Interaction with Memory Integrity Enforcement (MIE / EMTE)

• Apple की MIE (Memory Integrity Enforcement) वह hardware + OS framework है जो Enhanced Memory Tagging Extension (EMTE) को always-on, synchronous mode में बड़ी attack surfaces पर लाती है।
• xzone allocator user space में MIE का एक बुनियादी हिस्सा है: xzone के माध्यम से किये गए allocations को tags मिलते हैं, और accesses hardware द्वारा चेक होते हैं।
• MIE में allocator, tag assignment, metadata management, और tag confidentiality enforcement एकीकृत होते हैं ताकि memory errors (जैसे stale reads, OOB, UAF) तुरंत पकड़े जाएं, न कि बाद में exploit किए जाएं।

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 modules

• Watcher anti-analysis: एक समर्पित watcher binary लगातार डिवाइस का प्रोफाइल बनाता है और जब एक रिसर्च वातावरण पाया जाता है तो kill-chain को abort कर देता है। यह security.mac.amfi.developer_mode_status, diagnosticd कंसोल की उपस्थिति, locales US या IL, jailbreak के निशान जैसे Cydia, प्रक्रियाएँ जैसे bash, tcpdump, frida, sshd, या checkrain, मोबाइल AV ऐप्स (McAfee, AvastMobileSecurity, NortonMobileSecurity), कस्टम HTTP proxy सेटिंग्स, और कस्टम root CAs की जाँच करता है। किसी भी जांच में विफल होने पर आगे की payload डिलीवरी ब्लॉक कर दी जाती है।

• Helper surveillance hooks: helper component अन्य चरणों से /tmp/helper.sock के माध्यम से संवाद करता है, फिर DMHooker और UMHooker नामक hook सेट लोड करता है। ये hooks VOIP audio paths को टैप करते हैं (रिकॉर्डिंग /private/var/tmp/l/voip_%lu_%u_PART.m4a के अंतर्गत आती हैं), एक system-wide keylogger लागू करते हैं, बिना UI के फोटो कैप्चर करते हैं, और SpringBoard को hook करके उन क्रियाओं से सामान्यतः उठने वाले notifications को दबा देते हैं। इसलिए helper भारी implants जैसे Predator गिराने से पहले एक stealthy validation + light-surveillance लेयर के रूप में काम करता है।

• HiddenDot indicator suppression in SpringBoard: kernel-level code injection के साथ, Predator SBSensorActivityDataProvider._handleNewDomainData: (sensor activity का aggregation point) को hook करता है। यह hook Objective-C self pointer (x0) को zero कर देता है ताकि कॉल [nil _handleNewDomainData:newData] बन जाए, जिससे camera/mic अपडेट्स गिर जाती हैं और दोनों green/orange dots दबा दिए जाते हैं।

• Mach exception-based hooking flow (DMHooker): Hooks EXC_BREAKPOINT + exception ports के माध्यम से लागू किए जाते हैं, फिर thread_set_state रजिस्टरों को बदलता है और execution resume होता है। Return code 2 का मतलब है “continue with modified thread state.”

• PAC-aware redirection for camera access checks: mediaserverd में, एक pattern-scan (उदा., memmem) CMCapture.framework के अंदर FigVideoCaptureSourceCreateWithSourceInfo के पास एक private routine ढूँढता है। Hook 3 लौटाता है ताकि pre-signed PAC cached return address का उपयोग करके redirect किया जा सके, जिससे PAC संतुष्ट होता है जबकि चेक बायपास हो जाता है।

• VoIP capture pipeline in mediaserverd: AudioConverterNew और AudioConverterConvertComplexBuffer+52 को hook करके buffers को टैप किया जाता है, buffer sizes से sample rate का अनुमान लगाया जाता है, float32 PCM → int16 NEON के साथ कनवर्ट किया जाता है, 4-channel को stereo में downmix किया जाता है, और ExtAudioFileWrite() के जरिए persist किया जाता है। VoIP module स्वयं indicators को suppress नहीं करता, इसलिए operators को HiddenDot अलग से सक्षम करना होगा।

WebKit DFG Store-Barrier UAF + ANGLE PBO OOB (iOS 26.1)

Webkit Dfg Store Barrier Uaf Angle Oob

iMessage/Media Parser Zero-Click Chains

Imessage Media Parser Zero Click Coreaudio Pac Bypass

संदर्भ

• https://www.jamf.com/blog/predator-spyware-ios-recording-indicator-bypass-analysis/
• Google Threat Intelligence – Intellexa zero-day exploits continue

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

• सदस्यता योजनाओं की जांच करें!
• हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।