How Attackers Exploit Play Integrity API and Where AppiCrypt Fits (Pt. 1/3)

Play Integrity's real limits: a 10,000-request daily quota, false positives you cannot debug, and seven documented bypasses. Plus where AppiCrypt fits.

Mobile apps operate in an environment that developers do not control. The device may be rooted, the app may have been repackaged, and the user may not be a person at all. To detect such devices is extremely important to any app that handles sensitive actions such as payments, authentication, or content access.

Google Play Integrity API is one of the main tools for this. This page explains what it does, how it works, and where it falls short.

👋 A word before we start

We build AppiCrypt® at Talsec and we spend our days inside app attestation: what the verdicts actually mean, where they hold, where they quietly stop holding, and what real fleets of devices look like when you measure them.

Nothing in this article is news to an attacker. Every technique described here is publicly documented, actively maintained, and discussed in the open.

"Do we use Play Integrity, AppiCrypt, both, or neither?" is a live question in a lot of apps right now, and the material you need to answer it is scattered across Google's docs, vendor marketing, forum threads and half-remembered advice. Our aim is simply to put it in one place.

This three-part series is written for CTOs, backend architects and mobile developers who have to decide what a device attestation verdict is allowed to authorise.

Explore the complete series:

• Part 1: How Attackers Exploit Play Integrity API — what Play Integrity does well, where its limits are, and the seven ways real attacks get around it.

• Part 2: Play Integrity Fix: why AppiCrypt is the better attestation anchor — one bypass, in depth: a Magisk module with millions of downloads, and what it says about anchoring authorisation on a single third-party verdict.

• Part 3: Combining AppiCrypt and Play Integrity — the side-by-side model: where the two overlap, where they complement, and how to bind them to one request so neither can be swapped out.

Disclaimer, for full transparency: this series uses Talsec technology. We are not the only vendor in mobile security — we are the one running on 2,500,000,000 devices.

⚡Key takeaways:

• 🚧 The 10,000 token requests per day default quota is the limit teams hit first. It is a hard planning constraint long before it is a security one.

• 🕵️ There are seven documented Play Integrity attack paths:

  • 1. ☠️ Client-side enforcement bypass,

  • 2. ☠️ Play Integrity Fix Module (PIF environment manipulation),

  • 3. ☠️ Tricky Store (Android Key Attestation certificate chain spoofing),

  • 4. Weak backend verification,

  • 5. Token substitution,

  • 6. Replay/business replay,

  • 7. Attestation relay/device farms

• 🌍 Verdicts depend on Google Play services. Custom ROMs, de-Googled builds, sideloaded distribution and weak networks all produce false negatives on legitimate users.

• 🧩 The fix is in the layering: a cryptographic proof bound to every API call, with Play Integrity as a weighted second opinion on high-risk operations.

• 💬 Your scenario may differ. Drop a message at [e-mail] and Talsec security engineers will walk through it with you.

The problem

You want only safe devices and apps reach the endpoint.

When a request reaches your backend, you know very little about its true origin. It may come from your genuine app on a real device. It may also come from an emulator, a repackaged binary, or a script built from a reversed API. At the network level, these are indistinguishable.

Some devices are not supposed to ever reach endpoint.

This is the gap Play Integrity is meant to close. It gives your backend a way to check whether a request came from a legitimate source - whether source reaching the endpoint is safe, if device is secure, if app wasn't modified or manipulated in some other way.

Requests are accepted only from valid sources.

Device Attestation

Attestation is the process of producing cryptographically verifiable evidence that a device, app, or execution environment is in a particular state.

The device submits evidence about its software, configuration, and environment to third party - attestation server. The third party evaluates that evidence and issues a signed statement describing what it found.

Your app then forwards that statement to your server, and your server (not the device) decides whether to proceed.

Play Integrity is then Google's attestation service ("Google's implementation" of attestation) for Android. Google evaluates the app and the device and returns a signed integrity token. Your app hands that token to your backend, which verifies Google issued it, reads the verdicts, and decides what to do. All of that is bundled in single API.

