Magisk vs KernelSU: la batalla por el superusuario este año

Rootear un móvil Android ya no es solo cosa de flashear Magisk y listo. Hoy en día hay varias soluciones potentes, y dos de las que más ruido están haciendo son Magisk y KernelSU. Ambas permiten tener permisos de superusuario y módulos para personalizar el sistema, pero su filosofía, su forma de integrarse en el sistema y, sobre todo, su capacidad para pasar desapercibidas ante apps bancarias y medidas de seguridad, son muy diferentes.

Si estás dudando entre seguir con Magisk o dar el salto a KernelSU, conviene entender con calma qué hace cada uno “por dentro”, qué compatibilidad con módulos ofrecen, qué problemas vas a tener con OTAs, con detección de root, y qué tipo de usuario encaja mejor con cada enfoque. A continuación vas a encontrar un análisis profundo, en español llano, pero sin dejar fuera los detalles técnicos importantes.

Magisk vs KernelSU: panorama general

Magisk se ha convertido en el estándar de facto para rootear Android, principalmente porque es relativamente fácil de instalar, tiene una comunidad enorme y un ecosistema de módulos gigantesco. Modifica la imagen de arranque (boot.img) para inyectar su propia capa de root de forma “systemless”, sin tocar directamente las particiones del sistema.

KernelSU, en cambio, apuesta por integrarse directamente en el kernel. En dispositivos con kernels GKI (Generic Kernel Image) o mediante un módulo LKM, KernelSU ejecuta el binario su dentro del propio núcleo de Linux. Esto le permite un control muy fino sobre qué apps ven o pueden utilizar el root y, en la práctica, suele ser más discreto frente a muchos mecanismos de detección y permite exprimir tu kernel.

A la hora de la verdad, la elección entre Magisk y KernelSU no es solo “qué se oculta mejor”, sino también qué tipo de dispositivo tienes, qué versión de Android y qué tipo de módulos necesitas. Además, entra en juego un tercer actor: APatch, que mezcla ideas de ambos mundos (instalación tipo Magisk con parches a nivel de kernel como KernelSU).

Similitudes entre Magisk y KernelSU en el uso de módulos

Aunque Magisk y KernelSU se apoyan en mecanismos internos muy distintos, desde el punto de vista del usuario y de los desarrolladores de módulos comparten bastantes cosas. De hecho, la estructura básica de los módulos es prácticamente idéntica, y eso facilita mucho portar un módulo de una plataforma a la otra.

Formato y ubicación de los módulos: tanto Magisk como KernelSU utilizan ficheros ZIP para empaquetar los módulos. Una vez instalados, los módulos acaban alojados en la misma ruta del dispositivo: /data/adb/modules. Esto quiere decir que, a nivel de archivos, el “esqueleto” de un módulo suele ser muy similar para ambas plataformas.

Modificación systemless del sistema: Magisk popularizó el concepto de modificar /system sin tocar directamente la partición. KernelSU también soporta cambios “systemless” a través de sus módulos, de forma que se pueden superponer archivos, binarios o librerías sin alterar físicamente el sistema base. Para el usuario esto se traduce en poder revertir cambios con relativa facilidad.

Scripts y propiedades compartidas: ambos frameworks procesan los mismos tipos de scripts dentro de los módulos:

• post-fs-data.sh, que se ejecuta en un momento muy temprano del arranque, con la misma semántica en los dos casos.
• service.sh, que se lanza una vez el sistema está más avanzado y se usa para servicios o demonios en segundo plano.
• system.prop, que permite definir propiedades de sistema que se inyectan de forma similar tanto en Magisk como en KernelSU.
• sepolicy.rule, que añade reglas a la política de SELinux con el mismo formato en ambas plataformas.

BusyBox y entorno de ejecución: los scripts de módulos se ejecutan en ambos casos sobre BusyBox con el llamado “Standalone Mode” activado. Eso garantiza un conjunto de utilidades POSIX bastante consistente, lo que facilita que el mismo script se comporte igual en Magisk y en KernelSU (siempre que se respeten sus diferencias concretas).

