非越狱iOS逆向实战：从Frida Hook到重签名注入完整指南

干移动安全这行久了，经常被问一个问题：手里只有一台非越狱的iPhone，能不能对App做逆向分析？能不能Hook它的方法、看它的加密逻辑、调试它的网络请求？答案是能，而且现在这条路比前几年好走太多了。非越狱环境下的iOS应用逆向，已经成了移动安全测试、竞品分析、自动化灰度和学习Objective-C运行时的重要技能。这篇文章我就把完整链路，从工具链、静态分析、动态Hook到重打包注入，按实战顺序完整梳理一遍。

适合看这篇内容的，主要有三类人：一是初入移动安全方向的安全工程师，想在不折腾越狱的情况下熟悉iOS应用结构；二是客户端开发，想分析第三方SDK到底在后台做了什么、有没有偷偷上传数据；三是自动化测试工程师，想通过Hook手段绕开UI操作直接验证业务逻辑。无论哪一类，只要你手上有一台Mac、一部iPhone，再加一个苹果开发者账号（个人免费签名也够用），就能把下面的流程完整跑一遍。

1. 非越狱逆向到底能做什么

1.1 非越狱逆向与越狱逆向的差异

很多人一听“逆向”就默认要越狱，其实这是个误解。越狱设备上确实能拿到root权限，可以随便往系统里注入代码、用Cycript或Frida直接改内存，自由度非常高。但越狱的代价也很明显：设备保修作废、系统稳定性下降、每次iOS升级都要等新的越狱漏洞，而且你分析出来的结论，在普通用户那台没越狱的机器上未必能复现。

非越狱路线的核心思路完全不同：不碰系统分区，只针对单个应用做手脚。我们利用的是iOS自身允许开发者签名运行App的机制，把要分析的App重新签名、安装到设备上，再通过注入动态库的方式挂上调试钩子。这样做的好处很实际：

• 设备保持原厂状态，不影响日常使用和系统升级。
• 分析环境更接近真实用户，测出来的网络行为、权限调用、性能损耗更有参考价值。
• 不用维护越狱环境，工具链反而更简单，一条数据线就能搞定。
• 对自研App做安全自查时，这套流程可以直接集成进CI，做到每天自动跑一遍Hook检查。

当然，非越狱也有它的边界：你拿不到root权限，改不了系统级行为，也没法对App Store里加密过的商业App随便砸壳。这一点后面我会单独讲，先说清楚能做什么，才能真正用对地方。

1.2 这套技术适合谁、不应该拿它做什么

先说适合的场景，都是我在实际工作中验证过的：

• 自研App安全自查：检查自己的App是否存在容易被Hook的点，比如登录校验、支付回调、越权接口，提前加固。
• 第三方SDK行为分析：很多App集成了几十个SDK，你根本不知道它们在后台做了什么。通过Hook网络层和系统API，能看到SDK到底上传了什么数据、调用了哪些敏感权限。
• 自动化测试辅助：UI自动化碰到难缠的弹窗、验证码，直接Hook掉对应方法，让测试流程顺畅跑下去。
• 学习Objective-C运行时：Hook是理解isa指针、消息转发、方法交换这些概念的最快方式，比看十篇原理文章都有效。

不适合做什么，更要讲清楚：不要对没有授权的商业App做去广告、内购绕过、协议破解，这在很多国家和地区都是明确违法的。非越狱逆向同样能定位到支付SDK的校验方法，但做不做是一念之差。技术本身是中性的，用在哪里取决于人。我这篇文章所有示例都基于自研的模拟项目X和授权测试包，你在实践时也请保持这个界限。

1.3 非越狱逆向的完整技术链路

把整个流程拆开看，其实就五步，每一步都有对应的工具和技巧：

