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