[Magisk] pndwal:
Re:

https://www.sstic.org/media/SSTIC20...idguard_a_deep_dive_into_safetynet-thomas.pdf

Official links for this May 2022 whitepaper:

https://www.romainthomas.fr/publication/22-sstic-blackhat-droidguard-safetynet/

This doc. says exactly what we know, w/ some extra (very interesting) detail as far as I can see...

I think you may have misunderstood some of it however...

"the.apk" is installed with Google Apps. It is the "real" Droidguard initial implementation...

GMS (Google Play(/Mobile) Services) hosts a service associated with DroidGuard, .droidguard.DroidGuardService running in its com.google.android.gms.unstable process

John Wu called that gms process the "SafetyNet" process, but this is evidently a loose term. Since the implementation of the Play Integrity API which is also implemented by means of this process, I've been referring to it as the "Attestation" process...

Basically it seems DroidGuard itself is the Attestation engine that communicates with GMS proper via this GMS process's DroidGuard service.

What GMS downloads are updates when an old version of DroidGuard is detected per your doc via this service which also dynamically loads DroidGuard itself.

So DroidGuard itself is a separate system app with an embeded Virtual Machine who's unique bytecode it downloads from Google servers (unique for each attestation request).

DroidGuard runs the bytecode which performs integrity checks, generates a token, binds the token with the attestation’s parameters and sends this to Google’s servers via GMS to generate ctsProfileMatch, basicIntegrity and newer security labels.

So essentially the Droidguard Virtual Machine is what is called by GMS to collect telemetry data, including a certificates chain embedding hardwaresigned information, to be sent to Google Play servers via GMS for generating the attestations calling apps receive.

Of course, while we can force fallbacks to Basic (non hardware based) integrity checks even on devices with supporting hardware that banks etc currently accept, this document reinforces why trying to subvert strongIntegrity verdicts, which themselves preclude basic evaluation types, is/will be futile. For example it states that "Bypassing the ctsProfileMatch flag is another challenge" that would require "finding a boot chain or a low-level vulnerability."

I'd say this too is quite understated:

*

... Praps just a little bit!

In short, I have just a few doubts that you'll ever cover unlocked B/L tracks made using hardware based attestation...

This may have been an oversight, but I believe that the following statements are quite correct:

So it seems checks for root are actually quite extensive, and I remember John commenting with some pride when he first discovered 'magisk' occuring the same Google code driving SafetyNet... (Of course, MagiskHide traditionally added the "attestation" process com.google.android.gms.unstable to hidelist, and now most modders use USNF to hide root from the same process).

FWIW, this reverse engineering undertaking (it took Romain Thomas, a Security Engineer, some five straight weeks of time but was spread over many weekends and early mornings by this dedicated reverser) reveals other very interesting details re. other Device Integrity Checks. I'll append them here as they may prove useful in understanding Google detections methods for modders:

*Continued from Bootloader Verification above:

Interestingly, other reversers have made efforts to understand DroidGuard and its role much earlier.

For example Umang Raghuvanshi comments on his intriguing conversation with Google after discovering their hidden message, incl an email address to contact, embedded in DroidGuard VM code in Jan 2018:

- www.reddit.com/r/androiddev/comments/b9q0rx/comment/ek6h25d/

- www.imgur.io/a/7h0adjB/

Anyway, thanks @Zibri for this insightful document! 🙂 PW