Security.framework 导出函数，如 SecCodeCheckValidityWithErrors() ref , src 用于验证针对证书库的代码签名的正确性。
但是，谁来检查检查员呢？ Security.framework 也已签名。内核如何在不事先加载 Security.framework 的情况下验证其签名以访问这些功能？这是否意味着只需将 Security.framework 替换为盲目接受任何签名的自定义实现就足以有效地关闭所有代码签名保护？
如果内核编译了 Security.framework 的静态版本，那么将它作为一个单独的框架有什么意义呢？如果没有，它是否只是盲目地相信这个特定的框架未被篡改？
背景:我最近在我的 Macbook 上更换了一个内置键盘，它用错误的 USB PID 声明自己，因此它被识别为 JIS 而不是 ANSI。它可以通过更改 AppleUSBTCKeyboard.kext 的 Info.plist 中的一行来修复，但这会使签名无效。使用所有相关 OID 创建自己的 CA 是不够的，因为 kext 签名检查被硬编码为仅接受 Apple 根证书。规避这种情况的唯一合法方法是向 Apple 支付 100 美元/年的费用，主要是为了使用我自己的电脑。这就是为什么我想提出 anchor apple 要求，不仅要匹配 Apple CA 颁发的证书，还要匹配任何受信任的 CA，包括用户提供的证书，以将公开可用的补丁作为非侵入性补丁尽可能，现在我正在研究如何做到这一点。
最佳答案
Apple 没有公开记录启动信任链的工作原理。
但是，有一些间接证据表明某些关键文件的校验和是在启动时执行的:
虽然我没有亲自尝试过，但似乎极有可能安全框架也被检查了，所以您不太可能偷偷对其进行更改。考虑在更高级别重新映射键盘。
关于macos - macOS 内核如何验证 Security.framework 的完整性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43966121/