记一次flutter框架的App渗透日记

原文链接：https://forum.butian.net/share/4405

客户安排了一个App的渗透测试，但是App抓不了包，于是展开一顿分析，最终进入内网………….

测试过程

1.使用Clash，打开全局代理进行抓包测试，发现验证码未加载，此时疑惑是否检测代理软件。

2.使用clash透明代理将防火墙转发流量进行抓包测试，竟然抓到了相关的数据包，但是此时还是没有成功通信。

3.这时还是非常纳闷为什么抓到了包还是无法访问，于是将数据包发送至repeater进行单独的服务器访问分析。

4.很显然，这个数据超乎我想象的简单，也就是说它不像是APP构造的包，更不像浏览器构造XHRrequest包，尤其这个user-agent特别具有标识，这时对useragent信息进行收集，因为最初猜测可能和证书相关，最终确认是flutter框架开发的App，特征都能吻合上，so库以及useragent等特征。

5.请教大佬以及熟人是否做过相关分析。

6.由于在我收集的信息里，大量的flutter证书bypass的文章，我下意识就认为ssl的问题，但是师傅说的又没错，这是一个http的包。于是震惊我中华的第二天早上，我发现这tm居然是个内网地址。

7.于是我百思不得其解，初步我设想是App做成本地请求+SDK(ssl认证转发发送)，于是我又尝试一些常规方法，对App源码进行分析，但是这个App源码竟然全体进行混淆，虽然没有加壳，但是这个混淆却异常的牛逼(有无师傅知道源码混淆如何还原，求求)，我尝试了关键词搜索，例如okhttp分析，libssl.so分析，以及一些字符串，JSON数据包hook分析，竟然没有找到任何与这个Dart发出来的请求相关的信息。然后就只能将希望寄托于网上的flutter分析，希望足够简单能够支持我解决抓包问题。

文章参考链接: https://www.ctfiot.com/217117.html

8.于是拿到了so的ssl bypasshook函数。

9.万幸互联网居然有对这个地址的分析，我以为十拿九稳了，将地址填充进代码测试。

10.如图下代码，进行hook测试，发现依旧无法成功抓包。

11.此时心态有点崩溃，但是重新振作了一下，在github找寻所有的libflutter.so分析，终于找到了一个可以用的项目，这个点赞量以及项目更新时间都非常符合我心意。

12.使用该脚本我成功做到抓包自由，当然该脚本细节也非常牛逼，将SO文件内存解析然后拿到导出地址来进行操作，对逆向分析flutter框架特别感兴趣的师傅可以研究一下。地址https://github.com/hackcatml/frida-flutterproxy

13.但是这个发出来的包还是，无法访问，但是我自作聪明的是，我有这个prod-api的公网地址，于是我用mitm给他替换成公网地址，侥幸通过了通信问题。

14.我也拿到了验证码成功的登录进了系统，我以为我能狸猫换太子这样的安安静静的测试了，但是！这个App核心业务是内置了的h5应用，也就是说有一部分请求是走的webview。也就是说该hook脚本只能抓包soket的包，也是通过flutter.so发起请求的包。并不能抓到js发起请求的包。于是我又开始对webview的分析。这里直接放送代码。

Java.perform(function () {
//实例化一个对象
var WebView = Java.use('android.webkit.WebView');
//重写WebView类的重载方法，因为setWebContentsDebuggingEnabled不是静态方法，所以需要一个对象来调用这个方法
WebView.$init.overload('android.content.Context').implementation = function (a) {
console.log("WebView.$init is called!1");
var retval = this.$init(a);
this.setWebContentsDebuggingEnabled(true);
return retval;
}
WebView.$init.overload('android.content.Context', 'android.util.AttributeSet').implementation = function (a, b) {
console.log("WebView.$init is called!2");
var retval = this.$init(a, b);
this.setWebContentsDebuggingEnabled(true);
return retval;
}
WebView.$init.overload('android.content.Context', 'android.util.AttributeSet', 'int').implementation = function (a, b, c) {
console.log("WebView.$init is called!3");
var retval = this.$init(a, b, c);
this.setWebContentsDebuggingEnabled(true);
return retval;
}
//始终设置为true,打开调试
WebView.setWebContentsDebuggingEnabled.implementation = function () {
this.setWebContentsDebuggingEnabled(true);
console.log("setWebContentsDebuggingEnabled is called!");
}

});

// frida -U -f package_name -l .hook.js --no-pause

15.该代码可以打开CDP分析的入口，于是我用inspect打开看了一下请求网络，我发现通往其他应用的入口竟然也是内网地址。

16.这时候我突然就意识到不对劲了，各种信息告诉我事情并非我想象的那样，于是我总结了一下信息，各位师傅还记得第一张图吗？是否关注到这里面有一个SanforidClient，组件里面也有大量的深信服的SDK。不会吧，因为我是第一次碰见深信服sslvpn sdk的App，但是我自认为应该没有开发那么蠢，在App里内置了一个默认的用户吧。

17.带着深信服Sdk的核心特征去github搜索，我从源码中关注到了认证方法。

18.于是我成功拿到了认证的用户名以及密码以及服务器地址，成功拨进vpn。

19.总结，也就是说，为什么抓不到包，是因为内置了深信服的sdk去通信，将流量通过sokcet或者回环也好转发至burp，由于PC并不能访问内网地址所以导致抓到了包也无法访问接口，同时也学习到了flutter的常规特征。后续如果碰到类似深信服SDK的可以直接进行相关账户找寻........

如侵权请私聊我们删文

原文始发于微信公众号（黑白之道）：记一次flutter框架的App渗透日记