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

#### सीमाएँ और चुनौतियाँ

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


---

## Key enhancements / differences compared to standard MTE

यहां Apple द्वारा बताई गई सुधारित चीज़ें और परिवर्तन दिए गए हैं:

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

क्योंकि Apple hardware और software दोनों को नियंत्रित करता है, वह EMTE को कड़ाई से लागू कर सकता है, performance समस्याओं से बच सकता है, और side-channel holes को बंद कर सकता है।

---

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

यहाँ एक high-level विवरण है कि Apple के MIE सेटअप में EMTE कैसे काम करता है:

1. **Tag assignment**
- जब memory allocate होती है (उदा. kernel या user space में secure allocators के माध्यम से), तो उस block को एक **secret tag** दिया जाता है।
- उपयोगकर्ता या kernel को जो pointer लौटता है, उसमे tag शामिल होता है (high bits में) — TBI / top byte ignore mechanisms का उपयोग करके।

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

3. **Retagging on free / reuse**
- जब memory free होती है, allocator उस block का tag बदल देता है (ताकि पुराने pointers जिनमें पुराना tag है, अब मैच न करें)।
- एक 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 पार करते हैं उन्हें पकड़ने में विशेष रूप से प्रभावी है।

5. **Tag confidentiality enforcement**
- Apple को tag values के leakage को रोकना होगा (क्योंकि यदि attacker tag सीख लेता है, तो वह सही tag वाले pointers तैयार कर सकता है)।
- वे microarchitectural / speculative controls शामिल करते हैं ताकि tag बिट्स के 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 की ओर से executing हो।


क्योंकि EMTE MIE में बिल्ट है, Apple महत्वपूर्ण attack surfaces पर synchronous mode में EMTE लागू करता है, न कि इसे opt-in या debugging mode के रूप में रखता है।


---

## Exception handling in XNU

जब कोई **exception** होता है (उदा., `EXC_BAD_ACCESS`, `EXC_BAD_INSTRUCTION`, `EXC_CRASH`, `EXC_ARM_PAC`, आदि), तो XNU kernel की **Mach layer** इसे UNIX-style **signal** (जैसे `SIGSEGV`, `SIGBUS`, `SIGILL`, ...) बनने से पहले intercept करने के लिए जिम्मेदार होती है।

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


### Exception Flow (High-Level)

1.  **CPU triggers a synchronous exception** (उदा., invalid pointer dereference, PAC failure, illegal instruction, आदि)।

2.  **Low-level trap handler** चलता है (`trap.c`, `exception.c` in XNU source)।

3.  trap handler **`exception_triage()`** को कॉल करता है, जो Mach exception handling का core है।

4.  `exception_triage()` तय करता है कि exception को कैसे route किया जाए:

-   पहले **thread's exception port** को भेजा जाता है।

-   फिर **task's exception port** को।

-   फिर **host's exception port** (अक्सर `launchd` या `ReportCrash`) को।

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

-   **इसे BSD signal में convert कर देना** (user-space processes के लिए)।

-   **panic** कर देना (kernel-space exceptions के लिए)।


### Core Function: `exception_triage()`

फंक्शन `exception_triage()` Mach exceptions को संभव handlers की श्रृंखला में route करता है जब तक कि कोई handler इसे 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 में अनुवादित किया जाता है।

एक्सेप्शन पोर्ट्स

प्रत्येक Mach ऑब्जेक्ट (thread, task, host) एक्सेप्शन पोर्ट्स रजिस्टर कर सकता है, जहाँ एक्सेप्शन संदेश भेजे जाते हैं।

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

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

प्रत्येक exception port में होते हैं:

• एक mask (कौन से exceptions यह प्राप्त करना चाहता है)
• एक port name (मैसेज प्राप्त करने के लिए Mach port)
• एक behavior (कर्नेल मैसेज कैसे भेजता है)
• एक flavor (कौन सा thread state शामिल होगा)

Debuggers and Exception Handling

एक debugger (उदा., LLDB) लक्ष्य task या thread पर एक exception port सेट करता है, आमतौर पर task_set_exception_ports() का उपयोग करके।

जब एक exception होता है:

• Mach message debugger process को भेजा जाता है।
• debugger तय कर सकता है कि exception को handle करे (resume, registers बदलना, instruction स्किप करना) या नहीं 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)।

