Key Conclusions#

• The WeChat 8.7.0 RQTX path can be split into seven stages: ObjC anchor, slot/body proof, VM init and layout proof, payload dump, runner localization, CFG skeleton stripping, and offline runtime verification.
• rqtx.dat is not just an opcode list. It behaves like a packaged VM image that contains an opcode map, payload image, relocation/export slots, and internal VM blocks.
• RQTX IRVMP instruction decoding depends on raw_word, the current IP, and the opcode map. The same high six bits can map to different semantics at different IPs.
• Version migration should preserve the evidence chain and layout relationships instead of directly reusing old runtime addresses.
• The offline runtime is useful only when it reconstructs the VM image, context, handler semantics, and observed traffic behavior. A single hook return value is not enough.

The reading path has four parts. First, we straighten the call chain. Then we explain how the VM image and context are initialized. After that, we recover instruction decoding and the CFG-obfuscated runner. Finally, we reduce the evidence into an offline runtime and a version-migration method.

Keywords And Terms#

Related articles are collected in the WeChat RQTX IRVMP Research Index.

RQTX is difficult because several protection layers are stacked together:

• the upper layer is an Objective-C selector that provides a stable business entry;
• the middle layer contains native stages that are flattened by CFG and are responsible for object construction, runtime handles, entry parsing, and bridging;
• the lower layer is an IRVMP runner that interprets rqtx.dat;
• the data layer includes an opcode map, payload image, relocation slots, and VM context;
• the dynamic-analysis layer must handle ASLR, thread noise, hot-path overhead, and watchdog or re-entry behavior.

For this kind of target, reading one pseudo-code fragment and making a conclusion is risky. The recovery method should make every conclusion falsifiable: the static address should match, the dynamic path should be hit, the VM state should explain the behavior, and the offline runtime should reproduce the observed result. Anything that cannot pass that bar stays marked as unknown.

Overall Path#

The first object to recover is the live path. Without it, every later statement about rqtx.dat, VM context, or the runner is floating. With it, the high-level selector, body wrapper, bridge, and VM runner can be placed on the same graph.

The live path can be summarized as:

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

The slot chain is not a single jump. After the calRqtData layer loads the slot, the analysis still needs to follow a thunk chain through several wrappers before reaching the body dispatch stage. Stopping at the first dispatcher makes the wrapper look like the algorithm, which is the wrong boundary.

The role table is more important than the raw address values:

IRVMP Design Model#

The entry and slot chain answer “where does execution go?” The next question is “why does the code not look like a normal native algorithm after we arrive there?” The answer is the IRVMP layering.

The RQTX IRVMP can be understood as five layers.

The first layer is the packaged VM image. The core logic is not simply hard-coded inside a native function. It is expressed by a VM image carried by rqtx.dat, and the native runner interprets that image.

The second layer is an objectized runtime. rqtx.dat is not executed as a raw file. It passes through global initialization, provider or handle management, blob getters, and context getters before it becomes the runtime object used by the bridge.

The third layer is VM context. Each bridge call prepares a context buffer that contains a register file, IP, next IP, VM state slots, and memory-window pointers.

The fourth layer is IP-aware instruction decoding. Opcode extraction is not merely word >> 26. The decoder mixes the current IP and the opcode map. Register fields are also XOR-obfuscated.

The fifth layer is native runner obfuscation. The interpreter itself is flattened by CFG and contains a main dispatcher, sub-dispatchers, selector state, and shared tails.

These layers create a typical protected target: static analysis cannot see the whole algorithm, dynamic trace is noisy, and dumped data cannot run directly unless relocation and context are reconstructed.

rqtx.dat Layout#

After the model is clear, the bottom layer is the VM image. rqtx.dat carries the VM data and the protected logic. If this layout cannot be explained, the later init, decode, and runtime recovery have no stable foundation.

The recovered model treats rqtx.dat as a packaged image:

The important observation is that the native runner and the VM image are coupled. A dump of the file is useful only after the loader relationship is understood: which bytes are copied, which pointers are rewritten, and which slots are interpreted as runtime state.

VM Initialization#

The initialization stage turns a data file into a runtime object. The useful proof is not just “this function touches the file.” The proof is a sequence:

1. A global initialization path obtains or constructs the RQTX provider.
2. A handle-like object is used by later calculation stages.
3. The VM bridge asks for a blob and a context.
4. The context gets filled with register and memory-window state.
5. The runner receives the context and begins interpreting payload instructions.

In practice, the init path should be verified from both directions. Static analysis gives the object graph and field offsets. Dynamic instrumentation confirms that the same fields are read and written during a live call. When those two views agree, the layout becomes reliable enough for offline reconstruction.

VM Context#

The VM context is the boundary between native code and the virtual machine. It is where VM registers, IP, state slots, memory windows, and temporary buffers become observable.

A useful context model separates fields by behavior:

1
VmContext
2
  registers[...]
