lijianfei.com

在 iOS 15 引入系统签名卷（SSV / APFS Sealed System Volume）之后，苹果通过硬件级加密校验将系统根分区（/）彻底锁死为只读快照。为了在不触发内核 Panic 的前提下维系生态，越狱社区全面转向了 Rootless（免根分区）范式——以 Dopamine 为代表的现代越狱工具将所有二进制文件、动态库与配置全部重定向至 /var/jb。然而，这一妥协方案迅速成为了移动安全攻防的新靶心：金融银行、主流手游与企业级 MDM 仅仅通过检索 /var/jb 静态路径、遍历 dyld 内存镜像或探测 sileo:// 协议，就能以极高精度完成越狱拦截。

为了打破这种“越狱即暴露”的被动对抗死锁，Roothide 开发团队推出了深度定制的 Dopamine-roothide。它并没有停留在“利用 Hook 隐藏自身”的传统修补逻辑，而是从操作系统底层彻底推翻了 Rootless 的静态假设：通过完全消除 /var/jb 静态锚点、在 dyld4 中引入基于 @loader_path/.jbroot 的动态相对寻址、构建虚拟化文件系统垫片（vroot），并在 launchd、lsd、springboard、cfprefsd 等核心系统守护进程上构建立体隐匿矩阵，实现了普通应用沙盒内部对越狱痕迹的“物理级不存在”。我深入审计了其全部 C/C++ 与 Objective-C 源码，系统梳理出了这套现代 iOS 无痕越狱的底层架构与工程实现。

一、 根源之困：为什么传统 Rootless 越狱依然“一眼假”？

要理解 Dopamine-roothide 的架构突破，首先必须透视传统 Rootless 越狱在防御风控面前暴露出的三维死穴。

在传统的 Dopamine 架构中，系统通过提权在 /private/preboot/<UUID>/ 目录下生成越狱工作目录，并在用户数据分区根部建立一个全局软链接：/var/jb -> /private/preboot/<UUID>/dopamine-<Hash>/procursus。尽管它没有修改系统的密封快照，但在应用层的风控探针眼中，这套环境依然暴露出巨大的攻击面：

flowchart TD
    subgraph Traditional ["传统 Rootless 架构的暴露面"]
        A1["静态文件系统探测<br/>access('/var/jb', F_OK)<br/>stat('/var/jb') 软链接暴露"]
        A2["dyld 动态库镜像探测<br/>_dyld_get_image_name()<br/>遍历出 /var/jb/usr/lib/*.dylib"]
        A3["系统服务与协议探测<br/>canOpenURL('sileo://')<br/>向 launchd jbserver 投递 Mach 消息"]
    end

    subgraph DefenseFailure ["传统绕过方案的局限 (Choicy / Shadow / vnodebypass)"]
        B1["基于运行时 Hook 拦截函数调用<br/>(易被 SVC 直接系统调用穿透)"]
        B2["向目标进程注入屏蔽插件<br/>(自身动态库注入即成为新的检测特征)"]
        B3["维护成本极高，极易引发崩溃与内存泄漏"]
    end

    A1 -.-> B1
    A2 -.-> B2
    A3 -.-> B3

1. 静态全局路径的“阿喀琉斯之踵”

任何一个普通的沙盒内应用，只要执行一行基础的 POSIX 文件系统调用：

if (access("/var/jb", F_OK) == 0 || stat("/var/jb", &st) == 0) {
    // 捕获越狱特征
}

即可瞬间抓现行。即便攻击者试图在应用内 Hook stat 或 open，商业安全 SDK（如 Promon、ThreatMetrix、DXShield 等）早已改用内联汇编直接发起系统调用（Direct Syscall svc #0x80），瞬间让所有用户态符号拦截全部落空。

2. 全局动态注入的“自证矛盾”

传统越狱引擎为了在各种守护进程中维持 Hook 能力，通常会让 systemhook 和 ElleKit 广泛渗透到大多数进程空间。即使通过插件管理器（如 Choicy）对银行 App 关闭了插件加载，动态链接器在加载期注入的动态库内存页、修改过的 dyld 结构体以及异常的 PROT_EXEC 内存段，都会在内核或系统库的自检中彻底暴露。

