Rooting methods, explained

Before you start#

Required: Android’s Security Model, Verified Boot and Encryption, and SELinux Policy Lab. Rooting means arranging for a process to obtain elevated privileges, commonly UID 0, inside Android. It may be owner-authorized (for example, a debug build or modified boot image) or exploit-based; it does not necessarily edit /system, decrypt unavailable data, or control hardware-backed components. No universal method exists. This lesson compares mechanisms and trust changes; it gives no generic flash/unlock commands.

Learning goals#

Compare development-build root, boot-image userspace root, kernel-integrated root, kernel-image patching, and historical exploit-based access by privileged component, authorization, boot acceptance, changed TCB, support/update burden, and evidence limits. Explain why a manager APK alone is not root and why “systemless,” “kernel mode,” and “higher than root” are not safety rankings.

Method 1: development builds

Every method below must answer two different questions: how does privileged code get into the accepted booted system, and how does a particular request obtain its authority? Boot acceptance is the installation/trust question; a credential transition is the runtime question. A manager dialog answers neither by itself. The next chapter, How a process becomes root, works through real/effective/saved IDs, the adbd restart, and a broker-created root child rather than assuming an app can promote itself with setuid(0).

AOSP has user, userdebug, and eng variants (AOSP build targets). Broadly, user is the production variant with limited security access, userdebug is for developers studying a near-production build with debugging access, and eng has faster build times for day-to-day development. Exact switches depend on build configuration. On eligible development images, adbd can restart with root; in AOSP Android 14, should_drop_privileges() permits this when the build is debuggable and service.adb.root=1 (pinned source). This is owner-controlled development access, not an exploit against a retail build. A prompt is not evidence: inspect UID, build type, SELinux mode/context, and image state separately.

Method 2: boot-image userspace root

Magisk is a third-party project. In pinned v28.1, its PID-1 path chooses setup by boot layout and then executes the original Android init (init.cpp); MagiskSU mediates privileged requests. The exact image (boot, init_boot, or another supported arrangement), ramdisk layout, bootloader policy, and update behavior vary by device and release. A modified image may require an authorized unlocked bootloader; AOSP documents that unlocked devices can boot software not signed by the built-in root of trust, and state transitions wipe data (device state). Correct matching and recoverability are device-specific. “Systemless” can describe a runtime file view without rewriting the original system filesystem; it does not mean no persistent or boot modification.

Method 3: kernel-integrated root (KernelSU)

KernelSU describes a root mechanism with kernel-side enforcement and a userspace manager; its current guide says it works in kernel mode and grants root to userspace apps directly in kernel space. That guide also describes metamodule-based module management, which the pinned v1.0.1 examples below do not cover. A manager can present requests and policy, but it cannot add compatible kernel hooks to an arbitrary stock kernel just by being installed. Kernel source/configuration, integration method, kernel ABI, architecture, boot image, and userspace protocol all matter; the historical sucompat.c and allowlist.c citations below are the concrete implementation example, not a current compatibility promise.

Historical source example, KernelSU v1.0.1, commit 59ba84eb2b45c7ee7cded8774c918100d62a2712 (not a description of current releases): kernel/sucompat.c registers selected exec hooks in a supported configuration; the compatibility path checks whether the current UID is on the allowlist and invokes kernel-side privilege logic. See pinned sucompat.c, allowlist.c, and core_hook.c. UID/capabilities are not SELinux context: a kernel change or policy change may alter how a root child is labeled or authorized. Never assume the stock SELinux policy still describes a modified kernel/runtime; inspect effective configuration.

Method 4: kernel-image patching (APatch)

APatch is a separate third-party project. Its pinned tag 11282, commit e8e4651c16fb5075882a25813c8732285fdb3505, describes APatch as kernel-based, with APM module support and KPM kernel-module facilities based on KernelPatch (pinned project README). Its path is not interchangeable with KernelSU source integration or Magisk’s boot-time userspace path. The image/kernel support constraints and authorized boot path still apply.

The same pinned APatch README says the SuperKey “has higher privileges than root access” (README line 40). That is the project’s wording for a project-specific high-authority credential/authorization feature, not a Linux UID, capability, or universal privilege level. Do not compare it numerically with UID 0 or infer that it defeats every other boundary. Protect secrets and do not use such features to evade an owner’s policy.

Method 5: historical exploit-based access

Vulnerabilities in kernels, drivers, or privileged services have sometimes allowed unauthorized privilege transitions. They depend on exact vulnerable builds and conditions and are closed by fixes. This course provides no exploit chain, code, or ownership/integrity bypass. Study public advisories and patches; do not test production devices or services.

Method comparison and assurance

Status checked 2026-10-26. AOSP source uses android-14.0.0_r1; third-party source examples below are intentionally historical pins. No current release compatibility or physical hardware was tested.

Compare each configuration against a stated threat model, not a single “safe/unsafe” score. A debug root environment can be excellent for learning and unsuitable for protecting sensitive daily-use data. An unlocked non-root OS can have altered boot assurance without any app granted root. A root manager can improve request-level consent while increasing the consequence of manager/daemon compromise. Kernel location alone does not prove stronger isolation or better maintenance.

Practice#

Use a disposable emulator or read the pinned source references. Record (a) exact project/revision, (b) where privileged code runs, (c) who decides a request, (d) what must accept the modified boot content, (e) which SELinux context/policy is actually established, and (f) what evidence is missing. Do not modify a phone for this exercise. On a development image, adb root may succeed; on a production user build, rejection is expected. Neither result establishes third-party root compatibility.

Knowledge check#

1. Which approach lets an owner choose a debug build rather than exploit retail software?
2. What must a kernel-root manager have beyond an APK?
3. Is APatch’s SuperKey, described as having “higher privileges than root access,” a Linux privilege level?
4. Does a successful adb root establish a vendor production trust chain?
5. Name two components whose compromise matters in a root-manager design.

Answers#

1. A development build such as an eligible userdebug/eng image.
2. A compatible kernel-side integration/image and matching protocol/support; the APK cannot create that kernel authority alone.
3. No. It is wording for an APatch-specific mechanism, not UID/capability terminology.
4. No. It establishes only the debug-target shell’s observed identity, not production signing/trust properties.
5. Examples: boot-time code, kernel component, daemon, manager, policy database/key, update path.

Checkpoint#

Submit the comparison table for one chosen source revision, with hardware support explicitly marked untested. Ready if you distinguish root mechanism, boot acceptance, authorization, SELinux context, and evidence; revise if you rank projects by labels alone; not yet evidenced if a source revision or actual booted component is unknown. Remediation: reread the pinned source walkthrough and Threat Modeling Android Security.

Sources#

• AOSP, build variants, current docs, accessed 2026-10-26; and ADB at android-14.0.0_r1.
• Magisk, official repository and installation guide, checked 2026-10-26; third-party/moving documentation. Pinned v28.1 implementation is described in Magisk and Systemless Root.
• KernelSU guide, current project documentation (describes metamodules, not the v1.0.1 pin), checked 2026-10-26; plus pinned v1.0.1 source, historical implementation only.
• APatch pinned tag 11282 / commit e8e4651c16fb5075882a25813c8732285fdb3505 and KernelPatch; project descriptions, not independent security evaluation.
• AOSP Verified Boot device state, current documentation, accessed 2026-10-26.

Next: How a process actually becomes root