Skip to main content
Live-tested findings on this page were confirmed against production on 2026-07-03, using client identity com.lastwar.ios v1.0.344 (build 786) for the reconnect/collection path and com.fun.lastwar.gp v1.0.351 for the bootstrap/guest-login path. This documents an unofficial third-party game server’s behavior, which the operator can change at any time without notice — treat anything marked Confirmed or Resolved on this page as true as of that date, not a permanent guarantee. If a command, field, or error code described here stops matching reality, re-verify against a fresh packet capture before assuming this documentation is still correct.
This is an unofficial reverse-engineering dossier, assembled for interoperability research. It’s a from-the-APK reconstruction of the client architecture, the gate-server crypto, the SmartFoxServer wire protocol, and the full 3,178-command protocol surface — assembled to spec a compatible Go client.

Extraction methodology

How the three custom, undocumented file formats were reverse-engineered from first principles.

Live validation

What’s been confirmed by actually round-tripping traffic against production, versus what’s static-analysis-only.

Go implementation roadmap

What a compatible Go client needs to implement, and in what order.

Game entity ID reference

The full catalog of game entity IDs recovered from the data tables.
Last War is a Unity game with almost none of its logic compiled into the app you download. Three independent, independently-updatable layers sit on top of a thin native core, and only the crypto and wire protocol are what a Go client needs to reimplement.

​
Client architecture

The client is built on Unity + IL2CPP, but IL2CPP compiles almost nothing of the game itself. Instead:
  • Gameplay logic and UI — city building, army/hero systems, world map, alliance, chat, mail, shop, and essentially every one of the 3,178 network commands — is written in Lua (18,514 compiled modules, hot-updated as one bundle).
  • Engine glue and platform integration — the network stack, the crypto, asset/resource management, and third-party SDK wiring — lives in hot-updatable C#, shipped as 117 hot-swappable assemblies via HybridCLR, interpreted at runtime rather than AOT-compiled.
  • The static core — libil2cpp.so, the Unity engine runtime, and the native HybridCLR/xLua interpreters — is what’s actually fixed at app-store-release granularity. It contains no game logic at all (confirmed empirically, see Native binaries & security).
Two transports carry traffic to FunPlus’s servers:
  • HTTP(S) for bootstrap — version check, hot-update manifests, and gate-server discovery (the “GSL” flow) — wrapped in a custom RSA+AES hybrid scheme.
  • A raw TCP socket speaking a hand-rolled reimplementation of SmartFoxServer 2X’s binary SFSObject protocol, carrying every gameplay command as a string cmd (e.g. "mail.read") plus a typed key/value payload.

​
Layer diagram

​
What a Go client actually needs

Only two of these three layers matter for protocol compatibility: the crypto (Gate-server crypto) and the wire format (SFS2X wire protocol, Command reference). The Lua/C# split is a client-implementation detail — a Go client talks TCP and HTTP directly and never touches Lua. The native-binary survey exists to answer one practical question: does anything below the protocol layer (anti-cheat, device attestation, signing) block a clean-room client?
Short answer: no, for creating and driving new guest accounts, and for binding a guest session to a real account via email verification — both confirmed live, end to end, repeatedly. Reconnecting into an already-established account’s live game state worked live too, at the time it was tested, but a later security fix means whether it still succeeds against the code as it ships today is an open, unconfirmed question, not a proven-working recipe — see Native binaries & security and Live validation against production for the full scope and current state.