[原创]AVMP初见(纯AI)-Android安全-看雪安全社区｜专业技术交流与安全研究论坛

[原创]AVMP初见(纯AI)

发表于: 2026-5-25 11:28 9037

[原创]AVMP初见(纯AI)

Tubbs

2026-5-25 11:28

9037

# 从 AVMP 到 x-sign：把 VMCode 转成 IR 后，参数算法还原会清楚很多

这篇文章记录的是一次闲鱼 Android 端 `x-sign` 参数算法的还原过程。样本里的核心逻辑不在普通 Java 层，也不直接以清晰的 native 函数形式出现，而是被放进 AVMP 虚拟机执行。native 层能看到大量解释器、handler、helper 和 descriptor 调用，但真正决定参数结果的数据流藏在 VMCode 里。

本文使用的样本环境大致如下：

```text
目标 App      : 闲鱼 / Idle Fish
目标包名     : com.taobao.idlefish
核心 native  : libsgmainso-6.7.260202.so
ABI          : arm64-v8a
目标命令     : SecurityGuard doCommandNative(70102)
目标结果     : 返回 Map 里的 x-sign
上层输入     : doCommandNative 参数中的 canonical signing string
核心 VM 镜像 : 0x4e500、0x78c50 等 AVMP bytecode image
```

分析过程中同时使用了静态和动态证据：静态部分包括 handler table 恢复、VMCode dump、opcode 语义归纳、VMCode 到 IR 翻译；动态部分包括参数捕获、指令级 trace、关键 VM slot 和内存状态快照。文章里的地址、index、opcode 和中间值都来自这些分析产物。

本文不会完整展开所有业务字段，也不会把每个 helper 都逆完。重点放在一个更通用的问题上：面对 AVMP 这类虚拟机保护，怎么从“看不懂的 native dispatch”推进到“能切片、能验证、能还原算法的数据流”。x-sign 只是案例，用来说明 VMCode 转 IR 对参数算法分析到底有什么实际帮助。

在分析带虚拟机保护的参数算法时，最容易陷入的误区是：一直跟 native 汇编，以为把解释器看完就等于把算法看完。实际上，解释器只是执行引擎，真正的参数算法通常在自定义 VMCode 里。本文后面会先介绍 AVMP 的 VMCode 设计，再说明 VMCode 如何转成 IR，最后用 x-sign 的 MD5、SHA1、XOR、Base64 链路说明 IR 对算法还原的贡献。

## 1. 分析困境

在普通 native 算法里，我们通常找入口函数、看参数、看内存读写、跟调用链，最后把核心逻辑还原成伪代码。

但 AVMP 保护后，真实逻辑会被拆成几层：

```text
Java / JNI 参数
    -> native bridge
    -> descriptor/helper 参数封装
    -> AVMP launcher
    -> VMCode interpreter
    -> opcode handler
    -> helper / descriptor / runtime object
    -> 输出 x-sign
```

如果只看 native，会看到大量 handler：

```text
handler_0x1e9:
    从 VMCode 取 op0/op1/imm
    从虚拟寄存器里取 base
    load [base + imm]
    写回虚拟寄存器 op0
    取下一条 opcode
    br handler_table[next_opcode]
```

这些 handler 不是业务算法本身，只是 VM 指令的实现。直接跟这些 handler，相当于在 CPU 层分析每条机器指令，而不是看编译后的函数逻辑。

所以更有效的路线是：

```text
定位 AVMP 入口
    -> dump VMCode
    -> 恢复 opcode handler table
    -> 归纳 opcode 语义
    -> VMCode 转 IR
    -> 在 IR 上做 CFG / 切片 / 算法识别
    -> 用动态 trace 验证关键数据
```

## 2. 解释器入口

本次样本里，AVMP launcher 会调用真正的解释器函数。解释器拿到几个关键参数：

```text
X1 = vmctx
X2 = program / code object
W3 = start_index
X4 = vmctx + 0x40    ; VM register file
X5 = handler table
```

解释器的核心流程可以抽象成：

```c
bytecode_base = *(uint64_t *)(program + 8);
pc = bytecode_base + start_index * 0x10;
opcode = *(uint16_t *)pc;
vmctx->pc = pc;
goto handler_table[opcode];
```

这里有几个重要信息：

- VMCode 是定长记录，当前样本里一条指令是 `0x10` 字节。
- `start_index` 不是字节偏移，而是 VM 指令索引。
- handler table 是 opcode 到 native handler 的映射。
- VM 寄存器文件由 native 解释器维护，handler 读写的并不是 ARM64 通用寄存器意义上的业务变量，而是 VM slot。

这一步的目标不是完全理解所有 handler，而是确认“解释器怎么取指、怎么分发、VMCode 从哪里读”。

## 3. Handler Table

样本里 handler table 位于：

```text
libsgmainso + 0x2ADC60
```

但直接看 ELF 文件时，这个区域是零填充。原因是 table 项不是静态写死在文件里的绝对地址，而是通过 `.rela.dyn` 重定位生成。

也就是说，静态恢复时不能只读文件里的 table bytes，而要解析 relocation：

```text
R_AARCH64_RELATIVE:
    table_entry_runtime = module_base + rela_addend
```

恢复后可以得到：

```text
opcode 0x000 -> handler offset 0xd6484
opcode 0x014 -> handler offset 0x160ccc
opcode 0x1e9 -> handler offset 0x121ef4
opcode 0x242 -> handler offset 0xf17c4
...
```

这个映射非常关键。后面所有 VMCode decode 都依赖它：

```text
VMCode record opcode -> handler offset -> handler static semantics -> IR operation
```

为了避免静态误判，需要做一次运行时交叉验证：观察解释器里真实使用的 table base，比如 `X23 = module_base + 0x2ADC60`，并确认运行时分发的 handler 和 RELA 恢复出来的 handler 一致。

## 4. VMCode 格式

通过 runtime dump 和 handler 访问模式，可以确认当前 VMCode 指令格式大致如下：

