1. 项目概述当逆向遇上动态防护瑞数6.5这个名字在爬虫与逆向工程师的圈子里几乎等同于“硬骨头”的代名词。它不像一些简单的JS混淆改几个变量名、还原几层eval就能搞定。瑞数构建了一套完整的、动态变化的客户端执行环境检测与加密体系其核心防御机制在于每一次请求的cookie特别是关键的sign值都是根据当前浏览器环境动态生成的且这个生成逻辑被深度混淆和分割直接静态分析如同大海捞针。传统的“扣代码”方式在这里往往举步维艰因为你扣下来的可能只是一堆无法独立运行的“死代码”严重依赖浏览器特定的对象和状态。那么破局点在哪里近两年的实战经验表明RPC远程过程调用结合环境补全已经成为应对瑞数这类高强度动态加密的主流且高效的策略。这个项目的核心就是深入解析如何利用RPC技术将瑞数那套运行在浏览器“黑盒”里的sign生成逻辑“搬运”到我们可控的服务端环境中来执行并在此过程中攻克动态cookie的生成策略。简单来说我们不再试图完全逆向和重写那套复杂的JS而是“借用”浏览器这个完美的执行环境通过RPC远程调用其内部函数为我们计算出所需的加密值。这就像你不必自己造一台精密的钟表而是学会如何远程读取墙上那只现成钟表的时间。2. 核心思路环境补全与RPC调用的双剑合璧要理解这个方案必须先拆解瑞数的防御逻辑。它的sign生成并非一个孤立的函数而是一个严重依赖浏览器运行时环境的“生态过程”。这个环境包括但不限于window、document、navigator、location等大量原生对象及其属性甚至包括一些浏览器特有的行为特征和事件循环机制。直接把这些代码抠出来放在Node.js或纯Python中运行99%的概率会报错“xxx is not defined”。因此我们的策略分为紧密相连的两步2.1 第一步构建一个“以假乱真”的浏览器环境这不是简单地创建几个空对象。我们需要一个环境补全工具来模拟出足够真实的浏览器上下文让瑞数的检测代码“相信”自己正运行在一个真实的浏览器中。PyExecJS或Node.js的vm2模块是常见选择但更专业、更强大的工具是像playwright或puppeteer这样的无头浏览器。它们提供了一个完整的、真实的浏览器内核环境从根本上杜绝了环境缺失的问题。在这个项目中我们选择以playwright为核心来搭建这个“沙箱”。注意环境补全的深度是关键。瑞数可能会检测一些非常细微的特征比如navigator.plugins的长度和内容、screen.colorDepth的值甚至是某些API的性能特征。一个粗糙的补全很容易被识别出来导致生成的sign无效。我们的目标不是100%完美复刻那几乎不可能而是补全到足以让核心加密逻辑顺利执行的程度。2.2 第二步建立与“沙箱”通信的RPC桥梁环境准备好了我们还需要一种方式从外部我们的爬虫主程序向这个环境内部的特定函数发起调用并获取返回值。这就是RPC的用武之地。我们不会去启动一个完整的、带界面的浏览器然后模拟点击那样太重了。相反我们启动一个轻量级的无头浏览器实例在其中注入一个通信层。典型的实现是在浏览器页面中注入一段JS脚本这段脚本暴露一个特定的函数例如window.getDynamicSign到全局。这个函数内部封装了触发瑞数sign生成逻辑的代码。然后在我们的Python主程序中通过playwright的evaluate方法远程执行JS代码来调用这个暴露的函数并将结果传递回来。这个过程本质上就是一次最简单的RPC调用客户端Python发起一个请求服务端浏览器环境中的JS执行特定过程并返回结果。为什么是RPC而不是其他方式解耦与复用RPC将复杂的JS执行环境封装成一个服务。爬虫逻辑请求构造、数据处理和加密逻辑sign生成完全分离。一旦RPC服务搭建好任何请求需要sign时只需调用即可无需每次重新初始化整个浏览器环境。稳定性浏览器环境作为一个独立进程运行即使某个页面上下文崩溃通常不会影响到主爬虫进程也便于重启和重试。性能权衡虽然启动浏览器实例有开销但通过连接复用一个浏览器实例处理多个RPC请求和池化技术可以将其控制在可接受范围内远优于为每个请求启动一个全新浏览器。3. 实战部署从零搭建RPC服务获取动态Sign理论清晰后我们进入实战环节。我将以PlaywrightPython为例展示一个最小化可行系统的搭建过程。3.1 环境准备与基础框架搭建首先确保安装必要的库pip install playwright playwright install chromium # 安装Chromium浏览器驱动接下来我们编写RPC服务的核心。这个服务需要做两件事1. 启动并维护一个浏览器环境2. 暴露一个调用接口。# rpc_server.py import asyncio from playwright.async_api import async_playwright import json class RsRpcServer: def __init__(self): self.browser None self.context None self.page None self._injection_script // 这是要注入到页面的JS代码 // 首先补全或重写一些可能被瑞数检测的关键对象属性示例 Object.defineProperty(navigator, webdriver, { get: () false }); // ... 更多环境补全代码 ... // 暴露RPC函数到全局 window.getDynamicSign async function(targetUrl) { // 1. 导航到目标URL触发瑞数脚本加载和执行 // location.href targetUrl; // 注意在playwright中导航由外部控制 // 这里我们假设页面已经导航到了目标页 // 2. 等待瑞数核心JS加载并初始化完成。这是一个关键且困难的点。 // 通常需要等待特定变量或函数出现或者等待一个时间间隔。 await new Promise(resolve setTimeout(resolve, 2000)); // 示例等待2秒 // 3. 尝试从页面中提取或触发sign生成。 // 方法A直接读取已经生成好的cookie如果瑞数直接设置 // let cookies document.cookie; // 方法B调用瑞数内部暴露的某个函数需要逆向分析得出函数名和参数 // let sign window._rs_encrypt(...); // 假设的瑞数函数 // 此处为示例返回一个模拟的sign。真实情况需要替换为逆向分析出的逻辑。 console.log([RPC] Generating sign for:, targetUrl); return simulated_sign_ Date.now(); } async def start(self): 启动浏览器和页面并注入RPC脚本 playwright await async_playwright().start() self.browser await playwright.chromium.launch(headlessTrue) # 无头模式 self.context await self.browser.new_context( viewport{width: 1920, height: 1080}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ... ) self.page await self.context.new_page() # 注入环境补全和RPC函数脚本 await self.page.add_init_script(self._injection_script) print(RPC Server started.) async def get_sign(self, url): 对外提供的RPC方法获取指定URL的动态sign if not self.page: raise RuntimeError(Server not started.) # 导航到目标页面 await self.page.goto(url, wait_untilnetworkidle) # 等待网络空闲 # 调用页面中已注入的RPC函数 sign await self.page.evaluate(([url]) window.getDynamicSign(url), [url]) return sign async def stop(self): 停止服务 if self.browser: await self.browser.close() print(RPC Server stopped.) # 简易的HTTP服务器包装使其他Python程序可以通过HTTP调用 from aiohttp import web import aiohttp async def handle_get_sign(request): url request.query.get(url) if not url: return web.json_response({error: Missing url parameter}, status400) try: sign await rpc_server.get_sign(url) return web.json_response({url: url, sign: sign}) except Exception as e: return web.json_response({error: str(e)}, status500) async def start_app(): global rpc_server rpc_server RsRpcServer() await rpc_server.start() app web.Application() app.router.add_get(/get_sign, handle_get_sign) return app if __name__ __main__: web.run_app(start_app(), host127.0.0.1, port8080)这个框架搭建了一个最基础的HTTP RPC服务访问http://127.0.0.1:8080/get_sign?url目标网址即可获取sign。然而这仅仅是开始里面的window.getDynamicSign函数是空的我们需要用逆向分析的成果来填充它。3.2 逆向分析与RPC函数实现这是整个项目的灵魂也是最耗时的部分。你需要对目标网站进行JS逆向找到生成sign的入口和逻辑。通常步骤是定位入口在浏览器开发者工具的Sources面板中搜索cookie、sign、encrypt等关键词或通过XHR断点监控网络请求找到设置加密cookie的JS代码位置。逻辑分析瑞数的代码通常是高度混淆的控制流平坦化、字符串加密、常量替换等。你需要使用AST解析、动态调试debugger等手段逐步理清其执行流程。关键是要找到最终生成sign的那个核心函数或表达式。提取关键代码你不需要还原全部代码。目标是提取出生成sign所必需的最小代码片段以及它所依赖的环境变量和函数。这可能包括一个主要的加密函数例如window._$xx。几个关键的辅助函数或数组用于查表、计算。一些从window、document等对象上获取的动态值如页面HTML特征、时间戳的某种变换等。假设经过一番艰苦的逆向你发现瑞数6.5的sign由一个名为window._$rs的函数生成它接受当前页面的href作为参数。那么你的注入脚本中的window.getDynamicSign函数就需要这样实现window.getDynamicSign async function(targetUrl) { // 确保瑞数核心对象已加载 if (typeof window._$rs ! function) { // 如果还没加载可以尝试触发一下页面事件或者直接等待/重试 console.error(瑞数核心函数未加载); return null; } // 调用逆向分析出的核心函数 // 注意参数可能需要根据实际情况调整这里只是示例 var dynamicSign window._$rs(window.location.href); // 有时sign是直接设置到cookie的我们需要读取 // var cookies document.cookie; // var signMatch cookies.match(/RM4hZBv0dDon443M([^;])/); // dynamicSign signMatch ? signMatch[1] : dynamicSign; return dynamicSign; }实操心得逆向分析时善用Chrome DevTools的“Overrides”功能。你可以将线上的混淆JS文件映射到本地然后在本地进行格式化、重命名和打日志刷新页面后修改会生效极大提升调试效率。另外关注初始化阶段sign生成逻辑通常在页面加载早期执行找到入口点比盲目跟踪更重要。3.3 服务优化与稳定性设计基础的RPC服务很脆弱需要增强其健壮性。连接池与实例管理单个浏览器实例可能崩溃或内存泄漏。更佳实践是维护一个浏览器实例池。主服务启动多个RsRpcServer实例当有请求到来时从池中分配一个空闲实例进行处理。这提高了并发能力和容错性。心跳与健康检查定期检查每个浏览器页面的状态例如执行一个简单的page.evaluate(11)。如果无响应或报错则自动重启该实例。超时与重试机制在get_sign函数内部和外部HTTP调用层都要设置超时。对于因环境未初始化好导致的失败可以实现指数退避重试。资源清理定期清理浏览器缓存、Cookie或者定期完全重启浏览器实例以防止内存占用过高。异步通信优化上述HTTP服务器是简单的GET请求。在生产环境中可以考虑使用更高效的RPC框架如gRPC或消息队列如Redis来处理调用请求实现更好的解耦和流量控制。一个简单的池化示例结构class RsRpcPool: def __init__(self, pool_size3): self.pool_size pool_size self.instances [] self._lock asyncio.Lock() async def init_pool(self): for i in range(self.pool_size): instance RsRpcServer() await instance.start() self.instances.append({instance: instance, busy: False}) async def acquire(self): async with self._lock: for item in self.instances: if not item[busy]: item[busy] True return item[instance] # 如果没有空闲实例可以等待或动态扩容复杂 raise asyncio.TimeoutError(No available RPC instance) def release(self, instance): for item in self.instances: if item[instance] instance: item[busy] False break4. 动态Cookie Sign生成策略的深度解析通过RPC调用我们拿到了sign但这还不够。我们需要理解这个sign的生成策略以便评估其有效期、唯一性并应对可能的变化。4.1 Sign的构成与生命周期瑞数的动态sign通常不是永久有效的。逆向分析时需要关注种子Seedsign计算通常基于一些“种子”数据如当前URL或其中某部分、页面HTML的某个特征值如某个div的id、一个由服务端下发的随机令牌可能在之前的响应中、客户端的时间戳可能被混淆处理。加密算法可能是标准的哈希如MD5、SHA256也可能是自定义的混淆算法。算法本身可能被编码在JS中通过一个巨大的数组和复杂的控制流来模拟。时效性sign可能是一次性的仅对当次请求有效也可能有一个短暂的有效期如5分钟。这需要通过反复测试同一sign能否用于不同请求或不同时间来验证。4.2 环境依赖性的具体表现为什么环境补全如此重要瑞数可能检测以下方面你的补全脚本需要针对性地处理检测类别具体示例补全/绕过思路Navigator对象navigator.webdriver,navigator.plugins,navigator.languages使用Object.defineProperty重写getter返回符合真实浏览器的值。Screen对象screen.width,screen.height,screen.colorDepth在创建浏览器上下文时设置合理的视窗大小或通过JS重写。Window对象window.chrome,window.outerWidth确保这些属性存在且值合理。DOM特性特定的HTML元素是否存在其属性或内容在页面加载后通过playwright执行JS来动态添加或修改DOM元素。性能APIPerformanceTiming相关数据可能需要对performance.now()等函数进行Hook或模拟。函数toString检测原生函数的toString()结果是否包含[native code]对于关键函数可以尝试用JS重新实现并替换但要注意不影响其功能。注意事项补全不是越多越好过度补全可能引入新的不一致性。最佳策略是动态观察在真实浏览器中运行目标页面通过console记录下瑞数代码访问了哪些属性和函数然后只对这些访问点进行精准补全。4.3 对抗代码更新与动态变化瑞数的JS代码可能会定期更新变更加密逻辑或检测点。你的RPC服务不能是一劳永逸的。监控与告警在爬虫系统中加入对sign有效性的监控。如果连续多个请求因sign无效被拒绝应触发告警提示可能需要重新进行逆向分析。代码指纹对比定期例如每天抓取一次目标网站的核心JS文件计算其哈希值如MD5。如果哈希值发生变化自动通知相关人员。模块化设计将RPC服务中负责具体加密逻辑的JS代码即注入的getDynamicSign函数内部设计成可配置、可热更新的。当检测到变化时可以从外部存储如数据库、配置文件加载新的JS逻辑而无需重启整个RPC服务。5. 常见问题排查与实战技巧在实际运行中你肯定会遇到各种问题。以下是一些典型场景及排查思路问题1RPC调用返回null或undefined控制台报错“xxx is not defined”。排查这几乎肯定是环境补全不到位。打开浏览器的开发者工具在playwright启动时添加headlessFalse以便观察查看Console输出的具体错误。是哪个对象或属性未定义根据错误信息针对性补全。技巧在注入脚本的开头写一个try-catch将window、document等关键对象的所有属性遍历并console.log出来与真实浏览器环境对比差异。问题2sign能获取到但用于请求时服务器仍然返回验证错误如412状态码。排查时效性检查sign是否是一次性的。尝试用同一个sign发起第二次请求看是否失败。关联性sign可能不仅与URL有关还与请求头如User-Agent、Referer甚至POST数据有关。确保RPC生成sign时的上下文如document.location.href与实际发起请求时的参数完全一致。Cookie完整性瑞数可能不止一个动态cookie。除了sign可能还有RM4hZBv0dDon443M、F0HmY_等。确保将所有必要的动态cookie都获取并携带上。技巧使用抓包工具如Fiddler、Charles拦截真实浏览器的一次成功请求记录下所有的请求头、Cookie和表单数据。然后用你的爬虫程序完全复现这个请求进行对比排查。问题3RPC服务运行一段时间后响应变慢或内存占用过高。排查这是资源泄漏的典型表现。可能是浏览器页面上下文未正确关闭或JS内存未释放。解决实现定期重启策略。例如每个浏览器实例在处理了N个请求后或运行了M分钟后强制重启。在每次RPC调用后清理页面中不必要的全局变量和事件监听器如果可能。使用playwright的context.clear_cookies()和context.clear_storage()定期清理状态。问题4如何应对瑞数的“debugger”反调试现象打开开发者工具代码会自动在debugger;语句处暂停。解决在启动playwright时可以通过--disable-devtools参数或启动选项禁用开发者工具。更常见的是在注入脚本中重写或禁用Function构造器、eval或者对debugger关键字进行正则匹配和替换需谨慎可能破坏代码逻辑。一个简单粗暴但有效的方法是在playwright的add_init_script中注入window._debugger function(){};然后重写Function和eval但这需要根据瑞数的具体实现来调整。这个项目从思路到实践充满了细节和挑战。RPC调用提供了绕过高强度JS混淆的可行路径而动态sign的生成策略则是这场攻防战的核心战场。成功的钥匙在于精细的环境补全、精准的逆向定位以及一个健壮稳定的服务架构。每一次与瑞数的交锋都是对耐心和技术的深度考验但一旦打通其解决方案也往往具有很高的复用性和扩展性能够应对同类别的其他动态加密挑战。