disable-flutter-tls-verification patches BoringSSL in a running Flutter app

Why Flutter needs a different interception approach

A Flutter application is not a normal Android or iOS app on the network layer. Its HTTP stack is Dart code running inside the Flutter engine, and it does not use the operating system's proxy settings by default, which means the usual trick of pointing a device at a proxy does not necessarily expose its traffic. The README states this directly, and it is the reason a project like this exists at all.

The consequence for an analyst is that interception has to happen below the Dart layer, at the point where the engine talks to OpenSSL or BoringSSL. The script here works by pattern matching to find ssl_verify_peer_cert in the BoringSSL handshake.cc source, then patching that function at runtime so that certificate verification stops rejecting the chain.

This is not a proxy, and it does not decrypt anything by itself. It removes the check that would cause the connection to fail, so that a proxy the analyst controls, or a rogue access point, can sit in the path and see the plaintext. The interception is still done by other tooling; this project removes the obstacle that Flutter puts in the way of that tooling.

The intended audience is security researchers and app testers working on applications they are permitted to test. The repository belongs to NVISOsecurity, a security firm, and the README links a blog post on intercepting Flutter traffic on iOS and Android covering HTTP, HTTPS and certificate pinning, which gives the technique its context.

Pattern matching is what makes the script portable across builds

The mechanism has a clear limitation and a clear advantage, and both follow from the same choice. The script does not look for a fixed address or a fixed offset. It searches the loaded library for a pattern that identifies the ssl_verify_peer_cert function, using the shape of the compiled code rather than a build-specific address.

The advantage is that the same script works across different builds of the Flutter engine, which matters because every app ships its own copy of libflutter.so on Android or the Flutter framework on iOS. An address-based patch would break on the next app you tested. The cost is that pattern matching is inherently a heuristic: it can find the wrong function if a build changes shape, and it can fail to find anything if the code is compiled differently. The script therefore has a failure mode that is silent in the sense that you get no error, you just do not get intercepted traffic.

The repository is structured around that fragility. Alongside the script itself, disable-flutter-tls.js, there is a libflutter_samples directory holding reference builds of the Flutter engine library, and a test_app directory. A verify.py script is referenced in the troubleshooting steps, which is how a user compares the library in a target app against the known samples and establishes whether the pattern should be expected to match at all.

The primary language of the repository is listed as C++, which fits a project whose payload is a native function patch, and the top-level entries are minimal: a .github directory, the README, the script, the samples and the test app.

Running the script with Frida on a device

There are two documented ways to use the script, and both are Frida command lines. The first is to download disable-flutter-tls.js and pass it to the frida client while spawning the target process:

frida -U -f your.package.name -l disable-flutter-tls.js --no-pause

The -U flag selects the USB device, -f names the package to spawn, -l loads the script, and --no-pause means the process is not held at startup while you attach.

The second route uses Frida codeshare, which fetches the script from the codeshare server by author and name, so there is nothing to download:

frida -U --codeshare TheDauntless/disable-flutter-tls-v1 -f YOUR_BINARY

Note that the codeshare identifier carries a v1 suffix while the file in the repository is named disable-flutter-tls.js without a version, which is a small indication that the published version and the repository file are not guaranteed to be the same thing at any given moment.

The script works on Android x86, Android x64 and iOS x64, as the README states. That platform list is narrow by nature, since it covers the architectures an analyst typically has on a laptop, and it says nothing about arm64 devices or Android arm images, so a test on a physical phone is not what this tool was written for.

The troubleshooting checklist tells you when the script is not the problem

The README has a section titled What if this script doesn't work, and it is the most useful part of the document for anyone about to spend an hour wondering whether the patch failed. The first check is whether you can intercept plain HTTP requests from the demo application. If you cannot, the problem is upstream of this script, because Flutter apps do not use the system's proxy settings by default, and the README points to Proxydroid on Android, OpenVPN on iOS, or a rogue access point on both. On Android Studio AVDs you can use the -http-proxy option when launching the emulator.

