然而，当目标应用使用 Flutter 开发时，事情往往不会这么简单。

不少测试人员都会遇到类似的情况：

• Burp 已开启代理，但始终没有任何请求；
• 手机浏览器可以正常联网，而 Flutter App 一直提示 "No Internet"；
• 安装系统证书、关闭证书校验依然无效；
• 使用常见 Frida SSL Pinning Bypass 脚本也没有任何效果。

很多人第一反应会认为是 SSL Pinning 太强，但实际上，大多数情况下真正的问题并不是某一种证书校验，而是 Flutter 的网络通信机制与传统 Android 应用存在本质区别。

本文结合一次 Flutter 抓包实战，对整个问题进行梳理，希望能够帮助大家少走一些弯路。

一、为什么 Flutter 比普通 Android 更难抓包？

传统 Android 应用的 HTTPS 通信路径通常如下：

App │Java/Kotlin │Android SSL Framework │System CA │HTTPS

整个 TLS 验证流程依赖 Android 系统提供的 SSL Framework。

因此，只要完成以下两步：

• 安装 Burp Suite CA 证书；
• 让应用信任系统证书；

大多数应用便可以正常抓包。

而 Flutter 完全不同。

Flutter 的网络通信路径更接近下面这种结构：

Flutter App │Dart Runtime │libflutter.so │BoringSSL │TLS

可以看到，Flutter 并没有直接使用 Android 系统的 TLS 实现，而是依赖 BoringSSL 完成 HTTPS 通信。

也就是说：

即使系统已经信任 Burp CA，Flutter 也未必会信任。

这也是很多人在第一次测试 Flutter 应用时最容易踩到的坑。

二、为什么安装 Burp 证书没有任何作用？

很多安全测试人员都会经历下面这个过程：

第一步：

安装 Burp CA。

第二步：

浏览器访问 HTTPS 正常。

第三步：

启动 Flutter App。

结果：

No Internet

或者一直请求失败。

原因就在于：

Flutter 并不会读取 Android 系统证书库，而是在 BoringSSL 中完成自己的证书验证。

因此：

系统证书×Flutter TLS

两者之间并不存在必然联系。

所以：

安装系统 CA 并不能解决 Flutter HTTPS 抓包问题。

三、ReFlutter 为什么有时候仍然抓不到流量？

很多人接下来会尝试 ReFlutter。

它可以修改 Flutter Engine，对 libflutter.so 进行 Patch，从而绕过 Flutter 层的 TLS 校验。

按理来说，这一步已经足够。

但实际测试中，仍然会遇到下面的问题：

Burp 没有任何请求App 提示 No Internet

为什么？

原因是：

很多应用真正的启动流程并不是：

Flutter↓HTTPS

而是：

Java 初始化↓网络检测↓证书验证↓Flutter 初始化↓真正业务请求

如果 Java 层已经判定网络不可用，那么 Flutter 根本不会发起后续请求。

也就是说：

即使 Flutter TLS 已经成功绕过，

Java 层仍然可能提前终止整个流程。

因此，仅修改 Flutter Engine 并不能解决所有问题。

四、真正需要绕过的，不只是 Flutter

经过多次测试后，可以发现，一个完整的 Flutter App 实际上可能同时存在多个证书验证点。

例如：

Flutter BoringSSL+Java TrustManager+HostnameVerifier+WebView+Flutter InAppWebView

任何一层没有绕过，都可能导致抓包失败。

因此，一个成熟的抓包方案，需要覆盖整个通信链，而不仅仅是 Flutter 本身。

五、Flutter TLS 层如何处理？

Flutter HTTPS 最核心的验证逻辑位于：

libflutter.so

其中最关键的函数就是：

ssl_verify_peer_cert()

它负责验证服务器证书是否合法。

很多 Frida 脚本都会直接 Hook 这里。

核心思路其实非常简单：

当函数准备返回验证结果时，

直接修改返回值：

return SUCCESS

这样：

所有服务器证书都会被认为可信。

Burp CA 也自然能够通过验证。

这一步解决的是：

Flutter 自身 TLS 验证。

六、Java 层同样不能忽略

很多人以为 Hook libflutter.so 就结束了。

实际上并不是。

Android 原生代码仍然可能包含大量 SSL 校验逻辑，例如：

TrustManager

最常见的是：

checkServerTrusted()

如果这里抛出异常：

HTTPS 请求依旧会失败。

因此很多 Frida 脚本都会直接让：

checkServerTrusted()↓不执行任何验证

HostnameVerifier

除了证书验证，

很多应用还会检查：

证书域名是否匹配目标 Host

即：

Hostname Verification。

如果这里返回 false，

HTTPS 同样会失败。

因此通常也需要统一返回：

true

SSLContext

不少应用会动态创建 SSLContext。

如果这里只 Hook TrustManager，

新的 SSLContext 仍可能使用默认验证逻辑。

因此很多通用脚本都会同时 Hook：

SSLContext.init()

把自己的 TrustManager 注入进去。

七、很多人忽略了 WebView

越来越多 Flutter 应用都会混合使用：

• Flutter 页面
• WebView 页面

甚至：

Flutter + H5

共同组成整个业务。

因此：

除了 Flutter TLS，

WebView 同样需要处理。

例如：

onReceivedSslError()

如果这里直接取消请求：

整个页面仍然打不开。

很多脚本都会直接：

handler.proceed();

继续加载页面。

八、InAppWebView 更容易被忽略

很多 Flutter 项目使用的是：

flutter_inappwebview

它并不是 Android 原生 WebView。

因此：

即使 Hook：

WebViewClient

仍然可能没有任何效果。

真正需要 Hook 的，

往往是：

InAppWebViewClient

不少抓包失败的问题，

最后都是因为遗漏了这一层。

九、一套更加完整的 Flutter 抓包思路

经过整理，一个较为稳定的 Flutter HTTPS 抓包流程如下：

启动 Burp↓安装代理↓配置手机代理↓Hook Flutter TLS↓Hook TrustManager↓Hook HostnameVerifier↓Hook SSLContext↓Hook WebView↓Hook InAppWebView↓重新启动 App↓开始抓包

相比单独运行某一个 SSL Pinning Bypass 脚本，

这种方式覆盖面更广，

成功率也更高。

十、几点经验总结

很多时候，Flutter 抓包失败并不是因为 SSL Pinning 特别复杂，而是因为只处理了其中一层。

如果整个通信链存在多个验证点，那么：

绕过 Flutter，

Java 仍然可能失败；

绕过 Java，

WebView 仍然可能失败；

绕过 WebView，

Flutter 自身 TLS 又可能失败。

真正需要关注的是：

整个 HTTPS 通信链，而不是某一个函数。

从安全测试角度来看，Flutter 已经逐渐成为移动应用开发的重要框架，未来越来越多的 App 都会采用这种架构。因此，理解 Flutter 的网络通信原理，比单纯记住几个 Frida 脚本更有价值。

只有弄清楚每一层验证发生在哪里，才能在面对不同目标应用时快速定位问题，而不是不断尝试各种脚本碰运气。

结语

Flutter 并没有让 HTTPS 抓包变得“不可能”，只是改变了传统 Android 的证书验证路径。

对于安全测试人员而言，与其不断寻找新的绕过脚本，不如先理解 Flutter 的网络通信架构，再针对不同层次进行分析和处理。

很多时候，当你真正理解了 BoringSSL、Java SSL、WebView 三者之间的关系后，再遇到 "No Internet" 或 "Burp 抓不到包" 的情况，就不会再陷入长时间排查的困境。

掌握原理，比记住工具更重要。