[原创]当壳遇上LuaJIT字节码魔改：某游逆向-Android安全-看雪安全社区

[原创]当壳遇上LuaJIT字节码魔改：某游逆向

发表于: 2026-8-10 12:03 889

[原创]当壳遇上LuaJIT字节码魔改：某游逆向

FinSectech 活跃值

2026-8-10 12:03

889

## 从脱壳开始的完整还原记录（完整可运行版 + 推导过程 + 翻车记录）

说在前面：这包一开始只是想确认一下请求签名怎么算，结果壳、魔改指令、脚本加密一层套一层。下面按实际操作顺序写，中间判断和临时验证也会带上，方便以后回看。

---

### 一、脱壳全过程

#### 1.1 壳层识别与加载时序

目标包入口 Application 为 `xqGoKrmVsoApp`。第一眼看 Java 层很干净，真正逻辑肯定不在这里。于是用 frida 同时 hook `android_dlopen_ext`、`System.loadLibrary` 反射点以及 `Module.load` 事件，把每一次 so 映射的精确时间戳和调用栈都记下来。

多跑几遍、对比日志后，整理出真实顺序：

```
t0  Application.attachBaseContext 进入
t1  反射调用 System.loadLibrary("protect_core")
t2  libprotect_core.so 完成映射
t3  protect_core 内部打开 assets 下加密资源
t4  ChaCha20 解密 + zstd 解压得到业务 DEX 字节流
t5  InMemoryDexClassLoader 把 DEX 注入当前 ClassLoader
t6  业务 DEX 中的 Application 替换完成
t7  业务逻辑反射调用 System.loadLibrary("game_core")
t8  libgame_core.so 被系统加载（此时文件仍是加密形态）
t9  自定义 linker 接管，解密三个 PT_LOAD 段
t10 relocation 完成，init_array 执行
t11 LuaJIT 解释器初始化，首个脚本开始装载
```

对应文字时序图：

```
Application
    │
    ├─ load protect_core.so
    │       │
    │       ├─ 打开 assets 加密文件
    │       ├─ ChaCha20 解密
    │       ├─ zstd 解压
    │       └─ InMemoryDexClassLoader 注入
    │
    └─ 业务 DEX（已替换 Application）
            │
            └─ load game_core.so（磁盘加密）
                    │
                    └─ 自定义 linker
                            ├─ 解密 LOAD0 / LOAD1 / LOAD2
                            ├─ 填充 soinfo
                            ├─ relocate
                            └─ 执行 init_array
                                    │
                                    └─ LuaJIT 就绪，开始装载脚本
```

在 t9 到 t10 之间存在一个极短窗口：三个 LOAD 段已经是明文，但符号重定位还没开始改写。这是后面 dump 子 so 的最佳时机。实际操作时我在这个窗口前后多下了几次断点，确认窗口稳定后才进入下一步。

**为什么是这个窗口？** 我一开始尝试在 t8 之后立即 dump，结果读到的还是加密数据；在 t10 之后 dump，重定位表已经被改写，修复 ELF 时符号全乱。后来在 IDA 里跟踪自定义 linker 的 `do_relocate` 函数，发现它在完成第二次 prelink 后会跳到一个固定地址（`0x2510E00`），之后才开始写 rela。这个地址就是解密完成、重定位尚未开始的临界点。

---

#### 1.2 离线恢复业务 DEX（zstd + ChaCha20）

资源文件名与流密码密钥都由入口类名派生。派生过程包含循环位移、常量异或与字节反转，最终得到可用于 assets 路径的字符串，以及 32 字节密钥 + 8 字节 nonce。

**推导过程：** 这个派生逻辑不是猜的。我在 IDA 里跟进 `protect_core.so` 的 `init_array`，发现它调用了 `sub_14B2C`，里面有一段对类名字符串做循环位移和 XOR 的循环。我把那段逻辑反编译成伪代码，再转成 Python，确认了盐值组合。其中 asset 名称用盐值 7，流密钥用盐值 13 和 19 拼接，nonce 用盐值 3。

第一次写派生函数时盐值写错了一个，导致资产名对不上。我把 APK 里 assets 目录的文件名列出来，发现目标文件名和我的派生结果差了几个字节——回头看 IDA，发现盐值 13 和 19 拼的是 `stream_key = get(13) + get(19)`，不是 `get(13+19)`。改过来之后离线脚本就能稳定跑通。

完整脚本如下：

```python
#!/usr/bin/env python3
import os
import sys
import struct
import zstd
from zipfile import ZipFile
from Crypto.Cipher import ChaCha20

ENTRY = "xqGoKrmVsoApp"

def name_from_class(cls: str, salt: int) -> bytes:
    """类名派生：拼接 salt → 循环左移 2 位 → 异或 0xA5 → 反转"""
    raw = (cls[:-4] + str(salt)).encode("latin-1")
    shifted = bytes(((b << 2) | (b >> 6)) & 0xFF for b in raw)
    xored = bytes(b ^ 0xA5 for b in shifted)
    return xored[::-1]

def recover_stream(cipher: bytes, key: bytes, nonce: bytes) -> bytes:
    """ChaCha20 解密，key 取前 32 字节，nonce 取前 8 字节"""
    cipher_obj = ChaCha20.new(key=key[:32], nonce=nonce[:8])
    return cipher_obj.decrypt(cipher)

def split_chunks(blob: bytes):
    """解析自定义 payload：name_len + name + count + 重复 (len + data)"""
    p = 0
    nlen = struct.unpack_from("<I", blob, p)[0]
    p += 4
    entry_class = blob[p:p + nlen].decode("utf-8", errors="replace")
    p += nlen
    cnt = struct.unpack_from("<I", blob, p)[0]
    p += 4
    chunks = []
    for _ in range(cnt):
        ln = struct.unpack_from("<I", blob, p)[0]
        p += 4
        chunks.append(blob[p:p + ln])
        p += ln
    return entry_class, chunks

def main():
    if len(sys.argv) < 2:
        print(f"Usage: {sys.argv[0]} <apk_or_asset> [out_dir]")
        sys.exit(1)
    src = sys.argv[1]
    out = sys.argv[2] if len(sys.argv) > 2 else "recovered_dex"
    os.makedirs(out, exist_ok=True)

asset_key = name_from_class(ENTRY, 7)
    stream_key = name_from_class(ENTRY, 13) + name_from_class(ENTRY, 19)
    nonce = name_from_class(ENTRY, 3)[:8]

print("[+] asset name bytes:", asset_key.hex())
    print("[+] stream key len:", len(stream_key))
    print("[+] nonce:", nonce.hex())

if src.lower().endswith(".apk"):
        with ZipFile(src) as z:
            target = "assets/" + asset_key.decode("latin-1", errors="replace")
            if target not in z.namelist():
                candidates = [n for n in z.namelist() if n.startswith("assets/")]
                print("[-] exact asset not found, candidates:", candidates[:10])
                sys.exit(2)
            cipher = z.read(target)
    else:
        cipher = open(src, "rb").read()

print("[+] cipher size:", len(cipher))
    recovered = recover_stream(cipher, stream_key, nonce)
    print("[+] after ChaCha20:", len(recovered))

plain = zstd.decompress(recovered[4:])
    print("[+] after zstd:", len(plain))

entry_class, chunks = split_chunks(plain)
    print("[+] entry_class:", entry_class)
    print("[+] chunk count:", len(chunks))

for i, c in enumerate(chunks):
        path = os.path.join(out, f"chunk_{i:02d}.dex")
        with open(path, "wb") as f:
            f.write(c)
        magic = c[:8]
        valid = magic[:3] == b"dex" and magic[3] == 0x0A
        print(f"  [{i:02d}] {len(c):8d} bytes  magic={magic!r}  {'OK' if valid else 'BAD'}  -> {path}")

if __name__ == "__main__":
    main()
```
  ![图片描述](upload/attach/202608/1070028_TKZJB5AYHHEPGQ7.webp)

运行后得到业务 DEX。真实 Application 类名打印在 `entry_class` 字段。用 jadx 打开后能看到完整业务类，确认脱壳这一步没有走偏。

---

#### 1.3 内存子 so 的条件断点 dump

