[原创] 某 App 抽取壳的内存脱壳与请求签名逆向-Android安全-看雪安全社区

# 前言

目标是逆向某** App的网络请求签名 `sign`。

该样本使用了**企业版加固，核心业务方法采用了指令抽取保护，反编译后方法体均为 nop 桩。跟进分析发现，**采用运行期惰性恢复机制：只有被调用到的方法，壳才会将对应的 `code_item` 回填至内存。由于发起网络请求必然触发签名计算，直接通过 `/proc/pid/mem` 转储内存即可获取已解密的签名逻辑。

本文记录加固特征分析、`/proc/pid/mem` 内存脱壳、签名算法还原与 Python 离线复现的过程；后半部分针对未执行代码，记录基于 ArtMethod 级主动调用的全量脱壳方案，以及排查和解决**动态 patch `libart.so` 引发崩溃的对抗细节。

# 加固特征分析

入口 Application 为 `s.h.e.l.l.S`，经典的**特征。解压 APK 后检查 assets 与 lib 目录，关键文件分布如下：

![图片描述](upload/attach/202609/1085268_ZG2HSQCFPMJW8KU.webp)

```
assets/ijiami.dat            (~36 MB)  加密的业务 DEX 载荷
assets/ijiami.ajm
assets/ijm_lib/<abi>/libexec.so, libexecmain.so   **壳 native（ijm=ijiami）
assets/libijmDataEncryption_<abi>.so
assets/IJMDal.Data
lib/<abi>/libijm-emulator.so     ** VMP / 指令模拟
lib/<abi>/libzxprotect.so        ** RASP（反 frida / 反调试）
```

该加固方案结合了指令抽取与 VMP：大部分业务方法指令被抽取，少量逻辑由 `libijm-emulator.so` 解释执行，加密后的业务 DEX 存放在 `ijiami.dat` 中，由壳在运行时动态解密并映射加载。未脱壳前 jadx 查看原始 base APK 仅有 143 个类，主要为 ARouter 路由表。

壳的指令回填采用按需惰性策略：方法首次执行时才由壳回填 `code_item`，未执行的方法在内存中保持 nop 占位。以网络拦截器 `jobs.android.retrofitnetwork.BasicParamsInterceptor` 为例，在未触发网络请求时，jadx 反编译结果全为 `return null`，并提示 `Invalid debug info offset`：

![图片描述](upload/attach/202609/1085268_G4QK3X4T22E6UGU.webp)

由于网络请求触发前必然执行签名计算，签名相关的类与方法在内存中已被解密还原。因此无需全量脱壳，直接转储运行时内存即可获取有效字节码。

# 基于 /proc/pid/mem 的内存转储

常规注入手段在此场景下受限，Frida 在 attach 或 spawn 阶段均会被 `libzxprotect.so` 拦截终止：

```
attach -> target terminated with signal 9        # 注入 agent 即触发 SIGKILL
spawn  -> unexpectedly timed out while waiting for app to launch
```

由于进程内注入面临反调试对抗，直接root 权限读取 `/proc/pid/mem` 是一种无侵入方案。该方法不涉及目标进程内的代码执行与线程创建，且内核接口允许直接读取 VMA 权限被设置为不可读（如 `-wxp`）的 DEX 内存页。

dump 流程如下：首先解析 `/proc/pid/maps`，筛选出名为 `[anon:dalvik-DEX data]` 的内存段，在各段起始地址检索 DEX 魔数 `dex\n035\0`。DEX 头部前 `0x70` 字节中，用于重建文件的关键字段如下：

```
偏移 0x08  checksum   Adler32（覆盖 magic 之后到文件尾）
偏移 0x0C  signature  SHA-1，20 字节（同上覆盖范围）
偏移 0x20  file_size  整份 DEX 字节数
```

读取到 `file_size` 后，按该长度连续转储内存。对于体积较大的 DEX，其在 maps 中常跨越多个相邻的匿名内存映射区域。此时需按虚拟地址连续读取超出当前段大小的数据（相邻 VMA 在虚拟地址空间上连续），最后按 `file_size` 截断。

内存中转储的 DEX 镜像虽已包含回填的 `code_item`，但头部 `checksum` 与 `signature` 仍需修复。需按照 DEX 规范重新计算 Adler32 与 SHA-1 并回写，以确保 jadx 正常反编译。

```bash
pid=$(pidof com.job.android)
# 过滤全部 DEX 内存段（本例共 496 个 [anon:dalvik-DEX data]）
su -c "grep 'dalvik-DEX data' /proc/$pid/maps"
# 在 PC 计算好页对齐的 skip 和 count，从 /proc/pid/mem 提取
su -c "dd if=/proc/$pid/mem bs=4096 skip=<dex_page> count=<npages> 2>/dev/null" > region.bin
# 离线处理：按 header 的 file_size 截断，重算 signature(data[0x20:]) 与 checksum(data[0x0c:])
```

修复后共提取出 16 个有效 DEX 文件，包含 55,054 个类。
在 `full_6f9d1b1000.dex` 中定位到了签名核心类 `EncryptAndSignUtil` 与 `SignFor51`。检查其 CodeItem：`doEncryptOrSign` 包含 439 条指令，`getRequestBodyAfter` 包含 202 条指令，`getSignJsonDataFromMap` 包含 52 条指令，`hmacSha256` 包含 42 条指令，指令流完整，未被抽空为 nop。签名相关逻辑已成功恢复。

# 签名定位：SignFor51 与 EncryptAndSignUtil

检索常用密码学 API（`MessageDigest`、`Mac`、`Cipher`）的交叉引用，定位至核心签名类 `com.jobs.network.digest.SignFor51`。
该类方法实现均为标准加密原语：`hmacSha256` 对应标准 HMAC-SHA256，`getSHA256` 对应 SHA-256，`toHexString` 使用 `Formatter("%02x")` 生成小写十六进制字符串。反编译代码完整可读：

![图片描述](upload/attach/202609/1085268_VHTUQQGQSNAYQ3A.webp)

请求签名的装配逻辑位于拦截器 `com.jobs.network.EncryptAndSignUtil`。首先由 `isNeedSign` 判定目标 host 是否处于验签范围（涵盖 VAPI / IM / AppApiV3 / Young-Cupid 站点，且无 `needSign` 请求头或该头值为 `true`）。核心装配逻辑位于 `getRequestBodyAfter`（以 young/cupid 业务线为例）：

```java
// message = URL host 之后的 path 部分 + getSignJsonDataFromMap(params) 参数转 Gson JSON
String url = request.url().getUrl();
String sign = SignFor51.hmacSha256(
        signKeyForHost.getSignKey(),                                  // key
        url.substring(url.indexOf(host) + host.length())
            + getSignJsonDataFromMap(map));                           // message
return request.newBuilder()
        .addHeader("sign", sign)
        .post(RequestBody.create(MEDIA_TYPE_JSON, getSignJsonDataFromMap(map)))
        .build();
```

签名计算公式为：
`sign = HMAC-SHA256(perHostKey, urlAfterHost + gsonJson(params))`
结果置于 HTTP 请求头的 `sign` 字段。其中 `urlAfterHost` 为 host 之后的完整 URI。需要注意拦截器的执行次序：`CommonParamInterceptor` 会先行将公共 query 参数（`partner`、`guid`、`uuid`、`clientid`、`apiversion` 等）追加至 URL 中，后续执行的 `doEncryptOrSign` 对截取后的完整字符串进行签名，因此该截取段**包含 query 查询串**，而非仅有 path。

参数序列化与签名的关键约束如下：
`getSignJsonDataFromMap` 遍历参数 `Map`（实际传入类型为 `LinkedHashMap`，保证键值插入顺序），对各 value 执行 `String.valueOf(v)` 转换为字符串存入 `JsonObject`，最终调用 `toString()` 输出无冗余空格的 JSON 串。签名拼接的 message 尾部内容与实际发送的 POST 请求体来源于同一次序列化结果，二者需保持逐字节一致。请求头中的 `Client-Time` 由 `CommonHeaderInterceptor` 单独生成，取 GMT+8 时区整点秒级时间戳（分、秒、毫秒归零），**不参与 cupid 站点的 HMAC 计算**。

在 `getRequestBodyAfter` 中还存在两套分支逻辑：非 young/cupid 站点调用 `SignFor51.getRequestBody`，计算公式为 `signData = MD5(SHA256(clientTime + jsonData + signKey))`；旧版 appapi 站点调用 `CQEncrypt.encrypt(formData, true)`，body 格式为 `application/x-www-form-urlencoded`。数据流向梳理如下：

![图片描述](upload/attach/202609/1085268_68C7FVTMA8NDPE4.webp)

# 密钥分发与站点映射

密钥按 host 维度进行配置。枚举类 `EncryptAndSignUtil$SignKey` 在 `<clinit>` 中定义了明文密钥常量：

```
V_API            = "8a9f1f19……3456"   (32 hex)
V_API_FOR_CAMPUS = "9hnrejix……0t1k"
V_API_FOR_YJS    = "1960a9b2……c2cb"
IM               = "w$mm……ctvH"
APP_API          = "44kC……tNc8"
SIGH_KEY_XY      = "lhs3aygg……nt3r"   (64 字符)
SIGN_KEY_51JOB   = "……"                cupid / young 默认
```

`getSignKeyForHost(url)` 依据请求 host 选取对应的 key，部分站点结合 query 参数做二级匹配：

```java
switch (host) {
    case "appapi.51job.com": case "appapi.51jobapp.com":   return APP_API;
    case "vapi.51job.com":   case "vapi.51jobapp.com":
        if (clientid == "000013") return V_API_FOR_CAMPUS;
        return clientid == "000004" ? V_API_FOR_YJS : V_API;
    case "cupid.51job.com":  case "cupid.51jobapp.com":
    case "youngapi.yingjiesheng.com": case "youngapi.51job.com":
        return api_key == "XY" ? SIGH_KEY_XY : SIGN_KEY_51JOB;
    case "im.51job.com":     case "im.51jobapp.com":        return IM;
    default: return V_API;
}
```

例如首页职位列表请求发往 `cupid.51job.com`，匹配的密钥即为 `SIGN_KEY_51JOB`。

# 未执行方法恢复：ArtMethod 级主动调用与 libart patch 对抗

静态内存转储仅能获取已在运行期触发的方法。针对未被执行、仍为 nop 占位的冷门业务逻辑，需借助进程内 ArtMethod 级主动调用机制实现全量解密。
其原理是在运行时遍历已加载 `DexFile` 的 `ClassDef`，解析所有 direct 与 virtual 方法对应的 `ArtMethod` 指针，主动调用 `ArtMethod::GetCodeItem()`。由于**在首次解析方法 code_item 时完成回填，主动遍历调用可促使壳执行解密流程，随后顺着 `CodeItem*` 指针将解密后的字节码转储落盘。

测试基于修改版 **<a href="elink@e64K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3g2X3g2U0N6r3!0J5">Vector</a>** 框架实现。Vector 基于 Zygisk 并在 ART 层提供 hook 能力。方案中将 `HookInline` 底层接入 **<a href="elink@b4cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3M7%4c8W2j5h3I4@1K9q4)9J5k6s2m8G2j5H3`.`.">stealth-poc</a>** 的内核无痕 hook 引擎（shpte KPM）：利用内核缺页异常机制将目标 libart 函数重定向至克隆的 ghost 内存页执行，避开用户态内存校验与 maps 扫描，未开启时回退至 Dobby。脱壳逻辑位于 `native/src/unpack`，通过系统属性进行调度：`dexfind` 负责通过 ART `VisitClasses` 枚举类，`trigger` 负责对各方法调用 `GetCodeItem` 强制触发解密并输出数据。

初次注入测试时，App 在启动 1 秒内发生崩溃。抓取的 tombstone 堆栈信息如下：

![图片描述](upload/attach/202609/1085268_VZF67F5QMDSCNBP.webp)

崩溃表现为主线程向 `libart.so` 的 `.text` 代码段执行写操作时触发 `SEGV_ACCERR`。崩溃现场 pc 位于匿名可执行段，`x18` 寄存器指向**的 `libexec.so`，`x27 = 0xd503233f`（AArch64 下的 `PACIASP` 指令），`x1 = 0x1000`（4KB 内存页大小）。
分析原因为：**壳在启动初期会通过 `mmap` 创建私有内存空间，逐页覆盖原始 libart 函数序言（包含 PAC 保护指令）以建立其私有 hook 机制。若脱壳 worker 线程在此阶段并发 attach 至 ART 并解析符号，将与壳的内存覆盖逻辑产生写冲突并引发异常。对照实验表明：关闭脱壳开关（`unpack=0`）时 App 正常运行；开启后一旦 worker 执行 `AttachCurrentThread`，主线程即触发崩溃。

