TaskAgent Reverse Lab

WeChat 8.7.0 ClientCheckData White-Box AES: From AES-CBC to 03/08 Table Interpreter Recovery

Mon, 11 May 2026 00:00:00 GMT

The first two RQTX articles focused on VM runtime observation, trace aggregation, and semantic hash recovery. This third article moves to another piece of the WeChat 8.7.0 request-protection surface: the white-box AES used around client check data.

This component does not look like a normal AES-CBC(key, iv, data) library call. It behaves more like a table interpreter. The runtime code is mostly stable, while the concrete algorithm instance is carried by a PB template. That template contains an IV, TableKey, TableValue, FinalTable, and a few profile fields. The interpreter feeds those tables round by round and eventually emits ciphertext that is semantically equivalent to AES-128-CBC.

This is a common industry pattern. A protocol wants to preserve AES-CBC semantics, while the client wants to avoid shipping a raw AES key as a normal constant. The key schedule, SBox, MixColumns contribution, and final round key material are folded into lookup tables. The key does not appear as a plain source constant, but the computation still needs the equivalent material somewhere.

The article starts from standard AES-CBC, then peels into the 03/08 table interpreter, how traces reveal the algorithm boundary, how key/IV recovery works, and how the edge challenge vector can be used for reverse validation.

Key Findings#

The client check data encryption path is semantically AES-128-CBC: data is processed in 16-byte blocks, each block is XORed with the IV or previous ciphertext block, then encrypted.
The runtime is not a normal AES implementation. It is a PB-template-driven white-box table interpreter: runtime code = interpreter, PB template = concrete AES instance.
00000008 has a weak FinalTable shape. Each byte lane can be fitted as an AES final-round SBox lane, yielding the round-10 key and then the AES-128 master key through inverse key schedule.
00000003 adds byte-level encoding. Its FinalTable no longer directly reveals the final-round key, but the hidden XOR coordinates can still be recovered from TableValue, allowing first-round TableKey fitting.
In 8.7.0, the VER08 template is best modeled as descriptor plus template blob plus length plus transform gateway. The gateway materializes protobuf wire records into a typed object before the later OLLVM-style table interpreter consumes them.
The IV is not a cryptanalytic problem. It is a CBC chaining value carried by the template. Stronger protection needs per-message IV policy, template integrity, stronger table encoding, and cross-byte fusion.
The page challenge is generated by an edge function. Every refresh produces a random hex input and the corresponding 03/08 AES-CBC ciphertexts for validation against a hook, offline interpreter, or recovered standard AES implementation.

Edge-Generated White-Box AES Challenge#

The vector below is generated when the page loads. Every refresh creates a new 24-byte hex input. The server applies the client check data block-padding semantics and returns ciphertext for both 00000008 and 00000003 profiles.

The browser receives only the input, lengths, padding mode, and ciphertexts. The profile key/IV material is used server-side.

If the card says the server profile is not configured, the deployment has not received the 03/08 equivalent profiles yet. The edge function fails closed and does not return placeholder ciphertext.

White-box AES Challenge Generating

input_kind: hex_bytes
input_hex: loading
input_length: - bytes
padding: -
padded_length: - bytes
00000008 cipher_hex: -
00000008 profile_source: -
00000003 cipher_hex: -
00000003 profile_source: -
generated_at: -

Start With Plain AES-CBC#

White-box AES is easier to understand once the plain CBC layer is clear:

1
ciphertext = AES-CBC-Encrypt(key, iv, plaintext)

CBC mode is short:

1
C[-1] = IV
2

3
for each 16-byte plaintext block P[i]:
4
    X[i] = P[i] xor C[i-1]
5
    C[i] = AES_Encrypt(K, X[i])

AES-128 block encryption then follows the familiar round structure:

1
state = input
2
state = AddRoundKey(state, K0)
3

4
for round 1..9:
5
    state = SubBytes(state)
6
    state = ShiftRows(state)
7
    state = MixColumns(state)
8
    state = AddRoundKey(state, Kround)
9

10
state = SubBytes(state)
11
state = ShiftRows(state)
12
state = AddRoundKey(state, K10)

SubBytes is the byte SBox, ShiftRows rotates rows in the 4x4 state, MixColumns linearly mixes each column, and AddRoundKey XORs round-key bytes into the state. AES-128 has eleven round keys, K0..K10.

A normal implementation often exposes AES constants, SBox tables, T-tables, key schedule code, or a library call boundary. A white-box implementation tries to remove those obvious shapes from source code by folding them into tables.

The White-Box Intuition: Turn Formulae Into Tables#

A normal AES round can be viewed as:

1
output_column = MixColumns(SubBytes(input_column xor round_key_column))

A white-box implementation precomputes pieces of that relation:

1
TableKey[position][input_byte] -> contribution bytes

The runtime uses the current state byte as a lookup index, obtains contribution bytes, and then combines those contributions through another table:

1
TableValue[encoded_contribution_0, encoded_contribution_1, ...] -> output_byte

The source no longer contains a clear SBox[x xor key] expression, nor a visible MixColumns formula such as 2*x ^ 3*y ^ z. It mostly contains indexing, offsets, and byte movement.

For the 03/08 family, the core model is:

1
runtime code = generic table interpreter
2
PB template   = concrete AES-CBC instance

Changing the PB template changes the profile while the interpreter remains the same.

ClientCheckData Encryption Flow#

At the outer layer, the dataflow is:

flowchart TD A[client check data bytes] --> B[block padding] B --> C[split into 16-byte blocks] C --> D[CBC XOR with IV or previous ciphertext] D --> E[white-box AES table interpreter] E --> F[ciphertext block] F --> G[next CBC chaining block]

Inside the interpreter:

flowchart TD A[plain block xor chaining block] --> B[Transpose to AES-like state] B --> C[visible ShiftRows] C --> D[round 0 TableKey] D --> E[round 0 TableValue] E --> F[ShiftRows] F --> G[round 1..8 repeat] G --> H[FinalTable] H --> I[TransposeBack] I --> J[cipher block]

Several boundaries are useful during analysis:

CBC XOR is visible, so block boundaries are clear.
Transpose and TransposeBack convert between byte arrays and AES-like state layout.
ShiftRows remains visible and appears after each round.
The nine main rounds become TableKey -> TableValue -> ShiftRows.
The AES final round is collapsed into FinalTable.

This is not AES disappearing. It is AES represented as a table interpreter.

The 8.7.0 VER08 Template Boundary#

In the 8.7.0 client check data path, VER08 should not be understood as an isolated AES_encrypt() function. The cleaner boundary is:

1
collect CCD fields
2
  -> build dataBody
3
    -> build middle wrapper with field 3 = dataBody
4
      -> zlib-compatible compression
