В Mountain Lion я знаю, что некоторые приложения, в том числе все приложения в Mac App Store, имеют цифровую подпись разработчика, так что, если они будут изменены, подпись не будет совпадать, и это вызовет всевозможные ошибки (и ситуация будет увеличиваться со следующим выпуском операционной системы...).
Мой вопрос: какие части пакета .app покрывает подпись? Если что - то Appname.app/Contentsизменится (включая метаданные, например дату изменения Contentsпапки), нарушает ли это подпись? Это просто двоичный файл в Contents/MacOS? Включены ли .plist в подпись? Resources? _ Как конечный пользователь, что я могу взломать (если что) без нарушения подписи?
TL;DR Разработчик должен выбрать, какие части приложения будут подписаны и приведет ли вмешательство в эти части к каким-либо действиям при запуске приложения. Вы должны использовать метод проб и ошибок, чтобы понять это для каждого приложения отдельно.
В значительной степени разработчик должен решить, какие компоненты в его пакете приложений представлены в печати, которая будет подписана до того, как они доставят свое приложение. Все, что находится в печати, эффективно защищено от несанкционированного доступа, поскольку в большинстве случаев невозможно изменить эти вещи, не изменив их хэш-подписи. Но на самом деле это не означает, что вы не можете вмешиваться в них.
В руководстве Apple для разработчиков говорится о том, что вы должны подписывать:
Вы должны подписать каждый исполняемый файл вашего продукта, включая приложения, инструменты, скрытые вспомогательные инструменты, утилиты и т. д. Подписание пакета приложений распространяется на его ресурсы, но не на его подкомпоненты, такие как инструменты и подпакеты. Каждый из них должен быть подписан независимо.
Если ваше приложение состоит из большой части пользовательского интерфейса с одним или несколькими небольшими вспомогательными инструментами, которые пытаются представить пользователю одно лицо, вы можете сделать их неразличимыми для подписи кода, назначив им одинаковый идентификатор подписи кода. (Вы можете сделать это, убедившись, что все они имеют одинаковое значение CFBundleIdentifier в своем Info.plist, или используя параметр -i в команде codesign, чтобы назначить один и тот же идентификатор.) В этом случае все компоненты вашей программы имеют доступ к одним и тем же элементам цепочки для ключей и проверка в той же программе. Делайте это только в том случае, если задействованные программы действительно предназначены для формирования единого объекта без каких-либо различий.
Универсальный двоичный файл (пакет или инструмент) автоматически имеет индивидуальные подписи, применяемые к каждому компоненту архитектуры. Они независимы, и обычно проверяется только собственная архитектура системы конечного пользователя.
В случае пакетов установщика (пакеты .pkg и .mpkg) все неявно подписано: архив CPIO, содержащий полезную нагрузку, архив CPIO, содержащий сценарии установки, и спецификация (BOM) имеют хэш, записанный в XAR. заголовок, а этот заголовок, в свою очередь, подписывается. Поэтому, если вы измените сценарий установки (например) после того, как пакет был подписан, подпись будет недействительной.
Вы также можете подписать свои плагины и библиотеки. Хотя в настоящее время это не требуется, это будет в будущем, и наличие подписей на этих компонентах не является недостатком.
В зависимости от ситуации, codesign может добавить к вашему исполняемому файлу Mach-O, добавить к нему расширенные атрибуты или создать новые файлы в каталоге Contents вашего пакета. Ни один из ваших других файлов не изменен.
Также отсюда не обязательно верно, что наличие недопустимой подписи для приложения означает, что оно не запустится. На странице написано:
Система или программа, которая запускает или загружает подписанный код, решает, следует ли проверять подпись, и, если да, то как оценивать результаты этой проверки.
Приложение может решить разрешить модификации.
Лучше всего использовать метод проб и ошибок с любым приложением, которое вы пытаетесь изменить. Может сработать, может нет. Не всегда можно дать верный ответ.
Если приложение было подписано, вы можете найти Contents/CodeResourcesфайл или Contents/_CodeSignature/CodeResourcesфайл в комплекте. В этом файле перечислены все подписанные компоненты и их ожидаемые хэш-значения в комплекте. Это хорошее место, чтобы начать понимать, какие части приложения разработчик считает достаточно важными, чтобы следить за изменениями.
Несмотря на то, что вопрос конкретно относится к Mountain Lion, в более новой версии macOS есть важное изменение. В macOS 10.11 и более поздних версиях подписи, которые не охватывают весь код, отклоняются.
См. техническое примечание TN2206 — Подробная информация о подписывании кода в macOS .
Адам Дэвис
Даниэль
Адам Дэвис