TL;DR Depende del desarrollador elegir qué piezas de la aplicación están firmadas y si la manipulación de esas piezas da lugar a alguna acción cuando se lanza la aplicación. Hay que utilizar el método de prueba y error para averiguarlo aplicación por aplicación.
En gran medida, es el desarrollador quien decide qué componentes de su paquete de aplicaciones están representados en el sello que se firma antes de entregar su aplicación. Todo lo que está en el sello es efectivamente a prueba de manipulaciones, ya que es casi imposible modificar estas cosas sin cambiar sus firmas hash. Pero eso no significa que no se pueda manipular.
La guía para desarrolladores de Apple tiene esto que decir sobre lo que debe firmar:
Debe firmar todos los ejecutables de su producto, incluyendo aplicaciones, herramientas, herramientas de ayuda ocultas, utilidades, etc. La firma de un paquete de aplicaciones cubre sus recursos, pero no sus subcomponentes, como las herramientas y los subpaquetes. Cada uno de ellos debe ser firmarse de forma independiente.
Si su aplicación consiste en una gran parte de interfaz de usuario con una o más pequeñas herramientas de ayuda que tratan de presentar una sola cara al usuario, puede hacerlas indistinguibles para la firma de código dándoles a todas el exactamente el mismo identificador de firma de código. (Puede hacerlo asegurándose de que que todos tengan el mismo valor CFBundleIdentifier en su Info.plist, o utilizando la opción -i en el comando codesign, para asignar el mismo identificador). En ese caso, todos los componentes de su programa tienen acceso a los mismos elementos del llavero y se validan como el mismo programa. Haga esto sólo si los programas involucrados están realmente destinados a formar una sola entidad, sin hacer distinciones.
Un binario universal (paquete o herramienta) tiene automáticamente firmas individuales firmas individuales aplicadas a cada componente de la arquitectura. Estas son independientes, y normalmente sólo la arquitectura nativa en el sistema del sistema del usuario final.
En el caso de los paquetes instaladores (paquetes .pkg y .mpkg), todo está firmado implícitamente: El archivo CPIO que contiene la carga útil, el archivo archivo CPIO que contiene install scripts, y la lista de materiales (BOM) tienen cada uno un hash registrado en la cabecera XAR, y esa cabecera a su vez está firmada. a su vez está firmada. Por lo tanto, si se modifica un scriptsscript de instalaciónscripts (por ejemplo) después de que el paquete haya sido firmado, la firma será inválida.
También puedes firmar tus plug-ins y bibliotecas. Aunque esto Aunque esto no es necesario en la actualidad, lo será en el futuro, y no hay desventaja de tener firmas en estos componentes.
Dependiendo de la situación, el codiseño puede añadir a su archivo ejecutable Mach-O o crear nuevos archivos en el directorio de contenidos de su paquete. en el directorio de contenidos de su paquete. Ninguno de sus otros archivos se modifica.
También desde aquí no es necesariamente cierto que tener una firma inválida para una aplicación signifique que ésta no se inicie. La página dice:
Depende del sistema o del programa que lanza o carga el código firmado código firmado decidir si verifica la firma y, si lo hace, determinar determinar cómo evaluar los resultados de esa verificación.
Una aplicación puede optar por permitir modificaciones.
Su mejor opción es un enfoque de prueba y error con cualquier aplicación que esté tratando de modificar. Puede que funcione, puede que no. No se puede dar una respuesta siempre verdadera.
Si una aplicación ha sido firmada puedes buscar un Contents/CodeResources o un Contents/_CodeSignature/CodeResources del paquete. Este archivo enumera todos los componentes firmados y sus valores hash esperados en el paquete. Es un buen lugar para empezar a entender qué piezas de la aplicación un desarrollador considera lo suficientemente críticas como para vigilar los cambios.