5
        -> VER08 AES-CBC-compatible envelope
6
          -> outer ccData

The white-box AES layer is only the envelope layer. If a hook or offline validator mixes raw business fields, the pre-compression wrapper, compressed bytes, and white-box entry bytes, it will produce false algorithm mismatches.

The 8.7.0 VER08 entry can be modeled with four pieces:

1
template descriptor
2
template blob
3
template length
4
transform gateway

IDA Callsite Reference#

In IDA, the main collector callsite has this shape:

1
ADRL X8, dword_11D077548
2
LDR  W21, [X8]
3
...
4
ADRL X1, unk_11D036528
5
ADRL X2, unk_11D037454
6
MOV  X3, X21
7
MOV  X4, X20
8
BL   sub_1129E7A20

That gives a direct parameter map:

1
dword_11D077548 -> template length word
2
unk_11D036528   -> template descriptor
3
unk_11D037454   -> template blob
4
X21             -> template length value
5
X20             -> scratch / arena-like context
6
sub_1129E7A20   -> VER08 template/table expansion gateway

In the current 8.7.0 view, the template length is 0x400f3. That is not ciphertext length. It is the full VER08 template blob length, and it lines up with the later field layout and the TableKey/TableValue/FinalTable sizes.

The collector passes descriptor, blob, length, and scratch arena into the gateway. The first gateway stage is not an AES round. It parses protobuf wire records, maps them through descriptor rows, and materializes typed object slots. Large length-delimited fields are represented as source pointer plus length first; the interpreter reads the table windows later.

That prevents a common misread. Looking only at gateway size, switches, and control flow, it may appear to be one huge AES function. Semantically it is closer to:

1
wire-format template parser
2
  -> descriptor-backed object materializer
3
    -> table expansion / transform gateway

No ordinary AES-CBC library boundary is visible on this path. The AES semantics live in template fields, table windows, and interpreter access rhythm.

Gateway Parser Details#

The gateway can be modeled with this signature:

1
void sub_1129E7A20(
2
    VerObject *out,
3
    VerDescriptor *descriptor,
4
    uint8_t *blob,
5
    int blob_len,
6
    Arena *arena_or_scratch);

Its first stage parses the template blob into 12-byte wire records:

1
struct WireRecord {
2
    uint32_t tag;  // protobuf wire tag, field_number = tag >> 3
3
    uint32_t lo;   // scalar low bits or value start offset
4
    uint32_t hi;   // scalar high bits or value end offset
5
};

The important parser behavior is:

1
initial record storage: stack scratch, capacity 18
2
growth path: heap array, capacity grows in 0x40-record chunks
3
record size: 0x0c
4
supported wire types: 0, 1, 2, 5
5
rejected wire types: 3, 4
6
length-delimited values: stored as source offsets, not copied immediately

The second stage is descriptor-driven. The descriptor points to a fixed-size entry array, and the current top-level entries can be read as:

1
entry array pointer: 0x11d036108
2
entry count:         22
3
entry size:          0x30
4

5
fields 1,2:   type 12, flag 1
6
field 3:      type 5,  flag 1
7
fields 4-8:   type 12, flag 0
8
fields 9-12:  type 12, flag 1
9
fields 13-21: type 12, flag 0
10
field 50:     type 13, flag 0

type 12 handles length-delimited bytes/string-like fields, type 5 handles a scalar lane, and type 13 handles profile scalar fields such as field 50. Materialized fields are then inserted into a hash/table-like object. Useful gateway ranges to label are:

1
0x1129ea26c..0x1129ea288
2
  type-12 bytes/slice materialization:
3
  stores source pointer and length
4

5
0x1129e8a54..0x1129e8a70
6
  scalar/simple materialization into typed field object
7

8
0x1129ea000..0x1129ea044
9
  nested-message handler exists,
10
  but top-level VER08 table fields use bytes/slice slots

So sub_1129E7A20 is better labeled as the VER08 template/table expansion gateway, not as a compact AES round function. It is large, switch-heavy, and recursive in shape, but the current client check data path does not show an ordinary AES-CBC API boundary.

What Lives In The PB Template#

The template is a protobuf wire-format blob. Its fields can be understood by role:

Field	Role	Reverse-engineering value
field 1	profile/version string	Separates `00000003`, `00000008`, and other table-generation strategies
field 2	16-byte IV	CBC initial chaining block
field 3	scalar control parameter	In 8.7.0 VER08, this acts as a round-plan control parameter
field 9/11	small auxiliary tables	Profile metadata or helper data
field 10	TableKey, nine rounds	Absorbs round key, SBox, and MixColumns contribution
field 12	TableValue, nine rounds	Combines contributions; close to XOR in 08, encoded binary combiner in 03
field 18	FinalTable	Absorbs final SubBytes and last-round key material
field 50	profile scalar	Template parameter

For 8.7.0 VER08, the roles are more concrete:

1
field 1   version selector: "00000008"
2
field 2   16-byte CBC IV
3
field 3   scalar control parameter, observed as 0x3060
4
field 9   small required table block, 0x80 bytes
5
field 10  large TableKey block, 0x24000 bytes
6
field 11  small required table block, 0x40 bytes
7
field 12  large TableValue block, 0x1b000 bytes
8
field 18  FinalTable block, 0x1000 bytes
9
field 50  scalar profile parameter, observed as 3

The same descriptor family also reserves optional slots that are not the main table carriers for the current VER08 instance. This matters for version migration: when a later version shifts field numbers, start by recovering the roles of version, IV, large table blocks, scalar control, and gateway xrefs rather than searching for a raw key.

The large table sizes mirror AES structure:

1
TableKey   = 9 rounds * 16 positions * 256 inputs * 4 contribution bytes
2
TableValue = 9 rounds * 16 output positions * 0x300-byte combiner windows
3
FinalTable = 16 positions * 256 entries

These are not arbitrary constants. They align with the 16-byte AES state, the nine rounds that include MixColumns, and the final round without MixColumns.

Single-Block Semantics#

After reducing implementation detail, one block can be described as:

1
state = Transpose(plainBlock xor chainingBlock)
2
state = ShiftRows(state)
3

4
for round = 0..8:
5
    secTable = TableKey[round](state)
6
    state = TableValue[round](secTable)
7
    state = ShiftRows(state)
8

9
state = FinalTable(state)
10
cipherBlock = TransposeBack(state)

On 8.7.0 VER08, that plan can be grounded in field windows:

1
CBCXor with field 2 IV
2
Transpose4x4
3
ShiftRows
4

5
for round = 0..8:
6
    read field 10 TableKey window at round * 0x4000
7
    read field 12 TableValue window at round * 0x3000
8
    ShiftRows
9

10
read field 18 FinalTable
11
TransposeBack4x4