```c
struct AvmpInsn {
    uint16_t opcode;   // +0x00
    uint8_t  op0;      // +0x02
    uint8_t  op1;      // +0x03
    uint8_t  op2;      // +0x04
    uint8_t  op3;      // +0x05
    uint8_t  pad[2];   // +0x06
    uint64_t imm;      // +0x08
};
```

同一个 `imm` 字段在不同 opcode 里有不同解释：

```text
imm64: 普通 64 位立即数
imm32: 低 32 位立即数
delta: 相对跳转偏移
offset: load/store 的内存偏移
value: cmov 条件成立时写入的值
```

例如：

```text
0x000: r0 = r1 + imm64
0x014: goto index + imm64
0x1e9: r0 = *(u64 *)(r1 + imm64)
0x244: *(u64 *)(r0 + r1) = r2
0x262: if r0 == imm32 goto index + delta
```

看一个真实 VMCode 记录会更直观。x-sign 最终输出点 `0x453f` 的原始 16 字节如下：

```text
index  = 0x453f
offset = 0x453f0
bytes  = 42 02 02 00 08 00 00 00 20 00 00 00 00 00 00 00
```

按上面的结构拆开：

```text
+0x00 u16 opcode = 0x0242       ; little-endian: 42 02
+0x02 u8  op0    = 0x02         ; base slot
+0x03 u8  op1    = 0x00
+0x04 u8  op2    = 0x08         ; value slot
+0x05 u8  op3    = 0x00
+0x06 u16 pad    = 0x0000
+0x08 u64 imm    = 0x20
```

结合 opcode `0x242 = st64_base_imm`，这条记录就能翻译成：

```text
*(u64 *)(r0x2 + 0x20) = r0x8
```

再看前一条 `0x453e`：

```text
index  = 0x453e
bytes  = e9 01 02 1e 00 00 00 00 08 ff ff ff ff ff ff ff
decode = r0x2 = *(u64 *)(r0x1e + -0xf8)
```

两条连起来就是：

```text
r0x2 = *(u64 *)(r0x1e - 0xf8)
*(u64 *)(r0x2 + 0x20) = r0x8
```

也就是从 VM frame 里取出输出对象指针，再把 `%r8` 指向的 x-sign 对象写到输出结构体的 `+0x20` 字段。这个例子说明，16 字节记录不是抽象猜测，而是可以逐字节拆出来，并且能和最终业务语义对应上。

这里最容易踩坑的是跳转。很多 branch opcode 不是跳到字节偏移，而是跳到 VM 指令索引：

```text
target_index = current_index + delta
target_pc    = bytecode_base + target_index * 0x10
```

如果把 delta 当字节偏移，CFG 会完全错。

## 5. Opcode 语义

opcode 语义可以分三层确认。

第一层是 handler 短路径。很多 handler 非常短，语义可以直接从汇编看出来。例如 `st64_base_imm`：

```text
ldrb op0, [pc,#2]
ldrb op2, [pc,#4]
ldr  base, [vm_regs, op0<<3]
ldr  val,  [vm_regs, op2<<3]
ldr  imm,  [pc,#8]
str  val,  [base, imm]
dispatch next
```

可以翻成：

```text
*(u64 *)(r_op0 + imm64) = r_op2
```

第二层是 handler 家族。比如一组 load/store opcode 结构类似，只是访问宽度不同：

```text
ld8_base_imm
ld16_base_imm
ld32_base_imm
ld64_base_imm
ld8_base_slot
ld16_base_slot
ld32_base_slot
ld64_base_slot
```

这种可以先确认几个代表 handler，再批量归纳。

第三层是 helper 型 opcode。有些 handler 本身只做参数搬运，然后调用一个复杂 helper：

```text
load q0/q1 from VM raw-FP slots
call helper
store q0 back to VM raw-FP slot
```

这类不能只看 handler，要继续看 helper。比如某组 raw-FP128 opcode：

```text
0xc8 -> helper 翻转高 64 位里的 sign bit       -> rawfp128_neg
0x6d -> helper 做 exponent/mantissa 对齐与归一化 -> rawfp128_add
0xc7 -> helper 做 exponent/mantissa 乘法         -> rawfp128_mul
0xcb -> 先翻转第二操作数 sign bit，再进 add core -> rawfp128_sub
```

这里故意命名成 `rawfp128`，而不是直接叫 IEEE `f128`。原因是静态证据能证明它是扩展浮点样式的 raw representation 和 arithmetic helper，但不能随便声称它就是某个标准 ABI 类型。

## 6. 伪汇编

拿到 opcode 语义后，第一步可以先输出伪汇编：

```text
0x4535: call_descriptor imm64=0x2
0x4536: r0x2 = *(u64 *)(r0x1e + -0x108)
0x4537: r0x8 = *(u64 *)(r0x2 + r0x0)
0x453e: r0x2 = *(u64 *)(r0x1e + -0xf8)
0x453f: *(u64 *)(r0x2 + 0x20) = r0x8
```

这一步已经比 native handler 清楚很多，但还不够。伪汇编适合阅读，不适合自动化分析。比如想反向追 `%r8` 从哪里来、哪些 block 写过 x-sign 对象、哪些循环是 XOR loop，就需要更结构化的表示。

所以第二步是转成 IR。

## 7. IR 设计

这里的 IR 不是为了做编译优化，而是为了逆向分析。目标是：

- 统一不同 opcode 的表达方式。
- 保留 VM 寄存器和内存访问。
- 能构建 CFG。
- 能做简单 use-def 和 backward slice。
- 对未知 helper 保守建模，不编造语义。

### 7.1 寄存器

VM slot 统一表示成：

```text
%r0
%r1
%r8
%r1e
```

raw-FP / SIMD 类 slot 统一表示成：

```text
%f0
%f4
%f8
```

这样可以把 ARM64 寄存器噪声去掉，只保留 VM 层变量。

### 7.2 内存访问

不同宽度的 load/store 统一成：

