Once while investigating a competitor, I unpacked their IPA and briefly examined the symbol information using Hopper. Class names, method names, and resource paths were mostly readable, and even interface naming wasn’t processed. For apps involving business logic, this essentially exposes the implementation directly.

Later, I encountered a similar but more challenging situation: an old app of ours where the source code was no longer available, but the IPA was still running and needed ongoing maintenance, release, and an additional layer of security protection. In this case, the only object we could work with was the IPA itself.

This article documents a process for hardening a released IPA without source code. The core idea is to directly manipulate the binary and resources.

Confirm Information Currently Exposed by the IPA

Before any processing, you can first check how much this IPA “exposes.”

Unpack:

cp app.ipa app.zip
unzip app.zip

Navigate to:

Payload/AppName.app

Next, use a few simple commands to inspect.

View Class and Method Names

strings AppBinary | grep Controller

If the output resembles:

LoginViewController
VipCenterController
OrderManager

It indicates that symbols are hardly processed.

View Resource Structure

ls assets/

If present:

vip_banner.png
payment_config.json
order_success.html

The resource layer also allows direct inference of business structure.

Verify Readability with Decompilation Tools

To confirm the issue, you can examine the structure using Hopper or class-dump.

For example, class-dump output:

@interface PaymentManager : NSObject
- (void)startPayment;
@end

Such information is sufficient for analyzing logic.

The goal is not to completely prevent decompilation but to make this information unreadable.

Perform Symbol Obfuscation at the IPA Level

Without source code, modifying class and method names can only be applied directly to the Mach-O file.

Ipa Guard provides the ability to parse the binary in the IPA and list all modifiable symbols.

After importing the IPA, you can see:

OC classes
Swift classes
OC methods
Swift methods

Filter business-related symbols in the list, for example:

PaymentManager
VipService
UserCenterController

After executing obfuscation:

PaymentManager → a8d3k2

Check again using strings or Hopper, and the original names have been replaced.
Code

Handle Variables and Method Parameters

In some projects, even after method names are obfuscated, logic can still be inferred from parameter names.

Ipa Guard supports processing method parameters and variables:

userId → x92k
orderId → k21d

This step further reduces code readability.

Note that if certain parameters are used via string reflection, they need to be excluded in the configuration.

Restructure Resource Files

During decompilation, many people first examine the resource directory.

For example:

vip_background.png
level_config.json
activity.html

These names are sufficient to understand module divisions.

In the resource module of Ipa Guard, you can select:

  • Images
  • JSON
  • HTML
  • JS

After processing:

vip_background.png → p82k3.png
level_config.json → m39sd.json

The tool automatically updates reference paths.
File Renaming

Modify Resource Fingerprints (MD5)

If only renaming is done, resource content remains consistent.

You can further modify resource MD5:

  • Keep image content unchanged
  • Change MD5 value

Verification method:

md5 image.png

Results differ before and after processing.

This step is used to scatter resource characteristics.
MD5 Value Modification

Clean Up Debug Information

Old versions of apps often retain debug information.

You can check:

strings AppBinary | grep NSLog

If the output contains log content, it can be deleted during processing.

Ipa Guard supports automatically cleaning up some debug information, making the binary cleaner.

Supplement: JS / H5 Resource Compression

If the app contains WebView or React Native modules, JS can be processed separately.

Execute during packaging or after unpacking:

terser main.js -o main.min.js

After compression, repack it into the IPA.

Then, combine with resource renaming to make file paths lose semantics.

Re-sign and Verify Operation

After all modifications, the IPA must be re-signed.

You can use:

kxsign sign app.ipa \
-c cert.p12 \
-p password \
-m dev.mobileprovision \
-z test.ipa \
-i

If the device connection is successful, the app will install automatically.

Testing focuses include:

  • Page loading
  • Network requests
  • Payment processes
  • Dynamic calls

If certain functions are abnormal, you can roll back corresponding obfuscation items.

IPA being decompiled doesn’t mean it can’t be remedied. Even without source code, you can still reduce readability through binary symbol obfuscation, resource structure adjustments, and debug information cleanup.

Ipa Guard provides the ability to directly process Mach-O binaries and resource files without relying on project source code. It also supports local signing and testing, allowing quick validation of results.

Reference link: https://ipaguard.com/blog/154