Exploits, Tools & Data Recovery · Bug Classes & Mitigations · Lesson 3 of 5

Exploit Mitigations

The walls, shuffles, signatures and tags that make bugs much harder to use.

Walls, shuffles and no-run zones

Fixing every bug is the goal, but nobody gets there. So phone makers also add exploit mitigations: defenses that don't fix any particular bug, but make bugs much harder to turn into an attack, or limit the damage when one is used. Think of them as smoke alarms, fire doors and sprinklers, rather than a promise that nothing will ever catch fire.

Three have been standard for years:

• Sandboxing. You met sandboxes in Mobile Fundamentals. Each app, and many risky parts of the system, runs inside walls that limit what it can reach. Apple's BlastDoor, which processes untrusted iMessage content in a locked-down space, is one example. If an attacker gets code running inside a sandbox, they only control a small room, and need another bug to get out.
• Address space layout randomization (ASLR). Many attacks need to know where things sit in memory. ASLR places code, libraries and data at different random spots each time. Picture a hotel that reshuffles which room is which every night, so a burglar's floor plan from yesterday is useless. Apple says ASLR helps protect against the exploitation of memory corruption bugs, and that it randomizes where executable code and system libraries are placed.
• Non-executable memory. Memory that holds data, like a downloaded picture, is marked as "never run this." Arm chips call this Execute Never (XN), and Apple's Platform Security guide says iOS uses it to mark memory pages as nonexecutable. It's like a mailroom rule: letters can be read, but nothing written in them is ever treated as orders from the boss.

None of these is perfect. A determined attacker might find a second bug that leaks where things are, or reuses code that's already allowed to run. But each mitigation forces the attacker to find and combine more bugs, which costs time and money and gives defenders more chances to catch them.

Signed pointers, tagged memory and chains

Newer mitigations are built into the chip itself.

A pointer is a note in memory that says where something else is, like "the next instruction is over there." Attackers love to overwrite pointers. Apple's Pointer Authentication Codes (PAC) add a small cryptographic signature to important pointers, made with a secret key. Before the pointer is used, the signature is checked. If someone changed the pointer, the check fails and the process stops. Apple says it was the first in the industry to ship PAC, in the A12 Bionic chip in 2018.

Memory tagging goes after the bugs themselves. Picture every block of memory and every key to it getting a matching secret color. Writing past the end of your form runs into a block of a different color. Opening a reassigned locker with an old key fails, because the locker was recolored. On a mismatch, the program is stopped instead of quietly corrupted. Arm's version is the Memory Tagging Extension (MTE).

• Pixel: Google's developer docs list the Pixel 8 and later Pixels as supporting MTE, which developers can turn on through a Developer Options setting. Google's help page for Android's Advanced Protection mode lists MTE among its protections, for supported apps, and warns it may slow the device.
• iPhone: On September 9, 2025, Apple announced Memory Integrity Enforcement for all iPhone 17 models and iPhone Air. It combines an enhanced form of MTE with hardened memory allocators, is on by default, and covers the kernel and over 70 user-level processes. Apple said its own team tested it against six real-world exploit chains and could not rebuild any of them to work around it.

This is why modern attacks need an exploit chain, several bugs used in sequence: one to run code, one to defeat randomization, one to escape the sandbox, and so on. Apple says the only system-level iOS attacks it sees in the wild come from mercenary spyware, with chains costing millions of dollars.