AI绕过ios越狱检测

admin
admin
admin
0
文章
0
评论
2026-05-11 07:32:31 网络安全文章 来源：ZONE.CI 全球网 0 阅读模式

文章总结： 该文档记录了在iOS16越狱环境下绕过FanDuel应用越狱检测的全过程。通过静态分析识别反欺诈SDK（GeoComply、Sift、Incognia）和自建检测模块，动态调试发现进程终止源于初始化阶段主动调用Objective-C方法导致的死锁。最终方案采用被动Hook替代主动调用、延时加载检测模块、替换dyld镜像名等组合措施，实现60秒稳定运行。关键发现包括：避免spawn-gated期间调用OC方法、递归替换dyld函数会导致栈溢出、需区分检测上报与主动终止逻辑。 综合评分： 87 文章分类： 移动安全,逆向分析,免杀,红队,安全工具

cover_image

AI 绕过 ios 越狱检测

zhuzhu_biu zhuzhu_biu

看雪学苑

2026年5月9日 17:59 上海

在小说阅读器读本章

去阅读

目标：让com.fanduel.sportsbook在 palera1n rootless 越狱 (iOS 16 / arm64) 的 iPhone 上能通过 Frida spawn/attach 且不被越狱检测杀进程。

#

结果：60+ 秒稳定存活；绕过方案共三件组合修复，脚本不到 50 行有效逻辑。

1.目标与环境

对照实验结论：这是FanDuel 专属的越狱检测，不是 frida/device 侧故障。

2.静态分析阶段：先看二进制里有什么

通过 IDA MCP（server_health返回module: SportsbookWrapper, imagebase: 0x100000000, hexrays_ready: true）直接在 IDA 里查询。

2.1 用func_query/regex 找 JB 相关函数名

命中：

  • +[AppsFlyerUtils isJailbrokenWithSkipAdvancedJailbreakValidation:]

    @0x101c1efe0

  • -[AppsFlyerLib skipAdvancedJailbreakValidation]

    @0x101c1ce30

  • -[AFSDKChecksum calculateV2ValueWithTimestamp:...isJailBroken:...]

2.2 反编译 AppsFlyer 的 JB 判定

+[AppsFlyerUtils isJailbrokenWithSkipAdvancedJailbreakValidation:]:
  v21[0..20] = @[
      @"/Applications/Cydia.app",
      @"/Applications/blackra1n.app", ...
      @"/Library/MobileSubstrate/DynamicLibraries/LiveClock.plist",
      @"/private/var/lib/apt", ...
      @"/usr/sbin/sshd"
  ];
for p in v21: if [NSFileManager fileExistsAtPath:p] return YES;
  ...
  // 再做 dladdr(class_getMethodImplementation(NSFileManager, @selector(fileExistsAtPath:)))
  // 对比是否在 Foundation.framework 里（检测 IMP 有没有被 swizzle）

结论：AppsFlyer 的 JB 判定不会杀进程，只是把结果塞给归因上报。不是这次的元凶。

#

2.3 用find(type=string)扫 JB 相关字串

/Applications/Cydia.app   → 1 hit (AppsFlyer 列表内)
/usr/sbin/sshd            → 1 hit
MobileSubstrate           → 3 hits
Jailbreak/Jailbroken      → 8 hits 总计

交叉引用回去：

  • 0x102a8e340 / 0x102a8e5c0 / 0x102a8e500

    都被 AppsFlyer 引用；

  • 0x10218c27e "MobileSubstrate"

    在sub_1017FC3A0（Sentry KSCrash 设备信息收集器）里，同样只是日志字段不杀。

2.4 扫更激进的 RASP 关键字

frida, Frida, FRIDA                 → 0 hits
cynject, libhooker, libsubstitute   → 0 hits
DYLD_INSERT_LIBRARIES                → 0 hits
PT_DENY_ATTACH                       → 0 hits
GeoComply                            → 30+ hits  ✓
Sift                                 → 60+ hits  ✓
IncdOnboarding (Incognia)            → 有        ✓
PredictsFraudMonitorPlugin           → 1 hit     ✓ (FanDuel 自建)

