黑苹果驱动Kext绕过签名校验指南

玩黑苹果的人都知道，折腾完引导和系统之后，最头疼的往往不是跑分不稳，而是**驱动装不上、或者装上就崩**。尤其是当你从GitHub上拖下来一个第三方kext，放进EFI里却发现系统根本不认——这时候问题十有八九出在签名上。

很多新手卡在这一步：明明按教程把驱动放进了对应文件夹，也重建了缓存，但重启后设备就是没反应，或者直接五国。翻遍论坛，有人说是Lilu版本不对，有人说是WhateverGreen冲突，其实真正的原因常常是**kext没通过系统的完整性校验**。

最核心的痛点在于：macOS从Mojave开始强化了对内核扩展的签名验证，普通用户自己编译或修改过的kext，基本过不了原生SIP那一关。更麻烦的是，很多老教程还在教人用`csrutil disable`彻底关掉SIP，这在现在的T2芯片或Apple Silicon机型上根本行不通，而且**关闭系统保护本身就是个安全隐患**。

解决方案其实不复杂，核心思路是**绕过签名校验而非关闭安全功能**。具体来说，配合OpenCore引导，你可以启用`SecureBootModel`设置为`Disabled`（仅针对非Apple机型），同时开启`KextSigning`和`KextAppleRTC`的修正参数。重点在于**使用OpenCore自带的签名绕过机制**，它能在不触发SIP警告的情况下让未签名kext正常加载。

具体做法分三步走。第一步，确认你的EFI里OpenCore版本在0.7.5以上，并在`config.plist`的`Misc → Security`里把`AllowNvramReset`设为`True`，`Vault`设为`Optional`。第二步，用`Kext Utility`或`sudo kextcache -i /`重建缓存，但注意**每次修改kext后都要重新执行一次**。第三步，也是最容易被忽略的，去`System Settings → Privacy & Security`里检查是否有“系统软件已被阻止”的提示，如果有，直接点“允许”——这一步往往比改配置文件更管用。

说到底，**黑苹果的稳定性是折腾出来的**，签名问题只是其中一道坎。只要掌握绕过而非关闭的思路，大部分驱动冲突都能迎刃而解。下次再遇到加载失败，先别急着删驱动，去看看签名日志吧。
=== 第2段 ===
**当你在Console.app里看到`kernel extension is not signed`或`code signature invalid`时，基本就能确诊了**。日志会明确告诉你哪个kext被拒，以及拒绝原因——这比盲猜硬件的兼容性要高效得多。

**实操中最容易踩的坑其实是缓存残留**。很多人改了配置、解除了签名限制，但`/System/Library/Caches/com.apple.kext.caches`里还躺着旧文件的副本。这时候需要用终端强制清理：`sudo rm -rf /Library/Caches/com.apple.kext.caches && sudo kextcache -i /`，然后再重启。**这一步不执行，前面所有配置都白搭**。

另外，如果你用的是Hackintool生成的SSDT热补丁，务必检查它是否被放进了`Kernel → Add`列表且启用了`BundlePath`。有些新手把补丁放对了位置，却忘了在config里勾选，导致签名校验直接跳过这个设备，但驱动本身却因为缺少依赖而崩溃。**加载顺序也关键**：Lilu必须排第一，VirtualSMC第二，其他插件依次紧跟，顺序错了同样会触发签名异常。

遇到实在搞不定的顽固kext，还有个偏方——用`-lilubetaall`启动参数临时放开所有Lilu插件的兼容性限制，但这个只适合调试，别长期使用。**最终稳定方案还是在Release版本里找预编译好的签名证书文件**，那些带`-signed.pkg`后缀的版本通常能直接通过校验。

记住，**别一遇到问题就重装系统**。先翻日志，再查缓存，最后看加载顺序，这套流程走下来，90%的签名问题都能在十分钟内解决。剩下的10%，多半是你下载的kext本身跟系统版本不匹配，换一个对应分支的版本即可。