[原创]记某灰黑棋牌游戏逆向-Android安全-看雪安全社区

[原创]记某灰黑棋牌游戏逆向

发表于: 2026-6-14 13:40 53823

[原创]记某灰黑棋牌游戏逆向

Aar0n

2026-6-14 13:40

53823

# 1.概况

这次拿到的是一个 Cocos2d-x + Lua 写的棋牌马甲包，目标很明确：把它的请求签名 `sign` 还原出来，方便后续做接口分析。

但这个app主要难在两点：

- 壳套了好几层，Java 壳里套 so，so 里又解出 dex，最后的真实 so 还是运行时才解密映射进内存的。
- 业务逻辑全在 Lua 里，而且不是普通 Lua，是**魔改了 opcode 的 LuaJIT** 编译成字节码再加密的。无法直接反编译。

整条链路大概是这样：

```
Java 壳 → librnbqzphi.so → 解密dex → libcocos2dlua.so → 内存子 so → 魔改 LuaJIT → 加密.luajit 脚本
```

# 2.脱壳

## 2.1 四层壳

先用 jadx 看 Java 层，入口 Application 是 `goPMyRxdApp`。

![image-20260614024212900](upload/attach/202606/985355_3B8MWF9X7TSP92F.png)

这壳一共四层，每层都是 **RC4 + zlib** 的组合，密钥不是写死的，是拿包名/类名做凯撒位移 `getNewKey(seed, shift)` 现算出来的：

1. Java 壳 `goPMyRxdApp`，用 `RC4(muVSFXEjmuVSFXEj) + zlib` 解出 `librnbqzphi.so`

或者按逻辑所示直接在`absolutePath + /ltUREWDi/librnbqzphi.so`中拉下来这个so即可

![image-20260614024747609](upload/attach/202606/985355_2G7R8DS2UB5RP7Z.png)

2. `librnbqzphi.so` 再用 `RC4(jrSPCUBgjrSPCUBg) + zlib` 解出 `解密后的dex`，这才是真正的业务 dex

此so的关键函数有：

- `myUnseal` — 反隐藏 API（FreeReflection 思路，patch art Runtime）
- `loadEncData` @0x1320C — 解密 `assets/ksTQDVCh` 得业务 DEX
- `make_dex_elements` — 把解密 DEX 注入到原 ClassLoader 的 dexElements
- `onCreateNative` — 真 Application 替换

![image-20260614031702139](upload/attach/202606/985355_NT9SAZAXCBWQ5XG.png)

梳理其加载业务dex的逻辑：密钥和资源名都是拿入口类名 `goPMyRxdApp` 去掉末尾 3 个字符（`goPMyRxd`）再 `getNewKey` 算出来的：`encName = getNewKey(keyStr, 4)` 是 assets 里加密资源的文件名，`rc4Key = getNewKey(keyStr, 3) * 2` 是 RC4 密钥（注意它把结果重复了一遍）。解密就是 `RC4` 之后跳过头 4 字节的长度，剩下 `zlib.decompress`

可以写一份离线脚本得到dex

```python
import os, sys, struct, zlib
from zipfile import ZipFile

APP_CLASS_SIMPLENAME = "goPMyRxdApp"  # AndroidManifest android:name basename

def get_new_key(seed: str, shift: int) -> str:
    out = []
    for ch in seed.encode():
        v = (ch + shift) & 0xFF
        if v >= 0x7B:
            v -= 57
        elif 0x5B <= v <= 0x60:
            v += 7
        out.append(v)
    return bytes(out).decode("latin-1")

def rc4(data: bytes, key: bytes) -> bytes:
    s = list(range(256))
    j = 0
    for i in range(256):
        j = (j + s[i] + key[i % len(key)]) & 0xFF
        s[i], s[j] = s[j], s[i]
    out = bytearray(len(data))
    i = j = 0
    for n, b in enumerate(data):
        i = (i + 1) & 0xFF
        j = (j + s[i]) & 0xFF
        s[i], s[j] = s[j], s[i]
        out[n] = b ^ s[(s[i] + s[j]) & 0xFF]
    return bytes(out)

def parse_payload(blob: bytes):
    p = 0
    (name_len,) = struct.unpack_from("<I", blob, p); p += 4
    real_name = blob[p:p + name_len].decode("utf-8", errors="replace")
    p += name_len
    (count,) = struct.unpack_from("<I", blob, p); p += 4
    dexes = []
    for _ in range(count):
        (ln,) = struct.unpack_from("<I", blob, p); p += 4
        dexes.append(blob[p:p + ln])
        p += ln
    return real_name, dexes, p

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

seed = APP_CLASS_SIMPLENAME[:-3]
    enc_name = get_new_key(seed, 4)
    rc4_key = (get_new_key(seed, 3) * 2).encode()

print(f"[+] simpleName  = {APP_CLASS_SIMPLENAME}")
    print(f"[+] keyStr      = {seed}")
    print(f"[+] encName     = {enc_name}")
    print(f"[+] rc4Key      = {rc4_key.decode()}")

if src.lower().endswith(".apk"):
        with ZipFile(src) as z:
            target = f"assets/{enc_name}"
            if target not in z.namelist():
                print(f"[-] {target} not found in APK"); sys.exit(2)
            cipher = z.read(target)
            print(f"[+] read APK!{target}: {len(cipher)} bytes")
    else:
        with open(src, "rb") as f:
            cipher = f.read()
        print(f"[+] read {src}: {len(cipher)} bytes")

step1 = rc4(cipher, rc4_key)
    (uncomp_size,) = struct.unpack("<I", step1[:4])
    print(f"[+] declared uncompressed size = {uncomp_size}")

blob = zlib.decompress(step1[4:])
    print(f"[+] actual   uncompressed size = {len(blob)}")
    if len(blob) != uncomp_size:
        print(f"[!] size mismatch (declared {uncomp_size} vs got {len(blob)})")

raw_path = os.path.join(out_dir, "_payload_plain.bin")
    with open(raw_path, "wb") as f:
        f.write(blob)
    print(f"[+] full plaintext blob -> {raw_path}")

real_name, dexes, consumed = parse_payload(blob)
    print(f"[+] real Application class = {real_name}")
    print(f"[+] dex count              = {len(dexes)}")
    print(f"[+] consumed {consumed} / {len(blob)} bytes")

for i, d in enumerate(dexes):
        path = os.path.join(out_dir, f"payload_{i:02d}.dex")
        with open(path, "wb") as f:
            f.write(d)
        magic = d[:8]
        ok = magic[:3] == b"dex" and magic[3] == 0x0A
        print(f"    [{i:02d}] {len(d):>10} bytes  magic={magic!r}  {'OK' if ok else '??'}  -> {path}")

if __name__ == "__main__":
    main()
```

3. `libcocos2dlua.so` 里面塞了一个被自定义 linker 打包过的**子 so**，运行时才解密映射
4. 子 so 里跑的就是魔改 opcode 的 LuaJIT，它负责解密并执行 `.luajit` 脚本

## 2.2 自定义linker得到子so

麻烦的是第三层那个子 so。它不落地，只在内存里，而且被自定义 linker 改过，段信息都不对，直接 dump 内存也修不成正常 ELF。

这里的思路是借用他自己的linker修复逻辑后dump：hook 它自己的 linker，等它把段都映射好、relocation 还没改之前那一刻下手。静态分析过 `master_linker`（`sub_250E338`）的调用序列，最佳 dump 点是 relocate 派发函数（`sub_2510444`）的入口：此时代码和数据都已经解密到位、映射进 LOAD0 了，但 rela/symtab/strtab 还是干净的，soinfo 也被两次 prelink 填满了。

```js
// dump_child_so.js：在 relocate 派发入口（解密完成、重定位之前）dump
const OFF_relocate_dispatcher = 0x2510444;   // 最佳 dump 时机
const OFF_alloc_soinfo        = 0x250D01C;   // 拿 soinfo 指针

// LOAD 段范围（来自 IDA 里 PT_LOAD 的 vaddr）
const LOAD0_VA = 0x0,        LOAD0_SZ = 0x24fe000;
const LOAD1_VA = 0x24fe000,  LOAD1_SZ = 0xafe98;
const LOAD2_VA = 0x25be2a0,  LOAD2_SZ = 0x5a8bd8;

Interceptor.attach(mod.base.add(OFF_relocate_dispatcher), {
    onEnter(args) {
        // 此时三个 LOAD 段已是解密后的明文，整段 dump 出来
        dumpRange('load0.bin', mod.base.add(LOAD0_VA), LOAD0_SZ);
        dumpRange('load1.bin', mod.base.add(LOAD1_VA), LOAD1_SZ);
        dumpRange('load2.bin', mod.base.add(LOAD2_VA), LOAD2_SZ);
        // 顺便把 soinfo 里解析出的 strtab/symtab/rela 各表也 dump 下来
    }
});
```

