fairplay-decrypt : déchiffrement hors ligne d'IPA FairPlay

En bref

• fairplay-decrypt est un outil sous GPLv3 qui déchiffre les IPA FairPlay de l'App Store sans lancer l'app. Il utilise un identifiant de 16 octets pour le compte Apple qui possède l'IPA.
• Le récupérateur exige un iPhone jailbreaké sous iOS 10 ou version ultérieure, avec un accès SSH root et une app installée depuis ce compte. Le déchiffrement s'exécute ensuite hors ligne sous macOS ou Linux avec Python 3.9 ou version ultérieure.
• La faiblesse est un identifiant de compte réutilisable qui déballe la clé de chaque app. Une capture déchiffre les IPA correspondants du compte. Aucune CVE n'est attribuée, et le catalogue KEV de la CISA 2026.11.10 ne contient aucune entrée FairPlay.
• Traitez l'IPA comme public lorsque l'identifiant du compte peut être capturé. Gardez les secrets côté serveur, détectez les versions réempaquetées et installez les apps uniquement depuis l'App Store. Voir « Comment corriger ? ».

Suis-je concerné ?

Vous êtes exposé si votre app est livrée sous forme d'IPA arm64 chiffré par FairPlay et qu'un attaquant peut obtenir un identifiant pour un compte Apple qui la possède. Toutes ces conditions doivent être réunies :

• Votre version App Store est chiffrée par FairPlay. L'outil ne traite que les tranches Mach-O arm64 avec LC_ENCRYPTION_INFO_64 et un cryptid non nul.
• L'attaquant détient l'identifiant de 16 octets du type correspondant pour un compte Apple qui possède l'app, ou un modèle réutilisable récupéré depuis une inscription Mac liée à ce compte.
• L'attaquant possède l'IPA. Il peut l'acheter avec ce compte, le recevoir d'un partenaire ou le voler.
• Il peut exécuter l'outil sous macOS ou Linux. Le déchiffrement n'a besoin d'aucun accès réseau à Apple ni à vos serveurs.

Ce n'est pas une vulnérabilité distante dans l'app. C'est une propriété de l'enveloppe FairPlay autour de l'IPA, et l'étape de capture exige un appareil compromis ou un Mac inscrit. Un identifiant d'un compte ne déchiffre pas une app possédée par un autre compte. L'outil ne traite ni la vidéo FairPlay Streaming, ni les binaires 32 bits, ni les IPA non chiffrés.

Un identifiant normal couvre les apps App Store normales. Le README du récupérateur indique que les apps Apple Arcade exigent un identifiant Arcade distinct, donc une capture ne couvre pas les deux types.

Vérifiez si un IPA est chiffré. Sous macOS, extrayez le binaire principal et lisez sa commande de chargement de chiffrement :

unzip -p App.ipa Payload/App.app/App > /tmp/App
otool -l /tmp/App | grep -A4 LC_ENCRYPTION_INFO_64
codesign -dv --verbose=4 /tmp/App

Une valeur cryptid de 1 signifie que les pages sont chiffrées. Une valeur de 0 signifie que le binaire est déjà en clair. Remplacez Payload/App.app/App par le chemin de l'exécutable dans l'IPA. La commande codesign affiche le TeamIdentifier de la signature, à comparer avec le vôtre.

Comment corriger ?

Le dépôt ne publie aucune version corrigée, car il s'agit de l'outil de déchiffrement et non d'un produit avec une version corrigée. Ces étapes réduisent l'exposition et limitent ce qu'une copie déchiffrée révèle :

1. Traitez l'IPA déchiffré comme public. Supprimez les clés d'API, les secrets de signature et les algorithmes propriétaires qui doivent rester confidentiels. Un secret côté client est lisible une fois les pages en clair.
2. Déplacez les décisions sensibles vers votre serveur. Autorisez les actions côté serveur avec des jetons de courte durée, et ne faites pas confiance à une valeur embarquée dans le binaire.
3. Ajoutez une détection de réempaquetage et une attestation côté serveur. App Attest et DeviceCheck d'Apple peuvent signaler un client modifié, mais ils n'empêchent pas le déchiffrement.
4. Pour les utilisateurs, installez les apps uniquement depuis l'App Store ou TestFlight. Pour les flottes gérées, bloquez l'installation hors du catalogue géré.
5. Si vous pensez qu'un identifiant de compte a été capturé, cessez d'utiliser ce compte pour la distribution et traitez chaque IPA qui en provient comme exposé. Examinez son historique d'achats.

