; 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>Exemple</summary>
Un buffer overflow écrase une adresse de retour sur la stack. L'attaquant écrit l'adresse du gadget cible mais ne peut pas calculer le PAC correct. Quand la fonction retourne, l'instruction CPU `AUTIA` fault parce que le PAC ne correspond pas. La chaîne échoue.
L'analyse de Project Zero sur A12 (iPhone XS) a montré comment le PAC d'Apple est utilisé et des méthodes pour forger des PAC si un attaquant dispose d'un primitive de lecture/écriture mémoire.
</details>


### 9. **Branch Target Identification (BTI)**
**Introduit avec ARMv8.5 (matériel plus récent)**
BTI est une fonctionnalité matérielle qui vérifie les **cibles de branchement indirectes** : lors de l'exécution de `blr` ou d'appels/sauts indirects, la cible doit commencer par un **BTI landing pad** (`BTI j` ou `BTI c`). Sauter vers des adresses de gadget qui ne possèdent pas le landing pad déclenche une exception.

L'implémentation d'LLVM note trois variantes d'instructions BTI et comment elles se mappent aux types de branchement.

| BTI Variant | Ce qu'il permet (quels types de branche) | Placement / cas d'utilisation typique |
|-------------|----------------------------------------|-------------------------------|
| **BTI C** | Cibles des branches indirectes de style *call* (par ex. `BLR`, ou `BR` utilisant X16/X17) | Placé à l'entrée des fonctions susceptibles d'être appelées indirectement |
| **BTI J** | Cibles des branches de type *jump* (par ex. `BR` utilisé pour des tail calls) | Placé au début des blocs atteignables par des jump tables ou des tail-calls |
| **BTI JC** | Agit à la fois comme C et J | Peut être ciblé par des branches de type call ou jump |

- Dans le code compilé avec enforcement des branch targets, les compilateurs insèrent une instruction BTI (C, J, ou JC) à chaque cible valide de branchement indirect (débuts de fonctions ou blocs atteignables par des sauts) afin que les branches indirectes ne réussissent que vers ces emplacements.
- Les **branches / calls directs** (c.-à-d. adresses fixes `B`, `BL`) ne sont **pas restreints** par BTI. L'hypothèse est que les pages de code sont de confiance et que l'attaquant ne peut pas les modifier (donc les branches directes sont sûres).
- De plus, les instructions **RET / return** ne sont généralement pas restreintes par BTI parce que les adresses de retour sont protégées via PAC ou des mécanismes de signature de retour.

#### Mécanisme et application

- Quand le CPU décode une **branche indirecte (BLR / BR)** dans une page marquée comme « guarded / BTI-enabled », il vérifie si la première instruction de l'adresse cible est un BTI valide (C, J ou JC selon autorisation). Sinon, une **Branch Target Exception** survient.
- L'encodage de l'instruction BTI est conçu pour réutiliser des opcodes précédemment réservés pour des NOPs (dans les versions ARM antérieures). Ainsi, les binaires BTI-enabled restent rétrocompatibles : sur du matériel sans support BTI, ces instructions agissent comme des NOPs.
- Les passes du compilateur qui ajoutent des BTI les insèrent uniquement où c'est nécessaire : fonctions pouvant être appelées indirectement, ou blocs de base ciblés par des sauts.
- Certains correctifs et du code LLVM montrent que BTI n'est pas inséré pour *tous* les blocks — seulement ceux qui sont des cibles potentielles de branches (par ex. depuis des switch / jump tables).

#### Synergie BTI + PAC

PAC protège la valeur du pointeur (la source) — garantit que la chaîne d'appels indirects / retours n'a pas été modifiée.

BTI garantit que même un pointeur valide ne peut cibler que des points d'entrée correctement marqués.

Combinés, l'attaquant a besoin à la fois d'un pointeur valide avec le PAC correct et que la cible possède un BTI placé là. Cela augmente la difficulté de construction de gadgets exploitables.

#### Exemple


<details>
<summary>Exemple</summary>
Un exploit tente de pivoter vers un gadget à `0xABCDEF` qui ne commence pas par `BTI c`. Le CPU, en exécutant `blr x0`, vérifie la cible et fault parce que l'alignement d'instruction n'inclut pas un landing pad valide. Ainsi, de nombreux gadgets deviennent inutilisables à moins qu'ils n'aient un préfixe BTI.
</details>


### 10. **Privileged Access Never (PAN) & Privileged Execute Never (PXN)**
**Introduit dans des extensions ARMv8 plus récentes / support iOS (pour noyau renforcé)**

#### PAN (Privileged Access Never)

- **PAN** est une fonctionnalité introduite en **ARMv8.1-A** qui empêche le code **privilégié** (EL1 ou EL2) de **lire ou écrire** la mémoire marquée comme **accessible par l'utilisateur (EL0)**, à moins que PAN ne soit explicitement désactivé.
- L'idée : même si le kernel est trompé ou compromis, il ne peut pas déréférencer arbitrairement des pointeurs utilisateur sans d'abord *désactiver* PAN, réduisant ainsi les risques d'exploits de type **`ret2usr`** ou de mauvaise utilisation de buffers contrôlés par l'utilisateur.
- Quand PAN est activé (PSTATE.PAN = 1), toute instruction privilégiée de load/store accédant à une adresse virtuelle « accessible à EL0 » déclenche une **permission fault**.
- Le kernel, lorsqu'il doit légitimement accéder à la mémoire utilisateur (par ex. copier des données depuis/vers des buffers utilisateur), doit **désactiver temporairement PAN** (ou utiliser des instructions de load/store « non privilégiées ») pour permettre cet accès.
- Dans Linux sur ARM64, le support PAN a été introduit vers 2015 : des patchs du kernel ont ajouté la détection de la fonctionnalité, et remplacé `get_user` / `put_user` etc. par des variantes qui effacent PAN autour des accès mémoire utilisateur.

