TL; DR Depende del desarrollador elegir qué partes de la aplicación están firmadas y si la manipulación de esas partes resulta o no en acciones 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 están representados en el sello que se firma antes de entregar su aplicación. Cualquier cosa 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 puedas manipularlos.
La Guía del desarrollador de Apple tiene esto que decir sobre lo que debe firmar:
Debe firmar todos los ejecutables en su producto, incluidas las aplicaciones, herramientas, herramientas auxiliares ocultas, utilidades, etc. Firmar un paquete de aplicaciones cubre sus recursos, pero no sus subcomponentes, como herramientas y subgrupos. Cada uno de estos debe ser firmado 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 auxiliares que intentan presentar una sola cara al usuario, puede hacer que no se puedan distinguir con 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 de 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 acceso a los mismos elementos de llavero y validar como el mismo programa. Haga esto solo si los programas involucrados realmente están destinados a formar una sola entidad, sin distinciones.
Un binario universal (paquete o herramienta) aplica automáticamente firmas individuales a cada componente de la arquitectura. Estos son independientes y generalmente 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á implícitamente firmado: 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 se requiere actualmente, lo será en el futuro, y no hay inconveniente en tener firmas en estos componentes.
Dependiendo de la situación, el código puede agregarse a su archivo ejecutable 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 significa que no se iniciará. La página dice:
Depende del sistema o programa que está iniciando o cargando el código firmado para decidir si se verifica la firma y, si lo hace, determinar cómo evaluar los resultados de esa verificación.
Una aplicación puede elegir permitir modificaciones.
Su mejor opción es un enfoque de prueba y error con cualquier aplicación que esté intentando modificar. Es posible que funcione, puede que no. No hay una respuesta siempre verdadera 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.