Diferencias clave en el sistema de módulos y montaje

Más allá de esas similitudes superficiales, la arquitectura interna cambia mucho. Magisk integra todo su sistema de montaje de módulos dentro del propio framework (el clásico magic mount), mientras que KernelSU delega esa tarea en un sistema de “metamódulos” enchufables.

Metamódulos en KernelSU: en lugar de que el núcleo de KernelSU se encargue de montar los módulos, el proyecto define un sistema extensible donde los “metamódulos” implementan las estrategias de montaje. El ejemplo de referencia es meta-overlayfs, que aprovecha OverlayFS para superponer archivos. También existen soluciones como Meta-Hybrid Mount, escritas en Rust, que combinan OverlayFS con mecanismos similares al magic mount de Magisk.

Esto implica que una instalación fresca de KernelSU no monta módulos por arte de magia: necesitas instalar, como mínimo, un metamódulo para que empiecen a funcionar. Sin metamódulo, el directorio de módulos estará ahí, pero sus cambios no se aplicarán al sistema.

Magisk, por su parte, lleva el “magic mount” integrado en su núcleo. Desde el momento en que flasheas o parcheas la imagen de arranque con Magisk, el framework ya sabe cómo montar módulos, superponer archivos y gestionar reemplazos. No tienes que añadir nada más para que un módulo estándar funcione.

Gestión de borrados y reemplazos de archivos: aquí hay una diferencia especialmente importante para desarrolladores de módulos:

• Magisk admite el método .replace (y también carpetas .replace) para indicar que un archivo o directorio del sistema debe eliminarse o reemplazarse por uno proporcionado por el módulo.
• KernelSU no soporta el método .replace. En su lugar, se utilizan variables como REMOVE y REPLACE en los scripts para controlar qué archivos y carpetas se eliminan o sustituyen. Además, para “borrar” un archivo concreto se puede recurrir a crear un nodo de dispositivo con mknod nombre_archivo c 0 0, de modo que ese archivo especial anula el original.

Rutas internas de BusyBox: otra diferencia más sutil es dónde vive BusyBox en cada framework. Magisk lo aloja en /data/adb/magisk/busybox, mientras que KernelSU lo sitúa en /data/adb/ksu/bin/busybox. Esto normalmente no afecta al usuario final, pero para scripts que hagan referencia explícita a la ruta puede ser importante. Además, el propio proyecto KernelSU avisa de que esta ubicación se considera un detalle interno que podría cambiar.

Detección del entorno: cómo saber si el módulo corre en Magisk o KernelSU

Para que un mismo módulo sea compatible con Magisk y KernelSU, hay que poder distinguir el entorno. KernelSU introduce una variable de entorno muy cómoda para ello: KSU. Cuando un script se ejecuta bajo KernelSU, esa variable se establece a true.

Esto se puede aprovechar en scripts como customize.sh, post-fs-data.sh o service.sh para tomar decisiones en tiempo de ejecución. Por ejemplo, usar un bloque if para ejecutar cierta lógica solo cuando el módulo está siendo gestionado por KernelSU, y dejar otro camino para Magisk.

Esta técnica es prácticamente imprescindible en módulos avanzados que dependen de detalles como las rutas de BusyBox, el sistema de reemplazo de archivos o la presencia de Zygisk. De este modo, el usuario solo instala un ZIP, pero por dentro el módulo sabe adaptarse a cada framework.

Capacidades, requisitos y público objetivo de cada framework

Si miramos la foto global de Magisk, KernelSU y APatch, cada uno apunta a un tipo de usuario, con distintos requisitos de kernel y diferentes niveles de complejidad en la instalación.

Magisk está pensado para la mayoría de usuarios que quieren root “sin demasiadas complicaciones”. Funciona desde Android 6.0 en adelante, y en lo técnico se basa en parchear la imagen de arranque del sistema (boot.img) para insertar su lógica de root y su sistema Zygisk. No exige un kernel específico, basta con poder flashear o inyectar el boot parcheado.

