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.

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
});

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:

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#

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

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

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:

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.

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:

1. Page vector: edge-generated input/result pair.
2. Device hook: replace the normalized input boundary and observe device output.
3. VM oracle: run the recovered VM runtime against the same input.
4. 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#