发现的反欺诈栈：GeoComply（地理围栏 + RASP）、Sift Science（行为反欺诈）、Incognia（设备指纹）、PredictsFraudMonitor（自建）。静态字串都不像会直接abort，而是做数据上报。

2.5 扫exit / _exit / abort / ptrace

imports:
  _exit                 → libSystem.B.dylib       ✓
  _sysctl/_sysctlbyname → libSystem.B.dylib       ✓
  _task_info            → libSystem.B.dylib       ✓
  _getppid              → libSystem.B.dylib       ✓
  __dyld_get_image_header → libSystem.B.dylib     ✓
  ptrace                → NOT imported            ✗
  csops                 → NOT imported            ✗

xrefs 追_exit的 3 个 code 调用点全在 Firebase Crashlytics（mach exception server / signal handler）内部 —— 都是崩溃处理走的路径，非主动杀。

2.6 找直接 syscall（svc #0x80）

find_bytes pattern=01 10 00 D4     → 6 matches

6 条 match 全部不是 4 字节对齐，都落在__gcc_except_tab等数据段的字节序巧合 —— 假阳性。二进制里没有直接绕 libc 的 syscall 调用。

2.7 扫__init_offsets（iOS 16 新版 init 段）

用py_eval在 IDA 里读 segment，0x102066a00..0x102066bc8，一共 114 个初始化函数指针。逐个检查最前的几个：

sub_10000400C: objc_opt_class(&BetTracker); +[RNCasinoGameInfoViewContainerManager load]_0(...)
sub_1000040A0: objc_opt_class(&TimestampModuleBridge); ...
// 所有 entry 都是这种 RN module 注册 stub，没有 RASP 检测

阶段结论：静态看不到明显的”调_exit的 JB 判定”。真正的杀必然在三方 SDK（GeoComply / Incognia / Sift）内部，或者走非常规路径。得上动态。

#

3. 第一次动态绕过尝试：全面但翻车

3.1 最初脚本（v1）

覆盖所有经典 JB 检测面：

  • Objective-C：NSFileManager fileExistsAtPath:/UIApplication canOpenURL:/ AppsFlyer JB 接口重写
  • libc：stat / lstat / access / open / openat / fopen / ... / statfs
  • dyld 隐身：getenv("DYLD_INSERT_LIBRARIES")、dlopen/dlsym过滤、_dyld_image_count+_dyld_get_image_namereplace 重写
  • 反反调试：ptraceno-op、sysctl KERN_PROC_PID清P_TRACED
  • GeoComply 启发式扫描（GC*/Solus*前缀的类全 hook）
  • Crashlytics / Sentry 的isBeingTraced改 NO

启动命令：

frida -H 127.0.0.1 -f com.fanduel.sportsbook -l bypass.js --runtime=v8

3.2 结果

Connectedto127.0.0.1 ([email protected])
Failedtoloadscript: theconnectionisclosed

脚本根本没装上，frida-agent 的 IPC 就断了。排查两个嫌疑：

  • --runtime=v8

    在 iOS 16 + palera1n 上可能 JIT 失败。

  • 我对_dyld_image_count做了Interceptor.replace，replacement 里又调new NativeFunction(imgCount, ...)调回原符号 ——这是自递归，因为replace之后该地址已经指向我们的 trampoline。栈溢出直接让 agent 死。

3.3 修复

  • 换成默认 QJS runtime；
  • 不 replace 整个 dyld API，改成Interceptor.attach在onLeave里把被挑出的 image name 指针就地替换为/usr/lib/system/libsystem_pthread.dylib这种无害字符串。

4. 故障定位：script 根本没加载成功

4.1 先证明”chain 本身没坏”

写最小脚本test_min.js：

console.log('[MIN] script loaded');
console.log('[MIN] process : ' + Process.id + ' ' + Process.arch);
console.log('[MIN] main    : ' + Process.mainModule.name + ' base=' + Process.mainModule.base);