Ces étapes n'empêchent pas le déchiffrement d'un IPA que le compte possède. Elles limitent ce que la copie déchiffrée révèle et la manière dont elle peut être détournée.

Quelle est la cause racine ?

FairPlay chiffre chaque page de 4 Ko avec une clé dérivée de deux fichiers de SC_Info, et la chaîne commence par un identifiant de compte de 16 octets. Le chiffrement est AES-128. La faiblesse tient à l'endroit où le secret racine est conservé, pas à un chiffrement cassé.

Les trois fichiers qui comptent

• <Name>.sinf est un arbre d'atomes avec le name du compte, un iviv de 16 octets et un enregistrement priv de 440 ou 448 octets.
• <Name>.supf ou <Name>.v5.supf contient un enregistrement de 32 octets par page chiffrée : une clé encapsulée de 16 octets et un IV AES-CBC de 16 octets.
• L'en-tête Mach-O arm64 porte LC_ENCRYPTION_INFO_64 avec cryptoff, cryptsize et cryptid, qui localisent les pages chiffrées.

derive_work16() transforme l'identifiant de compte et l'enregistrement priv en une clé de travail de 16 octets propre à l'app. Dans l'extrait, name, iviv, credential et raw_priv sont les champs SINF et l'identifiant de 16 octets lus par l'analyseur. La clé est l'identifiant XORé avec l'octet 0x30, pas l'identifiant seul. L'IV est le MD5 du nom du compte et de iviv :

iv = hashlib.md5(name + iviv).digest()
op = Cipher(algorithms.AES(_xor(credential, b"0" * 16)), modes.CBC(iv)).decryptor()
clear = op.update(raw_priv) + op.finalize()
if clear[:4] != b"itun" or clear[20:24] != b"key " or clear[44:48] != b"iviv":
    raise ValueError("credential does not decode this SINF priv record")
return clear[24:40]

derive_page_key() prend l'enregistrement encapsulé de 16 octets, l'index de page et la clé de travail. Il chiffre trois blocs source de 16 octets avec AES-128-ECB sous la clé de travail, puis les mélange via une transformation personnalisée appelée finish() :

a, b, c = (
    struct.unpack(">8H", block_transform(s, work))
    for s in source_blocks(wrapped, absolute_index)
)
return struct.pack(">8H", *finish(_xor_int(finish(_xor_int(finish(a), b)), c)))

finish() exécute quatre tours de 16 bits et quatre tours de 32 bits d'additions, de mises au carré et de XOR. Les commentaires du code indiquent qu'une retenue est conservée et l'autre abandonnée. Cette transformation est de l'obfuscation au-dessus d'AES, pas un second secret. Le résultat de 16 octets est la clé AES-CBC de la page, et les 16 octets suivants de l'enregistrement SUPF sont son IV.

La clé propre à l'app est chiffrée sous un secret de compte, donc un identifiant déballe l'enregistrement priv de chaque app correspondante que le compte possède. Le récupérateur récupère cet identifiant sur l'appareil. Il place des points d'arrêt matériels sur la fonction de sélection de fairplayd et déclenche une opération de licence via une app installée.

Le récupérateur capture la sortie du sélecteur et l'état du keybag. Il combine cet état avec l'UDID de l'appareil et les tables de l'outil pour produire le fichier de 16 octets.

La conception suppose que le système d'exploitation de l'appareil garde l'état de fairplayd privé. Un appareil jailbreaké avec un accès root n'offre pas cette frontière de confiance. C'est la faiblesse de conception : l'identifiant est propre au compte, réutilisable et récupérable depuis l'espace utilisateur sur un appareil compromis.

Comment la faille est-elle exploitée ?

Un attaquant qui contrôle un iPhone jailbreaké et un compte Apple qui possède l'app cible récupère un identifiant et déchiffre hors ligne les IPA correspondants. L'outil public suit ce chemin :

1. Préparez un iPhone jailbreaké sous iOS 10 ou version ultérieure avec un accès SSH root, et installez au moins une app App Store depuis le compte cible.
2. Compilez le récupérateur sur un Mac avec Xcode, ldid, idevice_id et iproxy, puis exécutez credential-retrieval/retrieve.py contre l'appareil.
3. Le récupérateur place des points d'arrêt dans fairplayd, lance une app installée pour déclencher une opération de licence, capture la sortie du sélecteur et l'état du keybag, et écrit credential.bin.
4. Obtenez l'IPA cible depuis le même compte Apple.
5. Exécutez decrypt.py avec l'IPA et l'identifiant. Il analyse la commande de chiffrement Mach-O, l'enregistrement SINF et la table SUPF, dérive la clé de travail et chaque clé de page, déchiffre les pages, efface cryptid et écrit un nouvel IPA.
6. Re-signez la sortie si elle doit être installée. Le déchiffrement efface le marqueur de chiffrement mais ne crée pas de signature de code valide.

