; Example: indirect function pointer stored in a struct ; suppose X1 contains a function pointer PACDA X1, X2 ; sign data pointer X1 with context X2 STR X1, [X0] ; store signed pointer

; later retrieval: LDR X1, [X0] AUTDA X1, X2 ; authenticate & strip BLR X1 ; branch to valid target

; Example: stripping for comparison (unsafe) LDR X1, [X0] XPACI X1 ; strip PAC (instruction domain) CMP X1, #some_label_address BEQ matched_label

</details>

<details>
<summary>Example</summary>
버퍼 오버플로우가 스택의 return address를 덮어쓴다. 공격자는 대상 gadget 주소를 쓴다지만 올바른 PAC를 계산하지 못한다. 함수가 반환될 때 CPU의 `AUTIA` 명령이 PAC 불일치로 예외를 일으킨다. 체인은 실패한다.
Project Zero의 A12 (iPhone XS) 분석은 Apple의 PAC 사용 방식과, 공격자가 memory read/write primitive를 가질 때 PAC을 위조하는 방법을 보여주었다.
</details>


### 9. **Branch Target Identification (BTI)**
**Introduced with ARMv8.5 (later hardware)**
BTI는 간접 분기 대상(indirect branch targets)을 검사하는 하드웨어 기능이다: `blr` 또는 간접 호출/점프를 실행할 때, 대상은 **BTI landing pad**(`BTI j` 또는 `BTI c`)로 시작해야 한다. landing pad가 없는 gadget 주소로 점프하면 예외가 발생한다.

LLVM의 구현 노트는 BTI 명령의 세 가지 변형과 이들이 분기 유형에 어떻게 매핑되는지 기술한다.

| BTI Variant | What it permits (which branch types) | Typical placement / use case |
|-------------|----------------------------------------|-------------------------------|
| **BTI C** | Targets of *call*-style indirect branches (e.g. `BLR`, or `BR` using X16/X17) | Put at entry of functions that may be called indirectly |
| **BTI J** | Targets of *jump*-style branches (e.g. `BR` used for tail calls) | Placed at the beginning of blocks reachable by jump tables or tail-calls |
| **BTI JC** | Acts as both C and J | Can be targeted by either call or jump branches |

- branch target enforcement로 컴파일된 코드에서는 컴파일러가 각 유효한 간접-분기 대상(간접 호출될 수 있는 함수 시작 또는 점프로 도달 가능한 블록)에 BTI 명령(C, J, 또는 JC)을 삽입하여, 간접 분기가 오직 그러한 위치로만 성공하도록 한다.
- **Direct branches / calls**(예: 고정 주소 `B`, `BL`)은 BTI의 제한을 받지 않는다. 이는 코드 페이지가 신뢰된다고 가정하고 공격자가 이를 변경할 수 없으므로(따라서 direct branches는 안전하다고 간주)이다.
- 또한, **RET / return** 명령은 일반적으로 PAC 또는 return signing 메커니즘으로 return 주소가 보호되기 때문에 BTI의 제한을 받지 않는다.

#### Mechanism and enforcement

- CPU가 “guarded / BTI-enabled”로 표시된 페이지에서 **indirect branch (`BLR` / `BR`)**를 디코드할 때, 대상 주소의 첫 명령이 허용된 BTI(C, J, 또는 JC)인지 검사한다. 그렇지 않으면 **Branch Target Exception**이 발생한다.
- BTI 명령 인코딩은 이전 ARM 버전에서 NOP로 예약되었던 opcode를 재사용하도록 설계되었다. 따라서 BTI-enabled 바이너리는 BTI를 지원하지 않는 하드웨어에서도 호환성을 유지한다: 그 명령들은 NOP로 동작한다.
- BTI를 추가하는 컴파일러 패스는 필요한 곳에만 BTI를 삽입한다: 간접적으로 호출될 수 있는 함수들이나 점프로 도달 가능한 기본 블록들.
- 일부 패치와 LLVM 코드는 BTI가 모든 기본 블록에 삽입되는 것이 아니라—스위치/점프 테이블 등으로부터의 가능한 분기 대상인 블록들에만 삽입된다는 점을 보인다.

#### BTI + PAC synergy

PAC는 포인터 값(소스)을 보호한다 — 간접 호출/반환 체인이 변조되지 않았음을 보장한다.

BTI는 유효한 포인터라 하더라도 오직 적절히 표시된 진입점으로만 향해야 함을 보장한다.

결합하면, 공격자는 올바른 PAC를 가진 유효한 포인터뿐 아니라 대상에 BTI가 배치되어 있어야 한다. 이는 exploit gadget을 구성하는 난이도를 증가시킨다.

#### Example


<details>
<summary>Example</summary>
익스플로잇이 `0xABCDEF`의 gadget으로 피벗하려 하는데 그곳은 `BTI c`로 시작하지 않는다. CPU가 `blr x0`를 실행할 때, 대상 검사를 수행하고 유효한 landing pad가 없으므로 폴트가 발생한다. 따라서 많은 gadgets는 BTI 프리픽스가 없으면 사용할 수 없다.
</details>


### 10. **Privileged Access Never (PAN) & Privileged Execute Never (PXN)**
**Introduced in more recent ARMv8 extensions / iOS support (for hardened kernel)**

#### PAN (Privileged Access Never)

- **PAN**은 **ARMv8.1-A**에서 도입된 기능으로, **privileged code**(EL1 또는 EL2)가 **user-accessible (EL0)**로 표시된 메모리를 **읽거나 쓰지 못하도록** 한다. PAN을 명시적으로 비활성화하지 않는 한 접근이 차단된다.
- 아이디어는: 커널이 속임을 당하거나 손상되더라도, 먼저 PAN을 *해제*하지 않는 한 임의로 user-space 포인터를 역참조할 수 없게 하여 **`ret2usr`** 스타일의 익스플로잇이나 사용자 제어 버퍼의 오용 위험을 줄인다.
- PAN이 활성화되어 있을 때(PSTATE.PAN = 1), privileged load/store가 EL0에서 접근 가능한 가상 주소에 접근하면 **permission fault**가 발생한다.
- 커널이 정당하게 user-space 메모리에 접근해야 할 경우(예: 사용자 버퍼로의 데이터 복사), 커널은 **일시적으로 PAN을 비활성화**하거나 “unprivileged load/store” 명령을 사용해야 그 접근을 허용할 수 있다.
- ARM64의 Linux에서는 PAN 지원이 2015년경 도입되었다: 커널 패치들이 이 기능의 감지를 추가하고 `get_user` / `put_user` 등의 호출을 PAN을 해제하는 변형으로 교체했다.

