A Frida toolkit that neutralizes SSL/TLS certificate pinning across Android's Java and native layers, built for authorized mobile audits and lab traffic inspection.

Certificate pinning is the single most common obstacle in authorized mobile application assessments: even with a proxy CA installed on a rooted test device, the target app refuses to negotiate TLS because it validates the server certificate against a hardcoded expectation. danieldev23/frida-ssl-bypass is a compact Frida toolkit written in JavaScript that removes this obstacle across essentially every layer an Android app can implement pinning in, from the Java TrustManager down to native OpenSSL/BoringSSL calls inside libflutter.so or Facebook's proxygen.

The repository is deliberately minimal in structure. Everything an operator needs is split between a wrapper, run.sh, and two Frida scripts under scripts/: universal_bypass.js, which the README claims works against any Android app, and fb4a_bypass.js, an optimized variant targeting Facebook's Android client with symbols the author says were confirmed via Ghidra. The project ships under the MIT license, sits at a modest 23 stars, and is authored by @danieldev23.

What distinguishes this toolkit from the usual one-off pinning snippets circulating in pentest gists is its coverage table. On the Java side it hooks SSLContext.init() to inject a trust-all manager, forces HostnameVerifier to accept everything, no-ops CertificatePinner.check() including obfuscated OkHttp builds common in banking apps, neutralizes the Conscrypt provider, teaches NetworkSecurityConfig to trust user-added CAs, auto-proceeds on WebViewClient SSL errors, and covers both legacy Apache HTTP clients and the TrustKit pinning library.

The native layer is where most modern apps actually enforce pinning, and the README addresses this head on. SSL_CTX_set_verify() is forced to SSL_VERIFY_NONE, SSL_get_verify_result() is stubbed to always return X509_V_OK, and SSL_set_custom_verify() has its callback path disabled. Two vendor-specific stubs round it out: verifyWithMetrics() in Facebook's proxygen is replaced with a CModule that returns TRUE, and Flutter's ssl_verify_peer_cert() in the Dart engine returns success. The use of CModule for the proxygen replacement is a nice touch — native stubs compiled in-process avoid the per-call JavaScript bridge overhead, which the README advertises as zero-millisecond overhead.

Module discovery is handled dynamically rather than via hardcoded offsets, which is what makes the universal script plausible across app ecosystems. In attach mode, the script scans already-loaded native modules on injection; in spawn mode, it hooks android_dlopen_ext and dlopen to intercept SSL libraries the moment they are mapped into memory, with a backoff-polling fallback for lazy loaders. This design detail matters for apps that load their crypto stack late or from unpacked, non-standard paths.

Ergonomics are handled by run.sh, which wraps frida-server interaction and script selection behind three flags: -p for the target package, -s to choose between universal and fb4a scripts, and -m to pick attach versus spawn mode. The default package is com.facebook.katana and the default mode is attach, reflecting the author's Facebook research focus. For operators who prefer the raw CLI, standard Frida invocation patterns with -U -f or -U -p and -l scripts/universal_bypass.js work as expected.

The README's tested-applications matrix reads as a tour of hard pinning implementations: Facebook and Instagram with native proxygen and OpenSSL, WhatsApp with its Noise Protocol plus native SSL, Twitter/X with OkHttp pinning, TikTok with custom BoringSSL verification, banking apps using Conscrypt and TrustKit, and cross-platform frameworks where the script hooks the underlying engine (libflutter.so for Flutter, the OkHttp layer for React Native). For an auditor building a mobile testing lab, this matrix doubles as a checklist of pinning techniques worth reviewing in client code.

It is worth noting the boundary the README itself draws: the disclaimer states the project is strictly for security research and education, only on applications you own or have explicit authorization to audit. That is the correct framing. This toolkit does not exploit anything on its own — it requires a rooted device or emulator with frida-server placed in /data/local/tmp/, meaning the operator already has full control of the endpoint. Its sole function is to let an intercepting proxy see the app's own traffic during an authorized engagement.

From a defensive perspective, every technique in this toolkit is also a detection catalogue. Apps that rely solely on Java-layer pinning are trivially bypassed and should layer native verification or integrity checks instead. Runtime signals of this exact toolkit include frida-server artifacts in /data/local/tmp, permissive return values from SSL_get_verify_result() under instrumentation, and dlopen interception patterns — all of which modern mobile anti-tampering SDKs can be configured to flag.

Caveats before adopting it in a workflow: the 23-star project is young, with no published release cadence or CI, and the Facebook-specific script depends on symbols that will break with each significant app update — expect to re-confirm offsets in Ghidra yourself. The universal script's breadth is a strength for auditors and a liability for stability, since hooking obfuscated OkHttp variants relies on heuristic class scanning that will occasionally miss renamed implementations. Still, as an educational reference for how pinning is implemented and defeated at every layer of the Android stack, frida-ssl-bypass is one of the more complete single-repo collections available.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.