Process of attestation

The key concept here is verifiable security. A compromised device can lie about itself, so you can't trust it to evaluate its own security status. That's why attestation server (third party) has to do it.

Advantages of Play Integrity

Play Integrity is a genuinely good control, and this article is not an argument for turning it off. Google does something no individual app can do alone: it evaluates the device from outside your process, using hardware-backed signals, and normalises the result across thousands of device models and Android versions. You get a verdict your backend can act on without building and maintaining a device-attestation system of your own. In short:

• Server-side by design — the verdict is evaluated by your backend, so a modified client cannot simply flip a boolean and walk in.

• Not a single yes/no — you get separate verdicts (app recognition, device integrity, licensing), which lets you allow, step up, throttle or block per action instead of per user.

• Hardware-backed where it counts — Google abstracts away Android version, OEM and key-provisioning differences for you.

• Fast enough for real flows — standard requests use on-device caching and typically return in a few hundred milliseconds.

• Raises the cost of abuse meaningfully — tampered clients, emulators, bot traffic and unofficial installs can all be routed into restricted or step-up flows.

• Operationally supported — Play Console gives you configurable test responses, verdict and error reporting, and Google Play remediation dialogs for legitimate users who are genuinely broken.

Limitations of Play Integrity — starting with the one that blocks releases

A hard cap of 10,000 token requests per day.

This is the limitation most teams run into first. The default limit is 10,000 token requests and 10,000 server-side decryptions per day, per linked Google Cloud project. Higher limits can be requested, but approval is subject to eligibility, and large or sudden traffic increases can still be throttled.

Do the arithmetic before you design around it. An app with 50,000 daily active users cannot attest every session, let alone every sensitive action. You are immediately forced into rationing: attest on login only, or on payment only, or on a sampled subset — and every one of those choices is a hole you have deliberately left open, chosen by quota maths rather than by threat modelling. For a lot of teams this is the point where Play Integrity stops being a candidate for a per-request control and becomes, at best, an occasional complementary solution.

Dependency on the Google ecosystem Play Integrity depends on Google Play services and the official Google Play Store. Devices without these may not be able to obtain verdict, even when user is legitimate - Google certification is effectively acting as "security". Apps distributed outside of Google Play Store are also problematic.

Android Key Attestation can provide lower-level information without depending on the Play Integrity service, serving as partial replacement for Google Integrity.

Legitimate users can fail strict policies Devices which are otherwise legit can be considered as harmful by Google Integrity, effectively generating false positive.

Legitimate devices that routinely fail or degrade:

• Unlocked bootloader or a non-factory ROM — including privacy-focused builds such as GrapheneOS. A security-conscious user is indistinguishable from an attacker here.

• Devices no longer receiving security updates — common on older and budget hardware, and heavily concentrated in exactly the markets many apps are trying to grow in.

• Outdated or missing Play Store / Play services components — a real problem in markets where alternative mobile services are present.

• Slow or intermittent networks — attestation needs connectivity. If your app has to work offline, or your users pay by the megabyte, this is a design constraint, not an edge case.

• Emulators and test environments — including your own QA fleet.

Google-side outages are your outage.

There is also the dependency itself. The latest notable Play Integrity incident was on September 12, lasting multiple hours. If you have not built a graceful fail-open (or a considered fail-closed) path, your users see generic errors such as API_NOT_AVAILABLE or integrity timeouts, and your support queue finds out before you do.

Limited knowledge Security researchers have pointed out that because Google provides very little context on why a device failed a verdict, developers have a hard time diagnosing false positives.

If an app update accidentally triggers an integrity check failure on a specific phone model, the developer sees the failure but cannot see the underlying device telemetry causing it. With Talsec, you get complete visibility of data and can easily diagnose why the device or suspicious transaction got flagged.

Exploiting Play Integrity: seven attack paths

