Comment FairPlay protège les binaires d'apps iOS, et une faiblesse au niveau du compte

En bref

• FairPlay chiffre la plage d'un binaire Mach-O iOS déclarée par sa commande de chargement LC_ENCRYPTION_INFO ou LC_ENCRYPTION_INFO_64. Le noyau déchiffre cette plage par blocs de 4 Ko au fil des défauts de page, et les pages déchiffrées ne sont jamais réécrites dans le fichier. C'est pourquoi l'ancienne méthode d'analyse d'une app de l'App Store consistait à vider sa mémoire pendant son exécution.
• Chaque IPA transporte aussi une licence SC_Info. L'enregistrement SINF encapsule une clé de travail de 16 octets propre à l'app, et l'enregistrement SUPF fournit une valeur encapsulée de 16 octets et un IV de 16 octets pour chaque page de 4 Ko. La clé de page est dérivée de la clé de travail, de l'enregistrement de page et de l'offset du fichier.
• L'outil public EthanArbuckle/fairplay-decrypt montre que la hiérarchie se réduit à un identifiant réutilisable de 16 octets. L'identifiant est extrait une fois depuis un appareil jailbreaké ; ensuite, le déchiffrement est hors ligne, déterministe et ne nécessite plus d'appareil.
• La faiblesse n'est pas un chiffrement cassé. C'est une conception de clé porteuse : l'identifiant déverrouille la clé de travail distincte de chaque app, et les clés de page sont dérivées de cette clé de travail plutôt que d'être des secrets indépendants. Un identifiant déverrouille donc toutes les apps du compte ou de l'enrôlement.
• Un second projet, DrWhax/unfairplay, récupère un modèle équivalent depuis un Mac enrôlé et déchiffre plusieurs IPA sous macOS ou Linux. Son README indique que le modèle est lié à l'enrôlement, pas à une seule app.
• Nous n'avons trouvé aucune CVE attribuée. Une recherche par mot-clé dans le NVD ne renvoie aucun enregistrement fairplay au 12 novembre 2026, et le catalogue CISA KEV version 2026.11.10 ne contient aucune entrée FairPlay. Il s'agit d'un contournement de DRM qui exige un appareil jailbreaké ou un Mac enrôlé, pas d'un exploit distant.
• Traitez l'identifiant ou le modèle comme un secret de compte. Si vous acquérez des IPA pour des tests, utilisez un compte dédié, gardez l'identifiant chiffré et journalisez les accès, puis supprimez-le à la fin de la mission. Si vous développez une app, ne comptez pas sur FairPlay pour garder le code ou des secrets de longue durée confidentiels.

Pourquoi un binaire iOS doit-il être déchiffré ?

Les tests iOS automatisés échouent dès la première étape : obtenir le binaire. L'analyse statique, la détection des dépendances, l'extraction de chaînes et l'analyse des vulnérabilités ont toutes besoin de l'exécutable Mach-O en clair. L'IPA livrée par l'App Store est chiffrée, et les pages déchiffrées n'existent que pendant l'exécution de l'app.

La méthode traditionnelle repose sur un appareil jailbreaké. L'analyste lance l'app, attend que le noyau déchiffre ses pages, puis vide la mémoire du processus. La page MASTG d'OWASP sur l'obtention et l'extraction des apps décrit cette approche de vidage mémoire et cite frida-ios-dump. Elle exige un appareil physique pour chaque analyse, dépend du support du jailbreak pour la version d'iOS et reste difficile à rendre reproductible ou auditable.

La voie hors ligne change l'économie. Dès qu'un identifiant réutilisable existe, le déchiffrement devient une fonction de l'IPA et de l'identifiant. L'appareil sert à obtenir l'identifiant, pas à déchiffrer chaque app. C'est le changement opérationnel que cet article explique, et la raison pour laquelle la portée au niveau du compte compte.

Que documente Apple à propos de FairPlay ?

