Cómo FairPlay protege los binarios de apps iOS, y una debilidad a nivel de cuenta

Resumen

• FairPlay cifra el rango de un binario Mach-O de iOS declarado por su comando de carga LC_ENCRYPTION_INFO o LC_ENCRYPTION_INFO_64. El kernel descifra ese rango en bloques de 4 KB a medida que se cargan las páginas, y las páginas descifradas nunca se vuelven a escribir en el archivo. Por eso el método antiguo para analizar una app de la App Store consistía en volcar su memoria mientras se ejecutaba.
• Cada IPA también incluye una licencia SC_Info. El registro SINF encapsula una clave de trabajo de 16 bytes propia de la app, y el registro SUPF proporciona un valor encapsulado de 16 bytes y un IV de 16 bytes para cada página de 4 KB. La clave de página se deriva de la clave de trabajo, del registro de página y del desplazamiento en el archivo.
• La herramienta pública EthanArbuckle/fairplay-decrypt muestra que la jerarquía se reduce a una credencial reutilizable de 16 bytes. La credencial se extrae una vez de un dispositivo con jailbreak; después, el descifrado es fuera de línea, determinista y no necesita ningún dispositivo.
• La debilidad no es un cifrado roto. Es un diseño de clave portadora: la credencial desbloquea la clave de trabajo distinta de cada app, y las claves de página se derivan de esa clave de trabajo en lugar de ser secretos independientes. Por tanto, una credencial desbloquea todas las apps de la cuenta o del registro.
• Un segundo proyecto, DrWhax/unfairplay, recupera un modelo equivalente de un Mac registrado y descifra varias IPA en macOS o Linux. Su README indica que el modelo está ligado al registro, no a una sola app.
• No encontramos ninguna CVE asignada. Una búsqueda por palabra clave en el NVD no devolvió ningún registro de fairplay el 12 de noviembre de 2026, y el catálogo CISA KEV versión 2026.11.10 no contiene ninguna entrada de FairPlay. Es una técnica de elusión de DRM que requiere un dispositivo con jailbreak o un Mac registrado, no un exploit remoto.
• Trate la credencial o el modelo como un secreto de cuenta. Si adquiere IPA para pruebas, use una cuenta dedicada, mantenga la credencial cifrada y con registro de accesos, y elimínela al terminar el trabajo. Si desarrolla una app, no confíe en FairPlay para mantener confidenciales el código o los secretos de larga duración.

¿Por qué hay que descifrar un binario iOS?

Las pruebas automatizadas de iOS fallan en el primer paso: obtener el binario. El análisis estático, la detección de dependencias, la extracción de cadenas y el análisis de vulnerabilidades necesitan el ejecutable Mach-O en claro. La IPA que entrega la App Store está cifrada, y las páginas descifradas solo existen mientras se ejecuta la app.

El método tradicional se apoya en un dispositivo con jailbreak. El analista lanza la app, espera a que el kernel descifre sus páginas y vuelca la memoria del proceso. La página de MASTG de OWASP sobre obtención y extracción de apps describe ese enfoque de volcado de memoria y cita frida-ios-dump. Requiere un dispositivo físico para cada análisis, depende del soporte de jailbreak para la versión de iOS y es difícil de hacer repetible o auditable.

La vía fuera de línea cambia la economía. Una vez que existe una credencial reutilizable, el descifrado se convierte en una función de la IPA y la credencial. El dispositivo hace falta para obtener la credencial, no para descifrar cada app. Ese es el cambio operativo que explica este artículo, y la razón por la que importa el alcance a nivel de cuenta.

¿Qué documenta Apple sobre FairPlay?

Apple documenta la firma de código, no la confidencialidad del código de las apps. Su guía Platform Security dice que en iOS, iPadOS, tvOS, visionOS y watchOS, «these operating systems require that all executable code be signed using an Apple-issued certificate» (Apple, App code signing process, publicado el 19 de diciembre de 2024, guía actualizada en agosto de 2026). La firma de código demuestra quién construyó el código y que no se modificó. No oculta el código, y volver a firmar una app no elimina el cifrado de FairPlay.

La página de firma de código y la página de seguridad del proceso en ejecución que revisamos no describen FairPlay ni el cifrado de binarios de apps. No encontramos una página de Apple que documente el mecanismo. El lado del kernel es público en el código fuente de XNU, pero la derivación de claves, los formatos SINF y SUPF y la credencial de cuenta son conocimiento reconstruido por la comunidad. Cada afirmación siguiente cita su fuente.

