iMessage Media Parser Zero-Click → CoreAudio RCE → PAC/RPAC → Kernel → CryptoTokenKit Abuse

Reading time: 7 minutes

Questa pagina riassume una superficie d'attacco zero-click moderna per iOS e una catena di sfruttamento end-to-end osservata che abusa della analisi automatica dei media di iMessage per compromettere CoreAudio, bypassare BlastDoor, sconfiggere Pointer Authentication (PAC) tramite un percorso RPAC, escalare al kernel e infine abusare di CryptoTokenKit per usi non autorizzati delle chiavi.

Avvertenza: Questo è un riassunto a scopo didattico per aiutare difensori, ricercatori e red team a comprendere le tecniche. Non usare in modo offensivo.

Catena ad alto livello

• Vettore di consegna: un allegato audio malevolo (ad es., .amr / MP4 AAC) inviato via iMessage/SMS.
• Ingestione automatica: iOS analizza automaticamente i media per anteprime e conversioni senza interazione dell'utente.
• Bug nel parser: strutture malformate colpiscono AudioConverterService di CoreAudio e corrompono la memoria heap.
• Esecuzione di codice nel contesto dei media: RCE all'interno del processo di parsing dei media; segnalato che bypassa l'isolamento di BlastDoor in percorsi specifici (ad es., il framing “known sender”).
• Bypass PAC/RPAC: una volta ottenuta la capacità di R/W arbitrario, un bypass PAC nel percorso RPAC permette il controllo stabile del flusso sotto arm64e PAC.
• Escalation al kernel: la catena converte l'esecuzione in userland in esecuzione nel kernel (ad es., tramite percorsi di codice wireless/AppleBCMWLAN e la gestione AMPDU come visto nei log sotto).
• Post-exploitation: con l'accesso al kernel, abusare di CryptoTokenKit per effettuare firme con chiavi protette da Secure Enclave, leggere percorsi di dati sensibili (contesti Keychain), intercettare messaggi/2FA, autorizzare azioni silenziosamente e abilitare sorveglianza stealth (microfono/fotocamera/GPS) senza prompt.

Note sulla superficie d'attacco iMessage/BlastDoor

BlastDoor è un servizio rinforzato progettato per analizzare contenuti di messaggi non attendibili. Tuttavia, i log osservati indicano percorsi in cui le protezioni possono essere bypassate quando i messaggi sono incorniciati da un “known sender” e quando filtri aggiuntivi (ad es., Blackhole) sono meno restrittivi:

IDSDaemon    BlastDoor: Disabled for framing messages
SpamFilter   Blackhole disabled; user has disabled filtering unknown senders.

Punti chiave:

• L'auto-parsing rappresenta ancora una superficie di attacco remota (zero-click).
• Le decisioni di policy/contesto (mittente noto, stato del filtering) possono cambiare significativamente l'isolamento effettivo.

CoreAudio: AudioConverterService corruzione dell'heap (userland RCE)

Componente interessata:

• CoreAudio → AudioConverterService → flussi di parsing e conversione AAC/AMR/MP4

Punto di contatto del parser osservato (logs):

AudioConverterService    ACMP4AACBaseDecoder.cpp: inMagicCookie=0x0, inMagicCookieByteSize=39

Riassunto della tecnica:

• Metadati di container/codec malformati (es., magic cookie invalido/breve/NULL) causano una corruzione di memoria durante la configurazione del decode.
• Si attiva nel percorso di conversione media di iMessage senza interazione dell'utente.
• Consente l'esecuzione di codice nel processo di parsing dei media. L'analisi afferma che questo scavalca BlastDoor nel percorso di consegna osservato, abilitando la fase successiva.

Suggerimenti pratici:

• Fuzz AAC/AMR magic cookie e MP4 codec atoms quando si mirano le conversioni di AudioConverterService.
• Concentrarsi su heap overflows/underflows, OOB reads/writes, e size/length confusion intorno all'inizializzazione del decoder.

PAC bypass via RPAC path (CVE-2025-31201)

