关键结论#

• WeChat 8.7.0 的 RQTX 链路可以拆成 ObjC anchor、slot/body proof、VM init/layout proof、payload dump、runner localization、CFG skeleton stripping、offline runtime verification 七个阶段。
• rqtx.dat 不是单纯 opcode 列表，而是由 opcode map、payload image、relocation/export slots 和内部 VM blocks 组成的 packaged VM image。
• RQTX IRVMP 的 opcode decode 同时依赖 raw_word、当前 IP 和 opcode map；相同高 6 位在不同 IP 上可能解出不同语义。
• 对 WeChat RQTX 做版本迁移时，应该迁移证据链和布局关系，而不是直接复用旧版本 runtime address。
• 离线 runtime 的目标是复现 VM image、context、handler semantics 和 observed traffic，而不是只拿到一次 hook 返回值。

阅读顺序可以简单理解成四段：先把调用链拉直，再解释 VM image 和 context 如何被初始化；接着看指令如何被解码、runner 如何被 CFG 隐藏；最后把这些证据收束成离线 runtime 和版本迁移方法。每一段都回答一个问题：下一层为什么能被信任。

关键词与术语#

相关内容会持续整理到 WeChat RQTX IRVMP 研究索引。

rqtx 的难点不在单个函数，而在多层保护叠加：

• 上层是 Objective-C selector，提供稳定业务入口。
• 中层是多个被 CFG 扁平化的 native stage，负责对象构造、runtime handle、entry 解析和 bridge。
• 底层是一个解释执行 rqtx.dat 的 IRVMP runner。
• 数据层还有 opcode map、payload image、relocation slots 和 VM context。
• 动态分析层必须处理 ASLR、线程噪声、热路径卡顿和 watchdog re-entry。

这类目标最怕只看一段伪代码就下结论。我的处理方式是把每一层都做成可反驳的结论：静态地址能对上，动态路径能命中，VM 状态能解释，离线 runtime 能复现 observed 行为。做不到这一点的地方，就保留为 unknown。

总体链路#

先看 live path。没有这条链，后面所有关于 rqtx.dat、VM context 和 runner 的分析都会悬空；有了它，才能把高层 selector、body wrapper、bridge 和 VM runner 放到同一张图里。

rqtx 的 live path 可以归纳成下面这条链：

1
WCCalRqtDataMgr
2
  - calRqtData:len:cmd:uin:
3
    -> slot 0x28 dispatcher / wrapper
4
      -> rqtx_md5_body_dispatch        sub_112E270BC
5
        -> rqtx_calc_stage_dispatch    sub_112D3B6A0
6
          -> rqtx_vm_bridge            sub_112D3AF68
7
            -> rqtx_vm_runner_flat     sub_112E16DB0
8
              -> rqtx.dat + VM context + opcode map

当前版本的关键静态地址如下：

下面这组地址用于串起静态入口、动态命中和运行时对象，重点是层级关系，而不是孤立 offset。

slot 解析也不是一跳到位。从 calRqtData 看到 0x28 后，还要继续解析 thunk chain：

1
calRqtData loads slot 0x28
2
  -> sub_107C0CCA8
3
    -> sub_1129EA5F4
4
      -> sub_112B6CD80
5
        -> thin wrapper
6
          -> sub_112E270BC

这个步骤很重要。如果停在第一个 slot dispatcher，会把包装层误判成算法主体。

IRVMP 的设计思路#

入口和 slot chain 解决的是“走到哪里”。下一步要解释的是“为什么走进去以后看不到普通 native 算法”。答案在 IRVMP 的分层设计里。

rqtx 的 IRVMP 可以理解成五层设计。

第一层是 packaged VM image。核心数据不是硬编码在 native 函数里，而是封装在 rqtx.dat 中。native runner 只负责解释执行，具体逻辑和数据通过 VM image 表达。

第二层是 objectized runtime。rqtx.dat 不会直接以文件形态执行，而是经过全局 init、provider/handle 管理、blob getter、context getter 之后，变成 runtime 对象。

