// 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 mismatch इसे पकड़ नहीं पाता।
- **Tag width limitation**: tag के लिए केवल कुछ बिट्स उपलब्ध होते हैं (उदा. 4 bits, या छोटा domain)—सीमित namespace।
- **Side-channel leaks**: यदि tag बिट्स leak हो सकते हैं (cache / speculative execution के माध्यम से), attacker वैध 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 केवल उन्हीं डिवाइसों पर enabled है जिनमें support है।
- **Complex allocator logic**: allocator को tags, retagging, boundary alignment manage करना होगा और mis-tag collisions से बचना होगा। allocator logic में बग vulnerabilities पैदा कर सकते हैं।
- **Mixed memory / hybrid areas**: कुछ memory legacy कारणों से untagged रह सकती है, जिससे interoperability जटिल हो जाती है।
- **Speculative / transient attacks**: कई microarchitectural protections की तरह, speculative execution या micro-op fusions checks को transient रूप से bypass कर सकती हैं या tag बिट्स को leak कर सकती हैं।
- **Limited to supported regions**: Apple संभवतः EMTE को selective, high-risk क्षेत्रों (kernel, security-critical subsystems) में ही enforce करे, न कि सार्वभौमिक रूप से।


---

## Key enhancements / differences compared to standard MTE

यहाँ वे improvements और परिवर्तन हैं जिन पर 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 को कड़ाई से enforce कर सकता है, performance pitfalls से बच सकता है, और side-channel holes बंद कर सकता है।

---

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

नीचे एक उच्च-स्तरीय विवरण है कि Apple के MIE सेटअप में EMTE कैसे काम करता है:

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

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

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

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

5. **Tag confidentiality enforcement**
- Apple को tag values के leak होने से रोकना होगा (क्योंकि अगर attacker tag जान लेता है, तो वह सही tags के साथ pointers बना सकता है)।
- वे tag bits के speculative side-channels आदि के माध्यम से leakage रोकने के लिए protections शामिल करते हैं।

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 में 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 में convert होने से पहले कई layers के 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` में defined है।
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">c</span></div>

```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 object (thread, task, host) exception ports रजिस्टर कर सकता है, जहाँ exception messages भेजे जाते हैं।

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

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

प्रत्येक एक्सेप्शन पोर्ट के पास:

• एक मास्क (यह किस एक्सेप्शन को प्राप्त करना चाहता है)
• एक पोर्ट नाम (Mach पोर्ट जो संदेश प्राप्त करेगा)
• एक बिहेवियर (कर्नेल संदेश कैसे भेजता है)
• एक फ्लेवर (कौन सा thread state शामिल किया जाएगा)

डिबगर्स और एक्सेप्शन हैंडलिंग

एक डिबगर (उदा., LLDB) लक्षित task या thread पर एक एक्सेप्शन पोर्ट सेट करता है, आमतौर पर task_set_exception_ports() का उपयोग करके।

जब कोई एक्सेप्शन होता है:

• Mach संदेश डिबगर प्रक्रिया को भेजा जाता है।
• डिबगर निर्णय ले सकता है कि वह इसे हैंडल करे (resume, registers बदलना, instruction skip करना) या नहीं हैन्डल करे।
• अगर डिबगर इसे हैंडल नहीं करता, तो एक्सेप्शन अगले स्तर पर फैलता है (task → host).

EXC_BAD_ACCESS का फ्लो

1. Thread किसी अमान्य pointer को dereference करता है → CPU Data Abort उठाता है।

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

3. संदेश भेजा जाता है:

• Thread पोर्ट → (डिबगर ब्रेकपॉइंट को इंटरसेप्ट कर सकता है)।

• अगर डिबगर अनदेखा करता है → Task पोर्ट → (प्रोसेस-लेवल हैंडलर)।

• अगर अनदेखा किया जाता है → Host पोर्ट (आम तौर पर ReportCrash)।

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

PAC एक्सेप्शन्स

जब Pointer Authentication (PAC) फेल होता है (signature mismatch), एक विशेष Mach एक्सेप्शन उठाया जाता है:

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

अगर बाइनरी में फ्लैग TFRO_PAC_EXC_FATAL set है, तो कर्नेल PAC फेलियर्स को fatal मानता है, और डिबगर इंटरसेप्शन को बायपास कर देता है। यह इसलिए किया गया है ताकि attackers डिबगर का उपयोग करके PAC checks को बायपास न कर सकें और यह platform binaries के लिए सक्षम होता है।

सॉफ़्टवेयर ब्रेकपॉइंट्स

