The missing signal in gaming fraud: What the running game can tell you

What your fraud stack misses from the backend

Fraud systems are set up to view accounts, transactions, rewards, and player behavior. But we can add another source of evidence. This logic happens inside the client when triggered by a gamer, and sometimes, a hacker.

We call this the running game, or the client at runtime. It’s the live game client executing on the player’s device, including its code, runtime state, and interactions with the device, embedded AI models, and backend services.

Imagine a player claims a new-user reward. Or an account starts behaving unusually. Maybe a device disappears and returns as a new installation. These events can surface in backend data. But security and fraud teams are inundated with alerts, false positives, and uncorrelated signals that cloud decisioning and action.

But there’s another side to the activity. Was the game modified? Was code injected? Was a hooking framework present? Was someone debugging the client or running an unauthorized version of it? Or attempting to bypass detection models, cheat, or abuse backend business logic?

None of those signals alone prove fraud. What they can do is add context to evidence that already exists elsewhere. It’s a correlation that points to the missing signal.

Backend and runtime provide two sets of evidence about the same activity that can be correlated to provide a wider fraud and abuse context. Their combination still doesn't prove fraud. It gives the fraud/abuse team a fuller picture from which to make its own assessment.

Fraud and abuse can operate through the running game

Mobile game fraud is often discussed in terms of payments, stolen credentials, or suspicious player behavior. But some forms of abuse depend on manipulating the game itself. The code, logic, embedded secrets, and on-device models.

Read more: Mobile game security in Unity and Unreal: Reducing cheat ROI at runtime

Attackers have many tactics at their disposal. They may modify a game to change its behavior. They can hook functions at runtime or inject code. Many focus on reverse-engineering business logic or interfering with controls protecting purchases and entitlements.

The client is part of the attack surface

Researchers from The Ohio State University analyzed 39,121 Unity mobile games for weaknesses in in-app purchase verification. They identified 8,954 with vulnerable payment verification. Of those, 8,233 performed no verification and 721 verified transactions locally inside the game. [1]

That doesn’t mean all 8,954 games were being exploited. It shows what can happen when security-sensitive decisions depend too heavily on logic running in an environment the attacker can target.

Purchases are only one example. Once somebody can manipulate or instrument the running game, the state of the client runtime becomes relevant for all business logic, including entitlements, promotions, in-app purchases, and to ensure the integrity of embedded AI models used for fraud detection, anti-cheat, and NPC logic.

Cheater, attacker, or fraudster?

Imagine a debugger attached to a game. That provides information about the execution environment. But we don't yet know why the debugger is there.

Read more: App Threat Report Q3 2026: GPU debugger abuse in Android apps

The same applies to a rooted device, a modified client, hooking activity, or other signs of manipulation. These conditions signal increased risk. They don’t prove that the player behind the session is committing fraud.

Runtime signals are evidence, not guilt

Someone may be modifying a game to gain a competitive advantage or bragging rights. Another attacker could be attempting to reverse engineer it. Such client manipulation could be one part of a wider scheme to extract money, rewards, or other value. The technical event alone doesn’t tell us which one we’re observing.

Google takes this into account in its own Play Integrity guidance. It recommends initially collecting integrity verdicts without enforcement, then analyzing how those results correlate with existing abuse signals and historical abuse data before deciding how to respond. [2]

Useful analysis is not limited to listing of suspicious activity happening inside the client. It must press forward towards a discovery of what else was happening around it.

Correlation gives runtime evidence meaning

Let’s take an example of a rooted device. On its own, that may tell us little about intent. Many gamers use Android devices and root them to make them more customizable.

Now suppose the same environment shows signs of hooking. The player account is new. A new-user benefit is claimed. The game is then reinstalled and another supposedly new player appears.

Each event means something different. But taken together, they provide context.

This is exactly the point at which runtime evidence can complement the information gaming companies already collect. Account history shows who is acting. Transaction data records commercial activity. Player behavior reveals unusual patterns.

Our “missing signal” isn’t one detection event. It’s what happens when evidence is combined.

Read more: How to make mobile attack telemetry useful for fraud, security operations, and audit teams

The runtime insight

Runtime signals add another question: What was happening to the game itself while that activity took place?

Google recommends a comparable approach for Play Integrity: compare integrity results with existing abuse signals and historical abuse data, then use that analysis to determine an appropriate enforcement strategy. [2]

For gaming fraud teams, there is no requirement to replace any systems already doing the analysis. It means giving them another source of evidence to work with.

Promon Insight is designed to surface runtime signals from inside the protected game so they can be considered alongside wider behavior, environment, and device context. Signals relevant to gaming can include evidence of hooking frameworks, repackaging, debugging, native code hooks, code injection, or tampering with on-device AI models and logic.

