> For the complete documentation index, see [llms.txt](https://docs.talsec.app/appsec-articles/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talsec.app/appsec-articles/articles/how-attackers-exploit-play-integrity-api-and-where-appicrypt-fits.md). # How Attackers Exploit Play Integrity API and Where AppiCrypt Fits 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.
{% hint style="info" %} #### 👋 A word before we start We build [**AppiCrypt®**](https://docs.talsec.app/premium-products/product/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.* {% endhint %} ## ⚡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\) PIF environment manipulation (Play Integrity Fix), * 3\) Android Key Attestation certificate chain spoofing (Tricky Store), * 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 [**info@talsec.app**](mailto:info@talsec.app) 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](https://developer.android.com/google/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

{% hint style="info" %} 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. {% endhint %} ## 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](https://developer.android.com/google/play/integrity/overview#decide-how) 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](https://developer.android.com/google/play/integrity/overview#have-anti-abuse) 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. {% hint style="info" %} [**Android Key Attestation**](https://developer.android.com/privacy-and-security/security-key-attestation) can provide lower-level information without depending on the Play Integrity service, serving as **partial** replacement for Google Integrity. {% endhint %} **Legitimate users can fail strict policies**\ Devices which are otherwise legit can be considered as harmful by Google Integrity, effectively generating [false positive](https://en.wikipedia.org/wiki/False_positives_and_false_negatives). Legitimate devices that routinely fail or degrade: * **Unlocked bootloader or a non-factory ROM** — including privacy-focused builds such as [GrapheneOS](https://grapheneos.org/). 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](https://status.play.google.com/incidents/uvQfx54dffG2zJwfYxAU). 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`](https://developer.android.com/google/play/integrity/reference/com/google/android/play/core/integrity/model/StandardIntegrityErrorCode#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. ```java 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. {% hint style="warning" %} **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. {% endhint %} ### 2. Play Integrity Fix (PIF) Manipulating environment Tools such as [**Play Integrity Fix (PIF)**](https://github.com/KOWX712/PlayIntegrityFix?utm_source=chatgpt.com) 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. *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.***](/appsec-articles/articles/play-integrity-fix-why-appicrypt-is-the-better-attestation-anchor.md) 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. {% hint style="warning" %} **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. {% endhint %} ### 3. Manipulating Android Key Attestation (Tricky Store) Property spoofing primarily affects software identity. Tools such as [**Tricky Store**](https://github.com/5ec1cff/TrickyStore?utm_source=chatgpt.com) 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. {% hint style="warning" %} **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.** {% endhint %} ### 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. {% hint style="warning" %} **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.** {% endhint %} ### 5. Token substitution A token-substitution attack uses a legitimate token for an operation other than the one for which it was intended. If the token is bound only to the application and device, it may remain cryptographically valid while saying nothing about the changed recipient or amount. For standard requests, Play Integrity provides `requestHash`. The application calculates a\ digest of the security-relevant request data. The backend independently calculates the\ expected digest from the request it actually receives and compares it with the value in the verified verdict. The digest may cover the authenticated user, session, one-time operation ID, operation type, recipient, amount, currency, and expiry time. The representation must be stable and unambiguous. {% hint style="warning" %} **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.** {% endhint %} ### 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. {% hint style="warning" %} **Security implication**\ Use both token-level replay protection and business-level idempotency. A valid fresh token\ does not replace database transaction controls. {% endhint %} ### 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. {% hint style="warning" %} **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. {% endhint %} ## Achieving maximum security [Google explicitly advises developers to develop enforcement strategy instead of solely relying on binary allow/deny decisions.](https://developer.android.com/google/play/integrity/overview#have-tiered) 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
CapabilityAppiCryptPlay Integrity
Platform SupportAndroid, iOS, Browser (Web Apps)Android + GMS only
External DependencyNoneGoogle Play Services
Backend OwnershipDeveloper, Self-HostedGoogle, Google Cloud
Threat SignalsFine-grained: debugger, Frida, overlays, accessibility abuse, GPS spoofing, screen lock statusGeneric: device passes/fails, CTS profile
Response TimeLow latency, verification runs on your own backendHundreds of ms to seconds (network dependent)
False PositivesConfigurable per risk thresholdBinary verdict; cannot tune independently
Quota LimitsNone10,000 requests/day default; approval required for more
Service OutagesNot applicableOccurred Sept 2023 (multiple hours)
Device CoverageCheap/unlocked devices, custom ROMs, devices not Google-certifiedGoogle-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 (China, EU-sovereign builds) * **Performance**: Real-time verification, not network-dependent {% hint style="success" %} Handle App Security with a Single Solution! Check Out Talsec's Premium Offer & Plan Comparison!
#### Apps Security Threats Report 2025 #### Plans Comparison #### Premium Products: * [RASP+](https://docs.talsec.app/premium-products/product/rasp) - An advanced security SDK that actively shields your app from reverse engineering, tampering, rooting/jailbreaking, and runtime attacks like hooking or debugging. * [AppiCrypt](https://docs.talsec.app/premium-products/product/appicrypt) (Android & iOS) & [AppiCrypt for Web](https://docs.talsec.app/premium-products/product/appicryptweb) - 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](https://docs.talsec.app/premium-products/product/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](https://docs.talsec.app/premium-products/product/app-hardening#about-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](https://docs.talsec.app/premium-products/product/app-hardening#about-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. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.talsec.app/appsec-articles/articles/how-attackers-exploit-play-integrity-api-and-where-appicrypt-fits.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.