TL; DR Depende del desarrollador elegir qué partes de la aplicación están firmadas y si la manipulación de esas piezas resulta en alguna acción cuando se lanza la aplicación. Tienes que usar prueba y error para resolverlo aplicación por aplicación.
Es en gran medida el 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 falsificaciones ya que es casi imposible modificar estas cosas sin cambiar sus firmas de hash. Pero eso no significa que no puedas manipularlos.
La guía para desarrolladores de Apple tiene esto que decir sobre lo que debes firmar:
Debes firmar cada ejecutable en tu producto, incluyendo
aplicaciones, herramientas, herramientas de ayuda ocultas, utilidades, etc.
La firma de un paquete de aplicaciones cubre sus recursos, pero no su
Subcomponentes tales como herramientas y sub-paquetes. Cada uno de estos debe ser
firmado independientemente.
Si su aplicación consiste en una parte de UI grande con una o más pequeñas
Las herramientas de ayuda que intentan presentar una única cara al usuario, puede
hacerlos indistinguibles a la firma de código dándoles toda la
exactamente el mismo identificador de firma de código. (Puedes hacerlo asegurándote
que todos tienen el mismo valor de CFBundleIdentifier en su
Info.plist, o usando la opción -i en el comando codesign, para
asigne el mismo identificador.) En ese caso, todos los componentes de su programa
tener acceso a los mismos elementos de llavero y validar como el mismo
programa. Haga esto solo si los programas involucrados están realmente destinados a formarse
una sola entidad, sin distinciones.
Un binario universal (paquete o herramienta) tiene individualmente
Firmas aplicadas a cada componente de la arquitectura. Estos son
Independiente, y usualmente solo la arquitectura nativa al final.
Se verifica el sistema del usuario.
En el caso de 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 scripts de instalación y la lista de materiales
(BOM) cada uno tiene un hash registrado en el encabezado XAR, y ese encabezado en
el turno está firmado. Por lo tanto, si modifica un script de instalación (para
ejemplo) después de que el paquete haya sido firmado, la firma será
inválido.
Es posible que también desee firmar sus complementos y bibliotecas. Aunque esto
Actualmente no se requiere, será en el futuro y no hay
Desventaja de tener firmas en estos componentes.
Dependiendo de la situación, el codeign puede agregarse a su ejecutable Mach-O
archivo, agregue atributos extendidos o cree nuevos archivos en su
Directorio de contenidos del paquete. Ninguno de tus otros archivos está modificado.
También desde aquí no es necesariamente cierto que tener una firma no válida para una aplicación significa que no podrá iniciarse. La página dice:
Depende del sistema o programa que se está iniciando o cargando firmado
código para decidir si verificar la firma y, si lo hace, para
determinar cómo evaluar los resultados de esa verificación.
Una aplicación puede elegir permitir modificaciones.
Su mejor apuesta es un enfoque de prueba y error con cualquier aplicación que esté intentando modificar. Es posible que funcione, puede que no. No siempre se puede dar una respuesta verdadera.
Si se ha firmado una aplicación, puede buscar un archivo Contents/CodeResources o un archivo Contents/_CodeSignature/CodeResources 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 entender qué partes de la aplicación un desarrollador considera lo suficientemente críticas como para observar los cambios.