[原创] 某招聘 App 搜索接口逆向与纯算-Android安全-看雪安全社区

最近在看某招聘 App 的职位搜索接口，把 native 层简单逆了下，实现纯算复现协议签名。

抓包：搜索请求的 query 里挂着一个 `sp`（几百字符的密文串）和一个 `sig`（`V3.0` 开头的 32 位 hex），请求体是二进制，响应应该也是密文。这三样都出自一个 native 库 `libyzwg.so`（JNI 包装类 `com.twl.signer.YZWG`，Java 侧封装 `com.twl.signer.a`）。

版本是 v14.050（`Y29tLmhwYnIuYm9zc3poaXBpbg==`）。

环境：

| 层 | 工具 |
|---|---|
| 静态 | jadx-headless-mcp + IDA（反编译 `libyzwg.so` ） |
| 预言机 | unidbg 加载 `libyzwg.so`，做黑盒差分 |
| 动态 | Pixel 6（root）+ 反检测 frida |
| 复现 | Python（`lz4` + `requests`） |

---

## 一、静态分析加签公式

搜索结果列表顺着 `GeekSearchCardRequest` 找到端点和关键的通用加签层 `net.bosszhipin.base.m` ，它的 `c()` 给每个请求补公共参数（`curidentity`/`v`/`req_time`/`uniqid`/`client_info`），然后按请求是不是批量，分流到 `e()`（普通）或 `f()`（批量）。搜索走批量，`f()` 反编译结果如下（去噪）：

```java
private static void f(mf0.b bVar, String url, boolean z11) {
    BatchBodyBean body = bVar.d();
    Map<String,String> params = bVar.c();
    String key = z11 ? LBase.getSecretKey() : null;          // 白名单决定是否带 key
    String strD = d(params);                                  // 排序 + URLEncoder + k=v&
    byte[] encBody = com.twl.signer.a.e(bg0.n.h(body), key); // nativeEncodeRequestBody(bodyJson, key)
    bVar.y(encBody);                                          // 请求体 = 密文字节
    String strA = com.twl.signer.a.a(encBody);               // nativeCalculateCRC32(密文体)
    String sp  = com.twl.signer.a.d(strD, key);              // nativeEncodeRequest -> 参数 sp
    bVar.w("sp", sp);
    if (strD.length() > 5000) strD = strD.substring(0, 5000);
    String sig = com.twl.signer.a.i(config.m.f(url) + strD + strA, key);  // nativeSignature -> 参数 sig
    bVar.w("sig", sig);
}
```

- `strD` = 参数按 key 字典序排序、value 走 `URLEncoder.encode(...,"UTF-8")`、拼 `k=v&`（`d()` 就是干这个）。
- `sp = nativeEncodeRequest(strD, key)`，作为 query 参数。
- `sig = nativeSignature(f(url) + strD + strA, key)`，`f(url)` 是 URL 从 `/api/` 起的路径，`strA` 是加密后请求体的 CRC32。
- `key` 由 `config.m.j(url)` 白名单决定，批量端点 `/api/batch/requests` 落在白名单里 → key=null。

`com.twl.signer.a` 就是这层 native 的 Java 薄封装，每个方法都会转发到对应的 `nativeXxx`：

![com.twl.signer.a 的反编译](upload/attach/202608/1085268_49M8MPUXAPCB5QP.webp)

关键逻辑全在`libyzwg.so` 里：`nativeSignature / nativeEncodeRequest / nativeEncodeRequestBody / nativeCalculateCRC32 / nativeDecodeContent`。

---

## 二、把 so 跑成一个差分预言机

`libyzwg.so` 4.47MB、OLLVM 平坦化、字符串加密、JNI_OnLoad 里带反重打包自检，反汇编难度较大。先让这个 so 在 unidbg 里跑起来，当一个可以任意喂输入、看输出的黑盒预言机，用差分探针把算法的形状摸出来。