1. 拿到可分析的Mach-O二进制：自研App直接从Xcode的DerivedData目录取，授权测试包解压IPA就能拿到。
2. 静态分析摸清结构：用class-dump导出所有Objective-C头文件，用反汇编工具看关键函数的实现，先搞清楚有哪些类、哪些方法、方法之间怎么调用。
3. 动态Hook验证行为：用Frida或LLDB在运行时拦截目标方法，打日志、改参数、改返回值，验证静态分析时的判断。
4. 注入动态库实现自动化：把自定义的dylib或Frida Gadget注入到App里，重签名安装，让Hook逻辑随App启动自动生效。
5. 整理结论并做防护闭环：把分析出的风险点整理成报告，反向指导App加固方案。

后面的内容就沿着这条链路展开，每一步我都会给出可直接复制的命令和代码，以及我自己踩过的坑。

2. 工具链选型与工作台搭建

2.1 硬件与基础环境

先说硬性条件。一台Mac是必须的，因为重签名、编译注入库都要用到Xcode工具链，Windows上做iOS逆向会非常别扭。iPhone方面，建议iOS 14以上系统，越老的版本对Frida新特性的支持越差。数据线最好用原装或MFi认证的，调试过程中传输频繁，劣质线经常断连，排查起来非常浪费时间。

软件环境方面，Xcode必须装好，并且至少要跑过一次真机调试，让开发证书和Provisioning Profile都配置妥当。如果你用的是个人免费账号，注意免费签名7天就会过期，重签名后安装的App要定期续签。这一点在自动化脚本里一定要处理，否则第二天跑到一半发现设备上的App打不开了。

另一个容易忽视的点是Homebrew。macOS上多数逆向工具都能通过brew安装，建议先把brew环境整理干净，后面装class-dump、iproxy这些工具会省很多事。

2.2 核心工具清单与选型逻辑

我把这次要用到的核心工具整理成了表格，每个工具背后都有明确的选型理由：

工具不在多，顺手最重要。比如反汇编这块，有人更喜欢IDA的F5伪代码，有人觉得Hopper界面更轻巧，两者都可以，核心是要能快速定位到目标方法。Frida和objection虽然是两套工具，但通常配合使用：先跑objection探索类结构，再写Frida脚本做精细Hook。

2.3 用Frida Gadget打通非越狱调试通道

在越狱设备上，Frida直接装个frida-server就行。但非越狱环境没有root权限，frida-server跑不起来，这时候就要用Frida的Gadget模式。

Gadget本质上是一个动态库，你把FridaGadget.dylib注入到目标App的Mach-O里并重签名，App每次启动就会自动加载Gadget，Gadget会在后台开一个调试端口，Mac上的Frida客户端连上去就能做Hook。整个过程不依赖越狱环境，完全走开发签名通道。

具体操作分两步。第一步，从Frida官方仓库下载对应iOS版本的frida-gadget-<版本>-ios-universal.dylib，重命名为FridaGadget.dylib。注意要选universal版本，它同时包含arm64和arm64e架构，能覆盖新款iPhone和老款iPhone。

第二步，把这个动态库放进App的Frameworks目录，并用insert_dylib注入Load Command：

mkdir -p Payload/模拟项目X.app/Frameworks cp FridaGadget.dylib Payload/模拟项目X.app/Frameworks/ insert_dylib @executable_path/Frameworks/FridaGadget.dylib Payload/模拟项目X.app/模拟项目X --all-yes

@executable_path是Mach-O里的一个动态路径变量，它会自动解析成App可执行文件所在的目录，这样无论App装在哪个沙盒路径下，都能正确找到Frameworks里的Gadget库。注入完成后再用开发证书重签名，App就能装到设备上了。

启动App后，Gadget默认会在127.0.0.1:27042监听。用iproxy把设备的27042端口转发到Mac本地：

iproxy 27042 27042

然后另开一个终端窗口连接：

frida -H 127.0.0.1:27042 -n 模拟项目X

连接成功后就能执行Frida命令了。我第一次跑通这个流程的时候，最大的感受是：非越狱逆向真的不再依赖越狱漏洞，纯粹是开发者签名机制的合理利用。