**Key nuance / limitation / bug**
- Siguza 등은 ARM 설계의 명세 버그(또는 애매한 동작)가 있다는 점을 지적했는데, 이는 **execute-only user mappings**(`--x`)이 **PAN을 발생시키지 않을 수 있다**는 것이다. 즉, 사용자 페이지가 읽기 권한 없이 실행만 가능하게 표시되어 있으면, 커널의 읽기 시도가 PAN을 우회할 수 있다 — 아키텍처가 “EL0에서 접근 가능”을 판정할 때 읽기 권한을 요구하고 실행 권한만으로는 고려하지 않기 때문이다. 이는 특정 구성에서 PAN 우회로 이어질 수 있다.
- 따라서 iOS / XNU가 execute-only 사용자 페이지를 허용(예: 일부 JIT 또는 코드 캐시 설정)하면, 커널은 PAN이 활성화되어 있어도 해당 페이지에서 읽어올 수 있어 의도치 않은 경로가 생길 수 있다. 이는 일부 ARMv8+ 시스템에서 알려진 미묘한 취약 지점이다.

#### PXN (Privileged eXecute Never)

- **PXN**은 페이지 테이블 엔트리(leaf 또는 block 엔트리)에 있는 플래그로, 해당 페이지가 **privileged 모드(예: EL1)에서 실행 불가**임을 표시한다.
- PXN은 커널(또는 모든 privileged 코드)이 user-space 페이지에서 명령을 점프하거나 실행하지 못하게 막는다. 실질적으로 커널 수준의 제어 흐름을 사용자 메모리로 리디렉션하는 것을 차단한다.
- PAN과 결합하면 다음을 보장한다:
  1. 기본적으로 커널은 사용자 데이터를 읽거나 쓸 수 없다 (PAN)
  2. 커널은 사용자 코드를 실행할 수 없다 (PXN)
- ARMv8 페이지 테이블 포맷에서 리프 엔트리들은 속성 비트에 `PXN` 비트(및 비권한자 실행 금지용 `UXN`)를 가진다.

따라서 커널이 손상되어 사용자 메모리를 가리키는 잘못된 함수 포인터를 갖고 있다 하더라도, 그 주소로 분기하려 하면 PXN 비트가 폴트를 유발한다.

#### Memory-permission model & how PAN and PXN map to page table bits

PAN / PXN이 어떻게 동작하는지 이해하려면 ARM의 변환 및 권한 모델을(단순화하여) 봐야 한다:

- 각 페이지 또는 블록 엔트리는 읽기/쓰기, 특권/비특권 등을 나타내는 **AP[2:1]** 필드와 실행 금지 제약을 위한 **UXN / PXN** 비트 등을 가진다.
- PSTATE.PAN이 1로 설정되면 하드웨어는 수정된 의미론을 시행한다: EL0에서 접근 가능한 페이지(즉 user-accessible)로 표시된 페이지에 대해 privileged 접근을 금지한다.
- 앞서 언급한 버그 때문에, 읽기 권한 없이 실행만 허용된 페이지는 일부 구현에서 “EL0에서 접근 가능”으로 간주되지 않을 수 있어 PAN을 우회할 수 있다.
- 페이지에 PXN 비트가 설정되면, 상위 권한에서의 명령 페치라 할지라도 실행이 금지된다.

#### Kernel usage of PAN / PXN in a hardened OS (e.g. iOS / XNU)

하드닝된 커널 설계(예: Apple이 사용할 법한 설계)에서는:

- 커널이 기본적으로 PAN을 활성화한다(따라서 privileged 코드가 제약을 받는다).
- 사용자 버퍼를 정당하게 읽거나 써야 하는 경로(예: syscall 버퍼 복사, I/O, 사용자 포인터 읽기/쓰기)에서는 커널이 일시적으로 **PAN을 비활성화**하거나 PAN을 우회하는 특수 명령을 사용한다.
- 사용자 페이지에는 PXN = 1로 설정하여(페이지 테이블을 통해) 커널이 실행하지 못하도록 하고, 커널 페이지에는 PXN이 설정되지 않는다.
- 커널은 어떤 코드 경로도 사용자 메모리 영역으로 실행 흐름을 이동시키지 않도록 보장해야 한다(그렇지 않으면 PXN을 우회할 수 있음). 따라서 “사용자 제어 shellcode로 점프”에 의존한 익스플로잇 체인은 차단된다.

앞서 언급한 execute-only 페이지를 통한 PAN 우회 가능성 때문에, 실제 시스템에서는 Apple이 execute-only 사용자 페이지를 비활성화하거나 명세상 약점을 패치했을 수 있다.

#### Attack surfaces, bypasses, and mitigations

- **PAN bypass via execute-only pages**: 앞서 논의한 대로, 명세는 갭을 허용한다: 읽기 권한 없이 실행만 가능한 사용자 페이지는 일부 구현에서 “EL0에서 접근 가능”으로 간주되지 않아 PAN이 커널의 읽기를 차단하지 못할 수 있다. 이는 공격자에게 execute-only 섹션을 통해 데이터를 전달할 수 있는 비정상적 경로를 제공한다.
- **Temporal window exploit**: 커널이 필요한 것보다 더 긴 시간 동안 PAN을 비활성화하면, 레이스나 악의적 경로가 그 창을 이용해 의도하지 않은 사용자 메모리 접근을 수행할 수 있다.
- **Forgotten re-enable**: PAN을 다시 활성화하지 않는 코드 경로가 있으면, 이후의 커널 작업이 잘못해서 사용자 메모리에 접근할 수 있다.
- **Misconfiguration of PXN**: 페이지 테이블이 사용자 페이지에 PXN을 설정하지 않거나 사용자 코드 페이지를 잘못 매핑하면, 커널이 사용자 공간 코드를 실행하도록 속을 수 있다.
- **Speculation / side-channels**: 투기적 우회와 유사하게, PAN / PXN 검사에 대한 일시적 위반을 초래하는 마이크로아키텍처적 부작용이 있을 수 있다(그러나 이런 공격은 CPU 설계에 크게 의존한다).
- **Complex interactions**: JIT, shared memory, JIT 코드 영역 등 고급 기능에서는 커널이 특정 사용자 매핑에 대해 세밀한 제어를 허용해야 할 수 있다; PAN/PXN 제약 아래에서 이를 안전하게 설계하는 것은 까다롭다.

