; 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>Örnek</summary>
A buffer overflow, stack üzerindeki bir return adresini ezerek çalışır. Saldırgan hedef gadget adresini yazar ama doğru PAC'ı hesaplayamaz. Fonksiyon döndüğünde, CPU’nun `AUTIA` talimatı PAC uyuşmazlığı nedeniyle hata verir. Zincir başarısız olur.
Project Zero’nun A12 (iPhone XS) üzerine analizi, Apple’ın PAC kullanımını ve bir saldırganın memory read/write primitive’a sahip olması durumunda PAC’ları nasıl sahteleyebileceğini gösterdi.
</details>


### 9. **Branch Target Identification (BTI)**
**ARMv8.5 ile tanıtıldı (daha yeni donanım)**
BTI, **indirect branch target'ları** kontrol eden bir donanım özelliğidir: `blr` veya dolaylı call/jump'lar yürütülürken, hedef bir **BTI landing pad** (`BTI j` veya `BTI c`) ile başlamalıdır. Landing pad içermeyen gadget adreslerine atlamak bir istisna tetikler.

LLVM’nin uygulama notları BTI talimatlarının üç varyantını ve bunların branch türleriyle nasıl eşlendiğini not eder.

| BTI Variant | Hangi şeylere izin verir (hangi branch türleri) | Tipik yerleştirme / kullanım |
|-------------|----------------------------------------|-------------------------------|
| **BTI C** | *call*-stil dolaylı branch hedefleri (ör. `BLR`, veya X16/X17 kullanılarak `BR`) | Dolaylı olarak çağrılabilecek fonksiyonların girişine konur |
| **BTI J** | *jump*-stil branch hedefleri (ör. tail call için kullanılan `BR`) | jump tablolarından veya tail-call'larla ulaşılabilen blokların başına konur |
| **BTI JC** | Hem C hem J gibi davranır | Hem call hem jump branch'leri tarafından hedef alınabilir |

