知乎x-zse-96参数逆向分析：从JS混淆到Python纯算还原

1. 项目概述：从“黑盒”到“白盒”的逆向之旅

最近在分析某乎的接口时，不可避免地撞上了它的核心加密参数

x-zse-96

。这个参数就像一道坚固的城门，守护着其API数据的访问权限。对于数据分析师、爬虫工程师或者安全研究员来说，理解并还原这个参数的生成逻辑，意味着能够以更稳定、更高效的方式获取公开数据，进行舆情分析、内容研究或产品竞品调研。这绝不是一个鼓励“破解”或“攻击”的过程，而是一个典型的、在安全研究领域被称为“协议逆向工程”的实践。其核心目标，是理解一个合法客户端（如官方App或网页）是如何与服务器进行安全通信的，并尝试用代码复现这一过程，从而摆脱对模拟浏览器环境的依赖，实现纯算力请求。

x-zse-96

这个名字本身就透露了它的血统：“x-”开头的自定义HTTP头部，“zse”很可能是“ZhiHu SEcurity”的缩写，“96”则大概率指代其输出为96位（或12字节）的十六进制字符串。逆向分析它，本质上就是搞清楚一串看似随机的96位十六进制数，是如何由你的请求内容（如问题ID、时间戳、设备信息等）经过一系列加密、哈希、编码操作后生成的。最终实现的目标，是仅凭算法和必要的输入参数，在Python、JavaScript等任何编程环境中本地计算出完全一致的

x-zse-96

值，从而构造出能被服务器认可的合法请求。

这个过程充满了挑战，也极具学习价值。它不仅涉及对JavaScript混淆代码的静态分析与动态调试，还考验着对现代Web加密算法（如AES、HMAC、各种哈希）组合应用的理解。接下来，我将以一个资深逆向分析从业者的视角，带你完整走一遍从定位、分析到最终纯算还原

x-zse-96

的全过程，分享其中关键的思路、工具和踩过的坑。

2. 逆向分析的核心思路与工具选型

逆向分析一个Web端加密参数，最忌讳的就是一头扎进海量的混淆代码里。一个清晰的策略和合适的工具链，能让你事半功倍。我们的核心思路是“由外而内，动静结合”。

2.1 逆向分析的基本策略

首先，我们需要明确目标：找到生成

x-zse-96

参数的JavaScript代码块，并理解其输入、输出和中间处理过程。一个高效的策略通常分四步走：

2.2 工具链的选择与配置

工欲善其事，必先利其器。以下是经过实战检验的工具组合：

• 浏览器与开发者工具

  ：

  Google Chrome

  或

  Microsoft Edge

  的开发者工具是主力。它们的调试功能强大，对于JavaScript的格式化、断点、内存快照等支持最好。

• 抓包与调试代理

  ：

  Fiddler Everywhere

  或

  Charles

  。当需要分析移动端App（如知乎App）的请求时，需要将手机代理到电脑上的这些工具，以便捕获HTTPS流量。它们也能用于重发请求、修改请求参数进行测试，是动态测试算法还原正确性的关键。

• 反混淆与代码分析工具

  ：面对高度混淆压缩的代码，一个好用的格式化工具是必须的。浏览器开发者工具自带的“Pretty Print”（美化打印）按钮（通常显示为

  {}

  符号）是第一步。对于更复杂的、变量名被替换为

  a, b, c

  或

  _0xabc123

  这种十六进制形式的混淆，可以借助一些在线工具或VS Code插件进行初步的反混淆，但核心逻辑仍需通过动态调试来理解。

• 算法还原开发环境

  ：

  Python 3.x

  是我们的首选。因为它拥有极其丰富和易用的加密库（

  hashlib

  ,

  hmac

  ,

  Crypto

  ），并且脚本编写快捷，非常适合快速验证算法逻辑。配合

  Jupyter Notebook

  或

  VS Code

  进行分步调试和验证，体验极佳。

注意

：在逆向过程中，务必遵守目标网站的

robots.txt

协议，控制请求频率，避免对目标服务器造成压力。我们的目的是学习技术与方法，而非进行数据掠夺或服务干扰。

3. 定位与解析 x-zse-96 的生成逻辑

有了清晰的策略和顺手的工具，我们就可以开始实战了。假设我们已经通过抓包，找到了一个携带

x-zse-96

的请求，例如获取某个问题详情的API。

3.1 关键代码的定位与初步分析

在开发者工具的Network面板中，找到目标请求，右键选择“Copy -> Copy as cURL”或“Copy -> Copy as Node.js fetch”，可以快速获取到完整的请求信息，其中就包含

