Quando le applicazioni sono firmate dal codice, quali parti del pacchetto .app sono coperte dalla firma?

13

In Mountain Lion, so che alcune applicazioni, incluse tutte le applicazioni sul Mac App Store, sono firmate digitalmente dallo sviluppatore, così che se vengono modificate, la firma non corrisponderà e genererà tutti i tipi di errori ( e la situazione si intensificherà con la prossima versione del sistema operativo ...).

La mia domanda è: quali parti del pacchetto .app sono coperte dalla firma? Se qualsiasi cosa in Appname.app/Contents cambia (inclusi i metadati, come la data di modifica della cartella Contents ), ciò interrompe la firma? È solo il binario in Contents/MacOS ? Le liste sono incluse nella firma? Il codice%? Come utente finale, cosa posso modificare (se possibile) senza rompere la firma?

    
posta Daniel 28.03.2012 - 15:14
fonte

2 risposte

13

TL; DR Spetta allo sviluppatore scegliere quali parti dell'app sono firmate e se manomettere o meno tali parti comporta azioni quando l'app viene avviata. Devi utilizzare prove ed errori per calcolare l'app per ogni app.

Spetta in gran parte allo sviluppatore decidere quali componenti nel loro pacchetto di applicazioni sono rappresentati nel sigillo che viene firmato prima di consegnare la loro applicazione. Qualunque cosa nel sigillo è effettivamente a prova di manomissione poiché è quasi impossibile modificare queste cose senza modificare le loro firme di hash. Ma in realtà non significa che non puoi manometterli.

La guida per gli sviluppatori Apple ha questo da dire su cosa devi firmare:

You should sign every executable in your product, including applications, tools, hidden helper tools, utilities and so forth. Signing an application bundle covers its resources, but not its subcomponents such as tools and sub-bundles. Each of these must be signed independently.

If your application consists of a big UI part with one or more little helper tools that try to present a single face to the user, you can make them indistinguishable to code signing by giving them all the exact same code signing identifier. (You can do that by making sure that they all have the same CFBundleIdentifier value in their Info.plist, or by using the -i option in the codesign command, to assign the same identifier.) In that case, all your program components have access to the same keychain items and validate as the same program. Do this only if the programs involved are truly meant to form a single entity, with no distinctions made.

A universal binary (bundle or tool) automatically has individual signatures applied to each architecture component. These are independent, and usually only the native architecture on the end user's system is verified.

In the case of installer packages (.pkg and .mpkg bundles), everything is implicitly signed: The CPIO archive containing the payload, the CPIO archive containing install scripts, and the bill of materials (BOM) each have a hash recorded in the XAR header, and that header in turn is signed. Therefore, if you modify an install script (for example) after the package has been signed, the signature will be invalid.

You may also want to sign your plug-ins and libraries. Although this is not currently required, it will be in the future, and there is no disadvantage to having signatures on these components.

Depending on the situation, codesign may add to your Mach-O executable file, add extended attributes to it, or create new files in your bundle's Contents directory. None of your other files is modified.

Anche da qui non è necessariamente vero che avere una firma non valida per un'applicazione significa che non riuscirà ad avviarsi. La pagina dice:

It is up to the system or program that is launching or loading signed code to decide whether to verify the signature and, if it does, to determine how to evaluate the results of that verification.

Un'applicazione può scegliere di consentire modifiche.

La soluzione migliore è un approccio trial-and-error con qualsiasi applicazione che stai cercando di modificare. Potrebbe funzionare, non può. Non c'è una risposta sempre vera che possa essere data.

Se un'app è stata firmata, puoi cercare un file Contents/CodeResources o un file Contents/_CodeSignature/CodeResources nel pacchetto. Questo file elenca tutti i componenti firmati e i loro valori hash previsti nel pacchetto. È un buon punto di partenza per capire quali parti dell'applicazione uno sviluppatore ritiene abbastanza critico da tenere sotto controllo le modifiche.

    
risposta data 28.03.2012 - 16:48
fonte
0

Anche se la domanda si riferisce specificamente a Mountain Lion, c'è un cambiamento importante nella versione più recente di macOS. Su macOS 10.11 e versioni successive, le firme che non coprono l'intero codice vengono rifiutate.

Vedi Nota tecnica TN2206 - Accesso al codice macOS .

    
risposta data 03.02.2017 - 13:10
fonte

Leggi altre domande sui tag