Una mirada a las complicaciones de la raíz del malvavisco y de la verdad

A medida que el polvo se deposita en el Lanzamiento de Android 6.0, muchos usuarios de Nexus están buscando OTA y Imágenes de fábricay preparándose para la última versión del sistema operativo Android.

Si bien, desde fuera, Android 6.0 parece (al menos visualmente) notablemente similar a Android 5.0 y 5.1 (las versiones Lollipop), hay una serie de cambios significativos en el adentro. Uno de ellos potencialmente tiene ramificaciones para la ROM personalizada y las comunidades raíz. Primero, un poco de historia. Si no está interesado en esto, salte a "¿Por qué es importante?".

Una característica llamada verdad

El problema (es un problema si te gusta rootear y modificar dispositivos) surge de algo que señalé hace mucho tiempo, cuando llegó por primera vez a AOSP: la introducción de dm-verity a Android. Verity es una característica de seguridad, que se encontraba originalmente en ChromeOS, diseñada para proporcionar dispositivos informáticos seguros y confiables, evitando que software malicioso modifique un dispositivo. En Android 4.4, Google anunció la verdad para Android y luego todo permaneció en silencio. Si bien ha habido algunos

investigación sobre el uso de la verdad, en su mayor parte, las cosas han estado tranquilas. Hasta ahora, eso es.

Con Android 6.0, Google ha comenzado a mejorar su juego en materia de seguridad de dispositivos. Uno de los requisitos fundamentales para ello es evitar que el software de un dispositivo se modifique sin el conocimiento del usuario, mientras que aquí muchos en XDA dan por sentado el acceso root, imagina que el dispositivo de un usuario es rooteado sin su conocimiento o consentimiento, y que se utiliza el acceso root para robar su datos. Por este motivo, Google ha comenzado a implementar la verificación de la partición del sistema en algunos dispositivos. También actualizaron recientemente su paginas de soporte para cubrir esto.

¿Qué significa esto para los usuarios rooteados?

Con la verdad en su lugar, cualquier cambio realizado en la partición del sistema se detectará al iniciar o acceder. Luego se enfrentará a uno de los errores como se ve arriba. Algunos le permiten continuar y otros quieren protegerlo impidiendo que el dispositivo se inicie. Hay tres estados disponibles. Uno se muestra cuando el gestor de arranque está desbloqueado, lo que indica que puede estar en riesgo hasta que vuelva a bloquear el gestor de arranque. Este es el caso porque una imagen del kernel modificada puede pasar por alto la verdad, ya que el disco RAM del kernel contiene las claves utilizadas para verificar el estado de un sistema.

Las cosas parecen poco divertidas para los usuarios aspirantes a root en dispositivos bloqueados.

El siguiente estado se muestra (presumiblemente) cuando Verity está deshabilitado o apagado, o no se puede verificar debido a modificaciones en el disco RAM. No puedo estar seguro, debido a que no tengo un Nexus 5X o 6P para investigar, pero mi sospecha (basada en los mensajes) es que si carga otra ROM, que luego coloca su propio núcleo en el dispositivo, aparecerá la página "sistema operativo diferente". aparecer.

El estado final es la advertencia roja que indica que el dispositivo está dañado. Sospecho que esto significa que la imagen contiene verdad, pero la verificación falló debido a que se modificó la imagen del sistema. Nuevamente, no podemos estar seguros sin el hardware disponible, pero ese error parece ser el que verá si un dispositivo original fue modificado por un software malicioso.

¿Porque es esto importante?

En Android M (6.0), root actualmente requiere que se realicen modificaciones en la imagen del kernel, además del sistema de archivos. Esto significa que, incluso si ignoramos la verdad (como en un dispositivo Nexus más antiguo como un Nexo 7 2013), se necesita una nueva imagen del kernel para evitar las protecciones de SELinux que impiden que funcione el acceso raíz.

Si quieres rootear hoy, en Android Marshmallow, necesitarás usar una imagen de arranque modificada.

Hasta ahora, ha habido granos modificados configurar SELinux en modo permisivo, pero esta no es una solución ideal, ya que significa que no obtiene los beneficios de seguridad de la protección de SELinux. Y, después de la Miedo escénicosagaSupongo que puede ver los beneficios de SELinux y otras protecciones contra vulnerabilidades de seguridad.

Desarrollador senior reconocido de XDA, Fuego en cadena, el maestro de todo lo relacionado con la raíz ha lanzado un versión actualizada de SuperSU que mantiene SELinux en modo obligatorio, pero una vez más requiere que se realicen modificaciones en la configuración de SELinux de la imagen de arranque. Esto significa que necesita instalar SuperSU, así como una imagen de inicio modificada.