x-zse-96

头。

然后，我们转向Sources面板进行全局搜索。搜索“x-zse-96”可能直接定位到类似下面的代码片段（此为模拟的混淆后代码）：

function _0x12ab3c(_0x5e8d29) {
var _0x37c2a8 = _0x1a2b3d(_0x5e8d29);
var _0x59e1f4 = _0x22cd67(_0x37c2a8, _0x48b91e);
return _0x59e1f4['toString']('hex')['slice'](0, 96);
}
headers['x-zse-96'] = '2.0_' + _0x12ab3c(_0x8d2f1a);

这段代码虽然变量名面目全非，但结构清晰：一个函数

_0x12ab3c

接收参数

_0x5e8d29

，经过

_0x1a2b3d

和

_0x22cd67

两个函数处理，结果转成十六进制并截取前96位，最后在前面拼接上

'2.0_'

前缀。这很可能就是我们要找的核心函数。

接下来，我们在

_0x12ab3c

函数入口和

headers['x-zse-96']

赋值处打上断点，重新触发请求。当断点命中时，通过鼠标悬停或添加到Watch面板，查看

_0x5e8d29

和

_0x8d2f1a

的值。通常，它们会是一个包含多种信息的字符串或对象，可能由路径（path）、查询参数（query）、时间戳、Cookie中的某个关键值（如

d_c0

）等拼接而成。

3.2 动态调试与数据流追踪

通过单步执行（F11），我们进入

_0x1a2b3d

和

_0x22cd67

函数内部。这时需要高度关注：

例如，在调试中，你可能会发现

_0x1a2b3d

函数实际上是将输入字符串进行了一次特定的排序和拼接，而

_0x22cd67

函数则调用了

CryptoJS.HmacSHA256

，并且第二个参数是一个固定的字符串密钥。

一个更具体的发现流程可能是：

• 断点显示

  _0x8d2f1a

  是一个字符串，格式如

  /api/v4/questions/12345678/answers?limit=5&offset=0

  。

• _0x1a2b3d

  函数将其与Cookie中的

  d_c0

  字段值以及当前时间戳（可能经过取整）以某种分隔符（如

  +

  ）拼接起来。

• 拼接后的字符串传入

  _0x22cd67

  ，动态跟踪发现它调用了

  CryptoJS.HmacSHA256(message, key)

  。

• key

  是一个固定的字符串，比如

  "zse_96_v1_secret"

  （举例）。

• HMAC-SHA256 的结果是一个256位（32字节）的哈希值，

  toString('hex')

  后是64位十六进制字符串。

• 最后代码截取这个64位字符串的前24位（96位十六进制/4 = 24字节？这里需要精确验证），发现与实际

  x-zse-96

  值（去掉

  2.0_

  前缀后）的前24位相符？不，96位十六进制是48字节，这里逻辑需要厘清。实际上，96位十六进制是12字节（因为1字节=8位，1字节十六进制表示为2个字符，所以12字节=24字符）。所以更可能的是，HMAC-SHA256产生32字节哈希，然后可能经过Base64编码或其他变换，最终输出被截取或编码成24个字符的十六进制字符串？这正是调试要弄清的。

实操心得

：在动态调试时，善用

Console

面板。你可以直接在断点处，在Console中执行

copy(_0x5e8d29)

来将复杂对象复制到剪贴板，然后粘贴到文本编辑器中仔细分析。也可以手动调用怀疑的函数，传入已知值来验证其功能。

3.3 算法逻辑的归纳与验证

经过反复调试和多个不同请求的对比，我们可以归纳出

x-zse-96

版本2.0的一个可能生成逻辑（以下为示例逻辑，非真实算法）：

为了验证这个逻辑，我们需要在Python中复现这个过程。用同一个请求的原始数据（path, d_c0, timestamp）和推导出的密钥，按照上述步骤计算，看结果是否与抓包得到的

x-zse-96

值完全一致。通常需要多次调试和微调（如分隔符、时间戳精度、截取位置等），才能达到完全匹配。

4. 纯算还原：Python代码实现与关键细节

当我们通过动态调试，基本摸清了算法步骤后，就可以着手用Python进行纯算还原了。这里以假设的算法逻辑为例，展示实现代码和需要注意的关键细节。

4.1 依赖库与基础准备

首先，确保你的Python环境安装了必要的库。标准库

hashlib

,

hmac

,

base64

,

time

,

json

通常就足够了。

# 通常无需额外安装，除非使用CryptoJS兼容库等
# pip install pycryptodome # 如果需要AES等更多算法，但x-zse-96可能不需要