3. 静态分析：不运行代码也能摸清App结构

3.1 拿到可分析的Mach-O二进制

静态分析的前提是拿到App的可执行文件。对自研App来说，路径非常固定：Xcode的DerivedData目录里能找到编译产物，完整路径类似~/Library/Developer/Xcode/DerivedData/模拟项目X-xxxx/Build/Products/Debug-iphoneos/模拟项目X.app/模拟项目X。直接用命令查看就好：

find ~/Library/Developer/Xcode/DerivedData -name "模拟项目X" -type f

如果你拿到的是IPA安装包，解压后同样能找到二进制：

unzip 模拟项目X.ipa -d Payload file Payload/模拟项目X.app/模拟项目X

用file命令能看到二进制支持的架构：

Mach-O 64-bit executable arm64

arm64和arm64e的区别很重要：arm64e是新款iPhone的架构，启用了指针签名机制，后面注入动态库时如果处理不当，会导致App一启动就崩溃，这个问题我会在排查章节专门讲。

这里必须强调一个合规边界：App Store下载的应用是FairPlay加密过的，二进制里看不到明文的代码段，非越狱环境很难直接砸壳。所以我建议的实践路径是：自研App、企业签名的测试App、开源Demo，以及CTF比赛提供的专用样本。这些目标已经足够你练熟整套逆向技能了。

3.2 class-dump导出Objective-C头文件

拿到二进制后，第一件事就是导出头文件。class-dump能解析Mach-O里的Objective-C运行时信息，把所有的类、方法、协议、属性还原成可读的.h文件。

安装很简单：

brew install class-dump

然后指定架构导出：

class-dump --arch arm64 -H Payload/模拟项目X.app/模拟项目X -o Headers

几分钟后，Headers目录里就会出现几十个.h文件。看一个典型的类文件片段：

@interface XAuthManager : NSObject { NSString *_token; NSString *_userId; } @property(nonatomic, copy) NSString *token; @property(nonatomic, copy) NSString *userId; - (BOOL)loginWithUsername:(NSString *)username password:(NSString *)password; - (BOOL)logout; - (BOOL)isLoggedIn; @end

看到XAuthManager的loginWithUsername:password:方法，我心里就有数了：登录验证的核心逻辑大概率在这个类里，下一步Hook就围绕它展开。

class-dump有个实用技巧：先别急着看全部头文件，用grep先把敏感类名捞出来，效率更高：

grep -r "login\|token\|auth\|key" Headers/ | head -50

关键词筛选能帮你快速定位核心逻辑，尤其是分析不熟悉的App时，这个习惯能省下大量阅读时间。

3.3 用Hopper/IDA定位关键函数与伪代码

class-dump告诉你“有哪些方法”，但方法内部做了什么，还得靠反汇编工具。Hopper是我用得最多的，它的伪代码功能虽然不如IDA的F5出名，但胜在轻快、操作顺手。

把二进制拖进Hopper，等它自动分析完成，然后在左侧符号列表里搜索loginWithUsername，双击跳转到对应地址，按F5切换到伪代码视图。你会看到类似这样的结果：

bool -[XAuthManager loginWithUsername:password:](void *self, void *sel, void *username, void *password) { bool result = false; r12 = [username length]; if (r12 != 0x0) { r12 = [password length]; if (r12 > 0x6) { r12 = [[XNetworkManager sharedManager] loginWithUsername:username password:password]; result = r12 != 0x0; } } return result; }

这段伪代码直接揭示了几个关键信息：用户名不能为空、密码长度必须超过6位、真正的网络请求是调用XNetworkManager的loginWithUsername:password:完成的。后续Hook就有两个切入点了：可以直接HookXAuthManager的登录方法，也可以更深入HookXNetworkManager看网络层是否加密。

静态分析的意义在于，它让你在写第一行Hook脚本之前，就已经知道应该hook什么、期望看到什么输出。没有这一步，直接上手调试就像在黑屋子里找开关，效率极低。

