快手滑块轨迹分析
本帖最后由 521105 于 2024-3-7 18:06 编辑### 本文仅学习参考，如有涉及侵权联系本人删除
### 如果有任何问题，欢迎交流指导
### 文章仅记录本人分析轨迹变异的过程，用真实轨迹进行缩放也能通过。
目标网址：aHR0cHM6Ly9saXZlLmt1YWlzaG91LmNvbS8=
## 一、确定目标
通过**verifyParam**快速定位到加密后的位置，然后看上一层作用域，能拿到加密前的轨迹文本
把轨迹的字符串取出，简单分析之后，可以判断轨迹包含x、y、time信息，每一组轨迹用“,”进行分割。稍微处理下，我们拿出x、time进行画图，从图中我们更能直观的观察轨迹变化。
可以发现，在这个正常的轨迹中，有几个轨迹点发生了变异，不正常的凸起。这也就是本文需要分析的点。
## 二、分析过程
### 1.轨迹分析
为了探究这几个点为什么发生了变异，就需要找到记录轨迹点的位置。
观察堆栈，发现三个有特殊含义的函数，dragEndCb、slideEnd、verifyCaptcha，分别进行下断点
刷新页面，再次拖动滑块，可以看到变量r就是轨迹数组，并且有几个轨迹点是异常的
并且在该断点的堆栈前两层还在while循环中，也分别打上日志点，如图所示
在该断点的上方，还出现了“dragStartCb”、“dragMoveCb”，也打上日志点
通过分析日志，发现在第索引为3的函数中，传入了***MouseEvent***事件，随后开始了计算和取值
于是，在索引为3、长度为4的时候，进行debugger，尝试单步调试，跟踪代码运行逻辑
在之后的单步调试中，发现了在大量while循环中，每次执行的结果都有push操作
并且push方法是官方js代码实现的一个函数，在push方法中打上日志点
此时结合轨迹和日志点进行分析，很清晰明了
通过下面这一段日志，进行猜测分析和对比，可以得出以下结论：
1. 取出clientX的值，与第一个轨迹点的clientX进行相减
1. 拿相减之后的结果除固定值276得到一个小数
1. 拿小数乘1000，并拿到他的整数部分即为最终的**x**的值
同理，通过以下日志也可以分析出**y**值的计算方式：
取出clientY的值，减去固定值282.25再取整数部分
### 2.变异点的分析(A)
正常的轨迹点的计算方式找到了，下一步就是找为什么有的轨迹点会发生变异。根据/rest/zt/captcha/sliding/config返回的信息，可以分为两种情况讨论，本小点针对返回值中存在**q**值进行分析。
快速在日志中定位到变异点的位置
为了方便观察，我这里截取了索引为29的轨迹点、索引30的变异点的日志。对比发现，变异的轨迹点也是正常执行了上方的计算，随后进行了某个判断，当判断值为**true**的时候，会进行额外的操作，也就是产生了文章所说的变异点。
细心的可以发现，这个**true**猜测应该是**轨迹长度+1**之后与**31**进行了判断，当**轨迹长度+1**等于**31**之后，就会发生变异，同时回过头看/rest/zt/captcha/sliding/config这个接口返回的信息中，也有个**a**的值为**30**，在经过运算过得到了**31**。也就是轨迹长度**等于a+1的时候为第一个变异点**（这个a+1仅是多次测试的结论，没有实际进行跟栈观察）
变异前的轨迹点为：
变异后的轨迹点为：
继续分析**true**之后的日志，也能通过猜测得出结论：
**1009 = 456 * sx + ix**
**147 =13 * sy + iy**
**sx、sy、ix、iy**都是接口返回，如下图所示
继续观察后续日志，（由于时间关系，此次日志与上文日志非同一份），分析后续变异点的规律。
其中**2.258983396379993、30**都是接口返回，分别为**q**和**a**，根据日志也可以猜测得出下个点的计算方式为：
**Math.floor(Math.pow(q, 变异次数) + a)**
### 3.变异点的分析（B）
本小点针对返回值中存在**d**值进行分析。
当接口返回数据存在**d**值，要简单很多。
通过观察轨迹，就能发现，当轨迹长度等于**a**值，发生第一次变异，之后每间隔**d**值发生变异，如下图所示，分别在轨迹长度12、25（12+13）、38（25+13）发生了变异，变异值的计算方式与上文相同。
## 三、验证
针对轨迹这一块，是由算法生成的，优化下轨迹算法表现可能会更好。在本次测试中，分别进行了200次、500次、1000次测试，测试环境为不同IP、环境指纹部分随机的情况下连续进行，仅统计验证通过和因轨迹失败的结果，忽略缺口识别错误导致的失败，结果如下：
| 统计次数 | 通过率 |
| :------: | :----: |
| 200 | 99.5%|
| 500 | 98.2%|
| 1000 | 93.8%|
uuwatch 发表于 2024-3-12 15:16
已收藏，有空研究下这个did的使用时长
不要漏流程，did基本上都能用。我这里请求用户主页，通过判断响应中是否包含用户的个性签名来校验did，197次did 196次可用 看了半天 看了个热闹{:1_889:} 看了个寂寞啊，脑瓜子懵懵的
看了个寂寞 能运用到游戏上的滑块验证码 还有这样的轨迹生成方式，学习了 感谢分享！！ 看了个寂寞啊，脑瓜子没看懂 我也没看懂呀 太高深了，荏是没有笼懂{:1_918:}