¿Cuáles son las tres capas de protección de FairPlay?

FairPlay se entiende mejor como tres capas con trabajos distintos. La firma de código protege la integridad. El cifrado Mach-O protege los bytes en reposo. La licencia SC_Info y los servicios FairPlay del dispositivo deciden quién puede descifrar cada app.

Capa 1: la firma de código

La firma de código es la capa de integridad. Vincula el binario a un certificado emitido por Apple y a un identificador de equipo, y el kernel se niega a ejecutar código que no supera la validación. No dice nada sobre la capacidad de un lector de recuperar las instrucciones. Un atacante que copia una IPA sigue teniendo los bytes cifrados; un atacante que elimina la firma sigue teniendo el cifrado de FairPlay.

Capa 2: las páginas cifradas del Mach-O

La cabecera Mach-O puede incluir LC_ENCRYPTION_INFO o LC_ENCRYPTION_INFO_64. El comando guarda cryptoff (el desplazamiento del archivo para el rango cifrado), cryptsize (su tamaño) y cryptid (el sistema de cifrado aplicable); la estructura está en la cabecera del cargador Mach-O de Apple. Un cryptid de 1 significa que el rango está cifrado; 0 significa que el comando está vacío y el rango no está cifrado. El artículo de SensePost de 2011, Decrypting iPhone Apps, muestra los mismos campos y el método de volcado de memoria que permitieron en las primeras versiones de iOS.

Apple publica el lado del kernel. En mach_loader.c, parse_machfile() trata los dos comandos de cifrado en un mismo caso y llama a set_code_unprotect(). Si esa función devuelve LOAD_DECRYPTFAIL, el kernel registra EXEC_EXIT_REASON_FAIRPLAY_DECRYPT («failed to load due to missing FP keys») y mata un exec que no es spawn con SIGKILL. En vm_apple_protect.c, el descifrado se ejecuta en un gestor de memoria externo que «handles memory from the encrypted sections of some executables protected by the DSMOS kernel extension». Al cargar una página, descifra bloques de 4 KB mediante un callback page_decrypt, y la fuente afirma que «the decrypted pages will never be dirtied»: los originales permanecen limpios y el texto claro solo vive en memoria.

Esa última propiedad explica por qué el volcado de memoria funcionó durante años. También es la propiedad que reproduce el descifrador fuera de línea: calcula las mismas claves de página y escribe el texto claro en una copia del archivo.

Capa 3: la licencia y el material de claves

Una IPA de la App Store incluye un directorio SC_Info/. El análisis de Noham sobre una app iOS crackeada lo describe como el lugar donde «Apple's FairPlay DRM stores iTunes Store licensing metadata», con archivos Manifest.plist, .sinf, .supf, .supp y .supx, y señala que «Not much is documented publicly about the internal FairPlay file formats». Por tanto, los roles siguientes proceden de las herramientas públicas y del análisis de terceros, no de una especificación de Apple.

El SINF es un árbol de átomos al estilo MPEG-4. Los campos que importan aquí son:

• user y key: dos selectores de 4 bytes que identifican la cuenta y el registro de licencia.
• iviv: un valor de 16 bytes que se usa con el nombre de la app para derivar un IV.
• priv: un registro de 440 o 448 bytes que encapsula la clave de trabajo de 16 bytes de la app.
• name y sign: el nombre de la app y una firma.

El SUPF es la tabla de páginas. El README de fairplay-decrypt indica que admite SUPF de versión 3 y 5, registros priv de 448 y 440 bytes y segmentos Mach-O arm64 cifrados. En el código, un SUPF de versión 3 tiene una cabecera por arquitectura de 32 bytes y uno de versión 5 una cabecera de 12 bytes; después, cada página recibe un registro de 32 bytes formado por un valor encapsulado de 16 bytes seguido de un IV de 16 bytes (core.py).

La licencia es el puente entre la cuenta y la app. El SINF vincula la app a una cuenta y a un selector de licencia; el SUPF describe cómo derivar las claves de página una vez conocida la clave de trabajo de la app. La sección siguiente muestra cómo convierte la herramienta pública esos dos archivos en texto claro.

¿Cómo recupera la clave de una app el descifrador fuera de línea?

