对应用程序进行代码签名时，签名涵盖.app捆绑包的哪些部分？

在Mountain Lion中，我知道某些应用程序（包括Mac App Store上的所有应用程序）都是由开发人员进行数字签名的，因此，如果对它们进行修改，签名将不匹配，并且会引发各种错误（以及情况如何）。将随着操作系统的下一个版本升级...）。

我的问题是签名覆盖.app捆绑包的哪些部分？如果任何的Appname.app/Contents变化（包括元数据，如用于修改日期Contents的文件夹），这是否破坏签名？仅仅是二进制文件Contents/MacOS吗？签名中是否包含.plists？的Resources？作为最终用户，我该如何破解（如果有的话）而不会破坏签名？

TL; DR取决于开发人员，以选择对应用程序的哪些部分进行签名，以及是否对这些部分进行篡改会在应用程序启动时导致任何操作。您必须使用反复试验才能逐个确定该错误。

在很大程度上，由开发人员决定在交付应用程序之前，应用程序束中的哪些组件在已签名的图章中表示。印章中的任何内容都可以有效地防止篡改，因为在不更改其哈希签名的情况下，几乎不可能修改这些内容。但这实际上并不意味着您不能篡改它们。

苹果开发人员指南对此有明确的规定：

您应该对产品中的每个可执行文件进行签名，包括应用程序，工具，隐藏的帮助程序工具，实用程序等。对应用程序捆绑包进行签名将覆盖其资源，但不会覆盖其子组件（例如工具和子捆绑包）。每个都必须独立签名。

如果您的应用程序由一个很大的UI组成，并带有一个或多个试图向用户展示单个面孔的小助手工具，则可以通过为它们提供完全相同的代码签名标识符来使它们与代码签名难以区分。（您可以通过确保它们在Info.plist中都具有相同的CFBundleIdentifier值，或通过使用codesign命令中的-i选项来分配相同的标识符来做到这一点。）在这种情况下，所有程序组件都具有访问相同的钥匙串项目并验证为相同的程序。仅在所涉及的程序确实旨在形成一个单一实体而没有任何区别的情况下，才执行此操作。

通用二进制文件（捆绑或工具）自动将各个签名应用于每个体系结构组件。它们是独立的，通常仅验证最终用户系统上的本机体系结构。

对于安装程序包（.pkg和.mpkg捆绑包），所有内容都进行隐式签名：包含有效负载的CPIO归档文件，包含安装脚本的CPIO归档文件和物料清单（BOM）都在XAR中记录了哈希值标头，然后对该标头进行签名。因此，如果在对程序包进行签名后修改了安装脚本（例如），则签名将无效。

您可能还需要对插件和库进行签名。尽管当前不需要这样做，但将来会这样做，并且在这些组件上具有签名也没有不利之处。

根据情况，codesign可能会添加到您的Mach-O可执行文件中，向其添加扩展属性，或者在捆绑软件的Contents目录中创建新文件。您的其他文件均未修改。

同样从这里开始，对于应用程序具有无效签名不一定意味着它将无法启动。该页面显示：

由启动或加载签名代码的系统或程序决定是否验证签名，如果确定，则确定如何评估该验证的结果。

应用程序可以选择允许修改。

最好的选择是尝试并尝试修改任何应用程序的方法。它可能有效，但可能无效。没有永远正确的答案。

如果已对应用程序进行签名，则可以在捆绑软件中查找Contents/CodeResources文件 Contents/_CodeSignature/CodeResources。该文件在捆绑包中列出了所有已签名的组件及其预期的哈希值。在这里开始了解开发人员认为应用程序的哪些部分足够重要以监视更改的好地方。

即使该问题专门针对Mountain Lion，更新的macOS版本也发生了重要变化。在macOS 10.11及更高版本上，拒绝覆盖整个代码的签名。

请参阅技术说明TN2206-macOS代码签署深度。