检查 `libexec.so` 导入表可以印证上述行为：虽然敏感字符串在静态分析中已加密，但其导入的系统 API 组合明确展示了其运行时行为特征：`mmap`、`mprotect`、`memcpy` 用于修改代码段属性并回写指令，`dlopen`、`dl_iterate_phdr` 用于模块定位，`ptrace`、`kill`、`fork` 负责反调试检测，`sigsetjmp` 与 `siglongjmp` 用于异常处理：

![图片描述](upload/attach/202609/1085268_MG69BBFWCFFZEW8.webp)

定位冲突原因后，对 Vector 进行了针对性调整：
- **增加 worker 启动延时（`worker_delay_ms`）**：**对 libart 的重写操作集中于进程启动初期。通过设置延时，使 worker 线程等待壳完成自身初始化与 hook 部署后再执行 attach。实测延时配置为 12000ms（12 秒）。
- **回退至纯 Dobby 模式**：KPM 依赖的页表操作与内存映射在敏感时机同样易与壳的内存补丁产生冲突。针对转储 CodeItem 场景，Dobby 已满足需求，故将 KPM 设为默认关闭。
- **支持多 VMA 连续转储**：增强对单个 DEX 跨越多个内存映射区域时的连续读取逻辑。
![图片描述](upload/attach/202609/1085268_9DHQPTCN6K6KWBZ.webp)
通过 APatch 的 resetprop 配置如下系统属性：

```bash
resetprop persist.kpmhook.unpack 1
resetprop persist.kpmhook.target com.job.android
resetprop persist.kpmhook.unpack.stealth 0             # 仅使用 Dobby，不启用 KPM
resetprop persist.kpmhook.unpack.traceless 0
resetprop persist.kpmhook.unpack.dexfind 1             # VisitClasses 枚举目标 DEX
resetprop persist.kpmhook.unpack.trigger 1             # 逐方法调用 GetCodeItem 强制回填 -> captures.txt
resetprop persist.kpmhook.unpack.worker_delay_ms 12000 # 延时 12 秒，避开壳初始化冲突
resetprop persist.kpmhook.unpack.extout 1              # 输出至应用外部目录，绕过 MLS 策略
```

再次启动 App，在 12 秒延时窗口期内交互触发业务逻辑。脱壳逻辑在延时结束后正常执行，在指定目录生成了 `captures.txt` 及结构 DEX 文件。全量遍历共转储 36 万条 CodeItem 记录（格式为 `<region_start> <method_idx> <codeitem_hex>`）。

对转储数据进行格式有效性校验：CodeItem 头部记录的 `ins_size` 需与方法 proto 声明的参数槽位大小匹配（虚方法需计入 `this` 引用）。编写脚本校验指令序列与反汇编自洽性，36 万条记录匹配率为 1.000，确认指令流完整且未出现索引错位。

该方案为后续分析未经执行触发的冷分支逻辑提供了完整的代码还原能力。

# 签名还原与 Python 实现

签名算法基于标准 HMAC-SHA256，Python 实现核心逻辑如下：

```python
def sign_cupid(after_host, params, host="cupid.51job.com"):
    key = sign_key_for(host)                                     # 对应 getSignKeyForHost，cupid 默认 SIGN_KEY_51JOB
    message = "/" + after_host.lstrip("/") + gson_json(params)   # after_host 包含 host 之后完整字符串（含 query），带前导 /
    return hmac.new(key.encode(), message.encode(), hashlib.sha256).hexdigest()
```

其中 `after_host` 必须保留公共 query 参数；`gson_json` 还原 Java 端 `getSignJsonDataFromMap` 的序列化规则。计算得到的哈希值写入 HTTP `sign` 请求头；网关头 `Client-Time`（GMT+8 时间戳）不计入 HMAC。完整实现已开源至 **<a href="elink@760K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3K9X3!0T1y4e0q4Q4x3X3c8U0L8r3V1`.">job51-cli</a>**。

# 接口验证

