我最早遇到acw_sc__v2和无限debugger这两样东西是在采集雪球网讨论数据的时候。当时打开开发者工具准备抓包页面瞬间卡死在debugger断点上网络请求一个都看不到。关掉断点请求才能发出去但每次请求的Cookie里都带了一个动态变化的acw_sc__v2去掉就返回JS挑战页。那段时间我花了两天把这条链路彻底摸了一遍这篇文章就把整个过程、绕过方案、逆向思路和踩过的坑都写出来给同样在搞数据采集、前端安全或者反爬研究的同学一个参考。雪球这套反爬体系并非单个技术点而是由两道关卡组成一道是无限debugger用来卡住所有想打开开发者工具做分析的人另一道是acw_sc__v2动态Cookie用来拦截不执行JS的纯HTTP客户端。两道关卡互相配合如果不先把第一个解决后面连定位的机会都没有。1. 雪球网反爬体系初探acw_sc__v2和无限debugger到底是什么1.1 从第一次请求说起雪球网到底拦了什么假设你现在用requests直接请求雪球网的行情页面返回的内容其实是正常的HTML但页面里没有任何接口数据只有一段又一段等待浏览器执行的JS。直接拿正则去抓HTML里的目标内容抓到的基本都是空壳。这时候如果你换成浏览器访问同一个地址页面又能正常展示数据说明服务器端对访问客户端的类型有严格判断。真正的问题出现在打开开发者工具的那一刻。按下F12Chrome的Sources面板自动跳到一段代码上页面顶部出现一行黄色的提示条显示“Paused in debugger”。点击继续执行不到100毫秒又停在同一个位置反复操作几轮之后你会意识到有人在JavaScript里埋了定时触发的debugger语句。这就是雪球网的第一道防线。它的目标不是拦截数据请求而是拦截数据分析者。任何想通过网络面板查看请求详情、想在Sources里打断点调试JS的人都会被困在这条断点循环里。只要你不找到绕过方式后续工作基本没法推进。1.2 acw_sc__v2的生成链路阿里云WAF的JS挑战机制等绕过无限debugger重新刷新页面并观察网络请求你会发现浏览器发出的每个请求里都带着一个acw_sc__v2的Cookie。去掉这个Cookie再直接请求雪球网会返回一个掐头去尾的JS挑战页里面只有一段脚本没有任何业务内容。这个acw_sc__v2属于阿里云WAF的JS校验能力官方叫法是JS Challenge或动态JS验证。它的运行流程大致是客户端第一次访问没有acw_sc__v2WAF识别为可疑请求返回一个JS挑战页。JS挑战页里包含一段脚本和一个变量arg1脚本会基于arg1计算出acw_sc__v2的值。浏览器把计算出的值写入Cookie并自动刷新页面。刷新后的请求带上acw_sc__v2WAF验证通过返回真实内容。关键在于这个Cookie不是服务器下发的而是客户端本地JS算出来的所以普通爬虫不去执行页面JS就永远拿不到合法Cookie。WAF通过这种“执行JS”的隐性考验变相验证了访问者是一个真实浏览器环境。1.3 无限debugger在整条链路中的角色把acw_sc__v2的生成链路拉通之后再回来看无限debugger它的定位就很清楚了保护生成算法不被逆向。acw_sc__v2的计算逻辑混在雪球的混淆JS里正常情况下只要顺着Sources面板找总能找到核心代码。但雪球把debugger语句和业务逻辑放在同一个脚本里开发者工具一开就不断触发断点让你根本没法静下心来看代码。我当时抓到的大致实现模式是setInterval(function() { debugger; }, 100);有些实现更阴它不是直接用debugger关键字而是把字符串拆开动态构造setInterval(function() { Function(de bug ger)(); }, 50);这种写法让搜索debugger关键字的人在全局搜索时扑个空必须花时间分析变量拼接进一步拖慢逆向进度。可以说无限debugger负责劝退acw_sc__v2负责拦截两道关卡配合下来让直接拿requests或者普通脚本采集的人基本无从下手。2. 无限debugger正面交锋四种绕过方案实测2.1 为什么无限debugger能让人寸步难行无限debugger能卡住人本质上是利用了开发者工具的默认行为只要脚本执行到debugger语句无论这个断点是不是你手动设置的浏览器都会强制暂停。既然它是浏览器给开发者的正常调试能力那就一定有对应的开关和控制方法。难点不在于技术上无法绕过而在于很多人不知道这些开关的存在。我当时在一个群里问了很多人发现不少人的处理方式是打开开发者工具后直接硬扛一边疯狂点击“继续执行”一边快速切换到Network面板看数据。这种操作不是不可行但手工点击恢复的速度往往赶不上setInterval触发的速度而且页面会变得卡顿观察请求细节基本靠运气。后面我试了四种不同的方案各有适用场景。2.2 方案一Deactivate breakpointsCtrlF8最快的一种方式打开Sources面板后按下CtrlF8或者点击工具条上的“Toggle breakpoints”按钮。这个操作会全局停用所有断点包括代码里的debugger语句。实际体验是按下快捷键之后立刻见效页面恢复流畅后续再也不会因为debugger语句而暂停。代价是手动设置的断点也会全部失效如果中途想调试其他JavaScript代码还得再按一次CtrlF8恢复。所以这个方案适合前期快速抓包观察请求流程不适合长期调试。2.3 方案二Add script to ignore list脚本黑名单这个方案更精准。在Sources面板左侧找到触发断点的脚本右键点击文件选择“Add script to ignore list”Chrome就会在调试时直接跳过这个脚本里的所有断点包括debugger语句。用这个方案的前提是先确认罪魁祸首是哪个文件。雪球的脚本是动态加载执行的经常显示为VMxxx并不一定是正常的JS文件名但同样可以右键加入忽略列表。加入之后那个脚本就进了黑名单既不会再触发暂停也不会干扰其他文件的调试。这个方案的坑在于如果触发debugger的脚本和生成acw_sc__v2的脚本是同一个文件那后续想在那个文件里打断点逆向算法时也会被一起忽略。解决办法是把脚本从ignore list里移除或者切换回Deactivate breakpoints模式。我用这个方案跑通整条逆向链路后发现只要不点那个脚本的断点其实影响不大。2.4 方案三Hook构造函数改写debugger指令如果浏览器层面的开关因为某些原因没法用比如网站检测到了DevTools状态或者脚本通过动态拼接方式生成debugger字符串那就需要从JavaScript本身下手。核心思路是Hook住Function构造函数在动态执行代码之前把包含debugger的字符串替换掉。我实际测试过的一版代码是这样的(function () { var original Function.prototype.constructor; Function.prototype.constructor function () { var args Array.prototype.slice.call(arguments); if (typeof args[args.length - 1] string) { args[args.length - 1] args[args.length - 1].replace(/debugger/g, ); } return original.apply(this, args); }; })();这段代码在Console里执行后再刷新页面能拦截掉通过Function构造执行的debugger。缺点是对直接写在脚本源码里的字面量debugger语句无效因为那些语句在解析阶段就存在不会经过Function构造函数。实际场景中这两类情况往往同时存在所以我把方案三当成辅助手段主要配合前面两个方案一起用。2.5 方案四Never pause here最后一个方案是从断点行本身入手。如果已经定位到具体是哪一行触发的debugger可以直接在那一行的行号上右键选择“Never pause here”。Chrome会把这个位置加入忽略列表之后执行到这里直接跳过不再暂停。这个方案在调试过程中非常实用。比如你想在某一行打断点观察变量但发现这一行旁边有debugger干扰就右键设置“Never pause here”把干扰去掉再在旁边加自己的断点。总体而言我的建议是快速浏览用CtrlF8固定分析某个脚本用ignore list精准调试用Never pause here三套组合拳下来无限debugger基本形同虚设。3. acw_sc__v2加密逆向全记录从断点到算法还原3.1 定位加密入口在VM上下文里找到关键函数绕过无限debugger只是热身真正的重头戏是从混淆JS里挖出acw_sc__v2的生成算法。我第一次操作时走了不少弯路后来总结出一套相对顺畅的定位流程。第一步先清理掉所有断点和忽略列表正常访问雪球首页在Network面板里找到最开始返回的HTML请求。第一次访问时这个HTML通常就是JS挑战页里面有一段内联脚本会定义一个变量常见变量名是arg1script var arg1%xx%xx%xx...; /script这个arg1就是生成acw_sc__v2的输入原料。记下它的原始值后续做算法验证时要用。第二步在Sources面板里搜索acw_sc__v2这个字符串。如果直接搜索不到可能是因为代码混淆时把它拆开拼接了这时候换一种思路搜索“cookie”或者“expires”这些设置Cookie时的固定写法找到document.cookie 的赋值语句。在赋值语句那一行打断点刷新页面然后查看调用栈就能回溯到真正生成Cookie值的函数。定位的时候建议配合浏览器右上角的格式化按钮Pretty print把压缩过的JS代码展开阅读体验会好很多。雪球的脚本在格式化之后整体逻辑会清晰不少。3.2 扣代码还是理逻辑为什么我选择重写算法找到生成函数后摆在我面前的有两条路。第一条是把JS函数整体扣下来放到Node.js或者PyExecJS里原样执行再把结果拿回来用。这个方案看起来最省事但实际操作中非常痛苦。因为那段JS里充斥着环境检测和DOM操作比如document、window、navigator对象有的还夹着Canvas指纹读取、鼠标事件监听。在纯Node.js环境里没有这些对象必须一个一个用mock对象补环境经常是补完一个又冒出另一个。第二条路是读懂算法然后用Python或Node.js重写一遍。这条路前期慢但一旦跑通后续维护成本极低而且不依赖任何重型的JS解释环境。我最后选择了第二条。逆向时有几个原则值得分享先别急着逐行读代码先把输入和输出搞清楚。输入就是arg1字符串输出是浏览器实际种下的acw_sc__v2值。然后在本地用Node.js写个小脚本用同样的输入跑一遍自己的算法逻辑跟真实输出对比对上了再继续对不上就回头检查。3.3 核心算法拆解字节位移、异或和16进制混淆我逆向到的雪球acw_sc__v2生成逻辑核心可以拆成四个步骤用%分割arg1字符串得到若干个十六进制片段。去掉分割后的第一个空元素从第二个片段开始处理。每个片段用parseInt(item, 16)转成整数。将这个整数与固定密钥做异或运算这里密钥是十进制31也就是十六进制的0x1F异或结果再用String.fromCharCode()转成字符依次拼接。这个算法本质是一种编码混淆不是强加密。它没有密钥交换没有哈希校验只要知道异或的常量值任何人都能轻松还原。用伪代码表示result for item in arg1.split(%)[1:]: code parseInt(item, 16) decoded code XOR 31 result String.fromCharCode(decoded) return result密钥31为什么是31而不是其他数字其实没有高深的道理就是一个随机选定的常量写在混淆JS里。不同网站的WAF实现可能选择不同的密钥比如我后来分析其他使用同类WAF的网站时见过0x1C、0x24、0x17这些值。所以逆向时不能假设密钥固定要在JS代码里找到那个异或的源操作数。3.4 验证算法正确性用Node.js快速跑通在写完整的Python实现之前我习惯先用Node.js把核心算法跑通。因为浏览器本身执行的就是JS用Node.js能最快地对照验证。function generateAcwScV2(arg1) { let result ; const parts arg1.split(%); for (let i 1; i parts.length; i) { if (parts[i] ) continue; result String.fromCharCode(parseInt(parts[i], 16) ^ 31); } return result; } // 替换成实际抓到的arg1 const arg1 %46%72%6f%6d...; console.log(generateAcwScV2(arg1));跑出来的结果如果和浏览器Network面板里看到的acw_sc__v2值完全相同说明算法理解正确。如果不一致检查三件事第一分割符是不是%第二异或的常量是不是31第三有没有漏掉arg1里的特殊片段比如混入Unicode编码%uXXXX的情况。这类特殊编码需要先额外处理一次不能直接用parseInt(item, 16)解析。4. 用Python复现acw_sc__v2生成器4.1 为什么不推荐直接用Selenium很多人在这一步会选择Selenium或Playwright开个无头浏览器让页面自己生成Cookie。坦白说这个方案确实能跑通但我不推荐把它作为长期方案。原因有三个一是效率低每次请求都要启动一个完整浏览器进程内存和CPU占用都很大并发处理更是麻烦二是自动化特征明显虽然无头浏览器在慢慢“隐身”但WAF依然可以通过webdriver标记、浏览器指纹、JS执行上下文等维度识别自动化环境三是维护成本高浏览器版本一升级相关驱动就要跟着升稳定性没法保证。既然acw_sc__v2的生成算法已经逆向出来了用纯Python手写生成器才是性能最好、最可控的方案。4.2 完整Python代码实现下面这份代码是我验证过的实现分两步完成请求第一步访问目标页面拿到挑战页从HTML里提取arg1第二步计算acw_sc__v2并写入Session再重新请求目标地址。import requests import re def generate_acw_sc_v2(arg1: str) - str: result parts arg1.split(%) for item in parts[1:]: if not item: continue result chr(int(item, 16) ^ 31) return result def get_xueqiu_page(url: str) - str: session requests.Session() headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif, image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, Referer: https://xueqiu.com/, Connection: keep-alive, } # 第一次请求触发JS挑战页 resp session.get(url, headersheaders, timeout10) text resp.text # 从内联JS里提取arg1 match re.search(rvar arg1([^]), text) if not match: # 如果没有arg1说明当前请求没有被挑战直接返回页面内容 return text arg1 match.group(1) acw_value generate_acw_sc_v2(arg1) # 将计算出的acw_sc__v2写入Session并再次请求目标页面 session.cookies.set(acw_sc__v2, acw_value) resp2 session.get(url, headersheaders, timeout10) return resp2.text if __name__ __main__: html get_xueqiu_page(https://xueqiu.com/hq) print(len(html))这里有几个细节要提醒一下。第一次请求的Session不能丢弃因为响应头里的acw_tc等Cookie值代表会话状态必须保留。其次session.cookies.set时要确认没有把之前的Cookie覆盖掉最好在设置后打印一下session.cookies看看全貌。4.3 带Cookie发起请求的完整流程上面的代码把两次请求封装在同一个Session里这个设计是有原因的。雪球WAF校验acw_sc__v2时不只是看这个Cookie存在不存在还会结合其他Cookie和请求头做综合判断。如果第二次请求换了一个完全没有历史的Session只带acw_sc__v2被识别的概率会大幅上升。另外要注意的是如果你要请求的不是HTML页面而是接口逻辑也是一样的先走一遍挑战流程拿到合法的acw_sc__v2再带着这个Cookie请求真实接口。可以封装一个通用的方法判断当前Session里有没有acw_sc__v2没有就先触发挑战页有就直接请求。这样对后续批量采集会友好很多。5. 实测踩坑记录Cookie重写、请求头顺序和IP风控5.1 坑一Cookie被强制重写我第一次跑通代码如下逻辑后发现第二次请求依然返回挑战页。抓包对比浏览器和requests的请求头最后定位到问题是Cookie被覆盖了。场景是这样的第一次请求挑战页时服务端会在响应头里下发Set-Cookie其中有一个acw_sc__v2的初始占位值也可能是过期值。requests的Session会自动处理这些Set-Cookie把我手动设置的acw_sc__v2覆盖掉。解决方法是在发起第二次请求前先检查session.cookies里acw_sc__v2的实际值如果不对就再set一次。我在代码里加了一句调试输出打印cookies的完整内容才意识到这个坑。更稳妥的做法是第一次请求后先不急着set Cookie而是等到所有需要的Cookie都拿到手再统一覆盖acw_sc__v2。重点要保证Session里acw_sc__v2的值始终是自己计算出来的那一个而不是服务端下发的初始值。5.2 坑二请求头顺序对结果的影响在连续多次实验后我还遇到过一个比较“玄学”的情况同样的Cookie同样的IP只改请求头字段的顺序成功率就不一样。这大概率是WAF在做HTTP头部特征识别时对某些字段顺序有隐式要求。为了最大程度贴近真实浏览器我最终固定了一套完整的请求头主要包括User-AgentAcceptAccept-LanguageSec-Fetch-DestSec-Fetch-ModeSec-Fetch-SiteSec-Ch-UaSec-Ch-Ua-Platform如果是XHR请求还需要加X-Requested-With: XMLHttpRequest。实测下来把这一套补齐之后被拦截的概率明显下降。如果某天的请求还是被拦优先检查是不是请求头里漏了特定的Sec-Fetch字段。5.3 坑三高频请求触发风控怎么办即使acw_sc__v2算法完全正确Cookie也带上了请求头也模拟了只要请求频率稍微上去雪球依然会返回验证码或者直接警告。这说明反爬体系是分层的动态Cookie校验只能拦住不会执行JS的初级爬虫对于能模拟Cookie的爬虫还有更上层的风控策略在起作用。我在压测时试过一秒发十几个请求结果一分钟内就被封了几个IP。后来把请求间隔调整到3到5秒一次单线程跑基本就稳定了。如果确实需要更高的采集速率建议用稳定的代理池而且代理IP的信誉度一定要好公共代理IP的出口地址早被风控标记了用了反而更糟。这个坑想提醒大家的是逆向出算法不等于可以无限制采集。数据采集要尊重目标网站的规则合理设置频率能走官方API就走官方API把所有希望压在一个逆向出来的Cookie上随时可能被更严格的风控打回原形。6. 这套方案能不能通用聊聊acw_sc__v2系列变体6.1 acw_sc__v2并非雪球独有搞清楚原理之后你会发现acw_sc__v2并不是雪球网自己设计的一套东西而是很多网站都在用的通用方案。只要看到类似“第一次请求返回带arg1的JS挑战页然后需要生成一个动态Cookie才能访问”的流程基本就是同一套WAF体系下的产物。同款站点之间区别主要在于变量名和密钥。变量名不一定叫arg1可能是arg2、arg3总之是某个拼接出来的字符串。密钥不一定等于31需要到混淆JS里去找那条异或运算代码看它后面的常量是多少。找到密钥算法就破解了一大半。此外还有一些变体会在异或之后再做一层Base64编码或者把异或结果改成十六进制大写字符串而不是字符拼接。这些都不难处理先跑通一个样本再用对照法验证很快就能适配。6.2 从acw_sc__v2延伸出的逆向思路现在不少网站已经用上了acw_sc__v3v3最大的变化是在Cookie生成过程中加入了更多环境特征比如时间戳、Canvas、WebGL指纹、鼠标轨迹等。单纯模拟一个加密函数已经不够可能需要借助轻量级的DOM执行环境或者维护一个真实的浏览器环境才能解决。但逆向的整体思路是不变的先绕过反调试再定位入口然后分析算法最后用自己熟悉的语言重写验证。换个网站换套变量名方法论依然适用。我的个人经验是处理这类带JS挑战的站点最重要的是留下“黄金样本”。所谓黄金样本就是第一次访问时返回的挑战页HTML、arg1原始值以及浏览器种下的最终Cookie值。这三个数据是验证算法的关键参照物有了它们哪怕代码写到一半思路断了也能通过对比逐步逼近正确结果。我就因为没及时保存样本在改代码时反复刷新页面白白多花了一个晚上的时间。希望读到这里的你别再踩这个坑。