Apple documente la signature de code, pas la confidentialité du code des apps. Son guide Platform Security indique que sur iOS, iPadOS, tvOS, visionOS et watchOS, « these operating systems require that all executable code be signed using an Apple-issued certificate » (Apple, App code signing process, publié le 19 décembre 2024, guide mis à jour en août 2026). La signature de code prouve qui a construit le code et qu'il n'a pas été modifié. Elle ne cache pas le code, et re-signer une app ne supprime pas le chiffrement FairPlay.

La page sur la signature de code et la page sur la sécurité du processus d'exécution que nous avons consultées ne décrivent pas FairPlay ni le chiffrement des binaires d'apps. Nous n'avons pas trouvé de page Apple qui documente le mécanisme. Le côté noyau est public dans le code source XNU, mais la dérivation des clés, les formats SINF et SUPF et l'identifiant de compte relèvent de connaissances reconstituées par la communauté. Chaque affirmation ci-dessous cite sa source.

Quelles sont les trois couches de protection de FairPlay ?

FairPlay se comprend mieux comme trois couches aux rôles différents. La signature de code protège l'intégrité. Le chiffrement Mach-O protège les octets au repos. La licence SC_Info et les services FairPlay de l'appareil décident qui peut déchiffrer quelle app.

Couche 1 : la signature de code

La signature de code est la couche d'intégrité. Elle lie le binaire à un certificat délivré par Apple et à un identifiant d'équipe, et le noyau refuse d'exécuter du code qui échoue à la validation. Elle ne dit rien sur la capacité d'un lecteur à récupérer les instructions. Un attaquant qui copie une IPA possède toujours les octets chiffrés ; un attaquant qui retire la signature possède toujours le chiffrement FairPlay.

Couche 2 : les pages chiffrées du Mach-O

L'en-tête Mach-O peut porter LC_ENCRYPTION_INFO ou LC_ENCRYPTION_INFO_64. La commande stocke cryptoff (l'offset du fichier pour la plage chiffrée), cryptsize (sa taille) et cryptid (le système de chiffrement applicable) ; la structure se trouve dans l'en-tête du chargeur Mach-O d'Apple. Un cryptid de 1 signifie que la plage est chiffrée ; 0 signifie que la commande est vide et que la plage n'est pas chiffrée. L'article de SensePost de 2011, Decrypting iPhone Apps, montre les mêmes champs et la méthode de vidage mémoire qu'ils ont permis sur les premières versions d'iOS.

Apple publie le côté noyau. Dans mach_loader.c, parse_machfile() traite les deux commandes de chiffrement dans un même cas et appelle set_code_unprotect(). Si cette fonction renvoie LOAD_DECRYPTFAIL, le noyau enregistre EXEC_EXIT_REASON_FAIRPLAY_DECRYPT (« failed to load due to missing FP keys ») et tue un exec non-spawn avec SIGKILL. Dans vm_apple_protect.c, le déchiffrement s'exécute dans un gestionnaire de mémoire externe qui « handles memory from the encrypted sections of some executables protected by the DSMOS kernel extension ». Au défaut de page, il déchiffre des blocs de 4 Ko via un callback page_decrypt, et la source précise que « the decrypted pages will never be dirtied » : les originaux restent propres et le clair ne vit qu'en mémoire.

Cette dernière propriété explique pourquoi le vidage mémoire a fonctionné pendant des années. C'est aussi la propriété que le déchiffreur hors ligne reproduit : il calcule les mêmes clés de page et écrit le clair dans une copie du fichier.

Couche 3 : la licence et le matériel de clé

Une IPA de l'App Store transporte un dossier SC_Info/. L'analyse de Noham sur une app iOS crackée le décrit comme l'endroit où « Apple's FairPlay DRM stores iTunes Store licensing metadata », avec des fichiers Manifest.plist, .sinf, .supf, .supp et .supx, notant que « Not much is documented publicly about the internal FairPlay file formats ». Les rôles ci-dessous viennent donc de l'outillage public et de l'analyse tierce, pas d'une spécification Apple.

Le SINF est une arborescence d'atomes de style MPEG-4. Les champs qui comptent ici sont :