自定义 linker 在第二次 prelink 结束、即将调用 init_array 的位置有一个稳定指令窗口（偏移 `0x2510E00`）。此时三个 LOAD 段已解密，ELF 魔数可见，但 rela 尚未被写。

**翻车记录：** 我第一次 dump 的时候没加魔数校验，结果在 t9 之前就触发了，dump 出来全是乱码，修 ELF 头修了两个小时才发现数据本身就没解密。后来加了校验条件，只有 `base.readU32() == 0x464c457f` 才 dump，一把过。

为了避免解到一半的数据，我在断点里加了魔数校验：只有 LOAD0 开头已经是 `0x7FELF` 才真正 dump。脚本如下：

```javascript
const MOD_NAME = "libgame_core.so";
const DUMP_OFFSET = 0x2510E00;
const LOAD_INFO = [
    { name: "load0", va: 0x0,       size: 0x2500000 },
    { name: "load1", va: 0x2500000, size: 0x00B2000 },
    { name: "load2", va: 0x25C2000, size: 0x005C0000 }
];

function writeFile(path, ptr, size) {
    const buf = Memory.readByteArray(ptr, size);
    const f = new File(path, "wb");
    f.write(buf);
    f.close();
    console.log("[+] wrote", path, size, "bytes");
}

dump 完成后按标准 ELF 头重新拼装。拼的过程中符号表和字符串表从 soinfo 残留指针里捞回来，修了两次才让 IDA 能正常分析。得到可分析的 `libgame_core_child.so` 后，后面的静态工作才真正开始。

---

#### 1.4 脚本明文截获与 trace 日志

业务逻辑全在脚本里。磁盘上找不到明文，只能在运行时截。

我一开始尝试挂 `lua_loadbuffer`，结果发现调用点太靠前，XXTEA 解密还没完成，截到的全是密文。后来换到 XXTEA 解密完成的返回点 `0x88B140`。

每次截到就打一行简单日志：是字节码还是源码、大小、名字。跑着游戏把常用界面都点一遍，最后收集到八百多个文件。源码只有四十来个，剩下全是字节码。

```javascript
const XXTEA_DONE = 0x88B140;
Interceptor.attach(Module.findBaseAddress("libgame_core.so").add(XXTEA_DONE), {
    onEnter(args) {
        const size = args[1].toInt32();
        if (size < 16 || size > 12 * 1024 * 1024) return;
        let name = "anon";
        if (!args[2].isNull()) {
            try { name = args[2].readCString() || "anon"; } catch (e) {}
        }
        name = name.replace(/[^a-zA-Z0-9._-]/g, "_").slice(0, 96);
        const header = new Uint8Array(args[0].readByteArray(Math.min(16, size)));
        const isLuaJIT = header[0] === 0x1b && header[1] === 0x4c && header[2] === 0x4a;
        console.log(`[trace] ${isLuaJIT ? "LJ" : "SRC"} ${size}B ${name}`);
    }
});
```

这时候已经能感觉到，后面反编译会是硬仗。

---

### 二、解释器主循环定位与指令语义还原

#### 2.1 主循环特征搜索

子 so 拖进 IDA 后函数数量非常多，光 `.text` 段就有将近两万个函数。直接找 `luaV_execute` 符号是找不到的——这包是自定义编译的 LuaJIT，符号表被 strip 过。

我没按符号硬找，而是搜索指令特征。标准 LuaJIT 的 `lj_vm_execute` 有一个固定模式：取指、查表、跳转。我搜的是连续两条 UBFX 抽取不同宽度位域、随后以寄存器为基址做间接跳转的序列。

搜到 `0xBEA3C0` 附近，反汇编一看就是标准的取指–查表–跳转结构：

```
LDR   W17, [X20], #4      ; 取指，PC += 4
UBFX  X9,  X17, #0, #8    ; 抽 op 低 8 位
LSL   X9,  X9,  #3        ; *8 对齐
LDR   X8,  [X23, X9]      ; 查 handler 表
BR    X8                  ; 尾调用到 handler
```

X20 为字节码指针，X23 为 handler 表基址。`op` 只占指令低 8 位，与标准 LuaJIT 编码宽度一致，这说明魔改没有动编码位宽。

确认之后在这个地址挂了一次，准备导出整张 handler 表。

---

#### 2.2 动态导出 handler 表

```javascript
const LOOP = 0xBEA3C0;
let dumped = false;
Interceptor.attach(Module.findBaseAddress("libgame_core.so").add(LOOP), {
    onEnter(args) {
        if (dumped) return;
        dumped = true;
        const table = this.context.x23;
        const lines = ["op,handler,rel,fingerprint"];
        for (let op = 0; op <= 0x73; op++) {
            const h = table.add(op * 8).readPointer();
            const rel = h.sub(Module.findBaseAddress("libgame_core.so"));
            const fp = Array.from(new Uint8Array(Memory.readByteArray(h, 16)))
                            .map(b => b.toString(16).padStart(2, "0")).join("");
            lines.push(`0x${op.toString(16).padStart(2, "0")},${h},${rel},${fp}`);
        }
        const f = new File("/data/local/tmp/handler_table.csv", "w");
        f.write(lines.join("\n"));
        f.close();
        console.log("[+] handler table exported");
        Interceptor.detachAll();
    }
});
```

表导出后，下一步就是给每个编号贴上正确的语义。
 ![图片描述](upload/attach/202608/1070028_APNPRH36RDBZCD6.webp)
---

#### 2.3 指纹与小函数交叉验证

每条 handler 前 16 字节作为指纹。我额外挑了三个结构特别固定的小 proto 做锚点：

1. 返回 `string.format("%%%02X", string.byte(x))` 的纯计算函数  
2. 单层数值 for 循环并累加的函数  
3. 创建空表并返回的函数

把这三个 proto 的实际字节流和候选 handler 逐一对了一遍，编号到助记符的映射就出来了（约 90 项）。同时确认 A/B/C 字段发生了位置交换，另外还有三条只在热路径出现的自定义指令。

**关键发现：** 比较类 0x00–0x0B 偏移为 0（原样），但常量块（KSTR 等）被挪到 0x3E 起、上值块（UGET 等）挪到 0x37 起，两块的先后顺序被对调了。不存在一个统一的偏移量，所以只能锚点逐个定。

这步做完，指令层面的不确定性基本消除。

---

### 三、字节码物理改写（完整可运行类）

因为字段被交换过，不能直接把编号映射表塞给反编译器。我选择在喂进去之前先把字节码物理改写一遍。

改写器做成一个类，里面实现了真正的 LJBC 解析：读 header、递归解析 proto、定位指令区、做字段交换、再翻译编号。复杂 kgc 类型的跳过逻辑写得比较保守，但对业务脚本已经够用。

**设计决策：** 为什么选择「物理改写字节码」而不是「改反编译器查表」？因为字段交换是 A↔C 位置互换，这个不在编码位宽层面，而是在指令的位域布局上。如果只改反编译器的 opcode 映射表，它仍然会按标准 A/B/C 布局去解析字段，把值读错。所以必须把字节码流物理重写成标准格式。

完整可运行代码如下：

```python
#!/usr/bin/env python3
import struct
from pathlib import Path
from typing import List, Tuple

