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