根据 `com.job.android.network.MyNetWorkConfig.getCommonQueryParams` 组装公共 query 参数（`api_key=51job`、`clientid=000007`、`version=16.15.0`，以及网关校验的秒级时间戳 `timestamp`），使用 cupid 默认的 `SIGN_KEY_51JOB` 计算签名，构造 HTTP 请求进行服务端校验：

- **抓包比对**：抓取客户端发出的 `open/index/notice-infos` 请求，提取其 `sign` 头部。对相同请求 URL（截取 host 之后的完整串，GET 请求无 body）使用 `SIGN_KEY_51JOB` 计算 HMAC-SHA256，计算结果与抓包中的 `sign` 字段完全一致。
- **差分测试**：请求 `open/noauth/index/common-switch`，携带正确签名返回 HTTP 200 并进入业务参数错误响应（`{"status":"100004","message":"参数校验错误"}`）；若篡改签名中的任一字符重放，服务端返回 `{"status":"110011","message":"鉴权失败，签名错误"}`。
- **业务接口调用**：调用职位搜索接口 `open/good-job-tab/search-new-job-list`，服务端返回 `110104 用户令牌 user-token 不能为空`，证明签名验证通过，仅拦截于登录态校验。

进一步测试免登录公开接口 `open/noauth/gold-two-silver-three/search-job-list`，携带签名请求成功返回岗位列表（`{"status":"1","message":"成功"}`），各岗位职位信息完整；职位详情接口 `open/noauth/jobs/detail/base/{jobId}` 同样无需登录态即可获取完整 JD。实测中 `uuid`、`partner` 参数传入随机值均不影响返回结果，表明该网关仅针对 `sign` 进行签名校验。

验证过程明确了两个关键细节：网关校验的时间戳位于 query 参数 `timestamp`；签名校验范围覆盖 URL 中的完整 query 字符串。

将上述算法封装为 CLI 工具 job51-cli，可实现脱机的职位数据抓取：

![图片描述](upload/attach/202609/1085268_4BYK3PJ4CWVCT5R.webp)

# 复盘

1. **惰性抽取机制下的取舍**：该 App 采用按需回填策略，仅执行过的代码会被解密回写。对于网络请求、加解密等高频核心逻辑，在应用触发对应操作后，直接利用 root 权限读取 `/proc/pid/mem` 即可Dump完整 CodeItem，避开了注入层面的反调试检测。
2. **ART 脱壳的时机对抗**：**在启动初期会对 `libart.so` 注入私有 hook 并修改内存属性。脱壳线程若在壳初始化完成前强行 attach 并解析符号，易引发并发内存访问崩溃。引入启动延时（如等待 12 秒）避开初始化窗口，是一种实用的应对手段。
3. **签名还原细节**：签名核心算法为 HMAC-SHA256，其校验严格依赖序列化格式（`LinkedHashMap` 键值插入顺序、value 强制转换为字符串）。

# 工具

| 工具 | 用途 |
| --- | --- |
| <a href="elink@5f5K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3K9X3q4V1P5q4)9J5k6r3S2W2j5h3c8D9k6i4y4K6i4K6u0V1L8h3y4H3">jadx-headless-mcp</a> | 加载重组后的 DEX，反编译类结构与方法体 |
| <a href="elink@c28K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3g2X3g2U0N6r3!0J5">Vector</a> | 基于 Zygisk + KPM 的无痕 hook 框架，内建 FART 脱壳模块 |
| <a href="elink@4cdK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3M7%4c8W2j5h3I4@1K9q4)9J5k6s2m8G2j5H3`.`.">stealth-poc</a> | shpte KPM 内核无痕 hook（区域克隆 / ghost 内存），Vector `HookInline` 可选后端 |
| <a href="elink@269K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0M7X3g2^5L8$3c8A6j5g2)9J5c8X3W2V1j5g2)9J5k6s2m8J5L8#2)9J5k6r3#2U0M7l9`.`.">ida-pro-mcp</a> | 分析 `libexec.so` 导入表与运行时能力特征 |
| Claude Opus 5 | 编排 jadx / IDA MCP，辅助反编译分析与逆向链路梳理 |
| <a href="elink@e67K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6p5K6y4e0l9K6z5o6V1%4i4K6u0r3K9X3!0T1y4e0q4Q4x3X3c8U0L8r3V1`.">job51-cli</a> | 签名纯 Python 复现及免登录岗位数据获取 CLI 工具 |

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

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