dump 完三个段，再把 soinfo 里读出来的 strtab/symtab/rela 等信息拼回一个标准 ELF 头。修完得到 `libcocos2dlua_child_v3.so`，45.5MB，6w 多个函数，能正常拖进 IDA解析。

**修复参考：<mark class="encrypted">6b1K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2U0N6r3k6A6L8%4c8Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6j5H3z5e0c8Q4x3X3g2Z5N6r3#2D9i4K6u0m8i4K6u0m8</mark>

**看雪ID：乐子人：https://bbs.kanxue.com/homepage-872365.htm**

![image-20260614033512527](upload/attach/202606/985355_A3J8C46BNUDP6RS.png)

后面所有的 opcode 分析、函数定位都基于这个修好的子 so。

## 2.3 把 lua 脚本 dump 出来

脱壳脱到这里，dex 和子 so 都有了，但**真正要分析的业务逻辑全在 lua 里**，而磁盘上根本找不到明文 lua——它们要么被 XXTEA 加密塞在 assets 里，要么干脆打包进资源，运行时才解出来交给 LuaJIT。所以得在「lua 已经被解密、即将喂给 LuaJIT 装载」的那一刻把它截下来。这一步是后面 opcode 还原和反编译的输入，没有它什么都谈不上。

定位思路是抓 Cocos 的 lua 装载入口。Cocos2d-x 里所有 lua 脚本最终都从 `cocos2d::LuaStack::luaLoadBuffer` 进去，它内部如果发现启用了 XXTEA 就先解密、再把明文丢给底层的 `luaL_loadbufferx` 装载。所以有两个可以下手的点：

- `LuaStack::luaLoadBuffer`（子 so `0x88ab58`）：入口，但拿到的 buf 可能还是 XXTEA 密文（取决于解密发生在函数内哪一步）。
- 底层装载 thunk（`0x60e850`，最终落到 `luaL_loadbufferx` 的 body `0x254ca84`）：**这里的 buf 一定是最终交给 LuaJIT 的明文**，是最干净的截获点。

我两个点都 hook 了，入口处当验证、底层 body 当主力，谁先稳定拿到明文用谁。注意那个底层 thunk 是经过 GOT 间接跳转的，地址不固定，得先把 GOT 解析一遍才能定位到真正的 body：

```js
//（核心：hook lua load，落地明文）
const OFF = {
    LuaStack_luaLoadBuffer: 0x88ab58,   // Cocos lua 装载入口
    luaL_loadbuffer_body:   0x254ca84,  // 最终 luaL_loadbufferx body，buf 已是明文
};

// 入口 hook：this, L, buf, size, name
Interceptor.attach(mod.base.add(OFF.LuaStack_luaLoadBuffer), {
    onEnter(args) {
        dumpBuffer('luaLoadBuffer.enter', args[1], args[2], args[3].toInt32(),
                   readCString(args[4]), this.context);
    }
});

// 底层 body hook：L, buf, size, name —— 主力截获点
Interceptor.attach(mod.base.add(OFF.luaL_loadbuffer_body), {
    onEnter(args) {
        dumpBuffer('luaL_loadbuffer_body', args[0], args[1], args[2].toInt32(),
                   readCString(args[3]), this.context);
    }
});
```

dump 的时候顺手按文件头分个类，方便后面处理——`1B 4C 4A` 开头（`\x1bLJ`）是 LuaJIT 字节码，存成 `.luajit`；纯可打印文本是明文 lua 源码，存成 `.lua`；再用「size + 头部 hex + name」去重，避免同一脚本反复装载存一堆：

```js
function classify(buf, size) {
    const u8 = readBytes(buf, Math.min(size, 512));
    if (u8[0] === 0x1b && u8[1] === 0x4c && u8[2] === 0x4a)   // \x1bLJ
        return { kind: 'luajit-bytecode', ext: 'luajit' };
    // 大部分字节可打印 -> 当明文 lua 源码
    // 否则 unknown
}
```

跑起来进游戏逛一圈，让它尽量多触发脚本装载，最后 pull 下来：

```bash
frida -U -f nlatyjs.fuqvipmonkk.raiuwvd -l scripts/dump_lua_direct_verified.js
adb pull /sdcard/Android/data/nlatyjs.fuqvipmonkk.raiuwvd/files/lua_dump_verified out/lua_dump_verified
```

![image-20260614131520166](upload/attach/202606/985355_C7BMBUR9TCCDRAA.png)

一共落地 900 多个文件，其中 47 个是明文 lua 源码（这部分直接就能看），**850 个是 LuaJIT 字节码 `.luajit`**——但这 850 个拖进任何反编译器都是乱码，因为它们是用魔改过 opcode 的 LuaJIT 编译的。这就引出了下一章。

# 3.魔改 opcode 还原

这是最难搞的。原版 LuaJIT 的 opcode 编号是固定的，魔改版把编号**重新排列**了，所以直接拿标准反编译器解析字节码会全部错位、崩溃。必须先在 IDA 里把`魔改编号 → 真实语义`这张表逆出来。

但这里要先解决一个问题：上来 IDA 里六万多个函数，`sub_XXXX` 一片，**怎么定位哪个函数是 VM 的分发循环、哪段数据是 opcode 表？**

## 3.1 怎么定位到分发循环

LuaJIT 的解释器有个很好认的结构特征，不管怎么魔改都跑不掉：它是 computed-goto 风格的「取指 → 查表 → 间接跳转」循环，编译到 arm64 上一定长这样——**用一个寄存器当字节码指针、自增取 4 字节、拿低 8 位当索引去查一张函数指针表、`BR` 跳过去**。所以不靠符号也能找，方法有几条，我是组合着用的：

- **认间接跳转 `BR`**：LuaJIT 的 handler 之间是尾调用串起来的，整个解释器里到处是 `LDR Xn, [Xtab, Xop, LSL#3]` 紧跟 `BR Xn` 这种「按 op×8 查表再跳」的形态。在 IDA 里搜 `BR` 指令，配合它前面是「基址 + 索引×8 取指针」的，很快能圈出分发点。
- **认字节码自增**：`LDR W16, [X21], #4`（带 `#4` 后变址）这种「读完指令指针自动 +4」的写法，在普通业务代码里几乎不出现，是取指循环的强特征。
- **顺藤摸瓜**：先找到任意一个明显是 Lua VM 的字符串（比如报错信息 `attempt to ...`、`luaL_` 相关），交叉引用到 VM 核心区域，分发循环就在这一片。

定位到的主分发循环在子 so 的 `0xbe901c`：

```asm
LDR  W16, [X21], #4          ; X21 = 字节码指针(PC)，取 4 字节指令，PC += 4
ADD  X9,  X22, W16, UXTB#3   ; X22 = 分发表基址；op = 指令低 8 位(UXTB)，×8 当偏移
UBFX X27, X16, #8,  #8       ; A = bits[8:16]
LDR  X8,  [X9, #0xF70]       ; handler = *(X22 + 0xF70 + op*8)
UBFX X28, X16, #16, #16      ; D = bits[16:32]
BR   X8                      ; 跳到对应 handler
```

这段把魔改的关键全暴露了：`UXTB`（取最低字节）说明 **op 就是指令的低 8 位**，`UBFX ...#8,#8` / `...#16,#16` 说明 **A/B/C/D 字段的位置和原版完全一样**。也就是说：

**标准 LuaJIT 的 BC_AD 指令编码（A/B/C/D 字段布局）一点没改，魔改的只是 op → handler 这个查表关系。** 换句话说，只要我把那张表搞到手，磁盘上的字节码本身可以原样喂给标准解析器，不用动编码。

顺带也拿到了两个后面要用的关键值：**分发表的基址在 `X22`，表相对 X22 的偏移是 `0xF70`**（动态 dump 时直接读 `X22+0xF70` 就是这么来的）。

## 3.2 怎么定位到 opcode 表并导出

分发循环只告诉我们运行时拿 `X22+0xF70` 这张表来跳，但 X22 是运行时才填好的寄存器，静态文件里这张表在哪、怎么填的，得去找**填表的那段初始化代码**。

顺着 `X22+0xF70` 这个表被写入的地方做交叉引用，找到初始化函数 `sub_BCE930`。它的 F5 伪代码很干净，就是一个循环把 handler 地址逐个写进分发表：

```c
// sub_BCE930：VM 启动时填分发表
for (int i = 0; i < 105; i++)
    handler[a1 + 0xF70 + 8*i] = BASE_HANDLER + *(OFFSET_TABLE + i);
// BASE_HANDLER = 0xBE8AF0   ← 所有 handler 的公共基址
// OFFSET_TABLE = 0x1210DC0  ← 一张 16 位相对偏移的数组
```

读这段伪代码能抠出三个常量，它们就是 opcode 表的全部秘密：

- **循环次数 105**：所以一共 105 个 opcode，编号 `0x00–0x70`。
- **`BASE_HANDLER = 0xBE8AF0`**：handler 地址的公共基址（循环体里那个加在偏移前面的常量）。
- **`OFFSET_TABLE = 0x1210DC0`**：一张 16 位偏移数组的起始地址（IDA 里双击进去就是一片 `.short` 数据）。第 `i` 个 16 位偏移加上基址，就是魔改编号 `i` 对应的 handler。