La herramienta tiene dos etapas. La primera extrae una credencial reutilizable de un dispositivo con jailbreak. La segunda usa esa credencial, el SINF y el SUPF para descifrar la IPA en un equipo normal. Esta sección es nuestra lectura del código público; Apple no publica nada de esto.

Etapa 1: extraer una credencial de 16 bytes de un dispositivo

El componente credential-retrieval admite iOS 10 y posteriores y requiere un dispositivo con jailbreak emparejado, acceso SSH root y al menos una app instalada desde la cuenta (README de credential-retrieval). El recuperador:

1. Se adjunta a fairplayd con task_for_pid() e instala puntos de interrupción de hardware en IOConnectCallStructMethod (observer.c). Conserva los puntos de vigilancia de otros depuradores y evita un problema de recarga de registros de depuración en XNU 8792 que la fuente señala.
2. Ejecuta un disparador que mapea un ejecutable cifrado y llama a mremap_encrypted(), pidiendo al kernel que prepare el descifrado de FairPlay para ese ejecutable. El comentario del disparador dice que solicita «FairPlay's first-use path without running or copying decrypted code» (trigger.c). Por eso la extracción no necesita ejecutar la app objetivo.
3. Lee el archivo IC-Info.sidb del dispositivo, lo descifra con una clave derivada del UDID del dispositivo y selecciona el registro user y key del SINF (credential.c).
4. Combina el valor de 16 bytes observado en la llamada de FairPlay con un contexto derivado del UDID, la cuenta y el selector de clave, más una tabla de palabras de 4 KB que incluye la herramienta, y escribe el resultado en credential.bin.

El dispositivo es necesario para esta derivación. Lo importante es lo que ocurre después: la salida de 16 bytes es un valor autónomo. El descifrado ya no llama nunca al dispositivo, a fairplayd ni a FairPlayIOKit.

El código de recuperación incorpora conocimiento específico de versiones. Elige el selector de FairPlay 9 o 21 según la versión de iOS, y contiene comentarios ligados a iOS 16.3.1 para el formato moderno de UDID. El README indica iOS 10 y posterior, pero el objetivo se mueve: un cambio en fairplayd puede romper el recuperador sin cambiar el formato de descifrado.

Etapa 2: derivar la clave de trabajo y todas las claves de página fuera de línea

El descifrador fuera de línea es Python puro y funciona en macOS y Linux (README). Abre la IPA como un ZIP, empareja cada .supf o .v5.supf con su binario y su SINF, y omite los binarios sin un segmento arm64 cifrado. Para cada segmento cifrado hace tres cosas.

Primero, desbloquea la clave de trabajo de 16 bytes del registro priv del SINF:

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

El código comprueba que el registro descifrado empieza por itun, contiene key en el desplazamiento 20 e iviv en el desplazamiento 44, y luego toma la clave de 16 bytes en el desplazamiento 24. Si la credencial es incorrecta, la comprobación de marcadores falla y la herramienta se detiene; no intenta fuerza bruta (core.py).

Después, deriva una clave de página para cada página de 4 KB. El registro SUPF proporciona un valor encapsulado de 16 bytes y un IV de 16 bytes. El código construye tres bloques de 16 bytes a partir del valor encapsulado y del desplazamiento absoluto de la página en el archivo, cifra cada uno con AES-128-ECB bajo la clave de trabajo y pasa los tres resultados de 16 bytes por una función de mezcla propia basada en sumas, multiplicaciones y XOR de 16 bits. La salida es la clave de página. El desplazamiento de la página forma parte de la entrada, así que un registro de página movido a otro desplazamiento produce una clave distinta.

Por último, descifra la página con AES-128-CBC usando esa clave de página y el IV del SUPF, escribe el texto claro en la copia de salida y pone cryptid a 0. El resultado es una IPA cuyas páginas ejecutables están en claro (core.py, decrypt.py).

Todo el proceso es determinista. No hay un nonce aleatorio de Apple, ni un desafío del servidor, ni atestación de dispositivo, ni un secreto por lanzamiento. La única entrada secreta es la credencial de 16 bytes; todo lo demás viene de la IPA.

¿Dónde falla la jerarquía de claves?

