El root es un elemento muy importante para muchos usuarios avanzados, ya que les permite una libertad de personalización y de uso en general que no podrían tener de otra manera. Gracias al root muchos nos hemos deshecho de ese bloatware que tanto nos molesta o hemos incorporado nuevas características a nuestros teléfonos.
Pero la llegada de Android Nougat y los nuevos terminales Pixel de Google pueden dar al traste (aún más) con nuestros intentos de rootear los dispositivos, incluso con el método de systemless root. Todo ello puede ser culpa de una "mudanza" del driver responsable de vigilar que no se modifique la partición /system.
¿Cómo era el root antes de Marshmallow?
Para llegar a la cuestión que nos ocupa, vamos a empezar por explicar cómo era el root, empezando por la época anterior a Marshmallow. Es cierto que a medida que avanzaba el tiempo los desarrolladores se esforzaban por facilitar el proceso del root, donde algunos modelos el proceso era tan tedioso que la gente se lo pensaba tres o cuatro veces antes de decidirse.
El proceso que tenía que seguir el usuario, a través de instalar diversos 'drivers', descargarse ciertos archivos y ejecutar instrucciones en la ventana de comandos, era conseguir modificar la partición /system para obtener el acceso root tan deseado. Es decir, el usuario estaba ejecutando una serie de 'exploits'.
Con el tiempo acabaron por aparecer aplicaciones que, con un sólo click en la pantalla, te rooteaba el teléfono. Seguramente la primera aplicación que te venga a la cabeza sea Kingroot. Aplicaciones de este estilo no eran más que un conjunto de 'exploits', y la app únicamente buscaba cuáles podía usar para rootear tu modelo de teléfono.
Al final, antes de la llegada de Marshmallow, la mayoría de usuarios podía usar alguna aplicación de este tipo y, a partir de ahí, volverse locos instalando módulos de Xposed, aplicaciones que necesitaran root o ROMs personalizadas. Pero con la llegada de Android 6.0 el método tradicional de root se había acabado.
El root en Marshmallow, la llegada de systemless root
En Android Marshmallow Google decidió tomar cartas en el asunto para intentar extinguir el root en sus terminales, sobre todo de cara a ganarse la confianza de empresas del tipo bancos y demás empresas importantes para que los usuarios pudieran usar su nueva plataforma de pagos, Android Pay.
Lo que hizo Google fue añadir un driver en el kernel de Android llamado dm-verity, el cual se encargaba de vigilar que nada modificara la partición /system. Si detectaba un cambio en dicha carpeta por parte de un proceso no autorizado, el terminal se reiniciaba, pero el proceso de reinicio no se completaba, quedándose en una advertencia de que /system estaba corrupto y el sistema no arrancaría.
Entonces Chainfire, el desarrollador de SuperSU, tuvo la idea de intentar obtener acceso root sin modificar la partición /system. Esto se conseguía accediendo a ramdisk para desactivar dm-verity y así poder tener acceso root. Este método es lo que se conoce como systemless root, aunque tenía ciertas limitaciones. Pero la llegada de Nougat pondría las cosas mucho más difíciles.
Android Nougat, Pixel y el intento de adiós definitivo al root por parte de Google
Parece ser que a Google le sobran recursos y tiempo que destinar a intentar "matar" el root para siempre, y es que con la llegada de Nougat los métodos de root conocidos hasta ahora ya no valen. ¿La idea de Google? Meter a ramdisk en la partición /system, con lo cual dm-verity también queda dentro de dicha partición... o algo así.
Me explico, la partición /system "original", a la que iría cualquier exploit para modificar, en realidad es un sistema completo de archivos root que en el kernel era ramdisk que está unido a los archivos que suele tener la partición /system por defecto. Esto quiere decir que si intentas desactivar dm-verity a través de ramdisk, se considera que modificas la partición y, por lo tanto, brick al canto.
Dees_Troy, un destacado desarrollador que destaca en el mantenimiento de CyanogenMod, dice que para conseguir desactivar dm-verity habría que instalar un kernel modificado, pero esto podría hacer que las actualizaciones vía OTA quedaran desactivadas, además de otras complicaciones que aún se desconocen.
De todas formas, hasta que los desarrolladores no se hagan con un Pixel no podrán saber cómo de difícil ha puesto Google el root, pero teniendo en cuenta que los métodos actuales no funcionan, el equipo de desarrolladores van a tener que trabajar juntos para hallar una solución a este "problema".
Vía | XDA-DevelopersEn Xataka Android | Chainfire lanza suhide, para ocultar el root de aplicaciones específicas
Ver 25 comentarios