#### Example

<details>
<summary>Code Example</summary>
다음은 사용자 메모리 접근 주변에서 PAN을 활성/비활성화하는 것을 보여주는 예시 의사 어셈블리 시퀀스이다.

// Suppose kernel entry point, PAN is enabled (privileged code cannot access user memory by default)

; Kernel receives a syscall with user pointer in X0 ; wants to read an integer from user space mov X1, X0 ; X1 = user pointer

; disable PAN to allow privileged access to user memory MSR PSTATE.PAN, #0 ; clear PAN bit, disabling the restriction

ldr W2, [X1] ; now allowed load from user address

; re-enable PAN before doing other kernel logic MSR PSTATE.PAN, #1 ; set PAN

; … further kernel work …

; Later, suppose an exploit corrupts a pointer to a user-space code page and jumps there BR X3 ; branch to X3 (which points into user memory)

; Because the target page is marked PXN = 1 for privileged execution, ; the CPU throws an exception (fault) and rejects execution

If the kernel had **설정하지 않았다면** PXN on that user page, then the branch might succeed — which would be insecure.

If the kernel forgets to re-enable PAN after user memory access, it opens a window where further kernel logic might accidentally read/write arbitrary user memory.

If the user pointer is into an execute-only page (user page with only execute permission, no read/write), under the PAN spec bug, `ldr W2, [X1]` might **오류를 일으키지 않을 수 있다** even with PAN enabled, enabling a bypass exploit, depending on implementation.

</details>

<details>
<summary>Example</summary>
A kernel vulnerability tries to take a user-provided function pointer and call it in kernel context (i.e. `call user_buffer`). Under PAN/PXN, that operation is disallowed or faults.
</details>

---

### 11. **Top Byte Ignore (TBI) / Pointer Tagging**
**Introduced in ARMv8.5 / newer (or optional extension)**
TBI means the top byte (most-significant byte) of a 64-bit pointer is ignored by address translation. This lets OS or hardware embed **tag bits** in the pointer’s top byte without affecting the actual address.

- TBI stands for **Top Byte Ignore** (sometimes called *Address Tagging*). It is a hardware feature (available in many ARMv8+ implementations) that **ignores the top 8 bits** (bits 63:56) of a 64-bit pointer when performing **address translation / load/store / instruction fetch**.
- In effect, the CPU treats a pointer `0xTTxxxx_xxxx_xxxx` (where `TT` = top byte) as `0x00xxxx_xxxx_xxxx` for the purposes of address translation, ignoring (masking off) the top byte. The top byte can be used by software to store **metadata / tag bits**.
- This gives software “free” in-band space to embed a byte of tag in each pointer without altering which memory location it refers to.
- The architecture ensures that loads, stores, and instruction fetch treat the pointer with its top byte masked (i.e. tag stripped off) before performing the actual memory access.

Thus TBI decouples the **logical pointer** (pointer + tag) from the **physical address** used for memory operations.

#### Why TBI: Use cases and motivation

- **Pointer tagging / metadata**: You can store extra metadata (e.g. object type, version, bounds, integrity tags) in that top byte. When you later use the pointer, the tag is ignored at hardware level, so you don’t need to strip manually for the memory access.
- **Memory tagging / MTE (Memory Tagging Extension)**: TBI is the base hardware mechanism that MTE builds on. In ARMv8.5, the **Memory Tagging Extension** uses bits 59:56 of the pointer as a **logical tag** and checks it against an **allocation tag** stored in memory.
- **Enhanced security & integrity**: By combining TBI with pointer authentication (PAC) or runtime checks, you can force not just the pointer value but also the tag to be correct. An attacker overwriting a pointer without the correct tag will produce a mismatched tag.
- **Compatibility**: Because TBI is optional and tag bits are ignored by hardware, existing untagged code continues to operate normally. The tag bits effectively become “don’t care” bits for legacy code.

#### Example
<details>
<summary>Example</summary>
A function pointer included a tag in its top byte (say `0xAA`). An exploit overwrites the pointer low bits but neglects the tag, so when the kernel verifies or sanitizes, the pointer fails or is rejected.
</details>

---

### 12. **Page Protection Layer (PPL)**
**Introduced in late iOS / modern hardware (iOS ~17 / Apple silicon / high-end models)** (some reports show PPL circa macOS / Apple silicon, but Apple is bringing analogous protections to iOS)

- PPL is designed as an **intra-kernel protection boundary**: even if the kernel (EL1) is compromised and has read/write capabilities, **it should not be able to freely modify** certain **sensitive pages** (especially page tables, code-signing metadata, kernel code pages, entitlements, trust caches, etc.).
- It effectively creates a **“kernel within the kernel”** — a smaller trusted component (PPL) with **elevated privileges** that alone can modify protected pages. Other kernel code must call into PPL routines to effect changes.
- This reduces the attack surface for kernel exploits: even with full arbitrary R/W/execute in kernel mode, exploit code must also somehow get into the PPL domain (or bypass PPL) to modify critical structures.
- On newer Apple silicon (A15+ / M2+), Apple is transitioning to **SPTM (Secure Page Table Monitor)**, which in many cases replaces PPL for page-table protection on those platforms.

Here’s how PPL is believed to operate, based on public analysis:

#### Use of APRR / permission routing (APRR = Access Permission ReRouting)

- Apple hardware uses a mechanism called **APRR (Access Permission ReRouting)**, which allows page table entries (PTEs) to contain small indices, rather than full permission bits. Those indices are mapped via APRR registers to actual permissions. This allows dynamic remapping of permissions per domain.
- PPL leverages APRR to segregate privilege within kernel context: only the PPL domain is permitted to update the mapping between indices and effective permissions. That is, when non-PPL kernel code writes a PTE or tries to flip permission bits, the APRR logic disallows it (or enforces read-only mapping).
- PPL code itself runs in a restricted region (e.g. `__PPLTEXT`) which is normally non-executable or non-writable until entry gates temporarily allow it. The kernel calls PPL entry points (“PPL routines”) to perform sensitive operations.