用默认 runtime 跑：

[MIN] script loaded
[MIN] process : 51969 arm64
[MIN] main    : SportsbookWrapper base=0x10029c000
[MIN] objc    : true
[MIN] runtime : QJS
Spawned `com.fanduel.sportsbook`. Resuming main thread!

脚本能装。所以之前是 v8 的问题。弃用--runtime=v8。

4.2 逐段加 hook，找出是哪段把 agent 搞崩

把脚本分成 1→2→…→N 个 section，每段跑完打ok(...)标志。

[JB-BYPASS] + NSFileManager hooks installed
[JB-BYPASS] + UIApplication canOpenURL hook installed
[JB-BYPASS] + +[AppsFlyerUtils isJailbrokenWith...] -> NO
Failed to load script: the connection is closed        ← 死在这里

下一段是：

const inst = lib.shared();   // 在 spawn-gated 状态下主动调用 +[AppsFlyerLib shared]
inst.setSkipAdvancedJailbreakValidation_(1);

Spawn-gated 期间主动调 OC 方法触发 AppsFlyer 内部 init 副作用（可能要 dispatch 到主线程，但主线程还冻着），直接死锁/崩溃。

修复：永远不在 bypass 阶段”主动调”OC，只”被动 hook”。把 setter 调用换成 hook-[AppsFlyerLib skipAdvancedJailbreakValidation]的 getter，永远返回 YES：

Interceptor.attach(lib['- skipAdvancedJailbreakValidation'].implementation,
    { onLeave(r) { r.replace(ptr(1)); } });

然后继续，下一段hookGeoComply()里Object.keys(ObjC.classes)全扫（2 万+ 类），太慢，同样把 agent 拖超时。改成setTimeout(hookGeoComply, 400)延后到 resume 后再扫。

5. 走对路径后的第一次”看见进程启动”

此时 hook 能全部装上：

[JB-BYPASS] + bypass ready
[HB] heartbeat armed
Spawned `com.fanduel.sportsbook`. Resuming main thread!

但用 Python 宿主run.py跑监控循环，结果：

[!] session detached: process-terminated crash=None
[=] alive for 0.0s (dead=True)

进程在 resume 后立刻死，仍然是 0 秒。且crash=None表示是”干净终止”而不是崩溃。

6. 误判与纠偏：进程并不是被”外部杀”的

6.1 noexit 实验（错误版）

假设：既然 hook 全装了 JB 还被杀 → 一定是别的信号。

尝试noexit.js：把exit / _exit / abort / raise / kill / pthread_kill / __cxa_throw / objc_terminate / ...一股脑用Interceptor.replace(p, new NativeCallback(()=>0, 'int', []))全 no-op 化。

结果：进程还是 0 秒死，而且[NOEXIT] sym called一条都没打。

当时的错误结论：既然所有 exit 原语都被替换为 no-op 还立刻死，杀进程肯定走的是 mach 级（task_terminate）或者 SIGKILL。

6.2 进一步对照证据（加深了错判）

  • 对照组

    用spawn_only.py只device.spawn后device.resume，不 attach 任何 session → 进程 0.6s 死。

  • msgSend 全量追踪

    能抓到 1633 次objc_msgSend，全是 Foundation + Apple Vision framework 初始化；没一次落到 FanDuel 自己的+load。

  • 其他 app 对照

    Lamoda / Winpot Casino / App Store / Safari同设备同 frida spawn 全部正常。

这一串证据把我往”外部 SIGKILL / launchd entitlement 拒绝”方向带偏了，写了一大段总结放弃 Frida 路线建议用 Substrate tweak。

6.3 关键误判点

后来才明白：Interceptor.replace(exit_like, ()=>0)替换一个 noreturn 函数是错的。exit/abort被编译器标记__attribute__((noreturn))，调用点后面不保留合法返回路径（常常编译成BL abort; UDF #0或者直接接下一个 basic block 的其他代码）。我们的 no-op “return 0” 让执行 flow 穿透到了垃圾指令，下一步走SIGILL，看起来就像”立刻死”。