The second check is whether you can intercept HTTPS from the demo app at all. The third is whether your app's flutter library is inside the libflutter_samples directory, which is established by comparing the library in the app against the known samples. The README gives platform specific commands for that: on Android you run apktool d on your APK and then run md5sum on the library under the architecture directory in libs, and on iOS you extract an unencrypted IPA, unzip it and run md5sum on the Flutter binary inside Payload/Runner.app/Frameworks/Flutter.framework. Alternatively you copy the library into the right folder in libflutter_samples and run python3 verify.py.

The logic of the final step is worth stating plainly. If all requests from the demo app are intercepted and your library is not in the samples, then you are told to open a GitHub issue. If some requests are intercepted but others are not, the README's explanation is that the app is probably using additional SSL pinning plugins, and that a combination of this plugin with objection or other Frida scripts may be necessary. That is explicitly called outside the scope of this project, with the reader told to reverse engineer it themselves.

What the project does not cover

The boundaries are stated, which is unusual and helpful. Platform support is limited to Android x86, Android x64 and iOS x64, so a target running on arm64 hardware is outside what the script claims to handle. Additional certificate pinning implemented through a plugin is outside the scope, and the README is candid that reversing those protections is left to the reader.

The script also does not give you the traffic. It disables verification; it does not proxy, intercept, decrypt, log or present a certificate. If you expected a one-command interception setup, this is not it. The README's structure makes that dependency explicit, since the very first troubleshooting bullet asks whether you can intercept HTTP requests, which presupposes separate interception tooling.

There is also no release process. The repository has no GitHub releases, and the only version marker is the v1 in the codeshare identifier. The last push was on 2026-06-17, and the repository is not archived. The licence is not stated in the repository facts available here, which is a genuine consideration for a security firm distributing a script that others will build on, and it is a question to settle with the project rather than to assume.

None of this makes the project wrong for its purpose. It is a small, single-file patch that solves one specific obstacle, and the surrounding documentation spends most of its length on the cases where the obstacle is not the one you are hitting.

How this compares with a proxy plus a pinning bypass

The alternative approach is the one the README itself points at: a traffic interception proxy on the path, combined with separate tooling that handles any pinning the application adds. The difference in approach is about where the work happens.

A proxy and a pinning bypass work at the network and application layers respectively, and they require you to understand what the app is doing to its certificate checks. This script works one layer lower, inside the engine's own copy of BoringSSL, and it is version-independent within the architectures it supports because it locates the function by pattern rather than by address. Its advantage is that it handles a case where the app has no extra pinning plugin at all, where the only thing in the way is Flutter's own strict verification, and where a proxy would fail for reasons that have nothing to do with the app's design.

The difference in cost is real. This script is one file and two commands. A proxy setup with per-app pinning handling is a running infrastructure, a certificate to install, a device to configure and a set of app-specific workarounds. For a quick look at one application's HTTPS traffic on an x86 emulator, the single file wins on setup and loses on coverage.

The other alternative is not to work around the verification at all. Where you control the app, a debug build with the app's own network security configuration relaxed, or a test build pointing at a trusted proxy, gives you the same visibility without patching a third party's binary in memory. That is the right approach for your own product, and this script is the right approach for the case where the app is not yours and you have permission to test it.

Editorial conclusion

Adopt this script if you are authorised to test a Flutter application and need its HTTPS traffic visible, particularly on Android x86 or x64 or iOS x64 simulators and emulators, and if you are prepared to check the BoringSSL build yourself with the libflutter_samples comparison the README describes. Do not adopt it for a production mobile application, because the result is a build with no certificate validation, and do not expect it to defeat an app that adds an extra pinning plugin, which the README places outside the project's scope. Verify first that the frida command attaches to your target, that your libflutter.so or Flutter binary matches a library in libflutter_samples, and that the app is not using additional SSL pinning plugins before concluding that the script failed.

Frequently asked questions

Official sources

1. Issues
2. NVISOsecurity/disable-flutter-tls-verification on GitHub
3. README