Once, while troubleshooting an online issue, I dropped my project’s IPA into class-dump and glanced at the output. Class names, method signatures, and parameter names were restored almost verbatim. For example, the output directly showed:
@interface PaymentManager : NSObject
- (void)startPayment:(NSString *)orderId userId:(NSString *)userId;
@end
This kind of information is already sufficient for reverse engineering. The interface structure, parameter meanings, and calling relationships can all be inferred. Later, I specifically implemented defenses against class-dump. The key is to make its output meaningless.
I. What class-dump Can Extract
Before processing, you can run it yourself:
class-dump AppBinary > dump.txt
Open dump.txt and focus on:
- Class names
- Method names
- Parameter names
- Protocol names
If you see:
UserManager
VipSubscriptionService
handleLoginWithUserId
It means symbols are fully exposed.
II. Reducing Symbol Information During Build
Adjust Release configuration in Xcode:
Strip Linked Product = YES
Strip Swift Symbols = YES
Rebuild and run:
class-dump AppBinary
The output will be reduced, but core class names still remain. This step cleans up debug symbols, but has limited effect on class-dump.
III. Identifying Symbols That Must Be Preserved
Before direct obfuscation, you need to identify parts that cannot be modified.
For example:
NSClassFromString("PaymentManager")
Or:
@objc(handleLogin:)
Methods that depend on strings or selectors will cause runtime errors if modified.
Approach:
- Record these class names and methods
- Exclude them from subsequent obfuscation
IV. Rewriting Symbols at the IPA Level
class-dump primarily relies on symbol information in the Mach-O binary.
To change the output content, you need to directly modify these symbols.
Ipa Guard, after loading the IPA, parses the binary and lists:
OC classes
Swift classes
OC methods
Swift methods
In practice, we filter:
PaymentManager
UserCenterController
VipService
After obfuscation:
PaymentManager → a8d3k2
Run again:
class-dump AppBinary
The output becomes:
@interface a8d3k2 : NSObject
The structure remains, but semantics are lost.
V. Handling Method Parameters
class-dump output includes not only method names but also parameter names:
- (void)payWithOrderId:(NSString *)orderId userId:(NSString *)userId;
If only method names are changed, parameters can still provide clues.
Ipa Guard supports processing parameter names:
orderId → a1b2
userId → c3d4
After processing:
- (void)a8d3k2:(NSString *)a1b2 c3d4:(NSString *)c3d4;
class-dump output becomes hard to understand.
VI. Resource Files Can Also Aid Analysis
Even if symbols are obfuscated, resource files may still expose logic.
For example:
config/payment.json
assets/vip_banner.png
These files can help infer module structure.
In Ipa Guard’s resource module, you can:
- Rename files
- Update reference paths
After processing:
payment.json → k39sd.json
vip_banner.png → a82kd.png
Handling Resource Fingerprints
If multiple apps use the same resource, file contents may be compared.
You can enable MD5 modification:
md5 banner.png
Before and after processing differ. This step changes resource characteristics, not content.
Deleting Debug Information (Reducing Additional Clues)
Besides class-dump, analysts also combine string information.
You can check:
strings AppBinary | grep NSLog
If log messages exist, they can be removed during processing.
Ipa Guard supports cleaning some debug content.
Supplement: JS / H5 Layer Processing
If the app contains WebView or React Native:
main.jsbundle
index.html
You can use:
terser main.js -o main.min.js
Minify and then combine with resource renaming.
Re-signing and Verification
After modifications, re-signing is required:
kxsign sign app.ipa \
-c cert.p12 \
-p password \
-m dev.mobileprovision \
-z test.ipa \
-i
Verify after installation:
- Are pages normal?
- Are dynamic calls effective?
- Is functionality complete?
XI. Verify Processing Effect
Run again:
class-dump AppBinary
If the output becomes:
@interface a82kd3 : NSObject
It means processing is effective.
class-dump itself is not the problem; it is merely an entry point. The real issue is that the binary retains enough semantic information. As long as this information exists, any tool can exploit it.