Y eso está muy bien. hasta que los transportistas estadounidenses entren en la mezcla. Los bastiones de la lucha contra la elección del consumidor, se sabe que los incondicionales como AT&T y Verizon disfrutan bloqueando dispositivos, evitando que los usuarios instalen firmware personalizado a través de los bloqueos de su gestor de arranque. De hecho, Verizon es particularmente malo al ni siquiera transmitir actualizaciones de firmware a los usuarios, con el Sony Xperia Z3v. no configurado para recibir Marshmallow mientras que el resto de la gama Z3 (y de hecho la gama Z2) sí lo harán. Diablos, todavía ni siquiera han implementado Lollipop en el dispositivo, a pesar de que está disponible para bastante tiempo (noviembre de 2014) en el Z3 normal.

En lugar de un desbloqueo no oficial del gestor de arranque (esos son bastante raros hoy en día, a excepción de los gestores de arranque de ingeniería filtrados para algunos dispositivos Samsung), parece muy poco probable. que obtendrás root en Android 6.0 sin ninguna intervención divina: la combinación de dm-verity (para evitar que tu teléfono arranque con cualquier modificación en el partición del sistema), y el requisito de cambios de SELinux en el disco ram (para permitir que el root funcione), parecen destinados a hacer las cosas poco divertidas para los usuarios aspirantes a root de estos dispositivos bloqueados.

¿Pago Android?

Finalmente, Android Pay. Probablemente parezca completamente ajeno al resto de este artículo, pero en realidad es bastante relevante. Android Pay se basa en el nuevo API de SafetyNet dentro del marco de servicios patentados de Google, que está diseñado para proporcionar certificaciones del estado del dispositivo sobre si un dispositivo está rooteado, modificado de otro modo o ejecutándose en un estado no aprobado.

Si bien hay un proyecto Al analizar las respuestas falsificadas a SafetyNet, actualmente requiere un complemento Xposed, y no parece probable que esto cambie, dada su forma de funcionar. Xposed requiere root y realiza modificaciones en la partición del sistema. Eso hace que esto sea difícil de llevar a cabo en un dispositivo con gestor de arranque bloqueado. Incluso entonces, cosas como ésta no son más que entrar en un juego del gato y el ratón con Google. Con SafetyNet, los dispositivos rooteados (o incluso los dispositivos modificados) se consideran "no compatibles con CTS", lo cual es un eufemismo para dispositivos modificados.

Hay mucho más escrito sobre SafetyNet en esta publicación de blog de desmontaje, pero ciertamente parece que podemos identificar algunas áreas que Google quiere tomar medidas drásticas. En primer lugar, no les gusta rootear, Xposed ni nada que modifique la partición del sistema. En segundo lugar, parece que Google está considerando detectar usuarios que tengan habilitado el bloqueo de anuncios: el protocolo de enlace SSL verifica pubads.g.doubleclick.net Ciertamente me sugieres que Google quiera saber si estás bloqueando anuncios en tu dispositivo. Teniendo en cuenta que la raíz suele ser un requisito previo allí, pero que la API de VPN podría usarse para hacerlo Esto sin root, parece que Google al menos quiere tener una idea de quién (o cuántas personas) está bloqueando. anuncios. El bloqueo de anuncios es un tema de actualidad dada la presión de Apple para admitirlo en el navegador web (posiblemente para fomentar que las personas usen más aplicaciones, donde controlan la experiencia y pueden ofrecer anuncios no bloqueables), y estos movimientos son interesante.

Conclusión

Si desea rootear hoy, en Android Marshmallow (6.0), necesitará usar una imagen de inicio modificada. Si bien queda por ver si esto seguirá siendo así indefinidamente, parece probable que así sea durante algún tiempo: los cambios de SELinux hacen que sea mucho más difícil obtener acceso root sin modificar la imagen de arranque. Y como modificar la imagen de arranque requiere un gestor de arranque desbloqueado, esto podría poner fin a root (y Xposed y otras funciones raíz) en dispositivos que se envían con cargadores de arranque que los usuarios finales no pueden desbloquear. Dm-verity también está haciendo acto de presencia y parece estar habilitado en modo obligatorio en nuevos dispositivos. Eso hará que sea difícil modificar /system, incluso si obtuvieras acceso root, sin volver a tener un gestor de arranque desbloqueado.

¿Esto cambia su visión de los dispositivos bloqueados con el gestor de arranque? ¿Ha llegado Android a la etapa en la que aún comprarías un dispositivo con cargador de arranque bloqueado si tu operador te ofreciera una buena oferta?, ¿O solo te interesan los dispositivos desbloqueados? ¿Qué aplicaciones o funciones raíz extrañarías en un gestor de arranque bloqueado?

No dude en compartir sus pensamientos en los comentarios a continuación.