#3931·mastg

[Tool Android] FlutterTap - Zygisk module for intercepting Flutter app traffic

Author: script-or-scriptCreated Jul 30, 2026Updated Jul 30, 2026

Tool

FlutterTaphttps://github.com/script-or-script/FlutterTap

Proposing this as an Android testing tool. Opening an issue first, per the contribution guidelines, rather than going straight to a pull request.

Why it fills a gap in the MASTG

The guide covers TLS interception and pinning bypass well, but Flutter apps defeat the standard approach for a structural reason: the Dart engine bundles its own BoringSSL with its own trust chain compiled into libflutter.so, so a CA certificate installed in the Android system store is never consulted. dart:io sockets also ignore the proxy configured on the Wi-Fi network. A tester following the usual procedure sees an empty proxy log with no error to explain it.

Two consequences worth documenting regardless of this tool:

  1. Both problems have to be solved. Bypassing certificate verification alone still leaves the traffic going to its real destination.
  2. @MASTG-TOOL-0027-style Java/ART hooking cannot reach it. verify_cert_chain and GetSockAddr are unexported native functions inside libflutter.so — there is no Java method to intercept.

What the tool does

A Zygisk module (Magisk, KernelSU, SukiSu Ultra, APatch) that, for user-selected apps only:

  • Resolves verify_cert_chain and GetSockAddr at runtime by parsing libflutter.so's ELF segments, scanning for anchor strings and disassembling with Capstone, then hooks them with Dobby.
  • Bypasses the certificate chain verification.
  • Rewrites the destination sockaddr so traffic reaches the tester's proxy, with no CA certificate installed on the device and no repackaging or re-signing of the APK.
  • Unloads itself (DLCLOSE_MODULE_LIBRARY) in every process the tester did not select.

Because it is a module rather than a live instrumentation session, it survives reboots and opens no listening port — relevant when the app under test ships anti-tampering that looks for frida-server.

Details relevant to inclusion criteria

  • License: MIT. Third-party components (Dobby, Apache-2.0; Capstone, BSD-3-Clause) documented in THIRD_PARTY.md, license texts shipped in the release artifact.
  • Source: fully open, both the native module (C++) and the manager app (Kotlin). No obfuscation. A clone plus one script reproduces the released artifact.
  • Platform coverage: Android 10 (API 29) through 17 (API 37), arm64-v8a and x86_64.
  • Validated on hardware: Android 10 (Magisk + NeoZygisk) and Android 17 (SukiSu Ultra + Zygisk Next with its Linker enabled).
  • Documentation: README with an annotated walkthrough, plus docs/ARCHITECTURE.md covering the address resolution and its failure modes.

Honest scope

It complements dynamic instrumentation rather than replacing it — iterating on a native module is far slower than editing a script. And there is a documented limitation: on some libflutter.so builds the GetSockAddr walk can resolve to the wrong function, in which case the certificate bypass still applies but the redirect does not fire. That is described in docs/ARCHITECTURE.md rather than left for a tester to discover.

Next step

If this is of interest, I am happy to write the tools/android/MASTG-TOOL-XXXX.md entry in the established format (frontmatter with title/platform/source, prose in second person and active present) and open the pull request. Please let me know which ID to use, or whether you would prefer it framed as a technique rather than a tool.

Disclosure: I am the author of the tool.