定位到这三个常量之后，opcode 表的还原就完全离线化了——根本不用在 IDA 里手点 105 次，写个脚本从修好的子 so 文件里把 `OFFSET_TABLE` 读出来、逐个加基址就行：

```python
# export_luajit_opcode_map.py
import struct
from pathlib import Path

SO  = Path(r"out\libcocos2dlua_child_v3.so")
BASE_HANDLER = 0xBE8AF0
OFFSET_TABLE = 0x1210DC0
MAX_OP = 0x70

data = SO.read_bytes()
rows = ["op,handler,handler_rel,first_bytes"]
for op in range(MAX_OP + 1):
    off = struct.unpack_from("<H", data, OFFSET_TABLE + op * 2)[0]
    handler = BASE_HANDLER + off
    first = data[handler:handler + 16].hex()      # 留作指纹识别
    rows.append(f"0x{op:02x},0x{handler:x},0x{off:x},{first}")
```

剩下的就是对每个 handler 做指纹识别，定出它到底是哪条指令。

## 3.3 两条路交叉验证

为了不出错，我用了两种方法对着验：

- **静态**：直接从子 so 里把 `OFFSET_TABLE` 读出来还原映射，如上
- **动态**：Frida 在运行时把真实分发表 dump 下来，跟静态的逐字节比。3.1 已经知道分发表基址在 `X22`、表偏移是 `0xF70`，那就 hook 到分发循环所在的代码块（函数头偏移 `0xbe9000`，循环体取指偏移是 `0xbe901c`，挂函数头即可），命中时直接从 `X22+0xF70` 把整张表读出来：

```js
// 命中分发循环时，从 X22+0xF70 读出整张 handler 表
dispatchListener = Interceptor.attach(mod.base.add(0xbe9000), {
    onEnter(args) {
        if (dumped) return;
        dumped = true;
        const table = this.context.x22.add(0xf70);
        for (let op = 0; op <= 0x70; op++) {
            const h = table.add(op * 8).readPointer();
            const rel = '0x' + h.sub(mod.base).toString(16);
            log(`op=0x${op.toString(16).padStart(2,'0')} handler=${h} rel=${rel}`);
        }
        dispatchListener.detach();
    }
});
```

两边结果完全一致，连 `0x6c == 0x6d` 共用同一个 handler（`0xbeaac4`）这种都对得上。

## 3.4 handler 指纹

判定语义靠的是 handler 里的特征指令，举几个例子：

| 语义            | 特征                                                |
| --------------- | --------------------------------------------------- |
| 算术 VN/NV/VV   | `FADD/FSUB/FMUL/FDIV/FRINTM` + 操作数加载顺序       |
| `0x68` JMP_FAST | `0xbeaa18`：直接 `PC += D`，没有 hotcount，裸重分发 |
| `0x42` CALL 尾  | `0xbe9b88`：往槽里写 `LJ_TNIL` 再分发               |
| `0x58` JMP 慢路 | `0xbea4b4`：走类型分发                              |

子 so 里其实有**两张**分发表，第二张是用 NEON 从 `word_1210E92` 填进 `a1+4888` 的 hotcount/JIT 表。这就解释了为什么魔改编号 `0x61–0x70` 是 `FORL/ITERL_HOT/LOOP_HOT/JMP_FAST` 这一类——作者是把 JIT 热度计数从 loop/call 指令里拆出来单独编了号，并没有改指令本身的语义。摸清楚这点之后，这几个扩展 opcode 在反编译里基本可以当 NOP / 普通 LOOP / CALL 处理。

# 4.补全 ljd 批量反编译

opcode 映射拿到了，接下来用 ljd（LuaJIT Decompiler，Aussiemon 那个 fork，支持 2.0/2.1）来反编译。驱动脚本是 `decompile_modded.py`。

## 4.1 LuaJIT Decompiler修改方案

先说清楚整体思路，不然后面那个关键修复会看不懂。

前面 3.1 已经确认过：**魔改动的只是 opcode → handler 的编号，标准 LuaJIT 的 BC_AD 指令编码（4 字节里 A/B/C/D 各字段的位置和宽度）一点没改**。也就是说，磁盘上这堆 `.luajit` 字节码，除了「第一个字节那个 op 号被换了」，其它全是标准的。

ljd 解析字节码时，是拿 `op 号` 去查它自己的一张分发表 `ljd.rawdump.code._MAP`，`_MAP[op]` 给出这条指令对应的指令类（`MOV` / `CALL` / `ADDVV` …）。标准 ljd 的 `_MAP` 是按原版 LuaJIT 编号排的，所以如果拿魔改字节码直接喂进去，那么每个 op 都将查错指令类，全盘错位。

那么一般有两条路：

- **A：改字节码** —— 把每条指令的 op 号从「魔改编号」翻译回「标准编号」，再喂给原版 ljd。要重写整个字节码流、还要处理 KGC 操作数编码，容易出错。
- **B：改 ljd 的查表** —— 字节码原样不动，只把 ljd 的 `_MAP` 重排成「魔改编号 → 标准指令类」。

我选择走 B。`_MAP` 本来就是个 `[256]` 的查找数组，重排它只是换个索引，干净得多。`decompile_modded.py` 干的核心就这一件事。

## 4.2 完整 opcode 整理

要注意，这套映射和第 3 章那两份 CSV **不是一回事**：

- 第 3 章的 `opcode_handler_map.csv` / `opcode_semantics_reviewed.csv`，`op` 列是按**原版 LuaJIT 2.1 顺序**排的（0x12=MOV、0x42=CALL、0x58=JMP 那套），它回答的是「这个 VM 的某条**内部指令**语义是不是 stock」——结论是 0x00–0x60 基本 stock、0x61–0x70 是 hotcount 扩展。这是**指令语义**层面的确认。
- 但磁盘上 `.luajit` 第一个字节用的是**另一套编号**（MOV=0x1B、CALL=0x52、JMP=0x68 那套）。「磁盘字节 → 指令语义」这张映射，分发表是推不出来的，得靠下面这两步独立还原：

**第一步，频率打底。** 写个最小的容器解析器（只走 LJBC header + 每个 proto 的 4 字节指令流，不需要懂任何 opcode 语义），把 850 个 chunk 里第一个字节做直方图。任何 Lua 程序里 JMP/MOV/CALL/TGETS 一定是高频指令——实测 `0x68` 出现 28728 次、`0x49` 出现 85441 次，先把这些高频字节圈成候选锚点。

**第二步，已知形状的小函数定锚。** 挑一个结构被唯一确定死的小 proto 来对位置。比如有个 proto 一眼就是 `return string.format("%%%02X", string.byte(arg))`，它的指令序列被强约束成：

```text
GGET  r1, "string"      ; 取全局 string
TGETS r1, r1, "format"  ; string.format
KSTR  r3, "%%%02X"
GGET  r4, "string"
TGETS r4, r4, "byte"    ; string.byte
MOV   r6, r0
CALL  r4, ...
CALLT r1, ...
```

把这段的实际字节挨个位置比对，就能一次性钉死 `GGET=0x46`、`TGETS=0x49`、`KSTR=0x3E`、`MOV=0x1B`、`CALL=0x52`、`CALLT=0x54`。再找几个含循环、含表构造的小函数补 JMP/FORI/TNEW 等，锚点滚雪球，56 项就齐了。

**第三步，验证闭环。** 把推出来的映射喂 ljd，看反编译能不能成立、sign 能不能复现。能跑通、salt 对得上，就反证这批映射是对的。

另外提一句，这套排列**不是简单平移**：比较类 0x00–0x0B 偏移为 0（原样），但常量块（KSTR 等）被挪到 0x3E 起、上值块（UGET 等）挪到 0x37 起，两块的先后顺序被对调了，不存在一个统一的 `+N`。所以只能锚点逐个定，没法靠一个公式推完。

回到 ljd。最终的映射分两批喂进去：一批就是上面方法得到的 56 项 `OPMAP`，另一批是我用 3.4 的 IDA 指纹补出来的 `complete_opmap()`（主要补算术/扩展类），加起来 82 个，sign 相关 chunk 里 0 个 unknown：

```python
# OPMAP（节选，来自 decompile_sign.pyc，stock_name -> 魔改 op）
OPMAP = {
    "MOV":0x1B, "CAT":0x32, "GGET":0x46, "GSET":0x47,
    "TGETS":0x49, "CALL":0x52, "CALLT":0x54,
    "ITERC":0x55, "ITERN":0x56, "ITERL":0x62, "LOOP":0x65, "JMP":0x68,
    # ... 共 56 项
}

# complete_opmap()（IDA 指纹补全，魔改 op -> stock_name）
extra = {
  0x14:"ISTC",0x15:"ISFC",0x18:"ISTYPE",0x19:"ISNUM",0x1A:"NOT",0x1C:"LEN",0x1D:"UNM",
  0x22:"ADDVN",0x23:"SUBVN",0x24:"MULVN",0x25:"DIVVN",0x26:"MODVN",
  0x27:"ADDNV",0x28:"SUBNV",0x29:"MULNV",0x2A:"DIVNV",0x2B:"MODNV",
  0x2C:"ADDVV",0x2D:"SUBVV",0x2E:"MULVV",0x2F:"DIVVV",0x30:"MODVV",0x31:"POW",
  0x5D:"FORI",0x5F:"FORL",0x3B:"USETP",
}
```