**Nuance / limitation / bug clé**
- Comme noté par Siguza et d'autres, un bug de spécification (ou un comportement ambigu) dans la conception ARM signifie que les **execute-only user mappings** (`--x`) peuvent **ne pas déclencher PAN**. En d'autres termes, si une page utilisateur est marquée exécutable mais sans permission de lecture, la tentative de lecture du kernel pourrait contourner PAN parce que l'architecture considère « accessible à EL0 » comme nécessitant la permission de lecture, pas seulement l'exécution. Cela conduit à un contournement de PAN dans certaines configurations.
- À cause de cela, si iOS / XNU autorise des pages utilisateur execute-only (comme certains setups JIT ou code-cache), le kernel pourrait lire accidentellement depuis elles même avec PAN activé. C'est une zone subtile connue comme exploitable sur certains systèmes ARMv8+.

#### PXN (Privileged eXecute Never)

- **PXN** est un bit dans la page table (dans les entrées de leaf ou block) qui indique que la page est **non exécutable en mode privilégié** (c.-à-d. quand EL1 exécute).
- PXN empêche le kernel (ou tout code privilégié) de sauter vers ou d'exécuter des instructions depuis des pages utilisateur même si le contrôle est détourné. En pratique, cela bloque la redirection de contrôle au niveau kernel vers la mémoire utilisateur.
- Combiné avec PAN, cela assure que :
1. Le kernel ne peut pas (par défaut) lire ou écrire les données utilisateur (PAN)
2. Le kernel ne peut pas exécuter le code utilisateur (PXN)
- Dans le format de table de pages ARMv8, les entrées leaf ont un bit `PXN` (et aussi `UXN` pour unprivileged execute-never) dans leurs bits d'attributs.

Ainsi, même si le kernel a un pointeur de fonction corrompu pointant vers la mémoire utilisateur et tente de brancher là-bas, le bit PXN provoquerait un fault.

#### Modèle de permissions mémoire & comment PAN et PXN se mappent aux bits de table de pages

Pour comprendre comment PAN / PXN fonctionnent, il faut voir comment la traduction ARM et le modèle de permissions opèrent (simplifié) :

- Chaque entrée de page ou block possède des champs d'attributs incluant **AP[2:1]** pour les permissions d'accès (read/write, privilégié vs non-privé) et les bits **UXN / PXN** pour les restrictions execute-never.
- Quand PSTATE.PAN = 1 (activé), le hardware applique une sémantique modifiée : les accès privilégiés aux pages marquées « accessibles par EL0 » (c.-à-d. accessibles par l'utilisateur) sont interdits (fault).
- À cause du bug mentionné, les pages marquées uniquement exécutables (sans permission de lecture) peuvent ne pas être considérées comme « accessibles par EL0 » selon certaines implémentations, contournant ainsi PAN.
- Quand le bit PXN d'une page est réglé, même si le fetch d'instruction provient d'un niveau de privilège supérieur, l'exécution est interdite.

#### Utilisation du kernel de PAN / PXN dans un OS renforcé (par ex. iOS / XNU)

Dans une conception de kernel renforcé (comme ce que Apple pourrait utiliser) :

- Le kernel active PAN par défaut (donc le code privilégié est contraint).
- Dans les chemins qui doivent légitimement lire ou écrire des buffers utilisateur (par ex. copie dans/syscall, I/O, read/write user pointer), le kernel **désactive temporairement PAN** ou utilise des instructions spéciales pour outrepasser.
- Après avoir fini l'accès aux données utilisateur, il doit réactiver PAN.
- PXN est appliqué via les tables de pages : les pages utilisateur ont PXN = 1 (donc le kernel ne peut pas les exécuter), les pages kernel n'ont pas PXN (donc le code kernel peut s'exécuter).
- Le kernel doit s'assurer qu'aucun chemin d'exécution n'amène le flux d'exécution dans des régions mémoire utilisateur (ce qui contournerait PXN) — ainsi les chaînes d'exploit reposant sur « sauter dans du shellcode contrôlé par l'utilisateur » sont bloquées.

À cause du contournement PAN via les pages execute-only, dans un système réel, Apple pourrait désactiver ou interdire les pages utilisateurs execute-only, ou patcher autour de la faiblesse de spécification.

#### Surfaces d'attaque, contournements et atténuations

- **Contournement PAN via execute-only pages** : comme discuté, la spec laisse une brèche : les pages utilisateur execute-only (pas de perm de lecture) pourraient ne pas être considérées comme « accessibles à EL0 », donc PAN ne bloquera pas les lectures du kernel selon certaines implémentations. Cela donne à l'attaquant un chemin inhabituel pour fournir des données via des sections « execute-only ».
- **Exploit via fenêtre temporelle** : si le kernel désactive PAN pour une fenêtre plus longue que nécessaire, une course ou un chemin malveillant pourrait exploiter cette fenêtre pour effectuer des accès mémoire utilisateur non voulus.
- **Oubli de réactivation** : si des chemins de code oublient de réactiver PAN, des opérations kernel ultérieures pourraient accéder incorrectement à la mémoire utilisateur.
- **Mauvaise configuration de PXN** : si les tables de pages ne mettent pas PXN sur les pages utilisateur ou mappent incorrectement des pages de code utilisateur, le kernel pourrait être trompé en exécutant du code utilisateur.
- **Spéculation / side-channels** : analogues aux contournements spéculatifs, il peut exister des effets microarchitecturaux transients qui violent PAN / PXN (bien que de telles attaques dépendent fortement du design du CPU).
- **Interactions complexes** : avec des fonctionnalités avancées (par ex. JIT, shared memory, zones de code just-in-time), le kernel peut avoir besoin d'un contrôle fin pour permettre certains accès mémoire ou exécutions dans des régions mappées utilisateur ; concevoir cela en sécurité sous les contraintes PAN/PXN est non trivial.

#### Exemple

<details>
<summary>Exemple de code</summary>
Voici des séquences pseudo-assembly illustratives montrant l'activation/désactivation de PAN autour d'un accès mémoire utilisateur, et comment un fault peut survenir.
</details>
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">  </span></div>

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