• user et key : deux sélecteurs de 4 octets qui identifient le compte et l'enregistrement de licence.
• iviv : une valeur de 16 octets utilisée avec le nom de l'app pour dériver un IV.
• priv : un enregistrement de 440 ou 448 octets qui encapsule la clé de travail de 16 octets de l'app.
• name et sign : le nom de l'app et une signature.

Le SUPF est la table des pages. Le README de fairplay-decrypt indique qu'il prend en charge les SUPF de version 3 et 5, les enregistrements priv de 448 et 440 octets et les tranches Mach-O arm64 chiffrées. Dans le code, un SUPF de version 3 a un en-tête par architecture de 32 octets et un SUPF de version 5 un en-tête de 12 octets ; chaque page reçoit ensuite un enregistrement de 32 octets composé d'une valeur encapsulée de 16 octets suivie d'un IV de 16 octets (core.py).

La licence fait le lien entre le compte et l'app. Le SINF lie l'app à un compte et à un sélecteur de licence ; le SUPF décrit comment dériver les clés de page une fois la clé de travail de l'app connue. La section suivante montre comment l'outil public transforme ces deux fichiers en clair.

Comment le déchiffreur hors ligne récupère-t-il une clé d'app ?

L'outil fonctionne en deux étapes. La première extrait un identifiant réutilisable d'un appareil jailbreaké. La seconde utilise cet identifiant, le SINF et le SUPF pour déchiffrer l'IPA sur une machine ordinaire. Cette section est notre lecture du code public ; Apple n'en publie rien.

Étape 1 : extraire un identifiant de 16 octets depuis un appareil

Le composant credential-retrieval prend en charge iOS 10 et versions ultérieures et exige un appareil jailbreaké appairé avec un accès SSH root et au moins une app installée depuis le compte (README de credential-retrieval). Le récupérateur :

1. S'attache à fairplayd avec task_for_pid() et installe des points d'arrêt matériels sur IOConnectCallStructMethod (observer.c). Il préserve les points de surveillance des autres débogueurs et contourne un problème de rechargement des registres de débogage dans XNU 8792, signalé dans la source.
2. Lance un déclencheur qui mappe un exécutable chiffré et appelle mremap_encrypted(), demandant au noyau de préparer le déchiffrement FairPlay pour cet exécutable. Le commentaire du déclencheur indique qu'il demande « FairPlay's first-use path without running or copying decrypted code » (trigger.c). C'est pourquoi l'extraction n'a pas besoin d'exécuter l'app cible.
3. Lit le fichier IC-Info.sidb de l'appareil, le déchiffre avec une clé dérivée de l'UDID de l'appareil et sélectionne l'enregistrement user et key du SINF (credential.c).
4. Combine la valeur de 16 octets observée lors de l'appel FairPlay avec un contexte dérivé de l'UDID, du compte et du sélecteur de clé, plus une table de mots de 4 Ko fournie par l'outil, et écrit le résultat dans credential.bin.

L'appareil est nécessaire pour cette dérivation. Le point important est la suite : la sortie de 16 octets est une valeur autonome. Le déchiffrement n'appelle plus jamais l'appareil, fairplayd ni FairPlayIOKit.

Le code de récupération embarque des connaissances propres aux versions. Il choisit le sélecteur FairPlay 9 ou 21 selon la version d'iOS, et contient des commentaires liés à iOS 16.3.1 pour le format moderne d'UDID. Le README annonce iOS 10 et ultérieur, mais la cible bouge : un changement dans fairplayd peut casser le récupérateur sans changer le format de déchiffrement.

Étape 2 : dériver la clé de travail et toutes les clés de page hors ligne

Le déchiffreur hors ligne est en Python pur et fonctionne sous macOS et Linux (README). Il ouvre l'IPA comme un ZIP, associe chaque .supf ou .v5.supf à son binaire et à son SINF, et ignore les binaires sans tranche arm64 chiffrée. Pour chaque tranche chiffrée, il fait trois choses.

D'abord, il déverrouille la clé de travail de 16 octets depuis l'enregistrement priv du SINF :

