; 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>예시</summary>
버퍼 오버플로우는 스택의 반환 주소를 덮어쓴다. 공격자는 목표 gadget 주소를 쓰지만 올바른 PAC를 계산하지 못한다. 함수가 반환될 때 CPU의 `AUTIA` 명령은 PAC 불일치로 인해 오류를 발생시킨다. 체인이 실패한다.
Project Zero의 A12 (iPhone XS)에 대한 분석은 Apple의 PAC가 어떻게 사용되는지와 공격자가 메모리 read/write 프리미티브를 가졌을 때 PAC를 위조하는 방법들을 보여주었다.
</details>


### 9. **Branch Target Identification (BTI)**
**Introduced with ARMv8.5 (later hardware)**
BTI는 **간접 분기 대상**을 검사하는 하드웨어 기능이다: `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)을 삽입하여 간접 분기가 오직 그 위치들로만 성공하도록 한다.
- **직접 분기 / 호출**(즉 고정 주소 `B`, `BL`)은 BTI의 제한을 받지 않는다. 가정은 코드 페이지가 신뢰되며 공격자가 이를 변경할 수 없다는 것이므로(따라서 직접 분기는 안전하다).
- 또한, **RET / return** 명령은 일반적으로 PAC나 return signing 메커니즘으로 반환 주소가 보호되기 때문에 BTI의 제한을 받지 않는다.

#### Mechanism and enforcement

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

#### BTI + PAC synergy

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

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

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

#### Example


<details>
<summary>예시</summary>
공격자가 `0xABCDEF`에 있는 gadget으로 피벗하려고 하는데 그 주소가 `BTI c`로 시작하지 않는 경우를 생각해보자. CPU는 `blr x0`을 실행할 때 대상을 확인하고 유효한 landing pad가 없으므로 오류를 발생시킨다. 따라서 많은 gadget이 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), “EL0에서 접근 가능한” 가상 주소에 접근하는 privileged load/store 명령은 권한 오류를 발생시킨다.
- 커널은 합법적으로 user-space 메모리에 접근해야 할 때(예: 사용자 버퍼로/로부터 데이터 복사) **일시적으로 PAN을 비활성화**하거나 “unprivileged load/store” 명령을 사용해야 한다.
- ARM64의 Linux에서는 PAN 지원이 대략 2015년경에 도입되었다: 커널 패치가 기능 감지를 추가하고 `get_user` / `put_user` 등에서 PAN을 해제하는 변형으로 대체했다.

**핵심 뉘앙스 / 제한 / 버그**
- Siguza 등에서 지적한 바와 같이, ARM 설계의 명세 버그(또는 모호한 동작)로 인해 **execute-only user mappings**(`--x`)는 **PAN을 유발하지 않을 수 있다**. 다시 말해, 사용자 페이지가 실행 가능하지만 읽기 권한이 없으면, 커널의 읽기 시도가 PAN을 우회할 수 있다. 아키텍처는 “EL0에서 접근 가능”을 판정할 때 읽기 권한을 요구하지 않고 단지 실행 가능만으로 다루는 경우가 있어 특정 구현에서 PAN 우회가 발생한다.
- 이로 인해, iOS / XNU가 execute-only user 페이지를 허용하면(예: 일부 JIT 또는 코드 캐시 설정), 커널은 PAN이 활성화된 상태에서도 해당 페이지에서 우연히 읽어올 수 있다. 이는 일부 ARMv8+ 시스템에서 알려진 미묘한 exploitable 영역이다.

#### PXN (Privileged eXecute Never)

- **PXN**은 페이지 테이블 플래그(페이지 테이블 엔트리, leaf 또는 block 엔트리)에 있는 비트로, 해당 페이지가 **privileged 모드에서 실행 불가**함을 나타낸다(즉 EL1에서 실행할 수 없음).
- PXN은 커널(또는 어떤 privileged 코드)이 user-space 페이지로 분기하여 그곳에서 명령을 실행하는 것을 방지한다. 결과적으로 커널 수준의 제어 흐름이 사용자 메모리로 리디렉션되는 것을 차단한다.
- PAN과 결합하면:
1. 기본적으로 커널은 사용자 데이터를 읽거나 쓰지 못한다 (PAN)
2. 커널은 사용자 코드를 실행할 수 없다 (PXN)
- ARMv8 페이지 테이블 포맷에서 leaf 엔트리에는 `PXN` 비트(및 unprivileged execute-never인 `UXN`)가 속성 비트로 존재한다.

따라서 가설적으로 커널에 손상된 함수 포인터가 사용자 메모리를 가리키더라도, PXN 비트는 분기 시 오류를 발생시킨다.

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

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

- 각 페이지 또는 블록 엔트리는 읽기/쓰기, privileged vs unprivileged를 위한 **AP[2:1]**와 실행 불가 제한을 위한 **UXN / PXN** 비트 등을 포함하는 속성 필드를 가진다.
- PSTATE.PAN이 1(활성)일 때, 하드웨어는 수정된 의미론을 강화한다: “EL0에서 접근 가능한”으로 표시된 페이지에 대한 privileged 접근은 금지되고(오류 발생) 차단된다.
- 앞서 언급한 버그 때문에, 읽기 권한 없이 실행만 가능한 페이지는 특정 구현에서 “EL0에서 접근 가능한”으로 간주되지 않아 PAN을 우회할 수 있다.
- 페이지의 PXN 비트가 설정되면, 더 높은 권한 레벨에서 온 명령 페치라도 실행이 금지된다.

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

강화된 커널 설계(예: Apple이 사용할 수 있는 설계)에서는:

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

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

#### Attack surfaces, bypasses, and mitigations

- **execute-only 페이지를 통한 PAN 우회**: 앞서 논의했듯, 명세의 허점으로 인해 읽기 권한이 없는 execute-only 사용자 페이지는 일부 구현에서 “EL0에서 접근 가능”으로 간주되지 않아 PAN이 차단하지 못할 수 있다. 이는 공격자에게 “execute-only” 섹션을 통해 데이터를 주입할 비정상적인 경로를 제공한다.
- **일시적 윈도우 익스플로잇**: 커널이 PAN을 필요 이상으로 오래 비활성화하면, 레이스나 악의적 경로가 그 창을 이용해 의도치 않은 사용자 메모리 접근을 수행할 수 있다.
- **재활성화 누락**: 코드 경로가 PAN을 다시 활성화하는 것을 잊으면, 이후의 커널 작업이 잘못해서 사용자 메모리에 접근할 수 있다.
- **PXN의 잘못된 구성**: 페이지 테이블이 사용자 페이지에 PXN을 설정하지 않거나 사용자 코드 페이지를 잘못 매핑하면, 커널이 사용자 공간 코드를 실행하도록 속을 수 있다.
- **추측 실행 / 사이드채널**: 추측 실행 우회와 유사하게, 마이크로아키텍처적 부작용이 PAN / PXN 검사에서 일시적 위반을 초래할 수 있다(다만 이런 공격은 CPU 설계에 크게 의존한다).
- **복잡한 상호작용**: JIT, shared memory, just-in-time code regions 같은 고급 기능에서는 커널이 특정 메모리 접근이나 사용자 매핑 영역에서의 실행을 허용할 필요가 있으며, PAN/PXN 제약 하에서 이를 안전하게 설계하는 것은 비자명하다.

#### Example

<details>
<summary>코드 예시</summary>
다음은 사용자 메모리 접근 주위에서 PAN을 활성/비활성화하는 것을 보여주는 설명적 의사-어셈블리 시퀀스와 오류가 발생할 수 있는 방법들이다.
</details>

// 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 **not** set 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 **not** fault even with PAN enabled, enabling a bypass exploit, depending on implementation.

</details>

<details>
<summary>예시</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: 사용 사례 및 동기

- **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>예시</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>코드 예제</summary>
Here’s a simplified pseudocode / logic showing how a kernel might call into PPL to modify protected pages:
</details>
```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 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**: 일부 메모리는 비태그(레거시)로 남아 있을 수 있어 상호운용성이 복잡해집니다.
- **Speculative / transient attacks**: 많은 마이크로아키텍처 보호와 마찬가지로, speculative execution이나 micro-op fusion이 검사를 일시적으로 우회하거나 태그 비트를 누출할 가능성이 있습니다.
- **Limited to supported regions**: Apple은 EMTE를 커널이나 보안 핵심 서브시스템 등 선택된 고위험 영역에만 적용할 수 있으며, 전역적으로 강제하지 않을 수 있습니다.

