去年年底接了一个电商联盟数据采集的需求对方要求从某头部电商平台的联盟后台拉取订单明细与佣金报表。前半年一直跑得好好的直到某天早上批量任务突然全部返回参数错误登录状态还在但接口就是不给数据。后台一查所有请求都卡在了一个叫h5st的加密签名参数上。那一刻我就知道平台已经把前端的风控签名从旧版本升级到了新版本网上流传的很多生成方案直接失效。这篇文章就围绕这个 h5st 3.1 签名参数讲讲我完整的逆向分析思路、Python 侧的落地实现以及实际调试中最容易踩的几个大坑。适合谁看如果你正在做电商开放接口的数据同步、广告联盟的订单归因分析或者单纯对前端加密参数的反爬对抗感兴趣这篇内容可以帮你少走很多弯路。我会尽量把每一步的原理和操作都拆开讲代码部分也会给出可以直接跑通的参考实现但务必注意所有逆向和技术分析仅用于学习研究和已授权业务场景请严格遵守平台规则与相关法律法规。1. 先把 h5st 3.1 到底是什么讲清楚1.1 这个参数在保护什么h5st 是电商平台前端生成的一段签名信息通常以 URL 参数或请求头的形式出现在接口请求中。它的核心作用有两个第一确认请求来自真实的浏览器环境而不是脚本或自动化工具第二防止请求参数被篡改和重放。换句话说服务器拿到 h5st 后会按照同样的算法对请求中的关键参数重新计算一遍签名如果两边对不上就直接拒绝响应。对于做开放接口数据同步的开发者来说h5st 往往不是故意要拦你而是因为它无法区分正常脚本请求和恶意攻击请求。联盟后台的订单查询、商品检索、佣金报表这类接口基本都套了这一层防护。旧版本可能只是一个简单的时间戳加 MD5但 3.1 版本引入了动态令牌、环境指纹、时间窗口和参数混淆整个生成过程复杂了很多。1.2 从 1.0 到 3.1 的变化我在之前维护的项目里经历过 h5st 1.0 和 2.0 两个阶段。1.0 时代签名算法相对透明只需要找到前端打包后的关键函数拿到固定的 appKey按照固定顺序拼接参数再用哈希算法生成摘要即可。2.0 开始引入了随机因子每次请求的签名都不一样但随机因子的生成逻辑仍然可以从 JavaScript 代码里分析出来。3.1 版本最大的变化是签名不再是“参数拼接 固定哈希”那么简单。它引入了会话级别的动态令牌令牌的生成依赖于一个复杂的计算链并和浏览器环境信息深度绑定。比如屏幕分辨率、时区、浏览器版本、canvas 指纹、时间偏移等都会参与计算。更麻烦的是签名算法本身经过了混淆和加密直接读代码基本读不通必须要配合动态调试才能一步步还原。1.3 为什么网上很多方案突然失效你可能会发现网上关于 h5st 的博客和代码片段其实不少但绝大多数都是针对旧版本的。平台升级到 3.1 之后很多关键变量名变了生成逻辑加了分支判断甚至同一套代码在不同时间点返回的签名结构都会有细微差异。最典型的情况是有的人把旧代码直接拿过来跑发现时间戳格式不对有的人则是算出来的签名偶尔有效、偶尔无效这通常是因为没有处理动态令牌的刷新机制。所以真正要做好 h5st 3.1 的适配不能只靠抄一段固定代码而是要理解它的整体设计并且把 Python 侧的生成流程做成灵活的、可配置的模块。2. 逆向分析从抓包到还原生成逻辑2.1 工具准备与初始抓包先说工具。我用的环境是 Windows 11 加 Chrome 浏览器配合抓包工具 Charles 和浏览器开发者工具进行联动分析。如果你习惯用 Fiddler 或者 mitmproxy思路完全一样关键是把 HTTPS 解密打开否则看不到请求体里的 h5st 参数。打开联盟后台的订单查询页面触发一次查询操作在抓包工具里找到对应接口。接口请求里会有一长串h5st参数长度通常在 100 到 200 个字符之间包含数字、字母和一些特殊符号。同时请求头里往往还会有一个cookie或token字段这个字段和 h5st 之间存在关联后面分析时需要注意。第一次抓包拿到数据后先别急着分析算法先把请求头和参数结构完整保存下来。我习惯把所有字段都存成一个 JSON 文件作为后续调试的基线数据。接下来要做的是在前端代码里定位 h5st 的生成位置。2.2 JS 断点定位关键函数Chrome 开发者工具里的“Sources”面板是分析前端代码的主战场。首先要做的是全局搜索h5st这个关键词找到所有出现位置通常是赋值语句或者函数入参。为了缩小范围可以在搜索框里输入h5st并筛选 JS 文件重点关注体积较大、命名混淆度高的几个文件。定位到可疑代码之后在对应的行上打一个断点然后回到页面重新触发一次查询。断点命中后查看调用栈Call Stack找到最上层与签名生成相关的函数。这里有个很实用的技巧如果 h5st 是异步生成的也就是说断点没有自动命中可以考虑在控制台里直接执行一次请求函数或者在 Network 面板里选中“发起程序”来跟踪调用链。拿到关键函数后不要急着读全部代码先把函数入参记录下来。h5st 生成函数通常接收多个参数包括原始请求参数、时间戳、一些随机串等。你需要搞清楚这些入参分别对应什么后续在 Python 里复现时才能知道每个参数该从哪里获取。2.3 还原算法结构在分析混淆代码时我习惯使用 Chrome 开发者工具自带的“Pretty Print”功能把压缩过的 JS 代码格式化。格式化之后代码的可读性会好很多但变量名仍然可能是_0xabc123这种形式没法直接看出含义。这时候不要逐行去读而是先找几个关键特征看时间戳怎么取。搜索Date.now、getTime、performance.now找到签名里时间戳的来源和格式。找加密算法特征。搜索md5、sha256、hmac或一些常见的编码函数比如btoa、charCodeAt。不过 3.1 版本通常不会直接用这些知名函数而是封装了自己的哈希函数算法名称可能也被混淆了。看动态令牌的生成。搜索一些可疑的字符串拼接和循环位移操作dytoken 或类似命名的参数往往就在这里生成。我当时还原出来的整体流程是先生成一个动态令牌和一个随机数然后把业务参数、时间戳、令牌、随机数一起拼成特定格式的字符串再做两轮哈希计算最后进行编码拼接。其中第一轮哈希的输出会作为第二轮哈希的输入之一形成串联关系。这个结构听起来不复杂但实际代码里充满了条件分支和冗余计算稍不留神就会看错。2.4 动态调试中必须注意的细节调试过程中有几个特别容易被忽略的坑。第一个是浏览器指纹的影响。h5st 3.1 会把 UA、屏幕宽高、语言、时区等环境信息纳入计算。同一个签名生成函数在普通电脑上和自动化浏览器里跑结果可能完全不同。这也解释了为什么很多人在本地算出来的签名是有效的一放到服务器上就失效。第二个是时间同步问题。签名里带了时间戳服务端会校验时间窗口通常允许的偏差在 30 秒到 2 分钟之间。服务器时间和你本地时间不一致或者 Python 代码里用了time.time()而前端用的是毫秒级时间戳都会导致校验失败。第三个是动态令牌的时效性。我遇到过一种情况调用一次页面会生成多个 h5st 参数有的可以复用一段时间有的则是一次性的。需要反复测试才能确定令牌的更新策略。测试方法很简单在同一个会话里连续发两个请求看 h5st 内容是否变化再隔几分钟发一个请求看是否还能通过校验。3. Python 侧的实现细节与代码落地3.1 整体架构设计等逆向分析做得差不多了就该把它转成 Python 代码。我的建议是不要把整个签名生成逻辑写成一个大函数而是拆成几个模块参数准备模块负责从业务请求中提取参与签名的字段并规范格式。令牌生成模块模拟动态令牌计算输出当前所需的令牌值。指纹生成模块模拟浏览器环境信息维护一份与目标环境一致的数据。签名计算模块将上述信息按特定顺序拼接执行哈希计算和编码产出最终 h5st。请求模块负责发起请求并自动处理签名刷新。这样的好处是当平台调整了某个环节时不需要改动全部代码只要修改对应模块即可。3.2 辅助函数哈希与编码这里直接提供一个简化但结构完整的示例方便你理解整体流程。先写几个基础函数import time import random import hashlib import urllib.parse def md5_string(data: str) - str: 标准的 MD5 摘要输出小写十六进制字符串。 return hashlib.md5(data.encode(utf-8)).hexdigest() def sha256_string(data: str) - str: 标准的 SHA-256 摘要输出小写十六进制字符串。 return hashlib.sha256(data.encode(utf-8)).hexdigest() def base64_encode(data: str) - str: 标准 Base64 编码去掉末尾换行符。 import base64 return base64.b64encode(data.encode(utf-8)).decode(utf-8).strip()实际逆向出来的 3.1 签名算法不一定是纯 MD5 或 SHA-256但核心组合思路差不多。你可以先用自己的哈希函数跑一遍如果校验不通过再对比前端代码里的哈希实现看看是不是加了盐值、变换顺序或者采用了自定义的摘要算法。3.3 签名生成核心代码下面是一段基于常见结构的核心代码它不保证和你遇到的那个平台版本完全一致但给出了可复现的编写思路def generate_h5st(params: dict, token: str, timestamp: int None) - str: 生成 h5st 签名参数。 :param params: 业务请求参数字典 :param token: 动态令牌 :param timestamp: 毫秒级时间戳默认取当前时间 :return: h5st 签名字符串 if timestamp is None: timestamp int(time.time() * 1000) # step 1: 将业务参数按照 key 的字典序排序并拼接 sorted_keys sorted(params.keys()) raw_items [] for key in sorted_keys: raw_items.append(f{key}{params[key]}) raw_string .join(raw_items) # step 2: 拼接 token、时间戳和原始请求串 first_seed f{token}|{timestamp}|{raw_string} first_hash md5_string(first_seed) # step 3: 将第一轮哈希结果再次与随机数、环境指纹拼接 env_fingerprint dpi1920x1080|langzh-CN|tz-480|uachrome_120 random_no random.randint(100000, 999999) second_seed f{first_hash}|{random_no}|{env_fingerprint} second_hash sha256_string(second_seed) # step 4: 编码拼接得到最终 h5st h5st base64_encode(f{timestamp}.{random_no}.{second_hash}) return urllib.parse.quote(h5st)这段代码里params需要是请求中真正参与签名的业务参数token来自前一步的令牌生成模块。环境指纹部分我写的是一个简化的字符串实际项目中很可能需要从 JavaScript 代码里分析出具体的拼接格式才能保证算出来的值能被服务端接受。3.4 请求模块与签名刷新机制签名不是生成一次就能一直用的通常每隔一段时间或者请求失败后就需要重新生成。我实际操作时的策略是维护一个签名管理器它的职责包括缓存当前 token并记录 token 的生成时间。当 token 过期或请求返回签名校验失败时自动触发一次令牌刷新。在每次请求前检查是否需要更新签名。下面是签名管理器的一个简化版本class H5STManager: def __init__(self, token_provider): self.token_provider token_provider self.token None self.token_expire_at 0 def get_token(self): now time.time() if not self.token or now self.token_expire_at: self.token, self.token_expire_at self.token_provider() return self.token def make_signature(self, params): token self.get_token() return generate_h5st(params, token)token_provider是提前写好的函数负责从另一套逻辑中获取动态令牌。这个函数的具体实现在不同场景下差异很大但只要保证返回值和过期时间点正确签名管理器就可以稳定工作。3.5 接入业务请求的完整示例假设你要请求联盟平台的订单查询接口核心代码如下import requests manager H5STManager(token_providerfetch_token_from_api) # 构造业务请求参数 query_params { page: 1, page_size: 20, start_time: 2025-01-01 00:00:00, end_time: 2025-01-31 23:59:59 } # 对请求参数做一次预处理 query_params_str urllib.parse.urlencode(query_params) # 生成签名 h5st_value manager.make_signature(query_params) # 发起请求把签名的关键参数放入请求体或请求头 resp requests.post( https://api.example.com/openapi/order/query, data{**query_params, h5st: h5st_value}, headers{User-Agent: Mozilla/5.0 ...} ) if resp.status_code 200: data resp.json() if data.get(code) sign_error: # 触发一次令牌刷新再重试一次 manager.token None h5st_value manager.make_signature(query_params) resp requests.post(...)这里我把具体接口地址替换成了示例域名你实际使用时改成自己的目标地址即可。请求失败后的重试逻辑一定要控制好频率避免连续重试造成更大风险。4. 常见问题与排查技巧实录4.1 签名校验失败每次都报参数错误这种情况最常见的原因是参与签名的参数和你实际请求的参数不一致。举个例子你的请求体里包含了page和page_size但签名计算时可能只对部分参数做了排序拼接或者还需要把额外的app_key、timestamp也纳入签名计算。我的排查方法是先固定一组参数手动计算一次 h5st再和前端页面里的 h5st 对比。如果完全一致说明算法逻辑正确如果不一致就去前端代码里看看到底有哪些参数参与了拼接。一个比较隐蔽的点是值可能不是原始字符串而是经过 URL 编码或去空格处理后的版本。4.2 签名偶发失效时好时坏如果签名大多数时候有效、偶尔失效优先排查时间戳和随机数部分。我遇到过一次比较头疼的情况本地生成签名后延迟了几秒钟才请求服务端判定时间窗口过期返回签名错误。后来我在代码里增加了重试机制并在重试时重新生成签名这才解决问题。另外一个容易忽略的点是毫秒级时间戳与秒级时间戳的混用 。前端代码里可能是毫秒级但你从接口返回的 JSON 里取到的可能是秒级两者相差 1000 倍一旦混了签名就完全不对。4.3 指纹相关参数导致的环境不匹配3.1 签名会考虑浏览器环境信息但很多 Python 代码里并没有模拟这部分内容。最初我也偷懒过直接写死了一组环境指纹结果在本地能通过部署到服务器上就失效。原因在于服务器没有真实的显示器、GPU 和字体列表前端脚本采集到的指纹信息自然不一样。要彻底解决这个问题比较实用的做法是从浏览器端把指纹参数导出来然后作为配置项传给 Python 侧。也就是说签名生成的部分可以在浏览器里跑Python 只需要负责请求调度和数据处理。如果一定要全部用 Python 实现就必须对指纹生成逻辑做完整的模拟这会大大增加工作量而且随着平台不定期更新维护成本很高。4.4 令牌抓取与自动化之间的冲突有些自动化方案可以做到用户无感知地携带动态令牌。但反过来如果令牌抓取得太频繁也容易被风控盯上。我的建议是设计一个合理的令牌缓存策略在令牌过期前不要重复抓取过期后再去刷新。同时请求频率尽量模拟真人操作不要用并发线程同时去轰接口。4.5 常见问题速查表现象可能原因处理方式所有请求都返回签名错误算法版本不匹配或参数顺序不对重新抓包并对比前后端签名签名偶发失效时间戳单位混用或请求延迟统一毫秒级时间戳延迟重试时重算签名本地有效、服务器无效指纹环境不匹配从浏览器侧导出指纹参数或引入真实浏览器执行环境偶尔出现验证码请求频率过高或令牌复用异常降低频率增加随机延时优化令牌缓存策略代码跑一段时间后失败平台调整了签名生成规则建议建立监控告警第一时间感知接口变更4.6 一个被很多人忽略的请求头问题h5st 只是签名机制的一部分实际请求中服务端还会校验请求头的顺序和附加字段。比如说某些自定义 header 字段的先后顺序如果和浏览器不一致也会命中风控。我用的方式是直接模拟浏览器实际发出的完整 header 集合不手动精简。有一种做法是直接把浏览器请求复制成 curl 命令再转成 Python 代码这样能最大程度保留原请求的特征。requests 库有个好处是可以通过session.headers统一设置公共请求头然后再针对单个请求调整个性化字段。5. 反爬对抗背后的一些延伸思考5.1 技术分析不等于鼓励违规抓取讲了这么多逆向和分析的方法但有一点必须反复强调这些技术手段只应该用在两个场景里。第一个是平台允许的开放接口场景比如你本身就是联盟平台的合法开发者只是需要解决自己业务中的数据同步问题。第二个是安全研究在授权范围内分析平台的防护机制是否足够健壮。如果你要用这些方法去抓取平台未开放的数据或者大规模采集用户信息那不仅违背平台服务协议还可能触碰法律红线。我见过不少因为违规爬虫而导致账号封禁甚至被告上法庭的案例真的不值得。做技术的人应该对规则保持敬畏。5.2 从对抗到共存的思路转变现在很多平台都在逐步开放标准 API支持开发者以更低成本获取数据。与其整天在研究逆向签名上投入大量精力不如花时间看看平台是否提供了官方的数据接口或者思考如何通过合理合法的方式获得数据授权。如果确有必要维护逆向逻辑我也建议一定要做好隔离。把签名生成、令牌管理、请求发送这些逻辑放在单独的服务里业务层尽量不要依赖具体的加密实现。这样未来平台升级签名算法时你只需要修改底层模块不需要大范围改动业务代码。5.3 维护长期稳定运行的关键最后分享一个小技巧给关键接口加上垫片检测和日志监控。我平时会在签名生成模块里埋一些日志记录每次生成的参数长度、时间戳、指纹来源。当接口开始出现大批量报错时通过这些日志能快速定位是算法变了是令牌通道出了问题还是某台服务器的环境指纹不稳定。日志格式不用太复杂但一定要标准建议使用 JSON 格式把请求路径、参数摘要、签名结果、状态码、耗时都记录下来。有了这些数据你才能在出问题时快速反应而不是靠猜。6. 写在最后的实际操作体会这套 h5st 3.1 的分析和落地我前前后后大概花了三天时间。分析过程最耗神的部分不是写代码而是反复比对不同请求下的签名差异确认哪些参与计算、哪些只是表象。整个项目跑通之后我又花了不少精力做稳定性优化包括令牌缓存和异常重试最终让批量任务可以连续运行很长时间不出问题。如果你也在做类似的事情我的建议是永远留一个“手动复现”的通道。也就是说在写自动化脚本前先通过浏览器手动触发一次请求并记录签名再用 Python 代码生成同样的签名两边对得上再往下走。这个习惯帮我排查了太多诡异的问题。另一点是不要迷信网上任何一份现成代码平台规则一直在变能让你长期依赖的只有自己的理解能力和调试能力。
去年年底接了一个电商联盟数据采集的需求对方要求从某头部电商平台的联盟后台拉取订单明细与佣金报表。前半年一直跑得好好的直到某天早上批量任务突然全部返回参数错误登录状态还在但接口就是不给数据。后台一查所有请求都卡在了一个叫h5st的加密签名参数上。那一刻我就知道平台已经把前端的风控签名从旧版本升级到了新版本网上流传的很多生成方案直接失效。这篇文章就围绕这个 h5st 3.1 签名参数讲讲我完整的逆向分析思路、Python 侧的落地实现以及实际调试中最容易踩的几个大坑。适合谁看如果你正在做电商开放接口的数据同步、广告联盟的订单归因分析或者单纯对前端加密参数的反爬对抗感兴趣这篇内容可以帮你少走很多弯路。我会尽量把每一步的原理和操作都拆开讲代码部分也会给出可以直接跑通的参考实现但务必注意所有逆向和技术分析仅用于学习研究和已授权业务场景请严格遵守平台规则与相关法律法规。1. 先把 h5st 3.1 到底是什么讲清楚1.1 这个参数在保护什么h5st 是电商平台前端生成的一段签名信息通常以 URL 参数或请求头的形式出现在接口请求中。它的核心作用有两个第一确认请求来自真实的浏览器环境而不是脚本或自动化工具第二防止请求参数被篡改和重放。换句话说服务器拿到 h5st 后会按照同样的算法对请求中的关键参数重新计算一遍签名如果两边对不上就直接拒绝响应。对于做开放接口数据同步的开发者来说h5st 往往不是故意要拦你而是因为它无法区分正常脚本请求和恶意攻击请求。联盟后台的订单查询、商品检索、佣金报表这类接口基本都套了这一层防护。旧版本可能只是一个简单的时间戳加 MD5但 3.1 版本引入了动态令牌、环境指纹、时间窗口和参数混淆整个生成过程复杂了很多。1.2 从 1.0 到 3.1 的变化我在之前维护的项目里经历过 h5st 1.0 和 2.0 两个阶段。1.0 时代签名算法相对透明只需要找到前端打包后的关键函数拿到固定的 appKey按照固定顺序拼接参数再用哈希算法生成摘要即可。2.0 开始引入了随机因子每次请求的签名都不一样但随机因子的生成逻辑仍然可以从 JavaScript 代码里分析出来。3.1 版本最大的变化是签名不再是“参数拼接 固定哈希”那么简单。它引入了会话级别的动态令牌令牌的生成依赖于一个复杂的计算链并和浏览器环境信息深度绑定。比如屏幕分辨率、时区、浏览器版本、canvas 指纹、时间偏移等都会参与计算。更麻烦的是签名算法本身经过了混淆和加密直接读代码基本读不通必须要配合动态调试才能一步步还原。1.3 为什么网上很多方案突然失效你可能会发现网上关于 h5st 的博客和代码片段其实不少但绝大多数都是针对旧版本的。平台升级到 3.1 之后很多关键变量名变了生成逻辑加了分支判断甚至同一套代码在不同时间点返回的签名结构都会有细微差异。最典型的情况是有的人把旧代码直接拿过来跑发现时间戳格式不对有的人则是算出来的签名偶尔有效、偶尔无效这通常是因为没有处理动态令牌的刷新机制。所以真正要做好 h5st 3.1 的适配不能只靠抄一段固定代码而是要理解它的整体设计并且把 Python 侧的生成流程做成灵活的、可配置的模块。2. 逆向分析从抓包到还原生成逻辑2.1 工具准备与初始抓包先说工具。我用的环境是 Windows 11 加 Chrome 浏览器配合抓包工具 Charles 和浏览器开发者工具进行联动分析。如果你习惯用 Fiddler 或者 mitmproxy思路完全一样关键是把 HTTPS 解密打开否则看不到请求体里的 h5st 参数。打开联盟后台的订单查询页面触发一次查询操作在抓包工具里找到对应接口。接口请求里会有一长串h5st参数长度通常在 100 到 200 个字符之间包含数字、字母和一些特殊符号。同时请求头里往往还会有一个cookie或token字段这个字段和 h5st 之间存在关联后面分析时需要注意。第一次抓包拿到数据后先别急着分析算法先把请求头和参数结构完整保存下来。我习惯把所有字段都存成一个 JSON 文件作为后续调试的基线数据。接下来要做的是在前端代码里定位 h5st 的生成位置。2.2 JS 断点定位关键函数Chrome 开发者工具里的“Sources”面板是分析前端代码的主战场。首先要做的是全局搜索h5st这个关键词找到所有出现位置通常是赋值语句或者函数入参。为了缩小范围可以在搜索框里输入h5st并筛选 JS 文件重点关注体积较大、命名混淆度高的几个文件。定位到可疑代码之后在对应的行上打一个断点然后回到页面重新触发一次查询。断点命中后查看调用栈Call Stack找到最上层与签名生成相关的函数。这里有个很实用的技巧如果 h5st 是异步生成的也就是说断点没有自动命中可以考虑在控制台里直接执行一次请求函数或者在 Network 面板里选中“发起程序”来跟踪调用链。拿到关键函数后不要急着读全部代码先把函数入参记录下来。h5st 生成函数通常接收多个参数包括原始请求参数、时间戳、一些随机串等。你需要搞清楚这些入参分别对应什么后续在 Python 里复现时才能知道每个参数该从哪里获取。2.3 还原算法结构在分析混淆代码时我习惯使用 Chrome 开发者工具自带的“Pretty Print”功能把压缩过的 JS 代码格式化。格式化之后代码的可读性会好很多但变量名仍然可能是_0xabc123这种形式没法直接看出含义。这时候不要逐行去读而是先找几个关键特征看时间戳怎么取。搜索Date.now、getTime、performance.now找到签名里时间戳的来源和格式。找加密算法特征。搜索md5、sha256、hmac或一些常见的编码函数比如btoa、charCodeAt。不过 3.1 版本通常不会直接用这些知名函数而是封装了自己的哈希函数算法名称可能也被混淆了。看动态令牌的生成。搜索一些可疑的字符串拼接和循环位移操作dytoken 或类似命名的参数往往就在这里生成。我当时还原出来的整体流程是先生成一个动态令牌和一个随机数然后把业务参数、时间戳、令牌、随机数一起拼成特定格式的字符串再做两轮哈希计算最后进行编码拼接。其中第一轮哈希的输出会作为第二轮哈希的输入之一形成串联关系。这个结构听起来不复杂但实际代码里充满了条件分支和冗余计算稍不留神就会看错。2.4 动态调试中必须注意的细节调试过程中有几个特别容易被忽略的坑。第一个是浏览器指纹的影响。h5st 3.1 会把 UA、屏幕宽高、语言、时区等环境信息纳入计算。同一个签名生成函数在普通电脑上和自动化浏览器里跑结果可能完全不同。这也解释了为什么很多人在本地算出来的签名是有效的一放到服务器上就失效。第二个是时间同步问题。签名里带了时间戳服务端会校验时间窗口通常允许的偏差在 30 秒到 2 分钟之间。服务器时间和你本地时间不一致或者 Python 代码里用了time.time()而前端用的是毫秒级时间戳都会导致校验失败。第三个是动态令牌的时效性。我遇到过一种情况调用一次页面会生成多个 h5st 参数有的可以复用一段时间有的则是一次性的。需要反复测试才能确定令牌的更新策略。测试方法很简单在同一个会话里连续发两个请求看 h5st 内容是否变化再隔几分钟发一个请求看是否还能通过校验。3. Python 侧的实现细节与代码落地3.1 整体架构设计等逆向分析做得差不多了就该把它转成 Python 代码。我的建议是不要把整个签名生成逻辑写成一个大函数而是拆成几个模块参数准备模块负责从业务请求中提取参与签名的字段并规范格式。令牌生成模块模拟动态令牌计算输出当前所需的令牌值。指纹生成模块模拟浏览器环境信息维护一份与目标环境一致的数据。签名计算模块将上述信息按特定顺序拼接执行哈希计算和编码产出最终 h5st。请求模块负责发起请求并自动处理签名刷新。这样的好处是当平台调整了某个环节时不需要改动全部代码只要修改对应模块即可。3.2 辅助函数哈希与编码这里直接提供一个简化但结构完整的示例方便你理解整体流程。先写几个基础函数import time import random import hashlib import urllib.parse def md5_string(data: str) - str: 标准的 MD5 摘要输出小写十六进制字符串。 return hashlib.md5(data.encode(utf-8)).hexdigest() def sha256_string(data: str) - str: 标准的 SHA-256 摘要输出小写十六进制字符串。 return hashlib.sha256(data.encode(utf-8)).hexdigest() def base64_encode(data: str) - str: 标准 Base64 编码去掉末尾换行符。 import base64 return base64.b64encode(data.encode(utf-8)).decode(utf-8).strip()实际逆向出来的 3.1 签名算法不一定是纯 MD5 或 SHA-256但核心组合思路差不多。你可以先用自己的哈希函数跑一遍如果校验不通过再对比前端代码里的哈希实现看看是不是加了盐值、变换顺序或者采用了自定义的摘要算法。3.3 签名生成核心代码下面是一段基于常见结构的核心代码它不保证和你遇到的那个平台版本完全一致但给出了可复现的编写思路def generate_h5st(params: dict, token: str, timestamp: int None) - str: 生成 h5st 签名参数。 :param params: 业务请求参数字典 :param token: 动态令牌 :param timestamp: 毫秒级时间戳默认取当前时间 :return: h5st 签名字符串 if timestamp is None: timestamp int(time.time() * 1000) # step 1: 将业务参数按照 key 的字典序排序并拼接 sorted_keys sorted(params.keys()) raw_items [] for key in sorted_keys: raw_items.append(f{key}{params[key]}) raw_string .join(raw_items) # step 2: 拼接 token、时间戳和原始请求串 first_seed f{token}|{timestamp}|{raw_string} first_hash md5_string(first_seed) # step 3: 将第一轮哈希结果再次与随机数、环境指纹拼接 env_fingerprint dpi1920x1080|langzh-CN|tz-480|uachrome_120 random_no random.randint(100000, 999999) second_seed f{first_hash}|{random_no}|{env_fingerprint} second_hash sha256_string(second_seed) # step 4: 编码拼接得到最终 h5st h5st base64_encode(f{timestamp}.{random_no}.{second_hash}) return urllib.parse.quote(h5st)这段代码里params需要是请求中真正参与签名的业务参数token来自前一步的令牌生成模块。环境指纹部分我写的是一个简化的字符串实际项目中很可能需要从 JavaScript 代码里分析出具体的拼接格式才能保证算出来的值能被服务端接受。3.4 请求模块与签名刷新机制签名不是生成一次就能一直用的通常每隔一段时间或者请求失败后就需要重新生成。我实际操作时的策略是维护一个签名管理器它的职责包括缓存当前 token并记录 token 的生成时间。当 token 过期或请求返回签名校验失败时自动触发一次令牌刷新。在每次请求前检查是否需要更新签名。下面是签名管理器的一个简化版本class H5STManager: def __init__(self, token_provider): self.token_provider token_provider self.token None self.token_expire_at 0 def get_token(self): now time.time() if not self.token or now self.token_expire_at: self.token, self.token_expire_at self.token_provider() return self.token def make_signature(self, params): token self.get_token() return generate_h5st(params, token)token_provider是提前写好的函数负责从另一套逻辑中获取动态令牌。这个函数的具体实现在不同场景下差异很大但只要保证返回值和过期时间点正确签名管理器就可以稳定工作。3.5 接入业务请求的完整示例假设你要请求联盟平台的订单查询接口核心代码如下import requests manager H5STManager(token_providerfetch_token_from_api) # 构造业务请求参数 query_params { page: 1, page_size: 20, start_time: 2025-01-01 00:00:00, end_time: 2025-01-31 23:59:59 } # 对请求参数做一次预处理 query_params_str urllib.parse.urlencode(query_params) # 生成签名 h5st_value manager.make_signature(query_params) # 发起请求把签名的关键参数放入请求体或请求头 resp requests.post( https://api.example.com/openapi/order/query, data{**query_params, h5st: h5st_value}, headers{User-Agent: Mozilla/5.0 ...} ) if resp.status_code 200: data resp.json() if data.get(code) sign_error: # 触发一次令牌刷新再重试一次 manager.token None h5st_value manager.make_signature(query_params) resp requests.post(...)这里我把具体接口地址替换成了示例域名你实际使用时改成自己的目标地址即可。请求失败后的重试逻辑一定要控制好频率避免连续重试造成更大风险。4. 常见问题与排查技巧实录4.1 签名校验失败每次都报参数错误这种情况最常见的原因是参与签名的参数和你实际请求的参数不一致。举个例子你的请求体里包含了page和page_size但签名计算时可能只对部分参数做了排序拼接或者还需要把额外的app_key、timestamp也纳入签名计算。我的排查方法是先固定一组参数手动计算一次 h5st再和前端页面里的 h5st 对比。如果完全一致说明算法逻辑正确如果不一致就去前端代码里看看到底有哪些参数参与了拼接。一个比较隐蔽的点是值可能不是原始字符串而是经过 URL 编码或去空格处理后的版本。4.2 签名偶发失效时好时坏如果签名大多数时候有效、偶尔失效优先排查时间戳和随机数部分。我遇到过一次比较头疼的情况本地生成签名后延迟了几秒钟才请求服务端判定时间窗口过期返回签名错误。后来我在代码里增加了重试机制并在重试时重新生成签名这才解决问题。另外一个容易忽略的点是毫秒级时间戳与秒级时间戳的混用 。前端代码里可能是毫秒级但你从接口返回的 JSON 里取到的可能是秒级两者相差 1000 倍一旦混了签名就完全不对。4.3 指纹相关参数导致的环境不匹配3.1 签名会考虑浏览器环境信息但很多 Python 代码里并没有模拟这部分内容。最初我也偷懒过直接写死了一组环境指纹结果在本地能通过部署到服务器上就失效。原因在于服务器没有真实的显示器、GPU 和字体列表前端脚本采集到的指纹信息自然不一样。要彻底解决这个问题比较实用的做法是从浏览器端把指纹参数导出来然后作为配置项传给 Python 侧。也就是说签名生成的部分可以在浏览器里跑Python 只需要负责请求调度和数据处理。如果一定要全部用 Python 实现就必须对指纹生成逻辑做完整的模拟这会大大增加工作量而且随着平台不定期更新维护成本很高。4.4 令牌抓取与自动化之间的冲突有些自动化方案可以做到用户无感知地携带动态令牌。但反过来如果令牌抓取得太频繁也容易被风控盯上。我的建议是设计一个合理的令牌缓存策略在令牌过期前不要重复抓取过期后再去刷新。同时请求频率尽量模拟真人操作不要用并发线程同时去轰接口。4.5 常见问题速查表现象可能原因处理方式所有请求都返回签名错误算法版本不匹配或参数顺序不对重新抓包并对比前后端签名签名偶发失效时间戳单位混用或请求延迟统一毫秒级时间戳延迟重试时重算签名本地有效、服务器无效指纹环境不匹配从浏览器侧导出指纹参数或引入真实浏览器执行环境偶尔出现验证码请求频率过高或令牌复用异常降低频率增加随机延时优化令牌缓存策略代码跑一段时间后失败平台调整了签名生成规则建议建立监控告警第一时间感知接口变更4.6 一个被很多人忽略的请求头问题h5st 只是签名机制的一部分实际请求中服务端还会校验请求头的顺序和附加字段。比如说某些自定义 header 字段的先后顺序如果和浏览器不一致也会命中风控。我用的方式是直接模拟浏览器实际发出的完整 header 集合不手动精简。有一种做法是直接把浏览器请求复制成 curl 命令再转成 Python 代码这样能最大程度保留原请求的特征。requests 库有个好处是可以通过session.headers统一设置公共请求头然后再针对单个请求调整个性化字段。5. 反爬对抗背后的一些延伸思考5.1 技术分析不等于鼓励违规抓取讲了这么多逆向和分析的方法但有一点必须反复强调这些技术手段只应该用在两个场景里。第一个是平台允许的开放接口场景比如你本身就是联盟平台的合法开发者只是需要解决自己业务中的数据同步问题。第二个是安全研究在授权范围内分析平台的防护机制是否足够健壮。如果你要用这些方法去抓取平台未开放的数据或者大规模采集用户信息那不仅违背平台服务协议还可能触碰法律红线。我见过不少因为违规爬虫而导致账号封禁甚至被告上法庭的案例真的不值得。做技术的人应该对规则保持敬畏。5.2 从对抗到共存的思路转变现在很多平台都在逐步开放标准 API支持开发者以更低成本获取数据。与其整天在研究逆向签名上投入大量精力不如花时间看看平台是否提供了官方的数据接口或者思考如何通过合理合法的方式获得数据授权。如果确有必要维护逆向逻辑我也建议一定要做好隔离。把签名生成、令牌管理、请求发送这些逻辑放在单独的服务里业务层尽量不要依赖具体的加密实现。这样未来平台升级签名算法时你只需要修改底层模块不需要大范围改动业务代码。5.3 维护长期稳定运行的关键最后分享一个小技巧给关键接口加上垫片检测和日志监控。我平时会在签名生成模块里埋一些日志记录每次生成的参数长度、时间戳、指纹来源。当接口开始出现大批量报错时通过这些日志能快速定位是算法变了是令牌通道出了问题还是某台服务器的环境指纹不稳定。日志格式不用太复杂但一定要标准建议使用 JSON 格式把请求路径、参数摘要、签名结果、状态码、耗时都记录下来。有了这些数据你才能在出问题时快速反应而不是靠猜。6. 写在最后的实际操作体会这套 h5st 3.1 的分析和落地我前前后后大概花了三天时间。分析过程最耗神的部分不是写代码而是反复比对不同请求下的签名差异确认哪些参与计算、哪些只是表象。整个项目跑通之后我又花了不少精力做稳定性优化包括令牌缓存和异常重试最终让批量任务可以连续运行很长时间不出问题。如果你也在做类似的事情我的建议是永远留一个“手动复现”的通道。也就是说在写自动化脚本前先通过浏览器手动触发一次请求并记录签名再用 Python 代码生成同样的签名两边对得上再往下走。这个习惯帮我排查了太多诡异的问题。另一点是不要迷信网上任何一份现成代码平台规则一直在变能让你长期依赖的只有自己的理解能力和调试能力。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
