[原创] VMP强壳还原思路之一

{
  "ctx":{
    "pc_reg":"x19",
    "ctx_base":"x23"
  },
  "handlers":[
    {"addr":"0x2c0cc0","end_addr":"0x2c0d50","name":"COMPOUND_STORE_INIT"},
    {"addr":"0x2b05f4","end_addr":"0x2b0634","name":"STORE_REG"},
    {"addr":"0x2b137c","end_addr":"0x2b13bc","name":"LOAD_INDIRECT"},
    {"addr":"0x2b2c8c","end_addr":"0x2b2cb0","name":"ret"}
  ]
}

• addr
  ：handler 入口的 offset 地址
• end_addr
  ：handler 最后一条指令地址（通常是 BR/RET），用于精确边界匹配。部分 handler 内部包含条件分支（beq、csel），会干扰边界判断，end_addr 避免了误判

从 IDA dispatch table 完整导出了 161 个 handler，覆盖所有 vm_handler_*、vm_op_*、vm_compound_*。

3.5 输出格式演进

经历了三轮迭代：

第 1 版：完整 JSON——每条 handler 输出一个对象，包含起止 index、完整指令序列、调用地址。太冗余，读完难。

第 2 版：精简带分隔符——STORE_REG: 69393 + --- 分隔。好一些但还有噪音。

最终版：代码注释风格

COMPOUND_STORE_INIT// 69357
STORE_REG           // 69393
STORE_REG           // 69409
LOAD_INDIRECT       // 69523

读起来就像代码注释，一眼看出 handler 执行序列。最直观的方案往往是最简单的。

四、IR 解释器：从 Handler 序列到中间表示

4.1 为什么需要 IR

Handler 序列只能告诉你"执行了哪些 handler"，但看不懂"这些 handler 具体在操作什么"。比如：

STORE_REG      // 69393
MOV_REG        // 69409
add_imm        // 69452
call           // 69480
load_mem       // 69523
beq            // 69556

这串序列的含义是：存一个值 → 搬一个值 → 加常数 → 调函数 → 读内存 → 条件跳转。但具体操作哪些寄存器？偏移多少？跳转到哪？

IR 的目标是把每条 handler 的编码操作数解码出来：

store_mem(VM_REG[1] + 0x1b8, VM_REG[27])
VM_REG[24] = VM_REG[10]
VM_REG[5] = 0x73665d9b18 + 0x55
call0x29bd94
VM_REG[231] = load_mem(VM_REG[55] + 0x0)
beq VR[8], +0x1c

4.2 操作数编码：从 trace 中提取语义

