lijianfei.com

自 2026 年底 worse_query 0-Day 沙盒逃逸漏洞公开以来，免越狱直接借调高特权守护进程修改 iOS 26 与 iOS 27 底层配置掀起了一波技术狂潮。然而在这场狂欢背后，暗流汹涌的移动安全黑产迅速嗅到了血腥味：恶意侧载包伪装成美化插件或改版工具，暗中利用底层系统调用暴力爆破 APFS 卷容器路径，通过符号链接掉包大肆搜刮受害者相册私钥助记词截图、偷取加密钱包并常驻后台窥探剪贴板。

面对这一近乎失控的攻防失衡，由开发者 Kianuni 开源的 WQGuard（容器守卫） 给出了一套令人耳目一新的防御答卷。不同于以往依赖以毒攻毒、甚至自身也借用逃逸漏洞进行自证的粗糙扫描脚本，WQGuard 采用 100% 物理只读内核系统调用、双槽 CSBlob（XML ∪ ASN.1 DER）密码学验签门禁、原生 lockdownd 环回配对协议栈与零解压网络熔断护盾，为侧载生态筑起了一道坚如磐石的端侧纵深防线。

在 iOS 强制访问控制模型（Seatbelt MACF）的既往认知中，不同 App 容器之间犹如被一道道深不见底的深渊彻底隔绝。然而，无论是针对 APFS Inode 盲扫的 bad_query（fsgetpath），还是通过欺骗高特权 containermanagerd 签发任意容器读写令牌的 worse_query，都在现实中撕开了触目惊心的权限口子。

当我拿到并深入逆向审计 WQGuard 的全套 Swift 5.9+ 核心源码（WQGuardCore）时，最让我震撼的不是它列出了多少条静态签名特征，而是它在底层系统工程上的极端克制与严谨品味：整套系统不含一行越狱提权利用代码，不依赖任何第三方 C 桥接库或 OpenSSL，仅凭 POSIX 原生描述符锁死、只读内存页映射与密码学不变式，便完成了对 2026 年全系已知逃逸利用链的降维打击。

在本文中，我将基于真实的真机环境取证与代码级逆向剖析，完整解构 WQGuard 的四层渐进式扫描流水线、两阶段沙盒逃逸攻防物理学、双槽签名防遮蔽解算、以及如何通过代理网络层跨越 iOS 50MB Jetsam 内存墙熔断 HTTP2Shell 远程高危漏洞。

一、系统全景：四层渐进式静态审计流水线

要对未知且潜在高度恶意的第三方侧载包进行安全体检，扫描器自身必须具备坚不可摧的防御不变量。如果扫描器在解析恶意安装包时被 Zip-Slip 路径穿越污染、被解压炸弹撑爆内存，甚至在遍历软链接时被引诱写入宿主目录，那么扫描器本身就会沦为黑客攻击的跳板。

WQGuard 设计了一条自顶向下的四层渐进式过滤流水线，每一层都设有极其严格的短路淘汰门禁：

1.1 三大无越权非侵入采集源 (Zero-Exploit Collection)

在标准未越狱 iOS 系统的沙盒限制下，普通应用无法直接 readdir 枚举 /var/mobile/Containers 下的其他应用目录。很多初级扫描工具为了拿到全机清单，往往冒险内嵌漏洞代码强行越权，这极易引发 0x8badf00d 看门狗强杀与系统守护进程崩溃。

WQGuard 彻底摒弃了漏洞提权思路，自研了三大非侵入采集源：

• 引擎 1A（本机虚拟环回直连）：通过本机环回网络扩展（如 LocalDevVPN）建立虚拟网卡，利用纯 Swift 零依赖手写的 LockdownInstProxyClient 直接与本机 lockdownd（TCP 62078）进行严格校验证书指纹（Fail-Closed）的 TLS 握手，直接查询官方 com.apple.mobile.installation_proxy 获取全机正规清单；
• 引擎 1B（离线注册表快照导入）：支持安全研究员通过电脑端 pymobiledevice3、Xcode 16+ 原生 devicectl 导出的 JSON 快照，或 installation_proxy 的 Plist/XML 备份文件，通过 AirDrop 一键导入直接离线审计；
• 引擎 2（本地未安装 IPA 队列深扫）：支持在系统「文件」App 中一次性勾选任意数量的 .ipa / .tipa 安装包，在随机 UUID 临时沙盒中完成按需拆包取证与立即自毁；
• 引擎 3（本机协议在位探针）：借助 UIApplication.canOpenURL，对已知黑产盗版工具链与仿冒钱包的常用 URL Scheme 进行毫秒级在位探测。

