For a period, we tried using online hardening services in our project. The process was simple: upload the IPA, wait for processing, download the hardened package, then sign and install for testing. It was indeed convenient in operation, but during an internal review, we discovered an issue: we were uploading the complete IPA, which contains code, resources, and even interface structures. How would this data be handled?

There was no answer to this question. How the server stores it, whether copies are retained, or if it’s used for model analysis or rule training—all are invisible. Subsequently, we changed the entire process to be completed entirely locally, including obfuscation, resource processing, and signing testing.


Comparing the Differences Between the Two Processing Methods

First, look at the core differences between the two methods:

Cloud Processing Flow:

Upload IPA → Server Processing → Download Result

Local Processing Flow:

Local IPA Parsing → Local Obfuscation → Local Signing → Local Testing

The key difference is handing over the complete app to a third party.

The contents of an IPA include:

  • Executable binary (Mach-O)
  • Resource files (images, JSON, HTML)
  • JS bundle (if React Native / H5)
  • Configurations and interface structures

Combined, this information can largely reconstruct the app’s logic.


First, Identify What Recognizable Information the IPA Contains

Before migrating the process, we conducted a check on the current IPA.

Extract the IPA:

unzip app.ipa

Enter the directory:

Payload/App.app

Check several key points:

1. Class and Method Names

strings AppBinary | grep Manager

Example output:

PaymentManager
VipService
OrderController

2. Resource File Naming

assets/images/vip_banner.png
config/payment_config.json

3. H5 or JS Files

main.jsbundle
index.html

Uploading this information to the cloud essentially fully exposes the app’s structure.


Switching to Local Code Obfuscation Processing

In the local process, the core step is directly processing the IPA.

The method provided by Ipa Guard involves parsing the Mach-O file and listing modifiable symbols.

Operation process:

  • Open the tool
  • Import the IPA file
  • Enter the “Code Module”

You can see:

OC Classes
Swift Classes
OC Methods
Swift Methods

Code Obfuscation

In the list, select classes containing business semantics, for example:

VipSubscriptionManager
PaymentService
UserCenterController

After executing obfuscation:

VipSubscriptionManager → k39sd2

When checking again with strings, these names have been replaced.

The entire process is completed locally, without uploading any data.


Local Resource File Processing

Resource files also need processing; otherwise, the app structure can still be analyzed through file names.

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

  • Images
  • JSON
  • JS
  • HTML
  • Audio

After execution:

vip_banner.png → a82k3.png
payment_config.json → k29sd.json

The tool automatically updates reference paths.
Resource File Processing


Modifying Resource MD5 and Feature Values

If multiple apps share resources, simply renaming is insufficient.

Ipa Guard supports modifying resource MD5:

  • File content remains consistent
  • Fingerprint value changes

You can verify with a command:

md5 vip_banner.png

The results differ before and after processing.

This step reduces the probability of resources being identified through comparison.
MD5 Value


Compressing JS and HTML Content

For React Native or H5 projects, the JS bundle remains readable.

During the packaging phase, you can use:

terser main.js -o main.min.js

Compress it before placing it into the IPA.

Then, use Ipa Guard to modify file names, making the paths lose semantics as well.


Cleaning Debug Information

Debug information is also a leakage point.

You can check:

strings AppBinary | grep NSLog

If the output is extensive, you can delete debug information during processing.

Ipa Guard supports automatically cleaning some debug symbols, making the binary more concise.


Local Signing and Testing

After obfuscation is complete, re-signing is required.

You can use the command:

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

Or directly configure certificates in Ipa Guard and generate a new IPA.

After connecting a device, you can install and test directly.
Re-signing


Verifying Process Stability

After installation, verify:

  • Whether pages load normally
  • Whether resources load
  • Whether H5 pages are functional
  • Whether login and payment processes work correctly

If issues arise, adjust the obfuscation scope and regenerate.


Conclusion

Uploading IPA to the cloud for obfuscation essentially hands over the complete app to a third party for processing. Whether it’s secure is difficult to verify through technical means. Migrating the process locally allows data control within your own environment.

In this process, Ipa Guard provides a way to directly manipulate IPA: performing symbol obfuscation on Mach-O binaries, renaming and modifying MD5 for resource files, and supporting local signing and testing. Combined with JS compression and signing tools, this forms a complete local hardening workflow.

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