lunes, 12 de febrero de 2024

Instalación de binarios y creación de un entorno chroot Debian en Android


 

Una vez ganemos el root en nuestro móvil estaremos limitados por los ejecutables que este contenga de fábrica. Para poder realizar más acciones necesitaremos instalar binarios ejecutables adicionales que nos permitirán hacerle todo tipo de cosas al hardware.

¿Cómo funcionan los binarios en Android?

Android contiene binarios ejecutables nativos que provienen de diferentes fuentes. Los binarios comunes que encuentras en dispositivos Android comerciales pueden ser parte de toolbox o toybox, y algunos también pueden provenir del código de AOSP.

Los binarios se encuentran en las rutas /system/bin, /system/xbin, y /sbin:

  • /system/bin: En este directorio se encuentran los binarios esenciales que son parte de AOSP y son comunes a la mayoría de los dispositivos Android. Estos ejecutables proporcionan funciones básicas del sistema y herramientas de línea de comandos.

  • /system/xbin: Se usa para almacenar binarios adicionales que pueden no ser esenciales para las funciones básicas del sistema. En este directorio se colocan los binarios adicionales que hemos compilado por nuestra cuenta.

  • /sbin: Este directorio se utiliza para almacenar binarios críticos del sistema que están relacionados con operaciones del sistema a nivel más bajo. A menudo contiene binarios que son necesarios para el arranque del sistema y otras operaciones esenciales. En Android, este directorio podría contener binarios específicos del fabricante o personalizaciones del sistema.

Para construir bibliotecas nativas (archivos .so) y binarios ejecutables específicos que puedan ser usados por las aplicaciones de Android o en una consola, como adb shell, Google proporciona el Kit de Desarrollo Nativo (NDK). Esta herramienta es especialmente útil cuando se requiere un rendimiento optimizado y se elige escribir ciertas partes de la aplicación en lenguajes de bajo nivel. Sin embargo el hecho de que un binario ejecutable haya sido optimizado dentro del NDK no significa que tenga todos los permisos necesarios para funcionar en Android. Necesitarán el acceso root los binarios que realicen tareas como: acceder y modificar las particiones del sistema, acceso a algunos archivos y directorios como archivos de configuración críticos y directorios sensibles, modificar o controlar procesos y servicios del sistema operativo, acceso a ciertos componentes de hardware, como el controlador de la CPU, la interfaz de red avanzada, o ajustes específicos de hardware. No debemos confundir el NDK, destinado para construir binarios y bibliotecas con el Software Development Kit (SDK), destinado para el desarrollo de aplicaciones .apk.

Instalar binarios sin ser root es complicado por la limitación de ejecutar chmod para otorgar permisos de ejecución o el impedimento de ejecutar chown, ya que el sistema de archivos puede estar montado con restricciones de seguridad que impiden cambios en los propietarios de ciertos archivos o directorios, como describíamos en el anterior artículo sobre cómo conseguir el root. Se podría intentar instalar en la ruta /data/local/tmp/ ya que esta ruta se utiliza para almacenar y realizar ciertas operaciones temporales. Por lo general, la instalación de binarios requiere de root.

Para instalar binarios estáticos que son aquellos que no dependen de ninguna biblioteca, por lo que se pueden usar directamente, una forma sencilla es compilarlos para el hardware de nuestro móvil (arm ó arm64) y copiarlos a la carpeta destino con adb push /ruta/de/nuestro/pc/origen /ruta/destino/móvil.

¿Cómo instalar busybox estático, busybox dinámico y/u otros binarios?

Para ganar algunas nuevas funcionalidades podemos instalar los binarios individualmente o hacer una instalación de “busybox” que es una especie de navaja suiza que alberga muchos binarios en un mismo ejecutable. El repertorio de instrucciones que contiene es mayor que el de toolbox o toybox, que son sus alternativas. Existen dos tipos de compilaciones de busybox, la estática que se vale por sí sola y ocupa más espacio, o la dinámica que depende de bibliotecas (.so) que pueden ser compartidas por otras aplicaciones y ocupa menos espacio. En ambas instalaciones se usan enlaces simbólicos que ejecutan el binario busybox. Las bibliotecas se suelen almacenar en /system/lib. Para instalar cualquier binario simplemente basta con haberlo compilado para la arquitectura en la que estamos trabajando y copiarlo a su carpeta de destino.