```text
%r2 = load.i64 [%r1e + -0xf8]
%r1b = load.i32 [%r18 + %r0]
%r1c = load.i8  [%r1d + %r1b]

store.i64 %r8,  [%r2 + 0x20]
store.i32 %r1b, [%r18 + %r0]
store.i8  %r1c, [%r1d + %r1b]
```

如果是符号扩展，也要显式保留：

```text
%r0 = load.i8s  [base + off] -> i64
%r0 = load.i16s [base + off] -> i64
%r0 = load.i32s [base + off] -> i64
```

否则后续判断有符号比较、长度检查时会出错。

### 7.3 算术和位运算

算术统一成表达式：

```text
%r1b = (%r1b shl 0x7)
%r1c = (%r1b lshr 0x19)
%r1b = (%r1c or %r1b)
%r1b = (%r1b xor %r1a)
```

这样一眼就能看出：

```text
rol32(x, 7) = (x << 7) | (x >> 25)
```

如果再接一个 xor 常量，就可以识别成：

```text
rol32(seed, 7) ^ const
```

### 7.4 控制流

branch 和 jump 统一成：

```text
br icmp.eq.i64 %r19, 0x0, bb_47d0, bb_47cf
jmp bb_472b
ret_pc %r0
```

AVMP 里经常有 bytecode 子过程，调用和返回不一定是普通 call/ret。对于这种情况，可以在 CFG 构建时做保守近似：对某些直接 jump 同时保留目标边和 fallthrough 边，用来覆盖 VMCode 子过程返回路径。

这不适合生成最终伪代码，但足够做“目标 store 是否可达”“某个窗口附近有哪些 producer”。

### 7.5 Helper 与 Descriptor

不是所有东西都应该强行还原。对未完全解释的复杂调用，IR 保留 side effect：

```text
%r8 = call avmp.helper(0x23131)
call avmp.descriptor(0x2)
call avmp.call_resolve_pc(%r1a + %r0)
```

这样做有两个好处：

- 不会因为猜错 helper 语义污染整体 IR。
- 后续可以针对高价值 helper 单独动态验证。

## 8. x-sign 输出点

本次 x-sign 的完整 AVMP 镜像大小是 `0x4e500`，历史确认的 x-sign 入口是：

```text
entry_index = 0x40a0
```

最终输出点位于：

```text
index  = 0x453f
opcode = 0x242
```

转成 IR 后是：

```text
0x453f:
store.i64 %r8, [%r2 + 0x20]
```

这条指令的含义很明确：

```text
output->field_0x20 = xsign_object
```

也就是说，x-sign 最终不是某个 native 函数直接返回的字符串，而是 VM 内部构造出的对象，被写入输出结构体偏移 `0x20`。

从这条 store 反向看，可以得到：

```text
0x4535: call_descriptor 0x2
0x4536: %r2 = load.i64 [%r1e + -0x108]
0x4537: %r8 = load.i64 [%r2 + %r0]
0x453e: %r2 = load.i64 [%r1e + -0xf8]
0x453f: store.i64 %r8, [%r2 + 0x20]
```

这说明：

- `[r1e - 0xf8]` 保存了输出结构体指针。
- `[r1e - 0x108]` 附近保存了某个中间对象或对象数组。
- `%r8` 是最终被包装出来的 x-sign 对象。
- `descriptor(0x2)` 参与了最后的对象/字段准备。

再把同一位置和完整 trace 对上，可以看到真实运行时值：

```text
5230754  handler 0xf17c4: op0 = 0x2
5230755  load vm slot r2  => X7  = 0x7b4ac3e108
5230756  load imm         => X14 = 0x20
5230758  load vm slot r8  => X8  = 0x7c045320c0
5230759  store            => [0x7b4ac3e108 + 0x20] = 0x7c045320c0
```

这说明静态 IR 里的：

```text
store.i64 %r8, [%r2 + 0x20]
```

在该次 trace 中对应真实值：

```text
output        = 0x7b4ac3e108
xsign_object  = 0x7c045320c0
output+0x20   = xsign_object
```

继续往前看这个 `xsign_object` 的字段，还能看到：

```text
xsign_object + 0x0 = 0x7b9e428bd0   ; payload pointer
xsign_object + 0x8 = 0x66           ; payload length, 102 bytes
```

也就是说，`0x453f` 不是随便一个对象赋值，而是最终把长度为 `0x66` 的 x-sign payload 对象挂到输出结果上。

这类信息如果直接从 native handler 跟，会被大量 dispatch 淹没；在 IR 上则是几行数据流。

## 9. Entry 区分

同一个 `0x4e500` 镜像，在不同捕获里可能有不同 entry。例如：

```text
representative entry: 0x3130
x-sign entry       : 0x40a0
```

这两个 entry 对应同一个镜像 hash，但静态可达结果不同：

```text
entry 0x3130 -> 不到达 0x453f
entry 0x40a0 -> 可到达 0x453f
```

所以分析 AVMP 时不能只说“这个 image 是 x-sign”，还要说明：

```text
哪个 image
哪个 entry
哪个 target index
当前 CFG 近似规则是什么
```

否则很容易出现“同一个 VMCode 镜像，为什么这次切不到输出点”的误判。

## 10. 算法链路

IR 的另一个价值是识别算法形态。

比如某个 seed 变换在 IR 中长这样：

```text
%r1b = load.i32 [%r18 + %r0]
%r1c = (%r1b lshr 0x19)
%r1b = (%r1b shl 0x7)
%r1b = (%r1c or %r1b)
%r1b = (%r1b xor %r1a)
store.i32 %r1b, [%r18 + %r0]
```

读成高级语义就是：

```c
v = *(uint32_t *)(buf + off);
v = rol32(v, 7) ^ key_or_const;
*(uint32_t *)(buf + off) = v;
```

再比如一个字节 XOR loop：

```text
key_byte = load.i8 [key + i]
old_byte = load.i8 [dst + i]
new_byte = old_byte xor key_byte
store.i8 new_byte, [dst + i]
```