第三层是 VM context。每次调用 bridge 都会准备一个上下文缓冲区，里面既有寄存器文件，也有 IP、next IP、VM state slot、内存窗口指针。

第四层是 IP-aware instruction decode。指令的 opcode 不只是 word >> 26，还会混入当前 IP，并通过 opcode map 翻译。寄存器字段也经过 XOR 混淆。

第五层是 native runner obfuscation。真正解释 VM 指令的 runner 又被 CFG 扁平化，内部有 main dispatcher、sub dispatcher、selector state 和 common tail。

这几层叠在一起，形成了一个典型保护目标：静态看不到完整算法，动态 trace 容易混入噪声，dump 出来的数据如果不重建 relocation 也不能直接运行。

rqtx.dat 布局#

理解了分层以后，先看最底下的 VM image。rqtx.dat 是业务逻辑和 VM 数据的承载体；如果这个布局解释不通，后面的 init、decode 和 runtime 都没有稳定基础。

rqtx.dat 不是单纯的 opcode 列表。当前恢复模型中，它由 opcode map、payload image、relocation/export slots 和内部 VM blocks 组成。

runtime patch slots 的当前映射如下：

这解释了一个容易误判的问题：live dump 和旧 payload 如果只在 patch-slot 附近出现少量差异，并不必然代表算法重写。那些位置是 runtime relocation/patch bytes，会随 payloadBase 改变。正确做法是先用 relocation model 解释差异，再判断 VM bytecode block 或 data block 是否发生结构变化。

VM 初始化#

布局只是静态模型。VM 初始化要证明这份模型真的在运行时成立：blob 怎么 objectize，payload 怎么落到内存，patch slot 怎么被改写，每次调用又如何拿到自己的 context。

IRVMP 的 init 阶段不是“读一个 blob”这么简单。它至少完成四件事：

1. 从 rqtx.dat 拆出前 0x200 字节，构造 opcode map 对象。
2. 把 payload image 复制到 page-aligned runtime memory。
3. 根据 payload 内部表重写 relocation/export slots。
4. 准备每次调用的 VM context 和初始 IP。

当前 IDA init pipeline 为：

VM-init 阶段不能只写一句“dump 成功”。最少要回答：

1
global init body = sub_112E283A8
2
blob-returning function = sub_112E0E210
3
context-returning function = sub_112E265EC
4
per-call context init = sub_112D3AF68
5
0x80418 layout proof = 0x112D3B1FC - 0x112D3B21C

并且必须区分：

• 静态稳定点：IDA 函数和 call site。
• 动态运行点：blobPtr、headerPtr、ctxPtr、slot80418。

动态指针会因为 ASLR/restart 改变，不能作为版本迁移的核心依据；真正可迁移的是 IDA point set 和布局关系。

VM Context#

初始化证明了 VM image 能被装载，context 则解释一次调用如何进入 VM。这里开始，分析对象从“全局 runtime”切到“单次 RQTX 计算”。

离线 runtime skeleton 中，context buffer 大小约为 0x80440，关键字段如下：

bridge-like 初始化可以抽象成：

1
ctx[0x10084] = entryLike;
2
ctx[0x10085] = entryLike;
3
*vmStateSlot = defaultHaltLikeValue;
4

5
ctx[0] = reg0;
6
ctx[1] = reg1;
7
ctx[2] = reg2;
8
ctx[3] = reg3;
9

10
rqtx_vm_runner_flat(ctx, blob);
11
return ctx[0];

旧版兼容路径中，默认入口是 main_memory + 0x4000，寄存器形态接近：

1
reg0 = md5_32
2
reg1 = 0x20
3
reg2 = out_value
4
reg3 = out_len

当前 870 bridge-like 路径仍然把 entry_like、md5_32、reg1/reg2/reg3 作为独立建模对象，这是为了避免把旧版本参数约定强行套到新版 live path 上。

指令编码#