所以当时看到的现象是我们的 hook 自己把进程搞死的，跟 RASP 没关系。但我当时没反应过来。

7. 用户关键提醒：”frida 先执行”

用户贴了 terminal 给我：

frida-H127.0.0.1-fcom.fanduel.sportsbook-l .\empty.js-olog.txt
...
Connectedto127.0.0.1 ([email protected])
Spawning `com.fanduel.sportsbook`...
[EMPTY]nohooksinstalled         ← 脚本在 resume 之前就输出了
Spawned `com.fanduel.sportsbook`. Resumingmainthread!
[Remote::com.fanduel.sportsbook ]-> Processterminated

并断言”这里 frida 先执行，是可以绕过检测的”。

这句提醒是整个会话的转折点。它意味着：

  • 脚本在Spawned ... Resuming main thread!之前就 print 出来了 —— 说明 spawn-gated 时机 OK，hook 确实能在 app 任何指令之前装好；
  • 之前的noexit.js之所以失败不是因为”外部 SIGKILL”，而是我用错了Interceptor.replace处理 noreturn 函数。

于是回到 Frida 正途。

8. 再次对照：发现真正的 kill 通道是 libc abort()

8.1 重写为最小异常处理器exception_only.js

纯粹只装Process.setExceptionHandler，不装任何 hook。看看纯净状态下啥异常会触发。

Process.setExceptionHandler(function (d) {
console.log('[EXC] ' + d.type + ' at ' + d.address);
    d.context.pc = d.context.pc.add(4);   // 跳过当前指令继续跑
return true;
});

结果：

