Memory Integrity Enforcement (MIE) on iOS Deep Dive – Part 1

Introduction

In this two-part blog series, we will explore Apple's groundbreaking Memory Integrity Enforcement (MIE) feature. In Part 1, we'll cover the fundamentals: what memory corruption vulnerabilities are, how MIE works at a technical level, and how to analyze the kernel implementation using Binary Ninja. In Part 2, we'll shift to the practical side—enabling MIE in applications, checking entitlements, and analyzing crash logs.

Memory corruption vulnerabilities represent the most critical and persistent security challenge facing the industry today. When we look at the statistics, both Google and Microsoft have published data showing that approximately 70% of all severe security vulnerabilities in their codebases stem from memory safety issues. These aren't just theoretical problems, they are the foundation of virtually every sophisticated attack that we see in the wild.

The Memory Safety Crisis

Let's break down what we mean by memory corruption. The three most common categories are:

1. Buffer Overflows – Where an attacker writes beyond the bounds of an allocated memory region
2. Use-After-Free (UAF) – Where memory is accessed after it has been freed and potentially reallocated
3. Type Confusion – Where memory is interpreted as the wrong type

These bugs are so valuable because they give attackers the ability to read and write arbitrary memory, which is the fundamental primitive needed to take control of a system.

This is why Apple has invested around five years of extraordinary reverse engineering and engineering resources into solving this problem at a fundamental level.

Apple's Answer: Memory Integrity Enforcement

Memory Integrity Enforcement (MIE) is Apple's biggest leap in memory safety. It is the result of a five-year collaboration between the Apple Silicon team and the OS security team. What's remarkable is that this brings always-on memory safety with zero performance cost—something the industry has been trying to achieve for years.

MIE vs AddressSanitizer: Why Hardware Matters

Before MIE, the industry's best tool for finding memory bugs was AddressSanitizer (ASan)—a compiler-based instrumentation tool. While ASan has been invaluable for developers, it has fundamental limitations that make it unsuitable for production deployment:

The Philosophy

Apple combined their hardware innovations (A19 silicon), software security measures, and secure allocators into one unified design. The result is a complete end-to-end memory safety solution that closes entire classes of exploitation techniques.

The Evolution: From PAC to MTE to EMTE

Understanding MIE requires understanding its evolution.

2018: Pointer Authentication Codes (PAC)

In 2018, Apple shipped the A12 Bionic chip with Pointer Authentication Code (PAC). This made them the first in the industry to deploy this protection at scale. PAC uses cryptographic signatures to verify that code pointers have not been tampered with.

2019: ARM Memory Tagging Extension (MTE)

When ARM published the Memory Tagging Extension specification in 2019, it was designed primarily as a debugging tool. The core idea is elegant: tag every memory allocation with a secret 4-bit value, and have the hardware check that subsequent accesses provide the correct tag.

However, Apple's security team identified critical weaknesses:

2022: Enhanced MTE (EMTE)

Apple worked directly with ARM to address these shortcomings. EMTE requires synchronous checking (immediate exceptions), protects non-tagged memory access, and includes several other improvements that make it viable as a real-time defensive measure.

The Three Pillars of MIE

MIE is built on three interconnected pillars that work together to provide comprehensive protection:

Pillar 1: Secure Type-Aware Allocators

Apple has developed several allocators:

• kalloc_type for the kernel
• xzone malloc for userland
• libpas for WebKit/browsers

These allocators use compile-time type information to organize memory, making it extremely difficult for attackers to position malicious allocations where they need to be.

Pillar 2: Enhanced MTE (EMTE)

EMTE fills the gap that software allocators cannot address—protection within a single type bucket at sub-page granularity:

• Every memory allocation gets tagged with a 4-bit secret (16 possible values)
• Adjacent buffers get different tags
• If code writes beyond one buffer into the next, the hardware sees a tag mismatch and immediately raises a synchronous exception

Pillar 3: Tag Confidentiality Enforcement

This is where Apple goes beyond the ARM specification with custom implementations. To understand why this pillar is critical, we need to examine the TikTag attack.

The TikTag Threat: Why Tag Confidentiality Matters

In 2024, security researchers from Seoul National University and Samsung Research published a devastating attack against MTE called TikTag. Using speculative execution side-channels, TikTag can leak MTE tags with 95%+ success rate in under 4 seconds.

Apple's Tag Confidentiality Countermeasures

Deep Dive: SPTM Protection

The Secure Page Table Monitor (SPTM) is Apple's hypervisor-level protection layer that provides guarantees even if the kernel is fully compromised:

This is a critical differentiator from Android's MTE implementation, where a kernel compromise can potentially disable or bypass MTE protections.

How MTE Works: Technical Deep Dive

The Tag Memory Architecture

MTE introduces a parallel "tag memory" layer alongside regular data memory:

Understanding Tagged Pointers

The tag is stored in the lower 4 bits of the top byte of a 64-bit address:

Hardware Tag Checking: No Extra Instructions!

An important thing to note is that there are no additional instructions for checking the tag value every time. The LDR and STR instructions do it for you under the hood.

Whenever you load or store using a pointer:

1. The tag value is extracted from the pointer (bits 59:56)
2. The tag value for the corresponding granule is read from tag memory
3. If the pointer tag matches the memory tag → valid access
4. If they don't match → synchronous hardware fault

Memory Allocation Flow: What Happens on malloc()

Let's trace through what happens when you call malloc(64):

Step 1: Find Free Memory

The xzone malloc finds free memory at address 0xFFFFFE0008493520.

Step 2: Tag the Pointer (IRG Instruction)

The pointer is tagged using the IRG (Insert Random Tag) instruction:

IRG x0, x0, x1

; x0: Untagged address (0xFFFFFE0008493520)
; x1: Exclusion mask (recent tags to avoid)
; Result: Tagged address (0xAFFFFFFE0008493520, tag = 0xA)

Step 3: Tag the Memory (STG Instruction)

The memory that this pointer points to must also be tagged using the STG (Store Tag) instruction:

STG x0, [x0], #16   ; Tag granule 0 with 0xA
STG x0, [x0], #16   ; Tag granule 1 with 0xA
STG x0, [x0], #16   ; Tag granule 2 with 0xA
STG x0, [x0], #16   ; Tag granule 3 with 0xA

Now both the pointer AND the memory it points to have the same tag (0xA).

How MIE Prevents Attacks

Buffer Overflow Prevention

Use-After-Free Prevention

Reversing MTE in the iOS Kernel

Now let's look at how to analyze the MTE implementation in the iOS kernel.

Step 1: Download the Kernelcache

Using the ipsw tool from blacktop's ipsw repository:

$ ipsw extract --remote --kernel \
  "https://updates.cdn-apple.com/.../iPhone18,3_26.1_23B85_Restore.ipsw"

Extracting kernelcache
  • Created 23B85__iPhone18,3/kernelcache.release.iPhone18,3