Android: ¿cómo funciona Magisk?

Después de tanto trabajar pudimos hallar el resultado de esta escollo que algunos los lectores de nuestra web presentan. Si quieres aportar algo más no dudes en dejar tu conocimiento.

Solución:

La mayor parte de su pregunta está cubierta en la documentación de Magisk. Citaré una de mis respuestas anteriores a una pregunta diferente, con algunas innecesario detalles 🙂

REQUISITOS PREVIOS:

Para tener una comprensión completa de cómo funciona Magisk, uno debe tener una comprensión básica de:

• Control de acceso discrecional (DAC)
  • Identificadores de usuario ([ESR]UID), set-user-ID
  • Capacidades de Linux (proceso y archivo) que proporcionan un control detallado sobre los permisos de superusuario
• Control de acceso obligatorio (MAC)
  • SELinux en Android
• Monte espacios de nombres, el uso de espacios de nombres de Android para permisos de almacenamiento
• Enlazar montaje
• Proceso de arranque de Android, particiones y sistemas de archivos
• Androide init servicios (el primer proceso iniciado por el kernel)
  • Archivos * .rc
• Estructura de boot partición (kernel + DTB + ramdisk), Blobs del árbol de dispositivos, 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 (generalmente shell) con UID cero (0) y todas las capacidades de Linux para que el proceso privilegiado pueda eludir todas las verificaciones de permisos del kernel.
Los privilegios de superusuario se obtienen normalmente mediante la ejecución de un binario que tiene:

• set-user-ID-root (SUID) bit establecido en él

  Así es como su y sudo trabajar en Linux en UNIX DAC tradicional. Los usuarios sin privilegios ejecutan estos binarios para obtener derechos de root.

• O capacidades de archivo (setgid,setuid+ep) establecido en él

  Este es el método menos común utilizado.

En ambos casos, el proceso de llamada 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 de root reales.

¿CÓMO ANDROID RESTRINGE EL ACCESO A LA RAÍZ?

Hasta Android 4.3, simplemente se podía ejecutar un set-user-ID-rootsu binary para elevar sus permisos al usuario root. Sin embargo, hubo una serie de mejoras de seguridad en Android 4.3 que rompieron este comportamiento:

• Android cambió a capacidades de archivo en lugar de depender de set-user-ID tipo de vulnerabilidades de seguridad. Un mecanismo más seguro: las capacidades ambientales también se han introducido en Android Oreo.
• Los servicios y los demonios del sistema pueden hacer uso de las capacidades de los archivos para obtener las capacidades del proceso (consulte 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 de proceso NO_NEW_PRIVS, ignorando set-user-ID así como capacidades de archivo. SUID también se ignora al montar /system y /data con nosuid opción para todas las aplicaciones.
• El UID se puede cambiar solo si el proceso de llamada tiene la capacidad SETUID / SETGID en su conjunto de límites. Pero las aplicaciones de Android están diseñadas para ejecutarse con todas las capacidades ya incluidas en todos los conjuntos utilizando el atributo de control de procesos CAPBSET_DROP.
• A partir de Oreo, la capacidad de las aplicaciones para cambiar UID / GID se ha suprimido aún más al bloquear ciertas llamadas al sistema mediante filtros seccomp.

Desde el independiente su Los binarios dejaron de funcionar con el lanzamiento de Jelly Bean, se realizó una transición al modo su daemon. Este demonio se inicia durante el arranque y maneja todas las solicitudes de superusuario realizadas por las aplicaciones cuando ejecutan el comando especial. su binario ⁽¹⁾. install-recovery.sh (ubicado debajo /system/bin/ o /system/etc/) que es ejecutado por un servicio de inicio preinstalado flash_recovery (inútil para aventureros; recuperación de actualizaciones después de una instalación de OTA) se usó para iniciar este demonio SU en el arranque.

El siguiente gran desafío se enfrentó cuando SELinux se estableció estrictamente enforcing con el lanzamiento de Android 5.0. El servicio flash_recovery se agregó a un contexto SELinux restringido: u:r:install_recovery:s0 que detuvo el puro acceso al sistema. Incluso el UID 0 estaba destinado 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 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?

La actualización de Magisk generalmente requiere un dispositivo con un cargador de arranque desbloqueado para que boot.img podría modificarse dinámicamente desde la recuperación personalizada ⁽⁴⁾ o un pre-modificado boot.img⁽⁵⁾ podría ser flasheado / arrancado, por ejemplo, desde fastboot.
^{Como nota al margen, es posible iniciar Magisk en una ROM en ejecución si de alguna manera obtiene privilegios de root usando algún exploit en el sistema operativo (6). Sin embargo, la mayoría de estas vulnerabilidades de seguridad se han solucionado con el tiempo. (7).
También debido a algunas vulnerabilidades a nivel de SoC (como el modo EDL de Qualcomm), el cargador de arranque bloqueado puede ser pirateado para cargar una imagen de arranque / recuperación modificada rompiendo la Cadena de Confianza. Sin embargo, estas son solo excepciones.}

Una vez que el dispositivo arranca desde parcheado boot.img, un demonio de 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 de root, ejecuta Magisk’s (/sbin/)su binario (accesible en todo el mundo por DAC y MAC) que no cambia el UID / GID por sí solo, sino que simplemente se conecta al demonio a través de un socket UNIX ⁽⁸⁾ y solicita proporcionar a la aplicación solicitante un shell raíz con todas las capacidades. Para interactuar con el usuario para otorgar / denegar su solicitudes de aplicaciones, el demonio está conectado con el Magisk Manager aplicación que puede mostrar indicaciones de la interfaz de usuario. Una base de datos (/data/adb/magisk.db) de permisos otorgados / denegados es construido por el demonio para uso futuro.

Proceso de arranque:

Se inicia el kernel de Android init con SELinux en permissive modo en el arranque (con algunas excepciones). init cargas /sepolicy (o política dividida) antes de iniciar cualquier servicio / demonio / proceso, lo establece enforcing y luego cambia a su propio contexto. De aqui despues, incluso init la política no le permite volver al modo permisivo ^{(9, 10)}. Ni la política puede ser modificada ni siquiera por el usuario root. ⁽¹¹⁾. Por lo tanto, Magisk reemplaza /init archivo con una costumbre init que parchea las reglas de la política de SELinux con SUPER CONTEXTO (u:r:magisk:s0) y define el servicio para lanzar el demonio Magisk con este contexto. Entonces el original init se ejecuta para continuar el proceso de arranque ⁽¹²⁾.

Trabajo sin sistema:

Desde el init el archivo está integrado boot.img, modificarlo es inevitable y /system la modificación se vuelve innecesaria. Ahí es donde el systemless término fue acuñado ^{(13, 14)}. La principal preocupación era hacer que las OTA sean más fáciles: volver a flashear el boot la imagen (y la recuperación) es menos complicada que volver a flashear system. OTA basada en bloques en un /system la partición fallará porque permite el uso de dm-verity para firmar criptográficamente el system dividir.

Sistema como raíz:

En dispositivos más nuevos, el kernel system-as-root no se carga ramdisk de boot Pero de donde system. Entonces [system.img]/init necesita ser reemplazado con Magisk’s init. También Magisk modifica /init.rc y coloca sus propios archivos en /root y /sbin. Significa system.img va a ser modificado, pero el enfoque de Magisk es no tocar system dividir.

Sobre A/B dispositivos durante el arranque normal skip_initramfs La opción se pasa desde el gestor de arranque en la línea cmd del kernel como boot.img contiene ramdisk para recuperar. Entonces Magisk parchea el binario del kernel para ignorar siempre skip_initramfs es decir, arranque en recuperación y coloca Magisk init binario en recuperación ramdisk dentro boot.img. Al arrancar cuando el kernel arranca en recuperación, si no hay skip_initramfs es decir, el usuario arrancó intencionalmente para la recuperación, luego Magisk init simplemente ejecuta la recuperación init. De lo contrario system.img está montado en /system_root por Magisk init, contenido de ramdisk luego se copian a / limpiando todo lo que existía previamente, los archivos se agregan / modifican en rootfs /, /system_root/system está enlazado a /system, y finalmente [/system]/init es ejecutado ^{(15, 16)}.

Sin embargo, las cosas han cambiado de nuevo con Q, ahora /system está montado en / pero los archivos que se agregarán / modificarán como /init, /init.rc y /sbin están superpuestos con monturas de enlace ⁽¹⁷⁾.

Sobre non-A/Bsystem-as-root dispositivos, Magisk debe instalarse para la recuperación ramdisk para mantener el enfoque sin sistema porque boot.img no contiene ramdisk⁽¹⁸⁾.

Módulos:

Un beneficio adicional de systemless enfoque es el uso de Magisk Modules. Si desea colocar algunos binarios en /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, puedes hacerlo sin tocar la partición haciendo uso de Magic Mount (basado en monturas de enlace). Magisk admite agregar y eliminar archivos superponiéndolos.

MagiskHide:⁽¹⁹⁾

Otro desafío 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 presentaron Red de seguridad como parte de Play Protect, que se ejecuta como un proceso GMS (Play Services) e informa a las aplicaciones (incluidas las propias Google Pay) y, por lo tanto, sus desarrolladores que el dispositivo se encuentra actualmente en un estado no manipulado⁽²⁰⁾.

El enraizamiento es uno de los muchos estados moderados posibles, otros son arranque no verificado, cargador de arranque desbloqueado, no certificación CTS, ROM personalizada, compilación depurable, permissive SELinux, ADB encendido, algunos malo propiedades, presencia de Lucky Patcher, Xposed, etc. Magisk usa algunos trucos para asegurarse de que la mayoría de estas pruebas siempre pasen, aunque las aplicaciones pueden usar otras API de Android o leer algunos archivos directamente. Algunos módulos proporcionan una ofuscación adicional.

Además de ocultar su presencia de SafeyNet de Google, Magisk también permite a los usuarios ocultar la raíz (su binary y cualquier otro archivo relacionado con Magisk) desde cualquier aplicación, nuevamente haciendo uso de bind mounts y mount namespaces. Para esto, zygote se debe vigilar continuamente en busca de máquinas virtuales de aplicaciones recién bifurcadas.

Sin embargo, es una tarea difícil ocultar realmente el dispositivo rooteado de las aplicaciones a medida que evolucionan nuevas técnicas para detectar la presencia de Magisk, principalmente desde /proc u otros sistemas de archivos. Así que un número de Las peculiaridades se realizan para respaldar adecuadamente la ocultación de modificaciones de la detección.. Magisk intenta eliminar todos los rastros de su presencia durante el proceso de arranque ⁽²¹⁾.

---

Magisk también admite:

• Inhabilitando dm-verity y /data cifrado modificando fstab (en ramdisk, /vendor o DTB). Consulte ¿Cómo deshabilitar dm-verity en Android?
• Cambiar las propiedades de solo lectura usando la herramienta resetprop, Modificando boot.img usando magiskboot y Modificación de la política de SELinux utilizando magiskpolicy.
• Ejecutando scripts de arranque utilizando init.d-como mecanismo ⁽²²⁾.

Esa es una breve descripción de las funciones ofrecidas actualmente por Magisk (AFAIK).

---

OTRAS LECTURAS:

• ¿Cómo proporciona SuperSU privilegios de root?
• ¿Cómo rootear manualmente un teléfono?
• Particiones y sistemas de archivos de Android
• Proceso de arranque de Android
• ¿Qué privilegios especiales tiene “/ system / xbin / su” con acceso de root?
• ¿Qué contexto de política pública permitirá que cualquier otro contexto acceda a él?

Magisk proporciona acceso root al proporcionar un binario “root” funcional montado en /sbin/magisk. Cualquier aplicación que intente ejecutar este binario mostrará Magisk para otorgarles acceso de root, que a su vez es administrado y mantenido por la aplicación Magisk Manager.

los /boot La partición es una partición separada que almacena algunos datos necesarios para iniciar el sistema. Incluye la inicialización de algunos mecanismos de muy bajo nivel como el kernel de Linux, controladores de dispositivos, sistemas de archivos, etc., antes de que aparezca el sistema operativo Android de capa superior. Está separado de tal manera que las cosas de nivel de Linux se almacenan en él, mientras que las cosas de nivel de Android (SystemUI, Configuración, etc.) se almacenan en el /system dividir. Modificando /boot no cuenta como modificar /system, el último de los cuales es lo que normalmente comprueban DM-verity y AVB.

Y Magisk se parchea y se integra en los /boot dividir, por lo que no toca la partición del sistema en absoluto. Utiliza una técnica llamada “un montaje de enlace” para cambiar el contenido de los archivos del sistema que ven otros programas, sin modificar realmente el sistema de archivos subyacente debajo de la partición del sistema (por lo que los archivos “reales” se dejan intactos).

Recuerda que te brindamos la opción de parafrasear tu experiencia si te fue de ayuda.

---

---

Utiliza Nuestro Buscador