TL;DR C'est au développeur de choisir les éléments de l'application qui sont signés et de décider si l'altération de ces éléments entraîne ou non des actions au lancement de l'application. Il faut procéder par essais et erreurs pour le déterminer, application par application.
C'est en grande partie au développeur de décider quels composants de son paquet d'applications sont représentés dans le sceau qui est signé avant qu'il ne livre son application. Tout ce qui figure 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 pour autant que vous ne pouvez pas les altérer.
Le guide du développeur Apple a ceci à dire sur ce que vous devriez signer :
Vous devez signer chaque exécutable de votre produit, y compris les applications, les outils, les outils d'aide cachés, les utilitaires, etc. La signature d'un paquet d'applications couvre ses ressources, mais pas ses sous-composants tels que les outils et les sous-paquets. sous-composants tels que les outils et les sous-groupes. Chacun d'entre eux doit être signé indépendamment.
Si votre application se compose d'une grande partie d'interface utilisateur avec une ou plusieurs petites outils d'aide qui tentent de présenter un seul visage à l'utilisateur, vous pouvez vous pouvez les rendre indiscernables pour la signature de code en leur donnant à tous le exactement le même identifiant de signature de code. (Vous pouvez le faire en vous assurant qu'ils ont tous la même valeur de CFBundleIdentifier dans leur Info.plist, ou en utilisant l'option -i dans la commande codesign, afin d'attribuer le même identifiant). attribuer le même identifiant). Dans ce cas, tous les composants de votre programme ont accès aux mêmes éléments du trousseau de clés et sont validés comme le même programme. Ne procédez de la sorte que si les programmes concernés sont réellement destinés à former une seule entité, sans aucune distinction.
Un binaire universel (paquet ou outil) a automatiquement des signatures individuelles individuelles appliquées à chaque composant de l'architecture. Ces signatures sont indépendants, et généralement seule l'architecture native du système de l'utilisateur système de l'utilisateur final est vérifiée.
Dans le cas des paquets d'installation (paquets .pkg et .mpkg), tout est implicitement signé : L'archive CPIO contenant le payload, l'archive l'archive CPIO contenant les scripts d'installation scripts et la nomenclature (BOM). (BOM) ont chacune un hash enregistré dans l'en-tête XAR, et cet en-tête est à son tour signé. en-tête est à son tour signé. Par conséquent, si vous modifiez un scripts d'installation (par (par exemple) après que le paquet a été signé, la signature sera invalide.
Vous pouvez également signer vos plug-ins et vos bibliothèques. Bien que cela que cela ne soit pas exigé actuellement, cela le sera à l'avenir, et il n'y a pas d'inconvénient à avoir des signatures sur ces composants. inconvénient à ce que ces composants soient signés.
Selon la situation, le codesign peut ajouter à votre exécutable Mach-O Mach-O, lui ajouter des attributs étendus, ou créer de nouveaux fichiers dans le répertoire Contents de votre répertoire Contents de votre bundle. Aucun de vos autres fichiers n'est modifié.
Aussi d'ici il n'est pas nécessairement vrai que le fait d'avoir une signature invalide pour une application signifie qu'elle ne pourra pas être lancée. La page dit :
Cela dépend du système ou du programme qui lance ou charge la signature. signé de décider de vérifier la signature et, le cas échéant, de déterminer comment déterminer comment évaluer les résultats de cette vérification.
Une application peut choisir d'autoriser des modifications.
Le mieux est de procéder par essais et erreurs pour toute application que vous essayez de modifier. Cela peut fonctionner, mais pas forcément. 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 numéro d'identification de l'application. Contents/CodeResources ou un fichier Contents/_CodeSignature/CodeResources dans le paquet. Ce fichier liste tous les composants signés et leurs valeurs de hachage attendues dans le bundle. C'est un bon point de départ pour comprendre quels sont les éléments de l'application qu'un développeur juge suffisamment critiques pour en surveiller les changements.