#### Gate / Entry & Exit

- When the kernel needs to modify a protected page (e.g. change permissions of a kernel code page, or modify page tables), it calls into a **PPL wrapper** routine, which does validation and then transitions into the PPL domain. Outside that domain, the protected pages are effectively read-only or non-modifiable by the main kernel.
- During PPL entry, the APRR mappings are adjusted so that memory pages in the PPL region are set to **executable & writable** within PPL. Upon exit, they are returned to read-only / non-writable. This ensures that only well-audited PPL routines can write to protected pages.
- Outside PPL, attempts by kernel code to write to those protected pages will fault (permission denied) because the APRR mapping for that code domain doesn’t permit writing.

#### Protected page categories

The pages that PPL typically protects include:

- Page table structures (translation table entries, mapping metadata)
- Kernel code pages, especially those containing critical logic
- Code-sign metadata (trust caches, signature blobs)
- Entitlement tables, signature enforcement tables
- Other high-value kernel structures where a patch would allow bypassing signature checks or credentials manipulation

The idea is that even if the kernel memory is fully controlled, the attacker cannot simply patch or rewrite these pages, unless they also compromise PPL routines or bypass PPL.


#### Known Bypasses & Vulnerabilities

1. **Project Zero’s PPL bypass (stale TLB trick)**

- A public writeup by Project Zero describes a bypass involving **stale TLB entries**.
- The idea:

1. Allocate two physical pages A and B, mark them as PPL pages (so they are protected).
2. Map two virtual addresses P and Q whose L3 translation table pages come from A and B.
3. Spin a thread to continuously access Q, keeping its TLB entry alive.
4. Call `pmap_remove_options()` to remove mappings starting at P; due to a bug, the code mistakenly removes the TTEs for both P and Q, but only invalidates the TLB entry for P, leaving Q’s stale entry live.
5. Reuse B (page Q’s table) to map arbitrary memory (e.g. PPL-protected pages). Because the stale TLB entry still maps Q’s old mapping, that mapping remains valid for that context.
6. Through this, the attacker can put writable mapping of PPL-protected pages in place without going through PPL interface.

- This exploit required fine control of physical mapping and TLB behavior. It demonstrates that a security boundary relying on TLB / mapping correctness must be extremely careful about TLB invalidations and mapping consistency.

- Project Zero commented that bypasses like this are subtle and rare, but possible in complex systems. Still, they regard PPL as a solid mitigation.

2. **Other potential hazards & constraints**

- If a kernel exploit can directly enter PPL routines (via calling the PPL wrappers), it might bypass restrictions. Thus argument validation is critical.
- Bugs in the PPL code itself (e.g. arithmetic overflow, boundary checks) can allow out-of-bounds modifications inside PPL. Project Zero observed that such a bug in `pmap_remove_options_internal()` was exploited in their bypass.
- The PPL boundary is irrevocably tied to hardware enforcement (APRR, memory controller), so it's only as strong as the hardware implementation.



