Si llevas tiempo trasteando con Android, es muy probable que hayas oído hablar de Magisk y KernelSU como dos de las soluciones de root más potentes que existen ahora mismo. Ambos permiten acceso de superusuario sin modificar directamente la partición del sistema, pero lo hacen con enfoques muy distintos y con implicaciones importantes en compatibilidad, módulos, actualizaciones OTA y, sobre todo, en la capacidad de ocultar el root frente a apps bancarias, juegos y la API de Play Integrity.
En las siguientes líneas vamos a desgranar qué diferencia realmente a Magisk de KernelSU y en qué casos te interesa pasarte de uno a otro. Veremos similitudes, diferencias técnicas, qué tal se llevan con los módulos, cómo se comportan frente a la detección de root, qué necesitas para migrar y qué opción encaja mejor según el uso que le des a tu móvil como dispositivo diario, de juegos optimizado con root o de pruebas.
Magisk vs KernelSU: visión general rápida
Magisk sigue siendo, a día de hoy, la referencia para la mayoría de usuarios que empiezan con root. Se instala parcheando la imagen de arranque (boot.img) de la ROM, funciona desde Android 6.0 en adelante y cuenta con la comunidad más grande, la documentación más extensa y el catálogo de módulos más amplio con diferencia.
KernelSU, en cambio, apuesta por una filosofía distinta: integra el root directamente en el kernel mediante GKI o un módulo LKM. Esto le permite un control muy fino sobre quién puede usar su, cómo se montan los módulos y qué capacidades y reglas SELinux se aplican, a costa de una instalación algo más técnica y de depender de que tu kernel sea compatible o exista un port específico.
Junto a ellos ha aparecido otro actor, APatch, que combina lo más cómodo de Magisk con el enfoque de parcheo de kernel de KernelSU, pero su ecosistema aún es más pequeño y su público más de nicho. Para comparar Magisk y KernelSU conviene tenerlo en el radar, aunque aquí nos centraremos sobre todo en esas dos soluciones principales.
Arquitectura interna: cómo rootea cada uno
La primera gran diferencia está en la forma en la que cada framework se engancha al sistema. Magisk modifica la imagen de arranque para inyectar su propio entorno systemless, mientras que KernelSU se integra en el núcleo de Linux.
Magisk utiliza un enfoque de modificación systemless de la boot image con Zygisk como pilar para cargar código en el proceso Zygote y poder inyectar módulos y hooks en apps y servicios del sistema. Más del 40% de su código nativo se ha reescrito en Rust, y se está migrando progresivamente más lógica para ganar seguridad y robustez, incluyendo soporte a nuevos formatos de sepolicy introducidos en versiones recientes de Android.
KernelSU, por su parte, apuesta por ejecutar el root dentro del propio kernel Linux del dispositivo. Puede funcionar aprovechando GKI (Generic Kernel Image) en versiones modernas de Android (12 a 16, con kernels 5.10 a 6.12) o bien mediante un módulo LKM en algunos escenarios, sin necesidad de reemplazar todo el kernel original. Esta integración hace que solo las apps autorizadas puedan ver y usar su, y permite afinar permisos (uid, gid, grupos, capacidades, políticas SELinux) de una manera mucho más granular.
APatch combina la idea del parcheo de boot.img estilo Magisk con inyección de código a nivel de kernel mediante KernelPatch, ofreciendo módulos APModule (al estilo Magisk) y un sistema de llamadas privilegiadas (SuperCall) con un SuperKey que puede tener más privilegios incluso que root. Es una solución potente, pero todavía menos extendida que Magisk o KernelSU.
Sistema de módulos y montaje de archivos
Uno de los puntos que más interesan a los usuarios avanzados es cómo gestionan los módulos Magisk y KernelSU, porque de ello dependen desde los tweaks de rendimiento hasta los bypass de integridad.
En la parte de similitudes, ambos utilizan módulos en formato ZIP y una estructura prácticamente idéntica: el contenido se instala en el directorio /data/adb/modules, permiten modificaciones systemless de /system y comparten scripts como post-fs-data.sh y service.sh con el mismo momento de ejecución y la misma semántica. También admiten system.prop y sepolicy.rule con funcionamiento equivalente, y ejecutan los scripts en un entorno BusyBox en modo standalone.
Ahora bien, la filosofía cambia bastante cuando miramos el montaje. Magisk integra en su núcleo un sistema de magic mount que se encarga directamente de sobreponer archivos y directorios de los módulos sobre el sistema, soportando mecanismos como los archivos .replace para sustituir o borrar rutas completas de forma sencilla desde el ZIP del módulo.
KernelSU, en cambio, ha pasado a un modelo de arquitectura de metamódulos para el montaje. El propio KernelSU ya no monta los módulos de serie: delega esa tarea en metamódulos enchufables como meta-overlayfs o Meta-Hybrid Mount (desarrollado en Rust, combinando OverlayFS y Magic Mount). Eso significa que, tras instalar KernelSU, necesitas añadir un metamódulo si quieres que tus módulos funcionen y se monten correctamente.
Además, el mecanismo de borrado y reemplazo de archivos en KernelSU es distinto. No admite los archivos .replace típicos de Magisk. En su lugar, para eliminar un archivo puedes crear un nodo con el mismo nombre mediante el comando mknod filename c 0 0, o bien usar variables específicas como REMOVE y REPLACE que el framework entiende para gestionar la eliminación y sustitución de rutas. Es un enfoque más bajo nivel, pero también muy flexible.
Hasta la ruta de BusyBox varía: Magisk coloca BusyBox en /data/adb/magisk/busybox, mientras que KernelSU la sitúa en /data/adb/ksu/bin/busybox. Este detalle es interno y podría cambiar en futuras versiones, pero conviene tenerlo en cuenta si tus scripts llaman a BusyBox usando rutas absolutas, por ejemplo con exploradores de archivos para dispositivos Android.
Compatibilidad de módulos entre Magisk y KernelSU
Como la estructura de los módulos es muy parecida, muchos usuarios se preguntan si sus módulos Magisk funcionarán tal cual en KernelSU. La respuesta rápida es: a menudo sí, pero no es un sí garantizado para todos los casos.
En términos de formato, al compartir ZIP y directorio /data/adb/modules, una buena parte de los módulos Magisk puede ejecutarse también bajo KernelSU, siempre que se instale el metamódulo de montaje correspondiente (por ejemplo meta-overlayfs o Meta-Hybrid Mount). Scripts como post-fs-data.sh, service.sh, system.prop y sepolicy.rule se interpretan prácticamente igual, de modo que lo básico suele ir bien.
Sin embargo, hay diferencias que afectan a la compatibilidad. KernelSU no soporta directamente la mecánica .replace ni la instalación de módulos desde recovery, y los módulos que dependen de estas características tendrán que adaptarse. En el lado positivo, KernelSU añade fases extra como post-mount (para ejecutar scripts tras completar el montaje de módulos) y boot-completed (para lanzar scripts cuando el arranque del sistema ha terminado), lo que permite estructuras de módulos algo más avanzadas.
Para los desarrolladores de módulos es importante poder saber en qué entorno se están ejecutando. KernelSU expone una variable de entorno llamada KSU que se establece a true cuando el módulo se corre bajo KernelSU. De esta forma, desde scripts como customize.sh, post-fs-data.sh o service.sh se puede hacer una ramificación condicional y adaptar el comportamiento según sea Magisk o KernelSU.
En la práctica, eso significa que muchos módulos populares pueden portar su lógica fácilmente para funcionar tanto en Magisk como en KernelSU con un único ZIP, siempre y cuando el desarrollador tenga en cuenta las diferencias en el sistema de montaje, en la ruta de BusyBox y en la forma de eliminar o reemplazar archivos.
Zygisk, root hiding y detección por apps bancarias
La otra gran preocupación hoy en día es la capacidad real de esconder el root a ojos de apps sensibles, como bancos, pasarelas de pago, apps gubernamentales o juegos con anti-cheat agresivo. Aquí Magisk y KernelSU ofrecen enfoques distintos, y ninguno es infalible.
Magisk se apoya en Zygisk, que actúa dentro del proceso Zygote para cargar módulos nativos y aplicar hooks. Esto es muy potente, pero también tiene una cara B: es extremadamente complicado ocultar completamente Zygisk. Muchas apps han ido incorporando chequeos específicos para detectar la presencia de Magisk o de sus rastros en el entorno, incluso cuando pasas Safetynet o la API de Play Integrity con ayuda de módulos como Play Integrity Fix, Tricky Store y similares.
De hecho, hay casos en los que el dispositivo supera sin problemas las pruebas oficiales de Google (Basic Integrity, Device Integrity e incluso algunos niveles más estrictos) y herramientas como Momo marcan el entorno como «normal», pero las apps bancarias siguen negándose a funcionar. Esto se debe a que, además de Play Integrity, muchas aplicaciones incorporan sus propios métodos de detección de root, comprobaciones de Zygisk, búsquedas de firmas de Magisk o de módulos concretos.
Algunas bifurcaciones de Magisk, como las builds «Alpha» y otras variantes no oficiales, han intentado mitigar esta exposición haciendo que Zygisk resulte menos evidente o reduciendo su huella. Sin embargo, a día de hoy esto suele ser más un parche que una solución definitiva, porque la detección de root se ha convertido en un juego del gato y el ratón donde los desarrolladores de apps actualizan sus mecanismos con relativa frecuencia.
KernelSU, al integrarse directamente en el kernel y controlar con detalle qué apps pueden ver o usar su, suele percibirse como más sigiloso en la práctica. Para muchas configuraciones, las apps que solo realizan comprobaciones básicas de root o inspeccionan rutas típicas de Magisk tendrán más difícil detectar que el dispositivo está rooteado, precisamente porque no se basa en el mismo stack (no hay Zygisk integrado en KernelSU).
Ahora bien, esto no significa que KernelSU sea inmune. Ningún framework puede garantizar pasar todos los niveles de Play Integrity ni engañar de forma permanente a todas las apps bancarias. A partir del momento en que desbloqueas el bootloader y modificas el entorno, siempre existe la posibilidad de que una actualización de la app o del sistema de detección empiece a marcar tu dispositivo como no confiable. Por eso, para un «móvil de banco» crítico, la recomendación más conservadora sigue siendo no tener root.
Requisitos, dificultad de instalación y actualizaciones OTA
A la hora de elegir entre Magisk y KernelSU es clave valorar lo sencillo o complejo que será instalar y mantener cada solución en tu dispositivo concreto, sobre todo pensando en las actualizaciones del sistema.
Magisk destaca por ofrecer una instalación relativamente sencilla y bien documentada. Básicamente necesitas el boot.img de tu ROM, lo parcheas con la app de Magisk y flasheas el resultado mediante fastboot o un recovery compatible. Tras cada OTA, lo habitual es tener que volver a parchear o, como mínimo, comprobar que Magisk sigue activo, porque el sistema suele sobreescribir la imagen de arranque.
KernelSU plantea un escenario algo más técnico. Para que funcione, tu dispositivo debe tener un kernel compatible con GKI 2.0 (u otros kernels soportados) o disponer de un port específico de KernelSU. En algunos casos se utiliza un módulo LKM que se carga sin reemplazar el kernel original, pero no es algo universal. Además, en instalaciones nuevas necesitas añadir un metamódulo de montaje (meta-overlayfs, Meta-Hybrid Mount u otro) si quieres usar módulos, lo que suma un paso adicional frente a Magisk.
Respecto a las OTA, algunos montajes con KernelSU pueden sobrevivir a ciertas actualizaciones gracias al uso de LKM u otras técnicas, pero no es algo garantizado ni homogéneo entre dispositivos y ROMs. En la práctica, en cualquier framework de root conviene asumir que tras cada actualización grande del sistema tendrás que revisar el estado del root y, en muchos casos, repetir parte del proceso.
Seguridad, perfiles de apps y control de permisos
Desde el punto de vista de la arquitectura de seguridad, la principal diferencia es que KernelSU juega con ventaja al correr dentro del kernel y ofrecer perfiles finos por aplicación, mientras que Magisk se centra más en la gestión de módulos y la compatibilidad.
Magisk maneja el root según un modelo clásico: las apps solicitan su y Magisk decide si lo concede o no, pero no existe un sistema de perfiles muy granular a nivel de kernel. No hay un aislamiento por namespaces tan agresivo como el que plantea KernelSU, y el foco está en la compatibilidad, el ecosistema y la facilidad de uso.
KernelSU implementa un sistema de perfiles de aplicaciones que permite aislar y controlar de forma muy precisa el acceso al root. Para cada uid se pueden definir grupos, capacidades, reglas SELinux y visibilidad del propio su, de modo que muchas apps ni siquiera pueden detectar que el sistema está rooteado. Esto ofrece un plus de seguridad y privacidad, sobre todo en dispositivos de prueba o uso profesional.
En el caso de APatch, se introduce un mecanismo adicional llamado SuperKey y SuperCall, con un nivel de privilegios incluso más alto que el root clásico, pensado para operaciones de kernel-level muy específicas. Es una solución muy potente para desarrolladores de bajo nivel, aunque menos amigable para el usuario medio.
Compatibilidad por fabricante y tipo de uso
No todos los dispositivos responden igual de bien a cada solución de root. La combinación fabricante + política de bootloader + kernel disponible influye mucho a la hora de decidir entre Magisk y KernelSU.
En los Google Pixel, Magisk suele ser la opción más directa y con mejor soporte general, mientras que KernelSU es una excelente alternativa cuando hay un kernel compatible o un port GKI específico. En Samsung, la situación se complica por Knox: al desbloquear y rootear se activa un flag irreversible, y el uso de ciertos modos, como LKM, puede no funcionar correctamente en algunos modelos, por lo que muchas veces Magisk o, en casos conflictivos, APatch son los caminos más realistas.
Mientras que en marcas como Xiaomi, Redmi o POCO, la elección dependen mucho de si estás en la ROM stock (MIUI o HyperOS) o en una custom ROM. En muchos escenarios Magisk funciona muy bien en la ROM de fábrica, mientras que KernelSU suele brillar más en entornos con kernels personalizados y ROMs de la comunidad. En OnePlus, tanto Magisk como KernelSU suelen dar muy buenos resultados, y suele ser más una cuestión de preferencias y compatibilidad de módulos.
Para marcas como Nothing, Motorola, ASUS (ROG y Zenfone) u OPPO/Realme, el patrón se repite: Magisk es normalmente el punto de partida recomendado por su mayor documentación y por la facilidad de encontrar guías específicas. KernelSU y APatch pueden ser alternativas muy interesantes cuando el camino con Magisk se complica o cuando necesitas funcionalidades a nivel de kernel que Magisk no cubre.
Si hablamos de tipo de uso, para un móvil de diario con equilibrio entre estabilidad y personalización, Magisk suele ser la apuesta más sensata. Para entornos de desarrollo, pruebas de seguridad o usuarios avanzados que quieren controlar hasta el último detalle de permisos y perfiles, KernelSU puede marcar la diferencia. Y cuando ningún camino standard termina de funcionar en un firmware concreto, APatch puede ser la navaja suiza que desbloquee la situación.
Migrar de Magisk a KernelSU (y viceversa)
Si ya estás rooteado con Magisk y estás valorando si merece la pena saltar a KernelSU, conviene que tengas claros los pasos generales y el impacto en tus módulos.
Antes de mover ficha, es fundamental contar con un backup completo del dispositivo (datos de usuario, exportaciones de apps críticas, copia de seguridad de archivos importantes) y tener a mano el boot.img stock de tu ROM o acceso a un recovery funcional. También ayuda mucho anotar qué módulos estás usando ahora y qué hacen exactamente.
La migración típica de Magisk a KernelSU implicará desinstalar Magisk por completo, flashear un kernel con soporte para KernelSU (ya sea mediante GKI o un port específico), instalar la app de gestión de KernelSU y, acto seguido, añadir un metamódulo de montaje (por ejemplo meta-overlayfs o una solución híbrida). A partir de ahí podrás empezar a reinstalar módulos compatibles, revisando uno a uno y comprobando qué tal funcionan bajo KernelSU.
El camino inverso, de KernelSU a Magisk, pasa por restaurar o flashear de nuevo la boot image o el kernel stock de la ROM, parchear con Magisk y reinstalar los módulos relevantes. En ambos sentidos, lo ideal es tomárselo con calma, probar cada módulo por separado y no dar por hecho que todo lo que funcionaba en un framework se va a comportar igual en el otro.
Sea cual sea el lado al que migres, ten presente que no existe una solución mágica y definitiva para las apps bancarias o los juegos más sensibles. El grado de éxito variará mucho según la combinación ROM + bootloader + fingerprint + versión de la app, y con cierta frecuencia será necesario ajustar módulos de Play Integrity, fingerprints y configuraciones específicas para cada caso.
Al final, elegir entre Magisk y KernelSU pasa por valorar qué te importa más: si priorizas comodidad, documentación y ecosistema, Magisk sigue siendo la opción más lógica. Si lo que buscas es control profundo a nivel de kernel, perfiles de apps avanzados y una superficie de detección distinta a la de Magisk, KernelSU se vuelve muy atractivo siempre que tu dispositivo y su kernel acompañen.
