瑞数6.5 sign生成与Cookie获取：逆向工程与自动化实战

1. 项目概述：瑞数6.5的sign与cookie攻防战

在当前的网络数据交互领域，尤其是涉及大规模数据采集或自动化流程的场景，瑞数动态安全Botgate（通常被业内简称为“瑞数”）是一个绕不开的名字。它以其独特的客户端动态混淆和执行逻辑，构建了一道坚固的防线。其中，6.x版本，特别是6.5版本，因其应用广泛且防护机制复杂，成为了众多逆向分析者和爬虫工程师重点研究的对象。这个项目的核心，就是深入其腹地，完整解析一个关键安全令牌——sign——的生成逻辑，并厘清从远程过程调用（RPC）到最终形成完整可用的浏览器环境标识（Cookie）的整个链条。

简单来说，瑞数6.5的防护可以理解为一个“动态契约”系统。服务器不是简单地给你一个登录凭证（Cookie），而是先给你一套复杂的、每次访问都可能变化的“考题”（一堆动态生成的JavaScript代码和初始参数）。你的浏览器（或模拟环境）必须正确“解答”这些考题，生成一个名为sign的“答案”，并将这个答案提交回去。服务器验证答案正确后，才会颁发“通行证”（关键的Cookie，如acw_sc__v2或acw_sc__v3）。没有正确的sign，你连获取有效Cookie的资格都没有，更别提后续的数据请求了。因此，sign的生成是整个流程的锁钥，而理解其生成过程中的RPC调用、环境构建、逻辑执行，则是复制这套流程的关键。

2. 核心思路与逆向工程方法论

面对瑞数6.5这样高度混淆和动态化的前端安全方案，盲目硬怼是不可取的。我们需要一套系统性的逆向工程方法论。核心思路是“环境模拟”与“逻辑追踪”相结合，目标不是破解其加密算法（那可能是黑盒且强度很高），而是完整复现其在前端浏览器中的执行流程。

2.1 逆向分析的切入点选择

通常，瑞数的防护流程始于一个状态码为202或412的拦截页面，或者是一个包含大量混淆JavaScript的HTML响应。页面的URL中或返回的Set-Cookie头里，常包含一个关键参数，如acw_sc__v2的初始值。这个值就是后续生成sign的种子之一。我们的切入点就在这里：

1. 网络请求追踪：使用浏览器开发者工具的Network面板，记录首次访问目标页面到最终成功加载内容之间的所有请求。重点关注那些返回了混淆JS的请求，以及最终成功时携带了有效Cookie（如acw_sc__v3）的请求。前者是“考题”，后者是“通行证”。
2. 关键参数定位：在拦截页面的HTML源码或首次请求的响应Cookie中，寻找如acw_sc__v2、arg1、arg2等参数。这些参数会被注入到动态执行的JS代码中，作为计算的输入。
3. JavaScript执行流分析：这是最核心的部分。瑞数的核心逻辑通常由一段极度混淆的JS代码执行，它可能通过document.write或eval动态生成并执行更多的代码。我们需要使用调试工具，在关键位置（如Cookie设置、网络请求发起处）设置断点，逐步跟踪代码执行栈，找到最终生成sign并提交的那个函数。

2.2 RPC（远程过程调用）在此场景下的体现

标题中的“RPC调用”需要特别解释。在传统的后端服务间通信中，RPC指一种像调用本地函数一样调用远程函数的技术。在瑞数的上下文中，“RPC”更贴切地是指浏览器内JavaScript逻辑与“外部”或“底层”环境之间的一种抽象交互过程。这主要体现在两个方面：

1. 浏览器环境API调用：生成sign的JS代码会大量调用浏览器的原生API，如Date.now()（获取时间戳）、Math.random()（生成随机数）、navigator.userAgent（获取浏览器指纹）、canvas.toDataURL()（生成Canvas指纹）等。这些调用对于纯JS环境来说是“本地”的，但对于我们试图在Node.js或Python等非浏览器环境中复现时，它们就变成了需要被模拟的“远程”或“外部”接口。因此，模拟这些API的行为，本质上就是在实现一套针对浏览器环境的“RPC Stub”（存根）。
2. 逻辑分块与动态加载：瑞数的代码可能被分割成多个块，通过异步加载、eval或Function构造函数动态拼接和执行。块与块之间的函数调用和数据传递，也可以看作是一种内部的、基于JS执行环境的“过程调用”。