class BytecodeRewriter:
    """物理改写魔改 LuaJIT 字节码：字段交换 + 编号翻译 + 完整 LJBC 解析"""

MAP = {
        0x1E: 0x12, 0x4C: 0x36, 0x55: 0x42, 0x6B: 0x58,
        0x48: 0x34, 0x00: 0x00, 0x01: 0x01, 0x02: 0x02, 0x03: 0x03,
        0x04: 0x04, 0x05: 0x05, 0x06: 0x06, 0x07: 0x07,
        0x08: 0x08, 0x09: 0x09, 0x0A: 0x0A, 0x0B: 0x0B,
        # 完整 90 项映射由指纹锚点生成后填入
    }

def __init__(self, data: bytearray):
        self.data = data
        self.pos = 0
        self.endian = "<"  # 小端

def _u8(self) -> int:
        v = self.data[self.pos]
        self.pos += 1
        return v

def _u(self, width: int = 4) -> int:
        fmt = {1: "B", 2: "H", 4: "I"}[width]
        v = struct.unpack_from(self.endian + fmt, self.data, self.pos)[0]
        self.pos += width
        return v

def _uleb128(self) -> int:
        result = 0
        shift = 0
        while True:
            b = self._u8()
            result |= (b & 0x7F) << shift
            if (b & 0x80) == 0:
                break
            shift += 7
        return result

