One of the longstanding joys of the Mac has been how you can customise apps, giving them new icons and, in the past at least, even a few gentle tweaks. What’s unfortunate is that changing apps isn’t just for users. If we can alter them, so can an attacker, and the last thing any of us would want is for Safari or Preview to turn malicious. Over the years the scope for making changes to apps has therefore been reduced. This article explains how, and what we can still do.
To understand how customisation has been limited, we need to know what can and can’t change.
Signature
The most basic requirement of any app is that it’s signed. This provides a set of hashes that can be used to verify that none of its contents have been changed since that app was signed, and those hashes are hashed again to product code directory hashes, CDHashes, that are used to identify and recognise the app. Whatever we might customise in an app, its CDHashes must match its contents.
Certificate
Next comes the chain of trust established by the certificate used to sign the app. Developer certificates are issued by Apple as their Certificate Authority, so they each can be traced back through an Apple Intermediate certificate to Apple’s Root certificate, the chain of trust.
An Apple-issued certificate isn’t required for macOS to run an app, though. Because many Mac users build their own apps locally from open source, local or ad hoc certificates are also acceptable. However, anyone can sign an app with an ad hoc certificate, including an attacker, and, apart from the few malicious apps that have been signed using developer certificates, all other malware for the Mac is now ad hoc signed. As ad hoc signatures have no chain of trust, you can’t put any trust in them.
Notarization
Over the last few years, Apple has required developers to get their apps notarized. That involves ensuring the app meets certain security requirements, and is submitted to Apple to be checked to see if it contains any malicious code. Apps that satisfy those requirements are then issued with a ticket, that’s usually stapled inside the app’s bundle. That consists of the app’s set of CDHashes, again used to identify and recognise that app.
Although there’s no reason that you can’t notarize your own apps, and any you have resigned, that requires a paid-for subscription as a developer, putting it out of the reach of most. However, in an enterprise it can prove useful.
Launch constraints
Since macOS 13.3 Ventura, a new set of restrictions have been imposed on all apps and command tools provided as part of macOS, in launch constraints. These are rules that must be met for macOS to launch that app or binary, and include self constraints that the binary itself must meet, parent constraints that must be met by its parent process, and responsible constraints that must be met by the process requesting the launch.
Launch constraints for bundled apps prevent them from being run from anywhere else. If you manage to make a copy of any of those apps, and that’s a challenge in itself, then macOS will prevent you from running that copy. This is made harder to avoid by the fact that these launch constraints are stored in an inaccessible Trust Cache, so the only way you could work round those rules is by turning System Integrity Protection (SIP) off, which in turn reduces Boot Security. That’s explained in more detail here.
Although third-party apps don’t get to use launch constraints or the Trust Cache, some may now have started using environment constraints, which can have similarly restrictive effects. The best way to discover this is using Apparency, which also includes a full guide to the constraints available.
Bundled apps
If you can’t remember which apps are bundled and which are not, look in /System/Applications, as that shows all those in the Signed System Volume, to which you need to add Safari, as that’s sealed in a cryptex.
Sadly, because of all their levels of protection, you can’t customise any of the bundled apps. Even copying them from their read-only SIP-protected location to a folder in your Home folder, which is difficult enough, that copy can’t be run, no matter what you do to it. You can make a Finder alias to the original app and give that a custom icon that will appear in Finder windows. But the app’s original icon will still be displayed everywhere else, including in the Dock, so it’s simply not worth the effort.
If you had ideas that you could replace all Tahoe’s new-style app icons with those from Sequoia, I’m afraid you will be disappointed.
Third-party apps
One customisation you can apply in complete safety is to replace a regular app’s icon. To do that, paste the new icon into the top left of its Get Info dialog, and further information is given here. This doesn’t affect any of the security protection of that app, as the new icon is added as a hidden Icon file at the top level inside the app’s bundle, which isn’t included in its CDHashes.
Any more substantial changes, even to the app’s resources, should break its signature and CDHashes, and macOS won’t like that.
If there’s a really good reason for making a change, and you can justify resigning the app using an insecure ad hoc signature, you could try stripping its current signature, changing the app bundle, then resigning it with an ad hoc signature. There are two cautions, though:
Any ad hoc signature is inherently insecure, and makes it simple for malicious code to tamper with that app.
This may break the app’s updating process, and if it doesn’t, any update will undo your customisation.
Before going any further, you’ll need to add Terminal to the list in System Settings > Privacy & Security > App Management, otherwise your commands will be unable to make any changes to the app. Then make a copy of the app you intend to change, so you can readily revert to the original. Once you’ve done that, open Terminal and use the command codesign --remove-signature MyApp.app
to strip the existing signature from the app MyApp.app. Note that two hyphens precede the remove-signature verb.
When you’ve made your changes, use the command codesign --sign - MyApp.app
to sign that app with an ad hoc signature.
Summary
Apps bundled in macOS from 13.3 onwards can’t be copied and run from elsewhere, preventing all customisation, and can’t be given custom icons.
Third-party apps can have custom icons applied in the normal way.
Any internal surgery inside the app bundle will break its notarization and signature, and shouldn’t be attempted.
If it’s an essential change, you may be able to strip the signature, make the change, and resign with an ad hoc signature.
Ad hoc signatures are inherently insecure, and should be avoided if at all possible.
我参与 3DFiti 这个艺术项目，旨在通过 3D 扫描和 3D 打印技术，使我们生活的周边环境增加一些趣味性和艺术性。在人类学家项飙（英国牛津大学社会人类学教授，德国马克斯普朗克社会人类学研究所所长）所描述的那个「附近」的概念之中延展出来，一切我可以到达的地方，只要有我感兴趣的公共区域内的「缺损」部分，就有可能成为这个艺术项目的创作对象。
我通过 iPhone 扫描空间或者物体，并对模型进行二次创作，使用 3D 打印技术将其制作成一件真实的物品，即能够与现场的「缺损」相嵌合的物件，使这个「缺损」转化为一处临时的微型艺术场所。
No.001 作品中的 紫竹观音像 3D 模型，是来自 Funes.world 的文件。他们的工作是在人类从原子社会进入到比特社会的过程中，将原本属于原子世界中的建筑、空间、故事，通过 3D 扫描建模的方式，将其保存在数字世界中，建成一座人类文明的数字空间博物馆。
Login
尾注
后台私信出了三把 
这是万万没想到的…… 鉴于各个平台一直都有人问我有没有购买链接，那就索性上架水产市场，就当赛博摆摊了。
温馨提示：
而且是毒蘑菇！
什么四根手指啊、三根绥带啊、两端对不齐的签子啊… 其实咋一看的效果也确实足够好了，毕竟是虚构的漫画角色，你说头身比例奇怪，好像也是合理范围内。
播放地址：
苹果真的只是在给 UI 换皮吗？
为什么苹果要在这个时间点，推出这样一套动态、半透明的视觉语言？
为什么它要在 iPhone 上实现这种「液态玻璃」的设计？
难道它背后还有更大的目标 —— 比如，透明手机？或者，是为某种尚未到来的设备铺路？