• अगर ignore किया गया → Host port (आमतौर पर ReportCrash)।

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

PAC Exceptions

जब Pointer Authentication (PAC) फेल होता है (signature mismatch), एक special Mach exception उठता है:

• EXC_ARM_PAC (type)
• Codes में विवरण हो सकते हैं (उदा., key type, pointer type)।

यदि बायनेरी में flag TFRO_PAC_EXC_FATAL सेट है, तो कर्नेल PAC failures को fatal के रूप में मानता है, debugger interception को bypass करता हुआ। यह attackers को debuggers का उपयोग करके PAC checks bypass करने से रोकने के लिए है और यह platform binaries के लिए सक्षम होता है।

Software Breakpoints

एक software breakpoint (int3 on x86, brk on ARM64) को जानबूझकर 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 → exception_triage(), exception_deliver_*() का core।

• bsd/kern/kern_sig.c → Signal delivery logic।

• osfmk/arm64/trap.c → Low-level trap handlers।

• osfmk/mach/exc.h → Exception codes और 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 रखता था।

स्क्रीनशॉट से:

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

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

यही कारण था कि heap spraying / feng shui इतने प्रभावी थे: आप उसी size class की allocations स्प्रे करके object neighbors का अनुमान लगा सकते थे।

The freelist

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

• जब एक chunk free होता था, कर्नेल उस chunk के start पर एक pointer लिखता था → उसी zone के अगले free chunk का address।

• Zone एक HEAD pointer रखता था जो पहले free chunk का पता देता था।

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

1. HEAD को pop करें (उस memory को caller को return किया जाता है)।

2. HEAD = HEAD->next अपडेट करें (जो freed chunk के header में स्टोर होता था)।

• Free करना 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)

freelist का शोषण

क्योंकि किसी free chunk के पहले 8 bytes = freelist pointer होते हैं, एक हमलावर इसे बिगाड़ (corrupt) सकता है:

1. Heap overflow एक adjacent freed chunk में → इसके “next” pointer को overwrite कर देना।

2. Use-after-free एक freed object में write करके → इसके “next” pointer को overwrite करना।

फिर, उस size के अगले allocation पर:

• allocator corrupted chunk को pop करता है।
• attacker-supplied “next” pointer को follow करता है।
• arbitrary memory के लिए एक pointer return करता है, जिससे fake object primitives या targeted overwrite संभव हो पाते हैं।

freelist poisoning का visual उदाहरण:

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 डिज़ाइन ने हार्डेनिंग से पहले 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.
इस तरह, जब memory corruption होगा, attacker reliably victim object को controlled डेटा से overwrite कर सकेगा।

Steps:

1. Spray allocations (fill the holes)

• समय के साथ kernel heap fragmented हो जाता है: कुछ zones में पुराने freed objects के कारण holes बन जाते हैं।
• attacker सबसे पहले बहुत सारी dummy allocations करके इन gaps को भरता है, ताकि heap “packed” और predictable बन जाए।

2. Force new pages

• एक बार holes भर जाने पर, अगली allocations zone में add की गई नई pages से आनी पड़ती हैं।
• नई pages का मतलब है कि objects एक साथ clustered होंगे, पुराने fragmented memory में scattered नहीं होंगे।
• इससे attacker को neighbors पर बेहतर control मिलता है।

3. Place attacker objects

• attacker अब फिर से spray करता है, उन नई pages में बहुत सारे attacker-controlled objects बनाता है।
• ये objects size और placement में predictable होते हैं (क्योंकि वे उसी zone के हैं)।

4. Free a controlled object (make a gap)

• attacker जानबूझकर अपने एक object को free करता है।
• यह heap में एक “hole” बनाता है, जिसे allocator बाद में उसी size की अगली allocation के लिए reuse करेगा।

5. Victim object lands in the hole

• attacker kernel को trigger करता है ताकि victim object (जिसे वह corrupt करना चाहता है) allocate हो।
• चूँकि hole freelist में पहला available slot होता है, victim ठीक वहीं placed होगा जहाँ attacker ने अपना object free किया था।

6. Overflow / UAF into victim

• अब attacker के आसपास attacker-controlled objects हैं।
• अपने किसी object से overflow करके (या freed object को reuse करके) attacker reliably victim की memory fields को चुने हुए मानों से overwrite कर सकता है।

Why it works:

