Malicious apps can draw fake dialogs pixel-identical to system UI

What it is

On a shared screen, any app holding drawing capability can render its own UI pixel-identical to a system dialog, and neither the user nor the system can tell the two apart from the pixels alone. This attack surface is interface spoofing; the variant that stacks a transparent layer to hijack taps is clickjacking / tapjacking. It is a structural weakness of composited graphics stacks, not an implementation bug in any one system.

Why it happens

The window system composites every app's and the OS's output into one flat pixel plane; pixels carry no provenance, and touch events go to whichever window is topmost in z-order. A malicious app only needs to replicate the visual assets of the real dialog (system UI is public and screenshotable), present it in its own window, and the user's input lands in the attacker's controls. The system cannot distinguish "a legitimate app's own drawing" from "a forged system dialog" at the render layer, because drawing itself is anonymous. Tapjacking goes further: a transparent window sits above a real control, the user aims at A, the event lands on B.

Studying it

Two paradigms dominate: attack demonstration and measurement — reproducing overlay/tapjacking on real systems and surveying how many mainstream apps expose coverable sensitive screens; and user detection studies — giving participants spoofed/real dialog pairs and measuring recognition, mis-click and post-hoc detection rates. Typical independent variables are spoof fidelity and timing (the instant of a foreground switch, bundled with system animations); dependent variables are mis-click and input-leak rates. Methodological caution: participants told that spoofing exists show markedly higher detection, so warned-condition results overestimate ordinary users' defenses — only unsignalled conditions extrapolate.

Where it stops holding

Modern mobile systems gate "draw over other apps" behind an explicit permission, so exposure through reputable channels has narrowed without disappearing; desktop systems with a secure desktop — confirmation dialogs drawn on a surface with exclusive input — are immune by construction. The web's counterpart weakness is iframe-based clickjacking, mitigated by response headers and frame policies, not by users. The attack presupposes an installed malicious app: store vetting lowers reach, it does not change the mechanism.

Applying it

• System side: draw sensitive confirmations (passwords, payments, permissions) from the system process on a protected surface that declares itself non-screenshotable and non-coverable.
• App side: flag login and payment windows as excluded from screenshots/recording; verify the foreground app's identity before echoing sensitive state; apply the same flags to sensitive webview content.
• Verification: run a red-team pass that overlays your own confirmation dialogs — any surface a third-party window can cover and harvest input from is a gap.

Related

• Same group: O3.14.2 Secure attention sequences · O3.14.3 Spoofed prompts as phishing payloads · O3.14.4 Users rarely verify interface origin
• Nearby: O3.06 Trusted path · O3.04 Phishing detection cues · O3.08 Privilege-elevation confirmation
• Search terms: UI spoofing · overlay attack · tapjacking · trusted path