एक सॉफ़्टवेयर ब्रेकपॉइंट (int3 on x86, brk on ARM64) को जानबूझ कर fault उत्पन्न करके इम्प्लीमेंट किया जाता है.
डिबगर इसे exception पोर्ट के माध्यम से पकड़ता है:

• instruction pointer या memory को संशोधित करता है।
• मूल instruction को पुनर्स्थापित करता है।
• execution पुनः आरंभ करता है।

यही मेकैनिज़्म आपको एक PAC एक्सेप्शन "catch" करने की अनुमति देता है --- जब तक TFRO_PAC_EXC_FATAL सेट न हो, उस स्थिति में यह कभी डिबगर तक नहीं पहुँचता।

BSD सिग्नल्स में रूपांतरण

अगर कोई हैंडलर एक्सेप्शन स्वीकार नहीं करता:

• कर्नेल task_exception_notify() → bsd_exception() को कॉल करता है।

• यह Mach एक्सेप्शन्स को सिग्नल्स में मैप करता है:

XNU स्रोत में प्रमुख फाइलें

• osfmk/kern/exception.c → exception_triage(), exception_deliver_*() का कोर।

• bsd/kern/kern_sig.c → सिग्नल डिलिवरी लॉजिक।

• osfmk/arm64/trap.c → लो-लेवल trap handlers।

• osfmk/mach/exc.h → एक्सेप्शन कोड्स और स्ट्रक्चर्स।

• osfmk/kern/task.c → Task exception पोर्ट सेटअप।

पुराना Kernel Heap (Pre-iOS 15 / Pre-A12 युग)

कर्नेल एक zone allocator (kalloc) का उपयोग करता था जो फिक्स्ड-साइज़ "ज़ोन्स" में विभाजित था। प्रत्येक ज़ोन केवल एक सिंगल साइज क्लास के allocations स्टोर करता था।

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

यह इस प्रकार काम करता था:

• प्रत्येक allocation अनुरोध को निकटतम zone size तक round up किया जाता था। (उदा., 50-बाइट का अनुरोध kalloc.64 ज़ोन में जाएगा)।
• प्रत्येक ज़ोन में मेमोरी एक freelist में रखी जाती थी — कर्नेल द्वारा फ्री की गई chunks उसी ज़ोन में वापस जाती थीं।
• अगर आप एक 64-बाइट buffer overflow करते थे, तो आप उसी ज़ोन के अगले ऑब्जेक्ट को overwrite कर देते थे।

यही कारण है कि heap spraying / feng shui इतना प्रभावी था: आप एक ही साइज क्लास के allocations स्प्रे करके ऑब्जेक्ट соседों की भविष्यवाणी कर सकते थे।

The freelist

प्रत्येक kalloc ज़ोन के अंदर, फ्री किए गए ऑब्जेक्ट्स सीधे सिस्टम को वापस नहीं किए जाते थे — वे freelist में जाते थे, उपलब्ध chunks की एक linked list।

• जब एक chunk फ्री किया जाता था, कर्नेल उस chunk की शुरुआत में एक pointer लिखता था → उसी ज़ोन के अगले फ्री chunk का पता।

• ज़ोन एक HEAD pointer रखता था जो पहले फ्री chunk की ओर इशारा करता था।

• Allocation हमेशा मौजूदा HEAD का उपयोग करता था:

1. HEAD को pop करना (वह मेमोरी caller को वापस की जाती है)।

2. HEAD = HEAD->next अपडेट करना (जो फ्री किए गए chunk के हेडर में संग्रहीत था)।

• Freeing chunks को वापस पुश करता था:

• freed_chunk->next = HEAD

• HEAD = freed_chunk

तो freelist बस मुक्त मेमोरी के अंदर ही निर्मित एक linked list थी।

सामान्य स्थिति:

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 के बराबर होते हैं, एक हमलावर इसे 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 का अनुसरण करता है।

• Arbitrary memory के लिए pointer return करता है, जिससे fake object primitives या 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 डिजाइन हार्डनिंग से पहले exploitation को अत्यंत प्रभावी बनाती थी: heap sprays से अनुमानित पड़ोसी, raw pointer freelist links, और किसी भी प्रकार का विभाजन न होने के कारण हमलावर UAF/overflow बग्स को arbitrary kernel memory control में escalate कर सकते थे।

Heap Grooming / Feng Shui

