本帖最后由 littlewhite11 于 2024-11-19 23:33 编辑
逆向目标
- 网址:
aHR0cDovL3d3dy5jYi5jb20uY24v
- 目标:cookie中的
__jsl_clearance 参数
抓包分析
清空cookie,刷新网站,会发起三个相同的请求,其中前两次响应状态码为512,第三次响应状态码为200,这是jsl的典型特征。
第一次响应设置了一个名为__jsluid_h 的cookie。
第二次请求携带上一个响应的cookie和一个名为__jsl_clearance 的cookie。
第三次请求携带和第二次响应名字相同的cookie,但__jsl_clearance 的值不一样了,比较明显的区别就是第二次cookie值中间的数字是-1,第三次cookie值中间的数字是0。
逆向分析
流程分析完了,下面开始正式逆向,一般来说,对于cookie加密的情况,直接hook。
成功hook到第二次的cookie,而且代码也非常熟悉,经典的OB混淆。
那第二次请求的__jsl_clearance 在哪生成的呢,为什么没有hook到。
还是下熟悉的script断点 看看吧。
第一加载index的时候,会发现是这个时候生成了第二次请求的__jsl_clearance ,这个并不难,我们重点需要分析第二次生成的__jsl_clearance 。
既然遇到OB混淆了,那就无脑AST。
还原后的代码只有240行,我们甚至可以直接静态分析。
直接搜索document["cookie"] ,只有一个地方,_0x4954f5 就是我们的目标了。
继续往前分析,发现_0x5bef39[0] 就是__jsl_clearance 最终的值。
再往前分析,最终找到目标参数的生成位置。
剩下的事情就是,你懂的,缺啥补啥。其中_0x23b046 是调用go 函数传进去的对象。
下面直接模拟请求:
成功!!!
请求的时候可以session保持 ,其次还需要注意JS脚本是动态 的,每次使用的hash算法 可能都不一样,需要将动态的参数提取出来进行请求。
|