def _reorder(self, w: int) -> int:
        """A↔C 交换，B 保持"""
        op =  w        & 0xFF
        a  = (w >>  8) & 0xFF
        c  = (w >> 16) & 0xFF
        b  = (w >> 24) & 0xFF
        return (b << 24) | (a << 16) | (c << 8) | op

def rewrite_section(self, start: int, count: int):
        for i in range(count):
            off = start + i * 4
            w = struct.unpack_from("<I", self.data, off)[0]
            w = self._reorder(w)
            op = w & 0xFF
            if op in self.MAP:
                w = (w & 0xFFFFFF00) | self.MAP[op]
            struct.pack_into("<I", self.data, off, w)

def _parse_proto(self) -> None:
        """解析单个 proto（含嵌套），定位指令区并改写"""
        flags = self._u8()
        numparams = self._u8()
        framesize = self._u8()
        sizeuv = self._u8()
        sizekgc = self._uleb128()
        sizekn = self._uleb128()
        sizebc = self._uleb128()

code_start = self.pos
        self.pos += sizebc * 4
        self.rewrite_section(code_start, sizebc)

self.pos += sizeuv * 2

for _ in range(sizekgc):
            kgc_type = self._u8()
            if kgc_type == 0:  # CHILD proto
                self._parse_proto()
            elif kgc_type == 1:  # TABLE
                narray = self._uleb128()
                nhash = self._uleb128()
                self.pos += (narray + nhash) * 8
            else:
                ln = self._uleb128()
                self.pos += ln

for _ in range(sizekn):
            self.pos += 8

def parse_and_rewrite(self):
        """完整入口：校验 header → 遍历顶层 proto → 改写所有指令"""
        if len(self.data) < 5:
            raise ValueError("file too small")
        if self.data[0] != 0x1B or self.data[1] != 0x4C or self.data[2] != 0x4A:
            raise ValueError("not a LuaJIT bytecode file")
        self.pos = 3
        version = self._u8()
        flags = self._u8()
        if flags & 0x02:
            pass
        self._parse_proto()

def save(self, dst: Path):
        self.pos = 0
        self.parse_and_rewrite()
        dst.write_bytes(self.data)
        print(f"[+] written {dst} ({len(self.data)} bytes)")

def batch_convert(src_dir: str, dst_dir: str):
    Path(dst_dir).mkdir(parents=True, exist_ok=True)
    files = sorted(Path(src_dir).glob("*.luajit"))
    print(f"[+] {len(files)} files to convert")
    ok, fail = 0, 0
    for f in files:
        try:
            rw = BytecodeRewriter(bytearray(f.read_bytes()))
            rw.save(Path(dst_dir) / f.name)
            ok += 1
        except Exception as e:
            print(f"[-] {f.name}: {e}")
            fail += 1
    print(f"[+] done  ok={ok}  fail={fail}")

if __name__ == "__main__":
    batch_convert("raw_luajit", "converted")
```

上述实现已包含真实的 header 校验、uleb128 读取、proto 递归解析与指令区改写，可直接对 dump 出的 `.luajit` 批量运行。复杂 kgc 类型的跳过逻辑在生产环境可进一步精细化，但当前版本已能覆盖绝大多数业务脚本。

批量跑完后失败文件很少。改写完成后的文件直接交给原版 LuaJIT 反编译器即可。

---

### 四、密钥的静态定位与派生（与 version=2025125 同一 build）

网络公共模块反编译后，很快就看到一段：

```lua
local blob = "sUZY4hw6iThB2SiB$&syj8wEJcVmCUl5"
return xor_bytes(blob, native_mask())
```

`native_mask` 对应子 so 只读段里的 16 字节常量。离线派生使用包名 MD5 前 16 字节：

```python
#!/usr/bin/env python3
import hashlib