Heap grooming का लक्ष्य है कि heap लेआउट को आकार देना ताकि जब हमलावर overflow या use-after-free ट्रिगर करे, तो लक्ष्य (victim) ऑब्जेक्ट सीधे attacker-controlled ऑब्जेक्ट के बगल में बैठा हो।
इस तरह, जब memory corruption होता है, हमलावर विश्वसनीय रूप से victim ऑब्जेक्ट को नियंत्रित डेटा से overwrite कर सकता है।

Steps:

1. Spray allocations (fill the holes)

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

2. Force new pages

• एक बार holes भर दिए जाने पर, अगली allocations को उस zone में नई pages से आना होगा।
• ताज़ा pages का मतलब है कि objects एक साथ clustered होंगे, पुराने fragmented memory में बिखरे हुए नहीं।
• इससे हमलावर को पड़ोसियों पर बेहतर नियंत्रण मिलता है।

3. Place attacker objects

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

4. Free a controlled object (make a gap)

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

5. Victim object lands in the hole

• हमलावर kernel को ट्रिगर करता है ताकि victim ऑब्जेक्ट allocate हो।
• चूँकि hole freelist में पहली उपलब्ध slot है, victim ठीक उसी जगह पर रखा जाता है जहाँ हमलावर ने अपनी object free की थी।

6. Overflow / UAF into victim

• अब हमलावर के पास victim के आस-पास attacker-controlled ऑब्जेक्ट होते हैं।
• अपनी किसी ऑब्जेक्ट से overflow करके (या freed ऑब्जेक्ट का reuse करके), वे विश्वसनीय रूप से victim की memory fields को चुने हुए मानों से overwrite कर सकते हैं।

क्यों यह काम करता है:

• Zone allocator की predictability: एक ही size की allocations हमेशा उसी zone से आती हैं।
• Freelist व्यवहार: नई allocations सबसे हाल में freed chunk को पहले reuse करती हैं।
• Heap sprays: हमलावर स्मृति को predictable content से भरता है और layout को नियंत्रित करता है।
• अंत में: हमलावर नियंत्रित करता है कि victim ऑब्जेक्ट कहाँ land करे और उसके बगल में कौन सा डेटा हो।

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

Apple ने allocator को मजबूत किया और heap grooming को काफी मुश्किल बना दिया:

1. From Classic kalloc to kalloc_type

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

हमलावर अब यह सुनिश्चित नहीं कर सकता कि controlled डेटा (OSData) sensitive kernel objects (task_t) के साथ उसी size पर adjacent आ जाएगा।

2. Slabs and Per-CPU Caches

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

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

• लाभ: यह decentralized तरीका heap sprays को कम deterministic बनाता है, क्योंकि allocations अलग-अलग CPUs के caches से पूरी हो सकती हैं।

3. Randomization inside zones

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

4. Guarded Allocations

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

5. Page Protection Layer (PPL) and SPTM

• भले ही आप किसी freed object को नियंत्रित कर लें, आप kernel की पूरी memory को modify नहीं कर सकते:
• PPL (Page Protection Layer) यह लागू करता है कि कुछ क्षेत्रों (उदा., code signing data, entitlements) kernel के लिए भी read-only हों।
• A15/M2+ devices पर यह भूमिका SPTM (Secure Page Table Monitor) + TXM (Trusted Execution Monitor) द्वारा बदली/बढ़ाई गई है।
• ये hardware-enforced layers सुनिश्चित करते हैं कि हमलावर एक 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 लागू कर सकते हैं, यानी कि freed object केवल अपने सही typed zone के माध्यम से ही वापस आ सकता है; गलत cross-zone frees panic करवा सकते हैं या reject किए जा सकते हैं। (Apple अपनी memory safety पोस्ट्स में इसका जिक्र करती है)

6. Large Allocations

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

7. Allocation Patterns Attackers Target

इन सुरक्षा उपायों के बावजूद, हमलावर अभी भी इन चीज़ों की तलाश करते हैं:

• Reference count objects: अगर आप retain/release काउंटर्स में छेड़छाड़ कर सकें तो use-after-free पैदा हो सकता है।
• Objects with function pointers (vtables): एक को corrupt करना अभी भी control flow दे सकता है।
• Shared memory objects (IOSurface, Mach ports): ये अभी भी निशाने पर हैं क्योंकि वे user ↔ kernel का पुल होते हैं।

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

Example: Allocation Flow in Modern Heap

मान लीजिए userspace IOKit में कॉल करके एक OSData ऑब्जेक्ट 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 में अगले free chunk का पता store होता है, पर वह secret key के साथ encoded होता है।
• attacker data से उस फ़ील्ड को overwrite करने पर तब तक काम नहीं करेगा जब तक आप key नहीं जानते।

