iOS反调试与反反调试

反调试原理ptrace​​ptrace (Process Trace)​​ 是 Linux（以及其他一些类 Unix 系统，如 macOS）提供的一个极其强大且底层的​​系统调用​​。它的

反调试原理ptrace​​ptrace (Process Trace)​​ 是 Linux（以及其他一些类 Unix 系统，如 macOS）提供的一个极其强大且底层的​​系统调用​​。它的核心功能是​​允许一个进程（称为 tracer）观察和控制另一个进程（称为 tracee）的执行，并能检查和修改该进程的内存和寄存器。​​

核心功能

追踪器的介入 (Tracer/Tracee):

一个进程（如 gdb, strace）调用 ptrace 并指定 PTRACE_ATTACH 或 PTRACE_TRACEME 来开始追踪另一个目标进程。

被追踪的进程 (tracee) 就进入了特殊的状态。每当发生特定事件（尤其是系统调用或信号传递）时，内核会暂停 (SIGSTOP) tracee 的执行，并通知 tracer。

​​观察和控制执行:

​​单步执行 (Stepping):​​ Tracer 可以让 tracee 执行一条机器指令 (PTRACE_SINGLESTEP, PTRACE_STEP)，然后再次暂停，让 tracer 有机会检查状态。

​​设置断点:​​ Tracer 可以修改 tracee 的代码（在内存中），通常是通过替换目标地址的指令为一个特殊的陷阱指令（如 int 3）。当 tracee 执行到此处时，会触发一个信号并暂停，交给 tracer 处理。之后 tracer 恢复原指令，并可能继续执行或单步。

​​拦截系统调用:​​

Tracer 可以要求在 tracee 即将进入系统调用 (PTRACE_SYSCALL) 或刚从系统调用返回时暂停。

strace 工具就是利用这点来打印出 tracee 进行了哪些系统调用以及参数、返回值。

Tracer 甚至可以修改进入系统调用时的寄存器参数（从而改变系统调用行为）或者修改系统调用的返回值。

​​检查和修改内存和寄存器:​​

Tracer 可以读写 tracee 的内存 (PTRACE_PEEKDATA, PTRACE_POKEDATA)，包括代码段和数据段。

Tracer 可以读写 tracee 的 CPU 寄存器 (PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS, PTRACE_SETFPREGS)。

处理信号:​

当有信号要发送给 tracee 时，内核会先暂停 tracee，并通过 wait() 通知 tracer。

​​Tracer 有决定权:​​

忽略这个信号：不让它传递给 tracee。

将信号传递给 tracee，让它处理。

注入一个自定义的信号给 tracee。

在这个过程中修改信号的行为。

主要应用场景

​​调试器 (Debuggers):​​ 这是最经典的用途。像 gdb 就是利用 ptrace 来实现设置断点、单步执行、检查变量（内存）、查看寄存器值等核心调试功能。

​​系统调用追踪器 (System Call Tracers):​​ strace 和 ltrace 这些工具完全依赖 ptrace 来拦截进程调用的系统调用和库函数，并打印相关信息，用于诊断和分析程序行为。

​​代码插桩 (Instrumentation):​​ 在运行时修改程序代码或注入代码片段，用于性能分析（Profiling）、测试覆盖率、内存检测（如 AddressSanitizer/Valgrind 的部分功能原理）等。

​​沙箱/安全工具:​​ 创建受限的执行环境。Tracer 可以监控 tracee 的系统调用，并根据安全策略允许或拒绝某些敏感操作（如访问特定文件、进行网络连接）。

​​进程间控制:​​ 一些特殊场景下需要精细控制另一个进程的执行流。

​​进程注入:​​ 向另一个运行中的进程注入代码或数据。

重要特点和注意事项

​​强大而底层:​​ ptrace 给了 tracer 对 tracee 几乎完全的控制权。

​​复杂性:​​ ptrace 接口相对复杂，涉及信号处理、进程状态、内存布局等多个方面，正确使用并不容易。

​​安全性:​​ ptrace 能力强大，通常普通用户只能 ptrace 自己拥有的进程（除非有 CAP_SYS_PTRACE 权限或 YAMA 等安全模块被配置）。恶意使用 ptrace 可被用于攻击或监控其他进程。

​​性能开销:​​ 频繁的 ptrace 操作（如 strace 追踪每个系统调用）会显著降低目标进程的执行速度。