• Zone allocator predictability: एक ही size की allocations हमेशा उसी zone से आती हैं।
• Freelist behavior: नई allocations सबसे हाल में freed chunk को सबसे पहले reuse करती हैं।
• Heap sprays: attacker predictable content से memory भरता है और layout को control करता है।
• End result: attacker control करता है कि victim object कहाँ आयेगा और उसके पास क्या data रहेगा।

आधुनिक Kernel Heap (iOS 15+/A12+ SoCs)

Apple ने allocator को harden किया और heap grooming को काफी कठिन बना दिया:

1. From Classic kalloc to kalloc_type

• Before: हर size class (16, 32, 64, … 1280, आदि) के लिए एक single kalloc.<size> zone मौजूद था। उसी size के कोई भी object वहाँ रखा जाता था → attacker objects privileged kernel objects के बगल में आ सकते थे।
• Now:
• Kernel objects अब typed zones (kalloc_type) से allocate होते हैं।
• हर object type (उदा., ipc_port_t, task_t, OSString, OSData) का अपना dedicated zone होता है, भले ही उनका size समान हो।
• object type ↔ zone का mapping compile time पर kalloc_type system से generated होता है।

एक attacker अब यह guarantee नहीं कर सकता कि controlled data (OSData) उसी size के sensitive kernel objects (task_t) के adjacent पहुंचेगा।

2. Slabs and Per-CPU Caches

• heap को slabs में बाँटा गया है (उस zone के लिए fixed-size chunks में काटी गई pages)।
• हर zone का एक per-CPU cache होता है ताकि contention कम हो।
• Allocation path:

1. पहले per-CPU cache देखें।
2. अगर खाली है, तो global freelist से खींचें।
3. अगर freelist खाली है, तो नया slab (एक या अधिक pages) allocate करें।

• Benefit: यह decentralization heap sprays को कम deterministic बनाती है, क्योंकि allocations अलग-अलग CPUs’ caches से satisfy हो सकती हैं।

3. Randomization inside zones

• एक zone के भीतर, freed elements simple FIFO/LIFO order में वापस नहीं दिए जाते।
• Modern XNU encoded freelist pointers का उपयोग करता है (Linux जैसा safe-linking, ~iOS 14 के आसपास आया)।
• हर freelist pointer को per-zone secret cookie के साथ XOR-encode किया जाता है।
• इससे attacker के लिए fake freelist pointer forge करना मुश्किल हो जाता है यदि वे write primitive हासिल भी कर लें।
• कुछ allocations को slab के भीतर randomized placement मिलता है, इसलिए spraying adjacency की गारंटी नहीं देता।

4. Guarded Allocations

• कुछ critical kernel objects (उदा., credentials, task structures) guarded zones में allocate किए जाते हैं।
• ये zones slabs के बीच guard pages (unmapped memory) या objects के चारों ओर redzones डालते हैं।
• guard page में overflow होने पर fault trigger होता है → immediate panic होता है बजाय silent corruption के।

5. Page Protection Layer (PPL) and SPTM

• भले ही आप किसी freed object को control कर लें, आप kernel memory का सब कुछ modify नहीं कर सकते:
• PPL (Page Protection Layer) सुनिश्चित करता है कि कुछ regions (उदा., code signing data, entitlements) kernel के लिए भी read-only रहें।
• A15/M2+ devices पर यह भूमिका/सुरक्षा SPTM (Secure Page Table Monitor) + TXM (Trusted Execution Monitor) द्वारा बदली/मजबूत की गई है।
• ये hardware-enforced layers attackers को single heap corruption से critical security structures को arbitrary patch करने से रोकते हैं।
• (Added / Enhanced): kernel में pointers (विशेषकर function pointers, vtables) को सुरक्षित करने के लिए PAC (Pointer Authentication Codes) भी उपयोग किया जाता है ताकि उन्हें forge/ corrupt करना कठिन हो।
• (Added / Enhanced): zones अब zone_require / zone enforcement लागू कर सकते हैं, यानी किसी object को free करने पर केवल उसके correct typed zone से ही लौटाया जा सके; invalid cross-zone frees panic या reject हो सकते हैं। (Apple ने इसे अपनी memory safety posts में संकेत दिया है)

6. Large Allocations

