有一次在排查线上问题时,我把自己项目的 IPA 丢进 class-dump,看了一眼输出。结果类名、方法签名、参数名几乎一字不差地被还原出来。例如输出里直接出现:
@interface PaymentManager : NSObject - (void)startPayment:(NSString *)orderId userId:(NSString *)userId; @end
这类信息对逆向来说已经足够。接口结构、参数意义、调用关系都可以被推测出来,后来专门做了一次针对 class-dump 的防护处理。重点是让它输出的内容变得无意义
在处理之前,可以自己跑一遍:
class-dump AppBinary > dump.txt
打开
dump.txt,重点看:
如果看到:
UserManager VipSubscriptionService handleLoginWithUserId
说明符号完全暴露。
在 Xcode 中调整 Release 配置:
Strip Linked Product = YES Strip Swift Symbols = YES
重新构建后再跑:
class-dump AppBinary
输出会减少,但核心类名仍然存在。这里的作用是清理调试符号,对 class-dump 的影响有限。
在直接混淆之前,需要先找出不能修改的部分。
例如:
NSClassFromString("PaymentManager")
或:
@objc(handleLogin:)
这类依赖字符串或 selector 的方法,如果被修改,会导致运行错误。
处理方式:
class-dump 的核心依赖是 Mach-O 中的符号信息。
要改变输出内容,就需要直接修改这些符号。
Ipa Guard 在加载 IPA 后,会解析二进制并列出:
OC 类 Swift 类 OC 方法 Swift 方法

在实际操作中,我们筛选:
PaymentManager UserCenterController VipService
执行混淆后:
PaymentManager → a8d3k2
再运行:
class-dump AppBinary
输出会变成:
@interface a8d3k2 : NSObject
结构还在,但语义已经消失。
class-dump 输出不仅包含方法名,还包括参数名:
- (void)payWithOrderId:(NSString *)orderId userId:(NSString *)userId;
如果只改方法名,参数仍然可以提供线索。
Ipa Guard 支持对参数名称进行处理:
orderId → a1b2 userId → c3d4
处理后:
- (void)a8d3k2:(NSString *)a1b2 c3d4:(NSString *)c3d4;
class-dump 输出变得难以理解。
即使符号被混淆,资源文件仍然可能暴露逻辑。
例如:
config/payment.json assets/vip_banner.png
这些文件可以帮助推断模块结构。
在 Ipa Guard 的资源模块中,可以:
处理后:

payment.json → k39sd.json vip_banner.png → a82kd.png
如果多个应用使用同一资源,文件内容可能被比对。
可以开启 MD5 修改:
md5 banner.png

处理前后不同,这一步改变的是资源特征,而不是内容。
class-dump 之外,分析者还会结合字符串信息。
可以检查:
strings AppBinary | grep NSLog
如果存在日志信息,可以在处理阶段删除。
Ipa Guard 支持清理部分调试内容。
如果应用包含 WebView 或 React Native:
main.jsbundle index.html
可以使用:
terser main.js -o main.min.js
压缩后再配合资源改名。
修改完成后,需要重新签名:
kxsign sign app.ipa \ -c cert.p12 \ -p password \ -m dev.mobileprovision \ -z test.ipa \ -i
安装后验证:

再次运行:
class-dump AppBinary
如果输出变为:
@interface a82kd3 : NSObject
说明处理生效。
class-dump 并不是问题本身,它只是一个入口。真正的问题是二进制中保留了足够多的语义信息。只要这些信息存在,任何工具都可以利用。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70047439/viewspace-3115058/ ,如需转载,请注明出处,否则将追究法律责任。