有了 image 和 context，还不能直接执行 VM。runner 每取到一个 word，都要先通过 IP-aware decode 把它变成可解释的 opcode 和 operand。

runner 的 fetch-decode-execute 模型大致如下：

1
current_ip = ctx.ip
2
raw_word   = *(uint32_t *)current_ip
3
ctx.ip_storage = current_ip
4
ctx.ip = current_ip + 4
5
decoded = decode(raw_word, current_ip, opcode_map)
6
execute(decoded)

原始 opcode 先来自高 6 位：

1
raw_opcode = raw_word >> 26

但如果当前指令地址不是默认 halt-like buffer，还会混入 IP：

1
raw_opcode ^= (current_ip >> 8) & 0x3f

之后再查 opcode map：

1
if opcode_map[2 * raw_opcode] != 0:
2
    opcode = opcode_map[2 * raw_opcode + 1]

这说明 opcode 不是静态全局表，而是由 raw_word、current_ip 和 opcode_map 联合决定。这个设计会直接破坏简单的字节码反汇编器，因为相同高 6 位在不同 IP 上可能解出不同语义。

寄存器字段也不是直接读取。旧模型中的几类格式如下。

1
rs = ((word >> 12) & 0x7f) ^ ((word >> 19) & 0x7f)
2
rt = ((word >> 19) & 0x7f) ^ reg_field
3
imm = sign_extend(word & 0xfff, 12)

1
rd  = ((word >> 5)  & 0x7f) ^ ((word >> 12) & 0x7f)
2
rs  = ((word >> 12) & 0x7f) ^ ((word >> 19) & 0x7f)
3
rt  = ((word >> 19) & 0x7f) ^ reg_field
4
imm = word & 0x1f

1
rt  = ((word >> 19) & 0x7f) ^ reg_field
2
imm = sign_extend(word & 0x7ffff, 19)

1
imm = sign_extend(word & 0x3ffffff, 26)

1
reg_field = (current_ip >> 2) & 0x7f

指令语义#

编码解决“字段怎么取”，语义解决“这条指令到底做什么”。这一步要谨慎：能命名的就命名，证据不足的要保留不确定性。

旧模型中的 Opcode870 覆盖了 0x00..0x37 范围内的 VM opcode。可以按语义分组理解：

870 live-hit runner 里确认过一组 selector 到 semantic 的绑定。注意：这些 selector 是 native runner 内部状态/分派值，不应该直接等同于 VM raw opcode。

store byte 当前仍属于 best-fit 语义，而不是完全闭合的静态证明。证据来自 live body 0x112e18d78 .. 0x112e18d98 和前驱状态链，runtime skeleton 也明确把这种不确定性保留在注释里。这种标注方式比强行填满 opcode 表更可靠。

Runner 运行模型#

单条指令的语义只是局部真相。runner 运行模型要把 current_ip、decode、writeback、next IP 和 halt reason 连起来，才能支撑后面的 CFG 剥离和离线执行。

runner 每一步都要维护几个状态：

离线 runtime 还补了 halt reason，用于定位还原不完整的位置：

1
Running
2
MaxSteps
3
Returned
4
IpOutOfWindow
5
DecodeRejected
6
MemOutOfRange
7
UnknownSemantic

这对 flywheel 很重要。一次回归用例不匹配时，不能只看 expected/actual，还要看是 decode 被拒绝、IP 跳出窗口、内存越界，还是某个 semantic 仍未知。

CFG 扁平化#

到这里，VM 的正常解释器模型已经清楚了；真正挡住还原的是 native runner 自身的 CFG 扁平化。下面这一步不是继续猜伪代码，而是先把稳定执行路径从噪声里分出来。

rqtx_vm_runner_flat 的静态范围约为：

1
0x112E16DB0 .. 0x112E1A138

如果直接看 F5，几乎一定会被 dispatcher 状态污染。我采用的规则是：

