Introduction: The Gateway to Root

The su binary is the linchpin of privilege escalation on Android devices. It stands for “substitute user,” and its primary function is to allow a user to execute commands with the privileges of another user, typically the superuser (root). For a forensic investigator, understanding the nuances of the su binary and the traces it leaves behind is paramount for determining if and how a device has been rooted, and subsequently, how privileges were escalated.

Understanding the su Binary’s Role

In a default, unrooted Android environment, the su binary either does not exist or is a non-functional stub. When an Android device is rooted, a functional su binary is typically placed in a system-wide executable path, often with the SUID (Set User ID) bit set. This SUID bit is critical; it allows the binary to run with the permissions of its owner (which is usually root), regardless of the user executing it. When a regular user executes su, the kernel sees the SUID bit, and temporarily elevates the process’s effective UID to that of the owner (root), thus enabling the execution of privileged commands.

Forensic Landscape of Android Rooting

Identifying the presence and activity of a malicious or unauthorized su binary is a key step in a forensic investigation. The traces left behind can reveal the method of rooting, the time of escalation, and potentially the actor responsible.

Typical Locations and Persistent Traces

Historically, su binaries were directly placed within the /system partition, making detection straightforward but also risking system integrity and easier unrooting. Modern rooting solutions, like Magisk, employ more sophisticated techniques to hide their presence.

• /system/bin/su and /system/xbin/su: These are the classic locations for older root methods. Finding a functional su in these directories is a strong indicator of a traditional, system-modifying root.
• /data/adb/magisk/su (or similar hidden paths): Magisk operates by creating a “systemless” root. It uses a custom init process to mount its own su binary over the original /system/bin/su (or /system/xbin/su) or provides it via its own PATH modifications. The actual binary resides in a hidden directory within /data, often associated with the Magisk installation.
• Memory Traces: Even if the su binary is hidden, its execution will leave traces in process memory and kernel logs.

To investigate these locations, an investigator would typically use an ADB shell, often requiring a rooted device for full filesystem access, or a forensic image.

adb shell
# Check classic locations
ls -la /system/bin/su
ls -la /system/xbin/su

# Check common Magisk path (may vary slightly)
ls -la /data/adb/magisk/su

# Find all SUID binaries on the system (might reveal hidden ones)
find / -perm /4000 2>/dev/null

The find command is particularly powerful as it searches the entire filesystem for files with the SUID bit set, which is a hallmark of any functional su binary.

Permissions, Ownership, and SUID Bit Analysis

The permissions of the su binary are crucial. A legitimate su binary must have the SUID bit set to function. Incorrect permissions or ownership can indicate tampering or a misconfigured root solution.

# Example output for a functional su binary
ls -la /system/bin/su
# -rwsr-xr-x 1 root shell 13832 2023-01-15 10:30 /system/bin/su

In this output, the s in the owner’s execute permissions (rws) indicates the SUID bit is set. The owner is root, and the group is shell (or root for older implementations). If these attributes are different, it might suggest a custom or modified su binary.

Furthermore, examining the ownership of the su binary can reveal unexpected users or groups, which could point to a sophisticated exploit attempting to masquerade its presence or abuse specific user context permissions.

Log File Analysis for Escalation Events

System logs are invaluable for tracking privilege escalation attempts and successful rooting events. Key logs to examine include:

• logcat: The Android logging system often records su execution, especially when a root management app (like Magisk Manager) grants or denies root access. Look for processes requesting su and the responses.
• Kernel Logs (dmesg, /proc/kmsg): These logs might contain low-level information about process execution, SUID bit changes, or file system modifications that occur during rooting.
• Audit Logs (if enabled): Some Android distributions or custom ROMs might enable audit logging, providing detailed records of system calls and privilege changes.

Searching for keywords like “su”, “root”, “uid=0”, “gid=0”, or the process ID of known root management apps can yield significant results.

# Capture real-time logcat output for su events
adb logcat | grep "su:"

# Examine kernel messages for SUID-related events (requires root)
adb shell "dmesg | grep SUID"

# Review shell history for su commands (if history is preserved)
adb shell "cat /data/misc/shell/history" # Location might vary

Shell history files, though often overlooked, can sometimes provide direct evidence of an attacker or user manually executing su commands, especially if the device was physically accessed.

Examining SELinux Policy Modifications

SELinux (Security-Enhanced Linux) is a mandatory access control system that adds an extra layer of security on Android. For su to function correctly, particularly with modern “systemless” roots, modifications to the SELinux policy are often necessary.

Magisk, for instance, operates by patching the kernel’s sepolicy at boot time to allow its su daemon to operate without violating SELinux rules. Forensic analysis should include examining the active SELinux policy, though this often requires specialized tools or an understanding of sepolicy syntax.

Simple checks can indicate SELinux status:

adb shell
getenforce # Should return "Enforcing" on a healthy system
sestatus # Provides more detailed SELinux status (may not be available on all devices)

If getenforce returns “Permissive” or “Disabled” unexpectedly on a device that should be enforcing, it could be a sign of a tampered SELinux configuration, possibly to facilitate rooting or other exploits.

Post-Exploitation Artifacts and Environment Variables

Beyond the su binary itself, other artifacts can indicate root escalation:

• Environment Variables: Elevated privileges can sometimes lead to changes in environment variables, particularly PATH, to include directories where malicious or custom binaries reside.
• Custom Files/Directories: Look for new or modified files in system directories, particularly those belonging to root or other privileged users, that are not part of the stock Android image.
• Installed Root Management Apps: Apps like Magisk Manager, SuperSU, or other “root checker” apps, while not always definitive, can indicate a user’s intent to root or confirm root status.

Investigating the PATH variable can reveal suspicious entries:

adb shell 'echo $PATH'

An investigator should look for unusual directories prepended or appended to the standard PATH, especially those pointing to /data partitions or temporary directories, which could host malicious binaries.

Conclusion: Piecing Together the Root Story

Forensically analyzing the su binary and its surrounding environment on Android is a complex but critical task. By meticulously examining filesystem integrity, permissions, log files, SELinux policies, and other system artifacts, investigators can reconstruct the narrative of privilege escalation. This multi-faceted approach, combining direct binary inspection with contextual system analysis, provides a robust methodology for determining the presence and extent of root compromise on an Android device.