在动态 trace 里补上具体值后，就可以确认：

```text
xor_out == dst_byte_before ^ key_byte
```

本次 x-sign trace 里有一个更具体的 XOR run。`0x78c50:bb_464d` 这段循环一共命中了 6 组，其中最后一组直接参与最终 Base64 输入：

```text
run      = 5
key ptr  = 0x7b51692a8f
key      = a9 4e repeat
dst      = 0x7b51692e8f
count    = 0x41
check    = 65 iterations all satisfy xor_out == dst_before ^ key_byte
```

这个 `a9 4e` 不是静态常量直接拷贝出来的，而是前面 `0x468f..0x4696` 的 key setup 算出来的。trace 中两个字节的计算例子如下：

```text
byte0:
  word = 0xacb0e487
  mix  = 0x48242742 | 0x7b51692634
  tmp  = 0x7c061e0bfd
  out  = low8(tmp + floor(tmp / 0xff)) = 0xa9

byte1:
  word = 0x0612ada8
  mix  = 0x763f92a6 | 0x7b51692634
  tmp  = 0x7b7d92645e
  out  = low8(tmp + floor(tmp / 0xff)) = 0x4e
```

最终 Base64 前的 69 字节二进制状态是：

```text
raw69 =
0002a94e61808c96e791d85fad6fa94ea948944fc33486f228c89a4facf0e272
d261354c3771471c42831a17a5cfe24f667b0909ec7abd05e25be227a84ebd
07aa4ca94ea9
```

它的结构可以拆成：

```text
raw69[0..1]   = 00 02
raw69[2..3]   = a9 4e
raw69[4..68]  = xor_out65
```

标准 Base64 后得到 92 字节 tail：

```text
AAKpTmGAjJbnkdhfrW+pTqlIlE/DNIbyKMiaT6zw4nLSYTVMN3FHHEKDGhelz+JPZnsJCex6vQXiW+InqE69B6pMqU6p
```

前面再拼固定/半固定 header：

```text
header = azU7Bc002x
x-sign = header || base64(raw69)
```

所以该次 trace 的最终 payload 是：

```text
azU7Bc002xAAKpTmGAjJbnkdhfrW+pTqlIlE/DNIbyKMiaT6zw4nLSYTVMN3FHHEKDGhelz+JPZnsJCex6vQXiW+InqE69B6pMqU6p
```

这里还可以再往上游补一段：`tmp21` 里的 `md5(input)` 来源。

早期我们在 `0x4e500` 的 x-sign 路径里定位到一段 MD5-like routine。静态上它有非常标准的 MD5 特征：

```text
IV:
  0x67452301
  0xefcdab89
  0x98badcfe
  0x10325476

T constants:
  0xd76aa478
  0xe8c7b756
  0x242070db
  0xc1bdceee
  ...
```

动态验证时，在 AVMP index `0x4502` 捕获 MD5 输入，在 `0x4503` 捕获 digest 输出，再在 `0x4514/0x4520` 附近捕获 `tmp21`。其中一个样本是：

```text
4502 input_len        = 0x5f4
4503 digest_out       = e7315c5a2ee35e66dc173d666dabf07a
python hashlib.md5(input)
                       = e7315c5a2ee35e66dc173d666dabf07a

4520 tmp21            = 1100000005e7315c5a2ee35e66dc173d666dabf07a
tmp21[0..4]           = 11 00 00 00 05
tmp21[5..20]          = MD5(input)
```

这个 `input` 也不是随机二进制。捕获到的 MD5 输入是 100% 可打印字符串，开头和 `doCommandNative(70102)` 的 Java 参数 `arg[1]` 是同一类 canonical signing string：

```text
agE9BGeXXD0DAA110FL0VDSu&&&21407387&
<data-md5>&
<timestamp>&
<api>&
<version>&&
231200@fleamarket_android_7.26.20&&0&0&
openappkey=DEFAULT_AUTH&27&&&&&&&
```

后面还会继续拼接一段可打印的 security material，所以关系更准确地说是：

```text
md5_input = canonical_arg1_prefix || extra_security_material
digest16  = MD5(md5_input)
tmp21     = 11 00 00 00 05 || digest16
```

不同请求、不同时间戳会得到不同的 digest。上面 `e731...` 是 MD5 封装验证样本；后面完整 x-sign 链路里的 `122eff...` 是另一条 trace 的 digest16。值不同不影响数据流关系。

把 MD5 来源、`tmp21` 封装、下游 XOR/Base64 串起来，当前 trace 中从参数材料到 x-sign 的算法流程可以写成：

```text
md5_input = canonical_arg1_prefix || extra_security_material
  -> digest16 = MD5(md5_input)
  -> tmp21 = 11 00 00 00 05 || digest16
  -> 本次下游 trace 的 digest16 = 122effe8051b7340d40bb94da4f331ff
  -> prefix57 = digest16 || binary_tail8 || ">" || ascii32
  -> old_origin56 = counter/static words/seed transform/version-like fields/tail fields
  -> orig113 = prefix57 || old_origin56
  -> head9 = SHA1(orig113)[5:14]
  -> prexor65 = head9 || old_origin56
  -> key = a9 4e
  -> xor_out65 = prexor65 XOR repeat(a9 4e)
  -> raw69 = 00 02 || a9 4e || xor_out65
  -> x-sign = "azU7Bc002x" || base64(raw69)
```

其中几个关键具体值是：

```text
binary_tail8  = 2e48932a66479f0d
ascii32       = b53d696bc36c59275ffb8570daa18de6
SHA1(orig113) = b7826ff232c8ce25d84edf7111047bfc2024ce62
head9         = c8ce25d84edf711104
```

这类 loop 在 native handler 层看起来是大量 `ldr/str/br` 的解释器噪声；在 IR 层就是普通的字节循环。

## 11. 算法误判

静态 IR 里还可以看到一些 hash-like 或 base64-like 的块：

