My game got hacked! Now what?

First, take a breath. Seeing cheats, cracked builds, strange currency, or angry player reports can feel scary. But a hacked game does not always mean everything is lost. It means something needs to be checked, limited, fixed, and watched.

The best first response is calm and simple: find out what happened, protect players from more damage, collect proof, and then fix the right place. If you rush, you may ban honest players, break a safe feature, or patch the wrong part of the game.

What does hacked mean?

Players often use the word hacked for many different problems. For a Unity developer, it helps to split the report into clear groups.

• Cheating: a player changes memory, speed, health, ammo, score, or match results.
• Save editing: a player changes local save files to get coins, items, levels, or progress.
• Cracked builds: a paid game or premium feature is patched so it can be used without the normal license.
• Repackaged APKs: someone changes an Android build, signs it again, and shares it outside official stores.
• Backend abuse: someone sends fake or repeated requests to claim rewards, purchases, event points, or leaderboard scores.
• Account problems: stolen accounts, shared accounts, chargebacks, botting, or support scams.

These problems need different fixes. A save edit is not the same as a stolen server key. A modified APK is not the same as a bug in your reward API. Naming the problem makes the next step much easier.

Step 1: Confirm the report

Start by asking what proof you have. A Discord message is a signal, not a full answer. A video is helpful, but it might show an old version, a private test build, or a fake server. Logs are better, but logs can also be incomplete.

Try to collect these basics:

• Game version and build number.
• Platform, such as Steam, Android, iOS, or console.
• Player ID, account ID, device ID, or session ID when allowed.
• Time of the event, including time zone.
• The exact feature, such as shop, save file, leaderboard, or match result.
• Screenshots, videos, support tickets, server logs, and client logs.

Keep this evidence before you change anything. If you delete leaderboard rows, reset accounts, or patch code too fast, you may lose the proof that explains what really happened.

Step 2: Reduce harm safely

You do not always need the final fix before you can reduce damage. If an event reward is being abused, pause the event claim. If leaderboard scores are fake, hide or freeze the leaderboard. If a shop endpoint is giving too much currency, add a server-side limit.

Safe first actions can include:

• Pause a leaderboard, event, trade, or reward claim for a short time.
• Rate-limit suspicious requests.
• Block only the affected action instead of the whole account.
• Disable one risky server endpoint while you investigate.
• Move suspicious cases into review instead of banning immediately.
• Ask players to update if old builds are unsafe.

The goal is to protect honest players while you learn more. This is usually better than a loud public ban wave based on weak evidence.

Step 3: Find the layer that failed

A Unity game has many layers. The bug or attack path might be in the client, the backend, the store setup, a save file, a plugin, or your release process. Fixing the wrong layer can make the problem come back.

Ask these questions:

• Did the client trust a value that should have been checked by the server?
• Did the backend accept a reward, score, or purchase without enough proof?
• Did a local save file control something valuable?
• Was an Android APK modified and signed with a different key?
• Was a license check or anti-cheat check patched out?
• Was a secret key, test endpoint, or admin tool exposed?

For Unity projects, client-only trust is a common cause. The client is in the player's hands. If the client says it has 999999 coins, the backend should not accept that claim without checking if it makes sense.

Example: players edit local saves

Save editing is common in offline and single-player Unity games. A player finds the save file, changes coins or level progress, then loads the game again. This may be low risk for a solo game, but high risk if those values later affect cloud saves, leaderboards, trading, or premium rewards.

A calm response could be:

• Confirm which save values are being changed.
• Stop edited saves from submitting leaderboard scores or online rewards.
• Add save integrity checks or protected storage for future builds.
• Move valuable currency and purchases to the backend when possible.
• Give honest players a clear message if their save cannot be trusted.

For deeper prevention, read about save-game tampering and design important rewards so a local file alone cannot create value.

Example: a modified APK is spreading

On Android, someone may unpack your APK, change files, remove ads, unlock paid content, add cheats, sign it with their own key, and upload it to another website. This is stressful, but the modified copy is not the same as your official store build.

A practical response could be:

• Collect the file, download link, package name, version, and signing certificate.
• Check what was changed, such as ads, license checks, purchases, or anti-cheat.
• Report the file to hosting sites and stores when possible.
• Use install-source, package, signing, and Play Integrity signals for online trust.
• Require official builds for multiplayer, cloud saves, purchases, or events.

You can learn more in the articles about APK repackaging and Google Play signing and license checks.

Example: premium currency was abused

Premium currency needs extra care because it can affect money, refunds, trading, player trust, and legal support. If players can create paid currency by changing memory, editing saves, replaying requests, or faking purchases, act quickly but carefully.

A good first response could be:

• Pause the exact claim path if it is still active.
• Save affected account IDs, request IDs, purchase IDs, and timestamps.
• Block duplicate receipt claims or replayed reward requests.
• Move currency grants to a server ledger if they are not already there.
• Review large accounts before removing currency or banning players.

Avoid public blame until you know the facts. Some players may have received wrong currency because of your bug, not because they cheated.

Example: checks were patched out

Sometimes attackers find a clear method name like ValidateLicense, CheckCheat, or GrantReward, then patch the result. This can happen in both Mono and IL2CPP builds, although the tools and difficulty differ.

A response could be:

• Move the final decision for valuable actions to the backend.
• Make local checks less obvious with build-time protection.
• Add more than one signal, such as build identity, behavior, and server history.
• Do not tell players exactly which check was patched.
• Prepare a forced update if old builds are too easy to abuse.

Tools like Obfuscator and Anti-Cheat can help raise the cost of patching and tampering, but the backend should still own the most important decisions.

Be careful with bans

It is tempting to ban everyone who looks suspicious. Slow down. A bad ban can hurt honest players and create more damage than the original hack. Before strong punishment, check your confidence.

Good evidence can include:

• Repeated impossible actions across many sessions.
• Server logs showing fake, replayed, or impossible requests.
• A modified build signal plus suspicious behavior.
• Clear save tampering that affects online rewards.
• Multiple signals that point to the same account or device.

Weak evidence should usually lead to logging, limits, or review. Strong evidence can support stronger action. This protects both the game and honest players.

Communicate without teaching attackers

Players deserve clear updates, especially if a feature is paused or rewards are delayed. Keep the message simple and calm. Explain what is affected, what players should do, and when you expect the next update.

A good message might say:

We are investigating suspicious leaderboard activity in version 1.4. Leaderboard rewards are paused while we review the data. Normal play is still available, and we will share an update when rewards are safe to grant.

Avoid messages that explain the exact exploit, detector name, memory value, endpoint, request field, or patch location. That information belongs in internal notes, not public posts.

Plan the fix and the next release

After the first response, decide what kind of fix is needed. Some fixes can happen on the server. Others need a Unity client hotfix. Some need a forced update so old builds cannot keep abusing the same problem.

Common follow-up work includes:

• Add server validation for rewards, scores, purchases, and cooldowns.
• Protect local saves and stop them from creating trusted online value.
• Obfuscate release builds so important checks are harder to find.
• Add runtime checks for memory edits, tampering, or modified builds.
• Rotate exposed API keys, store secrets, or admin credentials.
• Improve logging so the next incident is easier to understand.

Once the fix is live, keep watching. Look at logs, support tickets, reviews, social posts, refunds, and suspicious account patterns. A fix is not finished until you know the abuse has gone down.

A calm incident checklist

Use this checklist when something feels wrong after release. It helps your team slow down, protect players, and choose the right fix.