始终

不忘初心

0%

iOS 越狱检测的三层纵深：一个金融 App 的攻防实录

发表于 分类于
本文字数： 8.1k 阅读时长 ≈ 15 分钟

越狱检测是 iOS 移动端安全对抗中被讨论最多、也最容易被低估的环节。多数公开方案停留在「检查几条文件路径」的层面——这类检测在生产环境中几乎不堪一击。本文以一个国内大型金融 App（下文简称「App X」）的越狱检测实现为分析对象，从防御方的视角完整还原其三层纵深防御体系：检测层、冻结层、退出层。所有结论均来自对 rootless 越狱环境（Dopamine，iOS 16.x，arm64）的实际逆向验证，每一条检测手段背后都对应着真实的攻防博弈，而非理论推演。

威胁模型

讨论检测方案之前，必须明确攻击者的能力边界。在当前主流 rootless 越狱环境下：

  • GOT rebinding（fishhook）：通过修改 __DATA segment 中的 GOT/Lazy Symbol Pointer，可拦截任何通过 PLT 调用的 C 函数。不修改函数 prologue，不触发代码签名校验。
  • MSHookFunction（CydiaSubstrate）：直接修改 C 函数 prologue 的前几条指令，插入跳转到替换函数的 trampoline。对 inline call 和 GOT call 均有效。
  • ObjC Method Swizzling：通过 method_setImplementation 或 Logos %hook 替换任意 ObjC 方法的 IMP 指针。
  • 注入时机：Tweak 在 __attribute__((constructor)) 阶段注入，早于 main() 和 UIApplicationMain。攻击者在 App 代码开始执行前就已经完成布局。

这意味着一个直接推论：任何仅依赖单一 API 返回值的检测都可以被精准拦截。有效的防御必须在多个层次形成冗余，并且——这是 App X 方案最具启发性的部分——必须在检测命中后制造攻击者难以逆转的既成事实。

第一层：检测层

文件系统探测——覆盖面决定一切

越狱环境在文件系统中留下大量 artifact。经典越狱（unc0ver、checkra1n）集中在 /Applications/Cydia.app、/usr/sbin/sshd 等路径；rootless 越狱则使用 /var/jb 作为根目录，派生出一套完全不同的路径树。

App X 维护了一份包含 40+ 路径的检测列表，覆盖经典与 rootless 两种环境：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 经典越狱路径
"/Applications/Cydia.app"
"/Library/MobileSubstrate/DynamicLibraries"
"/usr/sbin/sshd"
"/bin/bash"
"/etc/apt"

// rootless 越狱路径（Dopamine / palera1n）
"/var/jb"
"/.installed_dopamine"
"/procursus"
"/var/binpack"
"/var/checkra1n.dmg"

// 调试工具
"/usr/sbin/frida-server"
"/tmp/frida-"
"/usr/local/bin/cycript"

但路径列表只是检测内容的一半——同样重要的是检测入口的多样性。App X 同时通过以下 API 检查路径是否存在：

API 层级 特征
stat / lstat / access libc 最基础的文件存在性检查
open / fopen libc 尝试打开文件
opendir / readdir libc 目录枚举
realpath / readlink libc 符号链接解析
NSFileManager fileExistsAtPath: Foundation ObjC 封装
syscall(SYS_stat64, ...) 系统调用包装 绕过 libc 函数级 Hook

最后一项值得展开。syscall() 是一个通用的系统调用包装函数——它不经过 libc 中各个具名函数的实现，直接通过系统调用号发起内核请求：

1
2
3
4
int result = syscall(SYS_stat64, "/var/jb", &st);
if (result == 0) {
    // 越狱文件存在——即使 stat() 函数本身已被 Hook
}

攻击者如果只 Hook 了 stat()，这条检测仍然能命中。要绕过它，攻击者必须额外 Hook syscall() 并在内部解析第一个参数（系统调用号），针对 SYS_stat64、SYS_access、SYS_open 分别处理。这显著增加了攻击者的工作量和出错概率。