```text
SHA-256-like: 0x428a2f98, 0x71374491, ...
MD5-like    : 0xd76aa478, 0xe8c7b756, ...
base64      : base64 helper anchor
```

这些信息很有用，但不能直接等价为“它就是当前 x-sign 主路径”。原因是一个 AVMP 镜像可能包含多段通用算法实现、工具函数、备用路径或不同命令共享的逻辑。

正确做法是：

```text
静态 IR 找候选算法块
    -> 动态 trace 判断当前 x-sign 是否执行到这些 block
    -> 对执行到的 block 做值级验证
```

在本次分析中，IR 帮助把“看起来像标准算法的块”和“当前 x-sign 实际执行路径”分开。这样可以避免因为看到 SHA/MD5 常量就过早下结论。

## 12. Opcode 补全

早期 decoder 里大量 opcode 只能叫：

```text
opaque_XXX(...)
```

这种情况下，IR 仍然能跑，但切片和算法识别会有很多断点。随着 opcode 语义补全，IR 质量会明显提升。

本次处理后的一个结果是：

```text
batch4 opaque: 92
batch6 opaque: 31
```

并且剩余 opaque 全是单例。更重要的是：

```text
IR06: 0 opaque
IR07: 0 opaque
```

这意味着 x-sign 相关路径的 opcode 层面已经基本打通。后面真正的难点转为：

- helper 的业务语义。
- descriptor 参数/返回对象。
- runtime object 的字段含义。
- 动态值如何回填到静态 IR。

换句话说，VMCode 转 IR 不是终点，但它把问题从“指令级看不懂”推进到了“数据流和对象语义还原”。

## 13. 分析流程

结合这次 x-sign 分析，可以整理出一套相对通用的流程。

### 13.1 解释器

目标是找到：

```text
bytecode_base 从哪里来
entry_index 是哪个参数
opcode 如何读取
handler table 在哪里
VM register file 在哪里
```

如果看到类似：

```text
pc = bytecode_base + index * fixed_size
opcode = *(u16*)pc
handler = table[opcode]
br handler
```

基本可以判断进入了 VM 解释器。

### 13.2 VMCode Dump

dump 时至少记录：

```text
program pointer
bytecode_base
bytecode_size
entry_index
sha256 / hash
触发场景
```

同一个 image 可能有多个 entry，所以不要只按 size 去重，最好按 image hash 去重，同时保留 entry 列表。

### 13.3 Handler Table

如果 table 在文件里不是直接地址，要看 relocation。

输出最好长这样：

```text
opcode, handler_offset, handler_addr_runtime
```

并用运行时分发做一次校验。

### 13.4 Opcode

优先级可以这样排：

```text
高频 opcode
控制流 opcode
load/store opcode
算术/位运算 opcode
影响目标切片的 opcode
```

不要为了清零 opaque 去分析所有单例。只有落在目标路径上的单例才值得优先处理。

### 13.5 IR

IR 不必一步到 SSA。先做到：

```text
寄存器统一
load/store 带宽度
branch target 正确
helper 保守建模
每条 IR 保留原始 index/opcode/handler
```

这些已经足够支持很多静态分析。

### 13.6 CFG 与切片

从目标输出点反向切，通常比从入口正向读更快：

```text
找到最终 store
确认输出结构体 base
确认 value object
反向追 value object producer
再追 payload buffer / key / seed
```

如果 VMCode 有子过程和非标准返回，CFG 可以先保守近似，后续再用动态 trace 收敛。

## 14. 常见坑

### 14.1 混淆 Entry 和 Image

同一个 VMCode image 可以有多个 entry。分析报告里应该同时写：

```text
image hash
size
entry index
target index
```

否则不同 entry 的可达性差异会造成误判。

### 14.2 误读算法常量

看到 SHA/MD5 常量只能说明“这里存在对应实现或类似实现”，不能说明“当前请求执行了它”。必须用动态 trace 或可达切片确认。

### 14.3 Opcode 过度命名

比如 raw-FP128 helper，静态能证明它有扩展浮点特征，但不一定能证明标准类型。命名成 `rawfp128_add` 比直接写 `f128_add` 更稳。

### 14.4 符号扩展

`ld8`、`ld8s`、`ld16`、`ld16s` 在长度判断、索引计算、比较分支里差别很大。IR 里必须保留 signedness。

### 14.5 Helper 猜测

helper 不懂就保留 `call avmp.helper(...)`。等它进入关键切片，再单独用静态或动态方式验证。

## 15. 小结

AVMP 保护下，参数算法被藏在 VMCode 里。native 层更多是解释器和 handler，不是最终业务逻辑。想还原 x-sign 这类参数算法，关键不是硬啃所有 native 汇编，而是先把 VMCode 提升到可分析的中间表示。

本文的核心思路可以概括为：

```text
dump VMCode
  -> 解析 handler table
  -> 归纳 opcode 语义
  -> 翻译成 IR
  -> 构建 CFG
  -> 从输出点反向切片
  -> 动态 trace 验证关键值
```

在 x-sign 案例中，IR 化之后可以明确看到：

- 最终 x-sign 对象写入 `output + 0x20`。
- `0x40a0` 才是到达最终输出点的关键 entry。
- 若干中间变换可以从 handler 噪声里抽象成普通 load/store/xor/rotate。
- 静态算法候选块和真实执行路径可以分开验证。

这就是 VMCode 转 IR 的价值：它不能自动给出完整算法，但能把“解释器迷宫”变成“可切片、可验证、可逐步命名的数据流”。对于 AVMP 这类保护，做到这一步，后面的参数算法还原才真正进入可工程化阶段。

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

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

收藏・21

点赞・191

打赏

赞赏记录

参与人

雪币

留言

时间

深沉

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

2026-10-3 22:11

mb_icgthzdk

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

2026-9-29 22:54

New对象处

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

2026-9-28 18:50

想画画

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

2026-9-28 14:42

er胡

为你点赞！

2026-9-23 20:02