Comparison Table

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

हालिया Apple OS वर्शन (खासकर 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: allocations को type या उपयोग (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 बनाए रखना, अधिक fragmentation से बचना, और प्रति सेकंड कई allocations का low-latency समर्थन करना।

Architecture & Components

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

Segment Groups & Zones

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

Chunks & Blocks

• एक chunk एक क्षेत्र है (अक्सर कई pages) जो एक size class के allocations के लिए समर्पित होता है।
• एक chunk के अंदर blocks allocation के स्लॉट होते हैं। 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) से जुड़ा होता है जो बताता है कि किस तरह का ऑब्जेक्ट allocate हो रहा है। यह type ID allocator को दिया जाता है, जो इसे सही zone/segment चुनने के लिए उपयोग करता है।
• इसलिए, भले ही दो allocations का आकार समान हो, उनके types अलग होने पर वे पूरी तरह अलग zones में जा सकते हैं।
• iOS 17 के पहले वर्ज़न में, सभी APIs (उदा., CFAllocator) पूरी तरह type-aware नहीं थीं; Apple ने iOS 18 में कुछ कमजोरियों को संबोधित किया।

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 के भीतर, वह उस size के लिए free blocks वाला chunk खोजता है।

• यह 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) सक्रिय है, तो वापस किया गया block एक tag पा लेता है और metadata इसकी “live” स्थिति दर्शाने के लिए अपडेट होता है।
6. जब free() कॉल होती है:

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

Security Features & Hardening

ये आधुनिक userland xzone में निर्मित रक्षा हैं:

Interaction with Memory Integrity Enforcement (MIE / EMTE)

• Apple का MIE (Memory Integrity Enforcement) hardware + OS फ्रेमवर्क है जो Enhanced Memory Tagging Extension (EMTE) को major attack surfaces पर always-on, synchronous mode में लाता है।
• 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 न हो सकें।

अगर आप चाहें तो मैं आपके बुक के लिए xzone internals का cheat-sheet या diagram भी बना कर दे सकता हूँ। क्या आप चाहेंगे कि मैं अगला ऐसा बनाऊँ? ::contentReference[oai:20]{index=20}

(Old) Physical Use-After-Free via IOSurface

ios Physical UAF - IOSurface

Ghidra Install BinDiff

BinDiff DMG को https://www.zynamics.com/bindiff/manual से डाउनलोड करें और इंस्टॉल करें।

Ghidra को ghidraRun से खोलें और File --> Install Extensions पर जाएँ, add बटन दबाएँ और path /Applications/BinDiff/Extra/Ghidra/BinExport चुनें और OK पर क्लिक कर के install करें भले ही version mismatch हो।

Using BinDiff with Kernel versions

1. उस पेज पर जाएँ https://ipsw.me/ और वे iOS versions डाउनलोड करें जिन्हें आप diff करना चाहते हैं। ये .ipsw फाइलें होंगी।
2. decompress करें जब तक कि आपको दोनों .ipsw फाइलों के kernelcache का bin format न मिल जाए। इसको कैसे करना है इसके बारे में जानकारी आपको मिल सकती है:

macOS Kernel Extensions & Kernelcache

3. Ghidra को ghidraRun से खोलें, एक नया project बनाएं और kernelcaches लोड करें।
4. प्रत्येक kernelcache खोलें ताकि वे Ghidra द्वारा स्वतः analyze हो जाएँ।
5. फिर, Ghidra के project Window पर प्रत्येक kernelcache पर right click करें, Export चुनें, format में Binary BinExport (v2) for BinDiff चुनें और export करें।
6. BinDiff खोलें, एक नया workspace बनाएं और एक नया diff जोड़ें जिसमें primary file वह kernelcache हो जो vulnerability रखता है और secondary file patched kernelcache हो।

Finding the right XNU version

अगर आप किसी specific version के iOS में vulnerabilities चेक करना चाहते हैं, तो आप यह देख सकते हैं कि वह iOS किस XNU release version का उपयोग करता है इस पेज पर: [https://www.theiphonewiki.com/wiki/kernel]https://www.theiphonewiki.com/wiki/kernel).

उदाहरण के लिए, versions 15.1 RC, 15.1 और 15.1.1 Darwin Kernel Version 21.1.0: Wed Oct 13 19:14:48 PDT 2021; root:xnu-8019.43.1~1/RELEASE_ARM64_T8006 उपयोग करते हैं।

iMessage/Media Parser Zero-Click Chains

Imessage Media Parser Zero Click Coreaudio Pac Bypass