​​不可靠的信号处理:​​ 使用 ptrace 的进程（tracer）在信号处理上需要极其小心，因为 SIGCHLD 等信号的默认行为会被 ptrace 事件干扰。

​​竞争条件:​​ 在设计使用 ptrace 的工具时要特别注意并发和竞争条件。

总结:​​ ptrace 是 Linux 系统上一个非常基础的、用于进程间追踪和控制的系统调用。它赋予了调试器 (gdb)、系统调用跟踪器 (strace) 以及其他各种分析、安全和控制工具强大的能力，但同时也非常复杂且需要谨慎使用。理解 ptrace 是深入理解 Linux 下进程执行、调试和系统监控机制的关键。

ptrace 的参数简单介绍ptrace 的原型可以在 macOS 中找到，新建一个 macOS 的应用，或者更加简单一点的命令行程序，就可以导入 sys/ptrace.h 文件查看函数原型并使用它了。如下图：

1234567891011121314151617181920212223242526272829303132333435363738#ifndef _SYS_PTRACE_H_#define _SYS_PTRACE_H_#include #include #include enum { ePtAttachDeprecated __deprecated_enum_msg("PT_ATTACH is deprecated. See PT_ATTACHEXC") = 10};#define PT_TRACE_ME 0 /* child declares it's being traced */#define PT_READ_I 1 /* read word in child's I space */#define PT_READ_D 2 /* read word in child's D space */#define PT_READ_U 3 /* read word in child's user structure */#define PT_WRITE_I 4 /* write word in child's I space */#define PT_WRITE_D 5 /* write word in child's D space */#define PT_WRITE_U 6 /* write word in child's user structure */#define PT_CONTINUE 7 /* continue the child */#define PT_KILL 8 /* kill the child process */#define PT_STEP 9 /* single step the child */#define PT_ATTACH ePtAttachDeprecated /* trace some running process */#define PT_DETACH 11 /* stop tracing a process */#define PT_SIGEXC 12 /* signals as exceptions for current_proc */#define PT_THUPDATE 13 /* signal for thread# */#define PT_ATTACHEXC 14 /* attach to running process with signal exception */#define PT_FORCEQUOTA 30 /* Enforce quota for root */#define PT_DENY_ATTACH 31#define PT_FIRSTMACH 32 /* for machine-specific requests */__BEGIN_DECLSint ptrace(int _request, pid_t _pid, caddr_t _addr, int _data);__END_DECLS#endif /* !_SYS_PTRACE_H_ */

_request： 最重要的参数，指定要对目标进程 pid 执行的具体操作类型。常用的 request 包括：

PT_TRACE_ME：指示本进程希望被其父进程跟踪（通常是调试器启动目标进程时，目标进程主动调用）。

PT_ATTACH: 附着到已运行的 pid 进程上，开始跟踪它。

PT_DETACH: 停止跟踪 pid 目标进程，使其恢复独立运行。

PT_STEP: 设置单步陷阱标志，让目标进程 pid 执行一条指令后暂停。

PT_DENY_ATTACH: 拒绝调试器附加，这正是我们需要传入的参数。

_pid：目标进程的进程 ID。

_addr​​: 内存地址（常用于 READ/WRITE DATA，系统调用号过滤器等特定操作）。

_data：指向一个数据缓冲区的指针，其含义取决于 request（如要写入的数据，存储读取数据的结构体地址，信号编号等）。

在 iOS 中调用 ptrace 反调试在刚刚的 macOS 应用的例子中我们可以直接导入 sys/ptrace.h 头文件使用 ptrace 函数。但是到了 iOS 环境是无法直接导入 sys/ptrace.h 头文件的，那么自然是无法通过这种方式调用 ptrace 了。但是可以确定的是 iOS 中也的确存在 ptrace 这个函数，只是 iOS 系统没有对外开放。我们可以使用一些绕过限制的方法调用 ptrace。

1. 使用 extern如下图：

这样调用之后，使用 Xcode 调试启动 APP 之后就会被断开调试了，也就意味着我们的 APP 现在无法被 lldb 调试器附加了。尝试附加调试会报以下错误：

123456 ~/ ssh root@localhost -p 2222iPhone8plus:~ root# debugserver localhost:3333 --attach=demoiOSAppdebugserver-@(#)PROGRAM:LLDB PROJECT:lldb-16.0.0 for arm64.Attaching to process demoiOSApp...zsh: segmentation fault debugserver localhost:3333 --attach=demoiOSApp