That rhythm is what deserves trace labels: the 0x4000-sized TableKey round window, the 0x3000-sized TableValue round window, the stable ShiftRows interval, and the separate final table.

Compared with normal AES:

Normal AES	Table interpreter
`AddRoundKey`	Folded into TableKey and FinalTable
`SubBytes`	Folded into TableKey and FinalTable
`MixColumns`	Split into contribution generation and TableValue combining
`ShiftRows`	Still visible
`CBC XOR`	Still visible
final round	16 independent FinalTable byte lanes

Once a trace reveals these boundaries, the AES shape is already mostly exposed.

How Trace Locates The Algorithm#

Searching for AES, SBox, or CBC strings is usually weak. The better route is to compress behavior from the boundary inward.

First, observe length behavior. The ciphertext length is always a multiple of 16. Non-aligned input is padded to the next block; aligned input does not receive an extra full block. That padding behavior is a useful boundary marker.

Second, observe chaining. The first plaintext block is XORed with a 16-byte initial block, and later plaintext blocks are XORed with the previous ciphertext block. That is the CBC shell.

Third, observe state layout. After CBC XOR, the 16 bytes are transposed into a 4x4 state and then shifted by AES row rules. Transpose + ShiftRows is a strong AES fingerprint.

Fourth, observe the 64-byte intermediate buffer. Each TableKey round takes 16 state bytes and emits four contribution bytes for each one. That gives a 64-byte secTable, matching the idea of byte-level contribution generation.

Fifth, observe TableValue access. It does not simply XOR four bytes in source. Each output byte walks three nibble-level lookup stages. In 08 this is semantically close to XOR; in 03 the same shape is encoded into hidden coordinates.

The trace then becomes a named pipeline:

1
padding
2
  -> CBC chaining
3
    -> state transpose
4
      -> visible ShiftRows
5
        -> TableKey contribution
6
          -> TableValue combiner
7
            -> FinalTable
8
              -> ciphertext

That naming is the move from runtime trace to semantic algorithm recovery.

`00000008`: Why FinalTable Leaks The Last-Round Key#

00000008 is the more direct profile. TableValue is table-driven, but semantically close to XOR. TableKey contributions are close to raw MixColumns contributions. The most important weakness is FinalTable.

Each final lane is:

1
FinalTable[position][x] -> y

For 08, each lane can be fitted as:

1
T[x] = SBox[x xor a] xor b

a is input-side material absorbed by the table, while b corresponds to a byte of the last-round key. Fitting is simple:

1
for a in 0..255:
2
    b = T[0] xor SBox[a]
3
    if T[x] == SBox[x xor a] xor b for every x:
4
        recover b

Repeat that for 16 lanes, reorder from state position to ciphertext position, and the AES round-10 key is recovered:

1
FinalTable
2
  -> 16 lane SBox fit
3
    -> round10 key
4
      -> inverse AES-128 key schedule
5
        -> master key

The AES-128 key schedule is reversible. Given K10, walking the schedule backward yields the master key.

The IV is more direct: it is carried by the template as the CBC initial chaining block.

For 08, the recovery route is therefore:

1
field18 FinalTable -> round10 key -> master key
2
field2 IV          -> IV

That is table-driven AES-CBC, not a strong extraction-resistant white-box design.

`00000003`: More White-Box-Like, Still Recoverable#

00000003 improves on 08. Its FinalTable no longer directly fits SBox[x xor a] xor b, and TableKey contribution bytes are not raw MixColumns contribution in the current byte coordinate.

It blocks the shortest 08-style route:

1
FinalTable -> round10 key

However, the complete truth tables are still present. Each 0x100 TableValue subtable can be treated as an encoded binary combiner:

1
encoded_op(encoded_a, encoded_b) -> encoded_sum

The underlying operation is still XOR, but input and output coordinates have been changed. The recovery route is to normalize the binary operation:

1
read binary combiner table
2
  -> find left/right projections
3
    -> recover hidden identity
4
      -> build XOR-isomorphic coordinates
5
        -> decode contribution bytes

Once the hidden XOR coordinates are recovered, first-round TableKey contribution can be fitted back to AES semantics:

1
decoded_contribution ~= affine(coeff * SBox[x xor keyGuess])

coeff is one of the AES MixColumns coefficients 01/02/03. For each key byte, the candidate that matches all 256 inputs is the recovered byte. Since the first round uses the AES master key directly, no inverse key schedule is needed.

The 03 recovery route is:

1
TableValue
2
  -> recover hidden XOR coordinates
3
    -> decode first-round contribution
4
      -> fit coeff * SBox[x xor keyGuess]
5
        -> master key
6

7
field2
8
  -> IV

It is harder than 08, but still a PB-only recovery because the template carries the complete algorithm instance.

03 vs 08#

Dimension	`00000008`	`00000003`
FinalTable	Direct SBox-lane fit	Encoded permutation, not directly fitted
TableValue	Close to XOR combiner	Encoded binary combiner
TableKey contribution	Close to raw MixColumns contribution	Byte-level encoded contribution
PB-only key recovery	Very short through FinalTable	Medium effort through hidden XOR coordinates
Automated feature matching	Easy	Harder
White-box strength	Weak	Better, still insufficient

03 raises the cost of simple pattern matching and static fitting. A script that directly searches SBox-like final lanes will work on 08 but not on 03. Still, the deeper structures remain:

complete truth tables are readable;
output bytes are not strongly fused;
round boundaries are stable;
CBC boundaries are stable;
the IV is template-provided;
there is no per-build binding material or runtime-derived table in the core semantics.

So 03 is better described as encoded table-driven AES, not a strong white-box design.

From Key/IV Recovery To Semantic Proof#

Recovering key and IV is only the first step. The useful proof is equivalence.

flowchart TD A[PB table interpreter] --> D[compare ciphertext] B[Recovered AES-CBC key and IV] --> D C[Independent random input vectors] --> A C --> B D --> E[semantic equivalence]

The first layer is single-block verification, including non-aligned inputs so padding participates in the computation.

The second layer is multi-block verification, which exercises CBC chaining. It is not enough to validate AES block encryption alone.

The third layer is profile verification. 08 and 03 take different recovery routes, but both should land on the same abstract interface:

1
encrypt_client_check_data(profile, plaintext_hex) -> cipher_hex

The page challenge is a lightweight entry point for this proof. Refresh the page, take the generated input and ciphertexts, and compare them with a hook boundary, an offline interpreter, or a recovered standard AES-CBC implementation.

Reverse Validation With A Hook#

The hook should not patch the return value. That would destroy the verification. The clean approach is to replace the input once at the encryption boundary, then observe the real ciphertext produced by the runtime path.

The boundary can be modeled as:

1
encrypt_client_check_data(input_bytes) -> cipher_bytes

