防得最狠的地方往往最不值钱--xx总结-Android安全-看雪安全社区

## 引言

从一款 App（下称 T-App）里拆出来五套 Native 防护体系，逆完摊开一看，发现它们在讲同一件事：

**工程精力全砸在"藏"上，但藏的地方跟真正值钱的地方经常对不上号；防护力度的分布，跟检测结果有没有被服务端真正拿去用，是两件完全脱钩的事。**

```
T-App
 ├─ 子系统 A：设备指纹（SDK-S，OLLVM 三层混淆，检测结果静默上报服务端决策）
 ├─ 子系统 B：请求签名（libG.so，伪装 OpenGL + 内嵌 QuickJS，现役、最硬）
 ├─ 子系统 C：短码 + RSA（libN.so，手写密码学，短码退役、RSA 仍在用）
 ├─ 子系统 D：自定义加固壳（壳-N，自实现 Linker，独立于上述三者）
 └─ 子系统 E：机密通道（Java 层 DES+RSA，解密第三方平台自动化脚本）
```

一个个说吧

---

## 第一幕：libN.so —— 一颗被"退役"的手写密码学心脏

这是全文最小的一个库，19KB 出头，却是我逆得最爽的一个——不是因为简单，而是因为它的每一层混淆手法都很"朴素"，没有平坦化，没有加密函数指针，纯粹靠命名混淆、段隔离和诱饵撑门面，逆起来像拆一个精巧但没有真正上锁的盒子。

### 1.1 侦察：19KB 里能榨出多少情报

拿到一个陌生二进制，我的习惯是先不读一行反汇编，把导出表、导入表、字符串、段布局这四样过一遍——这四样交叉比对，往往能在写下第一个断点之前，就把这个库的身份、用途、防护手段猜个七八成。

字符串扫下来，整个库的意图几乎是明牌：`"[REDACTED_PKG]"`（宿主包名的痕迹）、导出名里蹭了一个知名开源裁剪库的包名做马甲、Base64 字母表和 RSA 公钥 DER 头的片段全都在。最有意思的是导入表——一个会算 HMAC-SHA1、Base64、RSA 的库，**导入表里居然没有任何 `libcrypto`/BoringSSL 的符号**。这就一件事：所有密码学原语都是作者自己手写、编译进 `.text` 的。这既解释了为什么 19KB 能塞下这么多功能，也提前预告了后面会看到一坨手写的 SHA-1 轮函数——这个反直觉点我们后面再展开，先看段布局。

段表里多出一个 `.mytext`，三个最敏感的 JNI 函数（`encode`/`getrsakey`/`checkSignature`）恰好全在这个自定义段里。看到非标准段名，逆向时应该立刻条件反射：**这里面装的东西，作者认为值得单独隔离**——这跟标准 Clang 产出的 `.text` 形成鲜明对比，是个很便宜但很有效的"划重点"信号。

再往下看编译器指纹：函数序言用 `STP X29,X30` 加 `MRS X8,TPIDR_EL0` 读栈 canary，NEON 指令密集，除法被替换成"乘以模逆再移位"——这些都是 Clang -O2 以上的产物。但**没有任何控制流平坦化的痕迹**，每个函数的 CFG 都是干干净净的菱形结构。这跟同一个 App 里另一个库（我们第三幕要讲的 SDK-S）形成了一个很鲜明的对照：**同一个 App，不同的库，混淆投入完全不是一个量级**。这是"资产分级"这条主线第一次冒头。

### 1.2 JNI 层：一个只有一条指令的"障眼法"

静态导出表里能看到一个方法，反编译出来只有一条汇编：

```c
__int64 Java_xxx_TempEncodeUtil_encode() {
    return real_encode_impl();   // 汇编就一条: B .real_encode_impl
}
```

这是个纯粹的跳板（thunk）。它的存在只是为了让"按 JNI 命名约定静态绑定"这条路看起来是通的——系统能找到这个符号，但真正干活的函数藏在 `.mytext` 里，而且更关键的是，**这个静态导出根本不是 App 实际调用的入口**。真正的方法绑定藏在 `JNI_OnLoad` 里，靠 `RegisterNatives` 动态注册——JNI 有两种绑定方式，静态命名约定和动态注册，后者的好处是导出表里看不到方法名与地址的对应关系，逆向者必须先读懂 `JNI_OnLoad`、解出注册表数组，才知道哪个地址对应 Java 的哪个方法。这道门槛不高，但确实拦了一层。

解出注册表后，三个方法的真实职责是：一个恒真桩（`checkSignature`，两条指令 `MOV W0,#1; RET`）、一个 RSA 公钥拼装器（`getrsakey`）、和这个库真正的心脏——一套 7 字符短码生成算法（`encode`）。

### 1.3 `encode` 核心算法：一整套 HOTP 拼出来的"防刷短码"

这是这个库着墨最多的地方，我们把全景数据流先摆出来：

```
s1 ──► Base64编码 ──────────────────────────┐  作 HMAC 的密钥 K
                                             ▼
s2 ─atoi─┐                          ┌─────────────────────┐
         ├─► n = atoi(s2)+cnt ────►│  HMAC-SHA1(K, C)      │──► mac[20]
s3 ─┐    │  C = big_endian_u64(n)  │                       │
    └─统计s3中数字个数cnt┘          └─────────────────────┘
                                             │  RFC4226 动态截断
                        off = mac[19] & 0x0F
                        DT  = be32(mac[off:off+4]) & 0x7FFFFFFF
                                             ▼  自定义Base58展开5位
                        table = 固定26字符 + upper(s3)
                        code[k] = table[(DT // 58^k) % 58]   k=0..4
                                             ▼  GF(2⁸)混淆+%100校验
                        chk = sum(gfmix([code1..4])) % 100
                                             ▼
                        return code[0..4] + "%02d"%chk   ← 7字符
```

熟悉 RFC 4226（HOTP）的人应该秒懂这个结构——`HOTP(K,C) = Truncate(HMAC-SHA1(K,C))`，这个库把这套标准结构原样搬了过来，唯一不一样的是：标准 HOTP 里 `K` 是一个长期不变的共享密钥，这里反过来，`s1`（运行时输入）才是密钥载荷，counter 反而是一个从入参凑出来的小整数。**这意味着这个库内部不存在任何长期秘密**，短码的安全性完全寄托在"没人知道组装方式"这一件事上。这个设计选择我第一次看到的时候愣了一下——这不是标准做法，但仔细想也不奇怪：移动端能藏的东西终究是有限的，与其死守一个迟早会被 dump 出来的常量密钥，不如干脆把密钥变成运行时输入的一部分，反正真正要保护的不是密钥本身，是"组装规则"。

SHA-1 本体是一段完全自包含的手写实现，不调用任何 PLT，识别它的铁证是那五个雷打不动的初始向量和四段轮常量：

```python
# SHA-1 标准初始向量与轮常量（公开算法常量，非目标App机密）
H = [0x67452301, 0xEFCDAB89, 0x98BADCFE, 0x10325476, 0xC3D2E1F0]
K = [0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC, 0xCA62C1D6]
```

我用 Unicorn 把这段真实机器码单跑了 10 组输入，跟 Python `hashlib.sha1` 对拍，10/10 全中，覆盖了 SHA-1 padding 最容易出错的 55/56/64 字节块边界——这一步一次性把"它是不是真 SHA-1、字节序对不对、padding 有没有边界 bug"三件事都钉死了。手写实现的好处是逆向者拿不到现成符号，坏处是它没法绕开算法本身雷打不动的魔数指纹——**"没有 OpenSSL" 反而让密码学更好认**，这是本幕第一个反直觉点。

### 1.4 一个藏在 Base58 表里的越界机关

自定义算法 Base58。拿到 31-bit 的 `DT` 之后，用基数 58 展开成 5 位，逐位查表。反汇编里看不到除法指令——编译器把"除以 58 的幂"换成了乘法逆再移位，这是常规操作，还原回去就是 `58, 58², 58³, 58⁴` 几个数。真正有意思的是这张查找表本身：

```
table[ 0 .. 25]  = 固定 26 字符（剔除易混淆字符如 0/O/1/I/L/S/Z/U/A/E）
table[26 .. 57]  = upper(s3) 的前 32 个字符（运行期由输入 s3 填充）
table[58]        = 0（显式清零，但 %58 永远取不到）
```

**模数是 58，固定字母表却只有 26 个字符。** 缺的 32 个槽位靠 `upper(s3)` 从下标 26 开始填。这意味着算法**隐式要求 `s3` 长度至少 32**——如果 `s3` 短于这个长度，Base58 的某些下标会越界读到栈上未初始化的垃圾字节，导致 `strlen` 提前截断，短码直接被砍短。我实测过，喂一个只有 4 个字符的 `s3`，本该是 7 位的短码被砍成了 3 位。这不是 bug，更像是一个隐式的"输入契约"——把"这个函数只能配合 32 位定长字段调用"这件事，用一个不会主动报错、只会默默产出错误结果的方式焊死在了算法里。这种"用越界代替校验"的写法，说实话不太优雅，但确实有效，逆向者如果没意识到这个契约，复现时会被一个莫名其妙的短码长度坑很久。

