目标网站
aHR0cHM6Ly9pdGVtLmpkLmNvbS8xMDAwNzcxODA5MTAuaHRtbA==
流程分析
直接搜索ParamsSign 找到这个融合接口的地方
后续直接搜索这个Psign即可
这里有很多 可以每个都打上断点。也可以根据搜索自己的接口传参打断点。
这里可以发现 得到的值应该就是新版的h5st的值。
这里直接反推另辟蹊径 去把这个new ParamsSign给补了。
然后给他全扣出来，伪造出来 放到浏览器执行就行了。
这里新版直接扣这个ParamsSign 返回的是null。
看了下接口校验。校验强的接口，已经改成了最新版，弱的接口仍然还是这个ParamsSign.
如下图所示位置
可以看到 new 三个实例都可以，分别是ParamsSign、ParamsSignLite、ParamsSignMain
这里分别声明，可以发现第一个走的是老的逻辑，第二个返回的是未定义。第三个是一套新的流程。
这里总结下：
- 强校验接口的老逻辑代码后续依然会走到新的流程里。
- 弱校验接口会走老流程。估计5.0 最近会改。
这里不管了。直接全部封装好。只不过调用逻辑 改成新的流程。
改了下 然后跑下发现可以。对比了下长度也是一样的。
补环境
这里我们先补环境吧。先把node伪造出来
复制上文到node中。
这里原型挺多的，直接用v-jstools一把梭
补完然后会报一个 ： Cannot set property Symbol(Symbol.toStringTag) of #
直接给他改了 或者把他重新定义一下
如下 声明下面添加下列代码：
复制代码 隐藏代码Object.defineProperty(_$MF, _$B4(Et(0xd7)), {
value: '',
writable: true,
enumerable: false
});然后跑出来应该就有值了
但是看了下长度 明显对不上。
这里就看源码吧。看看是什么没补的。
这里生成处如下：
这个 _$ms 是一个switch流。暂时先不管。看看传参。
浏览器：
Node：
这里发现 传参的这个$clt() 长度对不上。
这里发现_$clt() 也是个swtich流。
那这里我们挨个看吧。
_$clt()
这里直接插装吧。
然后发现这里。collect envCollect 应该就是收集环境值的地方。
那这里我们再看下node
这里挨个对比啊 然后修改即可。
全部修改完毕。然后发现 长度终于一致了。
然后全部封装请求。
发现 请求出来 依然是403.
虽然长度对了。但是请求好像依然有问题。
刚刚只看了传参的值没看生成函数的switch流。那这里继续回去看看。
_$ms
我们插装看看值。
这段代码还是挺简单的。
同比，我们对比node中的插装值。
这里发现 好像node中的是tk04，浏览器中的是 tk03。这个的差别是什么 大家应该都知道。
这里需要请求request_algo。把tk 还有一些东西 替换 一下再请求看看。
这里还要看下这个逻辑是从哪进的. 把这个sign也插一波
执行出来的顺序是[0,5,6,1,2,3] 所以我们去看这个this._$rds();
后面看到 rds 做了一些检测 逻辑因此走的tk04，这里可以选择直接修改上层。
后面修改完了之后依然是403 即使抓包直接使用都不行，测试下来原来是tls... 修改下就可以了
最后修改变成tk03就可以用了
结果