Record four fields:

1
page.input_hex
2
runtime input after patch
3
runtime cipher_hex
4
page.cipher_hex

When all four align, the edge AES-CBC equivalent implementation, the local encryption boundary, and the recovered 03/08 profile are referring to the same semantics.

A Frida script should start read-only. Confirm argument length, output length, and timing first, then perform one controlled input replacement:

Use a four-step workflow:

Observe first, do not write memory. Confirm the function receives envelope plaintext, not raw CCD fields or the pre-compression wrapper.
Record the input pointer, input length, output location, and output length. Output length must be a multiple of 16; non-aligned input should only pad to the next block.
Replace input once. The replacement length must exactly match the page input_hex length to avoid breaking the caller’s buffer lifetime.
Read the real runtime ciphertext in onLeave, then compare it with the page 00000008 or 00000003 cipher_hex.

Jailbroken attach and Frida Gadget repackaging differ only in script loading, not in validation logic. In a jailbroken lab, attach after the process is stable. In a repackaged lab, let Gadget load the same script after initialization. The script should not publish hard-coded addresses; resolve slide and target boundaries inside the authorized local environment.

1
const challenge = {
2
  profile: "00000008",
3
  inputHex: "<page-input-hex>",
4
  expectedCipherHex: "<page-cipher-hex>",
5
};
6

7
const targetAddress = ptr("<locally-resolved-envelope-entry>");
8
let patchedOnce = false;
9

10
function hexToBytes(hex) {
11
  const out = new Uint8Array(hex.length / 2);
12
  for (let i = 0; i < out.length; i++) {
13
    out[i] = parseInt(hex.slice(i * 2, i * 2 + 2), 16);
14
  }
15
  return out;
16
}
17

18
function readHex(ptrValue, length) {
19
  return Array.from(new Uint8Array(ptrValue.readByteArray(length)))
20
    .map((value) => value.toString(16).padStart(2, "0"))
21
    .join("");
22
}
23

24
Interceptor.attach(targetAddress, {
25
  onEnter(args) {
26
    const input = resolveInputBuffer(args);
27
    const length = resolveInputLength(args);
28
    const expectedLength = challenge.inputHex.length / 2;
29

30
    this.check = false;
31
    if (patchedOnce || length !== expectedLength) {
32
      return;
33
    }
34

35
    this.beforeHex = readHex(input, length);
36
    input.writeByteArray(hexToBytes(challenge.inputHex));
37
    patchedOnce = true;
38
    this.check = true;
39
  },
40
  onLeave(retval) {
41
    if (!this.check) return;
42
    const cipher = resolveOutputBuffer(retval, this);
43
    const cipherLength = challenge.expectedCipherHex.length / 2;
44
    const cipherHex = readHex(cipher, cipherLength);
45

46
    console.log(JSON.stringify({
47
      profile: challenge.profile,
48
      input_before: this.beforeHex,
49
      input_after: challenge.inputHex,
50
      cipher_runtime: cipherHex,
51
      cipher_expected: challenge.expectedCipherHex,
52
      matched: cipherHex === challenge.expectedCipherHex,
53
    }));
54
  },
55
});

展开收起

resolveInputBuffer, resolveInputLength, and resolveOutputBuffer depend on the local boundary. Keep the patch near the white-box AES envelope entry. Patching higher-level business objects or lower-level ciphertext destroys the clarity of the test.

If runtime output does not match the page ciphertext, check these first:

whether the hook point is after compression and before the white-box envelope;
whether injected input length exactly matches page input_hex;
whether the captured output buffer belongs to the current call rather than a reused previous result;
whether the selected profile is wrong, because 00000008 and 00000003 are not interchangeable;
whether aligned input was accidentally given an extra padding block.

Why White-Box AES Is Hard#

White-box cryptography tries to protect key material even when the attacker can observe, debug, and copy the runtime environment. That is much harder than server-side encryption.

The problem with the 03/08 family is not that there is no obfuscation. The problem is that the obfuscation does not remove enough recoverable structure:

independent FinalTable lanes invite byte-wise analysis;
full TableValue truth tables allow hidden XOR coordinate recovery;
per-input TableKey contribution allows SBox/key fitting;
a static IV is not a security boundary;
unsigned templates can be analyzed, replaced, or downgraded.

Stronger designs usually combine several measures:

1
input/output external encoding
2
+ cross-byte fusion
3
+ fused rounds
4
+ per-build table layout
5
+ runtime-derived transient tables
6
+ template signature
7
+ per-message IV
8
+ anti-downgrade policy

White-box AES can still have engineering value. It raises extraction cost and preserves protocol compatibility. But it should not be treated as a guarantee that key material can never be recovered.

Reading Path For Beginners#

If this is your first white-box AES case, read it in this order:

Understand AES-CBC: blocks, IV, padding, chaining.
Understand AES rounds: SBox, ShiftRows, MixColumns, AddRoundKey.
Think of SBox[x xor key] as a lookup table.
Think of MixColumns as four contributions combined by XOR.
Then map the white-box design: TableKey creates contributions, TableValue combines them, FinalTable finishes the round.
Finally, read the recovery logic: 08 leaks through final lanes; 03 requires recovering hidden XOR coordinates first.

Viewed this way, white-box AES is not magic. It is standard AES turned into tables and encodings.

FAQ#

Is the WeChat client check data white-box AES standard AES-CBC?#

Its external semantics are equivalent to AES-128-CBC, but the runtime is not a normal library call. It interprets TableKey, TableValue, and FinalTable from a PB template, and the resulting ciphertext can be verified against recovered key/IV through standard AES-CBC.

Are `00000003` and `00000008` two completely different algorithms?#

They are better understood as two table-generation strategies for the same AES-CBC table interpreter. 08 is closer to unencoded or weakly encoded table-driven AES. 03 adds byte-level encoding to contribution and combiner tables.

Why can `00000008` recover key through FinalTable?#

Because each 08 FinalTable byte lane can be fitted as SBox[x xor a] xor b. Recovering the 16 b values yields the last-round key; inverse AES-128 key schedule then yields the master key.

Why is `00000003` still recoverable?#

Its FinalTable does not directly fit the same lane model, but TableValue stores complete encoded binary combiner truth tables. After recovering hidden XOR coordinates, first-round TableKey contributions can be fitted to coeff * SBox[x xor keyGuess].

What is the page challenge for?#

It is a reverse-validation vector. Refresh the page to get a new hex input and 03/08 ciphertexts, then compare them with a local hook, offline interpreter, or recovered standard AES-CBC implementation.

How should the 8.7.0 VER08 entry be located?#

Do not start with key search. A more stable route is to follow the client check data collector into the envelope transform, then recover the relationship among version, IV, large table blocks, scalar control, and gateway. Once that boundary is found, validate the path as compressed bytes -> VER08 envelope -> ciphertext.