校验位那两位是个 GF(2⁸) 混淆黑盒，我没有把它完全还原成纯 Python——它带跨 lane 的重排，不是逐列标准的 MixColumns，用 Unicorn 当 oracle 顶替能保证正确性（5 组样本 5/5 命中），但要做到完全脱离二进制的离线复现，这块还差最后一步。我不打算在这里硬凑一个"看起来解决了"的结论，这是这个库唯一一处开放问题，留着。

参考实现（前 5 位纯 Python，已验证）：

```python
import hashlib, hmac, base64, struct

def encode_prefix(s1: str, s2: str, s3: str) -> str:
    """复现短码的前 5 位。前提：s3 长度需 >= 32，否则命中上面说的越界机关。"""
    K   = base64.b64encode(s1.encode())
    cnt = sum(48 <= c <= 57 for c in s3.encode())
    n   = (int(s2) + cnt) & 0xFFFFFFFF
    C   = struct.pack(">Q", n)
    mac = hmac.new(K, C, hashlib.sha1).digest()
    off = mac[19] & 0x0F
    DT  = struct.unpack(">I", mac[off:off+4])[0] & 0x7FFFFFFF
    s3up  = bytes((c - 32) if 97 <= c <= 122 else c for c in s3.encode())
    table = b"<REDACTED_26CHAR_TABLE>" + s3up
    return bytes(table[(DT // (58 ** k)) % 58] for k in range(5)).decode()
# 完整短码 = encode_prefix(...) + 两位校验（GF(2^8)黑盒，暂未纯 Python 化）
```

### 1.5 RSA 公钥：分片 + 诱饵的组合拳

`getrsakey` 把内置前缀、内置中段、运行时传入的尾段拼起来，最终解出一段教科书级的 1024-bit RSA SPKI 结构。这里有两个反直觉的地方：

第一，**这个 so 里只硬编码了公钥的前 3/4**，缺失的 modulus 末段和公钥指数是运行期由 Java 层传入的——这是一种朴素的密钥分片，单看这个二进制文件，永远拿不到完整公钥。

第二，也是更有意思的一处：跟这段真公钥并列存放的，还有一段看起来像"配套第二段密钥"的 Base64 串，解码出来却是一片高熵的 `0xFF/0xFE`——不是合法大数，接上去 DER 长度和结构直接崩掉。它唯一的作用就是**诱使逆向者去解一把假钥匙**，而 `getrsakey` 实际代码里，从头到尾都没碰过这个诱饵字段。这种"真前缀 + 假整段"的组合我第一次看到的时候差点被绕进去，花了一段时间才确认那段真的是纯粹的噪声，没有半点真实密钥材料掺在里面。

这把公钥拿去干嘛用了？这里先卖个关子——它不止用在一个地方，后面拼图收束那一节会揭晓它牵出的一整条"机密通道"。

### 1.6 两个钩子，本幕先按下不表

写到这里，可能你觉得算法层已经完全清楚了。但还有两件事没讲完：

第一，这套精妙的 7 字符短码算法，**它的产物最后进了哪个请求字段**？

第二，那把 RSA 公钥，**除了签名用途，它还解密了什么**？

这两个问题的答案都在拼图收束那一节，而且答案会让你觉得——这个库被逆得这么透，多少有点用力过猛的意思。

---

## 第二幕：壳-N —— 一个 App 里，为什么会有自己的 ELF 链接器

这是五个库里工程量最大、也是我逆得最费劲的一个。跟前面那个"朴素混淆"的库完全不是一个路数——这里有自定义 Linker、有加密的二级 payload、有平坦化、有裸 syscall 级别的处置手段。如果说 libN.so 是"用命名和分段藏东西"，壳-N 是"把整个运行时都重新造了一遍"。

### 2.1 体检：不寻常的开局

`objdump -h` 读出来 section 名全为空——section header 字符串表被抹掉了。导出表里只有一个 `JNI_OnLoad`，没有任何静态导出，走的还是动态注册那一套。真正点破这个库性质的是 `JNI_OnLoad` 的第一行代码：

```c
__android_log_write(4, "壳-N", "vX.XX");   // 自报家门
...
if (resolve_symbol(handle, "JNI_OnLoad", &real_entry))
    real_entry(vm, reserved);               // 找到真正的入口并跳过去
```

这个库的本体，**是一个自己实现的 ELF 链接器**。它不依赖系统 linker，用自己的代码把一段内嵌的、加密的二级 ELF payload 映射进内存，再用自建符号表在 payload 里找到真正的 `JNI_OnLoad` 并调用。这个库真正保护的业务逻辑，全在那个被加密保护的二级 payload 里；外层这个文件只是加固壳，负责加载 payload、以及跑一整套反调试/反注入/防篡改检测。

### 2.2 双模式符号解析

真正的符号解析函数是一个薄包装下面的核心实现，它的逻辑是这样的：

```c
void *resolve_symbol(handle, name) {
    int tag = *(int*)(handle + 12);
    if (tag == INTERNAL_ELF_TAG)                  // 自己解密映射的内嵌 ELF
        return lookup_in_custom_symtab(name, handle);
    else if (tag == WRAPPED_SYSTEM_LIB_TAG)        // 包装的系统库
        return real_dlsym(handle[24], name);       // 透传给真·dlsym
    return NULL;
}
```

这说明壳-N 是一个**完整的双模式链接器**——既能管理自己解密映射的内嵌 ELF，走自建符号表；也能包装系统库，透传给真正的 `dlsym`。这个设计说实话超出了我对一般加固壳的预期，一般的壳解决"怎么把自己藏起来"就够了，这个壳等于是把整个动态链接的基础设施都重新实现了一遍，只为了让核心逻辑活在一个"外部工具找不到入口"的地方。

### 2.3 "文件里的文件"

加载二级 payload 的函数里有个细节很关键——它传给加载器的路径参数，返回的居然是自己这个文件的文件名。也就是说：**payload 不是外部文件，而是嵌在这个 so 自身内部的一段加密数据**，这个库把自己文件里的某一段当成一个独立的 ELF 重新解析、映射、链接。这也解释了为什么 section header 字符串表要被抹掉——payload 是"文件里的文件"，传统 section 视图对它毫无意义。

我对全文件搜过 ELF magic（`7F 45 4C 46`），**零命中**。连外层自己的 ELF 头都因为特殊的加载方式搜不到，payload 必然是密文，只有运行时才由内部函数解密。要拿到这个 payload 的真身（也就是真正的业务逻辑），静态还原解密函数的成本很高，更省力的路是**动态 dump**——等加载完成后，从内存里已经解密的区域直接落盘。前提是得先压住第五节要讲的那些检测，否则进程会在你 dump 之前就被处置退出。这一步我还没有做完。

### 2.4 混淆体系：平坦化 + 集中式 XOR

这个库同样上了 OLLVM 控制流平坦化，状态机驱动的巨型 `while(1)` 长这样：

```c
v0 = -1598397234;
while (1) {
    if (v0 == 238789395) { ...; v0 = 371708096; }
    else if (v0 == 601395558) { /* 读 /proc/self/cmdline */ v0 = 1707529757; }
    ...
}
```

跟第三幕要讲的那个库比，这里的平坦化分支少得多，手工顺着数据依赖就能还原真实控制流，不用上符号执行或者微执行——这也是我把它归类成"工程量大但技术含量分布不均"的原因之一。

字符串加密走的是**集中式 3 字节循环 XOR**，跟另一个库"22 个分散解码器"的做法完全不同风格：

```python
KEY = [0x99, 0xa7, 0xa9]   # 3 字节循环密钥（壳-N 自身算法实现，非目标App机密）
def dec(cipher: bytes) -> str:
    return bytes(cipher[i] ^ KEY[i % 3] for i in range(len(cipher))).decode('latin1')
```

有个挺精妙的工程细节：解密前，程序在**密文**上直接用 `strlen` 算长度，靠密文中的 `0x00` 定界。为什么这样不会出错？因为明文都是 ASCII 路径/符号名（字节 < 0x80），而 key 字节全部 ≥ 0x80，明文字符永远不会等于 key 字节，所以 `明文 ⊕ key ≠ 0`——**密文中的 `0x00` 当且仅当对应明文的字符串终止符**。这个设计让"先解密再定界"和"先定界再解密"两种顺序都能正确工作，是个很讨巧的小设计。

哈希原语用的是标准 CRC32——初值 `0xFFFFFFFF`、查表、末尾取反，教科书写法。这里有个值得记住的反直觉点：**CRC32 是非密码学校验，可逆构造**，所以这套防篡改的强度不来自算法本身，而完全来自"你不知道内置的预期 CRC 值是多少"——一旦这个预期值被提取出来，伪造一个 CRC 相同的篡改体在数学上是平凡的事情。

### 2.5 反调试三连：一个藏得很深的看门狗

