Fluttida
Frida scripts for Flutter apps that enable proxy support including sandbox flutter app. This repo demonstrates how to redirect and intercept Flutter app traffic (dart:io, Cupertino, NSURLSession, etc.) through a proxy (Burp, mitmproxy) using Frida, with detection scripts to identify the active networking stack.
Install / Use
/learn @XDcobra/FluttidaREADME
Fluttida – Intercepting Flutter App Traffic with Frida
This repository provides tools and Frida scripts to analyze, intercept and forward network traffic from Flutter applications via Frida. Because Flutter often bypasses system proxy settings and uses custom networking stacks, standard proxy interception fails. The scripts here help identify which client (e.g. dart:io, NSURLSession, NSURLConnection, or WKWebView) is in use and redirect traffic through a proxy for effective reverse engineering.
Quick Start
- Install mitmproxy or Burp Suite on your analysis machine.
- Export and install the proxy’s CA certificate on your iOS device, then enable full trust under Settings --> General --> About --> Certificate Trust Settings.
- Configure your iPhone’s Wi‑Fi proxy manually to point to your machine’s IP and chosen port (e.g.
192.168.1.5:8889). - Run the proxy in standard mode (
mitmproxy -p 8889) or Burp with an “Invisible Proxy” listener. - Use Frida hooks to redirect Dart’s
connect()calls to the proxy (e.g.frida -n YourApp -l intercept_dartio.js) - Refresh the app and watch requests appear in your proxy.
- If traffic is still missing, check which networking stack the app uses by running any of the scripts within the frida_detect_engine folder (Dart:io, Cupertino/NSURLSession, NSURLConnection, WKWebView) and apply the corresponding hook.
Why Flutter Apps Cannot Be Intercepted with a Standard Proxy
Flutter simplifies cross‑platform development, but when it comes to network traffic, it introduces complexities that make traditional proxy interception unreliable. This document explains in detail why Flutter apps often bypass normal proxy setups, the technical background behind it, and what approaches can still work.
Overview
Flutter apps can use different networking stacks depending on the code path. The most common is the Dart‑based dart:io HttpClient. Unlike native iOS/Android clients, dart:io often ignores system proxy settings and does not perform the expected proxy handshake, which breaks standard interception with tools like Burp or mitmproxy.
- Core issue: Many Flutter apps connect directly to target hosts without sending a CONNECT request to the proxy.
- Result: Proxies see no traffic, TLS connections fail, or only raw socket streams appear without host context.
- Workarounds: Transparent interception (NAT/pf/iptables), manual proxy configuration plus hooks, installing custom CA certificates, and bypassing certificate pinning.
This repo includes several scripts to make reverse engineering of flutter APIs easier.
<div align="center">| Engine / Library | Detection (iOS) | Detection (Android) | Intercept (iOS) | Intercept (Android) | |----------------------------------|----------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|-------------------------------------------------------------|----------------------------------------------------------------| | dart:io HttpClient | frida_detect_engine/check_dartio.js | Coming soon | intercept_dartio.js | intercept_dartio.js | | package:http (default / IOClient)| Coming soon | Coming soon | Coming soon | Coming soon | | package:http via IOClient | Coming soon | Coming soon | Coming soon | Coming soon | | cupertino_http (NSURLSession) | frida_detect_engine/check_cupertino.js| N/A | Coming soon | N/A | | NSURLConnection / CFURL | frida_detect_engine/check_nsurl.js | N/A | Coming soon | N/A | | WKWebView / WebView | frida_detect_engine/check_webview.js | Coming soon | Coming soon | Coming soon | | Android HttpURLConnection | N/A | Coming soon | N/A | Coming soon | | Android OkHttp | N/A | Coming soon | N/A | Coming soon | | Android Cronet (embedded) | N/A | Coming soon | N/A | Coming soon | | libcurl (native) | Coming soon | Coming soon | Coming soon | Coming soon |
</div>Technical Background
Dart:io HttpClient vs. Standard Proxy Usage
- No CONNECT handshake unless explicitly configured.
- System proxy often ignored.
- Direct socket calls bypass proxy‑aware APIs.
Alternative Stacks
- Cupertino HTTP (NSURLSession) – may respect system proxy, but often configured to bypass.
- WebView (WKWebView) – traffic depends on WebKit and system settings.
- Native bridges – custom ObjC/Swift/Java networking stacks may ignore proxy.
TLS, HTTP/2, Certificates, and Pinning
- Direct TLS connections cannot be intercepted by a standard proxy.
- HTTP/2 and ALPN negotiation requires proper TLS termination.
- ATS and certificate pinning block interception unless bypassed (see accept_all_certs.js for a general ssl pinning bypass)
- IPv6 and QUIC/HTTP/3 introduce additional challenges.
Symptoms in Practice
- Proxy shows no traffic.
- mitmproxy transparent mode errors (“cannot resolve original destination”).
- TLS handshake failures.
- Partial visibility (only WebView traffic intercepted).
Working Approaches
System Proxy + Hooks
- Manual proxy in Wi‑Fi settings.
- Frida hook on
connect()to force Dart traffic through proxy. - Install and trust proxy CA.
- Bypass certificate pinning.
Transparent Interception (Linux/macOS)
- Use
pforiptablesto redirect traffic. - Run mitmproxy in transparent mode.
- On Windows, use WSL or Burp Invisible Proxy mode.
Detecting Which Stack Is Used
- Dart:io: Hook
connect()inlibsystem_kernel.dylib. - Cupertino/NSURLSession: Hook
-[NSURLSession dataTaskWithRequest:completionHandler:]. - NSURLConnection/CFNetwork: Hook
+[NSURLConnection sendSynchronousRequest:returningResponse:error:]orCFURLConnectionCreateWithRequest. - WebView: Hook
-[WKWebView loadRequest:].
Example App: Fluttida (example_app/fluttida)
| | | | |
|---|---:|---:|:---|
| 
| 