4. 动态调试：LLDB与Frida双管齐下

4.1 debugserver与LLDB的基本用法

静态分析是“猜”，动态调试是“验”。LLDB是Xcode自带的调试器，在非越狱环境里，最常用的场景是配合Xcode调试自研App：在Xcode里打上断点，跑到断点停下来后，可以在LLDB控制台执行命令查看寄存器和内存。

但如果你想脱离Xcode、单独调试一个重签名App，就需要用到debugserver。iPhone上自带一份debugserver，但权限受限，需要用ldid给它的Mach-O加上get-task-allow权限，否则无法附加目标进程。通用做法是：

# 从设备拷贝debugserver到Mac scp root@<设备IP>:/Developer/usr/bin/debugserver ./debugserver # 准备entitlements文件 cat > debugserver.xml <<EOF <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>get-task-allow</key> <true/> <key>task_for_pid-allow</key> <true/> </dict> </plist> EOF # 重签名debugserver ldid -Sdebugserver.xml debugserver

把修改后的debugserver放回设备，运行起来监听一个端口，Mac端再用iproxy转发，最后用LLDB连接：

iproxy 12345 12345 lldb (lldb) process connect connect://127.0.0.1:12345

连接成功后，thread backtrace看调用栈、frame variable看局部变量、memory read读内存，这些都是LLDB的基本功。不过在非越狱环境里，LLDB的部署链路偏繁琐，而且附加外部App的限制比较多，所以我在实际项目中，85%的动态调试工作都交给了Frida，剩下15%需要断点单步调试的才用LLDB。

4.2 Frida的attach、spawn与Gadget模式

Frida有三种工作模式，开搞之前一定要搞清楚区别：

• attach模式：连接到一个正在运行的进程，适合对已启动的App做探查，速度快，但可能错过启动早期的逻辑。
• spawn模式：拉起一个新进程并暂停在入口处，等Hook脚本注入后再继续运行，适合分析启动流程、早期初始化逻辑。
• Gadget模式：动态库注入式，App启动即加载Gadget，既能探查也能管控，最适合非越狱重签名场景。

在Gadget模式下，我会写一段Python脚本来启动目标App并注入JS脚本。基础框架长这样：

import frida import sys def on_message(message, data): if message["type"] == "send": print("[*] {0}".format(message["payload"])) else: print(message) device = frida.get_usb_device() pid = device.spawn(["com.example.demo"]) session = device.attach(pid) source = """ if (ObjC.available) { console.log("[*] Objective-C runtime is available"); } """ script = session.create_script(source) script.on("message", on_message) script.load() device.resume(pid) sys.stdin.read()

这段脚本的核心逻辑是：用spawn启动App，App暂停在入口，注入脚本后再用resume让它跑起来。这样能保证Hook在业务代码执行之前就生效。

4.3 Hook一个Objective-C方法全流程

现在进入真正的重头戏：Hook模拟项目X里的XAuthManager登录方法。

目标是两件事：第一，当用户调用登录方法时，把用户名和密码打出来；第二，不影响原方法的正常逻辑，让App照常跑下去。Frida的JS脚本如下：

if (ObjC.available) { var m = ObjC.classes.XAuthManager['- loginWithUsername:password:']; m.implementation = ObjC.block(function (cmd, username, password) { console.log("[*] loginWithUsername called"); console.log("[*] username: " + username.toString()); console.log("[*] password: " + password.toString()); var ret = m.call(this, username, password); console.log("[*] login result: " + ret); return ret; }); } else { console.log("[-] Objective-C runtime not available"); }

这里有几个容易出错的地方：

• 方法名的写法必须原样带冒号和参数名：'- loginWithUsername:password:'，少一个冒号都匹配不上。
• ObjC.block(function (cmd, username, password) {...})里的cmd对应Objective-C的_cmd参数，代表当前方法的SEL，可以忽略，但不能不写。
• m.call(this, username, password)的作用是调用原方法，并且把this绑定到当前对象实例上，这样原方法内部访问属性、调用其他方法才不会出问题。
• 如果原方法返回的是对象类型，ret需要调用toString()才能打印出可读描述；如果是基本类型如BOOL，直接console.log即可。