反调试线程大概每 2 秒轮询一次，逻辑是：

```c
tracer_pid = read_tracer_pid();                  // 读 /proc/self/status 的 TracerPid
if (tracer_pid == -1                              // 读不到
 || (tracer_pid != 0 && !is_our_watchdog(tracer_pid))   // 有人附加，但不是自己人
 || thread_state_scan() == TRACING_STOP)          // 或有线程处于 tracing-stop
    dispose();
```

**TracerPid 自校验**是我觉得这里面最精巧的一处。它没有简单地"非 0 即报警"，而是把这个 tracer 的 PID 拿去查**那个 tracer 自己的** `/proc/<pid>/status`，比对其 `PPid` 是否等于内置的一个值——这暴露了一个 **self-ptrace 看门狗**机制：这个库自己 fork 了一个子进程去 ptrace 附加父进程，利用"一个进程同一时刻只能被一个 tracer 附加"这条内核规则，先把这个唯一的席位占住。所以 `TracerPid != 0` 在这里是**正常状态**——只有当这个 PID 不是它自己认识的看门狗时，才说明外部调试器抢了 attach 的位置。这条对我这种想 hook 它的人来说是个硬约束：单纯把 `TracerPid` 清零反而会触发"看门狗失踪"的异常分支，必须连看门狗一起接管才行。

线程 state 扫描更底层：遍历 `/proc/self/task` 下每个线程，读它们的 `stat` 文件里的 state 字符，`(state | 0x20) == 't'` 这个判断同时匹配大写 `T`（stopped）和小写 `t`（tracing stop）——任何被 ptrace 停住的线程都会落进这个判断。这条检测**不依赖任何 Frida 特征名**，给线程改名也没用，因为它看的是内核维护的调度状态，是个比字符串匹配狠得多的检测维度。

### 2.6 反注入三连 + 防篡改

反注入线程每 4 秒跑一轮，三条腿都指向同一个对手——线程名匹配已知注入框架的事件循环线程名、扫描自身 fd 目录里的软链接找注入临时文件、以及扫 `/proc/self/maps` 找可疑路径加载的可执行段，命中即用 `dlopen` 打开该 ELF、检查其导出符号是否含注入框架的特征导出。这是**三重冗余检测**：线程名 + fd + maps，任何单点绕过都不足以蒙混过关，这跟 §7 蓝队视角要讨论的"多信号交叉优于单点精确"是同一套设计哲学。

防篡改这块最大的函数是全库体积最大的函数，我一开始以为它是反 hook 的核心逻辑，读完才发现——**它是在自己实现一整套 ASN.1 DER 解析 + APK zip 定位 + 证书提取**，用来从磁盘上的 APK 里读出签名证书公钥，跟内置的期望值比对。这是这类设备 ID/风控 SDK 一个很硬的产业约束：**必须用注册时登记的应用签名，否则拒绝正常工作**——这个函数就是防止换了签名重打包之后还能正常拿到设备标识。同时还有一套 DEX 白名单校验，遍历所有 dex 文件算 CRC32，跟内置的白名单比对，任何 dex 被篡改或新增都会命中。

### 2.7 处置机制：从字符串 0 引用开始的一次误判

第一轮静态分析时我一度很困惑——反调试字符串（比如"kill -9"那种）在库里能找到，但**交叉引用数是 0**。`ptrace` 这个导入符号也一样，找不到真正的调用点。这个困惑直到我扒开处置函数才解开：

```c
void dispose_hidden(int a1) {
    uint8_t buf[28] = decrypt(embedded_ciphertext, key);   // 运行时解出 28 字节机器码
    *(uint32_t*)buf += MAGIC_DELTA;                         // 修正首条指令
    void *p = mmap(0, 28, PROT_RWX, MAP_ANON|PRIVATE, -1, 0);
    memcpy(p, buf, 28);
    __clear_cache();
    ((void(*)(int))p)(a1);                                  // 直接跳进去执行
}
```

解出这 28 字节反汇编之后，谜底揭晓：

```
MOVZ X8, #94      ; 94 = __NR_exit_group（不是 93 的 exit，是 exit_group）
SVC  #0           ; 直接系统调用
RET
NOP × 4
```

这是 `exit_group(0)` 的裸 syscall。**关键 syscall 全部不走 libc 符号，而是运行时解密成机器码直接 `svc` 发出**——这解释了第一轮所有的困惑：hook `exit`/`_exit`/`kill`/`ptrace` 这些 PLT 符号一律拦不住，因为程序从来没调用过它们的符号版本。更狠的一处细节：这 28 字节机器码在静态存储态首指令是"退出码 0 的空操作"，只有运行时加上一个偏移常量才变成真正的 `MOVZ X8,#94`——你直接 dump 这块数据看到的东西是假的，必须跑那一步加法才现出真身。真有必要吗？为了藏一个系统调用号，专门写了这么一段自解密的 shellcode。

### 2.8 最关键的盲区：磁盘完整性防得死，内存 hook 全盲

写完检测体系之后，我把所有检测线和对应的对抗手段列了一张表：

| 检测线 | 对抗要点 |
|---|---|
| TracerPid 自校验 | 不能简单清零，需连看门狗一起接管 |
| 线程 state | hook 改写 stat 里的 state 字段，或用非 ptrace 调试 |
| 线程名 / fd / maps | 改名 + 隐藏映射 + 抹符号，三线都得堵 |
| APK 签名 / DEX 白名单 | 不重打包即天然通过 |
| 处置兜底（裸 syscall） | hook `exit`/`kill` 无效，需下沉到 `mmap`/`svc` 层 |

然而：**DEX 白名单和 APK 签名校验，读的都是磁盘上的文件，完全不碰内存里 ART 已经加载的方法结构**。这意味着**运行时的 ART 方法 hook（比如替换内存里已加载类的方法入口指针）对这两条最重的防线天然免疫**——内存里怎么改，磁盘上的 `classes.dex` 一字不差，CRC 照样对得上。**换句话说，这套加固对"磁盘完整性"防得死死的，对"内存运行时 hook"反而是一片空白**。真正能抓到内存 hook 的，只有 native 层那几条线程/fd/maps 检测，以及 Java 层的类枚举——完整性校验这个听起来最"重"的防线，实际上防的是一个已经过时的攻击面。

---

## 第三幕：SDK-S —— OLLVM 拿下，一套可复用的通用范式

这是这批库里对我个人价值最大的一个——不是因为它藏的东西最值钱（其实前面已经说了，检测结果最后是静默上报，端上根本不用），而是因为破它逼着我写出了一套后面能直接复用的工具，这套工具在第四幕的高潮部分再次派上用场。

### 3.1 三层混淆，静态分析全废

这个库（下称 SDK-S）690KB，stripped，刚加载进 IDA 就能看出不寻常：

**第一层信号**——入口点列表里有 22 个数据解密函数，挂在 `.init_array` 段，动态链接器在 `JNI_OnLoad` 之前逐个调用，运行时把 `.data` 段里加密的字符串、表、常量原地解密。直接后果：`.rodata` 只有 2264 字节，对一个 690KB 的库来说小得反常——所有明文串都躺在 46KB 的 `.data` 里以密文形式存在。`strings`/`grep` 在这个库上完全失效，这是设计使然。

**第二层信号**——`.text` 586KB，但函数高度碎块化。随便反编译一个函数，Hex-Rays 吐出来的是一坨状态机：真实的基本块被打散成"状态机分发器 + 一堆扁平真实块"，用一个状态变量串起来。原本 `A→B→C` 的顺序执行被改写成"dispatcher 看 state → 跳 A → A 设置 state=某魔数 → 回 dispatcher → 跳 B → ……"，人是读不了的，因为控制流被状态变量间接化了。

**第三层信号**——全库有 270 个种子全局变量，被将近四千条指令引用，喂给类似 `(x-1)*x & 1 == 0` 这种代数恒真判断，制造出"看起来是条件分支、实际恒定走一边"的假分支，进一步搅乱控制流。

三层叠加的意图很清楚：让静态分析（读伪代码、grep 字符串、追控制流）的成本高到不可行，逼分析者要么放弃，要么上动态手段。

去平坦化没有通用脚本，脚本形态完全取决于 dispatcher 的实现细节。这个库的 dispatcher 长这样：

```asm
loc_dispatch:                  ; dispatcher 根
  MOV  W8, W10                 ; ★ 状态变量在寄存器，不是内存
  CMP  W8, W11                 ; W11 是边界值，也预加载在寄存器
  B.LE loc_left
  CMP  W8, W14
  B.GT loc_right
  ...
```

两个让静态分析格外难受的地方：状态变量和边界值全在寄存器里，`CMP` 指令里没有立即数，扫立即数找不到这棵比较树的路标，必须做寄存器常量传播才能复原它；而且这棵树是二叉查找树，不是 switch 跳转表，没有一张集中的表可以改。真实块末尾更新状态变量有三种形态，第三种是杀手：