Can white-box AES fully prevent key extraction?#

Not by itself. White-box AES raises extraction cost. If full tables, stable round boundaries, independent final lanes, and static IVs remain analyzable, key/IV recovery may still be possible. Stronger designs need encoding, byte fusion, template integrity, and runtime diversity together.

WeChat RQTX Part 2: From VM Runtime Trace to Semantic Algorithm Recovery

Sat, 09 May 2026 00:00:00 GMT

RQTX sits in a WeChat request-chain signing and checking path. Its input comes from request-related data, and the visible output is a short integer. This second article focuses on what happens after the VM runtime becomes observable: how a long virtual-machine execution stream can be reduced into an algorithm that is readable, testable, and maintainable.

I prefer to call this step “from runtime to semantics.” At the beginning, the observable objects are VM input, output, registers, memory, and many blocks. At the end, the goal is to name ordinary engineering functions:

1
message_schedule()
2
compress_sha_like()
3
tail_transform()
4
rolling133_to_0x44()

When a register replay like r8/r9/ra/rb becomes algorithm objects such as state, block, digest, and finalizer, RQTX has effectively walked out of the VM.

The article first gives a page-level verification vector, then extracts a standard-library-like algorithm skeleton. After that, it explains how trace localizes the algorithm and where the result resembles or diverges from MD5, SHA-2, HMAC, CRC, and rolling-hash families.

Key Conclusions#

The input boundary for this path is not the raw request body. It is a normalized 32-byte lowercase MD5 hex string.
VM trace should not be read as one long line. It should be aggregated into memory boundaries, dynamic blocks, context-slot diffs, and block-local instruction windows.
The main algorithm is not CRC, standard MD5, standard SHA-256, or standard HMAC. It borrows recognizable structures and then applies profile-specific changes.
Semantic recovery depends on naming blocks by behavior, validating them against standard algorithm shapes, and closing the loop with both a VM oracle and primitive tests.
The VM runtime should not be discarded after the semantic implementation works. It remains useful as a trace oracle, regression oracle, and version-migration oracle.

The article moves through five layers: a refresh-generated vector, a publishable algorithm skeleton, trace localization, standard-algorithm comparison, and a verification loop.

Refresh-generated Verification Vector#

The vector below is generated by an edge function when the page loads. Each refresh produces a new 32-byte ASCII hex input and the corresponding 0x44-prefixed RQTX result. It is meant for reverse comparison with local hooks, runtime trace, or a semantic implementation.

RQTX Challenge generating

input_kind: md5_hex_32
cmd: -
input: loading
rqtx: -
generated_at: -

Local Reverse Validation With Frida#

The page does not accept custom reader input. Instead, it publishes a fresh vector on each refresh. A reader can hook the relevant local boundary, replace the live input with the generated vector, and compare the device result with the page result.

For a jailbroken Frida flow, the validation shape is:

1
// Replace symbolic names with locally verified symbols.
2
const target = Module.findExportByName(null, "rqtx_entry_like");
3
Interceptor.attach(target, {
4
  onEnter(args) {
5
    const vector = "replace_with_page_generated_input";
6
    Memory.writeUtf8String(args[0], vector);
7
    args[1] = ptr(vector.length);
8
  },
9
  onLeave(retval) {
10
    console.log("device rqtx =", retval);
11
  },
12
});

For a repackaged Frida flow, inject the same boundary replacement into the app process and compare the result after the request path reaches RQTX. Keep the probe narrow: modify only the normalized input boundary and log only the short result. Avoid collecting raw request bodies or unrelated user data.

First, Shape The Algorithm Like A Standard Library#

Before reading every trace line, it helps to define the kind of code we want to end with. The publishable semantic implementation should look like a normal small algorithm library, not like VM register replay.

A useful architecture is:

1
pub struct RqtxInput<'a> {
2
    pub md5_hex_32: &'a [u8; 32],
3
    pub cmd: u32,
4
}
5

6
pub struct RqtxProfile {
7
    pub iv: [u32; 8],
8
    pub round_constants: &'static [u32; 64],
9
    pub finalizer_seed: u32,
10
}
11

12
pub fn rqtx_870(input: &RqtxInput, profile: &RqtxProfile) -> u16 {
13
    let block = stage_md5_hex(input.md5_hex_32, input.cmd);
14
    let words = message_schedule(&block);
15
    let digest = compress_sha_like(profile.iv, &words, profile.round_constants);
16
    let tail = tail_transform(&digest, input.cmd);
17
    rolling133_to_0x44(&tail, profile.finalizer_seed)
18
}

展开收起

This shape is intentionally close to standard cryptographic and checksum libraries. It separates input staging, message schedule, compression-like mixing, tail transformation, and final short-integer reduction.

That does not mean RQTX is SHA-256, HMAC, MD5, or CRC. It means the comparison target is clear. Once the semantic code has this shape, the analysis can say precisely which pieces resemble a standard primitive and which pieces are profile-specific.

Start By Accepting The VM As The Oracle#

At the beginning of semantic recovery, the VM runtime is the only trustworthy oracle. The trace is noisy, the pseudo-code is distorted by CFG flattening, and a hand-written semantic implementation is not yet proven.

The first rule is simple: the semantic implementation is wrong until it matches the VM oracle for many inputs.

The oracle gives three kinds of evidence:

input staging: where the normalized 32-byte input is placed;
state evolution: how context fields and memory windows change across blocks;
output write: where the short RQTX value is produced.

This prevents a common mistake: seeing SHA-like operations in the runner and immediately declaring the whole algorithm to be SHA-256. The VM oracle forces every abstraction to earn its name.

Trace Should Be Aggregated, Not Hoarded#

More trace is not automatically better. Raw instruction trace becomes unreadable quickly. The useful trace is compressed into layers:

Trace View	What It Answers
memory boundary trace	Where input is staged and output is written.
dynamic block trace	Which blocks form loops, rounds, and tails.
context slot diff	Which slots behave like state, block words, counters, or digest.
block-local instruction window	Which operations resemble known algorithm steps.

The goal is to replace “thousands of native instructions” with “a small number of behavior-labeled blocks.” A block name should describe what the block does, not where it lives.

How Trace Localizes The Algorithm#

Step 1: Lock The Wrapper Boundary#

Start from the known request-chain entry and stop at the wrapper that receives the normalized RQTX input. This boundary keeps request normalization separate from the protected algorithm.

The wrapper boundary is proven when:

repeated calls hit the same path;
the normalized input appears at a stable memory boundary;
replacing only that staged input changes the final RQTX result;
unrelated request fields do not need to be dumped to reproduce the algorithm input.