Rien dans le chemin de déchiffrement ne contacte Apple. La seule interaction avec l'appareil est l'étape de capture. Le déchiffreur est en Python pur et s'exécute sous macOS ou Linux.

Comment se déroule l'attaque ?

Un appareil jailbreaké observe fairplayd pour récupérer l'identifiant du compte, et l'identifiant déballe la clé de chaque app afin que les pages soient déchiffrées hors ligne.

Que peut faire un attaquant ?

Un attaquant qui possède l'identifiant peut déchiffrer les IPA correspondants que le compte Apple possède, hors ligne et de façon répétée, puis lire ou réempaqueter leur code et leurs ressources. L'impact porte sur la confidentialité et le réempaquetage, pas sur l'exécution de code à distance.

Les conditions font partie de l'impact :

• L'app doit appartenir au compte de l'identifiant et correspondre à son type. Le README indique que chaque identifiant fonctionne avec les apps du compte Apple dont il provient, et qu'une app Arcade exige l'identifiant Arcade distinct.
• L'IPA doit contenir des tranches arm64 chiffrées avec une paire SINF et SUPF prise en charge.
• L'attaquant a besoin d'une copie de l'IPA.
• Le réempaquetage pour l'installation exige une identité de signature. L'outil ne signe pas.
• Le déchiffrement ne contourne ni l'authentification côté serveur, ni la logique métier, ni App Attest. Ces contrôles s'exécutent toujours lorsque l'app réempaquetée appelle vos serveurs.

Un IPA déchiffré expose le code Swift et Objective-C, les chaînes, la configuration embarquée, les points de terminaison d'API et toute clé ou tout jeton embarqué dans le binaire. Cela accélère la recherche de vulnérabilités et facilite le réempaquetage. Un attaquant peut injecter un framework ou modifier des ressources, re-signer le bundle et le distribuer hors de l'App Store.

Un second projet public, UnfairPlay, récupère un modèle réutilisable depuis un Mac inscrit au lieu d'un iPhone jailbreaké. Son README indique qu'un modèle déchiffre d'autres IPA personnalisés de la même inscription et peut convertir un IPA iOS en disposition macOS. Cela abaisse la barrière d'un téléphone jailbreaké à un compte Mac App Store. Le projet est apparu le 25 octobre 2026, six jours après le premier commit de fairplay-decrypt.

UnfairPlay avertit aussi que sa sortie conserve les licences SC_Info et le fichier iTunesMetadata.plist de l'entrée, qui identifient le compte du Store, sauf si l'opérateur les supprime. Un IPA déchiffré partagé sans précaution peut donc exposer l'identité du compte en plus du code.

Le 12 novembre 2026, le dépôt fairplay-decrypt comptait plus de 2 400 étoiles et 375 forks. L'intérêt n'est pas l'exploitation : aucune attaque utilisant l'outil n'est signalée dans le projet ni dans les sources examinées.

Utilisez l'outil uniquement sur des apps que vous êtes autorisé à analyser. La commande de déchiffrement décrit son entrée comme un IPA autorisé.

Pourquoi le correctif fonctionne-t-il ?

Aucune version corrigée n'existe à citer, donc rien dans le projet ne ferme la faiblesse de conception. Un correctif devrait changer la hiérarchie des clés, pas une fonction d'analyse. Trois changements augmenteraient le coût :

• Lier la clé propre à l'app à un secret matériel que le système d'exploitation ne peut pas lire, comme la Secure Enclave, et attester le système avant de la libérer.
• Livrer une clé propre à l'app et à la session depuis un serveur qui vérifie l'appareil et le compte, au lieu de la dériver d'un identifiant de compte conservé sur l'appareil.
• Faire tourner le schéma d'identifiants et invalider les identifiants capturés lorsqu'une utilisation abusive est détectée.

