What a device-bound check compares
The server records values when it issues a token and compares them against values on each later request. A mismatch ends the session regardless of how correct the token is. Several different values can play that role, and an app often uses more than one.
- A hardware-backed key signs the request. A key generated in the Android keystore can be marked hardware-backed, and in that case the private key cannot be exported from the device that holds it.
- An attestation verdict describes the device and the app. Play Integrity and vendor equivalents return a signed statement about the app, the device and the account, and the server verifies that signature rather than trusting the client.
- An installation identifier is generated on first run. The app stores it locally and sends it with every request, which ties the token to one install rather than one person.
- Build properties form a fingerprint. Manufacturer, model, and system property values are easy to read and easy to send, so a check built only from them is the simplest to satisfy.
- A key derived from the signing certificate identifies the build. A value computed over the APK signing certificate proves the request came from a genuine copy of the app.
Why copying the values fails
Values that are bound to a device stop being valid when they leave it. A hardware-backed key produces a signature that no other device can produce, so copying the signature from one request is valid only for the message it covered and useless for the next one. An attestation token has a short life and a signature from a key the server already trusts, so it cannot be edited or reused. An installation identifier copied into a script can work until the server also checks the key that signs the request carrying it.
That combination, an identifier plus a signature, is the reason a client that sends the right fields can still be refused. The fields are correct and the proof around them is not.
Options for passing the check
- Reproduce the check in a client you control. If the binding value is derived from data the app can read plus a secret the app contains, the routine can be recovered and run in Python. This works when the proof is a software signature rather than a hardware one.
- Understand what the server actually verifies. An attestation response carries many fields, and a server sometimes checks only part of it. Reproducing the part the server reads is a smaller job than forging the whole statement.
- Keep the request on the device that holds the identity. When the proof cannot leave the hardware, orchestrate the app on a device you control and drive it, so the genuine proof is generated where it is valid.
- Run the app in an environment you manage. A controlled device or emulator with the app installed produces real values, and the client calls into that environment rather than imitating it. Device farm isolation covers the operational side.
Choosing between these follows from one question: is the proof generated by hardware, or by code? Hardware proof limits you to environments that can produce it. Code proof can be recovered and moved. Device-bound API reverse engineering draws that line for a specific app.
Confirm which values the server checks
Test the check rather than assuming its scope. Send the token with one binding value removed and read the response. Send it with a binding value altered and compare the error with the error from an invalid token. Send the same token from a second environment and note whether the server refuses the session or the individual request.
Those results show which values are load-bearing. A field the app sends but the server ignores is a field you do not have to reproduce, and finding that out early saves work.
Keep a record of the responses you collect while testing. An error that names a specific check saves time later, and a server that returns the same generic refusal for every failure tells you the checks run in a fixed order, so the earliest one has to be satisfied before the later ones are even evaluated.
Google Play Integrity reverse engineering describes the equivalent investigation for an attestation-backed check, including which fields a server actually reads.
Related work
Reviewed 28 September 2026 · SReverse research desk