Flutter SSL Bypass How to Intercept HTTPS Traffic When all o... #1570
+43
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🤖 Automated Content Update
This PR was automatically generated by the HackTricks News Bot based on a technical blog post.
📝 Source Information
🎯 Content Summary
Context: Flutter apps use Dart’s networking stack and bundle BoringSSL inside
libflutter.so, so they typically do not rely on Android’s system CA store. As a result, common Android TLS pinning bypasses (which hook platform APIs) miss the real verification path. The post documents a practical method to intercept HTTPS by directly patching BoringSSL’s certificate verification routine insidelibflutter.so.Problem observed🔧 Technical Details
Hook BoringSSL’s chain verification in Flutter: In Flutter apps, TLS verification occurs inside BoringSSL within
libflutter.so, not the Android system store. Extract the app’slibflutter.so, locatessl_crypto_x509_session_verify_cert_chain(via a string search forssl_clientand XREFs), confirm it takes 3 args and returns a boolean, compute the relative offset from the binary’s base, then Frida-hook that address to always return success. This universally bypasses certificate checks, enabling HTTPS interception regardless of pins or CA trust.Account for architecture differences: Pattern-based hooks often fail cross-arch. Recompute the exact function and offset for the target build and architecture (ARM vs x86_64), and hook by address at runtime rather than relying on static byte patterns.
Proxy redirection is not enough: Even with iptables redirecting traffic ...
🤖 Agent Actions
I analyzed the blog and the existing HackTricks Android/Flutter coverage. The repo already had a Flutter page explaining BoringSSL-based TLS verification and a pattern-scan Frida approach. However, it did not include the offset-based hooking technique to directly replace BoringSSL’s ssl_crypto_x509_session_verify_cert_chain using a base+offset computed from Ghidra, nor the practical workflow to find the function via “ssl_client” string/XREFs, compute the RVA, and hook it with Interceptor.replace. Those details are important when signature scans fail across architectures (e.g., x86_64), which is exactly the blog’s contribution.
What I updated
Why this is the right place
No new files were created, and only one file was modified, preserving existing content and style.
This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.
📚 Repository Maintenance
All .md files have been checked for proper formatting (headers, includes, etc.).