Play Integrity involves several components: the application, Google Play services, Google's integrity servers, the application backend, and the protected operation. An attacker does not necessarily need to forge a Google-issued token. They may instead:

• Remove or skip a check performed locally by the application.

• Exploit incomplete or inconsistent backend verification.

• Manipulate the device information observed during attestation.

• Obtain valid tokens through another trusted device.

• Perform abuse with the authentic application on a genuine device.

These attacks have different outcomes. Opening an application screen after bypassing a local check is not equivalent to convincing the backend to authorize a payment.

1. Bypassing client-side enforcement

The simplest target is an application that makes the final decision locally. Because this code runs on a device controlled by the attacker, it can potentially be patched, hooked, or skipped.

if (!integrityResult.isTrusted()) {
  showUnsupportedDeviceMessage();
  return;
}
openProtectedFeature();

Changing this branch may expose a screen or enable a button. It does not create a valid Google-issued token, and it does not bypass a backend that independently verifies integrity before performing the protected action.

Security implication The backend must make the final authorization decision. A client-side result is not sufficient authorization for payments, rewards, account changes, or access to valuable content.

2. Play Integrity Fix (PIF) Manipulating environment

Tools such as Play Integrity Fix (PIF) attack the evidence-collection stage. PIF implementations generally run through a root framework and Zygisk. They can change selected values from android.os.Build or intercept system-property queries made by the relevant Google Play services process.

PlayIntegrityFix is widely adopted tool to spoof Play Integrity verdicts.

Play Integrity Fix gets a whole article to itself — the scale of it, where it came from, and what it means for anyone anchoring authorisation on a single verdict: Part 2: Play Integrity Fix: why AppiCrypt is the better attestation anchor.

Typical targets include the build fingerprint, product identity, ROM signature, and other properties used to describe the installed Android build. The objective is not to edit the integrity token after Google produces it. The objective is to make Google Play services observe a different device identity before requesting the verdict.

PIF workflow

This is better described as evidence manipulation than token forgery. Google still creates and signs the token, but some of the evidence used before issuance may have been altered.

Security implication An acceptable Play Integrity verdict does not mean that the device will pass an application's separate root, injection, debugger, or tampering checks. PIF is not a universal bypass for banking, payment, or gaming applications.

3. Manipulating Android Key Attestation (Tricky Store)

Property spoofing primarily affects software identity. Tools such as Tricky Store target Android Key Attestation instead. Main mechanism works by modifying the certificate chain returned for key-attestation requests.

A certificate chain normally allows a remote verifier to determine whether a key was created inside trusted hardware and to inspect security properties associated with that key.

An attacker who can alter the chain returned to applications makes the environment appear to have stronger hardware-backed properties than it actually has.

Security implication A server verifying Android Key Attestation should validate the chain signatures, accepted root, attestation challenge, extension data, security level, boot state, and revocation status. Verification must occur on a trusted server, not on the potentially compromised device.

4. Exploiting weak backend verification

Manipulating the device is not always necessary. In many cases, the easier target is the application backend. A weak implementation may decrypt the token successfully but validate only one part of the response and ignore the rest.

Example of naive verification

In the example above, the result does not necessarily prove that:

• token belongs to the expected application

• token is fresh

• token is bound to the current operation

• it uses the expected signing certificate

• or satisfies the required device and licensing policy.

A complete policy may need to verify:

• The expected request package and a recent timestamp.

• The request hash or nonce for the exact protected operation.

• Application recognition, version, and signing-certificate digest.

• The device-integrity level required for that operation.

• Licensing and optional environment verdicts when relevant.

Security implication Use an explicit allow policy: authorize only when every required condition is present and valid. Missing or unevaluated fields must not silently be treated as successful results.

5. Token substitution (integration risk)

Token substitution means using a valid integrity token for a different operation than the one it was issued for, such as reusing a login token for a payment with a changed recipient. Play Integrity prevents this when it's integrated correctly. The app puts a requestHash of the operation's key fields (user, operation ID, recipient, amount, expiry) into the token request. The backend recomputes the hash from the request it actually received and rejects any mismatch.