```c
// 形态 A：无条件，单一后继
MOV W10, #0xEE50; MOVK W10, #0x9CCB, LSL#16

// 形态 B：条件，真实 if/else
CMP W8, #0; CSEL W10, W9, W8, EQ

// 形态 C：算术编码，把业务分支伪装成算术赋值
ASR W8, W0, #0x1F; EOR; BIC; SUB; NEG W8
```

形态 C 把一个真实的业务条件分支（比如"如果某次调用返回负数"）伪装成一串"看似无条件的算术运算"。这是为什么纯模式匹配脚本必败——网上一搜一大把的 OLLVM 去平坦化脚本只认形态 A 和形态 B，用正则提 next-state，遇到形态 C 会静默漏掉这些边，重建出残缺的 CFG，而形态 C 恰恰是检测逻辑里最关键的业务分支。**一旦确认目标含形态 C，就该直接放弃纯静态模式匹配，必须上能"算出 next-state"的方案。**

### 3.2 核心洞察：不要解 dispatcher，喂它跑

这里是这套方法论最关键的一个决定，说出来简单，但走到这一步花了不少弯路：**不要去静态解析那棵二叉比较树**（边界在寄存器、还嵌套，解析起来极烦），而是把它当黑盒——用 Unicorn 喂一个 state 值，从 dispatcher 根跑一遍，看它落到哪个真实块。用一句话概括就是"以执行代替解析"。

由此得到一个 worklist 遍历真实 CFG 的伪代码：

```python
S0 = emulate_prologue(fn)           # 微执行序言，拿到初始 state（不是静态扫的！）
queue = [(main_dispatcher, S0)]
cfg = {}
while queue:
    root, state = queue.pop()
    block, out_states = emulate_step(root, state)   # 喂 state 跑一遍
    cfg[(root, state)] = {"block": block, "succ": out_states}
    for s in out_states:
        queue.append((root, s))
```

`emulate_step` 是整套引擎的灵魂：一气呵成地"从 dispatcher 根出发 → 过分发器 → 进真实块 → 执行块体 → 块尾写出口 state → 回到分发器"，在第二次进入任一 dispatcher 时停下，同时拿到落点块和出口 state。进入真实块时的寄存器上下文是 dispatcher 真实路由出来的，完全正确，不需要手工构造。

worklist 要发现所有分支，关键在怎么把"一个 state"分裂成"两条边"，我按 next-state 的产生形态分治处理：

- **形态 B**：不去猜条件来自哪，直接 hook 到那条 `CSEL` 指令，强制它选一个操作数跑一遍，再强制选另一个操作数跑一遍。不管条件源是内存、调用返回值还是标志位，都能拿到两个真后继。
- **形态 C**：块里没有写 state 的 `CSEL`，出口随某个外部调用的返回值变化——用"双返回值 fork"：把被跳过的外部调用返回值一次设 0、一次设 -1，各跑一遍。
- **形态 A / 不透明谓词**：两遍结果相同，自动塌缩成单后继。

有个坑必须提一下：形态 B 的 `CSEL` 强制 fork 有个副作用——它会把不透明谓词的死分支也当成真后继（因为不透明谓词的 `CSEL` 也选两个不同的 state，其中一个永不可达）。区分真假分支的本质矛盾是：真实条件分支，baseline（真实执行）只走一支，需要 force 才能发现另一支；不透明谓词，baseline 走的就是唯一真支，force 出来的是死支——光看 force 无法区分两者。但这个库的不透明谓词有一个唯一指纹：都会读某个特定的全局种子数组。所以策略变成："凡是读种子的块，只取 baseline 真后继，不做 force fork"，死支自然消除——这一招把"识别不透明谓词"从一个需要符号化判恒真的难题，降级成了查一个引用集合的简单判断。

还有一层嵌套平坦化的坑：这个库把平坦化套了两层，外层用 if-tree，内层用 switch，外层某块跳进内层、内层算完再跳回外层。一开始我把内层当黑盒穿透，对外层做返回值 fork，结果发现两个极值恰好都导致内层同一结果——外层通往整个 `RegisterNatives` 子图的分支永远发现不了。正解是把 worklist 节点从单纯的 `state` 升级成 `(dispatcher, state)` 二元组，识别出所有 dispatcher，`emulate_step` 停在"再次进入任一 dispatcher"，出口 state 用到达的那个 dispatcher 的 state 寄存器读——这样层间跳转和任意深度嵌套都能自然展开。

字符串解密顺手就解决了：去平坦化的 Unicorn 基建拿来跑那 22 个数据解密函数，它们本身就是普通函数，跳过外部调用、跑到 `RET`，会原地解密内存里的密文段。跑完把整个数据段 dump 回 IDB。有个必须守住的工程点是**幂等**——解码前要从原始文件读密文覆盖 Unicorn 里的数据，而不是从已经在分析中的 IDB 读，否则如果 IDB 已经是解密后的明文，再跑一遍解码器会把明文又异或回乱码。这个坑我真的踩到过，一次工具意外重跑触发的。

最终成果：**187/191 个函数去平坦化成功（97.9%），3259 处 patch，21 个字符串解码器全部成功，`.data` 段（46KB）全部转为明文。有 4 个函数因为序言里含寄存器间接跳转（跳转目标是运行时才能确定的值，微执行给不出这个值，会导致 PC 飞出去执行非法指令）失败，占比约 2%。

`JNI_OnLoad` 去平坦化前后的对比很能说明问题——之前 154 行状态机，完全不可读；之后 18 行，语义一目了然：

```c
jint JNI_OnLoad(JavaVM *vm, void *reserved) {
    if (!(*vm)->GetEnv(vm, &env, JNI_VERSION_1_6)) {
        jclass cls = FindClass(env, target_class);
        if (cls)
            RegisterNatives(env, cls, method_table, 5);
    }
    return result;
}
```

### 3.3 检测函数还原：环境检测入口

把去平坦化和字符串解密两个成果合流之后，环境检测入口函数的核心逻辑现形了——这是一个经典的 Magisk 挂载点检测：读 `/proc/self/mounts`，逐行子串匹配"magisk"这个关键字，Magisk 的 overlay/bind mount 会在挂载表里留痕。

补一个判据：全库扫描发现，四个对外采集接口是简单包装、**没有被平坦化**，唯独这个检测入口函数被重点平坦化保护——这本身就是情报：**检测逻辑是这套体系里被重点保护的那一块**，也是"该藏的地方"和"实际值钱的地方"第一次真正对上号的例子。

### 3.4 情报产出：这套 SDK 到底检测/采集什么

解密后的字符串全量分类，能拼出一份完整的检测清单：

**环境检测（反作弊）**——Root 检测靠几十条 su 路径暴力枚举；Magisk 检测就是上面那条挂载点扫描；Hook/注入框架检测覆盖了多种常见框架的特征包名；模拟器检测靠系统属性、服务名、特殊目录、CPU 架构四路交叉，覆盖了主流的桌面模拟器和云手机方案；系统完整性检测读取 Verified Boot 相关属性，配合反调试的 TracerPid 判断。

**设备指纹采集**——除了标准设备属性和 SIM/运营商信息，最有意思的是一批**厂商私有设备 ID 接口**，专门适配了国内主流手机厂商的私有标识 API。这背后有个数学事实：标准 `android_id` 熵不足以支撑大规模去重，所以厂商私有 ID 成了熵的命脉，这是一个多信号冗余的工业实践。还有一项我觉得是这批检测里最"毒"的——**扫描 ARP 邻居表，查同网段设备**，这不是单机反作弊，是抓群控农场/批量多开设备，比单机检测高了一个维度。以及一项**硬件级指纹**：读取 flash 存储芯片的出厂唯一码，这是云手机/模拟器几乎不可能伪造的一项，是这套指纹体系里熵最高、最难对抗的一环。

上报加密链路方面，采集完的数据不是明文上报，走的是一条标准流水线：`采集JSON → zlib压缩 → AES-128-CBC(硬编码key) → Base64 → 上报字段`。我把这条流水线完整还原了，AES 用的是标准 S 盒和 Rcon 表（不是魔改算法），但**密钥和 IV 都是硬编码在二进制里的顺序递增字节**——这种弱到近乎象征性的密钥强度，配合"没有任何随机数/时间戳参与加密"这个事实，意味着**上报主体理论上可以被静态全解**，只要拿到密钥就能批量还原任意截获的上报包。另外还有一层 RSA-OAEP 信封加密某个字段，但因为对称密钥本身是写死的，这层 RSA 保护的不是密钥交换，只是给某个字段多包了一层——这是**"security by obscurity"的一个标本**：SDK-S 把混淆预算全砸在检测逻辑的平坦化上，传输机密性反而是短板，这也印证了移动端风控一个很务实的哲学——**判决在云端靠多信号冗余，单条上报的机密性从来不是关键防线**。

### 3.5 抽象一下：拿到一个陌生的 OLLVM 库该怎么走

上面这套流程不止适用于 SDK-S 一个库——第四幕的 libG.so 直接复用了同一套引擎，省掉了大量重复工作。既然要讲方法论，不如在这里把它抽象成一份判断流程，遇到任何疑似上了 OLLVM 的 ARM64 库都能照着走一遍。

