En Mountain Lion, sé que algunas aplicaciones, incluidas todas las aplicaciones en Mac App Store, están firmadas digitalmente por el desarrollador, por lo que si se modifican, la firma no coincidirá y generará todo tipo de errores (y la situación escalará con la próxima versión del sistema operativo...).
Mi pregunta es ¿qué partes del paquete .app cubre la firma? Si algo cambia (incluidos los metadatos, como la fecha de Appname.app/Contentsmodificación de la Contentscarpeta), ¿eso rompe la firma? ¿Es solo el binario en Contents/MacOS? ¿Están incluidos los .plists en la firma? el Resources? Como usuario final, ¿qué puedo hackear (en todo caso) sin romper la firma?
TL; DR Depende del desarrollador elegir qué partes de la aplicación se firman y si la manipulación de esas partes da como resultado alguna acción cuando se inicia la aplicación. Tienes que usar prueba y error para resolverlo aplicación por aplicación.
Depende en gran medida del desarrollador decidir qué componentes de su paquete de aplicaciones se representan en el sello que se firma antes de entregar su aplicación. Cualquier cosa en el sello es a prueba de manipulaciones, ya que es casi imposible modificar estas cosas sin cambiar sus firmas hash. Pero eso no significa que no puedas manipularlos.
La guía para desarrolladores de Apple dice lo siguiente sobre lo que debe firmar:
Debe firmar todos los archivos ejecutables de su producto, incluidas las aplicaciones, las herramientas, las herramientas auxiliares ocultas, las utilidades, etc. La firma de un paquete de aplicaciones cubre sus recursos, pero no sus subcomponentes, como herramientas y subpaquetes. Cada uno de ellos debe firmarse de forma independiente.
Si su aplicación consta de una gran parte de la interfaz de usuario con una o más pequeñas herramientas de ayuda que intentan presentar una sola cara al usuario, puede hacer que no se distingan de la firma de código dándoles exactamente el mismo identificador de firma de código. (Puede hacerlo asegurándose de que todos tengan el mismo valor CFBundleIdentifier en su Info.plist, o usando la opción -i en el comando codesign, para asignar el mismo identificador). En ese caso, todos los componentes de su programa tienen acceder a los mismos elementos del llavero y validar como el mismo programa. Haga esto solo si los programas involucrados están realmente destinados a formar una sola entidad, sin hacer distinciones.
Un binario universal (paquete o herramienta) automáticamente tiene firmas individuales aplicadas a cada componente de la arquitectura. Estos son independientes y, por lo general, solo se verifica la arquitectura nativa en el sistema del usuario final.
En el caso de los paquetes de instalación (paquetes .pkg y .mpkg), todo está firmado implícitamente: el archivo CPIO que contiene la carga útil, el archivo CPIO que contiene los scripts de instalación y la lista de materiales (BOM) tienen un hash registrado en el XAR. encabezado, y ese encabezado a su vez está firmado. Por lo tanto, si modifica un script de instalación (por ejemplo) después de que se haya firmado el paquete, la firma no será válida.
También puede firmar sus complementos y bibliotecas. Aunque esto no es un requisito actualmente, lo será en el futuro y no hay ninguna desventaja en tener firmas en estos componentes.
Dependiendo de la situación, el codiseño puede agregar a su archivo ejecutable de Mach-O, agregarle atributos extendidos o crear nuevos archivos en el directorio de contenido de su paquete. Ninguno de sus otros archivos se modifica.
Además , desde aquí no es necesariamente cierto que tener una firma no válida para una aplicación signifique que no se iniciará. La pagina dice:
Depende del sistema o programa que inicia o carga el código firmado decidir si verifica la firma y, si lo hace, determinar cómo evaluar los resultados de esa verificación.
Una aplicación puede optar por permitir modificaciones.
Su mejor apuesta es un enfoque de prueba y error con cualquier aplicación que intente modificar. Es posible que funcione, puede que no. No hay una respuesta siempre cierta que se pueda dar.
Si se ha firmado una aplicación, puede buscar un Contents/CodeResourcesarchivo o un Contents/_CodeSignature/CodeResourcesarchivo en el paquete. Este archivo enumera todos los componentes firmados y sus valores hash esperados en el paquete. Es un buen lugar para comenzar a comprender qué partes de la aplicación un desarrollador considera lo suficientemente críticas como para observar los cambios.
Aunque la pregunta hace referencia específicamente a Mountain Lion, hay un cambio importante en la versión más nueva de macOS. En macOS 10.11 y versiones posteriores, se rechazan las firmas que no cubren todo el código.
Consulte la Nota técnica TN2206 - Firma de código en macOS en profundidad .
adam davis
Daniel
adam davis