Apple Security Club

A community for those defending macOS users.

Hi, I'm Arin. You might know me from my work at 9to5Mac.


Hi, I'm Arin. You might know me from my work at 9to5Mac.

These are my reverse engineering notes and half-finished research from an Apple security reporter learning the internals (:

Writing

Latest from the club

Hardware

The Secure Enclave, explained

A second computer on the die that the rest of the system cannot read out of.

Sep 9, 2026 · 9 min
macOS

The sealed system volume, and what breaking the seal costs

macOS does not boot the system volume. It boots a cryptographically sealed snapshot of it.

Sep 4, 2026 · 7 min
iOS

What Lockdown Mode actually turns off

Not a privacy setting. A deliberate amputation of the surface that mercenary spyware arrives through.

Aug 29, 2026 · 6 min
macOS

Gatekeeper, notarization, and what happens at first launch

Three separate mechanisms collapsed into one scary dialog. They check different things.

Aug 24, 2026 · 8 min
iOS

Rapid Security Responses: the (a) in your version number

A patch that ships outside the release train, can be removed, and vanishes into the next update.

Aug 19, 2026 · 5 min
iOS

Advanced Data Protection, and who holds the iCloud keys

The feature does one thing: it moves key custody onto your devices. Everything else follows.

Aug 14, 2026 · 7 min
Hardware

Pointer authentication, and the gadgets it did not kill

Apple silicon signs pointers with a key you cannot read, using bits the address space never used.

Aug 8, 2026 · 8 min
iPadOS

Supervision, MDM, and what a managed iPad can actually see

Management is not surveillance, but the boundary is specific — and almost nobody can state it.

Aug 2, 2026 · 6 min
iPad

DFU, restores, and what “clean” actually means

Erase All Content is not a wipe. It is a key deletion, which is why it takes seconds.

Jul 28, 2026 · 6 min
iPhone

BlastDoor, and the shrinking iMessage attack surface

The lesson from zero-click exploits was not to parse more carefully. It was to parse somewhere else.

Jul 21, 2026 · 7 min
Tracking

Patch board

Updated 2026-09-11 from Apple’s security releases
ReleaseDevicesFixesExploitationShipped
iOS 26.6.2 and iPadOS 26.6.2iPhone 11 and later · +5—No published CVEs2026-09-08
Safari 26.6.1macOS Sonoma and macOS Sequoia21No known exploitation2026-08-18
iOS 26.6.1 and iPadOS 26.6.1iPhone 11 and later · +529No known exploitation2026-08-17
iOS 18.7.10 and iPadOS 18.7.10iPhone XS · +3122No known exploitation2026-08-17
macOS Tahoe 26.6.2macOS Tahoe28No known exploitation2026-08-17
visionOS 26.6.1Details coming soon—Details pending2026-08-17
macOS Tahoe 26.6.1macOS Tahoe1Actively exploited · 1 CVE2026-08-06
macOS Sequoia 15.7.9macOS Sequoia1Actively exploited · 1 CVE2026-08-06
The briefing

Join the club

One email when Apple ships a security release that matters, with the fixes worth your attention and the ones that are not.

Demo form — point its action at your list provider.

Hardware

The Secure Enclave, explained

It is not a folder, a keychain, or a feature flag. It is a second computer on the die that your Mac or iPhone cannot read out of — only ask questions of.

Illustration of a chip with a locked inner core, representing the Secure Enclave.

The Secure Enclave is a separate subsystem inside Apple silicon with its own boot ROM, its own AES engine, and memory the main application processor cannot address. It runs its own small operating system, sepOS, verified by that immutable boot ROM at every start. The practical consequence is the part people skip: even a fully compromised kernel does not get to read what the Enclave holds.

What it holds is key material. Face ID and Touch ID templates never leave it — the sensor sends data over a channel keyed to the Enclave, matching happens inside, and what comes back out is essentially a yes or a no. Your file class keys live there too, which is why Data Protection is meaningful rather than decorative: a file encrypted under a class that requires the device be unlocked genuinely cannot be decrypted while it is locked, because the key is not resident anywhere the rest of the system can reach.

Terms of artAP — the application processor, the chip you think of as the CPU.
SEP — the Secure Enclave Processor, a peer, not a peripheral.
UID — a key fused at manufacture, never exported, not known to Apple.

The passcode is the hinge, and it is why the Enclave needs a friend. A six-digit passcode is trivially brute-forceable if you can try guesses at silicon speed, so attempt counting has to be tamper-evident and non-rewindable. That is the job of the Secure Storage Component, a separate chip holding entropy and enforcing anti-replay over an encrypted, authenticated link. Restore the flash, roll back the state, replay an old response: the counters disagree, and the key is never derived.

The useful habit when reading an advisory is to ask which side of the Enclave boundary the bug lives on. A kernel arbitrary write is severe, and it gets an attacker the running device. It still does not get them the class keys of a phone sitting locked in an evidence bag, and that difference is the whole design.

macOS

The sealed system volume, and what breaking the seal costs

macOS does not boot the system volume. It boots a cryptographically sealed snapshot of it.

Illustration of a hash tree whose leaves roll up to a single sealed root.

Since macOS 11, everything Apple ships lives on a read-only system volume hashed into a Merkle tree. Each block hashes up into a parent, parents hash up again, and the whole structure terminates in a single root value: the seal. The kernel checks that seal at boot, and what you are actually running is a signed APFS snapshot, not the live filesystem.

This changes what a software update is. Rather than mutating files in place and hoping nothing was left half-written, the updater builds a new snapshot and a new seal, and the next boot switches to it. It also changes what tampering means: modifying one system file does not produce a system with one modified file, it produces a system whose root hash no longer matches — which macOS notices immediately rather than eventually.

Verify it yourselfcsrutil status
csrutil authenticated-root status
diskutil apfs list | grep -i snapshot

Breaking the seal on purpose is possible — disable System Integrity Protection, then permit a non-sealed root — and it is the right move for certain research. Know the bill first: the machine records a reduced security state, services that depend on an attested system stop being available, and you cannot recompute the seal yourself. You get it back by reinstalling, not by repairing.

For anyone auditing a fleet, the check worth automating is not whether SIP is on. It is whether the authenticated-root state matches what you expect, per machine, over time.

iOS

What Lockdown Mode actually turns off

It is not a privacy setting. It is a deliberate amputation of the attack surface that mercenary spyware keeps arriving through.

Illustration of an iPhone with a lock and several features struck through.

Lockdown Mode is aimed at a small population — people plausibly targeted by commercial surveillance vendors — and it works by removing capability rather than adding detection. Most message attachment types other than images are blocked, and link previews are turned off, which closes a long-favored path where merely receiving something causes a parser to run.

In Safari, just-in-time JavaScript compilation is disabled unless you explicitly exclude a site. JIT is a performance feature that necessarily writes executable memory at runtime, and a long line of exploit chains has started exactly there. Turning it off costs page speed and buys the removal of an entire technique.

Where to find itSettings › Privacy & Security › Lockdown Mode
Requires a restart. Exclusions are per-site and per-contact.

Elsewhere: incoming FaceTime calls from people you have never called are rejected, wired accessories require an unlocked device before they connect, and configuration profiles cannot be installed at all — which also means a device in Lockdown Mode cannot be enrolled in mobile device management while it stays on.

The honest framing is the trade, not the badge. Most people will find the cost irritating and the benefit theoretical. For the handful for whom it is neither, it is the strongest single switch on the platform.

macOS

Gatekeeper, notarization, and what happens at first launch

Three separate mechanisms get collapsed into one scary dialog. They check different things and fail in different ways.

Illustration of an app passing through a gate to a verified checkmark.

When a browser or messaging app writes a downloaded file to disk, it attaches a quarantine attribute to it. That flag is the tripwire: it is what makes the first launch of an app different from the second, and why an app copied from a USB stick sometimes behaves differently than the same app downloaded.

On that first launch, Gatekeeper evaluates the code signature and looks for a notarization ticket. Notarization is not app review — no human reads your app. A developer submits a build, an automated service scans it for known malicious content and signing problems, and if it passes, a ticket is issued. That ticket can be stapled into the app so the check works offline; otherwise macOS asks Apple about it over the network.

Inspect a bundlexattr -p com.apple.quarantine /Applications/Example.app
codesign -dv --verbose=4 /Applications/Example.app
spctl -a -vvv -t install /Applications/Example.app

The failure modes deserve to be separated when you write about them. An unsigned app fails differently than a signed-but-unnotarized one, which fails differently again from an app whose signature was broken by a bad archive extraction. That last case is common, and the dialog is actively misleading: macOS reports damage when what it means is that the signature no longer verifies.

Apple retains the ability to revoke a ticket after the fact, which is what makes this a live system rather than a build-time gate. When a notarized app later turns out to be malware, revocation takes effect on machines that already installed it.

iOS

Rapid Security Responses: the (a) in your version number

A patch that ships without a full OS update, can be removed, and quietly disappears into the next release.

The version number 26.0.1 (a), with the rapid response letter highlighted.

A Rapid Security Response is a small, targeted patch delivered outside the normal release train, typically for components exposed to the open internet — WebKit above all, plus a handful of system frameworks. It installs quickly, usually needs only a restart, and marks itself with a letter appended to the version.

The design goal is time-to-patch. A full OS update is a large download with broad regression risk, so it moves at the speed of validation. A response is narrow enough to ship in days, which matters when the bug is already being used against people.

Reading the version26.0.1      full release
26.0.1 (a)  first rapid response on top of it
26.1        response folded in, letter drops

Two operational details that fleet managers keep learning the hard way. Responses can be removed, which is unusual for Apple updates and exists because a fast narrow patch occasionally breaks a specific workflow. And responses are cumulative into the next full release, so a device on 26.1 is not missing what 26.0.1 (a) fixed.

If you manage devices, the setting that governs this is separate from ordinary automatic updates. Confirm it is on before you need it.

iOS

Advanced Data Protection, and who holds the iCloud keys

The feature does one thing: it moves the keys for most iCloud categories out of Apple’s hands and onto your devices. Everything else follows from that.

Illustration of an encryption key moving from the cloud onto an iPhone.

By default, a number of iCloud data categories are encrypted in a way that leaves Apple able to decrypt them. That is what makes web access and account recovery work, and it is also what makes those categories producible in response to legal process. Advanced Data Protection changes the custody model so the keys exist only on your trusted devices.

That shift is not free, and the cost is recovery. With Apple out of the loop, a forgotten password plus a lost device is not a support problem, it is data loss. Enabling ADP therefore requires setting up a recovery contact or a recovery key first, and that is the single most important thing to tell a reader before they turn it on.

Before enabling1. Set a recovery contact or generate a recovery key.
2. Update every device on the account — old ones lose access.
3. Web access at iCloud.com turns off until you re-authorize it.

Some categories stay outside the end-to-end set for interoperability reasons — iCloud Mail, Contacts, and Calendar, because they speak standard protocols other providers have to be able to talk to. Writing about ADP without naming that exception overstates what it covers.

The useful test for any claim about cloud encryption is the same one applied consistently: name who can derive the key. If the provider can, encryption at rest protects against a stolen disk, not against a subpoena.

Hardware

Pointer authentication, and the gadgets it did not kill

Apple silicon signs pointers with a key you cannot read, using bits the address space was never going to need anyway.

Illustration of a 64-bit pointer whose top bits hold an authentication signature.

A 64-bit pointer does not need 64 bits. The top bits go unused, and pointer authentication puts them to work: a cryptographic signature over the pointer value and a context is computed in hardware and tucked into those spare bits. Before the pointer is used, the hardware authenticates it. A forged or corrupted pointer fails, and the process dies rather than jumping somewhere an attacker chose.

This is aimed squarely at return-oriented and jump-oriented programming, the techniques that made non-executable memory survivable for attackers. If you cannot control where execution goes, a write primitive becomes dramatically less useful.

Key contextsIA, IB  instruction pointers
DA, DB  data pointers
GA      generic, for arbitrary values
Each process receives its own key set at exec.

It is not a cure, and writing about it as one is the common mistake. The literature has explored signing gadgets — code sequences that will sign an attacker-chosen pointer on request — and reuse of validly signed pointers within the same key context. Both are real, both are harder than what came before, and that is the actual claim: a large class of exploitation went from routine to expensive.

The pattern to watch for in advisories is chaining. A modern chain now spends steps acquiring a signing primitive that older chains never needed at all.

iPadOS

Supervision, MDM, and what a managed iPad can actually see

Management is not surveillance, but the boundary is specific, and almost nobody in the room can state it.

Illustration of an iPad home screen with an organization’s shield badge.

Supervision is a device state, not an app. A supervised iPad unlocks a set of restrictions unavailable on personally owned devices — blocking app removal, forcing a proxy, locking the device into a single app — because the organization is asserting ownership, not merely enrollment.

The clean path to that state is Automated Device Enrollment through Apple Business Manager or Apple School Manager, where the device is bound to the organization at activation. That binding is the point: it survives an erase, which is exactly what you want on hardware you own, and exactly what surprises someone who bought a used iPad that was never released from an organization.

Check enrollment stateSettings › General › VPN & Device Management
A supervised device says so on the lock screen
and under About › Supervision.

What MDM can see is narrower than people assume: device identifiers, OS version, installed app inventory, compliance state, and whether policies applied. What it cannot see on an unsupervised personal device is your browsing history, the contents of your mail, or your personal data in apps the organization did not install.

For a school or business readership, that list is worth publishing once and linking to forever. Most of the fear in the room is about capabilities that do not exist, and it crowds out the ones that do.

iPad

DFU, restores, and what “clean” actually means

Erase All Content and Settings is not a wipe. It is a key deletion, and that is why it takes seconds instead of hours.

Illustration of an iPad with a black screen connected to a Mac by a cable.

Everything on the device is already encrypted. Erasing content works by destroying the keys that make it readable — discard those and the remaining bits are noise, no overwriting required. This is why a factory reset on an Apple device is both instant and stronger than a multi-pass erase on a disk that was never encrypted to begin with.

Device Firmware Update mode is a different tool for a different problem. DFU bypasses the local bootloader entirely and accepts a firmware image over USB, which is the recovery path when iBoot itself will not come up. It is also how you install a system on hardware you do not trust to tell you the truth about its current state.

Recovery vs DFURecovery mode  iBoot runs, screen shows a cable
DFU mode       iBoot skipped, screen stays black
Both restore from a currently signed image.

The signing window is the constraint that surprises people. A restore requires a firmware image Apple is currently signing, and signing for older releases stops shortly after a new one ships — so downgrading is normally not possible, and a device cannot be rolled back onto a version with a known bug.

For a security readership, the line worth drawing is between clean and trustworthy. A DFU restore gives you a known-good operating system. It tells you nothing about what happened to the data that was on the device before you did it.

iPhone

BlastDoor, and the shrinking iMessage attack surface

The lesson Apple took from zero-click messaging exploits was not to parse more carefully. It was to parse somewhere else.

Illustration of a message passing through a sandbox before reaching the system.

Zero-click means the target does nothing: a message arrives and code runs. Historically the path was a parser — some format handler in the message pipeline processing attacker-controlled bytes inside a process with real privileges. You cannot ask people to be careful about a message they never opened.

BlastDoor is a separate, tightly sandboxed service that does the untrusted parsing. It is written in a memory-safe language, denied nearly everything by its sandbox profile, and hands back only structured, validated results. A memory bug in the parser now buys an attacker a foothold in a process that can barely do anything.

The patternUntrusted bytes → sandboxed, memory-safe parser
→ validated structure → privileged process.
Never untrusted bytes → privileged process.

Two supporting changes matter as much and get written about less. The memory allocator used on these paths was hardened so heap grooming — the careful layout work exploitation depends on — became less reliable. And repeated failed attempts against a device are throttled with an escalating delay, turning a technique that needs many tries into one that runs out of time.

The architectural point generalizes well past messaging: when input cannot be trusted and the parser cannot be proven correct, move the parser somewhere the blast radius is acceptable. Defense in depth is not a slogan here. It is a process boundary.