default title

Preface

When doing network debugging on the iOS platform, many developers use common tools such as Charles, Fiddler, or mitmproxy. But in practical operation, we often encounter a tricky problem: even though we have configured the proxy and certificate, the iPhone still cannot capture the package.

This situation is very common, especially after the popularity of HTTPS. This article summarizes the common reasons for iOS packet capture failures based on daily development experience, and shares several feasible solutions.

1、 Why does iOS often fail to capture packages?

1. The proxy is not configured correctly

When using proxy packet capture on iPhone, you need to manually set Wi Fi → HTTP proxy to the computer's IP and port. If filled in incorrectly or if the Wi Fi network does not support proxy, it will result in no data being captured.

2. HTTPS encryption issues

The iOS system will strictly verify HTTPS certificates by default. If the packet capture tool does not install a certificate or the certificate is not trusted, HTTPS requests made by the application will be directly rejected by the system.

3. Certificate not trusted

Many developers only install certificates, but forget to enable full trust in "Settings ->General ->About this machine ->Certificate trust settings". This will result in HTTPS data still being unable to be decrypted.

4. The app has enabled SSL Pinning

More and more applications, such as financial payments and video platforms, are adopting SSL Pinning technology to enforce certificate fingerprinting verification. If intercepted by a proxy, the app will directly reject communication, which is also the reason why many people cannot catch packages even though they are configured correctly.

5. System restrictions or port conflicts

Sometimes firewalls, VPNs, or system security policies can cause proxy ports to be inaccessible, resulting in the illusion of 'no traffic'.

2、 Common troubleshooting strategies

Test if the proxy is connected

Visit an HTTP website in Safari to see if the request can be displayed in the packet capture tool

If not, prioritize checking the computer IP and port

Check if HTTPS decryption is enabled

Open the decryption function in the tool and import the certificate

For some domain names, they need to be manually added to the decryption list

Confirm if the certificate is trusted

The iOS system is very strict, and untrusted certificates are equivalent to whitewashing

Check if the 'Certificate Trust Settings' are enabled

Determine if SSL Pinning has been encountered

If some apps (such as banking and video apps) are unable to decrypt, it can be basically confirmed that it is SSL Pinning

Traditional proxy tools are basically powerless for this type of problem

3、 Practical case: When Charles is unable to decrypt

During the process of debugging an app, Charles configured it correctly and installed and trusted the certificate, but still could only see CONNECT requests. After analysis, it was found that the application has enabled bidirectional SSL authentication.

In this situation, both Charles and Fiddler are powerless. Then I tried Sniffmaster:

• Connect to iPhone via USB without relying on Wi Fi proxy
• No need for jailbreaking or rooting, plug and play
• Automatically decrypt HTTPS and support cracking two-way authentication
• Capture packets according to the app to avoid interference from a large number of system requests
• Built in interceptor, supports modifying requests and responses with JavaScript
• Can export data streams for further analysis by Wireshark
• In just a few minutes, the HTTPS traffic of the target interface was successfully decrypted, and the problem was easily solved.

4、 Best practices for tool combinations

My experience is: don't rely solely on a single tool, but use it in combination according to the scenario.

• Charles: Suitable for daily debugging, user-friendly interface, good cross platform support
• Fiddler: Suitable for Windows users, with strong scripting capabilities
• Mitmproxy: Strong command line and script customization capabilities, suitable for automated testing
• Sniffmaster: Suitable for high security scenarios, especially SSL Pinning and two-way authentication on iOS

By combining usage, efficiency can be maintained in different scenarios. for example

• First, use Charles to quickly capture regular traffic
• When encountering Pinning, switch to Sniffmaster and connect directly to iOS
• Finally, export the data to PCAP and further analyze it using Wireshark

5、 Experience summary

Most problems arise from proxy or certificate configuration, which is the first step in troubleshooting

IOS has stricter requirements for certificates, and trust settings are a detail that many people overlook

SSL Pinning is a key obstacle, and once encountered, specialized tools must be utilized

The combination of tools is the most effective, rather than sticking to a single one.