La jerarquía falla en la raíz, no en el cifrado. Una credencial de 16 bytes desbloquea la clave de trabajo de cada app, y la clave de trabajo deriva todas las claves de página de esa app. Las claves de página aportan separación de dominio: una clave de una página no puede descifrar otra página en otro desplazamiento. No aportan confidencialidad independiente, porque todas vienen de la misma clave de trabajo.

Tres propiedades convierten esa tabla en una debilidad a nivel de cuenta.

Una credencial cubre muchas apps. Cada app tiene su propio SINF y su propia clave de trabajo, pero la misma credencial desbloquea todas ellas. UnfairPlay expone la consecuencia con claridad: «One model can decrypt different IPAs personalized for the same enrollment. Each app still has its own key inside its personalized SINF.» Las claves por app limitan el daño de una clave de trabajo filtrada; no limitan el daño de una credencial filtrada.

La derivación es determinista y fuera de línea. Una vez que existe la credencial, la IPA contiene todo lo demás: la clave de trabajo encapsulada, los registros de página, los IV y los desplazamientos. No hay un segundo factor en el momento del descifrado. Una copia de la credencial en un portátil, un runner de CI o una copia de seguridad vale tanto como el original.

La credencial es un valor portador. El repositorio no contiene lógica de caducidad ni de revocación. El código público no determina si Apple invalida el material en el servidor. El README de la herramienta advierte que la credencial es para la cuenta propietaria de la IPA, y UnfairPlay pide mantener el modelo privado y respaldarlo solo en almacenamiento cifrado. Es el consejo correcto, y también una descripción del riesgo: cualquiera que tenga el valor puede usarlo.

Lo que no es la debilidad también importa. AES-128-CBC no está roto. La llamada MD5 deriva un IV de valores públicos; no es la frontera de confidencialidad. La mezcla propia es oscura, no una prueba de seguridad, y el código público la reimplementa. La ofuscación de fairplayd por Apple eleva el coste de la extracción: el análisis estático de Nicolò Altamura sobre macOS 13.5.1 describe predicados opacos, aplanamiento del flujo de control y constantes aritméticas booleanas mixtas, considera débiles los predicados opacos y eficaz el aplanamiento del flujo de control. La ofuscación cambia la dificultad de obtener la credencial. No cambia lo que la credencial permite una vez obtenida.

¿Hasta dónde puede llegar una credencial?

El primer paso es una app. El segundo es la biblioteca de la cuenta. El tercero es un pipeline automatizado. Cada paso es consecuencia del mismo diseño.

• De una app a muchas. Una credencial funciona para las apps de la cuenta o del registro del que procede. Las apps normales de la App Store y las de Apple Arcade usan credenciales separadas, según el README de fairplay-decrypt, así que una biblioteca Arcade necesita su propia extracción. Dentro de una misma clase, la credencial no está ligada a un identificador de bundle.
• Del iPhone al Mac. UnfairPlay recupera su modelo de un Mac registrado, no de un iPhone con jailbreak. El README indica que el modelo está ligado al registro de Mac App Store y puede descifrar otras IPA personalizadas para el mismo registro. Después, el descifrado se ejecuta en macOS o Linux, y la herramienta nunca lanza el fairplayd nativo. Es la misma concentración de confianza con otro punto de captura.
• De lo manual a CI. El descifrado fuera de línea es una función pura de la IPA y la credencial. Puede ejecutarse en un contenedor, encolarse, reintentarse y auditarse. Un equipo de seguridad puede analizar una app sin conectar un dispositivo; un atacante puede reempaquetarla sin una granja de dispositivos. El coste de ambos baja.
• Del texto claro al impacto. Una vez que las páginas están en claro, la app es un Mach-O normal. Un analista puede leer endpoints, claves incrustadas, indicadores de funcionalidades y lógica de licencia; comparar dos versiones; encontrar vulnerabilidades; parchear una comprobación; inyectar un dylib; o reconstruir una app modificada. FairPlay era la barrera de confidencialidad, no la de integridad. La firma de código sigue importando para la instalación, pero no vuelve secreto el código recuperado.
• De una credencial a una biblioteca. El radio de impacto es la cuenta, no la app. Una cuenta de pruebas compartida, una cuenta de revendedor o un secreto de CI pueden cubrir un catálogo amplio. Un único credential.bin o un modelo filtrado desbloquea todas las apps que esa cuenta o ese registro pueden descifrar. Es la diferencia entre perder un binario y perder una colección.