这种直接使用 ptrace 函数的方式，动态绕过的办法可以使用 fishhook 进行绕过。静态的方法当然是修改汇编指令也可以绕过。以下是使用 fishhook 绕过这种反调试的代码：

12345678910111213141516171819202122232425#import "InjectCode.h"#import "fishhook.h"int (*orig_ptrace)(int _request, pid_t _pid, caddr_t _addr, int _data);int hook_ptrace(int _request, pid_t _pid, caddr_t _addr, int _data) { if (_request == 31) { return 0; } return orig_ptrace(_request, _pid, _addr, _data);}@implementation InjectCode+ (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ struct rebinding one; one.name = "ptrace"; one.replaced = (void*)&orig_ptrace; one.replacement = hook_ptrace; struct rebinding array[] = {one}; rebind_symbols(array, 1); });}@end

2. 利用 dlsym123456789101112131415161718#import #import "AppDelegate.h"#import typedef int (*ptrace_t)(int _request, pid_t _pid, caddr_t _addr, int _data); int main(int argc, char * argv[]) { void *handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW); ptrace_t ptrace = dlsym(handle, "ptrace"); ptrace(31, 0, 0, 0); dlclose(handle); NSString * appDelegateClassName; @autoreleasepool { // Setup code that might create autoreleased objects goes here. appDelegateClassName = NSStringFromClass([AppDelegate class]); } return UIApplicationMain(argc, argv, nil, appDelegateClassName);}

使用 dlsym 函数动态获取 ptrace 的函数调用。这种方式调用 ptrace 的话，动态的方法就无法使用 fishhook hook ptrace 绕过反调试了，但是可以通过 fishhook hook dlsym 函数的方式绕过，还可以利用 lldb 实现汇编级别的 hook 实现绕过。静态的方法同样是修改汇编指令绕过。

3. 使用 syscall 的方式1234567891011121314#import #import "AppDelegate.h" int main(int argc, char * argv[]) { syscall(26, 31, 0, 0, 0); NSString * appDelegateClassName; @autoreleasepool { // Setup code that might create autoreleased objects goes here. appDelegateClassName = NSStringFromClass([AppDelegate class]); } return UIApplicationMain(argc, argv, nil, appDelegateClassName);}

使用 syscall 函数，通过传入第一个参数值 26 代表调用的 ptrace 函数，后续的参数就是 ptrace 所需的参数，而 31 正是 PT_DENY_ATTACH。这种方式也无法简单的通过 fishhook 绕过反调试。还可以使用 lldb 进行汇编指令级 hook 实现动态绕过。静态的方式依旧是修改汇编指令。

4. 使用内联汇编的方式123456789101112131415161718192021#import #import "AppDelegate.h" int main(int argc, char * argv[]) { __asm__ volatile( "mov x0, #0x1f\n" // PT_DENY_ATTACH 的值 (31) "mov x1, #0x0\n" // 第二个参数 (0) "mov x2, #0x0\n" // 第三个参数 (0) "mov x3, #0x0\n" // 第四个参数 (0) "mov x16, #0x1a\n" // ptrace 的系统调用号 (26) "svc #0x80" // 执行系统调用 ); NSString * appDelegateClassName; @autoreleasepool { // Setup code that might create autoreleased objects goes here. appDelegateClassName = NSStringFromClass([AppDelegate class]); } return UIApplicationMain(argc, argv, nil, appDelegateClassName);}

通过这种方式调用 ptrace，动态的绕过方式使用 fishhook 肯定是不行的，但是可以使用 lldb 汇编级 hook 绕过。而静态的方式当然依旧是分析并修改汇编代码。

以上 4 种方式都是直接或间接的调用 ptrace 函数来实现反调试。iOS 内核已加强对 ptrace 的管控，非越狱环境下调用受限，开发者需依赖私有 API 或漏洞利用。单一 ptrace 易被破解，通常需结合：

sysctl 定期检测​​：轮询进程状态标志位（如 P_TRACED），发现调试则主动退出或相应的处理。

代码混淆​​：隐藏反调试逻辑，增加逆向分析难度。

在 macOS/iOS 中，ptrace 的核心价值在于​​主动阻断调试器附加​​，但需结合动态加载、系统调用和混淆技术提升可靠性。反调试本质是攻防对抗的持续升级，单一措施不足以保证绝对安全，需多层防护策略。