iv = MD5(name || iviv)
work = AES-CBC-decrypt(credential XOR bytes([0x30] * 16), iv, priv)[24:40]

Le code vérifie que l'enregistrement déchiffré commence par itun, contient key à l'offset 20 et iviv à l'offset 44, puis prend la clé de 16 octets à l'offset 24. Si l'identifiant est faux, la vérification des marqueurs échoue et l'outil s'arrête ; aucune tentative de force brute n'est faite (core.py).

Ensuite, il dérive une clé de page pour chaque page de 4 Ko. L'enregistrement SUPF donne une valeur encapsulée de 16 octets et un IV de 16 octets. Le code construit trois blocs de 16 octets à partir de la valeur encapsulée et de l'offset absolu de la page dans le fichier, chiffre chacun en AES-128-ECB avec la clé de travail, puis passe les trois résultats de 16 octets dans une fonction de mélange maison fondée sur des additions, des multiplications et des XOR sur 16 bits. La sortie est la clé de page. L'offset de la page fait partie de l'entrée : un enregistrement de page déplacé vers un autre offset produit une clé différente.

Enfin, il déchiffre la page en AES-128-CBC avec cette clé de page et l'IV du SUPF, écrit le clair dans la copie de sortie et met cryptid à 0. Le résultat est une IPA dont les pages exécutables sont en clair (core.py, decrypt.py).

Tout le pipeline est déterministe. Il n'y a ni nonce aléatoire fourni par Apple, ni challenge serveur, ni attestation d'appareil, ni secret par lancement. Le seul secret en entrée est l'identifiant de 16 octets ; tout le reste vient de l'IPA.

Où la hiérarchie de clés échoue-t-elle ?

La hiérarchie échoue à la racine, pas dans le chiffrement. Un identifiant de 16 octets déverrouille la clé de travail de chaque app, et la clé de travail dérive toutes les clés de page de cette app. Les clés de page assurent une séparation de domaine : une clé pour une page ne peut pas déchiffrer une autre page à un autre offset. Elles n'assurent pas une confidentialité indépendante, car elles viennent toutes de la même clé de travail.

Trois propriétés transforment ce tableau en faiblesse au niveau du compte.

Un identifiant couvre plusieurs apps. Chaque app a son propre SINF et sa propre clé de travail, mais le même identifiant déverrouille toutes ces clés. UnfairPlay énonce la conséquence clairement : « One model can decrypt different IPAs personalized for the same enrollment. Each app still has its own key inside its personalized SINF. » Les clés par app limitent les dégâts d'une clé de travail divulguée ; elles ne limitent pas les dégâts d'un identifiant divulgué.

La dérivation est déterministe et hors ligne. Une fois l'identifiant présent, l'IPA contient tout le reste : la clé de travail encapsulée, les enregistrements de page, les IV et les offsets. Il n'y a pas de second facteur au moment du déchiffrement. Une copie de l'identifiant sur un ordinateur portable, un runner CI ou une sauvegarde vaut autant que l'original.

L'identifiant est une valeur porteuse. Le dépôt ne contient aucune logique d'expiration ou de révocation. La question de savoir si Apple invalide le matériel côté serveur n'est pas tranchée par le code public. Le README de l'outil rappelle que l'identifiant est destiné au compte qui possède l'IPA, et UnfairPlay demande de garder le modèle privé et de ne le sauvegarder que dans un stockage chiffré. C'est le bon conseil, et c'est aussi une description du risque : quiconque détient la valeur peut l'utiliser.

Ce qui n'est pas la faiblesse compte aussi. AES-128-CBC n'est pas cassé. L'appel MD5 dérive un IV à partir de valeurs publiques ; ce n'est pas la frontière de confidentialité. Le mélangeur maison est obscur, pas une preuve de sécurité, et le code public le réimplémente. L'obfuscation de fairplayd par Apple augmente le coût de l'extraction : l'analyse statique de Nicolò Altamura sur macOS 13.5.1 décrit des prédicats opaques, un aplatissement du flux de contrôle et des constantes arithmétiques booléennes mixtes, juge les prédicats opaques faibles et l'aplatissement du flux de contrôle efficace. L'obfuscation change la difficulté d'obtenir l'identifiant. Elle ne change pas ce que l'identifiant permet une fois obtenu.