El diseño a nivel de cuenta ya falló antes de otra forma. El informe AceDeceiver de Unit 42 de 2016 describe un man-in-the-middle de FairPlay que reproducía una autorización de compra almacenada para instalar apps sin certificado empresarial, y lo califica como «the first iOS malware we've seen that abuses certain design flaws in Apple's DRM protection mechanism». Apple retiró las tres apps de la App Store el 25 de febrero de 2016. AceDeceiver abusaba de la autorización de instalación, no del descifrado fuera de línea, así que es un precedente de problemas de diseño de FairPlay a nivel de cuenta, no una descripción de esta herramienta.

No encontramos ninguna CVE asignada al diseño de descifrado. Una búsqueda por palabra clave en el NVD de fairplay no devolvió registros el 12 de noviembre de 2026, y el catálogo CISA KEV versión 2026.11.10 no contiene ninguna entrada de FairPlay. Eso concuerda con una propiedad de diseño demostrada por una herramienta pública, no con una vulnerabilidad de software de un proveedor con una versión corregida.

¿Qué deben hacer los defensores y los desarrolladores?

Si adquiere IPA para pruebas autorizadas, la credencial es ahora el archivo más sensible del pipeline. Trátela como un secreto de cuenta, porque eso es.

• Use una cuenta de Apple dedicada al programa de pruebas. No reutilice una cuenta personal, una cuenta de equipo compartida ni una cuenta con compras de producción.
• Mantenga credential.bin o el modelo de UnfairPlay en un gestor de secretos, cifrado en reposo, con registro de accesos y un propietario identificado. No lo ponga en un repositorio, un registro de compilación ni un ticket.
• Limite quién puede ejecutar el descifrado y qué IPA entran en la cola. Registre la cuenta, la app y la fecha de cada ejecución para poder auditar el uso.
• Rote o retire la cuenta al terminar el trabajo. El código público no tiene un interruptor de caducidad, así que el control operativo es dejar de usar la credencial y eliminarla.
• Al compartir resultados, elimine los datos de cuenta. La opción --strip-account-data de UnfairPlay quita los miembros SC_Info y los campos de Apple ID y comprador de iTunesMetadata.plist; aun así, el README de la herramienta dice que la redacción no autoriza la redistribución.
• No comparta nunca SINF, SUPF, SIDB, un archivo de modelo o una IPA descifrada fuera del alcance autorizado. Los archivos de licencia identifican la cuenta, y el modelo es reutilizable.

Si desarrolla una app iOS, suponga que un analista decidido acabará obteniendo el binario. FairPlay eleva el coste; no convierte el código del lado del cliente en un secreto.

• No incluya claves de API de larga duración, claves privadas, credenciales de servidor ni material de firma en la app. Mueva la lógica valiosa y los secretos a un servidor que controle.
• Use tokens de corta duración ligados al usuario y al dispositivo, autorización del lado del servidor y atestación de dispositivo cuando el riesgo lo justifique. El certificate pinning eleva el coste de la interceptación; no protege un secreto que ya está en el binario.
• Trate las comprobaciones de licencia del lado del cliente como experiencia de usuario, no como una frontera de seguridad. Un binario parcheado puede evitarlas, y un binario descifrado hace que el parche sea más fácil de escribir.
• Mantenga el servidor como autoridad de los derechos, los límites de peticiones y las funciones de pago. Si una función no debe copiarse, aplique la regla donde el usuario no pueda editar el código.

Las correcciones del lado de la plataforma son cambios de diseño, no un parche que podamos citar. Un proveedor podría ligar las claves de página a un secreto del dispositivo en cada lanzamiento, emitir material de licencia de corta duración y rotarlo en el servidor, hacer que la credencial de cuenta no se pueda exportar del hardware seguro y detectar la conexión de un depurador o de un puerto de excepción a fairplayd. Cualquier esquema que descifre código en un dispositivo controlado por el usuario tiene que exponer una clave a ese dispositivo en algún momento; el objetivo es hacer que la clave sea efímera, ligada al dispositivo y de corta duración, no pretender que el descifrado del lado del cliente sea absoluto.

Para los usuarios, el consejo práctico es más limitado. Active la autenticación de dos factores en la cuenta de Apple, no comparta la cuenta y no instale IPA de fuentes no confiables. El riesgo principal de este artículo es la confidencialidad del código de las apps y el radio de impacto de una cuenta compartida, no un compromiso remoto de un teléfono bloqueado.

