本帖最后由 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算法可能都不一样，需要将动态的参数提取出来进行请求。
| 
[复制链接]
发表于 2024-11-18 23:13
|
发表于 2024-11-20 20:33
感谢分享 学习下