Step 2: Use Boundary Memory Trace For Input Staging And Output Write#

Memory boundary trace identifies where the 32-byte hex string enters VM-visible memory and where the short integer is written back.

This is the first semantic cut:

1
request material
2
  -> normalized md5_hex_32
3
    -> VM staging buffer
4
      -> VM rounds
5
        -> short rqtx result

The staging boundary tells us that the raw request body is not the algorithm input. The output boundary tells us which value the semantic implementation must reproduce.

Step 3: Use Dynamic Block Trace To Find Loop Skeletons#

After staging, the VM runs repeated block groups. The important question is not the native block address. The important question is whether the block group behaves like a schedule loop, a compression round, a tail transformation, or a final reducer.

Dynamic block trace gives this shape:

1
stage_input
2
  -> prepare_words
3
  -> schedule_loop
4
  -> compression_round_loop
5
  -> tail_mix
6
  -> rolling_finalizer
7
  -> write_output

This skeleton is the bridge between VM runtime and semantic algorithm.

Step 4: Use Context Slot Diffs To Name State, Block, And Digest#

Context slot diffs turn blocks into objects. A slot that is written once after input staging is likely part of block. A group of eight 32-bit values updated across rounds behaves like state. A derived group that survives into the final reducer behaves like digest.

This naming step should be conservative. If a slot looks like a counter in one trace but behaves like a pointer in another, it should remain unnamed until the conflict is explained.

Step 5: Compare Block-local Windows With Standard Algorithms#

Only after the block skeleton and context names are stable should standard algorithms enter the discussion. The comparison should be structural:

Does the schedule expand 16 words into a larger word array?
Does the round loop maintain eight working variables?
Are rotate, shift, choose, majority, xor, or modular-add patterns present?
Are constants used like SHA-2 round constants or profile-specific tables?
Does the finalizer reduce a digest into a short result like a checksum or rolling hash?

This is where “similar to SHA-2” becomes a useful clue, and “not standard SHA-256” becomes a precise conclusion.

The First Main Line Seen In Runtime#

The first stable line in runtime is input staging. The visible input is a lowercase 32-byte MD5 hex string. That string is not the final algorithm. It is a normalized boundary.

The VM then transforms it through a sequence that looks like:

1
md5_hex_32
2
  -> profile-aware block staging
3
  -> message schedule
4
  -> SHA-like compression
5
  -> MD5-like or HMAC-like tail influence
6
  -> rolling reducer
7
  -> 0x44-prefixed short value

This line explains why isolated observations can be misleading. Seeing MD5 at the input boundary does not make the core MD5. Seeing SHA-like rounds does not make it standard SHA-256. Seeing a short final result does not make it CRC.

Semantic Part 1: MD5 Hex Is Input Normalization, Not The Main Algorithm#

The 32-byte lowercase MD5 hex string is a boundary artifact. It is how request-related material is normalized before it enters the protected path.

This matters because MD5 can appear in the trace and still not be the algorithm being recovered. The semantic code should represent this as staging:

1
fn stage_md5_hex(input: &[u8; 32], cmd: u32) -> ProfileBlock {
2
    // Normalize and place bytes into the profile-specific block layout.
3
    ProfileBlock::from_md5_hex_and_cmd(input, cmd)
4
}

The proof is behavioral: replacing the staged 32-byte value changes the final RQTX result in a controlled way, while the rest of the algorithm still executes through the VM path.

Semantic Part 2: It Looks Like SHA-2, But It Is Not SHA-256#

The strongest structural similarity is SHA-2-like compression:

words are expanded from an initial block;
several 32-bit working values move through repeated rounds;
rotate, shift, xor, choose-like, majority-like, and modular-add patterns appear;
constants influence round behavior.

The differences are just as important:

the input block is profile-staged, not a standard SHA-256 padded message block;
constants and IV-like values are profile-specific;
tail processing does not follow standard SHA-256 digest finalization;
the output is reduced into a short RQTX value instead of a 256-bit digest.

So the correct description is SHA-2-like, not SHA-256.

Why The SHA-2-like Label Is Defensible#

The label is defensible because it comes from multiple signals, not from one operation:

Signal	Why It Matters
schedule expansion	Matches the idea of deriving later words from earlier words.
eight-lane state	Resembles a SHA-2 compression state shape.
rotate/shift/xor mix	Matches SHA-2-style bit mixing.
repeated round loop	Separates schedule, compression, and tail behavior.
profile constants	Explains why it is similar but not standard.

The label would be weak if it came only from a rotate instruction or a single constant. It becomes useful when the whole block behavior aligns.

Semantic Part 3: It Looks Like HMAC, But It Is Not HMAC#

HMAC-like signals can appear when the trace shows staged material, profile-derived constants, and inner/outer-looking influence. But standard HMAC has a clear construction: key normalization, ipad/opad, inner hash, and outer hash.

RQTX does not cleanly follow that construction. The better interpretation is that it borrows the idea of profile-conditioned mixing, not the exact HMAC algorithm.

In semantic code, that difference should be visible:

1
fn tail_transform(digest: &[u32; 8], cmd: u32) -> TailState {
2
    // Profile-specific tail mixing, not HMAC ipad/opad finalization.
3
    TailState::mix(digest, cmd)
4
}

Semantic Part 4: It Looks Like MD5, But It Is Not MD5#

MD5 appears at the boundary and can also appear as a comparison shape because the input is a 32-byte hex MD5 string. But the algorithm’s core loop does not behave like standard MD5 compression.

The important distinction is:

MD5 as a normalization source: yes;
MD5 as the recovered VM core: no;
MD5-like byte ordering or digest influence: possible, but must be tied to specific blocks.

This prevents the analysis from collapsing all “MD5-looking” artifacts into one incorrect conclusion.

Semantic Part 5: The Final Step Is Not CRC, But A Rolling Mixer#

The final reducer is tempting to call CRC because it produces a short result. The trace does not support that conclusion.

A CRC-like reducer would normally show polynomial-style shifts and table or bit-level feedback. The observed finalizer is better modeled as a rolling mixer:

1
fn rolling133_to_0x44(tail: &TailState, seed: u32) -> u16 {
2
    let mut acc = seed;
3
    for b in tail.bytes() {
4
        acc = acc.wrapping_mul(133).wrapping_add(u32::from(b));
5
        acc ^= acc >> 11;
6
    }
7
    0x4400 | ((acc as u16) & 0x00ff)
8
}

The exact constants belong to the profile under analysis. The important public point is the shape: rolling accumulation and short reduction, not CRC polynomial computation.

From Register Replay To Semantic Code#

Register replay is useful early because it stays close to the VM. It is bad as the final article-level abstraction because it hides meaning.

The migration path is:

1
r8/r9/ra/rb snapshots
2
  -> context slot names
