Yesterday, I was analyzing an Android application which uses OkHttp for certificate pinning. It took me hours to analyze the app, and have tried different methods to circumvent the app’s certificate pinning implementation. If I had only been monitoring the system log while running the app, I could have done it in just a matter of minutes. I might have wasted a lot of time and effort, but at least I’ve learned.
Here’s my write up on how I bypassed OkHttp’s Certificate Pinning implementation.
Attempt #1: Using Xposed Modules
Since I had Xposed running on my test device, I first used the modules SSLUnpinning and TrustMeAlready. I know these modules are outdated, but it might still work. Unfortunately, it didn’t work on the app that I’m testing.
Attempt #2: Using Frida Scripts
My second attempt involved the use of Frida. After setting it up on my test device, I immediately tried the “most popular” Frida script on CodeShare which is the Universal Android SSL Pinning Bypass script. But what I got was just an error.
NOTE: The reason I got the error because I forgot to copy Burp’s cert into
/data/local/tmp/cert-der.crt. Anyway, fixing the error still didn’t solve my problem of bypassing the app’s cert pinning implementation.
I tried another script but no luck as well. It did not even successfully detect the certificate pinning implementation used by the app.
I ended up trying all Frida scripts from CodeShare related to certificate pinning bypass but none of them worked.
Attempt #3: Via Manual Modification
Basically, the app checks for these fingerprints. If the fingerprint from the certificate chain matches one of the pinned fingerprints, then the peer’s identity has been verified and SSL pinning can be bypassed.
Before I could inject Burp’s certificate fingerprint, I first decompiled the app and look for the file where these pinned certificates were located. From the output below, the pinned fingerprints were located in
Lesson Learned: Always keep an eye on the system log while running the target application.