跑 unidbg 的门槛是 `JNI_OnLoad` 的反篡改自检，用 `-Dvmverbose=1` 看 JNI upcall 序列：`getPackagesForUid` 要真实包名、`getPackageInfo(pkg, GET_SIGNATURES).signatures[0].toCharsString().hashCode()` 要等于内嵌常量。满足它（喂真实证书 DER + 补一个真的 `String.hashCode`），`JNI_OnLoad` 就正常返回、native 方法注册上了。

签名侧：

```
sig(base, K)   = V3.0626c2a6ae2afe24c4b71c8021de5fe2a
sig(base, null)= V3.0b327810b631fb33ea5ebced128511edc      # key 参与运算
sig(base, K2)  = V3.0917a6ac34d4f4f44c6231c4bcc32d8d5
sig(flip1bit)  = V3.09763ceb2d98f7b8c2017bd3735887d5f      # 1 bit 翻转全变 = 哈希
sig("")        = V3.0a86fce5b188c8c0f6c61392d2cea407c
```

全部是 `V3.0` + 32 hex（=16 字节，MD5 家族），前导 `0` 恒定，key 参与。但拿真机抓的一条 `(input, key, sig)` 三元组去对撞 `md5(input+key)`、`md5(key+input)`、`hmac` 等等，一个都不中。哈希里还包含一个内嵌盐。黑盒推不出盐，这步必须分析汇编。

`sp` 探针的线索：

```
sp(inlen= 0)  outlen=36    # 空输入密文就有开销
sp(inlen=16)  outlen=56
sp(inlen=32)  outlen=56    # 32 字节和 16 字节几乎等长 -> 压缩
sp(16*'A')  ... 和 sp(32*'A') 长度几乎一样
```

把 base64 解回原始字节观察：同一个 key 下，前 12 字节恒定（`70e22488554382feca2200f2`，换 key 就变）；再把 `16*'A'` 和 `32*'A'` 两条 payload 逐字节 XOR，结果几乎全 `00`，keystream 被抵消了。`sp = 头(仅由 key 决定) + [ compress(input) XOR keystream(key) ]`，是流密码、不是分组，且密钥流只由 key 决定（sp 确定、无随机 IV）。这跟之前分析过的 GCash APSE 的 `zipAndEncryptData` 很类似。

---

## 三、攻坚 sig：从 RegisterNatives 到内嵌salt

`JNI_OnLoad`（OLLVM 平坦化，状态机在一个 `v5` 上转）里能看到 `(*env + 1720)` 就是 `RegisterNatives`，注册表 `off_443030`、10 个方法，类名走 `FindClass(0x443130)`。类名那串 `5f 53 51 13 48 4b 50 13...` 用 `XOR 0x3c` 一解就是 `com/twl/signer/YZWG`。so 里的字符串都是 XOR 混淆，而且每个字符串用不同的单字节 key，末尾那个字节就是 key（存的是 `0x00^key`）。照这个规律把 name/sig 表整个解出来：

```
nativeSignature      [BLjava/lang/String;)[B                 -> 0x23b6c
nativeEncodeRequest  [BLjava/lang/String;)Ljava/lang/String; -> 0x1f6ac
nativeEncodeRequestBody                                      -> 0x206b8
nativeCalculateCRC32 [B)Ljava/lang/String;                   -> 0x28388
nativeDecodeContent  (两个重载)                              -> 0x24980 / 0x26404
```

反编译 `nativeSignature`（0x23b6c），核心的 buffer 拼接如下：

```c
v43 = keylen? + input_len;
v44 = key_len + salt_len + input_len;
ptr = malloc(v44 + 1);
memcpy(ptr,            input,          input_len);   // ① input
memcpy(&ptr[input_len],qword_444470,   salt_len);    // ② 盐 = qword_444470
if (key_len > 0)
    memcpy(&ptr[input_len+salt_len], key, key_len);  // ③ key
v15 = sub_1C6E0(ptr, v44);                            // 哈希(整个 buffer)
v18 = sub_1C5CC(&byte_443804, v15);                  // 前缀 + hash
```