KernelSU se dirige más bien a usuarios avanzados que quieren un control muy fino a nivel de kernel y están dispuestos a lidiar con kernels GKI, módulos LKM o compilaciones personalizadas. Sus requisitos oficiales pasan por soportar GKI 2.0 en kernels 5.10 o superiores, aunque también puede funcionar en kernels más antiguos (desde 4.14) con compilaciones específicas.

APatch ocupa un lugar más de “tinkerer” o usuario de nicho. Solo soporta arquitecturas ARM64 y abarca kernels desde 3.18 hasta 6.12, con la salvedad de que KernelPatch todavía no se lleva del todo bien con kernel 6.6 salvo en algunos dispositivos concretos (como ciertos Xiaomi y OnePlus). Su idea es combinar la facilidad de instalación de Magisk (parcheas tu boot.img stock) con inyección de código a nivel de kernel (KPM).

En cuanto al soporte y la comunidad, Magisk sigue siendo el rey: decenas de miles de estrellas en GitHub, documentación extensa y una cantidad enorme de guías y tutoriales. KernelSU está creciendo a muy buen ritmo y ya cuenta con una comunidad notable, mientras que APatch sigue teniendo un tamaño menor y una documentación algo más cambiante.

Análisis en profundidad de Magisk

Magisk se ha ganado la fama de “estándar de la industria” porque funciona en un espectro amplísimo de dispositivos y ofrece un sistema de módulos muy pulido. Su arquitectura gira en torno a la modificación del boot image, con una implementación systemless basada en Zygisk.

En los últimos tiempos, más del 40 % del código nativo de Magisk se ha reescrito en Rust, y hay planes para seguir migrando subsistemas adicionales. Esto mejora la seguridad y la robustez del código, algo muy relevante en un componente tan sensible como el root.

Puntos fuertes de Magisk:

• Catálogo de módulos más grande con diferencia, cubriendo desde personalización visual hasta parches de seguridad y herramientas para desarrolladores.
• Compatibilidad muy amplia con gran cantidad de dispositivos y versiones de Android (a partir de 6.0).
• Documentación extensa y comunidad inmensa, lo que facilita encontrar solución a prácticamente cualquier problema.
• Soporte rápido para cambios de Android, incluyendo formatos nuevos de sepolicy introducidos en Android 16 QPR2.

Limitaciones de Magisk:

• Tras cada OTA suele tocar volver a parchear el boot image. No siempre, pero es un escenario muy habitual.
• La evasión de Play Integrity y apps sensibles es cada vez más complicada. Zygisk se ha vuelto un blanco muy jugoso y hay muchas formas de detectarlo, aunque podamos pasar tests como Safetynet o integridad básica.

Respecto a la instalación, para la mayoría de usuarios el proceso es relativamente sencillo: obtener la imagen de arranque o el firmware, parchearlo con la app de Magisk, flashear el resultado y, si todo va bien, empezar a instalar módulos. Ese flujo de trabajo está súper documentado y es una de las grandes bazas de Magisk.

KernelSU: root dentro del kernel y metamódulos

KernelSU adopta una postura radicalmente distinta: llevar el root al propio núcleo de Linux. En vez de inyectarse solo a través del boot image con una capa de usuario muy visible, KernelSU se integra a nivel de kernel, bien aprovechando GKI, bien mediante un módulo LKM (cargando un módulo del kernel sin reemplazar el kernel original).

Uno de los grandes puntos fuertes de KernelSU es la gestión de perfiles de apps. Solo aquellas aplicaciones a las que les des permiso explícito pueden ver y usar su. Esto significa que, en la práctica, muchas apps que “huelen” root no detectan nada porque, sencillamente, no tienen acceso ni visibilidad de ese binario.

Con KernelSU se pueden personalizar uid, gid, grupos, capacidades y reglas SELinux asociadas al su. Es decir, no solo controlas quién tiene root, sino también con qué permisos finos actúa, algo muy útil para escenarios de desarrollo, auditoría de seguridad o dispositivos muy sensibles.

Su sistema de metamódulos es otra de las señas de identidad. A diferencia del enfoque monolítico de Magisk, KernelSU delega el montaje de módulos en plugins:

• meta-overlayfs, que sirve como implementación de referencia usando OverlayFS para superponer archivos.
• Meta-Hybrid Mount, que combina OverlayFS con técnicas similares al magic mount, está escrito en Rust y ofrece gran flexibilidad.

Esto tiene una ventaja clara en términos de evasión de detección: el sistema de montaje deja de ser un único punto de fallo o de identificación. Si una técnica de detección se centra en un esquema concreto, siempre se puede diseñar otro metamódulo con una estrategia diferente.

En cuanto a compatibilidad, KernelSU cubre Android 12-16 en kernels GKI 5.10 a 6.12, y también funciona en algunos kernels más antiguos (4.14+) con builds manuales o puertos específicos de la comunidad. La desventaja es obvia: no todos los dispositivos tienen kernels adecuados o builds preparados, por lo que muchas veces dependes de ROMs o kernels personalizados.

KernelSU introduce además fases adicionales para los scripts de los módulos:

• post-mount: permite ejecutar scripts justo después de completar el montaje de módulos.
• boot-completed: brinda un punto de ejecución cuando el arranque del sistema ya ha finalizado, muy útil para tareas que necesitan que todo esté levantado.

Como contrapartida, una instalación limpia de KernelSU ya no incluye el mecanismo de montar módulos por defecto. Hay que instalar un metamódulo, y esa capa extra de configuración hace que el proceso sea algo más complejo que simplemente “flashear y olvidarte”, como suele pasar con Magisk en muchos dispositivos.

APatch: una tercera vía a tener en cuenta

Aunque la comparativa suele centrarse en Magisk vs KernelSU, APatch es una alternativa interesante para situaciones en las que Magisk o KernelSU no acaban de encajar bien en tu dispositivo.

APatch combina un flujo de instalación similar al de Magisk (parcheas tu boot.img stock, sin necesidad de código fuente del kernel) con un sistema de parches a nivel de kernel, el llamado KPM (Kernel Patch Module). Ese sistema permite inyección de código dentro del kernel mediante técnicas como inline-hook o syscall-table-hook.

En cuanto a módulos, APatch ofrece APModule (muy parecido al sistema de módulos de Magisk) y un esquema KPM para modificar el kernel. Su root se gestiona mediante un sistema de SuperKey, que otorga privilegios incluso por encima del root tradicional y se invoca por medio de una syscall específica (SuperCall).

Entre sus puntos fuertes destacan:

• Funciona con la imagen de arranque stock, sin necesidad de fuentes del kernel.
• Ofrece un modo Magic Mount por defecto, y permite activar OverlayFS o un “Lite Mode” según las necesidades.
• Está empezando a dar soporte a actualizaciones A/B tras OTA.

Sus limitaciones son claras:

• Solo soporta ARM64.
• KernelPatch todavía no funciona bien en kernel 6.6 salvo en algunos modelos concretos.
• La comunidad es más reducida y la documentación está en evolución, con cambios relativamente frecuentes.

Seguridad, módulos y evasión de detección

Si nos centramos en el aspecto de seguridad y detección de root, los tres frameworks juegan con cartas algo distintas. Para empezar, el modelo de permisos y la forma de aislar apps con root cambian bastante.

Magisk se basa en un modelo clásico centrado en apps. Otorgas o niegas root a cada aplicación y, aunque hay capas para ocultar la presencia de root (y módulos como los que intentan esquivar Play Integrity), no existe un aislamiento de namespaces tan profundo como el que maneja KernelSU con sus App Profiles.

KernelSU introduce aislamiento mediante perfiles de apps: cada aplicación tiene su perfil, y solo las autorizadas pueden ver o interactuar con su. El resto de apps, en la práctica, se comportan como si estuvieran en un sistema sin root. A esto se suma la posibilidad de ajustar SELinux, grupos, capacidades, etc., para cada perfil.

APatch utiliza el modelo de SuperKey, en el que solo las apps que invocan la syscall adecuada con la credencial correcta obtienen privilegios elevados. De nuevo, la idea es que las aplicaciones que no forman parte de ese esquema ni siquiera perciban que hay algo especial en el sistema.

