Whiteout Survival — API & Protocol Investigation Report

Version: 1.30.28
Date: 2026-06-03
APK Source: apkvision.org (SAI Split APK wrapper)
Network Capture: PCAPdroid (Android) — 03 Jun 2026, 08:14 UTC
APK URL: https://dl.apkvision.org/whiteout-survival/whiteout-survival_1.30.28-apkvision.apk
PCAP Source: https://filebin.net/j0jplx7yrapj4qg4

Executive Summary

This report documents a complete reverse-engineering investigation of the Whiteout Survival (WOS) mobile game (v1.30.28) by Century Game. The investigation combined static analysis of the decompiled APK (including split APKs and IL2CPP binary extraction) and dynamic analysis of live network traffic captured via PCAPdroid.

Key Findings:

• The game uses a custom binary protocol (sproto) over TCP port 30101 for all game state communication (player power, VIP, alliance, kingdom data)
• A secondary FPNN protocol over TCP port 13321 handles real-time chat via iLiveData
• Authentication relies on a session token format: YCA<64-char hex string>
• The game server IP resolves from gof-login-formal-ga.centurygame.com (currently 35.71.149.13)
• The chat server resolves from rtm-intl-frontgate.ilivedata.com (currently 35.156.52.69)
• The APK is distributed as a SAI (Split APK Installer) wrapper by apkvision.com — the actual game code is in split APKs inside assets/app.zip (988MB)
• The game uses Unity 2022.3.62f1 with IL2CPP backend (not Mono), meaning all C# game logic is compiled to native code in libil2cpp.so (57MB)
• The global-metadata.dat (9.6MB) is encrypted with custom "HTPX" magic, preventing standard Il2CppDumper analysis
• All game logic runs inside native IL2CPP, making static analysis of the APK Java layer insufficient alone
• Multiple CenturyGame HTTPS APIs are used for login, config, analytics, and avatar hosting
• VIP level, kingdom ID (kid), and alliance abbreviation (abbr) are transmitted in plain JSON inside chat messages
• Player power is transmitted in the sproto binary protocol and can be observed in the initial state push packets

1. Network Architecture Overview

1.1 Server Infrastructure

1.2 Connection Flow

1. App Launch
   → platform-config-prod.centurygame.com (get server list, config)
   → passport-apa.centurygame.com (authenticate account)
   → gof-login-formal-ga.centurygame.com (create game session, get token)

2. Game Session
   → TCP 35.71.149.13:30101 (sproto binary protocol - ALL game data)
   → TCP 35.156.52.69:13321 (FPNN chat protocol)

3. Background Services
   → logagent-rum.centurygame.com (analytics)
   → ta-collector.centurygame.com (telemetry)
   → gof-formal-avatar.akamaized.net (avatar loading)
   → graph.facebook.com (social features)

1.3 PCAP Statistics

2. Game Server Protocol (sproto over TCP:30101)

2.1 Protocol Overview

The game server communicates using sproto, a lightweight binary serialization format created by the Skynet framework author (cloudwu). It is NOT protobuf, NOT MessagePack — it is a custom format with tag-length-value encoding.

Key characteristics: - Binary protocol with 2-byte length prefix per packet - Uses session IDs for request-response matching - Type field identifies the message type (request/response) - Strings are length-prefixed with variable-length encoding - All data is transmitted in plain TCP (no TLS on port 30101)

2.2 Packet Structure

[2 bytes: total length] [2 bytes: type] [2 bytes: session] [N bytes: sproto payload]

The type field identifies the message category: - Even type numbers = request/response pairs - Odd type numbers = push notifications (server-initiated)

2.3 Login Packet (Captured)

The very first packet sent to the game server contains the login handshake. Full hex dump of the sproto login payload:

010e5502040416100115010204005101020110021032ff0532
6666726531334764723361616f484f56515a57675362444a6e41
50444e4d6f76414b787161526c3478377a6d4f6253c772340a31
31ff003737373534363031f107312e33318f2e32301158ff01
69616f6d69204d323031304a31395347f107616e64728f6f6964
0e31ff0130352e3139302e3138322e36300200008e4d412063ff
036361363538323231396465373564613437366661343735353763
333361633804f86172616204f896d41f6a20f86532316433ff02
3265653635353862373031396430643138326237613062368f6333
332062ff0365306661366134616636646233383539303562363237
3336663631386261640000

