I didn’t decompile these games. An AI agent did.
An AI agent took apart two top-grossing mobile games, Coin Master and Royal Match, using only their public builds, and looked at a third, Monopoly GO. Also, it found security issues and flagged them privately.
Given that, we’re not publishing how we did it.
The static read itself was quick: about 7 seconds for Monopoly GO, 12 for Royal Match and 34 for Coin Master. From download to a written set of findings on Coin Master took about 25 minutes, most of it reading. The agent’s own estimate for a non-expert doing the same by hand: half a day to two days.
That gap is the story. Not just what’s in these decompiled games, but what’s now possible for anyone, against any game, including yours.
So the real question isn’t what these studios could obfuscate. It’s whether easy decompiling puts a studio at serious risk of being copied or attacked, and, since this is now the new normal, how developers should react to it or whether to try and use it.
If you own a hit, what’s exposed and how do you protect it? If you’re entering a category someone else owns, what can you learn?
How it worked
Hard line: static analysis only. The agent installed and ran nothing, made no account, and contacted no game server. It read public Android builds. It saw names and shipped data, not live values. Keep that in mind for everything below.
What came out
The app manifest. What the app declares about itself and what it asks permission to do.
The Android wrapper code. On Android, the shell around the game (store, ads, login, push) ships as DEX, a bytecode format that’s easy to read back into near-source. The game itself is compiled separately, but its type and function names ship alongside it.
The game assets and config files. Art, levels, and tuning data.
What about iOS? We only analyzed Android builds, so nothing here is a measured iOS finding. In general terms: iOS has no DEX. The wrapper and the game are compiled to native machine code, and the app is encrypted on the store side, so the easy first layer on Android isn’t there. But these games are built on a cross-platform engine, and that engine keeps its type and function names alongside the compiled code on both platforms, and the assets and config files ship either way. Expect iOS to take a bit more effort, not to be meaningfully safer.
The big split: who decides
Coin Master puts the outcome on the server. The code has a clean request-and-response loop for the slot: the client asks for a spin, the server returns the result, and the reels stop on it. Raids, attacks, the probability mini-games, and gacha follow the same pattern. The client handles presentation: animations, reel effects, odds pop-ups, ad pacing. The build contains no drop tables. The odds aren’t there to find.
Royal Match runs on the client. Levels play out on the device. There’s no per-level outcome request. The client syncs progress to the backend (basic data, inventory, area, logs) and reports event scores. The install ships 14,700 numbered level files, plus a few hundred story, challenge, and reactivation levels, with remote updates.
Why each choice fits the game, and what flipping would cost
These approaches suit different products. Either studio could flip. It would cost them.
The economy. In Coin Master, spins and coins are the currency, the product, and the thing people pay for. If the client decided outcomes, anyone with a memory editor could print coins, and the odds would be public in the build. In Royal Match, what you spend are moves, lives, and boosters inside a level you play alone. Cheating one level mostly hurts the cheater’s own fun. What actually moves money, purchases, is verified on the server, and the client checks it’s talking to a genuine app.
Other players. Coin Master is social and asynchronous: you attack and raid other people’s villages. Somebody has to referee that, and it can’t be the attacker’s phone. Royal Match levels have no opponent. The competitive events only need a score reported.
Offline play and latency. A match-3 is played hundreds of times in short sessions, often with bad signal. It has to feel instant, and Royal Match’s own store listing sells it as playable with no wifi. A slot spin can afford a round trip, because the reels spinning cover it.
Live-ops speed. Coin Master tunes from the server: odds, events, and about 800 named remote toggles, all changeable without an app update. Royal Match ships its level book and difficulty tables, and updates them with remotely delivered level packs, numbered A/B tests, and backend flags.
Server cost. Server authority means a server call for every spin and raid, for every player, at top-grossing scale. Client authority means the heavy lifting runs on hardware the player already paid for. We didn’t measure either studio’s costs, but the direction is clear.
If Coin Master flipped to be more client-authoritative, it would save on servers and feel snappier, and it would hand its economy to cheaters and its odds to every competitor. If Royal Match flipped to be more server-authoritative, it would keep its level book private, and it would lose offline play, add delay to every level, and pay server costs on every move people make.
Coin Master vs Monopoly GO: same bet, different details
Monopoly GO is Coin Master’s closest same-genre rival: a roll-for-rewards loop, an economy built around a scarce currency (dice instead of spins), and social features. The agent read less of it, and its Android build was only available as a 32-bit version, so treat this as a lighter read.
Same approach. Monopoly GO’s code is organized around client actions and server results: the client sends a roll action, gets back a result with sub-results and error codes, and plays it out as animated sequences. There are a few hundred of those result types. Going by the names, the server decides the roll and the rewards, like Coin Master. Same genre, same answer.
Different details:
Protection. Coin Master doesn’t obfuscate its code. Monopoly GO ships a commercial obfuscation and anti-tamper product, plus root and tool detection. The static read still worked in 7 seconds.
Structure. Coin Master reads as a request-and-response loop per feature. Monopoly GO wraps everything in one general action-and-result system, so new features plug into the same pipe.
Live ops. Coin Master exposes about 800 descriptively named toggles. Monopoly GO’s live ops leans on a real-time messaging layer, and its social side includes sticker albums and album trading. We didn’t measure an equivalent toggle count for Monopoly GO, so I won’t compare one.
So genre isn’t what splits Coin Master and Monopoly GO. It’s how much each spends to make the client hard to read. Since the server holds the numbers in both, that spend buys less than you’d think.
The trade-off, in one table
What’s on the device, and what isn’t
Coin Master: the shape of the machine, not the settings. You can read which levers exist. You can’t read where they’re set.
The ad system. The code contains an ad-bidding client that sends standard ad-tech inputs (lifetime value, purchase history, attribution source) to a prediction service and gets back a prediction. Interstitials are gated on the device by a daily cap, a delay before the first one in a session, and a cooldown after a purchase. That last one is a good, player-friendly rule: don’t hit someone with an ad right after they paid you.
Presentation of results. Near-win animation scenarios weighted per symbol, and a function that compares the “expected” and “displayed” reel symbols for analytics. The server picks the result; the client picks how to show it. The weights themselves aren’t in the dump.
About 800 remote toggle names, dozens of them named as fix kill-switches. A mature live game runs as much through bug-fix flags as through content.
Payments. A payment-choice type that includes direct real-money purchase and plumbing for a web shop. Like most top grossers, Moon Active is building direct-to-consumer.
Royal Match: the settings ship too.
Dynamic difficulty, as data. Two tables, Easy and Hard, covering levels 1 to 1,100, keyed by level band and try counts. The code has a difficulty system that estimates player skill and adjusts the move count, with hooks on level fail, success, and play-on. Going by the names, move counts can adapt to how you’re doing. That’s a normal puzzle pacing tool, and a static read can’t show which players get which table.
Offers and economy constants. Coin-pack sizes ship as constants. Segmented offers and event default configs ship as data. The A/B registry names its experiments: play-on price change, reward reduction, an offer for extremely hard levels, and more. 119 numbered test IDs in all.
An ad stack. A complete integration from a major ad network, interstitial and rewarded, gated by an “in-game ads” A/B group, level thresholds, a cooldown, the no-ads purchase, storefront country, and a backend kill switch. The naming points to a limited experiment, not a default. Whether any real player sees an ad can’t be known from a static read, so I won’t claim it.
A web store through a third-party provider, gated by country, with a first-purchase bonus and its own A/B tests.
Two live-ops philosophies
Coin Master runs on named switches: hundreds of descriptive toggle keys, values from remote config. Royal Match runs on numbered experiments plus backend flags and remotely delivered content. It has no string-keyed toggle system.
Descriptive names are faster for a team to operate. Numbered IDs give away less to a reader. Both are reasonable, but only one tells an outside agent your roadmap in plain English.
Same with build hygiene. The Coin Master build contains some development residue: source-control info, test and mocking configs, profiling and test code, and debug panels that appear to be stubbed out. Royal Match’s build is lighter. Every studio ships some of this. I’ve shipped plenty. The difference now is that someone will read it.
What a copier gets, and what they don’t
From Coin Master, a copier gets the blueprint. The feature list, the flow, the toggle names, the shape of the network calls, what the ad model measures. They don’t get the odds, prices, segments, live toggle values, or the backend. They’d have to rebuild the economy blind, and in that genre the economy is the product.
From Royal Match, a copier gets the level book. This time the agent decoded the shipped level files. Every one of the 14,700 numbered levels read back cleanly from the public build: the board size and layout, the move limit, the goals (which blockers or pieces to clear, and how many), the starting pieces and obstacles, and which colors are in play. Every level is unique. Combined with the difficulty tables and event configs, that’s the whole designed puzzle curve, no playing required. We’re not publishing any of it. Still hidden: who’s in which test, backend flags, live offers, remote level updates, and the backend itself.
What nobody gets from either: the live-ops team, the content cadence, the UA machine, the brand, and the data flywheel that tunes it all. Royal Match is a top-grossing game with its level book on the device. The dump shows the levers, not the people pulling them.
So: exposed, not dead. What changed is time-to-copy. It went from months of playing and note-taking to minutes.
Obfuscation is a speed bump. Server authority is the wall.
Neither Coin Master nor Royal Match obfuscates its code. Monopoly GO does, with a commercial obfuscation and anti-tamper product. The agent’s static read got through it in seconds.
Obfuscation and anti-tamper add time and cost for whoever is reading. An agent’s time is almost free, and it doesn’t get bored. If you want something secret, don’t ship it.
What incumbent game developers risk, and how to protect yourself
The risk is real but narrower than it sounds. A rival can read your feature set, your flows, your live-ops levers and, if you’re client-authoritative, your content and tuning. Security holes in the build are now found in minutes, by anyone. What a rival can’t take is what kept you on top: the team, the cadence, the brand, the community, the UA, and the data.
Decide the client/server split on purpose. It decides what a rival can read and what a cheater can change. If odds, prices, or economy rules matter, keep them on the server.
Put integrity checks where value moves. Purchases, currency, progress. All three games do this.
If you’re client-authoritative, assume your content is public. Deliver the newest levels and tuning remotely, and stay ahead on content speed rather than relying on secrecy.
Use opaque config and experiment IDs. Cheap, and it stops your roadmap from reading like a press release.
Audit your shipped build for secrets. Make sure no private keys, secrets, or credentials are anywhere in it. A decompile surfaces them in seconds, and anyone can run one.
Strip build residue. Test and mock configs, debug tools, source-control info.
Don’t count on obfuscation. It’s a speed bump. Budget for it as one.
Read your own build every release. It takes minutes now. Find the security issues before someone else does.
What insurgent developers gain now that decompiling is trivial
If you’re entering a category someone else owns, the incumbent’s build is now the most detailed public design document you’ll ever get.
The architecture call, made for you. See how the leader split client and server, then decide whether your game type needs the same split or a different one.
The full feature and live-ops surface. Which systems exist, how they connect, which experiments are running, and what they’re named.
Monetization design. What the ad model measures, how ads are paced, how offers are structured, where web shops and direct payment are heading.
The difficulty curve. In a client-authoritative game, the level structure and pacing of the leader’s early game.
What not to copy. The things you can’t read (odds, live values, segments) are the things you’ll have to earn with your own data and team.
Copying the levels isn’t the advantage; the incumbent already has thousands and ships more every week. The advantage is skipping months of reverse-engineering by play, and spending that time on what’s actually different about your game.
The point
Last week, in ONE PROMPT. FULL BUILD. BULL SHIT., I argued that AI alone can’t make a game that sells. I still believe that. But it can certainly help. It can take apart a game that sells in less time than it takes to get the meeting on the calendar.
Moon Active, Dream Games, and Scopely built some of the best-run mobile games, and their builds show careful, deliberate engineering. The lesson isn’t about them. Whatever you ship is effectively published, so build with that in mind.
Method note: an AI research agent ran static analysis only on public Android builds. It ran nothing, used no account, and contacted no game server. Behavior described here is inferred from names in the code and shipped data; no runtime values were observed. Security issues found were flagged privately. We deliberately do not publish methods, level data, or security details.