NW Private-Server RE Dashboard

The 12 bytes the network sees. Meaningless on their own.

00 01 9d 05  00 03 6e f6  af 91 2d 74

The first 4 bytes are a small header that names the message type. The protocol encodes the type-id by splitting it into two pieces: a "marker" pair 00 01 followed by (type_id & 0x3f) | 0x80 and type_id >> 6. For 9d 05: (0x9d & 0x7f) | (0x05 << 6) = 0x15d.

00 01 9d 05  00 03 6e f6 af 91 2d 74
└── type 0x15d ──┘

server.javelin.dispatch.decode_replay_message(0x15d, "R", body) looks up 0x15d in its table and routes to heartbeat_15d.decode_ping. The dispatcher knows all 40 captured wire-types in the replay (plus 0x5d1 for the state-10 unblock).

The codec knows the heartbeat ping's wire layout: after the 4-byte header, two big-endian 32-bit integers — a counter and a nonce.

00 01 9d 05  00 03 6e f6  af 91 2d 74
             ↑──────────↑ ↑──────────↑
             counter      nonce
             = 225014     = 2945527156

The codec returns a Python dataclass that's easy to inspect and re-emit. Round-trip is byte-identical: encoding this back produces the original 12 bytes.

HeartbeatPing15D(
    counter = 225014,
    nonce = 2945527156,
)

The same dataclass renders as JSON when needed (e.g. for the tools/decode_message.py --json CLI or the dashboard's message inspector).

{
  "counter": 225014,
  "nonce": 2945527156
}

00 01 a6 62  f8 cb ed 57 c6 8b 18 f4  bf 85 31 4b bc 4a 95 1a
01 01 00 00  9c fa 58 61 78 14 69 f2  65 03 00 00  00 00 02 01

Same decode rule as before: (0xa6 & 0x7f) | (0x62 << 6) = 0x18a6.

00 01 a6 62  …
└── type 0x18a6 ─┘

Most non-trivial messages carry a 16-byte identity tag right after the type header. It splits as two 8-byte halves:

           f8 cb ed 57 c6 8b 18 f4  bf 85 31 4b bc 4a 95 1a
           └─ first_uuid_half ─┘  └ session_uuid_lower ┘

The session_uuid_lower (yellow) is constant across this whole session — see the Wire-type families panel for the 7 sub-system families it appears in.

The remaining 20 bytes are 5 typed fields the codec knows the layout of:

…  01 01  00 00  9c fa 58 61 78 14 69 f2  65 03 00 00  00 00 02 01
   ↑     ↑     ↑                       ↑           ↑
   flags pad   second_id (8 bytes)     build_ver   counter+pad
   = 257       = 9cfa58617814 69f2     = 869       = 1

InitMessage18A6(
    first_uuid_half = b'\xf8\xcb\xedW\xc6\x8b\x18\xf4',
    session_uuid_lower = b'\xbf\x851K\xbcJ\x95\x1a',
    second_id = b'\x9c\xfaXax\x14i\xf2',
    counter = 1,
    flags = 257,
    build_version = 869,
)

The counter field is what makes InitMessage18A6 a counter-coupled pair with 0x1a59 (SessionSubkeyBeacon). Each 0x18a6 the server sends carries an incrementing counter; the client's 0x1a59 reply echoes the same counter so the server can confirm the link is alive. Both sit in the same f8cbed57c68b18f4 sub-system family — see the Wire-type families panel for the cross-correlation table from wake 121.