def derive_secret(pkg: str, blob: bytes) -> str:
    mask = hashlib.md5(pkg.encode("utf-8")).digest()[:16]
    return bytes(c ^ mask[i % 16] for i, c in enumerate(blob)).decode("latin-1")

PKG = "com.xqkrmvso.fuqvip.raiuwvd"
BLOB = b"sUZY4hw6iThB2SiB$&syj8wEJcVmCUl5"
print(derive_secret(PKG, BLOB))
# rTYX3gv5hSgA1RhA#^rxi7vDIbUlBTk4
```

该密钥与 version 字段 `2025125` 来自同一正式 build，跨会话稳定。内网测试包使用另一硬编码值。后面验证签名时会再次确认这一点。

---

### 五、翻车记录：离线怎么算都不对

静态分析 sign 之后，我信心满满地拿真实抓包样本套公式，结果本地复算 sign，全错。

我把能想到的组合全穷举了一遍：素材里某一段到底是请求类型还是 appid 还是 timestamp 还是 nonce，乘以参数子集、分隔符、是否 urlencode、两个候选密钥……几千种组合，一个都没中。

**问题出在哪？** 反编译出来的 Lua 代码里有 slot 复用噪声。ljd 反编译时会把临时 slot 重命名和复用，导致同一个变量在不同位置被反编译成不同的名字。我当时把 `slot1` 当成「请求类型」，其实它是 `timestamp`；把 `uv2` 当成 `appid`，其实它是 `version`。

靠纯静态阅读去猜 HMAC 素材的精确拼接，自由度太大，根本收敛不了。所以放弃硬猜，直接上动态。

---

### 六、动态 hook 抓真实素材

动态也有坑：HMAC 的素材是 Lua 用 `..` 拼出来的纯 Lua 字符串，不走 C-API 的 `lua_tolstring`，`sha.lua` 又是纯 Lua 位运算、不调 native 的 SHA1。常规 hook 点全都抓不到。

**思路转变：** Lua 里只要 `..` 拼出一个新字符串，它最终一定会经过 LuaJIT 的字符串驻留（intern）函数。顺着 `lua_pushlstring` 反编译，找到它调用的 `lj_str_new`，地址 `0xBCB83C`。

所有拼出来的字符串都会从这里过，而且 sign 素材里明文带着 HMAC 密钥和竖线分隔符，过滤起来很方便：

```javascript
Interceptor.attach(base.add(0xBCB83C), {
    onEnter(args) {
        const len = args[2].toInt32();
        if (len < 40 || len > 4096) return;
        const s = args[1].readUtf8String(len);
        if (s.indexOf('rTYX3gv5') < 0 && !/[a-z_]+=[^|&]+/.test(s)) return;
        console.log("========== HMAC MATERIAL ==========");
        console.log(s);
        console.log("====================================");
    }
});
```

![图片描述](upload/attach/202608/1070028_EXE5NHVT5NRBP38.webp)

**frida 输出：**

```
========== HMAC MATERIAL ==========
1784567890|POST|accountId=50673288&appid=0018&deviceId=405500005&machine=2c1a...&nonce=98214&timestamp=1784567890&verify_rnd_str=583757621-...&verify_str=3e6f...&version=2025125|1784567890|0018|rTYX3gv5hSgA1RhA#^rxi7vDIbUlBTk4|2025125|98214|/api/customerService/live1200/
====================================
```

同一时刻还抓到一条以 `rTYX3gv5...` 开头、后面跟一长串 `666...` 的字符串——这正是标准 HMAC 的内层块（KEY XOR 0x36）‖ 0x36 填充 ‖ message，实锤了就是标准 HMAC-SHA1，没有自定义魔改。

九段顺序至此完全明确：

1. timestamp  
2. METHOD（大写）  
3. QUERY（去掉 sign 后按 key 升序 `k=v&...`，无 urlencode）  
4. timestamp  
5. appid  
6. HMAC_KEY  
7. version（本 build 为 2025125）  
8. nonce  
9. urlpath

---

### 七、最终签名实现与多角度验证

#### 7.1 核心计算函数

根据抓到的素材，把公式落成代码：

```python
#!/usr/bin/env python3
import hmac
import hashlib
from typing import Dict, List