Jusqu'où un identifiant peut-il aller ?

La première étape est une app. La deuxième est la bibliothèque du compte. La troisième est un pipeline automatisé. Chaque étape découle de la même conception.

• D'une app à plusieurs. Un identifiant fonctionne pour les apps du compte ou de l'enrôlement dont il provient. Les apps classiques de l'App Store et les apps Apple Arcade utilisent des identifiants séparés, selon le README de fairplay-decrypt ; une bibliothèque Arcade exige donc sa propre extraction. Dans une même classe, l'identifiant n'est pas lié à un identifiant de bundle.
• De l'iPhone au Mac. UnfairPlay récupère son modèle depuis un Mac enrôlé, pas depuis un iPhone jailbreaké. Le README indique que le modèle est lié à l'enrôlement du Mac App Store et peut déchiffrer d'autres IPA personnalisées pour le même enrôlement. Le déchiffrement s'exécute ensuite sous macOS ou Linux, et le fairplayd natif n'est jamais lancé par l'outil. C'est la même concentration de confiance avec un autre point de capture.
• Du manuel au CI. Le déchiffrement hors ligne est une fonction pure de l'IPA et de l'identifiant. Il peut tourner dans un conteneur, être mis en file, réessayé et audité. Une équipe de sécurité peut analyser une app sans brancher d'appareil ; un attaquant peut la reconstruire sans ferme d'appareils. Le coût des deux baisse.
• Du clair à l'impact. Une fois les pages en clair, l'app est un Mach-O ordinaire. Un analyste peut lire les endpoints, les clés embarquées, les drapeaux de fonctionnalité et la logique de licence ; comparer deux versions ; trouver des vulnérabilités ; contourner une vérification ; injecter un dylib ; ou reconstruire une app modifiée. FairPlay était la barrière de confidentialité, pas la barrière d'intégrité. La signature de code compte toujours pour l'installation, mais elle ne rend pas le code récupéré secret à nouveau.
• D'un identifiant à une bibliothèque. Le rayon d'action est le compte, pas l'app. Un compte de test partagé, un compte de revendeur ou un secret de CI peut couvrir un large catalogue. Un seul fichier credential.bin ou un seul modèle divulgué déverrouille toutes les apps que ce compte ou cet enrôlement peut déchiffrer. C'est la différence entre perdre un binaire et perdre une collection.

La conception au niveau du compte a déjà échoué autrement. Le rapport AceDeceiver de Unit 42 de 2016 décrit un man-in-the-middle FairPlay qui rejouait une autorisation d'achat stockée pour installer des apps sans certificat d'entreprise, et le qualifie de « the first iOS malware we've seen that abuses certain design flaws in Apple's DRM protection mechanism ». Apple a retiré les trois apps de l'App Store le 25 février 2016. AceDeceiver abusait de l'autorisation d'installation, pas du déchiffrement hors ligne ; c'est un précédent de problèmes de conception FairPlay au niveau du compte, pas une description de cet outil.

Nous n'avons trouvé aucune CVE attribuée à la conception du déchiffrement. Une recherche par mot-clé dans le NVD pour fairplay ne renvoie aucun enregistrement au 12 novembre 2026, et le catalogue CISA KEV version 2026.11.10 ne contient aucune entrée FairPlay. Cela concorde avec une propriété de conception démontrée par un outil public, pas avec une vulnérabilité logicielle d'un éditeur disposant d'une version corrigée.

Que doivent faire les défenseurs et les développeurs ?

Si vous acquérez des IPA pour des tests autorisés, l'identifiant est désormais le fichier le plus sensible du pipeline. Traitez-le comme un secret de compte, car c'en est un.

