Lorsque les applications sont signées par code, quelles parties du bundle .app sont couvertes par la signature?

Dans Mountain Lion, je sais que certaines applications, y compris toutes les applications du Mac App Store, sont signées numériquement par le développeur, de sorte que si elles sont modifiées, la signature ne correspondra pas et cela soulèvera toutes sortes d'erreurs (et la situation va s'intensifier avec la prochaine version du système d'exploitation ...).

Ma question est de savoir quelles parties du bundle .app sont couvertes par la signature? Si quelque chose dans les Appname.app/Contentschangements (y compris les métadonnées, comme la date de modification du Contentsdossier), est-ce que cela brise la signature? Est-ce juste le binaire Contents/MacOS? Les .plists sont-ils inclus dans la signature? Le Resources? En tant qu'utilisateur final, que puis-je pirater (le cas échéant) sans casser la signature?

TL; DR Il appartient au développeur de choisir les éléments de l'application qui sont signés et si la falsification de ces éléments entraîne ou non des actions lorsque l'application est lancée. Vous devez faire des essais et des erreurs pour le comprendre application par application.

Il appartient en grande partie au développeur de décider quels composants de son ensemble d'applications sont représentés dans le sceau qui est signé avant de livrer leur application. Tout ce qui se trouve dans le sceau est effectivement inviolable car il est pratiquement impossible de modifier ces éléments sans changer leurs signatures de hachage. Mais cela ne signifie pas que vous ne pouvez pas les altérer.

Le guide du développeur Apple a ceci à dire sur ce que vous devez signer:

Vous devez signer chaque exécutable de votre produit, y compris les applications, les outils, les outils d'assistance cachés, les utilitaires, etc. La signature d'un ensemble d'applications couvre ses ressources, mais pas ses sous-composants tels que les outils et les sous-ensembles. Chacun de ces documents doit être signé indépendamment.

Si votre application se compose d'une grande partie de l'interface utilisateur avec un ou plusieurs petits outils d'assistance qui tentent de présenter une seule face à l'utilisateur, vous pouvez les rendre indiscernables à la signature de code en leur donnant tous exactement le même identifiant de signature de code. (Vous pouvez le faire en vous assurant qu'ils ont tous la même valeur CFBundleIdentifier dans leur Info.plist, ou en utilisant l'option -i dans la commande codesign, pour attribuer le même identifiant.) Dans ce cas, tous vos composants de programme ont accéder aux mêmes éléments de trousseau et valider comme le même programme. Ne faites cela que si les programmes impliqués sont vraiment destinés à former une seule entité, sans distinction.

Un binaire universel (bundle ou outil) a automatiquement des signatures individuelles appliquées à chaque composant d'architecture. Ceux-ci sont indépendants et généralement seule l'architecture native du système de l'utilisateur final est vérifiée.

Dans le cas des packages d'installation (bundles .pkg et .mpkg), tout est implicitement signé: l'archive CPIO contenant la charge utile, l'archive CPIO contenant les scripts d'installation et la nomenclature (BOM) ont chacune un hachage enregistré dans le XAR en-tête, et cet en-tête est à son tour signé. Par conséquent, si vous modifiez un script d'installation (par exemple) après la signature du package, la signature sera invalide.

Vous pouvez également vouloir signer vos plug-ins et bibliothèques. Bien que cela ne soit pas actuellement nécessaire, il le sera à l'avenir et il n'y a aucun inconvénient à avoir des signatures sur ces composants.

Selon la situation, codesign peut s'ajouter à votre fichier exécutable Mach-O, y ajouter des attributs étendus ou créer de nouveaux fichiers dans le répertoire Contents de votre bundle. Aucun de vos autres fichiers n'est modifié.

Aussi d'ici ce n'est pas nécessairement vrai que d' avoir une signature non valide pour un moyen d' application , il ne parviendra pas à son lancement. La page dit:

Il appartient au système ou au programme qui lance ou charge le code signé de décider s'il convient de vérifier la signature et, le cas échéant, de déterminer comment évaluer les résultats de cette vérification.

Une application peut choisir d'autoriser les modifications.

Votre meilleur pari est une approche par essais et erreurs avec n'importe quelle application que vous essayez de modifier. Cela peut fonctionner, peut-être pas. Il n'y a pas de réponse toujours vraie qui puisse être donnée.

Si une application a été signée, vous pouvez rechercher un Contents/CodeResourcesfichier ou un Contents/_CodeSignature/CodeResourcesfichier dans le bundle. Ce fichier répertorie tous les composants signés et leurs valeurs de hachage attendues dans le bundle. C'est un bon endroit pour commencer à comprendre quels éléments de l'application un développeur juge suffisamment critiques pour surveiller les changements.

Même si la question fait spécifiquement référence à Mountain Lion, il y a un changement important dans la nouvelle version de macOS. Sur macOS 10.11 et versions ultérieures, les signatures qui ne couvrent pas l'intégralité du code sont rejetées.

Voir la note technique TN2206 - Signature en profondeur du code macOS .