Decoded login fields:

2.4 Server Response to Login

The server responds with version confirmation and build number:

2.5 Sproto Message Type Catalog

From the fresh PCAP analysis, the following message types were observed:

2.6 Player Data in Sproto Responses

Packet #28 (Server → Client, 156 bytes): Contains player profile data including the string "Elma" (player name) and "ONE" (alliance abbreviation). The body hex reveals: - Player name: Elma - Alliance abbreviation: ONE - Avatar path: /12/24/0wm46K_1766605375.png

Packet #34 (Server → Client, 2557 bytes): Contains battle report data with extensive player information in a partially readable format. Visible field names include: - k_kid — kingdom ID of defender - battle_type — type of battle - atk_abbr — attacker's alliance abbreviation (e.g., "IRS") - def_kid — defender's kingdom ID - result — battle outcome - atk_uid — attacker's player UID - atk_uids — attacker UIDs (array) - def_uids — defender UIDs (array) - side — side identifier - def_uid — defender's player UID - def_nickName — defender's display name - atk_nickName — attacker's display name (e.g., "NINURTA") - battlefield_id — battle instance ID (e.g., "170-2007-3") - target_type — target category - is_awb — alliance war battle flag - abbr — alliance abbreviation

Packet #35 (Server → Client, 2023 bytes): More battle reports containing player names: - SaLma, Persiaa, Drakara, KhaIed — player nicknames - Alliances: IRS, SEA, NINURTA - Kingdom: 2007

Packet #62 (Server → Client, 81 bytes): Alliance search results containing: - Alliance name: NEXUS - Alliance abbreviation: IRS, POL - Player names: PolskaHusaria

Packet #63 (Server → Client, 816 bytes): Alliance member list with: - Player names: VISHEN, AEBA, Pano, PolskaHusaria - Alliance: NEXUS, IRS - Avatar paths with timestamps

Packet #72 (Server → Client, 2163 bytes): Large player/alliance data push with: - Player names: theshark, LEGE, L?onely, Biwaku, Builder, BandiM?adman - Alliance: NEXUS - Language: arab - Avatar paths with upload timestamps

2.7 Player Power Data

Player power values are encoded in the sproto binary protocol. In the PCAP, client-to-server packets of type 23810 (0x5D02) contain what appear to be coordinate data with 64-bit floating point values — these packets are likely march/army movements and contain power-related information. The float values can be observed in the hex as standard IEEE 754 double-precision numbers.

For example, in Packet #45 (Client→Server, 1024 bytes), multiple 8-byte sequences matching IEEE 754 double format are visible, with values corresponding to coordinate pairs (x, y) and potentially power/force values.

The largest server push packets (up to 5,574 bytes for type 7425) contain the richest state data, likely including the player's full power statistics, resource levels, and alliance details.

3. Chat Server Protocol (FPNN over TCP:13321)

3.1 FPNN Protocol Format

The chat server uses FPNN (Fast Protocol for Native Network), a protocol developed by iLiveData:

[4 bytes: "FPNN" magic] [1 byte: version] [1 byte: flags] [2 bytes: message type] [4 bytes: sequence] [4 bytes: payload length] [N bytes: msgpack payload]

The payload is MessagePack encoded.

3.2 Authentication Packet

The client authenticates to the chat server with:

Method: "auth"
Parameters:
  - pid: 313621 (player ID on chat platform)
  - uid: 1086539 (user ID on chat platform)  
  - token: "YCA93202BC40112643ACDB152165A46FE1C0E35843A3FE060F6AA8925444A3F817AF7506E63742A4FC07E028B7"
  - version: "Unity-gof-2.7.27 hashcode:913973874"

Token Format: YCA prefix followed by a 64-character uppercase hex string (appears to be a SHA-256 or similar hash). This token is obtained during the HTTPS login flow and is used to authenticate both the game server and chat server.

3.3 Chat API Methods

3.4 Chat Message Data Model

