If you think HTTPS alone secures your mobile application, you are mistakenly relying on the user's device integrity. In the world of Mobile Security, the client device is always in the hands of the enemy. I’ve seen countless "secure" banking apps stripped naked by a junior pentester using Burp Suite and a self-signed certificate installed in the user trust store. While SSL Pinning is the industry standard fix for preventing Man-in-the-Middle (MITM) attacks, it is trivially bypassed by dynamic instrumentation tools like Frida unless you actively defend against them.
Analysis: Why Standard Pinning Fails
The concept of SSL Pinning is simple: instead of trusting any Certificate Authority (CA) in the device's root store, your app hardcodes the hash of the expected server certificate (Subject Public Key Info or SPKI). This effectively blocks proxies like Charles or Burp.
However, widely used networking libraries like OkHttp (Android) or Alamofire (iOS) implement pinning in high-level code. An attacker using Frida doesn't need to crack your encryption; they simply need to hook the check() function in the SSL library and force it to return true. This is Frida Defense 101: if your security logic runs in a runtime environment that the attacker controls, the logic can be rewritten.
Step 1: Implementing Robust SSL Pinning
Before we fight Frida, we must establish the baseline pinning. For Android Security, we use OkHttp's `CertificatePinner`. For iOS Security, we use `SecTrust` policies or libraries like TrustKit.
Android (OkHttp)
// Building the OkHttpClient with CertificatePinner
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("api.yourdomain.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
.build();
OkHttpClient client = new OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build();Step 2: The Solution – Native Frida Detection
To stop a Frida bypass script (like the popular frida-multiple-unpinning), we need to detect the presence of the Frida runtime itself. Java/Swift checks are too easy to hook. We must drop down to the Native layer (C/C++) using JNI on Android to inspect the process memory map.
The following C++ code scans `/proc/self/maps` for artifacts related to `frida-agent` or `frida-server`. This is much harder to hook without kernel-level rootkits.
#include <jni.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <android/log.h>
#define LOG_TAG "NativeGuard"
#define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, __VA_ARGS__)
// Native function to check for Frida artifacts in memory maps
extern "C" JNIEXPORT jboolean JNICALL
Java_com_example_security_NativeLib_checkFrida(JNIEnv *env, jobject thiz) {
FILE *fp;
char line[512];
// Open the memory map of the current process
fp = fopen("/proc/self/maps", "r");
if (fp == NULL) {
return JNI_FALSE;
}
while (fgets(line, sizeof(line), fp)) {
// Check for known Frida signatures
if (strstr(line, "frida-agent") || strstr(line, "frida-server") || strstr(line, "re.frida.server")) {
LOGE("Frida detected in memory map: %s", line);
fclose(fp);
// CRITICAL: Do not just return true.
// Attackers can hook this function result.
// Instead, induce a crash or corrupt the session token here.
exit(0);
return JNI_TRUE;
}
}
fclose(fp);
return JNI_FALSE;
}iOS Detection Strategy
For iOS, we look for dynamic libraries injected into the process image (`_dyld_get_image_name`) or check for standard port usage (Frida often uses port 27042).
import MachO
func isFridaRunning() -> Bool {
let count = _dyld_image_count()
for i in 0..<count {
if let imageName = _dyld_get_image_name(i) {
let name = String(cString: imageName)
if name.contains("FridaGadget") {
return true
}
}
}
return false
}| Defense Method | Effectiveness vs Frida | Implementation Cost |
|---|---|---|
| SSL Pinning (Standard) | Low (Easily bypassed) | Low |
| Obfuscation (ProGuard/R8) | Medium (Slows down analysis) | Low |
| Native Detection (JNI/C) | High (Harder to hook) | High |
| Syscall Verification | Very High (Requires Kernel access) | Very High |
Conclusion
Implementing SSL Pinning is mandatory for any fintech or sensitive application, but relying on it alone is negligence. The modern mobile threat landscape requires a "Defense in Depth" approach. By combining certificate pinning with native-level Frida Defense mechanisms, you force attackers to spend significantly more time and resources to reverse engineer your app. Remember, you cannot stop a determined attacker with physical access to the device, but you can make it cost-prohibitive for them to succeed.
Post a Comment