更激进的做法：使用 inline assembly 直接执行 svc #0x80 指令。这种方式连 syscall() 的 GOT 入口都绕过了，是当前已知最难被用户态 Hook 拦截的检测手段。App X 的 SecureUtilityPlus 框架中存在这类 inline SVC 检测——经逆向确认，攻击者无法通过 GOT rebinding 或 MSHookFunction 将其拦截。

环境变量与进程信息

注入框架在进程中留下的痕迹不只是文件：

1
2
3
4
// 环境变量检查
const char *env = getenv("DYLD_INSERT_LIBRARIES");
if (env != NULL) return YES;
// 同时检查 DYLD_LIBRARY_PATH, DYLD_FRAMEWORK_PATH, _MSSafeMode, _SafeMode

App X 同时通过 C 层 getenv() 和 ObjC 层 NSProcessInfo.environment 两个入口检查——两条路径的底层实现不同，攻击者必须同时覆盖。

动态库枚举

通过 dyld API 枚举当前进程加载的动态库镜像：

1
2
3
4
5
6
7
8
uint32_t count = _dyld_image_count();
for (uint32_t i = 0; i < count; i++) {
    const char *name = _dyld_get_image_name(i);
    if (strstr(name, "substrate") || strstr(name, "TweakInject") ||
        strstr(name, "ellekit") || strstr(name, "frida")) {
        return YES;
    }
}

这里存在一个攻击者容易犯的一致性错误：如果攻击者过滤了 _dyld_get_image_name 的返回值（隐藏注入 dylib 名称）但没有同步调整 _dyld_image_count 的返回值，或者没有同步处理 _dyld_get_image_header 和 _dyld_get_image_vmaddr_slide，那么这些 API 返回的数据之间就会产生不一致——image count 与实际可枚举数量不匹配本身就是一个检测信号。

防御建议：在不同时机多次调用 dyld 系列 API，对比 count 是否随时间突变、是否存在 index 空洞、count 与 header 数量是否一致。

URL Scheme 与文件系统可写性

1
2
3
4
5
6
7
8
// URL Scheme 探测
NSArray *schemes = @[@"cydia://", @"sileo://", @"zbra://",
                     @"filza://", @"undecimus://", @"activator://"];
for (NSString *s in schemes) {
    if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:s]]) {
        return YES;
    }
}
1
2
3
4
5
6
7
// 文件系统可写性检查
struct statfs fs;
statfs("/", &fs);
if (!(fs.f_flags & MNT_RDONLY)) {
    // 根文件系统可写——正常 iOS 设备不应出现此情况
    return YES;
}

这两类检测验证的信息来源与文件路径完全不同——前者检查系统注册的 URL handler，后者检查文件系统挂载属性。攻击者需要额外 Hook canOpenURL: 和 statfs 并伪造返回值。

反调试

1
2
3
4
5
6
7
static BOOL isBeingDebugged(void) {
    int name[4] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, getpid()};
    struct kinfo_proc info = {};
    size_t size = sizeof(info);
    sysctl(name, 4, &info, &size, NULL, 0);
    return (info.kp_proc.p_flag & P_TRACED) != 0;
}

App X 的 DebuggerChecker 检测 P_TRACED 标志位。攻击者需要 Hook sysctl 并在结果中清除该标志。此外，App X 还检查了 security.mac.amfi.developer_mode_status——这是 iOS 16+ 开发者模式的状态标志，越狱设备上通常为启用状态。

安全框架：SecureUtilityPlus

上述所有检测手段并非散落在业务代码中，而是被组织在一个名为 SecureUtilityPlus 的安全框架内——这是一个 Swift 编写的模块化检测引擎，包含以下 Checker 类：

Checker 职责
JailbreakChecker 文件路径 + URL Scheme + 环境变量
FileChecker 深度文件系统探测
MSHookFunctionChecker 检测函数 prologue 篡改
FishHookChecker 检测 GOT 修改
RuntimeHookChecker 检测 ObjC 方法 Swizzling
ReverseEngineeringToolsChecker Frida / Cycript / lldb 检测
EmulatorChecker 模拟器环境检测
DebuggerChecker 调试器 attach 检测
IntegrityChecker 代码完整性校验
ProxyChecker 网络代理检测
CheckAllCall 聚合入口，在业务节点统一触发