建表的代码本身很短，但有个**极其关键的设计**——`newmap[魔改字节]` 指向标准指令类，但这个指令类对象身上的 `.opcode` 属性，**保持原版 LuaJIT 的值不动**：

```python
def build_newmap():
    from ljd.rawdump.luajit.v2_1.luajit_opcode import _OPCODES as STD
    by_name = {instr.name: instr for op, instr in STD}   # 按指令名索引标准指令
    newmap = [None] * 256
    for name, modded in OPMAP.items():
        newmap[modded] = by_name[name]      # 魔改字节 -> 标准指令类（.opcode 仍是 stock）
    for modded, name in complete_opmap().items():
        newmap[modded] = by_name[name]
    return newmap

def install_opmap():
    import ljd
    ljd.CURRENT_VERSION = 2.1
    from ljd.rawdump.luajit.v2_1.luajit_opcode import _OPCODES as STD
    ljd.rawdump.code.init(STD)        # 先按标准表给每条指令设好 stock .opcode
    ljd.ast.builder.init()
    import ljd.pseudoasm.instructions; ljd.pseudoasm.instructions.init()
    ljd.ast.builder.handle_invalid_functions = True      # 容错：坏块不整体崩
    for mod in (ljd.ast.unwarper, ljd.ast.slotworks,
                ljd.ast.validator, ljd.ast.mutator):
        mod.catch_asserts = True
    ljd.rawdump.code._MAP = build_newmap()   # 重指向解析器查表
    _patch_ljd_robustness()                  # 见 4.3
```

为什么 `.opcode` 一定要留标准值？因为 ljd 内部除了用 `_MAP` 选指令类，**还在大量地方直接拿 `instruction.opcode` 做数值范围判断**（比如判断一条指令是不是 ITERL/FORL/ISNEXT、是不是跳转）。这两套用法必须分开：

- **「选哪个指令类」** → 用魔改字节查 `_MAP`
- **「这条指令语义上属于哪一类」** → 用指令身上的标准 `.opcode`

如果让标准 `.opcode` 也跟着变成魔改字节，第二套判断就全错了。下面 4.3 那个崩溃就是这么来的。

## 4.3 决定性修复

设计想清楚了，但 ljd 自带的 `code.read()` 偏偏违反了上面的分工。它解码每条指令时，会顺手把 `instruction.opcode` 覆盖成**当前读到的那个字节**——在魔改字节码里，这个字节就是魔改编号。

后果是灾难性的。比如 `CALL` 在这个 VM 里魔改编号是 `0x52`：`_MAP[0x52]` 确实正确给出了 `CALL` 指令类（没问题），但紧接着 `read()` 把这条 CALL 指令的 `.opcode` 也写成了 `0x52`。而标准 ljd 在 `builder.py:281` 判断「是不是迭代器循环」用的是 `0x52 <= opcode <= 0x54`（标准编号里那是 ITERL/IITERL/...）。于是这条 CALL 被误判成迭代器，走进 `_build_iterator_warp`，去访问一个 CALL 指令根本没有的字段，直接抛：

```
AttributeError: '_Instruction' object has no attribute 'B'
```

修复就是 patch 掉 `code.read`：照常用魔改字节查 `_MAP` 选指令类，但**绝不回写 `.opcode`**，让它保持 `code.init(STD)` 时设好的标准值：

```python
def _patch_ljd_robustness():
    import ljd.rawdump.code as code
    import ljd.bytecode.instructions as instructions
    import ljd.ast.builder as B

def read(parser):
        codeword = parser.stream.read_uint(4)
        opcode = codeword & 0xFF
        instruction_class = code._MAP[opcode]      # 用魔改字节选指令类
        if instruction_class is None:
            from ljd.util.log import errprint
            errprint("Warning: unknown opcode {0:08x}", opcode)
            instruction_class = instructions.UNKNW
        instruction = instruction_class()
        instruction.Bytecode = codeword
        # 关键：不要覆盖 instruction.opcode，保留 stock 值，
        # 这样 builder 里 ITERL/FORL/ISNEXT 等范围检查才正确
        code._set_instruction_operands(parser, codeword, instruction)
        return instruction
    code.read = read
```

这一步是整个反编译能跑通的决定性修改。

## 4.4 迭代器 warp 兜底

`.opcode` 修对之后，绝大多数 chunk 已经能跑了，但还有少数热路径 / JIT 形态的块，会在构建迭代器循环时撞 `_build_iterator_warp` 里的一个断言（它假定循环块倒数第二条一定是 `ITERC`/`ITERN`）。魔改 VM 把 hotcount 拆出去单独编号后（见 3.4），这个假设偶尔不成立。

补一个兜底：发现倒数第二条不是迭代器指令时，就退化成普通控制流 warp，别硬走迭代器逻辑：

```python
    _orig_iter = B._build_iterator_warp
    import ljd.bytecode.instructions as ins

def _safe_iter(state, last_addr, instrs):
        it = instrs[-2] if len(instrs) >= 2 else None
        if it is None or it.opcode not in (ins.ITERC.opcode, ins.ITERN.opcode):
            return B._build_flow_warp(state, last_addr, instrs[-1])   # 退化成普通流
        return _orig_iter(state, last_addr, instrs)
    B._build_iterator_warp = _safe_iter
```

注意这里 `it.opcode` 比的也是**标准 opcode**——又一次印证 4.2 那个设计：内部判断一律走标准 opcode。

## 4.5 容错 + AST 还原流程

`install_opmap()` 里那几个 `handle_invalid_functions=True` / `catch_asserts=True` 是配套的容错开关：单个块或单个 pass 出问题时，吞掉异常、尽量产出能看的结果，而不是让整个 proto 崩掉。

每个 proto 走的是 ljd 标准那套 AST pipeline，只是每步都套了容错：

```python
def decompile_proto(header, proto):
    ast = ljd.ast.builder.build(header, proto)       # 字节码 -> 原始 AST + warp
    ljd.ast.validator.validate(ast, warped=True)
    ljd.ast.mutator.pre_pass(ast)
    ljd.ast.locals.mark_locals(ast)
    try:
        ljd.ast.slotworks.eliminate_temporary(ast, identify_slots=True)  # 消临时 slot
    except AssertionError:
        print("  [warn] eliminate_temporary assert")
    ljd.ast.unwarper.unwarp(ast, False)              # warp -> 真正的 if/for/while
    ljd.ast.locals.mark_local_definitions(ast)
    ljd.ast.mutator.primary_pass(ast)
    ljd.ast.locals.mark_locals(ast, alt_mode=True)
    return ast
```

`slotworks`（消临时变量）和 `unwarper`（把控制流 warp 还原成 `if/for/while`）这两步噪声最大——后面第 6 节 sign 翻车，根子就在 `slotworks` 对 slot 的复用/重命名上。

## 4.6 批量结果

```bash
python scripts/decompile_modded.py --batch out/lua_dump_verified out/lua_decompiled_all
```

850 个 `.luajit`，反编译成功 **845** 个。

# 5.sign 静态分析

在还原出来的 Lua 里搜 `sign`，搜出三套独立的签名体系：

| 体系           | 位置                             | 算法                                                |
| -------------- | -------------------------------- | --------------------------------------------------- |
| HTTP API（主） | 00017 `sign4Url` / `signHttpUrl` | HMAC-SHA1，query 按 key 升序                        |
| 旧版 URL       | 00017 `signUrl850luaEx`          | SHA1(ts + 参数 + ts + 固定盐 `Mi2935uiPPnw#2dbY32`) |
| PHP 接口       | 00824 `sign4PhpUrl`              | MD5(sortedQuery + `&key=` + PHP_SIGN_KEY)           |

主目标是第一套 HTTP API。反编译出来的 `sign4Url` 长这样：

顺手确认了一下 `sha1` 模块（chunk 00079），就是标准的 sha.lua（kikito 版本），`sha1.hmac` 是标准 HMAC-SHA1，输出小写 hex。

到这步看起来公式都有了，结构也清楚，应该能算了。结果——

# 6.翻车：离线怎么都算不对

拿真实抓包样本套公式，本地复算 sign，**全错**。

我把能想到的组合全穷举了一遍：素材里那个 `slot1` 到底是请求类型、还是 appid、还是 POST/GET、还是 timestamp、还是 nonce，× 参数子集、× 分隔符、× 要不要 urlencode、× 两个候选密钥……几千种组合，一个都没中。

