FAQ regarding new SafetyNet changes:
Q1: SafetyNet is passing fine on my device
A1: It seems this new measure is not fully enforced, most likely to prevent false negatives. If your device is old, or somehow key attestation fails in keymaster HAL, SN will simply ignore it
Q1: SafetyNet is passing fine on my device
A1: It seems this new measure is not fully enforced, most likely to prevent false negatives. If your device is old, or somehow key attestation fails in keymaster HAL, SN will simply ignore it
Q2: <insert name> Xposed/Riru module allows me to pass SafetyNet
A2: The SN test in Magisk Manager is technically *not* a proper attestation. Proper SafetyNet checks will verify results on a remote server, not on device which can be manipulated by code injection frameworks
A2: The SN test in Magisk Manager is technically *not* a proper attestation. Proper SafetyNet checks will verify results on a remote server, not on device which can be manipulated by code injection frameworks
Q3: Can't we just create a fake SafetyNet test result?
A3: Nope, SafetyNet responses come from Google servers and are signed with Google's private key, which we do not have access to.
A3: Nope, SafetyNet responses come from Google servers and are signed with Google's private key, which we do not have access to.
Q4: Can't we hack GMS directly?
A4: This is technically what MagiskHide is doing. We create an isolated "safe environment" for the detection process, and it goes through Google's API to create a *legit* SafetyNet result that does not reflect the real status of the device.
(1/2)
A4: This is technically what MagiskHide is doing. We create an isolated "safe environment" for the detection process, and it goes through Google's API to create a *legit* SafetyNet result that does not reflect the real status of the device.
(1/2)
(2/2)
However, this new update utilizes hardware-based key attestation. It will send an unmodified keystore certificate to SafetyNet servers, verify its legitimacy, and check certificate extension data to know whether your device have verified boot enabled (bootloader status)
However, this new update utilizes hardware-based key attestation. It will send an unmodified keystore certificate to SafetyNet servers, verify its legitimacy, and check certificate extension data to know whether your device have verified boot enabled (bootloader status)
Q5: Can we fake a certificate (+ manipulated extension data)?
A5: Nope. Check how trusted execution environment (TEE) works. Unless there is serious implementation bugs in your ARM TrustZone (or security co-processor like Google's Titan M), you cannot break the cryptography.
A5: Nope. Check how trusted execution environment (TEE) works. Unless there is serious implementation bugs in your ARM TrustZone (or security co-processor like Google's Titan M), you cannot break the cryptography.
Q6: Is MagiskHide meaningless now?
A6: It depends on your expectation. MagiskHide is still effective to hide anything in userspace, but is no longer capable of spoofing bootloader/verified boot status.
To put it simply, we can still hide "root", but not the bootloader status.
A6: It depends on your expectation. MagiskHide is still effective to hide anything in userspace, but is no longer capable of spoofing bootloader/verified boot status.
To put it simply, we can still hide "root", but not the bootloader status.