3. 系统级信息泄露的“链式扩散”

即便应用自身无法直接读取越狱目录，系统级守护进程依然会无意中泄露越狱环境：

• lsd（Launch Services 守护进程）会在处理 canOpenURL: 时证实 sileo:// 或 filza:// 等越狱 URL Scheme 的存在；
• springboard 会在被查询安装包列表时返回越狱工具的 Bundle ID；
• cfprefsd 会在多进程共享配置时泄露越狱插件的偏好设置文件。

针对这些根本矛盾，Dopamine-roothide 确立了 “非授信进程零感知、零注入、零静态路径” 的终极设计理念。

二、 核心架构全景：Roothide 的立体隐匿矩阵

Dopamine-roothide 并非对上游代码进行简单的打补丁，而是将一套完整的 Roothide 底层子系统精准织入了 Dopamine 3.x 的内核提权与用户态引导链条中。

flowchart TD
    subgraph KernelSpace ["内核态提权与环境准备 (Dopamine 3.x)"]
        K1["内核漏洞利用链 (DarkSword / ClearSword / SPTM 绕过)"]
        K2["获取物理内存读写与内核凭据 (krw)"]
        K3["挂载 TrustCache 并向 launchd 注入 launchdhook"]
    end

    subgraph LaunchdSpace ["PID 1 (launchdhook + jbdomain_roothide)"]
        L1["jbserver 权限中枢 (roothide_domain_allowed)"]
        L2{"调用者 Token 是否受信任？"}
        L3["常规 App Store 进程：静默丢弃 Mach 消息 (零响应)"]
        L4["越狱授权进程：放行 POSIX Spawn 提权与 TrustCache 注册"]
    end

    subgraph DyldSpace ["动态链接层 (dyldhook + dyld4)"]
        D1["拦截 dyld4::Loader::expandAtLoaderPath"]
        D2["识别 @loader_path/.jbroot 前缀"]
        D3["动态重定向至运行时随机生成的物理 jbroot 路径"]
    end

    subgraph DaemonCloak ["系统守护进程过滤层 (roothidehooks)"]
        H1["lsd.x: 阻断越狱 URL Scheme 查询"]
        H2["springboard.x: 隐藏越狱 Bundle 信息，隔离快照"]
        H3["cfprefsd.x: 隔离插件配置，拒绝未授权读取"]
        H4["runningboardd.x: 修复允许锁定文件路径，消除 3735883980 崩溃"]
    end

    subgraph VRootLayer ["工具链与插件运行时 (vroot & libroothider)"]
        V1["libvroot: 垫片虚拟化 ~200 个 POSIX 系统调用"]
        V2["jbroot() / rootfs(): 双向物理/虚拟路径编解码"]
        V3["RootHideConfig.plist: 细粒度进程黑白名单路由"]
    end

    K1 --> K2 --> K3 --> L1
    L1 --> L2
    L2 -- "否 (黑名单/常规App)" --> L3
    L2 -- "是 (授权工具/插件)" --> L4
    L4 --> D1 --> D2 --> D3
    L4 --> H1 & H2 & H3 & H4
    D3 --> V1 --> V2 & V3

三、 动态链接器革命：@loader_path/.jbroot 与 dyldhook 劫持

在传统越狱中，所有插件与 Mach-O 工具的可执行文件头（Mach-O Load Commands）中，都硬编码着绝对依赖路径：

Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /var/jb/usr/lib/libsubstrate.dylib (offset 24)

只要这个绝对路径存在，任何依赖文件的移动都会导致程序崩溃，而固定路径的存在又天然沦为静态扫描的靶标。

Dopamine-roothide 彻底颠覆了动态库寻址机制。它将所有越狱二进制文件的依赖项 install_name 统一改造为相对寻址格式：

@loader_path/.jbroot/usr/lib/libsubstrate.dylib
@loader_path/.jbroot/Library/Frameworks/Cephei.framework/Cephei

1. dyld4 加载阶段的动态前缀重写