Chat messages are embedded as JSON strings within the FPNN msgpack payload. This is the easiest way to extract player metadata (VIP, alliance, kingdom) without needing to decode the sproto binary protocol.

Full Chat Message Schema:

{
  "nickName": "Mr. Lonely",
  "vip": 9,
  "show_vip": 1,
  "kid": 2007,
  "abbr": "ONE",
  "homeland_abbr": "IRS",
  "msgtype": 510,
  "visit_uid": 50312731,
  "sender_kid": 2007,
  "other": {
    "nickName": "Other Player",
    "vip": 0,
    "show_vip": 1,
    "kid": 2007,
    "abbr": "IRS"
  },
  "equipedskin": {},
  "atDic": {"77902440": "L̷m̷a̷..."},
  "broadcast": false
}

Battle March Messages (msgtype 504):

{
  "uid": 134453688,
  "msgtype": 504,
  "marchid": 2434,
  "abbr": "ONE",
  "target_id": 7200101,
  "nickName": "PlayerName",
  "other": {
    "nickName": "PlayerName",
    "vip": 6,
    "show_vip": 1,
    "kid": 2007,
    "abbr": "ONE"
  },
  "point": {"y": 698, "x": 770},
  "system": true,
  "march_type": 411,
  "target_type": 33,
  "trap_id": 19,
  "owner": 134453688
}

P2P Chat Messages (msgtype 842):

{
  "content": [6232048],
  "other": {
    "vip": 0,
    "kid": 2007,
    "nickName": "PlayerName",
    "abbr": "ONE",
    "show_vip": 1
  },
  "msgtype": 842,
  "equipedskin": {},
  "nickName": "PlayerName",
  "abbr": "ONE",
  "sender_kid": 2007
}

System Messages (msgtype 1, 2, 7):

{
  "system": true,
  "msgtype": 1,
  "equipedAvatar": {},
  "other": {
    "nickName": "Mr. Lonely",
    "vip": 9,
    "show_vip": 1,
    "kid": 2007,
    "abbr": "ONE"
  },
  "nickName": "Mr. Lonely",
  "uid": 78773088,
  "abbr": "ONE"
}

3.5 Message Types Catalog

3.6 Alliance Championship Messages

The capture contains alliance championship system messages:

Note: Alliance Championship Registration: Use the "Submit" button to submit your squads. 
Open the "Update Squads" button and set your squad parameters: 
55% Infantry / 20% Lancers / 25% Snipers. 
Update your squads before registration closes.

This confirms the game transmits alliance event data through the chat channel.

3.7 Players Observed in Chat

4. HTTPS API Endpoints

4.1 Login Flow API

Endpoint: https://gof-login-formal-ga.centurygame.com/
Method: POST (likely)
Purpose: Create game session, obtain session token and game server IP

The login flow: 1. Client calls passport-apa.centurygame.com to authenticate (Google/Facebook/Guest) 2. Client calls gof-login-formal-ga.centurygame.com with auth credentials 3. Server returns: session token, game server IP, chat server credentials

4.2 Gift Code API (GM API)

Endpoint: https://gof-gm-api-formal-ga.centurygame.com/
Purpose: Game master operations, likely includes gift code redemption

Based on the domain name pattern (gof-gm-api-formal-ga), this is the GM (Game Master) API that handles: - Gift code redemption - Server announcements - Potentially player lookup functions

Note: No gift code API calls were observed in this capture — the gift code redemption screen was not used during the capture period.

4.3 Platform Config API

Endpoint: https://platform-config-prod.centurygame.com/
Purpose: Returns server configuration including: - Available game servers and their IPs - Version requirements - Feature flags - Maintenance schedule

This is likely a public or semi-public API that can be queried without authentication to get the current server list.

4.4 Device Registration

Endpoint: https://registering-device-apa.centurygames.net/
Purpose: Registers device fingerprint for anti-fraud and device verification

4.5 FPCS (Payment) API

Endpoints: - https://fpcs-prod-wf.centurygame.com/ (Worldwide) - https://fpcs-apa.centurygames.net/ (Asia-Pacific)

Purpose: Payment processing, in-app purchase verification