#### Example
<details>
<summary>Code Example</summary>
Here’s a simplified pseudocode / logic showing how a kernel might call into PPL to modify protected pages:
```c
// In kernel (outside PPL domain)
function kernel_modify_pptable(pt_addr, new_entry) {
// validate arguments, etc.
return ppl_call_modify(pt_addr, new_entry)  // call PPL wrapper
}

// In PPL (trusted domain)
function ppl_call_modify(pt_addr, new_entry) {
// temporarily enable write access to protected pages (via APRR adjustments)
aprr_set_index_for_write(PPL_INDEX)
// perform the modification
*pt_addr = new_entry
// restore permissions (make pages read-only again)
aprr_restore_default()
return success
}

// If kernel code outside PPL does:
*pt_addr = new_entry  // a direct write
// It will fault because APRR mapping for non-PPL domain disallows write to that page

The kernel can do many normal operations, but only through ppl_call_* routines can it change protected mappings or patch code.

// 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**: 오버플로우가 동일한 할당 내에서만 발생(경계를 넘지 않음)하고 태그가 동일하게 유지되면 tag mismatch로는 탐지되지 않습니다.
- **Tag width limitation**: 태그에 사용할 수 있는 비트 수가 제한적(예: 4비트 또는 작은 도메인)이라 네임스페이스가 제한됩니다.
- **Side-channel leaks**: 태그 비트가 (캐시 / speculative execution 등을 통해) leaked 될 수 있다면 공격자가 유효한 태그를 알아내 우회할 수 있습니다. Apple의 tag confidentiality enforcement는 이를 완화하려고 설계되었습니다.
- **Performance overhead**: 각 로드/스토어마다 태그 체크가 추가 비용을 유발하므로 Apple은 하드웨어 최적화를 통해 오버헤드를 낮춰야 합니다.
- **Compatibility & fallback**: 구형 하드웨어나 EMTE를 지원하지 않는 구성 요소에서는 페일백이 필요합니다. Apple은 MIE가 지원되는 장치에서만 활성화된다고 주장합니다.
- **Complex allocator logic**: 할당자는 태그 관리, retagging, 경계 정렬, 태그 충돌 회피 등을 처리해야 합니다. 할당자 로직의 버그는 취약점을 유발할 수 있습니다.
- **Mixed memory / hybrid areas**: 일부 메모리는 untagged(레거시)로 남아 있어 상호운용성이 까다로워질 수 있습니다.
- **Speculative / transient attacks**: 다른 마이크로아키텍처 보호와 마찬가지로 speculative execution이나 micro-op fusion이 검사를 일시적으로 우회하거나 태그 비트를 leak 할 수 있습니다.
- **Limited to supported regions**: Apple은 EMTE를 커널이나 보안에 중요한 서브시스템 등 선별된 고위험 영역에서만 적용할 수 있습니다.

---

## 표준 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은 하드웨어와 소프트웨어 스택을 모두 통제하기 때문에 EMTE를 엄격하게 적용하고 성능 저하 요소를 피하며 side-channel 취약점을 봉쇄할 수 있습니다.

---

## EMTE가 실제로 동작하는 방식 (Apple / MIE)

다음은 Apple의 MIE 구성에서 EMTE가 동작하는 상위 수준 설명입니다:

1. **Tag assignment**
- 메모리가 할당될 때(예: 커널 또는 secure allocators를 통한 사용자 공간), 해당 블록에 **secret tag**가 할당됩니다.
- 사용자나 커널에 반환되는 포인터는 TBI / top byte ignore 메커니즘을 사용해 높은 비트에 그 태그를 포함합니다.

2. **Tag checking on access**
- 포인터를 사용한 load/store가 실행될 때마다 하드웨어는 포인터의 태그가 메모리 블록의 태그(할당 태그)와 일치하는지 검사합니다. 불일치하면 즉시 fault가 발생합니다(동기 방식이므로).
- 동기 방식이기 때문에 “지연된 탐지” 창이 존재하지 않습니다.

3. **Retagging on free / reuse**
- 메모리가 해제되면 할당자는 블록의 태그를 변경합니다(이전 태그를 가진 포인터는 더 이상 일치하지 않음).
- 따라서 use-after-free 포인터는 오래된 태그를 가지고 있어 접근 시 mismatch가 발생합니다.

4. **Neighbor-tag differentiation to catch overflows**
- 인접한 할당 블록에는 서로 다른 태그가 부여됩니다. 버퍼 오버플로우가 이웃 메모리로 흘러들어가면 태그 불일치로 fault가 발생합니다.
- 경계를 넘는 작은 오버플로우를 잡아내는 데 특히 강력합니다.

5. **Tag confidentiality enforcement**
- 공격자가 태그 값을 알게 되면 올바른 태그로 포인터를 조작할 수 있으므로 Apple은 태그 값이 leak 되는 것을 방지해야 합니다.
- 이를 위해 태그 비트의 side-channel leak 를 막기 위한 마이크로아키텍처적 / speculative 제어를 포함합니다.

6. **Kernel and user-space integration**
- Apple은 EMTE를 사용자 공간뿐 아니라 커널/OS 핵심 구성요소에서도 사용해 커널의 메모리 손상으로부터 보호합니다.
- 하드웨어/OS는 사용자 공간을 대신해 커널이 실행될 때에도 태그 규칙이 적용되도록 보장합니다.

EMTE는 MIE에 통합되어 있기 때문에 Apple은 핵심 공격 표면 전반에서 동기 모드로 EMTE를 적용하며, 단순한 선택적 또는 디버깅 용도가 아니라 기본적으로 활성화된 보호로 사용합니다.

---

## XNU에서의 예외 처리

예외가 발생할 때(예: `EXC_BAD_ACCESS`, `EXC_BAD_INSTRUCTION`, `EXC_CRASH`, `EXC_ARM_PAC` 등), XNU 커널의 **Mach 레이어**는 이를 UNIX 스타일의 signal(예: `SIGSEGV`, `SIGBUS`, `SIGILL`, ...)로 변환하기 전에 가로채는 역할을 합니다.

이 과정은 사용자 공간으로 전달되거나 BSD 시그널로 변환되기 전에 여러 계층의 예외 전파 및 처리를 포함합니다.

### 예외 흐름 (상위 수준)

1.  **CPU가 동기 예외를 유발**합니다(예: 잘못된 포인터 역참조, PAC 실패, 불법 명령 등).

2.  **저수준 trap handler**가 실행됩니다(`trap.c`, `exception.c` 참고).

3.  트랩 핸들러는 **`exception_triage()`**를 호출합니다. 이것이 Mach 예외 처리의 핵심입니다.

4.  `exception_triage()`는 예외를 어떻게 라우팅할지 결정합니다:

-   먼저 **thread의 exception port**로 보냅니다.

-   그 다음 **task의 exception port**로 보냅니다.

-   그 다음 **host의 exception port**로 보냅니다(종종 `launchd`나 `ReportCrash`).

이러한 포트들 중 어느 것도 예외를 처리하지 않으면 커널은:

-   **이를 BSD signal로 변환**합니다(사용자 공간 프로세스의 경우).

-   **panic을 일으킵니다**(커널 공간 예외의 경우).

### 핵심 함수: `exception_triage()`

함수 `exception_triage()`는 예외를 가능한 핸들러 체인으로 전달하여 처리될 때까지 또는 최종적으로 치명적으로 판정될 때까지 라우팅합니다. 이 함수는 `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)는 예외 메시지가 전송되는 exception ports를 등록할 수 있다.

다음 API로 정의된다:

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

각 예외 포트는 다음을 갖습니다:

• A mask (어떤 예외를 수신할지)
• A port name (Mach port to receive messages)
• A behavior (커널이 메시지를 어떻게 전송하는지)
• A flavor (어떤 thread state를 포함할지)

Debuggers and Exception Handling

A debugger (예: LLDB)는 대상 task나 thread에 exception port를 설정합니다. 보통 task_set_exception_ports()를 사용합니다.

예외가 발생하면:

• Mach 메시지가 debugger 프로세스로 전송됩니다.
• debugger는 예외를 처리할지(resume, 레지스터 수정, 명령어 건너뛰기) 아니면 처리하지 않을지 결정할 수 있습니다.
• debugger가 처리하지 않으면 예외는 다음 레벨로 전파됩니다 (task → host).

Flow of EXC_BAD_ACCESS

1. Thread가 유효하지 않은 포인터를 역참조 → CPU가 Data Abort를 발생시킵니다.

2. Kernel의 trap handler가 exception_triage(EXC_BAD_ACCESS, ...)를 호출합니다.

3. 메시지가 전송됩니다:

• Thread port → (debugger가 breakpoint를 가로챌 수 있음).

• debugger가 무시하면 → Task port → (프로세스 수준 handler).

• 무시되면 → Host port (보통 ReportCrash).

4. 아무도 처리하지 않으면 → bsd_exception()이 이를 SIGSEGV로 변환합니다.

PAC Exceptions

Pointer Authentication (PAC)이 실패(서명 불일치)하면, 특별한 Mach 예외가 발생합니다:

• EXC_ARM_PAC (타입)
• Codes에는 세부 정보가 포함될 수 있음(예: key type, pointer type).

