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 上传
好的，完美结束！
