Introduction to SSL Pinning and Frida’s Role

SSL (Secure Sockets Layer) pinning is a security mechanism employed by applications to prevent man-in-the-middle (MitM) attacks. Instead of relying solely on the device’s trust store, applications with SSL pinning verify the server’s certificate or public key against a predefined, hardcoded set of trusted certificates or keys. If the certificate presented by the server during the TLS handshake does not match the pinned ones, the connection is aborted, even if the certificate is otherwise valid and issued by a trusted CA.

For penetration testers and security researchers, SSL pinning presents a significant challenge, as it prevents intercepting application traffic with tools like Burp Suite or OWASP ZAP. Frida, a dynamic instrumentation toolkit, offers a powerful solution by allowing us to inject custom scripts into running processes and modify their behavior at runtime. This enables us to bypass SSL pinning by hooking into the application’s network security mechanisms and disabling or altering their validation logic. This article focuses on troubleshooting common issues encountered when attempting to bypass SSL pinning, specifically for Android applications using the popular OkHttp3 networking library.

Understanding OkHttp3 SSL Pinning Implementation

OkHttp3 is a widely used HTTP client for Android and Java applications. It provides a robust and flexible way to handle network requests, including built-in support for SSL pinning through its CertificatePinner class. Developers can configure an OkHttpClient instance with a CertificatePinner to enforce strict certificate validation rules. The pinning logic typically involves checking the SHA-256 hashes of certificates or public keys against a list of known, trusted hashes.

A typical OkHttp3 pinning configuration might look like this in Java/Kotlin:

OkHttpClient client = new OkHttpClient.Builder().certificatePinner(new CertificatePinner.Builder().add("example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=").add("*.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=").build()).build();

Our goal with Frida is to either replace the CertificatePinner with a benign one, or more commonly, to hook into its internal verification methods and force them to return a ‘true’ or ‘allow’ value, effectively bypassing the pin check.

Prerequisites for Frida Bypass

Before diving into troubleshooting, ensure your setup is correct:

• Rooted Android Device/Emulator: Frida requires root access to inject into system processes.
• Frida Server: The appropriate Frida server binary running on your Android device (e.g., frida-server-16.1.4-android-arm64).
• Frida Client: Installed on your host machine (e.g., pip install frida-tools).
• Proxy Tool: Burp Suite, OWASP ZAP, or similar, configured as a proxy on your host machine.
• Proxy CA Certificate: Installed as a system-trusted certificate on your Android device. This is crucial for your proxy to intercept HTTPS traffic.

Installing Proxy CA Certificate on Android

To install your proxy’s CA certificate (e.g., Burp Suite’s CA cert) as a system trusted certificate:

1. Export the CA certificate from your proxy in DER format (e.g., cacert.der).
2. Convert it to PEM format:openssl x509 -inform DER -in cacert.der -out cacert.pem
3. Get the hash of the certificate:openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1 (e.g., output: 9a5ba575)
4. Rename the PEM file:mv cacert.pem 9a5ba575.0 (replace hash with your own)
5. Push to the device’s system trust store:adb rootadb disable-verityadb remountadb push 9a5ba575.0 /system/etc/security/cacerts/adb reboot

Common Frida SSL Pinning Bypass Scripts for OkHttp3

A widely used Frida script for OkHttp3 bypass targets the CertificatePinner class directly. This script often aims to overwrite or nullify the pinning logic:

Java.perform(function() { try { var CertificatePinner = Java.use('okhttp3.CertificatePinner'); CertificatePinner.check.overload('java.lang.String', 'java.util.List').implementation = function(hostname, peerCertificates) { console.log('Bypassing CertificatePinner.check for: ' + hostname); // Simply call the original check without arguments, effectively bypassing the pin check this.check(hostname, peerCertificates); }; console.log('OkHttp3 CertificatePinner bypass applied!'); } catch (e) { console.log('Error applying OkHttp3 CertificatePinner bypass: ' + e.message); } try { // Additional bypass for TrustManager if default doesn't work var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager'); var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl'); TrustManagerImpl.checkTrustedRecursive.implementation = function(a, b, c, d) { console.log('Bypassing TrustManagerImpl.checkTrustedRecursive...'); return Java.array('java.security.cert.X509Certificate', []); }; console.log('TrustManagerImpl bypass applied!'); } catch (e) { console.log('Error applying TrustManagerImpl bypass: ' + e.message); }});

To run this script:frida -U -f com.example.appname -l your_script.js --no-pause

Troubleshooting Common Errors

Error 1: SSLHandshakeException: java.security.cert.CertPathValidatorException

This is the most common error, indicating that despite the Frida script, the application is still failing to validate your proxy’s SSL certificate.

Causes:

1. Proxy CA not system-trusted: The application might be using a default TrustManager that respects the system trust store, but your CA certificate wasn’t installed correctly or isn’t trusted by the app’s specific configuration.
2. OkHttp3’s aggressive pinning: The script might not be comprehensive enough to handle all pinning scenarios or custom TrustManager implementations.
3. Network Security Configuration (Android 7+): The app might explicitly disallow user-added CA certificates via its network_security_config.xml.

Solutions:

• Verify CA Installation: Double-check the steps for pushing the CA certificate to /system/etc/security/cacerts/. After reboot, confirm its presence and permissions.
• Enhance Frida Script: The basic CertificatePinner.check bypass might not be enough. Add hooks for TrustManager methods. The script above includes a TrustManagerImpl bypass, which is often crucial.
• Target TrustManagerImpl (if `CertificatePinner` fails): If the app uses a custom TrustManager or older Android versions, you might need to target javax.net.ssl.X509TrustManager directly.Java.use('javax.net.ssl.X509TrustManager').checkClientTrusted.implementation = function(chain, authType) {};Java.use('javax.net.ssl.X509TrustManager').checkServerTrusted.implementation = function(chain, authType) {};Java.use('javax.net.ssl.X509TrustManager').getAcceptedIssuers.implementation = function() { return []; };
• Bypass Network Security Configuration (NSC): For Android 7+ apps, NSC can restrict trusted CAs. Frida can sometimes bypass this by hooking android.security.net.config.NetworkSecurityConfig.is CleartextTrafficPermitted or by targeting the classes that load the configuration. However, more robust solutions often involve repacking the APK with a modified NSC or dynamic hooking of certificate validation.

Error 2: Script Not Attaching/Hooking (No output, no bypass)

The Frida script runs, but no console messages appear, and traffic isn’t intercepted.

Causes:

1. Incorrect Package Name: The app’s package name (`com.example.appname`) is wrong.
2. App Process Not Running: The app isn’t active or hasn’t started its network operations.
3. Frida Server Issues: Frida server isn’t running or accessible.
4. Timing Issues: The hook executes before the target class is loaded.

Solutions:

• Verify Package Name: Use adb shell pm list packages | grep 'appname' or frida-ps -Uai to get the exact package name.
• Ensure App is Active: Launch the app and navigate to relevant sections to trigger network requests.
• Check Frida Server:adb shell
  
  Android Mobile Specs & Compare Directory

  Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!

  Compare Devices Specs →