Aucun de ces changements n'est un correctif d'une ligne, et chacun fait encore confiance à l'appareil dans une certaine mesure. Un système jailbreaké peut observer un démon en espace utilisateur même lorsqu'une clé est encapsulée. Dans ce cas, le DRM côté client n'a pas gardé le code confidentiel face à un propriétaire d'appareil disposant d'un accès noyau.

Le projet suit les changements d'Apple. Il a ajouté la récupération pour iOS 10 à 12, la prise en charge des pages de 16 Ko, SUPF version 5, plusieurs tranches arm64 et les identifiants Apple Arcade. Aucune CVE n'est attribuée à fairplay-decrypt, et le projet n'a aucune version qui supprime la dépendance à l'identifiant de compte.

Comment vérifier si j'ai été compromis ?

Une copie déchiffrée ne laisse aucune trace sur vos serveurs, donc cherchez les versions réempaquetées et l'exposition d'un identifiant de compte. Pour chaque version distribuée, recherchez ces pistes :

• Un cryptid de 0 dans une version qui devrait être chiffrée.
• Une signature de code dont le TeamIdentifier n'est pas le vôtre.
• Un identifiant de bundle, un Info.plist ou un embedded.mobileprovision différent de votre version.
• Des frameworks injectés ou des fichiers SC_Info supplémentaires.
• Une distribution hors de l'App Store ou de TestFlight.

Extrayez le binaire principal et inspectez-le :

unzip -p Suspicious.ipa Payload/App.app/App > /tmp/App
otool -l /tmp/App | grep -A4 LC_ENCRYPTION_INFO_64
codesign -dv --verbose=4 /tmp/App

Un binaire en clair accompagné d'une signature d'une autre équipe est une piste sérieuse, pas une preuve de déchiffrement. Un binaire non chiffré ne prouve pas que la copie a été déchiffrée.

Côté serveur, examinez les échecs d'App Attest et de DeviceCheck, les signaux d'appareil jailbreaké et les clients d'API avec des versions inattendues ou des en-têtes d'intégrité absents. Ce sont aussi des pistes, pas des preuves. Le projet ne publie aucun indicateur de compromission. Le déchiffrement est une opération de fichier hors ligne qui n'appelle pas de serveur, donc une tentative échouée peut ne laisser aucune trace.

Chronologie

• 2026-10-19 : Le dépôt EthanArbuckle/fairplay-decrypt reçoit son premier commit public.
• 2026-10-22 : Le README confirme la prise en charge d'iOS 15.
• 2026-10-23 : Un commit ajoute la récupération des identifiants pour iOS 10 à 12.
• 2026-10-25 : Le projet macOS UnfairPlay est créé.
• 2026-10-30 : Le projet ajoute une licence GPLv3 et la récupération des identifiants Apple Arcade.
• 2026-11-08 : Le dernier commit remplace la capture Arcade par l'observation IOKit de FairPlay.

FAQ

Existe-t-il une CVE pour fairplay-decrypt ?

Non. Le projet est un outil de recherche, pas une vulnérabilité de produit avec une version corrigée. La NVD ne renvoie aucun enregistrement FairPlay pour ce projet au 12 novembre 2026, et le catalogue KEV de la CISA 2026.11.10 ne contient aucune entrée FairPlay.

Faut-il un jailbreak ?

Pour fairplay-decrypt, oui au moment de la capture. Le récupérateur exige un iPhone jailbreaké avec un accès SSH root. Le déchiffrement lui-même s'exécute sous macOS ou Linux sans le téléphone. Le projet distinct UnfairPlay utilise un Mac inscrit au lieu d'un iPhone jailbreaké.

Un identifiant déchiffre-t-il toutes les apps ?

Il déchiffre les IPA correspondants du compte Apple de l'identifiant. Un identifiant normal couvre les apps normales, et le README indique que les apps Arcade exigent un identifiant Arcade distinct. Il ne déchiffre pas les apps d'autres comptes, ni la vidéo FairPlay Streaming.

La sortie est-elle installable ?

Pas telle quelle. L'outil efface cryptid mais ne re-signe pas le binaire. iOS exige une signature valide, donc la sortie doit être re-signée avec un profil de provisionnement avant l'installation.

Quelles apps et quelles versions d'iOS sont couvertes ?

Le récupérateur indique iOS 10 ou version ultérieure. Le déchiffreur prend en charge les tranches Mach-O arm64, les versions 3 et 5 de SUPF, et les enregistrements SINF priv de 440 ou 448 octets. Il ne traite pas les apps 32 bits ni les binaires non chiffrés.

Est-il exploité dans la nature ?

