La mayor parte de su pregunta está cubierta en Documentación de Magisk . Citaré uno de mis respuesta anterior s a una pregunta diferente, con algunos innecesario detalles :)
PREREQUISITOS:
Para tener una comprensión completa de cómo funciona Magisk, uno debe tener conocimientos básicos de:
- Control de acceso discrecional ( DAC )
- Los identificadores de usuario (
[ESR]UID ), set-user-ID
-
Capacidades de Linux (proceso y archivo) que proporcionan un control de grano fino sobre los permisos de superusuario
- Control de acceso obligatorio ( MAC )
- Montar espacios de nombres, el uso de espacios de nombres de Android para Permisos de almacenamiento
- Montaje de la unión
- Proceso de arranque de Android, particiones y sistemas de archivos
- Android
init servicios (el primer proceso iniciado por el kernel)
- Estructura de
boot partición (kernel + DTB + ramdisk), Árbol de dispositivos Blobs , DM-Verity ( Arranque verificado de Android ), cifrado de disco completo / cifrado basado en archivos ( FDE/FBE ) etc.
¿QUÉ ES root?
Obtener privilegios de root significa ejecutar un proceso (normalmente el shell) con UID cero (0) y todas las capacidades de Linux, de modo que el proceso privilegiado puede saltarse todas las comprobaciones de permisos del kernel.
Los privilegios de superusuario se obtienen normalmente ejecutando un binario que tiene:
-
set-user-ID-Root (SUID) bit establecido en él
Así es como su y sudo trabajar en Linux en el tradicional DAC de UNIX. Los usuarios sin privilegios ejecutan estos binarios para obtener derechos de Root.
-
O Capacidades de los archivos ( setgid,setuid+ep ) colocado en él
Este es el método menos utilizado.
En ambos casos, el proceso que llama debe tener todas las capacidades en su conjunto de límites (una de las 5 categorías de capacidades que puede tener un proceso) para tener privilegios reales de root.
¿Cómo restringe Android el acceso a root?
Hasta Android 4.3, uno podía simplemente ejecutar un set-user-ID-root su binario para elevar sus permisos al usuario Root. Sin embargo, había una serie de Mejoras de seguridad en Android 4.3 que rompió este comportamiento:
- Android cambió a las capacidades de los archivos en lugar de depender de
set-user-ID tipo de vulnerabilidades de seguridad. Un mecanismo más seguro: Capacidades ambientales también se ha introducido en Android Oreo.
- Los demonios y servicios del sistema pueden hacer uso de las capacidades de los archivos para obtener capacidades de proceso (véase en Transformación de las capacidades durante la ejecución ) pero las aplicaciones tampoco pueden hacerlo porque el código de la aplicación es ejecutado por
zygote con atributo de control del proceso NO_NEW_PRIVS , ignorando set-user-ID así como las capacidades de los archivos. El SUID también se ignora al montar /system y /data con nosuid para todas las aplicaciones.
- El UID sólo puede cambiarse si el proceso de llamada tiene SETUID/SETGID en su conjunto Bounding. Pero las aplicaciones de Android están hechas para ejecutarse con todas las capacidades ya caídas en todos los conjuntos utilizando el atributo de control de procesos
CAPBSET_DROP .
- A partir de Oreo, la capacidad de las apps para cambiar el UID/GID se ha suprimido aún más por bloquear ciertas llamadas al sistema utilizando filtros seccomp .
Dado que el sistema autónomo su binarios dejaron de funcionar con el lanzamiento de Jelly Bean, se hizo una transición al modo su daemon . Este demonio se lanza durante el arranque y se encarga de todas las peticiones de superusuario realizadas por las aplicaciones cuando ejecutan el programa especial su binario ( 1 ) . install-recovery.sh (ubicado en /system/bin/ o /system/etc/ ) que es ejecutado por un servicio init preinstalado flash_recovery (inútil para los aventureros; actualiza la recuperación después de una instalación OTA) se utilizó para lanzar este demonio SU en el arranque.
El próximo gran reto se enfrentó cuando SELinux se estableció estrictamente enforcing con el lanzamiento de Android 5.0. recuperación_de_flash se añadió a un servicio de contexto SELinux restringido : u:r:install_recovery:s0 que detuvo el sin adulterar acceso al sistema. Incluso el UID 0 estaba obligado a realizar un conjunto muy limitado de tareas en el dispositivo. Así que la única opción viable era iniciar un nuevo servicio sin restricciones SUPER CONTEXTO por Parcheando la política de SELinux. Eso es lo que se hizo (temporalmente para Lollipop ( 2 , 3 ) y luego permanentemente para Marshmallow) y eso es lo que hace Magisk.
¿CÓMO FUNCIONA MAGISK?
El flasheo de Magisk suele requerir un dispositivo con el bootloader desbloqueado para que boot.img podría modificarse dinámicamente a partir de la recuperación personalizada ( 4 ) o un pre-modificado boot.img ( 5 ) puede ser flasheado/arrancado, por ejemplo, desde fastboot .
Como nota al margen, es posible iniciar Magisk en una ROM en funcionamiento si de alguna manera consigues privilegios de Root utilizando algún exploit en el SO ( 6 ) . Sin embargo, la mayoría de estas vulnerabilidades de seguridad se han corregido con el tiempo ( 7 ) .
También debido a algunas vulnerabilidades a nivel de SoC (como la de Qualcomm Modo EDL ), el cargador de arranque bloqueado puede ser hackeado para cargar una imagen de arranque / recuperación modificada rompiendo el Cadena de confianza . Sin embargo, estas son sólo excepciones.
Una vez que el dispositivo arranca desde el parcheado boot.img En este caso, un demonio Magisk con todos los privilegios (con UID: 0, capacidades completas y contexto SELinux sin restricciones) se ejecuta desde el inicio del proceso de arranque. Cuando una aplicación necesita acceso Root, ejecuta el programa Magisk (/sbin/)su binario (mundano accesible por DAC y MAC ) que no cambia el UID/GID por sí mismo, sino que simplemente se conecta al demonio a través de un socket UNIX ( 8 ) y pide que se proporcione a la aplicación solicitante un shell Root con todas las capacidades. Con el fin de interactuar con el usuario para conceder/denegar su de las aplicaciones, el demonio se engancha con el Magisk Manager aplicación que puede mostrar las indicaciones de la interfaz de usuario. Una base de datos ( /data/adb/magisk.db ) de los permisos concedidos/denegados es construido por el demonio para su uso futuro.
Proceso de arranque:
Se inicia el kernel de Android init con SELinux en permissive modo en el arranque. init cargas /sepolicy (o política de división ) antes de iniciar cualquier servicio/demonio/proceso, lo establece enforcing y luego cambia a su propio contexto. A partir de aquí, incluso init no está permitido por política volver al modo permisivo ( 9 , 10 ) . Tampoco la política puede ser modificada ni siquiera por el usuario Root ( 11 ) . Por lo tanto, Magisk sustituye a /init con un archivo personalizado init que parchea las reglas de política de SELinux con SUPER CONTEXTO ( u:r:magisk:s0 ) y define el servicio para lanzar el demonio Magisk con este contexto. A continuación, el init se ejecuta para continuar el proceso de arranque ( 12 ) .
Trabajo sin sistema:
Desde el init se construye en el archivo boot.img modificar es inevitable y /system la modificación se hace innecesaria. Ahí es donde el systemless El término fue acuñado ( 13 , 14 ) . La principal preocupación era facilitan las OTAs - re-flashear el boot imagen (y la recuperación) es menos molesta que volver a flashear system . OTA en bloque en una modificación de /system partición fallará porque permite el uso de dm-verity para firmar criptográficamente el system partición .
En los dispositivos más nuevos que utilizan system-as-Root en lugar de ramdisk en boot.img El init binario está en /system partición. En este caso recovery se utiliza para arrancar Magisk, conservando el enfoque sin sistema ( 15 ) .
Módulos:
Una ventaja adicional de systemless es el uso de Magisk Modules . Si desea colocar algunos binarios bajo /system/*bin/ o modificar algunos archivos de configuración (como hosts o dnsmasq.conf ) o algunas bibliotecas / archivos de marco (como los requeridos por mods como XPOSED ) en /system o /vendor puede hacerlo sin necesidad de tocar la partición mediante el uso de Montaje mágico (basado en los montajes de los enlaces). Magisk admite la adición y la eliminación de archivos mediante la superposición de los mismos.
MagiskHide: ( 16 )
Otro reto fue ocultar la presencia de Magisk para que las aplicaciones no puedan saber si el dispositivo está rooteado. A muchas aplicaciones no les gustan los dispositivos rooteados y pueden dejar de funcionar. Google fue uno de los principales afectados, por lo que introdujo SafetyNet como parte de GMS (Play Services), que indica a las aplicaciones (incluidas las propias Google Pay ) y por lo tanto sus desarrolladores que el dispositivo está actualmente en un estado no manipulado ( 18 ) . El rooting es también uno de los muchos estados templados posibles.
Además de ocultar su presencia del SafeyNet de Google, Magisk también permite a los usuarios ocultar Root de cualquier aplicación, de nuevo haciendo uso de bind mounts y mount namespaces. Para ello, zygote tiene que ser continuamente vigilado para los nuevos procesos bifurcados.
Sin embargo, es una tarea difícil ocultar realmente el dispositivo rooteado de las aplicaciones, ya que las nuevas técnicas evolucionan para detectar la presencia de Magisk, principalmente de /proc u otros sistemas de archivos. Así que un número de Las peculiaridades se hacen para apoyar adecuadamente la ocultación de las modificaciones de la detección . Magisk intenta eliminar todo rastro de su presencia durante el proceso de arranque ( 17 ) .
Magisk también es compatible:
-
Desactivación de
dm-verity y /data codificación modificando fstab (en ramdisk , /vendor o DTB ).
-
Modificación de las propiedades de sólo lectura utilizando resetprop herramienta, Modificación de
boot.img utilizando magiskboot y Modificación de la política de SELinux utilizando política mágica .
-
Ejecución de scripts de arranque utilizando
init.d -como el mecanismo ( 19 ) .
Esta es una breve descripción de las funciones que ofrece actualmente Magisk (AFAIK).
MÁS LECTURAS:
