某股票网 ab_sr 参数逆向分析

在对某股票网站的接口请求进行排查时，我注意到获取最新股价信息并不只是普通的接口调用。除了请求头中的 acs-token 之外，请求链路里还有一个非常关键的 Cookie 字段：ab_sr。本文围绕 ab_sr 的生成方式展开，重点梳理其定位思路、混淆处理方法、加密逻辑以及实际请求中真正起作用的参数。

需要说明的是，ab_sr 并不是直接写死在页面里的静态值，而是通过前置请求动态下发。其核心入口是一个类似 /abdr 的接口，请求时会携带若干参数，其中最关键的是 data 字段，而逆向工作的重点也正是在于弄清楚 data 的构造与加密过程。

一、ab_sr 的作用与整体请求链路

从接口行为来看，想正常获取股票相关数据，至少需要准备两部分内容：

• 请求头中的 acs-token
• Cookie 中的 ab_sr

其中，ab_sr 并非业务参数本身，更像是一类浏览器环境校验或设备指纹凭证。服务端会先通过前置接口校验客户端环境，再决定是否放行后续的行情请求。

进一步观察可发现：

• ab_sr 需要通过专门的接口获取；
• 请求参数里包含加密后的 data；
• 即使 ab_sr 可以被成功拿到，如果前置字段构造不完整，后续股价接口依然可能失败。

这说明服务端并不是只检查 Cookie 是否存在，而是会进一步验证其来源与上下文是否可信。

二、定位加密逻辑：从关键词搜索到混淆脚本还原

一开始直接搜索 data、abdr 等关键词，往往找不到有效线索。原因很简单：这部分逻辑通常会被压缩、混淆，甚至把字符串拆分后再动态拼接。

在这类场景下，更稳妥的思路不是硬搜业务字段，而是寻找通用 API，例如：

• encodeURIComponent
• JSON.stringify
• AES
• sha1
• 动态创建 DOM 或 Canvas 的逻辑

沿着 encodeURIComponent 往下追踪后，可以较快锁定到一个高度混淆的脚本模块。该模块内部包含大量字符串解码函数、十六进制转义串以及字典映射，直接阅读成本很高，因此更高效的做法是先把混淆层剥掉，再还原业务逻辑。

我这里采用的是比较朴素但很有效的方法：

1. 先还原字符串解密函数

脚本中存在一个类似 b() 的函数，专门负责把混淆字符串还原成真实内容。将这个函数单独抽出后，可以借助 Python 调用 JS 执行，把原脚本里所有 b('0x...') 形式的表达式批量替换成明文。

2. 再处理十六进制转义字符

像 \x75\x72 这一类内容，解码后才能恢复出真实字符串。批量转换之后，代码可读性会提升非常明显。

3. 替换字典常量

混淆代码里常见把关键字符串放进对象映射表，再通过 ph['xx'] 方式访问。把这些常量全部替换成实际值之后，剩余逻辑基本就能顺藤摸瓜看清楚了。

经过这三步，原本难以阅读的混淆代码通常会变成一个结构清晰得多的版本。此时再去搜索 data，定位加密入口就不困难了。

三、data 字段的核心：AES-CBC 加密

还原后可以确认，data 的生成本质上是一次 AES-CBC 加密。它通常接收四个参数：

• 明文内容
• key
• iv
• 输出格式控制项，用于决定最终产物是 hex 还是 base64

也就是说，ab_sr 的前置请求并不是简单上传一组 JSON，而是先采集浏览器环境，再将这些字段组织成明文对象，最后经过 AES-CBC 处理后提交给服务端。

从逆向结果看，明文里包含了几十个字段，涵盖了大量浏览器指纹信息。虽然字段很多，但真正影响请求是否成功的，并不是全部参数。

四、明文字段分析：这其实是一套浏览器指纹采集方案

从字段内容来看，这套 ab_sr 参数生成逻辑明显属于典型的浏览器指纹采集机制，主要覆盖以下几类信息。

1. 屏幕与显示环境

这部分字段主要包括：

• 屏幕分辨率
• 可用区域尺寸
• 色深
• 设备像素比
• 物理像素相关属性

这些信息用于判断访问端是否符合真实浏览器特征，也是最常见的设备环境指纹之一。

2. 浏览器能力检测

脚本会主动探测多种浏览器特性，例如：

• localStorage、sessionStorage 是否存在
• indexedDB 是否可用
• cookieEnabled 的值
• 视频格式支持情况
• eval 是否表现为原生函数
• 某些旧版兼容属性是否存在

这类检测的目标通常是识别异常运行环境，比如不完整的自动化浏览器、简化版 JS 引擎或补环境不足的爬虫运行时。

3. 插件、MIME 与 Navigator 信息

还原后能看到脚本会读取大量 navigator 字段，包括：

• userAgent
• language
• platform
• vendor
• appName
• appCodeName
• product
• plugins
• mimeTypes
• hardwareConcurrency
• deviceMemory

这一部分是浏览器指纹中最具代表性的组成部分，也是逆向时最值得优先确认的数据源。

4. Canvas 与 WebGL 指纹

脚本中存在典型的 Canvas 检测逻辑，还会进一步读取 GPU 供应商与渲染器信息。这类字段通常用来构建设备级差异特征，例如：

• Canvas 渲染结果摘要
• WebGL Vendor
• WebGL Renderer

如果补环境时忽略了这一层，前端脚本虽然可以跑通，但最终生成的数据可能与真实浏览器偏差较大。

5. 电池、触控与自动化特征

还有一部分字段用于判断当前环境是否像“真人设备”，比如：

