Add content from: Research Update Enhanced src/mobile-pentesting/android-app-p...

Author: HackTricks News Bot

src/mobile-pentesting/android-app-pentesting/play-integrity-attestation-bypass.md

@@ -9,11 +9,13 @@
 - **`appIntegrity`**: APK build/signature match (no repack/tamper).
 - **`deviceIntegrity`**: genuine & certified device, locked bootloader, no root/system tamper.
 - **`accountDetails`**: installation via Google Play.
+- **`environmentDetails`** *(optional)*: recent integrations can also request signals about risky apps in the environment (overlay, capture, control) and Play Protect state.
+- **Other optional signals**: some backends also enable **recent device activity** or **device recall** to catch hyperactive devices and previously flagged hardware even when a verdict otherwise looks valid.
 
 Key verdict flags commonly enforced:
 - `MEETS_BASIC_INTEGRITY`: token generated by genuine Play Services (not emulator/tampered transport).
 - `MEETS_DEVICE_INTEGRITY`: genuine/certified device, bootloader locked, no root/system tamper.
-- `MEETS_STRONG_INTEGRITY`: requires `DEVICE` plus **recent security patches on all partitions (OS + vendor)**.
+- `MEETS_STRONG_INTEGRITY`: on **Android 13+** it requires `DEVICE` plus **recent security patches on all partitions (OS + vendor)**. On **Android 12 and lower**, it mainly means hardware-backed boot integrity, so it is a weaker signal than many testers assume.
 
 ## Bypass Model
 
@@ -26,8 +28,9 @@ Google mitigates by **revoking abused keyboxes**; rotation is required when a ke
 
 ## Prerequisites & Tooling
 
-- **Root hiding:** [ReZygisk](https://github.com/PerformanC/ReZygisk) (or ZygiskNext). Disable Zygisk, enable Magisk Hide, install module, reboot.
+- **Root hiding:** [ReZygisk](https://github.com/PerformanC/ReZygisk) (or ZygiskNext). Disable Zygisk, enable Magisk Hide, install module, reboot. If the target also detects Zygote injection or Frida side effects, cross-check [Android anti-instrumentation and SSL pinning bypass](android-anti-instrumentation-and-ssl-pinning-bypass.md).
 - **Key attestation spoofing:** [TrickyStore](https://github.com/5ec1cff/TrickyStore) + [Tricky Addon](https://github.com/KOWX712/Tricky-Addon-Update-Target-List) (Magisk modules).
+- **Property / fingerprint spoofing:** [PlayIntegrityFork](https://github.com/osm0sis/PlayIntegrityFork). It mainly spoofs props only for the Google Play Services **DroidGuard** path. This mainly helps with **Android `<13`** or apps that still gate on legacy/softer checks; on **Android 13+** a passing `DEVICE` verdict still depends on locked-bootloader, hardware-backed signals.
 - **UI helper:** [KSU Web UI](https://github.com/adivenxnataly/KsuWebUI) to drive TrickyStore.
 - **Validation:** [Play Integrity API Checker](https://play.google.com/store/apps/details?id=gr.nikolasspyr.integritycheck) and [Key Attestation](https://github.com/vvb2060/KeyAttestation) APKs.
 - Optional background on attestation key material: <https://tryigit.dev/android-keybox-attestation-analysis>
@@ -46,10 +49,37 @@ Google mitigates by **revoking abused keyboxes**; rotation is required when a ke
 1. In TrickyStore, pick **Set Security Patch** → **Get Security Patch Date** → **Save**.
 2. Re-run *Play Integrity API Checker*; `MEETS_STRONG_INTEGRITY` should now pass.
 
+## Practical Tester Angles Against Weak Integrations
+
+Even when you cannot permanently recover `DEVICE`/`STRONG`, many app backends still misuse the API. During testing, look for:
+
+- **Missing action binding:** `standard` requests should bind the protected action to `requestHash`; `classic` requests should bind it to a high-entropy `nonce`. `standard` requests have Google-managed replay mitigation, but the backend still needs to validate `requestHash` (and the request timestamp) against the protected action. `classic` integrations are especially replay-prone if the server accepts any valid token without matching the original `nonce`.
+- **Weak freshness checks:** verify whether the backend enforces `timestampMillis` and rejects old tokens. Long replay windows are common in rushed integrations.
+- **Over-trusting package metadata:** Google documents that `requestPackageName` can be spoofed in the middle of the request, so it should not be the only app-identity check.
+- **Legacy policy assumptions:** some apps still treat `MEETS_STRONG_INTEGRITY` as equivalent across Android versions. On pre-13 devices that can lead to weaker trust decisions than the product team expects.
+
+## Emerging Technique: Remote Key Attestation (RKA)
+
+A newer evolution is to **relay the attestation request to another Android device** instead of copying `keybox.xml` onto every client device. The usual flow is:
+
+1. Intercept the local Key Attestation / Play Integrity request before it reaches the TEE/KeyStore path.
+2. Forward the nonce / app identity / request details to a remote rooted host.
+3. Let that host generate the attestation response using either an unrevoked legacy keybox or a genuinely vulnerable device whose boot chain still reports a locked state.
+4. Return the attestation blob to the client app/backend.
+
+Why it matters for testers:
+
+- it avoids burning a public `keybox.xml` on every device used during an assessment;
+- it makes simple certificate-serial revocation less effective against the operator;
+- it shifts the problem from **keybox distribution** to **relay infrastructure + host-device compromise**.
+
+This is where the ecosystem is moving: **Remote Key Provisioning (RKP)** reduces the long-term value of leaked static keyboxes, but it does **not** fully remove relay-style attacks when the attacker controls a privileged or exploited host device.
+
 ## Operational Notes
 
 - **Revocation risk:** Hitting the API repeatedly with the same `keybox.xml` can flag and block it. If blocked, replace with a fresh valid keybox.
-- **Arms race:** Publicly shared keyboxes burn fast; keep private copies and track community module updates (XDA/Telegram/GitHub) for new working chains.
+- **Arms race:** Publicly shared keyboxes burn fast; keep private copies and track community module updates (XDA/Telegram/GitHub) for new working chains. Newer RKA-style setups reduce direct keybox exposure but increase operational complexity.
+- **Optional environment / abuse signals:** Some newer apps also evaluate `environmentDetails` (for example risky overlay/capture/control apps), `recentDeviceActivity`, or `deviceRecall`. In those cases, passing `DEVICE`/`STRONG` alone is not enough if your testing stack leaves visible overlay, accessibility, screen-capture artifacts, or generates obviously abnormal token volume.
 - **Scope:** This bypass only spoofs attestation inputs; backend signature verification by Google still succeeds because the JWT itself is genuine.
 
 ## References
@@ -62,5 +92,7 @@ Google mitigates by **revoking abused keyboxes**; rotation is required when a ke
 - [Play Integrity API Checker](https://play.google.com/store/apps/details?id=gr.nikolasspyr.integritycheck)
 - [Key Attestation](https://github.com/vvb2060/KeyAttestation)
 - [Android keybox attestation analysis](https://tryigit.dev/android-keybox-attestation-analysis)
+- [Integrity verdicts | Android Developers](https://developer.android.com/google/play/integrity/verdicts)
+- [Bypassing the Key Attestation API with Remote Devices](https://www.guardsquare.com/blog/bypassing-key-attestation-api)
 
 {{#include ../../banners/hacktricks-training.md}}