TL; DR Spetta allo sviluppatore scegliere quali parti dell'app siano firmate e se manomettere o meno quelle parti si traduce in qualsiasi azione all'avvio dell'app. Devi utilizzare tentativi ed errori per capirlo su base app per 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 in quanto è quasi impossibile modificare queste cose senza cambiare le loro firme hash. Ma questo non significa in realtà che non puoi manometterli.
La guida per gli sviluppatori Apple ha questo da dire su ciò che dovresti firmare:
È necessario firmare tutti gli eseguibili nel prodotto, inclusi applicazioni, strumenti, strumenti di supporto nascosti, utilità e così via. La firma di un pacchetto di applicazioni copre le sue risorse, ma non i suoi sottocomponenti come strumenti e sottogruppi. Ognuno di questi deve essere firmato in modo indipendente.
Se l'applicazione è costituita da una grande parte dell'interfaccia utente con uno o più piccoli strumenti di supporto che tentano di presentare una singola faccia all'utente, è possibile renderli indistinguibili dalla firma del codice, dando loro esattamente lo stesso identificativo di firma del codice. (Puoi farlo assicurandoti che abbiano tutti lo stesso valore CFBundleIdentifier nel loro Info.plist, o usando l'opzione -i nel comando codesign, per assegnare lo stesso identificatore.) In quel caso, tutti i componenti del tuo programma hanno accedere agli stessi elementi del portachiavi e convalidare lo stesso programma. Fallo solo se i programmi in questione sono veramente pensati per formare una singola entità, senza fare distinzioni.
Un binario universale (bundle o strumento) ha automaticamente le firme individuali applicate a ciascun componente dell'architettura. Questi sono indipendenti e di solito viene verificata solo l'architettura nativa sul sistema dell'utente finale.
Nel caso dei pacchetti di installazione (pacchetti .pkg e .mpkg), tutto è implicitamente firmato: l'archivio CPIO contenente il payload, l'archivio CPIO contenente gli script di installazione e la distinta materiali (distinta materiali) hanno ciascuno un hash registrato nella XAR intestazione e quell'intestazione a sua volta è firmata. Pertanto, se si modifica uno script di installazione (ad esempio) dopo la firma del pacchetto, la firma non sarà valida.
Potresti anche voler firmare i plug-in e le librerie. Sebbene questo non sia attualmente richiesto, lo sarà in futuro e non ci sono svantaggi nell'avere firme su questi componenti.
A seconda della situazione, il codice può aggiungere al file eseguibile Mach-O, aggiungere attributi estesi o creare nuovi file nella directory dei contenuti del pacchetto. Nessuno degli altri tuoi file viene modificato.
Inoltre da qui non è necessariamente vero che avere una firma non valida per un'applicazione significa che non verrà avviato. La pagina dice:
Spetta al sistema o al programma che sta avviando o caricando il codice firmato decidere se verificare la firma e, in caso affermativo, determinare come valutare i risultati di tale verifica.
Un'applicazione può scegliere di consentire le modifiche.
La tua scommessa migliore è un approccio di prova ed errore con qualsiasi applicazione che stai tentando di modificare. Potrebbe funzionare, potrebbe non esserlo. Non c'è una risposta sempre vera che possa essere data.
Se un'app è stata firmata, puoi cercare un Contents/CodeResourcesfile o un Contents/_CodeSignature/CodeResourcesfile nel pacchetto. Questo file elenca tutti i componenti firmati e i loro valori hash previsti nel bundle. È un buon posto per iniziare a capire quali parti dell'applicazione sono ritenute abbastanza importanti da uno sviluppatore per tenere conto delle modifiche.