After a Flutter project is deployed on iOS, if someone obtains the IPA, the first step might not be decompilation but directly unpacking it. After extraction, the directory structure is very clear: Dart code, resource files, and plugin modules are all in different locations. By piecing this information together, one can roughly reconstruct the application’s logic.

In a Flutter project that includes a membership system and dynamic configuration, we specifically conducted anti-cracking processing.

First, Dismantle the Flutter IPA

After building the IPA, extract it directly:

unzip Runner.ipa

Navigate to the directory:

Payload/Runner.app

You can see several key contents:

App.framework
flutter_assets/
Frameworks/

Enter flutter_assets:

assets/
isolate_snapshot_data
kernel_blob.bin

Among these:

  • kernel_blob.bin: Dart compilation output
  • assets/: Resource files
  • App.framework: Partial logic code

Handle the Dart Layer First (But Don’t Stop Here)

Flutter provides an obfuscation option:

flutter build ios --obfuscate --split-debug-info=./symbols

After execution:

  • Dart symbols are replaced
  • Symbol mapping files are generated

However, after this step, if you unpack the IPA again, you’ll find:

  • Resource names are still clear
  • JS / JSON files are readable
  • iOS native symbols still exist

In other words, this step only handles the Dart layer.

Process the Flutter Resource Directory (Key Focus)

Enter flutter_assets/assets. If you see something like:

images/vip_banner.png
config/payment.json
html/activity.html

These names are sufficient to indicate the business structure.

Our approach is: Do not modify the Flutter project, but uniformly modify at the IPA level.

Use Ipa Guard:

  • Import the IPA
  • Switch to the resource module
  • Select images, JSON, HTML, JS

Resource Obfuscation

After execution:

vip_banner.png → a8d3k.png
payment.json → x92ks.json

Compress JS / HTML Again

If H5 pages (WebView) are embedded in Flutter, these files remain readable.

Process them during the build phase or after unpacking:

terser main.js -o main.min.js

Or:

uglifyjs page.js -o page.min.js

After processing, place them back into the IPA, then rename them using Ipa Guard.

The result is:

  • Content compression
  • Meaningless filenames
  • Unreadable paths

Handle the iOS Native Layer (Often Overlooked)

Flutter is not entirely Dart; it also includes:

  • Plugin code (Swift / OC)
  • Native bridging layer
  • SDK logic

These contents belong to Mach-O binaries in the IPA.

Check:

strings AppBinary | grep Manager

If you see:

FlutterPaymentManager
UserAuthHandler

It indicates the native layer is fully readable.

Use Ipa Guard for Binary Obfuscation

In the code module:

  • Select Swift classes
  • Select OC methods
  • Select key symbols

Code Obfuscation

After execution:

FlutterPaymentManager → k39sd2

Check again:

strings AppBinary | grep Payment

The original name is no longer found.

Modify Resource MD5 (Addressing “Reuse Identification” Issues)

If multiple applications use the same set of UI resources, even after renaming, they might be identified.

Ipa Guard provides an MD5 modification feature:

  • Image content remains unchanged
  • File fingerprint changes

MD5 Modification

Verify:

md5 vip_banner.png

Different before and after processing.

This step is more about preventing resources from being easily compared.

Remove Those “Excessive Information”

During the Flutter build process, debugging information might be included.

You can check:

strings AppBinary | grep Flutter

If the output includes log or debugging fields, they can be cleaned up during the IPA processing stage.

Ipa Guard supports deleting some debugging information.

Sign and Directly Install for Testing

After all modifications, re-signing is necessary.

You can use:

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

Or configure certificates directly in Ipa Guard.

After connecting the device, you can install it directly.
Re-signing

Testing Focus Points (Specific to Flutter)

When testing Flutter projects, pay special attention to:

  • Whether page rendering is normal
  • Whether Dart calls are abnormal
  • Whether plugins can still be called
  • Whether WebView loads successfully

If some pages fail to load, it can generally be traced to resource paths being mishandled.

The entry points for cracking Flutter iOS packages are not limited to Dart code. Resource directories, JS files, and native module symbols can also be exploited. A single method is difficult to cover all exposure points.

In practical projects, by using Flutter build parameters to handle the Dart layer and combining Ipa Guard for resource obfuscation, binary symbol processing, and MD5 modification on the IPA, a round of reinforcement can be completed without intruding into the project structure.

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