; 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>
A buffer overflow overwrites a return address on the stack. The attacker writes the target gadget address but cannot compute the correct PAC. When the function returns, the CPU’s `AUTIA` instruction faults because the PAC mismatch. The chain fails.
Project Zero’s analysis on A12 (iPhone XS) showed how Apple’s PAC is used and methods of forging PACs if an attacker has a memory read/write primitive.
</details>


### 9. **Identificazione del Branch Target (BTI)**
**Introdotto con ARMv8.5 (hardware più recente)**
BTI è una funzionalità hardware che controlla i **target di branch indiretti**: quando si eseguono `blr` o chiamate/salti indiretti, il target deve iniziare con un **BTI landing pad** (`BTI j` o `BTI c`). Saltare verso indirizzi di gadget che non hanno il landing pad provoca un'eccezione.

Le note di implementazione di LLVM descrivono tre varianti di istruzioni BTI e come si mappano ai tipi di branch.

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

- Nel codice compilato con branch target enforcement, i compiler inseriscono un'istruzione BTI (C, J o JC) in ogni valido target di branch indiretto (inizio di funzioni o blocchi raggiungibili tramite salti) in modo che i branch indiretti abbiano successo solo verso quei punti.
- **I branch / call diretti** (ossia gli indirizzi fissi `B`, `BL`) **non sono limitati** da BTI. L'assunzione è che le pagine di codice siano trusted e che un attacker non possa modificarle (quindi i direct branch sono considerati sicuri).
- Inoltre, le istruzioni **RET / return** generalmente non sono soggette a BTI perché gli indirizzi di ritorno sono protetti tramite PAC o meccanismi di return signing.

#### Meccanismo e enforcement

- Quando la CPU decodifica un **indirect branch (BLR / BR)** in una pagina marcata come “guarded / BTI-enabled”, verifica se la prima istruzione dell'indirizzo di destinazione è un BTI valido (C, J o JC a seconda di quanto permesso). Se non lo è, si verifica una **Branch Target Exception**.
- L'encoding delle istruzioni BTI è progettato per riutilizzare opcode precedentemente riservati per NOP (nelle versioni ARM precedenti). Quindi i binari BTI-enabled rimangono backward-compatible: sull'hardware senza supporto BTI quelle istruzioni agiscono come NOP.
- I passaggi del compiler che aggiungono BTI le inseriscono solo dove necessario: funzioni che possono essere chiamate indirettamente, o blocchi base target di salti.
- Alcune patch e codice LLVM mostrano che BTI non viene inserito per *tutti* i basic block — solo per quelli che sono potenziali target di branch (per esempio da switch / jump table).

#### Sinergia BTI + PAC

PAC protegge il valore del puntatore (la sorgente) — assicura che la catena di chiamate/ritorni indiretti non sia stata manomessa.

BTI assicura che anche un puntatore valido debba puntare solo a entry point opportunamente marcati.

Combinati, un attacker ha bisogno sia di un puntatore valido con PAC corretto sia che il target abbia un BTI posizionato lì. Questo aumenta la difficoltà nel costruire gadget per exploit.

#### Example


<details>
<summary>Example</summary>
An exploit tries to pivot into gadget at `0xABCDEF` that doesn’t start with `BTI c`. The CPU, upon executing `blr x0`, checks the target and faults because the instruction alignment doesn’t include a valid landing pad. Thus many gadgets become unusable unless they include BTI prefix.
</details>


### 10. **Privileged Access Never (PAN) & Privileged Execute Never (PXN)**
**Introdotto in estensioni ARMv8 più recenti / supporto iOS (per kernel hardened)**

#### PAN (Privileged Access Never)

- **PAN** è una funzionalità introdotta in **ARMv8.1-A** che impedisce al **codice privilegiato** (EL1 o EL2) di **leggere o scrivere** memoria marcata come **user-accessible (EL0)**, a meno che PAN non sia disabilitato esplicitamente.
- L'idea: anche se il kernel viene ingannato o compromesso, non può dereferenziare arbitrariamente puntatori user-space senza prima *disabilitare* PAN, riducendo così i rischi di exploit in stile **ret2usr** o l'abuso di buffer controllati dall'utente.
- Quando PAN è abilitato (PSTATE.PAN = 1), qualsiasi istruzione privilegiata di load/store che accede a un indirizzo virtuale “accessible at EL0” provoca un **permission fault**.
- Il kernel, quando deve legittimamente accedere alla memoria user-space (es. copiare dati da/a buffer utente), deve **disabilitare temporaneamente PAN** (o usare istruzioni di “unprivileged load/store”) per consentire quell'accesso.
- In Linux su ARM64, il supporto PAN è stato introdotto intorno al 2015: patch del kernel hanno aggiunto il rilevamento della feature e hanno sostituito `get_user` / `put_user` ecc. con varianti che puliscono PAN attorno agli accessi alla memoria utente.

**Sottigliezza / limitazione / bug**
- Come notato da Siguza e altri, un bug di specifica (o comportamento ambiguo) nel design ARM fa sì che le mappature user execute-only (`--x`) possano **non innescare PAN**. In altre parole, se una pagina user è marcata eseguibile ma senza permesso di lettura, il tentativo del kernel di leggere potrebbe bypassare PAN perché l'architettura considera “accessible at EL0” come richiesta di permesso di lettura, non solo di esecuzione. Questo porta a un bypass di PAN in alcune configurazioni.
- Per questo motivo, se iOS / XNU permettono pagine user execute-only (come in alcuni setup JIT o code-cache), il kernel potrebbe leggere accidentalmente da esse anche con PAN abilitato. Questa è un'area sottile nota per essere potenzialmente sfruttabile in alcuni sistemi ARMv8+.

#### PXN (Privileged eXecute Never)