arm64e Pointer Authentication (PAC) impedisce il dirottamento di return addresses e function pointers. La catena riporta di aver sconfitto PAC usando un RPAC path una volta che è disponibile arbitrary read/write.

Idea chiave:

• Con arbitrary R/W, attackers possono creare re-signed pointers validi o pivotare l'esecuzione verso PAC-tolerant paths.
• Il cosiddetto “RPAC path” abilita il controllo del flusso sotto i vincoli di PAC, trasformando un userland RCE in un setup affidabile per exploit sul kernel.

Note per i ricercatori:

• Raccogliere info leaks per sconfiggere KASLR e stabilizzare ROP/JOP chains anche sotto PAC.
• Prendere di mira callsites che generano o autenticano PAC in modi controllabili (es., signatures generated on attacker-controlled values, predictable context keys, or gadget sequences that re-sign pointers).
• Aspettarsi variazioni nel hardening Apple a seconda di SoC/OS; l'affidabilità dipende da leaks, entropy e primitive robuste.

Kernel escalation: wireless/AMPDU path example

Nella catena osservata, una volta in userland con memory corruption e una PAC bypass primitive, il controllo del kernel è stato ottenuto tramite code paths nello stack Wi‑Fi (AppleBCMWLAN) sotto gestione AMPDU malformata. Esempio di log:

IO80211ControllerMonitor::setAMPDUstat unhandled kAMPDUStat_ type 14
IO80211ControllerMonitor::setAMPDUstat unhandled kAMPDUStat_ type 13

Tecnica generale:

• Use userland primitives to build kernel R/W or controlled call paths.
• Abusare delle superfici del kernel raggiungibili (IOKit, networking/AMPDU, media shared memory, Mach interfaces) per ottenere kernel PC control o accesso a memoria arbitraria.
• Stabilizzare costruendo read/write primitives ed eludendo i vincoli PPL/SPTM dove applicabile.

Post-exploitation: CryptoTokenKit and identity/signing abuse

Una volta compromesso il kernel, processi come identityservicesd possono essere impersonati e operazioni crittografiche privilegiate possono essere invocate tramite CryptoTokenKit senza richieste all'utente. Esempio di log:

CryptoTokenKit    operation:2 algo:algid:sign:ECDSA:digest-X962:SHA256
CryptoTokenKit    <sepk:p256(d) kid=9a86778f7163e305> parsed for identityservicesd

Impact:

• Use Secure Enclave–backed keys for unauthorized signing (tokens, messages, payments), breaking trust models even if keys are not exported.
• Intercept 2FA codes/messages silently; authorize payments/transfers; enable stealth mic/camera/GPS.

Defensive angle:

• Treat post-kernel integrity breaks as catastrophic: enforce runtime attestation for CTK consumers; minimize ambient authority; verify entitlements at the point of use.

Reproduction and telemetry hints (lab only)

• Delivery: send a crafted AMR/MP4-AAC audio to the target device via iMessage/SMS.
• Observe telemetry for the foregoing log lines around parsing and wireless stack reactions.
• Ensure devices are fully patched; only test in isolated lab setups.

Mitigations and hardening ideas

• Patch level: iOS 18.4.1 reportedly fixes this chain; keep devices up to date.
• Parser hardening: strict validation for codec cookies/atoms and lengths; defensive decoding paths with bounds checks.
• iMessage isolation: avoid relaxing BlastDoor/Blackhole in “known sender” contexts for media parsing.
• PAC hardening: reduce PAC-gadget availability; ensure signatures are bound to unpredictable contexts; remove PAC-tolerant bypassable patterns.
• CryptoTokenKit: require post-kernel attestation and strong entitlements at call-time for key-bound operations.
• Kernel surfaces: harden wireless AMPDU/status handling; minimize attacker-controlled inputs from userland after compromise.

Affected versions (as reported)

• iOS 18.x prior to iOS 18.4.1 (April 16, 2025).
• Primary: CoreAudio → AudioConverterService (media auto-parsing path via iMessage/SMS).
• Chained: PAC/RPAC path and kernel escalation via AppleBCMWLAN AMPDU handling.

References

• iOS Crypto Heist repo (README)
• Remote Crypto Attack Chain details