Skip to main content
Best-effort symbol/string survey of the 7 most relevant native libraries, no disassembly, no Ghidra, beyond one targeted ARM64 disassembly of libxlua.so’s CalcChatSign helper performed in a later research pass to close an open question (see the feasibility table below and Findings & further work). The question that matters: does anything below the protocol layer block a clean-room Go client? For the one existing account tested against production, the answer is no, see the Warning below for the full scope.

​
libil2cpp.so confirms the hot-update architecture

Only 1.8 MB, small for a Unity IL2CPP binary, and for good reason: it contains zero strings for AESHelper, NetworkManager, SendLuaMessage, or even generic Unity type names. Assembly-CSharp is never AOT-compiled here at all, everything gameplay-relevant genuinely lives in the hot-update .mdl tier, interpreted via HybridCLR. This is a clean, non-ambiguous confirmation, not an absence of evidence.

​
Feasibility table

MechanismWhere it enters the wire protocolBlocking risk
ShuMei device fingerprint (boxId)login field shumeiBoxIdNone identified, live-tested (see Live validation against production): empty/synthetic values are accepted without issue for a brand-new guest account; reconnecting into an established account initially looked ShuMei-gated but turned out to be an unrelated packageName/platform/appVersion identity mismatch against the access token, fixed, reconnect worked at the time against the code as it then shipped (a later security fix replaced part of the request with placeholders, and whether reconnect still succeeds is now an open question, see Live validation against production), and no ShuMei-specific block was ever found
Tencent ACE anti-cheat reportNot found on the game-server protocol at all, local IPC to Tencent’s own backendNone identified
SecurityCode/OneCode/CoreVlogin request, ~3 fieldsNone: plain MD5 with a hardcoded salt, fully reproducible
packageSign (despite the name, not a cert hash, see Findings & further work)login requestNone: actually SHA1(packageName), a constant public string; trivially reproducible without touching the APK’s real signature. The field that genuinely depends on the signing cert is psh (see Identity, login & session), and the Go client reproduces it correctly for the Android identity, under iOS mode it still sends the Android-derived value, since no live iOS capture of this field exists to confirm what a real iOS client would send instead.
libxlua.so CalcChatSign/AES/MD5 helpersLua-native crypto call from ChatNetManager:InitWebSocketInst (alternate chat transport)None, resolved via direct ARM64 disassembly (see Findings & further work): plain unkeyed MD5(MD5(appId+uid)+timestamp), byte-identical to the known C# formula, no custom key material
TLS / certificate validationAll HTTPS trafficNone: standard chain validation, no pinning evidence found anywhere
Google Play Integrity / SafetyNet, Not used at all in this build
Bottom line, updated after live testing, see Live validation against production. Static analysis alone said nothing here blocks impersonation, and live testing against production confirms it fully for guest accounts: nothing blocks a pure Go client from creating and driving new guest accounts or from completing the email-verification bind of a guest session to a real account, both work end-to-end, repeatedly, against the real account used for testing. Reconnecting into an already-established account’s live game state also worked end-to-end at the time it was tested, but that test used the ta analytics blob’s real captured device/anti-fraud sub-fields; a later security fix (see Live validation against production) replaced those sub-fields with placeholders, and reconnect is now re-confirmed still working with those placeholders, an unattended cron reconnected and collected real resources over multiple days (August 2026), so the server does not require ta’s real device sub-fields. The reconnect step initially looked like a genuine protocol-level session gate (reproducibly rejected, even replaying that account’s own genuine device credentials from a real prior login), but turned out to be a packageName/platform/appVersion/versionCode identity mismatch against the access token, not a security check, see Live validation against production for the full methodology, test matrix, and the current state of the reconnect open question.