做前端分析的人，迟早会遇到滑块验证码。前两年我刚开始接触这类问题时，也是一头雾水，尤其看到请求里那个神秘的cb参数，长度不一、每次都在变，根本不知道它是从哪儿冒出来的。后来跟着请求链路一步步往下查，才慢慢梳理出一套完整的定位方法：从抓包开始，到全局搜索、XHR断点、调用栈回溯，再到断点调试还原生成逻辑。这个过程不依赖某个特定框架，也不绑定某一家验证服务，凡是需要前端动态计算参数的场景，基本都能复用。今天就把这条分析路径完整拆开讲一遍。适合正在学前端JS分析的朋友，也适合做接口调试、代码审计的同学参考。所有内容仅供学习交流，目标对象统一用“某滑块验证组件”代指，不针对任何真实业务。
1. 滑块验证码的校验链路与cb参数的角色
1.1 一次滑块验证的完整生命周期
要搞清楚cb是干什么的，先得把滑块验证的整体流程拉一遍。通常一次验证会经历这么几个阶段：
- 前端页面加载时，向后端申请初始化数据，拿到一个会话标识、背景图地址、缺口图地址，可能还有一段加密配置。
- 用户在页面上拖动滑块，从按下到移动再到松开，这期间浏览器会记录轨迹点、耗时、距离偏差、设备信息等。
- 前端把采集到的数据做序列化、拼接、加密，生成若干动态参数，随验证请求一起提交给后端。
- 后端拿到参数后，结合会话信息做校验，判断是否为真人操作，返回验证结果。
cb这个参数，就出现在第3步生成的动态参数里。有意思的是，在不同的验证组件中，cb的含义并不固定。它可能是回调标识、随机数、时间戳、加密结果的截断，甚至只是某个流程ID。只看名字完全猜不出来，必须结合请求上下文去判断。
1.2 cb参数的三种典型含义
我在实际分析中遇到过三种最常见的情况，整理成一张表：
| 场景 | cb的典型含义 | 判断方法 |
|---|---|---|
| 场景A | 会话内的一次性随机标识 | 每次刷新页面后变化，短时间内重复请求时会保持 |
| 场景B | 轨迹或设备信息的加密结果 | 长度较长，字符集为十六进制或Base64，且随操作过程变动 |
| 场景C | 透传的业务参数或回调字段 | 值直接来自后端返回，或来自页面全局变量 |
怎么判断？很简单。前端在发起验证请求前，先看这个值在页面加载时是否已经存在。如果刷新页面它就出现，那多半是后端下发；如果它只在滑动验证之后才出现，那基本就是前端动态生成的。再看它的字符组成，纯数字往往是时间戳或随机种子，混合大小写字母和数字则可能是加密结果。
1.3 为什么非要分析前端JS
有人会问：后端校验逻辑不是更关键吗？分析前端代码图什么？原因在于，cb这类参数必须由前端生成，后端只是校验方。如果能够定位前端生成它的具体函数，就能理解这个参数的结构、变化规律和拼接方式，进而推断后端校验的重点。这不是为了“破解”，而是把黑盒变成灰盒，减少盲猜的成本。对于做前端代码审计、接口测试的人来说，这是必备技能。
2. 分析前的准备工作：工具、环境与目标梳理
2.1 工具清单与各自职责
开始动手之前，先把工具备齐。我常用的组合是这几样：
- 浏览器开发者工具：核心工具，用来抓请求、下断点、查看作用域和调用栈。
- 独立抓包调试工具：用来保存请求样本、修改重放、对比参数差异。
- 代码格式化插件或在线工具：压缩混淆过的JS必须先格式化，不然没法看。
- 本地编辑器：把关键代码片段保存下来，做标注和整理。
很多人一上来就盯着代码看，其实顺序反了。正确的第一步应该是抓包，先把目标请求找出来，再看代码。因为代码是静态的，请求是动态的，动态信息能告诉你要找什么。
2.2 抓包锁定目标接口
操作很简单：打开目标页面，清空Network面板的日志，手动完成一次滑块拖动，观察新增的请求。重点找名字包含verify、check、captcha这类关键词的接口。找到验证请求后，逐个看它的POST参数，在参数列表里找到cb：
- 记录
cb当前的值； - 记录它的长度和字符集；
- 刷新页面再来一次，看它是否变化；
- 只拖动滑块但不完全验证，重复几次，看变化规律。
这些记录会直接影响后续的搜索策略。比如，如果cb每次滑动都变，那它大概率依赖轨迹数据；如果它只在最后提交时出现，那可能是提交函数临时生成的。
2.3 分清参数来源，缩小搜索范围
一个验证请求往往有七八个参数，不可能每个都从代码里找。先做一轮归类：
| 参数类型 | 特征 | 处理方法 |
|---|---|---|
| 后端下发 | 页面初始化时就存在，或响应里直接返回 | 不用分析生成逻辑 |
| 前端固定值 | 写死在代码里，比如版本号 | 搜索字符串即可确认 |
| 前端动态计算 | 每次请求都变化，依赖时间或用户操作 | 这是分析重点 |
这一步做完，搜索目标就从“找cb”变成了“找某个动态计算的函数”，范围小很多。
3. 定位cb生成逻辑的完整路径
3.1 从搜索入手：关键词与特征值
用过Sources面板的人都知道，Ctrl+Shift+F可以全局搜索。第一次搜cb，结果往往会爆炸，因为cb太短了，到处都是。我试过在某个压缩文件里搜cb，出来上千条匹配，根本没法看。
后来学聪明了，学会用特征值缩小范围：
- 搜
cb:，匹配对象属性写法； - 搜
"cb"，匹配字符串写法； - 搜
cb=，匹配拼接写法； - 如果已经在抓包里拿到了具体的值，直接搜那个值片段，命中概率极高。
搜索命中的结果，多半是参数赋值或者拼接的位置。从这里展开看，往往能直接找到生成函数。如果搜索结果还是太多，不要恋战，换XHR断点的路子。
3.2 用XHR断点做调用栈回溯
这个方法是我个人最推荐的。核心思路是：不从代码里找参数，而是从请求入口反推。
具体操作是：在Sources面板右侧的XHR/fetch Breakpoints里，添加一个针对目标验证接口URL的断点。然后重新触发滑块验证，浏览器会在请求发出的瞬间暂停。此时看右侧的Call Stack，从当前请求函数一层层往上翻，必然能找到生成cb的那一层。
这个方法的优势在于，它利用的是JavaScript的调用链逻辑——任何参数在被写进请求之前，必然经过某个函数。只要抓住请求发送的瞬间，就能逆推出所有上游函数。比起无头苍蝇式搜索，效率高得多。
3.3 事件断点辅助定位轨迹参数
有些验证组件里，cb并不直接等于轨迹加密结果，而是把轨迹数据先存在某个变量里，提交时才一起处理。这种情况下，还需要定位轨迹收集的逻辑。
在Event Listener Breakpoints中勾选mouse相关事件，尤其是mouseup和mousedown，然后拖动滑块，断点会在事件回调中触发。观察此时的作用域变量，能找到轨迹数组的存储位置。这个变量的声明处，往往就是整个加密链路的起点。
需要注意，移动端场景下事件类型不同，可能是touchstart、touchmove、touchend。分析移动端页面时，事件断点要换成触摸事件。
3.4 面对混淆代码的取舍
拿到的JS若是混淆过的压缩代码，不要试图从头到尾读懂。正确做法是：
- 先用格式化工具把代码展开；
- 搜索上一步确认的入口函数名或字符串特征；
- 顺着调用关系读关键路径，忽略无关分支；
- 把关键函数提取到编辑器里，分段加注释。
混淆只能增加阅读障碍，不能改变一个事实：前端代码最终要在浏览器里运行，运行时必然有真实的函数调用链。断点调试面对混淆代码依然有效，因为浏览器解释执行的是真实逻辑。
4. 断点调试与生成流程还原
4.1 在提交函数前下断点，先确认目标
找到验证请求的发送位置后，在发送前一行下断点。重新触发验证，断点命中时，查看当前作用域里与请求参数相关的对象，找到cb字段的确切值。这一步的目的不是生成逻辑，而是确认目标。
我常用的验证方式：在控制台手动修改这个对象里的cb值，比如把最后一位改掉，再放行请求。如果后端返回校验失败，说明这个参数确实参与校验；如果响应和没改一样，那可能只是个透传值。这个方法能快速决定后续还要不要继续投入分析。
4.2 借助调用栈和作用域向上溯源
确认cb是关键字段后，开始溯源：
- 在
Call Stack面板里，从当前帧逐层向上点击； - 每一层都查看
Scope面板里的变量； - 重点看
Closure部分，闭包变量经常藏着加密密钥或公共配置； - 记录每层函数的职责，标出哪一层做了拼接、哪一层做了加密、哪一层做了编码。
这个过程就像剥洋葱。我曾经遇到过一个特别绕的场景，cb在提交函数里看起来直接由某个全局变量赋值，但全局变量是在另一个异步回调里被更新的。如果只盯着提交函数看，永远找不到源头。必须把调用栈一层层剥开，才能看到完整的赋值链路。
4.3 抽取出通用生成伪代码
经过断点调试，通常能梳理出类似这样的结构：
// 伪代码，用于理解生成流程，不映射任何真实组件 function generateCb() { const timestamp = Date.now(); const traceData = collectTrace(); // 轨迹点数组 const deviceInfo = getDeviceProfile(); // 设备信息 const payload = { ts: timestamp, trace: traceData, device: deviceInfo }; const serialized = JSON.stringify(payload); const digest = hash(serialized, key); // 某种摘要算法 return encode(digest); // 十六进制或Base64 }它看起来像一个典型的“数据采集 -> 序列化 -> 签名 -> 编码”链路。实际组件可能更复杂，比如会加入随机种子、固定盐值、版本号等，但整体骨架八九不离十。理解了这个骨架，后续不管是分析其他参数还是排查问题，心里都有底。
4.4 验证定位是否准确
定位到疑似生成函数后，要做验证，别急着写结论。三种方法：
- 插桩对比：在生成函数外层包一层打印，输入参数和输出结果都打到控制台，多跑几次看输出是否与请求中的
cb一致。 - 单独调用：直接在控制台里调用生成函数，把返回值与抓包里的值比对。如果一致，说明找对了。
- 重放实验：修改生成结果中的某个字段，重新走验证流程，观察后端响应变化，确认其是否参与核心校验。
只有通过了验证，才算真正定位到cb的生成逻辑。
5. 常见问题排查与实战笔记
5.1 搜索cb却搜不到结果
这种情况很常见，原因通常是：
- 参数名在混淆过程中被改写成短变量名；
cb不是代码里的字面量，而是多个字符串拼接出来的；- 参数值由后端透传，前端只是原样搬运。
应对策略是改用特征值搜索：直接用抓包中得到的cb值去全局搜索。一个几十位的字符串，命中概率远高于两个字母。如果特征值太长，截取一段连续子串搜索。
5.2 断点一直不触发
断点没反应，先排查三个方向：
- 请求走了缓存，没有真正发出，清缓存或用隐私模式重试；
- 验证逻辑不在当前页面的主线程里，可能在Web Worker中；
- 事件绑定不是常规鼠标事件，而是触摸事件或自定义事件。
逐个排查时，可以在Network面板里确认请求确实发出，再回Sources看断点是否落在正确文件上。还有一个容易被忽略的点：如果代码里用了setInterval或requestAnimationFrame，断点触发频率可能异常，需要控制好触发节奏。
5.3 遇到无限debugger怎么办
无限debugger是常见反调试手段，会在固定位置循环触发debugger语句，让人无法正常调试。处理思路不是去“禁用”它，而是绕过它：
- 在debugger语句所在行，右键选择
Never pause here，让该行不再触发暂停； - 用条件断点，为该位置设置一个永远为假的条件，比如
false，变相跳过； - 如果多个位置都有，可以先把包含debugger的代码片段格式化，再逐行跳过。
这个方法只是调试技巧，不涉及任何攻击行为，可以放心使用。
5.4 参数在闭包里拿不到
有时候断点命中了，但想看的变量不在当前作用域，闭包里藏着关键数据。这种情况不用急：
- 在闭包外层函数声明处下断点，先在外层暂停，再单步进入内层；
- 或者在变量声明的那一行下断点，中断后看
Scope面板； - 还可以直接在控制台使用内存快照，搜索变量名。
关键逻辑往往是“变量不在当前作用域，但它一定在某个上层作用域里定义过”。顺着作用域链往上找，不要跳着看。
5.5 问题排查速查表
| 现象 | 可能原因 | 排查手段 |
|---|---|---|
| 搜不到相关关键词 | 混淆改名、字符串拼接、透传值 | 用特征值搜索、断点调用栈回溯 |
| 断点不触发 | 缓存、异步线程、事件类型不对 | 清缓存、排查Worker、切换事件断点 |
| 无限debugger | 反调试代码 | 条件断点、Never pause here |
| 闭包变量看不到 | 作用域层级不对 | 外层断点、单步进入、内存快照 |
| 定位了但改值无反应 | 参数不参与核心校验 | 重放实验、后端响应对比 |
表格里这几种情况，基本覆盖了大多数分析过程中的卡点。真正踩过一遍，后面就会顺手很多。
6. 实操心得与边界提醒
6.1 把逆向分析当成代码阅读训练
做了这么多分析之后，我的感受是：最有价值的不是记住某个组件的参数生成方式，而是练出一套面对陌生JS代码的阅读方法。拿到一段压缩混淆的代码，先找请求入口，再追调用栈，关键函数打上断点，观察数据流转，最后整理成结构化的伪代码。这套流程本身就是一种能力，可以用在很多场景里。
建议新同学刻意训练：每次分析完，把定位过程写成文档，记录哪一步最耗时、哪个方法最有效。几次下来，会形成自己的套路。
6.2 授权边界与合规意识
这一点必须反复强调：所有前端分析行为，都要建立在合法授权的基础上。自己搭的测试环境、模拟项目，或者拿到了明确授权的测试目标，都是可以的。未经授权去分析他人线上服务，试图绕过其安全策略，是明确的违规行为。技术本身是中性的，用在哪里、怎么用，决定了它的性质。
我在写这类文章时，也刻意隐去具体对象名称，只讲通用方法论。这样对读者负责，也对整个技术社区的生态负责。
6.3 后续可以深入的方向
如果对前端JS分析感兴趣，以下几点值得继续探索：
- 学习AST相关工具，提高反混淆效率；
- 熟悉常见摘要算法和加密算法的特征，比如长度、字符集、填充方式；
- 研究运行时环境差异，比如浏览器指纹、Canvas绘制、WebGL信息；
- 练习代码插桩与Hook技巧，提升动态分析的效率。
这些方向之间是递进关系，掌握之后，阅读任何前端代码都会轻松很多。
我个人在实际操作中的体会是：cb这类短参数名最容易让人上头，一上来就全局搜索，结果翻几百个文件。更稳的方式是先抓住请求入口，用调用栈往上走，整个过程其实是在和前端代码“对话”。最后再分享一个小技巧：遇到拿不准的参数，先看它的长度和字符集。长度32位的十六进制串，大概率是某种摘要算法之后的结果；纯数字的长串，可能是时间戳加随机种子的组合。这个特征能帮你少走不少弯路。
