How malicious Android apps used activity hijacking to steal data

一种获取Android应用信息的新思路

First published Nov 2012•Rewritten Nov 2026•Reverse engineering

This note describes a non-root technique for stealing credentials and personal data from an Android device, from a period when most practical mobile theft either required granting broad permissions or physically repackaging a target app.

The constraint that shaped the technique

On a non-rooted device, one app cannot simply read another app's files or memory; Android's process isolation blocks that directly. Sensitive data such as account credentials is either protected by the operating system's permission model, which requires the user to grant broad access, or sits inside the target app's own sandbox, which a different app cannot normally reach without root.

Activity hijacking: watch, then overlay

The technique sidesteps isolation rather than breaking it. A malicious app, running quietly, monitors the list of running processes through the system's activity manager and watches for a known target app, such as a banking or messaging app, to come to the foreground. The moment it does, the malicious app launches its own activity with a flag that brings it immediately to the front, placing a near-identical fake login screen directly over the real app before the user notices the switch. The user, seeing what looks like the expected login prompt, enters their credentials into the attacker's screen instead of the real one.

Why this matters more than it looks

The technique needs no root access and requests no unusual permissions beyond the ability to see which app is in the foreground, which made it quietly dangerous: it did not trip the obvious permission warnings that a more invasive approach would have. Its main weakness, noted honestly in the original writeup, is that it cannot smoothly hand control back to the real app after capturing credentials, which is often the detail that tips off an alert user.

How defenders and platform changes closed this off

Android's own hardening closed much of this gap over subsequent releases: visibility into other apps' running state was progressively restricted, and overlay permissions were made explicit, user-visible, and revocable, specifically because of hijacking and overlay-based phishing techniques like this one. For users, the durable advice is unchanged by any of that: unexpected re-prompts for a password, especially right after switching apps or returning to one already logged in, are a signal worth stopping on rather than typing through. For developers, apps handling credentials should use platform-provided secure input and authentication flows (biometric or system account APIs) rather than a custom login screen that a convincing-looking overlay can imitate.

This note has been rewritten and checked for this edition; it is not a copy of the original post.