把这段JS保存成hook_login.js，用Python客户端加载，然后触发App里的登录操作。终端里会输出类似这样的日志：

[*] loginWithUsername called [*] username: testuser [*] password: 123456 [*] login result: 1

这就证明Hook成功了。看到明文密码出现在终端的那一刻，你应该能理解为什么很多安全报告都强调不要用明文存储敏感信息——在逆向工程师手里，一次方法调用就能还原整个链路。

4.4 直接改返回值：一个登录校验的示例

Hook不止能看，还能改。还是拿登录方法举例，如果我们想模拟“任意账号都能登录成功”的效果，只需要把返回值固定为1：

if (ObjC.available) { var m = ObjC.classes.XAuthManager['- loginWithUsername:password:']; m.implementation = ObjC.block(function (cmd, username, password) { console.log("[*] force login success"); return 1; }); }

注意这里没有调用原方法，而是直接把返回值改成1，等价于绕过了所有登录逻辑。这个示例在自研App上做安全测试非常有用：如果业务层没有二次校验，直接用改返回值的Hook就能绕过登录，说明这套登录设计存在被HOOK的风险。换到真实攻击场景里，这就是一个高危漏洞。

但同样要重申：这个技巧只能用于你有权限的App。对别人的商业App做同样的事，性质就变成了绕过付费或认证，绝对不行。

5. 进阶：非越狱环境下的代码注入与重打包

5.1 动态库注入的原理与边界

Frida Gadget本质上就是一个动态库，注入的核心原理是修改Mach-O的Load Commands，增加一条LC_LOAD_DYLIB记录。dyld在启动App时读到这条指令，就会把对应的动态库加载进进程空间，动态库里的+load方法或构造函数会在main函数之前执行，这样就能抢在业务逻辑前面完成准备工作。

这个机制的边界在哪？主要三点：

• 只能针对应用沙盒内的进程，不能注入系统进程，因为系统进程受SIP保护。
• 只能注入arm64架构，arm64e设备上跑注入代码会触发指针签名校验，必须特殊处理。
• 重签名后App的Bundle ID必须和设备上已安装的版本一致，否则系统直接拒绝安装。

理解了原理，你就明白为什么注入类操作在非越狱下这么依赖“重签名”这个环节：签名是系统信任的地基，破坏了签名一致性，整个进程就启动不了。

5.2 用insert_dylib把Gadget塞进Mach-O

工具选择上，insert_dylib和yololib功能类似，都是命令行修改Mach-O的Load Commands。我用insert_dylib多一些，因为它支持--all-yes参数，批量替换时会自动确认。

基本用法：

insert_dylib @executable_path/Frameworks/FridaGadget.dylib Payload/模拟项目X.app/模拟项目X --all-yes

执行后会在同级目录生成模拟项目X_patched文件。把原二进制替换成这个补丁版本，再把FridaGadget.dylib放到Frameworks目录下：

cp Payload/模拟项目X.app/模拟项目X_patched Payload/模拟项目X.app/模拟项目X mkdir -p Payload/模拟项目X.app/Frameworks cp FridaGadget.dylib Payload/模拟项目X.app/Frameworks/

用otool验证注入是否成功：

otool -l Payload/模拟项目X.app/模拟项目X | grep -A5 LC_LOAD_DYLIB

输出里能看到：

cmd LC_LOAD_DYLIB cmdsize 56 name @executable_path/Frameworks/FridaGadget.dylib

看到这条记录，说明注入成功。这里有个经验之谈：修改完Load Commands后，最好先别急着安装，用codesign -d检查一下签名信息是否还完整，因为很多App有签名校验逻辑，一旦发现Mach-O被改动，会拒绝启动。

5.3 重签名、安装与常见签名坑