• Utilisez un compte Apple dédié au programme de test. Ne réutilisez pas un compte personnel, un compte d'équipe partagé ou un compte qui contient des achats de production.
• Gardez credential.bin ou le modèle UnfairPlay dans un gestionnaire de secrets, chiffré au repos, avec journalisation des accès et un propriétaire nommé. Ne le mettez pas dans un dépôt, un journal de build ou un ticket.
• Limitez qui peut lancer le déchiffrement et quelles IPA entrent dans la file. Enregistrez le compte, l'app et la date de chaque exécution pour pouvoir auditer l'usage.
• Faites tourner ou retirer le compte à la fin de la mission. Le code public n'a pas d'interrupteur d'expiration ; le contrôle opérationnel consiste à cesser d'utiliser l'identifiant et à le supprimer.
• Lors du partage de résultats, retirez les données de compte. L'option --strip-account-data d'UnfairPlay supprime les membres SC_Info et les champs Apple ID et acheteur de iTunesMetadata.plist ; le README de l'outil rappelle néanmoins que la rédaction n'autorise pas la redistribution.
• Ne partagez jamais SINF, SUPF, SIDB, un fichier de modèle ou une IPA déchiffrée hors du périmètre autorisé. Les fichiers de licence identifient le compte, et le modèle est réutilisable.

Si vous développez une app iOS, partez du principe qu'un analyste déterminé finira par obtenir le binaire. FairPlay augmente le coût ; il ne fait pas du code côté client un secret.

• N'embarquez pas de clés d'API de longue durée, de clés privées, d'identifiants serveur ou de matériel de signature dans l'app. Déplacez la logique précieuse et les secrets vers un serveur que vous contrôlez.
• Utilisez des jetons de courte durée liés à l'utilisateur et à l'appareil, une autorisation côté serveur et une attestation d'appareil lorsque le risque le justifie. Le certificate pinning augmente le coût de l'interception ; il ne protège pas un secret déjà présent dans le binaire.
• Considérez les vérifications de licence côté client comme de l'expérience utilisateur, pas comme une frontière de sécurité. Un binaire patché peut les contourner, et un binaire déchiffré rend le patch plus facile à écrire.
• Gardez le serveur comme autorité pour les droits, les limites de débit et les fonctionnalités payantes. Si une fonctionnalité ne doit pas être copiée, appliquez la règle là où l'utilisateur ne peut pas modifier le code.

Les corrections côté plateforme sont des changements de conception, pas un patch que nous pouvons citer. Un éditeur pourrait lier les clés de page à un secret détenu par l'appareil à chaque lancement, émettre un matériel de licence de courte durée et le faire tourner côté serveur, rendre l'identifiant de compte non exportable depuis le matériel sécurisé et détecter l'attachement d'un débogueur ou d'un port d'exception à fairplayd. Tout schéma qui déchiffre du code sur un appareil contrôlé par l'utilisateur doit encore exposer une clé à cet appareil à un moment donné ; l'objectif est de rendre la clé éphémère, liée à l'appareil et de courte durée, pas de prétendre que le déchiffrement côté client peut être rendu absolu.

Pour les utilisateurs, le conseil pratique est plus étroit. Activez l'authentification à deux facteurs sur le compte Apple, ne partagez pas le compte et n'installez pas d'IPA provenant de sources non fiables. Le risque principal de cet article est la confidentialité du code des apps et le rayon d'action d'un compte partagé, pas une compromission distante d'un téléphone verrouillé.

Qu'est-ce qui n'a pas pu être vérifié ?