- **PXN** è un flag della page table (nelle voci di page table, leaf o block entries) che indica che la pagina è **non eseguibile quando si esegue in privileged mode** (cioè quando EL1 esegue).
- PXN impedisce al kernel (o a qualunque codice privilegiato) di saltare o eseguire istruzioni da pagine user-space anche se il controllo viene dirottato. In pratica, impedisce l'esecuzione di codice user-space dal contesto kernel.
- Combinato con PAN, questo assicura che:
1. Il kernel non possa (di default) leggere o scrivere dati user-space (PAN)
2. Il kernel non possa eseguire codice user-space (PXN)
- Nel formato di page table ARMv8, le voci leaf hanno un bit `PXN` (e anche `UXN` per unprivileged execute-never) nei loro bit di attributo.

Quindi anche se il kernel ha un puntatore a funzione corrotto che punta a memoria user, e tenta di fare branch lì, il bit PXN causerebbe un fault.

#### Modello di permessi della memoria & come PAN e PXN si mappano ai bit di page table

Per capire come PAN / PXN funzionano, bisogna vedere come funziona la traduzione e il modello di permessi ARM (semplificato):

- Ogni entry di pagina o block ha campi attributo inclusi **AP[2:1]** per i permessi di accesso (read/write, privileged vs unprivileged) e bit **UXN / PXN** per restrizioni execute-never.
- Quando PSTATE.PAN è 1 (abilitato), l'hardware applica semantiche modificate: gli accessi privilegiati alle pagine marcate come “accessible by EL0” (cioè user-accessible) sono disabilitati (fault).
- A causa del bug menzionato, pagine marcate solo eseguibili (nessun permesso di lettura) potrebbero non essere considerate “accessible by EL0” in alcune implementazioni, bypassando così PAN.
- Quando il bit PXN di una pagina è impostato, anche se l'instruction fetch proviene da un livello di privilegio superiore, l'esecuzione è proibita.

#### Uso del kernel di PAN / PXN in un OS hardenizzato (es. iOS / XNU)

In un design di kernel hardenizzato (come quello che Apple potrebbe usare):

- Il kernel abilita PAN di default (quindi il codice privilegiato è vincolato).
- Nei percorsi che legittimamente devono leggere o scrivere buffer utente (es. syscall copy, I/O, read/write user pointer), il kernel disabilita temporaneamente **PAN** o usa istruzioni speciali per sovrascriverlo.
- Dopo aver finito l'accesso ai dati utente, deve riabilitare PAN.
- PXN è applicato tramite page table: le pagine utente hanno PXN = 1 (quindi il kernel non può eseguirle), le pagine kernel non hanno PXN (quindi il codice kernel può essere eseguito).
- Il kernel deve assicurarsi che nessun path di codice permetta il flusso di esecuzione verso regioni di memoria user (che aggirerebbero PXN) — quindi le catene di exploit che si basano su “jump into user-controlled shellcode” sono bloccate.

A causa del bypass PAN tramite pagine execute-only, in un sistema reale Apple potrebbe disabilitare o vietare pagine user execute-only, o correggere la debolezza della specifica.

#### Superfici di attacco, bypass e mitigazioni

- **PAN bypass via execute-only pages**: come discusso, la spec lascia un gap: pagine user con execute-only (nessun permesso di lettura) potrebbero non essere considerate “accessible at EL0,” quindi PAN non bloccherebbe letture kernel da tali pagine in alcune implementazioni. Questo dà all'attacker una via insolita per fornire dati tramite sezioni “execute-only”.
- **Exploit della finestra temporale**: se il kernel disabilita PAN per una finestra più lunga del necessario, una race o un percorso maligno potrebbe sfruttare quella finestra per effettuare accessi involontari alla memoria user.
- **Dimenticanza di riabilitazione**: se i percorsi di codice non riabilitano PAN, operazioni kernel successive potrebbero accedere erroneamente alla memoria user.
- **Misconfigurazione di PXN**: se le page table non impostano PXN sulle pagine user o mappano in modo errato le pagine di codice user, il kernel potrebbe essere ingannato nell'eseguire codice user-space.
- **Speculation / side-channels**: analogamente ai bypass speculativi, possono esistere effetti microarchitetturali transitori che causano violazioni temporanee dei controlli PAN / PXN (anche se tali attacchi dipendono molto dal design della CPU).
- **Interazioni complesse**: in funzionalità più avanzate (es. JIT, shared memory, code region just-in-time), il kernel potrebbe aver bisogno di controllo fine per permettere certi accessi memoria o esecuzioni in regioni mappate user; progettare questi percorsi in sicurezza sotto i vincoli PAN/PXN non è banale.

#### Example

<details>
<summary>Code Example</summary>
Here are illustrative pseudo-assembly sequences showing enabling/disabling PAN around user memory access, and how a fault might occur.
</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

Se il kernel avesse **non** impostato PXN su quella pagina user, allora il branch potrebbe avere successo — il che sarebbe insicuro.

Se il kernel si dimentica di riabilitare PAN dopo l'accesso alla memoria user, si apre una finestra in cui ulteriore logica del kernel potrebbe accidentalmente leggere/scrivere memoria user arbitraria.

Se il puntatore user punta a una pagina execute-only (pagina user con solo permesso di esecuzione, senza read/write), a causa di un bug nella specifica PAN, `ldr W2, [X1]` potrebbe **non** generare fault anche con PAN abilitato, permettendo un exploit di bypass, a seconda dell'implementazione.

</details>

<details>
<summary>Example</summary>
Una vulnerabilità del kernel prova a prendere un function pointer fornito dall'user e chiamarlo in contesto kernel (i.e. `call user_buffer`). Sotto PAN/PXN, quell'operazione è disabilitata o genera fault.
</details>

---

### 11. **Top Byte Ignore (TBI) / Pointer Tagging**
**Introdotto in ARMv8.5 / versioni più recenti (o estensione opzionale)**
TBI significa che il top byte (most-significant byte) di un puntatore a 64 bit è ignorato dalla traduzione degli indirizzi. Questo permette all'OS o all'hardware di incorporare **tag bits** nel top byte del puntatore senza influenzare l'indirizzo effettivo.

