Campus-25/static/Servers/Tachyon/docs/client-agent-request-2.md

Follow-up request: the RecRoomClientEncryptLayer 9-byte format

Your Tachyon findings resolved the handshake failure. Reconciled against the server side:

• The client's inbound layer strips 9 bytes off every datagram before LiteNetLib parses it.
• Our stock server sent a 15-byte ConnectAccept; after the client strips 9 it is 6 bytes, so NetConnectAcceptPacket.FromData fails Size != 15 and returns null — the exact silent ignore-and-retry-to-timeout we observed.
• Confirmed on the server: a stock server absorbs the client's over-long ConnectRequest (the 9 extra bytes fold into variable-length connect data), which is why the server logged "peer connected" while the client never did.

So the server needs the matching layer. We have built it as a configurable PacketLayerBase with ExtraPacketSizeForLayer = 9, and proved the plumbing: with the same 9-byte framing on both ends the handshake completes; with it on the server only, a stock client fails identically to the game today.

The one thing blocking a live test is the exact 9-byte format and the null-key behaviour. This is §3 / step 1 of your own task doc, and it is now the whole critical path.

Q1 — RecRoomClientEncryptLayer.ProcessOutBoundPacket (RVA 0x735D760)

Full disassembly / decompile. Specifically:

• Are the 9 bytes prepended (written at the front, payload shifted) or appended (written after the existing payload)? The offset math in the method answers this.
• What are the 9 bytes when the session key field (DAKIIEIEKNI, NetPacket+0x18) is null — the state during the whole LiteNetLib + NGO handshake, before RecRoom_SetEncryptionInfo runs? Zero fill? A counter? A magic constant? Copied from somewhere in the packet?
• When the key is non-null, what transforms the payload — AES over the body, and the 9 bytes carry a nonce/tag? We need the outbound path, but the null-key branch is what unblocks the handshake.
• Does it branch on packet property (e.g. treat ConnectRequest/Accept differently from Channeled data), or is it uniform for every datagram?

Q2 — RecRoomClientEncryptLayer.ProcessInboundPacket (RVA 0x735DF90)

Full disassembly / decompile. Specifically:

• Does it validate the 9 bytes (compare a MAC/magic/counter and drop on mismatch), or just strip them? This is the single most important question: if it only strips when the key is null, a zero-fill server reply connects immediately; if it validates, we must reproduce the exact bytes.
• Same prepend-vs-append question from the read side (which 9 bytes are removed, front or back).
• The null-key branch specifically — what happens to a datagram that arrives before a key is set (which is every handshake packet). Does it early-out, strip-only, or reject?
• Any length guard (e.g. drop if size < 9).

Q3 — the two unidentified layer methods

0x735DC20 and 0x735E140 are listed as unidentified members of the layer. One-line summary of each — likely a key setter (the sink for RecRoom_SetEncryptionInfo) and/or a nonce/counter helper. If one installs the key into DAKIIEIEKNI, note its signature.

Q4 — the .cctor at 0x735E220

If the layer has static state (a fixed magic, a base nonce, an RNG seed), it is initialised here. Dump any constants it writes.

Why this precise scoping

We are one bounded read from a live handshake. If Q2's null-key path is strip-only, the layer we have built connects the real client as-is and we move straight to the NGO ConnectionRequest (where your Tachyon JSON / "Carrot" findings take over). If it validates, we need the byte recipe before any wire test is meaningful — a guess here is the "plausible-but-wrong costs more than not-found" trap you flagged.

Report bytes and offsets, not prose. Where the null-key path is genuinely absent (i.e. the layer assumes a key is always set), say so — that itself would be a finding, implying the key is established out-of-band before the first datagram.