The Not-So-Silent Type: How Popular Chinese Keyboard Apps Leak Your Keystrokes

TLDR: Researchers at Citizen Lab and Princeton University discovered that popular Chinese keyboard apps like Baidu, Sogou, and iFlyTek use flawed, proprietary encryption to transmit user keystrokes. These apps effectively function as keyloggers, exposing sensitive data to both passive and active network eavesdroppers. Pentesters should prioritize inspecting non-TLS traffic in mobile applications, as these findings prove that even "encrypted" traffic can be trivially decrypted if the implementation relies on custom, broken crypto.

Security researchers often focus on finding complex RCE chains or sophisticated sandbox escapes, but sometimes the most dangerous vulnerabilities are the ones hiding in plain sight. A recent presentation at DEF CON 2024 by Jeffrey Knockel and Mona Wang exposed a massive, systemic failure in how popular Chinese keyboard applications handle user data. These apps, which boast hundreds of millions of users, were found to be transmitting keystrokes over the network using custom, proprietary encryption schemes that are fundamentally broken.

The Anatomy of a Keylogger

At the core of this research is a simple, terrifying reality: these keyboard apps are essentially keyloggers. When a user types, the app captures the input to provide cloud-based predictive text and auto-correction. While sending this data to a server is a known feature of these apps, the security of that transmission is where the failure occurs. Instead of using standard, battle-tested protocols like TLS, these developers opted to "roll their own" cryptography.

The researchers used Ghidra to reverse-engineer the binaries and Wireshark to capture the network traffic. What they found was a collection of amateur cryptographic mistakes. For instance, some implementations used ECB mode, which is notoriously insecure because it fails to provide data confidentiality. Others used weak key generation techniques, such as deriving keys from the current Unix time in milliseconds, or even hardcoding keys directly into the binary.

Breaking the "Encrypt Wall"

One of the most egregious examples involved a custom encryption system dubbed the "Encrypt Wall." The researchers demonstrated that by observing the traffic, they could perform a CBC padding oracle attack to decrypt the intercepted keystrokes. Because the server provided distinct responses for valid and invalid padding, an attacker could systematically decrypt the traffic block by block.

The researchers even found instances where the initialization vector (IV) was transmitted in the clear or was predictable, further simplifying the decryption process. In one case, the app used a static, hardcoded AES key that was effectively public knowledge once the binary was reversed. For a pentester, this is a goldmine. If you are testing a mobile application and see non-TLS traffic, do not assume it is just noise. If the traffic has high entropy, it is likely encrypted, but if you can identify the underlying block cipher and mode, you might be able to break it using the same techniques shown here.

Real-World Impact and Defensive Reality

The impact of this research is staggering. Millions of users, including those in sensitive positions, have had their keystrokes—passwords, private messages, and search queries—transmitted over the network in a way that any active network adversary could intercept and decrypt. This is not a theoretical risk; it is a practical, ongoing threat to user privacy.

From a defensive perspective, the solution is straightforward but rarely implemented: stop rolling your own crypto. Developers should rely on established libraries and protocols. If an application needs to send data over the network, it should use TLS with proper certificate pinning. For blue teams, the takeaway is to monitor for non-standard network traffic originating from mobile devices. If an app is communicating over UDP or raw TCP instead of standard HTTPS, it should be treated as a high-risk indicator.

Why This Matters for Pentesters

This research serves as a stark reminder that we cannot trust the "security" claims of an application just because it claims to encrypt data. As a pentester, your job is to verify those claims. When you encounter an application that uses proprietary encryption, your first step should be to pull the binary and start reversing. Look for the cryptographic primitives. Are they using standard libraries like OpenSSL, or are they calling custom functions that perform XOR operations on hardcoded byte arrays?

The researchers noted that after their disclosures, some companies switched to TLS, while others doubled down on their broken, custom implementations. This highlights a cultural issue in software development where "security through obscurity" is still prioritized over actual, verifiable security.

If you are performing a mobile assessment, do not skip the network analysis phase. Use a proxy like Burp Suite or a packet capture tool to inspect every request. If you see traffic that looks like encrypted blobs, don't just move on to the next finding. That blob might be the most critical vulnerability in the entire application. The next time you see a "secure" app, ask yourself: are they using TLS, or are they just hoping no one looks closely enough to see the "Encrypt Wall" they built?