最后于 2026-9-6 19:23 被星野安全编辑，原因：

#逆向分析 #混淆加固

最新回复 (96) 1 2 3 4 ▶
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 708 粉丝 7 关注私信	mb_ldbucrik 2 楼感谢分享 2026-9-4 22:31 0
iBa0 雪币： 1901 活跃值： (5948) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 493 粉丝 37 关注私信	iBa0 3 楼 555 2026-9-4 23:53 0
mb_ezmrnfsu 雪币： 222 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 24 粉丝 0 关注私信	mb_ezmrnfsu 4 楼感谢分享 2026-9-5 01:14 0
cpannn 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 75 粉丝 0 关注私信	cpannn 5 楼牛???? 2026-9-5 07:07 0
mb_sqetvntx 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 54 粉丝 0 关注私信	mb_sqetvntx 6 楼学习 2026-9-5 08:06 0
sfl4800 雪币： 199 活跃值： (353) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 101 粉丝 0 关注私信	sfl4800 7 楼这个必须学习 2026-9-5 08:12 0
kingking888 雪币： 3235 活跃值： (6337) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 302 粉丝 6 关注私信	kingking888 8 楼 666 2026-9-5 10:07 0
dpzx 雪币： 35 活跃值： (518) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 49 粉丝 0 关注私信	dpzx 9 楼学习 2026-9-5 12:52 0
呆萌的小白雪币： 1377 活跃值： (1279) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 90 粉丝 1 关注私信	呆萌的小白 10 楼牛 2026-9-5 15:51 0
LQ6H 雪币： 530 活跃值： (2627) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 80 粉丝 1 关注私信	LQ6H 11 楼 666 2026-9-5 16:56 0
mb_xjdhrmck 雪币： 78 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 154 粉丝 0 关注私信	mb_xjdhrmck 12 楼 123123 2026-9-5 18:40 0
上官兮唐雪币： 575 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 84 粉丝 0 关注私信	上官兮唐 13 楼看看 2026-9-5 19:16 0
A0tem 雪币： 1207 活跃值： (1046) 能力值： ( LV4，RANK：40 ) 在线值：发帖 4 回帖 22 粉丝 39 关注私信	A0tem 14 楼膜拜 2026-9-5 20:35 1
tonykros 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 100 粉丝 0 关注私信	tonykros 15 楼 666 2026-9-5 22:36 0
secflag 雪币： 304 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 31 粉丝 1 关注私信	secflag 16 楼 6666666666666 2026-9-6 00:28 0
夜惜风雨雪币： 95 活跃值： (3777) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 155 粉丝 0 关注私信	夜惜风雨 17 楼 66666666 2026-9-6 02:37 0
hacker521 雪币： 2686 活跃值： (5851) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 226 粉丝 30 关注私信	hacker521 18 楼 66666666 2026-9-6 02:59 0
mb_gkbxtfri 雪币： 487 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 54 粉丝 0 关注私信	mb_gkbxtfri 19 楼 666 2026-9-6 08:52 0
scllqk 雪币： 2619 活跃值： (2004) 能力值： ( LV3，RANK：20 ) 在线值：发帖 4 回帖 57 粉丝 28 关注私信	scllqk 20 楼学习了 2026-9-6 10:34 0
limign 雪币： 24 活跃值： (1007) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 9 粉丝 1 关注私信	limign 21 楼认真背诵 2026-9-6 10:46 0
落音吹雪雪币： 205 活跃值： (186) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 44 粉丝 0 关注私信	落音吹雪 22 楼 nba 2026-9-6 11:08 0
mb_qimctavn 雪币： 5329 活跃值： (6790) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 402 粉丝 1 关注私信	mb_qimctavn 23 楼 6 2026-9-6 12:13 0
小木鱼雪币： 0 活跃值： (1082) 能力值： ( LV3，RANK：20 ) 在线值：发帖 97 回帖 349 粉丝 3 关注私信	小木鱼 24 楼感谢分享 2026-9-6 12:58 0
mb_ykavguun 雪币： 1313 活跃值： (1830) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 166 粉丝 0 关注私信	mb_ykavguun 25 楼学习 2026-9-6 15:22 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复