前端加密参数逆向：从定位JS到Python实现MD5签名

之前接了个需求，对方甩过来一个数据平台的接口文档，接口本身不复杂，但请求参数里有个字段一眼就让人皱眉——k。一个每次请求都会变化、看起来毫无规律的字符串，长度固定，既不像时间戳也不像简单的MD5。这种场景做爬虫的朋友应该都不陌生：参数加密，而且是前端JS动态生成的那种。调试了半天，最后发现所有的逻辑都藏在前端打包压缩过的JS里，不把这段逻辑逆清楚，你连一个合法的请求都拼不出来。

这篇文章我就用这个案例，把整个逆向过程从头到尾理一遍。从怎么在浏览器里定位k参数的生成位置，到怎么把混淆过的JS函数提炼出来，再到最后用Python原生实现同一套加密逻辑。全程不绕弯子，你跟着操作能复现出来就行。会涉及不少实操细节和踩坑记录，爬虫新手和做JS逆向有段时间的朋友应该都能用得上。

先说清楚边界：本篇所有分析基于授权测试环境，逆向的目的在于接口联调和数据获取流程的自动化优化。大家在做类似事情之前，自己先确认目标平台的服务条款和授权范围，这是底线。

1. 参数定位：从HTTP请求到JS执行现场

1.1 先把请求特征固定下来

打开目标网站的页面，按F12进入开发者工具，切到Network面板，刷新页面触发数据请求。会看到页面底部列表加载时发出了一堆XHR请求，其中一条就是我们需要的核心数据接口。

把这条请求点开，看几个关键位置：

• 请求URL里有没有额外的query参数，比如?page=1&size=20&k=xxxx
• 请求体（Payload或Request Body）里是JSON、FormData还是普通键值对
• 请求头和响应头里有没有特殊的自定义字段

以这个案例为例，请求体是典型的JSON格式，里面除了业务字段之外，就有那个k。点开Payload视图会看到类似这样的结构：

json复制{
  "page": 1,
  "limit": 20,
  "k": "3f6b7f0e0b6a4b4b8f7f8e3a4c9d0e2f",
  "timestamp": 1736000000000
}

注意几个细节：k的长度是32位，而且是十六进制字符，纯小写。这意味着它大概率是一次MD5或类似哈希运算的输出，或者是某种自定义加密后的十六进制表示。另外就是timestamp字段，这个网站把时间戳放在JSON里，说明后端会校验时间范围，时间偏差太大的请求直接拒绝。

这里有个通用经验：第一步别急着找加密逻辑，先把请求参数的结构、类型、长度这些特征记录下来。为什么？因为参数特征本身就给出了大量线索。32位hex基本可以锁定MD5家族，32位Base64可能是AES后编码，40位hex可能是SHA1，64位hex大概率SHA256。你心里有底了，后面断点调试时就有方向。

1.2 全局搜索：最快的定位方式

请求参数已经确认，下一步就是在JS源码里找到k的生成逻辑。

切到Sources面板，按Ctrl+Shift+F进行全局搜索，输入k:（带冒号，因为JSON里键值对的写法通常是k:或者"k":），或者直接搜k =、k: getK这类模式。全局搜索可能会命中几百个结果，因为字母k太常见了，这时候要缩小范围。

我一般会加几个过滤条件：

• 只看.js文件，排除html、css
• 搜索k:并配合"k"来筛选，能直接命中对象字面量写法
• 搜索timestamp加k，如果加密逻辑中同时出现了这两个字段，大概率是在同一个函数里做的

实际操作中，我是在一个叫chunk-xxxx.js的大文件里命中的。这个文件是典型的webpack打包产物，总大小超过1MB，所有代码都被压缩成一行，正常情况下根本没法直接阅读。但压缩归压缩，函数名、字符串常量还在，关键逻辑是可以搜索到的。