• सभी allocations kalloc_type से नहीं जातीं।
• बहुत बड़े requests (~16 KB से ऊपर) typed zones को bypass करते हैं और सीधे kernel VM (kmem) से page allocations के जरिए serve किए जाते हैं।
• ये कम predictable होते हैं, पर कम exploitable भी होते हैं क्योंकि वे slabs किसी अन्य objects के साथ share नहीं करते।

7. Allocation Patterns Attackers Target

इन protections के बावजूद, attackers अभी भी इन चीज़ों को टार्गेट करते हैं:

• Reference count objects: यदि आप retain/release counters को tamper कर सकें, तो use-after-free को जनरेट किया जा सकता है।
• Objects with function pointers (vtables): किसी को corrupt करना अभी भी control flow दे सकता है।
• Shared memory objects (IOSurface, Mach ports): ये अभी भी attack targets हैं क्योंकि वे user ↔ kernel को bridge करते हैं।

पर — पहले की तरह — आप सिर्फ OSData spray करके उम्मीद नहीं कर सकते कि वह task_t के बगल में आ जाएगा। सफल होने के लिए आपको type-specific bugs या info leaks की ज़रूरत होगी।

Example: Allocation Flow in Modern Heap

मान लीजिए userspace IOKit को call करके एक OSData object allocate कराता है:

1. Type lookup → OSData map होता है kalloc_type_osdata zone (size 64 bytes) में।
2. per-CPU cache में free elements देखें।

• यदि मिलता है → उसे return करें।
• यदि खाली → global freelist पर जाएँ।
• यदि freelist खाली → नया slab allocate करें (4KB page → 64 chunks of 64 bytes)।

3. chunk caller को return करें।

Freelist pointer protection:

• हर freed chunk में next free chunk का address store होता है, पर secret key के साथ encoded होता है।
• attacker data से उस field को overwrite करना तब काम नहीं करेगा जब तक कि आप key नहीं जानते।

Comparison Table

आधुनिक Userland Heap (iOS, macOS — type-aware / xzone malloc)

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

Goals & Design Principles

• Type segregation / type awareness: allocations को type या usage (pointer vs data) के हिसाब से group करना ताकि type confusion और cross-type reuse रोका जा सके।
• Metadata isolation: heap metadata (उदा. free lists, size/state bits) को object payloads से अलग रखना ताकि out-of-bounds writes से metadata corrupt होने की संभावना कम हो।
• 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 बनाए रखना, excessive fragmentation से बचना, और high allocation rates के साथ low latency देना।

Architecture & Components

नीचे xzone allocator के मुख्य elements दिए गए हैं:

Segment Groups & Zones

• Segment groups address space को usage categories से partition करते हैं: उदा. data, pointer_xzones, data_large, pointer_large।
• हर segment group में segments (VM ranges) होते हैं जो उस category की allocations host करते हैं।
• हर segment के साथ एक metadata slab (separate VM area) जुड़ा होता है जो metadata (उदा. free/used bits, size classes) स्टोर करता है। यह out-of-line (OOL) metadata सुनिश्चित करता है कि metadata object payloads के साथ mix न हो और overflow से corrupt न हो।
• Segments को chunks में काटा जाता है जो फिर blocks में subdivide होते हैं (allocation units)। एक chunk एक specific size class और segment group के लिए tied होता है (यानी chunk के अंदर के सभी blocks एक ही size & category साझा करते हैं)।
• small/medium allocations के लिए fixed-size chunks उपयोग होंगे; large/huge allocations के लिए अलग mapping हो सकती है।

Chunks & Blocks

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

Type / Type ID

• हर allocation site (या malloc, calloc, आदि को call) एक type identifier (malloc_type_id_t) से जुड़ा होता है जो बताता है कि किस तरह का object allocate हो रहा है। वह type ID allocator को दी जाती है, जो सही zone/segment चुनने के लिए इसका उपयोग करती है।
• इसलिए, भले ही दो allocations का size समान हो, वे अलग types होने पर पूरी तरह अलग zones में जा सकती हैं।
• early iOS 17 versions में सभी 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 के साथ invoke होता है।
2. allocator type ID का उपयोग करके सही segment group / zone चुनता है।
3. उस zone/segment में वह उस size के free blocks वाले chunk की तलाश करता है।

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