• 电池状态与电量信息
• 最大触控点数
• 触摸事件支持情况
• webdriver 是否存在
• 是否存在特定自动化或代理注入痕迹

特别是 webdriver 相关字段，在自动化环境里很容易暴露问题，因此是调试阶段必须重点关注的部分。

五、字段很多，但真正关键的并不多

完整明文对象包含几十项参数，看上去非常复杂，但实际分析下来会发现一个重要结论：

服务端未必会严格使用每一个字段。

也就是说，前端脚本虽然采集了大量信息，但在当前站点的校验策略下，其中相当一部分字段可能只是冗余采集，或者仅用于风控评分，而不是硬性校验项。

结合调试结果，可以把字段分为三类：

1. 固定值或可稳定复用字段

这类参数通常不随环境频繁变化，例如：

• 版本号
• 某些脚本常量
• 固定哈希片段
• 静态配置值

2. 当前环境实时采集字段

例如：

• 时间戳
• 页面 URL
• userAgent
• 分辨率
• 语言
• 平台信息

3. 关联计算字段

这类字段通常不是直接读取，而是基于已有字段进一步计算得到，比如：

• 某些字段组合后的 sha1
• 基于随机挑选字段再摘要的结果
• 以时间戳、URL、referrer、UA 等拼接后生成的校验值

从实际请求效果看，以下几项值得重点关注：

• 时间戳相关字段
• 由多字段组合生成的哈希值
• 页面 URL 与 UA 参与计算的摘要
• 版本与常量字段

这些参数之间存在依赖关系，只拿到表面字段而忽略联动计算，往往会导致 ab_sr 能生成，但后续业务接口不通过。

六、几个最关键的动态参数

在这套参数体系里，有几项动态字段尤其关键。它们的共同特点是：

• 依赖当前时刻；
• 依赖页面上下文；
• 依赖前面已采集的指纹字段；
• 会通过 sha1 或 AES 再次处理。

可以概括为以下几类：

1. 时间戳字段

这类字段通常直接取 new Date().getTime()，或者基于时间差构造。它们会参与后续多个参数的摘要计算，因此不能随意写死。

2. 指纹组合摘要字段

部分字段会从若干环境参数中挑选元素，打乱顺序后再做 sha1，目的是增加伪造成本。虽然实现方式不复杂，但如果没有把前置字段准备好，结果就无法复现。

3. 页面上下文摘要字段

常见做法是把以下内容拼接后做哈希：

• 随机数
• 页面 URL
• document.referrer
• navigator.userAgent
• 当前时间戳

这种字段的目的，是把本次访问与当前页面上下文绑定起来，避免 Cookie 被脱离场景地长期复用。

七、实际调试结果：生成 ab_sr 只是第一步

一个容易被忽略的点是：

能拿到 ab_sr，不代表一定能成功请求股价接口。

测试过程中可以发现，即便只保留少数字段，也有机会请求到 ab_sr。但如果后续再去访问行情接口，请求仍然可能失败。原因通常有两个：

• 前置环境信息不完整，服务端认为这份 Cookie 不可信；
• 某些关联字段虽然不是获取 ab_sr 的强校验项，却是后续业务接口放行的参考条件。

这说明该站点的风控策略至少分为两层：

• 前置 Cookie 下发阶段
• 业务接口访问阶段

第一层相对宽松，第二层才是真正决定能否稳定取数的地方。

八、逆向这类参数时的实用方法

如果你也在分析类似的浏览器指纹参数，我建议优先采用下面这套思路：

1. 不要急着逐行读混淆代码

先做自动化替换，把字符串、字典、十六进制转义全部还原。很多时候，真正的业务逻辑只有几十行，复杂的是外壳而不是核心。

2. 先找加密入口，再回溯明文来源

与其先研究每一个采集字段，不如先确认：

• 明文对象在哪里组装
• 最终由哪个函数加密
• key、iv 从哪里来
• 输出是 hex 还是 base64

只要入口明确，后续字段分析就能按图索骥。

3. 优先识别“硬校验字段”

并不是所有参数都要百分之百还原。真正影响通过率的，通常是：

• 时间戳
• URL / referrer / UA
• 浏览器指纹主字段
• 二次哈希字段
• 版本与常量字段

先把这些关键项跑通，效率会高很多。

4. 注意异步采集逻辑

部分字段并不是同步返回的，尤其像电池信息、某些环境检测、异步指纹计算等，经常会通过回调或递归方式汇总。阅读代码时如果只看同步流程，很容易误判参数来源。

九、结论

整体来看，这个 ab_sr 参数的逆向难度并不算特别高，难点主要不在算法本身，而在于：

• 前端脚本混淆较重
• 采集字段数量多，排查过程比较繁琐
• 部分字段之间存在联动计算关系

从加密层面说，它本质上仍然是比较常见的 AES-CBC + 哈希摘要 + 浏览器指纹采集 的组合方案。真正耗时的是把混淆层剥开、定位关键字段、区分哪些参数必须补齐，哪些参数可以暂时忽略。

如果只从“能否生成 ab_sr”这个角度看，门槛不高；但如果目标是“稳定获取股价信息”，那就必须把前置 Cookie、上下文字段和后续请求链路一起打通。也正因为如此，这类参数分析的重点从来不只是解密本身，而是完整理解它在整个请求流程中的角色。

对于类似站点，我的建议是始终围绕三个问题展开：

• 参数在哪里生成
• 服务端真正校验了什么
• 哪些字段决定后续业务接口是否放行

只要这三点明确，ab_sr 这样的参数就不再神秘了。