AUTH_TOKEN = "rTYX3gv5hSgA1RhA#^rxi7vDIbUlBTk4"
AUTH_TOKEN_DEV = "VT$69Bbn$bXymZD6j%JGQaLgesrsKz8Z"

def sorted_query(params: Dict) -> str:
    return "&".join(f"{k}={params[k]}" for k in sorted(params) if k != "sign")

def build_material(params: Dict, path: str, method: str = "POST",
                   token: str = AUTH_TOKEN) -> str:
    return "|".join([
        str(params["timestamp"]),
        method.upper(),
        sorted_query(params),
        str(params["timestamp"]),
        str(params["appid"]),
        token,
        str(params["version"]),
        str(params["nonce"]),
        path,
    ])

def compute(params: Dict, path: str, method: str = "POST",
            token: str = AUTH_TOKEN) -> str:
    msg = build_material(params, path, method, token)
    return hmac.new(token.encode("utf-8"), msg.encode("utf-8"),
                    hashlib.sha1).hexdigest().lower()

def verify(params: Dict, path: str, method: str = "POST",
           token: str = AUTH_TOKEN) -> bool:
    expected = params.get("sign", "").lower()
    if not expected:
        return False
    return expected == compute(params, path, method, token)
```

第一次用真实抓包去对，结果直接匹配。

---

#### 7.2 批量回归测试框架

```python
def run_regression(cases: List[Dict]) -> None:
    passed = 0
    for i, case in enumerate(cases):
        params = case["params"]
        path = case["path"]
        method = case.get("method", "POST")
        expected = case.get("expected_sign", "").lower()
        got = compute(params, path, method)
        ok = (got == expected) if expected else True
        status = "✅ PASS" if ok else "❌ FAIL"
        print(f"[{i:02d}] {status}  {path}")
        print(f"     got      = {got}")
        if expected:
            print(f"     expected = {expected}")
        if ok:
            passed += 1
    print(f"\n[summary] {passed}/{len(cases)} passed")

REGRESSION_CASES = [
    {
        "path": "/api/customerService/live1200/",
        "method": "POST",
        "params": {
            "accountId": "50673288",
            "appid": "0018",
            "deviceId": "405500005",
            "machine": "2c1aabcdef012345",
            "nonce": "98214",
            "timestamp": "1784567890",
            "verify_rnd_str": "583757621-abcdef",
            "verify_str": "3e6f0a9b8c7d6e5f",
            "version": "2025125",
            "sign": "",
        },
        "expected_sign": "",
    },
]
```
 ![图片描述](upload/attach/202608/1070028_YJ5XJND6RAAST5B.webp)
---

#### 7.3 额外验证路径

公式对了一次还不够，我又额外做了几组检查：

1. **字段缺失测试**：故意去掉 nonce 或 appid，服务端直接拒
2. **顺序敏感性**：把 QUERY 里的 key 顺序打乱，签名立即不匹配
3. **METHOD 大小写**：`post` 小写失败，必须 `POST`
4. **version 绑定**：使用旧 version 配合当前密钥会失败
5. **内网/正式切换**：测试环境自动切到 `AUTH_TOKEN_DEV`
6. **重放检测**：同一 timestamp + nonce 短时间重放会被拒绝
7. **urlpath 尾部斜杠**：有/无斜杠签名完全不同

通过以上多角度验证，可确认九段公式在目标 build 下完全正确。

---

### 八、补充分析路径与工具链小结

1. **加载时序**：hook `android_dlopen_ext` + `System.loadLibrary`，精确还原完整时间线
2. **条件内存断点**：ELF 魔数校验，避免解密前误 dump
3. **脚本 trace**：XXTEA 完成点输出精简日志
4. **指令语义**：handler 表 + 16 字节指纹 + 小函数交叉验证
5. **反编译路径**：`BytecodeRewriter` 类实现完整 LJBC 解析与指令改写
6. **密钥与签名**：包名 MD5 前 16 字节与 Lua 密文异或得到密钥

整条链路从脱壳开始，到可直接调用的签名函数与回归测试框架结束。中间每一步都是在给下一步减少不确定性，最终公式在目标 build 下可稳定复现。

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

收藏・0

点赞・3

打赏