![nativeSignature(sub_23B6C) 里的 buffer 拼接](upload/attach/202608/1085268_93R3SG3HM35KK3T.webp)
`sig = 前缀 + HASH(input ‖ qword_444470 ‖ key)`。前缀 `byte_443804`（`cb ae b3 ad`，XOR key `0x9d`）解出来是 `"V3.0"`。`qword_444470` 是 `JNI_OnLoad` 里算好缓存的一个 32 字符串，由证书签名的 hashCode 派生（就是反篡改校验那个常量），对官方签名是定值。

salt 的值直接从 unidbg 内存里 dump：

```
[salt] qword_444470 -> salt="a308f3628b3f39f7d35cdebeb6920e21" len=32
```

真机 oracle：

```
target(after V3.) = 0648236f9e4faf41e4446836fb756c1e7
md5(input|salt|key) = 0648236f9e4faf41e4446836fb756c1e7   match=True
```

`sig = "V3.0" + md5(input ‖ salt ‖ key)`，完全匹配。

---

## 四、攻坚 sp：BZPBlock + LZ4 + 混淆的 RC4

反编译 `nativeEncodeRequest`（0x1f6ac）：

1. `s = SALT ‖ key`（key 为空则 s=SALT），作为后面的密钥材料；
2. `sub_1D338` 压缩：`LZ4_compress_limitedOutput(input)` 写到 `dst+24`，前面补 24 字节头：`*(u64)dst = 0x6B636F6C42505A42`（小端就是 `"BZPBlock"`）+ `u32(0)` + `u32(压缩长)` + `u32(原长)` + `u32(原长 ^ 压缩长)`；
3. `sub_340CC(ctx, s, len)` + `sub_34740(ctx, buf, buf, len)` 就地加密压缩数据，`ctx` 是 `_BYTE[264]`，正好一个 RC4 S-box；
4. `sub_2EA54` base64、`sub_1CD94` 把 `+/=` 换成 `-_~`。

![图片描述](upload/attach/202608/1085268_X6MCRTCDXBZAV8Q.webp)

头前 12 字节 `"BZPBlock"+u32(0)` 是常量明文，RC4 keystream 固定，异或出来就是固定的 12 字节密文；后面 `压缩长/原长/校验` 才随输入变。

`sub_340CC` 是标准 RC4 KSA（`S[i]=i` 初始化，`j = j + S[i] + key[i%len]` 交换）；`sub_34740` 是 RC4 PRGA，但每个字节套了一层 `TWIST(x) = (~x & 0xCF) | (x & 0x30)`：

```c
out[n] = TWIST(keystream_byte) ^ TWIST(in[n]);
```

`0xCF | 0x30 == 0xFF` 且不重叠，所以 `TWIST(x) == x ^ 0xCF`，两次 TWIST 在 XOR 时相互抵消，`out = keystream ^ in` 就是标准 RC4，TWIST 纯属混淆。

![图片描述](upload/attach/202608/1085268_YXCNSFHUWEPTR9J.webp)
纯 Python 复现，对照 unidbg 的全部合成样本 + 真机样本：

```
== sp verification ==
  in=b''                 key=82a8b7 match=True
  in=b'ABCDEFGHIJKLMNOP' key=82a8b7 match=True
  in=b'A'*16 / b'A'*32 / mixed / key=null / key=K2   全 True
== real-device oracle ==
  sig match=True
  sp  leading chars identical to device capture: 16/400
  round-trip my sp -> plaintext == input : True   meta={complen,origlen,chk_ok}
```

真机 2086 字节样本只有前 16 个 b64 字符（=那 12 字节恒定头）逐字节相同，往后就对不上了：设备的 liblz4 和 python-lz4 对同一输入做了不同但都合法的压缩选择，头里的压缩长不一样。但我的 sp round-trip 解回原文成功、校验位对，服务器只解压不比字节，所以照样接受（后面实测证明了）。

剩下三个原语：`nativeCalculateCRC32` = `snprintf(..., "%u", crc32(x))`（IEEE CRC32 的无符号十进制串，空输入返 `""`）；`nativeEncodeRequestBody` 和 sp 同管线、只是最后返回原始字节不 base64；`nativeDecodeContent` 是逆（RC4 解密，视情况再 BZPBlock/LZ4 解压）。

