El paquete IPA por dentro: carpeta, perfil y firma

Un archivo IPA es un archivo comprimido, igual que un ZIP. Dentro hay una carpeta Payload, y dentro de ella una carpeta con extensión .app: ese es el paquete de la aplicación. Ahí viven el ejecutable, el archivo de propiedades Info.plist, los recursos (imágenes, textos, interfaces), la carpeta Frameworks con las bibliotecas de código que la app incluye, las extensiones en PlugIns, el perfil embedded.mobileprovision y la carpeta _CodeSignature con el sello de la firma.

Para la revisión esto significa que gran parte de lo que la app lleva se puede leer sin ejecutarla: el listado de archivos, sus tamaños y los textos de configuración. Lo que se lee es lo que cualquiera con el archivo puede leer. Por eso el criterio no es «esto está escondido», sino «esto no debería viajar aquí».

Un paquete de publicación debe llevar lo que la app necesita para funcionar para el usuario, y nada más. Los archivos de configuración de otros entornos —pruebas, preproducción, desarrollo— son un descuido frecuente: revelan direcciones de servidores internos, activan más registros de la cuenta y a veces traen cuentas de prueba. No son un fallo de cifrado; son información que sale en el paquete porque nadie la quitó del proceso de compilación.

El listado del IPA de Quetzal enumera los archivos con su tamaño; entre los nombres de los recursos habituales hay uno que pertenece a otro entorno. Ábrelo y lee qué revela.

El archivo embedded.mobileprovision es el perfil de aprovisionamiento: un documento firmado por Apple que dice a qué equipo de desarrollo pertenece la app, para qué aplicación vale, qué capacidades puede usar, hasta cuándo es válido y, si es de distribución restringida, en qué dispositivos puede instalarse. Es lo que permite que una app firmada por un equipo corra en teléfonos que no son de ese equipo.

El perfil se decodifica a texto con herramientas estándar y su resumen identifica al equipo con un código de diez caracteres, el identificador de equipo. Ese código aparece también en las firmas y en los grupos de acceso de los entitlements, así que es la llave para relacionar piezas entre sí.

El resumen de la firma de Quetzal dice que la verificación es válida y que el paquete lo firmó el equipo de Quetzal. Esas son las dos cosas que la firma de código garantiza: quién firmó y que los archivos sellados no han cambiado desde entonces. No garantiza que la aplicación sea segura, ni que sus datos estén cifrados, ni que el contenido del paquete esté oculto: el archivo de configuración de la tarea anterior está firmado y a la vez se lee en claro.

Un informe honesto no presenta «la firma es válida» como un hallazgo ni como una tranquilidad. Es un dato de procedencia e integridad, y se anota como tal.