• Le schéma exact de dérivation des clés d'Apple pour les binaires de l'App Store, et la question de savoir si la clé de travail priv du SINF est unique par app, par compte ou par transaction. Le comportement de l'outil public est la preuve ; Apple ne publie pas de spécification.
• La question de savoir si Apple fait tourner ou révoque l'identifiant de compte côté serveur. Le code public ne contient aucune logique d'expiration ou de révocation, mais une invalidation côté serveur ne peut pas être exclue à partir du dépôt.
• Le comportement sur les versions actuelles d'iOS. Le README du récupérateur annonce iOS 10 et ultérieur, et le code contient des notes propres à iOS 16.3.1, mais nous ne l'avons pas testé sur un appareil. Un changement de fairplayd peut casser la récupération sans changer le format hors ligne.
• Les internes de la récupération du modèle d'UnfairPlay. Nous avons lu son README et ses garanties annoncées, pas tout son code de récupération.
• Les dispositions exactes des SINF et SUPF au-delà des versions prises en charge par l'outil : SUPF de version 3 et 5, priv de 440 et 448 octets et tranches arm64. D'autres versions peuvent exister.
• Le nombre de comptes, d'apps ou d'identifiants en circulation. Aucune télémétrie n'est publiée, et les étoiles et forks du dépôt mesurent l'intérêt, pas l'exploitation.
• La question de savoir si la vidéo FairPlay Streaming utilise la même hiérarchie de clés. L'étude académique de 2023 de Rafi, Shepherd et Markantonakis couvre le DRM mobile, notamment FairPlay, mais se concentre sur le contenu en streaming, pas sur les binaires d'IPA de l'App Store ; c'est donc un contexte, pas une preuve pour cette voie.

FAQ

Existe-t-il une CVE pour le déchiffrement des apps FairPlay ?

Nous n'en avons trouvé aucune. Une recherche par mot-clé dans le NVD pour fairplay ne renvoie aucun enregistrement au 12 novembre 2026, et le catalogue CISA KEV version 2026.11.10 ne contient aucune entrée FairPlay. L'outil public et la conception qu'il démontre ne sont pas suivis comme une CVE.

S'agit-il d'un exploit de jailbreak ?

Non. Il n'exploite pas de corruption mémoire du noyau. Il exige un accès root sur un appareil jailbreaké pour s'attacher à fairplayd et observer l'appel FairPlay. Le déchiffrement lui-même est hors ligne et ne nécessite pas de jailbreak.

Un identifiant déchiffre-t-il toutes les IPA du monde ?

Non. L'identifiant est limité au compte ou à l'enrôlement qui l'a produit, et le SINF de chaque app est personnalisé pour cette portée. Les apps Apple Arcade ont besoin d'un identifiant distinct de celui des apps classiques de l'App Store, selon le README de fairplay-decrypt. La faiblesse est l'étendue à l'intérieur d'un compte, pas une clé mondiale.

Cela affecte-t-il la vidéo FairPlay Streaming ?

Ce n'est pas établi. L'outil public cible les binaires d'IPA de l'App Store et leurs licences SINF/SUPF. FairPlay Streaming est une voie média distincte, et l'étude de 2023 qui le couvre est un contexte, pas une preuve que le même identifiant déchiffre la vidéo.

Apple peut-il corriger cela ?

Apple peut changer la conception : lier les clés à un secret d'appareil à chaque lancement, raccourcir la durée de vie des licences, faire tourner le matériel côté serveur, rendre l'identifiant non exportable et durcir l'IPC FairPlay. Tout déchiffrement côté client doit encore exposer une clé à l'appareil qui lit le contenu ; l'objectif pratique est de réduire la durée de vie et la portée de cette clé, pas de la rendre inextractible au sens absolu.

Est-ce exploité dans la nature ?

Aucune attaque utilisant l'outil n'est signalée dans le projet ou les sources examinées au 12 novembre 2026. Le dépôt comptait plus de 2 400 étoiles et 370 forks à cette date, et UnfairPlay plus de 1 100 étoiles. Ces chiffres montrent l'intérêt, pas l'exploitation.

Références