先看状态变量在哪——如果在寄存器里（边界值也预加载在寄存器，`CMP` 指令里没有立即数），那"扫立即数找路标"这条路就直接废掉了。再看 dispatcher 结构——如果不是 switch 跳转表、而是一棵二叉查找树，静态解析这棵树的成本会很高，这时候就该考虑"不解析、直接喂它跑"。

**真正的分水岭是 next-state 的产生形态。** 形态 A（无条件赋值）和形态 B（`CSEL` 条件选择）都能用模式匹配或者强制 fork 处理，但一旦遇到形态 C——next-state 由某个外部调用的返回值经过算术/位运算推导出来——纯静态模式匹配就彻底失效了，必须上能"算出 next-state"的方案。这里我想把话说重一点：网上那些现成的 OLLVM 去平坦化脚本，绝大多数只认形态 A 和形态 B，遇到形态 C 会静默漏掉这些边，给你一张看起来完整、实际残缺的 CFG，而且**不会有任何报错提示你漏了什么**——这比直接报错更危险，因为你可能拿着一张残缺的图去做后续分析，而且对残缺本身一无所知。

```
判断流程：
1. 确认是平坦化（while(1) + 状态变量分发）
2. 状态变量在寄存器 → 排除扫立即数
3. dispatcher 是二叉查找树 → 排除改跳转表
4. 含形态 C → 排除纯模式匹配，必须上微执行/符号执行
5. 含不透明谓词 → 找种子指纹，不要去符号化判恒真
6. 覆盖率异常低 → 怀疑嵌套，节点升级为 (dispatcher, state) 二元组
7. patch 策略：只改块尾跳转，不碰 dispatcher 本身，宁可漏不可错
```

这套流程跟具体是哪个厂商、哪个 App 完全无关——任何 register-state 平坦化加数据加密的 ARM64 库，理论上都能照这个顺序走一遍。

---

## 第四幕（高潮）：libG.so —— 伪装图形库里，真正现役的签名黑箱

这是全篇的重头戏，也是我个人逆得最有戏剧性的一个库——因为我在这里被自己的第一轮判断结结实实地误导了一次，而纠正这个误判的过程，恰好把这整篇文章"精力错配"的主线体现得最彻底。

### 4.1 误判

这个 App 的请求签名字段叫 `hkey`。最初追踪这条线索时，我们把它追到了 Java 门面层一个方法名全用图形学术语伪装的类里，承载它的这个 so（下称 libG.so）通过字符串扫描，能确认内嵌了一个完整的 QuickJS 引擎——错误串 `invalid tag`、内建方法名 `__JS_FreeValue` 之类的特征全都在。基于这些证据，第一轮的判断是：**"签名算法极可能是 JS 字节码"**。这个推断看起来很自然，几乎是显然的——一个内嵌了完整 JS 引擎的库，又伪装成图形库，唯一合理的解释似乎就是它在用某种脚本化的动态签名算法来对抗静态分析。

这个判断是错的。

对签名入口函数做逐行反编译之后，证据链完全指向另一个方向：**QuickJS 一次都没被调用**。它的全部间接调用都是 JNIEnv 虚表偏移，没有任何一个进入 JS 引擎；被它引用的全局是 XOR 密钥表和兜底字符串，没有 QuickJS 字节码的魔数。**`hkey` 是纯 native 算出来的。**

那 QuickJS 去哪了？它确实在库里，错误串和内建方法名密集地躺在一段独立的文件偏移区间——只是它在**另一条独立代码路径上**，护的是这个 App 里另一项完全不同的业务（后面会讲），跟请求签名 `hkey` 毫无关系。之所以第一轮会误判，恰恰是因为这个库把逆向者的注意力成功导向了最唬人的那层伪装。这个教训我想着重说一下：**最值得逆的地方，往往不是看起来最难的地方**——一个库把最花哨的技术摆在明面上，反而应该激起警惕，而不是激起"这肯定是核心机密"的直觉。

于是全库的功能地图是这样的：

```
libG.so（伪装成图形库）
│
├─ 路径 A ── 签名入口函数 ─────────────► 请求签名 hkey
│    纯 native：反调试 + APK 签名校验 + 包名白名单
│    + 查表(15字段设备记录) + 字符串拼接 + 常量 key 变换
│    ⟵ QuickJS 完全不参与这条路径
│
└─ 路径 B ── QuickJS 字节码解释器（独立代码区）
     护的是另一项自动化业务，与 hkey 无关
```

### 4.2 签名入口：从 JNI 注册到四段门控

库里没有任何静态导出，唯一的 JNI 符号是 `JNI_OnLoad`，它对宿主 Java 类调用一次 `RegisterNatives`，一次性注册了将近 30 个 native 方法。这是第一层反静态：静态扫方法名什么也扫不到，方法名与实现地址的绑定关系全埋在 `JNI_OnLoad` 的函数体里。

注册表里绝大多数方法名构成一层双重语义烟雾——一部分是图形学术语，坐实图形库伪装；另一部分刻意混入了完全不相关的技术领域术语（比如某些看起来像自然语言处理模型接口的命名），让人误以为这是个别的什么推理接口。真实功能被术语彻底掩盖——这些方法实际上都是在往一张设备信息表里灌数据。

第二层反静态藏在注册过程本身：其中一个方法的 JNI 签名字符串不是明文存放的，而是 `JNI_OnLoad` 里现场跑一个 100 字节的 XOR 解密循环重建出来的——连 JNI 方法签名都不给你静态读，这是这个库反静态的基调：**大量工程投入用于抬高静态分析成本，而非提升密码学强度**，这句话你会在后面看到反复应验。

签名入口函数的执行分四段，前三段是门控，只有通过才进入 `hkey` 生成：

**第一段，反调试闸门**。解密出一个 `/proc` 路径和检测特征串，命中即直接自杀（用裸系统调用，不走 libc 符号）。配套的工具箱在导入表里都有印证——枚举已加载 so 查注入、读系统属性、扫 `/proc` 目录——但**没有 `ptrace` 的导入符号**，这条反调试如果用了 ptrace，走的也是裸 syscall。

**第二段，APK 签名校验**。通过 JNI 反射链拿到应用签名的 hashCode，跟一个内置常量字符串做比对，不等则直接跳到失败标签。

**第三段，包名白名单**。分段比对若干个合法包名，按字符串长度分发匹配——**分段比对而非一次性字符串比较**，这本身也是反静态手段：完整包名从来不以连续明文出现，得把几段拼起来才能识别。

**第四段，门控失败的兜底**。任一校验不过，`hkey` 会被赋成一个固定的常量字符串（大致语义是"无法创建日志文件"这类兜底提示）。

这里我想单独拎出来说一句：**这是一个绝佳的线上反篡改判据**。任何抓包如果看到 `hkey` 等于这个固定兜底串，等价于服务端收到了"客户端环境异常（被调试/被重打包/包名不符）"的信号。做风控策略的话，这个魔法串可以直接作为一条高置信度的环境异常规则，甚至都不需要理解签名算法本身是怎么算出来的——这是这次逆向里少数几个可以立刻拿去用、而且完全不需要理解底层密码学的产出。

### 4.3 hkey 算法的真相：查表、拼接、变换

前三段门控通过后，才进入真正的签名生成。这一段有三个反直觉之处，值得逐一拆开。

**第一个地方：十几个"局部变量"其实是同一条记录的栈切片。** 反编译初看，`hkey` 生成用到了十几个看起来彼此独立的变量，像是十几个独立数据源。真相是它们是**同一条 15 字段记录在栈上的相邻切片**——每个字段占固定字节数，第 k 个字段就在起始地址加上固定偏移的位置，精确命中每一个所谓的"独立变量"。这条记录不是 native 算出来的，而是从 Java 侧经由前面那批伪装成图形学/自然语言处理术语的 setter 方法，预先灌进一个全局单例的 map 结构里的。这是"字段名拆词 + Java/native 分离"的组合反静态：想知道某个字段到底装的是什么设备信息（品牌？型号？MAC？Android ID？），native 侧完全看不出来，因为值是 Java 采集后写进来的，native 只看到一个不透明的字符串。

**第二个地方：两条生成路径，现役的只吃两个字段。** 签名生成有两条分支，由一个布尔参数决定。现役调用传的是 `false`，走的是那条"极简"路径：只把两个字段拼接起来做变换，其它十几个字段（包括一个调试信息字段、包名、签名 hashCode）**完全不进入最终签名**，它们的作用仅限于前面的门控。另一条路径（对照路径）会把整条记录十四段全部拼接，但不做核心变换——这个对照路径的存在，反过来证明了这些字段是同质的设备/环境字段集合，现役路径只是从中选了两项再做一次变换而已。