其中 MSHookFunctionChecker 的存在对攻击者产生了重大的「工具选择约束」——它检查 C 函数 prologue 的前几字节是否被修改为 trampoline 跳转模式（LDR Xn, #offset; BR Xn）。一旦检测到，直接设置无效回调地址并通过 dispatch queue 执行跳转，触发 crash。

这迫使攻击者放弃 MSHookFunction——当前最通用的 C 函数 Hook 框架——转而使用 fishhook。而 fishhook 只能 Hook 通过 GOT 调用的函数，对模块内部的 inline call 无效。这种「限制攻击者工具选择」的策略比单纯「检测越狱特征」更具战略价值。

业务层状态分散

App X 不将越狱判定集中在一个布尔值中，而是将检测结果散布在超过 15 个属性和方法中：

1
2
3
isJailBreak, phoneIsJailBreak, isJailBrokenOne, isJailBrokenThree,
isJailBrokenFour, isJailBrokenFive, p_isJailBreak1, p_isJailBreak2,
MaxentJailBroken, jailbroken, jailbreaking, isJailbroken ...

并通过 authorityWithJailBreakFlag: 将标记传递给权限系统，在网络请求、页面跳转、登录等业务节点反复读取。攻击者需要通过全类遍历（objc_copyClassList）逐一找到并替换每个方法实现——遗漏任何一个都会导致业务异常或触发退出。

第二层：冻结层

如果说检测层回答的是「是否越狱」，那么冻结层回答的是「检测命中后如何让 App 变得不可用而不是简单退出」。这是 App X 方案中最具创新性的部分。

持续性冻结循环

当 inline SVC 检测到越狱文件后，App X 不是调用 exit() 退出——而是启动一个持续运行的冻结循环，以极高频率（30 秒内 14,000+ 次调用）执行以下操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 阻塞主线程（~470 次/秒）
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);

// 禁用动画（~166 次/秒）
[UIView setAnimationsEnabled:NO];

// 忽略触摸事件
[[UIApplication sharedApplication] beginIgnoringInteractionEvents];

// 禁用交互
view.userInteractionEnabled = NO;

// 移除所有动画
[layer removeAllAnimations];

这种设计的精妙之处在于：

  1. 冗余覆盖：5 种不同的冻结手段并行执行。即使攻击者 Hook 了其中 3 种，剩余 2 种仍然足以让 App 不可交互。
  2. 持续对抗：这不是一次性调用，而是一个永久运行的循环。攻击者不能「在启动时绕过一次就结束」——必须持续对抗每一次冻结尝试。
  3. 高频淹没：每秒数百次的调用频率意味着攻击者的拦截逻辑同样需要执行数百次。任何性能问题都会被放大。

dispatch_semaphore_wait 作为主武器

冻结循环的核心武器是 dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER)——在主线程上调用它会无限期阻塞主线程，使 RunLoop 停止调度事件。

为什么选择 semaphore 而非 sleep() 或 NSThread sleepForTimeInterval:？因为 semaphore 的阻塞发生在内核层面（mach_msg trap），从调用栈上看与正常的 GCD 同步操作难以区分。而 sleep() 的意图过于明显，更容易被针对性拦截。

时间门控

冻结循环中的 UI 冻结调用（setAnimationsEnabled:NO、removeAllAnimations 等）使用了一个巧妙的时间门控——前 3 秒允许正常执行：

1
2
3
4
5
6
// App 自身在启动阶段可能合法调用 setAnimationsEnabled:NO
// 3 秒后才是冻结循环的恶意调用
CFAbsoluteTime elapsed = CFAbsoluteTimeGetCurrent() - launchTime;
if (elapsed > 3.0) {
    // 此时的调用来自冻结循环——执行冻结
}

这增加了攻击者的区分难度：简单地「Hook 所有 setAnimationsEnabled:NO 调用使其无效」会破坏 App 自身的启动动画逻辑。攻击者必须实现与 App 相同的时间门控，或者找到其他区分合法调用与恶意调用的方式。

第三层：退出层

冻结层之外，App X 还部署了弹窗退出作为 fallback 机制。

弹窗 + exit 组合