VMP handler 的操作数几乎都通过 ldr [X0] 或 ldr [X0, #offset] 读取。X0 指向字节码流中的编码数据，trace 记录了每次加载的值。

简单 handler（单一操作）：

; handler add_imm 的 trace 片段
ldr w9, [x0]       ; w9 = 0x0080e03c → 编码

编码解析：

→ IR：VM_REG[224] = VM_REG[60] + 0x80

复合 handler（槽位式，多操作，如 COMPOUND_STORE_INIT）：

操作数放在 [X0, #0x10]、[X0, #0x08]、[X0, #0x00] 三个不同偏移：

// COMPOUND_STORE_INIT: ADD_IMM + STORE x2
VM_REG[1] = VM_REG[0] + 0x10          // 从 [X0,#0x10] 解码
store_mem(VM_REG[0] + 0x8, VM_REG[5])  // 从 [X0,#0x08] 解码
store_mem(VM_REG[0] + 0x0, VM_REG[3])  // 从 [X0,#0x00] 解码

顺序操作数 handler（如 eor_eor_ldr_ldr_ldr）：

操作数按执行顺序从 [X0] 逐个读取，X0 自动递增：

EOR#1:  VM_REG[12] = VM_REG[3] ^ VM_REG[7]      // 第1个 ldr [X0]
EOR#2:  VM_REG[15] = VM_REG[1] ^ VM_REG[9]      // 第2个 ldr [X0]
LOAD#1: VM_REG[8]  = load_mem(VM_REG[4] + 0x20)  // 第3个 ldr [X0]
LOAD#2: VM_REG[9]  = load_mem(VM_REG[4] + 0x28)  // 第4个 ldr [X0]
LOAD#3: VM_REG[10] = load_mem(VM_REG[4] + 0x30)  // 第5个 ldr [X0]

4.3 编码模式分类

通过分析全部 161 个 handler，总结出以下编码模式：

寄存器间操作（BYTE0=src1, BYTE1=src2, BYTE2=dst）

add64, sub64, and64, orr, EOR, nor64, sltu, UMOD
→ VM_REG[dst] = VM_REG[src1] OP VM_REG[src2]

立即数操作（BYTE0=src, BYTE1=dst, HIWORD=imm）

add_imm, slti, sltu_imm, ORR_IMM
→ VM_REG[dst] = VM_REG[src] + (int16_t)imm

移位操作（BYTE1=src, BYTE2=dst, BYTE3=shift）

lsl32, lsr32_imm, lsl64_imm, ROR32, ror64
→ VM_REG[dst] = VM_REG[src] OP shift

内存加载（BYTE0=base, BYTE1=dst, HIWORD=s16_offset）

load_mem, ldrsw, LDRB, ldrh
→ VM_REG[dst] = *(type*)(VM_REG[base] + offset)

内存存储（BYTE0=base, BYTE1=val, HIWORD=s16_offset）

STORE_REG, str32, strb, STRB, strh
→ *(type*)(VM_REG[base] + offset) = VM_REG[val]

分支跳转（BYTE0=cond_reg, HIWORD 或其他复杂编码）

b, beq, bne, blt, bbit
→ beq VR[cond], +0xNN 或 bbit VR[cond], +0xNN

浮点操作（BYTE2=src, byte3_hi=dst，独立浮点寄存器文件）

fneg, fcmpeq, fceilf, dceil, dcmple, floorf, dcsel_nz
→ FLOAT_REG[dst] = -FLOAT_REG[src]

4.4 CALL 类 handler 的特殊处理

CALL 类 handler 包含 BL vm_call_dispatch，用于调用 VM 内部的子函数。实际调用目标通过追踪双层 BLR 解析：

Handler call 内部:
  BL vm_call_dispatch       ← 进入分发器
  (vm_call_dispatch 内部):
    BLRX9                  ← 第1个 blr，wrapper 函数
    (wrapper 内部):
      BLRX8                ← 第2个 blr，实际目标函数！
        0x29bd94: stp ...   ← 目标函数第一条指令

→ IR: call 0x29bd94

4.5 解释器架构

所有 IR 逻辑集中在单文件 src/handler_interpreter.cpp（约 3800 行）：

// 操作数提取
get_operand(h, insts, encoded)            // 简单 handler
get_operand_at(h, insts, x0_offset, val)  // 槽位式
get_nth_x0_load(h, insts, n, val)         // 第 N 个顺序操作数
find_blr_target_after_bl(...)             // BLR 分发目标追踪

// 编码解码
decode_store(op, base, val, offset)       // STORE 模式
decode_load(op, base, dst, offset)        // LOAD 模式
decode_mov(op, src, dst)                  // MOV_REG 模式
decode_add_imm(op, base, dst, imm)        // ADD_IMM 模式

// 每个 handler 一个 interpret_xxx() 函数
// dispatch: if (name == "STORE_REG") return interpret_store_reg(...);

4.6 覆盖率：161/161

五、工程优化：BL 折叠与嵌套 VMP 处理

5.1 问题

VMP handler 中经常通过 BL 调用 native 函数。trace 会逐条展开 native 函数内部的几百上千条指令。不处理的话：

• handler 指令数暴增（被 native 函数"撑大"）
• 超过 500 条限制时触发警告或截断
• 无法提取 handler 的"真实逻辑"

5.2 初版方案：基于 offset 的栈折叠

// BL 入栈
if (mnem == "bl" || mnem == "BL") {
    uint64_t return_offset = curr_offset + 4;
    bl_stack.push_back(return_offset);
}

// 返回检测（offset 匹配栈顶 → 出栈）
if (!bl_stack.empty() && curr_offset == bl_stack.back()) {
    bl_stack.pop_back();
}

// 栈不为空 = 在 native 函数内部，跳过
if (!bl_stack.empty()) {
    continue;  // 折叠
}

69480: ldrw8, [x0]           ← handler 指令
69481: bl#0x2ced14           ← BL 入栈，记录 return_offset = 69485
69482: [native 100条指令...]   ← 折叠跳过
69582: (offset=0x69485)       ← 匹配栈顶 return_offset，出栈
69583: lsrx8, x28, #0x3c     ← 继续 handler 指令
...
69600: brx10                 ← handler 结束

Handler A
  BL native_func           ← 栈：[返回地址]
    (native 代码)
    遇到 VMP handler B     ← 栈不为空 → 被错误跳过！
      BRX8                ← 也被跳过
    (更多 native 代码)
  返回                     ← 出栈
Handler A 继续

if (!bl_stack.empty()) {
    // 检查是否是已知 handler 入口（嵌套 VMP 开始）
    if (handler_map_.find(curr_offset) != handler_map_.end()) {
        // 嵌套 VMP 的 handler 入口，不跳过，正常处理
    }
    // 检查是否是 BR 指令（可能是 handler 结束）
    elseif (mnem == "br" || mnem == "BR") {
        // 可能是 handler 结束或 VMP dispatch，不跳过
    }
    else {
        // 真正的 native 代码，折叠跳过
        continue;
    }
}

Handler A
  [前置逻辑]
  BL native_func         ← 入栈
    [native 代码 100 条] ← 全部折叠
  返回                   ← 出栈
  [后续逻辑]
  BR X8                  ← handler 结束

Handler A
  BL native_func         ← 入栈
    [native 前置代码]    ← 折叠
    Handler B 入口       ← handler_map 命中，不折叠
      [B 的逻辑]
      BRX8              ← BR 命中，不折叠
    [native 后续代码]    ← 继续折叠
  返回                   ← 出栈
  Handler A 继续

Handler A
  [A 的逻辑]
  Handler B 入口         ← 栈为空，正常识别
    [B 的逻辑]
    BR X8
  Handler A 继续         ← 栈为空，正常识别

Handler A
  BL native1             ← 栈：[ret1]
    BL native2           ← 栈：[ret1, ret2]
      Handler B 入口     ← 命中，不折叠
        [B 的逻辑]
        BR X8
      [native2 代码]    ← 折叠
    返回                 ← 栈：[ret1]
    [native1 代码]       ← 折叠
  返回                   ← 栈：[]
  Handler A 继续

for addr_str, end_str, name in handlers:
    func = ida_funcs.get_func(addr)          # L1: addr 是函数起始？
    last_insn = idc.prev_head(func.end_ea)   # L2: end_addr 是最后一条指令？
    mnem = idc.print_insn_mnem(end)          # L3: 最后一条是 BR/RET？

# 基础模式：只输出 handler 序列
./build/duckrevm trace_logs/code.log -o build

1. 运行工具 → 遇到未知 handler 停下
2. 去 IDA 分析该 offset 地址的函数
3. 确定 handler 名称和编码格式
4. 添加到 handlers_config.json
5. 在 handler_interpreter.cpp 中添加 IR 解码逻辑
6. 重新编译运行 → 继续到下一个未知 handler
7. 重复直到还原完毕