git_99440qimingminimax

为你点赞！

2026-9-23 11:36

mb_osuxginm

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

2026-9-21 21:16

taeyeon_ss

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

2026-9-20 13:23

呆呆呆呆

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

2026-9-17 18:53

逆天而行

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

2026-9-17 14:13

ldljlzw

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

2026-9-15 08:43

大帅锅

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

2026-9-4 10:54

zzhxsq

非常支持你的观点！

2026-9-3 15:10

青衫不负雪

为你点赞！

2026-9-3 10:50

Reverser07

为你点赞！

2026-9-2 02:19

mb_gjttoonf

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

2026-9-1 23:00

shmilyaxy

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

2026-9-1 17:08

binkj

为你点赞！

2026-9-1 15:44

WsttXm

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

2026-8-29 14:45

wx_Kiyose

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

2026-8-28 16:24

falconnnn

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

2026-8-27 16:16

Love 2016

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

2026-8-27 00:22

mb_jgrekwbr

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

2026-8-25 20:30

sk97

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

2026-8-25 17:14

加壳菜菜

非常支持你的观点！

2026-8-25 16:50

Aar0n

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

2026-8-25 11:02

mb_ilhoapnq

非常支持你的观点！

2026-8-25 07:59

一只鸭子

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

2026-8-23 15:01

mb_lthgjpwj

为你点赞！

2026-8-20 16:51

mb_wvlmehse

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

2026-8-20 13:22

黑龙lilad

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

2026-8-19 16:39

mb_kifexqhm

为你点赞！

2026-8-14 11:39

程序员小潘

为你点赞！

2026-8-13 14:21

Wika

为你点赞！

2026-8-8 15:40

mb_wsoacceo

为你点赞！

2026-8-8 00:53

天地一逆旅

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

2026-8-1 10:51

钟白

非常支持你的观点！

2026-7-31 16:18

Sigil

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

2026-7-31 09:31

mb_bzztlmaj

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

2026-7-29 18:43

neocanable

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

2026-7-29 10:22

mb_hftbhpsj

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

2026-7-28 16:22

mb_wyefudor

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

2026-7-28 11:33

mb_ztuznpua

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

2026-7-27 20:00

跟哥哥有糖

为你点赞！

2026-7-27 03:48

mxystery

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

2026-7-26 12:39

mb_hdiusdyf

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

2026-7-22 21:08

nxlite

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

2026-7-21 10:35

wx_sean_939769

为你点赞！

2026-7-20 17:06

Gift1a

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

2026-7-20 17:04

破执.

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

2026-7-18 02:44

wx_晨梦

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

2026-7-16 06:09

mb_selzmlge

为你点赞！

2026-7-15 04:36

北袅

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

2026-7-14 23:32

shush

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

2026-7-14 16:02

afishlong

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

2026-7-13 23:30

houjingyi

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

2026-7-9 18:59

mb_hsscwjpz

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

2026-7-8 19:04

mb_osaexivw

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

2026-7-7 05:07

mb_ooliergk

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

2026-7-5 04:21

Freax

为你点赞！

2026-6-30 21:36

bluegatar

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

2026-6-28 09:52

jpp_k

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

2026-6-27 16:53

git_36712chenyi-168

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

2026-6-26 15:11

FANGG3

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

2026-6-24 18:17

蜕无痕

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

2026-6-24 16:03

科学电击使

为你点赞！

2026-6-22 21:24

风兮木晓

为你点赞！

2026-6-21 21:16

mb_cebxltxx

为你点赞！

2026-6-18 14:40

mb_weywajpz

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

2026-6-16 10:27

mb_tvuiswau

为你点赞！

2026-6-15 20:23

天水姜伯约

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

2026-6-15 16:48

xzqc

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

2026-6-15 16:33

git_16338D-R-99

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

2026-6-14 00:36

mb_dziarviw

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

2026-6-12 19:39

wx_浓情淡如你

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

2026-6-12 17:23

feige_396505

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

2026-6-12 17:02

龙哥在不在

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

2026-6-9 22:46

马来

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

2026-6-9 18:26

wx_不愿入赘老板郎

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

2026-6-8 10:25

wx_栀_271

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

2026-6-5 09:35

ycdear

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

2026-6-4 23:10

mb_eiufitqh

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

2026-6-3 15:14

我只是没人要

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

2026-6-2 11:39

slurse_212010

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

2026-6-1 03:58

北门观雪

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

2026-5-31 05:39

zxhk

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

2026-5-30 05:52

mb_bppcorlj

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

2026-5-30 00:28

zx_1073136

非常支持你的观点！

2026-5-29 19:17

mb_bzlxewmx

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

2026-5-29 18:05

wx_0xC05StackOver

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

2026-5-29 15:03

Cure.

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

2026-5-29 14:40

richor

为你点赞！

2026-5-29 10:57

BeanSpy

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

2026-5-29 10:15

落日余辉

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

2026-5-28 22:19

劫__

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

2026-5-28 17:47

Je2em1ah

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

2026-5-28 12:14

shutterbug

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

2026-5-28 11:22

longloo

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

2026-5-28 09:32

hx九七

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

2026-5-28 00:43

mb_oatdtlak

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

2026-5-27 22:28

山间清爽的风

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

2026-5-27 21:05

十八垧

为你点赞！

2026-5-27 18:33

ChuXinﻬ.

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

2026-5-27 18:19

wx_kx15923

为你点赞！

2026-5-27 17:46

qqizai

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

2026-5-27 16:36

ke3l

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

2026-5-27 16:31

mb_aoooaosd

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

2026-5-27 16:16

青蓝梦

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

2026-5-27 15:52

mb_nofqtpir

为你点赞！

2026-5-27 14:39

龙幽

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

2026-5-27 14:24

Hawcett

为你点赞！

2026-5-27 14:07

mb_ovfonqtb

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

2026-5-27 11:32

mb_rrvlrvbk

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

2026-5-27 11:19

mb_mbxblliw

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