1
2
3
4
5
6
7
8
9
10
UIAlertController *alert = [UIAlertController
    alertControllerWithTitle:@"安全提示"
    message:@"您的设备环境存在隐私信息泄露风险..."
    preferredStyle:UIAlertControllerStyleAlert];
[alert addAction:[UIAlertAction actionWithTitle:@"确定"
    style:UIAlertActionStyleCancel
    handler:^(UIAlertAction *action) {
        exit(0);
    }]];
[rootVC presentViewController:alert animated:YES completion:nil];

弹窗的 action handler 中调用 exit(0)——这构成了独立于冻结层的第二条退出路径。攻击者需要同时做到：

  1. 拦截 presentViewController:animated:completion: 阻止弹窗展示
  2. 确保即使弹窗展示了，handler 中的 exit() 也不会被执行
  3. 识别哪些弹窗是安全相关的（不能拦截所有弹窗——否则正常业务弹窗也会消失）

App X 使用了两个安全弹窗——「安全提示」和「风险提示」——文案中包含「越狱」「风险」「设备」「异常」等关键字。攻击者可以基于关键字匹配来识别安全弹窗，但这种方法在 App 变更文案时会失效。

showJailBrokenAlertIfNeeded 的隐蔽触发

除了直接构造 UIAlertController，App X 还在多个业务类中实现了 showJailBrokenAlertIfNeeded 方法。这些方法散布在不同模块中，在不同时机被调用——攻击者需要通过全类遍历找到所有包含该 selector 的类并逐一替换。

三层联动的设计哲学

App X 的方案之所以有效，不在于任何单一层次的强度，而在于三层之间的联动关系：

不信任任何单一 API

检测层使用了 7 种不同的文件 API + syscall 包装 + inline SVC。即使攻击者 Hook 了 6 种，第 7 种仍然能触发冻结。

检测与响应分离

检测模块（SecureUtilityPlus 各 Checker）只负责设置状态标记。冻结循环和弹窗退出是独立的响应模块，各自读取状态并执行。这意味着攻击者不能通过 Hook 单个检测函数返回 NO 就同时绕过检测和响应——响应可能已经被触发了。

Hook 框架检测作为 force multiplier

MSHookFunctionChecker 不直接检测越狱，但它限制了攻击者的工具选择。被迫使用 fishhook 的攻击者无法拦截 inline call 和直接函数调用，这为 inline SVC 检测创造了不可绕过的锚点。

高频持续 vs. 一次性

冻结循环是永久运行的——这与「启动时检测一次」的方案形成本质区别。即使攻击者在 constructor 阶段成功绕过了所有检测，冻结循环仍然在持续执行。攻击者必须同时对抗检测绕过和冻结解除两个独立问题。

成本不对称

防御方成本 攻击方成本
添加一条路径到检测列表 逆向发现 + 添加到过滤列表
添加一种冻结手段 识别 + Hook + 验证不影响正常功能
变更弹窗文案 重新逆向 + 更新关键字匹配
添加新的 Checker 类 全类遍历 + 匹配 + 替换

防御方的每一次小改动都迫使攻击者重新逆向和适配。这种不对称性是纵深防御的核心经济学。

小结

App X 的越狱检测方案展示了一个重要的设计理念：有效的越狱检测不是一个「判断题」（是否越狱），而是一个「持续对抗系统」。三层防御——检测命中后不是简单退出，而是通过高频冻结循环制造不可逆的 UI 死亡状态，再辅以弹窗退出作为 fallback——构成了一个攻击者必须同时解决多个独立问题才能突破的体系。

对于移动安全防御方而言，最核心的 takeaway 是：把对抗成本从「检测准确性」转移到「响应不可逆性」。检测总会被绕过——在 root 权限面前没有绝对不可绕过的用户态检测。但响应机制的设计可以让绕过变得极其昂贵：攻击者不仅要绕过检测，还要逆转已经触发的冻结循环、拦截持续涌来的 semaphore wait、处理散布在十几个类中的退出入口。当绕过成本持续上升并超过攻击者愿意投入的阈值时，纵深防御的目标就达成了。

俗话说，投资效率是最好的投资。 如果您感觉我的文章质量不错，读后收获很大，预计能为您提高 10% 的工作效率，不妨小额捐助我一下，让我有动力继续写出更多好文章。