---

## Key enhancements / differences compared to standard MTE

Here are the improvements and changes Apple emphasizes:

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

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

---

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

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

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

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

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

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

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

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

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

---

## Exception handling in XNU

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

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


### Exception Flow (High-Level)

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

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

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

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

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

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

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

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

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

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


### Core Function: `exception_triage()`

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

일반적인 호출 흐름:

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

모두 실패하면 → bsd_exception()에서 처리되어 → SIGSEGV 같은 시그널로 변환된다.

예외 포트

각 Mach 객체(thread, task, host)는 예외 메시지가 전송되는 exception ports를 등록할 수 있다.

They are defined by the API:

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

각 예외 포트는 다음을 가진다:

• mask (어떤 예외를 받고 싶은지)
• port name (메시지를 받을 Mach 포트)
• behavior (커널이 메시지를 보내는 방식)
• flavor (어떤 스레드 상태를 포함할지)

디버거와 예외 처리

debugger(예: LLDB)는 대상 task 또는 thread에 exception port를 설정하며, 보통 task_set_exception_ports()를 사용한다.

예외가 발생하면:

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

EXC_BAD_ACCESS의 흐름

1. 스레드가 잘못된 포인터를 역참조 → CPU가 Data Abort를 발생시킨다.

2. 커널 트랩 핸들러가 exception_triage(EXC_BAD_ACCESS, ...)를 호출한다.