- TBI sta per **Top Byte Ignore** (talvolta chiamato *Address Tagging*). È una feature hardware (disponibile in molte implementazioni ARMv8+) che **ignora gli 8 bit più alti** (bit 63:56) di un puntatore a 64 bit quando esegue la **traduzione degli indirizzi / load/store / instruction fetch**.
- Di fatto, la CPU tratta un puntatore `0xTTxxxx_xxxx_xxxx` (dove `TT` = top byte) come `0x00xxxx_xxxx_xxxx` ai fini della traduzione degli indirizzi, ignorando (mascherando) il top byte. Il top byte può essere usato dal software per memorizzare **metadata / tag bits**.
- Questo fornisce al software uno spazio in-band “gratuito” per inserire un byte di tag in ogni puntatore senza modificare la locazione di memoria a cui fa riferimento.
- L'architettura garantisce che load, store e instruction fetch trattino il puntatore con il top byte mascherato (cioè tag rimosso) prima di effettuare l'accesso alla memoria.

Quindi TBI disaccoppia il **logical pointer** (pointer + tag) dall'**indirizzo fisico** usato per le operazioni di memoria.

#### Why TBI: Use cases and motivation

- **Pointer tagging / metadata**: Puoi memorizzare metadata aggiuntivi (es. object type, version, bounds, integrity tags) in quel top byte. Quando poi usi il puntatore, il tag è ignorato a livello hardware, quindi non è necessario rimuoverlo manualmente per l'accesso in memoria.
- **Memory tagging / MTE (Memory Tagging Extension)**: TBI è il meccanismo hardware di base su cui MTE si costruisce. In ARMv8.5, la **Memory Tagging Extension** usa i bit 59:56 del puntatore come una **logical tag** e li confronta con un **allocation tag** memorizzato in memoria.
- **Enhanced security & integrity**: Combinando TBI con pointer authentication (PAC) o controlli runtime, puoi forzare non solo il valore del puntatore ma anche che il tag sia corretto. Un attacker che sovrascrive un puntatore senza il tag corretto produrrà un tag non corrispondente.
- **Compatibility**: Poiché TBI è opzionale e i tag bits sono ignorati dall'hardware, il codice esistente senza tag continua a operare normalmente. I tag bits diventano effettivamente bit “don't care” per il codice legacy.

#### Example
<details>
<summary>Example</summary>
Un function pointer includeva un tag nel suo top byte (es. `0xAA`). Un exploit sovrascrive i bit bassi del puntatore ma trascura il tag, quindi quando il kernel verifica o sanifica, il puntatore fallisce o viene rifiutato.
</details>

---

### 12. **Page Protection Layer (PPL)**
**Introdotto in iOS recenti / hardware moderno (iOS ~17 / Apple silicon / modelli high-end)** (alcuni report mostrano PPL su macOS / Apple silicon, ma Apple sta portando protezioni analoghe su iOS)

- PPL è progettato come un **intra-kernel protection boundary**: anche se il kernel (EL1) è compromesso e ha capacità di read/write, **non dovrebbe essere in grado di modificare liberamente** certe **pagine sensibili** (soprattutto page tables, code-signing metadata, kernel code pages, entitlements, trust caches, ecc.).
- Effettivamente crea un “kernel within the kernel” — un componente più piccolo e trusted (PPL) con **privilegi elevati** che solo lui può usare per modificare pagine protette. Altro codice kernel deve chiamare le routine PPL per effettuare modifiche.
- Questo riduce la superficie d'attacco per exploit del kernel: anche con pieno arbitrario R/W/execute in kernel mode, il codice exploit deve in qualche modo entrare nel dominio PPL (o bypassare PPL) per modificare strutture critiche.
- Su Apple silicon più recenti (A15+ / M2+), Apple sta migrando verso **SPTM (Secure Page Table Monitor)**, che in molti casi sostituisce PPL per la protezione delle page-table su quelle piattaforme.

Ecco come si ritiene che PPL operi, basandosi su analisi pubbliche:

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

- L'hardware Apple usa un meccanismo chiamato **APRR (Access Permission ReRouting)**, che permette alle page table entries (PTEs) di contenere piccoli indici, invece dei full permission bits. Quegli indici sono mappati tramite registri APRR alle permission effettive. Questo permette il remapping dinamico delle permission per dominio.
- PPL sfrutta APRR per segregare i privilegi all'interno del contesto kernel: solo il dominio PPL è autorizzato ad aggiornare la mappatura tra indici e permission effettive. Cioè, quando codice kernel non-PPL scrive una PTE o prova a modificare i permission bits, la logica APRR lo disabilita (o impone una mappatura read-only).
- Il codice PPL stesso gira in una regione ristretta (es. `__PPLTEXT`) che normalmente è non-executable o non-writable fino a quando entry gates non lo consentono temporaneamente. Il kernel chiama i punti di ingresso PPL (“PPL routines”) per eseguire operazioni sensibili.

#### Gate / Entry & Exit

- Quando il kernel ha bisogno di modificare una pagina protetta (es. cambiare i permission di una kernel code page, o modificare le page tables), chiama una routine **PPL wrapper**, che fa la validazione e poi transizione nel dominio PPL. Fuori da quel dominio, le pagine protette sono effettivamente read-only o non modificabili dal kernel principale.
- Durante l'entry in PPL, le mappature APRR sono aggiustate in modo che le pagine di memoria nella regione PPL siano impostate come **executable & writable** all'interno di PPL. Al momento dell'uscita, tornano a essere read-only / non-writable. Questo assicura che solo le routine PPL ben revisionate possano scrivere sulle pagine protette.
- Fuori da PPL, i tentativi da parte del codice kernel di scrivere su quelle pagine protette genereranno fault (permission denied) perché la mapping APRR per quel dominio di codice non permette la scrittura.

