这个月的小程序基线测试又开始了,但是突然发现抓不到包了。通过一些尝试后,问题暂时解决,特此记录一下。
问题出现之前的测试环境:
Pixel 4
安卓11 RQ3A.210805.001.A1
Magisk 23.0
Move Certificates v1.9
Riru v23.5
Riru – EdXposed v0.5.2.2_4683
MagiskHide Props Config v5.4.1-v131
Busybox for Android NDK 1.33.1
Edxposed 0.5.2.2_4683
TrustMeAlready 1.11
已装了Burp Suite的证书并用move certificates插件将其移动到系统目录(/system/etc/security/cacerts)
Windows 10
Burpsuite V2021.7
由于抓其他app的请求包是没问题的,比如该小程序的app版本,这时怀疑是不是微信又在防御抓包方面升级了。
但是很快就放弃了这一想法,于是我第一时间看了Edxposed里面的
TrustMeAlready是什么状态。开启?关闭?
然后发现是开启的,这就很奇怪了。
虽然在这次基线测试之前,测了其他项目,也频繁改动TrustMeAlready的状态,但是没改其他东西啊!
接着只好先将其关闭,重启手机,抓包!
结果意料之中,不光是小程序抓不到包了,其他app也抓不到了。赶紧改回来,重启、抓包,小程序还是抓不到!!!
为了不耽误项目进度,赶紧试试在PC端微信抓,结果也抓不到,如下图所示:
看不到目标域名,期间尝试过Proxifier,也是也莫名其妙的抓不到,也试过HTTP Debug Pro,
抓是可以抓了,但是居然不支持代理,也就是说我得一个一个请求的复制粘贴到burp里面去,最后用fiddler解决了问题:
也就是让fiddler去抓包,然后用burp的代理,这样fiddler的流量就会经过burp:
这里有一个坑:以前抓包不把fiddler设置为系统代理,同时在微信中设置fiddler的代理可以抓包,但是现在这样的方式还是抓不到!如下图所示:
所以只好在将fiddler启动时设置为系统代理,然后选择微信小程序进程进行抓包。到这里,PC端的抓包就结束了。
在本文开头已经说过了,安卓上抓小程序的流量,在以往的测试中是没问题的,只是这次突然就抓不到了。
而且APP的流量是可以抓到的(Burp证书已安装,TrustMeAlready插件已开启):
然后换了HTTPToolkit(关闭TrustMeAlready插件),发现是可以抓到小程序流量的:
但是这个工具跟HTTP Debug Pro一样,不支持代理,也就是说,没办法让抓到的流量走burp的代理,不过既然能抓到包,那就说明是burp的问题。
跟PC端一样,用fiddler来抓小程序的流量,再把流量转到burp试试。
先试试fiddler抓安卓微信小程序(关闭TrustMeAlready插件,装fiddler证书,重启手机):
结果居然什么都没有抓到,微信小程序那边显示的是“网络繁忙中……”,再把TrustMeAlready插件开启,重启手机:
居然抓到了!后面将fiddler网关代理设置为burp代理即可。
目前为止,PC端和安卓端小程序抓包情况如下:
抓包工具 | 抓包结果 |
Burp Suite | 失败 |
Fiddler | 成功 |
HTTP Debug Pro | 成功 |
抓包工具 | 是否开启TrustMeAlready插件 | 是否安装证书 | 抓包结果 |
Burp Suite | 是 | 是 | 失败 |
Burp Suite | 否 | 是 | 失败 |
Fiddler | 是 | 是 | 成功 |
Fiddler | 否 | 是 | 失败 |
HTTP Toolkit | 否 | 是 | 成功 |
因为装了Move Certificates插件,用户装的插件都会自动move到系统目录,所以没安装证书的情况暂时没测试。
最终得到结论:
PC端微信小程序抓包:Fiddler设置系统代理,并将网关代理设置为burp的127代理+Burp Suite的logger++插件记录流量。
安卓端微信小程序抓包:开启TrustMeAlready插件的前提下,Fiddler网关代理设置为burp的127代理+Burp Suite的logger++插件记录流量。(可以不设置为系统代理,因为不抓PC端流量)
作者:Harold
原文链接:https://blog.cracker101.com/?p=272
好文推荐