重签名是整个流程里最容易翻车的环节。Apple的签名机制非常严格，App内所有的二进制、动态库、扩展插件、资源文件都要有合法签名，而且签名顺序还有讲究。

我的标准流程是先准备entitlements文件：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>application-identifier</key> <string>TEAMID.com.example.demo</string> <key>get-task-allow</key> <true/> <key>aps-environment</key> <string>development</string> </dict> </plist>

然后执行重签名：

# 移除旧签名 rm -rf Payload/模拟项目X.app/_CodeSignature # 签名动态库 codesign -f -s "iPhone Developer: 你的账号" Payload/模拟项目X.app/Frameworks/FridaGadget.dylib # 签名主二进制 codesign -f -s "iPhone Developer: 你的账号" --entitlements entitlements.plist Payload/模拟项目X.app/模拟项目X # 签名整个App codesign -f -s "iPhone Developer: 你的账号" --entitlements entitlements.plist Payload/模拟项目X.app

最后打包安装：

xcrun devicectl device install app --device <设备UDID> Payload/模拟项目X.app

安装遇到“无法安装App”提示时，优先检查三件事：签名使用的证书是否还有效、entitlements里的Team ID对不对、设备的UDID是否在Profile设备列表里。修好这三项，90%的签名问题都能解决。

5.4 让注入代码随App启动自动生效

动态库注入不是终点，你还得让Hook逻辑在App启动时自动跑起来。Frida Gadget天然支持这个需求：只要Gadget被dyld加载，它就会自动监听调试端口，不需要额外代码。

但如果你想在Gadget加载的同时执行自己的自定义逻辑，可以在动态库里实现+load方法或构造函数。这里用一个最简单的dylib模板说明：

#import <Foundation/Foundation.h> __attribute__((constructor)) static void my_hook_entry() { NSLog(@"[*] custom dylib loaded"); // 这里可以放Method Swizzle或hook逻辑 }

__attribute__((constructor))是dyld加载动态库时自动调用的入口，它比+load更底层，适用于纯C函数环境。在这个入口里做Method Swizzle，能保证运行时逻辑在App的main函数执行前就完成替换。

这段代码要编译成动态库，Xcode新建一个Framework工程或使用clang -dynamiclib手动编译都行。更复杂的场景里，你可以把Frida脚本直接编译进动态库，做成一个“离线版”Hook工具，不依赖Mac端实时连接也能生效。

6. 高频问题排查与经验避坑

6.1 找不到设备、连接被拒怎么办

这是刚上手时最容易遇到的问题。frida -H 127.0.0.1:27042连不上，先检查iproxy是否还在运行：

ps aux | grep iproxy

iproxy意外退出是常见原因，端口被占用导致转发失败更是家常便饭。换个端口再试：

iproxy 27043 27042 frida -H 127.0.0.1:27043 -n 模拟项目X

如果设备根本识别不到，检查USB线连接后，执行：

frida-ls-devices

输出里应该有你的iPhone。没有的话，可能是usbmuxd服务异常，重启一下：

sudo pkill usbmuxd

让系统自动重拉服务，再重新插拔数据线。

6.2 Hook不生效的几类原因

Hook脚本写对了但没有任何输出，这个坑我踩过很多次。总结下来无非这几类：

• 方法名拼错。Objective-C的方法名是带冒号的完整字符串，少一个冒号、多一个空格都匹配不上。建议直接从class-dump导出的头文件里复制。
• 目标方法被加到了子类而不是父类。class-dump导出的是类声明，但实际调用走的可能是私有子类，需要检查ObjC.classes运行时的实际类。
• 方法被内联或优化掉了。Release模式下编译器可能把短方法内联，Hopper里能看到符号，但运行时Hook不到。换一个更大粒度的方法hook，或者hook这个方法的调用者。
• 时序问题。Hook脚本注入时，目标实例可能已经创建过了，你没有hook到已经发生的方法调用。用spawn模式确保App启动早期就注入脚本。

