TL; DR Cabe ao desenvolvedor escolher quais partes do aplicativo são assinadas e se a violação ou não dessas partes resulta em ações quando o aplicativo é iniciado. Você deve usar tentativa e erro para descobrir isso app a aplicativo.
Depende do desenvolvedor decidir quais componentes do pacote de aplicativos são representados no selo que é assinado antes de entregar o aplicativo. Qualquer coisa no selo é à prova de violação, pois é quase impossível modificar essas coisas sem alterar as assinaturas de hash. Mas isso não significa que você não possa mexer com eles.
O guia do desenvolvedor da Apple tem a dizer sobre o que você deve assinar:
Você deve assinar todos os executáveis do seu produto, incluindo aplicativos, ferramentas, ferramentas auxiliares ocultas, utilitários e assim por diante. A assinatura de um pacote configurável de aplicativos abrange seus recursos, mas não seus subcomponentes, como ferramentas e subconjuntos. Cada um deles deve ser assinado de forma independente.
Se o seu aplicativo consistir em uma grande parte da interface do usuário com uma ou mais pequenas ferramentas auxiliares que tentam apresentar uma única face ao usuário, você pode torná-lo indistinguível da assinatura de código, fornecendo a todos exatamente o mesmo identificador de assinatura de código. (Você pode fazer isso garantindo que todos tenham o mesmo valor CFBundleIdentifier em seu Info.plist ou usando a opção -i no comando codesign para atribuir o mesmo identificador.) Nesse caso, todos os componentes do programa têm acessar os mesmos itens de chaveiro e validar como o mesmo programa. Faça isso apenas se os programas envolvidos tiverem realmente o objetivo de formar uma única entidade, sem distinções.
Um binário universal (pacote ou ferramenta) possui automaticamente assinaturas individuais aplicadas a cada componente da arquitetura. Eles são independentes e, geralmente, apenas a arquitetura nativa no sistema do usuário final é verificada.
No caso de pacotes do instalador (pacotes .pkg e .mpkg), tudo é assinado implicitamente: o arquivo CPIO que contém a carga, o arquivo CPIO que contém scripts de instalação e a lista de materiais (BOM) têm um hash registrado no XAR cabeçalho e esse cabeçalho, por sua vez, é assinado. Portanto, se você modificar um script de instalação (por exemplo) após a assinatura do pacote, a assinatura será inválida.
Você também pode assinar seus plug-ins e bibliotecas. Embora isso não seja necessário no momento, será no futuro e não há desvantagem em ter assinaturas nesses componentes.
Dependendo da situação, o código de código pode adicionar ao seu arquivo executável do Mach-O, adicionar atributos estendidos ou criar novos arquivos no diretório Conteúdo do seu pacote. Nenhum dos seus outros arquivos é modificado.
Também a partir daqui , não é necessariamente verdade que ter uma assinatura inválida para um aplicativo significa que ele falhará ao iniciar. A página diz:
Cabe ao sistema ou programa que está iniciando ou carregando o código assinado decidir se deve verificar a assinatura e, se o fizer, determinar como avaliar os resultados dessa verificação.
Um aplicativo pode optar por permitir modificações.
Sua melhor aposta é uma abordagem de tentativa e erro com qualquer aplicativo que você esteja tentando modificar. Pode funcionar, ou não. Não existe uma resposta sempre verdadeira que possa ser dada.
Se um aplicativo foi assinado, você pode procurar por um Contents/CodeResourcesarquivo ou um Contents/_CodeSignature/CodeResourcesarquivo no pacote. Este arquivo lista todos os componentes assinados e seus valores de hash esperados no pacote configurável. É um bom lugar para começar a entender quais partes do aplicativo um desenvolvedor considera críticas o suficiente para observar as mudanças.