抓包分析
首先点击获取验证码，会发送一个请求，该接口没有加密参数，响应包含了背景图、滑块图以及sessid（后续请求会用到）。
1.png (24.5 KB, 下载次数: 0)
下载附件
2024-11-24 17:17 上传
拖动滑块，会再发送一个请求，其中collect和sign是需要逆向的参数。
2.png (23.66 KB, 下载次数: 0)
下载附件
2024-11-24 17:17 上传
如果请求失败，接口返回验证失败。
3.png (14.72 KB, 下载次数: 0)
下载附件
2024-11-24 17:17 上传
如果请求成功，接口返回ticket。
4.png (21.4 KB, 下载次数: 0)
下载附件
2024-11-24 17:17 上传
逆向分析
我们先从启动器入手，看到了verify字样，直接进去。
5.png (26 KB, 下载次数: 0)
下载附件
2024-11-24 17:17 上传
发现代码被混淆了。
6.png (24.9 KB, 下载次数: 0)
下载附件
2024-11-24 17:17 上传
碰到混淆，老规矩，AST一把梭，当然，也可以硬刚，只是需要多耗点时间。
反混淆后的代码明显更加容易分析了。
7.png (17.3 KB, 下载次数: 0)
下载附件
2024-11-24 17:17 上传
我们先把混淆的文件替换为本地的（具体的替换方法可以自行百度），替换成功后，随便滑动一次失败的。
还是从verify进去，下断，重新滑动一次，发现参数已经生成，在_0x3d1ca1中。
8.png (16.59 KB, 下载次数: 0)
下载附件
2024-11-24 17:17 上传
往前分析，发现_0x3d1ca1经过_0x14c612(_0x481e7d)生成，而_0x481e7d已经有collect，那_0x14c612(_0x481e7d)很可能就是生成sign的。
9.png (11.68 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
再往前分析，发现_0x4b9595经过_0x2440f7({'position': _0x2c2063,'path': _0x1dc4f9});生成，其中_0x2c2063是经过缺口距离计算得出，_0x1dc4f9是轨迹。
10.png (9.42 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
我们先搞清楚加密的逻辑，然后再分析距离和轨迹是怎么生成的。
直接在生成collect处下断点。
11.png (10.33 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
一直跟进去，就会跟到下图的地方，一眼AES，那collect的生成逻辑就是将包含缺口距离和轨迹的对象进行序列化，然后进行AES加密。
12.png (16.7 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
接下来分析sign的生成逻辑。
先在_0x3d1ca1 = _0x14c612(_0x481e7d)下断，因为_0x481e7d现在还是没有sign值的，经过这之后就发包了，那sign很可能就是在里面生成的。
13.png (10.58 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
老样子，一直跟进去，就会到下图的地方，其实跟一遍就会挺清晰的，生成sign的逻辑就是先往传入的对象添加一个时间戳，然后将该对象经过_0x40a595方法处理成字符串，然后对该字符串进行MD5就生成了sign。
14.png (25.07 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
总的来说，反混淆后，collect和sign的逆向并不难。
下面继续分析缺口距离和轨迹是怎么生成的。
我们知道缺口和轨迹都是传参进来，那就一直往前跟栈，就会到下图的地方，其中this["left"]就是经缺口计算的，this["rawList"]就是轨迹。
15.png (12.31 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
先搜索this["left"]，会搜到这个地方，setLeft关键字提示我们left应该就是在这被设置的。
16.png (9.71 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
那我们继续搜索setLeft，会搜到这个地方，如果你在这个地方下断，那么你一动滑块它就会断住，你就不清楚参数是怎么生成的。
17.png (13.31 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
所以我们先简单分析分析。
我们要的left是_0x4a8918
而_0x4a8918可能是_0xd25440 / this["parentWidth"] * 0x64 + 0x0，也可能是0x64 * (0x1 - this["width"] / this["parentWidth"]
如果是第一种情况，那_0xd25440由_0x45279e["clientX"] - this["startX"]生成
我更倾向于第一种情况，然后我们下一个日志断点_0xd25440,_0x4a8918。
18.png (12.87 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
拖动一次滑块，然后查看日志输出，经比对，_0xd25440是真实的距离，_0x4a8918取的第一种情况。
19.png (17 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
left搞定后，我们再看轨迹，前面在setLeft之后直接setRawList了，那我们直接搜索setRawList，就会到下图这个地方，经常搞滑块的朋友看一眼大概就知道怎么回事了。
'x'就是滑块移动的距离（只是这里经过parseFloat(_0x220aec["toFixed"](0x2)) + this["width"] / this["parentWidth"] * 0x64 / 0x2处理，其中_0x220aec就是left的值），'y'就是滑块垂直方向的距离，'t'就是时间。
20.png (16.78 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
所有参数分析完毕，那我们直接模拟请求，缺口距离的识别可以用开源的模型，也可以走打码平台。轨迹可以自行构造，也可以用开源的模型。
模拟请求结果：
21.png (45.59 KB, 下载次数: 0)
下载附件
2024-11-24 17:18 上传
成功！！！
有一说一，加密很简单，难的是风控（具体是啥，自行摸索吧）
