Albion Headless Client — Status

┌──────────────────────────────────────────────────────────────────────────────┐ │ ALBION ONLINE — FULL HANDSHAKE (launch → in-world) │ │ │ │ Phase 0 — Content Validation │ │ AlbionMd5Check → scans game files, computes MD5s │ │ DeltaPatcher → downloads & applies binary patches if needed │ │ │ │ Phase 1 — Region Selection │ │ Parallel Photon status ping to 3 region servers (UDP 5055) │ │ 5.45.187.118 · 193.169.238.96 · 5.188.125.60 │ │ Empty OP 1 {} → EVT 1 { 1=3, 252=1 } ; best latency wins │ │ │ │ Phase 2 — Login Server (reliable-UDP, ENet-based, 193.169.238.210:5055) │ │ Client → Server: CONNECT │ │ Server → Client: VERIFY_CONNECT │ │ │ │ Phase 3 — Diffie-Hellman (per connection, never reused) │ │ Oakley Group 1 (768-bit MODP, generator 22) │ │ shared secret → SHA-256 → AES-256-CBC key (zero IV) │ │ │ │ Phase 4 — Encrypted Login (AES-256-CBC, GpBinaryV18) │ │ C → S: OP 1 (253=5) { identity, credentials, device JSON, MD5 } │ │ S → C: RES 1 (253=5) { ~100 fields · 51 = 16-byte GAME TOKEN } │ │ C → S: OP 1 {255=1, 253=19} · OP 1 {255=2, 253=349} (side lookups) │ │ │ │ Phase 5 — XIGNCODE3 Handshake │ │ S → C: EVT 1 { 0 = TARA challenge blob (~7000 chars), 252=473 } │ │ Client: getCookie2(challenge) → cookie (76 chars) │ │ C → S: OP 1 { 0 = cookie, 253=373 } │ │ │ │ Phase 6 — Character Enter → Server Hand-off │ │ C → S: OP 1 { 0 = <character name> } │ │ S → C: RES 1 (253=14) { │ │ 0 = "live03-win-41.ams.albiononline.com:5056" game server │ │ 7 = "live03-win-46.ams.albiononline.com:4535" chat server │ │ 1 = "@TUTORIALSINGLE@50f57e07-…" zone id │ │ 2 = "1008" cluster │ │ 8 = 16-byte CHAT TOKEN │ │ } │ │ │ │ Phase 7 — Chat Server (:4535, Albion.ChatServer) │ │ own DH → OP 1 { 0 = chat token (RES 14 param 8), 255=0, 253=188 } │ │ RES 1 rc=0 { 255=0, 253=188 } │ │ │ │ Phase 8 — Game Server (:5056, Albion.GameServer) ~3 s later │ │ own DH → OP 1 { 0 = game token (login RES param 51), │ │ 1 = <account e-mail>, 253=2 } │ │ S → C: ~80 × EVT 1 world-state burst (real event type in param 252) │ │ 384/385 map markers · 45 buildings · 113 resource nodes · │ │ 123 mobs · 30 players · 96/90 character state · 600 zone tick │ │ S → C: RES 1 (253=2) { 0=object id, 2=name, 8=zone, 9=pos[2], │ │ 11/12=health, … ~120 fields } │ │ │ │ Phase 9 — Steady State │ │ ↻ OP 2 { 0 = monotonic counter, 1 = 0|20 } every ~1 s │ │ ↻ EVT 1 { 0 = 8-byte zone tick, 252=600 } │ │ ↻ new XIGNCODE cookie per tick on the login peer │ │ ↻ lobby messages tunneled under OP 1 { 255 = cmd, 253 = corrId } │ └──────────────────────────────────────────────────────────────────────────────┘

1. TX knock e9712dd5 00010000 + 392 zero bytes (400B, ×2) 2. RX challenge e9712dd5 01010000 [nonce:4] [token:4] (16B) 3. TX confirm e9712dd5 11010000 [X:4] [nonce:4] [Y:4] (400B, ×2) 4. TX CONNECT …normal Photon reliable-UDP… ← now accepted

receive path: System.Net.Sockets.Socket::Receive → gzp::b (libil2cpp+0x6491808) → ExecutionContext::RunInternal send path: …Photon send queue… → System.Net.Sockets.Socket::Send_internal gzp::b = receive loop that processes the challenge and builds the confirm gzp::a7a (libil2cpp+0x6490b2c) = send · gzp::a7b (libil2cpp+0x64911d8) = receive

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. │ └──────────────────────────────────────────────────────────────────┘