Instalando busybox ganaremos algunas funcionalidades pero aún nos faltarán otras para poder sacarle todo el provecho al hardware. Otra forma de actuar sería instalar un sistema operativo Linux con todo los binarios necesarios para explorar todas las capacidades de nuestro móvil. El camino más largo es adaptar una distribución Linux a nuestro hardware o buscar si alguien ya ha implementado una solución más rápida para nuestro propósito. Las instrucciones más sencillas para probar un sistema Linux, como podría ser Debian, son instalar el sistema de archivos en una partición del móvil, como podría ser el almacenamiento externo y entrar en modo fastboot para indicarle al móvil que arranque desde el kernel indicado. Estas instrucciones se pueden encontrar aquí.

En vez de portar un nuevo sistema operativo a nuestro hardware, podemos aprovechar las propiedades del sistema operativo que ya tenemos, Android, e implementar los recursos que necesitemos. Esto se puede conseguir con un entorno “chroot” y de esta forma nos evitaremos el tedioso trabajo de adaptar todos los controladores y el software del sistema operativo al hardware, aún coste en ciertas restricciones al hardware que se podrían superar implementando modificaciones en el sistema operativo principal.

Si creamos un entorno “chroot” sin “root” muchas de las operaciones necesarias como la instalación de software y la manipulación de ciertos directorios del sistema estarán restringidas y puede que no funcionen, por lo que para un mayor beneficio necesitaremos el “root” del teléfono.

El comando chroot de Linux cambia el directorio raíz para un proceso y sus hijos. De esta forma se consigue un entorno aislado dentro del sistema de archivos principal, limitando el acceso del proceso a un subdirectorio específico. Chroot sólo proporciona aislamiento a nivel de sistema de archivos. No aísla completamente otros recursos como procesos, red o memoria. Dentro de este entorno, no se tendrá acceso a recursos fuera de este directorio por defecto. Por lo que para poder hacer uso de otros directorios hay que montarlos con mount y la opción -o rw (permiso de lectura-escritura) o vincularlo mediante -o bind. (Recuerda desmontar en orden inverso a como has montado, para evitar dependencias entre ficheros).

El entorno chroot más básico que podemos construir es una jaula con busybox. Para ello simplemente ejecutamos:

chroot /mnt/busybox /bin/busybox --install

chroot /mnt/Debian /bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/sh

Ó

chroot /mnt/Debian /bin/sh

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin (Definiendo la variable PATH)


Construyendo Debian dentro de Android

Hay diferentes formas de construir un sistema Debian en un entorno chroot desde Android. Una de ellas es desde una imagen mínima y luego completar la instalación. En la dirección https://ftp.debian.org/debian/dists/stable/main/installer-arm64/current/images/ tenemos las opciones “cdrom/”, “device-tree/”, “netboot/” y “u-boot/”. La imagen “cdrom/” está destinada para instalaciones desde CD-ROM. La carpeta “device-tree/” contiene archivos .dtb que son archivos utilizados para describir la información de hardware específica de una plataforma. Esto ficheros se usan en sistemas integrados como la Raspberry pi. La carpeta “u-boot/” contiene imágenes destinada a dispositivos que funcionan con un gestor de arranque U-Boot.

La carpeta “netboot/” contiene imágenes destinadas a instalaciones mínimas cómo la que hemos comentado.

Otro tipo de instalación podría ser usar una imagen cloud. En el caso de Debian se podría descargar desde https://cloud.debian.org/images/cloud/ e instalarla.

Existen otras distribuciones que ya viene preparadas para entornos chroot como es el caso de AlpineOS. En este caso solo tenemos que descomprimir el fichero y configurar el sistema.