**第三个地方：没有任何"每请求变化"的字段直接进入签名。** 通读全部输入字段后，我发现一个对复现极其关键的事实——入参本身只是一个选择器，决定取哪条记录，本身不进拼接；参与拼接的两个字段是设备固定值，调用期不会变化；变换用的密钥是编译期常量，运行时每次重建出来都是同一个值；核心变换本身是一段确定性逻辑。**这意味着对相同入参和相同设备记录，`hkey` 是确定性、可复现的**——一旦离线还原了算法，就能脱离真实设备伪造出合法的 `hkey`，不需要真机、不需要 hook。这也解释了为什么服务端能拿这个字段做校验：它本质上是设备指纹的一个确定性投影。

### 4.4 核心密钥：一场纯静态的解密闭环

现役路径的全部"秘密"集中在一个变换密钥上——一段常量，由某个函数每次重建（重建结果恒定），喂给核心变换函数做输入。
密钥在静态 IDB 里显示为全 `0xFF`（运行时才解密的目标缓冲）。核心循环剥出来很清晰——密文块的布局是"固定长度的密钥前缀 + 固定长度的密文"，逐字节做混合布尔算术变换后异或：

```
明文[i] = F(key[i % keylen]) ^ G(密文[i])
```

`F`/`G` 是两个混合布尔算术混淆的单字节变换，不需要手工化简，对 0-255 直接求值就够了。解出的明文是一串 64 个字符，去重之后发现恰好落在 16 个特定字母上——这是一套 **nibble→字母的自定义编码**（每 2 个字符编码 1 个字节），解码之后得到真正的 32 字节密钥。

一开始外推最终的 `hkey` 输出**也**是同样的字母编码，而且输出长度也是 32 字节——**这个外推完全错了**。通读整条数据流之后，真相是输出为 **64 字节**，序列化用的是标准的十六进制格式化（不是那套自定义字母编码）。这个教训我想说得重一点：**密钥的"存储编码"和最终输出的"序列化编码"是两套完全独立的机制，前者是常量混淆手段，后者是运行时格式化逻辑，不能互相外推**。看到一处编码规律就急着套到另一处，踩坑了。

### 4.5 核心变换的真相：一个被三层混淆包裹的标准 HMAC-SHA512

核心变换函数拿到 32 字节密钥之后，剥掉平坦化看它的骨架，其实只做了缓冲分配加一次核心调用：

```c
key_str = wrap_as_string(key32, 32);      // 32 字节密钥包成字符串
out_buf = alloc(64);                       // ★ 分配 64 字节 = 真正输出缓冲
core_transform(out_buf, data, strlen(data), key_str);
return out_buf;                            // 返回 64 字节
```

**第一个反直觉：输出是 64 字节，不是我最初以为的 32 字节。** 这个尺寸差异后来连锁纠正了上一节说的那处外推错误。

`core_transform` 剥开之后是教科书式的 init / update / finalize 三段式，用加密指针破解术把三个加密调用槽全部解出：

```
init(ctx, key32, 32)     ← 用 32 字节密钥初始化
update(ctx, data, len)   ← 灌入待签名数据
finalize(ctx, out64)     ← 出 64 字节摘要
```

这个"用 32 字节密钥初始化、灌数据、出 64 字节"的三段式，本身就把候选算法范围压到了带密钥的哈希构造这一类。**init 函数里的两个魔数直接定死了这是 HMAC**：`memset` 用 `0x36` 填充一段 128 字节的缓冲，另一处用 `0x5C` 填充同样长度的缓冲——`0x36`（ipad）和 `0x5C`（opad）是 HMAC 构造独有的指纹；block size 是 128 字节，意味着底层是 SHA-512 家族（SHA-256 的 block 只有 64 字节）。逐字节的 `ipad[i]=key[i]^0x36`、`opad[i]=key[i]^0x5C` 被混合布尔算术糊成了一坨看起来很复杂的位运算，但语义不变。带密钥的哈希（比如 BLAKE2、SHA3）自带 keying 机制、不需要 ipad/opad，据此可以排除——**这是一个 Merkle–Damgård 结构的哈希，外面套了标准 HMAC**。

在库里搜标准 SHA-512 的初始向量首字（小端形式），命中了一处地址，紧邻的就是 80 个 64 位轮常量表——配合"输出 64 字节"这个事实（SHA-384 只有 48 字节），底层唯一解是 **SHA-512**。Finalize 函数的三步也跟 HMAC 的双上下文结构完全吻合——inner 上下文和 outer 上下文分别做一次 finalize：

```
inner_final(inner_ctx, tmp64);              // tmp = H(ipad_key ‖ data)
outer_update(outer_ctx, tmp64, 64);         // 喂给外层
outer_final(outer_ctx, dst64);              // = HMAC-SHA512, 64 字节
```

最后一处细节：序列化函数同样被平坦化，但反汇编露了馅——一个从 0 到 64 的循环，逐字节把摘要交给一个格式化函数，而这个格式化函数本质是一个 `vsnprintf` 包装器，调用点传的 size 参数是"2 字符 + 结束符"——这是逐字节 `snprintf(fmt, byte)` 的铁证，自定义字母编码只会用位运算和算术，绝不会动用格式化字符串家族的函数。所以 64 字节摘要最终变成 128 个十六进制字符。大小写通过静态解出格式串（跟 §2 那套 XOR 解密同一手法）加上微执行双重验证，确认是大写十六进制。

**至此，现役 `hkey` 的算法层已经完全确定**：

```
hkey = HEX_UPPER_128( HMAC-SHA512( key = K32, msg = field_A ⧺ field_B ) )
```

参考实现（密钥已脱敏）：

```python
import hmac, hashlib

KEY32 = bytes.fromhex("<REDACTED_32B_KEY_HEX>")   # 已还原但脱敏，格式为标准32字节

def hkey(field_a: bytes, field_b: bytes) -> str:
    needle = field_a + field_b               # 纯字符串拼接，无分隔符
    digest = hmac.new(KEY32, needle, hashlib.sha512).digest()   # 64 字节
    return digest.hex().upper()               # 逐字节 snprintf("%02X")

# 自检：管线产出恒为 128 个大写十六进制字符
out = hkey(b"AAAA", b"BBBB")
assert len(out) == 128 and all(c in "0123456789ABCDEF" for c in out)
```

**这套混淆包的是一个人人都认识的算法**。攻击者没有自研密码学，只是把标准库的 SHA-512 三段式用加密函数指针藏起来、把 `key^0x36`/`key^0x5C` 用混合布尔算术糊住、把调用序列用平坦化打散。混淆强度全砸在"藏一个人人都认识的算法"上——一旦认出 `0x36/0x5C` 加上 SHA-512 的初始向量，整套自研假象瞬间坍塌成三行 Python。这再次印证一条贯穿全文的规律：**工程恶心度不等于数学强度，而且恶心度越高，往往越说明底下是标准件**——真正自研密码学的人，不会舍得在一个标准算法外面再套这么多层。

### 4.6 加密函数指针：一套可复用的纯静态破解方法

核心函数从不直接用 `BL` 指令跳转，而是通过一个形如下面的表达式取真实地址再跳转：

```c
// 变体 1：字节步进 + 常量1，结果 - 常量2
fn = *(QWORD*)(*(base_ptr) + K1) - K2;

// 变体 2：QWORD 步进 - 常量1*8，结果 + 常量2
fn = *(QWORD*)(*(base_ptr) - K1*8) + K2;
```

看起来像是运行时才成立的动态解密，唬人程度很高。但关键破绽在于：**`base_ptr` 处存的加密基址、以及那两个巨大的常量，全部是编译期就烘焙进静态数据段的常量**，运行时并不引入任何新的熵。所以它可以**纯算术离线解**：

```python
MASK = 0xFFFFFFFFFFFFFFFF
TEXT_LO, TEXT_HI = 0x71b50, 0x1ed5a0   # .text 区间，需按目标库调整

def decrypt_fnptr(base_addr, K1, K2, *, scale=1, add_K1=True, sub_K2=True):
    """解一个加密函数指针。scale=1 字节步进 / scale=8 QWORD 步进。"""
    base  = read_qword(base_addr) & MASK
    delta = (K1 * scale) & MASK
    entry = (base + delta if add_K1 else base - delta) & MASK
    assert entry < FILE_END, "entry 越界，公式变体或参数不对"
    enc = read_qword(entry) & MASK
    fn  = (enc - K2 if sub_K2 else enc + K2) & MASK
    assert TEXT_LO <= fn < TEXT_HI, "解出地址不在 .text 区间"
    return fn
```

核心函数在加密指针之上还叠了一层 OLLVM 平坦化，这层我没有再手动去解——直接复用了第三幕那套 Unicorn 微执行引擎，理由很简单，也是一石二鸟：微执行是"执行代替解析"，能直接线性化状态机；而且**微执行时 CPU 会自然算出加密指针的目标地址**，不需要手工校准每一种寻址变体，这恰好绕开了我在这个库里遇到的第三种尚未完全校准的寻址变体。这里我想强调一下这套工具链的复用价值——它不是"为这一个库量身定做"的，而是"任何 register-state 平坦化 + 加密函数指针混淆的 ARM64 库"都能直接套用的通用武器，这是我觉得整个逆向项目里，比任何单个被解开的库都更值钱的产出。