4. metadata slab update होता है (free bit cleared, bookkeeping)।
5. यदि memory tagging (EMTE) सक्रिय है, तो returned block को एक tag दिया जाता है, और metadata इसे “live” state में अपडेट करता है।
6. जब free() कॉल होता है:

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

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 को integrate किया गया है ताकि memory errors (उदा. stale reads, OOB, UAF) तुरंत पकड़े जाएँ और बाद में exploit न हों।

यदि आप चाहें, मैं आपकी book के लिए xzone internals का एक cheat-sheet या diagram भी बना सकता हूँ। क्या आप चाहेंगे कि मैं वह अगला बनाऊं?

: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: हाल के in-the-wild chains ने WebKit JIT bug (patched as CVE-2023-41993) का दुरुपयोग सिर्फ JavaScript-level arbitrary read/write पाने के लिए किया। exploit तुरंत एक purchased framework JSKit में pivot करता है, ताकि किसी भी भविष्य के Safari bug को बस वही primitive deliver करना पड़े।
• Version abstraction & PAC bypasses: JSKit कई iOS releases के लिए support और कई selectable Pointer Authentication Code bypass modules बंडल करता है। यह framework target build का fingerprint बनाकर appropriate PAC bypass logic चुनता है, और हर step (primitive validation, shellcode launch) को verify करता है।
• Manual Mach-O mapping: JSKit memory से सीधे Mach-O headers parse करता है, dyld-cached images के अंदर जरूरी symbols resolve करता है, और additional Mach-O payloads manual map कर सकता है बिना उन्हें disk पर लिखे। इससे renderer process in-memory ही रहता है और filesystem artifacts से जुड़े code-signature checks से बचता है।
• Portfolio model: Debug strings जैसे “exploit number 7” दिखाते हैं कि suppliers कई interchangeable WebKit exploits रखते हैं। एक बार JS primitive JSKit के interface से मेल खा जाए, बाकी chain campaigns के across unchanged रहता है।

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

• Kernel IPC UAF (CVE-2023-41992): दूसरा stage, जो अभी भी Safari context में चलता है, IPC code में kernel use-after-free trigger करता है, freed object को userspace से re-allocate कराता है, और dangling pointers को abuse करके arbitrary kernel read/write में pivot करता है। यह stage पहले से JSKit द्वारा compute किए गए PAC bypass material को reuse भी करता है बजाय कि उसे फिर से derive करने के।
• Code-signing bypass (CVE-2023-41991): kernel R/W मिलने के साथ, exploit trust cache / code-signing structures को patch करता है ताकि unsigned payloads system के रूप में execute हों। फिर यह stage बाद के payloads को एक lightweight kernel R/W service expose करता है।
• Composed pattern: यह chain एक reusable recipe दिखाती है जिसे defenders आगे भी expect कर सकते हैं:

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

PREYHUNTER helper & watcher modules

• Watcher anti-analysis: एक समर्पित watcher बाइनरी लगातार डिवाइस की प्रोफाइलिंग करती है और जब कोई research environment पता चलता है तो kill-chain को abort कर देती है। यह security.mac.amfi.developer_mode_status, एक diagnosticd console की मौजूदगी, locales US या IL, jailbreak के निशान जैसे Cydia, bash, tcpdump, frida, sshd, या checkrain जैसे processes, मोबाइल AV apps (McAfee, AvastMobileSecurity, NortonMobileSecurity), कस्टम HTTP proxy सेटिंग्स, और कस्टम root CAs की जाँच करती है। किसी भी चेक में असफल होने पर आगे की payload delivery ब्लॉक कर दी जाती है।
• Helper surveillance hooks: helper component अन्य stages से /tmp/helper.sock के माध्यम से संवाद करता है, फिर DMHooker और UMHooker नाम के hook सेट लोड करता है। ये hooks VOIP audio paths को टैप करते हैं (रिकॉर्डिंग्स /private/var/tmp/l/voip_%lu_%u_PART.m4a में सेव होती हैं), एक system-wide keylogger लागू करते हैं, बिना UI के photos कैप्चर करते हैं, और उन क्रियाओं से उत्पन्न होने वाली notifications को दबाने के लिए SpringBoard को hook करते हैं। इसलिए helper, भारी implants जैसे Predator को ड्रोप करने से पहले एक stealthy validation + light-surveillance लेयर के रूप में कार्य करता है।

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

संदर्भ

• 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 सबमिट करें।