3. 메시지가 전송된다:

• Thread 포트 → (디버거가 브레이크포인트를 가로챌 수 있음).

• 디버거가 무시하면 → Task 포트 → (프로세스 수준 핸들러).

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

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

PAC 예외

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

• EXC_ARM_PAC (타입)
• 코드에는 세부사항이 포함될 수 있음(예: 키 타입, 포인터 타입).

바이너리에 플래그 **TFRO_PAC_EXC_FATAL**가 설정되어 있으면, 커널은 PAC 실패를 치명적(fatal) 으로 처리하여 디버거 인터셉션을 우회한다. 이는 공격자가 디버거를 이용해 PAC 체크를 우회하는 것을 방지하기 위한 것으로 platform binaries에 대해 활성화된다.

Software Breakpoints

소프트웨어 브레이크포인트(int3 on x86, brk on ARM64)는 고의적인 폴트를 발생시키는 방식으로 구현된다.
디버거는 exception port를 통해 이를 포착한다:

• 명령 포인터 또는 메모리를 수정한다.
• 원래 명령을 복원한다.
• 실행을 재개한다.

이 동일한 메커니즘으로 PAC 예외를 “잡을” 수 있다 — **단, 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 → 저수준 트랩 핸들러.

• osfmk/mach/exc.h → 예외 코드와 구조체.

• osfmk/kern/task.c → Task 예외 포트 설정.

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

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

From the screenshot:

작동 방식:

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

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

프리리스트

각 kalloc 존 내부에서, 해제된 객체들은 시스템으로 바로 반환되지 않고 사용 가능한 청크들의 연결 리스트인 프리리스트로 들어갔다.

• 청크가 해제되면, 커널은 그 청크의 시작 부분에 포인터를 썼다 → 동일한 존의 다음 자유 청크의 주소를 가리킴.

• 존은 첫 번째 자유 청크를 가리키는 HEAD 포인터를 유지했다.

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

1. HEAD를 팝(해당 메모리를 호출자에게 반환).

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

• 해제는 청크를 프리리스트에 다시 푸시했다:

• freed_chunk->next = HEAD

• HEAD = freed_chunk

따라서 프리리스트는 해제된 메모리 자체 내부에 구축된 단순한 연결 리스트였다.

정상 상태:

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

1. Heap overflow로 인접한 freed chunk에 침투 → 그 “next” pointer를 덮어쓴다.

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

Then, on the next allocation of that size:

• allocator는 손상된 chunk를 꺼낸다.

• 공격자가 제공한 “next” pointer를 따른다.

• arbitrary memory를 가리키는 포인터를 반환하여 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 디자인은 하드닝 이전에 익스플로잇을 매우 효과적으로 만들었습니다: heap sprays로 인한 예측 가능한 이웃, raw pointer freelist 링크, 그리고 타입 분리가 없어서 공격자가 UAF/overflow 버그를 임의의 kernel memory 제어로 확대할 수 있었습니다.

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.
그렇게 함으로써 메모리 손상이 발생했을 때 공격자는 제어된 데이터로 victim 객체를 신뢰성 있게 덮어쓸 수 있습니다.

단계:

1. Spray allocations (fill the holes)