四大采集源的数据汇聚至 Bundle ID 跨源关联融合器，自动完成注册表元数据与物理二进制文件的多维对齐。

二、两阶段沙盒逃逸攻防与 containermanagerd 混淆替身受骗物理学

要真正读懂 WQGuard 的审计逻辑，我们必须先从操作系统内核与守护进程层面，彻底搞懂 2026 年席卷 iOS 26/27 的沙盒逃逸利用链究竟是如何运转的。

2.1 阶段一：APFS Inode 暴力枚举路径泄露 (bad_query / fsgetpath)

在 iOS 系统中，每个应用安装后，系统会为其分配一个形如 E2B8C41A-7F90-4D56-8A33-91C4B5E67890 的随机 UUID 容器路径。在没有提权的情况下，黑客无法预测受害者（如 MetaMask、Telegram）的具体路径，而 Seatbelt MACF 策略直接拦截了父目录遍历：

(deny file-read-data (subpath "/private/var/mobile/Containers"))

然而，系统底层的一个未封堵系统调用留下了致命漏洞——fsgetpath：

// Darwin / BSD 底层未公开系统调用
ssize_t fsgetpath(char *buf, size_t buflen, fsid_t *fsid, uint64_t ino);

恶意应用只需在后台开辟工作线程，从 ino = 1 顺序递增盲扫至上千万号段，由于 fsgetpath 直接向内核 APFS 对象映射表（Object Map）查询 Inode 并逆向反解路径，从而轻而易举地获取到了受害者应用的真实随机 UUID 路径！

[!WARNING] 系统稳定性杀手
单线程顺序盲扫 15,000,000 个 Inode 会引发极其剧烈的 APFS 缓冲抖动。如果在主线程执行，系统看门狗会在 10 秒内直接以 0x8badf00d 异常将进程强制杀死。

2.2 阶段二：containermanagerd 混淆替身软链接穿越 (worse_query)

拿到受害者容器路径后，恶意应用启动第二阶段攻击：向授权代管人（Authorized Deputy）投毒。
在 iOS 架构中，跨应用数据共享依赖 App Group。系统提供了一个具有高特权（root 或 mobile）的守护进程 containermanagerd，由其代为处理容器初始化并向 Darwin 内核索取沙盒扩展令牌（sandbox_extension_issue_file）。

攻击者在自己的合法 App Group 容器内设下致命陷阱：

1. 删除自身合法的 Library/Caches 目录；
2. 调用 symlink(targetVictimPath, cachesPath)，将 Library/Caches 偷换为指向受害者应用（如加密钱包目录）的符号链接；
3. 通过私有库 libsystem_containermanager.dylib，向 containermanagerd 发起针对自身 App Group 的标准容器查询（Class = 7, Part = 3）；
4. containermanagerd 收到请求，核验调用方的签名证书：“这个应用确实拥有这个 App Group 权限吗？” —— 核验通过！
5. containermanagerd 解析 Part = 3（即 Library/Caches），调用 realpath 解析物理路径。核心设计缺陷爆发：守护进程顺着符号链接解析到了受害者的物理目录，但严重漏掉了路径前缀边界回落检查（没有校验解析后的绝对路径是否仍然落在当前 App Group 容器内）；
6. containermanagerd 误以为这是合法目录，直接调用内核系统级特权接口：

   sandbox_extension_issue_file("com.apple.app-sandbox.read-write", targetVictimPath, 0);
   

7. 恶意应用接住内核签发的扩展令牌，调用 sandbox_extension_consume(token)，瞬间将当前沙盒特权直接扩展至受害者数据容器，实现无视系统隔离的物理级读写！

2.3 密码学不可能门禁定理 (Cryptographic Impossibility Gate)

针对这一看似防不胜防的漏洞链，WQGuard 在第一层给出了极其优雅的数学解法：
containermanagerd 的首道防线由内核 AMFI 强行约束。如果一个进程的代码签名中没有声明 com.apple.security.application-groups，containermanagerd 在收到 XPC 请求的第一瞬间就会直接以错误码 -1 物理拒绝，根本不可能进入后续的路径解析与令牌签发流程。