Non. Aucune attaque utilisant l'outil n'est signalée dans le projet ni dans les sources examinées au 12 novembre 2026. Il n'est pas dans le catalogue KEV de la CISA. Les nombres d'étoiles et de forks montrent l'intérêt, pas l'exploitation.

Références

• Dépôt EthanArbuckle/fairplay-decrypt, README, avec l'identifiant de 16 octets, les formats pris en charge et le déchiffrement hors ligne : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/README.md (vérifié le 12 novembre 2026)
• core.py au commit d81d98b13656c9dbb340f04dd0838137278f44a5, la dérivation SINF, SUPF et des clés de page : https://github.com/EthanArbuckle/fairplay-decrypt/blob/d81d98b13656c9dbb340f04dd0838137278f44a5/core.py (vérifié le 12 novembre 2026)
• decrypt.py au même commit, l'entrée IPA et le chemin de sortie : https://github.com/EthanArbuckle/fairplay-decrypt/blob/d81d98b13656c9dbb340f04dd0838137278f44a5/decrypt.py (vérifié le 12 novembre 2026)
• credential-retrieval/README.md, les prérequis de l'appareil jailbreaké, iOS 10 ou version ultérieure, et l'identifiant de compte réutilisable : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/README.md (vérifié le 12 novembre 2026)
• credential-retrieval/credential/observer.c, les points d'arrêt matériels et l'observateur FairPlay : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/credential/observer.c (vérifié le 12 novembre 2026)
• credential-retrieval/credential/credential.c, le sélecteur, le keybag et la dérivation de l'identifiant : https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/credential/credential.c (vérifié le 12 novembre 2026)
• Commit 5fdf16b48ea4a2a32950641aba23dd3063c34856, le premier commit public le 19 octobre 2026 : https://github.com/EthanArbuckle/fairplay-decrypt/commit/5fdf16b48ea4a2a32950641aba23dd3063c34856 (vérifié le 12 novembre 2026)
• Commit 9e5aa3ea290d79c3320190004dc512e034d99484, la licence GPLv3 le 30 octobre 2026 : https://github.com/EthanArbuckle/fairplay-decrypt/commit/9e5aa3ea290d79c3320190004dc512e034d99484 (vérifié le 12 novembre 2026)
• Commit 8350383e2e9050f7a77197bf32545ddbef90b57c, la récupération des identifiants Apple Arcade le 30 octobre 2026 : https://github.com/EthanArbuckle/fairplay-decrypt/commit/8350383e2e9050f7a77197bf32545ddbef90b57c (vérifié le 12 novembre 2026)
• Commit 5e35c7a, la prise en charge d'iOS 10 à 12 le 23 octobre 2026 : https://github.com/EthanArbuckle/fairplay-decrypt/commit/5e35c7a (vérifié le 12 novembre 2026)
• Historique des commits de EthanArbuckle/fairplay-decrypt, avec les changements iOS 10 à 12, pages de 16 Ko, SUPF v5, tranches multiples et Arcade : https://github.com/EthanArbuckle/fairplay-decrypt/commits/main (vérifié le 12 novembre 2026)
• Dépôt DrWhax/unfairplay, README, la voie du Mac inscrit et le modèle réutilisable : https://github.com/DrWhax/unfairplay/blob/main/README.md (vérifié le 12 novembre 2026)
• Page du dépôt DrWhax/unfairplay, créée le 25 octobre 2026 : https://github.com/DrWhax/unfairplay (vérifié le 12 novembre 2026)
• vnc0/fairplay-scinfo, documentation des formats SINF et SUPF et des clés de page encapsulées : https://github.com/vnc0/fairplay-scinfo (vérifié le 12 novembre 2026)
• Apple, loader.h, la structure LC_ENCRYPTION_INFO_64 et le champ cryptid : https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/loader.h (vérifié le 12 novembre 2026)
• CISA, catalogue Known Exploited Vulnerabilities au format JSON, version 2026.11.10, aucune entrée FairPlay : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 12 novembre 2026)
• Recherche NVD pour FairPlay, aucun enregistrement pour le projet au 12 novembre 2026 : https://nvd.nist.gov/vuln/search/results?query=fairplay&search_type=all (vérifié le 12 novembre 2026)
• Page du dépôt EthanArbuckle/fairplay-decrypt, plus de 2 400 étoiles et 375 forks le 12 novembre 2026 : https://github.com/EthanArbuckle/fairplay-decrypt (vérifié le 12 novembre 2026)