pipiolo77
Registrado
- Mensajes
- 335
- Puntos
- 688
Elegir ser ROOT o pagar con el movil
La temida certificación de hardware de SafetyNet se está implementando...lo que hace mucho más difícil para Magisk ocultar la raíz
En marzo, algunos usuarios con Magisk instalado notaron que sus dispositivos estaban fallando SafetyNetatestación. Esta noticia fue preocupante para la comunidad de XDA porque significa que muchas aplicaciones bancarias / financieras cruciales y juegos populares como Pokémon Go y Fate / Grand Order se negaron a ejecutarse en dispositivos rooteados. Durante algún tiempo, pareció que las restricciones más estrictas en SafetyNet se retiraron, solo para implementarse nuevamente para un puñado de usuarios en las últimas semanas. Sin embargo, Google confirmó silenciosamente a principios de mayo que estaban probando la certificación respaldada por hardware para las respuestas de SafetyNet, que es lo que hizo que Magisk no pudiera ocultar el estado de desbloqueo del cargador de arranque en marzo. Si este cambio se implementa ampliamente, significará que los usuarios tendrán que elegir entre tener acceso a ROM / kernels / etc raíz / personalizados. o sus aplicaciones y juegos bancarios preferidos. Uno de los mayores atractivos de Android para usuarios avanzados podría desaparecer pronto.
Para recapitular esta serie de eventos, primero deberíamos hablar sobre SafetyNet. SafetyNet es un conjunto de API en los servicios de Google Play. La API de certificación de SafetyNet es una de esas API, y puede ser invocada por aplicaciones de terceros para verificar si el entorno de software del dispositivo ha sido alterado de alguna manera. La API busca varias cosas como signos de binarios de superusuario, el estado de desbloqueo del cargador de arranque y más. Cuando rootea un dispositivo con Magisk, “[crea] un 'entorno seguro' aislado para el proceso de detección [SafetyNet], y pasa por la API de Google para crear un resultado legítimo de SafetyNet que no refleja el estado real del dispositivo, " Según el desarrollador reconocido superior de XDA topjohnwu. Esto permite al usuario rootear su teléfono mientras se asegura de que la API siempre devuelva "falso" para cualquier comprobación de desbloqueo del cargador de arranque. Este método de evitar la detección de desbloqueo del cargador de arranque de SafetyNet ha funcionado para Magisk durante los últimos años, pero eso es solo porque Google ha retrasado la verificación de la integridad de la imagen de arranque mediante la certificación de hardware. En marzo, parecía que Google finalmente estaba comenzando a emplear la certificación de hardware en SafetyNet para verificar la imagen de arranque, pero nunca recibimos una declaración oficial de Google que confirmara el cambio y solo unos pocos usuarios se vieron afectados. Sin embargo, como lo descubrió el miembro de XDA Senior Displax , Google confirmó el 5 de mayo de 2020 que las respuestas de la API de certificación SafetyNet de algunos dispositivos ahora incluyen comprobaciones respaldadas por hardware.
En el Grupo de Google para "Clientes API SafetyNet", Google detalló una nueva función para la API de certificación: tipo de evaluación. La respuesta de la firma web JSON (JWS) de algunos dispositivos tendrá un campo llamado "tipo de evaluación" que "proporcionará a los desarrolladores una idea de los tipos de señales / medidas que han contribuido a cada respuesta de API de certificación SafetyNet". Uno de los tokens compatibles en este campo es "HARDWARE_BACKED", que indica que la API "[utilizó] las funciones de seguridad respaldadas por hardware disponibles del dispositivo remoto (por ejemplo , certificación de clave respaldada por hardware) para influir en [su] evaluación ". Google dice que "están evaluando y ajustando los criterios de elegibilidad para dispositivos en los que confiaremos en las características de seguridad respaldadas por hardware". Lo que esto significa es que, en algunos dispositivos, los Servicios de Google Play ahora están utilizando una certificación respaldada por hardware para detectar que el software del dispositivo no ha sido alterado. Google no ha documentado oficialmente este cambio fuera del anuncio en el Grupo de Google, por lo que algunos desarrolladores que usan SafetyNet pueden no ser conscientes de este cambio (y, por lo tanto, aún no están buscando el campo "HARDWARE_BACKED" en las respuestas de JWS). para aquellas aplicaciones que están buscando este campo, ahora no hay forma de ocultarles el acceso a la raíz, siempre que su dispositivo sea parte de la prueba que Google está ejecutando.
Respuesta de SafetyNet Attestation API con el tipo de evaluación que devuelve "BASIC". Créditos: XDA Senior Member Displax
Respuesta de SafetyNet atestación API con el tipo de evaluación que devuelve "BASIC" y "HARDWARE_BACKED". Créditos: XDA Senior Member Displax
Según topjohnwu, la certificación respaldada por hardware significa que Google Play Services ahora "[envía] un certificado de almacén de claves no modificado a los servidores de SafetyNet, [verifica] su legitimidad y [verifica] los datos de extensión del certificado para saber si su dispositivo [ha] verificado el arranque habilitado (estado del gestor de arranque) ". Dado que las claves privadas de las que se derivan los certificados del almacén de claves están respaldadas por el entorno seguro aislado del teléfono, recuperarlas implicaría derrotar la seguridad del Entorno de ejecución de confianza (TEE) o el módulo de seguridad de hardware dedicado (HSM). Si de alguna manera se pudiera filtrar una clave privada, las claves se revocarían rápidamenteuna vez que Google se enteró. Google ofrece cientos de miles de dólares en recompensas por cualquier vulnerabilidad de seguridad crítica que afecte el TEE en los teléfonos Pixel, lo que demuestra que es increíblemente improbable que esto sea una vía potencial para evitar la detección de desbloqueo del cargador de arranque de todos modos.
Otra forma potencial en que Magisk podría seguir falsificando el estado de desbloqueo del cargador de arranque es modificando el código del lado del cliente de SafetyNet para usar siempre la evaluación BÁSICA. Sin embargo, como señala topjohnwu , esto requeriría inyectar código personalizado en los Servicios de Google Play a través de un marco de enganche como el Marco Xposed. Esto no solo es difícil de hacer porque los servicios de Google Play están muy ofuscados, sino que también es imposible de ocultar, ya que "algunos análisis del espacio de la memoria revelarán la manipulación del código muy fácilmente". Además, esto solo funcionaría si los servidores de Google continúan aceptando evaluaciones BÁSICAS y si las evaluaciones HARDWARE_BACKED no se aplican en dispositivos que las admiten. (Las respuestas de SafetyNet "[provienen] de los servidores de Google y están firmadas con la clave privada de Google", según topjohnwu, por lo que las respuestas reales no pueden ser falsificadas).
Desde Android 7 Nougat, Google ha requerido que todos los dispositivos tengan un entorno seguro aislado, lo que significa que este cambio en la forma en que SafetyNet verifica el desbloqueo del cargador de arranque afectará a la mayoría de los dispositivos que existen. Dado que los dispositivos más antiguos sin un entorno seguro aislado obviamente no pueden realizar una certificación respaldada por hardware, Magisk aún podrá ocultar el acceso de root en esos dispositivos. Pero si este cambio se implementa ampliamente, todos los demás tendrán que tomar una decisión difícil entre el acceso raíz y las aplicaciones bancarias.
Desafortunadamente, es probable que haya muchas aplicaciones que usan las comprobaciones de SafetyNet cuando en realidad no lo necesitan. Un ejemplo citado por topjohnwu es la aplicación oficial de McDonald's, que aparentemente se niega a ejecutarse en un dispositivo desbloqueado del cargador de arranque. En Twitter, topjohnwu llama a las aplicaciones que usan en exceso la API como la creación de un entorno hostil para usuarios avanzados. El desarrollador reconocido por XDA Quinny899 se une con una anécdota sobre cómo su equipo consideró usar SafetyNet para verificar el estado de seguridad del dispositivo. Finalmente, decidieron no hacerlo, ya que la aplicación de su equipo cifra todos los datos confidenciales con los que trabaja. SafetyNet, argumenta, no debe usarse en lugar de prácticas adecuadas de seguridad y manejo de datos, especialmente cuando se considera la posibilidad de explotaciones de superusuario .
Fuente XDA
Saludos
La temida certificación de hardware de SafetyNet se está implementando...lo que hace mucho más difícil para Magisk ocultar la raíz
En marzo, algunos usuarios con Magisk instalado notaron que sus dispositivos estaban fallando SafetyNetatestación. Esta noticia fue preocupante para la comunidad de XDA porque significa que muchas aplicaciones bancarias / financieras cruciales y juegos populares como Pokémon Go y Fate / Grand Order se negaron a ejecutarse en dispositivos rooteados. Durante algún tiempo, pareció que las restricciones más estrictas en SafetyNet se retiraron, solo para implementarse nuevamente para un puñado de usuarios en las últimas semanas. Sin embargo, Google confirmó silenciosamente a principios de mayo que estaban probando la certificación respaldada por hardware para las respuestas de SafetyNet, que es lo que hizo que Magisk no pudiera ocultar el estado de desbloqueo del cargador de arranque en marzo. Si este cambio se implementa ampliamente, significará que los usuarios tendrán que elegir entre tener acceso a ROM / kernels / etc raíz / personalizados. o sus aplicaciones y juegos bancarios preferidos. Uno de los mayores atractivos de Android para usuarios avanzados podría desaparecer pronto.
Para recapitular esta serie de eventos, primero deberíamos hablar sobre SafetyNet. SafetyNet es un conjunto de API en los servicios de Google Play. La API de certificación de SafetyNet es una de esas API, y puede ser invocada por aplicaciones de terceros para verificar si el entorno de software del dispositivo ha sido alterado de alguna manera. La API busca varias cosas como signos de binarios de superusuario, el estado de desbloqueo del cargador de arranque y más. Cuando rootea un dispositivo con Magisk, “[crea] un 'entorno seguro' aislado para el proceso de detección [SafetyNet], y pasa por la API de Google para crear un resultado legítimo de SafetyNet que no refleja el estado real del dispositivo, " Según el desarrollador reconocido superior de XDA topjohnwu. Esto permite al usuario rootear su teléfono mientras se asegura de que la API siempre devuelva "falso" para cualquier comprobación de desbloqueo del cargador de arranque. Este método de evitar la detección de desbloqueo del cargador de arranque de SafetyNet ha funcionado para Magisk durante los últimos años, pero eso es solo porque Google ha retrasado la verificación de la integridad de la imagen de arranque mediante la certificación de hardware. En marzo, parecía que Google finalmente estaba comenzando a emplear la certificación de hardware en SafetyNet para verificar la imagen de arranque, pero nunca recibimos una declaración oficial de Google que confirmara el cambio y solo unos pocos usuarios se vieron afectados. Sin embargo, como lo descubrió el miembro de XDA Senior Displax , Google confirmó el 5 de mayo de 2020 que las respuestas de la API de certificación SafetyNet de algunos dispositivos ahora incluyen comprobaciones respaldadas por hardware.
En el Grupo de Google para "Clientes API SafetyNet", Google detalló una nueva función para la API de certificación: tipo de evaluación. La respuesta de la firma web JSON (JWS) de algunos dispositivos tendrá un campo llamado "tipo de evaluación" que "proporcionará a los desarrolladores una idea de los tipos de señales / medidas que han contribuido a cada respuesta de API de certificación SafetyNet". Uno de los tokens compatibles en este campo es "HARDWARE_BACKED", que indica que la API "[utilizó] las funciones de seguridad respaldadas por hardware disponibles del dispositivo remoto (por ejemplo , certificación de clave respaldada por hardware) para influir en [su] evaluación ". Google dice que "están evaluando y ajustando los criterios de elegibilidad para dispositivos en los que confiaremos en las características de seguridad respaldadas por hardware". Lo que esto significa es que, en algunos dispositivos, los Servicios de Google Play ahora están utilizando una certificación respaldada por hardware para detectar que el software del dispositivo no ha sido alterado. Google no ha documentado oficialmente este cambio fuera del anuncio en el Grupo de Google, por lo que algunos desarrolladores que usan SafetyNet pueden no ser conscientes de este cambio (y, por lo tanto, aún no están buscando el campo "HARDWARE_BACKED" en las respuestas de JWS). para aquellas aplicaciones que están buscando este campo, ahora no hay forma de ocultarles el acceso a la raíz, siempre que su dispositivo sea parte de la prueba que Google está ejecutando.
Respuesta de SafetyNet Attestation API con el tipo de evaluación que devuelve "BASIC". Créditos: XDA Senior Member Displax
Respuesta de SafetyNet atestación API con el tipo de evaluación que devuelve "BASIC" y "HARDWARE_BACKED". Créditos: XDA Senior Member Displax
Según topjohnwu, la certificación respaldada por hardware significa que Google Play Services ahora "[envía] un certificado de almacén de claves no modificado a los servidores de SafetyNet, [verifica] su legitimidad y [verifica] los datos de extensión del certificado para saber si su dispositivo [ha] verificado el arranque habilitado (estado del gestor de arranque) ". Dado que las claves privadas de las que se derivan los certificados del almacén de claves están respaldadas por el entorno seguro aislado del teléfono, recuperarlas implicaría derrotar la seguridad del Entorno de ejecución de confianza (TEE) o el módulo de seguridad de hardware dedicado (HSM). Si de alguna manera se pudiera filtrar una clave privada, las claves se revocarían rápidamenteuna vez que Google se enteró. Google ofrece cientos de miles de dólares en recompensas por cualquier vulnerabilidad de seguridad crítica que afecte el TEE en los teléfonos Pixel, lo que demuestra que es increíblemente improbable que esto sea una vía potencial para evitar la detección de desbloqueo del cargador de arranque de todos modos.
Otra forma potencial en que Magisk podría seguir falsificando el estado de desbloqueo del cargador de arranque es modificando el código del lado del cliente de SafetyNet para usar siempre la evaluación BÁSICA. Sin embargo, como señala topjohnwu , esto requeriría inyectar código personalizado en los Servicios de Google Play a través de un marco de enganche como el Marco Xposed. Esto no solo es difícil de hacer porque los servicios de Google Play están muy ofuscados, sino que también es imposible de ocultar, ya que "algunos análisis del espacio de la memoria revelarán la manipulación del código muy fácilmente". Además, esto solo funcionaría si los servidores de Google continúan aceptando evaluaciones BÁSICAS y si las evaluaciones HARDWARE_BACKED no se aplican en dispositivos que las admiten. (Las respuestas de SafetyNet "[provienen] de los servidores de Google y están firmadas con la clave privada de Google", según topjohnwu, por lo que las respuestas reales no pueden ser falsificadas).
Desde Android 7 Nougat, Google ha requerido que todos los dispositivos tengan un entorno seguro aislado, lo que significa que este cambio en la forma en que SafetyNet verifica el desbloqueo del cargador de arranque afectará a la mayoría de los dispositivos que existen. Dado que los dispositivos más antiguos sin un entorno seguro aislado obviamente no pueden realizar una certificación respaldada por hardware, Magisk aún podrá ocultar el acceso de root en esos dispositivos. Pero si este cambio se implementa ampliamente, todos los demás tendrán que tomar una decisión difícil entre el acceso raíz y las aplicaciones bancarias.
Desafortunadamente, es probable que haya muchas aplicaciones que usan las comprobaciones de SafetyNet cuando en realidad no lo necesitan. Un ejemplo citado por topjohnwu es la aplicación oficial de McDonald's, que aparentemente se niega a ejecutarse en un dispositivo desbloqueado del cargador de arranque. En Twitter, topjohnwu llama a las aplicaciones que usan en exceso la API como la creación de un entorno hostil para usuarios avanzados. El desarrollador reconocido por XDA Quinny899 se une con una anécdota sobre cómo su equipo consideró usar SafetyNet para verificar el estado de seguridad del dispositivo. Finalmente, decidieron no hacerlo, ya que la aplicación de su equipo cifra todos los datos confidenciales con los que trabaja. SafetyNet, argumenta, no debe usarse en lugar de prácticas adecuadas de seguridad y manejo de datos, especialmente cuando se considera la posibilidad de explotaciones de superusuario .
Fuente XDA
Saludos
Última edición por un moderador:
Foro Xiaomi
Foro Realme
Foro OnePlus
Foro Jiayu
Foro Lenovo
Foro Samsung
Foro Nubia
Foro Blackview
Foro impresoras 3D