所以，我们的逆向目标之一，就是识别出所有生成sign所依赖的这类“RPC调用”，并在我们的模拟环境中一一实现或绕过。

3. 核心细节解析：sign的生成逻辑拆解

sign值通常是一个长度固定的十六进制字符串（如32位或64位），它是一系列环境参数、动态变量和固定逻辑经过特定运算后的摘要。其生成逻辑可以拆解为以下几个关键环节：

3.1 环境指纹的采集与固化

这是sign生成的基础，也是反爬机制验证“你是否是一个真实浏览器”的第一关。代码会采集大量浏览器和环境信息：

• 标准Navigator属性：userAgent,platform,language,hardwareConcurrency等。
• 屏幕与窗口属性：screen.width/height,colorDepth,availWidth/Height等。
• 插件与MimeType：通过navigator.plugins和navigator.mimeTypes枚举。
• Canvas指纹：通过绘制特定的图形、文字，调用toDataURL()生成图像Base64，再计算其哈希。不同硬件、显卡驱动、操作系统抗锯齿设置都会导致微妙的像素级差异。
• WebGL指纹：获取WebGL渲染器信息和扩展名。
• 字体枚举：通过测量特定字符的渲染宽度来推测已安装的字体列表。
• 音频指纹：利用AudioContext生成音频信号并分析其输出。

在模拟环境中，我们需要固定这些值。不能每次运行都随机生成，因为服务器端可能会记录首次提交的指纹，后续请求如果指纹突变，会被直接判定为异常。通常的做法是，从一次真实的浏览器会话中完整捕获这些指纹数据，然后在模拟代码中直接返回这些捕获值，完全模拟原浏览器的环境。

3.2 动态种子的获取与处理

sign不是静态的，它依赖于每次访问都变化的动态种子。这些种子主要来自：

1. 服务器下发的初始参数：如acw_sc__v2、arg1等，它们通常被编码（可能是Base64、Hex或自定义编码）并嵌入在HTML或Cookie中。
2. 客户端生成的时间戳与随机数：Date.now()获取的毫秒级时间戳，以及Math.random()生成的随机序列。这里需要注意，瑞数可能会对时间戳进行加工（如取整、与服务器时间同步校验），对随机数生成器（Math.random）的状态也有要求。
3. 页面DOM结构或URL的特定部分：有时，代码会读取页面中某个隐藏元素的innerHTML，或解析当前URL的query参数。

生成逻辑的第一步，往往是解码服务器下发的参数，然后将其与客户端生成的时间戳、随机数等按特定顺序拼接，形成一个原始的“待摘要字符串”。

3.3 核心的混淆运算逻辑

这是最复杂的部分。拼接好的字符串会送入一个高度混淆的加密或摘要函数。这个函数可能具有以下特征：

• 控制流平坦化：原本清晰的if-else、switch-case逻辑被拆解成一个个基本块，通过一个“分发器”来跳转，使静态分析难以理解执行路径。
• 常量混淆：字符串和数字常量被拆散、运算（如异或、加减）、或隐藏在数组中以索引方式引用。
• 死代码注入：插入大量永不执行或执行结果无关紧要的代码，干扰分析者。
• 环境依赖检查：函数内部会穿插对浏览器特定对象、属性存在性的检查，如果不在浏览器环境，函数会执行错误路径或返回假值。

逆向这一部分通常有两种策略：

• 动态调试提取：在浏览器真实执行环境中，通过调试器在函数入口和出口打桩，记录下所有可能的输入和对应的输出，建立一个“输入-输出”查找表。对于有限范围的输入，这种方法直接有效。
• 逻辑还原与翻译：耐心地跟踪代码，用更清晰的语言（如Python）重写其核心算法。这需要极高的耐心和JS功底，但一旦完成，便是最稳定可靠的方案。过程中需要特别注意其使用的位运算（如^,&,<<,>>>）和特定的数学函数。

3.4 sign的提交与验证

生成的sign值，通常会作为一个POST请求的参数（参数名可能是sign、acw_sc__v2等）提交到服务器的一个特定验证接口（路径可能像/xxx/validator）。这个请求必须携带之前页面返回的Session ID等相关Cookie，以维持会话关联。