---

## 五、纯算协议复现

搜索走 `GET /api/batch/requests`，body 里带上请求：

```json
{"subReqs":[{"method":"GET","path":"/api/zpgeek/app/geek/search/cardlist","query":"query=Python&city=...&page=1&..."}]}
```

外层 `strD` 的参数（`client_info`/`curidentity`/`req_time`/`uniqid`/`v`）要用 Java `URLEncoder` 风格编码：`~`→`%7E`、空格→`+`、保留 `.-*_`。这点很容易踩：Python 默认 `quote` 会保留 `~`，编出来的 strD 和服务器重算的对不上、sig 就废。按 Java 规则实现一个 `java_url_encode`，逐字节对拍捕获的 strD 和子 query，两个都 `match=True`，才敢用它重建查询。

踩着服务器的报错往前走：

```
# 第一版：query 只放 strD + sp + sig，body = encBody
HTTP 200  {"code":-1001,"message":"请求参数非法."}
```

分析装配代码，`app_id` 是在 `f()` 签名之后才 `bVar.w("app_id", ...)` 加进去的：它不进 strD 签名，但要发在 query 里，第一版漏了。补上 `app_id=1003` + 刷新 `req_time`（strD 变、重算 sp/sig）：

```
HTTP 200  {"code":0,"message":"Success","zpData":{
  "/api/zpgeek/app/geek/search/cardlist":{"code":1,"message":"invalid auth"}}}
```

外层 `code:0 Success`，sp/sig/参数/body/CRC 全过了；内层搜索子接口 `invalid auth`，缺登录态。auth 藏在哪？wire 层的公共头是更底层的 okhttp 拦截器加的（它把 okhttp3 整个混淆成了 `okhttp3.h0/a0/c0`，按原名 hook 不到）。从它自己的响应解码拦截器 `net.bosszhipin.base.a` 里取 `chain.request()` dump 头：

```
t2: <auth-token>
zp-accept-encrypting: 1     zp-accept-compressing: 3
User-Agent: NetType/wifi Screen/1080X2209 <App>/14.050 Android 36
```

`t2` 就是账号登录 token。补上 `t2` + `zp-accept-*` + 正确 UA 再发：

```
HTTP 200 len 12937  resp-hdrs {zp-encrypting:1, zp-compressing:2}
outer: 0 Success
cardlist: 0 Success
jobs: 15
  - Python代码运维（远程兼职） | 4000-4500元/月 | x码 | 杭州
  - python工程师（app逆向） | 18-30K | 浙江xx传媒科技 | 杭州
  - ...（共 15 条，与搜索结果逐条对上）
```

最终响应头 `zp-encrypting:1 / zp-compressing:2`，响应体是 `RC4(BZPBlock+LZ4(json))` 的二进制。用 `nativeDecodeContent` 的 RC4 解密 + BZPBlock 解 frame 还原成 JSON形式的真实职位数据。

已封装成cli工具：
<a href="elink@82bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3j5X3!0K6M7#2)9J5k6r3y4D9K9b7`.`.">github.com/1013503897/boss-cli</a>
 ![图片描述](upload/attach/202608/1085268_9Y4GV8NBDGS2AW6.webp)
相关工具:

| 工具 | 用途 |
|---|---|
| <a href="elink@5a6K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3K9X3q4V1P5q4)9J5k6r3S2W2j5h3c8D9k6i4y4K6i4K6u0V1L8h3y4H3">jadx-headless-mcp</a> | dex 反编译 |
| <a href="elink@0cfK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0M7X3g2^5L8$3c8A6j5g2)9J5c8X3W2V1j5g2)9J5k6s2m8J5L8#2)9J5k6r3#2U0M7l9`.`.">ida-pro-mcp</a> | so 反汇编 / 伪代码 |
| Claude Opus 5 | AI 辅助分析 / 编排 |

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2026-9-1 14:43 被星野安全编辑，原因：

