Can Android developers defend us against Pixnapping attacks?
Mobile app security firm Guardsquare analyses ways to mitigate risks and says yes

Recently, I wrote about Pixnapping, an Android vulnerability that allows malicious apps to extract sensitive visual data from other applications — such as one-time passwords and authentication codes — without needing special permissions. Now, a firm known as Guardsquare which specialises in mobile app security solutions, has outlined key steps that developers can take to reduce system weaknesses.
"Malware has been a hot topic for our customers for years now, especially in the Android ecosystem," said Ryan Lloyd, Chief Product Officer at Guardsquare.
"The main reason is that the Android ecosystem is open and API-rich: it tends to be more vulnerable to malware attacks against applications," he added.
Read: Yango launches Flex Mode for part-time drivers in Pakistan
What is Pixnapping
Pixnapping, first explained by academic researchers earlier this year, targets the way Android renders visual data on screen. By exploiting differences in GPU-timing, attackers can infer pixel colours on-screen and reconstruct what another app displays — from 2FA codes to snippets of text.
Anyone employing this can then covertly read sensitive information displayed on a device’s screen, and the attack simply requires a user to install and open a malicious, no-permissions application. Because the method requires no permissions, it bypasses traditional defences and is difficult to detect.
In-app security
Pakistan’s Android ecosystem includes a significant number of devices running outdated versions of Android — as of last month, 17.3% of users still used Android 11, and 6.4% used Android 9 Pie, according to StatCounter, a free online statistical tool. For local developers, especially in fintech, e-commerce, and communications, the new research shows the need for stronger in-app security rather than relying solely on system updates.
Read more: Teams Wi-Fi attendance feature and hybrid work in Pakistan
Guardsquare notes that Google is preparing fixes for inclusion in upcoming Android security bulletins, and advises that proactive measures remain the best defence in the meantime.
The researchers say that keeping up to date with the latest Android versions should suffice, but they only tested a limited range of devices.
Measures for developers
Based on their blog, Guardsquare was able to recreate a Pixnapping attack following the basic principles detailed by the researchers in the paper. They then identified measures that could lower the risk of such attacks stealing Android user data, and are now collaborating with the researchers to find the most effective tool available.
"We contacted the researchers to let them know what we researched in our tests before we published the blog post," Ryan said. However, they haven't gotten a response back for all their findings yet.
Limit visibility of sensitive data
Designing apps so that critical information — such as security codes or payment details — appears only briefly or on user action, is one way to combat Pixnapping.
"The most obvious thing you can do for your app is to not display sensitive information for any extended period of time on screen," he said.
Reducing on-screen durations shortens an attacker’s observation window. "What we find sometimes is sometimes app developers will overshare, thinking there's no risk," he added. "If you're displaying authenticator codes for 30 seconds, it's hard not to make that visible, but it's a mitigation technique that's worth considering."
FLAG_SECURE
Android’s FLAG_SECURE is an Android developer option that was designed to prevent fraud/abuse of screens containing sensitive information. While in theory it should defend against a Pixnapping attack, its process can be exploited by Pixnapping, as the information is still rendered.
"Historically, when we've thought about viewing sensitive information in the Android ecosystem, we've always thought about it in terms of screen recording tech," said Ryan, adding that if someone is using a banking app and the application has software that allows someone to remotely view their screen, FLAG_SECURE ensures that the user's screen isn't transmitted to the APIs used by remote viewer technologies.
However, this does not work in Pixnapping's case as this attack operates at a "different technical layer that works underneath the visibility setting," and Guardsquare warns that developers should instead pair this flag with deeper defensive measures.
Traditional activity injection defences
Activity injections are acts of inserting unauthorised activities above the legitimate app to capture sensitive information or mislead the user, as per another Guardsquare research post. These can "intercept touches or presses....collect information that the user inputted," giving the information to the attacker.
Defences can work against Pixnapping to some degree as "it controls the visibility of those views through this side channel," Ryan says. However, he adds that this is only a temporary measure, and that the attack can be adapted to dismiss injection defences and get to the underlying rendered view.
Hide views when the app is in the background
Guardsquare's research shows that the most reliable method across different versions is to make sensitive components of an app invisible when an app is paused or switched out, which should minimise the chance of any data being inferred through malicious overlays.
"The best way to mitigate this attack is to limit the background visibility of these activities and views that are sensitive," Ryan stated. "You restrict it so that it's not visible when the app is not in the foreground," he added.
Guardsquare had conducted tests on a variety of Samsung products with many different Android versions. He went on to say that while it did require different considerations for different models as there are a variety of platforms that use Android, all with their own codebases and language frameworks, they were able to get this method to work most of the time.
However, the researchers say that this method is not completely reliable. When asked about this, Ryan said that it was likely owed to the differences in goals of their research and the original paper authors, "the goal of their research was different than the goal of ours...they wanted to prove a vulnerability existed...our role was that, given a vulnerability exists, how do we stop it?"
Harden against tampering and repackaging
Attackers can modify and repackage legitimate apps to disable security flags. "Once you[developers] implement malware defences, if that malware can't work successfully anymore, what attackers do is they take an app and repackage it without those defences, and then try and trick someone into installing it on their phone," Ryan said.
"We're not helping end users figure out how to protect their phone, but if you've got a multi-factor authentication app that displays tokens on screen, well, if you implement our suggested techniques or approaches, you can hopefully harden that app and limit the damage to the end users of your app," Ryan stated, adding that there is a "shared responsibility model" that needs to be followed by both developers and users to achieve the best results in protecting apps from attackers.
Guardsquare recommended runtime protection, obfuscation, and layers that can detect tampering to preserve the integrity of applications. However, the most effective advice remains the same: be careful when downloading applications.
"The advice is the same as browsing the internet 10, 20 years ago, right? Be careful what you download. So that remains true for the mobile ecosystem as well," he concluded.
For developers, the message is clear: if your app displays sensitive data, assume that someone can be watching. And with that assumption, ask yourself what you can do to protect the end user.

1722324840-0/BeFunky-collage]-(96)1722324840-0-208x130.webp)

















COMMENTS (1)
Comments are moderated and generally will be posted if they are on-topic and not abusive.
For more information, please see our Comments FAQ