Pero la forma más eficiente para instalar Debian en un entorno chroot, es mediante debootstrap, una herramienta basada en un script que automatiza la construcción del sistema de archivos de un sistema Debian en un directorio específico de nuestro PC. Para ello necesitamos un PC con una distribución de Linux en el que ejecutaremos “debootstrap”.

Al correr “debootstrap” con “--foreign” estaremos indicando que vamos a realizar una instalación en dos pasos, completándose en un dispositivo distinto, y se le agregamos el parámetro “--arch=arm64” le indicamos que el dispositivo de destino tiene una arquitectura ARM de 64 bits. Esto hace que se genere también una carpeta con todos los binarios necesarios para hacer uso de debootstrap en esa arquitectura. Lo ideal sería partir de una jaula chroot con busybox dentro de Android y poder ejecutar “debootstrap” directamente en el mismo dispositivo, pero para ello tendríamos que resolver todas sus dependencias y modificar el script.

Lo ejecutamos en nuestro PC Linux:

sudo debootstrap --foreign --arch=arm64 stable /home/pc/DebianARM64 http://ftp.debian.org/debian

Comprimimos el directorio Debian:

sudo tar -cf DebianARM64.tar ./DebianARM64/

Se lo pasamos al móvil por adb:

adb push ./DebianARM64.tar /storage/self/primary/

Accedemos a una shell del móvil:

adb shell

Ya en el móvil, descomprimimos y montamos:

tar -xf /storage/self/primary/DebianARM64.tar -C /mnt/

mount -t proc none /mnt/DebianARM64/proc

mount -t sysfs none /mnt/DebianARM64/sys

mount -o bind /dev /mnt/DebianARM64/dev

chroot DebianARM64/ /bin/bash

Definimos variables:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Ejecutamos la segunda etapa de la instalación, que consiste en la configuración del sistema:

cd /debootstrap

./debootstrap --second-stage

Cuando termine, configuramos el password del usuario root, y añadimos el usuario con el que vamos a trabajar:

passwd root

adduser androidDebian

Salimos y volvemos a entrar logueandonos con:

chroot /mnt/DebianARM64 /bin/login

Una vez logueados tenemos que añadir los usuarios “aid_*” que utiliza Android para poder hacer uso del hardware. Podemos encontrar una lista completa de los grupos y usuarios de Android en su código fuente https://android.googlesource.com/platform/system/core/+/refs/tags/android-8.1.0_r50/libcutils/include/private/android_filesystem_config.h

groupadd -g 3001 aid_net_bt_admin

groupadd -g 3002 aid_net_bt

groupadd -g 3003 aid_inet

groupadd -g 3004 aid_net_raw

groupadd -g 3005 aid_net_admin

groupadd -g 3006 aid_net_bw_stats

groupadd -g 3007 aid_net_bw_acct

groupadd -g 3008 aid_net_bt_stack

Añadimos a los grupos los usuarios “root” y los que hallamos creado, en mi caso “android

usermod -G 3003 -a root

usermod -G 3003 -a android

Para que el gestor de paquetes “apt” tenga acceso a internet hay que introducirlo en los grupos secundarios aid_inet y aid_net_raw. El grupo principal puede ser cambiado por aid_inet.

usermod -g 3003 -G 3003,3004 -a _apt

Cuando dejemos de usar el sistema Linux tenemos que desmontar los discos en sentido inverso al que hemos montado:

umount -o bind /dev /mnt/DebianARM64/dev

umount -t sysfs none /mnt/DebianARM64/sys

umount -t proc none /mnt/DebianARM64/proc

Para guardar nuestro sistema operativo Linux y continuar otro día con el, podemos comprimirlo en un .tar o crear una imagen de disco.

Si decidimos crear una imagen, creamos el fichero:

touch /mnt/DebianARM64.img

Lo llenamos de zeros:

dd if=/dev/zero of=/mnt/DebianARM64.img bs=1M count=2048

Le damos formato ext4:

mke2fs -t ext4 /mnt/DebianARM64.img

Lo adjudicamos al loop0:

losetup /dev/block/loop0 ./DebianARM64.img

Lo montamos:

mkdir /mnt/imagen

mount -o rw -t ext4 /dev/block/loop0 /mnt/imagen