바이너리에 TFRO_PAC_EXC_FATAL 플래그가 있으면, 커널은 PAC 실패를 fatal로 처리하여 debugger의 가로채기를 우회합니다. 이는 공격자가 debugger를 이용해 PAC 체크를 우회하는 것을 방지하기 위한 것으로, platform binaries에 대해 활성화됩니다.

Software Breakpoints

소프트웨어 breakpoint(int3 on x86, brk on ARM64)는 의도적인 fault를 일으켜 구현됩니다.
debugger는 exception port를 통해 이를 잡습니다:

• instruction pointer나 메모리를 수정합니다.
• 원래의 명령어를 복원합니다.
• 실행을 재개합니다.

이 동일한 메커니즘 때문에 PAC 예외를 “catch“할 수 있습니다 — **단, TFRO_PAC_EXC_FATAL**이 설정된 경우에는 debugger에 도달하지 않습니다.

Conversion to BSD Signals

어떤 handler도 예외를 수락하지 않으면:

• 커널은 task_exception_notify() → bsd_exception()을 호출합니다.

• 이는 Mach 예외를 시그널로 매핑합니다:

### Key Files in XNU Source

• 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 port 설정.

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

커널은 zone allocator(kalloc)를 사용했으며, 고정 크기의 “zones“로 나뉘어 있었습니다.
각 zone은 단일 크기 클래스의 할당만 저장했습니다.

스크린샷에서:

동작 방식:

• 각 할당 요청은 가장 가까운 zone 크기로 올림(round up) 됩니다. (예: 50바이트 요청은 kalloc.64 zone에 할당됩니다).
• 각 zone의 메모리는 freelist에 보관되었습니다 — 커널이 해제한 청크는 해당 zone으로 되돌아갔습니다.
• 64바이트 버퍼를 오버플로우하면, 동일 zone의 다음 객체를 덮어쓰게 됩니다.

이 때문에 heap spraying / feng shui가 매우 효과적이었습니다: 같은 크기 클래스로 할당을 뿌리면 객체 이웃을 예측할 수 있었습니다.

The freelist

각 kalloc zone 내부에서, 해제된 객체들은 시스템에 직접 반환되지 않고 freelist에 들어갔습니다. freelist는 사용 가능한 청크들의 연결 리스트입니다.

• 청크가 해제되면, 커널은 그 청크의 시작 부분에 포인터를 씁니다 → 같은 zone의 다음 free 청크 주소.

• zone은 첫 번째 free 청크를 가리키는 HEAD 포인터를 유지했습니다.

• 할당은 항상 현재 HEAD를 사용했습니다:

1. HEAD를 팝(pop) (그 메모리를 호출자에 반환).

2. HEAD = HEAD->next로 업데이트 (해제된 청크의 헤더에 저장된 값).

• 해제는 청크를 다시 푸시(push)했습니다:

• freed_chunk->next = HEAD

• HEAD = freed_chunk

따라서 freelist는 해제된 메모리 자체 안에 구축된 단순한 연결 리스트였습니다.

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와 같기 때문에, 공격자는 이를 손상시킬 수 있다:

1. Heap overflow로 인접한 freed chunk에 침범 → 그 “next” pointer를 덮어쓰기.

2. Use-after-free로 freed object에 쓰기 → 그 “next” pointer를 덮어쓰기.

그 다음, 해당 크기의 다음 할당 시:

• allocator가 손상된 chunk를 꺼낸다.
• 공격자가 제공한 “next” pointer를 따른다.
• 임의 메모리를 가리키는 포인터를 반환하여 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.

이 freelist 설계는 하드닝 이전에 익스플로잇을 매우 효과적으로 만들었다: heap sprays로 인한 예측 가능한 이웃, 원시 포인터 freelist 링크, 그리고 타입 분리가 없어 공격자가 UAF/overflow 버그를 임의의 커널 메모리 제어로 확장할 수 있었다.

Heap Grooming / Feng Shui

The goal of heap grooming is to 힙 레이아웃을 조성하는 것 so that when an attacker triggers an overflow or use-after-free, the target (victim) object sits right next to an attacker-controlled object.
그렇게 하면 메모리 손상이 발생했을 때 공격자는 victim 객체를 제어된 데이터로 신뢰성 있게 덮어쓸 수 있다.

Steps:

1. Spray allocations (fill the holes)

• 시간이 지나면 커널 힙은 단편화된다: 오래된 객체들이 free되면서 구멍(hole)이 생긴다.
• 공격자는 먼저 많은 더미 할당을 만들어 이러한 빈틈을 채워 힙을 “빽빽하게” 만들어 예측 가능하게 만든다.

2. Force new pages

• 구멍이 채워지면 다음 할당은 zone에 새로 추가된 페이지에서 할당되어야 한다.
• 새 페이지는 객체들이 흩어지지 않고 클러스터링되게 한다.
• 이는 공격자가 이웃 제어를 훨씬 잘 하게 해준다.

3. Place attacker objects

• 공격자는 다시 스프레이하여 그 새 페이지들에 많은 공격자 제어 객체들을 만든다.
• 이 객체들은 모두 같은 zone에 속하므로 크기와 배치가 예측 가능하다.

4. Free a controlled object (make a gap)

• 공격자는 의도적으로 자신의 객체 중 하나를 free한다.
• 이렇게 하면 할당자가 이후 같은 크기의 다음 할당을 위해 재사용할 “구멍”이 생긴다.

5. Victim object lands in the hole

• 공격자는 커널이 victim 객체(손상하려는 객체)를 할당하도록 트리거한다.
• 구멍이 freelist에서 가장 먼저 사용 가능한 슬롯이므로, victim은 공격자가 free한 바로 그 위치에 놓인다.

6. Overflow / UAF into victim

• 이제 공격자는 victim 주위에 공격자 제어 객체들을 가지고 있다.
• 자신의 객체에서 overflow하거나 freed 객체를 재사용함으로써, 공격자는 victim의 메모리 필드를 선택한 값으로 신뢰성 있게 덮어쓸 수 있다.

Why it works:

