Cuando las aplicaciones tienen un código de firma, ¿qué partes del paquete .app cubre la firma?

13

En Mountain Lion, sé que algunas aplicaciones, incluidas todas las aplicaciones en Mac App Store, están firmadas digitalmente por el desarrollador, de modo que si se modifican, la firma no coincidirá y generará todo tipo de errores ( y la situación se intensificará con la próxima versión del sistema operativo ...).

Mi pregunta es ¿qué partes del paquete .app cubre la firma? Si cualquier cosa en Appname.app/Contents cambia (incluidos los metadatos, como la fecha de modificación de la carpeta Contents ), ¿eso rompe la firma? ¿Es solo el binario en Contents/MacOS ? ¿Las listas están incluidas en la firma? El código%? Como usuario final, ¿qué puedo hackear (si corresponde) sin romper la firma?

    
pregunta Daniel 28.03.2012 - 15:14

2 respuestas

13

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.

    
respondido por el Ian C. 28.03.2012 - 16:48
0

A pesar de que la pregunta hace referencia específicamente a Mountain Lion, hay un cambio importante en la versión más reciente de macOS. En macOS 10.11 y versiones posteriores, se rechazan las firmas que no cubren todo el código.

Consulte Nota técnica TN2206 - Profundidad de inicio de sesión del código macOS .

    
respondido por el Gunnar 03.02.2017 - 13:10

Lea otras preguntas en las etiquetas