<details>
If the noyau had **not** set PXN on that page utilisateur, then the branch might succeed — which would be insecure.

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

If the user pointer is into an execute-only page (page utilisateur 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>Exemple</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**
**Introduit dans ARMv8.5 / versions plus récentes (ou extension optionnelle)**
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*). C'est une fonctionnalité matérielle (disponible dans de nombreuses implémentations ARMv8+) qui **ignore les 8 bits supérieurs** (bits 63:56) d'un pointeur 64 bits lors de la **traduction d'adresses / load/store / instruction fetch**.
- En pratique, le CPU traite un pointeur `0xTTxxxx_xxxx_xxxx` (où `TT` = top byte) comme `0x00xxxx_xxxx_xxxx` pour la traduction d'adresses, en ignorant (masquant) l'octet supérieur. L'octet supérieur peut être utilisé par le logiciel pour stocker **métadonnées / tag bits**.
- Cela donne au logiciel un espace intégré "gratuit" pour insérer un octet de tag dans chaque pointeur sans modifier la localisation mémoire référencée.
- L'architecture veille à ce que les loads, stores et instruction fetch traitent le pointeur avec son octet supérieur masqué (c.-à-d. tag retiré) avant d'effectuer l'accès mémoire réel.

Ainsi, TBI découple le **pointeur logique** (pointeur + tag) de l'**adresse physique** utilisée pour les opérations mémoire.

#### Pourquoi TBI : cas d'utilisation et motivation

- **Pointer tagging / metadata** : Vous pouvez stocker des métadonnées supplémentaires (p.ex. type d'objet, version, bornes, tags d'intégrité) dans cet octet supérieur. Lorsque vous utilisez ensuite le pointeur, le tag est ignoré au niveau matériel, donc vous n'avez pas besoin de le retirer manuellement pour l'accès mémoire.
- **Memory tagging / MTE (Memory Tagging Extension)** : TBI est le mécanisme matériel de base sur lequel MTE s'appuie. Dans ARMv8.5, la **Memory Tagging Extension** utilise les bits 59:56 du pointeur comme **tag logique** et le compare à un **tag d'allocation** stocké en mémoire.
- **Enhanced security & integrity** : En combinant TBI avec pointer authentication (PAC) ou des vérifications à l'exécution, vous pouvez exiger non seulement que la valeur du pointeur soit correcte mais aussi que le tag le soit. Un attaquant qui écrase un pointeur sans le tag correct produira un tag non concordant.
- **Compatibility** : Parce que TBI est optionnel et que les bits de tag sont ignorés par le hardware, le code existant non taggé continue de fonctionner normalement. Les bits de tag deviennent effectivement des bits « sans importance » pour le code hérité.

#### Exemple
<details>
<summary>Exemple</summary>
Un pointeur de fonction incluait un tag dans son octet supérieur (par ex. `0xAA`). Un exploit écrase les bits bas du pointeur mais néglige le tag, si bien que lorsque le noyau vérifie ou assainit, la vérification du pointeur échoue ou il est rejeté.
</details>

---

### 12. **Page Protection Layer (PPL)**
**Introduit dans les versions récentes d'iOS / hardware moderne (iOS ~17 / Apple silicon / modèles haut de gamme)** (some reports show PPL circa macOS / Apple silicon, but Apple is bringing analogous protections to iOS)

- PPL est conçu comme une **frontière de protection intra-noyau** : même si le noyau (EL1) est compromis et dispose de capacités de lecture/écriture, **il ne devrait pas être capable de modifier librement** certaines **pages sensibles** (notamment les tables de pages, les métadonnées de signature de code, les pages de code du noyau, les entitlements, les trust caches, etc.).
- Il crée effectivement un **“noyau dans le noyau”** — un composant de confiance plus petit (PPL) avec **privilèges élevés** qui seul peut modifier les pages protégées. Le reste du code noyau doit appeler des routines PPL pour effectuer des changements.
- Cela réduit la surface d'attaque pour les exploits du noyau : même avec R/W/exécution arbitraire complète en mode noyau, le code d'exploit doit aussi d'une manière ou d'une autre atteindre le domaine PPL (ou contourner PPL) pour modifier des structures critiques.
- Sur les nouvelles puces Apple silicon (A15+ / M2+), Apple migre vers **SPTM (Secure Page Table Monitor)**, qui dans de nombreux cas remplace PPL pour la protection des tables de pages sur ces plateformes.

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

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

- Le hardware Apple utilise un mécanisme appelé **APRR (Access Permission ReRouting)**, qui permet aux entrées de tables de pages (PTEs) de contenir de petits indices, plutôt que des bits de permission complets. Ces indices sont mappés via des registres APRR vers des permissions effectives. Cela permet un remappage dynamique des permissions par domaine.
- PPL exploite APRR pour séparer les privilèges dans le contexte du noyau : seul le domaine PPL est autorisé à mettre à jour la correspondance entre indices et permissions effectives. Autrement dit, lorsque du code noyau non-PPL écrit une PTE ou tente de changer des bits de permission, la logique APRR l'en empêche (ou impose un mapping en lecture seule).
- Le code PPL lui-même s'exécute dans une région restreinte (p.ex. `__PPLTEXT`) qui est normalement non exécutable ou non modifiable jusqu'à ce que des portes d'entrée permettent temporairement l'accès. Le noyau appelle des points d'entrée PPL (« routines PPL ») pour effectuer des opérations sensibles.

#### Gate / Entry & Exit

