逆向某社区 App Shield 签名,完整流程公开

前言

某社区 App（版本 9.29.0）的接口签名体系，从设备注册到业务请求全链路纯 Python 实现，不依赖真机、不依赖 Frida，搜索/评论/主页 feed 全部 code=0。本文完整记录逆向思路、架构设计和关键代码。

一、目标与工具

1.1 目标

实现完全离线的接口调用能力：

本地生成 deviceId → 纯 Python 签名 → 业务接口 code=0

不需要真机、不需要 Frida 注入、不需要 RPC 桥接。

1.2 工具栈

二、签名体系全景

该 App 的接口保护分为 4 层签名，缺一不可：

┌─────────────────────────────────────────────────────┐│  Layer 1: shield (native so 生成，核心防护)          ││  Layer 2: x-mini-* (gid/sig/s1/mua，会话签名)      ││  Layer 3: xy-common-params (30+ 字段设备指纹)       ││  Layer 4: xy-platform-info (平台标识)               │└─────────────────────────────────────────────────────┘

2.1 签名头清单

2.2 关键发现

通过 jadx 反编译 + Frida hook，定位到签名链路：

OkHttp Interceptor 链（40 个 interceptor）  ├── TinyInterceptor      → x-mini-gid/sig/s1/mua  ├── PlatformInterceptor  → xy-common-params  ├── AccountInterceptor   → x-legacy-did/sid/fid  └── ShieldInterceptor    → JNI → libxyass.so → shield 头

核心结论：shield 签名完全在 native 层完成，Java 层只是传参。

三、Shield 签名逆向（核心）

3.1 定位 native 调用链

通过 Frida hook Native.intercept(chain, cPtr) 入口，trace 到 libxyass.so 内部调用链：

sub_7F094()  ← 入口：初始化签名上下文  → sub_7F224(ctx, 4, key64, 64)   ← 设置 64 字节密钥  → sub_7FEEC(ctx, canonical, len)  ← 输入 canonical 字符串  → sub_8001C(ctx, out16, out_len)  ← 输出 16 字节摘要

3.2 Canonical 构造

经 Frida hook sub_7FEEC 的输入参数确认：

defbuild_canonical(url, headers):"""    canonical = path + query + xy-common-params + xy-direction + xy-platform-info + xy-scene    """    parsed = urlparse(url)    parts = [parsed.path or"/", parsed.query or""]# 按固定顺序拼接指定 header 值for key in ["xy-common-params", "xy-direction", "xy-platform-info", "xy-scene"]:        parts.append(headers.get(key, ""))return"".join(parts)

这个发现解决了 HTTP 406 问题 —— 之前 canonical 少拼了 xy-scene 字段，导致签名校验失败。

3.3 核心摘要算法：sub_81CC4

这是 shield 签名的核心变换函数。约 800 条 ARM64 指令，OLLVM 控制流平坦化混淆。

逆向策略：不硬逆算法，而是 trace-lift —— 用 Frida 记录完整执行 trace，然后用 Python VM 重放。

# trace-lift 核心思路：# 1. Frida 记录 sub_81CC4 每条指令的 PC + opcode# 2. Capstone 反汇编为结构化指令# 3. Python VM 逐条模拟寄存器/内存操作from capstone import Cs, CS_ARCH_ARM64, CS_MODE_ARMdefexecute_trace(trace_file, input_state, input_block):"""在 Python 内存模型上重放 ARM64 trace"""    md = Cs(CS_ARCH_ARM64, CS_MODE_ARM)    md.detail = True    regs = [0] * 32# X0-X31    memory = bytearray(0x100000)# 加载输入    memory[STATE_ADDR:STATE_ADDR+len(input_state)] = input_state    memory[BLOCK_ADDR:BLOCK_ADDR+len(input_block)] = input_blockfor insn in trace:# 逐条执行 ARM64 指令语义        execute_single(insn, regs, memory)# 提取 16 字节输出return bytes(memory[OUT_ADDR:OUT_ADDR+16])

3.4 RC4 封包（sub_4B3D0）

摘要算出 16 字节 payload 后，还需要 RC4 加密 + 二进制头封装：

RC4_KEY = b"std::abort();"# 硬编码在 so 里的 RC4 密钥defpack_shield(payload16, device_id, build_code):"""    封包结构：    "XY" + Base64(header_16B + RC4(plain))    plain = [1, APP_ID, 2, len(build), len(deviceId), len(payload)]            + build_bytes + deviceId_bytes + payload16    """    build_b = build_code.encode()    device_b = device_id.encode()    plain = struct.pack(">IIIIII", 1, 0xECFAAF01, 2,                        len(build_b), len(device_b), len(payload16))    plain += build_b + device_b + payload16    cipher = rc4_crypt(RC4_KEY, plain)    header = struct.pack(">IIII", (4 << 16) | 4, 1, len(cipher), len(plain))return"XY" + base64.b64encode(header + cipher).decode()

四、x-mini-* 签名还原

4.1 x-mini-sig

defx_mini_sig(method, url, gid):"""HMAC-SHA256，key 是 gid"""    parsed = urlparse(url)    payload = f"{method.upper()}{parsed.netloc}{parsed.path}{parsed.query}"return hmac.new(gid.encode(), payload.encode(), hashlib.sha256).hexdigest()

4.2 x-mini-mua

