The purpose of SSL Pinning
In a standard HTTPS connection, the client trusts the server if its certificate is signed by a root Certificate Authority (CA) pre-installed on the device. Attackers exploit this by installing their own custom CA certificate onto a victim's phone (or their own rooted testing phone), allowing them to perform a Man-in-the-Middle (MitM) attack and read the encrypted traffic.
SSL Certificate Pinning solves this by hardcoding the expected certificate's hash directly into the mobile app's code. If the certificate presented by the server during the TLS handshake does not exactly match the hardcoded hash, the app drops the connection. This effectively blocks tools like Burp Suite or Charles Proxy.
How we bypass your SSL Pinning
During a mobile penetration test, bypassing SSL Pinning is always Step 1. If we cannot read the API traffic, we cannot test the backend for business logic flaws. We do not try to crack the encryption; we attack the application's memory.
1. Frida and Dynamic Hooking
We install the target app on a rooted Android device running the Frida server. We write a small JavaScript script that "hooks" into the Java/Kotlin function responsible for checking the certificate (e.g., `TrustManager` or `OkHttp`). When the app runs that function, our script intercepts the execution and forces the function to return `true` (valid), regardless of the actual certificate.
2. Objection Toolkit
Objection is a runtime mobile exploration toolkit powered by Frida. It comes with pre-built scripts to bypass pinning in almost every major networking library (OkHttp, Retrofit, Volley, Alamofire). In many cases, bypassing the pinning requires running a single command: `android sslpinning disable`.
3. Binary Patching (Re-packaging)
If the app uses a custom C++ library for networking (making Frida hooks difficult), we decompile the APK using `apktool`. We locate the hardcoded certificate hash in the smali code, replace it with the hash of our Burp Suite certificate, recompile the APK, sign it with our own developer key, and install it on the device.
Building Defense-in-Depth for Mobile APIs
Because SSL Pinning can always be bypassed by an attacker who controls the physical device, your backend APIs must assume the mobile client is compromised. You must implement Defense-in-Depth.
1. Payload Encryption (JWE)
Do not rely solely on the TLS tunnel for confidentiality. Implement Application-Layer Encryption. Encrypt sensitive payloads (like the login credentials or the transaction PIN) using JSON Web Encryption (JWE) before they leave the device. Even if the attacker bypasses SSL Pinning and intercepts the HTTP request in Burp Suite, they will only see a heavily encrypted blob, not the plaintext PIN.
2. Robust Root & Jailbreak Detection
To use Frida or Objection, the attacker needs a rooted or jailbroken device. Implement strong runtime protection (like `SafetyNet/Play Integrity` on Android and `DeviceCheck` on iOS) to detect compromised operating systems. If root is detected, the app must refuse to launch. While root detection can also be bypassed, layering it with SSL Pinning forces the attacker to spend days writing custom bypass scripts rather than minutes.
3. Obfuscation of the Pinning Logic
If you write a standard implementation of OkHttp pinning, automated tools like Objection will bypass it instantly. Write your own custom `TrustManager` wrapper, and heavily obfuscate the code using tools like ProGuard/R8 (or Jscrambler for React Native). This breaks the automated scripts and forces the attacker to manually reverse-engineer your obfuscated bytecode.
Is your backend API vulnerable once your SSL pinning is bypassed?
Book a Mobile App PentestThe Pentester's Perspective
When a client asks, "Why did you bypass our security controls during the test?" we explain that our job is to emulate a motivated attacker. If an attacker wants to steal money from your platform, they will bypass the client-side pinning to find the server-side vulnerabilities. Your security must live on the server, not on the phone.
Frequently asked questions
What is SSL Pinning?
Normally, a mobile app trusts any server presenting a certificate signed by a recognized Certificate Authority (CA). SSL Pinning forces the app to trust *only* the specific certificate or public key belonging to your API server, rejecting all others, even if they are signed by a trusted CA.
Why do attackers want to bypass SSL Pinning?
To find vulnerabilities in your backend API, attackers must intercept the traffic between the mobile app and the server. They use tools like Burp Suite as a proxy. SSL Pinning prevents this proxy connection. By bypassing the pinning, they can read and modify the API requests in plaintext.
How do attackers bypass SSL Pinning?
Attackers install the app on a rooted (Android) or jailbroken (iOS) device. They then use dynamic instrumentation frameworks like Frida or Xposed to hook into the application's memory while it is running, overriding the function that checks the certificate and forcing it to return 'True'.
If it can be bypassed, should we still implement SSL Pinning?
Yes. SSL Pinning is a critical baseline defense. While a determined attacker with a rooted device will bypass it, pinning stops 99% of casual script kiddies and protects your legitimate users from being attacked on malicious public Wi-Fi networks.
Related reading
Blog: Flutter Security Audit · React Native Security
Guides: Fintech Security Checklist · OWASP for Fintech
Services: Penetration Testing · API Security Testing