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