[*] resumed
[EXC#1] abort at 0x1f98c7198
[EXC#2] abort at 0x1f98c7198
[=] DIED at 0.58s

只有 2 次 abort，地址0x1f98c7198是 libc 的abort函数入口。之前 noexit 实验里看到的0x2a0184080这种 “illegal-instruction” 都不存在于 baseline —— 全部是我们自己Interceptor.replace引起的副作用（Frida Gum 的半成品 trampoline）。

8.2 修复 abort 拦截（正确版）

不用Interceptor.replace改写 abort 代码页，而是Interceptor.attach+onEnter里Thread.sleep(永远)：

Interceptor.attach(abort_addr, {
onEnter(args) {
log('BLOCKED abort; bt: ...');
while (true) Thread.sleep(3600);   // 调用线程永久 park
    }
});

  • 不改写原函数头部

    不会污染 Apple 任何通过函数指针调 abort 的路径；

  • onEnter 永不返回

    等同于 abort 从未被调用；

  • 原函数体根本进不去，抽象效果同”彻底 no-op”。

8.3 立刻看到 RASP 探测

重跑：

[JB]blockaccess /cores/.safe_mode
[JB]blockaccess /var/jb/usr/lib/TweakLoader.dylib
[JB]blockaccess /var/jb/usr/lib/TweakInject.dylib
[JB]BLOCKEDabortfrom: +[_NSPredicateUtilities _predicateSecurityAction] ...
[=]DIEDat21.43s

解读：

  • FanDuel 早期用access(path, W_OK)探测 3 条路径。前两条（/var/jb/usr/lib/Tweak*.dylib）是palera1n rootless 的 tweak 注入器，存在 = 越狱；
  • 我们的accesshook 把它们 block 成 -1 / ENOENT，RASP 看起来没检测到越狱；
  • 但进程仍然走到了abort，调用点在 AppleFoundation!+[_NSPredicateUtilities _predicateSecurityAction]；
  • abort 被我们的trapAndPark接住 → 线程 park → dyld 初始化永远完不成 → 20s 后 launchd watchdog 杀进程（”DIED at 21.43s”）。

#

9. 抓栈：看见_predicateSecurityAction的真面目

backtrace 指向非常明确的调用链：

0x1b891190c  Foundation!+[_NSPredicateUtilities _predicateSecurityAction]     ← abort()
0x1b8429fe4  Foundation!-[NSFunctionExpression  expressionValueWithObject:context:]
0x1b889fbac  Foundation!-[NSKeyPathExpression   expressionValueWithObject:context:]
0x1b8429d90  Foundation!-[NSComparisonPredicate evaluateWithObject:substitutionVariables:]
0x1b84299c0  Foundation!_filterObjectsUsingPredicate
0x1b84c4a84  Foundation!-[NSArray(NSPredicateSupport) filteredArrayUsingPredicate:]
0x1082c6bec  ServiceCore!initialize_framework_bundles
0x10373c42c  dyld!dyld4::Loader::findAndRunAllInitializers
0x105a50444  dyld!dyld4::Loader::runInitializersBottomUp

重点：

  • _NSPredicateUtilities _predicateSecurityAction

    是Apple 在 iOS 16 引入的 NSPredicate 安全动作。当NSFunctionExpression或NSKeyPathExpression被要求 evaluate 一个它认为 “可能用 KVC 调危险方法” 的表达式时，它调这个方法abort()整个进程（CVE 防护机制）。

  • 调用上下文是ServiceCore!initialize_framework_bundles，它在 dyld 初始化阶段用NSArray filteredArrayUsingPredicate:过滤所有已加载 framework 的 bundle 元数据。

  • 这条 abort 不是 FanDuel 自己发起的

    是 FanDuel 的 RASP 发现越狱后，把”看起来越狱”的信号塞到某个 framework bundle 的元数据里，让 Apple 自家的 predicate evaluation 命中 security-action 分支 ——“借刀杀人”式越狱检测，从调用栈看像 Apple 原生行为，非常隐蔽。

这一步彻底改写了”这是什么检测”的理解：之前以为是第三方 RASP 直接 exit，实际是通过 Apple 内部机制间接 abort。

10. 又踩一个坑：Interceptor.replace半改写 Apple 代码

在第 8 步做 noexit 和前期迭代时还看到过illegal-instruction at 0x2a01...XXXX，总以为是 RASP 埋的 BRK trap。

其实：

  • Interceptor.replace

    会在目标函数首几条指令写一个B跳到 Gum 生成的 trampoline；

  • trampoline 里为了”调用原函数再 hook”，会复制原函数的头部 + 修正 PC 相对引用（比如ADR）；

  • 对 arm64 PAC / 共享库里经过代码签名校验 / 其他 app 缓存了函数指针这种 corner case，这个复制可能半成品化，表现为运行到 trampoline 时撞上非法编码；

  • 用户态Process.setExceptionHandler把 PC+4 跳过以后确实能继续走几条，但之后很快又撞另一个异常，循环几十秒直到 launchd watchdog 把进程杀了。

规律总结：

  • Interceptor.attach

    = 软 hook，不改写目标指令，只在 prologue 插入桥跳到我们 cb，cb 返回后原函数正常执行。安全。

  • Interceptor.replace

    = 硬替换，重写目标。对于 exit / abort / __cxa_throw / __stack_chk_fail 这类编译器假设不会 return 的 noreturn 函数，用起来会让 caller 跑到不保留合法指令的 “dead code”；对于 Apple 缓存了函数指针的 libc / CoreFoundation 路径，也可能落到半成品 trampoline。能attach就不要replace。

对 exit 家族全换用 attach +Thread.sleep(∞)后，illegal-instruction再没出现过。

另一个踩坑：我用isRaspProbe()路径前缀过滤时把：

  • /private/preboot/

    当成 JB 路径（实际是 iOS 16 的 Cryptex 系统库路径，里面有 Safari / WebKit / AuthenticationServices 等）

  • /cores/

    前缀（实际里面有.dSYM/Contents/Resources/DWARF/dyld让 CFBundle 找 debug symbol）

拦了以后 NSBundle 一走到这两类路径就 bug，又触发_predicateSecurityActionabort（更隐晦的版本）。修复：

  • 删掉/private/preboot/前缀；
  • 精确 match/cores/.safe_mode这一条，不整块拦/cores/。

11. ObjC 私有类的定位手艺

定位到 kill 在+[_NSPredicateUtilities _predicateSecurityAction]。要 hook 它，踩了 4 种方法的坑才找到对路的：

11.1~~ObjC.classes._NSPredicateUtilities~~

ObjC.classes._NSPredicateUtilities// 报错或 undefined
Object.keys(ObjC.classes).includes('_NSPredicateUtilities')   // false

Frida 的ObjC.classes是 Proxy，下划线前缀的私有类不被枚举。直接 get 也容易拿到 undefined（对 JS Proxy 来说，cls === undefined时继续访问.$ownMethods直接 TypeError）。

#

11.2~~Module.findModuleByName('Foundation').enumerateSymbols()~~

扫 Foundation 的 47060 个符号，没有一个包含_predicateSecurityAction。因为它是 ObjC class-method IMP，不是通过 nlist 导出的 C 符号。

#

11.3~~DebugSymbol.fromName('+[_NSPredicateUtilities _predicateSecurityAction]')~~

Frida 能在 backtrace 里解析出这个符号名，所以理论上DebugSymbol.fromName应该也能。但fromName会全盘扫所有已加载模块的符号（47k Foundation + 所有其它模块），加上 ObjC runtime 反查，足够久让 agent load 超时，直接TransportError: connection closed。

#

11.4 ✓ Runtime C API 直调

最后用最基础的 ObjC runtime C API：

const lookUp = new NativeFunction(
    Module.findExportByName(null, 'objc_lookUpClass'),
'pointer', ['pointer']);
const sel_registerName = new NativeFunction(
    Module.findExportByName(null, 'sel_registerName'),
'pointer', ['pointer']);
const class_getInstanceMethod = new NativeFunction(
    Module.findExportByName(null, 'class_getInstanceMethod'),
'pointer', ['pointer', 'pointer']);
const method_getImplementation = new NativeFunction(
    Module.findExportByName(null, 'method_getImplementation'),
'pointer', ['pointer']);

const cls = lookUp(Memory.allocUtf8String('_NSPredicateUtilities'));  // ✓ 找到了

但是：

const method = class_getClassMethod(cls, sel_registerName(...'_predicateSecurityAction'...));
// method.isNull() === true    ← 取不到

+方法要从 metaclass 查，但这个类的_predicateSecurityAction很可能并没有注册成标准 class method（或被隐藏）。

#

11.5 ✓✓ 终极方案：上移一层，hook caller

既然目标 IMP 找不到，那就 hook调它的那个人：-[NSComparisonPredicate evaluateWithObject:substitutionVariables:]。这个方法是公开的 instance method，用同样的 runtime API 立刻拿到：

const cls = lookUp(Memory.allocUtf8String('NSComparisonPredicate'));
const sel = sel_registerName(Memory.allocUtf8String('evaluateWithObject:substitutionVariables:'));
const method = class_getInstanceMethod(cls, sel);
const imp = method_getImplementation(method);
Interceptor.replace(imp, new NativeCallback(function(self, _sel, obj, vars) {
return 0;     // NO - predicate 永远不匹配
}, 'bool', ['pointer', 'pointer', 'pointer', 'pointer']));

强制 predicate evaluate 返回 NO →_filterObjectsUsingPredicate拿到空数组 →NSKeyPathExpression/NSFunctionExpression根本不被求值→_predicateSecurityAction从源头就到不了。

12. 最终突破：短路 NSComparisonPredicate

跑起来：

[JB]terminationprimitivestrapped
[JB]RASPpathprobesblocked
[JB]-[NSComparisonPredicate evaluateWithObject:substitutionVariables:]-> NO @ 0x1b8429c88
[JB]FINALbypassarmed
[*]resumed
[JB]blockaccess /cores/.safe_mode
[JB]blockaccess /var/jb/usr/lib/TweakLoader.dylib
[JB]blockaccess /var/jb/usr/lib/TweakInject.dylib
[=]ALIVEafter60.0s  ---BYPASSSUCCEEDED

60 秒稳定存活，BLOCKED abort一次也没触发。搞定。

13. 完整绕过方案（生产脚本）

bypass.js核心三件事，总共 3 个代码块，约 50 行有效逻辑：

13.1 Trap abort 家族（保险丝）

function trapAndPark(sym) {
const p = Module.findExportByName(null, sym);
if (!p) return;
Interceptor.attach(p, {
onEnter(args) {
log('BLOCKED ' + sym);
// Thread.sleep 永久 park 当前线程；不 return，不改写原函数
while (true) Thread.sleep(3600);
        }
    });
}
['exit', '_exit', '_Exit', 'abort', 'abort_with_reason', 'abort_with_payload',
'raise', 'pthread_kill', 'pthread_exit'].forEach(trapAndPark);

13.2 Block 三条 RASP 路径探测

const RASP_PATHS = new Set([
'/cores/.safe_mode',
'/var/jb/usr/lib/TweakLoader.dylib',
'/var/jb/usr/lib/TweakInject.dylib',
]);

['access', 'faccessat', 'stat', 'lstat', 'fstatat', 'stat64', 'lstat64']
.forEach(name => {
const p = Module.findExportByName(null, name);
if (!p) return;
Interceptor.attach(p, {
onEnter(args) {
const path = (name === 'fstatat' || name === 'faccessat'
                          ? args[1] : args[0]).readCString();
this.blocked = path && RASP_PATHS.has(path);
        },
onLeave(retval) {
if (!this.blocked) return;
            retval.replace(ptr('-1'));
__error().writeInt(2);   // errno = ENOENT
        }
    });
});

13.3 短路-[NSComparisonPredicate evaluate...]

const lookUp = new NativeFunction(Module.findExportByName(null, 'objc_lookUpClass'), 'pointer', ['pointer']);
const selReg = new NativeFunction(Module.findExportByName(null, 'sel_registerName'), 'pointer', ['pointer']);
const classGetIM = new NativeFunction(Module.findExportByName(null, 'class_getInstanceMethod'), 'pointer', ['pointer','pointer']);
const methGetImp = new NativeFunction(Module.findExportByName(null, 'method_getImplementation'), 'pointer', ['pointer']);

const cls = lookUp(Memory.allocUtf8String('NSComparisonPredicate'));
const sel = selReg(Memory.allocUtf8String('evaluateWithObject:substitutionVariables:'));
const imp = methGetImp(classGetIM(cls, sel));

Interceptor.replace(imp, new NativeCallback(function (self, _sel, obj, vars) {
return 0;   // 永远 NO
}, 'bool', ['pointer', 'pointer', 'pointer', 'pointer']));

13.4 启动

frida -H 127.0.0.1 -f com.fanduel.sportsbook -l bypass.js -o log.txt

#

14. 技术教训与总结

14.1 Frida 用法层面

14.2 iOS 16 反越狱检测手法层面

  • 路径探测依然是基础

    palera1n rootless 最脆弱的暴露点是/var/jb/usr/lib/TweakLoader.dylib和TweakInject.dylib。大多数 RASP 会先access(W_OK)看这几个。

  • “借刀杀人” 式检测

    不直接调exit()，而是检测到越狱后构造一个会让iOS 自己的 NSPredicate KVC 安全校验触发abort的对象（塞到 framework bundle 元数据里）。从崩溃日志上看像 Apple 原生机制崩，反欺诈厂商有一定卸责性 + 抗分析价值。

  • dyld 初始化阶段是关键窗口

    ServiceCore!initialize_framework_bundles在所有__init_offsets之前跑，通过 NSPredicate 过滤所有已加载 framework。这是 iOS 16 新增的预处理步骤，它的副作用（+ app 特定数据）形成了这次的 kill 路径。

  • _NSPredicateUtilities _predicateSecurityAction

    是 iOS 16+ 的内置安全动作，遇到任何它认为”不受信任的 KVC 表达式”就无条件 abort。对反欺诈来说是天然的”借力点”。

#

14.3 调试方法论

  • 永远先跑对照组

    （空脚本 / 只装异常处理器）。这次要是一开始就 baseline 比较，至少能省 50% 的时间 —— 我花了太久在”外部 SIGKILL” 的错误假设上。

  • Process.setExceptionHandler是神器

    无论 BRK / UDF / SIGSEGV / SIGILL，都能捕获 + 拿 PC 和上下文。几次关键跳跃都靠它。

  • 抓 backtrace 就对了

    trapAndPark里Thread.backtrace+DebugSymbol.fromAddress把每层调用都解析出来，关键信息一行给出Foundation!+[_NSPredicateUtilities _predicateSecurityAction]就破案。

  • 观察时序 + 排除法

    先证明”其他 app 活”再证明”本 app 专属”；先证明”exit hooks 没触发”再思考是不是 mach 级；先把/cores/.safe_mode拦掉再看进程能不能多活一点。每一步都缩小搜索空间。

  • 遇到 Frida API 疑难坑，fallback 到 C runtime

    objc_lookUpClass / class_getInstanceMethod / method_getImplementation组合能搞定 95% 的”ObjC.classes 拿不到”问题。

14.4 已知副作用

-[NSComparisonPredicate evaluateWithObject:substitutionVariables:]被全局改成return NO，所有NSPredicate filter 都会返回空。对 bypass 启动足够，但 app 里任何依赖 predicate 的业务路径（搜索、筛选、缓存命中）都会失效。

生产级收敛建议：

  • HookServiceCore!initialize_framework_bundles的 enter / leave（用Module.findExportByName('ServiceCore', ...)查，加载晚但在我们需要前能完成），设一个全局 flagg_in_init_bundles。

  • NSComparisonPredicate evaluate...

    的 replacement 里读 flag：if (g_in_init_bundles) return 0; else return original(...)。

  • 调用原 IMP 可以通过Interceptor.replaceFast拿到原函数指针（Frida 16 新增），或手动 save 原 IMP 再调。

这部分本次没做（够用就行），但要上生产得把它加上。

附：文件清单

fanduel_bypass/
├── bypass.js          最终生产脚本（3 fix 组合，~50 行核心）
├── check_alive.py     Python 宿主：spawn → attach → load → 监控存活
├── minimal.js         迭代版本，保留完整注释，便于对比
├── exception_only.js  对照组：只装异常处理器
├── diag.js / ...      早期诊断脚本（全量 msgSend 追踪、file probe 追踪）
├── run.py             / gate_launch.py / spawn_only.py   多种启动姿势
├── log.txt            典型成功运行日志
├── README.md          简要说明
└── ANALYSIS.md        本文档
  • 最小可复现路径

frida -H 127.0.0.1 -f com.fanduel.sportsbook -l bypass.js -o log.txt

  • 自动化验证

python check_alive.py bypass.js→ 看到BYPASS SUCCEEDED即通过。

#

看雪ID：zhuzhu_biu

https://bbs.kanxue.com/user-home-878476.htm

*本文为看雪论坛优秀文章，由 zhuzhu_biu 原创，转载请注明来自看雪社区

第十届安全开发者峰会【议题征集】-欢迎投稿

往期推荐

安卓逆向基础知识之frida Hook

2025 强网杯和强网拟态部分题解

在逆向分析方面-unidbg真的适合 MCP 吗？

AI静态分析，内核模块隐藏 Frida 特征，绕过linker私有结构遍历崩溃链

某安全so库深度解析

球分享

球点赞

球在看

点击阅读原文查看更多

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：看雪学苑 zhuzhubiu zhuzhubiu《AI 绕过 ios 越狱检测》

版权声明

本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。

ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
ZONE.CI 全球网
安全领域涉猎者-乌云独行地带
ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
安全领域涉猎者-乌云独行地带
ZONE.CI 全球网
评论：0   参与：  0