在代码开头，我们先导入库，并定义从抓包数据中提取的常量。

import hmac
import hashlib
import base64
import time
import urllib.parse

# 假设从一次抓包中获取的固定值和变量
SECRET_KEY = b"zse_96_v1_secret" # 注意：密钥可能是字节串，这里是假设
API_PATH = "/api/v4/questions/12345678/answers"
QUERY_PARAMS = {"limit": "5", "offset": "0"}
D_C0_COOKIE = "your_actual_d_c0_cookie_value_here"
# 抓包时的时间戳（Unix时间戳，秒级）
CAPTURED_TIMESTAMP = 1712345678

4.2 消息体拼接的精确还原

这是最容易出错的一步。分隔符、字段顺序、URL编码格式、时间戳的取整方式，都必须与JavaScript代码中完全一致。

def build_message(path, params, d_c0, timestamp):
"""
根据逆向分析结果拼接消息字符串。
注意：这里的格式（分隔符、是否包含‘？’、参数排序）必须与JS端严格一致。
"""
# 1. 处理路径和查询参数。JS端可能对完整URL或特定格式进行拼接。
# 示例：将参数按字母顺序排序后拼接，与JS端行为一致。
sorted_params = sorted(params.items(), key=lambda x: x[0])
query_string = '&'.join([f"{k}={v}" for k, v in sorted_params])
full_path = path
if query_string:
full_path += '?' + query_string

# 2. 时间戳处理。JS端可能是 Math.floor(Date.now() / 1000)
# Date.now() 返回毫秒，除以1000后取整得到秒级时间戳。
# 我们使用抓包时的时间戳，或生成当前的时间戳。
ts = int(timestamp)

# 3. 按照观察到的分隔符拼接。假设是 '|' 分隔。
# 消息格式: `full_path|d_c0|timestamp`
message = f"{full_path}|{d_c0}|{ts}"
return message.encode('utf-8') # 转换为字节串，供哈希函数使用

# 构建消息
message_bytes = build_message(API_PATH, QUERY_PARAMS, D_C0_COOKIE, CAPTURED_TIMESTAMP)
print(f"构造的消息体: {message_bytes.decode()}")

4.3 核心加密与哈希计算

根据调试结果，使用正确的算法和密钥进行计算。

def calculate_hmac_sha256(message, key):
"""计算HMAC-SHA256，返回二进制结果。"""
# 使用hmac库，算法名指定为'sha256'
hmac_obj = hmac.new(key, message, digestmod=hashlib.sha256)
return hmac_obj.digest() # 返回32字节的二进制数据

# 计算HMAC
hmac_digest = calculate_hmac_sha256(message_bytes, SECRET_KEY)
print(f"HMAC-SHA256摘要 (hex): {hmac_digest.hex()}")

4.4 结果编码与最终格式化

HMAC结果需要经过特定的编码和截取，才能得到那96位十六进制数。

def encode_and_format(digest):
"""
对HMAC摘要进行编码和格式化，生成最终的96位十六进制字符串。
这是最需要根据实际调试调整的部分。
"""
# 假设调试发现是：先Base64编码，然后截取第6-24位字符，再转hex。
# 步骤1: Base64编码
b64_str = base64.b64encode(digest).decode('utf-8') # 例如得到44字符的字符串
# 步骤2: 截取特定部分 (例如，从索引5开始，取18个字符)
# 注意：Python字符串索引从0开始，JS的 slice(6, 24) 对应Python的 [6:24]
slice_start = 6
slice_end = 24
sliced_b64 = b64_str[slice_start:slice_end] # 假设这是关键的一步

# 步骤3: 将截取的Base64字符串（每个字符是64进制）转换为字节，再转十六进制。
# 注意：Base64字符集是A-Za-z0-9+/，直接将其当作ASCII字节处理。
sliced_bytes = sliced_b64.encode('utf-8')
final_hex = sliced_bytes.hex() # 将字节转换为十六进制字符串

# 步骤4: 确保最终是96位（48个十六进制字符）。如果不是，可能需要调整截取逻辑。
# 96位二进制 = 12字节 = 24个十六进制字符。但我们的最终输出是96位十六进制字符？这需要澄清。
# 实际上，x-zse-96 的 ‘96’ 很可能指的是96位十六进制字符，即48字节？这太长了。更可能是96比特（bit），即12字节，用十六进制表示为24字符。
# 我们必须以抓包实际值为准。假设抓包值是24字符的十六进制。
if len(final_hex) != 24: # 24字符十六进制 = 96 bit
print(f"警告：生成的十六进制长度是{len(final_hex)}，不是24。需要检查算法。")
# 另一种常见逻辑：直接取HMAC摘要的前12字节（96位）转hex。
final_hex = digest[:12].hex() # 取前12字节，转24字符hex