1. 先确认 target function 已经在 live path 上。
2. 从 bridge 进入时打开同线程 trace 窗口。
3. 记录 basic block starts，不做全指令热路径 trace。
4. 将结果分成 bridgeLeave 和 watchdog 两类。
5. 只把稳定的 bridgeLeave 路径作为 canonical semantic source。
6. 剥离 main dispatcher/sub dispatcher，再从 real blocks 重建 no-CFG pseudocode。

runner 稳定性验证不应该只看“是否进入过函数”，而要看多轮冷启动下 canonical path 是否收敛。判断标准是：

intersection == union 是关键判断：同一条业务路径在多轮冷启动中得到一致的 block-start 集合，才可以作为当前 traffic class 的 canonical real path。

watchdog 结果则只作为 secondary evidence。只要它出现 late noise 或 re-entry，就不能直接合并进语义表。

No-CFG 还原#

CFG 恢复的目标不是得到一张更漂亮的控制流图，而是把 flattened native 重新表达成“取指、解码、执行、写回”的解释器结构。

CFG 剥离后，runner 的 no-CFG 重建不是“美化反编译”，而是重新表达真实执行模型：

1
fetch raw instruction
2
decode opcode through IP-aware opcode map
3
decode operand family
4
map selector to semantic
5
execute micro-op
6
update writeback / memory / next_ip
7
loop

分类时要区分四类 block：

因此，runner 还原的核心不是保存一份庞大的 trace，而是把“扁平化后的 native 控制流”转回“VM 解释器的正常逻辑”：哪些 block 只负责调度，哪些 block 负责解码，哪些 block 负责具体 micro-op。

深层 Runner 定位#

前面为了讲清楚机制，已经把 runner 当成一个确定对象。实际工作里，runner 本身也要被证明出来；否则很容易把 bridge、wrapper 或 timing helper 误当成 VM 主循环。

runner 定位不能把 sub_112E16DB0 当成预设答案，而是要让两个独立启发式收敛。

1
bridge_enter
2
  tick_leave
3
  runner_enter
4
  runner_leave
5
  tick_leave
6
bridge_leave

1
sub_112E270BC
2
sub_112D3B6A0
3
sub_112D3AF68
4
sub_112E16DB0

Live Body#

runner 是最深的一层，body 则是它的上游边界。把 body 讲清楚，是为了确认 VM 收到的到底是什么输入，以及 high-level 返回值和 VM 返回值是否在同一条链路上。

sub_112E270BC 不是最终 VM runner，而是一个 flattened body stage。当前 live path 已确认它接收：

1
x0 -> 32-character ASCII hex string
2
x1 -> length = 32
3
x2 -> cmd
4
return -> uint32

body input shape 被证明之后，就不能再把它称为 raw packet stage。正确解释是：

1
calRqtData receives raw request buffer
2
upstream chain transforms it
3
sub_112E270BC receives md5-like 32-byte hex string + cmd
4
body return equals high-level calRqtData return

验证时关注的是关系：输入长度、字符类别、命令号、返回值类型，以及 body return 是否等于高层 return。

body 自身也被 CFG 扁平化。当前 live-path 语义证明了它会构造一个短 key buffer，执行已观察到的 byte transform stage，然后把 local object、runtime handle、md5-like input 和 cmd 传给 calc stage。这里仍然强调“live-path”：未命中的错误分支和其他 traffic class 不能随便写成死代码。

还原流程#

前面的章节按对象展开，读起来像一组局部证明。真正落地时，需要把这些证明编排成一个可重复流程：先证明入口，再证明数据，再证明 runner，最后证明离线 runtime。

这次 rqtx 最有价值的部分不是单个 hook，而是把逆向流程拆成几个稳定阶段。每个阶段只证明一件事，证明不了就停在当前层，不把猜测带到下一层。

1
trace design
2
block universe
3
CFG role table
4
real-block set
5
real execution order
6
real-block disassembly
7
no-CFG pseudocode
8
stability conclusion