3
    -> state/block/digest/tail objects
4
      -> standard-library-like functions
5
        -> tests against VM oracle

A good semantic implementation should be boring to read. It should look like ordinary code with small functions and explicit profiles. The reverse-engineering work remains in the evidence chain and tests, not in exotic naming.

Standard Algorithm Comparison#

“Similar” is a lead. “Different” is the result that matters.

Standard Shape	RQTX Relationship
MD5	Used as input normalization boundary; not the main VM core.
SHA-256 / SHA-2	Strong structural resemblance in schedule and compression; not a standard digest implementation.
HMAC	Profile-conditioned tail influence resembles keyed mixing; not standard HMAC construction.
CRC	Short output is superficially similar; final reducer behaves more like a rolling mixer.

This comparison is valuable because it lets the article say exactly what was borrowed and exactly what was changed.

Verification Loop#

The verification loop has four layers:

Page vector: edge-generated input/result pair.
Device hook: replace the normalized input boundary and observe device output.
VM oracle: run the recovered VM runtime against the same input.
Semantic implementation: run the standard-library-like code against the same input.

The implementation is accepted only when all four agree over many generated vectors. A single match can be luck. A thousand random matches against the VM and semantic implementation provide much stronger confidence.

The Role Of AI In This Process#

AI is useful as a naming, summarization, and comparison assistant. It can help turn trace groups into candidate names, compare a block skeleton against standard algorithm families, and point out missing verification steps.

AI should not be treated as the oracle. The oracle is still the VM runtime, the device result, and the tests. A suggested function name is useful only after trace behavior proves it.

Common Pitfalls#

Calling the input MD5 because the boundary contains MD5 hex.
Calling the core SHA-256 because the rounds look SHA-like.
Calling the final reducer CRC because the output is short.
Trusting one trace without checking input variation.
Keeping register names in the final semantic layer.
Throwing away the VM runtime after the semantic code starts passing.

Each pitfall comes from naming too early. The cure is to keep the evidence chain visible.

Combining The Two Stages#

The first article recovers the VM architecture: entry, rqtx.dat, context, instruction decoding, runner, and offline runtime. This article uses that runtime to recover semantic algorithm structure.

Together they form one chain:

1
entry proof
2
  -> VM image proof
3
    -> context proof
4
      -> runner proof
5
        -> runtime oracle
6
          -> trace aggregation
7
            -> semantic algorithm
8
              -> standard comparison
9
                -> verification vectors

This is why the runtime matters even after semantic lifting. It remains the bridge between protected execution and readable code.

Final Notes#

The most useful result is not a dramatic name for the algorithm. The useful result is a maintainable model: normalized input, profile-specific staging, SHA-2-like compression, non-standard tail mixing, rolling finalization, and tests that compare semantic output with VM output.

That model is precise enough to publish, precise enough to test, and flexible enough to survive version migration.

FAQ#

Is RQTX standard SHA-256?#

No. It has SHA-2-like structure, but the input staging, constants, tail behavior, and short output do not match standard SHA-256.

Is RQTX standard HMAC?#

No. Some profile-conditioned mixing can look HMAC-like, but the recovered path does not follow the standard HMAC construction.

Is the 32-byte input the raw request body?#

No. The observed input boundary is a normalized lowercase MD5 hex value derived from request-related material.

Why keep the VM runtime after semantic recovery?#

The runtime remains the oracle for regression, trace, and version migration. Semantic code is easier to read, but the VM proves whether it is still correct.

How should readers verify the result?#

Use the generated page vector, hook the normalized local input boundary, compare the device result, then compare the VM runtime and semantic implementation against the same vector.

WeChat RQTX IRVMP Recovery: Architecture, Instructions, and Runtime

Fri, 08 May 2026 00:00:00 GMT

This article records the reverse-engineering and recovery process for the RQTX IRVMP path. The important part is not a single hook point. The useful result is a chain of engineering objects that can be inspected and tested: the entry point, VM initialization, the rqtx.dat layout, instruction encoding, runner semantics, CFG cleanup, and an offline runtime.

Each layer is explained in the same order: what it is, why it matters, and how it can be proven. The article should read as an evidence chain rather than a work log.

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#

Term	Meaning
WeChat	The client environment where the RQTX path is observed.
RQTX	A protected computation path in the request chain.
IRVMP	Instruction-level virtual machine protection used by the RQTX path.
rqtx.dat	A VM data file carrying the opcode map, payload image, and relocation slots.
CFG deobfuscation	Block coverage, dispatcher stripping, and semantic recovery for a flattened native runner.
IDA Pro / Frida	Static analysis and dynamic instrumentation tools used for proof and validation.

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:

Role	Purpose
ObjC anchor	Stable top-level selector for the request-chain entry.
body wrapper	Accepts the normalized input and enters the RQTX computation path.
calc stage	Checks the runtime handle and parses entry-like fields.
VM bridge	Loads the blob/context and initializes VM registers.
VM runner	Executes the IRVMP instruction stream with heavy CFG flattening.

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:

Region	Purpose
opcode map	Deobfuscates instruction opcode values.
payload image	Holds VM instruction words and embedded data.
relocation/export slots	Connect the packaged image to runtime pointers and bridge state.
internal VM blocks	Provide control-flow and handler-level data used by the runner.

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:

A global initialization path obtains or constructs the RQTX provider.
A handle-like object is used by later calculation stages.
The VM bridge asks for a blob and a context.
The context gets filled with register and memory-window state.
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:

I-format#

I-format instructions carry register operands and a short immediate. They are useful for identifying arithmetic, memory access, and small control operations.

R-format#

R-format instructions carry multiple register fields. These are the best candidates for arithmetic and state-mixing handlers.

19-bit Immediate#

The 19-bit immediate form is useful for medium-size constants or offsets. It appears when the VM needs more than the small immediate but does not need a full branch target.

26-bit Branch#

The branch form carries a larger control-flow target. It is the main format used when rebuilding the VM-level CFG.

The key point is that instruction format is not enough. The opcode still needs deobfuscation. The same raw shape can mean different things once IP-aware mapping is applied.

Instruction Semantics#

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

A stable workflow is:

Decode a candidate instruction word.
Identify which handler block the native runner enters.
Trace context reads and writes around that handler.
Compare the behavior with a small set of semantic templates: move, add, xor, rotate, load, store, branch, compare, call-like transition.
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.

timestamp-wrapper heuristic#

Wrapper code often touches timing, watchdog, or bookkeeping state around the real work. The useful signal is not the timestamp itself. The signal is that a wrapper has a stable before/after shape around a deeper call that consumes the VM context.

effective-call-list ranking#

Instead of ranking callees by static size, rank them by runtime effect: context mutation, blob access, IP movement, output write, and repeated presence under live calls. The runner scores highly because it changes the VM state in a dense and repeated way.

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#

