John Wu (Desarrollador de Magisk) publicó actualizaciones de hoy que aclara los motivos.

Anteriormente, la API de SafetyNet no estaba implementada de forma completa/correcta, tal y como debía ser:

• Certificación de llaves

Por lo que hemos visto hasta ahora, la certificación clave no parece que se aplique del todo aún, ya que los dispositivos con implementaciones de keymaster incompatibles y potencialmente defectuosas (por ejemplo, algunos dispositivos OnePlus) que dan lugar a fallos de attest key cmd siguen pasando SafetyNet a pesar de todo.

• El certificado fue hecho localmente

El gestor de arranque informa del estado del dispositivo a través de los cmdlines del kernel, y el init los reflejará en las propiedades, y aparentemente SafetyNet estaba usando esos valores. Todas esas cosas están en el espacio de usuario, así que Magisk puede simplemente manipularlo

Ahora, con la Vista previa de la función: Evaluación de la API de atestación de SafetyNetType En este caso, habrá dos tipos de evaluación, BASIC y HARDWARE_BACKED para una evaluación completa con validación remota (frente a la local) :

HARDWARE_BACKED - Cuando utilizamos las características de seguridad disponibles respaldadas por hardware del dispositivo remoto (por ejemplo, la atestación de claves respaldada por hardware) para influir en nuestra evaluación.

Actualmente estamos evaluando y ajustando los criterios de elegibilidad de los dispositivos en los que confiaremos en las características de seguridad respaldadas por el hardware.

¿Se puede piratear este nuevo sistema?

Parece muy poco probable

• Incluso si forzamos la validación para usar BASIC método, no se ocultará

OMI es teóricamente posible alterar el flujo de control en el código de SafetyNet para forzarlo a utilizar siempre la evaluación BASIC utilizando algún marco de enganche como Xposed, sin embargo este tipo de inyección de código es básicamente imposible de ocultar (análisis del espacio de memoria).

• HARDWARE_BACKED es algo serio y es poco probable que se rompa ya que implica TEE o cambios en el hardware que lleven a un compromiso criptográfico (Robert también señaló en los comentarios )

Para hackear esta cosa, tienes que encontrar un vulnerabilidad en el firmware de TEE (que será parcheado lo antes posible una vez encontrado) o hardware (menos probable) para romper la criptografía.

Romper el TEE no será fácil, por lo que muchos investigadores de seguridad están trabajando activamente en ello.

(Énfasis añadido en todas las citas)

¿Cómo comprobar si Google ha implementado la certificación de hardware para mi dispositivo?

Editar El canario de Magisk se ha actualizado para mostrar el estado de la evaluación y, una vez que se implemente la API, se verán más detalles (a falta de SafetyNet). O bien, siga las instrucciones en este post de XDA para comprobar el método de atestación mediante logcat

Para más información, consulte La atestación de hardware de SafetyNet hará que ocultar Root en Magisk sea realmente difícil

Editado el 16 de diciembre de 20

Y el último clavo en el ataúd para engañar a la detección de la red de seguridad

Johnwu en

• tuitea dice

La evaluación basada en HW es impracticable de "hackear" (salvo trucos para hacerla retroceder al básico), y perdí todo interés en mejorar la forma actual de ocultar.

• Otro tuitea del 13 de diciembre de 2020

Si pasar SafetyNet es el único uso de Magisk para ti, entonces sí, adiós Face con los ojos en blanco ( en respuesta a Entonces... ¿el magisco es completamente inútil ahora mismo? )