1
VM init model is reproducible
2
observed traffic can be replayed offline
3
unknown selectors remain explicitly marked
4
version migration has a fixed proof sequence

1
Claim:
2
  deeper runner is localized.
3

4
Static evidence:
5
  effective call list reaches bridge -> runner.
6

7
Dynamic evidence:
8
  timestamp wrapper surrounds the candidate;
9
  same-thread ranking and function size agree;
10
  bridgeLeave path is stable across cold spawns.
11

12
Runtime evidence:
13
  no-CFG pseudocode feeds an offline VM model;
14
  observed traffic verifies the restored semantics.

难点处理#

流程看起来线性，实际最容易出错的地方都在边界：伪代码边界、trace 边界、版本边界和采样边界。下面这些问题如果不提前处理，后面的语义化会被噪声拖偏。

1
pointer-only capture first
2
second-phase dump later
3
same-thread short-window trace
4
block-start only by default

离线 Runtime#

当 no-CFG 语义表积累到一定程度后，下一步不是继续堆 hook，而是把 VM 运行环境搬到离线模型里。这样每次修改 decode 或 handler，都能快速回归。

离线 runtime 的任务是复现 VM 运行环境，而不是只翻译几个 handler。它要模拟：

• opcode map header。
• page-aligned main memory。
• memory region tree。
• payload copy。
• relocation patch slots。
• context buffer。
• IP 和 next IP storage。
• handler semantics。
• halt reason 和 validation result。

runtime skeleton 中的 flywheel 包含两类执行入口：

验证循环不是一次性写完，而是：

1
recover selector/handler
2
run offline replay
3
compare expected/actual
4
inspect halt reason
5
patch decode or semantic
6
repeat until matched=true

离线回归关注输入形态、命令类别、长度区间、返回值一致性和失败原因。这样 verifier 能证明语义闭合，也不会把采样内容和还原逻辑混在一起。

版本迁移思路#

离线 runtime 的另一个价值，是给未来版本迁移留下路线。迁移时不要从“旧 runner 地址”开始，而要从“旧证明流程”开始。

下一次版本迁移时，不应该从 runner 开始，而应该沿着同一条证据链重新证明：

1. ObjC anchor 是否仍是 WCCalRqtDataMgr - calRqtData:len:cmd:uin:。
2. slot 0x28 是否仍解析到同类 body。
3. body 输入是否仍是 32 字节 ASCII hex + cmd。
4. VM init point set 是否仍能解释 blobPtr/headerPtr/ctxPtr/0x80418。
5. rqtx.dat layout 是否仍是 opcode map + payload image + relocation slots。
6. runner candidate 是否被 timestamp wrapper 和 ranking 同时支持。
7. bridgeLeave trace 是否能三次 cold spawn 收敛。
8. offline runtime 是否仍能验证 observed traffic。

这样迁移时就不会被单个 offset 变化打乱。变化会被定位到具体层：入口、slot chain、VM init、blob layout、runner CFG、指令语义或 bridge 参数。

复盘#

回头看，第一篇真正想建立的是一种拆解方式：先把保护结构拆成可命名对象，再把每个对象放回证据链里验证。

rqtx 的 IRVMP 设计核心是“数据和解释器分离”：业务逻辑被放进 rqtx.dat 的 VM image，native runner 负责解释，context 承载调用状态，opcode map 和 IP-aware decode 增加静态分析成本，CFG 扁平化再隐藏 runner 的真实 micro-op。

逆向上对应的解法也是分层的：

1
ObjC anchor
2
  -> slot/body proof
3
    -> VM init/layout proof
4
      -> payload dump and relocation model
5
        -> runner localization
6
          -> CFG skeleton stripping
7
            -> no-CFG semantic table
8
              -> offline runtime
9
                -> observed traffic verification

这条链路的价值不在“拿到一个返回值”，而在可审计：每个结论都能追到一个静态地址、一次 live trace、一类动态证据或一条离线验证记录。对专业逆向工程来说，这比单次成功 hook 更重要。

常见问题#