因此，WQGuard 建立了密码学不可能门禁定理：
在预先排查无需 App Group 即可独立执行的底层 Inode 盲扫系统调用（SYM_FSGETPATH）与仿冒钱包元数据之后，凡是未声明 App Group 的普通侧载应用，其在物理上绝不可能触发 worse_query 漏洞。扫描器在 $O(1)$ 常数时间内即可将其直接判定为 🟢 安全合规 (Safe)，瞬间排除了全机 95% 以上的无辜纯净应用，将有限的算力精准收束到高危目标上。

三、粉碎双槽 CSBlob 权限遮蔽：XML 与 DER 的并集解算

然而，黑产团队为了对抗静态扫描器，开发出了更加隐蔽的签名欺诈手法：利用苹果代码签名槽位的历史包袱实施「双槽遮蔽攻击」。

在 Mach-O 二进制的代码签名超级块（CSMAGIC_EMBEDDED_SIGNATURE = 0xfade0cc0）中，权限表（Entitlements）可以同时存放在两个完全不同的槽位中：

• Slot 5 (0xfade7171)：传统的 XML 属性列表（Property List）格式；
• Slot 7 (0xfade7172)：自 iOS 15 引入并在 iOS 26/27 成为内核 AMFI 绝对权威的 Apple CoreEntitlements ASN.1 DER 编码流。

3.1 恶意双槽遮蔽的手法

市面上绝大多数开源静态检测脚本或签名查看器，由于缺乏自研 DER 解码器，通常只读取 Slot 5 的 XML 文本。
攻击者深谙此道，他们在打包恶意 IPA 时故意耍花招：

• 在 Slot 5 写入一份完全合规无害的 XML <dict/>，或者显式声明 <key>com.apple.security.application-groups</key><false/>；
• 却在 Slot 7 的 Apple DER 真实二进制流中，静默写入真实的 com.apple.security.application-groups 以及高危私有权限 com.apple.private.photos.*！

当此类安装包运行在真机上时，iOS 内核 AMFI 优先采信 Slot 7 的 DER 权限树，使得恶意越权完美生效；而普通静态安全工具读取 Slot 5，误以为其未声明 App Group，直接予以放行！

3.2 WQGuard 自研递归 ASN.1 DER 解码引擎

为了彻底斩断这根盲区盲杖，WQGuard 在 CSBlobParser.swift 中完全基于 Swift 从零手写了一套纯净的 ASN.1 DER 递归解码状态机，深度实现了 ITU-T X.690 规范：

// CSBlobParser.swift 核心双槽合并解算逻辑
public func parseEntitlements(from data: Data) throws -> ParsedEntitlements {
    // 1. 严格核验超级块魔数 0xfade0cc0
    guard data.count >= 12 else { throw CSBlobError.dataTooSmall }
    let magic = data.readBigEndianUInt32(at: 0)
    guard magic == CSBlobConstants.superBlobMagic else {
        throw CSBlobError.invalidSuperBlobMagic(actual: magic)
    }

    // 2. 遍历 SuperBlob 索引槽，分别提取 Slot 5 XML 与 Slot 7 DER
    var xmlDict: [String: Any]? = nil
    var derDict: [String: Any]? = nil

    if let slot5Data = extractSlot(data: data, slotType: CSBlobConstants.slotEntitlements) {
        xmlDict = try parseXMLPlist(data: slot5Data)
    }
    if let slot7Data = extractSlot(data: data, slotType: CSBlobConstants.slotDerEntitlements) {
        // 解码顶层 [APPLICATION 16] (0x70) 与 [CONTEXT 16] (0xb0) 构造容器
        derDict = try parseAppleCoreEntitlementsDER(data: slot7Data)
    }

    // 3. 严格防遮蔽并集合并 (Union Gating)
    let mergedGroups = Set(extractGroups(from: xmlDict)).union(Set(extractGroups(from: derDict)))
    let hasGroups = !mergedGroups.isEmpty

    return ParsedEntitlements(
        rawXML: xmlString,
        rawDER: slot7Data,
        hasAppGroups: hasGroups,
        appGroups: Array(mergedGroups).sorted(),
        formatUsed: determineFormat(hasXML: xmlDict != nil, hasDER: derDict != nil)
    )
}

在解码 Slot 7 时，解析器严密处理了 Apple CoreEntitlements 特有的三层包装头：

