MIE Deep Dive Part 2 Enabling Apps and Analyzing Memory-Tagg...

src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md

@@ -89,6 +89,56 @@ prctl(PR_SET_TAGGED_ADDR_CTRL,
 
 On Android, stack tagging is not automatic for arbitrary native code: if a lab or target was compiled with **`-fsanitize=memtag`** and a **`-fsanitize-memtag-mode=sync`** link mode, stack bugs that would normally stay invisible to heap-only MTE may now fault reliably. For a concrete exploitation scenario where MTE can break the overflow stage before shellcode/ROP, check [the ARM64 stack shellcode notes](../stack-overflow/stack-shellcode/stack-shellcode-arm64.md).
 
+### iOS / iPadOS MIE recon and crash triage
+
+Apple's **Memory Integrity Enforcement (MIE)** combines secure typed allocators, synchronous EMTE, and tag-confidentiality controls. On supported hardware, third-party targets opt in from Xcode's **Enhanced Security → Memory Safety → Enable Hardware Memory Tagging** setting.<sup>[[7]](#references)[[8]](#references)</sup>
+
+Current Apple SDK documentation identifies the main Boolean entitlement as **`com.apple.security.hardened-process.checked-allocations`** and requires the parent hardened-process and enhanced-security-version entitlements. The soft-mode key is **`com.apple.security.hardened-process.checked-allocations.soft-mode`**; when true, violations generate simulated-crash diagnostics instead of terminating the process. The 8kSec sample instead reports **`com.apple.security.cs.checked_allocations`**; audit both spellings when examining binaries from different SDK/toolchain revisions, but require an actual Boolean `true` value rather than merely grepping for `checked_allocations`.<sup>[[7]](#references)[[9]](#references)</sup>
+
+Resolve the bundle executable from `Info.plist`, dump its signed entitlements, and parse the Boolean values explicitly:<sup>[[7]](#references)[[9]](#references)</sup>
+
+```bash
+APP=/path/to/Target.app
+EXE=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleExecutable' "$APP/Info.plist")
+ENT=$(mktemp)
+codesign -d --entitlements :- "$APP/$EXE" 2>/dev/null > "$ENT"
+for KEY in com.apple.security.hardened-process.checked-allocations \
+           com.apple.security.hardened-process.checked-allocations.soft-mode \
+           com.apple.security.cs.checked_allocations; do
+  VALUE=$(/usr/libexec/PlistBuddy -c "Print :$KEY" "$ENT" 2>/dev/null) || continue
+  printf '%s = %s\n' "$KEY" "$VALUE"
+done
+rm -f "$ENT"
+```
+
+The entitlement proves that the signed target requested the feature, **not** that checks were active at runtime: Apple states that the setting has no effect on unsupported hardware. For hard-fault testing, use a supported physical device, ensure the soft-mode entitlement is absent/false, and execute the spatial and temporal tests separately because the first detected violation should terminate the process.<sup>[[7]](#references)[[9]](#references)</sup>
+
+```c
+#include <stdlib.h>
+#include <string.h>
+
+__attribute__((noinline, optnone)) void mie_oob(void) {
+    char *p = malloc(16);
+    memset(p, 'A', 32);          // crosses the first 16-byte granule
+}
+
+__attribute__((noinline, optnone)) void mie_uaf(void) {
+    volatile char *p = malloc(32);
+    free((void *)p);
+    p[0] = 'X';                  // stale pointer after allocator retagging
+}
+```
+
+These are destructive probes, not deterministic feature detectors: the invalid access must reach a differently tagged granule, and the four-bit tag space permits collisions. Treat a matching crash as strong runtime confirmation, but do not treat one non-crashing attempt as proof that MIE is disabled.<sup>[[9]](#references)</sup>
+
+For iOS `.ips` triage, the high-signal runtime fields observed in a synchronous MIE failure are:<sup>[[9]](#references)</sup>
+
+- `exception.type = EXC_GUARD` with subtype `GUARD_TYPE_VIRT_MEMORY`.
+- Flavor `GUARD_EXC_MTE_SYNC_FAULT`, which distinguishes the event from an ordinary `EXC_BAD_ACCESS`.
+- `mteState = enabled`, which confirms tagging was active at the fault.
+- `mtePageTags`, containing nearby 4-bit allocation tags, plus the tagged fault address in the exception codes.
+- The triggered thread's first application frame: synchronous enforcement stops the invalid load/store at the corruption point, so a frame such as `_platform_memset` above the caller usually identifies the actual overflowing operation.
+
 ## Implementation & Detection Examples
 
 Linux calls its MTE-backed kernel memory-safety detector **Hardware Tag-Based KASAN**. Supported kernel allocators such as `kmalloc` assign an allocation tag to the memory and return a pointer carrying the corresponding logical tag.<sup>[[5]](#references)</sup>
@@ -134,6 +184,20 @@ Project Zero's MTE testing/use-case analysis is still a good mental model:<sup>[
 
 This is especially relevant for browser, IPC and kernel exploits where the attacker can try to keep the whole corruption chain inside one "quiet" execution window.
 
+### Stale PFN and device aliases
+
+MTE checks do not repair lifetime bugs in page mappings. If a driver leaves an untagged or differently governed alias writable after returning the physical page to an allocator, the page can be recycled for a protected object while the stale alias still modifies the same bytes. This bypass class avoids guessing the new allocation tag because the corrupting path never performs the expected tagged dereference.<sup>[[6]](#references)</sup>
+
+The CVE-2025-0072 exploit demonstrated the following concrete pattern in the Arm Mali CSF driver:<sup>[[6]](#references)</sup>
+
+1. Bind a queue and map its command user pages into userspace.
+2. Unbind/rebind the queue so new pages overwrite `queue->phys`.
+3. Unmap the old region; cleanup frees the *new* pages while their second userspace mapping survives.
+4. Groom a freed page into a Mali GPU page-table global directory (PGD).
+5. Rewrite the recycled PGD through the stale userspace PFN mapping, then map arbitrary kernel memory for read/write and code execution.
+
+The demonstrated access was through a driver-created **userspace mapping** backed by `insert_pfn`, not a GPU write through an old GPU mapping. The broader lesson still applies to GPU/DMA aliases: CPU-side tag checks cannot compensate for stale writable mappings or non-CPU agents that do not participate in the same tag-checking domain. Drivers must revoke every CPU and device mapping before page reuse and synchronize IOMMU/page-table teardown with allocator lifetime.<sup>[[6]](#references)[[9]](#references)</sup>
+
 ### Speculative Tag Leakage (TikTag)
 
 *TikTag* (2024) demonstrated two speculative execution gadgets (**TIKTAG-v1/v2**) able to leak the 4-bit allocation tag of arbitrary addresses with **>95% success** in **less than 4 seconds**. The key idea is to speculatively trigger a tag-checked access, use a cache side channel to learn whether the access matched, and iterate over candidate tags until the correct one is recovered.<sup>[[3]](#references)</sup>
@@ -154,5 +218,9 @@ The paper demonstrates this against **Google Chrome** and the **Linux kernel**.<
 - [3] [TikTag: Breaking ARM's Memory Tagging Extension with Speculative Execution](https://arxiv.org/abs/2406.08719)
 - [4] [Sticky Tags: Efficient and Deterministic Spatial Memory Error Mitigation using Persistent Memory Tags](https://www.vusec.net/projects/stickytags/)
 - [5] [Linux kernel documentation - Kernel Address Sanitizer (KASAN)](https://docs.kernel.org/dev-tools/kasan.html)
+- [6] [GitHub Security Lab - Bypassing MTE with CVE-2025-0072](https://github.blog/security/vulnerability-research/bypassing-mte-with-cve-2025-0072/)
+- [7] [Apple Developer - Enabling enhanced security for your app](https://developer.apple.com/documentation/xcode/enabling-enhanced-security-for-your-app)
+- [8] [Apple Security Research - Memory Integrity Enforcement](https://security.apple.com/blog/memory-integrity-enforcement/)
+- [9] [8kSec - MIE Deep Dive Part 2: Enabling Apps and Analyzing Memory-Tagging Crashes](https://8ksec.io/mie-deep-dive-enabling-apps)
 
 {{#include ../../banners/hacktricks-training.md}}

src/mobile-pentesting/ios-pentesting/README.md

@@ -42,6 +42,8 @@ Some interesting iOS - IPA files decompilers:
 - [https://github.com/LaurieWired/Malimite](https://github.com/LaurieWired/Malimite)
 - [https://ghidra-sre.org/](https://ghidra-sre.org/)
 
+For iOS Memory Integrity Enforcement discovery and synchronous tag-fault triage, see [Memory Tagging Extension (MTE)](../../binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md).<sup>[[31]](#references)</sup>
+
 It's recommended to use the tool [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) to perform an automatic Static Analysis to the IPA file.
 
 Identification of **protections are present in the binary**:
@@ -1250,5 +1252,6 @@ zero-click-messaging-image-parser-chains.md
 - [28] [Mobile Pentesting 101 – Bypassing Biometric Authentication](https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/)
 - [29] [OWASP MASTG – iOS Testing Cryptography](https://mas.owasp.org/MASTG/0x06e-Testing-Cryptography/)
 - [30] [iOS (Swift) Anti-Jailbreak Bypass Using Frida – syrion (Internet Archive)](https://web.archive.org/web/20200514192843/https://syrion.me/blog/ios-swift-antijailbreak-bypass-frida/)
+- [31] [8kSec - MIE Deep Dive Part 2: Enabling Apps and Analyzing Memory-Tagging Crashes](https://8ksec.io/mie-deep-dive-enabling-apps)
 
 {{#include ../../banners/hacktricks-training.md}}

src/mobile-pentesting/ios-pentesting/extracting-entitlements-from-compiled-application.md

@@ -9,6 +9,8 @@ codesign -d --entitlements :- "Payload/Target.app" 2>/dev/null
 security cms -D -i "Payload/Target.app/embedded.mobileprovision"
 ```
 
+For MIE-specific entitlement interpretation, validation tests, and `.ips` crash signatures, see [Memory Tagging Extension (MTE)](../../binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md).<sup>[[4]](#references)</sup>
+
 ### **Extracting Entitlements and Mobile Provision Files**
 
 An IPA or installed app may not contain a standalone `.entitlements` file. Effective signed entitlements are embedded in the Mach-O code signature, while `embedded.mobileprovision`—when present—contains the provisioning profile and its permitted entitlement set. These are related but not guaranteed to be identical.
@@ -55,5 +57,6 @@ Adjusting the `-A num, --after-context=num` flag allows for the display of more
 - [1] [MASTG-TEST-0069: Review entitlements embedded in the compiled app binary - OWASP MASTG](https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0069/#review-entitlements-embedded-in-the-compiled-app-binary)
 - [2] [Apple — Code Signing Guide: Code Signing Tasks](https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html)
 - [3] [Telegram-iOS entitlement file used in the example](https://github.com/peter-iakovlev/Telegram-iOS/blob/77ee5c4dabdd6eb5f1e2ff76219edf7e18b45c00/Telegram-iOS/Telegram-iOS-AppStoreLLC.entitlements)
+- [4] [8kSec - MIE Deep Dive Part 2: Enabling Apps and Analyzing Memory-Tagging Crashes](https://8ksec.io/mie-deep-dive-enabling-apps)
 
 {{#include ../../banners/hacktricks-training.md}}