Weaponizing Android SystemUI: Bypassing BAL and LMKD for Persistent Hijacking

TLDR: Researchers at Black Hat Asia 2024 demonstrated how to weaponize Android’s Picture-in-Picture (PiP) mode to bypass Background Activity Launch (BAL) restrictions and LMKD protections. By manipulating SystemUI, an attacker can maintain a persistent, stealthy malicious process that survives standard termination attempts. This research highlights a critical path for privilege escalation and persistent execution on modern Android devices, forcing a re-evaluation of how system-level components handle background tasks.

Android security has spent years hardening the framework against Activity Hijack Attacks (AHA). We have seen the introduction of strict Background Activity Launch (BAL) restrictions and the aggressive management of the Low Memory Killer Daemon (LMKD). These defenses were supposed to kill the "classic" malware model where a background process could simply pop an activity to the foreground to steal credentials. But as this research proves, the framework itself remains a massive, complex attack surface. When you can force the system to treat your malicious activity as a trusted, system-level component, those security boundaries evaporate.

The Mechanics of the Hijack

The core of this research lies in abusing the PiP mode, a feature designed to allow users to watch video while interacting with other apps. Because PiP is a system-level feature, it is handled by the SystemUI component. The researchers discovered that by triggering specific IPC calls, a non-privileged application can force its activity into a PiP state.

Once in PiP mode, the activity is pinned to the top of the screen. Crucially, because it is managed by SystemUI, it bypasses the standard BAL restrictions that would otherwise prevent a background app from launching an activity. The researchers demonstrated that by sending an abnormal Rect object to the setSourceRectHint API, they could shrink the PiP window to a single pixel. This makes the malicious activity effectively invisible to the user while it remains active and pinned, maintaining a persistent presence that is difficult to detect or terminate.

Bypassing LMKD and Maintaining Persistence

Persistence is the holy grail for mobile malware. LMKD is designed to reclaim memory by killing background processes, and it typically targets apps with high oom_adj scores. The researchers found that by binding their malicious service to a system-level component, they could manipulate the system’s perception of their process priority.

By exploiting the AccessibilityService or AccountManager APIs, an attacker can bind their process to a system-level manager. Since these managers run with a system-level UID, the malicious process inherits a much lower oom_adj score, effectively shielding it from LMKD. Even when a user manually attempts to "Force Stop" the application through the settings menu, the process remains alive because it is tethered to the system-level manager. This is a classic Broken Access Control scenario where the framework trusts the manager's binding implicitly.

Technical Implementation

The researchers provided a proof-of-concept demonstrating how to trigger this behavior. The following snippet illustrates the logic used to initiate the PiP mode with an abnormal Rect to achieve the invisible, persistent state:

PictureInPictureParams.Builder builder = new PictureInPictureParams.Builder();
// Setting an abnormal 1x1 pixel rect to make the PiP window invisible
builder.setSourceRectHint(new Rect(1, 1, 2, 2));
enterPictureInPictureMode(builder.build());

This technique relies on the fact that the system does not sufficiently validate the Rect bounds provided by the application. While CVE-2021-0485 was a previous attempt to address similar issues, the researchers showed that the underlying logic in the PipBoundsAlgorithm could still be manipulated. Furthermore, CVE-2023-40116 highlights the ongoing struggle to patch these framework-level bypasses.

Real-World Implications for Pentesters

For those of us performing mobile application security assessments, this research changes the threat model. You can no longer assume that an app is "just" a background process. If an application requests accessibility permissions or account management capabilities, you need to audit how it interacts with the ActivityManagerService and SystemUI.

During an engagement, look for applications that attempt to bind to system services without a clear, legitimate business case. If you are testing for persistence, attempt to force-stop the application and observe if the process tree remains active or if it respawns immediately. The impact of this vulnerability is significant: an attacker can maintain a persistent, invisible overlay that can capture user input or perform actions on behalf of the user, all while appearing to be a standard, low-privilege application.

Defensive Considerations

Defending against this requires a shift in how we view system-level trust. The Android framework needs to implement stricter validation for IPC calls originating from non-privileged UIDs, especially those that interact with SystemUI or trigger PiP transitions. For developers, the best defense is the principle of least privilege. Do not request accessibility or account management permissions unless they are strictly necessary for the app's core functionality. If your app does not need to be a system-level manager, do not try to become one.

The complexity of the Android framework means that vulnerabilities like these will continue to emerge. As researchers, our job is to keep digging into these IPC boundaries. The next time you see an app requesting an unusual set of permissions, don't just flag it as a policy violation. Trace the IPC calls. See what it's binding to. You might just find the next persistent backdoor.