¿Cómo hacer root manualmente en un teléfono?

Estaba mirando los resultados de la búsqueda en la web de "cómo hacer funcionar manualmente los dispositivos Android" y me di cuenta de que la mayoría de ellos son sólo material publicitario o hace uso de soluciones del rooting dedicadas (particularmente de código cerrado). Aquellas que funcionaban hace algún tiempo ahora son obsoletas ya que dependían de algunos vulnerabilidad de seguridad en el Android que se fijó con el tiempo.

De hecho, no es imposible de rootear el teléfono manualmente, pero no vale la pena el problema. Sin embargo, como referencia, déjame describir una opción. Pero antes de sumergirnos en los detalles técnicos, necesitamos entender lo que es root y cómo Android previene el acceso a root . Los detalles se pueden encontrar aquí pero unos pocos puntos en resumen:

• La mayoría de los vendedores envían sus dispositivos con un cargador de arranque bloqueado, y se establece una cadena de confianza durante el proceso de arranque, que no permite ninguna modificación del núcleo ( boot.img ), la recuperación o el sistema operativo principal. Así que el primer paso hacia el arraigo es desbloqueado el cargador de arranque . Cuidado con el riesgos !

• Una parte de la cadena de confianza es dm-verity ( VB / AVB ); un fenómeno basado en el núcleo que asegura que las particiones que contienen el núcleo del sistema operativo ( /system , /vendor , /odm ) se montan siempre en modo de sólo lectura y cualquier intento malicioso de modificarlos debe fallar. Modificando boot.img o recovery.img suele ir acompañado de desactivando dm-verity para evitar sorpresas como los bootloops en etapas posteriores. La advertencia estándar de la TWRP:

  ¡Este dispositivo utiliza la versión DM!
  Esto significa que el swiping para permitir modificaciones en el sistema evitará que puedas arrancar si estás usando el kernel de reserva.

• Las aplicaciones para Android no tienen la capacidad de elevar sus privilegios ejecutando binarios que tienen setuid o conjunto de capacidades de archivo (que es la forma estándar de obtener acceso a Root). Por lo tanto, la única opción es ejecutar un proceso persistente en segundo plano (demonio) con privilegios de root fuera de las aplicaciones (por ejemplo, durante el proceso de arranque) y solicitarle que realice tareas privilegiadas en nombre de las aplicaciones sin privilegios cuando sea necesario.

• Root (es decir, UID 0) es el antiguo Control de Acceso Discrecional (DAC), pero Android también hace uso del Control de Acceso Obligatorio (MAC), es decir, SELinux. Un proceso Root que se ejecuta con un contexto SELinux restringido es bastante inútil, así que tenemos que romper esta barrera también. Requiere modificar la política de SELinux.

Trataré los dos últimos puntos aquí, pero las dos primeras consideraciones:

• Las soluciones del rooting de Android despliegan un especial su binario que, cuando es ejecutado por una aplicación, hace una conexión con un demonio privilegiado y le da a la aplicación un shell Root. Así que este su binario y demonio están especialmente desarrollados para este propósito. Un enfoque menos sofisticado sería ejecutar los demonios ya disponibles como adbd , sshd o uno de los viejos inetutils sabores ( telnetd , rlogind , rshd , rexecd ) con privilegios de root. Cuando se ejecutan en segundo plano, estos servidores pueden proporcionar un shell de root o ejecutar comandos con privilegios de root cuando se conectan por un cliente. Para simplificar, sólo estoy usando una utilidad de red mínima llamada netcat ( nc ) que es un busybox applet. Pero, por favor, tenga en cuenta que las aplicaciones no pueden tener acceso a root con este enfoque sólo se puede usar desde la línea de mando.
• Vamos a parchear el monolítico /sepolicy archivo y /init.rc que forman parte de ramdisk en boot.img . Pero empezando por Treble Los usos de Android política de división que se carga desde /vendor/etc/selinux/ . Empezando por SAR no hay ningún ramdisk en absoluto en boot.img y /init.rc es parte de system.img . Así que en ambos casos es necesario modificar necesariamente system partición. No voy a dar detalles sobre eso aquí.

PASOS:

• Extracto boot.img por ejemplo, utilizando AIK o magiskboot en Android o PC.

• Crear un nuevo contexto SELinux, por ejemplo pseudo_su . Ponerlo permisivo para permitir cualquier posible interacción con otros procesos / archivos etc. Usar la tecnología de Magisk. supolicy herramienta o sepolicy-inject ( 1 , 2 ) en Android o PC:

  ~# supolicy 'create pseudo_su'
  ~# supolicy 'permissive pseudo_su'
  ~# supolicy 'allow pseudo_su * * *'
  ~# supolicy 'allow * pseudo_su * *'

• Define un init servicio que inicia un simple servidor TCP en el arranque, sólo escuchando las conexiones del dispositivo:

  # /init.rc
  ...
  service pseudo_su /sbin/busybox nc -lk -s 127.0.0.1 -p 23 -e /sbin/busybox sh
      seclabel u:r:pseudo_su:s0
      disabled
  
  on property:sys.boot_completed=1
      start pseudo_su

  * Asegúrate de que tienes el derecho busybox binario, hay múltiples implementaciones de netcat .
  * Usar el puerto 23 o cualquier otro puerto no utilizado.

• Copia busybox binario a /sbin/ y establecer permisos de ejecución.

• Reempaquetar boot.img y el flash o la prueba con fastboot boot boot.img .

¿CÓMO EJECUTAR COMANDOS DE root?

Una vez arrancado, podemos pasar los comandos de un netcat cliente en una aplicación de emulador de terminal (como Termux) o adb shell :

~$ echo id | nc localhost 23
uid=0(root) gid=0(root) groups=0(root) context=u:r:pseudo_su:s0

Para facilitar su uso, cree funciones (póngalas en .bashrc para no tener que definir cada vez):

# ~/.bashrc
...
function psu() { echo "$@ 2>&1" | nc localhost 23; }
function psush() { nc localhost 23; }

~$ ls -ld /data/adb
ls: cannot access '/data/adb': Permission denied
~$ psu ls -ld /data/adb
drwx------ 7 root root 3488 2019-07-19 00:44 /data/adb

Para obtener la cáscara de root:

~$ psush
whoami
root
^C

Pero es sólo un concha tonta no está conectado a la terminal. Para tener una experiencia más rica en características, otras herramientas como socat se pueden usar que soportan la edición de líneas, pseudo-terminales, etc.
Además, las variables de entorno no se evalúan a menos que se pasen explícitamente, porque los comandos se ejecutan de forma remota:

~$ /data/data/com.termux/files/usr/bin/ps -p $$,1 -o pid=,comm=
23599 bash
~$ psu /data/data/com.termux/files/usr/bin/ps -p $$,1 -o pid=,comm=
CANNOT LINK EXECUTABLE "/data/data/com.termux/files/usr/bin/ps": library "libprocps.so" not found
~$ psu LD_LIBRARY_PATH=/data/data/com.termux/files/usr/lib /data/data/com.termux/files/usr/bin/ps -p $$,1 -o pid=,comm=
    1 init
23599 bash

Así es como podemos obtener una funcionalidad mínima de root sin usar ninguna herramienta especializada de root.