在 iOS 15 及更高版本中，苹果全面启用了全新重构的动态链接器 dyld4。Roothide 在 BaseBin/dyldhook/src/roothider.c 中，直接对 dyld4::Loader::expandAtLoaderPath 类静态方法实施了内核级精确挂钩：

#define ROOTHIDE_LOADER_PREFIX "@loader_path/.jbroot"

typedef struct Loader Loader;
typedef struct LoadOptions LoadOptions;
typedef struct RuntimeState RuntimeState;

// 原始 dyld4 类静态方法签名 (无 this 指针)
extern bool ORIG(_ZN5dyld46Loader18expandAtLoaderPathERNS_12RuntimeStateEPKcRKNS0_11LoadOptionsEPKS0_bPc)(
    RuntimeState* state, const char* loadPath, const LoadOptions* options, 
    const Loader* ldr, bool fromLCRPATH, char fixedPath[]);

bool HOOK(_ZN5dyld46Loader18expandAtLoaderPathERNS_12RuntimeStateEPKcRKNS0_11LoadOptionsEPKS0_bPc)(
    RuntimeState* state, const char* loadPath, const LoadOptions* options, 
    const Loader* ldr, bool fromLCRPATH, char fixedPath[])
{
    // 先让原生 dyld 尝试展开 @loader_path
    bool ret = ORIG(_ZN5dyld46Loader18expandAtLoaderPathERNS_12RuntimeStateEPKcRKNS0_11LoadOptionsEPKS0_bPc)(
        state, loadPath, options, ldr, fromLCRPATH, fixedPath);
    
    if (ret) {
        // 检测是否命中 Roothide 专有动态前缀
        if (strncmp(loadPath, ROOTHIDE_LOADER_PREFIX, sizeof(ROOTHIDE_LOADER_PREFIX) - 1) == 0)
        {
            if ((loadPath[sizeof(ROOTHIDE_LOADER_PREFIX) - 1] != '/')
             && (loadPath[sizeof(ROOTHIDE_LOADER_PREFIX) - 1] != '\0')) {
                return ret;
            }
            
            // 动态调取当前越狱运行时的随机真实路径
            char *jbroot = jbinfo_get_jbroot();
            if (jbroot) {
                // 将 @loader_path/.jbroot 瞬时拼接为真实物理路径
                strlcpy(fixedPath, jbroot, PATH_MAX);
                strlcat(fixedPath, &loadPath[sizeof(ROOTHIDE_LOADER_PREFIX) - 1], PATH_MAX);
            }
        }
    }
    return ret;
}

2. 双重容错：静态 .jbroot 符号链接机制

为了应对非 dyld4 管道、静态解析工具或调试器直接读取文件系统的场景，Roothide 的包管理器在安装每个带有 Mach-O 动态库的目录时，都会在同级目录下自动创建一个隐藏的 .jbroot 软链接，直接指向当次越狱生效的随机根目录。

通过这种设计，Mach-O 无论被放置在文件系统的何处，都不需要感知全局文件系统结构，仅仅通过 @loader_path 这一原生的相对加载原语，便能在 dyld4 的协助下平滑寻址。而系统中完全不需要存在任何像 /var/jb 这样昭告天下的全局静态入口。

四、 守护进程立体封锁：roothidehooks 的信息静默术

越狱检测不仅发生在目标 App 自身进程内部，很多高级检测 SDK 会通过 XPC 跨进程向系统服务“旁敲侧击”。Dopamine-roothide 在 BaseBin/roothidehooks 与 launchdhook 中部署了高精度的“信息消音器”。

1. launchd（PID 1）与 jbserver 的静默丢弃

在传统 Dopamine 中，launchd 承载着 jbserver 的 Mach 服务端口。若恶意应用通过 Mach IPC 向该端口发送试探消息，即使未获提权，也能通过返回的错误码或服务响应证实 jbserver 的存活。

在 BaseBin/launchdhook/src/jbserver/jbdomain_roothide.c 中，Roothide 构建了严格的调用者审计过滤：

