瑞数6代VMP逆向实战：从环境改造到Cookie生成全流程解析

我一直觉得瑞数这类动态防护是JS逆向里最有意思的战场尤其到了6代VMP版本很多靠搜索关键字、抠代码的老套路直接失效。这篇内容就是我针对企业征信查询场景做的一次完整逆向记录从环境准备到算法还原再到自动化验证全程踩坑不断但最终把整个链路跑通了。如果你正准备碰瑞数6VMP或者已经在里面折腾到怀疑人生这篇文章应该能帮你少走不少弯路。先说清楚逆向的目的是为了合法的数据采集需求比如批量查询企业公开信息用于风控建模、业务尽调整个过程不涉及任何绕过权限获取非公开数据的行为。文章中提到的所有技术细节都是基于公开接口和正常浏览器行为的分析。1. 内容整体设计与思路拆解1.1 瑞数6VMP到底难在哪瑞数从4代开始就基本告别了“找关键字、断点看堆栈”这种入门级逆向打法。到了6代JS代码几乎全部被丢进一个自定义虚拟机里执行你看到的不是一串串可以读的半明文JS而是一坨被编码过的字节码指令流。直接搜索cookie、generate这类关键字出来的全是VMP引擎的加载器代码真正的算法逻辑早就被编译进虚拟机的指令集了。这就好比你想看懂一段逻辑结果发现代码被加密成一道只有特定解释器才能运行的字节码而解释器本身又是混淆到妈都不认的。传统断点调试根本没法在关键位置下断因为每条指令都是在VMP引擎里动态解析执行的。1.2 技术选型与整体方案面对这种硬骨头我最终确定的方案是“浏览器环境自执行RPC调用”的混合路线。核心思路很简单既然我没法在纯Node环境里干净地还原VMP算法那我就让它在真实浏览器里帮我执行完然后通过RPC把结果拿回来。具体拆解下来整个方案分四层环境层用Puppeteer启动一个经过指纹改造的浏览器实例目的是让瑞数的环境检测脚本认为这是个真实用户。执行层在页面加载过程中通过Hook注入提前拦截瑞数的动态Cookie生成入口。通信层搭建一个本地WebSocket RPC服务让浏览器里拿到的Cookie结果实时回传到外部Python脚本。验证层用拿到的Cookie去请求真实的目标接口通过状态码和响应体长度判断是否被风控拦截。为什么不用纯Node模拟或者旧版的补环境方案因为我实测下来瑞数6VMP对浏览器指纹的检测维度已经扩大到了上百个包括WebGL渲染参数、字体列表、Canvas指纹、音频上下文、浏览器插件列表甚至显卡驱动信息。用手写navigator、window属性的补环境方案补了半年也赶不上它检测的速度。还是那句老话与其修补环境不如直接利用真实环境。1.3 瑞数6VMP的请求生命周期在动手之前我花了一整周时间摸清瑞数6VMP在请求生命周期里到底干了什么。这里直接给出我整理的核心链路首次访问目标页面时服务器返回一个带有动态Cookie种子的HTML页面里面加载了VMP引擎JS。VMP引擎执行完毕后会动态生成一个自定义Cookie通常名称为FSSBBIl1UgzbN7NxxxT之类的变体并把真实SessionID拼接进去。当你带着这个Cookie去请求业务API时服务端会根据Cookie里的时间和行为特征判断是否合法。如果校验失败返回一个反爬挑战页面要求浏览器自动重新执行一轮JS。理解了这条链路你就明白逆向的核心目标其实只有一句话搞清楚VMP引擎生成Cookie时依赖了哪些环境参数以及如何让这个生成过程在自动化场景下稳定复现。2. 逆向实战环境搭建与分析流程2.1 本地开发环境准备工欲善其事必先利其器这个项目的环境搭建不算复杂但版本对齐非常重要。我用了以下几个核心组件全部实测兼容Node.js 16.xPuppeteer对Node版本有要求20.x在新版本里也能跑但为了稳定我还是锁在16。Puppeteer 19.x新版本Puppeteer对浏览器启动参数做了更多限制老版本反而灵活度高。Python 3.9用来做RPC服务和后续的数据解析。Charles抓包工具用来分析请求头、Cookie跳转链路。安装完依赖之后我建议先把Puppeteer的浏览器下载路径设置好避免每次启动都去云端拉镜像npm config set puppeteer_download_hosthttps://npmmirror.com/mirrors npm install puppeteer19.11.12.2 浏览器指纹改造的完整方案瑞数6VMP对指纹检测的粒度非常细直接拿默认Puppeteer实例去跑大概率第一步就被拦截。我改造指纹时主要覆盖了下面几个维度每个维度都踩过坑用户代理与浏览器头默认的Headless Chrome UA里带HeadlessChrome字样一眼假。我直接取了本地真实Chrome的完整UA并且同步改了navigator.userAgent、navigator.appVersion、navigator.platform。WebGL指纹这是瑞数检测的重灾区。默认Puppeteer跑出来的WebGL渲染器是SwiftShader软件渲染真实用户浏览器是显卡驱动。我的方案是启动参数里强制开启硬件加速并从真实浏览器里导出WEBGL_debug_renderer_info的扩展值在页面加载前覆盖掉。时间戳与行为特征瑞数6VMP会记录从页面加载到Cookie生成的耗时真实用户通常在几百毫秒到几秒之间。如果自动化脚本生成Cookie的耗时总是稳定在同一个值很容易被聚类算法识别。我用了随机延时策略在关键步骤之间注入100ms~300ms的随机扰动。Canvas指纹这一步容易被忽略但瑞数对Canvas指纹的检测非常敏感。我在page.evaluateOnNewDocument阶段Hook了HTMLCanvasElement.prototype.toDataURL和getContext返回一套预先采集好的真实指纹数据。2.3 Hook注入与Cookie捕获点定位改造完浏览器指纹之后最核心的一步就是找到Cookie生成入口。瑞数6VMP的执行流程虽然被虚拟机包装但它最终一定会调用document.cookie来写入生成的Cookie值。这就像无论你把粽子包得多严实最后总得露出来一个角让人咬到。我的做法是在页面初始化前用下面的脚本强行Hook掉Cookie的setterObject.defineProperty(document, cookie, { get() { const cookies Object.getOwnPropertyDescriptor(Document.prototype, cookie).get.call(this); return cookies; }, set(newValue) { if (newValue.includes(FSSBBIl1UgzbN7N)) { window._capturedCookie newValue; if (window._onCookieCaptured) { window._onCookieCaptured(newValue); } } return Object.getOwnPropertyDescriptor(Document.prototype, cookie).set.call(this, newValue); } });这段代码的核心逻辑就是拦截不是目的通知才是目的。一旦Cookie被写入立即触发回调函数把Cookie值通过WebSocket推到本地RPC服务端。注意很多人在这一步会遇到一个问题——document.cookie的setter确实被Hook到了但拿到的Cookie值总是不完整。原因是瑞数6VMP会分多次写入Cookie每次追加一部分最后拼接成完整的值。我的解决方案是在回调里做累加判断等Cookie值稳定后再推送到RPC。2.4 WebSocket RPC通信服务搭建拿到Cookie之后需要一条高效的通道把它传回Python端做后续请求。我用WebSocket实现了一个轻量RPC服务代码量不大但非常实用# rpc_server.py import asyncio import websockets import json async def handler(websocket, path): async for message in websocket: data json.loads(message) if data[type] cookie: print(f[] Cookie捕获成功: {data[value][:80]}...) # 这里可以把Cookie写入共享队列供请求模块使用 await websocket.send(json.dumps({status: ok})) async def main(): async with websockets.serve(handler, 127.0.0.1, 8765): print([*] RPC服务启动监听端口 8765) await asyncio.Future() if __name__ __main__: asyncio.run(main())Node端在捕获到Cookie后直接用ws库推送到这个端口。整个链路从页面加载到Cookie回传实测延迟只有几百毫秒完全满足后续的高频请求需求。3. 核心算法还原思路与关键参数破解3.1 时间戳与动态因子拆解瑞数6VMP生成的Cookie并不是一个静态字符串里面通常包含多个动态因子。我用抓包和多次采样比对的方式对Cookie结构做了拆分发现其中有一个核心段是时间戳行为计数随机数的组合。时间戳部分比较好处理直接用Date.now()就能对上。行为计数就比较麻烦它记录的是页面加载后用户做了几次鼠标移动、几次滚动、甚至几次键盘输入。在自动化场景下如果这些计数全是零服务端会直接判定为机器人。我的解决方案是写了一个行为模拟脚本async function simulateUserBehavior(page) { const targets await page.$$(body); if (targets.length 0) return; for (let i 0; i Math.floor(Math.random() * 5) 3; i) { await page.mouse.move( 200 Math.random() * 600, 300 Math.random() * 400, { steps: 8 } ); await page.waitForTimeout(50 Math.random() * 200); } await page.evaluate(() { window.dispatchEvent(new Event(scroll)); }); }这里的关键是随机性。如果每次模拟鼠标轨迹都是固定路径反而更容易被识别成机器人。真实用户的鼠标轨迹是带加速度和抖动的我用steps参数让Puppeteer自动生成平滑曲线效果比一次性跳转好很多。3.2 VMP字节码不还原直接绕过说实话很多初学者一上来就想着把VMP的字节码一条条还原成可读的JS代码但这是一个无底洞。以瑞数6VMP的指令集规模来看完整还原的工程量堪比手工重写一个JavaScript引擎。我的思路完全不同VMP的最终目的是生成一个合法的Cookie值而Cookie的校验逻辑在服务端。只要我能在浏览器环境里等价地生成这个值就不需要关心VMP内部的指令执行细节。这就像你不需要理解发动机每个气缸的工作原理只要踩油门能让车走就行。实际操作中我利用了VMP的一个弱点它的字节码执行过程中一定会在内存里保存中间变量。我通过注入一段探测脚本来枚举VMP执行栈上的变量变化把整个Cookie生成过程中依赖的所有环境参数全部导出来。最终发现核心依赖集中在canvas.toDataURL()、navigator.userAgent和performance.now()这几个点上。只要这三个值在合理范围内变化生成的Cookie就能通过服务端校验。3.3 服务端校验逻辑逆向判断为了验证我拿到的Cookie是真的有效我搭了一个小的验证工具直接从Python端发起请求对比正常请求和被拦截请求的差异请求特征正常请求被拦截请求响应状态码200412响应内容完整JSON业务数据反爬挑战页面JS响应时长300~500ms800~1200msSet-Cookie字段无变化新增动态Cookie这个表格给我最大的启发是瑞数6VMP并不总是直接拒绝请求它有时候会先返回200和一个混淆的JS响应体里面藏着下一个挑战。所以验证阶段不能只看状态码还要检查响应内容里是否包含challenge或verify这类关键字。提示如果你在验证时发现收到的响应体是一段JS代码而不是JSON数据别慌说明你的Cookie被服务端判定为需要二次验证此时重新触发一轮Cookie生成基本就能解决。4. 常见问题与排查技巧实录4.1 指纹覆盖不完整导致每次都被拦截我一开始只改了UA和WebGL结果跑了一天成功率不到30%。后来加上了Canvas和Audio指纹的覆盖成功率一下提到了85%以上。这里最值得提醒的是瑞数6VMP会检测浏览器是否有-webkit-fake-audio这种自动化标记这个属性在Puppeteer的默认配置下居然是开着的必须显式关闭。解决方案是在启动参数里加上const browser await puppeteer.launch({ headless: new, args: [ --disable-audio-output, --disable-web-security, --no-sandbox, --disable-infobars, --disable-blink-featuresAutomationControlled ], ignoreDefaultArgs: [--enable-automation] });--disable-blink-featuresAutomationControlled这一行至关重要它直接把navigator.webdriver属性消除掉避免被检测成自动化工具。4.2 RPC通信串号导致Cookie错乱在并发场景下多个浏览器实例同时向RPC服务推送Cookie如果WebSocket服务端没有一个良好的队列机制很容易出现请求A带着请求B的Cookie去访问接口结果当然是412一堆。我的解决方案是在Cookie推送消息里带上实例IDPython端维护一个实例ID - Cookie的映射字典请求时按实例ID取用对应的Cookie。{ type: cookie, instanceId: instance_001, value: FSSBBIl1UgzbN7Nxxx }这样即使并发再多也不会串号。4.3 页面加载超时与重试策略瑞数6VMP的Cookie生成通常需要等页面加载完才能拿到但在弱网环境或者目标服务器响应慢时可能等很久都拿不到。我实测了多种配置最终把超时时间设置为10秒并在超时后自动重启浏览器实例。不过这里有个细节频繁重启浏览器实例会拉高被风控的概率因为同一个IP短时间内出现多次新建浏览器会话的行为本身就比较可疑。我的做法是维护一个浏览器实例池每个实例在拿到Cookie后不急着销毁而是复用一段时间等Cookie快过期了才换新的。4.4 Cookie过期与周期性失效处理瑞数6VMP生成的Cookie不是永久的我实测过它的有效期通常在10到30分钟之间具体取决于服务端的策略。超时后继续复用必然被拦截。我的处理逻辑是在Python端启动一个定时任务每隔8分钟主动发起一次“预热”请求用当前Cookie访问一个噪声接口如果返回412立即触发新一轮Cookie生成。这样做的好处是业务请求链路里几乎不会因为Cookie过期而出现断档。5. 自动化流程集成与结果验证5.1 把整个流程封装成可复用类为了后续能快速接入其他目标站点我把整个流程封装成了一个RuiShu6VMPClient类核心方法只有两个get_cookie()和fetch()。class RuiShu6VMPClient: def __init__(self, instance_id, rpc_url): self.instance_id instance_id self.rpc_url rpc_url self.cookie None def get_cookie(self): # 从本地RPC队列里拿到最新Cookie pass def fetch(self, url, headersNone): # 用拿到的Cookie去请求目标接口 pass使用的时候只需要先启动Puppeteer拉起浏览器再从Python端调用get_cookie()等待结果然后正常请求目标API就行。5.2 长时间跑批的稳定性调优我做了一次长达一周的稳定性测试每天从早上9点跑到晚上6点间隔2分钟请求一次目标接口。过程中遇到的最大问题是内存泄漏。Puppeteer跑了一整天之后浏览器进程占到2GB内存页面打开变慢Cookie生成成功率也开始下降。解决办法有两个一是定期重启浏览器实例我设置的是每500次请求强制重启一次二是在页面跳转时做累积的page.close()避免无界面的隐藏页面堆积。经过调优之后连续跑了一周没有出现一次412拦截成功率稳定在96%以上剩下的4%基本都是目标服务端主动断连或者网络抖动造成的。5.3 最终验证与数据对照我把逆向拿到的Cookie和正常浏览器手动访问拿到的Cookie放到同一台机器上连续请求同一个企业查询接口50次做了详细对照场景请求次数成功率平均响应时间手动浏览器Cookie50100%320ms逆向生成Cookie5098%350ms从结果来看逆向生成的Cookie在合法性和稳定性上已经非常接近真实浏览器产物完全能支撑常规的批量查询场景。6. 瑞数6VMP逆向的关键心得做完整轮逆向之后我最大的体会是逆向的本质不是征服而是理解对方的设计逻辑找到最高效的合作方式。特别是瑞数这类商业WAF产品它的目标是拦截批量自动化请求但这个拦截能力再强也必须保证真实用户的流畅体验。这中间的平衡点就是逆向技术的生存空间。如果你正准备上手瑞数6VMP我有几个建议不要死磕VMP字节码还原。把精力花在观察Cookie生成的外部依赖上找到规律比还原引擎有效十倍。环境模拟必须做到位。浏览器指纹、行为轨迹、时间抖动每一项都是可以单独写一篇文章的深度话题。做好日志和监控。在逆向项目里出bug是常态没有一套完整的日志体系排查问题会非常痛苦。遵守合规边界。自动化采集只用于合法数据场景不要做任何越权访问和黑产行为。最后分享一个我踩过一次的坑有一次我把WebSocket服务端口配成了8764但Node端连的是8765整整排查了一个下午才找到问题。后来我把所有端口配置统一放到了环境变量里再也没出过这种低级错误。碰到这种看似简单但影响链路通断的问题时先检查配置一致性再排查代码逻辑。