#### Protected page categories

Le pagine che PPL tipicamente protegge includono:

- Strutture delle page table (translation table entries, mapping metadata)
- Kernel code pages, specialmente quelle contenenti logica critica
- Code-sign metadata (trust caches, signature blobs)
- Entitlement tables, signature enforcement tables
- Altre strutture kernel di alto valore dove una patch permetterebbe di bypassare i controlli di firma o manipolare credenziali

L'idea è che anche se la memoria del kernel è completamente controllata, l'attaccante non può semplicemente patchare o riscrivere queste pagine, a meno che non comprometta anche le routine PPL o non bypassi PPL.

#### Known Bypasses & Vulnerabilities

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

- Una writeup pubblica di Project Zero descrive un bypass che implica **stale TLB entries**.
- L'idea:

1. Allocare due pagine fisiche A e B, marcarle come PPL pages (quindi protette).
2. Mappare due indirizzi virtuali P e Q le cui L3 translation table pages provengono da A e B.
3. Lanciare un thread che accede continuamente a Q, mantenendo viva la sua entry TLB.
4. Chiamare `pmap_remove_options()` per rimuovere le mappature a partire da P; a causa di un bug, il codice rimuove per errore le TTE sia per P che per Q, ma invalida solo la entry TLB per P, lasciando viva la stale entry di Q.
5. Riutilizzare B (la pagina della table di Q) per mappare memoria arbitraria (es. pagine protette PPL). Poiché la stale entry TLB mappa ancora la vecchia mapping di Q, quella mapping resta valida per quel contesto.
6. Attraverso ciò, l'attaccante può mettere in piedi una mapping scrivibile delle pagine protette PPL senza passare per l'interfaccia PPL.

- Questo exploit richiedeva un controllo preciso delle mappature fisiche e del comportamento del TLB. Dimostra che un confine di sicurezza che si basa sulla correttezza di TLB / mapping deve essere estremamente attento alle invalidazioni TLB e alla coerenza delle mappature.

- Project Zero ha commentato che bypass come questo sono sottili e rari, ma possibili in sistemi complessi. Tuttavia, considerano PPL una mitigazione solida.

2. **Other potential hazards & constraints**

- Se un exploit del kernel può entrare direttamente nelle routine PPL (chiamando i PPL wrappers), potrebbe bypassare le restrizioni. Perciò la validazione degli argomenti è critica.
- Bug nel codice PPL stesso (es. overflow aritmetico, controlli di confine) possono permettere modifiche out-of-bounds all'interno di PPL. Project Zero ha osservato che un bug del genere in `pmap_remove_options_internal()` è stato sfruttato nel loro bypass.
- Il confine PPL è irrevocabilmente legato all'enforcement hardware (APRR, memory controller), quindi è forte solo quanto l'implementazione hardware.

#### Example
<details>
<summary>Code Example</summary>
Ecco un pseudocodice / logica semplificata che mostra come un kernel potrebbe chiamare PPL per modificare pagine protette:
</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

Il kernel può eseguire molte operazioni normali, ma solo attraverso le routine ppl_call_* può modificare mappature protette o patchare il codice.

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

#### Limitazioni & sfide

- **Intrablock overflows**: Se l’overflow resta nella stessa allocazione (non attraversa il boundary) e il tag rimane lo stesso, il tag mismatch non lo rileva.
- **Tag width limitation**: Solo pochi bit (es. 4 bit, o piccolo dominio) sono disponibili per il tag—namespace limitato.
- **Side-channel leaks**: Se i bit del tag possono essere leaked (via cache / speculative execution), un attacker può apprendere tag validi e bypassare. La Tag confidentiality enforcement di Apple è pensata per mitigare questo.
- **Performance overhead**: I controlli di tag su ogni load/store aggiungono costo; Apple deve ottimizzare l’hardware per ridurre l’overhead.
- **Compatibility & fallback**: Su hardware più vecchio o su parti che non supportano EMTE, deve esistere un fallback. Apple dichiara che MIE è abilitato solo su dispositivi con supporto.
- **Complex allocator logic**: L’allocator deve gestire i tag, retagging, allineare i boundary e evitare collisioni di mis-tag. Bug nella logica dell’allocator potrebbero introdurre vulnerabilità.
- **Mixed memory / hybrid areas**: Alcune aree di memoria possono rimanere untagged (legacy), rendendo l’interoperabilità più complessa.
- **Speculative / transient attacks**: Come con molte protezioni microarchitetturali, speculative execution o micro-op fusions potrebbero bypassare controlli transientemente o leakare bit di tag.
- **Limited to supported regions**: Apple potrebbe far valere EMTE solo in aree selettive e ad alto rischio (kernel, subsistemi critici per la sicurezza), non universalmente.



---

## Miglioramenti chiave / differenze rispetto a standard MTE

Ecco i miglioramenti e i cambiamenti che Apple enfatizza:

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

Poiché Apple controlla sia l’hardware sia lo stack software, può far rispettare EMTE in modo stringente, evitare problemi di performance e chiudere buchi di side-channel.

---

## Come EMTE funziona in pratica (Apple / MIE)

Qui una descrizione ad alto livello di come EMTE opera sotto il setup MIE di Apple:

1. **Tag assignment**
- Quando la memoria viene allocata (es. in kernel o user space tramite secure allocators), viene assegnato a quel blocco un **secret tag**.
- Il puntatore restituito all’utente o al kernel include quel tag nei bit alti (usando TBI / top byte ignore mechanisms).

2. **Tag checking on access**
- Ogni volta che viene eseguito un load o store usando un puntatore, l’hardware verifica che il tag del puntatore corrisponda al tag del blocco di memoria (allocation tag). Se mismatch, genera subito un fault (dato che è synchronous).
- Poiché è synchronous, non esiste una finestra di “rilevamento ritardato”.

