Attack and defence in web games: a structured overview
网页游戏攻与防
Browser-based games, popular through the early 2010s and built heavily on Flash clients talking to a game server, shared a recurring set of weaknesses regardless of genre. This note organises them into the areas that mattered most: protocol security, client automation, memory tampering, save-file tampering, and account or payment fraud.
Protocol security: the core risk
The most consequential weakness was the client-server protocol itself. Whether carried over HTTP or a raw socket, the packets exchanged between a Flash client and its server encode every action a player takes. Once an attacker understands the packet format, header fields such as length, version, command and sequence number, followed by a variable-length body, they can construct arbitrary packets directly, bypassing the client entirely. This means bypassing not just the tedium of manual play but also every client-side rule the game relies on, because a crafted packet can carry whatever parameters the attacker chooses, not what the legitimate client would have sent. A server that assumes a request only ever arrives via its own client is trusting a boundary that does not actually exist.
Automation, memory and save-file tampering
Where the protocol itself is hard to reverse, attackers fall back to automating the real client (scripted mouse and keyboard input, sped up by patching timing values) or editing the client process's memory directly to change values like in-game currency or stats. Save-file tampering was a legacy concern carried over from offline Flash games: data intended to persist locally, such as a remembered login, was sometimes stored as plain text or weakly hashed, which is a meaningfully different problem from encryption and is trivial to reverse once found.
Account and payment fraud
Beyond technical exploitation, browser games faced the same account and payment fraud patterns common to any online service: credential phishing through fake tools that promise free in-game currency, social engineering, weak account-recovery flows that can be abused with minimal proof, and payment abuse through stolen top-up cards or protocol replay against payment confirmation steps.
Why these games were under-defended
Browser games typically had short development and lifecycle windows, built to monetise a player base quickly before the next title arrived. That economics discouraged investment in abuse prevention relative to longer-lived client-installed games, which is why these categories of weakness recurred across many unrelated titles rather than being specific to any one of them.
Defensive priorities
The server must itself validate every action a packet claims to represent, never trusting that a request came from the real client simply because it arrived in the expected format. Locally stored credentials need real encryption, not a bare hash, and ideally should not be stored client-side at all. Account recovery flows deserve the same security scrutiny as login itself, since a weak recovery path undermines an otherwise strong one.
Key takeaways
- The client-server protocol is the core risk: anyone who reverse-engineers the packet format can bypass client rules entirely
- Automation and memory editing are fallback techniques when the protocol itself resists reversing
- Locally stored save data and credentials are often weakly hashed rather than encrypted, and that's a meaningful difference
- Account and payment fraud (phishing, weak recovery flows, payment replay) matter as much as technical exploits
- Servers must validate every action themselves rather than trusting that traffic came from the real client
中文摘要
文章系统梳理了网页游戏的几类安全问题：协议安全（封包可被还原和篡改）、自动化与内存修改、存档安全、以及账号与充值相关的欺诈手法，并给出相应的防御建议。
This note has been rewritten and checked for this edition; it is not a copy of the original post.