4 votos

SafetyNet vs MagiskHide: ¿cuál es el estado actual a mediados de 2020?

Como se informó ampliamente en diferentes sitios, y también se discutió en este sitio (aquí y aquí), a principios de este año, Google hizo cambios en SafetyNet para que pudiera detectar el estado del bootloader/verificado incluso con MagiskHide activado. El desarrollador de Magisk, John Wu, en ese momento tuiteó que debido a que Google estaba usando el Entorno de Ejecución de Confianza (TEE), su chequeo sobre el estado del bootloader no podía ser derrotado. Por ejemplo, él escribió:

esta nueva actualización utiliza la atestación de clave basada en hardware. Enviará un certificado de almacén de claves no modificado a los servidores de SafetyNet, verificará su legitimidad y comprobará los datos de la extensión del certificado para saber si su dispositivo tiene habilitado el arranque verificado (estado del bootloader)

A menos que haya errores de implementación graves en su ARM TrustZone (o coprocesador de seguridad como Titan M de Google), no podrá romper la criptografía.

Básicamente concluyó:

Aceptémoslo. Se acabó la diversión, chicos.

Sin embargo, el 14 de marzo, John Wu tuiteó:

¿Así que aparentemente CTS está pasando de nuevo de la nada? ¿Quizás Google sigue probando cosas?

De todos modos ya no me importa. Google aparentemente está dispuesto a usar la atestación de clave para la detección. Dado que MagiskHide aún está ahí, la gente todavía puede usarlo como siempre.

Y otro tuit de él el 3 de abril que no entendí del todo:

¡EL GRAN MARTILLO DE GOOGLE HA VUELTO! Di adiós a SafetyNet, (no) te extrañaremos...

¿Eso significa que Google de alguna manera eliminaría SafetyNet, o al menos no utilizaría sus capacidades para detectar el estado del bootloader?

Entonces, surgieron algunas dudas a mediados de marzo. En mi propia prueba a finales de mayo de 2020, con MagiskHide desactivado, SafetyNet falló, pero con MagiskHide activado y apuntando a mi aplicación de prueba, SafetyNet pasó, lo que significa que MagiskHide aún podía derrotar a SafetyNet. La prueba se realizó en un Pixel 3 con Android 10.

Entonces, Google puede tener la capacidad de detectar MagiskHide, y estaba funcionando en el campo con dispositivos reales, pero de alguna manera han dejado de hacerlo? ¿Alguien sabe qué está pasando con SafetyNet? ¿Se revirtió temporalmente la función? ¿Volverá a SafetyNet, y si es así, cuándo?

1 votos

Es subjetivo (relacionado con dispositivo y sistema operativo), nada se puede decir con certeza. Consulta varios foros en XDA y tu respuesta dependerá de lo que leas.

0 votos

Hmm, ¿Me pregunto si hay alguna indicación sobre lo que está pensando Google? ¿O simplemente son personas especulando sobre lo que está haciendo Google?

0 votos

Es todo especulación - nadie sabe

3voto

auspicious99 Puntos 201

(29 de junio de 2020) Parece que Google simplemente está siendo cauteloso y preparando un nuevo campo en la respuesta de SafetyNet.

Según el equipo de clientes de la API de SafetyNet

Hemos comenzado a implementar una nueva función que proporcionará a los desarrolladores información sobre los tipos de señales/mediciones que han contribuido a cada respuesta individual de la API de Attestation de SafetyNet.

Nuestras respuestas JWS ahora tienen un nuevo campo opcional llamado evaluationType. El valor de este campo será una lista de tokens de cadena separados por comas, donde cada token representa un valor similar a un enum.

Actualmente, los siguientes tokens de cadena pueden indicarse:

  • BASIC: Cuando utilizamos señales y mediciones típicas junto con datos de referencia durante nuestra evaluación.
  • HARDWARE_BACKED: Cuando utilizamos las características de seguridad respaldadas por hardware disponibles del dispositivo remoto (por ej. atestación de clave respaldada por hardware) para influir en nuestra evaluación.

Ejemplos de valores de campos que puede esperar:

  • {“evaluationType”: “BASIC”}
  • {“evaluationType”: “BASIC,HARDWARE_BACKED”}

Actualmente estamos evaluando y ajustando los criterios de elegibilidad para dispositivos en los que confiaremos en características de seguridad respaldadas por hardware. Por lo tanto, por ahora, no utilice la presencia o el valor de este campo como una señal por sí solo.

Hay que tener en cuenta que esta función aún no ha sido documentada oficialmente. Actualmente, solo estamos comunicándola a esta lista de anuncios para recopilar comentarios.

Le animamos a utilizar nuestro formulario de comentarios en función de su experiencia con esta nueva función y con el servicio en general.

Gracias y saludos, Equipo de clientes de la API de SafetyNet

Así que una vez que se complete la prueba de esta nueva función, parece que la atestación de clave respaldada por hardware se instalará. Lo que significa que, a partir de entonces, SafetyNet sería capaz de detectar el estado de arranque/verificación de arranque incluso con MagiskHide habilitado.

John Wu sigue luchando

(actualizado el 29 de junio de 2020)

John Wu está tratando de persuadir a Google para que no aplique ciegamente la atestación respaldada por hardware de SafetyNet en todos los casos. Él tuiteó:

Abogo por que @AndroidDev restrinja la evaluación de SafetyNet respaldada por hardware a aplicaciones de seguridad "reales". Los desarrolladores deberían pasar por un proceso de solicitud para calificar para este nivel de acceso a la API. Es ridículo que McDonald's se niegue a funcionar en un dispositivo con bootloader desbloqueado.

Mientras tanto, parece que las comprobaciones de SafetyNet seguirán fallando incluso si el bootloader vuelve a bloquearse, como vemos aquí, tuiteado el 3 de julio de 2020

Mala noticia: está confirmado que para aquellos que desean volver a bloquear su bootloader con imágenes auto-firmadas (posible en dispositivos Pixel), SafetyNet con la evaluación HARDWARE-BACKED todavía NO pasará la verificación de CTS.

(Actualizado el 13 de diciembre de 2020) John Wu ahora tuitea

Permítanme aclarar esto: dado que ahora tengo un trabajo de tiempo completo, no tengo mucho tiempo para Magisk; necesito priorizar. La evaluación basada en hardware es impracticable de "hackear" (excepto trucos para hacerla retroceder a básica), y he perdido todo interés en mejorar la forma actual de ocultar.

1 votos

@beeshyams Gracias, ya había publicado esta URL groups.google.com/forum/#!topic/safetynet-api-clients/… hoy mismo, por lo que está claro lo que está sucediendo.

0 votos

@beeshyams De todas formas, es bueno saberlo; por lo que es probable que más aplicaciones utilicen SafetyNet en el futuro. ¿Crees que habrá alternativas "mejores" para hacer root en ese caso?

0 votos

Siento que es para mejor. Haz una elección: quieres aplicaciones de root o seguras. No puedes tener ambos //Mejores alternativas son posibles, tuvimos muchas antes de Su, aplicaciones de root kit y ahora Magisk. Una vez que John Wu deje de desarrollar, uno puede encontrar nuevos métodos. Siento que Magisk es el mejor que hemos tenido y probablemente lo sea por un tiempo. Para mí, pospondré la actualización a 11 hasta que la situación esté clara (no necesito ningún SafetyNet) pero usaré aplicaciones bancarias que no permiten root. Si el root se puede ocultar como dice John, estoy bien :)

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X