排查这类问题，我有个笨办法：先在脚本里全局扫描类信息，确认Frida拿到了正确的类和方法：

if (ObjC.available) { var cls = ObjC.classes.XAuthManager; if (cls) { console.log("[*] class found: " + cls); var methods = cls.$ownMethods; methods.forEach(function (m) { console.log(" " + m); }); } else { console.log("[-] class not found"); } }

运行这段脚本，如果打印出来的方法列表里没有loginWithUsername:password:，说明问题出在类名或方法名上，不用再往下查了。

6.3 崩溃、闪退的日志排查

App重签名后闪退，是新手最容易崩溃的时刻。先别慌，按这个顺序排查：

第一步看系统日志：

xcrun simctl spawn booted log stream --level debug --predicate 'process == "模拟项目X"'

真机上的日志用设备窗口看也可以。崩溃日志里最常见的信息是Signature invalid或code signature invalid，那就修复签名；如果是Library not loaded，说明动态库路径不对；如果是dyld: missing symbol，说明注入的动态库和App二进制不匹配。

定位崩溃点后，用xcrun crashlog或symbolicatecrash工具符号化崩溃日志，能看到具体的崩溃堆栈。实战中我遇到最多的场景是：注入的dylib是arm64e版本，但App只支持arm64，导致dyld直接拒绝加载。编译动态库时用universal架构，能避开这个坑。

6.4 一点更底层的经验：arm64e与指针签名

新款iPhone（A12及以上）的arm64e架构有个特殊机制：函数指针会被指针签名保护，简单说就是指针里嵌入了密钥信息，伪造的指针在调用时会触发异常。这对动态库注入和Hook来说是个大敌。

Frida Gadget从某个版本开始已经适配arm64e，所以Frida用户很少遇到问题。但如果你自己写dylib做Method Swizzle，就可能触发指针签名校验而崩溃。

应对方案有两个方向：一是编译时把dylib做成arm64e和arm64的universal版本，让dyld自动选择合适架构；二是尽量避免在arm64e设备上做底层指针改写，改用Frida这种成熟框架，由框架本身处理签名兼容问题。个人建议走第二条路，省心。

把常见问题整理成速查表，方便你随时查阅：

7. 写在最后：研究逆向的正确姿势

7.1 只对有权限的目标做分析

整套流程讲完了，我想把话收回到合规上。逆向是个技术活，更是个分水岭——同样的技能，用来做安全测试是防御，用来做破解是攻击。我在文中反复强调“自研App”“授权测试包”，不是套话，而是真的建议你把技能练在合法范围里。

如果你刚接触这个方向，最好的练习对象是自己写的App、开源项目，或者各种CTF的iOS赛题。这类样本足够丰富，你完全可以建立自己的技能树。等水平上来之后，再接到商业授权测试项目时，用这套流程去发现真正的高危漏洞，那才是它最值钱的地方。

7.2 从逆向到安全的闭环

逆向分析最大的价值，是反过来指导自己的App加固。比如你用Frida成功Hook了自己的登录方法，你就会明白：纯客户端校验是靠不住的，关键校验必须放在服务端；再比如你成功注入了一个动态库，你就会明白：重打包检测一定要做，至少得检查LC_LOAD_DYLIB里有没有异常记录。

我自己在项目里的习惯是：每次逆向分析完一个自研App，都会产出一份“Hook风险点清单”，然后交给开发团队逐条修复。这个闭环跑多了之后，新版本的App被Hook的难度会越来越高，逆向分析的成本也越来越大。这才是安全工程师该有的思路。

最后分享一个小技巧：把常用的Frida脚本、重签名命令、iproxy转发命令都整理成一个Shell脚本，一键完成注入、签名、安装。我现在的流程是改完脚本后直接跑自动化打包，几分钟就能完成一次完整的Hook验证。别小看这一步，它能把你的效率提高一个量级，也让你有更多时间去研究真正复杂的技术问题。