服务器收到sign后，会用自己的相同逻辑（或者一个可验证的等效逻辑）重新计算一遍，并与客户端提交的值比对。同时，服务器很可能还会校验提交sign所花费的时间（防模拟过快）、以及sign中编码的时间戳新鲜度（防重放攻击）。验证通过后，服务器会在响应中设置关键的通行Cookie（如acw_sc__v3），并可能返回一个让页面重定向到原始请求的指令。

4. 完整Cookie处理流程的实操复现

理解了原理，我们来看如何用代码（以Python为例）完整复现这一流程。我们将使用requests库处理HTTP，用execjs或PyExecJS来执行还原后的JS逻辑，用nodejs环境作为备选。

4.1 第一阶段：初始请求与种子捕获

import requests import re import execjs session = requests.Session() headers = { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...' # 使用固定指纹 } target_url = 'https://目标网站.com/需要访问的页面' # 1. 首次请求，预期被拦截，得到202/412状态或包含瑞数代码的页面 first_resp = session.get(target_url, headers=headers) print(f"首次请求状态码: {first_resp.status_code}") print(f"首次响应Cookie: {session.cookies.get_dict()}") # 2. 从响应HTML中提取关键种子参数，例如acw_sc__v2 # 瑞数参数可能藏在<script>标签、cookie中，或者是一个JSONP回调里。 html_content = first_resp.text # 示例：使用正则匹配，实际情况可能更复杂 pattern = r'var arg1=\"([^\"]+)\"' match = re.search(pattern, html_content) if match: arg1 = match.group(1) print(f"提取到arg1: {arg1}") else: # 也可能在Cookie里 arg1 = session.cookies.get('acw_sc__v2') print(f"从Cookie中获取acw_sc__v2: {arg1}") # 3. 提取并清理出核心的、需要执行的混淆JS代码。 # 这段JS可能很大，通常以<script>标签包裹，内容极度混淆。 js_pattern = r'<script[^>]*>([\s\S]*?)</script>' js_matches = re.findall(js_pattern, html_content) core_js = '' for js in js_matches: if 'cookie' in js and 'acw_sc__v2' in js: # 简单启发式判断，实际需更精确 core_js = js break # 清理掉可能的HTML注释、无关代码行（如果需要） # core_js = clean_js(core_js)

注意：第一步的User-Agent以及后续所有环境指纹，必须与后续执行JS时模拟的环境保持一致。最好是从一个真实的浏览器会话中一次性提取全套指纹并固化在代码中。

4.2 第二阶段：构建JS执行环境并计算sign

这是最核心的一步。我们需要一个能执行那段混淆JS并得到sign的环境。

# 假设我们已经通过逆向分析，将生成sign的核心函数提取/还原成了一个独立的JS函数，保存为`generate_sign.js` # 这个文件可能包含我们还原后的逻辑，或者是一个适配器，用于在Node.js环境下运行原始混淆代码。 with open('generate_sign.js', 'r', encoding='utf-8') as f: js_code = f.read() # 使用execjs调用 ctx = execjs.compile(js_code) # 假设我们还原的函数名叫`getSign`，它需要接收arg1, 时间戳等参数 # 时间戳的生成可能需要模拟浏览器行为，有时需要和服务器时间对齐 timestamp = int(time.time() * 1000) # 模拟 Date.now() # 有时需要特定的随机数序列，可能需要在JS环境内部初始化 sign = ctx.call('getSign', arg1, timestamp, other_fixed_params) print(f"计算得到的sign: {sign}")

关于generate_sign.js的内容：这个文件不是原封不动的混淆代码。它至少应该包含：

1. 所有被依赖的浏览器环境API的模拟实现（即我们前面说的“RPC Stub”）。
2. 核心的、还原后的sign生成算法函数。
3. 一个导出给外部调用的接口（如module.exports或全局函数）。

例如，一个极简的模拟环境可能开头是这样的：

// generate_sign.js - 模拟环境 // 1. 模拟浏览器全局对象 const window = this; const document = { getElementById: () => ({innerHTML: ''}), // ... 其他必要属性 }; const navigator = { userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...', // 固定值 platform: 'Win32', // ... 其他固定指纹 }; const Math = { random: () => 0.123456789, // 固定随机种子，或实现一个伪随机序列以匹配特定状态 // ... }; const Date = { now: () => 1640000000000, // 由外部传入的动态时间戳 }; // 2. 嵌入还原后的核心算法函数 function coreAlgorithm(arg1, timestamp) { // 这里是经过逆向、去混淆后的清晰逻辑 let step1 = decodeArg1(arg1); let step2 = combine(step1, timestamp); let step3 = complexHash(step2); // 可能是类似MD5/SHA的自定义变换 return step3; } // 3. 导出函数供Python调用 module.exports = function getSign(arg1, timestamp) { // 将外部传入的时间戳注入到模拟的Date.now中 Date.now = () => timestamp; return coreAlgorithm(arg1, timestamp); };

4.3 第三阶段：提交sign并获取通行Cookie

计算得到sign后，我们需要模拟浏览器提交验证请求的行为。

# 构造验证请求的URL和参数，这些信息需要从第一次响应的JS代码中分析得出 # 通常是一个固定的路径，如 /sign/verify, 或者路径也由JS动态生成 verify_url = 'https://目标网站.com/路径/validator' # 需动态分析获取 # 参数名也可能是动态的，常见是 `acw_sc__v2` payload = { 'acw_sc__v2': sign, # 或 'sign': sign # 可能还有其他固定参数 'tid': '...', } # 使用同一个session，携带初始的Cookie（如可能的Session ID） verify_headers = headers.copy() # 可能需要添加特定的Content-Type verify_headers['Content-Type'] = 'application/x-www-form-urlencoded' verify_resp = session.post(verify_url, data=payload, headers=verify_headers) print(f"验证请求状态码: {verify_resp.status_code}") print(f"验证响应文本: {verify_resp.text[:200]}") # 看前200字符 print(f"验证后Cookie: {session.cookies.get_dict()}") # 关键：检查响应中是否设置了新的Cookie，如 `acw_sc__v3` if 'acw_sc__v3' in session.cookies.get_dict(): print("✅ 成功获取到关键Cookie acw_sc__v3！") # 此时，可以用这个session去访问最初的目标页面了 final_resp = session.get(target_url, headers=headers) print(f"最终请求状态码: {final_resp.status_code}") # 如果成功，final_resp.text 应该包含预期的页面内容 else: print("❌ 未能获取关键Cookie，验证可能失败。") # 需要分析verify_resp的内容，可能是sign计算错误，或流程已更新。

5. 常见问题与排查技巧实录

在实际操作中，几乎不可能一帆风顺。以下是几个最常见的“坑”及其排查思路。

5.1 环境指纹模拟不全导致sign无效

问题现象：sign计算出来了，提交后服务器返回错误，或者返回的页面依然是被拦截的状态。

排查思路：

1. 对比检查：在浏览器成功通过验证的同一个会话中，使用开发者工具(Console)输出所有你认为重要的环境变量值（navigator属性、screen属性、canvas指纹哈希等）。与你模拟环境代码中返回的值进行逐一比对。任何细微差别都可能导致最终的sign哈希值天差地别。
2. 重点怀疑对象：
   • Canvas指纹：这是最常见的差异源。确保你的模拟canvas.toDataURL()返回的Base64字符串与真实浏览器完全一致。这通常需要你将真实浏览器生成的那一串很长的Base64字符串硬编码在模拟代码中。
   • Math.random序列：混淆JS可能连续调用多次Math.random()，其序列必须完全一致。你需要逆向出JS代码调用Math.random()的次数和顺序，然后在模拟环境中用一个固定的伪随机数序列去匹配，而不是每次调用都生成新的随机数。
   • 时区与时间格式：new Date().getTimezoneOffset()、Date.toUTCString()等返回的值需要匹配。

解决技巧：写一个“指纹采集脚本”，在浏览器控制台运行，将window、navigator、screen、document等对象的关键属性序列化为JSON保存下来。然后在你的Node.js/Python模拟环境中，直接读取这个JSON文件来提供这些属性值，确保百分百还原。

5.2 核心JS逻辑动态变化或存在反调试

问题现象：昨天还能用的脚本，今天突然失效了。或者一下断点，代码就执行异常。

排查思路：

1. 动态性：瑞数的JS可能每次请求都不同（代码混淆结构变化，但核心算法不变）。检查今天获取的arg1参数和JS代码块，与昨天的是否有较大差异。核心算法通常不变，但“包装层”（控制流平坦化、常量混淆的方式）可能会变。你需要确保你的还原逻辑是针对核心算法，而不是易变的包装层。
2. 反调试：
   • 检测debugger语句：代码中可能包含debugger;语句，或通过Function构造函数动态插入debugger。在调试前，可以重写Function构造函数或使用setTimeout绕过。
   • 检测控制台：通过判断console对象是否被重写或console.log的toString结果来检测。在正式执行环境中，不要开启开发者工具。
   • 时间差检测：在关键函数开始和结束用Date.now()计时，如果执行时间过长（说明可能下了断点），就跳转到错误逻辑。应对方法是打补丁（Patch），在模拟环境中重写Date.now，使其返回一个固定的、合理的时间值。

解决技巧：不要直接运行原始混淆代码。坚持使用“逻辑还原”的策略。虽然前期投入大，但一旦还原出核心算法（通常是几百行清晰的代码），其稳定性远高于直接执行动态变化的混淆代码。对于反调试，主要在动态提取输入输出对时用到，在最终的生产脚本中，应运行在无调试器的纯净环境。

5.3 请求流程与参数名更新

问题现象：sign计算似乎正确，但提交的验证接口URL或参数名不对，导致404或参数错误。

排查思路：

1. 动态分析网络请求：在浏览器成功通过验证时，仔细查看Network面板中sign提交的那个POST请求。记录下完整的请求URL、请求头（特别是Content-Type、Origin、Referer）和请求体（Form Data）的精确格式。
2. 检查JS中的请求构造：在混淆JS中搜索XMLHttpRequest、fetch、FormData、encodeURIComponent等关键词，找到构造和发送验证请求的那段代码。分析URL和参数是如何拼接出来的。
3. 会话一致性：确保从首次请求到提交sign的整个流程，使用同一个requests.Session()对象，以自动维持CookieJar。检查验证请求是否携带了必要的Referer头（通常是上一个页面的URL）。

解决技巧：将验证请求的URL、方法、参数结构作为配置项，与核心的sign生成逻辑分离。当网站更新时，你可能只需要更新这些配置，而无需改动核心算法。

5.4 算法还原中的细节错误

问题现象：sign计算出来了，但和浏览器实时计算的结果不一致。

排查思路：这是最耗时的部分。你需要进行“差分调试”。

1. 日志对比法：在浏览器的混淆JS中，在关键计算步骤前后插入console.log，输出中间变量的值。在你的还原算法中，在相同步骤也输出日志。逐行对比，找到第一个出现差异的地方。
2. 单元测试法：将整个算法分解成小函数（如decodeArg1、combineParams、hashRound1等）。为每个小函数编写测试用例，输入固定的值，确保其输出与浏览器中执行对应代码段的结果一致。
3. 关注位运算和整数溢出：JavaScript的数字是双精度浮点数，但位运算（>>>,<<,|,&）会先将操作数转换为32位有符号整数，运算后再转回。Python的整数是任意精度的，直接进行位运算不会自动截断。这是最常见的错误来源！在Python中模拟JS位运算时，必须手动模拟32位整数溢出：result & 0xffffffff。

解决技巧：对于复杂的位运算循环，可以写一个辅助函数来模拟JS的位运算行为：

def js_bitwise_unsigned_right_shift(val, n): """模拟JavaScript的 >>> 无符号右移""" if val < 0: val = val + (1 << 32) # 转换为补码形式的无符号整数 return (val >> n) & 0xffffffff def js_add_overflow(a, b): """模拟JavaScript加法，结果截断为32位无符号整数""" return (a + b) & 0xffffffff

整个逆向瑞数6.5sign的过程，是一场对耐心、细心和工程化能力的考验。它没有一成不变的银弹，核心在于理解其“动态验证”的思想，掌握“环境模拟”和“逻辑追踪”的方法论，并善于使用工具进行对比和调试。成功实现后，获得的不仅仅是一段可用的代码，更是对现代前端反爬技术原理的深刻理解。