• Zone allocator의 예측성: 같은 크기의 할당은 항상 같은 zone에서 온다.
• Freelist 동작: 새로운 할당은 가장 최근에 free된 청크를 우선 재사용한다.
• Heap sprays: 공격자가 예측 가능한 내용으로 메모리를 채우고 레이아웃을 제어한다.
• 결과: 공격자는 victim 객체가 어디에 놓일지와 그 옆에 어떤 데이터가 있을지를 제어할 수 있다.

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

Apple은 allocator를 하드닝하여 heap grooming을 훨씬 더 어렵게 만들었다:

1. From Classic kalloc to kalloc_type

• Before: 각 사이즈 클래스(16, 32, 64, … 1280 등)에 대해 단일 kalloc.<size> zone이 존재했다. 그 크기의 어떤 객체든 거기에 배치되었기 때문에 → 공격자 객체가 특권 커널 객체 옆에 놓일 수 있었다.
• Now:
• 커널 객체는 typed zones(kalloc_type)에서 할당된다.
• 각 객체 타입(e.g., ipc_port_t, task_t, OSString, OSData)은 크기가 같더라도 전용 zone을 가진다.
• 객체 타입 ↔ zone 간의 매핑은 컴파일 시 kalloc_type system에서 생성된다.

공격자는 더 이상 제어 데이터(OSData)가 같은 크기의 민감한 커널 객체(task_t) 옆에 반드시 놓일 것이라고 보장할 수 없다.

2. Slabs and Per-CPU Caches

• 힙은 각 zone을 위한 고정 크기 청크로 나뉜 slabs(메모리 페이지들)로 분할된다.
• 각 zone은 경쟁을 줄이기 위해 per-CPU cache를 가진다.
• 할당 경로:

1. per-CPU cache를 시도.
2. 비어 있으면 global freelist에서 가져옴.
3. freelist가 비어 있으면 새로운 slab(하나 이상의 페이지)를 할당.

• 이점: 이 분산화는 할당이 다른 CPU들의 캐시에서 충족될 수 있어 heap sprays를 덜 결정론적으로 만든다.

3. Randomization inside zones

• zone 내에서 freed 요소들이 단순한 FIFO/LIFO 순서로 반환되지 않는다.
• 최신 XNU는 encoded freelist pointers(Linux의 safe-linking과 유사, 약 iOS 14부터 도입)를 사용한다.
• 각 freelist 포인터는 per-zone secret cookie로 XOR 인코딩된다.
• 이는 공격자가 write primitive를 얻더라도 가짜 freelist 포인터를 위조하지 못하게 한다.
• 일부 할당은 slab 내 배치가 무작위화되어 스프레이가 인접성을 보장하지 못한다.

4. Guarded Allocations

• 특정 중요한 커널 객체(e.g., credentials, task structures)는 guarded zones에 할당된다.
• 이러한 zone은 slab 사이에 guard pages(언매핑된 메모리)를 삽입하거나 객체 주변에 redzones를 사용한다.
• guard page로의 어떤 overflow도 즉시 fault를 일으켜 → 무음의 손상 대신 즉시 panic을 유발한다.

5. Page Protection Layer (PPL) and SPTM

• 설령 freed 객체를 제어하더라도 모든 커널 메모리를 수정할 수 있는 것은 아니다:
• **PPL (Page Protection Layer)**는 특정 영역(e.g., code signing 데이터, entitlements)이 커널 자체에도 read-only로 강제되도록 한다.
• A15/M2+ 장치에서는 이 역할이 SPTM (Secure Page Table Monitor) + **TXM (Trusted Execution Monitor)**로 대체/강화된다.
• 이러한 하드웨어 강제 계층은 공격자가 단일 힙 손상에서 중요한 보안 구조를 임의로 패치할 수 없게 만든다.
• (Added / Enhanced): 또한 커널에서는 포인터(특히 함수 포인터, vtables)를 보호하기 위해 **PAC (Pointer Authentication Codes)**를 사용하여 위조나 손상이 더 어려워졌다.
• (Added / Enhanced): zones는 zone_require / zone enforcement를 시행할 수 있다. 즉, free된 객체는 올바른 typed zone을 통해서만 반환되어야 하며, 잘못된 cross-zone free는 panic되거나 거부될 수 있다. (Apple은 메모리 안전 관련 포스트에서 이를 언급한다)

6. Large Allocations

• 모든 할당이 kalloc_type을 통하지는 않는다.
• 매우 큰 요청(대략 ~16 KB 이상)은 typed zones를 우회하고 페이지 할당을 통해 **kernel VM (kmem)**에서 직접 서비스된다.
• 이러한 할당은 덜 예측 가능하지만, 다른 객체들과 slab를 공유하지 않기 때문에 exploitable 가능성도 낮다.

7. Allocation Patterns Attackers Target

이러한 보호가 있어도 공격자들이 여전히 노리는 것들:

• Reference count objects: retain/release 카운터를 조작할 수 있다면 use-after-free를 유발할 수 있다.
• Objects with function pointers (vtables): 이를 손상시키면 여전히 제어 흐름을 얻을 수 있다.
• Shared memory objects (IOSurface, Mach ports): 이들은 user ↔ kernel을 연결하므로 여전히 공격 대상이다.

하지만 — 과거와 달리 — 단순히 OSData를 스프레이해서 task_t 옆에 놓이길 기대할 수는 없다. 성공하려면 type-specific bugs나 **정보 누출(info leaks)**이 필요하다.

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)

최근 Apple OS 버전(특히 iOS 17+)에서 Apple은 사용자 공간 allocator인 xzone malloc(XZM)을 도입했다. 이는 커널의 kalloc_type에 대응하는 사용자 공간 아날로그로, 타입 인식, 메타데이터 분리, 메모리 태깅 완화 기능을 적용한다.

Goals & Design Principles

• Type segregation / type awareness: 타입 또는 사용(포인터 대 데이터)별로 할당을 그룹화하여 타입 혼동과 교차 타입 재사용을 방지.
• Metadata isolation: 힙 메타데이터(e.g. free lists, size/state 비트)를 객체 페이로드와 분리하여 OOB 쓰기가 메타데이터를 손상시키기 어렵게 함.
• Guard pages / redzones: 언매핑된 페이지나 패딩을 삽입하여 오버플로우를 포착.
• Memory tagging (EMTE / MIE): 하드웨어 태깅과 함께 작동하여 use-after-free, OOB, 잘못된 접근을 탐지.
• Scalable performance: 낮은 오버헤드 유지, 과도한 단편화 회피, 초당 많은 할당을 낮은 지연으로 지원.