Substitution only works when that binding is missing or broken: a token reused for the whole session, an empty or partial requestHash, a backend that never compares the hash with the received request, or hashed data serialized ambiguously.

In practice this is common. Binding every sensitive operation means a fresh token per operation, and with a default quota of 10,000 requests per day plus a round-trip to Google Play services each time, many teams attest once per session instead. That shortcut is what makes substitution possible.

AppiCrypt uses the same binding principle, but it generates the cryptogram on the device with no quota and no third-party round-trip. Binding every API call is the default rather than the expensive option, so there's no pressure to fall back to per-session attestation.

Security implication Without request binding, the token mainly answers whether an acceptable app and device produced it. Correct binding also establishes that the token was created for the current operation.

6. Replay — token replay and business replay

Token replay means submitting the same integrity token again. Standard requests include Google-managed protection against this form of replay.

Business-operation replay means executing the same payment, reward, coupon, or account action more than once, possibly with a fresh token each time.

Play Integrity can validate the new token, but it does not know whether claim ABC123 has already been processed. The backend must store one-time operation identifiers and reject or safely deduplicate repeated operations.

Security implication Use both token-level replay protection and business-level idempotency. A valid fresh token does not replace database transaction controls.

7. Attestation relay and device farms

A relay attack obtains a legitimate token from another device. Instead of making a compromised device pass, the attacker sends the operation to a genuine certified phone. That phone requests the token, and the token is returned to the attacker or submitted directly to the backend.

The token may be completely genuine. Request binding prevents the attacker from changing the operation after attestation, but it cannot always stop a genuine device from acting as an attestation oracle for the exact malicious operation.

Security implication Relay and device-farm attacks require controls outside attestation: account and device rate limits, short-lived operation IDs, session binding, transaction-velocity monitoring, and behavioural analysis.

Achieving maximum security

Google explicitly advises developers to develop enforcement strategy instead of solely relying on binary allow/deny decisions. The problem is clear: a single yes/no verdict cannot simultaneously minimize false positives (blocking legitimate users) and false negatives (missing real threats). Play Integrity cannot be your only defense.

The industry answer is layered attestation, and the honest version of it is not "replace Play Integrity". It is: pick a control you own for the decisions that must not depend on anyone else, and keep Play Integrity for the thing only Google can tell you.

Here is the whole model on one line each, before we go into either half:

	AppiCrypt®	Play Integrity
Root of trust	Talsec SDK, in your app	Google Play services
Platforms	iOS, Android, Web — no GMS dependency	Android with Google Play services only
Availability	offline-capable, no quota	needs network + Play, 10k/day default quota
Cadence	every API request	per session, or per sensitive action
Tells you	root, jailbreak, hooking, debugger, emulator, repackaging, tampering — what is happening in the runtime right now	unrecognised binary, uncertified device, unlicensed install, Play Protect state — what Google thinks of this device
Who verifies	your backend	Google, then your backend

AppiCrypt: Master Security API Layer

AppiCrypt (App Integrity Cryptogram) is a cryptographic proof of app and device integrity embedded directly in each API request. Unlike Play Integrity, which returns a periodic verdict, AppiCrypt signs every single API call with evidence of app state and device health.

AppiCrypt is cross-platform API protection and app and device-integrity verification layer. Each API call carries a unique cryptographic proof/signature, which is verified on the backend.

• Same SDK and same verification model on Android and iOS (or website). One mental model, one backend code path.

• No dependency on Google Play Services or Apple's online services. Works on any Android distribution, including EU-sovereign builds.

• Can be combined with RASP signals for a stronger runtime-aware policy decisions.

• Designed for per-request API gating, which maps well to high-risk RP actions (presentation, issuance, signature authorization).

How AppiCrypt Works

The app generates a unique cryptogram for each request that includes:

• Proof of app authenticity (binary integrity, signature verification)

• Device state (rooted/jailbroken status, emulator detection, debugger presence)

• Threat flags (accessibility service abuse, overlay attacks, tampering detection)

• Device identity and risk scoring

This cryptogram is verified on the backend. Because verification happens per-request and is cryptographically bound to the operation, the backend sees:

• Which specific app version made the call

• What device state was observed at that moment

• Whether runtime threats were active during the request

Key Advantages Over Play Integrity

Capability	AppiCrypt	Play Integrity
Platform Support	Android, iOS, Browser (Web Apps)	Android + GMS only
External Dependency	None (Talsec gives all assets to you)	Google Play Services
Backend Ownership	Developer (=you), Self-Hosted	Google, Google Cloud
Threat Signals	Fine-grained: debugger, Frida, overlays, accessibility abuse, GPS spoofing, screen lock status	Generic: device passes/fails
Response Time	Low latency, verification runs on your own backend	Hundreds of ms to seconds (network dependent)
False Positives	✅ Configurable per risk threshold, risk scoring system, threat details disclosed with many details and broader context	🛑 High-level verdict with low granularity; cannot tune independently to match the risk profile
Quota Limits	Unlimited; designed for continuous protection of every request and transaction signing	10,000 requests/day default cap; approval required for more
Service Outages	Not applicable, as stable as your backend :)	Occurs from time to time (e.g. Sept 2023 (multiple hours))
Device Coverage	Cheap/unlocked devices, custom ROMs, devices not Google-certified	Google-certified devices with active Play Services

What AppiCrypt Accomplishes

AppiCrypt establishes continuous, per-request proof that:

• The request originates from your legitimate app binary

• The device is in an acceptable security state

• No runtime hooking (Frida, Xposed) is active

• No active debugger is attached

• No tampering tools (PIF, Tricky Store) have modified the environment

Because this proof travels with every request, the backend can make fine-grained decisions: allow, rate-limit, require step-up auth, or block based on the exact threat state observed.

Play Integrity as Complementary Layer

Play Integrity has value, but only as an optional secondary check for specific high-risk operations. It adds signal only when:

• You explicitly want Google's hardware-backed attestation opinion

• The device has access to Google Play Services

• The overhead of a network round-trip is acceptable

• You need to verify the app was installed via official Play Store

Why This Matters

The Play Integrity outage of September 2023 locked out legitimate users for hours because apps relied solely on its verdict. With AppiCrypt as your master layer, an equivalent outage would have zero impact - every API call is verified locally on your backend with zero dependency on Google's servers.

You gain:

• Resilience: No single point of failure

• Coverage: Works on any Android device, not just Google-certified ones

• Flexibility: Granular threat signals, not binary yes/no

• Compliance: Works in regions without Google Play (India, EU-sovereign builds)

• Performance: Real-time verification, not network-dependent

Handle App Security with a Single Solution! Check Out Talsec's Premium Offer & Plan Comparison!

Apps Security Threats Report 2025

https://www.talsec.app/talsec-global-threat-report-2025

Plans Comparison

https://www.talsec.app/plans-comparison

Premium Products:

• RASP+ - An advanced security SDK that actively shields your app from reverse engineering, tampering, rooting/jailbreaking, and runtime attacks like hooking or debugging.

• AppiCrypt (Android & iOS) & AppiCrypt for Web - A backend defense system that verifies the integrity of the calling app and device to block bots, scripts, and unauthorized clients from accessing your API.

• Malware Detection - Scans the user's device for known malicious packages, suspicious "clones," and risky permissions to prevent fraud and data theft.

• Dynamic TLS Pinning - Prevents Man-in-the-Middle (MitM) attacks by validating server certificates that can be updated remotely without needing to publish a new app version.

• Secret Vault - A secure storage solution that encrypts and obfuscates sensitive data (like API keys or tokens) to prevent them from being extracted during reverse engineering.