1. 顶层 [APPLICATION 16]（Tag 0x70）；
2. 内部嵌套的 Schema 版本号 INTEGER 1；
3. 挂载真实字典数据的 [CONTEXT 16]（Tag 0xb0）；
4. 递归展开 0x30（SEQUENCE）、0x31（SET）、UTF8/IA5 字符串以及变长多字节标签。

经过与苹果官方 /usr/bin/codesign --generate-entitlement-der 编译结果进行逐字节实机对抗压测，WQGuard 实现了对 XML 与 DER 字典的原子级无遮蔽并集合并。任何企图利用空 Slot 5 掩护恶意 Slot 7 的伪装包，在导入瞬间便被彻底揭穿。

此外，WQGuard 还会顺着安装包的目录拓扑，对 PlugIns/*.appex 与 Extensions/*.appex 内的每一个独立扩展可执行文件单独进行 CSBlob 验签，封死了借助“小组件（Widget）或剪贴板扩展单独偷渡 App Group”的跳板路径。

四、抗混淆行为元组与 100% 物理只读不变量

当攻击者发现静态字符串匹配无法逃逸时，往往会采取进阶反取证手段：使用 strip -x 剥离符号表中的 C 函数名、利用 XOR / RC4 动态加密 "container_query_create" 等关键字符串，或者直接绕过 libsystem_containermanager.dylib 转为向底层 Mach 端口发送原始 XPC 消息。

4.1 逃无可逃的抗混淆启发式元组 (CM-07)

不论黑客如何对可执行文件进行加壳或字符串加密，在 iOS 用户态执行沙盒逃逸利用链，必须同时满足四项受制于操作系统物理规律的刚性约束：

1. 未加密执行体：普通侧载应用没有 App Store 的 FairPlay 硬件级 DRM 保护，其 Mach-O 头的 LC_ENCRYPTION_INFO_64 中 cryptid 恒等于 0；
2. 内核权限门票：必须在 CSBlob 中明文声明 com.apple.security.application-groups（该字段受内核 AMFI 校验，黑客绝不敢加密，否则应用直接被杀）；
3. 动态链接原语：剥离了动态库链接后，代码必须调用 dlopen 与 dlsym 才能在内存中动态挂载私有符号；
4. 文件系统穿越动作：攻击链最终必须调用符号链接创建接口（symlink、symlinkat 或 Cocoa 层的 createSymbolicLinkAtPath:withDestinationPath:error:），或者调用 sandbox_extension_consume 激活内核令牌。

WQGuard 将这四项刚性特征构建为抗 XOR 行为启发式元组（TUPLE_OBFUSCATED_EXPLOIT）：

$\text{cryptid} == 0 \quad\land\quad \text{AppGroups} \quad\land\quad (\text{dlopen} \land \text{dlsym}) \quad\land\quad (\text{symlink} \lor \text{sandbox\_consume})$

// 即使符号表全部被 strip，Objective-C 方法选择器名依然完好保存在 __objc_methname 段
let objcMethNames = machoParser.extractSectionCStrings(segment: "__TEXT", section: "__objc_methname")
if record.cryptid == 0 && record.hasAppGroups {
    let hasDynamicLoader = symbols.contains("dlopen") && symbols.contains("dlsym")
    let hasSymlinkAction = symbols.contains("symlink") || 
                           objcMethNames.contains("createSymbolicLinkAtPath:withDestinationPath:error:") ||
                           objcMethNames.contains("createSymbolicLinkAtURL:withDestinationURL:error:")
    let hasTokenConsume = symbols.contains("sandbox_extension_consume")
    
    if hasDynamicLoader && (hasSymlinkAction || hasTokenConsume) {
        // 命中 CM-07 启发式高危警报！
        findings.append(ThreatIndicator.tupleObfuscatedExploit)
    }
}

这一启发式规则的精妙之处在于：即使攻击者把所有的 C 语言字符串加密得干干净净，只要他在 Objective-C 或 Swift 中调用了系统创建软链接的 API，__objc_methname 中的选择器名称就会不可避免地留在二进制文件中暴露无遗。任何试图暗度陈仓的利用变种均会被定级为 🔴 高危告警。

4.2 100% 物理只读不变量 (Strict Read-Only Invariants)

作为一款安全防御工具，WQGuard 在工程设计上对自己立下了严酷的“三大零信任纪律”，杜绝由于扫描本身给用户系统带来连带风险：

[!IMPORTANT] 内核级只读硬锁死

1. POSIX 描述符锁死：底层文件访问强制采用 open(path, O_RDONLY | O_NOFOLLOW | O_CLOEXEC)。一旦遭遇恶意构造的跨目录软链接，内核层直接返回 ELOOP 抛错拒绝跟随，绝不给攻击者引诱扫描器跨出沙盒的机会；
2. 只读零拷贝内存映射：所有二进制与注册表解析均采用 Data(contentsOf: url, options: [.mappedIfSafe])，底层映射为虚拟内存的 PROT_READ 页面，配合严密的 64 位无符号算术防溢出校验，哪怕遇到畸形格式也绝不会发生崩溃；
3. 非递归软链接原位取证：容器排查严格使用 lstat() 代替 stat()，配合 readlink() 原位读取软链接指向的字符串直接作为证据留存，严禁对软链接进行向下递归；
4. 作用域 RAII 令牌自动释放：在处理沙盒扩展时，使用 ScopedSandboxToken 在作用域退出或 deinit 时立即通过 sandbox_extension_release 释放句柄，彻底防止大批量应用扫描耗尽 Darwin 内核的进程扩展表槽位（错误码 -6 / EXFULL）。

五、代理网络层防御：跨越 50MB Jetsam 内存墙熔断 HTTP2Shell

除了应用容器与侧载包审计，WQGuard 进一步将安全防护触角延伸到了系统底层的 CVE 固件免疫。
在 iOS 26 与 iOS 27.0–27.2.0 系统中，系统内置的 libbrotli 解压引擎存在一个严重的堆缓冲区越界写入高危漏洞——CVE-2026-111497（HTTP2Shell，CVSS 9.2）。由于许多追求系统可玩性的用户选择停留在特定固件版本，无法通过系统 OTA 升级消除该漏洞。

为此，WQGuard 在内置的固件评估雷达之外，独立开发了一套可在 Surge、Shadowrocket（小火箭）、Quantumult X（圈 X）、Loon 与 Stash 五大主流代理客户端上一键部署的防 Brotli 溢出网络护盾。

5.1 iOS 网络扩展进程的 50MB Jetsam 内存死穴

在网络代理层拦截 Brotli 压缩流，看似只需写一段脚本检查响应体，但在 iOS 系统工程中却暗藏一个致命陷阱：
在 iOS 架构中，所有代理软件均运行在名为 NEPacketTunnelProvider 的网络扩展插件进程内。苹果对该后台网络扩展施加了极其苛刻的 Jetsam 物理内存配额限制——硬上限仅有约 50MB。

如果代理脚本开启了 requires-body=true（要求抓取响应体进行分析），一旦用户刷到一段高清视频流或下载大体积文件，代理扩展就会因为瞬间将数兆乃至数十兆数据载入内存解压而触发内存超限，直接被 iOS 内核以 OOM 机制强杀，造成手机瞬间断网！

5.2 零解压纯响应头状态机与顶层 HTTP 403 熔断

WQGuard 巧妙地采用了“去程降级宣告 + 回程纯头熔断”的增强飞轮设计：

flowchart LR
    A["客户端 HTTP 请求"] -->|"Header Rewrite"| B["剥离 br 算法<br/>Accept-Encoding: gzip, deflate"]
    B --> C["外部 Web 服务器"]
    C -->|"正常合规响应"| D["下发 gzip/deflate 编码流 (安全通过)"]
    C -->|"强行推送 br 流"| E["brotli-guard.js 纯响应头检查<br/>(requires-body=false / max-size=0)"]
    E -->|"顶层零解压熔断"| F["立即返回 HTTP 403 Forbidden<br/>Content-Length: 0 / Connection: close"]

1. 去程正向降级：通过代理内核的请求头重写规则，强制将去程请求头替换为：

   ^https?:// header-replace Accept-Encoding "gzip, deflate"
   

   从源头上断绝合规 Web 服务器下发 br 压缩流的意图；
2. 回程纯响应头嗅探：对于无视协商、恶意推送 Content-Encoding: br 的恶意攻击源，回程脚本 brotli-guard.js 强制运行在 requires-body=false 且 max-size=0 模式下，全程不触碰、不拷贝一字节响应体；
3. 顶层 HTTP 403 熔断：一旦从多重大小写响应头中检出 br 编码标记，直接在顶层构建轻量级熔断响应中断连接：

   // Shields/scripts/brotli-guard.js 零解压熔断实现片段
   if (isBrotliEncoding(headers)) {
       // 跨越 50MB 内存墙：不分配任何缓冲区解压，直接在代理层击碎攻击流
       $done({
           status: 403,
           headers: {
               "Content-Type": "text/plain; charset=utf-8",
               "Content-Length": "0",
               "Connection": "close",
               "X-Protected-By": "WQGuard-Brotli-Shield"
           },
           body: ""
       });
       return;
   }
   

4. 16 项核心服务严格负向排除（Negative MITM Exclusions）：
   开启代理 HTTPS 解密（MITM）最怕误伤原生系统服务。WQGuard 内置编译器强制锁死了 16 项关键排除规则：
   • -guzzoni.apple.com 与 -*.siri.apple.com：保护普通话与全球 Siri，解密此域名会导致语音助手直接掉线瘫痪；
   • -apple-relay.* 与 -cp4.cloudflare.com：保护 Apple Intelligence 私有云计算（PCC） 与 iCloud 私密转送；
   • -*.alipay.com、-*.tenpay.com、-*.binance.com、-*.okx.com：严格豁免核心移动支付与金融交易的证书锁定（SSL Pinning），杜绝证书报错。

通过这一套精密配合，停留在旧版固件上的用户无需升级系统，便能在日常零电量消耗、零内存膨胀的前提下，彻底免疫来自 Web 传输层的 HTTP2Shell 远程堆越界写攻击。

六、实战落地：四级风险裁决与严格零信任准则

在实际使用 WQGuard（iOS 端或 macOS CLI wqguard-cli）对设备进行全盘审计时，系统会输出极其清晰的四级风险裁决结果：

[!NOTE] 为什么对第三方侧载工具坚持严格零信任？
很多用户习惯使用 Feather、全能签或 SideStore 来签名安装应用。但 WQGuard 绝不对任何第三方签名器暗开免检白名单。
因为在实战对抗中，黑产往往会拿 Feather 的源码二开打包，表面上看是一个签名器，暗中却植入了窃密 Payload。只有坚持以真实的二进制切片、代码签名与行为元组为准绳，绝不盲信应用显示名称，才能真正构筑坚固的安全壁垒。

七、总结与思考

在移动安全对抗的宏大图景中，破坏往往比建设容易得多。利用一个系统守护进程的路径解析疏漏撕开沙盒口子，写出一篇酷炫的 Exploit PoC，或许只需要数十行 C 代码；但要写出一套能够顶住恶意攻击、覆盖多种架构畸形样本、同时自身 100% 遵守物理只读规则的生产级审计引擎，却需要跨越数以千计的底层系统工程陷阱。

WQGuard 的出现，向我们清晰地展示了优秀的系统防御工程应当具备的模样：

• 不以暴制暴：绝不为了审计而引入新的漏洞利用，始终坚守 POSIX 描述符的只读硬约束；
• 数学与逻辑严密：通过双槽 CSBlob 并集解算打破暗箱遮蔽，利用密码学门禁定理实现 $O(1)$ 的无害放行；
• 敬畏系统边界：在代理网络层以纯响应头状态机跨越 50MB Jetsam 内存高墙，在毫厘之间达成安全防护与设备体验的完美平衡。

无论你是热衷于探索 iOS 底层机制的安全研究员，还是在日常玩机中希望保护自己数字资产与隐私安全的普通用户，WQGuard 都是一份不可多得的优秀工程范本。

原文链接与参考资料

• WQGuard 官方开源仓库：Kianuni/WQGuard (GitHub)
• WQGuard 底层技术白皮书与威胁矩阵：USAGE_GUIDE.md (GitHub)
• WQGuard 安全架构与物理只读不变量规范：SECURITY.md (GitHub)
• Apple Open Source 源码剖析：xnu/bsd/vfs/vfs_syscalls.c (fsgetpath & O_NOFOLLOW 实现机制)
• Apple Developer 官方规范：Mach-O Programming Topics & Code Signing Architecture
• CVE 官方漏洞库详情：CVE-2026-111497 (HTTP2Shell libbrotli Heap OOB Write)
• Erosion-CN 系统级配置修复项目：Kianuni/Erosion-CN (GitHub)