• 시간이 지나면 kernel heap은 단편화됩니다: 이전에 해제된 객체들 때문에 어떤 zone에는 구멍들이 생깁니다.
• 공격자는 먼저 많은 더미 할당을 해서 이 구멍들을 채워 힙을 “빽빽하게(packed)” 만들어 예측 가능하게 만듭니다.

2. Force new pages

• 구멍들이 채워지면 다음 할당은 zone에 새로 추가된 페이지에서 나오게 됩니다.
• 새 페이지는 객체들이 흩어져 있지 않고 한곳에 모이게 합니다.
• 이는 공격자가 이웃 제어를 훨씬 더 잘 하게 해줍니다.

3. Place attacker objects

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

4. Free a controlled object (make a gap)

• 공격자는 의도적으로 자신의 객체 중 하나를 해제합니다.
• 이렇게 하면 allocator가 동일한 크기의 다음 할당에 재사용할 “구멍”이 생성됩니다.

5. Victim object lands in the hole

• 공격자는 커널이 victim 객체(손상시키려는 객체)를 할당하도록 유도합니다.
• 그 구멍이 freelist에서 첫 번째 사용 가능한 슬롯이므로 victim은 공격자가 해제한 정확한 위치에 배치됩니다.

6. Overflow / UAF into victim

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

작동 원인:

• Zone allocator의 예측성: 같은 크기의 할당은 항상 같은 zone에서 나옵니다.
• Freelist 동작: 새 할당은 가장 최근에 해제된 청크를 먼저 재사용합니다.
• 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)에서 할당됩니다.
• ipc_port_t, task_t, OSString, OSData 등 각 객체 타입은 크기가 같더라도 자체 전용 zone을 가집니다.
• 객체 타입 ↔ zone 매핑은 컴파일 시 kalloc_type system으로 생성됩니다.

공격자는 이제 제어된 데이터(OSData)가 동일 크기의 민감한 커널 객체(task_t) 옆에 반드시 놓이도록 보장할 수 없습니다.

2. Slabs and Per-CPU Caches

• 힙은 slabs(해당 zone을 위해 고정 크기 청크로 잘라진 페이지)로 나뉩니다.
• 각 zone은 경쟁을 줄이기 위해 per-CPU cache를 가집니다.
• 할당 경로:

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

• 이점: 이러한 분산은 할당이 서로 다른 CPU의 캐시에서 충족될 수 있으므로 heap sprays의 결정론성을 낮춥니다.

3. Randomization inside zones

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

4. Guarded Allocations

• 특정 중요한 커널 객체(예: credentials, task 구조체)는 guarded zones에서 할당됩니다.
• 이러한 zone들은 slab 사이에 guard pages(맵되지 않은 메모리)를 삽입하거나 객체 주위에 redzones를 사용합니다.
• guard page로의 overflow는 fault를 유발 → 즉시 panic(정지)을 발생시키며 조용한 손상을 방지합니다.

5. Page Protection Layer (PPL) and SPTM

• 해제된 객체를 제어하더라도 모든 커널 메모리를 수정할 수는 없습니다:
• **PPL (Page Protection Layer)**은 특정 영역(예: code signing 데이터, entitlements)이 커널 자체에서도 read-only로 강제되게 합니다.
• A15/M2+ 기기에서는 이 역할이 SPTM (Secure Page Table Monitor) + **TXM (Trusted Execution Monitor)**로 대체/강화됩니다.
• 이러한 하드웨어 강제 레이어는 공격자가 단일 힙 손상에서 중요한 보안 구조의 임의 패치로 상승하는 것을 어렵게 만듭니다.
• (추가/강화): 또한 커널은 포인터(특히 함수 포인터, vtables)를 보호하기 위해 **PAC (Pointer Authentication Codes)**를 사용하여 이를 위조하거나 손상시키기 어렵게 합니다.
• (추가/강화): zones는 zone_require / zone enforcement를 시행할 수 있어, 잘못된 cross-zone free는 panic을 일으키거나 거부될 수 있습니다. (Apple은 이 점을 메모리 안전성 관련 게시물에서 암시합니다)

6. Large Allocations