把三层障碍的破解成本量化一下，用来佐证"工程恶心度不等于数学强度"这句话：

| 障碍 | 表面强度 | 实际破解成本 |
|---|---|---|
| JNI 动态注册 + 方法名烟雾 | 静态扫方法名归零 | 反编译入口函数一次，O(1) |
| 字符串/签名 XOR 解密 | 明文不落静态 | 还原一个 XOR 循环，O(串长) |
| 加密函数指针（3 变体） | 貌似运行时动态 | 纯算术公式，每个指针 O(1)，全库通用 |
| OLLVM 平坦化 | dispatcher 打散控制流 | 微执行，复用现成引擎 |

没有一层引入了真正需要"爆破"的密码学难题。全部成本都是"读懂混淆器的固定套路"，一次性投入、长期可复用。

---

## 五、拼图收束：三条数据流，一次全部打通

前面四幕分别攻克了四个库的算法层，但每一份单独的报告都在同一个地方戛然而止——它们回答了"输入是什么、怎么算出来的"，却没有回答"产出到底去了哪里、谁在真正用它"。这一节把 Java 侧的调用关系接进来，一次性打通剩下的问题。

### 5.1 三个系统的真实命运

把前面几幕的产出接到调用层之后，能看到一个很扎心的对比：

- **设备指纹（SDK-S）**：检测入口函数在 Java 层的调用次数是 **0**。全工程没有任何一处代码调用它。这不是疏漏，是设计——结合"四个采集接口没被平坦化、唯独检测入口被重点保护"这条线索，可以确定检测逻辑是在采集流程内部自调用（或者折进了大包采集里），结果不回传给宿主 App 做端上判断，而是随设备指纹一起加密上报，**由服务端做名单/评分/决策**。这条结论的反直觉之处在于：很多人以为"过检测"等于"让 App 不闪退、不弹风险提示"，但这种 SaaS 风控模式根本不在端上拦截——端上拦截一 hook 就废，真正的战场是"上报的环境标签是否干净"。绕过得不彻底，App 该跑照跑，但服务端早就给这台设备打上了标签，会在后续的登录、交易、活动参与这些业务动作里被降权或拦截。**目标是"让上报包里的环境信号为阴性"，不是"让客户端不崩"**——这个定义上的偏差，是我觉得这次逆向里对下游最有指导意义的一条结论。

- **短码引擎（libN.so 的 `encode`）**：在整个工程里只有**一个**调用点，而且返回值**没有被任何变量接收**。它旁边紧挨着的另一行代码，才是真正写进签名字段的 `hkey`——用的正是我们第四幕逆出来的 HMAC-SHA512。也就是说，**现役请求签名早就从这套精妙的手写密码学，迁移到了 QuickJS 所在的那个 native 库**。第一幕逆得那么透的算法，最后一行都没进任何请求。它现在的角色只剩两种可能：要么是没删干净的旧版本遗留实现，要么是一个防篡改的 tripwire——调用它一下，如果 native 自身被 patch 或者被 inline hook，内部状态能感知到、进而影响后续行为。**这也解答了一个本来很费解的问题**：为什么这套算法被逆得这么透，却从来没在任何抓包里见过它的产物——因为它压根不进请求。

- **请求签名（libG.so 的 hkey）**：现役、唯一真正在被服务端拿去校验的字段。

对抗强度和实际现役价值在这里出现了一次明显的倒挂——**逆向投入最大的两块，一个被攻克了，一个已经退役**。

### 5.2 一处漂亮的 anti-grep：拆词拼参数名

请求签名整体是在一个统一的方法里组装的，这个方法给最终请求追加一整组参数，而这些参数的 key **不是字面量**，而是用字符串替换的方式现场拼出来的，示意（真实字符串已用占位符替代，拆解逻辑与原始手法完全一致）：

```java
// 示意代码，原始品牌相关字符串已替换为占位符
String paramKey = "target".replaceAll("tar", "cli").replaceAll("get", "ent_type");
// 拼出来的实际语义类似 "client_type" 这样的参数名
```

目的很直接：让你 `grep` 某个具体参数名的字面量直接失效——静态搜索代码库找不到这个参数名是怎么来的，必须动态执行或者手动追踪这条拆词逻辑才能还原出真实语义。这个技巧本身成本很低，但确实能让"直接搜索关键字段名"这条最省事的静态分析路径失效，是我在 Java 层见过的最简单也最有效的一处 anti-grep 设计。

### 5.3 机密通道：被误用的"私钥加密"

在追踪那把被分片存储、还带诱饵的 RSA 公钥（第一幕结尾留的钩子）时，我发现它除了参与签名相关流程之外，还服务于一整条独立的**机密通道**——服务端会下发一个包含三个字段的加密对象，其中一个字段是用 RSA 公钥加密过的对称密钥，另一个字段是被这把对称密钥加密的密文，第三个字段是明文的 MD5 值，仅用于完整性校验：

```java
// 示意
public static String decrypt(EncryptedPayload p) {
    String symKey = rsaPublicDecrypt(p.getEncryptedKey());     // 用公钥"解密"出对称密钥
    String plain  = symmetricDecrypt(p.getCiphertext(), symKey);
    String md5    = md5(plain);
    return md5.equals(p.getIntegrityHash()) ? plain : null;    // 完整性校验，非机密性校验
}
```

承重的对称算法是 **DES（56-bit）**——不是 AES。而且用"公钥去解密"这个操作本身就很反常：正常的信封加密应该是用**公钥加密**对称密钥、**私钥解密**，这里反过来了，客户端手里只有公钥，只能"解密"不能"加密"。

这里必须把两件事分清楚，否则容易误判——**机密性和真实性是两回事**：

**机密性：已经破了。** 有了提取出来的公钥，理论上可以直接从密文里解出对称密钥，再解出明文，而且 DES 只有 56 位，即便拿不到公钥也可以暴力破解。

**真实性：没有破。** 伪造一个合法的加密字段需要服务端的私钥，客户端手里只有公钥，只能解不能造，所以中间人没法注入自己伪造的恶意内容。

反过来想，用"私钥加密"这个不寻常的操作，真实意图很可能是**给下发内容做来源认证**（确保这段内容确实来自服务端，防止中间人篡改）——机密性只是顺带的、甚至可能是没考虑周全的副作用。但基元选错了（DES 加上公钥可提取），想要的机密性完全没拿到，只有认证这一半功能是有效的。这条被解密的内容，服务端下发的清一色是要注入 WebView 执行的 JavaScript——用于跟第三方游戏发行平台交互的一系列自动化脚本（登录、领取活动内容、下单）。这套加密保护的**不是用户数据，而是这家公司自己的一套自动化实现细节**——不想让第三方平台看见注入了什么，也不想让同行抄走这套逻辑。

### 5.4 一份跨系统的威胁模型矩阵

把五套系统横向摊开对比，能看出一些很有意思的分布规律：

| 系统 | 防护的资产 | 假想对手 | 检测/破解后的处置 | 对哪类对手有效 |
|---|---|---|---|---|
| 短码引擎(libN) | 请求防伪(已退役) | 脚本小子级别的批量刷接口 | 无(已不在请求路径里) | 已失效，对任何对手都无意义 |
| RSA分片+机密通道 | 自动化脚本的来源认证 | 竞品逆向者、平台方反作弊 | 内容注入前的完整性/来源校验 | 对篡改内容的中间人有效，对静态提取无效 |
| 自定义加固壳(壳-N) | 二级payload完整性 | 逆向工程师、内存hook工具 | 磁盘防篡改 / 裸syscall终止进程 | 对磁盘篡改有效，对内存ART hook天然失明 |
| 设备指纹(SDK-S) | 设备身份的干净度 | 批量注册/刷单的黑产 | 静默上报，服务端多信号评分决策 | 对单点绕过无效，靠云端多信号冗余抬高成本 |
| 请求签名(libG) | 请求参数不被篡改/重放 | 想要脱机批量伪造请求的黑产 | 服务端签名校验 | 算法已被离线还原，抗重放能力理论上为零 |

这张表最值得拎出来说的是最后一行——`hkey` 没有 nonce、没有时间戳直接进入签名，这既是设计上的合理（服务端拿它当设备指纹的确定性投影，这个投影本来就不该每次变），也是防御上的真实软肋：一旦离线还原了算法，理论上可以脱机批量伪造。但这里我想纠正自己之前的一个不够严谨的判断——**"确定性可复现"不等于"防线形同虚设"**。指纹机制的价值从来不在于"单次不可伪造"，而在于批量伪造需要付出的边际成本：批量复用同一份字段组合会导致同一个 `hkey` 在大量账号上重复出现，这本身就是一个极强的碰撞检测信号，等于把攻击者亲手送进了指纹碰撞检测的射程；想要伪造出多样化的合法 `hkey`，攻击者还得先搞清楚那 15 个字段各自的设备语义（这块 native 侧完全看不到，需要回到 Java 层做 hook），并且让伪造出来的设备画像跟其它信号（IP、行为序列、其它子系统的设备 ID）保持自洽——这个综合成本，远高于单纯"把算法还原出来"这一步。**指纹机制真正的作用，是把攻击者维持"指纹多样性 + 跨信号一致性"的规模化成本抬高，而不是让单次伪造在数学上不可能。** 如果真要提升这块的强度，正解是引入服务端下发的一次性挑战（challenge-response），而不是再往这套已经算法闭环的东西上叠一层混淆。