- Quand le noyau doit modifier une page protégée (p.ex. changer les permissions d'une page de code noyau, ou modifier les tables de pages), il appelle une routine **PPL wrapper**, qui effectue des validations puis bascule dans le domaine PPL. En dehors de ce domaine, les pages protégées sont effectivement en lecture seule ou non modifiables par le noyau principal.
- Pendant l'entrée en PPL, les mappings APRR sont ajustés pour que les pages mémoire dans la région PPL soient **exécutables & modifiables** au sein de PPL. À la sortie, elles sont remises en lecture seule / non modifiables. Cela garantit que seules des routines PPL correctement auditées peuvent écrire sur les pages protégées.
- Hors PPL, les tentatives du code noyau pour écrire sur ces pages protégées provoqueront une fault (permission denied) car le mapping APRR pour ce domaine de code n'autorise pas l'écriture.

#### Catégories de pages protégées

Les pages que PPL protège typiquement incluent :

- Structures de tables de pages (entrées des tables de traduction, métadonnées de mapping)
- Pages de code du noyau, en particulier celles contenant une logique critique
- Métadonnées de signature de code (trust caches, blobs de signature)
- Tables d'entitlements, tables d'application des signatures
- Autres structures noyau à haute valeur où un patch permettrait de contourner les vérifications de signature ou de manipuler des credentials

L'idée est que même si la mémoire du noyau est totalement contrôlée, l'attaquant ne peut pas simplement patcher ou réécrire ces pages, sauf s'il compromet aussi les routines PPL ou contourne PPL.

#### Contournements et vulnérabilités connus

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

- Un article public de Project Zero décrit un contournement impliquant des **entrées TLB obsolètes**.
- L'idée :

1. Allouer deux pages physiques A et B, les marquer comme pages PPL (donc protégées).
2. Mapper deux adresses virtuelles P et Q dont les pages de table de traduction L3 proviennent de A et B.
3. Lancer un thread qui accède en continu à Q, maintenant son entrée TLB vivante.
4. Appeler `pmap_remove_options()` pour supprimer les mappings à partir de P ; en raison d'un bug, le code supprime par erreur les TTEs pour P et Q, mais invalide seulement l'entrée TLB pour P, laissant l'entrée obsolète de Q active.
5. Réutiliser B (la page de table de Q) pour mapper de la mémoire arbitraire (p.ex. des pages protégées par PPL). Comme l'entrée TLB obsolète mappe encore l'ancien mapping de Q, ce mapping reste valide pour ce contexte.
6. Grâce à cela, l'attaquant peut placer un mapping modifiable des pages protégées par PPL sans passer par l'interface PPL.

- Cet exploit nécessitait un contrôle fin du mapping physique et du comportement du TLB. Il démontre qu'une frontière de sécurité s'appuyant sur la correction des TLB/mapping doit être extrêmement prudente quant à l'invalidation des TLB et à la cohérence des mappings.

- Project Zero a commenté que des contournements de ce type sont subtils et rares, mais possibles dans des systèmes complexes. Ils considèrent néanmoins PPL comme une atténuation solide.

2. **Autres risques potentiels & contraintes**

- Si un exploit du noyau peut entrer directement dans les routines PPL (en appelant les wrappers PPL), il peut contourner les restrictions. Ainsi, la validation des arguments est critique.
- Des bugs dans le code PPL lui-même (p.ex. overflow arithmétique, vérifications de bornes) peuvent permettre des modifications hors limites à l'intérieur de PPL. Project Zero a observé qu'un tel bug dans `pmap_remove_options_internal()` a été exploité dans leur contournement.
- La frontière PPL est irrévocablement liée à l'application matérielle (APRR, memory controller), donc elle n'est aussi forte que l'implémentation matérielle.

#### Exemple
<details>
<summary>Exemple de code</summary>
Voici un pseudocode/une logique simplifiée montrant comment un noyau pourrait appeler PPL pour modifier des pages protégées:
</details>
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">c</span></div>

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

Le kernel peut effectuer de nombreuses opérations normales, mais ce n'est que via les routines ppl_call_* qu'il peut modifier des mappings protégés ou patcher du 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>

#### Limitations & défis

- **Intrablock overflows**: Si l'overflow reste dans la même allocation (ne franchit pas la frontière) et que le tag reste le même, le tag mismatch ne le détecte pas.
- **Tag width limitation**: Seuls quelques bits (p. ex. 4 bits, ou petit domaine) sont disponibles pour le tag — espace de noms limité.
- **Side-channel leaks**: Si les bits de tag peuvent être leaked (via le cache / l'exécution spéculative), un attaquant peut apprendre les tags valides et contourner. L'enforcement de confidentialité des tags d'Apple vise à atténuer cela.
- **Performance overhead**: Les vérifications de tag à chaque load/store ajoutent un coût ; Apple doit optimiser le matériel pour réduire cette surcharge.
- **Compatibility & fallback**: Sur du hardware plus ancien ou des parties ne supportant pas EMTE, il doit exister un fallback. Apple affirme que MIE n'est activé que sur les appareils disposant du support.
- **Complex allocator logic**: L'allocator doit gérer les tags, le retagging, aligner les frontières et éviter les collisions de mis-tag. Des bugs dans la logique de l'allocator pourraient introduire des vulnérabilités.
- **Mixed memory / hybrid areas**: Certaines zones mémoire peuvent rester untagged (legacy), rendant l'interopérabilité plus délicate.
- **Speculative / transient attacks**: Comme pour beaucoup de protections microarchitecturales, l'exécution spéculative ou les fusions de micro-op peuvent contourner les vérifications de façon transitoire ou leak des bits de tag.
- **Limited to supported regions**: Apple pourrait n'appliquer EMTE que dans des zones sélectives et à haut risque (kernel, sous-systèmes critiques pour la sécurité), pas universellement.

---

## Principales améliorations / différences par rapport au MTE standard

Voici les améliorations et changements mis en avant par Apple :

| Fonctionnalité | Original MTE | EMTE (amélioré par Apple) / MIE |
|---|---|---|
| **Check mode** | Prend en charge les modes synchrone et asynchrone. En async, les tag mismatches sont signalés plus tard (retardés) | Apple insiste sur le **mode synchrone** par défaut — les tag mismatches sont détectés immédiatement, sans fenêtre de délai/course autorisée. |
| **Coverage of non-tagged memory** | Les accès à la mémoire non-tagged (p. ex. globals) peuvent contourner les vérifications dans certaines implémentations | EMTE exige que les accès depuis une région tagged vers de la mémoire non-tagged valident aussi la connaissance du tag, rendant le contournement par mélange d'allocations plus difficile. |
| **Tag confidentiality / secrecy** | Les tags peuvent être observables ou leak via des side channels | Apple ajoute **Tag Confidentiality Enforcement**, qui tente d'empêcher la leakage des valeurs de tag (via des side-channels spéculatifs, etc.). |
| **Allocator integration & retagging** | MTE confie une grande partie de la logique d'allocator au software | Les allocators typés sécurisés d'Apple (kalloc_type, xzone malloc, etc.) s'intègrent à EMTE : quand la mémoire est allouée ou libérée, les tags sont gérés à granularité fine. |
| **Always-on by default** | Sur de nombreuses plateformes, MTE est optionnel ou désactivé par défaut | Apple active EMTE / MIE par défaut sur le hardware supporté (p. ex. iPhone 17 / A19) pour le kernel et de nombreux processus user. |

Parce qu'Apple contrôle à la fois le hardware et la pile software, elle peut appliquer EMTE strictement, éviter les écueils de performance et combler les failles de side-channel.

---

## Comment EMTE fonctionne en pratique (Apple / MIE)

Voici une description à plus haut niveau du fonctionnement d'EMTE dans la configuration MIE d'Apple :

1. **Tag assignment**
- Quand la mémoire est allouée (p. ex. dans le kernel ou en user space via des secure allocators), un **secret tag** est assigné à ce bloc.
- Le pointeur renvoyé à l'user ou au kernel inclut ce tag dans ses high bits (en utilisant TBI / top byte ignore mechanisms).

2. **Tag checking on access**
- Chaque fois qu'un load ou un store est exécuté avec un pointeur, le hardware vérifie que le tag du pointeur correspond au tag du bloc mémoire (allocation tag). En cas de mismatch, il faulte immédiatement (puisque synchrone).
- Parce que c'est synchrone, il n'y a pas de fenêtre de détection différée.

3. **Retagging on free / reuse**
- Lorsque la mémoire est freed, l'allocator change le tag du bloc (ainsi les anciens pointeurs avec de vieux tags ne correspondent plus).
- Un pointeur use-after-free aura donc un tag obsolète et provoquera un mismatch à l'accès.

4. **Neighbor-tag differentiation to catch overflows**
- Les allocations adjacentes reçoivent des tags distincts. Si un buffer overflow déborde dans la mémoire du voisin, le tag mismatch provoque un fault.
- Ceci est particulièrement efficace pour attraper les petits overflows qui franchissent une frontière.

5. **Tag confidentiality enforcement**
- Apple doit empêcher que les valeurs de tag soient leaked (car si un attaquant apprend le tag, il pourrait fabriquer des pointeurs avec les bons tags).
- Ils intègrent des protections (contrôles microarchitecturaux / spéculatifs) pour éviter la side-channel leakage des bits de tag.

6. **Kernel and user-space integration**
- Apple utilise EMTE non seulement en user-space mais aussi dans les composants critiques du kernel/OS (pour protéger le kernel contre la corruption mémoire).
- Le hardware/OS assure que les règles de tag s'appliquent même lorsque le kernel s'exécute au nom de l'user space.

Parce qu'EMTE est intégré dans MIE, Apple utilise EMTE en mode synchrone sur les surfaces d'attaque clés, et non comme option ou mode debug.

---

## Exception handling in XNU

Lorsqu'une **exception** survient (p. ex., `EXC_BAD_ACCESS`, `EXC_BAD_INSTRUCTION`, `EXC_CRASH`, `EXC_ARM_PAC`, etc.), la **Mach layer** du kernel XNU est responsable de son interception avant qu'elle ne devienne un **signal** de type UNIX (comme `SIGSEGV`, `SIGBUS`, `SIGILL`, ...).

Ce processus implique plusieurs couches de propagation et de gestion d'exception avant d'atteindre l'user space ou d'être convertie en signal BSD.


### Exception Flow (High-Level)

1.  Le CPU déclenche une exception synchrone (p. ex., déréférencement d'un pointeur invalide, PAC failure, instruction illégale, etc.).

2.  Le trap handler bas niveau s'exécute (`trap.c`, `exception.c` dans les sources XNU).

3.  Le trap handler appelle `exception_triage()`, le cœur de la gestion des exceptions Mach.

4.  `exception_triage()` décide comment router l'exception :

-   D'abord vers le **thread's exception port**.

-   Puis vers le **task's exception port**.

-   Puis vers le **host's exception port** (souvent `launchd` ou `ReportCrash`).

Si aucun de ces ports ne gère l'exception, le kernel peut :

-   **Le convertir en signal BSD** (pour les processus user-space).

-   **Panic** (pour les exceptions kernel-space).


### Fonction centrale : `exception_triage()`

La fonction `exception_triage()` achemine les exceptions Mach le long de la chaîne de handlers possibles jusqu'à ce que l'un s'en occupe ou que l'exception soit finalement fatale. Elle est définie dans `osfmk/kern/exception.c`.
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">c</span></div>

```c
void exception_triage(exception_type_t exception, mach_exception_data_t code, mach_msg_type_number_t codeCnt);

Flux d'appels typique :

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

Si tout échoue → géré par bsd_exception() → traduit en un signal comme SIGSEGV.

Ports d'exception

Chaque objet Mach (thread, task, host) peut enregistrer des ports d'exception, vers lesquels les messages d'exception sont envoyés.

Ils sont définis par l'API :

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

Chaque port d'exception possède :

• Un masque (quelles exceptions il veut recevoir)
• Un port name (Mach port pour recevoir les messages)
• Un behavior (comment le noyau envoie le message)
• Un flavor (quel état du thread inclure)

Débogueurs et gestion des exceptions

Un debugger (p.ex., LLDB) définit un exception port sur la tâche ou le thread cible, généralement en utilisant task_set_exception_ports().

Lorsque une exception survient :

• Le message Mach est envoyé au processus debugger.
• Le debugger peut décider de gérer (reprendre, modifier les registres, sauter l'instruction) ou ne pas gérer l'exception.
• Si le debugger ne la gère pas, l'exception est propagée au niveau suivant (task → host).

Flux de EXC_BAD_ACCESS

1. Le thread déréférence un pointeur invalide → le CPU génère un Data Abort.

2. Le gestionnaire de trap du noyau appelle exception_triage(EXC_BAD_ACCESS, ...).

3. Message envoyé à :

• Thread port → (le debugger peut intercepter le breakpoint).

• Si le debugger ignore → Task port → (gestionnaire au niveau process).

• Si ignoré → Host port (généralement ReportCrash).

4. Si personne ne gère → bsd_exception() traduit en SIGSEGV.

Exceptions PAC

Quand Pointer Authentication (PAC) échoue (incompatibilité de signature), une exception Mach spéciale est levée :

• EXC_ARM_PAC (type)
• Les codes peuvent inclure des détails (p.ex., type de clé, type de pointeur).

Si le binaire a le flag TFRO_PAC_EXC_FATAL, le noyau traite les échecs PAC comme fatals, contournant l'interception par le debugger. C'est pour empêcher des attaquants d'utiliser des debuggers pour contourner les vérifications PAC et c'est activé pour les platform binaries.

Breakpoints logiciels

Un breakpoint logiciel (int3 sur x86, brk sur ARM64) est implémenté en provoquant une faute délibérée.
Le debugger l'attrape via le exception port :

• Modifie le pointeur d'instruction ou la mémoire.
• Restaure l'instruction originale.
• Reprend l'exécution.

Ce même mécanisme permet de "capturer" une exception PAC — sauf si TFRO_PAC_EXC_FATAL est défini, auquel cas elle n'atteint jamais le debugger.

Conversion vers les signaux BSD

Si aucun gestionnaire n'accepte l'exception :

• Le noyau appelle task_exception_notify() → bsd_exception().

• Cela mappe les exceptions Mach en signaux :

Fichiers clés dans le code source XNU

• osfmk/kern/exception.c → Coeur de exception_triage(), exception_deliver_*().

• bsd/kern/kern_sig.c → Logique de livraison des signaux.

• osfmk/arm64/trap.c → Gestionnaires bas niveau des traps.

• osfmk/mach/exc.h → Codes d'exception et structures.

• osfmk/kern/task.c → Configuration des task exception ports.

Ancien kernel heap (ère pré-iOS 15 / pré-A12)

Le noyau utilisait un zone allocator (kalloc) divisé en "zones" de taille fixe.
Chaque zone ne stockait des allocations que d'une seule classe de taille.

D'après la capture d'écran :

Comment ça fonctionnait :

• Chaque requête d'allocation était arrondie vers le haut à la taille de zone la plus proche. (P.ex., une requête de 50 octets allait dans la zone kalloc.64).
• La mémoire dans chaque zone était conservée dans une freelist — les chunks libérés par le noyau retournaient dans cette zone.
• Si vous débordiez un buffer de 64 octets, vous écrasiez l'objet suivant dans la même zone.

C'est pour ça que le heap spraying / feng shui était si efficace : on pouvait prédire les voisins d'objets en pulvérisant des allocations de la même classe de taille.

La freelist

À l'intérieur de chaque zone kalloc, les objets libérés n'étaient pas rendus directement au système — ils allaient dans une freelist, une liste chaînée de chunks disponibles.

• Quand un chunk était free, le noyau écrivait un pointeur au début de ce chunk → l'adresse du prochain chunk libre dans la même zone.

• La zone conservait un pointeur HEAD vers le premier chunk libre.

• L'allocation utilisait toujours le HEAD courant :

1. Pop HEAD (retourne cette mémoire à l'appelant).

2. Met à jour HEAD = HEAD->next (stocké dans l'entête du chunk libéré).

• La libération poussait les chunks en retour :

• freed_chunk->next = HEAD

• HEAD = freed_chunk

Ainsi la freelist n'était qu'une liste chaînée construite à l'intérieur de la mémoire libérée elle-même.

État normal :

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)

Exploiter la freelist

Parce que les 8 premiers octets d'un free chunk = freelist pointer, un attaquant pourrait le corrompre:

1. Heap overflow into an adjacent freed chunk → overwrite its “next” pointer.

2. Use-after-free write into a freed object → overwrite its “next” pointer.

Then, on the next allocation of that size:

• L'allocator pops the corrupted chunk.
• Follows the attacker-supplied “next” pointer.
• Returns a pointer to arbitrary memory, enabling fake object primitives or 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 design made exploitation highly effective pre-hardening: predictable neighbors from heap sprays, raw pointer freelist links, and no type separation allowed attackers to escalate UAF/overflow bugs into arbitrary kernel memory control.

Heap Grooming / Feng Shui

Le but du Heap Grooming est de modeler la disposition du heap afin que, lorsqu’un attaquant déclenche un overflow ou un use-after-free, l’objet cible (victime) soit juste à côté d’un objet contrôlé par l’attaquant.
Ainsi, quand la corruption mémoire se produit, l’attaquant peut de manière fiable écraser l’objet victime avec des données contrôlées.

Étapes :

1. Spray allocations (fill the holes)

• Au fil du temps, le kernel heap se fragmente : certaines zones ont des trous où d’anciens objets ont été free.
• L’attaquant commence par effectuer de nombreuses allocations factices pour remplir ces espaces, de sorte que le heap devienne “compact” et prévisible.

2. Force new pages

• Une fois les trous remplis, les allocations suivantes doivent provenir de nouvelles pages ajoutées à la zone.
• Des pages fraîches signifient que les objets seront regroupés ensemble, et non dispersés dans de la mémoire fragmentée ancienne.
• Cela donne à l’attaquant un bien meilleur contrôle sur les voisins.

3. Place attacker objects

• L’attaquant effectue ensuite un nouveau spray, créant beaucoup d’objets contrôlés par l’attaquant dans ces nouvelles pages.
• Ces objets sont prévisibles en taille et en placement (puisqu’ils appartiennent tous à la même zone).

4. Free a controlled object (make a gap)

• L’attaquant libère délibérément un de ses propres objets.
• Cela crée un “trou” dans le heap, que l’allocator réutilisera ensuite pour la prochaine allocation de cette taille.

5. Victim object lands in the hole

• L’attaquant provoque maintenant le kernel pour allouer l’objet victime (celui qu’il veut corrompre).
• Étant donné que le trou est le premier emplacement disponible dans le freelist, la victime est placée exactement là où l’attaquant a free son objet.

6. Overflow / UAF into victim

• Maintenant l’attaquant a des objets contrôlés autour de la victime.
• En overflowant depuis un de ses propres objets (ou en réutilisant un objet libéré), il peut écraser de manière fiable les champs mémoire de la victime avec des valeurs choisies.

Pourquoi ça marche :

• Predictabilité de l’allocator de zone : les allocations de la même taille proviennent toujours de la même zone.
• Comportement du freelist : les nouvelles allocations réutilisent d’abord le chunk récemment free.
• Heap sprays : l’attaquant remplit la mémoire avec un contenu prévisible et contrôle la disposition.
• Résultat final : l’attaquant contrôle où l’objet victime atterrit et quelles données se trouvent à côté de lui.

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

Apple a durci l’allocator et rendu le heap grooming beaucoup plus difficile :

1. From Classic kalloc to kalloc_type

• Before: un unique zone kalloc.<size> existait pour chaque classe de taille (16, 32, 64, … 1280, etc.). Tout objet de cette taille y était placé → les objets de l’attaquant pouvaient se retrouver à côté d’objets kernel privilégiés.
• Now:
• Les objets kernel sont alloués depuis des typed zones (kalloc_type).
• Chaque type d’objet (ex. ipc_port_t, task_t, OSString, OSData) a sa propre zone dédiée, même s’ils ont la même taille.
• Le mapping entre type d’objet ↔ zone est généré par le kalloc_type system à la compilation.

Un attaquant ne peut plus garantir que des données contrôlées (OSData) se retrouvent adjacentes à des objets kernel sensibles (task_t) de la même taille.

2. Slabs and Per-CPU Caches

• Le heap est divisé en slabs (pages mémoire découpées en chunks de taille fixe pour cette zone).
• Chaque zone possède un cache per-CPU pour réduire la contention.
• Chemin d’allocation :

1. Essayer le cache per-CPU.
2. Si vide, prendre depuis le global freelist.
3. Si le freelist est vide, allouer un nouveau slab (une ou plusieurs pages).

• Avantage : cette décentralisation rend les heap sprays moins déterministes, puisque les allocations peuvent être satisfaites depuis les caches de différents CPUs.

3. Randomization inside zones

• Dans une zone, les éléments freed ne sont pas rendus dans un simple ordre FIFO/LIFO.
• XNU moderne utilise des encoded freelist pointers (safe-linking comme Linux, introduit ~iOS 14).
• Chaque pointer du freelist est XOR-encodé avec un cookie secret par zone.
• Cela empêche un attaquant de forger un faux pointer du freelist s’il obtient une primitive d’écriture.
• Certaines allocations sont randomisées dans leur placement à l’intérieur d’un slab, donc le spraying ne garantit pas l’adjacence.

4. Guarded Allocations

• Certains objets kernel critiques (ex. credentials, structures task) sont alloués dans des guarded zones.
• Ces zones insèrent des guard pages (mémoire non mappée) entre les slabs ou utilisent des redzones autour des objets.
• Tout overflow dans la guard page déclenche un fault → panic immédiat au lieu d’une corruption silencieuse.

5. Page Protection Layer (PPL) and SPTM

• Même si vous contrôlez un objet freed, vous ne pouvez pas modifier toute la mémoire kernel :
• PPL (Page Protection Layer) impose que certaines régions (ex. code signing data, entitlements) soient read-only même pour le kernel lui-même.
• Sur les devices A15/M2+, ce rôle est remplacé/amélioré par SPTM (Secure Page Table Monitor) + TXM (Trusted Execution Monitor).
• Ces couches matérielles forcées signifient que les attaquants ne peuvent pas escalader depuis une seule corruption de heap vers un patch arbitraire de structures de sécurité critiques.
• (Added / Enhanced) : aussi, PAC (Pointer Authentication Codes) est utilisé dans le kernel pour protéger les pointeurs (particulièrement les function pointers, vtables) de sorte que les falsifier ou les corrompre devienne plus difficile.
• (Added / Enhanced) : les zones peuvent appliquer zone_require / zone enforcement, c.-à-d. qu’un objet free ne peut être réinjecté que via sa zone typée correcte ; des frees cross-zone invalides peuvent paniquer ou être rejetés. (Apple évoque cela dans leurs posts sur memory safety)

6. Large Allocations

• Toutes les allocations ne passent pas par kalloc_type.
• Les requêtes très larges (au-dessus d’environ ~16 KB) contournent les typed zones et sont servies directement depuis le kernel VM (kmem) via des allocations de pages.
• Celles-ci sont moins prévisibles, mais aussi moins exploitables, car elles ne partagent pas de slabs avec d’autres objets.

7. Allocation Patterns Attackers Target

Même avec ces protections, les attaquants cherchent toujours :

• Reference count objects : si vous pouvez altérer les compteurs retain/release, vous pouvez provoquer des use-after-free.
• Objects with function pointers (vtables) : corrompre l’un d’eux donne toujours du contrôle de flux.
• Shared memory objects (IOSurface, Mach ports) : ils restent des cibles car ils font le pont user ↔ kernel.

Mais — contrairement à avant — vous ne pouvez plus simplement sprayer OSData et espérer le voir voisin d’un task_t. Il faut des bugs spécifiques au type ou des info leaks pour réussir.

Example: Allocation Flow in Modern Heap

Supposons que userspace appelle IOKit pour allouer un objet OSData :

1. Type lookup → OSData mappe à la zone kalloc_type_osdata (taille 64 bytes).
2. Check per-CPU cache for free elements.

• Si trouvé → retourner un élément.
• Si vide → aller au global freelist.
• Si freelist vide → allouer un nouveau slab (page de 4KB → 64 chunks de 64 bytes).

3. Retourner le chunk à l’appelant.

Freelist pointer protection :

• Chaque chunk freed stocke l’adresse du prochain chunk libre, mais encodée avec une clé secrète.
• Écraser ce champ avec des données contrôlées par l’attaquant ne fonctionnera pas à moins de connaître la clé.

Comparison Table

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

Dans les versions récentes des OS Apple (surtout iOS 17+), Apple a introduit un allocator userland plus sécurisé, xzone malloc (XZM). C’est l’analogue user-space de kalloc_type du kernel, appliquant la conscience de type, l’isolation des métadonnées et des protections de memory tagging.

Goals & Design Principles

• Type segregation / type awareness : grouper les allocations par type ou usage (pointer vs data) pour prévenir les type confusion et la réutilisation cross-type.
• Metadata isolation : séparer les métadonnées du heap (p.ex. free lists, bits de taille/état) des payloads d’objet pour que les écritures hors bornes corrompent moins probablement les métadonnées.
• Guard pages / redzones : insérer des pages non mappées ou du padding autour des allocations pour détecter les overflows.
• Memory tagging (EMTE / MIE) : travailler en conjonction avec le tagging matériel pour détecter use-after-free, out-of-bounds et accès invalides.
• Scalable performance : maintenir une faible surcharge, éviter la fragmentation excessive, et supporter de nombreuses allocations par seconde avec une latence basse.

Architecture & Components

Voici les éléments principaux de l’allocator xzone :

Segment Groups & Zones

• Segment groups partitionnent l’espace d’adressage par catégories d’usage : ex. data, pointer_xzones, data_large, pointer_large.
• Chaque segment group contient des segments (plages VM) qui hébergent les allocations pour cette catégorie.
• Associé à chaque segment se trouve une metadata slab (zone VM séparée) qui stocke les métadonnées (p.ex. bits free/used, classes de taille) pour ce segment. Cette metadata out-of-line (OOL) garantit que les métadonnées ne sont pas mélangées aux payloads d’objet, atténuant la corruption par overflow.
• Les segments sont découpés en chunks (slices) qui sont à leur tour subdivisés en blocks (unités d’allocation). Un chunk est lié à une classe de taille et à un segment group spécifique (c.-à-d. tous les blocks d’un chunk partagent la même taille & catégorie).
• Pour les allocations petites/moyennes, on utilise des chunks de taille fixe ; pour les grandes/très grandes, on peut mapper séparément.

Chunks & Blocks

• Un chunk est une région (souvent plusieurs pages) dédiée aux allocations d’une classe de taille dans un group.
• À l’intérieur d’un chunk, les blocks sont des emplacements disponibles pour les allocations. Les blocks freed sont suivis via la metadata slab — p.ex. via des bitmaps ou des free lists stockés out-of-line.
• Entre les chunks (ou à l’intérieur), des guard slices / guard pages peuvent être insérées (p.ex. slices non mappées) pour détecter les écritures hors bornes.

Type / Type ID

• Chaque site d’allocation (ou appel à malloc, calloc, etc.) est associé à un type identifier (un malloc_type_id_t) qui encode le type d’objet alloué. Cet type ID est passé à l’allocator, qui l’utilise pour sélectionner quel zone / segment servira l’allocation.
• De ce fait, même si deux allocations ont la même taille, elles peuvent aller dans des zones totalement différentes si leurs types diffèrent.
• Dans les premières versions d’iOS 17, toutes les APIs (p.ex. CFAllocator) n’étaient pas entièrement type-aware ; Apple a adressé certaines de ces faiblesses dans iOS 18.

Allocation & Freeing Workflow

Voici un flux haut-niveau de l’allocation et du freeing dans xzone :

1. malloc / calloc / realloc / typed alloc est invoqué avec une taille et un type ID.
2. L’allocator utilise le type ID pour choisir le segment group / zone approprié.
3. Dans cette zone/segment, il cherche un chunk qui a des blocks libres de la taille demandée.

• Il peut consulter des caches locaux / per-thread pools ou des free block lists depuis la metadata.
• Si aucun block libre n’est disponible, il peut allouer un nouveau chunk dans cette zone.

4. La metadata slab est mise à jour (bit free effacé, bookkeeping).
5. Si le memory tagging (EMTE) est actif, le block retourné reçoit un tag, et la metadata est mise à jour pour refléter son état “live”.
6. Quand free() est appelé :

• Le block est marqué comme freed dans la metadata (via l’OOL slab).
• Le block peut être placé dans une free list ou poolé pour réutilisation.
• Optionnellement, le contenu du block peut être effacé ou empoisonné pour réduire les fuites de données ou l’exploitation de UAF.
• Le tag matériel associé au block peut être invalidé ou re-tagged.
• Si un chunk entier devient libre (tous les blocks freed), l’allocator peut reclaim ce chunk (le unmaper ou le rendre à l’OS) sous pression mémoire.

Security Features & Hardening

Voici les défenses intégrées dans xzone userland :

Interaction with Memory Integrity Enforcement (MIE / EMTE)

• Le MIE d’Apple (Memory Integrity Enforcement) est le framework hardware + OS qui met l’Enhanced Memory Tagging Extension (EMTE) en mode toujours actif et synchrone sur les surfaces d’attaque majeures.
• L’allocator xzone est une fondation fondamentale de MIE en user space : les allocations faites via xzone reçoivent des tags, et les accès sont vérifiés par le hardware.
• Dans MIE, l’allocator, l’assignation des tags, la gestion des métadonnées et l’application de la confidentialité des tags sont intégrés pour garantir que les erreurs mémoire (p.ex. lectures stale, OOB, UAF) sont détectées immédiatement, et non exploitées plus tard.

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.

iMessage/Media Parser Zero-Click Chains

Imessage Media Parser Zero Click Coreaudio Pac Bypass