2026-5-27 10:10

教教我吧~

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

2026-5-27 09:13

lingyi223

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

2026-5-27 08:41

王叔叔

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

2026-5-27 00:06

mb_asiwnxyv

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

2026-5-26 23:13

快乐的小跳蛙

为你点赞！

2026-5-26 22:27

mb_itubdqgo

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

2026-5-26 21:23

ldzspace

为你点赞！

2026-5-26 20:17

Ms135

为你点赞！

2026-5-26 20:08

mb_pajvlyxs

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

2026-5-26 19:45

wx_funcrever

非常支持你的观点！

2026-5-26 19:08

2beNo2

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

2026-5-26 18:17

安卓逆向test

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

2026-5-26 17:58

yxnwh

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

2026-5-26 17:22

iCookiie

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

2026-5-26 16:43

悲殇落幕

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

2026-5-26 16:19

the_hs

为你点赞！

2026-5-26 15:47

dsfa

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

2026-5-26 15:40

void *

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

2026-5-26 15:05

Catmeow

为你点赞！

2026-5-26 14:03

maxfire

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

2026-5-26 13:32

岁月。

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

2026-5-26 12:50

Eirv

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

2026-5-26 12:13

零_721409

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

2026-5-26 11:07

fogSea

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

2026-5-26 10:49

酋knave

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

2026-5-26 10:37

git_56009war9

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

2026-5-26 09:50

alienhe

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

2026-5-26 09:48

ngiokweng

非常支持你的观点！

2026-5-26 09:20

wx_墨_198

非常支持你的观点！

2026-5-26 09:13

灬哈密瓜

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

2026-5-26 09:09

ONewTach

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

2026-5-26 09:03

linchuan0

为你点赞！

2026-5-25 21:54

mb_dtidoewd

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

2026-5-25 21:52

nonovo

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

2026-5-25 21:20

pexillove

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

2026-5-25 20:17

npc0vo

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

2026-5-25 20:12

伟叔叔

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

2026-5-25 19:33

xjohjrdy

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

2026-5-25 19:26

曹无咎

为你点赞！

2026-5-25 19:16

oMasko

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

2026-5-25 19:08

孤独的街

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

2026-5-25 18:47

路过1

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

2026-5-25 18:31

mb_axnyspcg

为你点赞！

2026-5-25 18:01

doduhuang

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

2026-5-25 17:50

sun-shine

非常支持你的观点！

2026-5-25 17:48

Harpe

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

2026-5-25 17:24

mb_iesvmzqc

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

2026-5-25 17:21

mb_sexbafmg

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

2026-5-25 17:13

陈某人

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

2026-5-25 17:03

熊猫人大A

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

2026-5-25 17:02

木志本柯

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

2026-5-25 16:45

mb_hhiypuwp

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

2026-5-25 16:41

梧桐生

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

2026-5-25 16:39

userapp

为你点赞！

2026-5-25 16:32

mb_pnrjfxiv

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

2026-5-25 16:31

wangzehua

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

2026-5-25 16:12

巷口的那只猫

非常支持你的观点！

2026-5-25 16:10

mb_rjdrqvpa

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

2026-5-25 15:41

码小芹

为你点赞！

2026-5-25 15:05

小傲骨

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

2026-5-25 15:04

wInFoG_2017

非常支持你的观点！

2026-5-25 14:43

nekomiao

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

2026-5-25 14:35

whohh

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

2026-5-25 14:30

MsScotch

非常支持你的观点！

2026-5-25 14:17

mb_wpitiize

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

2026-5-25 14:07

顽劣

非常支持你的观点！

2026-5-25 14:06

杨如画

非常支持你的观点！

2026-5-25 14:04

下雨天sana

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

2026-5-25 14:02

mb_wdhsjycl

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

2026-5-25 13:55

huangyalei

非常支持你的观点！

2026-5-25 13:46

东方玻璃

为你点赞！

2026-5-25 13:38

逆向小玖

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

2026-5-25 13:35

白衣23

为你点赞！

2026-5-25 12:39

令狐双

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

2026-5-25 12:24

lgnorantlu

非常支持你的观点！

2026-5-25 12:07

mb_rtxphxry

为你点赞！

2026-5-25 11:38

Mrack

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

2026-5-25 11:36

