前言
上篇我们找到了他具体的浏览器指纹怎么生成的，我们已经拿到了请求验证码图片的所有参数，那么剩下的就可以安心搞轨迹生成了。
源网址：aHR0cHM6Ly9saXZlLnYud28uY24vcGxhdGZvcm0veXRweHovdHRkcmF3Lmh0bWw=（b64）
分析
打开网站，清掉缓存和Cookie，开启Fiddler抓一个滑动的包。
经过一番查看，确定这个链接就是发送滑动验证码的操作结果的请求。
先看看这些参数，第一个id写死的，token服务器返回，第三个acToken，依然是服务器返回，width应该是图片的宽度：
type和version都写死不变。然后cb，生成的算法我们在上一篇已经找到了。extraData runEnv referer这些都不用管，callback是jsonp的参数，随便写。剩下的data，就是轨迹了。
这里这几个变量名，无论搜索哪个，结果都非常多。我们换一种方式定位，下事件断点。
操作完之后，当我们抬起鼠标的时候就会断在对应的地方了。尝试一下，正常拖动验证码，然后拖到某个位置松开鼠标：
我们观察到，这个arguments里就存放着一些鼠标坐标的数据：
顺着nc.apply方法往下跟，可以跟到这里：
这里的data里面有d m r ext，这不就是我们前面看到的轨迹数据吗。看一下traceData:
一个大数组，里面很多加密数据。那么这个很有可能就是一组组轨迹数据了。文件里搜索traceData，在这样类似于push的地方下断，我们要看看这个数组里到底push进去了什么东西。
然后刷新验证码开始滑动，刚开始滑就断下来了
向数组中push了f，f是上面一行代码得来的，控制台打印看看f里原本的数据是什么
f = p(u, [Math.round(i.dragX < 0 ? 0 : i.dragX), Math.round(i.clientY - i.startY), a.now() - i.beginTime] + "");
· 国际惯例，第一个参数是x坐标，第二个是y的坐标，第三个是时间，为了方便，我直接管时间坐标叫z了。看来他是每取到一个点，就进行一次加密，把加密的值放到数组里。那我们就不太好观察每个轨迹的内容了，下一步进行插桩输出。
也就是在这行下面加一个console.log。插完桩干嘛？当然是替换js啊。fiddler走起，常规操作了。。不展开了。
很显然这里他取的是一个偏移值，有些网站会取从浏览器或者屏幕最左端和最上端的坐标计算，而这里x是从图片最左端开始计算的偏移值，y则是以最开始鼠标按下的位置为原点计算的偏移值。可以理解为是下面这样一个坐标系，O就是原点：
y坐标没什么好说的，变动的区间很小，如果要伪造的话，不要让y变动的太大，最多1 2个像素的样子，也不能让他一直变，y坐标如果是0 1 0 -1 0 1这样一直在变，那明显是不对的，后台会检测到的，可以设置个策略让他随机变化一点。
x坐标就是一个速度的问题了，我们在用selenium过滑块的时候都知道，这个东西在最开始要加速度，快到缺口的位置的时候减速，到了缺口的位置，也可以让他过一点，再拉回来。这些都是为了欺骗服务器，伪造出符合人类习惯的轨迹。这里一样的道理，速度是在x坐标和时间差上体现的。加速和减速，要么是x坐标变化的比较大，要么是z坐标变化比较大。
这个是其他网站里扒下来的轨迹坐标，貌似也是在z上的数值变化较大。好吧，一时半会也找不到具体的例子了。总之，减速的这个过程，要么是在差不多的时间里，x轴位移变小，要么是在差不多的位移变化里，时间间隔变大，很容易想明白。这边很显然，用的策略是后者。我们只需要按照他的规律，伪造出符合他的条件的轨迹就行了。
需要注意的地方是最后x停的位置，x不应该正正好好停在缺口的位置，向前或向后偏移一些才是正常的。然后是最后停的位置，我们需要知道他停下来的地方是什么。是缺口的位置还是滑块的位置，或者是其他的。上面这张图，最后一个点的x值为104，大概量一下：
那么最后一个点的值就是滑块位置了。
轨迹的代码不难，只是有些麻烦，如果后面都搞定了验证结果却没过，那么首先要怀疑轨迹生成的有问题。就是要慢慢调了。
回到代码里，看看加密函数里做了什么。
f是调用函数p得到的，第一个参数u是上面的token，第二个参数就是轨迹数组，通过弱类型转换得到的字符串。token是啥，找一下呗。
是在获取验证码图片的时候和图片一起从服务器返回来的。进到p里：
一些位操作，然后是_：
里面的m:
原来是替换编码的base64。这部分也不难，直接抠出来或者改写成其他语言的都可以。单个点的就是这么多了，接下来看他怎么合并的。
找了一下，i依然是上面那个token值。this.mouseDownCounts固定为1， 然后1拼了个逗号，传了一个traceData的长度。。p函数：
还是上面那个p。wc他没验证轨迹吗？？？
不好意思看错了，轨迹在这里。。。
截取了轨迹中的50个点，在下面这个函数里截取
然后用 ":" 拼接，最后加密：
找到头尾直接抠就行了，代码也不多，300多行。
改法和之前的差不多，改成自执行，第一个参数随便传，第二个参数给他传个全局对象，然后执行this.eypt就行了：
接下来就剩个参数p了，找一下，也很简单：
鼠标放上去，第一个参数是226px，相信大家已经能猜到了，这个东西，就是滑块重点的x坐标，要么是滑块的，要么是缺口的。
看来是缺口的。和滑块的坐标大概差了9个像素点。在伪造轨迹的时候就要注意了，通过算法或者打码平台识别出来的是缺口位置，而在轨迹里传的是滑块的坐标，需要把这9个像素加回来。而最后向服务器传的就是缺口坐标，不需要再加其他值了。
width 310，图片的宽。加密的方法和上面ext的加密一样。
over。
总结
那么整个滑动验证的过程就分析完了，比较难的部分，一是指纹的生成，二是轨迹的伪造。某盾这个版本的滑块相对简单，跟某验之类的比，难度要低一些，至于对轨迹的检测，那就不好说了，怎样去模仿的像一点提高成功率，需要慢慢优化。现在有些滑块验证码的图片，做过切片混淆或者canvas现画一个出来，难度加到了对图片的获取上，比如某验，其余的部分都是大同小异，在一些地方的处理就见仁见智吧。。
本文分析过程仅供学习交流，并无任何个人以及商业或其他用途。如有不慎侵权，请联系我删除。