Copiamos la carpeta raíz:

mv -r /mnt/DebianARM64 /mnt/imagen

O si decidimos comprimirlo en un fichero .tar:

tar -cf Debian.tar /mnt/DebianARM64

Aplicaciones y proyectos

Todo este proceso puede automatizarse por medio de una aplicación para Android. Así es como trabaja LinuxDeploy, una app que inicializa un entorno chroot con busybox e instala una distribución Linux con una versión adaptada del script debootstrap. LinuxDeploy permite la instalación de Alpine, Arch, CentOS, Debian, Fedora, Kali, Slackware y Ubuntu en un entorno chroot dentro de Android, creando para ello, según deseemos, una imagen de disco, un directorio en una tarjeta flash, una partición o directamente sobre la RAM. La distribución Linux instalada es accesible desde SSH y VNC para su uso a distancia, de esta forma puedes convertir tu móvil en un PC temporalmente. No es funcional al 100% por que el Hardware está ocupado por los servicios de Android y su kernel. Todos los cambios realizados en el dispositivo son reversibles, es decir, la aplicación y los componentes se pueden eliminar por completo.

Un proyecto pensando para convertir tu móvil Android en un PC completamente funcional es maruos.com. Este proyecto esta pensado para hacer un uso dual del hardware. Para ello reemplaza el sistema operativo Android por el firmware Maru, el cuál permite tener en el dispositivo móvil una distribución adaptada de LineageOS y al conectarlo por HDMI a una pantalla tendríamos Maru Desktop, una versión adaptada de Debian 9, comportándose como si fuera un PC. Permite conectar teclado y ratón por bluetooth.

Desde Termux también se puede realizar una instalación de Debian con GUI en un entorno chroot. Además se puede lograr sin ser root al ejecutar la instrucción proot, una implementación de chroot en el espacio de usuario, lo que significa que no necesita ningún privilegio.

Una solución para instalar un sistema Linux completo con su kernel es hacer uso de Qemu o KVM. Podríamos hacer uso de Qemu en dispositivos que no cuenten con emulación por hardware, corriendo toda la emulación por software, lo que podría suponer en un alto consumo de recursos. Y hacer uso de KVM en dispositivos que tengan disponible la emulación por hardware.

 

domingo, 11 de febrero de 2024

[Nota] Ejecutar script al arrancar Android

 


Ejecutar scripts al arranque de Android era sencillo antes de la implantación de SELinux, simplemente había que crear un script en la ruta /system/etc/init.d/99Mi-Script.sh y este se ejecutaba sin más al arrancar. Desde la implantación de SELinux y tras la decisión de desactivar el soporte nativo para la ejecución de scripts desde /system/etc/init.d, esto ya no es posible, por lo que hay que buscar alternativas. Una de ellas es rootear el móvil con Magisk y usar la ruta por defecto /data/adb/post-fs-data.d/ que utiliza magisk para ejecutar script automáticamente tras el arranque.


Cuando el sistema arranca, Magisk ejecuta automáticamente scripts ubicados en la carpeta /data/adb/post-fs-data.d/ después de que el sistema de archivos principal ha sido montado y antes de que las aplicaciones comiencen a ejecutarse. Los scripts se ejecutan como root y ofrecen una oportunidad para realizar configuraciones personalizadas, correcciones o modificaciones en el sistema antes de que las aplicaciones empiecen a cargarse.

El script puede tener la forma:

#!/system/bin/sh
# Script de arranque personalizado

# Comandos o acciones que deseas realizar al iniciar el dispositivo

# Ejemplo: Montar una partición
mount -o remount,rw /system
echo "Hola, este es mi script de arranque" > /system/boot.log
mount -o remount,ro /system

# Puedes agregar más comandos según tus necesidades


exit 0



sábado, 10 de febrero de 2024

[Nota] ¿Cómo reducir la capacidad de una imagen de disco?

 


Reducimos el tamaño de una imagen de disco formato "ext4"

  1. Eliminación del espacio sobrante.

Determinamos cuánto queremos que ocupe:

truncate -s 8g /ruta/Debian.img


  1. Comprobación y corrección de errores de la imagen.

Ejecutamos e2fsck para corregir errores de la imagen del disco:

e2fsck -f /ruta/Debian.img


  1. Reducción de la imagen.

Reducimos el tamaño del sistema de archivos (el prefijo G,M,K corresponde a Gigas, Megas, Kilo):

resize2fs /ruta/Debian.img 8G


  1. Montamos imagen y comprobamos tamaño:

Creamos carpeta de montaje:

mkdir /mnt/Debian


Montamos en la carpeta de montaje:

mount -t ext4 /ruta/Debian.img /mnt/Debian


Comprobamos tamaño, desmontamos y borramos carpeta:

df -h

umount /mnt/Debian

rm /mnt/Debian


[Nota] ¿Cómo aumentar la capacidad de una imagen de disco?

 


Aumentar la capacidad de una imagen de disco “.img” formato ext4 en 8GB en 4 pasos.

  1. Aumentar el espacio en la imagen.

Creamos el espacio adicional en la imagen:

dd if=/dev/zero bs=1048576 count=8192 >> linux.img

  1. Asociamos la imagen .img con el dispositivo /dev/block/loop0.

Comprobamos el primer dispositivo loop libre:

losetup -f

Asociamos la imagen y el dispositivo loop:

losetup /dev/block/loop0 ./linux.img

Comprobamos que se han asociado correctamente viendo que el primer dispositivo loop libre se ha incrementado en uno:

losetup -f

  1. Ampliar el sistema de archivos ext4.

Escaneamos el sistema de archivos para descartar errores:

e2fsck -f /dev/block/loop0

Aumentamos el tamaño del sistema de archivos:

resize2fs /dev/block/loop0

  1. Montar sistema de archivos y comprobar.

Montamos la imagen para comprobar que el aumento se ha realizado con éxito.

Creamos la carpeta donde vamos a montar:

mkdir /mnt/linux

Montamos la imagen asociada al dispositivo loop en la carpeta creada:

mount -t ext4 /dev/block/loop0 /mnt/linux

Comprobamos el tamaño:

df -h

Desmontamos al comprobar que el tamaño es el correcto:

umount /mnt/linux

Borramos la carpeta creada:

rm /mnt/linux

lunes, 5 de febrero de 2024