Architecture & Components

아래는 xzone allocator의 주요 요소들이다:

Segment Groups & Zones

• Segment groups는 주소 공간을 사용 카테고리별로 분할: 예) data, pointer_xzones, data_large, pointer_large.
• 각 segment group은 해당 카테고리의 할당을 호스팅하는 segments(VM 범위)를 포함한다.
• 각 segment와 연관된 metadata slab(별도의 VM 영역)가 있어 해당 segment의 메타데이터(e.g. free/used 비트, size classes)를 저장한다. 이 out-of-line (OOL) metadata는 메타데이터가 객체 페이로드와 섞이지 않도록 하여 오버플로우로 인한 손상을 완화한다.
• Segments는 chunks(슬라이스)로 쪼개지고, 각 chunk는 다시 blocks(할당 단위)로 세분화된다. 하나의 chunk는 특정 사이즈 클래스와 segment group에 묶여 있다(즉, chunk 내부의 모든 block은 같은 크기 & 카테고리).
• 작은/중간 크기 할당에는 고정 크기 chunks를 사용하고, 큰/매우 큰 할당은 별도로 매핑할 수 있다.

Chunks & Blocks

• chunk는 일반적으로 여러 페이지로 구성된, 해당 그룹 내 한 사이즈 클래스를 위한 영역이다.
• chunk 내부에서 blocks는 할당 가능한 슬롯이다. 해제된 블록들은 메타데이터 slab를 통해 추적된다 — 예: 비트맵이나 out-of-line에 저장된 free lists를 통해.
• chunk들 사이(또는 내부)에는 guard slices / guard pages가 삽입될 수 있어 OOB 쓰기를 포착한다.

Type / Type ID

• 모든 할당 지점(또는 malloc, calloc 등 호출)은 어떤 종류의 객체가 할당되는지 인코딩하는 type identifier(malloc_type_id_t)와 연관된다. 이 type ID는 allocator에 전달되어 어떤 zone/segment가 할당을 제공할지 선택한다.
• 따라서 같은 크기의 두 할당이라도 타입이 다르면 완전히 다른 zone에 들어갈 수 있다.
• 초기 iOS 17 버전에서는 모든 API(e.g. CFAllocator)가 완전히 타입 인식적이지 않았고, Apple은 iOS 18에서 일부 약점을 해결했다.

Allocation & Freeing Workflow

다음은 xzone에서 할당 및 해제의 상위 수준 흐름이다:

1. malloc / calloc / realloc / typed alloc이 크기와 type ID와 함께 호출된다.
2. allocator는 type ID를 사용하여 올바른 segment group / zone을 선택한다.
3. 해당 zone/segment 내에서 요청된 크기의 여유 블록을 가진 chunk를 찾는다.

• 로컬 캐시 / per-thread pools 또는 메타데이터의 free block lists를 참조할 수 있다.
• 사용 가능한 블록이 없으면 해당 zone에 새 chunk를 할당할 수 있다.

4. 메타데이터 slab를 업데이트(프리 비트 클리어, 북키핑).
5. 메모리 태깅(EMTE)이 적용되는 경우 반환된 블록에 tag가 할당되고 메타데이터는 그 블록이 “live” 상태임을 반영하도록 업데이트된다.
6. free() 호출 시:

• 블록은 메타데이터에서 해제된 것으로 표시된다(OOL slab 통해).
• 블록은 free list에 들어가거나 재사용을 위해 풀링될 수 있다.
• 선택적으로 블록 내용을 지우거나 poisoning하여 데이터 누출이나 use-after-free 악용을 줄인다.
• 블록과 연관된 하드웨어 태그는 무효화되거나 재태그될 수 있다.
• 전체 chunk가 비게 되면(모든 블록이 해제되면) allocator는 메모리 압력이 있을 때 그 chunk를 회수(언맵하거나 OS에 반환)할 수 있다.

Security Features & Hardening

아래는 modern userland xzone에 내장된 방어책들이다:

Interaction with Memory Integrity Enforcement (MIE / EMTE)

• Apple의 MIE(Memory Integrity Enforcement)는 하드웨어 + OS 프레임워크로, **Enhanced Memory Tagging Extension (EMTE)**를 주요 공격 표면 전반에서 항상-온 동기식 모드로 제공한다.
• xzone allocator는 사용자 공간에서 MIE의 근간이다: xzone을 통해 수행된 할당은 태그를 받고 접근은 하드웨어에 의해 검사된다.
• MIE에서는 allocator, 태그 할당, 메타데이터 관리, 태그 기밀성 강제가 통합되어 메모리 오류(e.g. stale reads, OOB, UAF)가 즉시 포착되어 이후에 악용되지 않도록 한다.

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 바이너리는 장치를 지속적으로 프로파일링하며 연구 환경이 감지되면 kill-chain을 중단합니다. security.mac.amfi.developer_mode_status, diagnosticd 콘솔의 존재, 로케일 US 또는 IL, Cydia 같은 jailbreak 흔적, bash, tcpdump, frida, sshd, checkrain 같은 프로세스, 모바일 AV 앱(McAfee, AvastMobileSecurity, NortonMobileSecurity), 커스텀 HTTP 프록시 설정 및 커스텀 루트 CA를 검사합니다. 어떤 검사라도 실패하면 추가 payload 전달이 차단됩니다.
• Helper surveillance hooks: helper 컴포넌트는 /tmp/helper.sock을 통해 다른 스테이지와 통신한 뒤 DMHooker와 UMHooker라는 훅 세트를 로드합니다. 이 훅은 VOIP 오디오 경로를 가로채며(녹음은 /private/var/tmp/l/voip_%lu_%u_PART.m4a에 저장됨), 시스템 전역 keylogger를 구현하고, UI 없이 사진을 촬영하며, SpringBoard를 훅하여 해당 동작들이 일반적으로 발생시키는 알림을 숨깁니다. 따라서 helper는 Predator 같은 무거운 임플란트를 떨어뜨리기 전에 은밀한 검증 및 경량 감시 레이어로 동작합니다.

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 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.