defx_mini_mua(fp, url=""):"""Base64(JSON)，包含设备态摘要"""    obj = {"a": "ECFAAF01",       # app biz id"c": get_counter(url), # 接口相关计数器"k": fp.fp_hash,       # 32 hex per-session key"p": "a",              # platform = android"s": fp.fp_long,       # 64/128 hex 签名    }return base64.b64encode(json.dumps(obj, separators=(',',':')).encode()).decode()

4.3 x-mini-s1

defx_mini_s1(gid):"""62 字节固定结构"""    buf = bytearray(62)    buf[1] = 0x09# version    buf[5] = 0x01# flag    buf[6:6+56] = gid.encode()[:56]  # gid 填充return base64.b64encode(bytes(buf)).decode()

五、设备注册协议（DVF）

5.1 完整注册流程

Step 1: /api/v1/cfg/android         ← 拉初始配置Step 2: /api/v1/dvf/gch/android c=20 ← generate challenge (160B blob)Step 3: /api/v1/dvf/gch/android c=21 ← 第二次 challenge (16B nonce)Step 4: /api/v1/dvf/vat/android c=25 ← verify activation tokenStep 5: /api/v1/register/android c=44 ← 关键：发送 d_blob (1104B)Step 6: /api/v1/dvf/vav/android c=54 ← post-register verify

5.2 请求体核心字段

5.3 设备指纹生成

@dataclassclassDeviceFingerprint:    deviceId: str    # UUID v3 (nameUUIDFromBytes(android_id))    did: str         # 40 hex hardware did    oaid: str        # 64 hex OAID    gid: str         # 56 hex 会话级    sid: str         # "session.xxxxxxxxxxxxxxxxxxx"    fp_hash: str     # 32 hex (tiny k)    fp_long: str     # 128 hex (tiny s)    shield_key_hex: str  # 64 字节 key64    @classmethoddefrandom(cls):"""完全离线生成全新设备指纹"""        android_id = secrets.token_hex(8)        device_id = str(uuid.uuid3(uuid.NAMESPACE_DNS, android_id))# ... 生成其他字段

六、端到端架构

6.1 调用流程

from pure_python.protocol.device_fp import DeviceFingerprintfrom pure_python.client.api import XhsApifrom pure_python.signers.shield import make_signer# 1. 生成设备指纹fp = DeviceFingerprint.random()# 2. 创建签名器signer = make_signer("python")# 3. 调用业务接口api = XhsApi(fp=fp, shield_signer=signer)results = api.search_notes("关键词", page=1, page_size=20)comments = api.comments(note_id="xxx", num=10)feed = api.home_feed(num=20)

6.2 签名流程（单次请求）

XhsApi.search_notes("关键词")  │  ├── 1. 构造 URL + query 参数  ├── 2. build_common_params(fp) → xy-common-params (30+ 字段)  ├── 3. all_xmini_headers(fp, url) → x-mini-gid/sig/s1/mua  ├── 4. shield_signer.sign(method, url, fp)  │       ├── build_canonical(url, headers)  │       ├── sub_81CC4(state, canonical_block) → payload16  │       └── pack_shield(payload16, deviceId) → "XYxxxxx..."  └── 5. requests.get(url, headers=all_headers) → HTTP 200

七、实测结果

7.1 接口验收

7.2 RPC vs 纯 Python 对拍

对拍结论：HTTP 状态码、业务 code、data 结构完全一致。纯 Python 版已通过网关签名校验，不再依赖 Frida/真机。

7.3 多设备轮换

设备档案 1: deviceId=xxx  → 5 个接口全部 code=0设备档案 2: deviceId=yyy  → 5 个接口全部 code=0设备档案 3: deviceId=zzz  → 5 个接口全部 code=0...自动轮换，单设备被限流后切换下一个

八、AI 辅助逆向心得

8.1 AI 做了什么

1. OLLVM 反混淆分析 - 3600+ 条 ARM64 指令的控制流平坦化代码，AI 辅助识别出真实逻辑块边界
2. 签名字段定位 - 108k 个 jadx 反编译类中快速定位 OkHttp Interceptor 链
3. 协议字段推导 - 从抓包样本推导出 30+ 字段的 xy-common-params 拼接顺序
4. Canonical 修复 - 定位到 shield 签名的 canonical 少拼了 xy-scene 字段导致 406

九、关键踩坑记录

9.1 HTTP 406 排查

9.2 d_blob 重放规则

发现：d_blob 不校验时间戳、不绑定 deviceId，可跨设备重用。但 key64 绑定 deviceId —— 同一个 key64 只能给对应 deviceId 签名。

9.3 限流机制

限流维度：deviceId / uid 级别（非 IP 级别）被封表现：code=-100 或搜索返回空 items解决方案：轮换 deviceId，每个设备独立会话

总结

这次逆向的核心突破：

1. Shield 签名纯 Python 化 - trace-lift 策略绕过 OLLVM 混淆，不需要硬逆算法，用 Python VM 重放 ARM64 trace 即可
2. 4 层签名全部还原 - shield + x-mini-* + xy-common-params + xy-platform-info，缺一个都是 406
3. Canonical 构造 - path + query + 4 个指定 header 值拼接，少一个字段就签名失败
4. 设备注册协议 - cfg → gch → vat → register 四步走，d_blob 可重放是关键发现，目前这块还是差点意思

逆向 native so 的正确姿势不是硬逆 OLLVM，而是 trace-lift：记录执行轨迹，用高级语言重放。 这个思路适用于所有 OLLVM 混淆的签名算法。

AI 在这个项目里的价值是读代码的速度 —— 108k 个类里定位签名入口、3600 条混淆指令里识别逻辑边界，这些以前要几天的工作现在几分钟完成。