En cuanto al ecosistema de módulos:

• Magisk tiene, con diferencia, el catálogo más amplio. La mayoría de guías, herramientas y parches están pensados de entrada para Magisk.
• KernelSU tiene un ecosistema intermedio pero en crecimiento. Muchos módulos diseñados para Magisk pueden funcionar en KernelSU si se instala un metamódulo de montaje compatible y se respetan las diferencias de reemplazo de archivos.
• APatch todavía va por detrás en número de módulos, repartidos entre APModule (a nivel de sistema) y KPM (a nivel de kernel).

Cuando hablamos de evasión de detección (banca, juegos, Play Integrity), ninguna de las soluciones puede garantizar resultados perfectos. Las comprobaciones cambian continuamente, y las capas que usan bancos o juegos con antitrampas agresivas no siempre se conforman con pasar un simple “Basic Integrity”.

Los tests de integridad básicos (Basic Integrity, Device Integrity) a veces se pueden superar usando módulos adicionales como Play Integrity Fix, Tricky Store y similares, pero la realidad es que la confiabilidad es muy baja, especialmente en el nivel de Strong Integrity. Además, el simple hecho de tener el bootloader desbloqueado ya coloca muchos dispositivos en listas negras.

Para apps bancarias o con antitrampas avanzadas, el resultado es muy dependiente del dispositivo, la ROM, la versión de Android y el estado del ecosistema de detección en ese momento. Magisk, al ser tan conocido y muy ligado a Zygisk, suele estar más en el punto de mira. KernelSU, al moverse a nivel de kernel y exponer su de forma más limitada, tiende a ir un paso por detrás en cuanto a detecciones generalizadas, aunque no es inmune.

Compatibilidad por marca y tipo de dispositivo

A la hora de elegir entre Magisk, KernelSU o APatch, la marca y el modelo del móvil cuentan más de lo que parece. No todas las combinaciones de kernel y ROM son igualmente amigables con cada framework.

En Google Pixel, la apuesta más segura suele ser Magisk, por soporte, documentación y compatibilidad general. KernelSU también puede ser una buena opción si dispones de un kernel GKI compatible o una build específica preparada, sobre todo si quieres aprovechar los App Profiles y el root a nivel de kernel.

En Samsung Galaxy con KNOX, Magisk es la opción más habitual, aunque hay que asumir que KNOX se disparará de manera permanente en cuanto desbloquees el bootloader o metas mano al sistema. APatch puede ser un plan B en dispositivos problemáticos o donde el enfoque tradicional dé demasiados errores. KernelSU no siempre se lleva bien con todos los kernels Samsung y, en algunos casos, el modo LKM puede dar problemas.

En Xiaomi, Redmi y POCO, Magisk suele encajar muy bien en ROMs stock tipo MIUI o HyperOS. Para ROMs personalizadas, KernelSU se vuelve más atractivo, especialmente cuando existe un kernel específico con soporte oficial o mantenido por la comunidad.

Mientras que en OnePlus, Nothing Phone, Motorola, ASUS, Realme y OPPO, Magisk sigue siendo la referencia, con KernelSU o APatch como alternativa dependiendo de la disponibilidad de kernels GKI, de la política de bootloader por región y del soporte particular de cada modelo. En algunos dispositivos gaming de ASUS, por ejemplo, KernelSU puede explotar mejor ciertas optimizaciones del kernel.

En cualquier caso, antes de lanzarte a flashear nada, conviene revisar bien foros de tu modelo concreto (XDA, comunidades de Telegram, grupos específicos de KernelSU o APatch) para ver qué framework está dando menos guerra en tu combinación de ROM, versión de Android y operador.

Migraciones entre Magisk, KernelSU y APatch

Cambiar de Magisk a KernelSU o a APatch, o viceversa, no es algo que se deba hacer a la ligera. Lo ideal es tratar cada migración casi como un pequeño “proyecto de mantenimiento” del dispositivo.

Antes de cualquier migración es esencial tener un checklist mínimo:

• Copia de seguridad completa de datos importantes (fotos, documentos, chats, etc.).
• Listado de módulos en uso y configuración clave, para poder replicarlos después.
• Imagen de arranque stock o firmware oficial a mano.
• Acceso a recovery funcional (stock o custom) para deshacer desastres.
• Pruebas de las apps críticas tras cualquier cambio (banca, trabajo, OTP, etc.).

De Magisk a KernelSU, el proceso suele implicar desinstalar Magisk por completo, flashear un kernel con soporte para KernelSU (GKI o con módulo LKM, según el caso), instalar la app de KernelSU Manager y añadir un metamódulo de montaje (como meta-overlayfs o hybrid_mount) para que los módulos empiecen a funcionar. Después toca reinstalar los módulos compatibles y configurar los App Profiles.

De Magisk a APatch, el flujo típico pasa por hacer copia, desinstalar Magisk, parchear la imagen de arranque con APatch Manager definiendo un SuperKey fuerte, flashear el boot parcheado, instalar el gestor de APatch y, por último, ir añadiendo módulos y comprobando que el root funciona como se espera.

Para volver de KernelSU a Magisk, normalmente hay que restaurar una imagen de arranque stock o de la ROM que uses, parchearla con Magisk, flashearla y luego reinstalar módulos desde el propio repositorio de Magisk o fuentes de confianza.

En todos los casos hay que reservar algo de tiempo (desde media hora hasta un par de horas), no hacerlo con prisas y tener claro cómo restaurar el estado anterior si algo sale mal.

¿Cuál ofrece mejor “sigilo” frente a apps bancarias y Play Integrity?

Una de las dudas más repetidas es si KernelSU “se esconde mejor” que Magisk, sobre todo ahora que muchas apps detectan Zygisk casi sin pestañear. Aunque la respuesta corta es que ningún método puede prometer invisibilidad total, sí hay matices importantes.

Magisk ha sido víctima de su propio éxito: al estar tan extendido, los desarrolladores de apps agresivas en seguridad han tenido años para afinar mecanismos de detección, ya sea mediante comprobaciones de Zygisk, de firmas binarias típicas, de rutas sospechosas o de cambios en el entorno de ejecución. Aunque pases Safetynet o algunas capas de Play Integrity, muchas apps de banca siguen negándose a funcionar.

KernelSU, al moverse a nivel de kernel y exponer su solo a apps autorizadas, reduce bastante la superficie de ataque para detecciones genéricas. Si la app bancaria no tiene visibilidad del binario ni del entorno de root, será más difícil que lo detecte… siempre que no utilice otros métodos (firmware, estado del bootloader, integridad estricta, etc.).

APatch, con su SuperKey y su enfoque basado en KernelPatch, también tiende a ser menos visible que Magisk en algunos escenarios, pero sigue sin haber garantías absolutas. Muchas detecciones modernas se apoyan en el propio estado del dispositivo (desbloqueo de bootloader, certificados, cambios en particiones, etc.), que ningún framework de root puede camuflar del todo.

En la práctica, si tu prioridad máxima es la “discreción”, KernelSU suele ofrecer una arquitectura más robusta que Magisk para ocultar root a nivel de apps no autorizadas. Eso sí, sigues dependiendo de cómo la app bancaria o de juegos implemente sus comprobaciones y de la combinación concreta de ROM y kernel que uses.

Teniendo todo esto en cuenta, lo razonable es elegir el framework que mejor encaje con tu dispositivo y tu nivel técnico, y asumir que, aunque se puedan mitigar muchas detecciones, las políticas de ciertos bancos o juegos pueden hacer directamente incompatible el root con sus servicios.

Al final, Magisk sigue siendo el camino más sencillo y bien documentado para la mayoría, KernelSU es perfecto para quienes buscan control profundo y mejor arquitectura de seguridad, y APatch resulta un salvavidas para configuraciones complicadas donde las otras dos soluciones se atragantan. Antes de dar el salto, infórmate bien de cómo se comporta cada una en tu modelo concreto, prepara copias de seguridad y ten siempre a mano la imagen de arranque original por si toca volver atrás.