冷静分析，原因有两个，而且都是反编译的 slot 复用噪声坑的：

- **误判一**：`slot1`（素材第 1、3 段）我一直当成「请求类型」，其实是 **timestamp**。
- **误判二**：素材第 5 段那个 `uv2`，反编译里看着像 appid，其实是 **version**。

这俩 upvalue 在 ljd 还原之后编号根本不可靠，跨函数的 slot 也被复用重命名了。**靠纯静态阅读去猜 HMAC 素材的精确拼接，自由度太大，根本收敛不了。** 所以这种我放弃硬猜，直接frida上动态。

# 7.动态 hook 抓真实素材

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

## 7.1 找对位置：lj_str_new

这里换个思路：Lua 里只要 `..` 拼出一个新字符串，它最终一定会经过 LuaJIT 的字符串 intern 函数被驻留下来。顺着 `lua_pushlstring`（`0xbd51f8`）反编译，找到它调用的 `sub_BCB83C`，这个就是 `lj_str_new(L, str, len)`，地址 `child+0xBCB83C`。

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

```js
// hook_strnew.js：按长度先过滤，再看关键串
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('zSWY1et3') < 0 && !/[a-z_]+=[^|&]+/.test(s)) return;
    log(s);                                       // 命中的就是真实 HMAC 素材
  }
});
```

frida输出：

![image-20260614044803638](upload/attach/202606/985355_HNC9WQ8X8DJUTDR.png)

## 7.2 结果

frida启用游戏，`lj_str_new` 命中，抓到 `/api/customerService/live800/` 这个接口的真实 HMAC 输入：

```
1781189206|accountId=27342955&appid=0009&deviceId=102200002&machine=0a98...&nonce=96062&timestamp=1781189206&verify_rnd_str=361535409-...&verify_str=1c4d...&version=2024326|1781189206|zSWY1et3fPeY9PfY#^pvg5tBGzSjZRi2|2024326|/api/customerService/live800/
```

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

# 8.还原公式并验证

真实素材一摆出来，6 段结构一目了然：

```python
sign = lower( HMAC_SHA1( HMAC_KEY, material ) )
material = f"{timestamp}|{QUERY}|{timestamp}|{HMAC_KEY}|{version}|{urlpath}"
```

各字段：

| 字段      | 取值 / 说明                                                  |
| --------- | ------------------------------------------------------------ |
| timestamp | body 里的 timestamp（第 1、3 段重复出现）                    |
| QUERY     | body 去掉 sign 后所有字段，按 key 升序 `k=v&…` 拼，**不做 urlencode** |
| HMAC_KEY  | `zSWY1et3fPeY9PfY#^pvg5tBGzSjZRi2`（同时也明文拼进第 4 段）  |
| version   | `2024326`（第 5 段，**不是 appid**，之前就栽在这）           |
| urlpath   | 去掉 host 前缀的请求路径，如 `/api/customerService/live800/` |

密钥的来源也清楚了：`res/cocos/btn_jian.png` / `btn_close3.png` 这俩图片里做了隐写，读出来按 `"||"` 拆，得到 `appid ‖ HMAC_KEY ‖ RC4_KEY ‖ version` 四元组。换 build / 换 appid 的时候，只要把这四元组换掉就行，这个 HMAC_KEY 在同一个 build 里跨会话是稳定的，不是热更下发的。

拿一个完整解密包（`POST /api/customerService/live800/`，包里 sign 是 `fe1445de…`）代进去验：

```
computed: fe1445dec709a415a2fd9db36ea2ba582aa562da
expected: fe1445dec709a415a2fd9db36ea2ba582aa562da
MATCH: True
```

字节级对上了，sign 到此彻底还原。生成器我写成了 `sign_generator.py`，提供 `compute_sign(body, urlpath)` 和 `verify_sign(...)`，过了回归测试，后面做接口直接调就行：

```python
import hmac
import hashlib

# appid 0009 build 的密钥，从 btn_jian.png / btn_close3.png 隐写里 "||" 拆出来的
HMAC_KEY = "zSWY1et3fPeY9PfY#^pvg5tBGzSjZRi2"

def build_query(body: dict) -> str:
    """去掉 sign 后所有字段，按 key 升序拼 k=v&...，不做 urlencode"""
    return "&".join(f"{k}={body[k]}" for k in sorted(body) if k != "sign")

def compute_sign(body: dict, urlpath: str, hmac_key: str = HMAC_KEY) -> str:
    ts = str(body["timestamp"])
    ver = str(body["version"])
    query = build_query(body)
    # 6 段：timestamp | query | timestamp | KEY | version | urlpath
    material = f"{ts}|{query}|{ts}|{hmac_key}|{ver}|{urlpath}"
    return hmac.new(hmac_key.encode(), material.encode(), hashlib.sha1).hexdigest().lower()

def verify_sign(body: dict, urlpath: str, hmac_key: str = HMAC_KEY) -> bool:
    expected = body.get("sign", "").lower()
    return bool(expected) and compute_sign(body, urlpath, hmac_key) == expected
```

顺带提一句密钥的兜底逻辑：反编译里 `signHttpUrl`（chunk 00017）有个分支，内网测试服走的是硬编码 `appid=0000`、`HMAC_KEY="US$47Zzl$zVwkXB4h%HEOyJecqrpIx6X"`、`version=2024326`；正式包才走 png 隐写拆出来的那套。

# 9.小结

整条链路串下来：

1. 四层壳脱掉（前两层离线算法脱，第三层 hook linker dump 子 so 重建 ELF）
2. 在 IDA 里逆出魔改 LuaJIT 的 opcode → handler 映射（交叉验证）
3. 把映射注入 ljd，批量反编译 845/850 个 Lua（关键是别覆盖 stock opcode）
4. RC4 流量解密验证（24/24 字节级）
5. sign 静态分析定位到 `sign4Url`，但纯静态猜素材失败
6. hook `lj_str_new` 抓到真实 HMAC 素材，还原 6 段公式
7. 对真实包字节级复现，`MATCH: True`

> 本文仅用于安全研究与学习交流，相关样本来自授权分析，请勿用于任何非法用途。

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

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

收藏・34

点赞・259

打赏

赞赏记录

参与人

雪币

留言

时间

深沉

为你点赞！

2026-10-3 21:32

git_99440qimingminimax

为你点赞！

2026-9-23 11:40

mb_ajghhdbh

为你点赞！

2026-9-16 11:33

mb_dvqqrcce

为你点赞！

2026-9-11 17:23

mb_njkgqdad

为你点赞！

2026-9-9 17:28

晨曦。

为你点赞！

2026-9-9 07:27

张楚岚.

为你点赞！

2026-9-8 14:02

铭信

你的帖子非常有用，感谢分享！

2026-9-7 22:03

过我眼即我有

感谢你的积极参与，期待更多精彩内容！

2026-9-4 21:43

mb_qsgdgzbi

你的分享对大家帮助很大，非常感谢！

2026-8-28 01:59

Kazusa

感谢你分享这么好的资源！

2026-8-25 15:35

er胡

为你点赞！

2026-8-24 11:06

一叶梦花

为你点赞！

2026-8-24 10:53

git_46690chenlinux1

你的分享对大家帮助很大，非常感谢！

2026-8-22 20:27

mb_lthgjpwj

为你点赞！

2026-8-20 16:46

mb_vnizsrrg

为你点赞！

2026-8-20 12:52

橘喵Cat

为你点赞！

2026-8-19 14:50

wx_Mark_449

为你点赞！

2026-8-18 18:52

zhengcai

你的帖子非常有用，感谢分享！

2026-8-18 13:20

mb_iopmtttw

非常支持你的观点！

2026-8-12 09:05

mb_lecmckno

非常支持你的观点！

2026-8-11 10:35

0xThawne

谢谢你的细致分析，受益匪浅！

2026-8-11 10:09

mb_ljkqvpxg

这个讨论对我很有帮助，谢谢！

2026-8-10 23:45

mb_wsoacceo

为你点赞！

2026-8-7 23:14

FinSectech

这个讨论对我很有帮助，谢谢！

2026-8-6 09:09

Wika

非常支持你的观点！

2026-7-31 15:02

Am1re

期待更多优质内容的分享，论坛有你更精彩！

2026-7-30 17:24

hexdump

感谢你的贡献，论坛因你而更加精彩！

2026-7-30 11:16

iCookiie

谢谢你的细致分析，受益匪浅！

2026-7-27 16:57

Ppty

为你点赞！

2026-7-25 13:44

wx_RT

非常支持你的观点！

2026-7-23 22:03

青蓝梦

期待更多优质内容的分享，论坛有你更精彩！

2026-7-23 11:08

学会规则

为你点赞！

2026-7-22 18:29

yuanyouran

感谢你的贡献，论坛因你而更加精彩！

2026-7-22 10:28

微启宇

非常支持你的观点！

2026-7-22 03:35

0xCCCC

为你点赞！

2026-7-22 01:03

git_89565rockfox0