如果全局搜索迟迟找不到突破口，可以换个思路：对XHR/fetch请求打断点。在Sources面板右侧的XHR/fetch breakpoints里点击加号，输入请求URL中包含的路径片段，比如api/list，然后刷新页面。当浏览器准备发起这个请求时，会暂停在XMLHttpRequest.send或fetch调用处，右侧Call Stack会显示当前调用链，往回一层层翻，就能找到构造参数的那段代码。这个方法比全局搜索更精准，适合在代码量大、变量名被压缩的场景下使用。

1.3 调用栈回溯：从网络请求倒推函数链

在XHR断点断下后，右侧的Call Stack面板会列出当前执行所在的函数调用序列：

text复制setRequestHeader / send (XMLHttpRequest)
sendRequest (webpack://xxx/./src/api/request.js)
listQuery (webpack://xxx/./src/api/module.js)
handleSearch (webpack://xxx/./src/views/xxx.vue)

往上翻，从listQuery到getK这一链，最终会看到一个关键函数，它做了类似的事情：

javascript复制function generateK(timestamp) {
  var base = "some_fixed_salt_string";
  var raw = timestamp + base;
  return md5(raw).toString();
}

这个generateK就是我们需要的目标函数。函数体里面出现了一个固定字符串，然后用时间戳和它做拼接，最后走了一次MD5。

把这里整理一下，k的生成规则初步可定为：

text复制k = md5(timestamp + "固定盐值")

不过先别急着写Python代码，因为实际拿到的情况可能会更复杂。比如有些网站会先做一次MD5，再把结果转成大写，再拼上别的参数做第二次摘要，或者中间穿插Base64编码。一定要把单步执行走明白，把每一步的输入输出都记录下来，再做还原。

我习惯在浏览器Console里手动执行一遍这个函数：定义一个变量timestamp = 1736000000000，然后调用generateK(timestamp)，对比生成的值和请求包里实际抓到的k是否一致。如果一致，说明逻辑确认；如果不一致，说明还有隐藏参数或前置处理。

2. 加密逻辑还原：从混淆代码到可读算法

2.1 识别加密算法的关键特征

在拿到一堆压缩过的JS代码时，第一步不是通读全部代码，而是先识别算法指纹。

常见的识别入口有：

• 输出长度：32位十六进制，优先怀疑MD5；40位十六进制，SHD-1；64位十六进制，SHA-256；128位十六进制，可能是RSA对长文本加密后的十六进制输出
• 函数命名：压缩代码里如果保留了部分函数名，那么md5、sha256、AES、encrypt这类单词就直接暴露了算法类型
• 依赖的库：代码头部出现CryptoJS、jsencrypt、forge这类字样的，直接去对应库的文档里找标准调用方式
• 特征常量：RSA的010001公钥指数、AES的固定IV向量、SM4的固定S盒常量，这些在压缩代码里往往以十六进制字符串出现

在我们这个案例里，代码中存在一个叫md5的外部函数引用，在压缩文件中虽然被重命名了，但在函数列表里能看到它对应的来源模块是crypto-js/md5。这就是很典型的webpack打包后还保留了模块来源注释的情况，你顺着定位到的函数往上看webpack模块定义，能看到__webpack_require__加载了名为crypto-js的模块。

那就不纠结了，这个k就是MD5计算，原始字符串是timestamp + 固定盐值。

2.2 把核心函数改造成可独立运行的JS

拿到逻辑后，先在浏览器里验证一下。

在Console里直接跑：

javascript复制function md5(str) {
  // 这里指向crypto-js的md5方法，但为了快速验证，先在页面环境里用CryptoJS全局变量
  return CryptoJS.MD5(str).toString();
}

var timestamp = 1736000000000;
var salt = "xxxx"; // 实际逆向出来的固定盐值
console.log(md5(timestamp + salt));

对比Network面板里的k值，一致。

如果一致，接下来把这段逻辑抽出来，放到本地Node.js环境里跑，用于后续的Python方案对照。

在Node.js里跑的话，需要先装crypto-js：

bash复制npm install crypto-js

然后写一个独立的脚本：

javascript复制// getK.js
const CryptoJS = require("crypto-js");

function getK(timestamp) {
  const salt = "xxxx";
  return CryptoJS.MD5(timestamp + salt).toString();
}

// 测试
console.log(getK(1736000000000));

这一步的意义在于：后续你要用Python实现的话，必须有一个参照物来验证正确性。如果Python算出来的结果和这个JS结果不一致，说明你还原的逻辑有问题，和网站本身无关。

2.3 从JS函数到Python原生化实现

JS这边已经验证过，现在用Python把这套逻辑实现出来。MD5是标准摘要算法，不需要额外安装密码学库，直接用hashlib就行：

python复制import hashlib
import time

SALT = "xxxx"  # 逆向出的固定盐值

def generate_k(timestamp: int = None) -> str:
    if timestamp is None:
        timestamp = int(time.time() * 1000)
    raw = f"{timestamp}{SALT}"
    return hashlib.md5(raw.encode("utf-8")).hexdigest()

if __name__ == "__main__":
    print(generate_k(1736000000000))

运行后和JS里的输出比对，完全一致。

到这里，最核心的逆向任务其实已经完成了。后面要处理的就是如何把这个参数正确应用到实际请求中，以及在什么情况下这套逻辑会失效。

3. 请求联调：从单参数拼接到完整请求流程

3.1 构造完整请求体

generate_k拿到正确值后，把它放进请求体，用requests发起一次真实请求。

先做基础验证：

python复制import requests
import json
import time

url = "https://target-site.com/api/list"
timestamp = int(time.time() * 1000)
k = generate_k(timestamp)

payload = {
    "page": 1,
    "limit": 20,
    "k": k,
    "timestamp": timestamp
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
    "Content-Type": "application/json",
    "Origin": "https://target-site.com",
    "Referer": "https://target-site.com/"
}

resp = requests.post(url, json=payload, headers=headers)
print(resp.status_code)
print(resp.text[:500])

这一步跑通的话，说明服务端只校验了时间戳和k的匹配关系，暂时没有其他校验逻辑。

但实际场景通常不会这么顺利。我在这个案例里第一次请求就返回了403，原因是缺少了Cookie。当然，这一步Cookie不是手动设置的，而是首次访问网站首页时服务端种下来的，后续请求会带上它。requests本身不会自动管理cookie，需要用一个requests.Session()对象来保持会话。

python复制session = requests.Session()
session.get("https://target-site.com/", headers=headers)  # 先访问首页获取Cookie
resp = session.post(url, json=payload, headers=headers)

这样调整之后，请求就通过了，返回了正常的数据JSON。

3.2 常见状态码排查：403、401、400、418

联调过程中返回的每一个状态码都在告诉你某种信息，整理一下我这类场景常遇到的：

其中418这个状态码在浏览器里不会出现，但是用requests去访问某些WAF严格的目标时会出现，因为Python的requests库默认TLS指纹太明显。遇到这种情况，可以尝试使用curl_cffi库来模拟浏览器的TLS指纹：

python复制from curl_cffi import requests as cffi_requests

session = cffi_requests.Session(impersonate="chrome")
resp = session.post(url, json=payload, headers=headers)

这样处理能解决相当一部分TLS指纹类拦截，不需要去改代码逻辑。

3.3 频率控制与请求节奏

数据接口跑通了之后，还有一个容易被忽略的环节：请求频率。就算你的参数加密完全正确，如果每秒发几十个请求，风控系统照样会把你拉黑。

我一般会在请求之间加随机延迟，模拟人的操作节奏：

python复制import random
import time

time.sleep(random.uniform(2, 5))

如果目标数据量很大，还需要考虑多线程下的限流方案。比较稳妥的做法是维护一个请求间隔队列，每个线程发起请求前检查队列头部的时间戳，确保整体频率不超过设定的阈值。这种设计比每个线程各自sleep要可控得多。

4. 踩坑实录：环境缺失、动态盐值与参数时序问题

4.1 环境缺失：浏览器对象在Node里不存在

顺着上面的流程走，有个坑几乎是每个做JS逆向的人都会踩到的：当你在浏览器里成功验证逻辑后，想把这段JS直接搬到Node.js里运行，结果报错document is not defined或者window is not defined。

原因很简单：前端代码运行时依赖了浏览器环境对象。比如某个加密函数内部调用了window.localStorage.getItem("salt")，或者用document.getElementById("xxx").value作为参数输入，这些在Node.js环境里统统不存在。

遇到这种情况，有两条路：

第一条路是补环境。在Node.js里手工创建一个global对象，填上脚本需要的window、document等变量。但这个方法有一个问题：如果脚本里用到的DOM方法和属性特别多，你要一个一个去补，工作量会很大。适用于脚本体量小、依赖对象少的场景。

第二条路是重写算法。不要试图把整个JS文件塞进Node里跑，而是只提取算法核心，把依赖环境的部分替换成固定值或Python端传入的参数。以这个案例来说，如果盐值是某个固定字符串，那么你根本不需要执行原始JS，Python里直接算MD5就行。如果盐值是从某个接口动态获取的，那就先请求那个接口拿到盐值，再传入加密函数。

我的倾向是：能纯Python实现就纯Python实现，不能纯Python实现才考虑用Node子进程或PyExecJS执行。因为纯Python实现意味着你不需要在服务器上额外装Node.js环境，部署成本低很多，后续维护也更方便。

4.2 动态盐值：拿到的固定字符串突然失效

逆向出固定盐值后，跑了几天，突然发现k验证不过了，请求返回401或403。重新抓包一看，同样的时间戳、同样的算法，生成的值和服务端返回的完全不一样。

这种情况大概率是盐值被动态化了。

所谓动态盐值，指的是网站不定期更换加密用的固定字符串。有的网站是每周一换，有的是根据用户维度生成，也有的是由某个接口返回。

遇到这种情况，需要回到浏览器里重新定位盐值来源。看之前的代码里这个SALT是在哪个函数里被赋值的。如果是来自某个配置接口，把它找出来，在爬虫流程开始前先请求一次这个接口，动态传入盐值。

举个简单的例子，如果盐值来自一个名为/api/config的接口：

python复制def fetch_salt(session):
    resp = session.get("https://target-site.com/api/config")
    return resp.json()["data"]["salt"]

salt = fetch_salt(session)

def generate_k_with_salt(timestamp, salt):
    raw = f"{timestamp}{salt}"
    return hashlib.md5(raw.encode("utf-8")).hexdigest()

这样改完之后，即使盐值定期更换，也能通过更新配置接口来应对。当然，有些网站的盐值更换频率很高，每次请求前都要拉取，那就把fetch_salt的调用频率调到和请求频率一致，或者加一个本地缓存，盐值变化时再重新拉取。

4.3 参数时序：为什么手动测试正常，脚本里却不通过

还有一个坑很少被提起，但一旦遇到就会很头疼：时间戳参数和k的生成必须发生在同一个时间刻度上。

也就是说，你在生成timestamp和k的时候，用的是同一个值，而不是先取一个timestamp，等到真正发请求时又重新time.time()。如果两者出现偏差，哪怕只有几毫秒，服务端在验签时也可能判断为不合法。

典型的错误写法：

python复制payload = {
    "timestamp": int(time.time() * 1000),  # 这里取了一个时间戳
    "k": generate_k(int(time.time() * 1000))  # 这里又取了一次
}

如果两次调用的时间戳值不同，生成k的原始字符串和服务端验签的原始字符串就不一致，403就是必然的。

正确写法：

python复制timestamp = int(time.time() * 1000)
k = generate_k(timestamp)
payload = {"timestamp": timestamp, "k": k}

这个原则在几乎所有带时间戳的签名算法里都适用，不只是MD5。签名原文里用到的所有参数，都必须在签名生成前固定下来，不能边生成边取。

4.4 代码工程化：把逆向结果封装成可维护模块

上面的步骤跑通后，最后一步是把零散的函数整理成一个结构清晰、可复用的模块。不要把所有代码堆在一个文件里，也不要把盐值硬编码在请求代码中。我用下来的一个比较顺手的目录结构是：

text复制scraper/
├── config.py            # 配置文件、请求头、基础URL
├── crypto_utils.py      # 加密算法封装（generate_k等）
├── api_client.py        # 会话管理与请求封装
└── main.py              # 业务逻辑

crypto_utils.py里把加密逻辑独立出来，参数只暴露外部需要传入的：

python复制class CryptoError(Exception):
    pass

class RequestSigner:
    def __init__(self, salt: str):
        self._salt = salt

    def sign(self, timestamp: int) -> str:
        if timestamp <= 0:
            raise CryptoError("invalid timestamp")
        raw = f"{timestamp}{self._salt}"
        return hashlib.md5(raw.encode("utf-8")).hexdigest()

api_client.py里处理会话和请求：

python复制from requests import Session

class ApiClient:
    def __init__(self, signer: RequestSigner, session: Session = None):
        self._signer = signer
        self._session = session or Session()

    def query(self, page: int, limit: int):
        timestamp = int(time.time() * 1000)
        sign = self._signer.sign(timestamp)
        payload = {
            "page": page,
            "limit": limit,
            "timestamp": timestamp,
            "k": sign,
        }
        resp = self._session.post("https://target-site.com/api/list", json=payload)
        resp.raise_for_status()
        return resp.json()

这样的好处是：盐值变化时，只需要改配置文件或动态获取逻辑，不需要动业务代码；签名逻辑单独测试也方便。

注意：如果你是在公司项目里做这类功能，最好把签名模块写清楚注释，标注逆向分析时间、目标接口、盐值来源。这样后续接手的人不用重新踩一遍你走过的坑。

5. 实操总结与几个建议

整个逆向过程用到的核心能力就三样：浏览器开发者工具的使用、加密算法特征的识别、Python与JS之间逻辑的等价翻译。只要这三样过关，遇到大多数前端参数加密都能较快搞定。

再分享几个操作层面的经验：

第一，逆向过程中一定要多留验证节点。浏览器Console里算出值之后，立刻和抓包里的值做对比，不要等到写完Python代码再去验证。对比的时间越早，排错成本越低。

第二，压缩混淆代码不要硬啃。用Prettify格式化一下，代码就会可读很多。很多压缩代码长成一行，格式化之后再加上局部搜索，一眼就能看到关键函数。

第三，遇到复杂加密算法不要慌。不管是AES还是RSA，核心API就那么几个，CryptoJS的调用方式和Python的pycryptodome、cryptography库是一一对应的。把加密模式、填充方式、密钥格式、输出编码这四个要素确认清楚，翻译就只是时间问题。

第四，写爬虫代码时始终预留一个“人工确认”开关。也就是在配置文件里加一个DEBUG选项，为True时把每次请求的URL、参数、响应状态码都打印出来。这个开关在调试阶段非常有用，上线后可以关掉，但关键时候能救急。

回到最初的场景，那个看起来让人头疼的k参数，本质上是时间戳加盐后的一次MD5运算。逆向它没有用到任何高深的数学知识，也没有复杂的协议分析，靠的是从请求到JS再到Python的完整链路梳理。而这种链路梳理的能力，才是爬虫工程里真正值钱的部分。

最后再提一句：所有涉及加密绕过的技术，都应当用于自己拥有合法调用权限的目标。跑偏了方向，最终吃亏的还是自己。希望这篇记录对你手上的项目有帮助。