return final_hex

# 生成最终的96位hex
x_zse_96_hex = encode_and_format(hmac_digest)
# 添加版本前缀
final_x_zse_96_value = f"2.0_{x_zse_96_hex}"
print(f"计算得到的 x-zse-96: {final_x_zse_96_value}")

4.5 完整可运行的示例脚本

将以上步骤整合，并加入与抓包值对比的验证环节。

import hmac
import hashlib
import base64
import time

def generate_x_zse_96(path, params, d_c0, timestamp, secret_key):
"""生成 x-zse-96 参数的核心函数"""
# 1. 拼接消息
sorted_params = sorted(params.items())
query_str = '&'.join([f"{k}={v}" for k, v in sorted_params])
full_path = path + ('?' + query_str if query_str else '')
message_str = f"{full_path}|{d_c0}|{int(timestamp)}"
message_bytes = message_str.encode('utf-8')

# 2. 计算HMAC-SHA256
hmac_digest = hmac.new(secret_key, message_bytes, hashlib.sha256).digest()

# 3. 编码与格式化（假设算法是取前12字节转hex）
# 这是需要根据实际逆向结果调整的关键部分！
# 假设真实算法就是取HMAC结果的前12字节（96位）
signature_hex = hmac_digest[:12].hex() # 24个十六进制字符

# 4. 添加前缀
return f"2.0_{signature_hex}"

# 使用示例
if __name__ == "__main__":
# 你的抓包数据
SECRET_KEY = b"your_real_secret_key_from_js" # 必须替换为真实密钥
API_PATH = "/api/v4/questions/12345678/answers"
QUERY_PARAMS = {"limit": "5", "offset": "0", "sort_by": "default"}
D_C0 = "your_d_c0_cookie"
TS = 1712345678 # 抓包请求发生的时间戳

# 生成签名
my_x_zse_96 = generate_x_zse_96(API_PATH, QUERY_PARAMS, D_C0, TS, SECRET_KEY)
print(f"Generated x-zse-96: {my_x_zse_96}")

# 与抓包值对比
captured_x_zse_96 = "2.0_a1b2c3d4e5f6789012345678" # 替换为实际抓包值
if my_x_zse_96 == captured_x_zse_96:
print("✅ 签名验证成功！")
else:
print("❌ 签名验证失败！请检查：")
print(" 1. SECRET_KEY 是否正确？")
print(" 2. 消息拼接格式（分隔符、字段顺序、URL编码）是否与JS完全一致？")
print(" 3. 时间戳的取值和取整方式是否正确？")
print(" 4. 最终编码截取逻辑（是取前12字节转hex，还是其他变换）？")

关键细节提醒

：

5. 常见问题、排查技巧与进阶思考

即使按照上述流程操作，在完全还原算法前，你很可能遇到各种问题。下面是一些常见坑点和排查技巧。

5.1 问题排查速查表

可能原因

排查步骤

5.2 进阶技巧与安全考量

5.3 从还原到工程化

当你的Python脚本能够稳定生成有效的

x-zse-96

后，可以考虑将其工程化：

• 封装成函数/类

  ：将密钥管理、消息构建、签名计算封装起来，提供简单的接口，如

  get_x_zse_96(url, cookie_d_c0)

  。

• 集成到爬虫框架

  ：可以编写Scrapy的中间件（Middleware）或requests的钩子（Hook），在发出请求前自动计算并添加签名头。

• 处理Cookie会话

  ：

  d_c0

  这类Cookie通常有有效期，需要实现一个会话管理机制，在过期时重新获取（可能需要模拟登录）。

• 错误处理与重试

  ：签名无效时，服务器会返回特定的HTTP状态码（如403、401）。你的代码应该能捕获这些错误，并尝试重新生成签名（例如，时间戳刷新后重试）或重新获取Cookie。

逆向分析

x-zse-96

这样的参数，是一个典型的“发现问题、分析问题、解决问题”的过程。它考验的不仅仅是技术，更是耐心、观察力和逻辑推理能力。每一次成功的还原，都会让你对Web安全、密码学应用和客户端-服务器交互有更深的理解。希望这份详细的指南和实录，能为你下一次的逆向之旅铺平道路。记住，最宝贵的不是最终那几行生成签名的代码，而是你一步步推导出这行代码的完整思维路径。