---

## 六、蓝队视角：

**针对短码引擎和 RSA 分片**：既然核心密钥其实是运行时输入的一部分而不是长期常量，这个设计本身没问题，真正的问题是**这套算法早就不在请求路径里了却还留在二进制里**——每多一段没在用的密码学实现，就是白白增加的攻击面和逆向者的免费练习靶。更实际的建议是把 RSA 公钥的分片策略从"native 存 3/4、Java 传 1/4"升级成真正的密钥协商（比如短期会话密钥配合 ECDH），而不是继续靠"藏一部分密钥材料"这种静态分片手段——分片能拖慢逆向速度，但拖不住耐心足够的对手，迟早会被完整还原。

**针对自定义加固壳**：这套系统最大的盲区是磁盘完整性防得死、内存 ART hook 完全免疫。如果我是这家厂商的工程师，我会优先补的不是磁盘校验的强度，而是**运行时的类方法指针一致性校验**——定期把内存里已加载类的方法入口地址跟一份预期的基线做比对，这条线目前完全是空的，比继续加固磁盘 CRC 划算得多。另外那套裸 syscall 处置手段虽然精巧，但本质上还是"处置在客户端完成"，一个耐心的对手迟早能在 tick 窗口内完成压制，更稳妥的思路是让处置决策部分依赖服务端下发的动态挑战，单靠客户端自证清白的模式天花板不高。

**针对设备指纹 SDK**：现在检测结果是静默上报、服务端决策，这个架构本身是对的，SaaS 风控就该这么做。但我在还原上报加密链路时发现对称密钥是硬编码的顺序字节，这个我认为是这套体系里唯一一处真正不合理的短板——上报机密性形同虚设，意味着上报包一旦被截获，可以被静态批量解密和批量伪造。检测逻辑藏得再深、平坦化打得再狠，都补不回这一条传输链路上的漏洞，这里的性价比账算得不划算：混淆预算过度集中在检测函数上，传输安全反而被完全忽视，我会建议把资源匀一部分过来，哪怕只是换成一个真正随机生成的会话密钥，边际收益都远高于继续加固检测函数的混淆强度。

**针对请求签名黑箱**：这套系统的算法层已经完全确定，唯一的软肋是没有 nonce、没有时间戳参与签名。我会强烈建议在现有的字段基础上追加一个由服务端下发的一次性挑战值参与签名计算，这个改动对现有架构几乎零侵入（反正协议里已经在传输时间戳字段了，只是没参与签名而已），但能直接把"离线批量伪造"的可行性归零——比继续在 QuickJS 这层伪装或者继续混淆核心变换函数划算得多。当前所有工程投入都花在"藏算法"上，而算法本身的抗重放能力是零，这个投入产出比明显是失衡的。

**相互印证**：这几套系统之间几乎没有互相印证——设备指纹检测出的"环境异常"跟请求签名的合法性校验是两条完全独立的判断链路，理论上一个设备可以在指纹检测上被打上"可疑"标签，但请求签名依然正常通过并被服务端接受。如果这几条信号能在服务端做一次交叉验证（比如同一设备指纹关联的多个请求签名之间是否存在异常的重复模式），防御效果会比继续在每一套系统内部单独加固强得多——这也是"风控"跟"单纯的客户端加固"最大的思路差异：单个系统内部的混淆强度总有天花板，但跨系统的信号交叉为0.

---

![图片描述](upload/attach/202607/1053738_HYMED9DS56Q683W.webp)

## 七、结语

没有完成的：

- 短码引擎的两位校验算法，目前用 Unicorn 当 oracle 顶替，尚未完全转成纯 Python 等价实现。
- 加固壳的二级 payload 真身尚未取得，需要动态 dump，且必须先压住全部检测线才能安全完成。
- 请求签名黑箱里那条独立的自动化脚本字节码交付链路，静态部分已经闭环，动态 hook 验证部分作为独立课题留待后续，跟本文主线无关，不在这里强行凑数。
- RSA 公钥拼接过程里一个来源不明的运行时参数，两条独立的分析路径都没能确认它的确切作用。
脚本和代码都在附录

（全文完）

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

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

上传的附件：

aes_report.py （2.14kb，18次下载）
engine.py （29.74kb，17次下载）

最新回复 (51) 1 2 3 ▶
温泉划水鱼雪币： 94 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 226 粉丝 28 关注私信	温泉划水鱼 2 楼 ???? 2026-7-12 10:51 0
mb_qimctavn 雪币： 5327 活跃值： (6780) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 401 粉丝 1 关注私信	mb_qimctavn 3 楼 6 2026-7-12 10:54 0
mb_suajmqsa 雪币： 32 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 28 粉丝 0 关注私信	mb_suajmqsa 4 楼 9999999 2026-7-12 12:36 0
iBa0 雪币： 1901 活跃值： (5928) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 490 粉丝 37 关注私信	iBa0 5 楼 66 2026-7-12 17:12 0
熊猫吃鱼雪币： 2040 活跃值： (4596) 能力值： ( LV3，RANK：20 ) 在线值：发帖 48 回帖 230 粉丝 50 关注私信	熊猫吃鱼 6 楼 66666 2026-7-12 17:17 0
mb_vghyvbhn 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 18 粉丝 0 关注私信	mb_vghyvbhn 7 楼 6666 2026-7-13 09:29 0
Imxz 雪币： 110 活跃值： (9571) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 775 粉丝 9 关注私信	Imxz 8 楼 tql 2026-7-13 09:39 0
Gryffindoss 雪币： 635 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 126 粉丝 0 关注私信	Gryffindoss 9 楼 6666 2026-7-13 10:11 0
随风而行aa 雪币： 7773 活跃值： (25229) 能力值： ( LV12，RANK：550 ) 在线值：发帖 39 回帖 432 粉丝 1587 关注私信	随风而行aa 10 10 楼看看 2026-7-13 10:32 0
s1nec-1o 雪币： 1900 活跃值： (3860) 能力值： ( LV7，RANK：110 ) 在线值：发帖 5 回帖 67 粉丝 33 关注私信	s1nec-1o 2 11 楼看看 2026-7-13 11:13 0
wx_插曲雪币： 411 活跃值： (991) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 323 粉丝 24 关注私信	wx_插曲 12 楼看 2026-7-13 13:23 0
xingbing 雪币： 158 活跃值： (5791) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1400 粉丝 2 关注私信	xingbing 13 楼学习！！！ 2026-7-13 14:37 0
小黄鸭爱学习雪币： 2982 活跃值： (5952) 能力值： ( LV2，RANK：10 ) 在线值：发帖 18 回帖 339 粉丝 154 关注私信	小黄鸭爱学习 14 楼 tt 2026-7-13 15:52 0
guijingwen 雪币： 7377 活跃值： (7605) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 312 粉丝 0 关注私信	guijingwen 15 楼 66 2026-7-13 16:04 0
Thehepta 雪币： 3601 活跃值： (7420) 能力值： ( LV11，RANK：185 ) 在线值：发帖 23 回帖 240 粉丝 283 关注私信	Thehepta 3 16 楼 1 2026-7-13 17:33 0
k4y0z 雪币： 325 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 144 粉丝 1 关注私信	k4y0z 17 楼 666 2026-7-13 18:18 0
mb_jnmxfjku 雪币： 109 活跃值： (820) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_jnmxfjku 18 楼 666 2026-7-13 19:57 0
zuoshang 雪币： 1848 活跃值： (2655) 能力值： ( LV6，RANK：80 ) 在线值：发帖 6 回帖 40 粉丝 55 关注私信	zuoshang 1 19 楼图好像不显示最后于 2026-7-13 20:17 被zuoshang编辑，原因：原来是回复了才显示 2026-7-13 20:16 0
mb_dmryhnwz 雪币： 10 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 92 粉丝 0 关注私信	mb_dmryhnwz 20 楼 666 2026-7-13 23:53 0
mb_pvtzrssj 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 20 粉丝 0 关注私信	mb_pvtzrssj 21 楼看看 2026-7-14 15:30 0
mb_nwhhyhde 雪币：能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	mb_nwhhyhde 22 楼 666 2026-7-14 15:30 0
mb_zmitfows 雪币： 211 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 0 关注私信	mb_zmitfows 23 楼 666 2026-7-14 15:43 0
无忧序列号雪币： 825 活跃值： (129) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 11 粉丝 0 关注私信	无忧序列号 24 楼 666 2026-7-15 16:08 0
CheRevir 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 90 粉丝 0 关注私信	CheRevir 25 楼 666 2026-7-15 18:12 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复