• EthanArbuckle/fairplay-decrypt, README, créé le 19 octobre 2026, dernier commit le 8 novembre 2026 : https://github.com/EthanArbuckle/fairplay-decrypt (consulté le 12 novembre 2026)
• core.py, le déverrouillage du priv du SINF, l'analyse du SUPF, la dérivation des clés de page et la remise à zéro de cryptid : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/core.py (consulté le 12 novembre 2026)
• decrypt.py, la gestion du ZIP de l'IPA et le plan par binaire : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/decrypt.py (consulté le 12 novembre 2026)
• credential-retrieval/README.md, iOS 10 et ultérieur, la séparation des identifiants Apple Arcade et les prérequis de l'appareil : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/README.md (consulté le 12 novembre 2026)
• credential.c, le déchiffrement du SIDB, la sélection user/key et la dérivation de l'identifiant : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/credential/credential.c (consulté le 12 novembre 2026)
• observer.c, task_for_pid(), les points d'arrêt matériels et le contournement de XNU 8792 : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/credential/observer.c (consulté le 12 novembre 2026)
• trigger.c, la demande de première utilisation via mremap_encrypted() et son commentaire : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/trigger/trigger.c (consulté le 12 novembre 2026)
• DrWhax/unfairplay, README, le modèle d'enrôlement, la portée multi-IPA, le déchiffrement macOS/Linux et l'option --strip-account-data : https://github.com/DrWhax/unfairplay (consulté le 12 novembre 2026)
• Apple, App code signing process in iOS, iPadOS, tvOS, visionOS, and watchOS, publié le 19 décembre 2024 : https://support.apple.com/guide/security/app-code-signing-process-sec7c917bf14/web (consulté le 12 novembre 2026)
• Apple, Security of runtime process in iOS, iPadOS, and visionOS, publié le 19 décembre 2024 : https://support.apple.com/guide/security/security-of-runtime-process-sec15bfe098e/web (consulté le 12 novembre 2026)
• Apple XNU, bsd/kern/mach_loader.c, set_code_unprotect(), LOAD_DECRYPTFAIL et EXEC_EXIT_REASON_FAIRPLAY_DECRYPT : https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/mach_loader.c (consulté le 12 novembre 2026)
• Apple XNU, osfmk/vm/vm_apple_protect.c, le gestionnaire de mémoire externe et la boucle page_decrypt de 4 Ko : https://github.com/apple-oss-distributions/xnu/blob/main/osfmk/vm/vm_apple_protect.c (consulté le 12 novembre 2026)
• Apple XNU, EXTERNAL_HEADERS/mach-o/loader.h, les champs de encryption_info_command : https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/loader.h (consulté le 12 novembre 2026)
• SensePost, « Decrypting iPhone Apps », 24 octobre 2011, les champs cryptid et la méthode de vidage mémoire : https://sensepost.com/blog/2011/decrypting-iphone-apps/ (consulté le 12 novembre 2026)
• Noham, « Anatomy of an iOS crack », 15 mai 2026, les fichiers SC_Info et la disposition des champs SINF : https://noh.am/en/posts/rev-dylib/ (consulté le 12 novembre 2026)
• pwn0rz, fairplay_research, le flux FairPlayIOKit/fairplayd et l'étape AES matérielle : https://github.com/pwn0rz/fairplay_research (consulté le 12 novembre 2026)
• Nicolò Altamura, « Analysis of Obfuscation Found in Apple FairPlay », 28 août 2023, macOS 13.5.1 : https://nicolo.dev/en/blog/fairplay-apple-obfuscation/ (consulté le 12 novembre 2026)
• Unit 42, Claud Xiao, « AceDeceiver: First iOS Trojan Exploiting Apple DRM Design Flaws to Infect Any iOS Device », 16 mars 2016 : https://unit42.paloaltonetworks.com/acedeceiver-first-ios-trojan-exploiting-apple-drm-design-flaws-to-infect-any-ios-device/ (consulté le 12 novembre 2026)
• Recherche par mot-clé du NVD pour fairplay, zéro enregistrement : https://nvd.nist.gov/vuln/search/results?query=fairplay&search_type=all (consulté le 12 novembre 2026)
• CISA, catalogue Known Exploited Vulnerabilities, version 2026.11.10, aucune entrée FairPlay : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consulté le 12 novembre 2026)
• Amir Rafi, Carlton Shepherd et Konstantinos Markantonakis, « A First Look at Digital Rights Management Systems for Secure Mobile Content Delivery », arXiv:2308.00437, août 2023 : https://arxiv.org/abs/2308.00437 (consulté le 12 novembre 2026)