bool roothide_domain_allowed(audit_token_t clientToken)
{
    // 高性能审计：直接根据调用的 audit_token 判断调用方是否属于黑名单进程
    if (isBlacklistedToken(&clientToken)) {
        JBLogDebug("ignore mach/xpc message from blacklisted process (%d),%s", 
                   audit_token_to_pid(clientToken), 
                   proc_get_path(audit_token_to_pid(clientToken), NULL));
        // 直接返回 false，底层 IPC 消息被彻底丢弃，不予任何应答
        return false;
    }

    return true;
}

对于未被用户主动开启越狱插件注入的常规 App，向 jbserver 发起的一切 Mach 查询如同石沉大海，没有任何端口应答特征可供利用。

2. lsd 阻断 URL Scheme 探查

许多金融应用习惯调用 [[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"sileo://"]] 来判断越狱包管理器的存在。

在 BaseBin/roothidehooks/src/lsd.x 中，Roothide 挂钩了 Launch Services 的核心决策入口：

%hook _LSCanOpenURLManager

-(void*)getIsURL:(NSURL*)url alwaysCheckable:(BOOL*)pCheckable hasHandler:(BOOL*)pHasHandler
{
    BOOL _checkable = NO;
    BOOL _hasHandler = NO;
    void* result = %orig(url, &_checkable, &_hasHandler);

    if (_checkable || _hasHandler)
    {
        NSNumber* tag = objc_getAssociatedObject(url, kBlockSchemeTagKey);
        // 如果该 URL 对应的是越狱组件（Sileo / Zebra / Filza 等）
        if (tag && tag.boolValue) {
            NSLog(@"block -[_LSCanOpenURLManager getIsURL:alwaysCheckable:hasHandler:] %@", url);
            // 强行覆写为“无处理程序”且“不可检查”
            _hasHandler = NO;
            _checkable = NO;
        }
    }

    if (pCheckable) *pCheckable = _checkable;
    if (pHasHandler) *pHasHandler = _hasHandler;
    return result;
}
%end

应用在沙盒内查询任何越狱相关的 URL Scheme，系统均会坚定地返回“该协议不存在”，彻底封堵了基于应用间调用的探测手段。

3. cfprefsd 阻断越狱配置越权嗅探

偏好设置守护进程 cfprefsd 负责全局配置分发。一些探针会尝试读取越狱插件的 plist 配置名（例如 com.rpetrich.rocketbootstrap.plist）。

在 BaseBin/roothidehooks/src/cfprefsd.x 中，Roothide 挂钩了 __CFPrefsGetPathForTriplet：

BOOL new_CFPrefsGetPathForTriplet(CFStringRef identifier, CFStringRef user, BOOL byHost, CFStringRef container, UInt8 *buffer)
{
    BOOL orig = orig_CFPrefsGetPathForTriplet(identifier, user, byHost, container, buffer);

    if (orig && buffer)
    {
        NSString* origPath = [NSString stringWithUTF8String:(char*)buffer];
        BOOL needsRedirection = preferencePlistNeedsRedirection(origPath);

        if (needsRedirection) {
            // 如果发起请求的客户端 PID 处于黑名单中（未授权的普通 App）
            if (gCurrentClientPid > 0 && jbclient_blacklist_check_pid(gCurrentClientPid) == true) {
                // 坚决拒绝重定向至 jbroot，直接阻断访问
                needsRedirection = NO;
            }
        }
        
        if (needsRedirection) {
            // 仅对越狱环境授权进程重定向至真实的 jbroot 配置路径
            const char* newpath = jbroot(origPath.UTF8String);
            if (strlen(newpath) < 1024) {
                strcpy((char*)buffer, newpath);
            } else {
                return NO;
            }
        }
    }
    return orig;
}

4. runningboardd 根治 3735883980 异常崩溃

在越狱应用通过 uicache 注册后，苹果的进程生命周期守护进程 runningboardd 会对受管进程的文件锁状态进行校验。当越狱应用持有 jbroot 下的文件句柄时，runningboardd 会因路径超出预期列表而直接抛出异常 RUNNINGBOARD 3735883980（即 0xDEAD10CC，系统判定进程在后台非法持有资源并执行终止）。

在 BaseBin/roothidehooks/src/runningboardd.x 中，Roothide 动态截获并重写了 -[RBProcess _allowedLockedFilePaths]：