最新回复 (121) 1 2 3 4 5 ▶
mb_sezgvuqb 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	mb_sezgvuqb 2 楼 1 2026-5-25 13:31 0
mb_mxsesokv 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 14 粉丝 0 关注私信	mb_mxsesokv 3 楼 1 2026-5-25 13:37 0
xingbing 雪币： 158 活跃值： (5791) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1400 粉丝 2 关注私信	xingbing 4 楼学习！！！ 2026-5-25 13:46 0
mb_mlyojneh 雪币： 10 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 53 粉丝 0 关注私信	mb_mlyojneh 5 楼学习！！！ 2026-5-25 13:51 0
method 雪币： 1972 活跃值： (8178) 能力值： ( LV5，RANK：70 ) 在线值：发帖 13 回帖 268 粉丝 134 关注私信	method 1 6 楼 1 2026-5-25 14:07 0
mb_xjdhrmck 雪币： 78 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 154 粉丝 0 关注私信	mb_xjdhrmck 7 楼 6+666 2026-5-25 14:54 0
mb_dcjxxhsk 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 79 粉丝 0 关注私信	mb_dcjxxhsk 8 楼 666 2026-5-25 15:31 0
温泉划水鱼雪币： 94 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 226 粉丝 28 关注私信	温泉划水鱼 9 楼看看最后于 2026-5-25 15:33 被温泉划水鱼编辑，原因： 2026-5-25 15:32 0
乐活雪币： 2941 活跃值： (3332) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 62 粉丝 1 关注私信	乐活 10 楼 6666 2026-5-25 16:08 0
mb_jnmxfjku 雪币： 109 活跃值： (820) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_jnmxfjku 11 楼 666 2026-5-25 16:34 0
Imxz 雪币： 110 活跃值： (9571) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 775 粉丝 9 关注私信	Imxz 12 楼 tql 2026-5-25 16:45 0
小尘0000 雪币： 18 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 80 粉丝 0 关注私信	小尘0000 13 楼 666 2026-5-25 17:40 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 259 粉丝 0 关注私信	mb_cbgtaveo 14 楼 666666666 2026-5-25 17:43 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 707 粉丝 7 关注私信	mb_ldbucrik 15 楼感谢分享 2026-5-25 19:24 0
farendaibiao 雪币： 10627 活跃值： (6994) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	farendaibiao 16 楼很好的分析文章 2026-5-25 19:50 0
XCicada 雪币： 3103 活跃值： (2705) 能力值： ( LV6，RANK：80 ) 在线值：发帖 3 回帖 324 粉丝 101 关注私信	XCicada 2 17 楼 666 2026-5-25 20:17 0
悟雪币： 0 活跃值： (575) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 15 粉丝 0 关注私信	悟 18 楼 11111111 2026-5-25 20:21 0
墨穹呢雪币： 4770 活跃值： (8232) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 231 粉丝 18 关注私信	墨穹呢 19 楼感谢分享 2026-5-25 20:51 0
mb_seujxaaa 雪币： 208 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 18 粉丝 0 关注私信	mb_seujxaaa 20 楼感谢分享 2026-5-25 21:03 0
SomeMx 雪币： 4211 活跃值： (5614) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 21 楼学习 2026-5-25 21:46 0
wx_Huber Barrientos 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 216 粉丝 1 关注私信	wx_Huber Barrientos 22 楼 666 2026-5-26 03:08 0
夜惜风雨雪币： 95 活跃值： (3767) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 155 粉丝 0 关注私信	夜惜风雨 23 楼 66666666666 2026-5-26 10:17 0
guijingwen 雪币： 7377 活跃值： (7605) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 312 粉丝 0 关注私信	guijingwen 24 楼 66 2026-5-26 10:30 0
dob_C 雪币： 131 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 86 粉丝 0 关注私信	dob_C 25 楼感谢分享 2026-5-26 10:34 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

Tubbs

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (121) 1 2 3 4 5 ▶
mb_sezgvuqb 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	mb_sezgvuqb 2 楼 1 2026-5-25 13:31 0
mb_mxsesokv 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 14 粉丝 0 关注私信	mb_mxsesokv 3 楼 1 2026-5-25 13:37 0
xingbing 雪币： 158 活跃值： (5791) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1400 粉丝 2 关注私信	xingbing 4 楼学习！！！ 2026-5-25 13:46 0
mb_mlyojneh 雪币： 10 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 53 粉丝 0 关注私信	mb_mlyojneh 5 楼学习！！！ 2026-5-25 13:51 0
method 雪币： 1972 活跃值： (8178) 能力值： ( LV5，RANK：70 ) 在线值：发帖 13 回帖 268 粉丝 134 关注私信	method 1 6 楼 1 2026-5-25 14:07 0
mb_xjdhrmck 雪币： 78 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 154 粉丝 0 关注私信	mb_xjdhrmck 7 楼 6+666 2026-5-25 14:54 0
mb_dcjxxhsk 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 79 粉丝 0 关注私信	mb_dcjxxhsk 8 楼 666 2026-5-25 15:31 0
温泉划水鱼雪币： 94 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 226 粉丝 28 关注私信	温泉划水鱼 9 楼看看最后于 2026-5-25 15:33 被温泉划水鱼编辑，原因： 2026-5-25 15:32 0
乐活雪币： 2941 活跃值： (3332) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 62 粉丝 1 关注私信	乐活 10 楼 6666 2026-5-25 16:08 0
mb_jnmxfjku 雪币： 109 活跃值： (820) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_jnmxfjku 11 楼 666 2026-5-25 16:34 0
Imxz 雪币： 110 活跃值： (9571) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 775 粉丝 9 关注私信	Imxz 12 楼 tql 2026-5-25 16:45 0
小尘0000 雪币： 18 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 80 粉丝 0 关注私信	小尘0000 13 楼 666 2026-5-25 17:40 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 259 粉丝 0 关注私信	mb_cbgtaveo 14 楼 666666666 2026-5-25 17:43 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 707 粉丝 7 关注私信	mb_ldbucrik 15 楼感谢分享 2026-5-25 19:24 0
farendaibiao 雪币： 10627 活跃值： (6994) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	farendaibiao 16 楼很好的分析文章 2026-5-25 19:50 0
XCicada 雪币： 3103 活跃值： (2705) 能力值： ( LV6，RANK：80 ) 在线值：发帖 3 回帖 324 粉丝 101 关注私信	XCicada 2 17 楼 666 2026-5-25 20:17 0
悟雪币： 0 活跃值： (575) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 15 粉丝 0 关注私信	悟 18 楼 11111111 2026-5-25 20:21 0
墨穹呢雪币： 4770 活跃值： (8232) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 231 粉丝 18 关注私信	墨穹呢 19 楼感谢分享 2026-5-25 20:51 0
mb_seujxaaa 雪币： 208 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 18 粉丝 0 关注私信	mb_seujxaaa 20 楼感谢分享 2026-5-25 21:03 0
SomeMx 雪币： 4211 活跃值： (5614) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 21 楼学习 2026-5-25 21:46 0
wx_Huber Barrientos 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 216 粉丝 1 关注私信	wx_Huber Barrientos 22 楼 666 2026-5-26 03:08 0
夜惜风雨雪币： 95 活跃值： (3767) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 155 粉丝 0 关注私信	夜惜风雨 23 楼 66666666666 2026-5-26 10:17 0
guijingwen 雪币： 7377 活跃值： (7605) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 312 粉丝 0 关注私信	guijingwen 24 楼 66 2026-5-26 10:30 0
dob_C 雪币： 131 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 86 粉丝 0 关注私信	dob_C 25 楼感谢分享 2026-5-26 10:34 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复