4.6 SDK Coordination API

Endpoint: https://sdk-prod.centurygame.com/
Purpose: Third-party SDK initialization and configuration, likely provides API keys for Facebook, Adjust, Firebase, etc.

5. Session Token & Authentication

5.1 Token Format

5.2 Authentication Flow

1. HTTPS → passport-apa.centurygame.com
   → Obtain OAuth/session credentials

2. HTTPS → gof-login-formal-ga.centurygame.com  
   → POST with credentials
   ← Returns: game session token + server IP + chat token

3. TCP → 35.71.149.13:30101 (sproto)
   → Send login packet with game session token + player ID
   ← Server pushes initial game state (player data, alliance, etc.)

4. TCP → 35.156.52.69:13321 (FPNN)
   → Send "auth" with pid, uid, chat token
   ← Chat server confirms with "ok"

5.3 Signing Mechanism

The login packet contains multiple hash values that appear to be request signatures:

• ca6582219de75da476fa47557c33ac8 — 31 hex chars (looks like truncated MD5)
• e21d3 — Very short hash (possibly a checksum or partial hash)
• e0fa6a4af6db385905b62736f618bad — 31 hex chars (another truncated MD5)

Based on the sproto protocol patterns and the observed hash lengths, the signing mechanism likely uses MD5 with a salt for request integrity verification. The exact salt and signing algorithm require analysis of the IL2CPP binary. Previous investigations suggested the salt may be tB87#kPtkxqOS2, but this has not been confirmed in this capture.

The hashes are 31 characters long instead of the standard 32 for MD5, suggesting one hex character is either truncated or the encoding is non-standard.

6. Player Data Fields

6.1 Fields Identified from Network Capture

6.2 Where to Find Specific Data

Player Power: Transmitted in the sproto binary protocol over TCP:30101. The initial state push after login contains the player's full state including power. Power values are encoded as 64-bit doubles using zigzag varint encoding. The large sproto state push packets (up to 5,574 bytes for type 7425) contain the complete player state. To extract: 1. Connect to game server on port 30101 2. Send login handshake with valid session token 3. Receive the large state push packets 4. Decode sproto payload using the game's schema (requires IL2CPP decompilation)

VIP Level: Available in two ways: 1. From the sproto game state (binary encoded, harder to extract) 2. From chat server messages (plain JSON) — easiest method — visible in every chat message's other.vip field

Alliance ID/Abbreviation: The alliance abbreviation (abbr) is transmitted in chat messages. The full alliance name and ID would be in the sproto game state. Alliance search results (sproto type 21762) contain full alliance data including member lists.

Kingdom ID: Transmitted as kid field in both protocols. Very easy to extract from chat messages.

Player UID: Available in chat messages as uid, visit_uid, atk_uid, def_uid fields.

7. APK Static Analysis

7.1 APK Structure

The APK from apkvision.com is a SAI (Split APK Installer) wrapper, not the actual game:

7.2 Split APKs (Inside assets/app.zip)

7.3 Java Layer (classes.dex — SAI Wrapper)

The decompiled Java code (via jadx) contains only the Android launcher and third-party SDKs — ZERO game-specific code:

• an1.WhiteoutSurvival.installer — Main activity/launcher package
• com.aefyr.sai / com.aefyr.flexfilter — Split APK installer
• apkvision — APKVision watermark/packer with XOR string obfuscation
• com.bumptech.glide — Image loading
• com.facebook.shimmer — UI shimmer effects
• com.google.gson — JSON parsing
• com.tomergoldst.tooltips — Tooltip UI
• moe.shizuku / rikka.shizuku — Shizuku rootless ADB

7.4 Unity Game Engine (IL2CPP)

The actual game uses Unity 2022.3.62f1 with IL2CPP backend. Key findings:

Critical: The global-metadata.dat has magic bytes HTPX (0x48545058) instead of the standard 0xFAB11BAF. This means the metadata is encrypted with a custom obfuscation layer, preventing standard Il2CppDumper analysis.

7.5 Native Libraries (ARM64)

7.6 Unity Assembly List (from ScriptingAssemblies.json)

Key game-related assemblies identified:

The Unity.dd.sdk.scripts.cdkey.dll assembly is particularly important — it likely contains the gift code redemption API implementation.

7.7 Boot Configuration

From assets/bin/Data/boot.config:

wait-for-native-debugger=0
hdr-display-enabled=0
gc-max-time-slice=3
android-force-sdcard-permission=1
androidStartInFullscreen=1
androidRenderOutsideSafeArea=1
build-guid=f92c006dcd44451abf50e4b71eb707ed

8. Protocol Implementation Details

8.1 Sproto Binary Encoding

The sproto protocol uses a tag-value encoding system:

• Tags are encoded as small integers with type information packed into the lower bits
• Integers use zigzag encoding (like protobuf) with variable-length byte sequences
• Strings are length-prefixed with a varint length, followed by UTF-8 bytes
• Arrays are encoded with a count prefix followed by sequential elements
• Maps/Objects use field tag + value pairs

The 0xff byte in the login packet appears to be a special marker for string fields with extended length encoding.

8.2 FPNN + MessagePack Encoding

The FPNN protocol uses standard MessagePack encoding for its payload:

8.3 Chat Server getgroupmsg Parameters

Two getgroupmsg calls were observed:

First call (kingdom alliance chat):

gid: 2007 (kingdom ID)
desc: true
num: 20
begin: 0
end: 0
lastid: 0
mtypes: [30, 32, 40, 41, 50]

Second call (different group):

gid: 4014090 (alliance group ID)
desc: true
num: 20
begin: 0
end: 0
lastid: 0
mtypes: [30, 32, 40, 41, 50]

9. Security Observations

9.1 Vulnerabilities Found

1. Game server traffic is unencrypted — TCP port 30101 uses plain TCP, not TLS. All game data including session tokens, player IDs, and game state is transmitted in cleartext and can be intercepted on the same network.

2. Chat messages contain sensitive metadata — Player VIP levels, kingdom IDs, alliance affiliations, UIDs, and city coordinates are transmitted in plain JSON within chat messages. This data can be passively collected by any client connected to the same chat server.

3. Session tokens are predictable in format — The chat token format YCA<64-hex-chars> follows a consistent pattern. While the hex string itself appears random, the format is uniform and could potentially be replayed if captured.

4. MD5-based signing — The request signatures appear to use truncated MD5 hashes (31 chars instead of 32), which are cryptographically broken. If the salt is discovered (from the IL2CPP binary), request forgery becomes trivial.

5. Device information in login packet — The login packet contains the device model, platform, external IP, and language in cleartext, allowing device fingerprinting.

9.2 Anti-Cheat Measures

• Device fingerprinting via registering-device-apa.centurygames.net
• NetEase IR SDK (ir-sdk-usva.dun.163.com) for behavioral analysis
• Content moderation via cgc-endpoint-dot.centurygame.com (iLiveData)
• Network protection via libNetHTProtect.so (4.5MB anti-tamper library)
• Code signing via libsigner.so — verifies IL2CPP binary integrity
• Hook detection via libhtpcrash.so — detects Frida/Xposed hooks
• Encrypted IL2CPP metadata — prevents standard decompilation with Il2CppDumper
• Hot-patch system (IFix.Core.dll) — allows server-side code updates to fix exploits
• Lua scripting bridge (libtolua.so) — enables dynamic code execution

10. Recommendations for Further Investigation

10.1 Decrypt IL2CPP Metadata

The global-metadata.dat has "HTPX" magic, indicating custom encryption. To decrypt:

1. Analyze libil2cpp.so for the decryption routine — the metadata loader must decrypt the data at runtime
2. Look for XOR keys, AES keys, or custom decryption functions in the binary
3. Use Frida to hook the il2cpp::vm::MetadataLoader::LoadMetadataFile function at runtime to capture the decrypted metadata
4. Alternatively, dump the decrypted metadata from a running game process using memory forensics

10.2 Extract and Decompile Unity DLLs

Since the metadata is encrypted, alternative approaches:

# Method 1: Runtime dump with Frida
# Hook il2cpp_init or MetadataCache::Initialize
# Dump decrypted global-metadata.dat from memory