sysctlsysctl 是一个用于动态配置内核参数的命令行工具同时也是一个可供编程的函数接口，在类 Unix 系统（如 Linux、FreeBSD）及 Apple 生态系统（macOS、iOS）中广泛使用，但不同平台的作用范围和权限限制存在显著差异。以下是具体分析：

类 Unix 系统（Linux/BSD）中的作用​sysctl 通过操作 /proc/sys/ 虚拟文件系统实现内核参数的实时调整，无需重启系统。核心功能包括：

​​动态调优性能​​

​​网络优化​​：调整 TCP 连接队列（net.core.somaxconn）、缓冲区大小（net.ipv4.tcp_rmem）、SYN Flood 防御（net.ipv4.tcp_syncookies=1）。

​​内存管理​​：控制 Swap 使用倾向（vm.swappiness=10）、脏页写回策略（vm.dirty_ratio）。

​​文件系统​​：设置最大文件句柄数（fs.file-max=2097152）。

功能启停

启用 IP 转发（net.ipv4.ip_forward=1），将主机配置为路由器。

禁用 ICMP 响应（net.ipv4.icmp_echo_ignore_all=1）以提升安全性。

持久化配置

参数写入 /etc/sysctl.conf 或 /etc/sysctl.d/*.conf，通过 sysctl -p 加载。

macOS 中的特殊性与限制​macOS 继承 BSD 的 sysctl 实现，但存在平台差异：

配置方式

默认无 /etc/sysctl.conf，需手动创建并加载（sudo sysctl -p）。

部分参数需通过 ​​launchd​​ 持久化（如修改 maxfiles 限制需编辑 /etc/launchd.conf）。

系统完整性保护（SIP）

macOS Big Sur 及以上版本中，修改核心参数（如 kern.ipc 系列）需​​关闭 SIP​​，否则操作被拦截。

典型用例

调整 Socket 队列（kern.ipc.somaxconn）、虚拟内存参数（vm.swappiness）。

iOS 中的严格限制​iOS 对 sysctl 的访问施加了更严格的安全策略：

权限封锁

多数敏感参数（如 kern.boottime）返回 ​​EPERM 错误​​，禁止用户态进程读取。

仅允许少数“白名单”参数（如设备型号、CPU 核心数）通过公有 API 访问。

合法使用场景

获取设备运行时间（kern.boottime）用于反欺诈检测（如防止日期篡改），但需 Apple 审核批准。

Apple 建议优先使用公开 API（如 NSProcessInfo），并​​避免依赖未文档化的参数​​。

开发风险

使用私有 sysctl 可能导致 App 审核被拒，因违反“禁止访问私有接口”条款。

在 iOS 中使用 sysctl 检测进程是否被调试实现代码如下：

123456789101112131415161718192021222324252627282930313233343536#import #import "AppDelegate.h"#import bool isBeingDebugged(void) { int name[4]; name[0] = CTL_KERN; name[1] = KERN_PROC; name[2] = KERN_PROC_PID; name[3] = getpid(); struct kinfo_proc info; size_t infoSize = sizeof(info); if (sysctl(name, 4, &info, &infoSize, NULL, 0) != 0) { perror("sysctl failed"); } return ((info.kp_proc.p_flag & P_TRACED) != 1);}int main(int argc, char * argv[]) { if (isBeingDebugged()) { printf("检测到调试。。。\n"); } else { printf("没有被调试。。。\n"); } NSString * appDelegateClassName; @autoreleasepool { // Setup code that might create autoreleased objects goes here. appDelegateClassName = NSStringFromClass([AppDelegate class]); } return UIApplicationMain(argc, argv, nil, appDelegateClassName);}

这种通过调用 sysctl 函数查询当前进程的一些信息来判断是否被附加调试的方式通常可以结合定时器，或者子线程 sleep 的方式来保持长期的运行。在这种情况下，检测到被调试的时候不建议直接退出当前进程如调用 exit、kill 等，这样的处理属于简单粗暴的方式。实际使用中可以根据需求制定其他的处理方式。

如何绕过这种检测呢？动态的方式当然同样可以使用 fishhook 进行绕过检测，但是这个 hook 方法的实现和一般的 hook 方法实现不一样，这个 hook 方法中需要修改 info 的结果，使其表示是否被调试的标志位始终为 0。具体的 hook 代码如下：

123456789101112131415161718192021222324252627282930313233343536373839#import "InjectCode.h"#import "fishhook.h"#import int (*orig_sysctl)(int *, u_int, void *, size_t *oldlenp, void *, size_t newlen);int hook_sysctl(int * name, u_int namelen, void * info, size_t *infosize, void * newInfo, size_t newsize) { if (namelen == 4 && name[0] == CTL_KERN && name[1] == KERN_PROC && name[2] == KERN_PROC_PID && info && infosize && *infosize == sizeof(struct kinfo_proc)) { int ret = orig_sysctl(name, namelen, info, infosize, newInfo, newsize); struct kinfo_proc *info_ptr = (struct kinfo_proc *)info; // 如果 info_ptr->kp_proc.p_flag 为 1，那么将它变为 0，因为 1 表示有附加调试 if (info_ptr && (info_ptr->kp_proc.p_flag & P_TRACED) != 0) { info_ptr->kp_proc.p_flag ^= P_TRACED; } return ret; } return orig_sysctl(name, namelen, info, infosize, newInfo, newsize);};@implementation InjectCode+ (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ struct rebinding one; one.name = "sysctl"; one.replaced = (void*)&orig_sysctl; one.replacement = hook_sysctl; struct rebinding array[] = {one}; rebind_symbols(array, 1); });}@end

那如何应对 fishhook 这种反反调试呢？当然是不要直接使用 sysctl 这样的函数调用，可以利用 dlsym 动态获取函数实现从而绕过 fishhook，或者使用汇编实现。还有一点值得注意的就是 hook 代码和反 hook 代码的执行顺序问题。

syscall如何反制总的来说，反制的的手段分为动态的 hook 和静态的修改 MachO 两个方面。

库的先后顺序能影响检测的结果。使用函数指针保存 ptrace，sysctl 地址，使用函数指针调用函数。修改 MachO

实战作者的实战环境是 Mac Pro（macOS 15.3.1），iPhone 8 Plus（iOS 16.7.10）使用 palera1n 的 rootful 越狱。

动态绕过反调试这里介绍一个 lldb 插件 xia0LLDB。提供了一个 debugme 命令可以 hook ptrace 和 inlinehook svc 来绕过反调试。但是在我的环境 iPhone8Plus iOS16.7.10 中想要成功利用 debugme 绕过 iOS 端最新版小红书还是没那么简单，出了点问题，我们来分析一下为什么。

小红书这里以作者编写本文时的 iOS 端小红书最新版本(8.88)为例。已经在2026年01月08日的最新版9.16.1验证同样可以绕过反调试防护。我们都知道，小红书是做了 lldb 反调试的。直接启动 APP，然后使用 debugserver 附加调试，肯定是附加不成功的。以下为演示：

APP 在前台时尝试附加：

12345iPhone8plus:~ root# debugserver localhost:3333 --attach=discoverdebugserver-@(#)PROGRAM:LLDB PROJECT:lldb-16.0.0 for arm64.Attaching to process discover...zsh: segmentation fault debugserver localhost:3333 --attach=discover

而就算把 APP 杀死，如上划杀掉进程，或者使用 kill，killall 命令干掉 APP 进程，再次附加调试也是无法成功的，因为此时进程并不存在。如下：

123456iPhone8plus:~ root# debugserver localhost:3333 --attach=discoverdebugserver-@(#)PROGRAM:LLDB PROJECT:lldb-16.0.0 for arm64.Attaching to process discover...error: failed to attach to process named: ""Exiting.

的确存在一种情况，即使做了反调试也可以成功附加的，那就是应用长时间没有打开过了，也不要打开，但是 ps 查看进程依然存在。这个时候可以使用 --attach 附加成功，对的即使做了反调试也能附加成功，只是在附加成功之后 continue 依然会被断开调试：

123(lldb) cProcess 562 resumingProcess 562 exited with status = 45 (0x0000002d)

或许你在网上曾经看到过 backboard 调试​​（通过 backboard 服务启动应用）时，​​在应用代码执行前暂停​​，以便调试器（LLDB）能附加并运行命令。即以下命令

1debugserver *:端口号 -x backboard /应用路径

然而，在 lldb 16.0.0 中，并不存在这个选项了。。。如下：

123456iPhone8plus:~ root#debugserver -x backboard localhost:3333 /private/var/containers/Bundle/Application/AEE569ED-D421-4274-93EA-72456A764135/discover.app/discovererror: invalid TYPE for the --launch=TYPE (-x TYPE) option: 'backboard'Valid values TYPE are: auto Auto-detect the best launch method to use. posix Launch the executable using posix_spawn. fork Launch the executable using fork and exec.

此时，可以使用 debugserver 的 –waitfor 选项来实现在目标应用代码执行前暂停，以便 lldb 能附加并运行命令。就是说 backboard 被 –waitfor 替代了。下面是完整的流程：

确保目标进程不存在：实现的方式有手动上划掉进程，killall -9 进程名，kill pid 等方式

使用 debugserver 的 –waitfor 选项：

我这里使用了 iproxy 进行了端口映射，将电脑的 3333 端口和手机的 3333 端口关联了起来，所以可以使用 localhost:3333 作为参数。

12345iPhone8plus:~ root# debugserver localhost:3333 --waitfor=discoverdebugserver-@(#)PROGRAM:LLDB PROJECT:lldb-16.0.0 for arm64.Waiting to attach to process discover...

手指点击启动目标 APP

进入 lldb 调试：

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071 ~/ lldb https://github.com/4ch12dy/xia0LLDB Welcome to xia0LLDB - Python3 Edition ,--. ,--. ,--. ,--. ,------. ,-----.,--. ,--.`--' ,--,--. / \ | | | | | .-. \ | |) /_ \ `' / ,--.' ,-. || () || | | | | | \ :| .-. \ / /. \ | |\ '-' | \ / | '--.| '--.| '--' /| '--' /'--' '--'`--' `--`--' `--' `-----'`-----'`-------' `------'[xia0LLDB] * Version: 3.1[xia0LLDB] + Loading all scripts from /Users/franky/xia0LLDB/src[xia0LLDB] * Finished(lldb) process connect connect://localhost:3333 # 连接到手机建立的 debugserverProcess 3166 stopped* thread #1, stop reason = signal SIGSTOP frame #0: 0x0000000118fb6ed0 dyld`dyld4::PrebuiltLoader::isValid(dyld4::RuntimeState const&) const + 520dyld`dyld4::PrebuiltLoader::isValid:-> 0x118fb6ed0 <+520>: add w22, w22, #0x1 0x118fb6ed4 <+524>: cmp w22, w9 0x118fb6ed8 <+528>: b.lo 0x118fb6e64 ; <+412> 0x118fb6edc <+532>: cbz x8, 0x118fb6f60 ; <+664>Target 0: (discover) stopped.(lldb) croc # 此时处在 dyld`start 方法中，是一个非常早的阶段，很多镜像都没完成加载，CoreFoundation 都没加载，直接使用 debugme 也是会报错的..所以执行这个命令，这个命令里面其实做的事情也很简单，设置了一个 CFBundleGetMainBundle 的断点，然后继续执行会来到断点，然后删掉所有断点，当断点来到 CFBundleGetMainBundle 后，此时所有镜像都加载完成了。后续的 debugme 命令也能成功运行了[*] going to env that can run oc script1 location added to breakpoint 1[+] now you can exe oc(lldb) debugme # 这个命令核心的作用就是对 ptrace 进行 hook，以及对 svc #80 指令进行 hook，这是通过对 APP 镜像文件以及所属的 Framework 的镜像文件的代码段扫描是否存在 svc #80 指令，如果存在就进行 hook。而 hook 的核心实现原理就是新创建一个内存页存放 hook 代码，同时修改原始指令的内存页跳转到 hook 代码中。[*] start patch ptrace funtion to bypass anti debug[+] ptrace funtion patach done[*] start patch svc ins to bypass anti debug[+] use "target list" to get main module:/private/var/containers/Bundle/Application/F55AF2FB-E18C-4B2A-95D1-9630F579F8FD/discover.app/discover[*] app dir:/var/containers/Bundle/Application/F55AF2FB-E18C-4B2A-95D1-9630F579F8FD/discover.app[*] search svc from:/private/var/containers/Bundle/Application/F55AF2FB-E18C-4B2A-95D1-9630F579F8FD/discover.app/discover[*] text start:0x0000000104a48000 end:0x0000000111848630------> 4550367176[*] start hook svc at address:0x10f3917c8[+] hook svc at address:0x10f3917c8 done[*] search svc from:/private/var/containers/Bundle/Application/F55AF2FB-E18C-4B2A-95D1-9630F579F8FD/discover.app/Frameworks/A.framework/A[*] text start:0x0000000118eec6d4 end:0x0000000118eeeb90------>