¿Qué no se pudo verificar?

• El esquema exacto de derivación de claves de Apple para los binarios de la App Store, y si la clave de trabajo priv del SINF es única por app, por cuenta o por transacción. El comportamiento de la herramienta pública es la evidencia; Apple no publica una especificación.
• Si Apple rota o revoca la credencial de cuenta en el servidor. El código público no contiene lógica de caducidad ni revocación, pero no se puede descartar una invalidación del lado del servidor a partir del repositorio.
• El comportamiento en versiones actuales de iOS. El README del recuperador indica iOS 10 y posterior, y el código contiene notas específicas de iOS 16.3.1, pero no lo probamos en un dispositivo. Un cambio en fairplayd puede romper la recuperación sin cambiar el formato fuera de línea.
• Los internos de la recuperación del modelo de UnfairPlay. Leímos su README y sus garantías declaradas, no todo su código de recuperación.
• Las disposiciones exactas de SINF y SUPF más allá de las versiones que admite la herramienta: SUPF de versión 3 y 5, priv de 440 y 448 bytes y segmentos arm64. Pueden existir otras versiones.
• El número de cuentas, apps o credenciales en uso. No se publica telemetría, y las estrellas y forks del repositorio miden interés, no explotación.
• Si el vídeo de FairPlay Streaming usa la misma jerarquía de claves. El estudio académico de 2023 de Rafi, Shepherd y Markantonakis cubre el DRM móvil, incluido FairPlay, pero se centra en contenido en streaming, no en binarios de IPA de la App Store; por tanto, es contexto y no evidencia de esta vía.

Preguntas frecuentes

¿Existe una CVE para el descifrado de apps FairPlay?

No encontramos ninguna. Una búsqueda por palabra clave en el NVD de fairplay no devolvió registros el 12 de noviembre de 2026, y el catálogo CISA KEV versión 2026.11.10 no contiene ninguna entrada de FairPlay. La herramienta pública y el diseño que demuestra no se registran como CVE.

¿Es un exploit de jailbreak?

No. No explota una corrupción de memoria del kernel. Necesita acceso root en un dispositivo con jailbreak para adjuntarse a fairplayd y observar la llamada de FairPlay. El descifrado en sí es fuera de línea y no necesita jailbreak.

¿Una credencial descifra todas las IPA del mundo?

No. La credencial está limitada a la cuenta o al registro que la produjo, y el SINF de cada app está personalizado para ese alcance. Las apps de Apple Arcade necesitan una credencial distinta de las apps normales de la App Store, según el README de fairplay-decrypt. La debilidad es la amplitud dentro de una cuenta, no una clave global.

¿Afecta al vídeo de FairPlay Streaming?

No está establecido. La herramienta pública apunta a binarios de IPA de la App Store y a sus licencias SINF/SUPF. FairPlay Streaming es una vía de medios distinta, y el estudio de 2023 que lo cubre es contexto, no evidencia de que la misma credencial descifre vídeo.

¿Puede Apple corregirlo?

Apple puede cambiar el diseño: ligar las claves a un secreto del dispositivo en cada lanzamiento, acortar la vida de las licencias, rotar el material en el servidor, hacer que la credencial no se pueda exportar y endurecer la IPC de FairPlay. Cualquier descifrado del lado del cliente tiene que exponer una clave al dispositivo que reproduce el contenido; el objetivo práctico es reducir la vida y el alcance de esa clave, no hacerla inextractable en términos absolutos.

¿Se explota en la naturaleza?

No se informa de ningún ataque que use la herramienta en el proyecto ni en las fuentes revisadas el 12 de noviembre de 2026. El repositorio tenía más de 2,400 estrellas y 370 forks en esa fecha, y UnfairPlay más de 1,100 estrellas. Esas cifras muestran interés, no explotación.

Referencias