你的帖子非常有用，感谢分享！

2026-7-21 03:25

mb_bpzyeyaf

感谢你的积极参与，期待更多精彩内容！

2026-7-19 18:49

哈哥

感谢你分享这么好的资源！

2026-7-17 11:10

mb_vkeacyrq

期待更多优质内容的分享，论坛有你更精彩！

2026-7-16 22:02

wx_晨梦

这个讨论对我很有帮助，谢谢！

2026-7-16 06:07

afishlong

为你点赞！

2026-7-13 22:47

mb_koixqizd

谢谢你的细致分析，受益匪浅！

2026-7-13 17:02

mb_hsscwjpz

为你点赞！

2026-7-10 11:34

nekomiao

感谢你分享这么好的资源！

2026-7-9 09:58

xxxmm

你的分享对大家帮助很大，非常感谢！

2026-7-8 23:13

mb_kamhgqsu

这个讨论对我很有帮助，谢谢！

2026-7-8 17:49

mb_rveckyle

为你点赞！

2026-7-8 10:15

chenzhouch

这个讨论对我很有帮助，谢谢！

2026-7-7 21:54

mb_wyefudor

你的分享对大家帮助很大，非常感谢！

2026-7-7 14:17

上网鱼

你的分享对大家帮助很大，非常感谢！

2026-7-6 15:18

不吃牛肉

你的分享对大家帮助很大，非常感谢！

2026-7-6 11:36

MioMio

为你点赞！

2026-7-5 21:48

P_Hac

谢谢你的细致分析，受益匪浅！

2026-7-4 00:42

mb_dbpeontu

感谢你的积极参与，期待更多精彩内容！

2026-7-3 09:01

C0D1

期待更多优质内容的分享，论坛有你更精彩！

2026-7-2 19:31

哦哈哈哈哈

感谢你分享这么好的资源！

2026-7-2 14:50

零_721409

谢谢你的细致分析，受益匪浅！

2026-7-2 14:47

mb_reyfinlv

非常支持你的观点！

2026-7-2 09:28

寻影星尘

期待更多优质内容的分享，论坛有你更精彩！

2026-7-1 17:02

智童

你的分享对大家帮助很大，非常感谢！

2026-7-1 01:31

mb_rxyqtaqw

你的分享对大家帮助很大，非常感谢！

2026-6-30 22:19

新新新新新

这个讨论对我很有帮助，谢谢！

2026-6-30 18:35

wx_公过水蚊

感谢你分享这么好的资源！

2026-6-30 16:39

周游列国

谢谢你的细致分析，受益匪浅！

2026-6-30 14:28

hacker521

谢谢你的细致分析，受益匪浅！

2026-6-30 10:46

深山樵夫

感谢你的积极参与，期待更多精彩内容！

2026-6-30 10:16

sbmatch

感谢你的积极参与，期待更多精彩内容！

2026-6-29 21:23

konf

为你点赞！

2026-6-29 18:06

mb_zfqvurgb

你的帖子非常有用，感谢分享！

2026-6-29 16:05

柳如烟

谢谢你的细致分析，受益匪浅！

2026-6-29 11:52

Marklice

这个讨论对我很有帮助，谢谢！

2026-6-27 23:09

无事不觉

谢谢你的细致分析，受益匪浅！

2026-6-27 19:06

wx_Chrome

为你点赞！

2026-6-27 11:16

ldljlzw

谢谢你的细致分析，受益匪浅！

2026-6-26 16:16

mb_mrjjcxgk

非常支持你的观点！

2026-6-26 14:32

mb_octmtxjv

你的帖子非常有用，感谢分享！

2026-6-26 11:31

mb_miylylso

感谢你的积极参与，期待更多精彩内容！

2026-6-26 11:06

beichen哭

感谢你分享这么好的资源！

2026-6-26 00:51

mb_iyljezfv

感谢你的积极参与，期待更多精彩内容！

2026-6-25 16:40

AlexNine

你的分享对大家帮助很大，非常感谢！

2026-6-25 15:28

mb_pfsyglzv

这个讨论对我很有帮助，谢谢！

2026-6-25 11:30

vox

这个讨论对我很有帮助，谢谢！

2026-6-25 09:24

archer21

为你点赞！

2026-6-24 23:23

chiikawa_gui

感谢你分享这么好的资源！

2026-6-24 15:22

KRIGERNM1G

为你点赞！

2026-6-24 11:23

btmanbtman

非常支持你的观点！

2026-6-24 09:52

ooww

期待更多优质内容的分享，论坛有你更精彩！

2026-6-24 03:34

PPTV

谢谢你的细致分析，受益匪浅！

2026-6-23 19:14

不吃番茄

感谢你分享这么好的资源！

2026-6-23 17:21

DaiXiaoHuer

非常支持你的观点！

2026-6-23 16:42

like希望

为你点赞！

2026-6-23 16:09

FuWenDen

谢谢你的细致分析，受益匪浅！

2026-6-23 14:30

小李08

感谢你的积极参与，期待更多精彩内容！

2026-6-23 14:27

mb_yiwwkcyb

期待更多优质内容的分享，论坛有你更精彩！

2026-6-23 10:32

mb_dpoxqwob

感谢你的积极参与，期待更多精彩内容！

2026-6-23 01:38

可以撩你吗

你的帖子非常有用，感谢分享！

2026-6-22 22:53

17340307464

感谢你分享这么好的资源！

2026-6-22 20:27

gtict

感谢你分享这么好的资源！

2026-6-22 19:35

Sigil

感谢你分享这么好的资源！

2026-6-22 18:00

mb_lclavsay

期待更多优质内容的分享，论坛有你更精彩！

2026-6-22 17:21

mb_ecoknywz

感谢你的积极参与，期待更多精彩内容！

2026-6-22 16:37

mb_txiypfiy

谢谢你的细致分析，受益匪浅！

2026-6-22 14:47

git_56402Syy040316

感谢你的贡献，论坛因你而更加精彩！

2026-6-22 14:02

yhock

为你点赞！

2026-6-22 11:39

34324

为你点赞！

2026-6-22 11:14

AEVE

期待更多优质内容的分享，论坛有你更精彩！

2026-6-22 10:34

財財

感谢你的贡献，论坛因你而更加精彩！

2026-6-22 00:34

mb_eesbzjvy

期待更多优质内容的分享，论坛有你更精彩！

2026-6-21 23:45

mb_bppcorlj

为你点赞！

2026-6-21 14:25

mb_bogoqnvg

感谢你分享这么好的资源！

2026-6-21 13:00

Halashao

感谢你分享这么好的资源！

2026-6-21 12:44

ookyo

你的分享对大家帮助很大，非常感谢！

2026-6-21 12:18

bluegatar

你的帖子非常有用，感谢分享！

2026-6-20 22:30

maxwudi

谢谢你的细致分析，受益匪浅！

2026-6-20 22:10

mb_sotuhfro

你的分享对大家帮助很大，非常感谢！

2026-6-20 10:14

mb_lhiuzpig

你的帖子非常有用，感谢分享！

2026-6-19 22:09

Harpe

为你点赞！

2026-6-19 18:59

zhongdong

为你点赞！

2026-6-18 17:56

漫雾.

感谢你分享这么好的资源！

2026-6-18 17:30

Jackuu

为你点赞！

2026-6-18 16:47

周鸿恩

这个讨论对我很有帮助，谢谢！

2026-6-18 15:57

hearwater

感谢你的贡献，论坛因你而更加精彩！

2026-6-18 11:28

只会逆一点点

期待更多优质内容的分享，论坛有你更精彩！

2026-6-18 10:43

酋knave

你的帖子非常有用，感谢分享！

2026-6-18 09:59

starscc

为你点赞！

2026-6-18 01:09

Ally Switch

谢谢你的细致分析，受益匪浅！

2026-6-17 18:25

bnd

你的帖子非常有用，感谢分享！

2026-6-17 18:08

mb_thmdyxrm

为你点赞！

2026-6-17 16:29

F0xm1ao

感谢你的积极参与，期待更多精彩内容！

2026-6-17 16:26

mb_moqpmvtv

感谢你分享这么好的资源！

2026-6-17 16:25

lovezeng

为你点赞！

2026-6-17 15:39

0x指纹

期待更多优质内容的分享，论坛有你更精彩！

2026-6-17 15:25

mb_dzntuqwg

你的分享对大家帮助很大，非常感谢！

2026-6-17 15:24

Vn小帆

为你点赞！

2026-6-17 15:22

New对象处

为你点赞！

2026-6-17 15:00

Jiyeon2

为你点赞！

2026-6-17 11:53

wx_让我来，蟹蟹

为你点赞！

2026-6-17 11:17

mb_cebxltxx

为你点赞！

2026-6-17 11:07

mb_audxeeaj

为你点赞！

2026-6-17 11:01

老小白

感谢你分享这么好的资源！

2026-6-17 09:49

__weil

谢谢你的细致分析，受益匪浅！

2026-6-17 08:47

鐵憨憨

