XIGNCODE3 getCookie2 — Reverse Engineering Report

┌──────────────────────────────────────────────────────────────────────────────┐ │ ALBION ONLINE LOBBY — FULL HANDSHAKE │ │ │ │ Phase 0 — Content Validation │ │ Client: AlbionMd5Check → scans all game files, computes MD5s │ │ Client: DeltaPatcher → downloads & applies binary patches if needed │ │ │ │ Phase 1 — Region Selection │ │ Client: Parallel TCP ping to 3 region servers │ │ Client: Selects best region (lowest latency) │ │ │ │ Phase 2 — Photon Connection (reliable-UDP, ENet-based, port 5055) │ │ Client → Server: CONNECT │ │ Server → Client: VERIFY_CONNECT │ │ │ │ Phase 3 — Diffie-Hellman Key Exchange │ │ Client ↔ Server: Oakley Group 1 (768-bit MODP, generator 22) │ │ Shared secret → SHA-256 → AES-256-CBC key (zero IV) │ │ Key is ephemeral — new for every connection │ │ │ │ Phase 4 — Encrypted Login (AES-256-CBC, GpBinaryV18 serialization) │ │ Client → Server: OP 1 { identity, device info, content MD5 } │ │ Server → Client: RES 1 { account data, character list } │ │ │ │ Phase 5 — XIGNCODE3 Handshake │ │ Server → Client: EVT 1 { param 0 = TARA challenge blob (~7000 chars) } │ │ Client: getCookie2(challenge) → cookie (76 chars) │ │ Client → Server: OP 1 { param 0 = cookie } │ │ Server: Validates cookie with Wellbia backend │ │ │ │ Phase 6 — Steady State │ │ ↻ PING heartbeat every ~5 seconds │ │ ↻ New challenge + cookie on every message │ │ ↻ All messages tunneled under OP 1 { param 255 = cmd, param 253 = corrId } │ └──────────────────────────────────────────────────────────────────────────────┘

Server → Client: EVT 1 { param 0 = challenge (~7000 char Z85 blob) } Client: getCookie2(challenge) → cookie (76 char) Client → Server: OP 1 { param 0 = cookie } Challenge format: 6A848B92 mz86Br6:zF0@@r3cE>... (~7000 chars) ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ timestamp Z85-encoded body (fixed per session) Cookie format: 83 6A848B92 _ 1e4182a7c383570581e95ae300c05254 _ 8b1d1e635b7693842f76103f81e28768 ^^ ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ prefix ts A = 16 bytes (deterministic) B = 16 bytes (keyed MAC)

Challenge: 6A848B92mz86Br6:zF0@@r3cE>...  (~7000 chars)
RPC Result: 836A848B92_1e4182a7c383570581e95ae300c05254_8b1d1e635b7693842f76103f81e28768
Real Call:  836A848B92_1e4182a7c383570581e95ae300c05254_8b1d1e635b7693842f76103f81e28768
Match: ✅

Layer 1 — Java XigncodeClientSystem.getCookie2(String challenge) │ ▼ Layer 2 — JNI Wrapper (libxigncode.so @ 0x1eff0) ZCWAVE_GetCookie2(JNIEnv*, jobject, jstring) ├─ g_ctx = .bss @ 0x8c0b0 ├─ is_ready(ctx) check └─ cookie_fn(32, out, 260, challenge) ← mode=32 = Cookie2 │ ▼ Layer 3 — cookie_fn (xraphael_arm64.xem @ +0xd988) ├─ adrp + ldr → GLOBALS[0x40] └─ blr x8 → dispatcher │ ▼ Layer 4 — Dispatcher + Jump Table (hash module, ~5 MB) ├─ mode - 17 = index → jump table ├─ mode=32 → index=15 └─ b → handler[15] → L5 wrapper │ ▼ Layer 5 — Sign Function (hash module @ +0x222ad0) int sign_fn(ctx*, out, maxlen, challenge) ├─ 0x2228bc → compute A/B (calls sub-object vtable[0x1b8]) ├─ 0x222bdc → compute A/B (calls sub-object vtable[0x1b8]) ├─ 0x222438 → main entry (buffer allocation, ~5 KB stack) ├─ 0x21f75c → heavy crypto (1123 XOR/rotate/reverse ops) └─ snprintf(out, "83%s_%s_%s", ts, hexA, hexB) [format string unconfirmed]

┌──────────────────────────────────────────────────────────────────┐ │ To implement getCookie2 in pure Python, we need: │ │ │ │ 1. The algorithm (F_a, F_b) │ │ → Custom, obfuscated, 1123 crypto ops │ │ → No standard library matches │ │ → Requires full ARM64 reversal │ │ │ │ 2. The secret key K (32 bytes) │ │ → Located at sub-context offset 0x100 │ │ → Changes every game launch (session-specific) │ │ → Generation mechanism unknown (device? server? random?) │ │ │ │ Even if we fully reverse the algorithm, we still need to │ │ extract the key from each session. The key generation │ │ itself is another unknown. │ └──────────────────────────────────────────────────────────────────┘