• EthanArbuckle/fairplay-decrypt, README, creado el 19 de octubre de 2026, último commit el 8 de noviembre de 2026: https://github.com/EthanArbuckle/fairplay-decrypt (consultado el 12 de noviembre de 2026)
• core.py, el desbloqueo del priv del SINF, el análisis del SUPF, la derivación de claves de página y la puesta a cero de cryptid: https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/core.py (consultado el 12 de noviembre de 2026)
• decrypt.py, la gestión del ZIP de la IPA y el plan por binario: https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/decrypt.py (consultado el 12 de noviembre de 2026)
• credential-retrieval/README.md, iOS 10 y posterior, la separación de credenciales de Apple Arcade y los requisitos del dispositivo: https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/README.md (consultado el 12 de noviembre de 2026)
• credential.c, el descifrado del SIDB, la selección user/key y la derivación de la credencial: https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/credential/credential.c (consultado el 12 de noviembre de 2026)
• observer.c, task_for_pid(), los puntos de interrupción de hardware y la solución para XNU 8792: https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/credential/observer.c (consultado el 12 de noviembre de 2026)
• trigger.c, la solicitud de primer uso mediante mremap_encrypted() y su comentario: https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/trigger/trigger.c (consultado el 12 de noviembre de 2026)
• DrWhax/unfairplay, README, el modelo de registro, el alcance multi-IPA, el descifrado en macOS/Linux y la opción --strip-account-data: https://github.com/DrWhax/unfairplay (consultado el 12 de noviembre de 2026)
• Apple, App code signing process in iOS, iPadOS, tvOS, visionOS, and watchOS, publicado el 19 de diciembre de 2024: https://support.apple.com/guide/security/app-code-signing-process-sec7c917bf14/web (consultado el 12 de noviembre de 2026)
• Apple, Security of runtime process in iOS, iPadOS, and visionOS, publicado el 19 de diciembre de 2024: https://support.apple.com/guide/security/security-of-runtime-process-sec15bfe098e/web (consultado el 12 de noviembre de 2026)
• Apple XNU, bsd/kern/mach_loader.c, set_code_unprotect(), LOAD_DECRYPTFAIL y EXEC_EXIT_REASON_FAIRPLAY_DECRYPT: https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/mach_loader.c (consultado el 12 de noviembre de 2026)
• Apple XNU, osfmk/vm/vm_apple_protect.c, el gestor de memoria externo y el bucle page_decrypt de 4 KB: https://github.com/apple-oss-distributions/xnu/blob/main/osfmk/vm/vm_apple_protect.c (consultado el 12 de noviembre de 2026)
• Apple XNU, EXTERNAL_HEADERS/mach-o/loader.h, los campos de encryption_info_command: https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/loader.h (consultado el 12 de noviembre de 2026)
• SensePost, «Decrypting iPhone Apps», 24 de octubre de 2011, los campos cryptid y el método de volcado de memoria: https://sensepost.com/blog/2011/decrypting-iphone-apps/ (consultado el 12 de noviembre de 2026)
• Noham, «Anatomy of an iOS crack», 15 de mayo de 2026, los archivos SC_Info y la disposición de campos del SINF: https://noh.am/en/posts/rev-dylib/ (consultado el 12 de noviembre de 2026)
• pwn0rz, fairplay_research, el flujo FairPlayIOKit/fairplayd y la etapa AES de hardware: https://github.com/pwn0rz/fairplay_research (consultado el 12 de noviembre de 2026)
• Nicolò Altamura, «Analysis of Obfuscation Found in Apple FairPlay», 28 de agosto de 2023, macOS 13.5.1: https://nicolo.dev/en/blog/fairplay-apple-obfuscation/ (consultado el 12 de noviembre de 2026)
• Unit 42, Claud Xiao, «AceDeceiver: First iOS Trojan Exploiting Apple DRM Design Flaws to Infect Any iOS Device», 16 de marzo de 2016: https://unit42.paloaltonetworks.com/acedeceiver-first-ios-trojan-exploiting-apple-drm-design-flaws-to-infect-any-ios-device/ (consultado el 12 de noviembre de 2026)
• Búsqueda por palabra clave del NVD de fairplay, cero registros: https://nvd.nist.gov/vuln/search/results?query=fairplay&search_type=all (consultado el 12 de noviembre de 2026)
• CISA, catálogo Known Exploited Vulnerabilities, versión 2026.11.10, sin entrada de FairPlay: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado el 12 de noviembre de 2026)
• Amir Rafi, Carlton Shepherd y Konstantinos Markantonakis, «A First Look at Digital Rights Management Systems for Secure Mobile Content Delivery», arXiv:2308.00437, agosto de 2023: https://arxiv.org/abs/2308.00437 (consultado el 12 de noviembre de 2026)