Introduction: The Evolution of Android Rooting

For years, gaining root access on Android devices involved modifying the /system partition directly. This approach, while effective, came with significant drawbacks: it broke Over-The-Air (OTA) updates, often tripped SafetyNet attestation, and made device restoration complex. The advent of Magisk, developed by John Wu, revolutionized the Android rooting landscape by introducing a “systemless” method. This means Magisk achieves root without altering the /system partition, allowing users to enjoy the benefits of root while maintaining system integrity, passing SafetyNet, and preserving OTA update functionality. But how exactly does Magisk achieve this low-level feat, interacting intimately with the Android kernel?

Magisk’s Core Philosophy: Hiding in Plain Sight

Magisk’s genius lies in its ability to intercept the boot process and subtly modify the runtime environment without touching core system partitions. The fundamental principle is to operate from the ramdisk of the boot image, creating a virtualized environment where root-related files and modifications reside, effectively overlaying the original system without actually changing it. This “systemless” approach is achieved through a combination of boot image patching, advanced mount namespace manipulation, and a robust daemon that manages superuser requests.

Deep Dive into Boot Image Patching

The Android boot image is a critical component, typically comprising a kernel and a ramdisk. The ramdisk contains the initial root filesystem, including the init executable and its configuration scripts (init.rc). Magisk’s first step is to patch this boot image. When you flash a Magisk-patched boot image, the following occurs:

1. Extracting and Modifying the Ramdisk

   Magisk’s patching script (boot_patch.sh, often executed by the Magisk Manager app or TWRP) first extracts the original ramdisk from your device’s boot image. It then modifies the ramdisk to replace or hook into the device’s original init process. Specifically, Magisk places its own magiskinit binary in the ramdisk and modifies the init.rc or the init binary itself to execute magiskinit very early in the boot sequence.

   # Example of init.rc modification (simplified) # Original: # service init /system/bin/init # ... # Magisk's modification might look like: service init /sbin/magiskinit --post-fs-data # or a direct replacement if init itself is patched 

   The magiskinit binary is crucial; it acts as an intermediary, taking over the responsibilities of the original init process while also setting up Magisk’s environment. It’s essentially an ‘init companion’ that ensures Magisk starts before almost anything else.

2. Repacking the Boot Image

   After modifications, the ramdisk is repacked with the kernel, and the new boot image is signed (if applicable, though typically this is for custom ROMs or unlocked bootloaders) and ready to be flashed to the device’s boot partition.

The `magiskinit` & `magiskd` Symphony

Once the patched boot image is flashed and the device reboots, magiskinit takes control. This is where the magic truly begins:

1. `magiskinit`: The Early Stage Hero

   magiskinit‘s primary role is to set up Magisk’s early environment. It performs critical tasks like:

   • Mount Namespace Setup: It creates an isolated mount namespace for Magisk, ensuring that any file system modifications Magisk makes are not visible to the original system processes unless explicitly desired.
   • Creating `/sbin/.magisk`: This hidden directory becomes the base for all Magisk’s operations, holding its binaries, module data, and configuration.
   • Handling post-fs-data and late_start Services: It manages custom scripts or actions that need to run at specific points in the boot process, often used by Magisk modules.
   • Spawning magiskd: Crucially, magiskinit launches the magiskd daemon, which will handle all future superuser requests and module management.

2. `magiskd`: The Superuser Daemon

   magiskd is the heart of Magisk. It runs continuously in the background, listening for requests. When an app requests root access (e.g., via the su command), the request is routed to magiskd. magiskd then:

   • Checks its internal allow/deny list (configured via the Magisk app).
   • Presents a prompt to the user if the app is requesting root for the first time.
   • If approved, grants root access to the requesting process by changing its UID/GID to 0.
   • Manages the overlay filesystem for modules.

   # Simplified flow of an app requesting su and magiskd handling it # 1. App executes 'su' # 2. 'su' binary (Magisk's version) communicates with magiskd via socket # 3. magiskd verifies/prompts user # 4. If approved, magiskd forks the requesting process # 5. In the forked child, magiskd calls setuid(0), setgid(0) # 6. The child process now runs as root 

Virtualizing `/system` with Mount Namespaces

The ability to provide a