3. **Retagging on free / reuse**
- Quando la memoria viene liberata, l’allocator cambia il tag del blocco (così i puntatori più vecchi con tag obsoleti non corrispondono più).
- Un use-after-free pointer quindi avrà un tag stale e mismatch quando verrà usato.

4. **Neighbor-tag differentiation to catch overflows**
- Allocazioni adiacenti ricevono tag distinti. Se un buffer overflow travasa nella memoria del vicino, il tag mismatch causa un fault.
- Questo è particolarmente efficace per rilevare piccoli overflow che oltrepassano il boundary.

5. **Tag confidentiality enforcement**
- Apple deve prevenire che i valori dei tag vengano leaked (perché se un attacker apprende il tag, può costruire puntatori con il tag corretto).
- Includono protezioni (microarchitectural / speculative controls) per evitare side-channel leakage dei bit di tag.

6. **Kernel and user-space integration**
- Apple usa EMTE non solo in user-space ma anche nel kernel / componenti critici dell’OS (per proteggere il kernel dalla corruzione di memoria).
- L’hardware/OS assicura che le regole sui tag si applichino anche quando il kernel esegue per conto dello user space.

Poiché EMTE è parte di MIE, Apple usa EMTE in synchronous mode sulle superfici di attacco chiave, non come opzione opt-in o modalità di debug.



---

## Exception handling in XNU

Quando si verifica un’**exception** (es., `EXC_BAD_ACCESS`, `EXC_BAD_INSTRUCTION`, `EXC_CRASH`, `EXC_ARM_PAC`, ecc.), il livello **Mach** del kernel XNU è responsabile di intercettarla prima che diventi un **signal** in stile UNIX (come `SIGSEGV`, `SIGBUS`, `SIGILL`, ...).

Questo processo coinvolge più livelli di propagazione e gestione delle exception prima di raggiungere lo user space o essere convertita in un BSD signal.


### Flusso delle Exception (High-Level)

1.  **La CPU genera una exception sincrona** (es., dereferenziazione di un puntatore invalido, PAC failure, istruzione illegale, ecc.).

2.  **Il low-level trap handler** viene eseguito (`trap.c`, `exception.c` nel sorgente XNU).

3.  Il trap handler chiama **`exception_triage()`**, il cuore della gestione delle Mach exception.

4.  `exception_triage()` decide come instradare l’exception:

-   Prima alla **thread's exception port**.

-   Poi alla **task's exception port**.

-   Poi alla **host's exception port** (spesso `launchd` o `ReportCrash`).

Se nessuna di queste porte gestisce l’exception, il kernel può:

-   **Convertirla in un BSD signal** (per processi user-space).

-   **Panic** (per exception in kernel-space).


### Funzione core: `exception_triage()`