感谢你的贡献，论坛因你而更加精彩！

2026-6-17 04:16

clz3216

谢谢你的细致分析，受益匪浅！

2026-6-16 21:18

墨儒蛮君

你的帖子非常有用，感谢分享！

2026-6-16 21:11

MGo

你的分享对大家帮助很大，非常感谢！

2026-6-16 20:54

houjingyi

你的帖子非常有用，感谢分享！

2026-6-16 20:17

mb_hzfcelhs

谢谢你的细致分析，受益匪浅！

2026-6-16 18:50

曹无咎

你的分享对大家帮助很大，非常感谢！

2026-6-16 18:17

mb_lhgqlaaa

谢谢你的细致分析，受益匪浅！

2026-6-16 16:56

gailium

为你点赞！

2026-6-16 16:45

mb_vnjlezpl

你的分享对大家帮助很大，非常感谢！

2026-6-16 16:38

happyasr

感谢你的积极参与，期待更多精彩内容！

2026-6-16 16:01

mb_kgfqphsx

谢谢你的细致分析，受益匪浅！

2026-6-16 15:14

andy张刘

感谢你的贡献，论坛因你而更加精彩！

2026-6-16 14:53

wpwpahj

你的帖子非常有用，感谢分享！

2026-6-16 14:36

she.

感谢你的贡献，论坛因你而更加精彩！

2026-6-16 12:38

git_43837featherL

感谢你的贡献，论坛因你而更加精彩！

2026-6-16 10:55

saykao

你的分享对大家帮助很大，非常感谢！

2026-6-16 10:37

天流

非常支持你的观点！

2026-6-16 10:30

mb_dqqyuxaq

非常支持你的观点！

2026-6-16 08:46

wx_1_659

期待更多优质内容的分享，论坛有你更精彩！

2026-6-16 02:53

wx_A哦

感谢你的贡献，论坛因你而更加精彩！

2026-6-16 02:12

RedSand07

谢谢你的细致分析，受益匪浅！

2026-6-16 01:29

hx九七

为你点赞！

2026-6-16 01:27

孤独的街

感谢你分享这么好的资源！

2026-6-15 23:16

小柯南

谢谢你的细致分析，受益匪浅！

2026-6-15 23:15

神堂

你的帖子非常有用，感谢分享！

2026-6-15 22:40

mb_fxmqgqkh

你的帖子非常有用，感谢分享！

2026-6-15 22:34

ddwwtom

感谢你的贡献，论坛因你而更加精彩！

2026-6-15 22:13

wx_张三_488

感谢你的积极参与，期待更多精彩内容！

2026-6-15 21:48

the_hs

你的帖子非常有用，感谢分享！

2026-6-15 21:18

定清先生

非常支持你的观点！

2026-6-15 20:47

mb_fefksfsl

你的帖子非常有用，感谢分享！

2026-6-15 20:15

兔子先生_168490

期待更多优质内容的分享，论坛有你更精彩！

2026-6-15 19:30

wx_byte

这个讨论对我很有帮助，谢谢！

2026-6-15 19:14

哆啦噩梦

你的帖子非常有用，感谢分享！

2026-6-15 18:38

_0xA1pha

非常支持你的观点！

2026-6-15 18:19

目露不羁

谢谢你的细致分析，受益匪浅！

2026-6-15 18:02

mb_uxncovua

为你点赞！

2026-6-15 17:28

Hutt0n0

谢谢你的细致分析，受益匪浅！

2026-6-15 17:20

wx_funcrever

非常支持你的观点！

2026-6-15 16:50

cydian

你的帖子非常有用，感谢分享！

2026-6-15 16:43

醉染

谢谢你的细致分析，受益匪浅！

2026-6-15 16:32

Mrack

感谢你分享这么好的资源！

2026-6-15 16:17

Valdoivre

期待更多优质内容的分享，论坛有你更精彩！

2026-6-15 16:15

dofla

谢谢你的细致分析，受益匪浅！

2026-6-15 16:13

ngiokweng

为你点赞！

2026-6-15 16:02

wx_0.0_522

为你点赞！

2026-6-15 15:54

mb_iesvmzqc

感谢你分享这么好的资源！

2026-6-15 15:39

mb_tvuiswau

为你点赞！

2026-6-15 15:32

rettozero

感谢你分享这么好的资源！

2026-6-15 15:21

mb_hbwwutcn

你的帖子非常有用，感谢分享！

2026-6-15 15:09

巷口的那只猫

你的分享对大家帮助很大，非常感谢！

2026-6-15 15:04

Dy1an

感谢你的贡献，论坛因你而更加精彩！

2026-6-15 15:04

Ms135

感谢你的贡献，论坛因你而更加精彩！

2026-6-15 14:51

wx_浓情淡如你

期待更多优质内容的分享，论坛有你更精彩！

2026-6-15 14:14

mb_liueenqt

非常支持你的观点！

2026-6-15 14:10

qqizai

感谢你的积极参与，期待更多精彩内容！

2026-6-15 14:03

fogSea

这个讨论对我很有帮助，谢谢！

2026-6-15 13:53

A冷忆

期待更多优质内容的分享，论坛有你更精彩！

2026-6-15 13:39

逆向小玖

非常支持你的观点！

2026-6-15 13:30

lingyi223

非常支持你的观点！

2026-6-15 13:28

Mengz3

你的分享对大家帮助很大，非常感谢！

2026-6-15 13:24

风兮木晓

感谢你的贡献，论坛因你而更加精彩！

2026-6-15 13:16

Yangser

你的帖子非常有用，感谢分享！

2026-6-15 13:14

北袅

期待更多优质内容的分享，论坛有你更精彩！

2026-6-15 13:03

KimoHex

非常支持你的观点！

2026-6-15 11:43

StriveMario

这个讨论对我很有帮助，谢谢！

2026-6-15 11:33

wx_五角星

非常支持你的观点！

2026-6-15 11:23

Yu4n

期待更多优质内容的分享，论坛有你更精彩！

2026-6-15 10:57

asd

感谢你的积极参与，期待更多精彩内容！

2026-6-15 10:57

shutterbug

为你点赞！

2026-6-15 10:47

bfloat16

谢谢你的细致分析，受益匪浅！

2026-6-15 10:37

mb_hhiypuwp

期待更多优质内容的分享，论坛有你更精彩！

2026-6-15 10:35

x0rrrrr

感谢你的积极参与，期待更多精彩内容！

2026-6-15 10:25

fei3ei

感谢你的积极参与，期待更多精彩内容！

2026-6-15 10:19

岁月。

感谢你的积极参与，期待更多精彩内容！

2026-6-15 10:09

wx_官

为你点赞！

2026-6-15 10:06

CCC_

谢谢你的细致分析，受益匪浅！

2026-6-15 10:03

jjjo

这个讨论对我很有帮助，谢谢！

2026-6-15 09:52

下雨天sana

谢谢你的细致分析，受益匪浅！

2026-6-15 09:48

wx_ㅤ_683

为你点赞！

2026-6-15 09:17

Hawcett

为你点赞！

2026-6-15 09:05

ONewTach

这个讨论对我很有帮助，谢谢！

2026-6-15 08:59

wx_Xuanli

你的帖子非常有用，感谢分享！

2026-6-15 08:54

优质胖虎

感谢你的贡献，论坛因你而更加精彩！

2026-6-15 08:46

头头dear

你的分享对大家帮助很大，非常感谢！

2026-6-15 07:46

oilm4n

这个讨论对我很有帮助，谢谢！

2026-6-15 06:22

kagayaki

期待更多优质内容的分享，论坛有你更精彩！

2026-6-15 05:47

npc0vo

这个讨论对我很有帮助，谢谢！

2026-6-15 03:48

lihaiyanz

为你点赞！

2026-6-15 00:24

mb_gcropjzi

为你点赞！

2026-6-15 00:14

samshine

这个讨论对我很有帮助，谢谢！

2026-6-14 23:50

mb_ghcouuzx

非常支持你的观点！

2026-6-14 23:46

fu11p7r

谢谢你的细致分析，受益匪浅！

2026-6-14 23:29

mb_bvvcoitr

感谢你的积极参与，期待更多精彩内容！

2026-6-14 23:07

伟叔叔

为你点赞！

2026-6-14 22:11

清风jw

感谢你的贡献，论坛因你而更加精彩！

2026-6-14 21:48

王叔叔

你的分享对大家帮助很大，非常感谢！

2026-6-14 21:32

Dr_Knox

你的帖子非常有用，感谢分享！

2026-6-14 21:00

梧桐生

期待更多优质内容的分享，论坛有你更精彩！

2026-6-14 20:46

fyrlove

感谢你分享这么好的资源！

2026-6-14 20:27

mb_rjdrqvpa

感谢你的积极参与，期待更多精彩内容！

2026-6-14 20:14

mb_asiwnxyv

谢谢你的细致分析，受益匪浅！

2026-6-14 20:07

lialong

感谢你分享这么好的资源！