None of those says, on its own, this player is a fraudster. Their value comes from what they add to the rest of the picture.

Reinstall abuse shows why continuity matters

One particularly clear example is an attacker repeatedly trying to appear new. Consider a device farm used for acquisition fraud. A device clicks an ad, installs a game, completes an action that triggers a payout, changes or resets identifying information, removes the app, and starts the process again. What is physically one source of activity can begin to look like several unrelated new users.

The same principle can apply to promotional abuse. Someone claims a welcome benefit or referral reward, reinstalls the game, and attempts to return as a new player.

Read more: The revenue leak you don’t see: When attackers rewrite your monetization rules

This problem is established enough that both Google and Apple provide mechanisms for retaining limited anti-abuse context across reinstalls.

Google and Apple fight fraud

Google's Device Recall allows developers to store three custom values associated with a device on Google's servers. Those values can be retrieved after the app is reinstalled or the device is reset. Google's own examples include remembering devices that have already redeemed high-value items and devices repeatedly used to create new accounts for abusive purposes. [3]

Apple has described a similar problem in its DeviceCheck guidance. Its example is someone repeatedly reinstalling an app to claim a single-use promotional item. Apple says DeviceCheck state can persist across app reinstallation, device transfer between users, and an "Erase all contents and settings" operation. [4]

Reinstalling isn't suspicious by itself. Players reinstall games for ordinary reasons. The useful information is the element of continuity.

Promon's Persistent App ID can help gaming teams connect repeat activity across reinstall attempts with the wider evidence around it. That can make it harder for the same source of abuse to return repeatedly by the same malicious actor on the same device.

Protect inside the game. Use the evidence outside it.

Protection and evidence provision are two different security jobs. The first is to protect the game while it is running. The second job is to make relevant runtime evidence useful beyond the app.

Shield acts locally to protect the running game. Insight surfaces runtime evidence for use beyond the game, where it can inform wider fraud and anti-cheat analysis.

App protection

Promon Shield can detect application manipulation and respond according to the protection policy configured for the game. If a protection is configured to act when a particular condition is detected, the response can happen inside the application.

This self-defending application security enforcement means there is no requirement on Promon Shield to decide whether the player is a fraudster.

Runtime evidence

Promon Insight can correlate signals about the state of the running game. Those signals can then form part of the wider context available to fraud teams, anti-cheat systems, analytics, or investigations.

Shield can respond to manipulation according to application-security policy. Insight can help surface evidence of that activity, using the trusted telemetry delivered by Shield and emerging threat intelligence. But it’s the role of the gaming company to decide what the combined evidence means for a player, account, or transaction.

Give existing fraud systems another view

Backend systems already provide gaming companies with a great deal of information. They can identify strange account behavior and see repeated reward claims, suspicious transactions, abnormal progression, and other patterns that warrant investigation. Some already consume network, device, and behavioral information from other sources.

Runtime protection adds a different view. It provides evidence about the condition inside the client running the app. It answers question like:

• Was the application modified?

• Was code hooked or injected?

• Was someone debugging the game?

• Were on-device models and logic tampered with or bypassed?

• Was the player running an unauthorized build?

Two sessions that look similar in backend data may look very different when you can also see what was happening inside the running application. This explains why correlation matters.

Account information tells you about the account. Behavioral data tells you how it is being used. Runtime signals can add in-app evidence about the game as the client runs it. The games’ authenticity and integrity coupled with the player’s intent. Value comes from connecting those views.

From technical anomaly to fraud context

A debugger does not prove fraud. Neither does a reinstall, a rooted device, or one suspicious account or unusual event. But the question changes when those signals start appearing together.

Runtime evidence connected with player history, account activity, device integrity, and behavioral events can help teams distinguish an isolated technical anomaly from a wider pattern of fraud and abuse.

That creates two opportunities for mobile game companies.

1. They can protect the running game when manipulation occurs.

2. They can make evidence from inside that game available to the people and systems trying to understand what the player is actually doing.

So, our missing signal is not another isolated alert. It means what the running game can tell you when you connect it to the rest of the story.

References

[1] Chaoshun Zuo and Zhiqiang Lin, Playing Without Paying: Detecting Vulnerable Payment Verification in Native Binaries of Unity Mobile Games, 31st USENIX Security Symposium, August 2022. USENIX Security 2022 paper

[2] Dom Elliott and Eric Lynch, Stronger threat detection, simpler integration: Protect your growth with the Play Integrity API, Android Developers Blog, November 19, 2025. Google Android Developers Blog

[3] Google, Detect repeat abuse using device recall (beta), Play Integrity documentation, last updated June 8, 2026. Google Play Integrity documentation

[4] Apple, Mitigate fraud with App Attest and DeviceCheck, WWDC21. Apple Developer video and transcript