[Magisk] zgfg:
Yeah, it's not fully random - app requesting validation creates the nonce by it's own BUT Google server does not care what the nonce was - it just copies the nonce back to the verdict (and signs the verdict incl that nonce and the originating timestamp)

Good cryptogrphic practices mean that nonce would be created by eg concatenating the app's packet name (or its activity name) by a random number and then taking the SHA hash, or something similar, to ensure that nonce is both random and unique to the requestor app. Instead of publicly known packet name

Eg.that app may also concatenate a user's id and/or transaction id into the string before taking the SHA, and so on, to additionally ensure that nonce is unique by each request

That way, even if pseudo random number generator is broken, nobody else should be able to create the fake nonces

(More secure - the app should not create the nonce by itself.

It shall ask their compony server to create the nonce, and at the end the app just returns the Google's signed verdict back to the app's server to check there both the timestamp and nonce and the verdict

That way you cannot break the app to accept Failed or fake G verdicts - but those additional protections d not apply to simple checkers like SPIC, PIC, etc)

Btw, test PI in TBChecker, SPIC or PI Checker and look into the verdict JSON and inspect the nonce

And again, read the G publicly available (how else the developers could use the API) PI API documentation

---

Hence adding any prop or whatever to the nonce will not affect Google's verdict

Be aware that this originating app is not Google Droid but PI Checker, SPIC, etc and it's not Google's business how the app's developers created the nonce.

It's just the common cryptographic practice that final response should include also the original timestamp and nonce and all together to be signed by the responder's private key - to avoid faking the response

If an app wants to check props by its own, it could do that but that's out-of--topic for Play Integrity.

Eg, varios banking apps check on their own other things, they don't just ask Google for the PI verdict

---

PS

Be aware that the whole picture includes:

- eg banking server in case of a banking app (the only optional entity, the others below are mandated)

- the app (like banking app, Wallet, TB-Checker, SPIC, etc)

- Google Play Services

- DroidGuard (bytecode that Google can push the updated version anytime they want - that bytecode collects the findings from your phone that will be sent to the G server as the evidence for the verdict)

- G server that creates the final verdict (and also validates in the first place do you have a valid and latest Droid Guard bytecode)

So it's protected from all sides.

And there is no need to add props to the nonce since if G wants to read additional props, they will update the Droid Guard bytecode (and that's not the app's business - the app just requests PI validation as a black box) and the G server side that reads the binary packet that DroidGuard collects, packs and sends

Of course, Google does nowhere publish their internals like what Droid Guard collects, how it structures that into the binary packet (and also signs that!!!), how G server reads that and how their 'jury' delivers the verdict

And even if you don't update the Google Play Services, Google can change their internals on the Droid Guard and on their server side.

Actually, they probably avoid any logic from putting into the Google Play Services (to avoid reverse engineering and to ensure that if users block GMS updates, that it wouldn't t prevent them from hardening the PI attestation. anytime they want. Only, they probably validate that you have the official GApps and the proper version - eg, ancient versions will not support PI, and GMS additionally signs itself to ensure it was really authentic GMS and version)