Entry Adaptation#

Start with the stable business entry, follow the slot chain, and stop at the body wrapper that actually enters the RQTX calculation stage. Use dynamic hits to prove that the static chain is not a dead path.

CFG Recovery#

Use dynamic coverage to identify dispatcher blocks, shared tails, handler groups, and IP update blocks. Do not try to make the flattened native function look natural before handler behavior is known.

Runtime Reconstruction#

Rebuild only what has been proven:

packaged VM image loader;
opcode map usage;
context fields with stable behavior;
instruction decoder;
handler semantics;
bridge input and output boundary.

The offline runtime should be allowed to start incomplete. It becomes reliable as more handler tests and live-vector comparisons pass.

Difficult Cases#

1. Hex-Rays Pseudo-code Is Not Direct Evidence#

Pseudo-code is a navigation aid. For flattened runners, it can merge unrelated selector states or hide real state changes. Use it to find candidates, then verify with traces.

2. Hot-path Instrumentation Can Change Behavior#

Heavy instrumentation can slow the runner, alter timing, or trigger watchdog paths. Keep probes narrow and move from native-instruction tracing to block-level or context-diff tracing as early as possible.

3. Watchdog And Re-entry Noise#

Repeated calls may include bookkeeping or re-entry paths that do not belong to the algorithm. Separate “called during the request” from “semantically required for the result.”

4. Version Address Drift#

Addresses drift between versions. Layout relationships, object roles, and dynamic behavior are more portable than raw addresses.

5. Relocation Differences#

A dump that looks byte-identical may still fail if relocation slots or runtime pointers are reconstructed incorrectly. Treat relocation as part of the VM image, not as external noise.

6. Observed Mode Is Not Full Coverage#

Observed behavior proves the executed path, not the whole VM. Mark unobserved handlers and branches as incomplete until they are hit or explained by another proof.

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:

reproduce observed behavior;
make handler semantics testable;
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#

What is RQTX?#

RQTX is a protected computation path in the WeChat request chain. In the analyzed path, it takes normalized request-related input and produces a short integer used by the request-side verification flow.

What is the core protection point of WeChat RQTX IRVMP?#

The core protection is the combination of a packaged VM image, IP-aware instruction decoding, objectized runtime context, and a CFG-flattened native interpreter.

What does rqtx.dat contain?#

The recovered model treats rqtx.dat as a packaged VM image that contains the opcode map, payload image, relocation/export slots, and internal VM blocks.

How can the VM runner be located?#

Start from the stable entry, follow the wrapper chain, identify the bridge, then rank candidate callees by runtime effect: context mutation, VM image access, IP movement, and output writes.

Why is Hex-Rays F5 pseudo-code not enough?#

Flattened control flow can make pseudo-code merge dispatcher state with real handler logic. It is useful for navigation, but handler semantics must be verified with dynamic traces and context diffs.

How does this method migrate to a newer WeChat version?#

Migrate the evidence chain instead of raw addresses. Re-prove the entry, slot chain, VM init, context layout, image structure, runner behavior, and handler decode relationship for the new version.

TaskAgent Reverse Lab

WeChat 8.7.0 ClientCheckData White-Box AES: From AES-CBC to 03/08 Table Interpreter Recovery

Key Findings#

Edge-Generated White-Box AES Challenge#

Start With Plain AES-CBC#

The White-Box Intuition: Turn Formulae Into Tables#

ClientCheckData Encryption Flow#

The 8.7.0 VER08 Template Boundary#

IDA Callsite Reference#

Gateway Parser Details#

What Lives In The PB Template#

Single-Block Semantics#

How Trace Locates The Algorithm#

00000008: Why FinalTable Leaks The Last-Round Key#

00000003: More White-Box-Like, Still Recoverable#

03 vs 08#

From Key/IV Recovery To Semantic Proof#

Reverse Validation With A Hook#

Why White-Box AES Is Hard#

Reading Path For Beginners#

FAQ#

Is the WeChat client check data white-box AES standard AES-CBC?#

Are 00000003 and 00000008 two completely different algorithms?#

Why can 00000008 recover key through FinalTable?#

Why is 00000003 still recoverable?#

What is the page challenge for?#

How should the 8.7.0 VER08 entry be located?#

Can white-box AES fully prevent key extraction?#

WeChat RQTX Part 2: From VM Runtime Trace to Semantic Algorithm Recovery

Key Conclusions#

Refresh-generated Verification Vector#

Local Reverse Validation With Frida#

First, Shape The Algorithm Like A Standard Library#

Start By Accepting The VM As The Oracle#

Trace Should Be Aggregated, Not Hoarded#

How Trace Localizes The Algorithm#

Step 1: Lock The Wrapper Boundary#

Step 2: Use Boundary Memory Trace For Input Staging And Output Write#

Step 3: Use Dynamic Block Trace To Find Loop Skeletons#

Step 4: Use Context Slot Diffs To Name State, Block, And Digest#

Step 5: Compare Block-local Windows With Standard Algorithms#

The First Main Line Seen In Runtime#

Semantic Part 1: MD5 Hex Is Input Normalization, Not The Main Algorithm#

Semantic Part 2: It Looks Like SHA-2, But It Is Not SHA-256#

Why The SHA-2-like Label Is Defensible#

Semantic Part 3: It Looks Like HMAC, But It Is Not HMAC#

Semantic Part 4: It Looks Like MD5, But It Is Not MD5#

Semantic Part 5: The Final Step Is Not CRC, But A Rolling Mixer#

From Register Replay To Semantic Code#

Standard Algorithm Comparison#

Verification Loop#

The Role Of AI In This Process#

Common Pitfalls#

Combining The Two Stages#

Final Notes#

FAQ#

Is RQTX standard SHA-256?#

Is RQTX standard HMAC?#

Is the 32-byte input the raw request body?#

Why keep the VM runtime after semantic recovery?#

How should readers verify the result?#

WeChat RQTX IRVMP Recovery: Architecture, Instructions, and Runtime

Key Conclusions#

Keywords And Terms#

Overall Path#

IRVMP Design Model#

rqtx.dat Layout#

VM Initialization#

VM Context#

Instruction Encoding#

I-format#

R-format#

19-bit Immediate#

26-bit Branch#

Instruction Semantics#

Runner Execution Model#

CFG Flattening#

No-CFG Recovery#

Deep Runner Localization#

timestamp-wrapper heuristic#

`00000008`: Why FinalTable Leaks The Last-Round Key#

`00000003`: More White-Box-Like, Still Recoverable#

Are `00000003` and `00000008` two completely different algorithms?#

Why can `00000008` recover key through FinalTable?#

Why is `00000003` still recoverable?#