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

Reading time: 7 minutes

This page summarizes a modern iOS zero-click attack surface and an observed end-to-end exploitation chain abusing iMessage automatic media parsing to compromise CoreAudio, bypass BlastDoor, defeat Pointer Authentication (PAC) via an RPAC path, escalate to kernel, and finally abuse CryptoTokenKit for unauthorized key uses.

Avertissement : Ceci est un résumé à but éducatif pour aider les défenseurs, chercheurs et red teams à comprendre les techniques. Ne pas utiliser à des fins offensives.

Chaîne de haut niveau

• Vecteur de livraison : une pièce jointe audio malveillante (p. ex., .amr / MP4 AAC) envoyée via iMessage/SMS.
• Ingestion automatique : iOS analyse automatiquement les médias pour les aperçus et les conversions sans interaction utilisateur.
• Bogue du parseur : des structures malformées atteignent AudioConverterService de CoreAudio et corrompent la mémoire heap.
• Exécution de code dans le contexte média : RCE à l'intérieur du processus d'analyse des médias ; signalé pour contourner l'isolation BlastDoor dans des chemins spécifiques (p. ex., le chemin de cadrage “known sender”).
• Contournement PAC/RPAC : une fois R/W arbitraire obtenu, un contournement PAC dans le chemin RPAC permet un contrôle stable du flux d'exécution sous arm64e PAC.
• Escalade au noyau : la chaîne convertit une exécution en espace utilisateur en exécution noyau (p. ex., via les chemins de code wireless/AppleBCMWLAN et la gestion AMPDU comme vu dans les logs ci-dessous).
• Post-exploitation : avec le noyau, abuser CryptoTokenKit pour effectuer des signatures avec des clés supportées par Secure Enclave, lire des chemins de données sensibles (contexte Keychain), intercepter messages/2FA, autoriser silencieusement des actions, et activer une surveillance furtive (micro/caméra/GPS) sans invites.

Notes sur la surface d'attaque iMessage/BlastDoor

BlastDoor est un service durci conçu pour analyser du contenu de message non fiable. Cependant, les logs observés indiquent des chemins où les protections peuvent être contournées lorsque les messages sont cadrés depuis un “known sender” et lorsque des filtres additionnels (p. ex., Blackhole) sont assouplis :

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

Points clés :

• Auto-parsing représente toujours une surface d'attaque distante zero-click.
• Les décisions de policy/contexte (known sender, filtering state) peuvent modifier de manière significative l'isolation effective.

CoreAudio: AudioConverterService heap corruption (userland RCE)

Composant affecté :

• CoreAudio → AudioConverterService → AAC/AMR/MP4 parsing and conversion flows

Point de contact observé du parser (logs) :

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

Technique summary:

• Des métadonnées container/codec malformées (p.ex., invalid/short/NULL magic cookie) provoquent une memory corruption pendant le decode setup.
• Se déclenche dans le chemin de conversion média d'iMessage sans action tactile de l'utilisateur.
• Donne lieu à une code execution dans le processus d'analyse média. Le write-up affirme que cela échappe à BlastDoor dans le chemin de livraison observé, permettant l'étape suivante.

Practical tips:

• Fuzz AAC/AMR magic cookie et MP4 codec atoms quand on cible les conversions AudioConverterService.
• Concentrez-vous sur heap overflows/underflows, OOB reads/writes, et les size/length confusion autour de l'initialisation du décodeur.

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

arm64e Pointer Authentication (PAC) empêche le détournement des return addresses et des function pointers. La chaîne rapporte avoir contourné PAC en utilisant un RPAC path une fois qu'un arbitrary read/write est disponible.

Key idea:

• Avec arbitrary R/W, les attaquants peuvent construire des pointeurs valides re-signed ou pivoter l'exécution vers des PAC-tolerant paths. Le soi-disant “RPAC path” permet le control-flow sous contraintes PAC, transformant un userland RCE en une configuration d'exploit kernel fiable.

Notes for researchers:

• Collect info leaks pour contourner KASLR et stabiliser les chaînes ROP/JOP même sous PAC.
• Ciblez les callsites qui génèrent ou authentifient PAC de manière contrôlable (p.ex., signatures générées sur attacker-controlled values, predictable context keys, ou gadget sequences qui re-sign pointers).
• Attendez-vous à une variance du hardening Apple selon le SoC/OS ; la fiabilité dépend des leaks, de l'entropie et de primitives robustes.

Kernel escalation: wireless/AMPDU path example

Dans la chaîne observée, une fois en userland avec memory corruption et une PAC bypass primitive, le contrôle du kernel a été obtenu via des code paths dans le Wi‑Fi stack (AppleBCMWLAN) sous un traitement AMPDU malformé. Example logs:

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

Technique générale :

• Utiliser des primitives userland pour construire un kernel R/W ou des chemins d'appel contrôlés.
• Abuser des surfaces kernel accessibles (IOKit, networking/AMPDU, media shared memory, Mach interfaces) pour obtenir le contrôle du PC du kernel ou un accès mémoire arbitraire.
• Stabiliser en construisant des primitives de lecture/écriture et en contournant les contraintes PPL/SPTM lorsque cela s'applique.

Post-exploitation : CryptoTokenKit et abus d'identité/signature

Une fois le kernel compromis, des processus comme identityservicesd peuvent être usurpés et des opérations cryptographiques privilégiées invoquées via CryptoTokenKit sans demandes à l'utilisateur. Exemples de logs :

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

Impact :

• Utiliser des clés Secure Enclave–backed pour des signatures non autorisées (tokens, messages, paiements), compromettant les modèles de confiance même si les clés ne sont pas exportées.
• Intercepter silencieusement des codes/messages 2FA ; autoriser des paiements/transferts ; activer micro/caméra/GPS en mode furtif.

Defensive angle :

• Considérer les ruptures d'intégrité post-kernel comme catastrophiques : appliquer l'attestation à l'exécution pour les consommateurs CTK ; minimiser l'autorité ambiante ; vérifier les entitlements au point d'utilisation.

Reproduction and telemetry hints (lab only)

• Delivery : envoyer un audio AMR/MP4-AAC spécialement conçu vers l'appareil cible via iMessage/SMS.
• Observer la télémétrie pour les lignes de log précitées autour du parsing et des réactions de la pile sans fil.
• S'assurer que les appareils sont à jour ; ne tester que dans des environnements de laboratoire isolés.

Mitigations and hardening ideas

• Patch level : iOS 18.4.1 corrige apparemment cette chaîne ; maintenir les appareils à jour.
• Parser hardening : validation stricte des codec cookies/atoms et des longueurs ; voies de décodage défensives avec vérifications de bornes.
• iMessage isolation : éviter de détendre BlastDoor/Blackhole dans les contextes de “known sender” pour le parsing des médias.
• PAC hardening : réduire la disponibilité des PAC-gadgets ; s'assurer que les signatures sont liées à des contextes imprévisibles ; supprimer les motifs tolérants PAC contournables.
• CryptoTokenKit : exiger une attestation post-kernel et des entitlements forts au moment de l'appel pour les opérations liées aux clés.
• Kernel surfaces : durcir la gestion AMPDU/status du sans-fil ; minimiser les entrées contrôlées par l'attaquant depuis le userland après compromission.

Affected versions (as reported)

• iOS 18.x antérieures à iOS 18.4.1 (16 avril 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