La funzione `exception_triage()` instrada le Mach exceptions lungo la catena di possibili handler finché una non la gestisce o finché non diventa infine fatale. È definita in `osfmk/kern/exception.c`.
```c
void exception_triage(exception_type_t exception, mach_exception_data_t code, mach_msg_type_number_t codeCnt);

Flusso di chiamata tipico:

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

Se tutte falliscono → l’eccezione viene gestita da bsd_exception() → viene tradotta in un segnale come SIGSEGV.

Porte di eccezione

Ogni oggetto Mach (thread, task, host) può registrare exception ports, dove vengono inviati i messaggi di eccezione.

Sono definiti dall’API:

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

Each exception port has:

• A mask (which exceptions it wants to receive)
• A port name (Mach port to receive messages)
• A behavior (how the kernel sends the message)
• A flavor (which thread state to include)

Debuggers and Exception Handling

A debugger (e.g., LLDB) sets an exception port on the target task or thread, usually using task_set_exception_ports().

When an exception occurs:

• The Mach message is sent to the debugger process.
• The debugger can decide to handle (resume, modify registers, skip instruction) or not handle the exception.
• If the debugger doesn’t handle it, the exception propagates to the next level (task → host).

Flow of EXC_BAD_ACCESS

1. Thread dereferences invalid pointer → CPU raises Data Abort.

2. Kernel trap handler calls exception_triage(EXC_BAD_ACCESS, ...).

3. Message sent to:

• Thread port → (debugger can intercept breakpoint).

• If debugger ignores → Task port → (process-level handler).

• If ignored → Host port (usually ReportCrash).

4. If no one handles → bsd_exception() translates to SIGSEGV.

PAC Exceptions

When Pointer Authentication (PAC) fails (signature mismatch), a special Mach exception is raised:

• EXC_ARM_PAC (type)
• Codes may include details (e.g., key type, pointer type).

If the binary has the flag TFRO_PAC_EXC_FATAL, the kernel treats PAC failures as fatal, bypassing debugger interception. This is to prevent attackers from using debuggers to bypass PAC checks and it’s enabled for platform binaries.

Software Breakpoints

A software breakpoint (int3 on x86, brk on ARM64) is implemented by causing a deliberate fault.
The debugger catches this via the exception port:

• Modifies instruction pointer or memory.
• Restores original instruction.
• Resumes execution.

This same mechanism is what allows you to “catch” a PAC exception — unless TFRO_PAC_EXC_FATAL is set, in which case it never reaches the debugger.

Conversion to BSD Signals

If no handler accepts the exception:

• Kernel calls task_exception_notify() → bsd_exception().

• This maps Mach exceptions to signals:

### Key Files in XNU Source

• osfmk/kern/exception.c → Core of exception_triage(), exception_deliver_*().

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

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

• osfmk/mach/exc.h → Exception codes and structures.

• osfmk/kern/task.c → Task exception port setup.

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

The kernel used a zone allocator (kalloc) divided into fixed-size “zones.” Each zone only stores allocations of a single size class.

From the screenshot:

How it worked:

• Each allocation request gets rounded up to the nearest zone size. (E.g., a 50-byte request lands in the kalloc.64 zone).
• Memory in each zone was kept in a free list — chunks freed by the kernel went back into that zone.
• If you overflowed a 64-byte buffer, you’d overwrite the next object in the same zone.

This is why heap spraying / feng shui was so effective: you could predict object neighbors by spraying allocations of the same size class.

The freelist

Inside each kalloc zone, freed objects weren’t returned directly to the system — they went into a freelist, a linked list of available chunks.

• When a chunk was freed, the kernel wrote a pointer at the start of that chunk → the address of the next free chunk in the same zone.

• The zone kept a HEAD pointer to the first free chunk.

• Allocation always used the current HEAD:

1. Pop HEAD (return that memory to the caller).

2. Update HEAD = HEAD->next (stored in the freed chunk’s header).

• Freeing pushed chunks back:

• freed_chunk->next = HEAD

• HEAD = freed_chunk

So the freelist was just a linked list built inside the freed memory itself.

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)

Sfruttare la freelist

Poiché i primi 8 byte di un free chunk = freelist pointer, un attacker potrebbe corromperlo:

1. Heap overflow in un freed chunk adiacente → sovrascrivere il suo “next” pointer.
2. Use-after-free scrivere in un freed object → sovrascrivere il suo “next” pointer.

Poi, alla successiva allocazione di quella dimensione:

• L’allocator estrae il corrupted chunk.
• Segue il attacker-supplied “next” pointer.
• Restituisce un pointer verso memoria arbitraria, consentendo fake object primitives o targeted overwrite.

Esempio visivo di 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.

Questo freelist design rese lo sfruttamento molto efficace prima dell’hardening: vicini prevedibili da heap sprays, raw pointer nelle freelist links e l’assenza di separazione dei tipi permetteva agli attaccanti di trasformare bug UAF/overflow in controllo arbitrario della memoria del kernel.

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.
In questo modo, quando avviene la corruzione di memoria, l’attaccante può sovrascrivere in modo affidabile l’oggetto vittima con dati controllati.

Passaggi:

1. Spray allocations (fill the holes)

• Col tempo, l’heap del kernel si frammenta: alcune zone contengono buchi dove oggetti vecchi sono stati liberati.
• Prima, l’attaccante effettua molte allocazioni fittizie per riempire questi spazi, così l’heap diventa “compattato” e prevedibile.

2. Force new pages

• Una volta riempiti i buchi, le allocazioni successive devono arrivare da nuove pagine aggiunte alla zona.
• Pagine fresche significano che gli oggetti saranno raggruppati insieme, non sparsi nella memoria frammentata.
• Questo dà all’attaccante un controllo molto migliore sui vicini.

3. Place attacker objects

• L’attaccante effettua di nuovo uno spray, creando molti oggetti controllati dall’attaccante in quelle nuove pagine.
• Questi oggetti sono prevedibili per dimensione e posizione (dato che appartengono alla stessa zona).

4. Free a controlled object (make a gap)

• L’attaccante libera deliberatamente uno dei propri oggetti.
• Questo crea un “buco” nell’heap, che l’allocator riutilizzerà per la prossima allocazione di quella dimensione.

5. Victim object lands in the hole

• L’attaccante induce il kernel ad allocare l’oggetto vittima (quello che vuole corrompere).
• Poiché il buco è la prima slot disponibile nella freelist, la vittima viene posizionata esattamente dove l’attaccante aveva liberato il proprio oggetto.

6. Overflow / UAF into victim

• Ora l’attaccante ha oggetti controllati attorno alla vittima.
• Sovrascrivendo tramite overflow da uno dei propri oggetti (o riutilizzando uno freed), può sovrascrivere in modo affidabile i campi di memoria della vittima con valori scelti.

Perché funziona:

• Zone allocator predictability: le allocazioni della stessa dimensione provengono sempre dalla stessa zona.
• Freelist behavior: le nuove allocazioni riutilizzano prima il chunk più recentemente liberato.
• Heap sprays: l’attaccante riempie la memoria con contenuti prevedibili e controlla il layout.
• Risultato finale: l’attaccante controlla dove l’oggetto vittima viene allocato e quali dati si trovano vicino ad esso.

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

Apple ha rinforzato l’allocator e reso il heap grooming molto più difficile:

1. From Classic kalloc to kalloc_type

• Prima: esisteva una singola zona kalloc.<size> per ogni classe di dimensione (16, 32, 64, … 1280, ecc.). Qualsiasi oggetto di quella dimensione veniva messo lì → gli oggetti controllati dall’attaccante potevano trovarsi accanto ad oggetti privilegiati del kernel.
• Adesso:
• Gli oggetti del kernel sono allocati da typed zones (kalloc_type).
• Ogni tipo di oggetto (es., ipc_port_t, task_t, OSString, OSData) ha la propria zona dedicata, anche se hanno la stessa dimensione.
• La mappatura tra tipo di oggetto ↔ zona è generata dal kalloc_type system a compile time.

Un attaccante non può più garantire che dati controllati (OSData) finiscano adiacenti a oggetti kernel sensibili (task_t) della stessa dimensione.

2. Slabs and Per-CPU Caches

• L’heap è diviso in slabs (pagine di memoria suddivise in chunk a dimensione fissa per quella zona).
• Ogni zona ha una cache per CPU per ridurre la contendibilità.
• Percorso di allocazione:

1. Prova la per-CPU cache.
2. Se vuota, preleva dalla freelist globale.
3. Se la freelist è vuota, allocare una nuova slab (una o più pagine).

• Vantaggio: questa decentralizzazione rende gli heap sprays meno deterministici, dato che le allocazioni possono essere soddisfatte dalle cache di CPU diverse.

3. Randomization inside zones

• All’interno di una zona, gli elementi liberati non vengono restituiti in semplice ordine FIFO/LIFO.
• XNU moderno usa encoded freelist pointers (safe-linking come Linux, introdotto ~iOS 14).
• Ogni puntatore della freelist è XOR-encoded con un cookie segreto per zona.
• Questo impedisce agli attaccanti di forgiare un puntatore di freelist falso se ottengono un primitive di scrittura.
• Alcune allocazioni sono randomizzate nella loro collocazione all’interno di una slab, quindi lo spraying non garantisce l’adiacenza.

4. Guarded Allocations

• Certi oggetti critici del kernel (es., credenziali, strutture task) sono allocati in guarded zones.
• Queste zone inseriscono guard pages (memoria non mappata) tra le slab o usano redzones attorno agli oggetti.
• Qualsiasi overflow nella guard page causa un fault → panic immediato invece di corruzione silente.

5. Page Protection Layer (PPL) and SPTM

• Anche se controlli un oggetto liberato, non puoi modificare tutta la memoria del kernel:
• PPL (Page Protection Layer) impone che certe regioni (es., dati di code signing, entitlements) siano read-only anche per il kernel stesso.
• Su dispositivi A15/M2+, questo ruolo è sostituito/enhanced da SPTM (Secure Page Table Monitor) + TXM (Trusted Execution Monitor).
• Questi layer imposti dall’hardware significano che gli attaccanti non possono scalare da una singola corruzione dell’heap al patching arbitrario di strutture di sicurezza critiche.
• (Aggiunto / Potenziato): anche PAC (Pointer Authentication Codes) è usato nel kernel per proteggere i puntatori (soprattutto function pointers, vtables) rendendo più difficile forgiare o corrompere tali puntatori.
• (Aggiunto / Potenziato): le zone possono applicare zone_require / zone enforcement, cioè che un oggetto liberato possa essere restituito solo attraverso la sua corretta typed zone; free cross-zone non validi possono causare panic o essere rifiutati. (Apple accenna a questo nei loro post sulla memory safety)

6. Large Allocations

• Non tutte le allocazioni passano per kalloc_type.
• Richieste molto grandi (sopra ~16 KB) bypassano le typed zones e sono servite direttamente dal kernel VM (kmem) tramite allocazioni di pagina.
• Queste sono meno prevedibili, ma anche meno sfruttabili, poiché non condividono slab con altri oggetti.

7. Allocation Patterns Attackers Target

Anche con queste protezioni, gli attaccanti cercano ancora:

• Reference count objects: se puoi alterare i contatori retain/release, puoi provocare use-after-free.
• Objects with function pointers (vtables): corrompere uno di questi fornisce ancora controllo del flow.
• Shared memory objects (IOSurface, Mach ports): restano bersagli perché fungono da ponte user ↔ kernel.

Ma — a differenza di prima — non puoi semplicemente sprayare OSData e aspettarti che stia vicino a un task_t. Serve un bug specifico per tipo o info leaks per avere successo.

Example: Allocation Flow in Modern Heap

Supponiamo che userspace chiami IOKit per allocare un oggetto OSData:

1. Type lookup → OSData mappa alla zona kalloc_type_osdata (size 64 bytes).
2. Controlla la per-CPU cache per elementi liberi.

• Se trovato → restituisci uno.
• Se vuoto → vai alla freelist globale.
• Se freelist vuota → allocare una nuova slab (pagina da 4KB → 64 chunk da 64 bytes).

3. Restituisci il chunk al chiamante.

Protezione dei puntatori della freelist:

• Ogni chunk liberato memorizza l’indirizzo del successivo chunk libero, ma codificato con una chiave segreta.
• Sovrascrivere quel campo con dati dell’attaccante non funzionerà a meno di conoscere la chiave.

Comparison Table

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

Nelle recenti versioni Apple OS (soprattutto iOS 17+), Apple ha introdotto un allocator userland più sicuro, xzone malloc (XZM). Questo è l’analogo in user-space di kalloc_type del kernel, applicando consapevolezza di tipo, isolamento dei metadata e meccanismi di memory tagging.

Goals & Design Principles

• Type segregation / type awareness: raggruppare le allocazioni per tipo o uso (pointer vs data) per prevenire type confusion e riuso cross-type.
• Metadata isolation: separare i metadata dell’heap (es. free lists, bit di size/state) dai payload degli oggetti in modo che scritture OOB siano meno propense a corrompere i metadata.
• Guard pages / redzones: inserire pagine non mappate o padding attorno alle allocazioni per catturare overflow.
• Memory tagging (EMTE / MIE): lavorare insieme al tagging hardware per rilevare use-after-free, out-of-bounds e accessi invalidi.
• Scalable performance: mantenere basso overhead, evitare frammentazione e supportare molte allocazioni al secondo con bassa latenza.

Architecture & Components

Di seguito gli elementi principali dell’allocator xzone:

Segment Groups & Zones

• Segment groups partizionano lo spazio di indirizzamento per categorie d’uso: es. data, pointer_xzones, data_large, pointer_large.
• Ogni segment group contiene segments (range VM) che ospitano allocazioni per quella categoria.
• Associato a ogni segment c’è una metadata slab (area VM separata) che memorizza i metadata (es. bit free/used, classi di dimensione) per quel segment. Questa out-of-line (OOL) metadata garantisce che i metadata non siano mescolati con i payload degli oggetti, mitigando la corruzione da overflow.
• I segments sono suddivisi in chunks (slice) che a loro volta sono suddivisi in blocks (unità di allocazione). Un chunk è legato a una classe di dimensione e a un segment group (cioè tutti i block in un chunk condividono la stessa dimensione & categoria).
• Per allocazioni small/medium si usano chunk a dimensione fissa; per large/huge può effettuare mapping separati.

Chunks & Blocks

• Un chunk è una regione (spesso diverse pagine) dedicata alle allocazioni di una classe di dimensione all’interno di un gruppo.
• All’interno di un chunk, i blocks sono slot disponibili per le allocazioni. I block liberati sono tracciati tramite la metadata slab — es. tramite bitmap o free lists memorizzate out-of-line.
• Tra i chunk (o al loro interno), possono essere inserite guard slices / guard pages (es. slice non mappate) per catturare scritture out-of-bounds.

Type / Type ID

• Ogni sito di allocazione (o chiamata a malloc, calloc, ecc.) è associato a un type identifier (un malloc_type_id_t) che codifica che tipo di oggetto viene allocato. Quel type ID è passato all’allocator, che lo usa per selezionare quale zona/segment servire l’allocazione.
• Per questo, anche se due allocazioni hanno la stessa dimensione, possono andare in zone completamente diverse se i tipi differiscono.
• Nelle prime versioni di iOS 17, non tutte le API (es. CFAllocator) erano pienamente type-aware; Apple ha corretto alcune di queste debolezze in iOS 18.

Allocation & Freeing Workflow

Ecco un flusso ad alto livello di come operano allocazione e deallocazione in xzone:

1. malloc / calloc / realloc / typed alloc viene invocata con una size e un type ID.
2. L’allocator usa il type ID per scegliere il corretto segment group / zone.
3. All’interno di quella zona/segment, cerca un chunk che abbia blocks liberi della dimensione richiesta.

• Può consultare local caches / per-thread pools o free block lists dalla metadata.
• Se non è disponibile nessun block libero, può allocare un nuovo chunk in quella zona.

4. La metadata slab viene aggiornata (bit free cancellato, bookkeeping).
5. Se il memory tagging (EMTE) è in uso, il block restituito riceve un tag, e la metadata viene aggiornata per riflettere lo stato “live”.
6. Quando viene chiamato free():

• Il block è marcato come liberato nella metadata (tramite OOL slab).
• Il block può essere messo in una free list o pooled per il riuso.
• Opzionalmente, il contenuto del block può essere cancellato o poisoned per ridurre leak di dati o sfruttamento UAF.
• Il tag hardware associato al block può essere invalidato o rietichettato.
• Se un intero chunk diventa libero (tutti i block liberati), l’allocator può reclaim quel chunk (unmapparlo o restituirlo al OS) sotto pressione di memoria.

Security Features & Hardening

Queste sono le difese integrate nel moderno xzone:

Interaction with Memory Integrity Enforcement (MIE / EMTE)

• MIE (Memory Integrity Enforcement) di Apple è il framework hardware + OS che porta Enhanced Memory Tagging Extension (EMTE) in modalità always-on, sincrona su superfici di attacco rilevanti.
• L’allocator xzone è una base fondamentale di MIE in user space: le allocazioni effettuate tramite xzone ricevono tag, e gli accessi sono controllati dall’hardware.
• In MIE, l’allocator, l’assegnazione dei tag, la gestione dei metadata e l’enforcement della confidenzialità dei tag sono integrati per assicurare che errori di memoria (es. stale reads, OOB, UAF) vengano rilevati immediatamente, non sfruttati in seguito.

Se vuoi, posso anche generare una cheat-sheet o un diagramma degli internals di xzone per il tuo libro. Vuoi che lo faccia adesso?

: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: Un watcher binario dedicato profila continuamente il dispositivo e interrompe la kill-chain quando viene rilevato un ambiente di ricerca. Ispeziona security.mac.amfi.developer_mode_status, la presenza di una console diagnosticd, le localizzazioni US o IL, tracce di jailbreak come Cydia, processi come bash, tcpdump, frida, sshd, o checkrain, app AV mobile (McAfee, AvastMobileSecurity, NortonMobileSecurity), impostazioni proxy HTTP custom e root CA custom. Il fallimento di qualsiasi controllo blocca la consegna successiva del payload.

• Helper surveillance hooks: Il componente helper comunica con le altre fasi tramite /tmp/helper.sock, poi carica set di hook chiamati DMHooker e UMHooker. Questi hook intercettano i percorsi audio VOIP (le registrazioni finiscono sotto /private/var/tmp/l/voip_%lu_%u_PART.m4a), implementano un keylogger di sistema, catturano foto senza UI e hookano SpringBoard per sopprimere le notifiche che tali azioni solitamente genererebbero. L’helper agisce quindi come strato di validazione stealth + sorveglianza leggera prima che vengano deployati implant più pesanti come Predator.

• HiddenDot indicator suppression in SpringBoard: Con injection di codice a livello kernel, Predator hooka SBSensorActivityDataProvider._handleNewDomainData: (il punto di aggregazione per l’attività dei sensori). L’hook azzera il puntatore Objective-C self (x0) così la chiamata diventa [nil _handleNewDomainData:newData], eliminando gli aggiornamenti camera/microfono e sopprimendo sia i puntini verdi sia quelli arancioni.

• Mach exception-based hooking flow (DMHooker): Gli hook sono implementati tramite EXC_BREAKPOINT + exception ports, poi thread_set_state muta i registri e l’esecuzione riprende. Il codice di ritorno 2 significa ‘continua con lo stato del thread modificato’.

• PAC-aware redirection for camera access checks: In mediaserverd, una pattern-scan (es. memmem) localizza una routine privata vicino a FigVideoCaptureSourceCreateWithSourceInfo dentro CMCapture.framework. L’hook ritorna 3 per reindirizzare usando un indirizzo di ritorno PAC pre-signed e cached, soddisfacendo PAC mentre bypassa il controllo.

• VoIP capture pipeline in mediaserverd: Hooka AudioConverterNew e AudioConverterConvertComplexBuffer+52 per intercettare i buffer, dedurre il sample rate dalle dimensioni dei buffer, convertire float32 PCM → int16 con NEON, downmixare da 4 canali a stereo e persistere tramite ExtAudioFileWrite(). Il modulo VoIP stesso non sopprime gli indicatori, quindi gli operatori devono abilitare HiddenDot separatamente.

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

Riferimenti

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

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.