#逆向分析

最新回复 (76) 1 2 3 4 ▶
龙游天下178 雪币： 169 活跃值： (2262) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 26 粉丝 1 关注私信	龙游天下178 2 楼 6666 2026-8-18 13:35 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 707 粉丝 7 关注私信	mb_ldbucrik 3 楼感谢分享 2026-8-18 13:42 0
温泉划水鱼雪币： 94 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 226 粉丝 28 关注私信	温泉划水鱼 4 楼 66 2026-8-18 14:07 0
mb_ykavguun 雪币： 1313 活跃值： (1830) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 166 粉丝 0 关注私信	mb_ykavguun 5 楼 66 2026-8-18 14:11 0
method 雪币： 1972 活跃值： (8178) 能力值： ( LV5，RANK：70 ) 在线值：发帖 13 回帖 268 粉丝 134 关注私信	method 1 6 楼 1 2026-8-18 14:29 0
k4y0z 雪币： 325 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 144 粉丝 1 关注私信	k4y0z 7 楼 666 2026-8-18 14:36 0
mb_fidppcok 雪币： 3805 活跃值： (4140) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 95 粉丝 1 关注私信	mb_fidppcok 8 楼 6666 2026-8-18 15:27 0
CAlbert_hub 雪币： 33 活跃值： (445) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 12 粉丝 0 关注私信	CAlbert_hub 9 楼 666 2026-8-18 15:54 0
mb_npylpnpl 雪币： 88 活跃值： (735) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 21 粉丝 0 关注私信	mb_npylpnpl 10 楼 666 2026-8-18 17:17 0
mb_donutrph 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 54 粉丝 0 关注私信	mb_donutrph 11 楼 666 2026-8-18 17:27 0
xtyuns 雪币： 396 活跃值： (983) 能力值： ( LV3，RANK：20 ) 在线值：发帖 1 回帖 57 粉丝 0 关注私信	xtyuns 12 楼学习一下 2026-8-18 17:45 0
mb_jnmxfjku 雪币： 109 活跃值： (820) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_jnmxfjku 13 楼 666 2026-8-18 18:56 0
落音吹雪雪币： 205 活跃值： (186) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 44 粉丝 0 关注私信	落音吹雪 14 楼可否询问大佬使用的模型？ 2026-8-18 21:03 0
iBa0 雪币： 1901 活跃值： (5928) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 490 粉丝 37 关注私信	iBa0 15 楼 1111 2026-8-18 23:02 0
kingking888 雪币： 3235 活跃值： (6337) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 302 粉丝 6 关注私信	kingking888 16 楼 666 2026-8-18 23:19 0
wx_插曲雪币： 411 活跃值： (991) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 323 粉丝 24 关注私信	wx_插曲 17 楼 66 2026-8-19 08:52 0
小明的爱雪币： 1 活跃值： (502) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 16 粉丝 0 关注私信	小明的爱 18 楼 6 2026-8-19 09:03 0
wx_jy 雪币： 0 活跃值： (192) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	wx_jy 19 楼 666 2026-8-19 09:10 0
列子御风雪币： 20 活跃值： (110) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 10 粉丝 0 关注私信	列子御风 20 楼 666 2026-8-19 09:21 0
lxyjyy 雪币： 2509 活跃值： (4199) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 16 粉丝 0 关注私信	lxyjyy 21 楼 6666 2026-8-19 10:21 0
hacker521 雪币： 2676 活跃值： (5841) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 226 粉丝 30 关注私信	hacker521 22 楼 666 2026-8-19 10:28 0
mb_qimctavn 雪币： 5329 活跃值： (6790) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 402 粉丝 1 关注私信	mb_qimctavn 23 楼 6 2026-8-19 11:00 0
mb_jhohnbzu 雪币： 28 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 83 粉丝 0 关注私信	mb_jhohnbzu 24 楼 666 2026-8-19 11:44 0
guijingwen 雪币： 7377 活跃值： (7605) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 312 粉丝 0 关注私信	guijingwen 25 楼 66 2026-8-19 13:54 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复