NSSet<NSString*>* fixAllowedPaths(pid_t pid, NSSet<NSString*>* paths)
{
    char* procpath = proc_get_path(pid, NULL);
    if (!procpath) return paths;

    // 非越狱应用直接放行
    if (strncmp(rootfs(procpath), "/rootfs/", sizeof("/rootfs/") - 1) == 0)
        return paths;

    NSMutableSet* result = [NSMutableSet new];
    for (NSString* path in paths) {
        NSString* newPath = path;
        // 如果路径处于 rootfs 映射区，则动态转换为 jbroot 真实物理路径
        if ([rootfs(path) hasPrefix:@"/rootfs/"]) {
            newPath = jbroot(path);
        }
        char real_path[PATH_MAX] = {0};
        if (realpath(newPath.fileSystemRepresentation, real_path)) {
            [result addObject:@(real_path).stringByStandardizingPath];
        }
    }
    return result;
}

通过修正 RunningBoard 的白名单边界，彻底攻克了越狱 App 后台静默闪退的历史顽疾。

五、 POSIX 文件系统虚拟化：vroot 与编解码原语

如果完全不用 /var/jb，那么源自 Procursus 的成千上万个 GNU/Linux 开源工具（如 dpkg、apt、bash、coreutils）该如何正常运行？它们源码中普遍硬编码了 /etc、/var、/usr 等根目录假定。如果逐个去修改它们的源码，工程量将难以维系。

Roothide 给出的极简且可持续的解法是：vroot 垫片库（Shim Library）与双向路径转换 API。

sequenceDiagram
    autonumber
    actor Tool as 越狱工具/插件 (Procursus / Tweak)
    participant VRoot as libvroot 垫片层 (~200 个 POSIX API)
    participant JBRootAPI as roothide API (jbroot / rootfs)
    participant FS as 真实底层文件系统 (APFS)

    Note over Tool,VRoot: 工具按标准 UNIX 绝对路径发起操作
    Tool->>VRoot: open("/etc/apt/sources.list", O_RDONLY)
    VRoot->>JBRootAPI: 内部调用 jbroot("/etc/apt/sources.list")
    JBRootAPI-->>VRoot: 返回 "/private/preboot/<UUID>/<Hash>/etc/apt/sources.list"
    VRoot->>FS: 真实底层系统调用 open(物理路径)
    FS-->>Tool: 成功返回文件句柄 (工具完全以为自己运行在原生 UNIX 根目录下)

    Note over Tool,FS: 工具需要操作真正的 iOS 原生只读分区
    Tool->>VRoot: open("/rootfs/System/Library/CoreServices/SystemVersion.plist")
    VRoot->>FS: 穿透 "/rootfs" 符号链接，精准读写真实系统分区

1. vroot 编译期拦截

libvroot 在构建工具链时，通过宏定义和符号重写拦截了近 200 个 POSIX C 库文件操作函数（open、fopen、stat、lstat、access、opendir、chdir、getcwd、unlink 等）。它将终端工具眼中的虚拟根目录（/）强制锚定到当前的 jbroot，使得开源包完全无需任何路径代码 Patch 即可原生编译运行。

2. jbroot 与 rootfs 双向转换 API

针对开发者撰写的专属插件与应用，Roothide 在 <roothide.h> 中提供了轻量级、零开销的双向路由原语：

#include <roothide.h>

// 1. jbroot: 将基于越狱虚拟根的路径，转换为 iOS 真实物理文件系统路径
const char* physical_path = jbroot("/var/mobile/Library/Preferences/my_tweak.plist");
// 实际输出类似：/private/preboot/<UUID>/dopamine-<Random>/var/mobile/Library/Preferences/my_tweak.plist

// 2. rootfs: 将系统绝对物理路径，反向编码为虚拟 jbroot 相对路径
const char* virtual_path = rootfs(physical_path);
// 实际输出恢复为：/var/mobile/Library/Preferences/my_tweak.plist

当这套代码被用于编译传统 Rootful 或标准 Rootless 包时，roothide.h 内部的预编译宏会自动将 jbroot() 与 rootfs() 展开为空桩内联函数（Stub Macro），保持了代码基在上游与下游之间 100% 的双向源码级兼容性。