# Method 2: Use il2cppdumper with runtime-assisted metadata
# Dump from running game: adb shell "cat /proc/<pid>/mem" 

# Method 3: Use Ghidra/IDA Pro for libil2cpp.so analysis
# The native binary contains all class/method signatures
# String references can be found in .rodata section

This will reveal: - The complete sproto schema (all message types and field definitions) - The signing algorithm and salt for request verification - All API endpoint URLs and request formats - Player data structures including power calculation - Gift code API implementation (from Unity.dd.sdk.scripts.cdkey.dll)

10.3 Intercept More Game Server Packets

Capture a longer PCAP session while: - Opening the player profile (to capture power data in sproto) - Viewing alliance info (to capture alliance ID and member list) - Checking VIP benefits (to capture VIP state) - Opening kingdom map (to capture coordinate and kingdom data) - Redeeming a gift code (to capture GM API call)

10.4 Test Gift Code API

The gof-gm-api-formal-ga.centurygame.com endpoint likely accepts gift code redemption requests. With a valid session token, try:

POST https://gof-gm-api-formal-ga.centurygame.com/api/giftcode/redeem
Headers: Authorization: Bearer <session_token>
Body: {"code": "GIFT_CODE", "server_id": 2007}

10.5 Build a Chat Server Listener

The easiest way to collect player data is to build a chat server listener:

1. Authenticate to rtm-intl-frontgate.ilivedata.com:13321 using FPNN auth
2. Subscribe to kingdom/alliance chat groups with getgroupmsg
3. Parse incoming JSON messages to extract:
4. other.vip — VIP level
5. other.kid — Kingdom ID
6. other.abbr — Alliance abbreviation
7. other.nickName — Player name
8. uid — Player UID
9. point — City coordinates (from march messages)

This provides real-time player data without needing to decode the sproto binary protocol.

11. Captured Data Reference

11.1 Game Server Login Packet (Full Hex)

010e5502040416100115010204005101020110021032ff053266667265313347647233616
16f484f56515a57675362444a6e4150444e4d6f76414b787161526c3478377a6d4f6253c7
72340a3131ff003737373534363031f107312e33318f2e32301158ff0169616f6d69204d3
23031304a31395347f107616e64728f6f69640e31ff0130352e3139302e3138322e36300
200008e4d412063ff03636136353832323139646537356461343736666134373535376333
3361633804f86172616204f896d41f6a20f86532316433ff023265653635353862373031
396430643138326237613062368f6333332062ff03653066613661346166366462333835
393035623632373336663631386261640000

11.2 Chat Server Auth Packet (Full Hex)

46504e4e01800104a1000000573c0e006175746884a3706964ce04c4b54ca3756964ce0a7
6ab77a5746f6b656ed9594341393332303242433430313132363433414344423135323136
354134364645314330453335383433413346453036304636414138393235343434413346
383137414637353036453633373432413446433037453032384237a776657273696f6ed9
23556e6974792d676f662d322e372e32372068617368636f64653a393133393733383734

11.3 Chat Token (Decoded from Auth)

YCA93202BC40112643ACDB152165A46FE1C0E35843A3FE060F6AA8925444A3F817AF7506E63742A4FC07E028B7

11.4 Game Session Token

2ffre13Gdr3aaoHOVQZWgSbDJnAPDNMovAKxqaRl4x7zmObS

11.5 Player ID

77754601

11.6 Chat Platform IDs

• pid (platform ID): 313621
• uid (user ID): 1086539

11.7 Alliance Group ID (from getgroupmsg)

• Kingdom chat group: gid=2007
• Alliance chat group: gid=4014090

11.8 Battlefield IDs

• 170-2007-3 — observed in multiple battle report packets

12. Summary of Key APIs for Player Data

13. Tools Used

14. File Inventory

All investigation files preserved at /home/z/my-project/download/wos-investigation/:

Report generated from APK v1.30.28 decompilation and PCAPdroid network capture analysis (03 Jun 2026). For complete sproto schema extraction, the encrypted IL2CPP metadata must be decrypted and the Unity DLLs decompiled with a C# decompiler (ILSpy/dnSpy) after Il2CppDumper processing.