With the recent attention on Signal Gate, we get asked: “How secure are messaging apps?”
As a backdrop, let me say that many messaging apps use “end-to-end” encryption to protect message content. That looks like strong protection against unwanted or even malicious harvesting of message content. However, this protection works inside a larger ecosystem—one that includes the application code, OS, device, network, and attack vectors. Let’s explore how this ecosystem can be compromised and how attackers can harvest message content even from the most seemingly secure messaging apps in real-world conditions.
For my red team friends, yes, I took a quick peek inside popular messaging apps to see what (if any) defenses messaging apps have against the threats listed below.
1. Can an Attacker Harvest Data Entered into a Messaging App?
A basic but effective attack involves harvesting message content as the user enters it into the messaging app. These attacks, like keyloggers, overlays, or malware that abuses accessibility services, all operate before content is encrypted and before a message is transmitted to the recipient. For example, overlay malware can present transparent screens over messaging apps, harvesting data in real-time via screen recording or mirroring keystrokes. Keylogging malware can also record data as it’s entered into a messaging app. Likewise, malware can tap into accessibility services to monitor activity streams or scrape screen content, including message text, contact names, and keystrokes. These exploits do not require the attacker to break the end-to-end encryption. They merely capture, copy, or replicate the data as the user enters it into the messaging app.
2. Can an Attacker Harvest Messages Prior to Encryption?
When a user composes a new message inside a messaging app, the first stop for that message is often an internal object—such as a StringBuilder, input buffer, or serialized message payload. The message string is placed there before any encryption routines are invoked. Malware or malicious apps that hook into the message composition functions or monitor memory allocations can harvest these plaintext messages prior to encryption. Some messaging apps may also write intermediate values like message drafts or pre-encryption payloads to local storage, shared memory, or inter-process communication (IPC) channels without any (or without proper) encryption. This requires more skill, but yes—an attacker could harvest the message content after data entry and before the content is encrypted.
3. Can an Attacker Harvest Message Content on Receipt?
Cyberattacks on messaging applications can also target the recipient. That’s because the message content must be decrypted for the recipient to read it. In other words, decrypted message content must reside in memory before being rendered on screen, creating a real attack vector inside otherwise secure messaging applications.
For example, messaging apps like Signal and Element (Matrix) decrypt message strings and pass the decrypted content through memory—e.g., message.getBody() or getClearContent()—before handing off to UI components like TextView.setText(). Attackers can exploit this by hooking into these methods using tools like Frida, Xposed, or other tools to intercept plaintext before it’s displayed. Likewise, on Android, with or without root, accessibility services can read on-screen text via AccessibilityNodeInfo.getText(). With root access, attackers can inspect shared memory (/dev/ashmem) or hook into native rendering calls to harvest message content. These techniques illustrate that because the message must be decrypted for the recipient to read it, the message content remains vulnerable at the moment of decryption and rendering.
4. Can an Attacker Decrypt Encrypted Messages from a Messaging App?
Many messaging apps store cryptographic values—such as encryption_salt, mac_salt, passphrase, and passphrase_iterations—in clear text in the local storage such as Android’s Shared Preferences or iOS’s NSUserDefaults. These values are used to generate encryption keys (e.g., in PBKDF2 or scrypt, each clearly visible in the messaging app’s codebase). Given that the inputs (salt, iterations, passphrase/seed) are all available, an attacker can use these values to reproduce the encryption key and decrypt the message content. In some apps or forks, the derived encryption keys are stored in Shared Preferences which can allow an attacker to simply use that key to decrypt the message content directly
Not many messaging apps use hardware-based StrongBox or Trusted Execution Environment for encryption keys. Those that do typically use fallbacks to software-based key derivation to ensure device compatibility. Given this, malware can be used to force a messaging app to fallback to software-based key derivation, opening the door to the methods listed above.
5. Are there Nation-State Threats that Target Messaging Apps?
Yes. There are nation-state malware that can be used to break into messaging apps. The well-known Pegasus spyware leverages zero-click exploits to compromise the entire device silently. Once installed, Pegasus gains root or equivalent access, bypasses OS protections, and has full access to decrypted messaging content, files, and even the microphone and camera. There are several known cases of nation-state actors using non-Pegasus malware to intercept IPC calls between app components, injecting modified binaries or libraries into secure apps, and tapping network traffic before encryption occurs, especially via compromised VPNs or root certificates.
End-to-End Encryption Isn’t Enough
Messaging apps have done exceptional work providing end-to-end encryption to protect message content. However, if you imagine using two cans connected by a string to send messages, end-to-end encryption protects the string. However, in real-world scenarios, the ‘knots’ holding the cans to the string and the ‘cans’ on opposite ends of the string themselves are not protected. Additionally, the encryption models are deterministic and the KDFs are known. So, the attacker can live on the string or unwind it.
True secure messaging needs active defenses to the modern-day exploits mentioned above – overlays, keyloggers, hooking, instrumentation, jailbreak, root, ATS malware, and more. Only then can we ensure message content is secure in the context of the larger ecosystem that end-to-end encryption lives. Unfortunately, for now, if someone asks you, “Is my messaging app secure?”, the only honest answer is “to modern threats, not really.”
If you want to protect a messaging app, drop us a line at info@appdome.com.