3
  ip
4
  next_ip
5
  state_slots[...]
6
  memory_windows[...]
7
  bridge_input
8
  bridge_output

The field names are not guessed from a single snapshot. They are assigned after repeated calls show stable read/write behavior. For example, a field that advances with every decoded instruction is an IP candidate. A field that is read by memory-like handlers and points into the staged input is a memory-window candidate. A field that receives the final short integer is an output slot candidate.

This is also where dynamic trace becomes useful. It does not need to record every native instruction. It needs to show which context fields change at block boundaries and which changes are correlated with input staging, loop execution, or final output.

Instruction Encoding#

The RQTX VM instruction word is not decoded by a plain fixed-format table. The high bits, register fields, immediate fields, current IP, and opcode map all participate.

The recovery model uses four public-facing formats:

Instruction Semantics#

Instruction semantics should be recovered from handler behavior, not from names assigned too early.

A stable workflow is:

1. Decode a candidate instruction word.
2. Identify which handler block the native runner enters.
3. Trace context reads and writes around that handler.
4. Compare the behavior with a small set of semantic templates: move, add, xor, rotate, load, store, branch, compare, call-like transition.
5. Add the handler to the offline runtime only after repeated samples agree.

This is slower than naming everything from pseudo-code, but it avoids a common failure: one misleading Hex-Rays expression can create a wrong handler, and then every later algorithm-level conclusion is built on it.

Runner Execution Model#

The runner is an interpreter hidden inside flattened native code. The useful mental model is:

1
while running:
2
  raw_word = load(ip)
3
  opcode = decode(raw_word, ip, opcode_map)
4
  handler = dispatch(opcode)
5
  handler(context, raw_word)
6
  ip = context.next_ip

The real implementation is less clean. Dispatch state can be encoded in selector variables, multiple tails can be shared, and IP updates can be split across blocks. Still, the interpreter model gives us a target shape. Every recovered block should eventually fit into decode, dispatch, handler, or next-IP update.

CFG Flattening#

CFG flattening makes the native runner look like a dense loop of selector updates. The recovery goal is not to produce beautiful native pseudo-code. It is to strip away the dispatcher skeleton until handler boundaries become visible.

The practical method is:

• collect dynamic block coverage under controlled inputs;
• identify the main dispatcher and sub-dispatcher states;
• remove common tails and selector plumbing from the analysis view;
• group blocks that always appear together as handler candidates;
• compare the grouped behavior with context diffs.

Once this is done, the runner stops looking like one giant function and starts looking like a table of VM handlers.

No-CFG Recovery#

The no-CFG view is a cleaned control-flow skeleton. It is not a recompiled program and should not be treated as one. It is an analysis view that keeps semantic blocks and removes dispatcher noise.

The value of this view is speed. It allows the analyst to ask simple questions:

• which block loads the next VM word;
• which block reads the opcode map;
• which block writes output;
• which block updates IP;
• which blocks only move selector state.

That separation is enough to drive the offline runtime implementation.

Deep Runner Localization#

Two heuristics are especially useful when the runner is buried behind wrappers.

Live Body#

The live body stage connects the top-level request path with the VM. It receives normalized input, enters the RQTX calculation chain, and eventually produces the short result.

This boundary is important because it prevents two mistakes:

• treating request normalization as the protected algorithm itself;
• treating a low-level VM block as the public API boundary.

The live body gives the offline runtime its external contract: normalized input in, short RQTX value out.

Recovery Workflow#

Difficult Cases#

Offline Runtime#

The offline runtime is the final integration point. It should not be a pile of copied pseudo-code. It should look like a small interpreter:

1
load_image(rqtx_dat)
2
build_context(input)
3
while context.running:
4
  instruction = decode(image, context.ip)
5
  execute(instruction, context)
6
return context.output

The runtime has three jobs:

1. reproduce observed behavior;
2. make handler semantics testable;
3. serve as a version-migration oracle.

It is acceptable for the runtime to contain unknown handlers during early recovery. What matters is that the known handlers are named, tested, and tied back to trace evidence.

Version Migration#

Version migration should start from the previous evidence chain:

• find the new stable entry;
• re-follow the slot chain;
• re-prove the body wrapper;
• rebuild the VM init and context layout;
• compare rqtx.dat image structure;
• re-rank runner candidates by dynamic effect;
• port handler semantics only after decode and context behavior match.

This approach avoids the most fragile migration pattern: copying addresses from one version into another and hoping the structure stayed identical.

Review#

The main lesson is that RQTX IRVMP recovery is not a single trick. It is a layered reconstruction problem. The useful output is not “we hooked the return value.” The useful output is a model where entry, data image, context, instruction decode, runner behavior, and offline verification all support each other.

That model also makes the next article possible: once the runtime can be observed and replayed, the next step is to lift the VM behavior into a semantic algorithm that can be compared with standard hashing structures.

FAQ#