六、 进程隔离与按需放行：从全局泛洪到精确打击

传统越狱方案的最大软肋在于“默认全量注入，例外手动屏蔽”；而 Dopamine-roothide 彻底颠覆为：“默认完全隔离，按需主动放行”。

在 BaseBin/systemhook/src/roothider_common.c 中，越狱注入引擎在评估当前进程时，对普通的 App Store 应用执行了坚决的放行策略：

bool allowInjectWithSafeMode(const char* path)
{
    // 如果处于 launchd 根管理流程中
    if (getpid() != 1) {
        return true;
    }

    // 检测是否为来自 /private/var/containers/Bundle/Application/ 的用户安装 App
    if (isRemovableBundlePath(path))
    {
        // 只有带有 TrollStore 标记的特殊 App 默认允许注入
        if (hasTrollstoreMarker(path)) {
            return true;
        } else {
            // 普通 App Store 应用默认严禁注入任何 systemhook 与动态库！
            return false;
        }
    }

    // 针对系统根分区的原生进程，遵循严密的安全策略
    struct statfs fs = {0};
    if (statfs(path, &fs) == 0) {
        if (strcmp(fs.f_mntonname, "/") == 0) {
            return false;
        }
    }

    return true;
}

配合图形化的 RootHide Manager，用户在手机端可以直观管理每个 App 的状态。只有当用户明确需要对某个应用生效特定插件并在管理器中将其勾选时，Roothide 才会为其解除隔离。而对于未勾选的银行、政务、高对抗游戏：

1. 内存零污染：进程内没有任何非 App Store 签名的 dylib 被 dyld 载入；
2. 符号零 Hook：没有任何 C 库函数被 fishhook 或 litehook 挂钩；
3. 环境零异常：调用 stat("/var/jb") 必定返回 ENOENT（文件不存在）；
4. 服务零泄漏：尝试与 launchd 通信或查询越狱 URL Scheme 必定返回失败。

从信息论与安全防御的角度来看，系统对未授权应用呈现的状态，与一台从未越狱的原厂纯净 iPhone 在数学与逻辑上达到了高度等价。

七、 总结与实战复盘

在深入解构了 Dopamine-roothide 的完整实现后，我深刻体会到它对现代移动安全攻防带来的启示：

1. 摆脱“兵来将挡”的打补丁思维：
   传统防越狱检测往往陷入“检测方探测 A -> 越狱方 Hook A 返回假值 -> 检测方改用底层汇编 B 探测 -> 越狱方内核 Hook B”的疲态军备竞赛。Roothide 证明了：最顶级的防御规避不是伪造证据，而是抹去存在的物理因果。
2. 相对寻址对绝对路径的降维打击：
   从硬编码 /var/jb 到全面拥抱 @loader_path/.jbroot，Roothide 借用苹果自身动态链接器的规范，完成了动态路径的高维解耦，消除了整个越狱生态对全局文件系统单点挂载的脆弱依赖。
3. 分层立体协同的系统工程范式：
   从内核态 PAC/SPTM 漏洞利用（继承自 Dopamine 3.x 的深厚积淀），到 launchd 消息审计、dyld4 加载劫持、vroot 文件系统虚拟化，再到关键系统守护进程的针对性“消音”，Roothide 展现出了教科书级别的系统级安全架构工程水准。

对于每一位从事 iOS 移动安全、逆向工程与底层系统开发的极客而言，Dopamine-roothide 不仅是一款让越狱设备得以在严苛商业应用生态中从容穿行的利器，更是一套探索现代 Darwin 内核机制、动态链接器演进与沙盒防御前沿的无价实战范本。

原文链接与参考资料

• Roothide Dopamine 官方开源仓库：roothide/Dopamine-roothide - GitHub
• Roothide 官方开发者文档与规范：roothide/Developer - GitHub
• Dopamine 上游项目官方仓库：opa334/Dopamine - GitHub
• Roothide 官方发布站点与下载：Roothide Release Assets
• Roothide 官方 Twitter / X：@roothideDev - Twitter