Bypassing SSL Pinning on iOS Applications

SSL pinning is one of the most common security controls developers implement to protect mobile applications from man-in-the-middle (MITM) attacks. On iOS, it prevents attackers and security researchers from intercepting encrypted traffic even when a custom root certificate is installed on the device. But during a penetration test, bypassing SSL pinning is often a critical step to analyzing what an application is actually sending and receiving.

This guide walks through how SSL pinning works on iOS, why it matters from an attacker's perspective, and the practical techniques and commands used to bypass it during a mobile application security assessment. Whether you are a seasoned pentester or just getting started with iOS application security, this guide gives you the hands-on knowledge to move past SSL pinning effectively.

If you are looking for expert-led mobile application penetration testing, the team at Redfox Cybersecurity specializes in iOS and Android security assessments that go far beyond surface-level scanning.

What Is SSL Pinning and Why Do iOS Apps Use It

SSL/TLS pinning is a technique that hardcodes the server's certificate or public key directly into the mobile application. When the app makes a network request, it validates the certificate returned by the server against the pinned value. If there is a mismatch, the connection is rejected.

On iOS, SSL pinning is typically implemented in one of three ways:

• Certificate Pinning, where the app stores the full certificate and compares it byte-for-byte with the server's presented certificate.
• Public Key Pinning, where only the public key is stored, gives developers more flexibility when rotating certificates without updating the app.
• SPKI Pinning (Subject Public Key Info), which hashes the public key and compares the hash, offering a more robust method of comparison.

Developers use SSL pinning to prevent tools like Burp Suite or Charles Proxy from intercepting application traffic, even when the user has trusted a custom CA certificate. This is why bypassing it is a necessary skill during a mobile pentest.

Setting Up Your iOS Pentest Environment

Before attempting any bypass, you need a properly configured environment. SSL pinning bypass on iOS requires a jailbroken device or, in some cases, a repackaged application.

Requirements:

A jailbroken iOS device running checkra1n, unc0ver, or Dopamine depending on your iOS version. A working installation of Frida and Objection on your host machine. Burp Suite configured as an intercepting proxy. SSH access to the jailbroken device over USB using iproxy.

Install Frida on the iOS device via Cydia or Sileo:

Add the Frida repository: https://build.frida.re

Install the Frida package for your device architecture (arm64 for modern iPhones).

On your host machine, install the Frida CLI tools:

pip3 install frida-tools objection


[cta]

Verify Frida is running on the device:

frida-ps -U


[cta]

This lists all running processes on the USB-connected device. If you see output, your Frida setup is working correctly.

For a professionally executed assessment that handles environment setup, testing, and reporting, consider reaching out to Redfox Cybersecurity's mobile pentest team.

How to Bypass SSL Pinning Using Objection

Objection is a runtime mobile exploration toolkit built on top of Frida. It provides a one-command SSL pinning bypass that works against most standard implementations.

Step 1: Forward the device port over USB using iproxy

iproxy 2222 22


[cta]

Step 2: SSH into the device

ssh -p 2222 root@127.0.0.1


[cta]

Default password for most jailbreaks is alpine.

Step 3: Identify the target application's bundle identifier

frida-ps -Uai | grep -i "appname"


[cta]

Replace appname with the application name you are targeting. This returns the bundle ID, such as com.example.targetapp.

Step 4: Launch the application with Objection

objection --gadget com.example.targetapp explore


[cta]

Step 5: Bypass SSL pinning with a single command

iOS sslpinning disable


[cta]

Objection hooks into the application's TrustKit, AFNetworking, Alamofire, and NSURLSession delegates and patches them at runtime to accept any certificate. After running this, route your device traffic through Burp Suite and you should begin seeing decrypted HTTPS requests.

Bypassing SSL Pinning with a Custom Frida Script

When Objection does not work (due to custom pinning implementations or obfuscation), writing a targeted Frida script gives you granular control. Below is a widely used generic Frida script that patches multiple SSL pinning methods on iOS.

Create a file called ssl_bypass.js:

setTimeout(function(){
 var X509Certificate = ObjC.classes.X509Certificate;
 var SSLContext = ObjC.classes.SSLContext;

 // Hook SecTrustEvaluate
 var SecTrustEvaluate = Module.findExportByName("Security", "SecTrustEvaluate");
 if (SecTrustEvaluate) {
   Interceptor.replace(SecTrustEvaluate, new NativeCallback(function(trust, result) {
     Memory.writeU32(result, 1);
     return 0;
   }, 'int', ['pointer', 'pointer']));
   console.log("[+] Hooked SecTrustEvaluate");
 }

 // Hook SecTrustEvaluateWithError (iOS 12+)
 var SecTrustEvaluateWithError = Module.findExportByName("Security", "SecTrustEvaluateWithError");
 if (SecTrustEvaluateWithError) {
   Interceptor.replace(SecTrustEvaluateWithError, new NativeCallback(function(trust, error) {
     if (!error.isNull()) {
       Memory.writePointer(error, NULL);
     }
     return 1;
   }, 'bool', ['pointer', 'pointer']));
   console.log("[+] Hooked SecTrustEvaluateWithError");
 }

}, 0);


[cta]

Run the script against the running application:

frida -U -l ssl_bypass.js -f com.example.targetapp --no-pause


[cta]

Or attach to an already running process:

frida -U -l ssl_bypass.js com.example.targetapp


[cta]

Watch the console for confirmation that the hooks were applied. Then open Burp Suite and browse the application. If traffic appears, the bypass was successful.

Custom pinning implementations may require reverse engineering the binary first using tools like Hopper Disassembler or Ghidra to identify the exact method being hooked.

Using SSL Kill Switch 2 for a Tweak-Based Bypass

SSL Kill Switch 2 is a Cydia/Sileo tweak that patches the low-level SecureTransport and NSURLSession APIs system-wide. This approach is useful when you want a persistent bypass without running Frida each session.

Install SSL Kill Switch 2:

Add the following repo in Cydia or Sileo: https://julioverne.github.io

Search for "SSL Kill Switch 2" and install it. After installation, go to iOS Settings, scroll down to SSL Kill Switch 2, and toggle on "Disable Certificate Validation."

Respring the device:

killall -9 SpringBoard


[cta]

Once active, all applications on the device that rely on standard iOS networking APIs will have their certificate validation bypassed. This is a blunt instrument and works well during exploratory testing sessions.

Do note that applications using custom TLS stacks (such as those built with BoringSSL or using certificate transparency checks) may not be affected by this tweak and will require Frida-based hooking instead.

Dealing with Advanced Pinning Implementations

Some applications implement pinning at the native library level using custom OpenSSL or BoringSSL builds, making Objection and standard Frida scripts ineffective. Here is how to approach those cases.

Step 1: Identify the native library being used

frida -U -e "Process.enumerateModules().forEach(function(m){ console.log(m.name); })" com.example.targetapp


[cta]

Look for modules like libssl.dylib, libboringssl.dylib, or any custom .dylib that handles TLS.

Step 2: Find the SSL verification function

frida-trace -U -i "*SSL*verify*" com.example.targetapp


[cta]

This traces all calls to functions with SSL and verify in the name. Identify which function is handling certificate validation.

Step 3: Hook the specific function

var targetLib = Module.findBaseAddress("libcustomssl.dylib");
var verifyOffset = 0x12345; // obtained from static analysis

Interceptor.attach(targetLib.add(verifyOffset), {
 onLeave: function(retval) {
   retval.replace(0); // Force return value to success
   console.log("[+] Custom SSL verify hooked");
 }
});


[cta]

This level of analysis often involves static reverse engineering alongside dynamic instrumentation, which is the kind of deep-dive mobile security work the team at Redfox Cybersecurity performs during full-scope iOS application assessments.

Configuring Burp Suite to Intercept iOS Traffic

Once SSL pinning is bypassed, you need to route traffic through an intercepting proxy.

Configure Burp Suite to listen on all interfaces:

Go to Proxy > Options > Add a listener on 0.0.0.0:8080.

On the iOS device, set the HTTP proxy:

Go to Settings > Wi-Fi > Your Network > Configure Proxy > Manual. Enter your host machine's IP address and port 8080.

Install Burp's CA certificate (needed for HTTPS decryption):

Visit http://burpsuite from Safari on the device. Download and install the certificate, then go to Settings > General > About > Certificate Trust Settings and enable full trust for the Burp CA.

Now with the pinning bypass active, Burp will intercept and decrypt all HTTPS traffic from the target application. You can inspect request headers, authentication tokens, API endpoints, and sensitive data in cleartext.

Common Issues and How to Resolve Them

Frida server not responding: Confirm the Frida server is running on the device with the correct architecture version.

ps aux | grep frida-server


[cta]

If not running, start it manually:

/usr/sbin/frida-server &


[cta]

‍Objection exits immediately: The application may be crashing due to jailbreak detection. Use the --startup-command flag and add jailbreak bypass hooks before the pinning bypass.

objection --gadget com.example.targetapp explore --startup-command "ios jailbreak disable"


[cta]

‍Traffic still not appearing in Burp: Confirm the proxy settings are correctly applied on the device and that Burp is listening on the correct interface. Also verify the bypass script is actually running without errors in the Frida console.

Application uses certificate transparency: Some apps check Certificate Transparency logs in addition to pinning. This requires patching the specific CT validation logic, which is best approached through static analysis first.

Legal and Ethical Considerations

SSL pinning bypass and mobile application penetration testing must only be performed on applications you own, have written authorization to test, or are operating in a dedicated lab environment. Unauthorized interception of network traffic is illegal in most jurisdictions under computer fraud and abuse laws.

Always obtain a signed scope-of-work and rules of engagement before conducting any mobile security assessment. If your organization needs a professionally conducted iOS application pentest with full compliance documentation and a detailed remediation report, Redfox Cybersecurity delivers exactly that.

Final Thoughts

Bypassing SSL pinning on iOS applications is a foundational skill in mobile application penetration testing. The methods covered here, from Objection's one-liner to custom Frida scripts targeting native libraries, cover the vast majority of pinning implementations you will encounter in the field. The key is understanding which layer the pinning is implemented at, and selecting the right tool for that layer.

As applications grow more security-conscious, so do their pinning implementations. Staying ahead requires a combination of dynamic instrumentation, static reverse engineering, and deep familiarity with the iOS security model.

If your organization builds iOS applications and wants to know whether your SSL pinning implementation holds up against a skilled attacker, the experts at Redfox Cybersecurity can put it to the test and provide actionable guidance on hardening your mobile security posture.