• 모든 할당이 kalloc_type을 통하지는 않습니다.
• 매우 큰 요청(대략 16 KB 이상)은 typed zones를 우회하고 페이지 할당을 통해 **kernel VM (kmem)**에서 직접 제공됩니다.
• 이런 할당은 덜 예측 가능하지만, 다른 객체와 slab를 공유하지 않기 때문에 익스플로잇 가능성도 낮습니다.

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 옆에 오게 할 수는 없습니다. 성공하려면 타입별 버그나 **정보 누출(info leak)**이 필요합니다.

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: *타입 또는 용도(포인터 대 데이터)*별로 할당을 그룹화하여 타입 혼동(type confusion)과 크로스-타입 재사용을 방지.
• Metadata isolation: 힙 메타데이터(예: 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에는 해당 segment의 메타데이터(예: free/used 비트, 사이즈 클래스)를 저장하는 metadata slab(별도의 VM 영역)가 연결됩니다. 이 out-of-line (OOL) metadata는 메타데이터가 객체 페이로드와 섞이지 않도록 하여 오버플로우로 인한 손상을 완화합니다.
• Segments는 chunks(슬라이스)로 잘려지며, 각 chunk는 다시 blocks(할당 단위)로 세분화됩니다. 하나의 chunk는 특정 사이즈 클래스와 segment group에 묶입니다(즉 해당 chunk의 모든 block은 동일한 크기와 카테고리를 공유).
• 작은/중간 크기 할당에는 고정 크기 chunks를 사용하고, 큰/거대한 할당은 별도로 매핑할 수 있습니다.

Chunks & Blocks

• chunk는 특정 그룹 내에서 하나의 사이즈 클래스를 위해 전용된 영역(종종 여러 페이지)입니다.
• chunk 내부의 blocks는 할당 가능한 슬롯입니다. 해제된 block은 metadata slab(예: 비트맵 또는 out-of-line free list)를 통해 추적됩니다.
• 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(예: 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 내에서 요청한 크기의 free blocks가 있는 chunk를 찾습니다.

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

4. metadata slab가 업데이트됩니다(free 비트 클리어, 회계 처리).
5. 메모리 태깅(EMTE)이 적용되는 경우 반환된 block에 tag가 할당되고 metadata는 해당 블록이 “라이브” 상태임을 반영하도록 업데이트됩니다.
6. free() 호출 시:

• block은 metadata에서 해제 상태로 표시됩니다(OOL slab 통해).
• block은 재사용을 위해 free list에 놓이거나 풀에 보관될 수 있습니다.
• 선택적으로 데이터 유출이나 use-after-free 악용을 줄이기 위해 블록 내용을 지우거나 poison 처리할 수 있습니다.
• 블록과 연관된 하드웨어 태그는 무효화되거나 재태깅될 수 있습니다.
• 전체 chunk가 비어 있으면(모든 block이 해제) allocator는 메모리 압박 하에서 해당 chunk를 회수(언맵하거나 OS로 반환) 할 수 있습니다.

Security Features & Hardening

다음은 현대 유저랜드 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, 태그 할당, metadata 관리, 태그 기밀성 강화는 통합되어 메모리 오류(예: 오래된 참조, 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 바이너리가 장치를 지속적으로 프로파일링하며 리서치 환경이 감지되면 킬체인을 중단합니다. 이 바이너리는 security.mac.amfi.developer_mode_status, diagnosticd 콘솔의 존재, 로케일 US 또는 IL, 탈옥 흔적(예: Cydia), bash, tcpdump, frida, sshd, checkrain 같은 프로세스, 모바일 AV 앱(McAfee, AvastMobileSecurity, NortonMobileSecurity), 사용자 지정 HTTP 프록시 설정 및 사용자 지정 루트 CA를 검사합니다. 어떤 검사라도 실패하면 추가 페이로드 전달이 차단됩니다.
• Helper surveillance hooks: helper 컴포넌트는 다른 단계와 /tmp/helper.sock을 통해 통신한 뒤 DMHooker 및 UMHooker라는 훅 세트를 로드합니다. 이 훅들은 VOIP 오디오 경로를 가로채며(녹음은 /private/var/tmp/l/voip_%lu_%u_PART.m4a에 저장됨), 시스템 전체 키로거를 구현하고 UI 없이 사진을 촬영하며, 이러한 동작이 보통 발생시킬 알림을 억제하기 위해 SpringBoard에 훅을 겁니다. 따라서 helper는 Predator와 같은 더 무거운 임플란트를 배포하기 전에 은밀한 검증 및 경량 감시 계층으로 작동합니다.

iMessage/Media Parser Zero-Click Chains

Imessage Media Parser Zero Click Coreaudio Pac Bypass

References

• 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을 제출하여 해킹 트릭을 공유하세요.