image.png (54.04 KB, 下载次数: 0)
下载附件
2023-12-6 14:42 上传
在request中上报的信息如下:
主要分析的就是profileData;
2. 下断点
这里直接搜的话是搜不到什么东西的,所以采用xhr断点进行调试:
image.png (65.45 KB, 下载次数: 0)
下载附件
2023-12-6 14:43 上传
跟踪堆栈:
image.png (104.23 KB, 下载次数: 0)
下载附件
2023-12-6 14:43 上传
堆栈打开可以看到是一个vmp,和签名x-s的很像
image.png (189.45 KB, 下载次数: 0)
下载附件
2023-12-6 14:43 上传
一般来说,代码使用vmp加密,最后能够实现补环境获取签名后,再在本地分析(我推荐的方式),但字节的vm都是跳来跳去的,一个签名可能使用了好几个vmp;
那么,开始补环境:
懂事的小伙伴都知道
x-s入口函数:window._webmsxyw()
profileData: window.xhsFingerprintV3.getV18
image.png (79.8 KB, 下载次数: 0)
下载附件
2023-12-6 14:45 上传
补环境(jsdom)
签名函数入口调用:
image.png (23.32 KB, 下载次数: 0)
下载附件
2023-12-6 14:45 上传
运行一下:
image.png (16.18 KB, 下载次数: 0)
下载附件
2023-12-6 14:46 上传
我擦,有结果了,格式看起来和网页上的一致
但是我不喜欢,执行vmp消耗的资源巨大,手上没点钱是顶不住业务机器的高并发的;
那么,分析算法:
首先,这个vm和之前的x-s的vmp很像,那么,根据之前分析x-s的思路来分析这个vmp会不会大大提升效率?开干!
打log调试,看看内存变化:
image.png (477.28 KB, 下载次数: 0)
下载附件
2023-12-6 14:48 上传
什么?乱七八糟的看不懂啊!!,别急,懂事的小伙伴已经看到了我标记的一处地点了,抓下来,base64看看是什么数据
image.png (144.11 KB, 下载次数: 0)
下载附件
2023-12-6 14:49 上传
这不就是浏览器各种各样的环境吗,太棒了。
分析到这里,笔者发现,这思路逻辑不就妥妥的和x-s的一模一样吗!?好的,开始验证::
在x-s签名算法中,我们使用的是 "x1=" + x1 + ";x2=0|0|0|1|0|0|1|0|0|0|1|0|0|0|0;" + "x3=" + setCa1 + ";x4=1687164665;"; 那么,我将这个字符串替换成我们上面得到的呢
image.png (9.51 KB, 下载次数: 0)
下载附件
2023-12-6 14:50 上传
好像不太一样;那换个key呢?返回到内存中看看有没有类似于key的数组存在
image.png (452.08 KB, 下载次数: 0)
下载附件
2023-12-6 14:50 上传
好吧,原来答案已经写在脸上了,当然前提要有和笔者一样分析过x-s的经验。
最好将key替换得到结果:
image.png (49.62 KB, 下载次数: 0)
下载附件
2023-12-6 14:39 上传
image.png (11.3 KB, 下载次数: 0)
下载附件
2023-12-6 14:40 上传
好的,完美结束!