- Branch target enforcement ile derlenen kodda, derleyiciler her geçerli indirect-branch hedefinde (fonksiyon başlangıçları veya jump ile erişilebilen bloklar) bir BTI talimatı (C, J veya JC) ekler, böylece dolaylı branch'lar sadece bu yerlere başarılı şekilde gidebilir.
- **Direct branches / calls** (yani sabit adresli `B`, `BL`) BTI tarafından **kısıtlanmaz**. Varsayım şudur: kod sayfaları güvenilirdir ve saldırgan bunları değiştiremez (dolayısıyla direct branch'ler güvenlidir).
- Ayrıca, **RET / return** talimatları genelde BTI ile kısıtlanmaz çünkü dönüş adresleri PAC veya return signing mekanizmalarıyla korunur.

#### Mekanizma ve uygulama

- CPU, bir sayfa “guarded / BTI-enabled” olarak işaretlenmişken bir **indirect branch (BLR / BR)** decode ettiğinde, hedef adresin ilk talimatının geçerli bir BTI (izin verilen C, J veya JC) olup olmadığını kontrol eder. Değilse bir **Branch Target Exception** oluşur.
- BTI talimatı kodlaması, daha önce NOPs için ayrılmış opcode’ları yeniden kullanacak şekilde tasarlanmıştır (önceki ARM versiyonlarında). Bu nedenle BTI-etkin ikili dosyalar geriye dönük uyumludur: BTI desteklemeyen donanımda bu talimatlar NOP gibi davranır.
- BTI ekleyen derleyici pass’ları yalnızca ihtiyaç olan yerlere yerleştirir: dolaylı olarak çağrılabilecek fonksiyonlar veya jump'larla hedeflenen basic block'lar.
- Bazı yamalar ve LLVM kodu gösteriyor ki BTI tüm basic block'lar için eklenmez — sadece potansiyel branch hedefleri olanlar için (ör. switch / jump tablolarından gelenler).

#### BTI + PAC sinerjisi

PAC, pointer değerini (kaynağı) korur — dolaylı çağrıların/dönüşlerin zincirinin değiştirilmediğini garanti eder.

BTI, geçerli bir pointer olsa bile hedefin yalnızca doğru işaretlenmiş giriş noktalarına işaret etmesi gerektiğini sağlar.

Birlikte, bir saldırganın hem doğru PAC'a sahip geçerli bir pointer hem de hedefte BTI bulunması gerekir. Bu, exploit gadget’ları oluşturmayı zorlaştırır.

#### Örnek


<details>
<summary>Örnek</summary>
Bir exploit, `0xABCDEF` adresindeki ve `BTI c` ile başlamayan bir gadget'a pivot etmeye çalışır. CPU, `blr x0` yürütüldüğünde hedefi kontrol eder ve talimat hizalaması geçerli bir landing pad içermediği için hata verir. Böylece birçok gadget, BTI öneki içermedikçe kullanılamaz hale gelir.
</details>


### 10. **Privileged Access Never (PAN) & Privileged Execute Never (PXN)**
**Daha yeni ARMv8 uzantılarında / iOS desteğinde tanıtıldı (sertleştirilmiş kernel için)**

#### PAN (Privileged Access Never)

- **PAN**, **ARMv8.1-A** ile tanıtılan ve **privileged code** (EL1 veya EL2) tarafından **user-accessible (EL0)** olarak işaretlenmiş belleğin **okunmasını veya yazılmasını** engelleyen bir özelliktir; PAN açık değilse bu erişime izin verilir.
- Fikir: kernel kandırılsa veya ele geçirilse bile, user-space pointer’larını rastgele dereference edemez; önce PAN'ı *temizlemelidir*, böylece `ret2usr` tarzı exploit veya user-kontrolündeki buffer'ların kötüye kullanımı riski azalır.
- PAN etkin olduğunda (PSTATE.PAN = 1), “EL0 tarafından erişilebilir” olarak işaretlenmiş sanal adreslere yapılan herhangi bir privileged load/store talimatı bir **permission fault** tetikler.
- Kernel, meşru olarak user-space belleğine erişmesi gerektiğinde (ör. user buffer'lara veri kopyalama), PAN'ı **geçici olarak devre dışı bırakmalı** (veya “unprivileged load/store” talimatlarını kullanmalı) ki bu erişime izin versin.
- Linux on ARM64'te PAN desteği yaklaşık 2015 civarında eklendi: kernel yamaları bu özelliği algılayıp `get_user` / `put_user` gibi çağrıları PAN'ı temizleyen varyantlarla değiştirdi.

**Önemli nüans / sınırlama / bug**
- Siguza ve diğerleri tarafından belirtildiği gibi, ARM tasarımındaki bir spesifikasyon hatası (veya belirsiz davranış), **execute-only user mappings** (`--x`) için PAN'ın **tetiklenmemesine** yol açabilir. Başka bir deyişle, bir user sayfası sadece yürütülebilir ve okuma izni yoksa, kernel’in okuma denemesi PAN tarafından engellenmeyebilir çünkü mimari “EL0 tarafından erişilebilir”i okunabilir izin gerektiriyor, sadece yürütülebilir olmasını değil. Bu, belirli konfigürasyonlarda PAN bypass'ına yol açar.
- Bu yüzden, eğer iOS / XNU execute-only user sayfalarına izin veriyorsa (ör. bazı JIT veya code-cache düzenlemeleri gibi), kernel PAN etkin olsa bile bu sayfalardan yanlışlıkla okuma yapabilir. Bu, ARMv8+ sistemlerde bilinen ince bir kullanılabilir alan.

#### PXN (Privileged eXecute Never)

- **PXN**, page table girdilerinde (leaf veya block entry'lerde) bulunan bir bayraktır ve sayfanın **privileged modda yürütülemeyeceğini** (ör. EL1 yürütürken) belirtir.
- PXN, kernel’in (veya herhangi bir privileged kodun) kontrolü tamamen ele geçirilse bile user-space sayfalarından talimat yürütmesini engeller. Özetle, kernel seviyesinde kontrol akışının user belleğine yönlendirilmesini durdurur.
- PAN ile birlikte şunu sağlar:
1. Kernel varsayılan olarak user veri sayfalarını okuyamaz/yazamaz (PAN)
2. Kernel user kodunu çalıştıramaz (PXN)
- ARMv8 page table formatında, leaf entry’lerin attribute bitleri içinde bir `PXN` biti (ve ayrıca unprivileged için `UXN`) bulunur.

Dolayısıyla kernel’in bozuk bir function pointer ile user belleğine yönelmesi durumunda, PXN biti bir hata tetikleyecektir.

#### Bellek-izin modeli & PAN ve PXN’in page table bitlerine eşlenmesi

PAN / PXN’in nasıl çalıştığını anlamak için ARM’ın translation ve izin modelinin nasıl çalıştığını (basitleştirilmiş) görmek gerekir:

- Her sayfa veya block entry’si, read/write ve privileged vs unprivileged için **AP[2:1]** ve yürütmeyi engelleme için **UXN / PXN** bitleri gibi attribute alanlarına sahiptir.
- PSTATE.PAN 1 olduğunda, donanım değişmiş semantikleri uygular: EL0 tarafından erişilebilir olarak işaretlenmiş sayfalara privileged erişimler engellenir (fault).
- Bahsedilen bug nedeniyle, yalnızca yürütülebilir (okunamaz) olarak işaretlenmiş sayfalar bazı implementasyonlarda “EL0 tarafından erişilebilir” olarak sayılmayabilir, dolayısıyla PAN atlatılabilir.
- Bir sayfanın PXN biti set edilmişse, talimat fetch’i daha yüksek ayrıcalık seviyesinden gelse bile yürütme yasaklanır.

#### Sertleştirilmiş bir OS (ör. iOS / XNU) içinde PAN / PXN’in kernel kullanımına dair

Sertleştirilmiş bir kernel tasarımında (Apple’ın kullanabileceği şekilde):

- Kernel varsayılan olarak PAN’ı etkinleştirir (böylece privileged kod kısıtlanır).
- Meşru olarak user buffer’larına erişmesi gereken yollar (ör. syscall buffer copy, I/O, user pointer ile read/write), kernel PAN’ı geçici olarak **devre dışı bırakır** veya user belleğe erişimi aşan özel talimatlar kullanır.
- User veri erişimi tamamlandıktan sonra PAN tekrar etkinleştirilmelidir.
- PXN page table aracılığıyla uygulanır: user sayfalarının PXN = 1 olarak ayarlanması (böylece kernel bunlarda yürütme yapamaz), kernel sayfalarının PXN’si 0 olur (kernel kodu yürütülebilir).
- Kernel, kontrol akışının user bellek bölgelerine yol açmayacağından emin olmalıdır — aksi halde “user-kontrolündeki shellcode’a atlama” gibi exploit zincirleri engellenemez.

Execute-only sayfalar üzerinden PAN atlatması nedeniyle, gerçek bir sistemde Apple execute-only user sayfalarını devre dışı bırakabilir veya spesifikasyon zayıflığına yönelik yamalar uygulayabilir.

#### Saldırı yüzeyleri, bypass'lar ve hafifletmeler

- **Execute-only sayfalar yoluyla PAN bypass**: yukarıda tartışıldığı gibi, spesifikasyon bir boşluk bırakır: okuma izni olmayan sadece yürütülebilir user sayfaları bazı implementasyonlarda “EL0 tarafından erişilebilir” sayılmayabilir; böylece PAN kernel okumasını engellemez. Bu, saldırganın “execute-only” bölümler aracılığıyla veri beslemesine izin verebilir.
- **Zamana dayalı pencere exploit'i**: kernel PAN'ı gerekenden uzun süre devre dışı bırakırsa, bir yarış veya kötü niyetli yol bu pencereyi kullanarak istenmeyen user bellek erişimleri gerçekleştirebilir.
- **Yeniden etkinleştirmeyi unutma**: eğer kod yolları PAN'ı tekrar etkinleştirmeyi unutursa, sonraki kernel işlemleri yanlışlıkla user belleğe erişebilir.
- **PXN yanlış yapılandırması**: page table'lar user sayfalarında PXN'yi ayarlamazsa veya user kod sayfalarını hatalı şekilde map ederse, kernel user-space kodunu çalıştırmaya ikna edilebilir.
- **Spekülasyon / yan-kanallar**: spekülatif atlamalara benzer şekilde, mikro-mimari yan-etkiler PAN / PXN kontrollerinin geçici olarak ihlal edilmesine sebep olabilir (ancak bu tür saldırılar CPU tasarımına çok bağımlıdır).
- **Karmaşık etkileşimler**: JIT, shared memory, just-in-time code bölgeleri gibi gelişmiş özelliklerde kernel, user-mapped bölgeler için belirli erişimlere izin vermek zorunda olabilir; PAN/PXN kısıtları altında bunları güvenli şekilde tasarlamak karmaşıktır.

#### Örnek

<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

Eğer kernel o kullanıcı sayfasında PXN'i **ayarlamamış** olsaydı, o branch başarılı olabilir — ki bu güvensiz olurdu.

Kernel kullanıcı bellek erişiminden sonra PAN'i yeniden etkinleştirmeyi unutursa, ilerideki kernel mantığının istemeden rastgele kullanıcı belleğini okuma/yazma yapabileceği bir pencere açar.

Eğer kullanıcı işaretçisi execute-only bir sayfaya (sadece yürütme izni olan, okuma/yazma olmayan kullanıcı sayfası) işaret ediyorsa, PAN spesifikasyon hatası altında, `ldr W2, [X1]` PAN etkin olsa bile **hata vermeyebilir**, uygulamaya bağlı olarak bir atlatma (bypass) istismarına olanak sağlayabilir.

</details>

<details>
<summary>Example</summary>
Bir kernel açığı, kullanıcı tarafından sağlanan bir fonksiyon işaretçisini alıp kernel bağlamında çağırmaya çalışır (yani `call user_buffer`). PAN/PXN altında, bu işlem yasaklanır veya hata verir.
</details>

---

### 11. **Top Byte Ignore (TBI) / Pointer Tagging**
**ARMv8.5 ve sonrası (veya isteğe bağlı uzantı) üzerine tanıtıldı**
TBI, 64-bit bir işaretçinin en yüksek baytının adres çevirme tarafından yok sayılmasını sağlar. Bu sayede OS veya donanım, işaretçinin üst baytına **tag bitleri** gömebilir ve gerçek adresi etkilemez.

- TBI, **Top Byte Ignore** (bazen *Address Tagging* olarak da anılır) anlamına gelir. Bu, birçok ARMv8+ uygulamasında bulunan bir donanım özelliğidir ve 64-bit bir işaretçinin en üst 8 bitini (bits 63:56) **adres çevirme / load/store / instruction fetch** sırasında yok sayar.
- Pratikte CPU, `0xTTxxxx_xxxx_xxxx` (burada `TT` = üst bayt) biçimindeki bir işaretçiyi adres çevirme açısından `0x00xxxx_xxxx_xxxx` olarak ele alır; üst bayt maskelenir (strip edilir). Üst bayt yazılım tarafından **metadata / tag bitleri** saklamak için kullanılabilir.
- Bu, her işaretçiye bir byte’lık etiket gömmek için yazılıma “ücretsiz” bir kanal sağlar; bu işlem bellek lokasyonunu değiştirmez.
- Mimari, load/store ve instruction fetch işlemlerinin, gerçek bellek erişimi yapılmadan önce işaretçinin üst baytını maskelenmiş (yani tag çıkarılmış) şekilde işlemesini garanti eder.

Böylece TBI, **mantıksal işaretçi**yi (işaretçi + tag) bellek işlemlerinde kullanılan **fiziksel adresten** ayırır.

#### Why TBI: Use cases and motivation

- **Pointer tagging / metadata**: Üst baytta ek metadata (ör. obje tipi, versiyon, bounds, bütünlük tagleri) saklayabilirsiniz. İşaretçiyi daha sonra kullandığınızda, donanım düzeyinde tag görmezden gelindiği için bellek erişimi için elle strip etmenize gerek kalmaz.
- **Memory tagging / MTE (Memory Tagging Extension)**: TBI, MTE’nin üzerine inşa olduğu temel donanım mekanizmasıdır. ARMv8.5’te, **Memory Tagging Extension** işaretçinin bits 59:56'sını bir **mantıksal tag** olarak kullanır ve bunu bellekte saklanan bir **allocation tag** ile karşılaştırır.
- **Geliştirilmiş güvenlik & bütünlük**: TBI'yi pointer authentication (PAC) veya çalışma zamanı kontrolleri ile birleştirerek, sadece işaretçi değerinin değil aynı zamanda tagin de doğru olmasını zorlayabilirsiniz. Bir saldırgan işaretçiyi doğru tag olmadan üzerine yazar ise tag uyuşmazlığı oluşur.
- **Uyumluluk**: TBI isteğe bağlıdır ve tag bitleri donanım tarafından yok sayıldığı için, mevcut tag içermeyen kod normal şekilde çalışmaya devam eder. Tag bitleri eski kod için etkili olarak “önemsiz” bitler olur.

#### Example
<details>
<summary>Example</summary>
Bir fonksiyon işaretçisi üst baytına bir tag (ör. `0xAA`) içeriyordu. Bir exploit işaretçinin düşük bitlerini ezdi ama tagi gözardı etti; kernel doğrulama veya temizleme yaptığında işaretçi başarısız olur veya reddedilir.
</details>

---

### 12. **Page Protection Layer (PPL)**
**Geç dönem iOS / modern donanımda tanıtıldı (iOS ~17 / Apple silicon / üst seviye modeller)** (bazı raporlar PPL’yi macOS / Apple silicon civarında gösterse de, Apple benzer korumaları iOS’a da getiriyor)

- PPL, bir **kernel içi koruma sınırı** olarak tasarlandı: kernel (EL1) ele geçirilmiş ve okuma/yazma yetkisine sahip olsa bile, **belirli hassas sayfaları serbestçe değiştirememesi** gerekir (özellikle page table'lar, code-signing metadata, kernel kod sayfaları, entitlements, trust cache'ler vb.).
- Pratikte bir **“kernel içinde kernel”** yaratır — korunan sayfaları sadece değiştirebilen daha küçük, güvenilir bir bileşen (PPL) vardır. Diğer kernel kodu değişiklik yapmak için PPL rutinlerini çağırmak zorundadır.
- Bu, kernel exploitleri için saldırı yüzeyini azaltır: kernel modunda tam rastgele R/W/execute elde edilmiş olsa bile, saldırgan kritik yapıların değiştirilmesi için ya PPL alanına girmeli ya da PPL’i atlatmalıdır.
- Yeni Apple silicon (A15+ / M2+) üzerinde Apple, birçok durumda sayfa tablosu koruması için PPL’nin yerine **SPTM (Secure Page Table Monitor)** getirmeye geçiş yapıyor.

Aşağıda PPL’in kamuya açık analizlere dayanarak nasıl çalıştığına ilişkin inanışlar yer almaktadır:

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

- Apple donanımı, page table entry’lerin (PTE) tam izin bitleri yerine küçük indeksler içermesine izin veren **APRR (Access Permission ReRouting)** adlı bir mekanizma kullanır. Bu indeksler APRR registerları aracılığıyla gerçek izne eşlenir. Bu, domain başına izinlerin dinamik olarak yeniden eşlenmesine izin verir.
- PPL, APRR’yi kernel bağlamı içinde ayrıcalıkları ayırmak için kullanır: yalnızca PPL domaini, indeksler ile efektif izinler arasındaki eşlemeyi güncelleyebilir. Yani non-PPL kernel kodu bir PTE yazdığında veya izin bitlerini çevirmeye çalıştığında, APRR mantığı bunu engeller (veya salt okunur eşleme uygular).
- PPL kodu kendisi kısıtlı bir bölgede (ör. `__PPLTEXT`) çalışır; bu bölge normalde giriş kapıları geçici olarak izin verene kadar yürütülebilir veya yazılabilir değildir. Kernel, hassas işlemleri gerçekleştirmek için PPL entry noktalarını (“PPL rutinleri”) çağırır.

#### Gate / Entry & Exit

- Kernel korunan bir sayfayı değiştirmesi gerektiğinde (ör. bir kernel kod sayfasının izinlerini değiştirmek veya page table’ları değiştirmek), doğrulama yapan ve PPL alanına geçiş yapan bir **PPL wrapper** rutinini çağırır. Bu alanın dışında korunan sayfalar esasen ana kernel tarafından değiştirilemez veya yazılamaz.
- PPL girişinde, APRR eşlemeleri PPL bölgesindeki bellek sayfalarının PPL içinde **executable & writable** olacak şekilde ayarlanır. Çıkışta ise tekrar salt okunur / yazılamaz hale getirilir. Bu, yalnızca iyi denetlenmiş PPL rutinlerinin korunan sayfalara yazmasına izin verir.
- PPL dışındayken, kernel kodunun bu korunan sayfalara yazma girişimleri hata verir (izin reddedildi) çünkü o kod domaini için APRR eşlemesi yazma izni tanımaz.

#### Protected page categories

PPL’in tipik olarak koruduğu sayfalar şunlardır:

- Page table yapıları (translation table entries, mapping metadata)
- Kernel kod sayfaları, özellikle kritik mantığı içerenler
- Code-sign metadata (trust cache’ler, signature blob’ları)
- Entitlement tabloları, signature enforcement tabloları
- İmzalama kontrollerini atlamaya veya kimlik bilgilerini manipüle etmeye izin verecek diğer yüksek değerli kernel yapıları

Fikir şudur: kernel belleği tam kontrol altında olsa bile, saldırgan bu sayfaları basitçe patchleyemez veya yeniden yazamaz; bunu yapabilmek için ya PPL rutinlerini ele geçirmeleri ya da PPL’i atlatmaları gerekir.


#### Known Bypasses & Vulnerabilities

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

- Project Zero tarafından yayımlanan bir yazıda **stale TLB entry’leri** içeren bir bypass anlatılmaktadır.
- Fikir:

1. İki fiziksel sayfa A ve B ayırın, bunları PPL sayfaları olarak işaretleyin (yani korumalı yapın).
2. L3 translation table sayfaları A ve B’den gelen iki sanal adres P ve Q mapleyin.
3. Bir iş parçacığını Q’ya sürekli erişecek şekilde döndürün, böylece onun TLB girişi canlı kalsın.
4. `pmap_remove_options()` çağırın; bir hatadan dolayı kod P için başlayan mappingleri kaldırırken yanlışlıkla hem P hem Q için TTE’leri kaldırır, ama yalnızca P’nin TLB girdisini invalide eder; Q’nunki stale (eski) olarak canlı kalır.
5. B’yi (Q’nin tablosu olan sayfayı) yeniden kullanarak rastgele belleği mapleyin (ör. PPL korumalı sayfalar). Çünkü stale TLB girişi hâlâ Q’nun eski mappingini o bağlam için geçerli gösterir.
6. Böylece saldırgan, PPL arayüzünden geçmeden PPL korumalı sayfaların yazılabilir mappingini yerleştirebilir.

- Bu exploit fiziksel mapping ve TLB davranışı üzerinde hassas kontrol gerektirmiştir. Bir güvenlik sınırının TLB / mapping tutarlılığına dayandığında, TLB invalidasyonları ve mapping tutarlılığı konusunda çok dikkatli olması gerektiğini gösterir.

- Project Zero, bu tür bypassların ince ve nadir olduğunu fakat karmaşık sistemlerde mümkün olduğunu belirtmiştir. Yine de PPL’i sağlam bir mitigasyon olarak değerlendirmişlerdir.

2. **Other potential hazards & constraints**

- Eğer bir kernel exploit doğrudan PPL rutinlerine girebiliyorsa (PPL wrapper’larını çağırarak), kısıtlamaları atlayabilir. Bu yüzden argüman doğrulaması kritik önemdedir.
- PPL kodunun kendisindeki hatalar (ör. aritmetik taşma, sınır kontrolleri) PPL içinde batasız değişikliklere izin verebilir. Project Zero, `pmap_remove_options_internal()` içindeki böyle bir hatanın bypass’ta kullanıldığını gözlemlemiştir.
- PPL sınırı donanım uygulamasına (APRR, memory controller) sıkı sıkıya bağlıdır; bu nedenle yalnızca donanım uygulaması kadar güçlüdür.



#### Example
<details>
<summary>Code Example</summary>
Burada, bir kernel’in korunan sayfaları değiştirmek için PPL’ye nasıl çağrı yapabileceğini gösteren basitleştirilmiş pseudocode / mantık gösterilmiştir:
</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

Kernel birçok normal işlemi gerçekleştirebilir, ancak korumalı eşlemeleri değiştirmek veya kodu yama yapmak yalnızca ppl_call_* rutinleri aracılığıyla mümkündür.

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

- **Intrablock overflows**: Eğer overflow aynı tahsis içinde kalırsa (sınırı geçmez) ve tag aynı kalırsa, tag mismatch bunu yakalamaz.
- **Tag width limitation**: Tag için sadece birkaç bit (örn. 4 bit veya küçük bir domain) mevcuttur—sınırlı isim alanı.
- **Side-channel leaks**: Eğer tag bitleri (cache / speculative execution üzerinden) leak olabiliyorsa, saldırgan geçerli tagleri öğrenip atlayabilir. Apple’ın tag confidentiality enforcement bu durumu hafifletmeyi amaçlar.
- **Performance overhead**: Her load/store için yapılan tag kontrolleri maliyet ekler; Apple donanımı optimize ederek overhead’i düşük tutmak zorunda.
- **Compatibility & fallback**: Eski donanım veya EMTE desteklemeyen parçalar için fallback olmalı. Apple, MIE’nin yalnızca destekli cihazlarda etkin olduğunu iddia ediyor.
- **Complex allocator logic**: Allocator tag’leri yönetmeli, retagging, hizalama sınırlarını ve çakışmaları önlemelidir. Allocator mantığındaki hatalar yeni güvenlik açıkları yaratabilir.
- **Mixed memory / hybrid areas**: Bazı bellekler untagged (legacy) kalabilir; bu, birlikte çalışabilirliği daha karmaşık hale getirir.
- **Speculative / transient attacks**: Birçok mikro-mimari korumada olduğu gibi, speculative execution veya micro-op füzyonları kontrolleri geçici olarak atlatabilir veya tag bitlerini leak edebilir.
- **Limited to supported regions**: Apple EMTE’yi yalnızca seçili, yüksek riskli alanlarda (kernel, güvenlik kritik alt sistemler) zorunlu kılabilir; evrensel olmayabilir.



---

## Key enhancements / differences compared to standard MTE

Here are the improvements and changes Apple emphasizes:

| Feature | Original MTE | EMTE (Apple’s enhanced) / MIE |
|---|---|---|
| **Check mode** | Senkron ve asenkron modları destekler. Asenkron modda, tag uyuşmazlıkları daha sonra (gecikmeli) bildirilir. | Apple varsayılan olarak **synchronous mode**’u zorunlu kılar—tag uyuşmazlıkları anında yakalanır, gecikme/yarış penceresi yoktur.|
| **Coverage of non-tagged memory** | non-tagged memory (örn. globals) erişimleri bazı uygulamalarda kontrolleri atlayabilir | EMTE, tag’li bir bölgeden non-tagged memory’ye yapılan erişimlerin de tag bilgisini doğrulamasını zorunlu kılar; böylece tahsisleri karıştırarak atlatmak zorlaşır.|
| **Tag confidentiality / secrecy** | Tags gözlemlenebilir veya leaked via side channels olabilir | Apple **Tag Confidentiality Enforcement** ekler; tag değerlerinin (via speculative side-channels vb.) sızdırılmasını/observation’u engellemeye çalışır.|
| **Allocator integration & retagging** | MTE büyük ölçüde allocator mantığını yazılıma bırakır | Apple’ın secure typed allocators (kalloc_type, xzone malloc, vb.) EMTE ile entegre olur: bellek allocate/	free edildiğinde tag’ler ince granulariteyle yönetilir.|
| **Always-on by default** | Birçok platformda MTE isteğe bağlıdır veya varsayılan kapalıdır | Apple, desteklenen donanımlarda (örn. iPhone 17 / A19) kernel ve birçok kullanıcı süreci için EMTE / MIE’yi varsayılan etkin olarak açar.|

Apple hem donanımı hem yazılım yığını kontrol ettiği için EMTE’yi sıkı şekilde uygulayabilir, performans tuzaklarından kaçınabilir ve side-channel açıklarını kapatabilir.

---

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

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

1. **Tag assignment**
- Bellek allocate edildiğinde (örn. kernel veya kullanıcı alanında secure allocators ile), o blok için bir **secret tag** atanır.
- Kullanıcıya veya kernela döndürülen pointer, tag’i yüksek bitlerinde içerir (TBI / top byte ignore mekanizmalarını kullanarak).

2. **Tag checking on access**
- Bir pointer kullanılarak load veya store çalıştırıldığında donanım pointer’ın tag’inin bellek bloğunun tag’i (allocation tag) ile eşleşip eşleşmediğini kontrol eder. Mismatch olursa hemen fault verir (synchronous olduğu için).
- Senkron olduğu için “gecikmeli tespit” penceresi yoktur.

3. **Retagging on free / reuse**
- Bellek free edildiğinde allocator bloğun tag’ini değiştirir (eski pointer’ların tag’i artık geçerli olmaz).
- Bu sayede use-after-free pointer’ı stale tag’e sahip olur ve erişimde mismatch oluşur.

4. **Neighbor-tag differentiation to catch overflows**
- Bitişik allocation’lara farklı tag’ler verilir. Eğer bir buffer overflow komşu belleğe sıçrarsa, tag mismatch fault oluşturur.
- Bu, sınırı geçen küçük overflows’ları yakalamada özellikle etkilidir.

5. **Tag confidentiality enforcement**
- Apple, tag değerlerinin leak olmasını engellemelidir (çünkü saldırgan tag’i öğrenebilirse doğru tag’li pointer’lar oluşturabilir).
- Bu amaçla speculative side-channel’lara karşı mikro-mimari / spekülatif kontroller içerir.

6. **Kernel and user-space integration**
- Apple EMTE’yi yalnızca kullanıcı alanında değil, kernel / OS-kritik bileşenlerde de kullanır (kernel’i bellek bozulmalarına karşı korumak için).
- Donanım/OS, tag kurallarının kullanıcı adına kernel yürütülürken bile uygulanmasını sağlar.

EMTE, MIE içine entegre olduğundan Apple, kritik saldırı yüzeylerinde EMTE’yi senkron modda kullanır; bu bir debug/isteğe bağlı mod değildir.



---

## Exception handling in XNU

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

Bu süreç, kullanıcı alanına ulaşmadan veya BSD sinyaline dönüştürülmeden önce birden fazla istisna yayılma ve işleme katmanını içerir.


### Exception Flow (High-Level)

1.  **CPU triggers a synchronous exception** (örn. geçersiz pointer dereference, PAC failure, illegal instruction, vb.).

2.  **Low-level trap handler** çalışır (`trap.c`, `exception.c` içinde XNU kaynağı).

3.  Trap handler **`exception_triage()`**’yi çağırır; bu Mach exception handling’in merkezidir.

4.  `exception_triage()` istisnayı nasıl yönlendireceğine karar verir:

-   Önce **thread'in exception port**una.
-   Sonra **task'ın exception port**una.
-   Sonra **host'un exception port**una (genellikle `launchd` veya `ReportCrash`).

Eğer bu portların hiçbiri istisnayı ele almazsa, kernel:

-   **Bunu bir BSD sinyaline dönüştürebilir** (kullanıcı alanı süreçleri için).
-   **Panic** yapabilir (kernel alanı istisnaları için).


### Core Function: `exception_triage()`

`exception_triage()` fonksiyonu Mach istisnalarını zincir boyunca uygun handler’a kadar yönlendirir; bir handler ele alana kadar veya nihayetinde ölümcül olana kadar bu süreç devam eder. Fonksiyon `osfmk/kern/exception.c` içinde tanımlıdır.
```c
void exception_triage(exception_type_t exception, mach_exception_data_t code, mach_msg_type_number_t codeCnt);

Tipik Çağrı Akışı:

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

Hepsi başarısız olursa → bsd_exception() tarafından işlenir → SIGSEGV gibi bir sinyale çevrilir.

İstisna Portları

Her Mach nesnesi (thread, task, host) istisna mesajlarının gönderildiği istisna portlarını kaydedebilir.

Bunlar API tarafından tanımlanır:

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

Her exception port’unun:

• A mask (almak istediği exception’lar)
• A port name (mesajları almak için Mach portu)
• A behavior (kernel’in mesajı nasıl gönderdiği)
• A flavor (hangi thread state’in dahil edileceği)

Debuggers and Exception Handling

Bir debugger (ör. LLDB) hedef task veya thread üzerinde genellikle task_set_exception_ports() kullanarak bir exception port ayarlar.

Bir exception oluştuğunda:

• Mach mesajı debugger sürecine gönderilir.
• Debugger exception’ı handle (resume, register’ları değiştir, instruction’ı atla) etmeye veya etmeme kararı verebilir.
• Eğer debugger handle etmezse, exception bir sonraki seviyeye yayılır (task → host).

EXC_BAD_ACCESS Akışı

1. Thread geçersiz bir pointer’ı dereference eder → CPU Data Abort tetikler.

2. Kernel trap handler exception_triage(EXC_BAD_ACCESS, ...) çağırır.

3. Mesaj şuraya gönderilir:

• Thread port → (debugger breakpoint’ı yakalayabilir).

• Eğer debugger gözardı ederse → Task port → (process-seviyesinde handler).

• Eğer yine gözardı edilirse → Host port (genellikle ReportCrash).

4. Kimse handle etmezse → bsd_exception() bunu SIGSEGV’e çevirir.

PAC Exceptions

Pointer Authentication (PAC) başarısız olduğunda (signature uyuşmazlığı), özel bir Mach exception yükseltilir:

• EXC_ARM_PAC (tür)
• Kodlar detaylar içerebilir (ör. key tipi, pointer tipi).

Eğer binary’de TFRO_PAC_EXC_FATAL flag’i varsa, kernel PAC hatalarını fatal olarak değerlendirir ve debugger intercept’ini atlar. Bu, saldırganların debugger kullanarak PAC kontrollerini atlatmasını engellemek içindir ve platform binaries için etkinleştirilmiştir.

Software Breakpoints

Bir software breakpoint (int3 on x86, brk on ARM64) kasıtlı bir fault oluşturularak uygulanır.
Debugger bunu exception port üzerinden yakalar:

• Instruction pointer veya memory’i değiştirir.
• Orijinal instruction’ı geri yükler.
• Execution’ı devam ettirir.

Aynı mekanizma PAC exception’ı “yakalamanıza” izin verir — TFRO_PAC_EXC_FATAL ayarlı değilse ulaşır; aksi halde debugger’a hiç ulaşmaz.

Conversion to BSD Signals

Eğer hiçbir handler exception’ı kabul etmezse:

• Kernel task_exception_notify() → bsd_exception() çağırır.

• Bu Mach exception’ları signal’lara map eder:

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

Kernel, sabit boyutlu “zones” olarak bölünmüş bir zone allocator (kalloc) kullanıyordu.
Her zone yalnızca tek bir size class’taki allocation’ları tutardı.

Ekran görüntüsünden:

Nasıl çalışıyordu:

• Her allocation isteği en yakın zone boyutuna yuvarlanır.
  (Ör. 50-byte isteği kalloc.64 zone’una düşer).
• Her zone içindeki memory bir freelist içinde tutulurdu — kernel tarafından freed edilen chunk’lar yine o zone’a geri giderdi.
• Eğer 64-byte buffer’ı taşırırsanız, aynı zone’daki bir sonraki objeyi overwrite ederdiniz.

Bu yüzden heap spraying / feng shui çok etkiliydi: aynı size class’ta allocation’lar spray ederek obje komşularını tahmin edebiliyordunuz.

The freelist

Her kalloc zone içinde, freed objeler doğrudan sisteme geri verilmez — bir freelist’e, yani kullanılabilir chunk’ların bağlı listesine giderdi.

• Bir chunk free edildiğinde, kernel o chunk’ın başına bir pointer yazar → aynı zone’daki bir sonraki free chunk’ın adresi.

• Zone ilk free chunk’ın HEAD pointer’ını tutardı.

• Allocation her zaman mevcut HEAD’i kullanırdı:

1. HEAD’i pop et (o belleği çağırana geri ver).

2. HEAD = HEAD->next olarak güncelle (freed chunk’ın header’ında saklı).

• Free etme push yapardı:

• freed_chunk->next = HEAD

• HEAD = freed_chunk

Yani freelist, freed belleğin kendisi içine kurulan bir linked list’ti.

Normal durum:

Zone page (64-byte chunks for example):
[ A ] [ F ] [ F ] [ A ] [ F ] [ A ] [ F ]

Freelist view:
HEAD ──► [ F ] ──► [ F ] ──► [ F ] ──► [ F ] ──► NULL
(next ptrs stored at start of freed chunks)

freelist’i istismar etme

Çünkü bir free chunk’ın ilk 8 baytı = freelist pointer olduğundan, bir saldırgan bunu bozabilir:

1. Heap overflow ile bitişik bir freed chunk’a taşma → onun “next” pointer’ını üzerine yazmak.
2. Use-after-free ile freed bir objeye yazma → onun “next” pointer’ını üzerine yazmak.

Sonra, o boyuttaki bir sonraki allocation sırasında:

• Allocator bozulmuş chunk’ı çıkarır.
• Saldırgan tarafından sağlanan “next” pointer’ı takip eder.
• Rastgele belleğe bir pointer döndürür; bu, fake object primitives veya hedefli overwrite’a olanak sağlar.

freelist poisoning’in görsel örneği:

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

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.
That way, when memory corruption happens, the attacker can reliably overwrite the victim object with controlled data.

Steps:

1. Spray allocations (fill the holes)

• Over time, the kernel heap gets fragmented: some zones have holes where old objects were freed.
• The attacker first makes lots of dummy allocations to fill these gaps, so the heap becomes “packed” and predictable.

2. Force new pages

• Once the holes are filled, the next allocations must come from new pages added to the zone.
• Fresh pages mean objects will be clustered together, not scattered across old fragmented memory.
• This gives the attacker much better control of neighbors.

3. Place attacker objects

• The attacker now sprays again, creating lots of attacker-controlled objects in those new pages.
• These objects are predictable in size and placement (since they all belong to the same zone).

4. Free a controlled object (make a gap)

• The attacker deliberately frees one of their own objects.
• This creates a “hole” in the heap, which the allocator will later reuse for the next allocation of that size.

5. Victim object lands in the hole

• The attacker triggers the kernel to allocate the victim object (the one they want to corrupt).
• Since the hole is the first available slot in the freelist, the victim is placed exactly where the attacker freed their object.

6. Overflow / UAF into victim

• Now the attacker has attacker-controlled objects around the victim.
• By overflowing from one of their own objects (or reusing a freed one), they can reliably overwrite the victim’s memory fields with chosen values.

Why it works:

• Zone allocator predictability: allocations of the same size always come from the same zone.
• Freelist behavior: new allocations reuse the most recently freed chunk first.
• Heap sprays: attacker fills memory with predictable content and controls layout.
• End result: attacker controls where the victim object lands and what data sits next to it.

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

Apple hardened the allocator and made heap grooming much harder:

1. From Classic kalloc to kalloc_type

• Before: a single kalloc.<size> zone existed for each size class (16, 32, 64, … 1280, etc.). Any object of that size was placed there → attacker objects could sit next to privileged kernel objects.
• Now:
• Kernel objects are allocated from typed zones (kalloc_type).
• Each type of object (e.g., ipc_port_t, task_t, OSString, OSData) has its own dedicated zone, even if they’re the same size.
• The mapping between object type ↔ zone is generated from the kalloc_type system at compile time.

An attacker can no longer guarantee that controlled data (OSData) ends up adjacent to sensitive kernel objects (task_t) of the same size.

2. Slabs and Per-CPU Caches

• The heap is divided into slabs (pages of memory carved into fixed-size chunks for that zone).
• Each zone has a per-CPU cache to reduce contention.
• Allocation path:

1. Try per-CPU cache.
2. If empty, pull from the global freelist.
3. If freelist is empty, allocate a new slab (one or more pages).

• Benefit: This decentralization makes heap sprays less deterministic, since allocations may be satisfied from different CPUs’ caches.

3. Randomization inside zones

• Within a zone, freed elements are not handed back in simple FIFO/LIFO order.
• Modern XNU uses encoded freelist pointers (safe-linking like Linux, introduced ~iOS 14).
• Each freelist pointer is XOR-encoded with a per-zone secret cookie.
• This prevents attackers from forging a fake freelist pointer if they gain a write primitive.
• Some allocations are randomized in their placement within a slab, so spraying doesn’t guarantee adjacency.

4. Guarded Allocations

• Certain critical kernel objects (e.g., credentials, task structures) are allocated in guarded zones.
• These zones insert guard pages (unmapped memory) between slabs or use redzones around objects.
• Any overflow into the guard page triggers a fault → immediate panic instead of silent corruption.

5. Page Protection Layer (PPL) and SPTM

• Even if you control a freed object, you can’t modify all of kernel memory:
• PPL (Page Protection Layer) enforces that certain regions (e.g., code signing data, entitlements) are read-only even to the kernel itself.
• On A15/M2+ devices, this role is replaced/enhanced by SPTM (Secure Page Table Monitor) + TXM (Trusted Execution Monitor).
• These hardware-enforced layers mean attackers can’t escalate from a single heap corruption to arbitrary patching of critical security structures.
• (Added / Enhanced): also, PAC (Pointer Authentication Codes) is used in the kernel to protect pointers (especially function pointers, vtables) so that forging or corrupting them becomes harder.
• (Added / Enhanced): zones may enforce zone_require / zone enforcement, i.e. that an object freed can only be returned through its correct typed zone; invalid cross-zone frees may panic or be rejected. (Apple alludes to this in their memory safety posts)

6. Large Allocations

• Not all allocations go through kalloc_type.
• Very large requests (above ~16 KB) bypass typed zones and are served directly from kernel VM (kmem) via page allocations.
• These are less predictable, but also less exploitable, since they don’t share slabs with other objects.

7. Allocation Patterns Attackers Target

Even with these protections, attackers still look for:

• Reference count objects: if you can tamper with retain/release counters, you may cause use-after-free.
• Objects with function pointers (vtables): corrupting one still yields control flow.
• Shared memory objects (IOSurface, Mach ports): these are still attack targets because they bridge user ↔ kernel.

But — unlike before — you can’t just spray OSData and expect it to neighbor a task_t. You need type-specific bugs or info leaks to succeed.

Example: Allocation Flow in Modern Heap

Suppose userspace calls into IOKit to allocate an OSData object:

1. Type lookup → OSData maps to kalloc_type_osdata zone (size 64 bytes).
2. Check per-CPU cache for free elements.

• If found → return one.
• If empty → go to global freelist.
• If freelist empty → allocate a new slab (page of 4KB → 64 chunks of 64 bytes).

3. Return chunk to caller.

Freelist pointer protection:

• Each freed chunk stores the address of the next free chunk, but encoded with a secret key.
• Overwriting that field with attacker data won’t work unless you know the key.

Comparison Table

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

In recent Apple OS versions (especially iOS 17+), Apple introduced a more secure userland allocator, xzone malloc (XZM). This is the user-space analog to the kernel’s kalloc_type, applying type awareness, metadata isolation, and memory tagging safeguards.

Goals & Design Principles

• Type segregation / type awareness: group allocations by type or usage (pointer vs data) to prevent type confusion and cross-type reuse.
• Metadata isolation: separate heap metadata (e.g. free lists, size/state bits) from object payloads so that out-of-bounds writes are less likely to corrupt metadata.
• Guard pages / redzones: insert unmapped pages or padding around allocations to catch overflows.
• Memory tagging (EMTE / MIE): work in conjunction with hardware tagging to detect use-after-free, out-of-bounds, and invalid accesses.
• Scalable performance: maintain low overhead, avoid excessive fragmentation, and support many allocations per second with low latency.

Architecture & Components

Below are the main elements in the xzone allocator:

Segment Groups & Zones

• Segment groups partition the address space by usage categories: e.g. data, pointer_xzones, data_large, pointer_large.
• Each segment group contains segments (VM ranges) that host allocations for that category.
• Associated with each segment is a metadata slab (separate VM area) that stores metadata (e.g. free/used bits, size classes) for that segment. This out-of-line (OOL) metadata ensures that metadata is not intermingled with object payloads, mitigating corruption from overflows.
• Segments are carved into chunks (slices) which in turn are subdivided into blocks (allocation units). A chunk is tied to a specific size class and segment group (i.e. all blocks in a chunk share the same size & category).
• For small / medium allocations, it will use fixed-size chunks; for large/huges, it may map separately.

Chunks & Blocks

• A chunk is a region (often several pages) dedicated to allocations of one size class within a group.
• Inside a chunk, blocks are slots available for allocations. Freed blocks are tracked via the metadata slab — e.g. via bitmaps or free lists stored out-of-line.
• Between chunks (or within), guard slices / guard pages may be inserted (e.g. unmapped slices) to catch out-of-bounds writes.

Type / Type ID

• Every allocation site (or call to malloc, calloc, etc.) is associated with a type identifier (a malloc_type_id_t) which encodes what kind of object is being allocated. That type ID is passed to the allocator, which uses it to select which zone / segment to serve the allocation.
• Because of this, even if two allocations have the same size, they may go into entirely different zones if their types differ.
• In early iOS 17 versions, not all APIs (e.g. CFAllocator) were fully type-aware; Apple addressed some of those weaknesses in iOS 18.

Allocation & Freeing Workflow

Here is a high-level flow of how allocation and deallocation operate in xzone:

1. malloc / calloc / realloc / typed alloc is invoked with a size and type ID.
2. The allocator uses the type ID to pick the correct segment group / zone.
3. Within that zone/segment, it seeks a chunk that has free blocks of the requested size.

• It may consult local caches / per-thread pools or free block lists from metadata.
• If no free block is available, it may allocate a new chunk in that zone.

4. The metadata slab is updated (free bit cleared, bookkeeping).
5. If memory tagging (EMTE) is in play, the returned block gets a tag assigned, and metadata is updated to reflect its “live” state.
6. When free() is called:

• The block is marked as freed in metadata (via OOL slab).
• The block may be placed into a free list or pooled for reuse.
• Optionally, block contents may be cleared or poisoned to reduce data leaks or use-after-free exploitation.
• The hardware tag associated with the block may be invalidated or re-tagged.
• If an entire chunk becomes free (all blocks freed), the allocator may reclaim that chunk (unmap it or return to OS) under memory pressure.

Security Features & Hardening

These are the defenses built into modern userland xzone:

Interaction with Memory Integrity Enforcement (MIE / EMTE)

• Apple’s MIE (Memory Integrity Enforcement) is the hardware + OS framework that brings Enhanced Memory Tagging Extension (EMTE) into always-on, synchronous mode across major attack surfaces.
• xzone allocator is a fundamental foundation of MIE in user space: allocations done via xzone get tags, and accesses are checked by hardware.
• In MIE, the allocator, tag assignment, metadata management, and tag confidentiality enforcement are integrated to ensure that memory errors (e.g. stale reads, OOB, UAF) are caught immediately, not exploited later.

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

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!
• 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter’da bizi takip edin 🐦 @hacktricks_live.**
• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.