2026-6-14 19:50

mb_fsoesckx

你的帖子非常有用，感谢分享！

2026-6-14 19:10

UserXCh

为你点赞！

2026-6-14 18:56

欲拭泪

非常支持你的观点！

2026-6-14 18:56

顽劣

期待更多优质内容的分享，论坛有你更精彩！

2026-6-14 16:39

huangyalei

为你点赞！

2026-6-14 16:11

我的小拇指啊

非常支持你的观点！

2026-6-14 15:37

doduhuang

为你点赞！

2026-6-14 15:32

sinker_

谢谢你的细致分析，受益匪浅！

2026-6-14 15:17

mb_cfjwplfo

感谢你的积极参与，期待更多精彩内容！

2026-6-14 15:01

墨穹呢

感谢你的积极参与，期待更多精彩内容！

2026-6-14 14:34

pexillove

感谢你分享这么好的资源！

2026-6-14 14:32

.KK

期待更多优质内容的分享，论坛有你更精彩！

2026-6-14 14:10

cyberp99

期待更多优质内容的分享，论坛有你更精彩！

2026-6-14 13:47

最新回复 (165) 1 2 3 4 5 6 7 ▶
墨穹呢雪币： 4770 活跃值： (8232) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 231 粉丝 18 关注私信	墨穹呢 2 楼感谢分享 2026-6-14 14:35 0
熊猫吃鱼雪币： 2040 活跃值： (4596) 能力值： ( LV3，RANK：20 ) 在线值：发帖 48 回帖 230 粉丝 50 关注私信	熊猫吃鱼 3 楼 66666 2026-6-14 15:28 0
FMNS 雪币： 9 活跃值： (2036) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 124 粉丝 1 关注私信	FMNS 4 楼前排 2026-6-14 16:03 0
Ruinv6 雪币： 177 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 53 粉丝 1 关注私信	Ruinv6 5 楼 6666 2026-6-14 16:25 0
mb_elqwyvnm 雪币： 2742 活跃值： (3475) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 170 粉丝 0 关注私信	mb_elqwyvnm 6 楼学习新思想争做新青年 2026-6-14 20:55 0
MaYil 雪币： 9446 活跃值： (8072) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 485 粉丝 2 关注私信	MaYil 7 楼感谢分享 2026-6-14 21:29 0
Zepp7289 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 147 粉丝 0 关注私信	Zepp7289 8 楼 tql 2026-6-14 21:50 0
mb_cuhnoneh 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 3 粉丝 0 关注私信	mb_cuhnoneh 9 楼 1111看看 2026-6-14 22:48 0
mb_xnairofv 雪币： 205 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 9 粉丝 0 关注私信	mb_xnairofv 10 楼 1111111111111111 2026-6-14 23:57 0
GEKEZYX 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 157 粉丝 0 关注私信	GEKEZYX 11 楼 666 2026-6-15 00:18 0
mb_ntpqnzrm 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	mb_ntpqnzrm 12 楼 66 2026-6-15 02:36 0
mb_eizetlni 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 47 粉丝 1 关注私信	mb_eizetlni 13 楼 666 2026-6-15 06:27 0
wx_Huber Barrientos 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 216 粉丝 1 关注私信	wx_Huber Barrientos 14 楼 666 2026-6-15 06:35 0
mb_qimctavn 雪币： 5327 活跃值： (6780) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 401 粉丝 1 关注私信	mb_qimctavn 15 楼 6 2026-6-15 07:14 0
风子雪币： 1320 活跃值： (1413) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 23 粉丝 1 关注私信	风子 16 楼 666 2026-6-15 07:43 0
Catmeow 雪币： 481 活跃值： (1270) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 51 粉丝 2 关注私信	Catmeow 17 楼 tql 2026-6-15 08:50 0
冷瞳雪币： 0 活跃值： (1608) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 75 粉丝 1 关注私信	冷瞳 18 楼 666 2026-6-15 09:34 0
mb_wdhsjycl 雪币： 208 活跃值： (2461) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	mb_wdhsjycl 19 楼 666 2026-6-15 09:44 0
guijingwen 雪币： 7377 活跃值： (7605) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 312 粉丝 0 关注私信	guijingwen 20 楼 66 2026-6-15 10:21 0
mb_zsizdcrb 雪币： 214 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 0 关注私信	mb_zsizdcrb 21 楼不明觉厉 2026-6-15 10:53 0
lixianhuei 雪币： 1748 活跃值： (2425) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 139 粉丝 0 关注私信	lixianhuei 22 楼 666 2026-6-15 11:29 0
LoginUser 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 48 粉丝 0 关注私信	LoginUser 23 楼感谢分享 2026-6-15 13:46 0
dayday向上8 雪币： 3118 活跃值： (4930) 能力值： ( LV8，RANK：120 ) 在线值：发帖 9 回帖 73 粉丝 21 关注私信	dayday向上8 2 24 楼 66 2026-6-15 14:16 0
xingbing 雪币： 158 活跃值： (5791) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1400 粉丝 2 关注私信	xingbing 25 楼感谢分享 2026-6-15 14:59 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

Aar0n

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (165) 1 2 3 4 5 6 7 ▶
墨穹呢雪币： 4770 活跃值： (8232) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 231 粉丝 18 关注私信	墨穹呢 2 楼感谢分享 2026-6-14 14:35 0
熊猫吃鱼雪币： 2040 活跃值： (4596) 能力值： ( LV3，RANK：20 ) 在线值：发帖 48 回帖 230 粉丝 50 关注私信	熊猫吃鱼 3 楼 66666 2026-6-14 15:28 0
FMNS 雪币： 9 活跃值： (2036) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 124 粉丝 1 关注私信	FMNS 4 楼前排 2026-6-14 16:03 0
Ruinv6 雪币： 177 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 53 粉丝 1 关注私信	Ruinv6 5 楼 6666 2026-6-14 16:25 0
mb_elqwyvnm 雪币： 2742 活跃值： (3475) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 170 粉丝 0 关注私信	mb_elqwyvnm 6 楼学习新思想争做新青年 2026-6-14 20:55 0
MaYil 雪币： 9446 活跃值： (8072) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 485 粉丝 2 关注私信	MaYil 7 楼感谢分享 2026-6-14 21:29 0
Zepp7289 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 147 粉丝 0 关注私信	Zepp7289 8 楼 tql 2026-6-14 21:50 0
mb_cuhnoneh 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 3 粉丝 0 关注私信	mb_cuhnoneh 9 楼 1111看看 2026-6-14 22:48 0
mb_xnairofv 雪币： 205 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 9 粉丝 0 关注私信	mb_xnairofv 10 楼 1111111111111111 2026-6-14 23:57 0
GEKEZYX 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 157 粉丝 0 关注私信	GEKEZYX 11 楼 666 2026-6-15 00:18 0
mb_ntpqnzrm 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	mb_ntpqnzrm 12 楼 66 2026-6-15 02:36 0
mb_eizetlni 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 47 粉丝 1 关注私信	mb_eizetlni 13 楼 666 2026-6-15 06:27 0
wx_Huber Barrientos 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 216 粉丝 1 关注私信	wx_Huber Barrientos 14 楼 666 2026-6-15 06:35 0
mb_qimctavn 雪币： 5327 活跃值： (6780) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 401 粉丝 1 关注私信	mb_qimctavn 15 楼 6 2026-6-15 07:14 0
风子雪币： 1320 活跃值： (1413) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 23 粉丝 1 关注私信	风子 16 楼 666 2026-6-15 07:43 0
Catmeow 雪币： 481 活跃值： (1270) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 51 粉丝 2 关注私信	Catmeow 17 楼 tql 2026-6-15 08:50 0
冷瞳雪币： 0 活跃值： (1608) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 75 粉丝 1 关注私信	冷瞳 18 楼 666 2026-6-15 09:34 0
mb_wdhsjycl 雪币： 208 活跃值： (2461) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	mb_wdhsjycl 19 楼 666 2026-6-15 09:44 0
guijingwen 雪币： 7377 活跃值： (7605) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 312 粉丝 0 关注私信	guijingwen 20 楼 66 2026-6-15 10:21 0
mb_zsizdcrb 雪币： 214 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 0 关注私信	mb_zsizdcrb 21 楼不明觉厉 2026-6-15 10:53 0
lixianhuei 雪币： 1748 活跃值： (2425) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 139 粉丝 0 关注私信	lixianhuei 22 楼 666 2026-6-15 11:29 0
LoginUser 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 48 粉丝 0 关注私信	LoginUser 23 楼感谢分享 2026-6-15 13:46 0
dayday向上8 雪币： 3118 活跃值： (4930) 能力值： ( LV8，RANK：120 ) 在线值：发帖 9 回帖 73 粉丝 21 关注私信	dayday向上8 2 24 楼 66 2026-6-15 14:16 0
xingbing 雪币： 158 活跃值： (5791) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1400 粉丝 2 关注私信	xingbing 25 楼感谢分享 2026-6-15 14:59 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复