Root en Android

 



    Tenemos nuestro móvil Android y queremos trastear su hardware y sacarle más provecho, ¿por qué Android no nos permite acceder a todo el hardware?

    Android utiliza un sistema de permisos basado en el principio de "privilegio mínimo necesario", controlando el acceso a recursos y funciones críticas del sistema. Este sistema está diseñado para garantizar la seguridad y la integridad del sistema operativo. Las versiones principales de Android se pueden distinguir en dos tipos de compilaciones, las compilaciones de desarrollo, destinadas a ingenieros y desarrolladores, que incluyen herramientas de depuración, acceso root y otras configuraciones para facilitar el desarrollo y la depuración. Tienen ninguna o pocas restricciones de seguridad. Y la compilación de dispositivo comercial destinada al usuario final, cuya consulta getprop ro.build.typeen una consola como “adb shell devuelve “user”. Cuenta con todas las restricciones de seguridad y no incluye herramientas de depuración. Por esta razón nuestro móvil no nos permite acceder a todo el hardware.

    ¿Cómo podemos ganar privilegios? ¿Cómo podemos obtener acceso root? Obtener el root en dispositivos que son comerciales es sencillo cuando se puede desbloquear el bootloader, pero puede ser un desafío en los otros casos en lo que no se puede desbloquear. En sistemas dónde el bootloader es desbloqueable se puede flashear la partición system por una que cambie el sistema operativo de una versión comercial a una versión de desarrollo, habilitando el acceso root. Esto se consigue modificando las propiedades ro.secure y ro.debuggable en el fichero “build.prop”.

  • ro.secure: Esta propiedad determina si el sistema se inicia en modo seguro. Si ro.secure está configurado como "1", el sistema se inicia en modo seguro, lo que significa que ciertas funcionalidades de depuración y acceso root pueden estar deshabilitadas o restringidas.

  • ro.debuggable: Esta propiedad indica si el sistema está configurado para ser depurable. Al configurarlo como "1", se permite la depuración del sistema. En una compilación de usuario final comercial, esta propiedad está configurada como "0" para mejorar la seguridad.

    Hay que tener en cuenta que desbloquear el bootloader provocará que la partición /data se borre, y que algunos bootloaders iniciarán un flag permanente indicando que el bootloader ha sido modificado, además este flag permanecerá incluso si se vuelve a bloquear.

    Al arrancar el sistema operativo con esta modificación en la partición System estaremos produciendo un cambio similar a como funciona una compilación de desarrollo y esto nos permite habilitar el acceso root. Al ejecutaradb rootestaremos consiguiendo una shell root. Además se puede instalar el binario “su”, asignándole el bit SUID y permitiendo el cambio al usuario root directamente.

    Puede ocurrir que la distribución comercial Android de nuestro móvil haya sido compilada sin definir la macro relativa al demonio adbd “ALLOW_ADBD_ROOT” que provoca que se ignoren las propiedades ro.secure y ro.debuggable, no permitiendo el acceso root. Si ALLOW_ADBD_ROOT está definido, el demonio adbd permitirá el acceso root.

    En esta situación aun nos quedaría el binario “su”, que habríamos agregado con el bit SUID, permitiendo el acceso root no solo desde la shell, sino también desde aplicaciones de terceros. Sin embargo las versiones actuales de Android tienen restricciones que impiden que las aplicaciones ejecuten binarios SUID, lo que limita la capacidad de las aplicaciones para elevar privilegios. Y desde hace unos años montan la partición System con la bandera nosetuid, lo que deshabilita el uso del bit SUID. También tenemos el sistema de control de acceso obligatorio (MAC) SELinux (Security-Enhanced Linux) que impone políticas de seguridad en el sistema. Por lo que incluso obteniendo acceso root, el proceso seguirá estando bajo las políticas de seguridad definidas por SELinux.

    Por otro lado Zygote es un componente que inicia junto al arranque de Android. Realiza tareas de inicialización y carga recursos comunes que son compartidos por varias aplicaciones. Cuando se lanza una nueva aplicación, Zygote crea un nuevo proceso hijo a partir de sí mismo. Este proceso hijo hereda el estado inicializado de Zygote, lo que acelera el tiempo de inicio de la aplicación. Zygote evita tener que cargar e inicializar recursos comunes cada vez que arranca una nueva aplicación, mejorando el tiempo de inicio de las aplicaciones y optimizando el uso de recursos del sistema. Zygote ayuda a acelerar el inicio de aplicaciones, pero cada aplicación se ejecuta en su propio proceso independiente. Además los procesos creados a partir de Zygote inician su ejecución con un conjunto limitado de capacidades, lo que refuerza la seguridad limitando las acciones que pueden realizar.

    En las versiones más antiguas de Android existía un método para conseguir el root mediante instalaciones Over-The-Air (OTA). Este método necesita de un recovery personalizado como TWRP ya que el recovery oficial del móvil sólo permite instalar OTA firmadas por el fabricante. Por lo que también necesita tener desbloqueado el bootloader para poder instalar el recovery personalizado. El método para escalar privilegios con una instalación OTA consiste en modificar el sistema de archivos. El paquete suele constar de binarios para la arquitectura ARM y x86, scripts para instalar demonios y el binario “su”, además suele haber una .apk que administra los permisos para el resto de aplicaciones. Básicamente lo que ocurre es que se copia el binario “su” y los demonios correspondientes a la partición system, y se configuran los permisos y las etiquetas de seguridad SELinux para poder ejecutar la elevación de privilegios.

    En la actualidad, Android implementa otras medidas de seguridad además de las ya comentadas, para prevenir el acceso root no autorizado. Entre estas medidas están, la verificación de integridad del sistema (Verified Boot) que verifica que solo se cargue el firmware firmado digitalmente en el momento del arranque. Si detecta que una partición ha sido modificada, el sistema puede mostrar un mensaje de advertencia al usuario o simplemente rechazar el arranque, dependiendo de la implementación específica del fabricante. Otra de las características de seguridad que incorpora Android es montar particiones críticas como de solo lectura.

    Desde hace unos años también incluye SafetyNet API, una medida de seguridad que permite a las aplicaciones verificar la integridad del dispositivo, verificando el estado del bootloader, la existencia de permisos de root y la detección de indicadores de compromiso que podrían indicar que el dispositivo ha sido rooteado o modificado. Esta API es utilizada por aplicaciones sensibles a la seguridad, como servicios bancarios y de pago, para determinar si el dispositivo permanece en un estado seguro y es confiable.

    Con todas estás medidas de seguridad, las aplicaciones de rooteo tienen que conseguir el root sin modificar las particiones del sistema directamente. Lo consiguen utilizando técnicas de inyección en el proceso Zygote, de esta forma producen modificaciones en tiempo de ejecución sin cambiar permanentemente el sistema, aplicando cambios como el remonte de la partición del sistema en modo lectura y escritura (mount -o remount,exec,dev,suid,rw /partición) temporalmente para aplicar modificaciones necesarias. Con estas propiedades surge la técnica "Systemless root" con la que las modificaciones necesarias para obtener acceso root y realizar otras personalizaciones se aplican en el espacio de usuario en lugar de modificar directamente las particiones de solo lectura. Estas modificaciones pueden incluir la instalación de binarios y archivos necesarios para el acceso root, así como la aplicación de parches en tiempo de ejecución para eludir restricciones. El espacio de usuario es donde se ejecutan las aplicaciones y los procesos del usuario. Este espacio es independiente de las particiones del sistema y generalmente es de lectura y escritura. Actualmente las aplicaciones de rooteo ocultan el acceso root a las aplicaciones que hacen uso de SafetyNet.

    Existen otra forma de escalar privilegios aprovechando la explotación de vulnerabilidades, fallos o configuraciones inseguras en aplicaciones que se ejecutan como root en el propio sistema. Se puede hacer uso de vulnerabilidades del kernel Linux para conseguir el root, como hace la aplicación TowelRoot. Otras aplicaciones hacen uso de vulnerabilidades conocidas y no parcheadas en el dispositivo. El uso de zero-days es menos frecuente, pero puede ser usados con fines de infiltración y ganancia de privilegios.

    La ganancia de privilegios es algo delicado y debe estar auditada en el proceso de instalación. Los instaladores de fuentes desconocidas pueden contener malware que con el poder del root puede ser catastrófico. Puede contener rootkit que sean indetectable para las medidas de seguridad estándar que hemos citado anteriormente, permaneciendo oculto y parasitando el dispositivo móvil para fines nocivos. Por eso siempre debemos conocer quien es la fuente y saber que es lo que hace en nuestro sistema. Actualmente la aplicación más usada es Magisk y su sitio oficial en github es https://github.com/topjohnwu/Magisk.

    Magisk utiliza un enfoque Systemless root, por lo que las modificaciones del sistema las realiza en el espacio de usuario. Desde la versión 22 de Magisk, lanzada en febrero de 2021, el método de instalación consiste sólo en descargarse una única apk que es a su vez un paquete zip flasheable desde un recovery personalizado como TWRP.

    Se instala la aplicación Magiskapp y al abrirla comprueba si el móvil tiene el “ramdisk” en la partición de arranque (boot). El "ramdisk" (disco RAM) en la partición de arranque (boot partition) es una parte del sistema de archivos que se carga en la memoria RAM durante el proceso de arranque. Sus funciones son la inicialización del hardware, la carga de módulos de kernel, la configuración de parámetros del sistema, y la ejecución de scripts de inicio. Magisk se instala en la partición de arranque y modifica el ramdisk, específicamente el archivo init, que es el script de inicio del sistema. Magisk utiliza el ramdisk para implementar la ocultación del acceso root, y para realizar un bypass de SafetyNet, engañando a las verificaciones de seguridad para que ciertas aplicaciones no detecten el estado de root.